search

opengeospatial / geotiff

19 stars 9 forks source link

PixelIsPoint vs. PixelIsArea #4

Closed tedhabermann closed 2 years ago

tedhabermann commented 9 years ago

This problem is described by Frank Warmerdam on the Refining GeoTIFF page.

The GeoTIFF Specification was somewhat vague on the implications of using and in 2.5.2.2. Some users fell into the trap of thinking that these were only a sampling technique clue and did not affect the real coordinate system. This is not the evolved industry consensus, and the specification needs to make this very clear. Some detail on this issue is captured here.

EmDevys commented 9 years ago

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

rouault commented 6 years ago

Note: I noticed there was an issue in the DGIWG profile about the georeferencing in the PixelIsArea case that @EmDevys addressed recently

EmDevys commented 6 years ago

Even and all This issue is being changed in a revised 2.2 version that is about to be sent out for publication. This version should (shortly) replace version 2.1, and align DGIWG GeoTIFF with GeoTIFF practice.

Note: it should be noted that this GeoTIFF “corner convention for area pixel” is not in sync with the usual OGC convention, which is “center of pixel”. This should be clarified / made explicit when OGC is doing the revision.

Emmanuel

De : Even Rouault [mailto:notifications@github.com] Envoyé : lundi 13 novembre 2017 18:55 À : opengeospatial/geotiff Cc : Emmanuel Devys; Mention Objet : Re: [opengeospatial/geotiff] PixelIsPoint vs. PixelIsArea (#4)

Note: I noticed there was an issue in the DGIWG profile about the georeferencing in the PixelIsArea case that @EmDevyshttps://github.com/emdevys addressed recently

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/4#issuecomment-344002441, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIZzap9JaWiyUdOoUxzyQcpdBAj0IpBjks5s2IJ7gaJpZM4DCPiv.

max-martinez commented 5 years ago

The reference to https://github.com/opengeospatial/geotiff/issues/55 relates to the question "should the spec actually allow people to use a RasterPixelIsArea raster space if they are only specifying tie points?". When specifying merely tie points, there is no scale to be found (no PixelScale and no ModelTransformation). Thus, what exactly would be the meaning of the "area" being insisted upon in a PixelIsArea raster space?

EmDevys commented 5 years ago

In case of mere Tie points GeoTIFF, the PixelIsPoint Raster space seems more adequate to me, isn't it? If there is a need of clarification, Annex B could be adjusted. If so, could you clarify and propose some contribution?

rouault commented 5 years ago

I don't think that PixelIsArea is less relevant in the case of tie points only. The pixels may still be considred as having an area. It is just it is not known and might be non constant if the image is not ortho-rectified. GDAL can typically handle both conventions (as it exposes all georeferencing in a PixelIsArea convention, it will add 0.5 to the I and J value of the tiepoints it reports to the user when the GeoTIFF is PixelIsPoint. Ignore this remark if it brings more confusion than clarity :-)) That said, I'm not against a recommendation to use PixelIsPoint for that case if that seems more adequate.

joanma747 commented 2 years ago

In the telco today, the group finds difficult to create a clarification to this issue without risking to create even more confusion. You can reopen the issue if you propose a clarification text that we can discuss.

The section where this is explained is B.2.2. Raster Space (http://docs.opengeospatial.org/is/19-008r4/19-008r4.html#_raster_space) We detected that "top-left" is only used one and "upper-left" several times so we propose to replace "top-left" with upper-left. See https://github.com/opengeospatial/geotiff/pull/107