Should we support LINEARRING type?

Question

Should we support LINEARRING type?

michaelkirk opened this issue 4 years ago · 13 comments

michaelkirk commented 4 years ago

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.

Answer 1 · 2020-12-06T15:17:43.000Z

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

Answer 2 · 2021-02-28T16:52:19.000Z

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.

Answer 3 · 2021-02-28T18:41:02.000Z

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)

Answer 4 · 2021-03-02T17:01:09.000Z

it would be good to support it behind a feature flag

That sounds like a smart approach to me.

Answer 5 · 2021-03-02T17:23:44.000Z

Should we support LINEARRING as another enum-case to the Geometry type here? Then, convert to LineString in the conversion to geo-types?

Answer 6 · 2021-03-02T17:29:59.000Z

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.

Answer 7 · 2021-03-02T18:00:46.000Z

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.

Answer 8 · 2021-03-02T18:27:38.000Z

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.

Answer 9 · 2021-03-02T23:47:40.000Z

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?

Answer 10 · 2021-03-03T05:59:09.000Z

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.

Answer 11 · 2021-04-07T15:00:10.000Z

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.

Answer 12 · 2021-04-07T15:19:36.000Z

I support it!

Answer 13 · 2021-04-30T18:12:47.000Z

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.