Edge value can be incompatible with CRS

[mapprehension]

The spec permits the edge value to either planar or spherical, without restriction, and defaults to planar. Meanwhile the default CRS is spheroidal, setting up a meaningless edge definition by default, as well as permitting a planar edge value to be explicitly assigned even when the CRS is spheroidal. Either the spec should prohibit the incompatible declarations or should specify an unambiguous mathematical meaning for a planar edge on a spheroidal datum.

[rouault]

unambiguous mathematical meaning for a planar edge on a spheroidal datum.

No ambiguity here. Planar on a geographic CRS means to consider the (longitude, latitude) space as a Cartesian coordinate space. This admitedly doesn't make sense to measure distances, but it is still widely used, like to define bounding boxes, despite its limitations

[mapprehension]

While it may be common in some systems to treat spherical coordinates as planar, unless the specification states that that is how it is to be interpreted, it is ambiguous. Many reasonable possibilities exist. I know of one system that does not use that interpretation; instead, it uses the rhumb between the two points. That way bounding boxes still work; the path is defined; and the path is meaningful. I am not advocating any particular definition, but I advocate that it be defined.

[paleolimbot]

Thank you for bringing this up...I admit that I am surprised at the notion that the interpretation is ambiguous since the way that this is expressed in GeoParquet is quite flexible (for example, we defined the "edges" values as a string such that we could add options in the future if they became common). Other systems generally use geography/geography type names or something like "is_spherical" (or just don't support anything except Cartesian interpretations).

Is the ambiguity you are referring to that the "edges" key can be missing an a default value inferred, or that the default value is not a value that you agree with?

[mapprehension]

Is the ambiguity you are referring to that the "edges" key can be missing an a default value inferred, or that the default value is not a value that you agree with?

I’m not sure what your first choice means, but yes, I disagree that the combination of edge = "planar" by default and crs = "OGC:CRS84" by default is a good thing. In a formal sense, it is ambiguous, since it does not define a path. @rouault gives the common usage, but if the common usage is what is intended, then it ought to be stated because its common use does not make it unique or ambiguous. In an informal sense, I think it’s poor practice to encourage flat-earth semantics, with the usual attendant errors, by mashing up a spheroidal CRS with a planar edge by default.

[paleolimbot]

Unfortunately I don't think we can change the defaults or how they are specified as we have a number of existing implementations; however, we could definitely do a better job disambiguating the meaning of "edges" if there is confusion. I think we very specifically are referring to the mathematics of how to add a point along a given edge between two defined coordinates (e.g., https://github.com/google/s2geometry/blob/ec260c3ad4c2bf812b54a4bc984b76747ace9d5d/src/s2/s2projections.h#L57-L72 ). As you've noted, the "spherical" interpolation method isn't perfect for an edge on an elipsoid (but most data have coordinates spaced such that the error is negligible).

I think it’s poor practice to encourage flat-earth semantics

I agree! I have found that a productive outlet for myself is to help develop open source alternatives that make it easy to do the right thing (e.g., https://github.com/paleolimbot/s2geography/ , https://github.com/r-spatial/s2 ). Until we have a widely available and rigorously tested drop-in alternative for GEOS/JTS, I don't see a spherical default as a viable option.