New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WKT support for 3/4D using Z and/or M #168
Comments
Since we currently don't allow M values, I suppose we will only need to add such guideline when we relax that restriction?
We can probably call it out more specifically for clarity / draw attention to it, but I think that the current text is unambiguous in having a space (i.e. "a Do you know the rationale of other standards like API-EDR to not use any space? The WKT spec itself as referenced in our spec has examples that actually do include a space (and for example GDAL also creates WKT with spaces). |
@jorisvandenbossche The EDR API Standard WG didn't realise having a space was an option. Possibly it was caused by multi-lingual problems, as the original proposal to use the When the issue was raised last year in the EDR API SWG, we looked at current practice, and there was no clear guidance. We agreed that no spaces would make for slightly easier unambiguous parsing. We also unconsciously assumed that The OGC original spec contains: But then the Table 6 of examples has So clear guidance is probably needed. |
A concrete reason for preferring no spaces before |
Can you point to where this parameter is described in the EDR API? (to better understand the use case) |
The latest draft version, V1.1 Sections 8.2.5, 8.2.6, for the |
Ah, so in the EDR API case that's about actual WKT reprs of full geometries, not just geometry type indications. Note that in our metadata, this is about the geometry type (so it's not actually WKT, the geometries are stored as WKB) Looking at #41 (comment) and comments below that, it seems we went with the current naming scheme based on the types from GeoJSON, and then decided to add "Z" with a space (and not without a space) somewhat randomly (although using the fact that typical WKT strings are using a space as prior art). |
And as we are embedding the WKT in URL queries (HTTP(S) GET and POST, saving a few spaces (or %20s) is useful. |
you're saving just one. Every following ordinate needs to be space separated
"Table 7: Integer codes for geometric types" in "8.2.3 A common list of codes for geometric types" has spaces in the type names: "Point Z", etc. Actually it seems that the only place in the simple features spec where no space is found is in table 6 (in a WKT context at least. When looking at WKB, there are C-style structures and enumerations that have no space, but that's because of the constraint of an identifier being a single word). Looking at the BNF of WKT, it seems to me that no space isn't even allowed, even if a number of WKT parsers (at least the ones in PostGIS and GDAL), accept WKT types both with or without space (speaking here about when ingesting a full WKT geometry) |
Yes, but the point I was trying to make is that we don't use WKT at all in the GeoParquet spec. The discussion about what the WKT spec says about spaces is certainly interesting (and relevant for EDR API) and useful to resolve, but thus not that relevant for GeoParquet (and probably should be held elsewhere so the relevant people see it?) If the WKT spec would be unambiguous, that would be a useful data point for us to decide whether we want to use a space as well or not. But in the end, our spec (and json schema) for the geometry type is currently explicit in having a space. |
@jorisvandenbossche @rouault So I am content that you have addressed the issue for GeoParquet, and highlighted the ambiguity in the WKT spec. |
In the draft Geoparquet specification, in the “geometry-types” section, the use of the “Z” suffix to indicate 3D data is mandated, and the “M” suffix for other coordinate system is not yet supported. As some OGC Standards (e.g. API-EDR v1.0.1, with V1.1 and V1.2 in the pipeline) use both suffices, perhaps clear guideline or standard could be established for combinations, such as “ZM”, “MZ”, etc., and specifically whether a preceding space is required or expected.
API-EDR has assumed that no leading spaces are expected of a suffix, but does not state an explicit requirement. Other software has assumed no spaces is the accepted syntax.
This may not seem very important, but is undoubtedly a barrier to interoperability. Perhaps alignment with this should be explicitly mentioned in the Charter, or in a workplan annex.
The text was updated successfully, but these errors were encountered: