[GRASS-user] g.parser terminated when execute scripts just like g.manual, v.report etc.
Hi, Using Ubuntu intrepid with grass 6.4svn version, gdal and grass are compiled by myself with dpkg-buildpackage. When running g.manual -i, get error: *** buffer overflow detected ***: g.parser terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f51558] /lib/tls/i686/cmov/libc.so.6[0xb7f4f680] /lib/tls/i686/cmov/libc.so.6[0xb7f4ed68] /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0xc8)[0xb7ec4a18] /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0xf4a)[0xb7e978da] /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa7)[0xb7f4ee17] /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb7f4ed5d] g.parser(main+0xa2b)[0x804987a] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7e6d685] g.parser[0x8048ce1] === Memory map: 08048000-0804a000 r-xp 08:01 8831575/usr/lib/grass64/bin/g.parser 0804a000-0804b000 r--p 1000 08:01 8831575/usr/lib/grass64/bin/g.parser 0804b000-0804c000 rw-p 2000 08:01 8831575/usr/lib/grass64/bin/g.parser 084b7000-084d8000 rw-p 084b7000 00:00 0 [heap] b7e42000-b7e4f000 r-xp 08:01 3440661/lib/libgcc_s.so.1 b7e4f000-b7e5 r--p c000 08:01 3440661/lib/libgcc_s.so.1 b7e5-b7e51000 rw-p d000 08:01 3440661/lib/libgcc_s.so.1 b7e51000-b7e53000 rw-p b7e51000 00:00 0 b7e53000-b7e55000 r-xp 08:01 3458222 /lib/tls/i686/cmov/libdl-2.8.90.so b7e55000-b7e56000 r--p 1000 08:01 3458222 /lib/tls/i686/cmov/libdl-2.8.90.so b7e56000-b7e57000 rw-p 2000 08:01 3458222 /lib/tls/i686/cmov/libdl-2.8.90.so b7e57000-b7faf000 r-xp 08:01 3458219 /lib/tls/i686/cmov/libc-2.8.90.so b7faf000-b7fb1000 r--p 00158000 08:01 3458219 /lib/tls/i686/cmov/libc-2.8.90.so b7fb1000-b7fb2000 rw-p 0015a000 08:01 3458219 /lib/tls/i686/cmov/libc-2.8.90.so b7fb2000-b7fb5000 rw-p b7fb2000 00:00 0 b7fb5000-b7fd9000 r-xp 08:01 3458223 /lib/tls/i686/cmov/libm-2.8.90.so b7fd9000-b7fda000 r--p 00023000 08:01 3458223 /lib/tls/i686/cmov/libm-2.8.90.so b7fda000-b7fdb000 rw-p 00024000 08:01 3458223 /lib/tls/i686/cmov/libm-2.8.90.so b7fdb000-b7fef000 r-xp 08:01 8405143/usr/lib/libz.so.1.2.3.3 b7fef000-b7ff1000 rw-p 00013000 08:01 8405143/usr/lib/libz.so.1.2.3.3 b7ff1000-b7ff2000 rw-p b7ff1000 00:00 0 b800a000-b801 r-xp 08:01 8659733 /usr/lib/grass64/lib/libgrass_datetime.6.4.svn.so b801-b8011000 r--p 6000 08:01 8659733 /usr/lib/grass64/lib/libgrass_datetime.6.4.svn.so b8011000-b8012000 rw-p 7000 08:01 8659733 /usr/lib/grass64/lib/libgrass_datetime.6.4.svn.so b8012000-b805b000 r-xp 08:01 8661461 /usr/lib/grass64/lib/libgrass_gis.6.4.svn.so b805b000-b805c000 r--p 00048000 08:01 8661461 /usr/lib/grass64/lib/libgrass_gis.6.4.svn.so b805c000-b805d000 rw-p 00049000 08:01 8661461 /usr/lib/grass64/lib/libgrass_gis.6.4.svn.so b805d000-b8065000 rw-p b805d000 00:00 0 b8065000-b807f000 r-xp 08:01 3440663/lib/ld-2.8.90.so b807f000-b808 r-xp b807f000 00:00 0 [vdso] b808-b8081000 r--p 0001a000 08:01 3440663/lib/ld-2.8.90.so b8081000-b8082000 rw-p 0001b000 08:01 3440663/lib/ld-2.8.90.so bff6d000-bff82000 rw-p bffeb000 00:00 0 [stack] Aborted Could anybody give me a hint of this problem? Best regards, Liangxu Wang ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Wrong projection info after importing Geotif
Markus, I already did use -d, I copy the output below. But the problem that worries me most is not that the default region be wrong, but that r.in.gdal gets confused and interfered by the default or active region while I think that the only geographic info that should matter for r.in.gdal is the one in the geotiff file, which is correct. $ g.region -d $ g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 90N south: 90S west: 180E east: 180E nsres: 0:14:25.153538 ewres: 0:21:36 rows: 749 cols: 1000 cells: 749000 $ r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp GRASS_INFO_MESSAGE(18845,1): Projection of input dataset and current location appear to match $ g.region rast=npp $ g.region -p GRASS_INFO_ERROR(18874,1): region for current mapset is invalid GRASS_INFO_ERROR(18874,1): line 9: e-w resol: 0 GRASS_INFO_ERROR(18874,1): run g.region Thanks, Agus Markus Neteler wrote: Agus, On Mon, Oct 27, 2008 at 10:17 PM, Agustin Lobo [EMAIL PROTECTED] wrote: Markus, I made the mapset using the QGIS plugin Grass /New mapset. I'm not sure if I made something wrong or it was a problem of the plugin(I'll clarify this), but the fact is that I ended up with this (wrong) region: ~$ g.region -p GRASS_INFO_ERROR(9537,1): region for current mapset is invalid GRASS_INFO_ERROR(9537,1): line 9: e-w resol: 0 GRASS_INFO_ERROR(9537,1): run g.region Yes (@devs: suggest the -d flag?) First problem is that I cannot fix this region as explained in http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html If you looks closely, there was suggested: g.region -d Did you really run that (g.region set to default region)? GRASS doesn't automatically recover from a illegal region setting. Then I suppose that it will work. Markus Second problem is that I run r.in.gdal as I mentioned to import the file that I've put in http://aloboaleu.googlepages.com/forMarkus and get a wrong region for the raster as well: r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp ~$ g.region rast=npp ~$ g.region -p GRASS_INFO_ERROR(19559,1): region for current mapset is invalid GRASS_INFO_ERROR(19559,1): line 9: e-w resol: 0 Nevertheless, according to gdalinfo, the geotif file is correct (see my last message for the gdalinfo output). Probably, r.in.gdal would have worked fine if the default region had been correct, but this is no the point (I think). r.in.gdal should set the region for the raster according to the geotiff settings, which are correct. So there is something wrong with r.in.gdal? Thanks for your patience! Agus Markus Neteler wrote: Agus, On Sat, Oct 25, 2008 at 10:48 AM, Agustin Lobo [EMAIL PROTECTED] wrote: Thanks Markus, but this should not be the correct way for r.in.gdal to work, should it? I mean that the default is reading the the geotif with its own region, which should not be interfered by the current region unless you use the -o option. Am I wrong? since I still don't know which steps you really did (apparently you created the location from the GeoTIFF file?) I don't know how to help. Maybe I just missed that. Anyway, my problem for applying your solution is described in message http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html (I set up the default region using qgis OK, but in QGIS, what did you do to set up the default region? and, by some reason, was wrong and cannot modify it) To reproduce it, I would need the steps in a detailed way... (say, due to work overload I am most motivated with the full procedure :-). Markus -- Dr. Agustin Lobo Institut de Ciencies de la Terra Jaume Almera (CSIC) LLuis Sole Sabaris s/n 08028 Barcelona Spain Tel. 34 934095410 Fax. 34 934110012 email: [EMAIL PROTECTED] http://www.ija.csic.es/gt/obster -- Dr. Agustin Lobo Institut de Ciencies de la Terra Jaume Almera (CSIC) LLuis Sole Sabaris s/n 08028 Barcelona Spain Tel. 34 934095410 Fax. 34 934110012 email: [EMAIL PROTECTED] http://www.ija.csic.es/gt/obster ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Wrong projection info after importing Geotif
On Tue, Oct 28, 2008 at 9:28 AM, Agustin Lobo [EMAIL PROTECTED] wrote: Markus, I already did use -d, I copy the output below. But the problem that worries me most is not that the default region be wrong, but that r.in.gdal gets confused and interfered by the default or active region while I think that the only geographic info that should matter for r.in.gdal is the one in the geotiff file, which is correct. $ g.region -d $ g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 90N south: 90S west: 180E - east: 180E - This is no good. West should be 180W. This means that the DEFAULT_WIND contains bad data. How did you create the location (sorry I forgot). Another magic could be to add -e to r.in.gdal below. But it seems that the location definition is inappropriate. Markus nsres: 0:14:25.153538 ewres: 0:21:36 rows: 749 cols: 1000 cells: 749000 $ r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp GRASS_INFO_MESSAGE(18845,1): Projection of input dataset and current location appear to match $ g.region rast=npp $ g.region -p GRASS_INFO_ERROR(18874,1): region for current mapset is invalid GRASS_INFO_ERROR(18874,1): line 9: e-w resol: 0 GRASS_INFO_ERROR(18874,1): run g.region Thanks, Agus Markus Neteler wrote: Agus, On Mon, Oct 27, 2008 at 10:17 PM, Agustin Lobo [EMAIL PROTECTED] wrote: Markus, I made the mapset using the QGIS plugin Grass /New mapset. I'm not sure if I made something wrong or it was a problem of the plugin(I'll clarify this), but the fact is that I ended up with this (wrong) region: ~$ g.region -p GRASS_INFO_ERROR(9537,1): region for current mapset is invalid GRASS_INFO_ERROR(9537,1): line 9: e-w resol: 0 GRASS_INFO_ERROR(9537,1): run g.region Yes (@devs: suggest the -d flag?) First problem is that I cannot fix this region as explained in http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html If you looks closely, there was suggested: g.region -d Did you really run that (g.region set to default region)? GRASS doesn't automatically recover from a illegal region setting. Then I suppose that it will work. Markus Second problem is that I run r.in.gdal as I mentioned to import the file that I've put in http://aloboaleu.googlepages.com/forMarkus and get a wrong region for the raster as well: r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp ~$ g.region rast=npp ~$ g.region -p GRASS_INFO_ERROR(19559,1): region for current mapset is invalid GRASS_INFO_ERROR(19559,1): line 9: e-w resol: 0 Nevertheless, according to gdalinfo, the geotif file is correct (see my last message for the gdalinfo output). Probably, r.in.gdal would have worked fine if the default region had been correct, but this is no the point (I think). r.in.gdal should set the region for the raster according to the geotiff settings, which are correct. So there is something wrong with r.in.gdal? Thanks for your patience! Agus Markus Neteler wrote: Agus, On Sat, Oct 25, 2008 at 10:48 AM, Agustin Lobo [EMAIL PROTECTED] wrote: Thanks Markus, but this should not be the correct way for r.in.gdal to work, should it? I mean that the default is reading the the geotif with its own region, which should not be interfered by the current region unless you use the -o option. Am I wrong? since I still don't know which steps you really did (apparently you created the location from the GeoTIFF file?) I don't know how to help. Maybe I just missed that. Anyway, my problem for applying your solution is described in message http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html (I set up the default region using qgis OK, but in QGIS, what did you do to set up the default region? and, by some reason, was wrong and cannot modify it) To reproduce it, I would need the steps in a detailed way... (say, due to work overload I am most motivated with the full procedure :-). Markus -- Dr. Agustin Lobo Institut de Ciencies de la Terra Jaume Almera (CSIC) LLuis Sole Sabaris s/n 08028 Barcelona Spain Tel. 34 934095410 Fax. 34 934110012 email: [EMAIL PROTECTED] http://www.ija.csic.es/gt/obster -- Dr. Agustin Lobo Institut de Ciencies de la Terra Jaume Almera (CSIC) LLuis Sole Sabaris s/n 08028 Barcelona Spain Tel. 34 934095410 Fax. 34 934110012 email: [EMAIL PROTECTED] http://www.ija.csic.es/gt/obster -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.profile ??
Hi all, does anyone know if there is a way of drawing a vertical profile from a 3d vector point map? For example from earthquakes location data which are typically 3d vector points? It seems to me that it should be something corresponding to r.profile, but for vectors (v.profile??). Also, typical profiles (sections) of such data require a thickness of the section to be set in order to project the vectors from a given distance onto the section. Again this is typical for earthquakes distributions. any hints? thanks in advance Francesco ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Export vect to shapefiles
Dear All, I am running native WinGrass and I am trying to export a vector map (with 100.000 areas). The command below is what I am using. v.out.ogr input=myvect dsn=c:/temp olayer=myexport type=area But after a all nigth long the command not finish and now update is done on the output files (which have about 80MB) since after 20minutes I start the command. Any help are welcome. Best wishes, miltinho astronauta brazil ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.profile ??
Hello Francesco. You are really lucky :) I'm implementing v.profile right now. It's almost working - it needs some final touches and documentation before it's ready for release. Currently it does not support 3d maps, but I will put it on my TODO list. Still it will not be in 6.4.0. Francesco, if You need some vector profiling tool right now, I can send it to You offlist. Otherwise just hope that I will have free time to work on GRASS code :) Maris. 2008/10/28, Francesco Mirabella [EMAIL PROTECTED]: Hi all, does anyone know if there is a way of drawing a vertical profile from a 3d vector point map? For example from earthquakes location data which are typically 3d vector points? It seems to me that it should be something corresponding to r.profile, but for vectors (v.profile??). Also, typical profiles (sections) of such data require a thickness of the section to be set in order to project the vectors from a given distance onto the section. Again this is typical for earthquakes distributions. any hints? thanks in advance Francesco ___ 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] v.profile ??
Hi Maris, thanks for your message, that's funny! :-) I am very happy that v.profile will exist! I do believe that a growing number of people can get advantages of such a tool, maybe especially geologists and seismologists who currently work with 3D vector data (also for example borehole data). It would be nice if you could send it to me in the meantime, I will try to install it and try it. best wishes Francesco Maris Nartiss wrote: Hello Francesco. You are really lucky :) I'm implementing v.profile right now. It's almost working - it needs some final touches and documentation before it's ready for release. Currently it does not support 3d maps, but I will put it on my TODO list. Still it will not be in 6.4.0. Francesco, if You need some vector profiling tool right now, I can send it to You offlist. Otherwise just hope that I will have free time to work on GRASS code :) Maris. 2008/10/28, Francesco Mirabella [EMAIL PROTECTED]: Hi all, does anyone know if there is a way of drawing a vertical profile from a 3d vector point map? For example from earthquakes location data which are typically 3d vector points? It seems to me that it should be something corresponding to r.profile, but for vectors (v.profile??). Also, typical profiles (sections) of such data require a thickness of the section to be set in order to project the vectors from a given distance onto the section. Again this is typical for earthquakes distributions. any hints? thanks in advance Francesco ___ 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] Re: Export vect to shapefiles
Hi GRASS-gurus, I tryed the command again, using the GRASS MSYS console, and I noticed that when my output command reach what I think is the end of task, the GRASS don´t finish it. So, The command appear stay in loop, and it never finish. And if I copy the files and try to open it on ArgGis - I really need it :-( - the ArcGis don´t understand the format. Any suggestion? miltinho brazil 2008/10/28 Milton Cezar Ribeiro [EMAIL PROTECTED] Dear All, I am running native WinGrass and I am trying to export a vector map (with 100.000 areas). The command below is what I am using. v.out.ogr input=myvect dsn=c:/temp olayer=myexport type=area But after a all nigth long the command not finish and now update is done on the output files (which have about 80MB) since after 20minutes I start the command. Any help are welcome. Best wishes, miltinho astronauta brazil ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] TIN and B/T correction in grass...
Hi everybody...Just a little quetion... 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? Thanks Luca Penasa Geology Student University of Padua [EMAIL PROTECTED] N 45° 24' 54''E 11° 52' 54'' -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Scopri Carta Eureka e realizza i tuoi sogni! Fido fino a 3.000 euro, rate a partire da 20 euro e canone gratis il 1� anno! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7878d=28-10 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.pca vs. r.covar/m.eigensystem/r.mapcalc
On Monday 27 October 2008, Nikos Alexandris wrote:
My apologies for BUMPing :-)
On Sun, 2008-10-12 at 00:20 +0200, Nikos Alexandris wrote:
I wanted to check/verify some i.pca results so I calculated 2 principal
components using r.covar, m.eigensystem and r.mapcalc. The results are
not the same with i.pca's output.
(Maybe this post http://www.nabble.com/Eigen-vectors-tt15686112.html was
about the same issue)
# i.pca performed on (3) modis surface reflectance bands (2, 6 and 7 -
500m spatial resolution)
*** and region resolution set to 500m of course***
r.info pca.2007.242.500.b267.1 -h
[...]
Eigen vectors:
( -0.64 -0.65 -0.42 )
( -0.71 0.29 0.64 )
( 0.29 -0.70 0.65 )
[...]
I repeated the same i.pca but setting this time a different region
resolution (250m) than before (500m) and I get slightly different
eigenvectors:
*** with region resolution=250m ***
Eigen values:
( -0.64 -0.65 -0.42 )
( -0.71 0.28 0.64 )
( -0.30 0.71 -0.64 )
I understand that the region resolution influences the results of
i.pca. OK, then how would someone re-produce the same PCs doing the math
in R and not in GRASS?
Could someone explain or give any hints to learn more about i.pca?
Thank you, Nikos
Hi,
Remember that the region settings may cause re-sampling of your image due to
changes in resolution or grid-cell alignment. Here is a re-enactment of your
example above in GRASS, then in R- using some color imagery. Although I am
not an expert in PCA, I think that the methods in R/GRASS here are
comparable. In the output from R, the row and column names of the returned
matrix are printed, and it looks like the rotation vectors (eigen vectors)
for the 3rd PC are the least stable. This seems to make sense as (in this
case) the 3rd PC accounts for the least amount of variance-- and is thus
probably just picking up noise.
Not sure about applying the rotation manually and how that compares with
i.pca ...
Cheers,
Dylan
--- example --
# intial test at 1m res
g.region res=1 -a
i.pca in=naip.red,naip.green,naip.blue out=pca --o
d.rgb r=pca.2 g=pca.1 b=pca.3
Eigen values:
( -0.74 -0.55 -0.38 )
( 0.67 -0.67 -0.31 )
( 0.08 0.49 -0.87 )
# now try 10m res
g.region res=10 -a
i.pca in=naip.red,naip.green,naip.blue out=pca --o
d.rgb r=pca.2 g=pca.1 b=pca.3
Eigen values:
( -0.73 -0.56 -0.38 )
( 0.68 -0.65 -0.34 )
( 0.06 0.51 -0.86 )
## now try it in R
# init libraries
library(spgrass6)
# read in same data used in GRASS PCA calc
system('g.region res=1 -a')
x - readRAST6(c('naip.red','naip.green', 'naip.blue'))
# use prcomp, as it directly returns rotation matrix
# same as Eigen values?
x.pca - prcomp([EMAIL PROTECTED])
# transpose result for printing in same order as GRASS
signif(t(x.pca$rotation), 2)
naip.red naip.green naip.blue
PC1 -0.730 -0.56 -0.38
PC20.680 -0.62 -0.39
PC30.023 0.54 -0.84
# do again, at reduces res:
system('g.region res=10 -a')
x - readRAST6(c('naip.red','naip.green', 'naip.blue'))
# use prcomp, as it directly returns rotation matrix
# same as Eigen values- yes, see the manual page for prcomp
x.pca - prcomp([EMAIL PROTECTED])
# transpose result for printing in same order as GRASS
signif(t(x.pca$rotation), 2)
PC1 -0.730 -0.56 -0.38
PC20.680 -0.64 -0.36
PC30.041 0.53 -0.85
--
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] Export To PostGIS (with attributes)
I'm going to resurrect this post because I think I was unclear on what I wanted as a result from the process. So I thought I would try this again with an example. Problem: I have a table in PostgreSQL/PostGIS where some polygons are overlapping, as illustrated in the picture below in the dark colored areas. We need to run, for example, area summaries on polygons so we cannot have overlapping polygons. Overlapping Polygons: http://www.nabble.com/file/p20212397/overlaps.png Clean Polygons http://www.nabble.com/file/p20212397/no_overlaps.png Since this is an automated process, I need the process to be robust and ensure proper results, i.e. why I'm using GRASS and the topological data model for data processing. After the layer has been imported and topologically cleaned in GRASS, I need to export the GRASS layer back to PostgreSQL/PostGIS. If I export layer 1 to PostgreSQL/PostGIS I get the result as above. I want to be able to export out layer 2, so there is not any overlapping polygons, export the attributes out GRASS with the result being three tables as follows: 1) Geometry Table: gid SERIAL the_geom geometry 2) Join Table: sp_id INTEGER att_id INTEGER 3) Attribute Table: gid SERIAL description varchar(200) ... http://www.nabble.com/file/p20212397/table_rel.png I've tried using Point in Polygon in PostGIS to relate the attributes and the geometry to build the table relationship illustrated above but I have run into some problems with PostGIS's ST_PointOnSurface function not working in some cases. Does anyone have any suggestions on a possible process to create the process above with a combination of GRASS and PostgreSQL? I prefer to do most of my geometry related processing in GRASS because of the robustness. Thanks for any help, Dustin hamish_b wrote: Moritz Lennert wrote: There is a fundamental difference between the PostGIS format which is non-topological and the internal GRASS format which is topological and which, thus, does not really allow for overlapping polygons. You can digitize them, but they are not really useful... I was hoping that all the processing could have been done in GRASS rather. You cannot directly process a PostGIS table in GRASS. GRASS has its own internal vector format. If you want to do everything in GRASS, you have to stop after step 2. You can link a GRASS layer to a PostgreSQL table, though. I just added that to a new PostGIS wiki page, it would be great if findings could be summarized there by an expert. http://grass.osgeo.org/wiki/PostGIS Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://www.nabble.com/Export-To-PostGIS-%28with-attributes%29-tp19405378p20212397.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] g.transform: forward and reverse rmse
Maciej Sieczka wrote: I have a problem understanding how to interprete the reverse and forward rmse returned by g.transform. I found Glynn's explanation [1], but, shame one me, I don't quite get it. Is there anybody willing to put the explanation some other words so maybe this gives enough clue? First, best-fit forward and/or reverse transformations are computed based upon the GCPs. The same algorithm is used for both forward and reverse transforms, the only difference being that the control points are swapped. Note that, unless order=1, the two transformations will typically not be exact inverses as the inverse of a polynomial containing quadratic or higher terms is not itself a polynomial. The RMS error for a transformation is the mean of the squares of the distances between the transformed source point and the corresponding destination point. If you have a GCP pair ((sx,sy),(dx,dy)) and a transformation T, the transformed source point is (tx,ty) = T(sx,sy). The square of the distance is (tx-dx)^2+(ty-dy)^2. The total square error is the sum of these values, the mean square error is the total square error divided by the number of values, and the root mean square error is the square root of the mean square error. The forward and reverse RMS errors correspond to the forward and reverse transformations. The forward error provides an estimate of how far a forward-projected point in the source coordinate system will be from the actual position of that point in the destination coordinate system. The reverse error provides an estimate of how far a reverse-projected point in the destination coordinate system will be from the actual position of that point in the source coordinate system. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] settings nulls with r.mapcalc
Sebastian P. Luque wrote: Are the following calls doing the same in terms of which cells get assigned the null value? $ r.mapcalc new_raster = if(raster == 0 || raster == 253, null(), raster) $ r.null map=raster setnull=0,253 Yes; both set any cells which are either 0 or 253 to null. They differ in that r.mapcalc creates a new map while r.null modifies the existing map in-place. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Extremely large vector coverages...
GISers: I'm hoping to get a list of programs/databases that can deal with the storage and querying of arbitrarily large vector (polygon) coverages ( 2gb)? My understanding is, for instance, PostGIS (and the various front-end interfaces) can deal with these types of data, but file formats such as shapefiles cannot. Please let me know either through the mailing list or directly via email -- I'm happy to post a summary of the responses in a few days. Can any of the newer ESRI formats handle large polygon coverages? --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: [EMAIL PROTECTED], Gchat: jgrn307 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Extremely large vector coverages...
On Tuesday 28 October 2008, Jonathan Greenberg wrote: GISers: I'm hoping to get a list of programs/databases that can deal with the storage and querying of arbitrarily large vector (polygon) coverages ( 2gb)? My understanding is, for instance, PostGIS (and the various front-end interfaces) can deal with these types of data, but file formats such as shapefiles cannot. Please let me know either through the mailing list or directly via email -- I'm happy to post a summary of the responses in a few days. Can any of the newer ESRI formats handle large polygon coverages? --j If you don't need topology PostGIS can scale very nicely with large vector data sets. 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] g.transform: forward and reverse rmse
Maciej Sieczka wrote: Note that, unless order=1, the two transformations will typically not be exact inverses as the inverse of a polynomial containing quadratic or higher terms is not itself a polynomial. Even for order=1 I get rather huge differences between forward and reverse. Normal? Order 1-3 examples for a single GCP set, g.transform -s group=tmp format=idx,fd,rd: # Order=1: index forward reverse 0 140.159347 30.366192 1 75.549553 16.157024 2 20.384295 4.152418 3 88.853688 19.265900 4 88.257880 19.471545 5 28.997927 6.360764 6 96.951029 21.909275 7 98.251481 21.344657 8 75.633328 17.289931 9 55.503010 12.158829 10 52.191730 11.329603 11 121.973315 27.215642 12 69.859427 15.239316 13 137.981202 29.362434 Number of active points: 14 Forward: x[13] = 127.41 y[11] = 119.24 g[0] = 140.16 RMS = 89.31 Reverse: x[13] = 28.74 y[11] = 25.14 g[0] = 30.37 RMS = 19.52 Note that the forward/reverse ratio only varies between 4.37 and 4.90, so there's a high degree of correlation between the two. Each set of numbers is measured in the corresponding coordinate system, so if you have e.g. pixels for the source, metres for the destination, and a resolution of 5 metres/pixel, you would expect the forward errors (in metres) to be roughly 5 times the reverse errors (in pixels). The above figures would make sense for a scale factor of around 4.5. # Order=2: Ratio = 3.97 - 4.92 # Order=3: Ratio = 3.55 - 5.70 For higher-order transformations, I would expect more divergence if the exact transformation is noticeably non-linear, as one of the transformations will often be a better fit to a polynomial than the other (e.g. for y = x^2 = x = sqrt(y), the former can be represented exactly while the latter can only be approximated). -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Change region in GIS Manager
Dear all, There is one problem that relates to changing region (g.region) using GIS Manager (gis.m). It seems that when I change the display, whether zoom in or zoom out or use g.region based on current raster, g.region with gis.m is not working. So, if I crop the image, the result is based on the previous region. To solve this problem, I had to switch to Display Manager (d.m). But switching to one GUI to another is a little bit annoying, especially when I am training people on how to use GRASS. Is there anyone having this problem also? Thanks. Firman Hadi Center for Remote Sensing - ITB Jl. Ganesha No. 10, 3rd Floor Bandung - 40132 INDONESIA Phone: +62-22-2530701 Fax: +62-22-2530702 Website : http://crs.itb.ac.id ; www.sigro.org Blog : http://jalmiburung.blogdetik.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
