On 30/11/10 3:02 AM, [email protected] wrote:
Send grass-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/grass-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of grass-user digest..."
Today's Topics:
1. Re: Closed Areas (Markus Metz)
2. Re: Closed Areas (pipppoo)
3. Avoiding using specific-machine language in winGRASS
(Franz Schiller)
4. Re: Closed Areas (pipppoo)
5. Re: Closed Areas (pipppoo)
6. Re: Avoiding using specific-machine language in winGRASS
(Philipp Glira)
7. Re: Re: Closed Areas (Martin Landa)
8. Re: Re: Closed Areas (Markus Metz)
9. WinGRASS: Error when importing GRIB files (Ant?nio Rocha)
10. Re: Closed Areas (pipppoo)
11. Re: Avoiding using specific-machine language in winGRASS
(Markus Neteler)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Nov 2010 11:16:59 +0100
From: Markus Metz<[email protected]>
Subject: Re: [GRASS-user] Closed Areas
To: pipppoo<[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
pipppoo wrote:
[...]
Number of duplicate centroids: 116
Number of areas without centroid: 116
That looks like there are overlapping areas. For these, a centroid can
not be unambiguously assigned.
v.category complete. 597 features modified.
The output says that to 116 areas a centroid can't be added.
Thus i controlled with v.digit, if the boundaries are closed:
http://osgeo-org.1803224.n2.nabble.com/file/n5783822/Screenshot-v.digit_-_FNF%40PERMANENT.png
How you can see, there are just green crosses, that means that every
boundary should be closed? Or not?
But why then there are 116 areas without centroid after runnig v.centroids?
Because there are also 116 duplicate area centroids. The total number
of centroids is identical to the total number of areas.
You would have to clean the area vector without centroids first with
the tools break,rmdupl, maybe also with rmsa: repeat
tool=break,rmdupl,rmsa until rmsa does no more modifications.
Markus M
Thanks for any help in advance!
cheers,
pipppoo
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Closed-Areas-tp5783822p5783822.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
------------------------------
Message: 2
Date: Mon, 29 Nov 2010 02:33:38 -0800 (PST)
From: pipppoo<[email protected]>
Subject: [GRASS-user] Re: Closed Areas
To: [email protected]
Message-ID:<[email protected]>
Content-Type: text/plain; charset=us-ascii
Thanks for you help!
What I really need is one area for every boundary. The reason is that I want
to compute the overlap of the areas, just like done here:
http://grass.osgeo.org/wiki/Vector_Overlapping_Areas
http://grass.osgeo.org/screenshots/vector.php (Overlapping Areas)
So the option with tool:break,rmdupl probably won't work. Is that right?
Has anybody another idea?
This is a closer screenshot of the overlapping areas (randomly colored):
http://osgeo-org.1803224.n2.nabble.com/file/n5783892/Screenshot-Map_Display_1.png
cheers,
pipppoo
Pipppoo,
Can I first ask: what was the original source of the map? Did you create
in v.digit, or was it imported from somewhere else?
It would be complex to calculate the overlaps, but perhaps possible. If
you can get a single area extracted, you could upload its area - with no
overlap - then get its overlap area, and compare the two.
I'm going to give, as an example, two overlapping circles, created as
buffers around points.
for i in `v.db.select PointMap column=cat -c`; do
v.extract PointMap output="PointMap_"$i where="cat=$i";
v.buffer "PointMap_"$i output="Buffer_"$i distance=<number>;
done
This creates one buffer for each point in PointMap.
for i in `g.mlist vect pattern=Buffer*`; do
v.db.addtable $i;
v.db.addcol $i columns="Area double";
v.to.db $i option=area units=k column=Area
done
I now have the area associated with each individual polygon.
v.overlay ainput=Buffer_1 atype=area binput=Buffer_2 btype=area
operator=and output=Overlay
The overlay will have three areas: the non-overlapping part of Buffer_1
and Buffer_2, and the overlapping area. The original areas uploaded by
v.to.db will be in the Overlay map's table, as a_area and b_area.
v.db.addcol Overlay columns="New_Area double"
v.to.db Overlay option=area units=k column=New_Area
This will put area values into the table for the non-overlapping and
overlap polygons. It's now easy to calculate the overlap.
The point of this ramble is: if your overlapping areas exist as
individual polygons, you can solve the problem of calculating overlap.
Cheers,
Richard Chirgwin
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
