[GRASS5] Q. How do you find the islands for a given area?

GRASS GRASS developer
1

I've been looking into the d.area island drawing problem. Anyway, I'm
trying to figure out how you find out:

  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?

I've discovered I can get the total number of islands in the map with

   Map.n_isles

And, I can get an island using:
   Vect_get_isle_points (&Map, isle_num, &pnts)

Problem is, I want to know just the islands for the current area. Even
with V2_get_area (&Map, area_num, &area_ptr), the area_ptr->n_isles
gives me nothing (even though I'm using a little test vector that has
two areas each with one interior island).

My idea for a solution to the filled area drawing routines would
basically connect all the islands to their outer area where the
island is closest to the area boundary. (Make any sense). I don't know
how else these holes could be handled.

Before:
     _________
    | _ |<= Area
    | / \ |
    | \_/ |
    | Isle^ |
    |_________|

After:
     _________
    | | | (Area "line points" now loops down and around island,
    | / \ | then back up to where it dropped down to the island
    | \_/ | to continue the rest of the area boundary)
    | |
    |_________|

What am I missing?

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Sat, 24 Feb 2001, Eric G. Miller wrote:

I've been looking into the d.area island drawing problem. Anyway, I'm
trying to figure out how you find out:

  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?

Eric,

  Funny that you mention this. In order to better help David with the
v.in.mif (and v.in.shape) modules, I've discovered the subject I need to
learn: computational geometry. My buddy in Boulder (CO) pointed me to Joseph
O'Rourke's book, "Computational Geometry in C", 2nd Edition; I bought a copy
last night at Powell's Technical Books in Portland. This book contains the
answer to these questions and a bunch of other vector-related questions.

  Briefly, read the nodes of the polygons into a structure (he uses a
doubly-linked, circular list for a number of reasons). If you walk the
vertices (nodes) in order, v0 -> v1 -> v2 ... -> v(n-1), the interior of the
polygon will be to your left when the nodes are traversed counter-clockwise.
If traversing the nodes in a clockwise direction, then the interior of the
polygon is to your right. By knowing on which edge you're walking, you can
tell if you're walking on the polygon external boundary or an internal
boundary defining a hole. Clear as mud, right?

  The clockwiseness he uses is the opposite of that used by ESRI on their
shapefiles. I'd stick with his approach for it permits the computation of
many polygon attributes.

  While I'm in the first chapter still (it's toward the end where he
