Closed michaelkirk closed 2 years ago
Looks like we can't avoid going into that rabbit hole. At least we're not alone (https://github.com/locationtech/jts/pull/567 https://trac.osgeo.org/geos/ticket/1005). Looks like your solution with an explicit empty_point
is the cleanest one. But in the end we would probably need this for all geometry types?
Anyway let's merge this and improve handling of empty geometries seperately. Thanks a lot!
in the end we would probably need this for all geometry types?
Luckily, I think POINT EMPTY
is kind of an exception. It seems like we can more reasonably handle other empty geometries like MULTIPOINT EMPTY
, LINESTRING EMPTY
, etc. without exploding.
I've expounded on this here: https://github.com/georust/geozero/pull/21
Fixes #19
I have a couple things I was hoping to get input on before submitting for actual review... questions inline.Update: OK! Ready for review!Definitely some weirdness around handling
POINT EMPTY
, but I went with what felt to me like a reasonable compromise of trying to:POINT EMPTY
where possible. Currently this is just Wkt->Wkt which isn't very likely to be used, but I suppose if someone wrote a custom processor, they might want to have the info.EMPTY
in a MultiPoint.Err
when encountering aPOINT EMPTY
. I couldn't find a way to "be lazy" and ignore aPOINT EMPTY
for a top level geometry - we have to return something. And havingWkt("POINT EMPTY).to_geo() -> point!(x: 0, y: 0)
seems likely to be a bad surprise.