Re: [GRASS-user] RE:How to find shortest distances from the investigation point to the shoreline
sgw00412 wrote: I tested by two kinds of geographical coordinate systems by using the same data. One of the geographical coordinate systems is UTM54, and the remainder is wgs84. data :point vector data (10 points) and a line vector data OS: grass 6.2.3 on Cygwin. As a result, the case of UTM54 obtained the distance of meter. On the other hand, wgs84 obtained the distance of decimal value. So, I guess that the decimal value of wgs84 is a degree of latitude longitude. Grass manual wrote that ...In lat-long locations v.distance gives distances (dist and to_along) in meters not in degrees calculated as geodesic distances on a sphere.. http://www.ces.iisc.ernet.in/grass/grass64/manuals/html64_user/v.distance.html Though this manual is version 6.4, the manual of version 6.2 is not written it. Is this interpretation correct? If it is so, please teach me the method of converting the decimal value into the meter. Yes, version 6.2.3 is giving distances in (useless) degree units. This was fixed in Jan 2008 by Martin to use geodesic distance in meters, so GRASS 6.3.0 and the upcoming 6.4 do return meters. But 6.2.3 was released in Nov 2007 and so is too old to have that fix. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass cell registration format
Seb wrote: What type of registration do GRASS raster cells use? cell, not grid. see http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html I'm trying to import several hundred rasters from GMT into GRASS, old GMT binary grid or new NetCDF GMT binary grid? and the only way I managed to do it was by piping grd2xyz output through r.in.xyz, did r.in.gdal not work? that should take care of the grid-cell registration region adjustments for you. (hopefully) does it segfault too? as the Wiki recommendation to use r.in.bin failed with segmentation fault (I think this is due to the GDAL packages in Debian sid, which cannot read the GMT grids because gdalinfo shows that same segfault). weird, r.in.bin specifically does not use GDAL at all. did you convert to an old style GMT grid before trying 'r.in.bin -h'? was an earlier version of gdalinfo able to read it? can gmt's grdinfo say anything about it? One of my concerns with the pipe I described is that grd2xyz's output corresponds to grid line registration, and I'm not sure this matches what GRASS uses. All of this happens in a lat/lon location. Any tips would be appreciated. Thanks. maybe the new XYZ import wiki page Markus just created can help? it explains how to expand the region by half a cell outward to deal with the different registration method. (see also the r.region module) http://grass.osgeo.org/wiki/Import_XYZ but r.in.gdal should be the easy automatic way... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass cell registration format
Seb: I'm trying to import several hundred rasters from GMT into GRASS, and the only way I managed to do it was by piping grd2xyz output through r.in.xyz, oh, besides the GMT wiki page[1] see also this wiki page[2] which gives an example of grd2xyz | r.in.xyz. [1] http://grass.osgeo.org/wiki/GRASS_and_GMT [2] http://grass.osgeo.org/wiki/Marine_Science#Bathymetric_data please fix directly or point out any errors or inefficiencies you find. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] RE:How to find shortest distances from the investigation point to the shoreline
Hi all, May be our friend Yasuo shimada are suffering for the absence of binary version newest than 6.2 on linux? regards, milton 2009/5/13 Hamish hamis...@yahoo.com sgw00412 wrote: I tested by two kinds of geographical coordinate systems by using the same data. One of the geographical coordinate systems is UTM54, and the remainder is wgs84. data :point vector data (10 points) and a line vector data OS: grass 6.2.3 on Cygwin. As a result, the case of UTM54 obtained the distance of meter. On the other hand, wgs84 obtained the distance of decimal value. So, I guess that the decimal value of wgs84 is a degree of latitude longitude. Grass manual wrote that ...In lat-long locations v.distance gives distances (dist and to_along) in meters not in degrees calculated as geodesic distances on a sphere.. http://www.ces.iisc.ernet.in/grass/grass64/manuals/html64_user/v.distance.html Though this manual is version 6.4, the manual of version 6.2 is not written it. Is this interpretation correct? If it is so, please teach me the method of converting the decimal value into the meter. Yes, version 6.2.3 is giving distances in (useless) degree units. This was fixed in Jan 2008 by Martin to use geodesic distance in meters, so GRASS 6.3.0 and the upcoming 6.4 do return meters. But 6.2.3 was released in Nov 2007 and so is too old to have that fix. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] white/black sky albedo
Hi to everybody! I´d like to calculate the ET(a) with the senay method. Does anybody know the difference between white and black albedo and what effects they have in the calculation? Thanks a lot! Nadine -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Raster Google Earth script using gdal2tiles.py
Hi, I've seen various ways of getting GRASS rasters into Google Earth tiles but always seemed to have trouble with the colours or the reprojections. This is what I finally found worked for me, so am posting it in case it is useful to anyone else. It requires a recent version of gdal (I have 1.5.2) to provied the gdal2tiles.py script, and the ImageMagick program mogrify to make null regions of the map (which were white in my map) transparent. I hope that it is useful. Later John r.out.ge #!/bin/bash # Export map to Google Earth tiles. map=$1 # Export map as png and make null data transparent g.region rast=$map export `g.region zoom=$map -lg` # Get map bounds in Lat Long r.out.png $map mogrify -transparent white $map.png # Georeference and reproject output gdal_translate -a_srs EPSG:4326 -a_ullr $nw_long $nw_lat $se_long $se_lat $map.png $map.tif gdalwarp -t_srs EPSG:4326 -rc $map.tif $map\4326.tif # Tile for Google Earth gdal2tiles.py -title $map -forcekml $map\4326.tif $map -- Dr John Stevenson Postdoctoral Research Associate School of Earth, Atmospheric and Environmental Sciences Williamson Building (Room 2.42) University of Manchester Manchester M13 9PL, UK tel. +44(0)161 306 6585; fax. +44(0)161 306 9361; john.steven...@manchester.ac.uk ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Raster Google Earth script using gdal2tiles.py
Thanks, John. Additionally, there is r.out.gmap: http://grass.osgeo.org/wiki/Addons#r.out.gmap best Markus On Wed, May 13, 2009 at 11:31 AM, John A Stevenson john.steven...@manchester.ac.uk wrote: Hi, I've seen various ways of getting GRASS rasters into Google Earth tiles but always seemed to have trouble with the colours or the reprojections. This is what I finally found worked for me, so am posting it in case it is useful to anyone else. It requires a recent version of gdal (I have 1.5.2) to provied the gdal2tiles.py script, and the ImageMagick program mogrify to make null regions of the map (which were white in my map) transparent. I hope that it is useful. Later John r.out.ge #!/bin/bash # Export map to Google Earth tiles. map=$1 # Export map as png and make null data transparent g.region rast=$map export `g.region zoom=$map -lg` # Get map bounds in Lat Long r.out.png $map mogrify -transparent white $map.png # Georeference and reproject output gdal_translate -a_srs EPSG:4326 -a_ullr $nw_long $nw_lat $se_long $se_lat $map.png $map.tif gdalwarp -t_srs EPSG:4326 -rc $map.tif $map\4326.tif # Tile for Google Earth gdal2tiles.py -title $map -forcekml $map\4326.tif $map -- Dr John Stevenson Postdoctoral Research Associate School of Earth, Atmospheric and Environmental Sciences Williamson Building (Room 2.42) University of Manchester Manchester M13 9PL, UK tel. +44(0)161 306 6585; fax. +44(0)161 306 9361; john.steven...@manchester.ac.uk ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] problem with v.clean and intersection pts
Hi everyone, Thanks in advance. I'm trying to extract intersection points. I have a shoreline I extracted using r.contour and many lines that cross the shoreline that are the output of v.distance. I want the intersection points so I'm patching the shoreline and crossbars and then using v.clean tool=break err=intersections. V.clean only gives me one intersection which is where the shoreline reaches the edge of the region, none in the actual intersections. Now I'll give some extra information in case it helps: The workflow that I'm using is: #digitize line roughly parallel to shoreline v.digit map=ShorelineMeasLine -n bgcmd=d.rast R_slope; d.vect R_maximum_036m; d.vect R_minimum_036m --o v.to.points -vi input=ShorelineMeasLine out=ShorelineMeasPts dmax=50 type=line --o #move vector line to the other side of shoreline v.digit map=ShorelineMeasLine -n bgcmd=d.rast R_slope; d.vect R_maximum_036m; d.vect R_minimum_036m #make the crossbars v.distance -p from=ShorelineMeasPts to=ShorelineMeasLine from_type=point to_type=line from_layer=2 upload=dist column=1 output=ShorelineMeasPerpLines --o v.patch input=R_20080327_75m,ShorelineMeasPerpLines output=R_20080327_75m_WPerps --o #find intersections v.clean input=R_20080327_75m_WPerps output=R_20080327_75m_WPerps_break error=R_20080327_75m_Pts tool=break --o --- I don't know if this helps, but if I query one of the crossbars (v.distance output), I get: East: 930243.068465 North: 209846.058091 Map: ShorelineMeasPerpLines Mapset: rodanthe Type: Line Line: 85 Length: 215.661245 -- And if I query the shoreline, I get: East: 930135.548755 North: 209954.759336 Map: R_20080327_75m Mapset: rodanthe Type: Line Line: 1 Length: 10750.507559 Line height: 0.75 Layer: 1 Category: 1 Driver: dbf Database: /home/eric/obx/rodanthe/dbf/ Table: R_20080327_75m Key column: cat cat : 1 level : 0.75 I hope I was clear and gave enough information. Thanks a lot, Eric -- View this message in context: http://n2.nabble.com/problem-with-v.clean-and-intersection-pts-tp2887675p2887675.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] Re: grass cell registration format
Seb wrote: I've experienced this problem with GDAL in the past. gdalinfo has been segfaulting with all (new format) GMT grids in my Debian sid AMD64 system for more than a year. I've also seen the problem with GDAL and other netCDF files, but I haven't been able to properly track this down. There's nothing wrong with the GMT grids, and grdinfo doesn't report anything weird, and they also plot fine. r.in.gdal also segfaults, reinforcing my feeling this is related to GDAL (or its Debian packages). I'd be interested to know whether you're able to import (new format) GMT grids to GRASS with r.in.gdal, especially if you're in Debian. (this is probably a matter better answered by the DebianGIS mailing list, http://wiki.debian.org/DebianGis) Any chance of a gdb backtrace of the segfault? http://grass.osgeo.org/wiki/Bugs check versions with ldd `which gdalinfo` #what does this say? $ dpkg -l | grep gdal | grep '^ii' $ dpkg -l | grep netcdf | grep '^ii' happy Debian user, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] average calculation
Hi, If one were to calculate an average of several rasters, one could simply do: r.mapcalc ave = (A + B + C) / 3 But how can we get around the problem of null values in any of the rasters, which would propagate it to the result? What is an efficient way to calculate both the numerator and denominator for each pixel so that it corresponds only to rasters with non-null values. A second problem is how to script this (shell) so that a large number of rasters can be included in this calculation. I would appreciate some pointers to some scripts where something along these lines can be read, or any thoughts about alternative/better approaches. Thanks. Cheers, -- Seb ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] average calculation
Seb wrote: If one were to calculate an average of several rasters, one could simply do: r.mapcalc ave = (A + B + C) / 3 But how can we get around the problem of null values in any of the rasters, which would propagate it to the result? What is an efficient way to calculate both the numerator and denominator for each pixel so that it corresponds only to rasters with non-null values. be careful with those sorts of tricks because different regions of the result will end up with different levels of statistical strength and so the result may be misleading. A second problem is how to script this (shell) so that a large number of rasters can be included in this calculation. I would appreciate some pointers to some scripts where something along these lines can be read, or any thoughts about alternative/better approaches. use r.series method=average. The -n flag will Propagate NULLs. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Exporting 3bands at same IMG our TIF.
Dear all, I have three image bands - each one as one raster on grass - and I need to export it as TIF or IMG, but on the same file, and as band be a channel (r, g or b) on the output file. I can export each band alone, as independent tiff using r.out.gdal, but I can't export more than one band on the same file. Thanks in advance for the help. milton brazil=toronto ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] qgis-grass bugfix
First success of the bugfix initiative: http://www.qgis.org/wiki/index.php/Bugs the long standing (11 months) and annoying bug https://trac.osgeo.org/qgis/ticket/1133 has been fixed. Please consider joining in: I cannot believe none of you have an annoying bug, and that nobody is willing to invest a few tens of euros/dollars to fix it. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