discusses implementation rather than just the math), I now understand how to
easily determine if two lines intersect (what he calls "proper
intersection") or if one line ends with a point collinear on another line
("improper intersection") and how to triangulate polygons and calculate
polygon areas. Cool stuff! I've been curious about this for more than a
decade.

  The next stage (eventually) will be to learn some graph theory algorithms
so we can add network analyses to GRASS using vectors.

  Anyway, perhaps your local library or geek book store has a copy of
O'Rourke's book (quite reasonably priced, too, for today's technical book
prices), and you can read about it for yourself. Otherwise, you'll have to
wait until I finish reading it. :slight_smile:

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

"Eric G. Miller" wrote:

I've been looking into the d.area island drawing problem. Anyway, I'm
trying to figure out how you find out:

Eric

I'm not familiar with this particular code, but a few remarks on the
problem generally:

  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.

I've discovered I can get the total number of islands in the map with

   Map.n_isles

And, I can get an island using:
   Vect_get_isle_points (&Map, isle_num, &pnts)

Problem is, I want to know just the islands for the current area. Even
with V2_get_area (&Map, area_num, &area_ptr), the area_ptr->n_isles
gives me nothing (even though I'm using a little test vector that has
two areas each with one interior island).

This should work, but the area, island elements and so on are
topological structures, they will be empty or invalid till you build the
map. If that is so you should get a result from this. Maybe there is a
bug in V2_get_area(). Writing v.out.shape, I extracted this info
manually, bit by bit as I described above. Perhaps that would work,
certainly it is OK in v.out.shape.

My idea for a solution to the filled area drawing routines would
basically connect all the islands to their outer area where the
island is closest to the area boundary. (Make any sense). I don't know
how else these holes could be handled.

Before:
     _________
    | _ |<= Area
    | / \ |
    | \_/ |
    | Isle^ |
    |_________|

After:
     _________
    | | | (Area "line points" now loops down and around island,
    | / \ | then back up to where it dropped down to the island
    | \_/ | to continue the rest of the area boundary)
    | |
    |_________|

What am I missing?

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.

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.

Regards

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Sat, Feb 24, 2001 at 03:32:20PM -0800, Rich Shepard wrote:

On Sat, 24 Feb 2001, Eric G. Miller wrote:

> I've been looking into the d.area island drawing problem. Anyway, I'm
> trying to figure out how you find out:
>
> 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?

Eric,

  Funny that you mention this. In order to better help David with the
v.in.mif (and v.in.shape) modules, I've discovered the subject I need to
learn: computational geometry. My buddy in Boulder (CO) pointed me to Joseph
O'Rourke's book, "Computational Geometry in C", 2nd Edition; I bought a copy
last night at Powell's Technical Books in Portland. This book contains the
answer to these questions and a bunch of other vector-related questions.

Yea, I've heard of this O'Rourke book. Been meaning to pick it up.
There are a couple of others I've seen mentioned in many places.

Anyway, the question was more directed at the GRASS interface functions,
then for algorithms. Turns out my test vector layer wasn't getting
built right. After much futzing with v.digit and v.support, I finally
managed to build one that had the properties I was looking for. So, now
I have to see if I can get d.area filling only areas that have been
labelled while "cutting out" the areas of internal islands... Basically
have to turn multiple polygons into one for the polygon fill operation.

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

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@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

On Sat, Feb 24, 2001 at 07:04:15PM -0800, Eric G. Miller wrote:

> 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...

Well, good and bad news. The good news is, with my small test vectors,
I've been able to get d.area to not fill inner island areas. The bad
news is it really sucks CPU and is very slow. My hardcore test for any
vector routine is running it on the geology layer I have for California.
It's got thousands of polygons and many island polys. Well, it takes
many many minutes to draw. Not good. d.vect takes about 1.5 minutes.

There's probably alot I can do to speed it up, by being more efficient
about memory dupes. The biggest killer is the search for the closest
tie point between the outer polygon and it's inner islands. I'm doing a
real lame nested looping thing through two polygons to find the closest
points. Maybe you'all have a better method to identify appropriate
points to tie to two polygons together at?

More later,

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

In addition to the O'Rourke book, I think Michael Worboys' "GIS - a
computing perspective" covers the lakes in islands issue too from the GIS
side.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

On Sun, 25 Feb 2001, Eric G. Miller wrote:

There's probably alot I can do to speed it up, by being more efficient
about memory dupes. The biggest killer is the search for the closest tie
point between the outer polygon and it's inner islands. I'm doing a real
lame nested looping thing through two polygons to find the closest points.
Maybe you'all have a better method to identify appropriate points to tie
to two polygons together at?

Eric,

  I'm not sure about this, but throwing out the idea. Pick a reference point
on the outer polygon. Test each inner polygon node by examining the length of
a vector between the reference node (on the outer polygon) and each node of
the inner polygon. I've no idea how to calculate the speed, but (in my
naivety) it might be O(n) because you calculate the vector once per pair of
points.

  Is this the type of solution that might work?

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Rich Shepard wrote:

On Sun, 25 Feb 2001, Eric G. Miller wrote:

> There's probably alot I can do to speed it up, by being more efficient
> about memory dupes. The biggest killer is the search for the closest tie
> point between the outer polygon and it's inner islands. I'm doing a real
> lame nested looping thing through two polygons to find the closest points.
> Maybe you'all have a better method to identify appropriate points to tie
> to two polygons together at?

Eric,

  I'm not sure about this, but throwing out the idea. Pick a reference point
on the outer polygon. Test each inner polygon node by examining the length of
a vector between the reference node (on the outer polygon) and each node of
the inner polygon. I've no idea how to calculate the speed, but (in my
naivety) it might be O(n) because you calculate the vector once per pair of
points.

"Some" years ago, I've written a polygon filling algorythm. I was also
faced to the problem of included polygons. I used a sorted list of vector.
The sort was done first by X ascendent, then by Y ascendent. For each
vector, i used the lower X end. You do not even sort them : with a double
linked list, you can easely fit them in place while building the list.
For any fixed X value, you can then traverse all the map and know where
you hit a polygon. Just draw a little exemple, you will see what I mean.
You can even deal with multple leve inclusions (isle in an isle in an isle)

