search

opengeospatial / geotiff

19 stars 9 forks source link

Priority rules for GeoKeys conveying similar (and contradictory) information #13

Open rouault opened 6 years ago

rouault commented 6 years ago

There are a number of situations where several GeoKeys that can convey implicitly or explicitly an information are found in the same file. A typical example is having ProjectedCSTypeGeoKey which completely defines the CRS, as well as a ProjLinearUnitsGeoKey. In the best case ProjLinearUnitsGeoKey confirms the linear unit of the EPSG code, but sometimes it overrides it with a different unit.

This is not a theoretical concern but issues I've seen in real world : https://trac.osgeo.org/gdal/ticket/6210 and https://trac.osgeo.org/gdal/ticket/4954

Should we allow such override ?

EmDevys commented 6 years ago

My opinion is that such override is a real issue in the laxism in TIFF and even more in GeoTIFF. IMHO it is total nonsense to override with a different Uom (Unit). what would happen there if one software rely on the standardized unit provided by the CRS definition, and another one on the override ! Just total lack of interoperability, with effects that may be dramatic. We are supposed to ensure interoperability, and such laxism would drive to lack of interoperability.

rouault commented 5 years ago

We could potentially go beyond and completely disallow overrides Like:

RogerLott commented 5 years ago

This is a general problem with redundent information. Some users want to have redundancy so they can run a check and then invesitigate any discrepancy. GeoTIFF doesn't follow this strategy - it tries to offer the register code as a shortcut.

Although only tangentially relevant to this issue, Topic 2 (18-005r3) clause 7.2 says "CRS or coordinate operation identification may be through: a) a full description, as defined in this document; or b) reference to a full description in a register of geodetic parameters (the reference is made to the register and to the identifier of the object description within that register); or c) both a full description and a reference to a full description in a register. If there is a conflict between the two, the object full description should prevail over the reference to a register".

(I would have preferred that the register definition prevailed, but I think it is this way round to cover an inadvertent slip in citing register code value).

Topic 2 goes on to say "a) and b) are alternative means of providing a full description. b) is recommended for simplicity" which is what GeoTIFF does whenever possible. (You would think that if (b) is recommended it would be the one that prevailed if conflict in (c)).

As I understand it, this port is only fixing really broken issues so we simply replicate existing GeoTIFF provisions leave the issue unresolved for now, and fix in a later GeoTIFF revision. Or is this considered to be a breaking issue?

cmheazel commented 5 years ago

Our goal is to provide adopters an OGC standard which is equivalent (or as close as possible) to the version that they know and love. Version 1.0 should only deviate from the 1995 version if there is a compelling need and that need has been documented. Otherwise we may end up with a nice set of shelfware.

Not saying that there isn't room for improvement. Just that we need to wait until we have sold existing adopters on our version.

desruisseaux commented 5 years ago

The OGC template for standards contains a section about "standardization target types" in its conformance section. Should we said that we have 2 target types?

EmDevys commented 5 years ago

