[gdal-dev] AREA_OR_POINT vs GDALMD_AREA_OR_POINT

[Even Rouault]

On Thursday 29 May 2014 20:16:12 Joaquim Luis wrote:
> On 29-05-2014 19:26, Even Rouault wrote:
> > Joaquim,
> > 
> > I'm confused by what you are actually trying to do.
> 
> OK Even, I'll try to explain better. As we all know here, GDAL reports
> all region limits as pixel corner coordinates (AREA_OR_POINT=Area for
> GeoTiffs). GMT on the other hand keeps track of the original
> registration (we call it grid or node registration (cell center) and
> pixel registration (cell corner)). And we can toggle between one and
> another either by just adjusting the grid limits or by re-interpolation.
> 
> When GMT reads grids via GDAL it only knows that what the latter tells
> it, but not the data's original info. A decision was made (mea culpa)
> that all rasters of char type (images) are treated in GMT as 'Area'
> (pixel) and the others (grids) as 'Point'. This allow as, for example,
> that a netcdf grid created and read by GMT internal code or via GDAL
> sow the same limits (most of times). It's a pity that the original
> registration type is not preserved in GDAL so we could respect it.

Is not preserved : through which operations ?

> But
> GeoTIffs when they use the AREA_OR_POINT key store that info, so in that
> case I try to respect it. So, answering to your question, that is what I
> am trying to do
> 
> So let me repeat one of my previous questions, why was this ignored?
> 
>      GDALSetMetadataItem(hDstDS, "AREA_OR_POINT", "Point", NULL);

What do you mean by "ignored" ? Self-contained reproducable use case please 
;-) I don't read in your mind.

$ python
Python 2.7.3 (default, Feb 27 2014, 19:58:35) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from osgeo import gdal
ds =>>> ds = gdal.GetDriverByName('Mem').Create('', 1, 1)
>>> ds.SetMetadataItem('AREA_OR_POINT', 'Point')
0
>>> ds.GetMetadataItem('AREA_OR_POINT')
'Point'


> 
> > Regarding the MEM driver, GDALMD_AREA_OR_POINT is just a random
> > metadata item.
> > 
> > Some drivers will set GDALMD_AREA_OR_POINT to the GDALMD_AOP_POINT =
> > "Point" value.
> > 
> > And the GTiff driver uses it to determine if it must apply a
> > half-pixel shift between the GDAL convention and the GeoTIFF convention.
> > 
> > Even
> > 
> > > Hi,
> > > 
> > > 
> > > 
> > > I made GMT respect as far as possible the AREA_OR_POINT GeoTiff key
> > > 
> > > for read/write, but ...
> > > 
> > > 
> > > 
> > > The following was silently ignored (GMT uses the MEM driver)
> > > 
> > > 
> > > 
> > > GDALSetMetadataItem(hDstDS, "AREA_OR_POINT", "Point", NULL);
> > > 
> > > 
> > > 
> > > so digging here and there I found about GDALMD_AREA_OR_POINT, and in
> > > 
> > > fact this one is now taken into consideration
> > > 
> > > 
> > > 
> > > GDALSetMetadataItem(hDstDS, "GDALMD_AREA_OR_POINT", "Point", NULL);
> > > 
> > > 
> > > 
> > > 
> > > 
> > > However, this implies that on reading I have now to test for both
> > > 
> > > 
> > > 
> > > GDALGetMetadataItem(hDataset, "AREA_OR_POINT", NULL)
> > > 
> > > 
> > > 
> > > ---- AND ----
> > > 
> > > 
> > > 
> > > GDALGetMetadataItem(hDataset, "GDALMD_AREA_OR_POINT", NULL)
> > > 
> > > 
> > > 
> > > This means that other codes that pay attention to the AREA vs POINT
> > > 
> > > thing will have to do both tests as well and if they do only the first
> > > 
> > > one, GeoTiffs created by GDAL will have the problem ignored, and quite
> > > 
> > > likely an error in coordinates will follow.
> > > 
> > > 
> > > 
> > > So the question is, why this name duplication (AREA_OR_POINT vs
> > > 
> > > GDALMD_AREA_OR_POINT) and why GDALSetMetadataItem() ignores the
> > > 
> > > AREA_OR_POINT key?
> > > 
> > > 
> > > 
> > > Thanks
> > > 
> > > Joaquim
> > > 
> > > 
> > > 
> > > ----------------------------------------------------------------
> > > 
> > > This message was sent using IMP, the Internet Messaging Program.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 
> > > gdal-dev mailing list
> > > 
> > > gdal-dev at lists.osgeo.org
> > > 
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > 
> > Geospatial professional services
> > 
> > http://even.rouault.free.fr/services.html
-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140529/b584a4d1/attachment-0001.html>