Re: [GRASS-user] v.patch segmentation fault
Hi Markus, MarkusM, many thanks to you both for the quick fix, I tested it now and it's working perfectly. best regards, Daniel. On 31/03/2021 22:47, Markus Neteler wrote: > Hi Daniel, > > On Tue, Mar 30, 2021 at 9:57 PM Daniel McInerney > wrote: >> Hi Markus, cc: List, >> >> thanks for your reply. I've reproduced the segmentation fault using the >> roads dataset from the Spearfish dataset. I've split the roads into >> three separate vector layers, and then patched them together as follows: > ... >> v.patch -e input=roads_12,roads_interstate output=roads_patch >> Segmentation fault > Fixed by Markus Metz in https://github.com/OSGeo/grass/issues/1488 and > backported to the upcoming GRASS GIS 7.8.6. > > Cheers > Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.patch segmentation fault
Hi Markus, cc: List, thanks for your reply. I've reproduced the segmentation fault using the roads dataset from the Spearfish dataset. I've split the roads into three separate vector layers, and then patched them together as follows: v.extract input=roads output=roads_interstate where="label='interstate'" v.extract input=roads output=roads_primary where="label LIKE 'primary%'" v.extract input=roads output=roads_secondary where="label LIKE 'secondary%'" ##here I patch one set of vectors without -e v.patch input=roads_primary,roads_secondary out=roads_12 v.patch -e input=roads_12,roads_interstate output=roads_patch Segmentation fault As mentioned previously this was caused by an oversight on my side, but it might be useful to check if all inputs to v.patch have a (valid) database table attached as well as the correct set of columns, rather than returning the segmentation fault. Hope that helps. best regards, Daniel On 28/03/2021 22:07, Markus Neteler wrote: > Hi Daniel, > > On Thu, Mar 11, 2021 at 11:35 AM Daniel McInerney > wrote: >> Hi List, >> >> I was running a series of steps in a workflow that patched different >> line vector datasets together using v.patch, but at one stage I got a >> Segmentation Fault without any indication of the cause. I soon realised >> that one of the inputs that I had previously generated with v.patch, did >> not have an attribute table as I had omitted the -e flag in error. Below >> is the command that lead to the seg fault (including the gdb outputs), >> where 'fishnet_1' did not have an attribute table. >> >> Starting program: /usr/local/grass79/bin/v.patch -e >> input=fishnet_1,fishnet_2 out=fishnet_all >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> [New Thread 0x7fffecf09700 (LWP 18601)] >> [New Thread 0x7fffec708700 (LWP 18602)] >> [New Thread 0x7fffe9f07700 (LWP 18603)] >> [New Thread 0x7fffe5706700 (LWP 18604)] >> [New Thread 0x7fffe2f05700 (LWP 18605)] >> [New Thread 0x7fffe0704700 (LWP 18606)] >> [New Thread 0x7fffddf03700 (LWP 18607)] >> >> Thread 1 "v.patch" received signal SIGSEGV, Segmentation fault. >> db_get_table_number_of_columns (table=0x0) at table.c:140 >> >> 140 return table->numColumns; >> >> When I recreated 'fishnet_1' and included -e, and then re-ran the above >> command, the process completed successfully. I'm therefore wondering if >> it would be possible for v.patch to check whether all of the inputs >> have valid attribute tables/dblinks attached, in a similar way it checks >> that all inputs have the same number of columns. I appreciate that I may >> be overlooking a more fundamental reason why this can't be done, but >> perhaps an error message could be included in lieu or in addition to the >> segmentation fault. The above was tested on grass-gis 7.9 dev with both >> sqlite and pg db drivers. >> >> thanks in advance, >> >> Daniel > Do you see a chance to provide a reproducible example? > Then we could run the debugger on it. > Certainly you may do that as well, with your data: > > https://grasswiki.osgeo.org/wiki/GRASS_Debugging#Using_GDB > > It may give some insights why the segfault happens. > > Best, > Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.patch segmentation fault
Hi List, I was running a series of steps in a workflow that patched different line vector datasets together using v.patch, but at one stage I got a Segmentation Fault without any indication of the cause. I soon realised that one of the inputs that I had previously generated with v.patch, did not have an attribute table as I had omitted the -e flag in error. Below is the command that lead to the seg fault (including the gdb outputs), where 'fishnet_1' did not have an attribute table. Starting program: /usr/local/grass79/bin/v.patch -e input=fishnet_1,fishnet_2 out=fishnet_all [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffecf09700 (LWP 18601)] [New Thread 0x7fffec708700 (LWP 18602)] [New Thread 0x7fffe9f07700 (LWP 18603)] [New Thread 0x7fffe5706700 (LWP 18604)] [New Thread 0x7fffe2f05700 (LWP 18605)] [New Thread 0x7fffe0704700 (LWP 18606)] [New Thread 0x7fffddf03700 (LWP 18607)] Thread 1 "v.patch" received signal SIGSEGV, Segmentation fault. db_get_table_number_of_columns (table=0x0) at table.c:140 140 return table->numColumns; When I recreated 'fishnet_1' and included -e, and then re-ran the above command, the process completed successfully. I'm therefore wondering if it would be possible for v.patch to check whether all of the inputs have valid attribute tables/dblinks attached, in a similar way it checks that all inputs have the same number of columns. I appreciate that I may be overlooking a more fundamental reason why this can't be done, but perhaps an error message could be included in lieu or in addition to the segmentation fault. The above was tested on grass-gis 7.9 dev with both sqlite and pg db drivers. thanks in advance, Daniel ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.net.allpairs - reduce number of calculations
Hi List, I've been using v.net.allpairs [1] for the calculation of shortest paths between pairs of nodes on a river network, and it is working very well. However, for some datasets there are several thousand individual nodes and I would like to reduce the associated processing time if possible. Based on the documentation and the current outputs, the module calculates the shortest paths between all pairs of nodes on the network. In my case, I'm only interested in the shortest paths from one specific node. I'm therefore, wondering if it is possible to use the module in this way and limit the shortest path calculations from one node to all of the other nodes on network. I tried to use the 'cats' and 'where' options, but so far to no avail. I appreciate I am overlooking something, but would value any feedback or advice on how to reduce the associated processing time. Thanks in advance. Regards Daniel. [1]: https://grass.osgeo.org/grass79/manuals/v.net.allpairs.html ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.net.distance - from feature was not reachable
Hi List, We are using v.net.distance to calculate the shortest path between two points on a river network, but have been experiencing some issues in both grass 7.4 and 7.9. In some instances, we need to add a new vector line (stream) to the river network, which we have done using v.patch as follows: v.patch input=river_network,stream output=river_network_with_stream We then clean the output as follows: v.clean input=river_network_with_stream output=river_network_with_stream_clean tool=rmdupl,break,snap We then run the following steps to calculate the shortest path (based on the documentation [1]), where the vector dataset (start_point) is located on the above-mentioned stream and the end_point is located on the river network: v.net input=river_network_with_stream_clean points=start_point output=river_net operation=connect thresh=100 arc_layer=1 node_layer=2 --overwrite v.net input=river_net points=end_point output=river_net2 operation=connect thresh=100 arc_layer=1 node_layer=3 --overwrite The resulting output of v.category is: v.category input=river_net2 option=report Layer: 1 type count min max point 0 0 0 line 102092 1 102072 boundary 0 0 0 centroid 0 0 0 area 0 0 0 face 0 0 0 kernel 0 0 0 all 102092 1 102072 Layer: 2 type count min max point 1 1 1 line 0 0 0 boundary 0 0 0 centroid 0 0 0 area 0 0 0 face 0 0 0 kernel 0 0 0 all 1 1 1 Layer: 3 type count min max point 1 1 1 line 0 0 0 boundary 0 0 0 centroid 0 0 0 area 0 0 0 face 0 0 0 kernel 0 0 0 all 1 1 1 At this point, I visually confirm that both points are connected to the network and then run: v.net.distance in=river_net2 out=river_path from_layer=2 to_layer=3 --overwrite However, I (keep) get a warning ( WARNING: 1 'from' feature was not reachable) and the output is empty. I have read a few posts online reporting the same issue, but none of the proposed solutions have helped. Is there a step that I am overlooking as I would have assumed that once the network topology is built and the points are connected to the network that it would have run correctly. I confirm that I can calculate the shortest path when I use a start point that is the river network (excluding the stream), so I am assuming that the issue is related to the output of the v.patch? Thanks in advance for any help or suggestions. best regards, Daniel. [1]: https://grass.osgeo.org/grass76/manuals/v.net.distance.html ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.out.ogr and Date fields
Many thanks for fixing this issue; the export of Date fields using v.out.ogr is working perfectly with GRASS 7.9.dev cloned from github this morning. best regards, Daniel On 11/11/2019 21:12, Markus Neteler wrote: On Wed, Nov 6, 2019 at 8:30 PM Markus Metz wrote: On Wed, Nov 6, 2019 at 4:52 PM Markus Metz wrote: On Wed, Nov 6, 2019 at 3:01 PM Markus Neteler wrote: Hi Daniel, On Mon, Nov 4, 2019 at 12:23 PM Daniel McInerney wrote: Hi List, As part of a workflow, we are importing ESRI Shapefiles into GRASS so that we can manage the vector topology, before re-exporting the vectors back to an ESRI Shapefile. However, we noticed that the date fields are being converted from a field of type Date to type String. Indeed, this happens in v.out.ogr, should be easy to fix. Can you create a ticket just as a reminder? Please try https://github.com/OSGeo/grass/pull/184 Markus M FYI: This fix is part of the freshly released GRASS GIS 7.8.1: https://trac.osgeo.org/grass/wiki/Release/7.8.1-News markusN ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.out.ogr and Date fields
Hi List, As part of a workflow, we are importing ESRI Shapefiles into GRASS so that we can manage the vector topology, before re-exporting the vectors back to an ESRI Shapefile. However, we noticed that the date fields are being converted from a field of type Date to type String. Hopefully the following steps will demonstrate the issue: The input Shapefile is scdb_date, with a date field called 'BA_DATE': >ogrinfo -so -al scdb_date.shp | grep BA_DATE BA_DATE: Date (10.0) After importing into GRASS using v.in.ogr, the field is still of type DATE (although the length has increased to 20): >db.describe scdb_date | grep -A 5 BA_DATE column:BA_DATE description: type:DATE len:20 scale:0 precision:0 However, when I export the vector (scdb_date) back to an ESRI Shapefile using v.out.ogr, the BA_DATE is converted to a String: v.out.ogr input=scdb_date output=scdb_date_export.shp format='ESRI_Shapefile' >ogrinfo -so -al scdb_date_export.shp | grep 'BA_DATE' BA_DATE: String (20.0) I tried exporting to a GeoPackage, but the issue persists. While, we can still overcome this issue using ogr and SQL, I am wondering if is there a flag or option in v.out.ogr that I am overlooking that would maintain the fields of type Date or is there something else that I should consider? Thanks in advance. best regards, Daniel. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.out.ogr - layer name
Hi List, When I export a vector using v.out.ogr, I'm unable to assign an output layer name when the output format is 'ESRI_Shapefile'. For example: v.out.ogr input=grid_clip output=grid_clip.shp output_layer=sub_grid format='ESRI_Shapefile' Exporting 4 areas (may take some time)... 100% v.out.ogr complete. 4 features (Polygon type) written to the message indicates that it has been written to sub_grid, but the output from ogrinfo indicates that is hasn't been updated: ogrinfo -so grid_clip.shp INFO: Open of `grid_clip.shp' using driver `ESRI Shapefile' successful. 1: grid_clip (Polygon) However, the above process works, and the correct layer name is written, when the output format is GeoPackage or SQLite. I can update the layer name subsequently with ogr2ogr, but it would be preferable if this could be avoided. I'm using GRASS 7.4.0 (2018) on Ubuntu 18.04 (bionic). Any advice appreciated. Regards, Daniel. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.generalize and external boundaries
Hi Markus, Micha,
Many thanks for your emails, the combined solution that you suggested
worked perfectly.
best regards,
Daniel.
On 25/08/18 11:03, Markus Metz wrote:
>
>
> On Sat, Aug 25, 2018 at 10:56 AM Micha Silver <mailto:tsvi...@gmail.com>> wrote:
> >
> > I think I have a series of steps that will allow you to separate the
> "inner" boundaries and generalize only those. The idea is based on
> using the v.to.db module, with the "sides" option to add the cat
> number of each area to the left and right of each boundary. Outer
> boundaries will have "-1" (nothing on that side) for the left or right
> sides. Then you can split out the inner boundaries with a v.extract
> using a "where" clause.
>
> nice approach, but it could be simplified because v.generalize has a
> where option, i.e. no need for v.extract:
> >
> > Somewhat convoluted, but here you are as regular grass command, not
> in python.
> >
> > (My example below is from the sample nc_basic_spm_grass7 location. I
> tested with the geology map.)
> >
> > # Make a copy and add cats to the boundaries in layer 2
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > g.copy vect=geology,my_geol
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.category my_geol layer=2
> type=boundary option=add output=my_geol2
> >
> > # Add attribute columns for the left and right sides in layer 2, and
> populate from the areas in *layer 1*
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.db.addtable my_geol2 layer=2
> column="left integer,right integer"
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.to.db my_geol2 layer=2
> option=sides column=left,right query_layer=1
>
> generalize inner boundaries
> GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.generalize input=my_geol2
> method=douglas output=my_geol2_smooth thresh=1000 type=boundary
> layer=2 where="left > -1 and right > -1" --o
>
> done
>
> Markus M
>
> >
> > # Now use the left and right cat value to separate the inner and
> outer boundaries
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.extract my_geol2 layer=2
> out=inner_bndry type=boundary where="left<>-1 and right<>-1"
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.extract my_geol2 layer=2
> out=outer_bndry type=boundary where="left=-1 or right=-1"
> >
> > # Convert inner boundaries to lines for smoothing, and run generalize
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.type input=inner_bndry
> out=inner_lines layer=2 from=boundary to=line
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.generalize inner_lines
> method=douglas output=inner_lines_smooth thresh=1000 --o
> >
> > # Convert back to boundary and merge back with the outer boundary
> and recreate area centroids
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.type inner_lines_smooth
> out=inner_bndry_smooth from=line to=boundary layer=2 --o
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.patch
> input=outer_bndry,inner_bndry_smooth output=merge_smooth --o
> > GRASS 7.4.0 (nc_basic_spm_grass7):~ > v.centroids merge_smooth
> output=merged_areas layer=2 option=add
> >
> >
> > You probably will have to do some manual cleaning of the result,
> since the smoothed inner boundaries might no longer exactly intersect
> with the untouched outer boundary due to overshoots, etc.
> >
> > If you try this, let us know how it went.
> >
> > Regards, Micha
> >
> >
> >
> > On 08/24/2018 06:43 PM, Daniel McInerney wrote:
> >
> > Hi List,
> >
> > I'm using v.generalize in a script (excerpt included below) to smooth
> > the boundaries of a polygon vector dataset. In the attached example
> > (input_vector.png), I would like to *only* generalize the internal lines
> > (blue), and leave the external boundary (green line) unchanged. I
> > thought that the flag, '-l' might provide this functionality, but
> > unfortunately the resulting external boundary is changed significantly
> > (attached vgeneralize_output.png).
> >
> > Is this functionality available in v.generalize or is there another way
> > that this could be achieved in GRASS?
> >
> > Thanks in advance.
> >
> > Best regards,
> > Daniel.
> >
> > ##run generalisation (step: 1 - douglas)
> > gscript.run_command('v.generalize', flags='l', overwrite=True,
> > input='segments', output='segments_douglas', method='douglas',
> threshold=1)
> >
> > ##run generalisation (step: 2 - sliding average)
> > gscript.run_command('v.generalize', flags='l', overwrite=True,
> > input='segments_douglas',
[GRASS-user] v.generalize and external boundaries
Hi List,
I'm using v.generalize in a script (excerpt included below) to smooth
the boundaries of a polygon vector dataset. In the attached example
(input_vector.png), I would like to *only* generalize the internal lines
(blue), and leave the external boundary (green line) unchanged. I
thought that the flag, '-l' might provide this functionality, but
unfortunately the resulting external boundary is changed significantly
(attached vgeneralize_output.png).
Is this functionality available in v.generalize or is there another way
that this could be achieved in GRASS?
Thanks in advance.
Best regards,
Daniel.
##run generalisation (step: 1 - douglas)
gscript.run_command('v.generalize', flags='l', overwrite=True,
input='segments', output='segments_douglas', method='douglas', threshold=1)
##run generalisation (step: 2 - sliding average)
gscript.run_command('v.generalize', flags='l', overwrite=True,
input='segments_douglas', output='segments_douglas_slide',
method='sliding_averaging', threshold='2', look_ahead='9', slide='0.1',
iterations='3')
##run generalisation (step: 3 - snake)
gscript.run_command('v.generalize', flags='l', overwrite=True,
input='segments_douglas_slide', output='segments_douglas_slide_snake',
method='snake', threshold='3', alpha='1', beta='1')
pEpkey.asc
Description: application/pgp-keys
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] European cities map
Hi Johannes, Eurostat's European Urban Audit dataset [1] could also be relevant.It contains a point Shapefile of each of the main EU cities (580 in total) as well as their respective urban extents as polygons. As far as I can see, the latest version dates from 2004 [2], but perhaps a more recent version exists somewhere else. best regards, Daniel [1] http://epp.eurostat.ec.europa.eu/portal/page/portal/region_cities/city_urban/ [2] http://epp.eurostat.ec.europa.eu/portal/page/portal/gisco_Geographical_information_maps/popups/references/administrative_units_statistical_units_1 On Wed, Jan 8, 2014 at 10:46 AM, Johannes Radinger johannesradin...@gmail.com wrote: Dear GRASS users, is there a good (more or less uptodate) vector (point) file containing European cities and maybe also there approximate size? Maybe someone of you is aware of such a product that is freely available e.g. from the European Union? Does anyone have an idea about such a data source? Thanks! Best regards, Johannes ___ 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] Export to Geotiff and produce tfw file
Hi Luis, You should also include `createopt=TFW=YES` in your r.out.gdal command. best regards, Daniel On Wed, Nov 6, 2013 at 10:00 AM, Luisa Peña luisapena1...@gmail.com wrote: Dear all, I have a question regarding the export to geotiff using r.out.gdal: how can I generate an auxilliary tfw file with the TIFF file? Thank you regards, Luisa ___ 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] Compilation error with g.extension v.krige
Hi Alessandro, On Thu, Oct 17, 2013 at 11:30 AM, Alessandro Sarretta alessandro.sarre...@gmail.com wrote: Dear all, I'm trying to install v.krige via *g.extension v.krige* but I receive an error. My configurations are the followings: GRASS version: 6.4.3 GRASS SVN Revision: GIS Library Revision: 50937 (2012-02-25) GDAL/OGR: 1.10.0 PROJ4: Rel. 4.8.0, 6 March 2012 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Linux-3.8.0-31-generic-x86_64-with-Ubuntu-13.04-raring Below the last lines of the command output: - *[...] /usr/bin/install: target ‘/home/ale/Documents/grassdb/wgs84/PERMANENT/.tmp/sarretta-utos/32627.0/dist.x86_64/etc/wxpython/scripts/’ is not a directory: No such file or directory** **make: *** [default] Error 1** **ERROR: Compilation failed, sorry. Please check above error messages.** *- I've read this http://lists.osgeo.org/pipermail/grass-user/2011-April/060329.html but I can't understand whether it is related with my problem or not. Do you have any ideas? Thank you very much for any suggestion! I got the same error on GRASS 6.4 when I tried to install v.krige. As an interim fix, you might consider running the trunk version of GRASS 7 as v.krige is available there. best regards, Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS7 d.mon
Yes, you're right, it doesn't display in wxGUI either - I thought that it had been working over the w/e. Daniel On Mon, Oct 14, 2013 at 11:56 AM, Martin Landa landa.mar...@gmail.comwrote: Hi, 2013/10/14 Daniel McInerney daniel.o.mciner...@gmail.com: cairo.x86_64 1.12.14-2.fc18 @updates It configured ok tho. hm, I expect that displaying rasters from wxGUI also doesn't work, right? Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS7 d.mon
Many thanks Martin, that revision has solved the problem. Daniel On Mon, Oct 14, 2013 at 3:21 PM, Martin Landa landa.mar...@gmail.comwrote: Hi, 2013/10/14 Daniel McInerney daniel.o.mciner...@gmail.com: Yes, you're right, it doesn't display in wxGUI either - I thought that it please try r57994. It should at least print more details in error message. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS7 d.mon
ok. the only difference this time, is that i passed --with-cairo to ./configure. Having said that the previous install had cairo support. I also updated the region settings before running d.rast. Daniel On Mon, Oct 14, 2013 at 5:38 PM, Martin Landa landa.mar...@gmail.comwrote: Hi Daniel, 2013/10/14 Daniel McInerney daniel.o.mciner...@gmail.com: Many thanks Martin, that revision has solved the problem. in this revision I just changed the error message to report more detailed info about failure. So it cannot be the reason why it's working now for you. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Joining vectors by location
Hi Daniel. You should use v.rast.stats [1] as it Calculates univariate statistics from a raster map based on vector polygons and uploads statistics to new attribute columns. Should be a more straight forward approach. Best Regards, Daniel. [1] http://grass.osgeo.org/gdp/html_grass64/v.rast.stats.html On Mon, Nov 21, 2011 at 3:40 PM, Daniel Lee l...@isi-solutions.org wrote: Hi group, Does anyone have a good idea of how to join vector areas by location? I'm trying to do aggregated statistics on vector maps using extracted values from rasters. I want the sum of the raster cells that lie within the vectors to be inserted into the vector attribute table. So far I've done stuff along these lines, but it's got a problem, and the main problem is that when I convert the rasters to polygons the polygons end up with stair-like boundaries rather than the smooth boundaries they had before they were converted to rasters. A second problem if I overlay the stair-like polygons over the original areas, the product of v.overlay is two polygons with a single centroid, which is absolutely wrong. Here's what I've been doing: 1. Convert the polygons to rasters with v.to.rast 2. Convert the rasters that I want to sum into the polygons to integers with r.mapcalc 3. Find the sums of the rasters for each polygon (in raster form) with r.statistics 4. Extract the summed values from the product of r.statistics with r.mapcalc, so that each polygon has the sum from the rasters as its value for all pixels. 5. Convert the rasters to vectors with r.to.vect -- This is where the first problem comes up - the boundaries are very jagged. 6. Connect the attributes with v.overlay -- Second problem: I get all the boundaries, not just the smooth ones or the jagged ones. Ideas: - Extract the centroids from the polygons and then join the polygon tables (extract the centroids with v.select, then use v.overlay? And as a last step use v.db.join to join the new values to the old geometries and get rid of the jagged boundaries? - Convert the rasters to points and then sum them inside the polygons? With what tool? Problems: - How can I connect the tables that no longer have thematic connections by the position of the geometries they belong to? I can connect the tables to the geometries by adding a layer to the map, but then I can't e.g. add the values of different fields together. I'm kind of at a loss. Thanks a lot fo the help! Daniel -- B.Sc. Daniel Lee Geschäftsführung für Forschung und Entwicklung ISIS - International Solar Information Solutions Deutschhausstr. 10 35037 Marburg Festnetz: +49 6421 379 6256 Mobil: +49 176 6127 7269 E-Mail: l...@isi-solutions.org Web: http://www.isi-solutions.org ISIS wird gefördert durch die Bundesrepublik Deutschland, Zuwendungsgeber: Bundesministerium für Wirtschaft und Technologie aufgrund eines Beschlusses des Deutschen Bundestages, sowie durch die Europäische Union, Zuwendungsgeber: Europäischer Sozialfonds. Zusätzliche Unterstützung erhält ISIS von dem Entrepreneurship Cluster Mittelhessen, der Universität Marburg, dem Laboratory for Climatology and Remote Sensing und dem GIS-Lab Marburg. ___ 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] Joining vectors by location
Hi Daniel, According to the documentation of [1] and previous discussions [2], v.rast.stats2 should be a lot faster. You should be able to change the BASECOLS variable in the script to only output the sums, which might speed things up for you. Hope that helps. Regards, Daniel. [1] http://grass.osgeo.org/wiki/GRASS_AddOns#v.rast.stats2 [2] http://osgeo-org.1803224.n2.nabble.com/faster-than-v-rast-stats-td6500105.html On Mon, Nov 21, 2011 at 4:10 PM, Daniel Lee l...@isi-solutions.org wrote: Hi Daniel, Very cool name :) You should use v.rast.stats [1] as it Calculates univariate statistics from a raster map based on vector polygons and uploads statistics to new attribute columns. Should be a more straight forward approach. Thanks for the tip, but v.rast.stats gives me all univariate statistics and takes a really long time (hours vs. seconds). I've got so many pixels that I get segmentation failures and in the end I only want the sums for each polygon. It also makes it a pain to delete the unneeded columns from the vector table afterwards. Or is there a way to only have v.rast.stats give me the sums? Thanks, Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is it possible to export a Raster to KML
Hi Katrin, Yes, it's possible using the r.out.kml add-on, see [1][2] [1] http://grass.osgeo.org/wiki/GRASS_AddOns#r.out.kml [2] http://osgeo-org.1803224.n2.nabble.com/KML-generator-for-GRASS-6-4-td4548193.html Regards, Daniel. On Mon, Oct 24, 2011 at 1:40 PM, katrin eggert katrineggert1...@gmail.comwrote: Greetings I have a raster mapthat I want to create an overlay in a KML file. Is it possible to do this with GRASS? if not, as anyone as an alternative to use? Thanks Kat ___ 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 to calculate SUM of an image
Hi Kim, What about using r.sum [1] or r.univar [2] ? Regards, Daniel [1] http://grass.osgeo.org/grass64/manuals/html64_user/r.sum.html [2] http://grass.osgeo.org/grass64/manuals/html64_user/r.univar.html On Mon, Oct 3, 2011 at 3:08 PM, Kim Besson kimbesson1...@gmail.com wrote: Greetings I have a raster map and I wan to calculate its sum. How can I do this in GRASS? Thanks Kim ___ 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] Conversion of multiple rasters to PNG files
Hi, you could use the following bash for loop as a basis for what you want to do: for file in `g.mlist rast pattern=searchpattern*`; do r.out.png input=$file output=/tmp/$file.png; done Regards, Daniel On Tue, Apr 12, 2011 at 5:10 AM, Mortsde alex.mort...@gmail.com wrote: Hi Community, I'm relatively new to GRASS/unix style commands and was wondering if anyone had a quick PERL script that could convert LOTS of raster maps to PNG files without the repetition of going through one by one. I'm not much of a programmer otherwise I'd write some kind of loop and have a go. The general form of my rasters is already in a Name_$Date style format so I think this should be pretty easy? I'm attempting to make video files that illustrate soil saturation with time. I have about 10 years (daily) of soil moisture that I'm looking to animate so it's a digestible amount of information. Thanks for reading/advice! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Conversion-of-multiple-rasters-to-PNG-files-tp6263692p6263692.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 mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.kappa query
Hi list, I have a query regarding the error matrix produced using r.kappa (in GRASS 6.4.0 RC6) and hoping that the following will help someone to replicate my findings. From what I see, the error matrix is mis-labeling the rows/columns in the matrix. Using the spearfish dataset, I digitised 18 points to create a reference dataset to validate the classification, in this case the raster 'landcover.orig' For the purposes of the test and simplicity, I ensured that the points were located within two landcover classes (raster values 42 and 81). The following steps were carried out to generate the output from r.kappa #Create reference dataset d.where | r.what input=landcover.orig kappa_test.txt For the purposes of this test, I deliberately changed the landcover class from 42 to 32 in the validation dataset [1] This will create an off-diagonal value in the error matrix. #Create the vector point from ascii and convert to raster v.in.ascii input=kappa_test output=kapp_test cat=4 v.to.rast input=kapp_test output=validation use=cat #Run r.kappa r.kappa classification=landcover.orig reference=validation output=validation.txt The output from r.kappa (validation.txt) is below, however, it appears to me that the matrix is transposed, i.e. the horizontal values (MAP1) should in fact be vertical. From my interpretation, the error matrix indicates that 8 validation points with the value 42 were classified as 32, but in fact it should state that 8 points with the value of 32 were classified as 42? Can anyone confirm my findings? Thanks in advance. Regards, Daniel. ACCURACY ASSESSMENT LOCATION: spearfish60 Fri Apr 1 12:45:42 2011 MASK: none MAPS: MAP1 = Categories (validation in user1) MAP2 = (untitled) (landcover.orig in PERMANENT) Error Matrix Panel #1 of 1 MAP1 cat# 32 42 81 Row Sum M320 8 0 8 A420 0 0 0 P810 0 10 10 Col Sum 0 8 10 18 Cats% Commission% Ommission Estimated Kappa 32 100.00 -nan-999.00 42 NA NA NA 81 0.000.001.00 Kappa Kappa Variance 0.3571430.002343 Obs Correct Total Obs % Observed Correct 10 18 55.56 [1] #validation input 590188.6875|4919453.8125||32 590188.6875|4918947||32 590307.9375|4918350.75||32 590576.25|4917694.875||32 590307.9375|4917694.875||32 590546.4375|4919364.375||32 590874.375|4919364.375||32 590904.1875|4919483.625||32 603604.3125|4922047.5||81 603336|4922315.8125||81 603514.875|4922464.875||81 603604.3125|4922256.1875||81 603634.125|4922107.125||81 603693.75|4921987.875||81 603962.0625|4921987.875||81 603753.375|4921600.3125||81 603962.0625|4922047.5||81 598983.375|4922256.1875||81 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.kappa query
Thanks for your email Markus. That's a necessary fix to r.kappa - one that may not be immediately obvious if the errors of omission and commission are more evenly dispersed between classes. Regarding the individual class errors, would it make sense to simplify or standardise the values: -999.; -nan and NA that are each reported within the r.kappa output? Regards, Daniel. On Fri, Apr 1, 2011 at 3:42 PM, Markus Metz markus.metz.gisw...@googlemail.com wrote: On Fri, Apr 1, 2011 at 2:45 PM, daniel mcinerney daniel.o.mciner...@gmail.com wrote: Hi list, I have a query regarding the error matrix produced using r.kappa (in GRASS 6.4.0 RC6) and hoping that the following will help someone to replicate my findings. From what I see, the error matrix is mis-labeling the rows/columns in the matrix. Right, I noticed that some months ago, but fixed it only in grass 7. Now also fixed in 6.5 and 6.4 (r45818 and r45819, respectively). Markus M Using the spearfish dataset, I digitised 18 points to create a reference dataset to validate the classification, in this case the raster 'landcover.orig' For the purposes of the test and simplicity, I ensured that the points were located within two landcover classes (raster values 42 and 81). The following steps were carried out to generate the output from r.kappa #Create reference dataset d.where | r.what input=landcover.orig kappa_test.txt For the purposes of this test, I deliberately changed the landcover class from 42 to 32 in the validation dataset [1] This will create an off-diagonal value in the error matrix. #Create the vector point from ascii and convert to raster v.in.ascii input=kappa_test output=kapp_test cat=4 v.to.rast input=kapp_test output=validation use=cat #Run r.kappa r.kappa classification=landcover.orig reference=validation output=validation.txt The output from r.kappa (validation.txt) is below, however, it appears to me that the matrix is transposed, i.e. the horizontal values (MAP1) should in fact be vertical. From my interpretation, the error matrix indicates that 8 validation points with the value 42 were classified as 32, but in fact it should state that 8 points with the value of 32 were classified as 42? Can anyone confirm my findings? Thanks in advance. Regards, Daniel. ACCURACY ASSESSMENT LOCATION: spearfish60 Fri Apr 1 12:45:42 2011 MASK: none MAPS: MAP1 = Categories (validation in user1) MAP2 = (untitled) (landcover.orig in PERMANENT) Error Matrix Panel #1 of 1 MAP1 cat# 32 42 81 Row Sum M320 8 0 8 A420 0 0 0 P810 0 10 10 Col Sum 0 8 10 18 Cats% Commission% Ommission Estimated Kappa 32 100.00 -nan-999.00 42 NA NA NA 81 0.000.001.00 Kappa Kappa Variance 0.3571430.002343 Obs Correct Total Obs % Observed Correct 10 18 55.56 [1] #validation input 590188.6875|4919453.8125||32 590188.6875|4918947||32 590307.9375|4918350.75||32 590576.25|4917694.875||32 590307.9375|4917694.875||32 590546.4375|4919364.375||32 590874.375|4919364.375||32 590904.1875|4919483.625||32 603604.3125|4922047.5||81 603336|4922315.8125||81 603514.875|4922464.875||81 603604.3125|4922256.1875||81 603634.125|4922107.125||81 603693.75|4921987.875||81 603962.0625|4921987.875||81 603753.375|4921600.3125||81 603962.0625|4922047.5||81 598983.375|4922256.1875||81 ___ 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] i.cluster not working in GRASS 7
Hi Ned, I have been using i.cluster in GRASS 7 on a 64-bit fedora server, without any trouble. However, I managed to replicate your problem and create a single class output by setting the parameter 'sample=5,5' as you had done in your example. If I run i.cluster without that parameter, the signature file and classification output both have the number of predefined classes. Can you see if this helps with your data? Regards, Daniel. On Thu, Feb 17, 2011 at 7:49 PM, Ned Horning horn...@amnh.org wrote: Hi - I would like to do an unsupervised classification using i.cluster from GRASS 7 on my Ubuntu 64-bit machine. When I run i.cluster then i.maxlik on a Landsat image I only get one output class, the entire image. Only one class appears in the signature file so the problem is with the i.cluster step. I tried running i.cluster on different images and always get just one class. Here is the command line I'm using: i.cluster group=TM_r15c33@PERMANENT subgroup=AllBands signaturefile=IsoDataSigs2 classes=20 sample=5,5 convergence=99.9 min_size=1 Is anyone able to get i.cluster to work properly? It would be helpful to know if it's a user problem or a bug. Thanks in advance to anyone who can help. All the best, Ned ___ 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] Calculate averagfe of raster maps without mapcalc
Hi Kim, You can use r.univar to compute univariate statistics of your raster data. http://grass.fbk.eu/grass65/manuals/html65_user/r.univar.html Regards, Daniel. On Wed, Feb 16, 2011 at 2:31 PM, Kim Besson kimbesson1...@gmail.com wrote: Greetings I need to calculate the average of a set of raster images. How can I calculate it without using mapcalc? THanks Kim ___ 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] Produce KML/KMZ files in GRASS
Hi Monica, You can use r.out.kml [1] to export GRASS rasters to kml. [1] http://grass.osgeo.org/wiki/GRASS_AddOns#r.out.kml Regards, Daniel. On Thu, Jan 13, 2011 at 1:03 PM, Monica Buescu monicabuescu1...@gmail.comwrote: Greetings I would like to know if it's possible to produce KML/KMZ files from a raster file in GRASS? If not, what tool do you advise? Thanks Monica ___ 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] v.out.ogr issue
Hi List, I'm having trouble exporting a GRASS vector file using v.out.ogr. The file contains 1 million areas and its attributes are stored in a postgresql table (view of joined tables and connected to geometry using v.db.connect). When I run the following command: v.out.ogr -c type=area input=g1km dsn=/tmp/shp I get the following error: 99% dbmi: Out of Memory ERROR: Cannot select attributes for cat = 991956 I can successfully create the shp file using the above procedure for a small vector file containing 400 areas, but I'm wondering if it's possible to export the large dataset? I'm running GRASS 6.5.svn on Linux and have compiled it with --enable-largefile. Thanks in advance, Daniel. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Difficulties with i.pr
Hi Joel - Sorry for the late reply. I only managed to successfully run i.pr.training and i.pr.features. I tried the image classification, but it threw too many errors. I haven't looked at i.pr for a while, but may revisit it when time permits. Best Regards, Daniel. joel dinis wrote: Hello Daniel, Thank you for the thread. I'm working with polygons. Did you classify any image with the i.pr? JD On Mon, Apr 12, 2010 at 4:36 PM, Daniel McInerney daniel.mciner...@ucd.iewrote: Hi Joel, I did some work with i.pr a while back, but was unsuccessful in getting it to fully work. Is your vector file a point or polygon? I tested i.pr.training with points. You might get some ideas from this thread: http://www.mail-archive.com/grass-user@lists.osgeo.org/msg00153.html Regards, Daniel. joel dinis wrote: Hello to all, Does anyone knows any working example of the i.pr add-on? I have install it, and I'm having some problems with the i.pr.training. I do: i.pr.training map=lis...@p9,lis...@p9,lis...@p9,lis...@p9training=iprteste9 vector=area1 rows=3 cols=3 class=0 And the iprteste9 only has this: Data type: GrassTraining Number of layers: 4 Label: /home/joel/iprteste9 Data: Layer_1Layer_2Layer_3Layer_4ClassEastNorth RowsColsEW-resNS-res And nothing else. I suppose that the file would have something more. Can anyone help me? ___ 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] Difficulties with i.pr
Hi Joel, I did some work with i.pr a while back, but was unsuccessful in getting it to fully work. Is your vector file a point or polygon? I tested i.pr.training with points. You might get some ideas from this thread: http://www.mail-archive.com/grass-user@lists.osgeo.org/msg00153.html Regards, Daniel. joel dinis wrote: Hello to all, Does anyone knows any working example of the i.pr add-on? I have install it, and I'm having some problems with the i.pr.training. I do: i.pr.training map=lis...@p9,lis...@p9,lis...@p9,lis...@p9 training=iprteste9 vector=area1 rows=3 cols=3 class=0 And the iprteste9 only has this: Data type: GrassTraining Number of layers: 4 Label: /home/joel/iprteste9 Data: Layer_1Layer_2Layer_3Layer_4ClassEastNorth RowsColsEW-resNS-res And nothing else. I suppose that the file would have something more. Can anyone help me? ___ 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] problem with spgrass6
Hi Leo, these type of questions are best sent to the grass-st...@list.osgeo.org [1] list (cc'd here), which discusses GRASS-GIS, R spgrass6 issues. What does sessionInfo() give? Best Regards, Daniel. [1] http://www.osgeo.org/mailman/listinfo/grass-stats Leo Hardtke wrote: Hi list, I am using spgrass6 in a grass6.4-R2.9.2 on Ubuntu 9.10 without problems / //x=readRAST6(c(raster.a,raster.b))/ but when i run the same line in grass65svn it gives an error with some rasters(DCELL)... (and other are imported without problems(DCELL too)) /CPL ERROR 4: `/media/COMP/grassdb//hardtke/Bisigato/.tmp/rs7/ndvi_sum' does not exist in the file system, and is not recognised as a supported dataset name. Error en .local(.Object, ...) : `/media/COMP/grassdb//hardtke/Bisigato/.tmp/rs7/ndvi_sum' does not exist in the file system, and is not recognised as a supported dataset name. /Any idea? Is it a grass65 bug? or my fault? Leo Hardtke ___ 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] KML generator for GRASS 6.4
Hi Luis, You should be able to export GRASS vectors to KML using v.out.kml [1] or v.out.ogr [1] [1] http://grasslab.gisix.com/scripts/v.out.kml/ [2] http://grass.itc.it/gdp/html_grass64/v.out.ogr.html Regards, Daniel. Luis Lisboa wrote: Greetings I would like to know if there is any module/function already developed to parse data (images, vectorials) to a KML file (Google Earth)? Thank you Best regards, Luis ___ 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 tools for palsar/radar images
Hi Maning, I'm not aware of any GRASS tools to process radar data, but you could have a look at Polsarpro [1], which handles ALOS Palsar data and is available for various operating systems. Best [2] might also be of use if you're using ASAR data. [3] is referenced in Markus and Helena's book and you may find some useful tools there. Regards, Daniel. [1] http://earth.esa.int/polsarpro/ [2] http://earth.esa.int/services/best/ [3] http://www.asf.alaska.edu/sardatacenter/?q=softwaretools maning sambale wrote: Hi, I'm looking for some tools in processing radar/palsar data. pre-processing, image classification, etc. So far, I found RAT radartools http://srv-43-200.bv.tu-berlin.de/rat/index.php Any GRASS user doing radar processing? cheers, maning ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
