Re: [GRASS-user] Tips for setting up an new FOSS-GEO-linux-box
On Wed, Oct 29, 2008 at 3:08 PM, Nikos Alexandris [EMAIL PROTECTED] wrote: Filesystems: Which filesystem is better(=safer/faster) for data storage? Is there any important advantage to choose XFS for example rather than ext3? I am using ext3 (wth 4k block size) for a long time. Partitions: Do you keep your geo-data in a separate partition? I have a directory for all original geodata files and one for grassdata/. Both are exported and shared through NFS, so that the team members can easily access from their machines. While the geodata/ directory is read-only (to avoid that elaborated data creep into the original files), the grassdata/ directory is write enabled. Like this, thanks to the concept of GRASS data management, we can all work in the same locations (but personal mapsets). Markus (who looks forward to the Wiki page on this topic :) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with executing some type od queries (with regular expresion parser)
Hello Jarek, please re-run Your gis.m with DEBUG=3 g.gisenv set=DEBUG=3 then redraw map and look into output pane for line: D3/3: db_select_int() D3/3: SQL: SELECT cat FROM ... and post result here. Ignore other error messages, that will popup. Maris. 2008/10/29, Jarek Jasiewicz [EMAIL PROTECTED]: Hi Well, I thing I expect too much, but for now grass has been suprising me (positively) on cooperation GRASS - POstgreSQL I have a query which works well in PgAdmin: SELECT cat FROM streams_coor WHERE link::text IN( SELECT regexp_split_to_table( (SELECT branch FROM links WHERE keyid='168'), E'\\.')) the branch looks like this: 89.88.166.169.168 and result are: 148 150 161 168 157 If I try to use this query in gis.m use sql query field with proper SQL syntax link::text IN( SELECT regexp_split_to_table(( SELECT branch FROM links WHERE keyid='168'), E'\\.')) do not receive any error but also any result so where is problem? As far as I know GRASS simply send query to database and recive list of cats as a result, so there could be the problem with parsing quotemarks and escape marks in regular expresion? regards Jarek ___ 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] using grass on rasters without converting?
Hello Grass World, As a long time GIS user I've dipped into grass from time to time but never in depth. One of the things that's deterred me is the fact that I have a large body of data I work with (tens of gigabytes) and the prospect of having to convert into grass, process it, and then flip it back out again is unappealing. I respect the fact that the grass storage format allow it to do things not possible otherwise. Is there any program available, or a project in the works, for easy in-and-out conversion? or better yet, a method to use grass commands on external formats like geotiff without conversion? Is this a possibility in future or is the structure of grass such that it will just never work? I'd love to be able to be able to do the likes of r.shaded.relief input=mydem.tif output=myshade.tif thanks, -matt -- View this message in context: http://www.nabble.com/using-grass-on-rasters-without-converting--tp20245591p20245591.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] using grass on rasters without converting?
Hi Matt, On Thu, Oct 30, 2008 at 1:07 PM, matt wilkie [EMAIL PROTECTED] wrote: Hello Grass World, As a long time GIS user I've dipped into grass from time to time but never in depth. One of the things that's deterred me is the fact that I have a large body of data I work with (tens of gigabytes) and the prospect of having to convert into grass, process it, and then flip it back out again is unappealing. Sure - also for us :) But it has been solved recently: r.external - Link GDAL supported raster file to a binary raster map layer. http://grass.osgeo.org/grass64/manuals/html64_user/r.external.html ... I'd love to be able to be able to do the likes of r.shaded.relief input=mydem.tif output=myshade.tif Yes, you can do that from 6.4.svn onwards: r.external [-r] in=/path/to/mydem.tif out=mydem g.region rast=mydem -p r.shaded.relief input=mydem shadedmap=myshade r.out.gdal myshade out=myshade.tif For r.out.gdal, check which format is appropriate to keep the color table if desired. Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
Markus Neteler wrote: Hi Matt, On Thu, Oct 30, 2008 at 1:07 PM, matt wilkie [EMAIL PROTECTED] wrote: Hello Grass World, As a long time GIS user I've dipped into grass from time to time but never in depth. One of the things that's deterred me is the fact that I have a large body of data I work with (tens of gigabytes) and the prospect of having to convert into grass, process it, and then flip it back out again is unappealing. Sure - also for us :) But it has been solved recently: r.external - Link GDAL supported raster file to a binary raster map layer. http://grass.osgeo.org/grass64/manuals/html64_user/r.external.html This solves a need for me too. Could something like that be done for WMS services, i.e. not downloading them with r.in.wms, but linking them without making a local copy? Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
As a long time GIS user I've dipped into grass from time to time but never in depth. One of the things that's deterred me is the fact that I have a large body of data I work with (tens of gigabytes) and the prospect of having to convert into grass, process it, and then flip it back out again is unappealing. Sure - also for us :) But it has been solved recently: r.external - Link GDAL supported raster file to a binary raster map layer. http://grass.osgeo.org/grass64/manuals/html64_user/r.external.html Awesome! Thanks Markus (for letting me know) and everyone who worked r.external. :) -- -matt ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
On Thu, Oct 30, 2008 at 2:08 PM, Jan Hartmann [EMAIL PROTECTED] wrote:
Markus Neteler wrote:
r.external - Link GDAL supported raster file to a binary raster map layer.
http://grass.osgeo.org/grass64/manuals/html64_user/r.external.html
This solves a need for me too. Could something like that be done for WMS
services, i.e. not downloading them with r.in.wms, but linking them without
making a local copy?
In theory, r.external might also accept WMS since GDAL does it:
http://www.gdal.org/frmt_wms.html
cat gdal_wms.xml
GDAL_WMS
Service name=WMS
Version1.1.1/Version
ServerUrlhttp://onearth.jpl.nasa.gov/wms.cgi?/ServerUrl
SRSEPSG:4326/SRS
ImageFormatimage/jpeg/ImageFormat
Layersmodis,global_mosaic/Layers
Styles/Styles
/Service
DataWindow
UpperLeftX-180.0/UpperLeftX
UpperLeftY90.0/UpperLeftY
LowerRightX180.0/LowerRightX
LowerRightY-90.0/LowerRightY
SizeX266/SizeX
SizeY133/SizeY
/DataWindow
ProjectionEPSG:4326/Projection
BandsCount3/BandsCount
/GDAL_WMS
# this works:
qgis gdal_wms.xml
# this, too:
r.external /tmp/gdal_wms.xml out=gdal_wms
g.region n=90 s=-90 w=-180 e=180 res=1 -p
d.mon x0
d.rast gdal_wms
# this gets stuck:
d.rast gdal_wms
0%
strace shows
...
select(8, [6 7], [], [], {0, 10}) = 0 (Timeout)
poll([{fd=6, events=POLLIN|POLLPRI}], 1, 0) = 0
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 0) = 0
select(8, [6 7], [], [], {0, 10}) = 0 (Timeout)
...
Maybe some update magic is needed internally (but maybe
I am exaggerating right now...).
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4 and Ubuntu Intrepid
LiangXu Wang wrote: Maybe affected by this bug: https://bugs.launchpad.net/ubuntu/+source/gdal/+bug/271670 https://bugs.launchpad.net/ubuntu/+source/gdal/+bug/284910 GDAL can not compiled in ubuntu intrepid, I have no idea about this, but if you deactivate the ruby and python bindings, it should be compiled. I did more testing about this problem, and I discovered this: - No, I haven't more then 1 version of GDAL or GRASS in my system - 6.4.0 and 6.2.3 report those errors while building: Errors in: /usr/src/grass-6.2.3/raster/r.drain /usr/src/grass-6.2.3/raster/r.fill.dir /usr/src/grass-6.2.3/raster/r.terraflow I'll repeat the test using an older GDAL, and let you know. Thanks Luca -- View this message in context: http://www.nabble.com/GRASS-6.4-and-Ubuntu-Intrepid-tp20222308p20247720.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] GRASS 6.4 and Ubuntu Intrepid
Casagrande Luca wrote: LiangXu Wang wrote: Maybe affected by this bug: https://bugs.launchpad.net/ubuntu/+source/gdal/+bug/271670 https://bugs.launchpad.net/ubuntu/+source/gdal/+bug/284910 GDAL can not compiled in ubuntu intrepid, I have no idea about this, but if you deactivate the ruby and python bindings, it should be compiled. I did more testing about this problem, and I discovered this: - No, I haven't more then 1 version of GDAL or GRASS in my system - 6.4.0 and 6.2.3 report those errors while building: Errors in: /usr/src/grass-6.2.3/raster/r.drain /usr/src/grass-6.2.3/raster/r.fill.dir /usr/src/grass-6.2.3/raster/r.terraflow I'll repeat the test using an older GDAL, and let you know. Thanks Luca Update: With Gdal 1.6.0beta v.in.ogr prompt no error and GRASS seem working fine, but the troubles with: /usr/src/grass-6.2.3/raster/r.drain /usr/src/grass-6.2.3/raster/r.fill.dir /usr/src/grass-6.2.3/raster/r.terraflow during make remains the same. Hope this will help someone. Bye Luca -- View this message in context: http://www.nabble.com/GRASS-6.4-and-Ubuntu-Intrepid-tp20222308p20248706.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
[GRASS-user] Road Extraction from HRI
Hi all, I'm trying to extract a urban road network from Quickbird imagery. The first question is: did someone already something similar? is it really possible? Now the technical questions: I have the RGB and NIR with 2.4 m spatial resolution and PAN with 0.6 m spatial resolution. I followed this procedure: - i.group to make a group with the RGB imagery - make classes by digitizing polygons to identify the probably road and no-road pixels - i.gensingset to make the statistic and produce the signature file - i.smap to classify - r.mapcalc to extract the road class First problem: with this method I can extract the roads (approximately...) but I get many pixel too which are not road. I would need to made a structural classification too. Maybe I should use r.texture but I don't know exactly how. Second problem: when I get finally a good classification, a simple r.thin and r.to.vect would not be enough because the pixel are not all close and precise on the lines, but are scattered along the line, so I don't get a line but many little disordered lines along the road. Is there a way to get a single and straight vector line in this conditions? regards, tommaso ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] GRASS 6.4 and Ubuntu Intrepid
I did more testing about this problem, and I discovered this: - No, I haven't more then 1 version of GDAL or GRASS in my system - 6.4.0 and 6.2.3 report those errors while building: Errors in: /usr/src/grass-6.2.3/raster/r.drain /usr/src/grass-6.2.3/raster/r.fill.dir /usr/src/grass-6.2.3/raster/r.terraflow I'll repeat the test using an older GDAL, and let you know. Thanks Luca I can confirm the same errors. I'm using a clean installation of 8.10, with all Grass dependencies installed through Synaptic. (gdal 1.5.2, Grass 6.4 and 7svn installed). Output from error.log: GRASS GIS compilation log - Started compilation: Thu Oct 30 09:48:55 ADT 2008 -- Errors in: /usr/local/grass6_devel/gui/wxpython/vdigit /usr/local/grass6_devel/raster/r.drain /usr/local/grass6_devel/raster/r.fill.dir -- In case of errors please change into the directory with error and run 'make'. If you get multiple errors, you need to deal with them in the order they appear in the error log. If you get an error building a library, you will also get errors from anything which uses the library. -- Finished compilation: Thu Oct 30 09:56:17 ADT 2008 The error with v.digit is related to the fact that it is not picking up the self-installed wxwidgets package that I had to fetch. The default wxwidgets version the ships with Ubuntu 8.10 is only version 2.6.3. ~ Eric. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] using grass on rasters without converting?
Is there any program available, or a project in the works, for easy in-and-out conversion? or better yet, a method to use grass commands on external formats like geotiff without conversion? Have a look at r.external: http://grass.itc.it/grass64/manuals/html64_user/r.external.html ~ Eric. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] newbie: problems with i.landsat.toar grass addon using suse 10.2 and grass 6.3
On Tue, Oct 21, 2008 at 11:54 PM, andrew haywood [EMAIL PROTECTED] wrote: Dear List, Im running grass 6.3 on suse 10.2. I have installed the latest version from the geo repository. I am now having problems trying to install i.landsat.toar I have checked out the most recent version of grass addons. Im getting the following error. I am a complete novice when it comes to make. The gis.h file is in /opt/grass/include/grass and somehow make isnt finding it. Any help would be greatly appreciated. regards Andy make MODULE_TOPDIR=/opt/grass test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p OBJ.x86_64-unknown-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/earth_sun.o -c earth_sun.c gcc -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/landsat.o -c landsat.c landsat.c:4:23: error: grass/gis.h: No such file or directory make: *** [OBJ.x86_64-unknown-linux-gnu/landsat.o] Error 1 did you ./configure GRASS? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with executing some type od queries (with regular expresion parser)
As you wish: D3/3: db_select_int() D3/3: SQL: SELECT cat FROM streams_coor WHERE link::text IN(SELECT regexp_split_to_table((SELECT branch FROM links WHERE keyid='168'), E'\\.')) D3/3: Escaped SQL: SELECT cat FROM streams_coor WHERE link::text IN(SELECT regexp_split_to_table((SELECT branch FROM links WHERE keyid='168'), E'.')) D3/3: describe_table() As we see, there is a problem with escape \ backslash grass (I don't know gis.m or db_select_int()) adds backslash before. In pgAdmin I must add escape character manually as in example in post before. In gis.m this command should look like: link::text IN( SELECT regexp_split_to_table(( SELECT branch FROM links WHERE keyid='168'), E'\.')) And everythik is OK. Porblem solved. thank you very much for your hint. It was very helpful. Jarek Maris Nartiss pisze: Hello Jarek, please re-run Your gis.m with DEBUG=3 g.gisenv set=DEBUG=3 then redraw map and look into output pane for line: D3/3: db_select_int() D3/3: SQL: SELECT cat FROM ... and post result here. Ignore other error messages, that will popup. Maris. 2008/10/29, Jarek Jasiewicz [EMAIL PROTECTED]: Hi Well, I thing I expect too much, but for now grass has been suprising me (positively) on cooperation GRASS - POstgreSQL I have a query which works well in PgAdmin: SELECT cat FROM streams_coor WHERE link::text IN( SELECT regexp_split_to_table( (SELECT branch FROM links WHERE keyid='168'), E'\\.')) the branch looks like this: 89.88.166.169.168 and result are: 148 150 161 168 157 If I try to use this query in gis.m use sql query field with proper SQL syntax link::text IN( SELECT regexp_split_to_table(( SELECT branch FROM links WHERE keyid='168'), E'\\.')) do not receive any error but also any result so where is problem? As far as I know GRASS simply send query to database and recive list of cats as a result, so there could be the problem with parsing quotemarks and escape marks in regular expresion? regards Jarek ___ 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] d.out.file now does GeoTIFFs
Hamish wrote: I just found out that the output from d.out.file geotiff has some distortions. See this: http://farm4.static.flickr.com/3007/2984908579_b73cdd3b99_o.png The lighter relief is the original raster from the GRASS dbase and the darker one with some green vector is the d.out.file output. Can you try again with today's SVN? You need to update the d.info module as well. I think it should be better now. I'm using qgis to visualize. yes me too, qgis known_good.tif new.tif and setting the transparency to 50% is a very fast way of checking. Today I hope to enable margin removal for all d.out.file formats. (a flag to keep them is already in place) I'd like to get rid of the sleep steps though (AFAIR the PNG driver may still be working after d.mon stop returns) This shouldn't happen. R_kill_driver() sends GRAPH_CLOSE to the monitor, then tries to read() one byte. As the monitor never sends this byte, the read() will block until it sees EOF, which happens when the monitor terminates. Similarly, R_close_driver() won't return until the driver's Respond() method has completed. For the PNG driver, this means writing the image if GRASS_PNG_AUTO_WRITE=TRUE. Is GRASS_PNG_AUTO_WRITE the solution? or RENDER_IMMEDIATE ..? For output, you should probably be using GRASS_RENDER_IMMEDIATE rather than the PNG driver. In 6.3.0 and later, you can use GRASS_PNG_READ to have the driver overlay its output onto an existing image rather than replacing it. GRASS_PNG_READ requires that the image already exists with the correct format and dimensions. Typical usage: GRASS_RENDER_IMMEDIATE=TRUE GRASS_PNG_READ=FALSE export GRASS_RENDER_IMMEDIATE GRASS_PNG_READ d.erase GRASS_PNG_READ=TRUE more d.* commands GRASS_PNG_AUTO_WRITE only matters if you are using a PNG monitor rather than immediate rendering, and you need the file to be written after each d.* command. Without GRASS_PNG_AUTO_WRITE, the file will only be written when the driver is terminated with d.mon stop=PNG. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.out.file now does GeoTIFFs
Hamish wrote: slight contributing motivation: I am not sure of a good way to merge raster maps with different color tables (imagery data). In the past I have tried 'r.mapcalc r# g# b#' operators+r.patch, d.out.png+r.in.gdal+r.region, neither was much fun. I guess g.pnmcomp could help but I fear the added complexity of passing the data through the display drivers will introduce noise. Perhaps gdal_merge.py? (see r.in.wms mess WRT merging paletted GIF images) Maybe r.composite should have an option to use a single input map rather than separate channels? IOW, convert the input map (whether integer or FP) to an integer map whose categories directly correspond to the input map's colours. It could easily be implemented as a script: in=$GIS_OPT_INPUT out=$GIS_OPT_OUTPUT tmp=tmp.colors.$$ r.mapcalc EOF $tmp.r = r#$in $tmp.g = g#$in $tmp.b = b#$in EOF r.composite r=$tmp.r g=$tmp.g b=$tmp.g levels=256 output=$tmp.c r.mapcalc $out = if(isnull($in),null(),$tmp.c) r.colors $out raster=$tmp.c g.remove rast=$tmp.r,$tmp.g,$tmp.b,$tmp.c Actually, the first r.mapcalc should probably be isolated into a separate uncomposite script, which split a colourised map into R/G/B channels: r.mapcalc EOF $out.r = if(isnull($in),null(),r#$in) $out.g = if(isnull($in),null(),g#$in) $out.b = if(isnull($in),null(),b#$in) EOF Also, a script to collapse a rule-based colour table (as generated by e.g. r.composite) to a category-based table, using r.category and r.what.color. Left as an exercise for the reader. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] TIN and B/T correction in grass...
From IDRISI manual: Contour lines at the top of a hill are shown in Figure 11-4a. In Figure 11-4b, the highest contour is shown along with the resulting triangles created within it when a constrained TIN is generated. Because all three of the points for all the trian- gles have the same elevation, the top of the hill is perfectly flat in the TIN model. Our experience with actual terrain tells us that the true surface is probably not flat, but rather rises above the TIN facets. The edges of the TIN facets that lie below the true surface in this case are examples of what are called “tunnel edges”. These are identified in Figure 11-4b. A tunnel edge is any triangle edge that lies below the true surface. Similarly, if the contours of Figure 11-4a represented a valley bottom or depression, the TIN facets of 10-4b would describe a flat surface that is higher than the true surface. The edges of the TIN facets that lie above the true surface would then be termed “bridge edges”. Bridge and tunnel (B/T) edges are not restricted to hill tops and depression bottoms. They can also occur along slopes, particularly where iso-lines are undulating, and along ridges or channels. Two such examples are shown in Figure 11-5. To optimize a TIN, B/T edges may be removed. B/T edge removal could technically be performed on an unconstrained TIN, but this is not recommended and is not allowed in IDRISI. An optimal TIN will be generated if iso-lines are used as the original input for TIN generation, the constrained triangulation is used, and B/T edges are removed. While many of the concepts of this section are illustrated with elevation data, the procedures are not limited to such data. Il giorno mer, 29/10/2008 alle 22.25 -0700, Hamish ha scritto: Luca Penasa wrote: Is there a way for apply a bridge/tunnel TIN correction in GRASS? Is there any other similar TIN correction yet implemented in GRASS GIS? Anybody know if this function is only implemented in IDRISI? can you explain what this function does exactly? no idea, Hamish -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: I pezzi pi� forti del momento sul tuo cellulare. Scarica ora! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8270d=30-10 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.out.file now does GeoTIFFs
Hamish wrote: 7.0 doesn't have D_get_screen_window(); D_setup() uses R_get_window() instead (R_get_window() reports the raster clip region, which is initially set from $GRASS_FRAME). note what we are after for the d.info -g flag is the *unclipped* geographic region. as you say, we already have g.region -g for the clipped version. I know. The point is that you need the geographic coordinates which correspond to some particular set of screen coordinates. If you're writing a script which needs to perform its own translation from display coordinates to geographic coordinates, you need two pieces of information: a rectangle in display coordinates, and the matching rectangle in geographic coordinates. In many cases, it doesn't particularly matter which display rectangle you pick, whether it's the full screen, or the active frame, or the portion of the active frame to which the region is mapped (i.e. the active frame excluding the margins), so long as you use the same rectangle for both display and region coordinates. If you need the active frame, R_get_window() will provide this information. That reports the low-level clip window; nothing will be drawn outside of that rectangle. OTOH, the D_get_d_* functions report the portion to which the current region is mapped, excluding any margins. Rasters will never be drawn outside of that region. Vectors might be drawn outside of that region, depending upon whether display-level clipping or culling is enabled. Also, note that mapping the display frame to geographic coordinates may produce an invalid region, as the north/south boundaries may exceed 90 degrees. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
Markus Neteler wrote:
r.external - Link GDAL supported raster file to a binary raster map layer.
http://grass.osgeo.org/grass64/manuals/html64_user/r.external.html
This solves a need for me too. Could something like that be done for WMS
services, i.e. not downloading them with r.in.wms, but linking them without
making a local copy?
In theory, r.external might also accept WMS since GDAL does it:
http://www.gdal.org/frmt_wms.html
# this gets stuck:
d.rast gdal_wms
0%
strace shows
...
select(8, [6 7], [], [], {0, 10}) = 0 (Timeout)
poll([{fd=6, events=POLLIN|POLLPRI}], 1, 0) = 0
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 0) = 0
select(8, [6 7], [], [], {0, 10}) = 0 (Timeout)
...
Maybe some update magic is needed internally (but maybe
I am exaggerating right now...).
Maybe GDAL can't handle skipping rows for WMS? Due to the region
mapping, GRASS typically doesn't request rows sequentially (it may
skip rows, or request them in an arbitrary order, even reverse order).
--
Glynn Clements [EMAIL PROTECTED]
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
Markus Neteler wrote: As a long time GIS user I've dipped into grass from time to time but never in depth. One of the things that's deterred me is the fact that I have a large body of data I work with (tens of gigabytes) and the prospect of having to convert into grass, process it, and then flip it back out again is unappealing. Sure - also for us :) But it has been solved recently: r.external - Link GDAL supported raster file to a binary raster map layer. http://grass.osgeo.org/grass64/manuals/html64_user/r.external.html However, this is only works for reading. Any maps created by GRASS are still stored in the GRASS database, and need to be exported explicitly with e.g. r.out.gdal. Making it work for writing would require a way to obtain the various creation options (i.e. file format, data format (UInt8, UInt16 etc), output directory, probably a lot of other options). Implementation shouldn't be hard, but specification and design might be. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Failure on Re: [GRASS-user] Help: Converting a raster map between locations (from wgs84 lat / long to UTM)
Dear Daniel, dear Nikos, dear list, I have tried everything I could. I read the GRASS books chapters and the documentation. It does not work. The problem is that the files I have are in WGS84 unprojected. See here: http://www.worldclim.org/format.htm Whichever procedure I use, whther Daniel's or the book (for example: page 47), the problem is always the same. I create a location + mapset + map with the worldclim data (location01). I load the original data, and I call the raster map precipitation. I generate the correct box with v.region and I call it test. I create a new location + mapset (utm + osgb), called location02. I run v.proj in location B pointing at map test v.proj input=test location=location01 mapset=PERMANENT I have the same problem: PROJ_INFO file not found for location location01 But of course the projection is not defined, the data are unprojected! I am slowly getting desperate I have been working on it several days and cannot get a sensible result. I have tried with different datum transformation parameters for osgb36 and trying to project but the results are very unreliable Do you know what should I do? On Thursday 23 October 2008 11:38:47 Daniel Victoria wrote: Corrado, What v.in.region does is create a vector that surrounds your current region. Then, when you run v.proj, the vector covering the region is brought to your target location so you know where your projected raster should be at... The manual labor after that is setting the resolution correctly. You could then use some rule of thumb like 3arcsec ~= 90 m or, try to set the number of columns/rows in your target region similar to your lat/lon region. But this latter option does not work so well if your raster is to be tilted a lot... On an additional question: How do people set the resolution correctly when transforming from lat/lon to meter and vice-versa? Are there any other methods besides the ones I mentioned? Cheers Daniel On Thu, Oct 23, 2008 at 8:16 AM, Nikos Alexandris [EMAIL PROTECTED] wrote: On Thu, 2008-10-23 at 10:40 +0100, Corrado wrote: Thanks Nikos, thanks Daniel! Unfortunately, my map is a raster map, not a vector can I still use v.in.region and v.proj? Thanks [...] Hi Corrado! For sure!! You can use v.in.region anytime since it deals with the current region and not with a specific map. Regards, Nikos -- Corrado Topi Global Climate Change Biodiversity Indicators Area 18,Department of Biology University of York, York, YO10 5YW, UK Phone: + 44 (0) 1904 328645, E-mail: [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
On Thu, Oct 30, 2008 at 6:57 PM, Glynn Clements
[EMAIL PROTECTED] wrote:
Markus Neteler wrote:
In theory, r.external might also accept WMS since GDAL does it:
http://www.gdal.org/frmt_wms.html
# this gets stuck:
d.rast gdal_wms
0%
strace shows
...
select(8, [6 7], [], [], {0, 10}) = 0 (Timeout)
poll([{fd=6, events=POLLIN|POLLPRI}], 1, 0) = 0
poll([{fd=7, events=POLLIN|POLLPRI}], 1, 0) = 0
select(8, [6 7], [], [], {0, 10}) = 0 (Timeout)
...
Maybe some update magic is needed internally (but maybe
I am exaggerating right now...).
Maybe GDAL can't handle skipping rows for WMS? Due to the region
mapping, GRASS typically doesn't request rows sequentially (it may
skip rows, or request them in an arbitrary order, even reverse order).
Here an offlist answer from Frank (fwd with permission):
On Thu, Oct 30, 2008 at 7:34 PM, Frank Warmerdam wrote:
I'm not too familiar with the WMS driver. But if it doesn't support
skipping rows then it is a bug and should be fixed. To file a ticket on
this issue it would be helpful if a demonstration of the problem could
be boiled down to a small C/C++ program or Python script just depending
on GDAL.
Adam Nowaki is the main author of the WMS driver.
Unfortunately I am not skilled enough in Python to write down the
requested test case.
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: Failure on Re: [GRASS-user] Help: Converting a raster map between locations (from wgs84 lat / long to UTM)
Even though the projection is not defined, the data still has some information it is WGS84 which has a datum/coordinate system so you do need to define it, the EPSG code is 4326. You can't reproject something from nothing, it needs at least a coordinate system, otherwise it doesn't know what point on your current map should be moved and to where it should be moved. When you configured your first location you should have specified the EPSG as 4326. Does that get you further? Alex Corrado wrote: Dear Daniel, dear Nikos, dear list, I have tried everything I could. I read the GRASS books chapters and the documentation. It does not work. The problem is that the files I have are in WGS84 unprojected. See here: http://www.worldclim.org/format.htm Whichever procedure I use, whther Daniel's or the book (for example: page 47), the problem is always the same. I create a location + mapset + map with the worldclim data (location01). I load the original data, and I call the raster map precipitation. I generate the correct box with v.region and I call it test. I create a new location + mapset (utm + osgb), called location02. I run v.proj in location B pointing at map test v.proj input=test location=location01 mapset=PERMANENT I have the same problem: PROJ_INFO file not found for location location01 But of course the projection is not defined, the data are unprojected! I am slowly getting desperate I have been working on it several days and cannot get a sensible result. I have tried with different datum transformation parameters for osgb36 and trying to project but the results are very unreliable Do you know what should I do? On Thursday 23 October 2008 11:38:47 Daniel Victoria wrote: Corrado, What v.in.region does is create a vector that surrounds your current region. Then, when you run v.proj, the vector covering the region is brought to your target location so you know where your projected raster should be at... The manual labor after that is setting the resolution correctly. You could then use some rule of thumb like 3arcsec ~= 90 m or, try to set the number of columns/rows in your target region similar to your lat/lon region. But this latter option does not work so well if your raster is to be tilted a lot... On an additional question: How do people set the resolution correctly when transforming from lat/lon to meter and vice-versa? Are there any other methods besides the ones I mentioned? Cheers Daniel On Thu, Oct 23, 2008 at 8:16 AM, Nikos Alexandris [EMAIL PROTECTED] wrote: On Thu, 2008-10-23 at 10:40 +0100, Corrado wrote: Thanks Nikos, thanks Daniel! Unfortunately, my map is a raster map, not a vector can I still use v.in.region and v.proj? Thanks [...] Hi Corrado! For sure!! You can use v.in.region anytime since it deals with the current region and not with a specific map. Regards, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with executing some type od queries (with regular expresion parser)
Jarek Jasiewicz wrote: D3/3: db_select_int() D3/3: SQL: SELECT cat FROM streams_coor WHERE link::text IN(SELECT regexp_split_to_table((SELECT branch FROM links WHERE keyid='168'), E'\\.')) D3/3: Escaped SQL: SELECT cat FROM streams_coor WHERE link::text IN(SELECT regexp_split_to_table((SELECT branch FROM links WHERE keyid='168'), E'.')) D3/3: describe_table() As we see, there is a problem with escape \ backslash grass (I don't know gis.m or db_select_int()) adds backslash before. In pgAdmin I must add escape character manually as in example in post before. In gis.m this command should look like: link::text IN( SELECT regexp_split_to_table(( SELECT branch FROM links WHERE keyid='168'), E'\.')) And everythik is OK. Porblem solved. db/drivers/postgres/execute.c has the following: /* Postgres supports in addition to standard escape character ' (apostrophe) also \ (basckslash) * as this is not SQL standard, GRASS modules cannot work escape all \ in the text * because other drivers do not support this feature. For example, if a text contains * string \' GRASS modules escape ' by another ' and string passed to driver is \'' * postgres takes \' as ' but second ' remains not escaped, result is error. * Because of this, all occurencies of \ in sql are escaped by \ */ str = G_str_replace(db_get_string(sql), \\, ); [Note that \\ is a string containing a single backslash, as C also uses backslash as an escape character.] IOW, the pg DBMI driver assumes that every backslash which it sees is supposed to be a literal backslash, and converts it to a double-backslash escape sequence to ensure that it is interpreted as such. So you can't use PostgreSQL's C-like escapes (\n etc) within SQL syntax. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] newbie: problems with i.landsat.toar grass addon using suse 10.2 and grass 6.3
Thanks Markus, I have not been compiling GRASS from scratch (I have been using the binaries). So I havent been running ./configure GRASS. If i install the binary how can i run ./configure grass? In the end i compiled the addons using the following (and linked some of the librarys to the correct place - Not sure what SUSE is doing with some of these). make MODULE_TOPDIR=/opt/grass CPPFLAGS='-I/opt/grass/include' LDFLAGS='-L/opt/grass/lib -L/lib -L/usr/lib' Historically I have compiled grass, but moving to a 64bit installation I have found it too hard to track all the dependancies and have relied on binary packages. cheers Andy On 10/31/08, Markus Neteler [EMAIL PROTECTED] wrote: On Tue, Oct 21, 2008 at 11:54 PM, andrew haywood [EMAIL PROTECTED] wrote: Dear List, Im running grass 6.3 on suse 10.2. I have installed the latest version from the geo repository. I am now having problems trying to install i.landsat.toar I have checked out the most recent version of grass addons. Im getting the following error. I am a complete novice when it comes to make. The gis.h file is in /opt/grass/include/grass and somehow make isnt finding it. Any help would be greatly appreciated. regards Andy make MODULE_TOPDIR=/opt/grass test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p OBJ.x86_64-unknown-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/earth_sun.o -c earth_sun.c gcc -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.3.0/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/landsat.o -c landsat.c landsat.c:4:23: error: grass/gis.h: No such file or directory make: *** [OBJ.x86_64-unknown-linux-gnu/landsat.o] Error 1 did you ./configure GRASS? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
On Thu, Oct 30, 2008 at 10:24 PM, Glynn Clements [EMAIL PROTECTED] wrote: Markus Neteler wrote: I'm not too familiar with the WMS driver. But if it doesn't support skipping rows then it is a bug and should be fixed. To file a ticket on this issue it would be helpful if a demonstration of the problem could be boiled down to a small C/C++ program or Python script just depending on GDAL. Adam Nowaki is the main author of the WMS driver. Unfortunately I am not skilled enough in Python to write down the requested test case. Does gdal_translate -outsize ... work with WMS? Apparently not: gdal_translate -outsize 20% 20% wms_jpl_onearth.xml bla.tif Input file size is 266, 133 0 ... then it goes into poll time-out (according to strace). Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
