Add explicit language around edges and ensure available options capture engine behaviours that import/export Parquet

[paleolimbot]

This PR is an attempt to improve the language around the "edges" key, to ensure it can capture the intent of all potential producers. We've done more research since the original wording and have some specific examples and use cases where implementations and specifications have struggled. Notably, this PR:

• Adds a "geodesic" option. I only knew about the spherical approximation because I'd only worked with s2, but it's been rightly pointed out that geodesic edges that consider the ellipsoid are a thing in several major engines.
• Adds examples of producers and consumers that use each edge type
• Adds explicit language around "planar" from simple features access
• Adds practical considerations around importing a column with an unsupported edge type (basically: you can import them silently if there are no edges; you should force an opt-in or display a prominent warning otherwise).

I've also added a PR to add similar language to GeoArrow geoarrow/geoarrow#79 .

[jiayuasu]

Can one describe the perfect sphere via a geodetic CRS? That way, we can merge spherical and geodesic together and recommend everyone to look into the crs key for interpreting the edge?

[rouault]

yes, a sphere is described by an ellipsoid with an inverse flattening conventionally set to 0 (it should actually be infinity, but the 0 convention is heavily used)
I believe an issue though (mentionned in some other discussion) is that in some situations some software might apply the formulas for spheres on non-spherical ellipsoids as a simplification avoiding using elliptical integrals

[paleolimbot]

If we did this we would loose the original CRS information, which is important for ensuring that the position of every single vertex is precisely defined (e.g., a CRS transform from a perfect sphere ellipsoid to UTM, for example, is not the transform we want to invoke on the longitude and latitude of the vertices). The spherical approximation is strictly limited to the (usually small) space between adjacent vertices.

[paleolimbot]

The difference between the geodesic and spherical are probably always trivial (I can at some point do some math to get a handle on the maximum/average error), but if we want a precise definition, we need it to be there.

[jiayuasu]

Now I understand. spherical mode actually overrides the edge specified in the crs. That's where the confusion came from.

I think this is making great progress. I will schedule another meeting among all parties to settle down on the geography type of Iceberg

[jorisvandenbossche]

I think this is good and clarifying content to add (thanks Dewey!), but one practical concern: do we have an idea if anyone would actually be planning to use the distinction between "spherical" and "geodesic" ?
For example, would bigquery, when importing data that is marked as "geodesic", do a similar edge tessellation like with importing planar data to ensure there is a certain max error? (and bigquery here is just an example, same applies to all other engines or packages mentioned. But at least BigQuery does correct planar data, while I have not seen similar documentation for several of the other systems)

Because if there is not actually an "ask" for this, do we need to add an actual separate option (instead of just documenting this and adding most of the language you are adding here)

[paleolimbot]

Because if there is not actually an "ask" for this, do we need to add an actual separate option (instead of just documenting this and adding most of the language you are adding here)

That's a great point (we could just acknowledge that such edges exist without allowing the option). I think allowing the option is good because in GeoArrow we actually will interact with that edge type as a vessel for database results coming from PostGIS and Redshift at least, and it would be a bit odd if we allowed the option there but not here.

In the same sphere (pun slightly intended), we could also mention loxodrome edges (constant bearing), which GeographicLib can also interpret. I don't know of any producers of Arrow or Parquet that do this but it does exist.