[GRASS-user] Mac OS X compilation and addons question (how to add on addons)
Mac OS X 10.5.7 Downloaded and installed dependencies from: http://www.kyngchaos.com/software:frameworks cd into the source directory run in the terminal as to the example in the macosx folder of the source: ./configure --with-freetype --with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/include/freetype2 /Library/Frameworks/FreeType.framework/unix/include --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --without-postgres --without-mysql --with-odbc --with-sqlite --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-cxx --with-tcltk-includes=/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders --with-tcltk-libs=/usr/local/lib --with-x --without-motif --without-glw --with-opengl=aqua --without-readline --prefix=/Applications --enable-macosx-app make end of make output: -- Following modules are missing the 'description.html' file in src code: -- GRASS GIS compilation log - Started compilation: Wed Jul 8 09:03:28 CDT 2009 -- Errors in: No errors detected. sudo make install installs fine Now I would like to add some addon packages specifically v.strahler. I can not figure this one out. I have svn checkout https://.../ grass-addons which checks out the source to a folder in /User/sefick/grass-addons I am not sure if I need to compile the sources and then recompile grass or use some sort of method hinted at in this post: http://n2.nabble.com/need-help-with-mac-os-x-installation-td1879293i20.html#a1879310 thanks for all of your help, Stephen Sefick -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Mac OS X compilation and addons question (how to add on addons)
The addon compilation setup for OSX is kindof in limbo right now. I think it still works. First make install GRASS. Then look at / Library/GRASS/6.4/modbuild/ReadMe.rtf. There is a platform-neutral make setup that is also installed now, but I'm not sure about the state of it in 6.4 or 6.5. In 7.0/trunk there is a new g.extension module that (I think) should be replacing GEM and work for OSX's needs. On Jul 8, 2009, at 9:18 AM, stephen sefick wrote: Mac OS X 10.5.7 Downloaded and installed dependencies from: http://www.kyngchaos.com/software:frameworks cd into the source directory run in the terminal as to the example in the macosx folder of the source: ./configure --with-freetype --with-freetype-includes=/Library/Frameworks/FreeType.framework/ unix/include/freetype2 /Library/Frameworks/FreeType.framework/unix/include --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/ unix/include --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/ include --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/ include --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/ include --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --without-postgres --without-mysql --with-odbc --with-sqlite --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/ include --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-cxx --with-tcltk-includes=/Library/Frameworks/Tcl.framework/ Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders --with-tcltk-libs=/usr/local/lib --with-x --without-motif --without-glw --with-opengl=aqua --without-readline --prefix=/Applications --enable-macosx-app make end of make output: -- Following modules are missing the 'description.html' file in src code: -- GRASS GIS compilation log - Started compilation: Wed Jul 8 09:03:28 CDT 2009 -- Errors in: No errors detected. sudo make install installs fine Now I would like to add some addon packages specifically v.strahler. I can not figure this one out. I have svn checkout https://.../ grass-addons which checks out the source to a folder in /User/sefick/grass-addons I am not sure if I need to compile the sources and then recompile grass or use some sort of method hinted at in this post: http://n2.nabble.com/need-help-with-mac-os-x-installation-td1879293i20.html#a1879310 thanks for all of your help, Stephen Sefick -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Mac OS X compilation and addons question (how to add on addons)
here is an update and it is not compiling- I think make GRASS_HOME='/Users/sefick/Grass-addons-installed' GRASS_APP='/Applications/GRASS-6.4.app' ../../include/Make/Grass.make:385: warning: overriding commands for target `first' ../../include/Make/Grass.make:385: warning: ignoring old commands for target `first' ../../include/Make/Grass.make:401: warning: overriding commands for target `inst_now' ../../include/Make/Grass.make:401: warning: ignoring old commands for target `inst_now' ../../include/Make/Grass.make:409: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/bin.i386-apple-darwin9.7.0' ../../include/Make/Grass.make:409: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/bin.i386-apple-darwin9.7.0' ../../include/Make/Grass.make:412: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/include/grass' ../../include/Make/Grass.make:412: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/include/grass' ../../include/Make/Grass.make:415: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/lib' ../../include/Make/Grass.make:415: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/lib' ../../include/Make/Grass.make:418: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/bin' ../../include/Make/Grass.make:418: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/bin' ../../include/Make/Grass.make:421: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/etc' ../../include/Make/Grass.make:421: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/etc' ../../include/Make/Grass.make:424: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/driver' ../../include/Make/Grass.make:424: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/driver' ../../include/Make/Grass.make:427: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/driver/db' ../../include/Make/Grass.make:427: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/driver/db' ../../include/Make/Grass.make:430: warning: overriding commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/fonts' ../../include/Make/Grass.make:430: warning: ignoring old commands for target `/Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/fonts' ../../include/Make/Rules.make:28: warning: overriding commands for target `OBJ.i386-apple-darwin9.7.0' ../../include/Make/Rules.make:28: warning: ignoring old commands for target `OBJ.i386-apple-darwin9.7.0' ../../include/Make/Rules.make:72: warning: overriding commands for target `clean' ../../include/Make/Rules.make:72: warning: ignoring old commands for target `clean' ../../include/Make/Html.make:45: warning: overriding commands for target `htmlcmd' ../../include/Make/Html.make:45: warning: ignoring old commands for target `htmlcmd' ../../include/Make/Html.make:49: warning: overriding commands for target `htmlscript' ../../include/Make/Html.make:49: warning: ignoring old commands for target `htmlscript' ../../include/Make/Html.make:53: warning: overriding commands for target `htmletc' ../../include/Make/Html.make:53: warning: ignoring old commands for target `htmletc' ../../include/Make/Html.make:57: warning: overriding commands for target `htmldir' ../../include/Make/Html.make:57: warning: ignoring old commands for target `htmldir' ../../include/Make/Html.make:61: warning: overriding commands for target `htmlmulti' ../../include/Make/Html.make:61: warning: ignoring old commands for target `htmlmulti' ../../include/Make/Man.make:43: warning: overriding commands for target `mancmd' ../../include/Make/Man.make:43: warning: ignoring old commands for target `mancmd' ../../include/Make/Man.make:47: warning: overriding commands for target `manscript' ../../include/Make/Man.make:47: warning: ignoring old commands for target `manscript' ../../include/Make/Man.make:51: warning: overriding commands for target `manetc' ../../include/Make/Man.make:51: warning: ignoring old commands for target `manetc' ../../include/Make/Man.make:55: warning: overriding commands for target `mandir' ../../include/Make/Man.make:55: warning: ignoring old commands for target `mandir' ../../include/Make/Man.make:59: warning: overriding commands for target `manmulti' ../../include/Make/Man.make:59: warning: ignoring old commands for target `manmulti' ../../include/Make/Module.make:25: warning: overriding commands for
[GRASS-user] .e00 to DEM
The data I would like to import in GRASS is here: http://csat.er.usgs.gov/statewide/layers/dem250.html I have tried r.in.gdal with no sucess. I will provide anything that is helpfull. This is my second post, so I don't know what would be helpful. thanks for the help, -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Mac OS X compilation and addons question (how to add on addons)
On Jul 8, 2009, at 10:53 AM, stephen sefick wrote: here is an update and it is not compiling- I think make GRASS_HOME='/Users/sefick/Grass-addons-installed' GRASS_APP='/Applications/GRASS-6.4.app' ... mkdir -p /Users/sefick/Grass-addons-installed/dist.i386-apple- darwin9.7.0/man/man1 GRASS_PERL=/usr/bin/perl VERSION_NUMBER=6.4.0RC5 sh /Users/sefick/Grass-addons-installed/tools/g.html2man/g.html2man /Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/ docs/html/v.strahler.html /Users/sefick/Grass-addons-installed/dist.i386-apple-darwin9.7.0/man/ man1/v.strahler.1 1 sh: /Users/sefick/Grass-addons-installed/tools/g.html2man/g.html2man: No such file or directory make[2]: *** [/Users/sefick/Grass-addons-installed/dist.i386-apple- darwin9.7.0/man/man1/v.strahler.1] Error 127 make[1]: *** [mancmd] Error 2 make: *** [cmd] Error 2 It looks like everything compiled OK, it's just having problems with making the man page, which isn't critical. The compiled module should be in the dist folder. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
On Wed, 2009-07-08 at 10:57 -0500, stephen sefick wrote: The data I would like to import in GRASS is here: http://csat.er.usgs.gov/statewide/layers/dem250.html I have tried r.in.gdal with no sucess. I will provide anything that is helpfull. This is my second post, so I don't know what would be helpful. thanks for the help, Hi. I've downloaded the GRID [1] file. gdalinfo works (with some reported errors) on the dem250/ directory which is stored within workspl[2]. So I created a location based on the data itself (using the dem250 directory as a source) and imported in grass with r.in.gdal (again using the dem250 directory as input). --- # enter in _some_ location and create another-one based on the data g.proj -c location=albers_us georef=/geo/geodata/world/us/worksp1/dem250 # exit from current location, enter in newly created one grass64 /geo/grassdb/global/albers_us/PERMANENT/ # import data r.in.gdal in=/geo/geodata/world/us/workspl/dem250 out=dem250 --- There is something strange with the values though (they expand from min = -32687 max = 32645). Don't have the time to dig further, maybe there are details in the meta-data about it (!?). Good Luck, Nikos --- [1] http://csat.er.usgs.gov/download/statewide/dem250grid.zip [2] gdalinfo dem250/ ERROR 3: Attempt to read past EOF in dem250//../info/arc.dir. ERROR 4: Failed to open table .VAT Driver: AIG/Arc/Info Binary Grid Files: dem250/ dem250/dblbnd.adf dem250/hdr.adf dem250/log dem250/prj.adf dem250/sta.adf dem250/vat.adf dem250/w001001.adf dem250/w001001x.adf Size is 7495, 8622 Coordinate System is: PROJCS[unnamed, GEOGCS[NAD83, DATUM[North_American_Datum_1983, SPHEROID[GRS 1980,6378137,298.257222101, AUTHORITY[EPSG,7019]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6269]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AUTHORITY[EPSG,4269]], PROJECTION[Albers_Conic_Equal_Area], PARAMETER[standard_parallel_1,29.5], PARAMETER[standard_parallel_2,45.5], PARAMETER[latitude_of_center,23], PARAMETER[longitude_of_center,-83.5], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[METERS,1]] Origin = (-190574.428637420991436,1327208.631963560357690) Pixel Size = (60.000,-60.000) Corner Coordinates: Upper Left ( -190574.429, 1327208.632) ( 85d36'18.54W, 34d59'5.20N) Lower Left ( -190574.429, 809888.632) ( 85d29'8.74W, 30d20'49.23N) Upper Right ( 259125.571, 1327208.632) ( 80d38'16.82W, 34d58'7.57N) Lower Right ( 259125.571, 809888.632) ( 80d48'1.00W, 30d19'54.45N) Center ( 34275.571, 1068548.632) ( 83d 7'56.55W, 32d41'16.79N) Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined Min=0.000 Max=1371.000 NoData Value=-32768 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
On Wed, 2009-07-08 at 18:19 +0200, Nikos Alexandris wrote: workspl[2]. Sorry, that is worksp1 ( 1 and not l). Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
On Wednesday 08 July 2009, Nikos Alexandris wrote: There is something strange with the values though (they expand from min = -32687 max = 32645). Don't have the time to dig further, maybe there are details in the meta-data about it (!?). This looks like an overflow problem. Could it be that this file contains unsigned 16 / 32 bit integers, but is being read in as signed 16 bit integers? This used to happen when reading in Arc ASCII grids that contained very large numbers ( 32768) somewhere other than in the first couple of lines. I am pretty sure this bug has been fixed-- but I am not sure how GDAL is interpreting this specific file. It would be useful to use gdal_translate to copy the file, forcing the bit-size of the output to something else. Here was the original GRASS ticket: http://trac.osgeo.org/grass/ticket/166 and the subsequent GDAL ticket: http://trac.osgeo.org/gdal/ticket/2369 There are some tips in the GDAL ticket on forcing a file to be read as a 32bit integers (etc.). Quoth Frank W: Note that with gdal_translate you can convert pixel types on the fly, so if you know the data range is suitable for Int16, you could do gdal_translate -ot Int16 in.grd out.tif for instance. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems with v.in.ogr importing shp files
Hope John solved his issue but it's quite different from mine. I guess the problem I'm facing with v.in.ogr function have been solved by Jachym Cepicky ( http://n2.nabble.com/grass-gdal-ubuntu-issue-solved-(-)-td2352498.html ), whose unofficial repository hold some updated packages that seems to work very well... Unfortunately I'm working on a 64bit pc with Ubuntu 9.04 and no package for this configuration is available there. I compiled a Grass 6.5 from source but really don't know on how to compile a more recent version of gdal and even don't know exactly wich libraries have to be updated. Some useful suggestion on what to do to make v.in.ogr work correctly with shp files? Thank you in advance. Ferro Jhon Ortiz ha scritto: Hi all. Compiled and installed Grass 6.5 from source on a 64x Ubuntu 9.04 machine. It seemed to me it worked fine but when I tried to import the curvespear shape file (following the step by step tutorial http://www.ing.unitn.it/~grass/docs/tutorial_62/index.html ) by v.in.ogr function, the procedure didn't go on. In the output window: ... Layer: curvespear Importing map 1755 features... and nothing else. The imported file is in the right place but with nearly no feature inside. I'v been looking for a tip in the user mailing list archive but Rafael Moraes suggestion doesn't help. Added http://les-ejk.cz/ubuntu repository to source list and reinstalled gdal... but nothing happend. The same with Grass 6.2.3. (Maybe I made some newbe mistake in updating gdal). Any suggestion? Thank you. Ferro P.S Hi all, I have the same problem when I tried to import the shapefile with v.in.org I'm working with GRASS 6.4.0svn on a 64x Ubuntu 9.04 In the terminal give this errors GRASS 6.4.0svn (Prueba_location):~ *** buffer overflow detected ***: v.in.ogr terminated === Backtrace: = /lib/libc.so.6(__fortify_fail+0x37)[0x7f95d00bc2c7] /lib/libc.so.6[0x7f95d00ba170] /lib/libc.so.6[0x7f95d00b97ab] /lib/libc.so.6(__snprintf_chk+0x7b)[0x7f95d00b967b] /usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature16GetFieldAsStringEi+0x346)[0x7f95d0de2296] v.in.ogr(main+0x2284)[0x406b50] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f95cffdb5a6] v.in.ogr[0x403969] Some advice? Thaks John Ortiz _ Llévate Messenger en el móvil a todas partes ¡Conéctate! http://www.microsoft.com/spain/windowsmobile/messenger/default.mspx ___ 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
Re: [GRASS-user] .e00 to DEM
On Wed, 2009-07-08 at 09:51 -0700, Dylan Beaudette wrote: On Wednesday 08 July 2009, Nikos Alexandris wrote: There is something strange with the values though (they expand from min = -32687 max = 32645). Don't have the time to dig further, maybe there are details in the meta-data about it (!?). This looks like an overflow problem. Could it be that this file contains unsigned 16 / 32 bit integers, but is being read in as signed 16 bit integers? Probably you are right Dylan. In the meta-data it is written: Level 2 DEM: Level 2 DEMs may contain void areas due to interruptions to contours in the source graphic or DLG. Void area elevation grid posts are assigned the value of -32,767. * This means that original data are for sure Signed (probably Int16-bit... ?). * gdal reads the data correctly (look previous post of mine) as: Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined Min=0.000 Max=1371.000 NoData Value=-32768 * grass reports the range of the imported data as: r.info dem250 -tr min=-32687 max=32645 datatype=CELL * The data show up correctly in GRASS: g.region rast=dem250 r.colors dem250 color=terrain d.mon x0 d.rast dem250 If we accept min=-32687 that was assigned to be nodata, what is this max=32645? Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] How does GRASS do tiled processing?
GRASSers: I was curious -- how is tiled processing realized in GRASS GIS? Is there a fixed input tile size (in MB of RAM or # of lines)? Is there some documentation buried on the GRASS site that describes the algorithm? I'm trying to replicate an efficient tiled approach in R -- I was basing it off the ENVI approach (precalculate the input data memory footprint per line of data, read in as many lines as the memory cap allows, process, write those lines, rinse, repeat), but I was curious if GRASS had a different approach. --j -- Jonathan A. Greenberg, PhD Postdoctoral Scholar Center for Spatial Technologies and Remote Sensing (CSTARS) University of California, Davis One Shields Avenue The Barn, Room 250N Davis, CA 95616 Cell: 415-794-5043 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.in.wms failure
Hi, I'm tring to use r.in.wms on mac osx leopard using grass64 (binary version) this the log : GRASS 6.4.0RC5 (lonlat_pg):~ g.region res=30 -ap projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 60N south: 30N west: 0 east: 30E nsres: 30 ewres: 30 rows: 1 cols: 1 cells: 1 GRASS 6.4.0RC5 (lonlat_pg):~ r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.cgi output=wms_global_mosaic Calculating tiles Requesting 1 tiles. Downloading tiles Downloading data 2009-07-08 20:23:14 URL:http://wms.jpl.nasa.gov/wms.cgi [89223] - / Users/Shared/grassdata/wms_download/wms_global_mosaic__0.geotiff [1] All tiles downloaded successfully Creating output file that is 3P x 3L. Processing input file /Users/Shared/grassdata/wms_download/ wms_global_mosaic__0.geotiff. 0...10...20...30...40...50...60...70...80...90...100 - done. WARNING: G_set_window(): Illegal latitude for North ERROR: r.in.gdalwarp: r.in.gdal failure. ERROR: r.in.gdalwarp failed have you any suggestion on how to get it works? thanks! Massimo ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Multiple v.net.path parameters
Hello all, I have finished v.net.distance module as a part of my Google Summer of Code project. The (source code of) module can be downloaded from grass add-ons repository (vector/net.analyze). I recommend to download the entire directory to avoid any compilation issues. Additionally, you get an access to some latest network analysis modules! Anyway, simple make command in the net.analyze directory should compile the modules (and library). There is no documentation (yet), however, the interface should be similar to the one used in v.net.path and/or v.distance. Finally, here is a couple of nice pictures: http://people.ksp.sk/~dano/grass/nd.png http://people.ksp.sk/~dano/grass/ndt.png http://people.ksp.sk/~dano/grass/ndtd.png Blue and orange lines show the shortest length and time paths respectively. Best, Daniel On Wed, Jul 1, 2009 at 5:56 PM, Moritz Lennertmlenn...@club.worldonline.be wrote: On 01/07/09 04:44, J. Holden wrote: Hello, I am looking to use v.net.path to determine the distance of many different points to many different other points on a network. Is it possible to send multiple parameters to v.net.path? For instance, I have (in theory) 4 points connected to a network. I want to find the distance of the line segments between points 1 and 4, 2 and 4, 3 and 4. I want to: run v.net.path once by passing multiple parameters; get vector line output of each of these three paths found by v.net.path in one output file; calculate the distance of each line from the file using v.to.db. Since this is not a module of GRASS which I have worked with in the past, I am wondering if this is possible. Sure, as mentioned on the man page: Nodes can be piped into the program from file or from stdin. The syntax is as follows: id start_point_category end_point_category or id start_point_x start_point_y end_point_x end_point_y So to take your example, and assuming that 1,2,3,4 are category values of existing points: Create a file containing: 1 1 4 2 2 4 3 3 4 and feed it to v.net.path with the file= parameter. You will then get one vector map with severals lines which have the category values used in the first column of your file. Moritz ___ 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
Re: [GRASS-user] How does GRASS do tiled processing?
Milton: Thanks, but I'm more curious in just the generic way GRASS does tiled processing (say, in mapcalc). I assume there is a low-level processing layer GRASS uses (or no?). I'm not doing a direct grass-to-R link, I'm doing the processing completely within R with rgdal, but I'm interested in various solutions to the tiled processing problem. That is a helpful suggestion, tho -- I used a similar approach when I forced r.sun to do tiled processing with a massive lidar image I had -- I ended up setting overlaps between each tile since its a spatial problem. For pure pixel analyses, of course, there's no need to worry about boundaries... --j Milton Cezar Ribeiro wrote: Hi Jonathan, When I need to do tiles processing of grass coupled R, I usually set a list of bounding boxes on R (a list of x1, x2, y1, y2), and then I put it on a for() looping. So, I set a new g.region using n= s= e= and w= parameters using system() function of R (you can do it of other ways). Just after the for() I reset g.region with -d. *but* you need to be very careful with your processing, because some of the results will be influenced by the boundary of new sub-regions. Good luck milton brazil=toronto 2009/7/8 Jonathan Greenberg greenb...@ucdavis.edu mailto:greenb...@ucdavis.edu GRASSers: I was curious -- how is tiled processing realized in GRASS GIS? Is there a fixed input tile size (in MB of RAM or # of lines)? Is there some documentation buried on the GRASS site that describes the algorithm? I'm trying to replicate an efficient tiled approach in R -- I was basing it off the ENVI approach (precalculate the input data memory footprint per line of data, read in as many lines as the memory cap allows, process, write those lines, rinse, repeat), but I was curious if GRASS had a different approach. --j -- Jonathan A. Greenberg, PhD Postdoctoral Scholar Center for Spatial Technologies and Remote Sensing (CSTARS) University of California, Davis One Shields Avenue The Barn, Room 250N Davis, CA 95616 Cell: 415-794-5043 AIM: jgrn307, MSN: jgrn...@hotmail.com mailto:jgrn...@hotmail.com, Gchat: jgrn307 ___ grass-user mailing list grass-user@lists.osgeo.org mailto:grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Jonathan A. Greenberg, PhD Postdoctoral Scholar Center for Spatial Technologies and Remote Sensing (CSTARS) University of California, Davis One Shields Avenue The Barn, Room 250N Davis, CA 95616 Cell: 415-794-5043 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How does GRASS do tiled processing?
Hi Jonathan, When I need to do tiles processing of grass coupled R, I usually set a list of bounding boxes on R (a list of x1, x2, y1, y2), and then I put it on a for() looping. So, I set a new g.region using n= s= e= and w= parameters using system() function of R (you can do it of other ways). Just after the for() I reset g.region with -d. *but* you need to be very careful with your processing, because some of the results will be influenced by the boundary of new sub-regions. Good luck milton brazil=toronto 2009/7/8 Jonathan Greenberg greenb...@ucdavis.edu GRASSers: I was curious -- how is tiled processing realized in GRASS GIS? Is there a fixed input tile size (in MB of RAM or # of lines)? Is there some documentation buried on the GRASS site that describes the algorithm? I'm trying to replicate an efficient tiled approach in R -- I was basing it off the ENVI approach (precalculate the input data memory footprint per line of data, read in as many lines as the memory cap allows, process, write those lines, rinse, repeat), but I was curious if GRASS had a different approach. --j -- Jonathan A. Greenberg, PhD Postdoctoral Scholar Center for Spatial Technologies and Remote Sensing (CSTARS) University of California, Davis One Shields Avenue The Barn, Room 250N Davis, CA 95616 Cell: 415-794-5043 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307 ___ 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
Re: [GRASS-user] .e00 to DEM
On Wednesday 08 July 2009, Nikos Alexandris wrote: On Wed, 2009-07-08 at 09:51 -0700, Dylan Beaudette wrote: On Wednesday 08 July 2009, Nikos Alexandris wrote: There is something strange with the values though (they expand from min = -32687 max = 32645). Don't have the time to dig further, maybe there are details in the meta-data about it (!?). This looks like an overflow problem. Could it be that this file contains unsigned 16 / 32 bit integers, but is being read in as signed 16 bit integers? Probably you are right Dylan. In the meta-data it is written: Level 2 DEM: Level 2 DEMs may contain void areas due to interruptions to contours in the source graphic or DLG. Void area elevation grid posts are assigned the value of -32,767. * This means that original data are for sure Signed (probably Int16-bit... ?). * gdal reads the data correctly (look previous post of mine) as: Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined Min=0.000 Max=1371.000 NoData Value=-32768 * grass reports the range of the imported data as: r.info dem250 -tr min=-32687 max=32645 datatype=CELL * The data show up correctly in GRASS: g.region rast=dem250 r.colors dem250 color=terrain d.mon x0 d.rast dem250 If we accept min=-32687 that was assigned to be nodata, what is this max=32645? Nikos Hi Nikos, Looks like a 16bit signed integer file. I have found that in the past using gdal_translate and manually setting the data type and nodata value results in the generation of a new file that GRASS can read in without further work. Also, have you tried manually setting NULL cells with r.null setnull=32768 Sometimes GRASS isn't notified of the nodata upon importing... Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
Nikos: * gdal reports: Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined Min=0.000 Max=1371.000 NoData Value=-32768 * grass reports: r.info dem250 -tr min=-32687 max=32645 datatype=CELL Did you notice that gdal's NoData Value=-32768 != grass' min=32645 ! = grass' max=32645. It's not a typo of mine. Where are these values (that grass reports) coming from? Dylan: Looks like a 16bit signed integer file. I have found that in the past using gdal_translate and manually setting the data type and nodata value results in the generation of a new file that GRASS can read in without further work. Will try. Also, have you tried manually setting NULL cells with r.null setnull=32768 Does not help unfortunately. Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] shapefile, TIGER, or what for a dlg that is stored in .e00 format
I am trying to make a DEM from contour lines downloaded from here http://csat.er.usgs.gov/statewide/layers/contours.html I converted this to a shape file, reprojected it, and then v.to.rast use=value and got out a raster with a range of 1 to 1. How do I do this? If you require any more information please tell me and I can give it to you. Thanks for any help. Stephen Sefick -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] shapefile, TIGER, or what for a dlg that is stored in .e00 format
stephen sefick wrote: I am trying to make a DEM from contour lines downloaded from here http://csat.er.usgs.gov/statewide/layers/contours.html I converted this to a shape file You don't need to convert it to Shapefile. You can import vector .e00 files directly in GRASS using v.in.e00. Note that you need to have to programs installed: avce00 and e00compr. reprojected it, why? from what to what CRS? Did you not create a location based on the coordinate reference system in which the data are referenced? Did you have any success with the GRID data, if of course you tried? and then v.to.rast use=value and got out a raster with a range of 1 to 1. That is so because the v.to.rast module expects from the user to define the value incase you use the use=value parameter. If the user does not define the value then value=1 is taken as default. Please read the respective manual(s) [1]. I suppose that v.to.rast use=val value=SomeValue is not what you want. Giving a fixed value to all of the vector features that will be rasterized wont be useful if you want to play further with the data (e.g. create a DEM as you mention above). How do I do this? --%---code--%--- # I downloaed the data you mention and did the following: v.in.e00 contours.e00 vect=contours type=line # check attribute table v.info -c contours v.info -c contours Displaying column types/names for database connection of layer 1: INTEGER|cat INTEGER|UserId INTEGER|FNODE_ INTEGER|TNODE_ INTEGER|LPOLY_ INTEGER|RPOLY_ DOUBLE PRECISION|LENGTH INTEGER|CONTOURS_ INTEGER|CONTOURS_I INTEGER|ELEV # match region ## I am unsure about the resolution (=look at the original data resolution from which the contours derived) g.region vect=contours res=SomeResolutionValue -pa # the last column is probably of your interest, so v.to.rast use=val value=attr col=ELEV --%---code--%--- Perhaps you do not even need to rasterise. Have a look at v.surf.rst [2]. Of course I am no expert with DEM's, v.surf.rst might not be what you need. Kind regards, Nikos --- [1] http://grass.osgeo.org/grass64/manuals/html64_user/v.to.rast.html [2] http://grass.osgeo.org/grass64/manuals/html64_user/v.surf.rst.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] shapefile, TIGER, or what for a dlg that is stored in .e00 format
I tried this with points, lines and areas on the .e00 file v.in.e00 'file=/Users/sefick/Desktop/contours Folder/contours.e00' type=area vect=georgia_contours --overwrite importing areas.. unable to open data source cont an error occured. Stop. what now? I didn't have any luck with the grid data - tried and gave up. thanks Stephen Sefick On Wed, Jul 8, 2009 at 7:38 PM, Nikos Alexandrisnikos.alexand...@felis.uni-freiburg.de wrote: stephen sefick wrote: I am trying to make a DEM from contour lines downloaded from here http://csat.er.usgs.gov/statewide/layers/contours.html I converted this to a shape file You don't need to convert it to Shapefile. You can import vector .e00 files directly in GRASS using v.in.e00. Note that you need to have to programs installed: avce00 and e00compr. reprojected it, why? from what to what CRS? Did you not create a location based on the coordinate reference system in which the data are referenced? Did you have any success with the GRID data, if of course you tried? and then v.to.rast use=value and got out a raster with a range of 1 to 1. That is so because the v.to.rast module expects from the user to define the value incase you use the use=value parameter. If the user does not define the value then value=1 is taken as default. Please read the respective manual(s) [1]. I suppose that v.to.rast use=val value=SomeValue is not what you want. Giving a fixed value to all of the vector features that will be rasterized wont be useful if you want to play further with the data (e.g. create a DEM as you mention above). How do I do this? --%---code--%--- # I downloaed the data you mention and did the following: v.in.e00 contours.e00 vect=contours type=line # check attribute table v.info -c contours v.info -c contours Displaying column types/names for database connection of layer 1: INTEGER|cat INTEGER|UserId INTEGER|FNODE_ INTEGER|TNODE_ INTEGER|LPOLY_ INTEGER|RPOLY_ DOUBLE PRECISION|LENGTH INTEGER|CONTOURS_ INTEGER|CONTOURS_I INTEGER|ELEV # match region ## I am unsure about the resolution (=look at the original data resolution from which the contours derived) g.region vect=contours res=SomeResolutionValue -pa # the last column is probably of your interest, so v.to.rast use=val value=attr col=ELEV --%---code--%--- Perhaps you do not even need to rasterise. Have a look at v.surf.rst [2]. Of course I am no expert with DEM's, v.surf.rst might not be what you need. Kind regards, Nikos --- [1] http://grass.osgeo.org/grass64/manuals/html64_user/v.to.rast.html [2] http://grass.osgeo.org/grass64/manuals/html64_user/v.surf.rst.html -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] shapefile, TIGER, or what for a dlg that is stored in .e00 format
Hi, Do you need to use this data for the generation of a DEM? Would it be possible to use another source? seamless.usgs.gov is a great place to get gridded elevation data for the USA. Interpolating from contours should be a last resort. Cheers, Dylan On Wed, Jul 8, 2009 at 6:42 PM, stephen sefickssef...@gmail.com wrote: I tried this with points, lines and areas on the .e00 file v.in.e00 'file=/Users/sefick/Desktop/contours Folder/contours.e00' type=area vect=georgia_contours --overwrite importing areas.. unable to open data source cont an error occured. Stop. what now? I didn't have any luck with the grid data - tried and gave up. thanks Stephen Sefick On Wed, Jul 8, 2009 at 7:38 PM, Nikos Alexandrisnikos.alexand...@felis.uni-freiburg.de wrote: stephen sefick wrote: I am trying to make a DEM from contour lines downloaded from here http://csat.er.usgs.gov/statewide/layers/contours.html I converted this to a shape file You don't need to convert it to Shapefile. You can import vector .e00 files directly in GRASS using v.in.e00. Note that you need to have to programs installed: avce00 and e00compr. reprojected it, why? from what to what CRS? Did you not create a location based on the coordinate reference system in which the data are referenced? Did you have any success with the GRID data, if of course you tried? and then v.to.rast use=value and got out a raster with a range of 1 to 1. That is so because the v.to.rast module expects from the user to define the value incase you use the use=value parameter. If the user does not define the value then value=1 is taken as default. Please read the respective manual(s) [1]. I suppose that v.to.rast use=val value=SomeValue is not what you want. Giving a fixed value to all of the vector features that will be rasterized wont be useful if you want to play further with the data (e.g. create a DEM as you mention above). How do I do this? --%---code--%--- # I downloaed the data you mention and did the following: v.in.e00 contours.e00 vect=contours type=line # check attribute table v.info -c contours v.info -c contours Displaying column types/names for database connection of layer 1: INTEGER|cat INTEGER|UserId INTEGER|FNODE_ INTEGER|TNODE_ INTEGER|LPOLY_ INTEGER|RPOLY_ DOUBLE PRECISION|LENGTH INTEGER|CONTOURS_ INTEGER|CONTOURS_I INTEGER|ELEV # match region ## I am unsure about the resolution (=look at the original data resolution from which the contours derived) g.region vect=contours res=SomeResolutionValue -pa # the last column is probably of your interest, so v.to.rast use=val value=attr col=ELEV --%---code--%--- Perhaps you do not even need to rasterise. Have a look at v.surf.rst [2]. Of course I am no expert with DEM's, v.surf.rst might not be what you need. Kind regards, Nikos --- [1] http://grass.osgeo.org/grass64/manuals/html64_user/v.to.rast.html [2] http://grass.osgeo.org/grass64/manuals/html64_user/v.surf.rst.html -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ 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
Re: [GRASS-user] shapefile, TIGER, or what for a dlg that is stored in .e00 format
stephen sefick wrote: I am trying to make a DEM from contour lines downloaded from here http://csat.er.usgs.gov/statewide/layers/contours.html fwiw, v.in.ogr's SDTS driver might help to import DLGs more directly. ?? Nikos wrote: Perhaps you do not even need to rasterise. Have a look at v.surf.rst [2]. Of course I am no expert with DEM's, v.surf.rst might not be what you need. v.surf.rst does not do all that well with contour lines. due to the adaptive grid size / quadtree design it focuses detail on where the data points are. In this case that's the vertices along the contour lines. r.surf.contour does a nice job with them though, just read in the help page about overcoming the lack of floating-point support, if that is needed. also, as mentioned there is probably a higher resolution DEM already out there for free, e.g. SRTM 1 (~30m) resolution or USGS quads. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems with v.in.ogr importing shp files
Ferruccio Sarra wrote: I'm working on a 64bit pc with Ubuntu 9.04 and no package for this configuration is available there. I compiled a Grass 6.5 from source but really don't know on how to compile a more recent version of gdal and even don't know exactly wich libraries have to be updated. I would suggest to rebuilt from source the DebianGIS packages found in Debian/experimental. search the web for instructions on how to use debuild, and see the instructions for GRASS in the grass SVN source code debian/ dir. Some useful suggestion on what to do to make v.in.ogr work correctly with shp files? well, it's really a matter of getting v.in.ogr to work at all! after rebuilding and reinstalling GDAL you will want to 'make distclean' and rebuild GRASS completely too. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
