-
Notifications
You must be signed in to change notification settings - Fork 16
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
EPSG code as string #391
Comments
In general I favor this, as the Counter argument: would users expect other prefixes are also allowed, e.g. something like |
For reference, we're using https://pyproj4.github.io/pyproj/stable/api/crs/crs.html#pyproj.crs.CRS.from_user_input to validate CRS fields now, so we're happy with both strings and integers! |
Thanks. I don't think so as it clearly states EPSG code in the schema, also validation should reject it. If you dig down into other authorities it quickly gets messy... |
I've tried to do this, but the schemas get very messy. I'm think we should only cater for the string vs. number issue in the clients. It seems like allowing it in the process spec makes it a work item for clients + backends while otherwise it makes it only to a work item in the clients. In the Web Editor for example it's not an issue at all as it hidden from the user anyway. |
This is one of the cases, where it seems the specification doesn't fully match what people expect. Also, implementations and examples did often also encourage the "wrong" way...
EPSG codes currently are provided as integers. We should probably also allow strings in 2.0 as this is what people seem to use quite a lot...
So the schema for it would change to something like:
Thoughts?
The text was updated successfully, but these errors were encountered: