Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
Joaquim Luis wrote: Frank, Wouldn't this apply to the netCDF grids as well? GMT has always made the distinction on the area vs point representation. The grids created by GMT hold that information on the global attribute node_offset. As for other netCDF CF grids created elsewhere it is also possible to find which model is used by checking the grid limits vs array size because for the same limits the PixelIsArea model has one less row and column than the PixelIsPoint. Joaquim, The gdal/frmts/netcdf/gmtdataset.cpp code already examines the node_offset and adjusts the geotransform accordingly. It does not currently attempt to expose the node_offset via the AREA_OR_POINT metadata item though it could. I do not see the GMT format driver being pertinent to the RFC. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
On 11/16/10 02:40, Frank Warmerdam wrote: Folks, After 15 years of denial, and bullheadedness it is now time for me to admit my interpretation of PixelIsPoint in GeoTIFF files is wrong. To that end I have prepared a brief RFC discussing how I intend to fix it. I'd appreciate comment before calling for a vote. http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Mmmm, crow - it tastes just like chicken! Best regards, Had to look up what this subject line meant, of course. Is this what you are looking like at the moment, Frank? :-) http://www.google.nl/imgres?imgurl=http://i727.photobucket.com/albums/ww276/tbattitori/EatingCrow1.jpgimgrefurl=http://s727.photobucket.com/albums/ww276/tbattitori/%3Faction%3Dview%26current%3DEatingCrow1.jpg%26newest%3D1h=375w=500sz=18tbnid=KaUtizW3jL28JM:tbnh=98tbnw=130prev=/images%3Fq%3Deating%2Bcrowzoom=1q=eating+crowusg=__v_cJYvwniyZnvECIivrDQDkqG38=sa=Xei=i2PiTOqrH4GXOvyzkWEved=0CDAQ9QEwAw Jan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
Frank, Wouldn't this apply to the netCDF grids as well? GMT has always made the distinction on the area vs point representation. The grids created by GMT hold that information on the global attribute node_offset. As for other netCDF CF grids created elsewhere it is also possible to find which model is used by checking the grid limits vs array size because for the same limits the PixelIsArea model has one less row and column than the PixelIsPoint. Joaquim Folks, After 15 years of denial, and bullheadedness it is now time for me to admit my interpretation of PixelIsPoint in GeoTIFF files is wrong. To that end I have prepared a brief RFC discussing how I intend to fix it. I'd appreciate comment before calling for a vote. http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Mmmm, crow - it tastes just like chicken! Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
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? Best regards, Ivan ---Original Message--- From: Frank Warmerdam warmer...@pobox.com To: Joaquim Luis jl...@ualg.pt Cc: gdal-dev gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation Sent: Nov 16 '10 09:40 Joaquim Luis wrote: Frank, Wouldn't this apply to the netCDF grids as well? GMT has always made the distinction on the area vs point representation. The grids created by GMT hold that information on the global attribute node_offset. As for other netCDF CF grids created elsewhere it is also possible to find which model is used by checking the grid limits vs array size because for the same limits the PixelIsArea model has one less row and column than the PixelIsPoint. Joaquim, The gdal/frmts/netcdf/gmtdataset.cpp code already examines the node_offset and adjusts the geotransform accordingly. It does not currently attempt to expose the node_offset via the AREA_OR_POINT metadata item though it could. I do not see the GMT format driver being pertinent to the RFC. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
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. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
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
[gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
Folks, After 15 years of denial, and bullheadedness it is now time for me to admit my interpretation of PixelIsPoint in GeoTIFF files is wrong. To that end I have prepared a brief RFC discussing how I intend to fix it. I'd appreciate comment before calling for a vote. http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Mmmm, crow - it tastes just like chicken! Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
Frank, Courageous decision! But I got confused by that sentence: In GDAL 1.7 and 1.6 branch the same changes will be applied, except the GTIFF_POINT_GEO_IGNORE configuration option will default to FALSE. Did you mean to say TRUE? Regards, Ivan ---Original Message--- From: Frank Warmerdam warmer...@pobox.com To: gdal-dev gdal-dev@lists.osgeo.org Subject: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation Sent: Nov 15 '10 20:40 Folks, After 15 years of denial, and bullheadedness it is now time for me to admit my interpretation of PixelIsPoint in GeoTIFF files is wrong. To that end I have prepared a brief RFC discussing how I intend to fix it. I'd appreciate comment before calling for a vote. http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Mmmm, crow - it tastes just like chicken! Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
Ivan Lucena wrote: Frank, Courageous decision! But I got confused by that sentence: In GDAL 1.7 and 1.6 branch the same changes will be applied, except the GTIFF_POINT_GEO_IGNORE configuration option will default to FALSE. Did you mean to say TRUE? Ivan, Yes, I have corrected it in the RFC. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
I thought you Canadians ate salmon? Martin Sent via BlackBerry by ATT -Original Message- From: Frank Warmerdam warmer...@pobox.com Sender: gdal-dev-boun...@lists.osgeo.org Date: Mon, 15 Nov 2010 20:40:20 To: gdal-devgdal-dev@lists.osgeo.org Subject: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation Folks, After 15 years of denial, and bullheadedness it is now time for me to admit my interpretation of PixelIsPoint in GeoTIFF files is wrong. To that end I have prepared a brief RFC discussing how I intend to fix it. I'd appreciate comment before calling for a vote. http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Mmmm, crow - it tastes just like chicken! Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Frank Eats Crow - or Fixing PixelIsPoint Interpretation
On 2010-11-16 05:49, chapm...@pixia.com wrote: I thought you Canadians ate salmon? He said Bullheadedness, not Bearheadedness Nice attitude to the issue, Frank. :-) -- === Zoltan Szecsei PrGISc [PGP0031] Geograph (Pty) Ltd. P.O. Box 7, Muizenberg 7950, South Africa. 65 Main Road, Muizenberg 7945 Western Cape, South Africa. 34° 6'16.35S 18°28'5.62E Tel: +27-21-7884897 Mobile: +27-83-6004028 Fax: +27-86-6115323 www.geograph.co.za === - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3258 - Release Date: 11/15/10 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
