[gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation

[Joaquim Luis]

On 16-11-2010 15:54, Frank Warmerdam wrote:
> Ivan Lucena wrote:
>> Frank,
>>
>> Although I agree with your answer to Joaquim's question I would like to
>> extend the subject a little bit.
>>
>> If I understood the RFC33 correctly the CreateCopy()'s of others 
>> driver will
>> not going to fell the effect of that change. I mean, the GeoTransform 
>> will
>> still be based on the center of the pixel. That is good.
>>
>> But for the sake of data quality, for driver/formats that support both
>> reference modes, I believe it will be important to carry away that
>> information to the output. If you take the outputted raster and use 
>> it in
>> surface analysis or 3D visualization packages it will be better to know
>> where the pixel reference really is. Right?
> >
> > IMHO, for those driver, including GTIFF itself, would be nice to 
> know what
> > was the pixel reference of the source dataset in order to make a 
> decision to
> > write reference in a PixelIsPoint or PixelIsArea fashion.
> > should we establish some automatic and standard way of dealing with 
> that?
>
> Ivan,
>
> In fact, I strongly disagree with conflating the sampling technique of
> the sensor (area average vs. point sample) with the georeferencing.  And
> for formats that can store the georeferencing based on either a top left
> corner of top left pixel vs. a center of top left pixel form, I see no
> value in distinguishing them.  There is no real significance.
>
> So, in my opinion, the only reason we might consider doing something with
> the GMT driver at this point is if we decide that the node_offset is 
> really
> intended to indicate something about the sampling nature of the sensor.
> If so, we might want to set it based on the AREA_OR_POINT metadata on 
> write
> and set the AREA_OR_POINT metadata on read.
>
> I don't know enough about the GMT format to know if there is intended to
> be some physical significance to the node_offset setting.
>
> I will note that the AREA_OR_POINT metadata item is already well defined
> in the GDAL Data Model document.  It says:
>
> """
> AREA_OR_POINT: May be either "Area" (the default) or "Point". 
> Indicates whether a pixel value should be assumed to represent a 
> sampling over the region of the pixel or a point sample at the center 
> of the pixel. This is not intended to influence interpretation of 
> georeferencing which remains area oriented.
> """

Frank, Ivan

I was not sure that my question was 100% related to this RFC but I guess 
my reasoning (a bit like Ivan) is, if it is acknowledged that GeoTiff 
can have both models why that information is not carried on when 
converting to other formats that also distinguish between Area vs Point?

I cannot answer to the question if there is any particular physical 
meaning on the PixelIsPoint representation (which in GMT is represented 
by node_offset = 0). Maybe not or maybe yes. The thing is many people 
can create netCDF grids with different softwares. Regarding this point, 
we should not be talking specifically on the GMT driver because it deals 
with the old and deprecated format. Now GMT creates only netCDF CF files 
(which are dealt with the generic netCDF format).

Joaquim