Shapely: cascaded_union crashes: No Shapely geometry can be created from null value

Created on 22 Mar 2013  路  11Comments  路  Source: Toblerity/Shapely

I started with it crashing on a union of 1506 shapes. I did a random.sample(200) on that list until I found a smaller crashing set. continuing to try to downsample that to find a minimum crashing set (all the pairs of 2 didn't crash).

I tried doing buffer(0) on all my polys, I tried exploding all my multipolys into individual loops, buffer(0) each loop, and checking is_valid, and cascaded_union was still crashing.

here's the input: http://f.cl.ly/items/343v1Q3M300f063K260V/200-fail.txt

from shapely.ops import cascaded_union
from shapely.wkt import dumps, loads
geoms = [loads(l) for l in open('200-fail.txt')]
cascaded_union(geoms)

also fails

geoms = [loads(l).buffer(0) for l in open('200-fail.txt') if loads(l).buffer(0).is_valid]
cascaded_union(geoms)

Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/shapely/ops.py", line 75, in cascaded_union
return geom_factory(lgeos.methods'cascaded_union')
File "/usr/local/lib/python2.7/dist-packages/shapely/geometry/base.py", line 32, in geom_factory
raise ValueError("No Shapely geometry can be created from null value")
ValueError: No Shapely geometry can be created from null value

geos

Most helpful comment

Curious about this issue. Just observed it occurring with GEOS 3.6.2. According to the issue tracker results on GEOS that @sgillies linked to earlier in this issue, it appears 1/2 the related issue are closed and 1/2 are still open.

So it _seems_ like this is still an unresolved issue with GEOS. Is this a correct assumption?

All 11 comments

Confirmed. While I think this is a GEOS bug (I suspect one of http://trac.osgeo.org/geos/search?q=cascaded+union&noquickjump=1&ticket=on), I'd like to do what I can. Any suggestions?

I encountered a similar problem with unary_union. In my case the troublemaker polygon had a hole in it. I went to QGIS, deleted the hole and then reran the union. Voila... success.

Thanks to all who work on this project.

I'm running into a similar problem using a unary_union on LinearRings packaged into a MultiLineString. The intent is to "node" the linestrings for use in polygonize.

  File "test4.py", line 6, in <module>
    mm = unary_union(mls)
  File "/usr/local/lib/python2.7/dist-packages/shapely/ops.py", line 89, in unary_union
    return geom_factory(lgeos.methods['unary_union'](collection))
  File "/usr/local/lib/python2.7/dist-packages/shapely/geometry/base.py", line 32, in geom_factory
    raise ValueError("No Shapely geometry can be created from null value")
ValueError: No Shapely geometry can be created from null value

All rings in the MultiLineString are valid and simple.

This file contains the problematic wkt http://blog.perrygeo.net/assets/files/bad_mls.wkt.gz .

And the code to recreate it:

from shapely.wkt import loads
from shapely.ops import unary_union
mls = loads(open("bad_mls.wkt", 'r').read())
mm = unary_union(mls)

I've tried to isolate the geometry or geometries that cause the problem
but have not been able to identify a smaller subset that also fails.
Simply removing random rings eliminates the error but the re-inclusion of those particular
rings doesn't _necessarily_ mean it will fail - sometimes it will work if other geometries are
removed. IOW it doesn't appear to be one specific geometry but some combination that I've yet to identify.

Using shapely 1.2.17 and geos 3.3.8 on ubuntu 12.04.

EDIT: a workaround is to split up the rings into two MultiLineStrings and do a regular union operation; much slower but seems more robust for the datasets I'm testing with. I've set up a fallback like so:

        try:
            log.debug("calculating union (try the fast unary_union)")
            mm = unary_union([mls1, mls2])
        except ValueError:
            log.error("unary_union FAILED")
            log.debug("calculating union again (usingh the slow a.union(b))")
            mm = mls1.union(mls2)

perrygeo -- falling back to a slower linear union in cases where cascading_union fails was a great suggestion that I hadn't thought of.

Labeled a likely GEOS bug. Will pursue a solution there.

Saw this bug with shapely 1.2.15 and it appears to go away with 1.2.18 (using geos 3.3.8). Here is a proposed extra test for cascaded union:

https://github.com/schwehr/Shapely/blob/85af13f33a75def2a066011c06679d77faaf20a5/shapely/tests/test_cascaded_union.py

Thanks, @schwehr, I've included a test based on that one in 0043a84.

Thank you all of you for all these helpful comments. Regards.

Curious about this issue. Just observed it occurring with GEOS 3.6.2. According to the issue tracker results on GEOS that @sgillies linked to earlier in this issue, it appears 1/2 the related issue are closed and 1/2 are still open.

So it _seems_ like this is still an unresolved issue with GEOS. Is this a correct assumption?

@kuanb yes, I believe you are right.

Is the test that was implemented by @sgillies in 0043a84 now failing since GEOS 3.6.2 or does that test not cover the remaining error scenario? I鈥檓 currently seeing this error with unary_union.

Was this page helpful?
0 / 5 - 0 ratings