Some drivers may be misinterpreting GDALMD_AREA_OR_POINT

[rayg]

The following raster drivers refer to the GDALMD_AOP_POINT metadata item:

AAIGRID, GeoTIFF, DTED, USGSDEM, Leveller, Terragen

The Leveller and Terragen drivers are point data, and mistakenly assume that setting GDALMD_AOP_POINT causes a projection origin correction. They also do not reverse shift when writing.

The other drivers may be making similar mistakes. AAIGRID appears to be self-shifting the projection origin when reading but in the wrong direction.

GDALMD_AOP_POINT is not a geospatial hint; setting GDALMD_AOP_POINT means only that the original data was scanned in using point rather than area samples. All drivers should strictly place the projection origin at the upper left corner of the upper left pixel, and quietly shift the projection origin by a half-pixel when performing I/O on point data.

[warmerdam]

Ray,

I have no reason to believe there are problems with with the dted, usgsdem and aaigrid drivers. Please point it out if you have a specific reason to believe there is.

There are differences of opinion on whether the GeoTIFF driver ought to offset pixel-as-point origins by half a pixel. Currently the driver does not, which is my interpretation of proper behavior. This issue is addressed via other tickets.

That leaves the Leveller and Terragen drivers in need of correction. Will you be taking care of them?

[rayg]

Section 2.5.2 of the GeoTIFF spec at ​http://www.remotesensing.org/geotiff/spec/geotiff2.5.html#2.5.2

clearly states that RasterPixelIsPoint is geospatially different than RasterPixelIsArea. Therefore the GeoTIFF driver is in error.

Lev/Terragen drivers: yes, I'll be fixing those.

[rayg]

Leveller and Terragen drivers have been updated for the 1.5 branch.

[moellney]

Replying to rayg: (...munch...)

The other drivers may be making similar mistakes. AAIGRID appears to be self-shifting the projection origin when reading but in the wrong direction.

Maybe the infos at:

​http://geotools.codehaus.org/ArcInfo+ASCII+Grid+format (last section on page seems to very clear on this topic) ​http://www.anuva.de/service_arcforum.php?action=vthread&forum=2&topic=2866 ​http://www.csc.noaa.gov/crs/tcm/instructions.html#binaryrasters

can gibe some support in the analyzing of the ARC ASCII grid driver. Btw. I do not have the impression there is a wrong shifting (at least in the Open method.) Only the interpretation of the meta data from the georeferencing seems to go to far.

Please note also that #2128 had a complain about the AAIGRID driver, too. But this was closed due to a wrongly (99% probability) generated file form geoengine.nima.mil.

[moellney]

sorry for all this cc'ing.

[rayg]

Good info, it looks 100% clear that if xllcenter/yllcenter are in an AAIGRID header, then geospatial pixels-as-points is intended. I think the origin shift is valid, I was confused by the vertical inversion. So AAIGRID should be alright.

[rayg]

Confirmed error in BT (binary terrain) driver; it is a point format but is not origin shifting. Offered to fix it for Ben Discoe or he may apply a fix.

DTED looks okay; origin shift is being done in a secondary module.

[rayg]

BT driver fixed for 1.5 branch. -- Ray

[warmerdam]

Ray,

What is outstanding on this ticket? I'm downgrading to Normal priority since there does not seem to be critical fixes we would hold up a release for here.

[rayg]

Only thing left is the GeoTIFF driver. I've hacked my local copy, but last time we spoke you weren't sure you wanted to update it.

[Jukka Rahkonen]

I suppose there is a consensus about how GDAL deals with area or point. I close this ticket. If some issues still exist, new better targeted tickets would be preferred.