[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 [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
