search

stac-extensions / perspective-imagery

Describes perspective imagery collected by photogrammetric or non-photogrammetric cameras
Apache License 2.0
14 stars 2 forks source link

Reference to CRSs: (compact) URI instead of number #2

Open heidivanparys opened 2 years ago

heidivanparys commented 2 years ago

According to https://github.com/stac-extensions/perspective-imagery#item-properties, pers:crs and pers:vertical_crs are specified as numerical EPSG code, WKT2 (ISO 19162) string or PROJJSON object.

This issue is regarding CRSs specified as numerical EPSG codes.

Current OGC policy is that CRSs should be referenced by means of URI's. A URI provides an unambiguous and explicit reference to CRS; other organisations than the one behind EPSG define CRSs as well. The CRS should be uniquely defined in the data. This has also been done in OGC API - Features - Part 2: Coordinate Reference Systems by Reference.

There is a policy change on its way in OGC to also allow simpler CRS references, see https://github.com/opengeospatial/NamingAuthority/issues/92 and https://github.com/opengeospatial/NamingAuthority/blob/fix-for-issue-92/policyAndProcedures/OGCNANameTypeSpecificationForDefinitions/clause_6_1_CURIEs.adoc. If that is approved, EPSG:4326 would be allowed as a more simple version of http://www.opengis.net/def/crs/EPSG/0/4326.

Therefore, I would suggest changing the specification on this point: pers:crs and pers:vertical_crs are specified as HTTP URI, Compact HTTP URI (CURIE), WKT2 (ISO 19162) string or PROJJSON object.

Minor note: http://www.epsg-registry.org/ redirects to https://epsg.org, perhaps the latter should be written in the spec.

AsgerPetersen commented 2 years ago

Hi @heidivanparys

I think this STAC extension should first and foremost try to be consistent with other STAC extensions. Unfortunately there is a little variance in how STAC extensions reference CRSs (and thereby demonstrating the need for a good standard šŸ˜€):

As some of the data carried by this extension (omega, phi, kappa, rotation matrix) may be very hard to transform to other CRSs, I think we need the flexibility of being able to specify a CRS which is not defined in the EPSG database or any other authority.

I personally like "EPSG:4326" much better than 4326, but i also like the simplicity of implementation with the current wording where the datatype indicates the format: If it is a number then it is an EPSG code, if it is a string it is WKT2, if it is an object it is PROJJSON.

What do you think?

heidivanparys commented 2 years ago

I think this STAC extension should first and foremost try to be consistent with other STAC extensions. Unfortunately there is a little variance in how STAC extensions reference CRSs (and thereby demonstrating the need for a good standard šŸ˜€):

One question is indeed whether there is some kind of best practice for this in the STAC community. Another question is how much STAC, and STAC extensions, should follow OGC principles. There is an intention to bring STAC into OGC, see https://medium.com/radiant-earth-insights/spatiotemporal-asset-catalogs-and-the-open-geospatial-consortium-659538dce5c7, so I think it would be good to follow OGC principles as much as possible, but others may have other views of course.

  • The Projection extension uses a plain integer, a WKT2 string or a PROJJSON object in separate properties.

This is slightly different as I see it, as there it is clear from the property name that it is an EPSG code: proj:epsg. In the perspective imagery spec, the property is simply crs.

As some of the data carried by this extension (omega, phi, kappa, rotation matrix) may be very hard to transform to other CRSs, I think we need the flexibility of being able to specify a CRS which is not defined in the EPSG database or any other authority.

I agree. So that is an argument in favour of using EPSG:4326 instead of 4326, isn't it? Doing that would also allow for e.g. OGC:CRS84, see also https://github.com/opengeospatial/NamingAuthority/issues/92#issuecomment-822434236.

m-mohr commented 2 years ago

The principle behind STAC is search and discovery. Thus we decided to use EPSG codes as the primary mean to define a projection as it is the easiest to use in this context. But we also know that not everything can be encoed in EPSG codes so we also looked at the alternatives:

Due to the fact that you can detect by the data type whether it is wkt2, projjson or epsg, it is easy to have it in a single field, but the proj extension makes it more explicit as the extension is specifically written for this use case. If the projection is just a "side" effect of the extension as for data cubes, it can be encoded in a single field to not blow up the fields too much. So I think the approach in this extension makes sense.