Re: [GRASS-user] NASA to release no cost 30m DEMs with world-wide coverage on 29 June
Thanks, Michael. That's great news. What do you make of the 20 m./30 m. vertical/horizontal accuracy statement? Isn't SRTM supposed to be around 15 m. vertical and 10 m. horizontal (even tho' it's 90 m. resolution)? Regards, Micha Michael Barton wrote: See the following announcement. NASA (USA) will release high resolution DEM's of the globe, produced from the Terra ASTER satellite, at no charge. You can check out the web announcement at https://lpdaac.usgs.gov/lpdaac/about/news_archive/monday_june_22_20092. As a Terra ASTER user, I've been using the DEM's for several years and found them to be a very good high-resolution (30x30m) topography source. Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Point attributes to a polygons
On 25/06/09 10:58, xavier garcia acosta wrote: Hello everybody, I'm working with cadastre information and I've got the next problem. I've the polygons that represent the plots of the houses but without any attribute. I've also the points with the attributes of the previous polygons. That I would like to do is to add the attributes of the points to the polygons. Has anybody got any idea how to do it? If the points are within the polygons, you can also try with v.distance from=points to=polygons [...] upload=to_attr to_column=cat to load the cat values of the polygons into the attribute table of the points. Then you can use v.db.connect to connect the attribute table of the points to that of the polygons via the polygon cat value. You might want to copy the table (db.copy) before connecting it, in order not to use the same attribute table with the points and polygon layer (if you erase one of the two layers, you will also erase the attribute table...). Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
On 23/06/09 17:42, Falko Engel wrote: Dear List, I have some problems with tables stored in PostgreSQL database. I'm using openSUSE 11.1 (and 10.3), PostgreSQL 8.2.13 and GRASS GIS 6.4.0RC4 My default db connection for my mapsets is set to postgresql. I am using schemas within the database corresponding to the mapsets. So my mapset forest has a corresponding schema forest in the database where all the forest-tables should be stored. Problem 1: After dissolving with v.extract -d using the new= parameter I tried to use v.db.addtable to create a table for my dissolved map. This has to be done, as far as I understood, since the new= parameter of v.extract results in maps without tables. Now v.db.addtable creates the table, but doesn't put it in the right database schema. It is created in the schema public2 and not in the schema 2forest, where it should be. Although db.connect -p verifys that all connection parameters are correctly set. I guess using v.extract without dissolving and doing that later using v.dissolve will solve the problem. I was just wondering if anyone experienced the same issues with the schemas and if there is a solution to this. I guess this is a bug in v.db.addtable (which is just a script). It uses: echo CREATE TABLE $table ($COLUMN_DEF) | db.execute database=$database driver=$driver to create the table, and so does not take into account the schema. Should be easy to fix, but no time now. Please post a bug report about this, so that it is not forgotten. Problem 2: This is really confusing me. I tried to use the capability of linking more than one attribute table to a map. Overall I succeded doing so. Grass reports (in german): ... v.db.connect -o map=trees_geo_init key=cat_id layer=3 table=forest.trees_buche Just adding a database connection to a layer does not add any features to that layer. In order for features to appear in a specific layer, you have to give them a category value in that layer, i.e. with v.category. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
Hi all, I think I am not the only one having problems with getting the connection vector geometry features - attribute table (for me its a sqlite db at the moment). ;-) So I wonder how is the default way to deal with vector layers to establish a metadata table to each geometry object? I always have the problem that the table is empty. And adding category is not enough to add an entry for every geometry object... well. Achim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
On 26/06/09 11:30, achim wrote: Hi all, I think I am not the only one having problems with getting the connection vector geometry features - attribute table (for me its a sqlite db at the moment). ;-) So I wonder how is the default way to deal with vector layers to establish a metadata table to each geometry object? Normally, categories are added and a table is automatically created at vector import, or, by default, at digitalisation. But some modules do not create a table as they wouldn't know what to put in it (and a table with just cat values is not very useful as such). I always have the problem that the table is empty. And adding category is not enough to add an entry for every geometry object... well. After adding the category, you have to upload it to the table with v.to.db. If you do not even have a table connected to the map, you can run the script v.db.addtable which creates the table (by running an SQL query) and then adds the category values to it (with v.to.db). Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net.salesman problem: number of cities [0]
On 24/06/09 19:46, Marco Lechner - FOSSGIS e.V. wrote: hi list, I've got a little net of ways and try to calculate a route from it. all the crossroads and all the ends of culs-de-sac have to be reached. according to the syntax of traveling-salesman-problem each cul-de-sac and crossroad is a city. I tried the following: - import of the ways using v.in.ogr - v.clean.break to segment the ways at crossroads - v.net.nodes to create arcs and nodes of the net (looks o.k.) I guess you mean v.net operation=nodes ? What is the exact command line you use ? - v.net.salesman input=net_nodes alayer=1 nlayer=0 ccats=0 output=net_salesman By default, nlayer should be 2 and ccats has to list the cat values of the nodes you want to include in your salesman journey. If you just want to include all nodes, use ccats=1-. to get the solution, but instead I get the following error message: Number of cities: [0] ERROR: Not enough cities ( 2) although layer_0 consists of 4 nodes (two at ends of cul-de-sac and two crossroads. What is layer_0 and how do you see that it contains the nodes ? In addition to that the cat-row is 0 at every node. Again, could you tell us how you get that info ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Importing .csv table into GRASS
On 26/06/09 10:34, JanaKr wrote: Hello, I am trying to import a simple okresy.csv table, the first few lines of which are: CAT,AREA,PERIMETER,CISLO_OKR,SO2_KG,SO2_OBYV 64,9485480,15278.33,101,3384,0.08 66,92488080,53576.26,102,3384,0.03 62,74758064,39651.84,103,3384,0.05 63,96450584,56394.8,104,3384,0.04 Using db.in.ogr okresy.csv out=okresy returns error message: Input table okresy.csv not found or not readable I am using Linux installation of GRASS 6.3, I tried to use full path to the .csv file, I tried to move it to current directory, but the message was always the same. Then I thought maybe my .csv file is not OK ... so I checked the http://www.gdal.org/ogr/drv_csv.html, but seems OK. Does anyone have any clue? use v.in.ascii ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
Yes, thanks, but how to force that every single geometry object (of one kind) gets an entry? Achim (just to mention: And why aren't those commands reachable in an useful order? One always has to check whether the table are built, go and add a table, on another place set connection, on another place load up cats...alway confusing and lots of clicking in the gui) Moritz Lennert wrote: On 26/06/09 11:30, achim wrote: Hi all, I think I am not the only one having problems with getting the connection vector geometry features - attribute table (for me its a sqlite db at the moment). ;-) So I wonder how is the default way to deal with vector layers to establish a metadata table to each geometry object? Normally, categories are added and a table is automatically created at vector import, or, by default, at digitalisation. But some modules do not create a table as they wouldn't know what to put in it (and a table with just cat values is not very useful as such). I always have the problem that the table is empty. And adding category is not enough to add an entry for every geometry object... well. After adding the category, you have to upload it to the table with v.to.db. If you do not even have a table connected to the map, you can run the script v.db.addtable which creates the table (by running an SQL query) and then adds the category values to it (with v.to.db). Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.lidar.edgedetection very slow
On 22/06/09 07:00, Michael Perdue wrote: On 19-Jun-09, at 8:54 PM, Hamish wrote: Michael wrote: I actually get the same thing. For the first while the process runs in full use of one core, but once the process starts writing results to the db, the whole process bogs down to a grinding halt. CPU usage for v.lidar.edgedetection drops down to ~1% (1% of one core) and sqlite usage rises to ~16%. Maybe I'm wrong, but my impression was that the bottle neck was the modifications to the database. hmmm. I've seen no problems on Linux64 + DBF backend. 100% core until completion. Are you running WinXP + SQlite? Can you try with the DBF driver? maybe the common problem is in the SQLite driver... ?? I'm running Mac OS X + SQLite with a 64 bit version of grass. I ran a whole bunch of tests today and it looks like there are at least a couple of things going on and SQLite is one of the issues. I ran a 500m x500m tile with three different DB back-ends (SQLite, Postgres and DBF) and these are the results I obtained; (SQLite) time v.lidar.edgedetection input=Cal_QTile output=Cal_QTile_edges real38m53.458s user1m17.602s sys4m6.353s (Postgres) time v.lidar.edgedetection input=Cal_QTile output=Cal_QTile_edges real6m49.060s user0m46.622s sys1m20.324s (DBF) time v.lidar.edgedetection input=Cal_QTile output=Cal_QTile_edges real1m54.065s user0m48.530s sys1m8.686s The results with Postgres and SQLite were a real surprise to me. As Hamish already mentioned, the main bottleneck here is the connection to the database which is much slower for actual database systems than for simple file-based DBF. Looking at the code, I see lots of calls to the Insert(), InsertInterpolation() and UpDate() functions. At each call you are hit with the overhead of the database connection. I don't know the code at all, but it might be worth thinking about grouping these database calls, possibly by putting all the SQL statements into a temp file and executing that only once at the end. In scripts doing this has lead to significant speed gains. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] table entry for every geometry object(s id)
...I mean: how to get an table entry for every vector objects Id? (every geometry object has an unique id) achim wrote: Yes, thanks, but how to force that every single geometry object (of one kind) gets an entry? Achim (just to mention: And why aren't those commands reachable in an useful order? One always has to check whether the table are built, go and add a table, on another place set connection, on another place load up cats...alway confusing and lots of clicking in the gui) Moritz Lennert wrote: On 26/06/09 11:30, achim wrote: Hi all, I think I am not the only one having problems with getting the connection vector geometry features - attribute table (for me its a sqlite db at the moment). ;-) So I wonder how is the default way to deal with vector layers to establish a metadata table to each geometry object? Normally, categories are added and a table is automatically created at vector import, or, by default, at digitalisation. But some modules do not create a table as they wouldn't know what to put in it (and a table with just cat values is not very useful as such). I always have the problem that the table is empty. And adding category is not enough to add an entry for every geometry object... well. After adding the category, you have to upload it to the table with v.to.db. If you do not even have a table connected to the map, you can run the script v.db.addtable which creates the table (by running an SQL query) and then adds the category values to it (with v.to.db). Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.roughness needs bc
Hello all, I'm trying to use r.roughness on windows vista, built from the osgeo4w. Unfortunately we get the following message: ./r.roughness map=Rough3 grid=0.03 rough=Rough3.roughness.3 /which: bc: unknown command r.roughness: bc required, please install it first/ / / /What is bc?/ /Where can I get this?/ / / /best regards!/ / / /Manuel/ // // // -- __ Dr. Manuel Seeger Dept. of Land Degradation and Development Wageningen University Researchcenter Postal address: P.O. Box 47, 6700 AA Wageningen, The Netherlands Visitors address: Atlas building, Droevendaalsesteeg 4, 6708 PB, room B415 phone: + 31 317 486617 fax: + 31 317 419000. __ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
On 26/06/09 12:10, achim wrote: Yes, thanks, but how to force that every single geometry object (of one kind) gets an entry? It might help if you could tell us exactly what you are trying to do. If I understand your question correctly, you need to make sure that all geometry objects for which you wish to have an entry have a category value: v.category in=MapWithoutCats option=add out=MapWithCats Then you have to create a table to hold the attribute values: echo create table MapWithCats (cat integer) | db.execute which you then connect to your map: v.db.connect -o MapWithCats table=MapWithCats key=cat and fill with cat values v.to.db MapWithCats option=cat column=cat The three last steps are all done for you by the script module v.db.addtable. The first one is left for you since only you can decided which objects in your map should be included. Or you can use the new wxpython GUI to quite easily create a new table and connect the map to that table (both in the Manage layers tab). (just to mention: And why aren't those commands reachable in an useful order? Define a useful order. One always has to check whether the table are built, go and add a table, on another place set connection, In the wxpython GUI these two steps are two clicks in one tab of the table manager. on another place load up cats...alway confusing and lots of clicking in the gui) As already mentioned, v.db.addtable (in the GUI: Databases-Manage databases-New table) does all of this for you in one single run. Maybe you should explain your entire workflow a bit more, and where exactly you encounter difficulties, but I've always found the default settings to work in 95% of cases... Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.net.visibility with obstacles that are not included as points
Take the following use case: I want to verify which antennas (points) on a certain site actually 'see' each other and for which visibility is blocked by buildings (areas). So, I would like to take my point map and submit it to v.net.visibility, telling it that it should use the area map as obstacles. However, v.net.visibility does not work that way: I have to patch the point and the area map and submit the patched map to v.net.visibility, but then all the nodes of the polygons are also integrated into the visibility analysis, i.e. I get the visibility network not only between my antennas, but also between all polygon corners and between the antennas and the polygon corners. Am I misunderstanding the use of v.net.visibility, or is this something that could be envisaged (i.e. should I post an enhancement ticket in trac) ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Grass osgeo4w does not like python(x,y)
Hi list, I'm using a python distribution know as python(x,y), which mimics some matlab like funcionability in my WinXP box. It uses python version 2.5.4. I then installed Grass 6.4 from OsGeo4W and when I try to run grass wxpython I get the following error message (badly translated from portuguese) popping up: Entry point not found: It was not possible to locate entry point of the procedure ?PyLong_FromTwoInts@@YAPAU_object@@h...@z in pywintypes25.dll in the command prompt I see: GRASS 6.4.0svn (utm23) Traceback (most recent call last): File C:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/wxpython/wxgui.py, line 70, in module import gui_modules.utils as utils File C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gui_modules\utils.py, line 26, in module import gcmd File C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gui_modules\gcmd.py, line 44, in module from win32file import ReadFile, WriteFile ImportError: DLL load failed: NÒo foi possÝvel encontrar o procedimento especifi cado. The error in portuguese translates to: DLL load failed: It was not possible to locate the specified procedure Cheers and thanks Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
Hi Moritz, thanks for reply and this detailed explanation. I try to report my problem with an example: reset to initial point v.db.connect -d map=my_li...@achim db.droptable -f table=testtable my_lines: | Type of Map: vector (level: 2) | | Number of points: 0 Number of areas: 0 | Number of lines:2326Number of islands:0 | Number of boundaries: 0 Number of faces: 0 | Number of centroids:0 Number of kernels:0 | Map is 3D: No | Number of dblinks: 0 Number of nodes: 2410 (with grass65 wx-gui) v.db.addtable map=my_li...@achim table=testtable Using user specified table name: testtable Creating new DB connection based on default mapset settings... Creating table with columns (cat integer) The table testtable is now part of vector map my_li...@achim and may be deleted or overwritten by GRASS modules Select privileges were granted on the table Reading features... Updating database... 0 categories read from vector map (layer 1) 0 records updated/inserted (layer 1) Current attribute table links: layer 1 table testtable in database /home/achim/grass/sqlite_db through driver sqlite with key cat Vector map my_li...@achim is connected by: ?here no records updated/inserted (with grass65 wx-gui) v.to.db map=my_li...@achim type=line option=cat Reading features... Updating database... 0 categories read from vector map (layer 1) 0 records updated/inserted (layer 1) ?here no records updated/inserted again (The Table Manager shows no entries as well) ...Seems like there is something wrong up to here. Achim PS: Later I try do define a useful order. But first I have to understand.. Moritz Lennert wrote: On 26/06/09 12:10, achim wrote: Yes, thanks, but how to force that every single geometry object (of one kind) gets an entry? It might help if you could tell us exactly what you are trying to do. If I understand your question correctly, you need to make sure that all geometry objects for which you wish to have an entry have a category value: v.category in=MapWithoutCats option=add out=MapWithCats Then you have to create a table to hold the attribute values: echo create table MapWithCats (cat integer) | db.execute which you then connect to your map: v.db.connect -o MapWithCats table=MapWithCats key=cat and fill with cat values v.to.db MapWithCats option=cat column=cat The three last steps are all done for you by the script module v.db.addtable. The first one is left for you since only you can decided which objects in your map should be included. Or you can use the new wxpython GUI to quite easily create a new table and connect the map to that table (both in the Manage layers tab). (just to mention: And why aren't those commands reachable in an useful order? Define a useful order. One always has to check whether the table are built, go and add a table, on another place set connection, In the wxpython GUI these two steps are two clicks in one tab of the table manager. on another place load up cats...alway confusing and lots of clicking in the gui) As already mentioned, v.db.addtable (in the GUI: Databases-Manage databases-New table) does all of this for you in one single run. Maybe you should explain your entire workflow a bit more, and where exactly you encounter difficulties, but I've always found the default settings to work in 95% of cases... Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Grass osgeo4w does not like python(x,y)
Replying to my own email I replaced the the pywintypes25.dll in c:/windows/system32 with the one that came with OSGeo4W. Now everything (Grass wxpython and python(x,y)) is working swell, AFAICT. Cheers Daniel On Fri, Jun 26, 2009 at 9:47 AM, Daniel Victoriadaniel.victo...@gmail.com wrote: Hi list, I'm using a python distribution know as python(x,y), which mimics some matlab like funcionability in my WinXP box. It uses python version 2.5.4. I then installed Grass 6.4 from OsGeo4W and when I try to run grass wxpython I get the following error message (badly translated from portuguese) popping up: Entry point not found: It was not possible to locate entry point of the procedure ?PyLong_FromTwoInts@@YAPAU_object@@h...@z in pywintypes25.dll in the command prompt I see: GRASS 6.4.0svn (utm23) Traceback (most recent call last): File C:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/wxpython/wxgui.py, line 70, in module import gui_modules.utils as utils File C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gui_modules\utils.py, line 26, in module import gcmd File C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gui_modules\gcmd.py, line 44, in module from win32file import ReadFile, WriteFile ImportError: DLL load failed: NÒo foi possÝvel encontrar o procedimento especifi cado. The error in portuguese translates to: DLL load failed: It was not possible to locate the specified procedure Cheers and thanks Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.select: exact meaning of disjoint operator
What exactly does the disjoint operator do in the GEOS operators of v.select (6.5+) ? It is described as disjoint - features do not spatially intersect Which sounds pretty much like the reverse of the intersect operator. However, when I try the following in the nc_spm_06 NC data set: v.extract input=roadsma...@permanent output=cary list=1004 v.select -g ainput=roadsma...@permanent atype=line binput=c...@user1 btype=area output=roads_disjoint_cary operator=disjoint I get: http://geog-pc40.ulb.ac.be/grass/misc/disjoint.png whereas v.select -r -g ainput=roadsma...@permanent atype=line binput=c...@user1 btype=area output=roads_reverse_intersect_cary operator=intersects gives me: http://geog-pc40.ulb.ac.be/grass/misc/reverse_intersect.png Is this a bug in the disjoint operator, or am I misinterpreting its meaning ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.delaunay Bug in Mac OS X
Hello all, Last week I asked the author of the new v.delaunay if he could have a look at this, but I haven't heard back from him yet. FWIW I can't reproduce the problem with today's 6.4 release branch on a 32-bit Linux system (Slackware 12.2). On Tue, 16 Jun 2009, William Kyngesburye wrote: I don't see any changes in v.delaunay itself from RC4, though maybe there are changes in the vector libraries. Did this work in RC4? A big difference in RC5 for OSX is that it's now 64bit. Does this affect all builds on OS X? If so, it seems like a rather drastic change when the 6.4 release branch is in critical bugfix only mode preparing for release - I fear a change to 64-bit binaries could trigger obscure bugs that might not be found for a long time. Not something to do just before the release IMHO. Paul ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] WXGui inform of MASK raster
Hi, I'm using grass6.4 from OSGeo4W (winXP) and just noticed that it would be nice to have something in the wxgui or terminal telling us when a MASK is in place. I don't see any warning if I create the mask using either the gui or comand line command. I tryed to file a wish on trac but somehow I could not get it done Thanks Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
Thats exactly the problem: It shows nothing. None of my lines has any cat. Achim Moritz Lennert wrote: On 26/06/09 15:24, achim wrote: Hi Moritz, thanks for reply and this detailed explanation. I try to report my problem with an example: reset to initial point v.db.connect -d map=my_li...@achim db.droptable -f table=testtable my_lines: | Type of Map: vector (level: 2) | | Number of points: 0 Number of areas: 0 | Number of lines:2326Number of islands:0 | Number of boundaries: 0 Number of faces: 0 | Number of centroids:0 Number of kernels:0 | Map is 3D: No | Number of dblinks: 0 Number of nodes: 2410 (with grass65 wx-gui) v.db.addtable map=my_li...@achim table=testtable Using user specified table name: testtable Creating new DB connection based on default mapset settings... Creating table with columns (cat integer) The table testtable is now part of vector map my_li...@achim and may be deleted or overwritten by GRASS modules Select privileges were granted on the table Reading features... Updating database... 0 categories read from vector map (layer 1) 0 records updated/inserted (layer 1) Current attribute table links: layer 1 table testtable in database /home/achim/grass/sqlite_db through driver sqlite with key cat Vector map my_li...@achim is connected by: ?here no records updated/inserted Probably none of your lines have categories. What does v.category my_lines option=report show ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.delaunay Bug in Mac OS X
On Jun 26, 2009, at 9:21 AM, Paul Kelly wrote: Hello all, Last week I asked the author of the new v.delaunay if he could have a look at this, but I haven't heard back from him yet. FWIW I can't reproduce the problem with today's 6.4 release branch on a 32-bit Linux system (Slackware 12.2). On Tue, 16 Jun 2009, William Kyngesburye wrote: I don't see any changes in v.delaunay itself from RC4, though maybe there are changes in the vector libraries. Did this work in RC4? A big difference in RC5 for OSX is that it's now 64bit. Does this affect all builds on OS X? If so, it seems like a rather drastic change when the 6.4 release branch is in critical bugfix only mode preparing for release - I fear a change to 64-bit binaries could trigger obscure bugs that might not be found for a long time. Not something to do just before the release IMHO. Michael did try it on 32bit OSX with the same results. And also said it happened on a previous 6.4RC that was 32bit only. As far as the 'drastic' change, this was a bugfix - fixed for trunk and dev6 http://trac.osgeo.org/grass/ticket/431 and backported to release: http://trac.osgeo.org/grass/changeset/36838 I didn't see it attached to a ticket, though I did notice the backport in: http://trac.osgeo.org/grass/ticket/597 Paul ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] NASA to release no cost 30m DEMs with world-wide coverage on 29 June
I've tended to consider SRTM to have a slightly better vertical accuracy and ASTER DEM to have a better horizontal resolution. There are other differences too. ASTER DEMs are created using stereoscopic imagery (forward and backward band 3 near IR) and SRTM is radar. So ASTER DEMs are affected by clouds and by surface vegetation, and pretty much stop at the coast. Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies, School of Human Evolution Social Change Director, Center for Social Dynamics Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton On Jun 26, 2009, at 12:48 AM, Micha Silver wrote: Thanks, Michael. That's great news. What do you make of the 20 m./30 m. vertical/horizontal accuracy statement? Isn't SRTM supposed to be around 15 m. vertical and 10 m. horizontal (even tho' it's 90 m. resolution)? Regards, Micha Michael Barton wrote: See the following announcement. NASA (USA) will release high resolution DEM's of the globe, produced from the Terra ASTER satellite, at no charge. You can check out the web announcement at https://lpdaac.usgs.gov/lpdaac/about/news_archive/monday_june_22_20092 . As a Terra ASTER user, I' ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.delaunay Bug in Mac OS X
Paul, I'm just back from a conference. I'll try to build GRASS 32 bit and test to see if that fixes it. However, I thought that Linux systems had been running GRASS 64 bit for some time now. Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies, School of Human Evolution Social Change Director, Center for Social Dynamics Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton On Jun 26, 2009, at 7:38 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Fri, 26 Jun 2009 15:21:22 +0100 (BST) From: Paul Kelly paul-gr...@stjohnspoint.co.uk Subject: Re: [GRASS-user] v.delaunay Bug in Mac OS X To: William Kyngesburye kyngch...@kyngchaos.com Cc: GRASS user list grass-user@lists.osgeo.org Message-ID: pine.lnx.4.62.0906261515440.14...@vortex.ukshells.co.uk Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hello all, Last week I asked the author of the new v.delaunay if he could have a look at this, but I haven't heard back from him yet. FWIW I can't reproduce the problem with today's 6.4 release branch on a 32-bit Linux system (Slackware 12.2). On Tue, 16 Jun 2009, William Kyngesburye wrote: I don't see any changes in v.delaunay itself from RC4, though maybe there are changes in the vector libraries. Did this work in RC4? A big difference in RC5 for OSX is that it's now 64bit. Does this affect all builds on OS X? If so, it seems like a rather drastic change when the 6.4 release branch is in critical bugfix only mode preparing for release - I fear a change to 64-bit binaries could trigger obscure bugs that might not be found for a long time. Not something to do just before the release IMHO. Paul ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
Thats exactly the problem: It shows nothing. None of my lines has any cat. Another example where it works partly: | Type of Map: vector (level: 2) | Number of points: 1 Number of areas: 56 | Number of lines:0 Number of islands:1 | Number of boundaries: 255 Number of faces: 0 | Number of centroids:56 Number of kernels:0 | | Map is 3D: No | Number of dblinks: 1 successfully created a table with 57 entries ?-. And now: how to do the same with boundaries? (And why doesn't it work with the other one?) Achim Achim Moritz Lennert wrote: On 26/06/09 15:24, achim wrote: Hi Moritz, thanks for reply and this detailed explanation. I try to report my problem with an example: reset to initial point v.db.connect -d map=my_li...@achim db.droptable -f table=testtable my_lines: | Type of Map: vector (level: 2) | | Number of points: 0 Number of areas: 0 | Number of lines:2326Number of islands:0 | Number of boundaries: 0 Number of faces: 0 | Number of centroids:0 Number of kernels:0 | Map is 3D: No | Number of dblinks: 0 Number of nodes: 2410 (with grass65 wx-gui) v.db.addtable map=my_li...@achim table=testtable Using user specified table name: testtable Creating new DB connection based on default mapset settings... Creating table with columns (cat integer) The table testtable is now part of vector map my_li...@achim and may be deleted or overwritten by GRASS modules Select privileges were granted on the table Reading features... Updating database... 0 categories read from vector map (layer 1) 0 records updated/inserted (layer 1) Current attribute table links: layer 1 table testtable in database /home/achim/grass/sqlite_db through driver sqlite with key cat Vector map my_li...@achim is connected by: ?here no records updated/inserted Probably none of your lines have categories. What does v.category my_lines option=report show ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
On 26/06/09 17:15, achim wrote: Thats exactly the problem: It shows nothing. None of my lines has any cat. That's why you have to run v.category option=add as I indicated in a previous mail. Another example where it works partly: | Type of Map: vector (level: 2) | Number of points: 1 Number of areas: 56 | Number of lines:0 Number of islands:1 | Number of boundaries: 255 Number of faces: 0 | Number of centroids:56 Number of kernels:0 | | Map is 3D: No | Number of dblinks: 1 successfully created a table with 57 entries ?-. What is the problem ? And now: how to do the same with boundaries? Why do you want your boundaries to have category values ? An area in GRASS is defined by the combination of boundaries with a centroid and the attribute data is attached to the centroid, not to the boundary. If you really want cat values for your boundaries, again: use v.category option=add type=boundary. Have you read: http://grass.itc.it/grass64/manuals/html64_user/vectorintro.html http://grass.osgeo.org/wiki/Vector_Database_Management ? Moritz Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tables connection in database
Sorry when getting on nerves with this stupid problem... ...for me its not stupid, but also getting on nerves. ...I always did and do: v.category --overwrite input=my_li...@achim output=my_lines2 type=line layer=1 Vector map my_lines2 already exists and will be overwritten Processing features... Copying attribute table(s)... Building topology for vector map my_lines2... Registering primitives... 20002326 primitives registered 4652 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 2410 Number of primitives: 2326 Number of points: 0 Number of lines: 2326 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.category complete. 2326 features modified. ...now I get: v.category -g input=my_lin...@achim output=my_lines2 option=report type=line 1 line 2326 1 2326 1 all 2326 1 2326 ...but nothing is seen with 'table manager'... (because categorization is to store 'hard' in the geometry layer and not 'soft' in the corresponding table. For this a v.to.db has to be done?) now: v.to.db map=my_lin...@achim option=cat Reading features... Updating database... 2326 categories read from vector map (layer 1) 2326 categories read from vector map don't exist in selection from table 2326 records updated/inserted (layer 1) ...and all is done. All I wanted is seen with 'table manager'! If you really want cat values for your boundaries, again: use v.category option=add type=boundary eg. sometimes it is useful to describe features of borders between two areas with v.to.db -option=sides More on my wishes..later in a mail. For now: thank you very much for helping! Sometimes a spoken word and a little hint in physical presence is easier. But maybe one or another can avoid mistakes reading this. Best regards, Achim Moritz Lennert wrote: On 26/06/09 17:15, achim wrote: Thats exactly the problem: It shows nothing. None of my lines has any cat. That's why you have to run v.category option=add as I indicated in a previous mail. Another example where it works partly: | Type of Map: vector (level: 2) | Number of points: 1 Number of areas: 56 | Number of lines:0 Number of islands:1 | Number of boundaries: 255 Number of faces: 0 | Number of centroids:56 Number of kernels:0 | | Map is 3D: No | Number of dblinks: 1 successfully created a table with 57 entries ?-. What is the problem ? And now: how to do the same with boundaries? Why do you want your boundaries to have category values ? An area in GRASS is defined by the combination of boundaries with a centroid and the attribute data is attached to the centroid, not to the boundary. If you really want cat values for your boundaries, again: use v.category option=add type=boundary. Have you read: http://grass.itc.it/grass64/manuals/html64_user/vectorintro.html http://grass.osgeo.org/wiki/Vector_Database_Management ? Moritz Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.delaunay Bug in Mac OS X
Hi, fyi I've posted a valgrind error for the module into the relevant bug report. IMO a good way to continue with this bug is to tackle that known error and see if it fixes it. https://trac.osgeo.org/grass/ticket/660 Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Testing two vectors for equality
Is there a way to test if two vectors are identical, including their attribute tables? i.e., I've changed some code and now I want to test that the results are the same. Is there an easy way to do this? Cheers, Mike ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Testing two vectors for equality
Michael Perdue wrote: Is there a way to test if two vectors are identical, including their attribute tables? i.e., I've changed some code and now I want to test that the results are the same. Is there an easy way to do this? not really. In the past I've used 'diff' on the command line to compare that the binary files in vector/ are exactly the same, as well as the DBs in dbf/. Seemed to work ok. If you test that the two vector dirs are the same with 'diff' it came back as only the timestamps in the map history metadata changing. for raster maps I added a wish for a r.md5sum module or a new flag to r.univar for that. Maybe something similar could be done for v.univar? (only based on live features?) https://trac.osgeo.org/grass/ticket/618 Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
