Should we support LINEARRING type?
michaelkirk opened this issue · 13 comments
e.g. LINEARRING(0 0, 0 5, 5 5, 5 0, 0 0)
JTS uses this - but it's unclear to me if this is a standard thing that we would benefit from supporting.
https://geos.osgeo.org/doxygen/classgeos_1_1io_1_1WKTWriter.html
GEOS also uses it apparently
A non-standard "LINEARRING" tag is used for LinearRings. The WKT spec does not define a special tag for LinearRings. The standard tag to use is "LINESTRING".
Not sure! My initial feeling is LINEARRING
could be behind a feature flag? Though I'd love to hear how commonly it gets used, though not sure how to do that
For comparison: openlayers seems to have considered this a while back (openlayers/openlayers#2679). IIUC, they did not support it! However, given JTS, geos and shapely output it, it would be good to support it behind a feature flag.
Along the same lines as this issue: JTS, geos, shapely also seem to support nan, inf, etc. in WKT. They have an "is_valid" predicate that'll be false, but allow conversion to / from wkt with nans. Eg. POINT (nan 0.0)
or POINT (10 inf)
it would be good to support it behind a feature flag
That sounds like a smart approach to me.
Should we support LINEARRING
as another enum-case to the Geometry
type here? Then, convert to LineString
in the conversion to geo-types?
Feature-gated enum values are a bit weird. Take this example:
- program P uses crates C1 and C2
- crates C1 and C2 use
wkt
- crate C2 enables the
linearring
feature - crate C1 stops building because it's no longer exhaustively matching a
wkt::Geometry
value
C1 could prevent this by adding fallback match
branches. Alternatively, wkt
could mark Geometry
as non_exhaustive
to force dependent crates to use a fallback when matching against it. But neither solution seems ideal.
Nice catch @lnicola ; I am also convinced against feature-gated addition to the enums. Should we then store the name of the tag in addition for this variant? We could also silently convert it to a linestring, but then parsing and writing back changes the wkt.
We could also have a variant for it and a normalization method, but I'd go for silently converting them until a user asks for more support.
To make sure I understand: by "silently convert", do you mean that any linestring which is closed
will be serialized to WKT as LINEARRING?
Would that behavior be behind a feature flag?
I meant reading LINEARRING as LineString, without a feature flag. It changes the WKT if you read and write back a file, but maybe it won't bother anyone.
Any further thoughts on this? I like the idea of silently reading LINEARRING and converting to LineString. Adding support for shapely and JTS extensions seems like a win for good interop.
I support it!
Fixed in #67
We might choose to do more in the future, but let's see what people's actual use cases are when they come up.