Re: [GRASS-user] v.patch and r.patch fails to execute in GIS manager and command line (WinGRASS 6.3 - Vista)
On Jan 5, 2009, at 10:00 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Sun, 4 Jan 2009 17:00:47 -0800 (PST) From: Kenneth Brookes ken_broo...@hotmail.com Subject: [GRASS-user] v.patch and r.patch fails to execute in GIS manager and command line (WinGRASS 6.3 - Vista) To: grass-user@lists.osgeo.org Message-ID: 1231117247961-2111065.p...@n2.nabble.com Content-Type: text/plain; charset=us-ascii Hello I've run into a problem trying to use v.patch and r.patch. I've tried through the GIS manager GUI and the command line shell and get a window pop-up saying Couldn't execute 'v.patch': invalide argument. I've tried to use this to combine several files of the same data format with no luck. Anybody have any idea what the problem might be. Thanks K. Brookes -- View this message in context: http://n2.nabble.com/v.patch-and-r.patch-fails-to-execute-in-GIS-manager-and-command-line-%28WinGRASS-6.3---Vista%29-tp2111065p2111065.html Sent from the Grass - Users mailing list archive at Nabble.com. This is a Vista issue. My students had the same problem on Vista but not on XP. I thought that these were fixed in winGRASS some time back. Can someone confirm if this is an out of date binary or something else? Thanks Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: Re: [GRASS-user] Re: GRASS-user] Help with reprojection (Hamish)
On Jan 5, 2009, at 10:00 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Mon, 5 Jan 2009 11:46:54 +0100 From: Markus Neteler nete...@osgeo.org Subject: Re: [GRASS-user] Re: GRASS-user] Help with reprojection (Hamish) To: Alex Bernstein pofi...@gmail.com Cc: GRASS user list grass-user@lists.osgeo.org, rchirg...@ozemail.com.au Message-ID: 86782b610901050246w125f196u440c04a12635d...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 5, 2009 at 11:11 AM, Alex Bernstein pofi...@gmail.com wrote: Thanks everyone for trying to help. A few hours ago, I've finally accomplished what I needed by using gdalwarp directly. I had some trouble with it as well, because it couldn't handle the reprojection of a global image. There is a ticket open for that: http://trac.osgeo.org/gdal/ticket/2305 To communicate interest, please add yourself in CC to the ticket. But once I limited it to the region of interest, it worked, Good to know. Independently, import and reprojection (r.proj which differs from gdalwarp) should work. Markus Echoing Markus, gdalwarp georegisters the map. This works fine obviously. You could also use the GRASS georegister module. Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.patch and r.patch fails to execute in GIS manager and command line (WinGRASS 6.3 - Vista)
On Mon, Jan 5, 2009 at 7:48 PM, Michael Barton michael.bar...@asu.edu wrote: From: Kenneth Brookes ken_broo...@hotmail.com ... This is a Vista issue. My students had the same problem on Vista but not on XP. I thought that these were fixed in winGRASS some time back. Can someone confirm if this is an out of date binary or something else? Well, we desperately need a GRASS 6.4.0RC1 built for Windows. Any volunteer here to compile and package it? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: GRASS-user] Help with reprojection (Hamish)
Thanks everyone for trying to help. A few hours ago, I've finally accomplished what I needed by using gdalwarp directly. I had some trouble with it as well, because it couldn't handle the reprojection of a global image. But once I limited it to the region of interest, it worked, Thanks again, --Alex ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: GRASS-user] Help with reprojection (Hamish)
On Mon, Jan 5, 2009 at 11:11 AM, Alex Bernstein pofi...@gmail.com wrote: Thanks everyone for trying to help. A few hours ago, I've finally accomplished what I needed by using gdalwarp directly. I had some trouble with it as well, because it couldn't handle the reprojection of a global image. There is a ticket open for that: http://trac.osgeo.org/gdal/ticket/2305 To communicate interest, please add yourself in CC to the ticket. But once I limited it to the region of interest, it worked, Good to know. Independently, import and reprojection (r.proj which differs from gdalwarp) should work. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Finding Nearest Intersection (point) on Road Network
Moritz Lennert wrote: Thanks for the reply. Sorry for the delay...out of town. On Wed, December 24, 2008 05:55, Ryan R. Rosario wrote: GRASS simply returns the same point back, since the closest node to A is A. In grass6.4 you have the dmin option to avoid that. That is good to know. Apparently it is not in the tcl/tk GUI. If I use patch first, then the from and to maps in v.distance must be the same, unless I am misunderstanding something. That is correct. The vector map containing the intersections (the set of points B) contains both points (created using v.net nodes) and lines (the original road network). I can get the nearest point using v.distance, but this uses straight-line distance, not the distance along the road. Although v.distance offers the to_along option, there does not appear to be anywhere to specify which vector contains the road network. IIUC, to_along works if your from_map is a point map and your to_map is a line map. And it seems that v.net.path requires that both the start and end points must be known a priori, and I only have the start point. I am trying to find the end point (the nearest intersection). I am stuck, but I think I am missing something important here. As a reminder, here's your original question: I have two vector maps consisting of points and a vector map containing a road network. Given a point A, I want to find the nearest point B along the road network, for each A. There is a definite need for a v.net.distance, i.e. a v.distance on a network. Maybe you could file a wish for that on trac. Will do. I am glad you mentioned this. I suspected that what I was attempting was not easy, or not yet possible, but kept chasing my tail. Here's an algorithm I imagine could help you get closer to an answer (untested): - Use v.net.iso on your road network with one point A as starting point setting costs to a sufficiently fine-grained resolution of distances. - Run v.distance with from_map=B to_map=VNetIsoOutput upload=cat - Find point in B with lowest cat (through SQL query on the attribute table) I will try this. Quite convulted, but might work, depending on the number of points and the complexity of your road network. Note that currently the v.net.* modules in GRASS do not work very well, and hardly at all once the network becomes too big. Rewriting these modules to be more scalable and reliable would be a nice Google Summer of Code project for next year. That would be excellent. Now that I know this, I might take a look at the code, as what I am trying to do relates to my dissertation. R. -- View this message in context: http://n2.nabble.com/Finding-Nearest-Intersection-%28point%29-on-Road-Network-tp1886245p2114512.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
World File problem (was Re: [GRASS-user] Re: GRASS-user] Help with reprojection (Hamish))
Markus Neteler wrote: On Mon, Jan 5, 2009 at 6:37 AM, rchirg...@ozemail.com.au rchirg...@ozemail.com.au wrote: Date: Sat, 3 Jan 2009 13:25:31 -0800 (PST) From: Hamish hamis...@yahoo.com Hamish wrote: - create a simple xy location (lat/lon location will not allow north 90, and your image while still not geo-referenced will go to 8100) - run r.region to set n,s,e,w bounds to 90,-90,180,-180 - run g.setproj to rejig the location into a lat/lon one. umm, that might not work -- r.info will still know the map is XY even if the location is changed to lat/lon. - check resolution is correct (nicely 0:01:20) with r.info. - zoom to area of interest. you probably do not want to reproject entire planet. after zooming check resolution is preserved, (g.region -p, maybe with g.region res=0:01:20 -a after zoom to fix) and run r.mapcalc cropmap=fullmap to perform the crop. then from the lambert location run r.proj to pull the cropped image across. there are some examples of this process in the GRASS wiki, look at the Global datasets page. the above issue should be covered there; also check the mailing list archives. so your easiest solution is to create a world file. see the GDAL JPG or GeoTiff format import page, or do a web search for instructions. Grass-6.3.0 under Mac doesn't seem to be checking for the world file. My test: 1) Export a raster using r.out.tiff with the create world file box checked 2) Check the output folder: test.tiff test.tfw 3) Import using r.in.gdal: r.in.gdal input=test.tiff output=test_2 In mine, this produces a projection mismatch error - which seems to tell me that Grass isn't noticing the tfw file. We would need more details to better understand the problem. What does gdalinfo report on the file? (GRASS calls GDAL to read the files). Markus Markus, Here's a sample gdalinfo output: Driver: GTiff/GeoTIFF Files: Tiff_Test.tif Size is 4838, 3781 Coordinate System is `' Origin = (150.34586944001,-33.59935522000) Pixel Size = (0.0278000,-0.0278000) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 150.3458694, -33.5993552) Lower Left ( 150.3458694, -33.6098664) Upper Right ( 150.3593191, -33.5993552) Lower Right ( 150.3593191, -33.6098664) Center ( 150.3525943, -33.6046108) Band 1 Block=4838x1 Type=Byte, ColorInterp=Red Band 2 Block=4838x1 Type=Byte, ColorInterp=Green Band 3 Block=4838x1 Type=Byte, ColorInterp=Blue The world file: 0.0278000 0.000 0.000 -0.0278000 150.34587082996 -33.59935661001 This file and the world file are the only items in the folder, and were created by r.out.tiff from a raster in a working location. ERROR: Projection of dataset does not appear to match current location. Location PROJ_INFO is: name: Lat/Lon proj: ll datum: wgs84 ellps: wgs84 no_defs: defined Import dataset PROJ_INFO is: cellhd.proj = 0 (unreferenced/unknown) Cheers, Richard ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: World File problem (was Re: [GRASS-user] Re: GRASS-user] Help with reprojection (Hamish))
Richard, On Mon, Jan 5, 2009 at 8:55 PM, Richard Chirgwin rchirg...@ozemail.com.au wrote: ... Grass-6.3.0 under Mac doesn't seem to be checking for the world file. It does - see below: My test: 1) Export a raster using r.out.tiff with the create world file box checked 2) Check the output folder: test.tiff test.tfw 3) Import using r.in.gdal: r.in.gdal input=test.tiff output=test_2 In mine, this produces a projection mismatch error - which seems to tell me that Grass isn't noticing the tfw file. No, that's not the message :) See below: ... Here's a sample gdalinfo output: Driver: GTiff/GeoTIFF Files: Tiff_Test.tif Size is 4838, 3781 Coordinate System is `' - the Coordinate System is (naturally) missing. Why? Because in the .tfw file it is not stored. It might be an additional .prj file (not sure if GDAL would recognize that, maybe yes). ... The world file: 0.0278000 0.000 0.000 -0.0278000 150.34587082996 -33.59935661001 This file and the world file are the only items in the folder, and were created by r.out.tiff from a raster in a working location. Right. ERROR: Projection of dataset does not appear to match current location. Correct message because GRASS/GDAL cannot guess the projection of the TIFF (since it is not specified). Location PROJ_INFO is: name: Lat/Lon proj: ll datum: wgs84 ellps: wgs84 no_defs: defined Import dataset PROJ_INFO is: cellhd.proj = 0 (unreferenced/unknown) GRASS is right: the PROJ_INFO is undefined. Just a human will recognize that it may be LatLong. Solution: use r.in.gdal -o to disable the test and import into a location with correct projection. Then the map will be placed correctly. Cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Problems with compiling addon r.uslek
Hi list members, I tried to compile a GRASS Addon called r.uslek. I compiled a fresh svn checkout of GRASS 6.4 and downloaded afterwards the addon code and put into a subfolder of the svn source code. With the following statement I get the error beneath... I never did this procedure before. I have the workflow from the WIKI (http://grass.osgeo.org/wiki/Compile_and_Install#Addons - last point) Any ideas? Thanks in advance, Christian cbr...@ubuntu:/usr/local/src/grass_64_svn/addons/r.uslek$ sudo make MODULE_TOPDIR=/usr/local/src/grass_64_svn/ mkdir -p @GRASS_HOME@/b...@host@ mkdir -p @GRASS_HOME@/di...@host@/include/grass mkdir -p @GRASS_HOME@/di...@host@/lib mkdir -p @GRASS_HOME@/di...@host@/bin mkdir -p @GRASS_HOME@/di...@host@/etc mkdir -p @GRASS_HOME@/di...@host@/driver mkdir -p @GRASS_HOME@/di...@host@/driver/db mkdir -p @GRASS_HOME@/di...@host@/fonts test -d o...@host@ || mkdir -p o...@host@ /bin/sh: CC@: not found make: *** [o...@host@/main.o] Error 127 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass' build problem with libtoolize
Hi,
I'm trying to build grass 6.4 rc1 from sources (using the tarball
available) but I get this blocking error :
libtoolize: cannot handle variables in AC_CONFIG_AUX_DIR
Here is the complete log -
http://pastebin.mandriva.com/5505
I've searched but the only part I've been able to understand so far is
that it is somewhat linked to the configure file so there is the options
I used :
--with-dbm-includes=%{_includedir}/gdbm/
--with-postgres-includes='%{_includedir}/postgresql
%{_includedir}/postgresql/internal' --with-freetype
--with-freetype-includes=%{_includedir}/freetype2 --with-motif
--with-opengl-libs=%{_prefix}/X11R6/%{_lib}
--with-motif-includes=%{_prefix}/X11R6/include --with-gdal
--with-odbc --enable-largefile --with-ffmpeg
--with-curses --with-python --with-sqlite \
--with-cxx --with-proj-share=%{_datadir}/proj \
--with-nls --with-wxwidgets=%{_libdir}/wxPython/bin/wx-config
I'm using mandriva cooker/libtool 1.5.26/gcc 4.3.2
Regards,
MORREALE JR
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.dxf lines with no elevation
I have a dxf file that contains both lines and points. If I import it into grass with v.in.dxf the lines end up at an elevation of 0, while the points show up correctly. I have verified that the lines do in fact have an elevation by importing the dxf both into google sketch up and blender as a test. I googled around some and it seems like it used to be necessary to run v.in.dxf3d but I can't find that, and it appears that it was just incorporated into v.in.dxf, best I can tell. Any suggestions for getting the lines to the correct elevation? Thanks, --Adam ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.dxf lines with no elevation
On Jan 5, 2009, at 6:02 PM, Adam Dershowitz wrote: I have a dxf file that contains both lines and points. If I import it into grass with v.in.dxf the lines end up at an elevation of 0, while the points show up correctly. I have verified that the lines do in fact have an elevation by importing the dxf both into google sketch up and blender as a test. I googled around some and it seems like it used to be necessary to run v.in.dxf3d but I can't find that, and it appears that it was just incorporated into v.in.dxf, best I can tell. Any suggestions for getting the lines to the correct elevation? Thanks, --Adam Also, when I do the import I get a warning 3-d data in dxf file ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.dxf lines with no elevation
Hi Adam, Can I take a look at the dxf file you tried? Thanks. Huidae On Mon, Jan 05, 2009 at 06:02:54PM -0800, Adam Dershowitz wrote: I have a dxf file that contains both lines and points. If I import it into grass with v.in.dxf the lines end up at an elevation of 0, while the points show up correctly. I have verified that the lines do in fact have an elevation by importing the dxf both into google sketch up and blender as a test. I googled around some and it seems like it used to be necessary to run v.in.dxf3d but I can't find that, and it appears that it was just incorporated into v.in.dxf, best I can tell. Any suggestions for getting the lines to the correct elevation? Thanks, --Adam ___ 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] grass' build problem with libtoolize
On Mon, Jan 5, 2009 at 11:00 PM, MORREALE Jean Roc
jr.morre...@enoreth.net wrote:
Hi,
I'm trying to build grass 6.4 rc1 from sources (using the tarball available)
but I get this blocking error :
libtoolize: cannot handle variables in AC_CONFIG_AUX_DIR
Please post the configure parameters/flags for inspection.
Here is the complete log -
http://pastebin.mandriva.com/5505
I've searched but the only part I've been able to understand so far is that
it is somewhat linked to the configure file so there is the options I used :
--with-dbm-includes=%{_includedir}/gdbm/
--with-postgres-includes='%{_includedir}/postgresql
%{_includedir}/postgresql/internal' --with-freetype
--with-freetype-includes=%{_includedir}/freetype2 --with-motif
--with-opengl-libs=%{_prefix}/X11R6/%{_lib}
--with-motif-includes=%{_prefix}/X11R6/include --with-gdal --with-odbc
--enable-largefile --with-ffmpeg
--with-curses --with-python --with-sqlite \
--with-cxx --with-proj-share=%{_datadir}/proj \
--with-nls --with-wxwidgets=%{_libdir}/wxPython/bin/wx-config
Apparently you are trying to create a RPM file? Please point
us to the SPEC file (note that the tarball contains
rpm/mandriva/grass*.spec
See also
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/grass/current/
I'm using mandriva cooker/libtool 1.5.26/gcc 4.3.2
I am using Mandriva 2009.0 and have no problems.
But libtool isn't used/usable for GRASS, probably that's the
source of the problem. We need to know more specifically
what you plan to do.
Best
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