Well, sorry to be so short, and not very constructive on the list those days,
but I have some important meeting to prepare for next week. I'll be back
next friday

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

On Sun, 25 Feb 2001, Eric G. Miller wrote:

The biggest killer is the search for the closest tie point between the
outer polygon and it's inner islands.

Eric,

  Do you know which objects are islands in which bounding polygons? If so,
my suggestion of a short time ago can probably be modified to comparing the
minimum x values or maximum x values of the two polygons. Then look at the y
values.

  If the relationships among polygons are not known, I wonder if the "plane
sweep" algorithm will help. This algorithm sweeps from max(y) of a polygon
through min(y), stopping at every node's y value and checking for
intersections of this sweep line with polygon edges. Because we cannot
assume that interior holes line up with the nodes of the bounding polygon,
the algorithm can be modified to step down a fixed distance each time
through the loop, and see if there are more than two polygon edges
intersecting at that distance.

  Am I making sense here?

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

There's probably alot I can do to speed it up, by being more efficient
about memory dupes. The biggest killer is the search for the closest
tie point between the outer polygon and it's inner islands. I'm doing a
real lame nested looping thing through two polygons to find the closest
points. Maybe you'all have a better method to identify appropriate
points to tie to two polygons together at?

I think that for Xdriver should be used system built in X window:
If fill-rule is set to EvenOddRule you can simply add islands to x,y array
(always return to area start point after each island) and it should be
plotted correctly. (For EvenOddRule, a point is inside if an infinite
ray with the point as origin crosses the path an odd number of times.)

Because other drivers (cell,..) will work in different way we need new function
R_polygon_with_holes_abs() which would send areas and islands separately
to driver. X driver would use X window internal fill system (probably
supported by HW) and cell driver would use your filling function
with closest points (cell driver may be slower).

Radim

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

On Sun, Feb 25, 2001 at 09:25:25AM -0800, Rich Shepard wrote:

On Sun, 25 Feb 2001, Eric G. Miller wrote:

> The biggest killer is the search for the closest tie point between the
> outer polygon and it's inner islands.

Eric,

  Do you know which objects are islands in which bounding polygons? If so,
my suggestion of a short time ago can probably be modified to comparing the
minimum x values or maximum x values of the two polygons. Then look at the y
values.

Yes, v.support would have already identified the 1st generation interior
islands for each boundary area. One thing I did that help enormously
was to remove duplicate points. I'm working in converted screen
positions, so it's often likely that what would otherwise be two
distinct points in geographic space degenerate into a single point in
screen real estate.

I thought about using delta_x, delta_y vs. a distance calculation, but
I'm not sure that would make the routine any faster. I don't know how
expensive sqrt() is; maybe there's a cheaper method to find the distance
between two points (other than the algebraic distance formula)?

I do only hit two node pairs once, and I have a short-circuit if the
distance drops below 1.0. I don't know, but maybe I don't need all of
this extra work. I just don't want filled space showing up where it
shouldn't. Now, since I basically create two line segments between the
outer ring and the inner ring that are colinear, would the driver draw
any fill at all along that segment? If not, then this extra effort is
probably unnecessary.

  If the relationships among polygons are not known, I wonder if the "plane
sweep" algorithm will help. This algorithm sweeps from max(y) of a polygon
through min(y), stopping at every node's y value and checking for
intersections of this sweep line with polygon edges. Because we cannot
assume that interior holes line up with the nodes of the bounding polygon,
the algorithm can be modified to step down a fixed distance each time
through the loop, and see if there are more than two polygon edges
intersecting at that distance.

Luckily, I'm relying on v.support having already done this. Many of
these algorithms are implemented in the vector library already. It's
just sometimes hard to follow the code.

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

On Sun, Feb 25, 2001 at 07:49:00PM +0100, Radim Blazek wrote:

> There's probably alot I can do to speed it up, by being more efficient
> about memory dupes. The biggest killer is the search for the closest
> tie point between the outer polygon and it's inner islands. I'm doing a
> real lame nested looping thing through two polygons to find the closest
> points. Maybe you'all have a better method to identify appropriate
> points to tie to two polygons together at?

I think that for Xdriver should be used system built in X window:
If fill-rule is set to EvenOddRule you can simply add islands to x,y array
(always return to area start point after each island) and it should be
plotted correctly. (For EvenOddRule, a point is inside if an infinite
ray with the point as origin crosses the path an odd number of times.)

