Re: [GRASS-user] flip raster
I've posted new versions of ETOPO1 that GDAL can read properly (north is north) on the ETOPO1 web page (http://www.ngdc.noaa.gov/mgg/global/global.html), along with an explanatory readme file (in each netcdf folder). I've also created and posted geotiff versions of ETOPO1. Please let me know if any more problems are encountered. Thanks, Barry Eakins barry.eak...@noaa.gov ETOPO1 1 Arc-Minute Global Relief Model http://www.ngdc.noaa.gov/mgg/global/global.html -- View this message in context: http://www.nabble.com/flip-raster-tp19836768p21081238.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
Barry Eakins wrote: We've looked into this issue and the problem lies in how GMT v.4.3, which was used to create ETOPO1, and GDAL read and write netcdf grids. Both purport to handle netcdf COORDS-compliant grids though there is clearly a problem with one of these applications (the vertical flipping); the GDAL community forum has apparently already discussed this issue. We're working on a temporary solution, such as publishing an older GMT 3.0 netcdf grid along with the current one that GDAL doesn't read properly. GDAL does read the older netcdf grid without problem. um, about that read without problem .. FYI I had found an odd error with the Smith Sandwell 1' dataset (v10.1) in the older GMT format. As far as I could determine the old GMT grd format introduced a floating point +0.005 elevation shift error in th data. Minor, but uninvited so worth investigating. (this is using GMT tools for Debian Etch; not sure if it's a GMT processing bug or something deeper?) see http://grass.osgeo.org/wiki/Marine_Science#Bathymetric_data my other problem with that dataset (and the focus of the above link) is the rather vague map projection definition given, and struggles with understanding the projection used with GMT's img2grd program. (I haven't checked the new SS 1' v11.1 dataset; there's no readme or log) Earlier today on the PROJ.4 mailing list I got a chuckle to read the phrase geodetic abomination be used in reference to using the mercator projection on a sphere and then trying to tie it back to WGS84. that's not your problem, just something to be aware of. I hope to have something up on our web site by next week. One question that I have: Is there another file format for the ETOPO1 grids that would be of more use to the GRASS community than netcdf? As Glynn noted, GRASS relies primarily on GDAL for importing raster data, but we also have a r.in.bin module which reads raw binary blocks. This is what we've used in the past to import ETOPO2 and ETOPO5 without any problem at all. see http://grass.osgeo.org/wiki/Global_datasets#ETOPO1 We could host something such as geotiffs of the grids, which we can create easily, but I'm not a GRASS user so don't know what grid/raster file format would be easiest to import into GRASS. r.in.gdal and r.in.bin cover most file formats rather well, so there's not one single format to recommend. just a few lossy ones to avoid. I've also never used QGIS. It also heavily relies on GDAL for data import/export, but with less flexible options. GeoTiff is probably a safe bet for them. One thing it is rather good at is quickly loading/previewing large Geotiffs which bring your standard image viewer or paint program to its knees, without the overhead and effort of a big GIS suite. P.S. Sorry about the grid- v. cell-registered grids being a pain, there really is an important difference between the two. The cell registered version of ETOPO1 is trivial to import into GRASS, but what motivated me to attempt to shoehorn in the grid-registed version as chronicled in the above Global_datasets#ETOPO1 wiki page was - The grid-registered is the authoritative registration for each version. The cell-registered was derived from the grid-registered version and the conversion produces slightly flattened relief. comment on the NGDC site. I take that to mean it takes an average of the 4 grid points at each of the cell's corners? The specific problem with working with global grid registered data in GRASS is that lat/lon projects can not have bounds which exceed 90.0 deg N,S. Here's another method to flip the data once it's in GRASS: after loading the flipped raster in GDAL/GRASS export it from GRASS to Matlab (or Octave if you prefer) with the r.out.mat module, run flipud(map_data) in Matlab, resave, and import back into GRASS with r.in.mat. (quicker than writing some C code to do the same) thanks for the effort, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
Hi all, I was informed of this forum discussion via email this morning (not being a GRASS user). We've looked into this issue and the problem lies in how GMT v.4.3, which was used to create ETOPO1, and GDAL read and write netcdf grids. Both purport to handle netcdf COORDS-compliant grids though there is clearly a problem with one of these applications (the vertical flipping); the GDAL community forum has apparently already discussed this issue. We're working on a temporary solution, such as publishing an older GMT 3.0 netcdf grid along with the current one that GDAL doesn't read properly. GDAL does read the older netcdf grid without problem. I hope to have something up on our web site by next week. One question that I have: Is there another file format for the ETOPO1 grids that would be of more use to the GRASS community than netcdf? We could host something such as geotiffs of the grids, which we can create easily, but I'm not a GRASS user so don't know what grid/raster file format would be easiest to import into GRASS. I've also never used QGIS. Any ideas or suggestions would be much appreciated. Thanks, Barry Eakins National Geophysical Data Center P.S. Sorry about the grid- v. cell-registered grids being a pain, there really is an important difference between the two. José María Michia wrote: 2008/10/6 Hamish [EMAIL PROTECTED]: José María Michia wrote: I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. How can I fix this? hmmm, this problem sounds vaguely familiar. Is this the dataset from: http://www.ngdc.noaa.gov/mgg/global/global.html ? if so, which version? the cell/grid registration thing is a slight pain. Yes: grid-registered version, netCDF format. The same problem (vertical inversion) occurs with QGIS. Same in GMT, with an strange (to me) situation: one GMT program produce normal maps. The same problem (vertical inversion) is produced with QGIS. And so does GMT, but one of GMT programs produce the expected result: This, produce vertical inverted map: $ grdraster 1 -R-80/-50/-50/-20 -Gargentina.nc $ grdimage argentina.nc -JM6i -P -B2 -Ctopo.cpt -V -K topo.ps grdraster extract a subset of netCDF grid. Definition for grdraster id 1 is: 1 ETOPO1 global topographym -R-180/180/-90/90 -I1m GG i 1 0 none /mnt/hdb1/geodata/etopo/ETOPO1_Bed_g.grd B And this produces the expected map: $ grdcontour -R-80/-50/-50/-20 /mnt/hdb1/geodata/etopo/ETOPO1_Bed_g.grd -JM6i -P -B2 -C250 -A1000 topo2.ps But, this map is a contour map, not raster map. So, is not adequate for GRASS import. I'm downloading the cell-registered version, I will try again with this version. With the alternative suggested by Hamish (see below), no need to import this file. Alexander: Thanks for your suggestion. I will take into account the CDO program in the future. Another idea for those interested: an alternative might be to use the GDAL program to convert the file into another format NetCDF middle, a format for which it is possible to import into GRASS. This intermediate format can be ASCII, to be able to easily modify it as needed. for importing 1' global elevation from: http://topex.ucsd.edu/marine_topo/mar_topo.html here are some hints, including ETOPO2: http://grass.osgeo.org/wiki/Marine_Science#Bathymetric_data Thanks for the suggestions. I've found the desired data in http://topex.ucsd.edu/cgi-bin/get_data.cgi Hamish Saludos José María ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://www.nabble.com/flip-raster-tp19836768p20708964.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
[CC'd to grass-dev.] beakins wrote: One question that I have: Is there another file format for the ETOPO1 grids that would be of more use to the GRASS community than netcdf? We could host something such as geotiffs of the grids, which we can create easily, but I'm not a GRASS user so don't know what grid/raster file format would be easiest to import into GRASS. I've also never used QGIS. Any ideas or suggestions would be much appreciated. GRASS' preferred raster format is anything which GDAL supports, and for which GetGeoTransform() succeeds, with the adfTransform[] array satisfying the constraints: adfTransform[1] 0 adfTransform[2] == 0 adfTransform[4] == 0 adfTransform[5] 0 [Currently, r.in.gdal/r.external don't bother to check adfTransform[1]; if it's negative, GRASS may import it okay, but then refuse to read it.] IOW, north-to-south, west-to-east, no rotation or shear. If the data uses a different orientation, GDAL needs to be able to transform it itself. It isn't a major problem if the georeferencing data isn't readily available, but a different orientation is (at present). Ultimately, we could make some changes to support flipped (but not rotated) rasters, but the format would ideally need to be such that there isn't a penalty for reading data north-to-south, i.e. any south-to-north data would need to be in a format which supports non-sequential access (seeking). -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
On Wed, Nov 5, 2008 at 8:59 AM, Etsushi Kato [EMAIL PROTECTED] wrote: On Thu, Oct 9, 2008 at 10:12 PM, Markus Neteler [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 2:15 PM, José María Michia: I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. ... I've filed a new ticket rather than adding a comment in #2584 because I can get the right image (EASE Grid SNOW data) with gdal_translate NETCDF:NL.2004.nsidc0321v01.nc:SCA /tmp/sca.tif using original gdal-1.5.3. I am using GDAL trunk and tried today on the EASE Grid Snow northern hemisphere): gdalwarp -s_srs +proj=laea +lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +a=6371228.0 +b=6371228.0 +to_meter=1 \ -t_srs epsg:4326 -te 0 30 30 60 NETCDF:NL.2004.nsidc0321v01.nc:SCA /tmp/sca.tif The resulting map is correctly (maybe) projected but all data are lost. Likewise GRASS cannot do much. I'll try to get this fixed on the GDAL side. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
On Thu, Oct 9, 2008 at 10:12 PM, Markus Neteler [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 2:15 PM, José María Michia [EMAIL PROTECTED] wrote: Hi, I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. I have a similar problem with the EASE Grid SNOW data and filed it as ticket to GDAL: http://trac.osgeo.org/gdal/ticket/2584 (see Attachment there for screenshot) If reproducable, please submit a test case incl data link to above ticket. The more interest, the more likely it gets fixed. I also experienced the vertical flipped image by gdal's NetCDF driver with CF-1.0 files. And I've just added a patch to fix this on gdal trac (http://trac.osgeo.org/gdal/ticket/2654). I've filed a new ticket rather than adding a comment in #2584 because I can get the right image (EASE Grid SNOW data) with gdal_translate NETCDF:NL.2004.nsidc0321v01.nc:SCA /tmp/sca.tif using original gdal-1.5.3. Cheers, -- Etsushi Kato [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
On Wed, 2008-10-08 at 23:48 -0300, José María Michia wrote: 2008/10/8 Nikos Alexandris [EMAIL PROTECTED]: On Tue, 2008-10-07 at 01:37 +0100, Glynn Clements wrote: José María Michia wrote: I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. How can I fix this? I try with mapcalc, without success: - neighborhood modifier: not accept computations in offset parameter, like map[0,total_rows-row()] - I dont know how to query map in arbitrary coordinates, like map(x(),-1*y()) There isn't any mechanism in r.mapcalc to achieve this. I'm not sure that it's possible to do it entirely within GRASS. Flipping geo-referenced data doesn't really make much sense. Either figure out how to import it with the correct orientation, or export it, flip the exported data, then re-import. Glynn and All, excuse me for hijacking the post. I am looking for a way (just for the fun of the game or for philosophical re-search) to rotate geotiffs at 180 degrees (i.e. flip vertically and horizontally). I've posted about this in the gdal-dev list [1]. Is there a way to accomplish a 180 deg. rotation using the listgeo/geotifcp command line tools? I'm not sure, but maybe this can be useful: Alexander Schulze suggested me that I use the library to invest CDO latitudes: http://www.mpimet.mpg.de/fileadmin/software/cdo/ Something like: cdo invertlat filein fileout1 cdo invertlon fileout1 fileout2 If you can use netCDF format, look at this: http://nco.wiki.sourceforge.net/reverse a dimension Saludos José María Thank you, Nikos [1] http://lists.osgeo.org/pipermail/gdal-dev/2008-October/018548.html Hola Jose! Thank you for your suggestion. I had a look but I am looking for a simpler solution for this and I want to stick with (geo-)tiff files. Hamish's method works great! Regards, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
On Thu, 2008-10-09 at 15:04 +0200, Nikos Alexandris wrote: On Wed, 2008-10-08 at 20:23 -0700, Hamish wrote: Nikos: Is there a way to accomplish a 180 deg. rotation using the listgeo/geotifcp command line tools? try saving meta data to a file as detailed in the libGeotiff FAQ, then tifftopnm | pnmflip | pnmtotiff and reattaching metadata as shown in the FAQ entry. http://www.remotesensing.org/geotiff/faq.html#preserve_metadata Hamish Hamish, thank you very much. It works fine (with coordinates preserved as before). Now I will also try to get them inverted as well (...if this is possible??). My warmest greetings from grey-clouded Freiburg, Nikos Forgot to copy-paste an example! # working with a file called testLandsatTM_rotated.tif # save geo-metadata listgeo -no_norm testLandsatTM.tif testLandsatTM.tif.geo # rotate via tifftopnm | pnmflip -r180 | pnmtotiff tifftopnm testLandsatTM.tif | pnmflip -r180 | pnmtotiff testLandsatTM_rotated.tif # apply geo-metadata back geotifcp -g testLandsatTM.tif.geo testLandsatTM_rotated.tif testLandsatTM_rotated_tagged.tif ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
On Mon, Oct 6, 2008 at 2:15 PM, José María Michia [EMAIL PROTECTED] wrote: Hi, I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. I have a similar problem with the EASE Grid SNOW data and filed it as ticket to GDAL: http://trac.osgeo.org/gdal/ticket/2584 (see Attachment there for screenshot) If reproducable, please submit a test case incl data link to above ticket. The more interest, the more likely it gets fixed. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
On Tue, 2008-10-07 at 01:37 +0100, Glynn Clements wrote: José María Michia wrote: I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. How can I fix this? I try with mapcalc, without success: - neighborhood modifier: not accept computations in offset parameter, like map[0,total_rows-row()] - I dont know how to query map in arbitrary coordinates, like map(x(),-1*y()) There isn't any mechanism in r.mapcalc to achieve this. I'm not sure that it's possible to do it entirely within GRASS. Flipping geo-referenced data doesn't really make much sense. Either figure out how to import it with the correct orientation, or export it, flip the exported data, then re-import. Glynn and All, excuse me for hijacking the post. I am looking for a way (just for the fun of the game or for philosophical re-search) to rotate geotiffs at 180 degrees (i.e. flip vertically and horizontally). I've posted about this in the gdal-dev list [1]. Is there a way to accomplish a 180 deg. rotation using the listgeo/geotifcp command line tools? Thank you, Nikos [1] http://lists.osgeo.org/pipermail/gdal-dev/2008-October/018548.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
2008/10/8 Nikos Alexandris [EMAIL PROTECTED]: On Tue, 2008-10-07 at 01:37 +0100, Glynn Clements wrote: José María Michia wrote: I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. How can I fix this? I try with mapcalc, without success: - neighborhood modifier: not accept computations in offset parameter, like map[0,total_rows-row()] - I dont know how to query map in arbitrary coordinates, like map(x(),-1*y()) There isn't any mechanism in r.mapcalc to achieve this. I'm not sure that it's possible to do it entirely within GRASS. Flipping geo-referenced data doesn't really make much sense. Either figure out how to import it with the correct orientation, or export it, flip the exported data, then re-import. Glynn and All, excuse me for hijacking the post. I am looking for a way (just for the fun of the game or for philosophical re-search) to rotate geotiffs at 180 degrees (i.e. flip vertically and horizontally). I've posted about this in the gdal-dev list [1]. Is there a way to accomplish a 180 deg. rotation using the listgeo/geotifcp command line tools? I'm not sure, but maybe this can be useful: Alexander Schulze suggested me that I use the library to invest CDO latitudes: http://www.mpimet.mpg.de/fileadmin/software/cdo/ Something like: cdo invertlat filein fileout1 cdo invertlon fileout1 fileout2 If you can use netCDF format, look at this: http://nco.wiki.sourceforge.net/reverse a dimension Saludos José María Thank you, Nikos [1] http://lists.osgeo.org/pipermail/gdal-dev/2008-October/018548.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
Nikos: Is there a way to accomplish a 180 deg. rotation using the listgeo/geotifcp command line tools? try saving meta data to a file as detailed in the libGeotiff FAQ, then tifftopnm | pnmflip | pnmtotiff and reattaching metadata as shown in the FAQ entry. http://www.remotesensing.org/geotiff/faq.html#preserve_metadata Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] flip raster
Hi, I've imported a NetCDF file (ETOPO1 model). The resulted raster appears flipped vertically. How can I fix this? I try with mapcalc, without success: - neighborhood modifier: not accept computations in offset parameter, like map[0,total_rows-row()] - I dont know how to query map in arbitrary coordinates, like map(x(),-1*y()) I need advice, I do not know another way to try out. Thanks José María ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
