[GRASS5] Q. How do you find the islands for a given area?
Eric G. Miller
egm2 at jps.net
Sat Feb 24 22:04:15 EST 2001
On Sun, Feb 25, 2001 at 01:12:57AM +0000, David D Gray wrote:
> "Eric G. Miller" wrote:
> >
> > For a given area A:
> > How many interior boundary islands does it have?
> > How do I get line_pnts struct(s) for just these interior islands?
> >
>
> Instead of using the top level n_isles field, identify the index of the
> area you are examining. This is available in struct Map_info as Area, an
> area of pointers to P_AREA structures, each of which describes the
> topology of just one area. The array starts at index 1, unusually. This
> gives the number of bounding lines (for the outer hull), and a list
> which is just an array of pointers to integers that represent the
> indices of the lines in the top level Line array. Similarly, the n_isles
> field and isles field give the number of islands and their identity
> resp. The isles field is an array of pointer to int which are the
> indices of the islands in top_level Isle which are islands of this area,
> so that will get you the islands.
>
> Each of these indices can be used in Vect_get_isle_points() to pull out
> the points into a struct line_pnts.
Yes, I'm just that far now... Now I have to figure out how to merge in
the islands...
> Yes this is more a problem in 2d vector rendering, rather than a map
> problem. Vector drawing is not my forte, but I understand this is
> commonly how it is done.
Yup. There's some masking thingies for X, but the display protocol
doesn't have any method to set them. But that'd be a bitmap anyway.
There's also some XSetRegion thing, but I think that just sets up a
clipping region. Anyway, the X specific methods wouldn't work with
the other drivers...
> I have recently been thinking that we should maintain a cache that
> stores the polygons in this form for drawing purposes. Cached data could
> be read for rapid display if the timestamp on the cache is more recent
> than the persistent data in Map_info. Pulling topological data out of
> dig_plus to generate geometry is quite fast anyway, but would be faster
> still if the information was cached.
Yes, I expect this operation is going to be expensive on CPU time...
--
Eric G. Miller <egm2 at jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev
mailing list