Yea, I switched to just gluing together the polys at whereever, and CPU
time dropped by 2/3.

Because other drivers (cell,..) will work in different way we need new function
R_polygon_with_holes_abs() which would send areas and islands separately
to driver. X driver would use X window internal fill system (probably
supported by HW) and cell driver would use your filling function
with closest points (cell driver may be slower).

Because no such thing exists in the driver interface, I'm hacking the
module itself. I'll need to see how the CELL driver deals with the
hack. I'm hoping it doesn't draw a 1pixel connecting line, but I don't
know...

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

14

On Sun, Feb 25, 2001 at 01:23:02PM -0800, Eric G. Miller wrote:

On Sun, Feb 25, 2001 at 07:49:00PM +0100, Radim Blazek wrote:
>
> > There's probably alot I can do to speed it up, by being more efficient
> > about memory dupes. The biggest killer is the search for the closest
> > tie point between the outer polygon and it's inner islands. I'm doing a
> > real lame nested looping thing through two polygons to find the closest
> > points. Maybe you'all have a better method to identify appropriate
> > points to tie to two polygons together at?
>
> I think that for Xdriver should be used system built in X window:
> If fill-rule is set to EvenOddRule you can simply add islands to x,y array
> (always return to area start point after each island) and it should be
> plotted correctly. (For EvenOddRule, a point is inside if an infinite
> ray with the point as origin crosses the path an odd number of times.)

Yea, I switched to just gluing together the polys at whereever, and CPU
time dropped by 2/3.

> Because other drivers (cell,..) will work in different way we need new function
> R_polygon_with_holes_abs() which would send areas and islands separately
> to driver. X driver would use X window internal fill system (probably
> supported by HW) and cell driver would use your filling function
> with closest points (cell driver may be slower).

Because no such thing exists in the driver interface, I'm hacking the
module itself. I'll need to see how the CELL driver deals with the
hack. I'm hoping it doesn't draw a 1pixel connecting line, but I don't
know...

Unfortunately, the CELL driver does draw a pixel wide connecting line,
even though the two boundary lines are colinear. So, I've hooked up
that real slow algorithm again. Takes about 3 times longer in my simple
testing... Note, vectors without islands shouldn't draw too much slower
than d.vect would draw them.

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

15

Hi Eric

"Eric G. Miller" wrote:

I've been looking into the d.area island drawing problem. Anyway, I'm
trying to figure out how you find out:

I'm sorry I didn't read my mail this weekend, but the most efficinet way
to solve your problem is to use a computer graphics algorithm for
filling polygons. This algorithm handles convex polygons, concave
polygons, self-intersecting polygons, and polygons with holes (or
islands in your case). Since you already did a lot of coding, you may
not be interested in this algorithm. However, if you are interested, it
can be found in the book "Computer Graphics: Principles and Practice" by
Foley, Van Dam, Feiner, and Hughes (see section 3.6 "Filling Polygons").
If you cannot find this book, let me know and I'll see what I can do to
summarize the algorithm for you. Note that with this algorithm, you do
not have to worry about which areas are islands. However, you may need
to modify this if you have nested islands.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

16

On Mon, Feb 26, 2001 at 02:29:28PM +0700, Justin Hickey wrote:

Hi Eric

"Eric G. Miller" wrote:
>
> I've been looking into the d.area island drawing problem. Anyway, I'm
> trying to figure out how you find out:

I'm sorry I didn't read my mail this weekend, but the most efficinet way
to solve your problem is to use a computer graphics algorithm for
filling polygons. This algorithm handles convex polygons, concave
polygons, self-intersecting polygons, and polygons with holes (or
islands in your case). Since you already did a lot of coding, you may
not be interested in this algorithm. However, if you are interested, it
can be found in the book "Computer Graphics: Principles and Practice" by
Foley, Van Dam, Feiner, and Hughes (see section 3.6 "Filling Polygons").
If you cannot find this book, let me know and I'll see what I can do to
summarize the algorithm for you. Note that with this algorithm, you do
not have to worry about which areas are islands. However, you may need
to modify this if you have nested islands.

Such changes would have to be made at the driver lib side, as Radim
noted. I don't know if I'm up to adding in another protocol call
to the rasterlib and the various driver libs. It'd probably be the
"correct" way to handle these islands, but there are many places where
changes would have to be made (as opposed to one place in the calling
module).

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'