My proposal is rather to keep as is, and leave the issue unresolved, though I would recommend providing a recommendation, based on the best practices (and hopefully rather on use of EPSG register, rather than duplication of information (and the risk of error when doing so). In addition, I would add that we don’t have to be fully consistent with Topic 2 and its c/ usage rule in clause 7.2.

De : RogerLott [mailto:notifications@github.com] Envoyé : vendredi 21 décembre 2018 18:21 À : opengeospatial/geotiff Cc : Emmanuel Devys; Comment Objet : Re: [opengeospatial/geotiff] Priority rules for GeoKeys conveying similar (and contradictory) information (#13)

This is a general problem with redundent information. Some users want to have redundancy so they can run a check and then invesitigate any discrepancy. GeoTIFF doesn't follow this strategy - it tries to offer the register code as a shortcut.

Although only tangentially relevant to this issue, Topic 2 (18-005r3) clause 7.2 says "CRS or coordinate operation identification may be through: a) a full description, as defined in this document; or b) reference to a full description in a register of geodetic parameters (the reference is made to the register and to the identifier of the object description within that register); or c) both a full description and a reference to a full description in a register. If there is a conflict between the two, the object full description should prevail over the reference to a register".

(I would have preferred that the register definition prevailed, but I think it is this way round to cover an inadvertent slip in citing register code value).

Topic 2 goes on to say "a) and b) are alternative means of providing a full description. b) is recommended for simplicity" which is what GeoTIFF does whenever possible. (You would think that if (b) is recommended it would be the one that prevailed if conflict in (c)).

As I understand it, this port is only fixing really broken issues so we simply replicate existing GeoTIFF provisions leave the issue unresolved for now, and fix in a later GeoTIFF revision. Or is this considered to be a breaking issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/13#issuecomment-449447150, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIZzaus6eVXgKJv_zzpQ5pn2akDvD6YMks5u7RiRgaJpZM4Q25Lh.

EmDevys commented 5 years ago

I agree for GeoTIFF files adhering to existing specification, dating 1995, with KeyRevision.MinorRevision = 1.0, that should still be handled.

But we should also allow some modernization / correction of the standard, clearly identified in a slightly revised version, which might have KeyRevision.MinorRevision = 1.1, when necessary (and documented).

Does this make sense?

De : Chuck Heazel [mailto:notifications@github.com] Envoyé : vendredi 21 décembre 2018 18:36 À : opengeospatial/geotiff Cc : Emmanuel Devys; Comment Objet : Re: [opengeospatial/geotiff] Priority rules for GeoKeys conveying similar (and contradictory) information (#13)

Our goal is to provide adopters an OGC standard which is equivalent (or as close as possible) to the version that they know and love. Version 1.0 should only deviate from the 1995 version if there is a compelling need and that need has been documented. Otherwise we may end up with a nice set of shelfware.

Not saying that there isn't room for improvement. Just that we need to wait until we have sold existing adopters on our version.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/13#issuecomment-449450950, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIZzaqAMtWVXZFyzdRwHdHWalV3QQWxYks5u7RwbgaJpZM4Q25Lh.

thareUSGS commented 5 years ago

>>But we should also allow some modernization / correction of the standard, clearly identified in a slightly revised version, which might have KeyRevision.MinorRevision = 1.1, when necessary (and documented).

I agree with this and the use of 1.1 as Even has suggested.

-Trent Trent Hare Cartographer/GIS Manager Astrogeology, USGS

On Fri, Dec 21, 2018 at 12:53 PM Emmanuel Devys notifications@github.com wrote:

I agree for GeoTIFF files adhering to existing specification, dating 1995, with KeyRevision.MinorRevision = 1.0, that should still be handled.

But we should also allow some modernization / correction of the standard, clearly identified in a slightly revised version, which might have KeyRevision.MinorRevision = 1.1, when necessary (and documented).

Does this make sense?

De : Chuck Heazel [mailto:notifications@github.com] Envoyé : vendredi 21 décembre 2018 18:36 À : opengeospatial/geotiff Cc : Emmanuel Devys; Comment Objet : Re: [opengeospatial/geotiff] Priority rules for GeoKeys conveying similar (and contradictory) information (#13)

Our goal is to provide adopters an OGC standard which is equivalent (or as close as possible) to the version that they know and love. Version 1.0 should only deviate from the 1995 version if there is a compelling need and that need has been documented. Otherwise we may end up with a nice set of shelfware.

Not saying that there isn't room for improvement. Just that we need to wait until we have sold existing adopters on our version.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub< https://github.com/opengeospatial/geotiff/issues/13#issuecomment-449450950>, or mute the thread< https://github.com/notifications/unsubscribe-auth/AIZzaqAMtWVXZFyzdRwHdHWalV3QQWxYks5u7RwbgaJpZM4Q25Lh>.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/geotiff/issues/13#issuecomment-449483422, or mute the thread https://github.com/notifications/unsubscribe-auth/AC86Yr7_5IaqdEL6p2-LPexiKaWb3OJlks5u7Tw-gaJpZM4Q25Lh .

EmDevys commented 5 years ago

Thanks Martin, this sounds to me like a reasonable proposal, to handle GeoTIFF as is…

De : Martin Desruisseaux [mailto:notifications@github.com] Envoyé : vendredi 21 décembre 2018 19:25 À : opengeospatial/geotiff Cc : Emmanuel Devys; Comment Objet : Re: [opengeospatial/geotiff] Priority rules for GeoKeys conveying similar (and contradictory) information (#13)

The OGC template for standards contains a section about "standardization target types" in its conformance section. Should we said that we have 2 target types?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/13#issuecomment-449462622, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIZzalelKDOVCsdGHlMIpAmQvqQmgUfKks5u7Sd2gaJpZM4Q25Lh.

EmDevys commented 5 years ago

Should this revision 1.1 add some recommendations on the behaviour of GeoTIFF writers / producers in order to avoid conflicts, and solve conflicts if there are for GeoTIFF readers / users. Big discussion, seem to be an uneasy issue.