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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
