Choose a consistent way of dealing with +2D geometries

[theroggy]

Remark; content here is being edited based on comments below to keep a consistent overview

Out in the wild there are 3 flavours how +2D geometry types are defined. With a "Point" layer as example: "2.5D POINT", "3D POINT" or "POINT Z".

• GDAL uses the following flavours:
  • in low-level API's: "2.5D POINT"
  • in this ogrinfo example "3D Point" is shown for this type of layers
  • in ogr2ogr -nlt (=force geometry_type): "POINT Z" (or POINT M, POINT ZM for elevation, measure, or elevation and measure).
• fiona uses "3D POINT"
• in WKT you use "POINT Z"
• in the QGIS UI you don't choose a type like this explicily, but you choose "Point" and then have radiobuttons for "Z", and/or "M", which leans towards the "POINT Z" flavour: new layer.

In the pyogrio codebase and documentation some flavours are already in use:

• pyogrio.read_info returns geometry type "the GDAL-low-level way": "2.5D POINT"
• the geometry_type parameter in write_dataframe supports 2 flavours: "2.5D POINT" and "POINT Z"
• ...

Probably explicitly choosing a flavour to be returned in the pyogrio API (eg. pyogrio.read_info) would be a good idea. That would probably be the logical one to be used consinstently in the code base and documentation as well.

For input parameters it is also an option to support multiple flavours.

The issue became apparent in #223

[jorisvandenbossche]

At the least, I would prefer not to use the "2.5D" in user facing APIs, since that's just confusing what this is about (I don't even know why it is that way).

Slight preference to go with "Point Z" (that matches more with things like WKT reprs of geometries, so that should be familiar), but "3D Point" being used by GDAL (eg in the output of ogrinfo) is also a good reason.

[theroggy]

At the least, I would prefer not to use the "2.5D" in user facing APIs, since that's just confusing what this is about (I don't even know why it is that way).

Short answer: I'm not sure either why anyone started using it and I also think it is confusing.

Longer answer: I looked around a few days ago, and you find all sorts of explanations:

• some talk about having only one Z coordinate per polygon, which is not the case here
• some talk about that each coordinate can have a seperate Z coordinate, but that calculations like area, intersections,... ignore this, which could be correct here in practice, but is more related to the other libraries in use (geos,...) than the data, so not a very good reason either
• some talk about the fact that it is 2.5D when it is "planar", so it is not possible to create boxes and that kind of stuff... Possible this is correct in GIS data.... but if it is that interesting?

Slight preference to go with "Point Z" (that matches more with things like WKT reprs of geometries, so that should be familiar), but "3D Point" being used by GDAL (eg in the output of ogrinfo) is also a good reason.

I also think "POINT Z" is the most "readable" option, especially if you also consider the "POINT M" and "POINT ZM" variants that are also out there for some use cases.

My only worry/question was what the rest of the ecosystem is doing. But please have a look at the initial comment in this issue again, I found and added some more info... and apparently the "POINT Z" notation is the one used in the ogr2ogr documentation, so that's not a bad credential.

[jorisvandenbossche]

I also think "POINT Z" is the most "readable" option, especially if you also consider the "POINT M" and "POINT ZM" variants that are also out there for some use cases.

Ah, yes, keeping the option open for supporting M and ZM versions, then I think the Z suffix ("Point Z" ) is the only sensible option ("3D" is already ambiguous ..)

[jorisvandenbossche]

But please have a look at the initial comment in this issue again, I found and added some more info... and apparently the "POINT Z" notation is the one used in the ogr2ogr documentation, so that's not a bad credential.

I would say that is more than enough to go for "Point Z" style (GeoParquet spec is also using that).

(It seems that GDAL ogr2ogr allows both "POINTZ" and "POINT Z")