search

opengeospatial / geotiff

19 stars 9 forks source link

Axis Order #1

Closed tedhabermann closed 5 years ago

tedhabermann commented 9 years ago

This problem is described by Frank Warmerdam on the Refining GeoTIFF page: The GeoTIFF Specification is vague on axis order issues. Some suggestions on this are made in the FAQ and some conclusion should likely be codified in the specification - hopefully not in a way that flies in the face of actual industry practice.

EmDevys commented 9 years ago

This issue is addressed in DGIWG profile. DGIWG may help to contribute on this, I could help as necessary.

tedhabermann commented 9 years ago

Thanks Emmanuel, it will be great to have DGIWG helping on this...

EmDevys commented 6 years ago

DGIWG profile clarifies that "X is always equal to Easting or Longitude, and Y is always equal to Northing or Latitude.", on the basis of the examples in GeoTIFF (cf. 3.1.4 3.2.1 3.2.3), as well as GeoTIFF practise (libgeotiff, gdal, ...). It should be noted that when the code is EPSG:4326, the axis order, according to EPSG is lat, long, therefore GeoTIFF is not consistent with EPSG rules on this topic (axis order).

rouault commented 6 years ago

In the OGC realm, a probably relevant standard to take into account in this discussion is "OGC® GML Application Schema - Coverages - GeoTIFF Coverage Encoding Profile" 12-100r1 : https://portal.opengeospatial.org/files/?artifact_id=54813

There are also coordinate systems with southing, westing or other axis (like polar projections)

max-martinez commented 5 years ago

With respect to axis order, there are at least two issues each with two sub-issues:

1) Impact of axis order on relationship between raster space and model space a) Bearing of axis order on the content of ModeltTiepoint, ModelPixelScale and ModelTransformation is not addressed in the original spec Recommendation: Explicitly require in 1.1 that model space axis order in these tags is fixed at (lon,lat,v) / (east,north,v) regardless of the model space CRS definition. b) The original spec did not sufficiently set expectations of impact of non-conventional axis direction Recommendation: Continue to include the explanation of how Tiepoint, PixelScale would be interpreted in TransformationMatrix (as in section 2.6.1 of the original spec) and further explain that such a matrix applied to i,j,k (col, row, ?) produces an X, Y, Z? coordinate in model space (possibly with different axis order as explained in 1(a)).

2) Understanding of axis order for user-defined CRS definitions a) Axis direction and order for existing user-defined CRS definitions is not specified Recommendation: State that the implicit axis order of user-defined CRS definitions is (e,n) for projected, (lat,lon) for geographic, (h) for vertical (probably should state this in terms of implicit CS...see b) b) No GeoKeys exist to communicate non-conventional axis order and direction for user-defined CRS definitions Recommendation: This seems like we either need to add additional GeoKeys or say this is not possible in 1.1. Hexagon (internally, not in GeoTIFF context) uses an extended version of GeoKeys and have found that this seems to be addressable in nearly all cases by simply adding keys for coordinate system (i.e., it is generally not necessary to go down to the axis level because EPSG already covers the cases sufficiently). We make use of 3 additional extended keys for Projected, Geographic, and Vertical "coordinate system" (in the ISO 19111 / EPSG sense of the term). These keys can be used with user defined systems to specify values that are different from the conventional implicit defaults (4400,6422,6499, respectively) clarified by 2(a). Downside: uses of user defined systems with unusual axis order, direction, AND units may still not be clearly specifiable (do these exist?).

EmDevys commented 5 years ago

Roger Lott questionned yesterday about this text in GeoTIFF 1.0 "However, simple reversals of orientation between raster and model space (e.g. horizontal or vertical flips) may be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers must honor this sign-reversal convention" Comment (RL24): Does this not mean that our discussions regarding axis order are incorrect? (it seems that GeoTIFF files are simply not compliant with this!)

rouault commented 5 years ago

"However, simple reversals of orientation between raster and model space (e.g. horizontal or vertical flips) may be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers must honor this sign-reversal convention"

This is not related to axis order (long vs lat), but axis orientation (northwards vs southwards)

max-martinez commented 5 years ago

Agree with Even. Refer to the example of plugging Tiepoints, PixelScale into the transformation matrix in the original spec section 2.6.1 mentioned two comments ago. If you maintain the signs on the supplied pixel scales and simply plug them into the matrix as shown, you will get the correct raster to model transformation. There is no ambiguity. Text should be strengthened to "SHALL" instead of the original "may".

EmDevys commented 5 years ago

Thanks for confirmation. The requirement has been added as follows: http://www.opengis.net/spec/GeoTIFF/0.0/ModelPixelScaleTag.axisReversal + Simple reversals of orientation between raster and model space (e.g. horizontal or vertical flips) SHALL be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers shall honor this sign-reversal convention.

EmDevys commented 5 years ago

Proposal to include following 2 notes for clarification of implicit GeoTIFF axis order convention:

max-martinez commented 5 years ago

