You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should explore how we support compound-CRSs, which is done by proj/gdalwarp by using 2 EPSG: EPSG:28992+5709 (this is equivalent to using EPSG:7415 but there are cases, like copdem where EPSG:4326+3855 is used and there is no one EPSG for this).
The OGC Name Specs now accepts CURIEs, and it is explained there how we could support this:
I think this is an important feature. Indeed some countries do not seem have a single EPSG code for their national CRS + vertical axis. So currently not possibly to properly represent this in CityJSON.
Modifying the type of "metadata"/"referenceSystem" would mean breaking a lot of and not backwards compatible.
It's a string at the moment though, but there is no way modifying the URL by allowing to concatenate two URLs would also break things.
One option is adding an extra property, eg "metadata"/"referenceSystem_Z". It solves it for many cases, but the "metadata"/"referenceSystem" can be a 3D CRS if there is a compound EPSG code that was created...
I think we should explore how we support compound-CRSs, which is done by proj/gdalwarp by using 2 EPSG:
EPSG:28992+5709
(this is equivalent to usingEPSG:7415
but there are cases, like copdem whereEPSG:4326+3855
is used and there is no one EPSG for this).The OGC Name Specs now accepts CURIEs, and it is explained there how we could support this:
this would mean modifying the
"metadata"/"referenceSystem"
to accept an array of strings, I guess.The text was updated successfully, but these errors were encountered: