mkaravel commented on PR #15781: URL: https://github.com/apache/iceberg/pull/15781#issuecomment-4165881265
@rdblue Please see answers/comments below. > > Although the wording is more clear it makes the spec more restrictive. > > How does this make it more restrictive? I didn't read it that way. The existing wording (prior to this PR is): --- _The default CRS value OGC:CRS84 means that the objects must be stored in longitude, latitude based on the WGS84 datum._ _Custom CRS values can be specified by a string of the format type:identifier, where type is one of the following values:_ _srid: [Spatial reference identifier](https://en.wikipedia.org/wiki/Spatial_reference_system#Identifier), identifier is the SRID itself. projjson: [PROJJSON](https://proj.org/en/stable/specifications/projjson.html), identifier is the name of a table property where the projjson string is stored._ --- How I read this depends on what "custom" means. Assume for a minute that "custom" means "non-default", that is everything except "OCG:CRS84". In this case what I read is the following: **We have the default value which is `OCG:CRS84` and everything else is non-default. Everything non-default is required to be in one of two formats: (1) `srid:identifier` (e.g. `srid:0`), or (2) `projjson: <projjson string>`**. Assume that "custom" does not mean "non-default". The natural question is what "custom" means. Given that there are well known authorities my reflex is to think: **There is the default which is `OCG:CRS84`, there are other well-defined CRS via well known authorities (see content in [https://spatialreference.org/](https://spatialreference.org/)), and there is also the possibility of defining my own personal/custom/proprietary CRS in two ways: (1) `srid:identifier` (e.g. `srid:0`), or (2) `projjson: <projjson string>`. I can of course define everything using the two proposed ways for custom CRSs, but I also have the ability to be between the default and the custom ones**. Unfortunately, there is nothing in the wording that either supports or directly rejects the above interpretation, hence the confusion. > > What can we do to make this more clear? I agree that the cases you listed are reasonable ways to specify a CRS -- how should we change the wording to definitely allow them? I think a wording of the following form would be much cleaner: 1. Avoid talking about custom CRSs. 2. Provide valid ways of defining a CRS that includes the two already mentioned plus the ability to specify a CRS using the `authority:code` approach much like what is done in [https://spatialreference.org/](https://spatialreference.org/). The default CRS value of "OGC:CRS84" falls naturally as one of the valid options. 3. Add specific examples of valid CRS definitions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
