Re: [GRASS-user] [GRASSLIST:7979] r.sim.water or r.sim.sediment
On Wed, Jan 7, 2009 at 3:09 PM, A Lanzer wrote: > Dylan Beaudette-3 wrote: >> Does anyone know the status of the commands: >> r.sim.water >> r.sim.sediment >> r.simwe >> >> in either GRASS54 or GRASS6 ? In GRASS5 not recommended, in GRASS6 + GRASS7 usable. > I found these pages on the web. > > http://skagit.meas.ncsu.edu/~jaroslav/r.sim/r.sim.water.html > http://skagit.meas.ncsu.edu/~jaroslav/r.sim/r.sim.sediment.html ... please don't use them (from 2002 and very outdated). They are better documented in the GRASS manual pages which are here: http://grass.osgeo.org/grass64/manuals/html64_user/r.sim.sediment.html http://grass.osgeo.org/grass64/manuals/html64_user/r.sim.water.html Additionally, in the GRASS book (3rd ed., pp. 163-166) there is in the section "5.5 Landscape process modeling" a paragraph on "Process-based water flow and erosion modeling" discussing the use with examples. Maybe your library has the book. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Importing polygon maps with overlapping features
Maris Nartiss wrote: > > The only trouble this gives me in practice arises when I need to > > import data created in non-topological GIS (e.g. ArcView Shapefiles) > > that contains overlapping polygons. Granted, those should not exist > > in the first place, but bad data quality and faulty topology is a > > constant reality in my field of work. With overlapping polygons, > > centroids cannot always be related to exactly one polygon, so the > > topology building fails for those cases and attribute data does > > not get attached "correctly". > > GRASS vector model is advanced, but sometimes it fails for simple > usage. It's one of best features is also it's point of failure. > Vector areas support in GRASS is built around bogous assumption, that > areas can not overlap. That's not an assumption, it's a design decision. Vector maps are supposed to tessellate 2D space. Any given point should always be in exactly one area (possibly the exterior area, which is the area not covered by any explicit areas). > Such assumption holds true for many vector > usages (i.e. property boundaries don't overlap), but fails for other > vector usage patterns. > Let's assume one GRASS user wants to create vector area map with > suitable animal habitat areas. Does gay wolf and brown bear habitat > areas may overlap in real world? Yes they can. Can they overlap in > GRASS? No. User is forced to adapt semantics (habitat area) to data > storage limitations (one map per species). If you have multiple disjoint areas, they need to be separate vector maps. You can no more have a point contained by multiple areas in a vector map than you can set a single raster cell to multiple values. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interpolating with a covariate - v.vol.rst
On Tue, Jan 6, 2009 at 2:33 PM, Markus Neteler wrote: > Dylan, > > On Tue, Jan 6, 2009 at 10:01 PM, Dylan Beaudette > wrote: >> Hi, >> >> For some crazy reason I was under the impression that it is possible to do >> interpolation with a covariate with v.vol.rst. Are there any examples on how >> to parameterize this module, when a 2D surface is requested, rather than a 3D >> volume. I noticed the 'cellinp' argument for a cross-section, but this is not >> quite what I am after. I am looking to do something very similar to >> interpolation of rainfall data, taking into account the orographic effect of >> terrain. > > This was my main business (say, of our cluster) over the last months :) > You can do that. I am using the elevation model as auxiliary variable: > > # something like this: > v.vol.rst in=vectpoints cellinp=dem wcolumn=pointval cellout=rst2d > > cellout delivers the 2D map, extracted from the volume along the > dem map. > > Hope this helps > Markus > Thanks Markus. One more question: have you found a good compromise in the 3D region settings- i.e. some ratio of horizontal:vertical resolution that gives good results and doesn't take too long to compute? Cheers, Dylan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Problems r.usler
Hi list members, with the help of Markus I managed to add the r.usler module to my GRASS 6.4 RC1 installation. I tried the modul with some of my precipitation data and I figured out that only the first option (roose) for the methods is working. Also the result I got is strange... Please have a look to the attached jpg. The grey triangle is the result of r.ulser, in color the precipitation data. Calculation region is the other half of the triangle Thanks, Christian <> Dipl. Geogr. Christian Braun Tel: +352- 425991-608 Mobil: +49-179-6845896 Mail: christian.br...@tudor.lu Resource Centre for Environmental Technologies, Public Research Centre Henri Tudor, Technoport Schlassgoart, 66 rue de Luxembourg, P.O. BOX 144, L-4002 Esch-sur-Alzette, Luxembourg ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASSLIST:7979] r.sim.water or r.sim.sediment
Dylan Beaudette-3 wrote: > > Hi, > > Does anyone know the status of the commands: > r.sim.water > r.sim.sediment > r.simwe > > in either GRASS54 or GRASS6 ? > > i have been drooling over the possiblity of using them... > > any help would be appreciated! > > -- > Dylan Beaudette > Soils and Biogeochemistry Graduate Group > University of California at Davis > 530.754.7341 > > > > I found these pages on the web. http://skagit.meas.ncsu.edu/~jaroslav/r.sim/r.sim.water.html http://skagit.meas.ncsu.edu/~jaroslav/r.sim/r.sim.sediment.html -- View this message in context: http://n2.nabble.com/-GRASSLIST%3A7979--r.sim.water-or-r.sim.sediment-tp1874296p2122554.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] Importing polygon maps with overlapping features
Hello there, yes this can be seen as a limitation of grass, or more precisely of the topological data model. But I think one must remind of the strict border that should lie between geometry and a "semantic" contents. With a relational database structure you can of course overlap various characteristics of a single area : on one hand you have a set of adjacent -- that is topologically clean -- polygons, on the other hand a table or a set of related tables holding the complexity of attributes ; the cat value of a centroïd has a univoque link with a row of a table, then you can define associations of polygons (ajacent, included, non-adjacent). Grass does not provide tools for directly manipulating let's say 'multi-polygon' objects, but the ability to link a database to simple geometry allows the handling of complex objects. __ (a bit out of context : for those who worked with ArcInfo, it is sometimes frustrating not to have in Grass a feature class like REGION-SUBCLASS, which is to my mind a far better solution than multipolygons (the OGC standard geographic features)) Yours, Vincent. Le mercredi 07 janvier 2009 à 14:47 +0200, Maris Nartiss a écrit : > Hello, > GRASS vector model is advanced, but sometimes it fails for simple > usage. It's one of best features is also it's point of failure. > Vector areas support in GRASS is built around bogous assumption, that > areas can not overlap. Such assumption holds true for many vector > usages (i.e. property boundaries don't overlap), but fails for other > vector usage patterns. > Let's assume one GRASS user wants to create vector area map with > suitable animal habitat areas. Does gay wolf and brown bear habitat > areas may overlap in real world? Yes they can. Can they overlap in > GRASS? No. User is forced to adapt semantics (habitat area) to data > storage limitations (one map per species). > > Probably this is not the best example, simply I could not make better one > fast. > > Sorry for language and trolling, > Maris. > > 2009/1/7, Benjamin Ducke : > > > > > The only trouble this gives me in practice arises when I need to > > import data created in non-topological GIS (e.g. ArcView Shapefiles) > > that contains overlapping polygons. Granted, those should not exist > > in the first place, but bad data quality and faulty topology is a > > constant reality in my field of work. With overlapping polygons, > > centroids cannot always be related to exactly one polygon, so the > > topology building fails for those cases and attribute data does > > not get attached "correctly". > > > > > Cheers, > > > > Ben > > > > > ___ > 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] Importing polygon maps with overlapping features
Hello, GRASS vector model is advanced, but sometimes it fails for simple usage. It's one of best features is also it's point of failure. Vector areas support in GRASS is built around bogous assumption, that areas can not overlap. Such assumption holds true for many vector usages (i.e. property boundaries don't overlap), but fails for other vector usage patterns. Let's assume one GRASS user wants to create vector area map with suitable animal habitat areas. Does gay wolf and brown bear habitat areas may overlap in real world? Yes they can. Can they overlap in GRASS? No. User is forced to adapt semantics (habitat area) to data storage limitations (one map per species). Probably this is not the best example, simply I could not make better one fast. Sorry for language and trolling, Maris. 2009/1/7, Benjamin Ducke : > > The only trouble this gives me in practice arises when I need to > import data created in non-topological GIS (e.g. ArcView Shapefiles) > that contains overlapping polygons. Granted, those should not exist > in the first place, but bad data quality and faulty topology is a > constant reality in my field of work. With overlapping polygons, > centroids cannot always be related to exactly one polygon, so the > topology building fails for those cases and attribute data does > not get attached "correctly". > > Cheers, > > Ben > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Importing polygon maps with overlapping features
On Wed, January 7, 2009 12:58, Benjamin Ducke wrote: > Thanks for your clarification, Moritz, that makes perfect sense > from the data model point of view. > > The only trouble this gives me in practice arises when I need to > import data created in non-topological GIS (e.g. ArcView Shapefiles) > that contains overlapping polygons. Granted, those should not exist > in the first place, but bad data quality and faulty topology is a > constant reality in my field of work. With overlapping polygons, > centroids cannot always be related to exactly one polygon, so the > topology building fails for those cases and attribute data does > not get attached "correctly". > > Are there any bright ideas on how to allow v.in.ogr to import maps > with overlapping polygons and still manage to create a GRASS map > that has all area objects and the right attribute table row linked > to each one of them? Export would also need to work in the same way. > My gut feeling is some patching of v.[in|out].ogr would be required... The question is what you want to do with the data. If it is for mapping, you can just use v.external. But if you want to actual do GIS analysis, the ambiguities created by the overlaps have to be lifted at one point. Overlapping polygons is a fundamental error in the classical 2D model as for a particular point in space, you cannot say for sure which attributes are linked to it. v.clean tries to repare this (v.in.ogr uses the same routines and you can parameter them), but in the end it is the responsibility of the user to make the decisions... So, I'm not sure it can be easily handled by a "patch" to v.in.ogr. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Importing polygon maps with overlapping features
Thanks for your clarification, Moritz, that makes perfect sense from the data model point of view. The only trouble this gives me in practice arises when I need to import data created in non-topological GIS (e.g. ArcView Shapefiles) that contains overlapping polygons. Granted, those should not exist in the first place, but bad data quality and faulty topology is a constant reality in my field of work. With overlapping polygons, centroids cannot always be related to exactly one polygon, so the topology building fails for those cases and attribute data does not get attached "correctly". Are there any bright ideas on how to allow v.in.ogr to import maps with overlapping polygons and still manage to create a GRASS map that has all area objects and the right attribute table row linked to each one of them? Export would also need to work in the same way. My gut feeling is some patching of v.[in|out].ogr would be required... Cheers, Ben Moritz Lennert wrote: >>> >>> To be quite honest, I have always been a bit bewildered about the >>> choice of using a centroid point for linking attributes to area >>> features. Could anyone here fill me in on what advantage that has? > > In a topological model where a boundary is boundary of two adjacent > polygons, you cannot link polygon attributes to the boundary as there > would be ambiguity as to which polygon these attributes are referring > to. So you need some way of unambiguously identifying the polygon. A > pseudo-centroid (i.e. not the geometric centroid, but one that in all > cases lies within the polygon) is one way of doing it and the one chosen > in GRASS's vector model. There might be other ways, but I'm no expert on > that. > -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeological Unit Limited Janus House Osney Mead OX2 0ES Oxford, U.K. Tel.: ++44 (0)1865 263 800 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.centroids and cat values
[forwarding this to the list for Micha, as it ended up in my mailbox ;) - Ben] Thanks for the suggestions. Some additional comments below: Benjamin Ducke wrote: > GRASS modules that create area type features should already be generating > centroids and adding categories to them automatically, shouldn't they? > As far as I am aware, e.g., v.in.ogr does this, so we are talking mainly > about adding centroid generation to the interactive digitizing tool, aren't > we? > The GRASS Vector lib API should have a function that finds a good centroid > automatically. > Or am I misled here (guess I am getting a bit confused myself, now)? > > As far as I know, v.in.ogr creates centroids automatically when you import a vector as type=boundary, and gives the centroids the same cat values as the boundaries. > To be quite honest, I have always been a bit bewildered about the choice > of using a centroid point for linking attributes to area features. > Could anyone here fill me in on what advantage that has? > > Cheers (and a good New Year, btw.), > > Ben > > Michael Barton wrote: > >> >> >>> Normally, the "best practice" is to digitize boundaries without category >>> values (unless you specifically want information concerning the >>> boundary, not the area it contains) and then digitize the centroids with >>> category values and relevant attribute data. >>> >>> Yes, I understand that now. >>> In your case, the easiest way out would seem to be v.distance, i.e.: >>> >>> - v.centroid in=YourBoundaries out=YourMap >>> - v.db.addcol YourMap column="b_cat int" >>> - v.distance from=YourMap from_type=centroid to=YourMap to_type=boundary >>> upload=cat column=b_cat #this should find the nearest boundary for each >>> centroid >>> - v.category in=YourMap out=YourMap2 option=del type=boundary >>> - v.reclass in=YourMap2 out=YourMap3 type=centroid column=b_cat >>> - db.copy from_table=YourMap2 to_table=YourMap3 >>> - db.dropcol YourMap3 col=b_cat >>> - Now you should have a YourMap3 with centroids that are linked to the >>> correct attributes. If this is the case, you can safely do the next step: >>> - g.remove vect=YourMap,YourMap2 >>> >>> This should be quite easy to make into a script module, or maybe extend >>> v.centroids to optionally do this for you. >>> I follow what you're suggesting, but as a general solution it seems like quite a convoluted process to go thru just to get attribute values, which were already entered, to display correctely. >> I still think that when an area is created, a centroid should >> automatically be placed at some standard and logical place for each >> area. Area centroids should be an integral component of area topology, >> not a separate point that must be manually placed and manipulated. >> >> Michael >> Michael: I think you brought this up in the past? This seems to me the most "natural" approach. So what would be needed is: 1- v.digit should automatically add a centroid in some reasonable place for each closed boundary, and give it the boundary's cat value. 2- v.centroid should also automatically assign cat values identical to the surrounding boundary's values. Regards, Micha -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] Re: grass-user Digest, Vol 33, Issue 10
On 06/01/09 22:18, Michael Barton wrote: From: Benjamin Ducke Subject: Re: [GRASS-user] v.centroids and cat values Cc: grass-user Message-ID: <1559037892.138311231273729471.javamail.r...@mail.thehumanjourney.net> Content-Type: text/plain; charset=utf-8 GRASS modules that create area type features should already be generating centroids and adding categories to them automatically, shouldn't they? I don't know. As far as I am aware, e.g., v.in.ogr does this, so we are talking mainly about adding centroid generation to the interactive digitizing tool, aren't we? In this case yes. I don't know about other modules. The GRASS Vector lib API should have a function that finds a good centroid automatically. Or am I misled here (guess I am getting a bit confused myself, now)? This is a good idea. If it exists, perhaps it should be accessed by the digitizing module as the default. To be quite honest, I have always been a bit bewildered about the choice of using a centroid point for linking attributes to area features. Could anyone here fill me in on what advantage that has? In a topological model where a boundary is boundary of two adjacent polygons, you cannot link polygon attributes to the boundary as there would be ambiguity as to which polygon these attributes are referring to. So you need some way of unambiguously identifying the polygon. A pseudo-centroid (i.e. not the geometric centroid, but one that in all cases lies within the polygon) is one way of doing it and the one chosen in GRASS's vector model. There might be other ways, but I'm no expert on that. My bet is that is is a legacy of early GRASS vector design--a convenient way to create a polygon and give it some data. I still find it strange that a "boundary" can exist that is not a "line" and not a part of an "area". On Jan 6, 2009, at 11:06 AM, Patton, Eric wrote: If the user just wants to digitize a "boundary without areas", then they could just digitize linework and snap the vertices, couldn't they? You might have a case where you need information concerning areas, but also information concerning their boundaries, i.e. just as an example off the top of my head, you could have migration balances for countries (polygons) and information concerning the permeability of the borders (boundaries). You could obviously use a separate layer of lines to represent your borders and link the attributes to that, but the GRASS model allows you to have both in the same map, with centroids in one layer linked to their attributes, and the borders in a second layer linked to theirs. I have no idea how frequent such usage is, though... Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.centroids and cat values
Thanks for the suggestions. Some additional comments below: Benjamin Ducke wrote: GRASS modules that create area type features should already be generating centroids and adding categories to them automatically, shouldn't they? As far as I am aware, e.g., v.in.ogr does this, so we are talking mainly about adding centroid generation to the interactive digitizing tool, aren't we? The GRASS Vector lib API should have a function that finds a good centroid automatically. Or am I misled here (guess I am getting a bit confused myself, now)? As far as I know, v.in.ogr creates centroids automatically when you import a vector as type=boundary, and gives the centroids the same cat values as the boundaries. To be quite honest, I have always been a bit bewildered about the choice of using a centroid point for linking attributes to area features. Could anyone here fill me in on what advantage that has? Cheers (and a good New Year, btw.), Ben Michael Barton wrote: Normally, the "best practice" is to digitize boundaries without category values (unless you specifically want information concerning the boundary, not the area it contains) and then digitize the centroids with category values and relevant attribute data. Yes, I understand that now. In your case, the easiest way out would seem to be v.distance, i.e.: - v.centroid in=YourBoundaries out=YourMap - v.db.addcol YourMap column="b_cat int" - v.distance from=YourMap from_type=centroid to=YourMap to_type=boundary upload=cat column=b_cat #this should find the nearest boundary for each centroid - v.category in=YourMap out=YourMap2 option=del type=boundary - v.reclass in=YourMap2 out=YourMap3 type=centroid column=b_cat - db.copy from_table=YourMap2 to_table=YourMap3 - db.dropcol YourMap3 col=b_cat - Now you should have a YourMap3 with centroids that are linked to the correct attributes. If this is the case, you can safely do the next step: - g.remove vect=YourMap,YourMap2 This should be quite easy to make into a script module, or maybe extend v.centroids to optionally do this for you. I follow what you're suggesting, but as a general solution it seems like quite a convoluted process to go thru just to get attribute values, which were already entered, to display correctely. I still think that when an area is created, a centroid should automatically be placed at some standard and logical place for each area. Area centroids should be an integral component of area topology, not a separate point that must be manually placed and manipulated. Michael Michael: I think you brought this up in the past? This seems to me the most "natural" approach. So what would be needed is: 1- v.digit should automatically add a centroid in some reasonable place for each closed boundary, and give it the boundary's cat value. 2- v.centroid should also automatically assign cat values identical to the surrounding boundary's values. Regards, Micha ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