In the second note, I'm not sure that "regardless of the model space CRS definition" clarifies anything and it might add confusion because user-defined CRS definitions ARE model space definitions. And, if we don't feel like we can address the issue in this revision, it might be helpful to complete the thought, leaving no questions in the reader's mind by adding: "As with GeoTIFF 1.0, it will remain not possible to express a user-defined CRS that deviates from this implicit axis order. The intention is to address this limitation in a future revision."

max-martinez commented 5 years ago

Thanks for confirmation. The requirement has been added as follows: http://www.opengis.net/spec/GeoTIFF/0.0/ModelPixelScaleTag.axisReversal + Simple reversals of orientation between raster and model space (e.g. horizontal or vertical flips) SHALL be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers shall honor this sign-reversal convention.

After further review, I wonder if Roger's concern here is about the fact that there is a built-in convention in GeoTIFF to express the "normal case" (increasing column corresponds to increasing model space x coordinate, increasing row corresponds to decreasing model space y coordinate) with a positive Y pixel scale. The statement, as written, is true of world files, but could be confusing for GeoTIFF. You could try something like this:

A positive ScaleX in the ModelPixelScaleTag SHALL indicate that model space X coordinates increase as raster space I indices increase. This is the standard horizontal relationship between raster space and model space. A positive ScaleY in the ModelPixelScaleTag SHALL indicate that model space Y coordinates decrease as raster space J indices increase. This is the standard vertical relationship between raster space and model space. Simple reversals of orientation from the standard relationship between raster and model space (e.g., horizontal or vertical flips) SHALL be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers shall honor this sign-reversal convention.

EmDevys commented 5 years ago

Thanks Max. I agree, and add your proposed clarification to the draft, just changing “it will remain not possible to express a user-defined CRS” to “it is not possible to express a user-defined CRS”

De : max-martinez [mailto:notifications@github.com] Envoyé : mardi 22 janvier 2019 13:05 À : opengeospatial/geotiff Cc : Emmanuel Devys; Comment Objet : Re: [opengeospatial/geotiff] Axis Order (#1)

In the second note, I'm not sure that "regardless of the model space CRS definition" clarifies anything and it might add confusion because user-defined CRS definitions ARE model space definitions. And, if we don't feel like we can address the issue in this revision, it might be helpful to complete the thought, leaving no questions in the reader's mind by adding: "As with GeoTIFF 1.0, it will remain not possible to express a user-defined CRS that deviates from this implicit axis order. The intention is to address this limitation in a future revision."

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

EmDevys commented 5 years ago

OK for clarification. I propose to have 2 requirements (instead 1 only for these 3 requirements) as follows: |http://www.opengis.net/spec/GeoTIFF/0.0/ModelPixelScaleTag.standardConvention + A positive ScaleX in the ModelPixelScaleTag SHALL indicate that model space X coordinates increase as raster space I indices increase. This is the standard horizontal relationship between raster space and model space. A positive ScaleY in the ModelPixelScaleTag SHALL indicate that model space Y coordinates decrease as raster space J indices increase. This is the standard vertical relationship between raster space and model space. |http://www.opengis.net/spec/GeoTIFF/0.0/ModelPixelScaleTag.axisReversal + Simple reversals of orientation from the standard relationship between raster and model space (e.g., horizontal or vertical flips) SHALL be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers shall honor this sign-reversal convention.

I change the draft (requirements_class_ModelPixelScaleTag) accordingly, hoping there is no objection (otherwise it is easy to cancel this commit)

Emmanuel De : max-martinez [mailto:notifications@github.com] Envoyé : mardi 22 janvier 2019 13:34 À : opengeospatial/geotiff Cc : Emmanuel Devys; Comment Objet : Re: [opengeospatial/geotiff] Axis Order (#1)

Thanks for confirmation. The requirement has been added as follows: http://www.opengis.net/spec/GeoTIFF/0.0/ModelPixelScaleTag.axisReversal + Simple reversals of orientation between raster and model space (e.g. horizontal or vertical flips) SHALL be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers shall honor this sign-reversal convention.

After further review, I wonder if Roger's concern here is about the fact that there is a built-in convention in GeoTIFF to express the "normal case" (increasing column corresponds to increasing model space x coordinate, increasing row corresponds to decreasing model space y coordinate) with a positive Y pixel scale. The statement, as written, is true of world files, but could be confusing for GeoTIFF. You could try something like this:

A positive ScaleX in the ModelPixelScaleTag SHALL indicate that model space X coordinates increase as raster space I indices increase. This is the standard horizontal relationship between raster space and model space. A positive ScaleY in the ModelPixelScaleTag SHALL indicate that model space Y coordinates decrease as raster space J indices increase. This is the standard vertical relationship between raster space and model space. Simple reversals of orientation from the standard relationship between raster and model space (e.g., horizontal or vertical flips) SHALL be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers shall honor this sign-reversal convention.

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

cmheazel commented 5 years ago

Closed by GeoTIFF SWG at the Banff TC meeting.