[GRASS5] Fw: d.area progress report...

[Robert Lagacé]

"Eric G. Miller" wrote:
> 
> Oops, wrong list...
> 
> Begin forwarded message:
> 
> Date: Sun, 20 Jan 2002 19:55:10 -0800
> From: Eric G. Miller <egm2 at jps.net>
> To: GRASS <GRASSLIST at baylor.edu>
> Subject: d.area progress report...
> 
> Just wanted to say, I've finally made some significant progress
> implementing a area w/holes simplifier.  Unfortunately, seems
> I made an unwarranted assumption about the possibility of
> colinear line segments (I didn't think about the fact that
> that island/holes may share edges).  So, hopefully I can
> work in some code for handling colinear segments in the
> next week, and then possibly get some of this code into GRASS.
> 
> Basically, I'm trying to implement an addition to the display
> library which consists of the following three functions:
> 
>   D_area_begin()   -- Set up for a new area
>   D_area_add_ring (struct line_pnts *) -- Add one or more boundaries.
>   D_area_finish()  -- Process the rings and draw the result to the
>                       display.
> 
> I'm not sure how to handle the colinear segments problem.  I'm
> thinking it might be better to have an interface level where the
> user passes a Map_info struct, and the id for the area to draw.
> I could then weed out the colinear segments by not adding any
> edge that didn't have the target area on one of it's sides.
> Then the interface would reduce to:
> 
>   D_area_plot (struct Map_info *, int);
> 
> Later on, I hope to implement a more generic (but more expensive)
> variant to handle essentially random polys that may intersect.
> I think such a routine won't be linked to the display environment,
> but more of an on the fly polygon intersector.
> 
> Taking comments... ?
> 
> --
> Eric G. Miller <egm2 at jps.net>
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

The islands always gives some kind of problems for handling them 
because one traditional way is to present them in reverse order (rings)
than the outside polygon.  

I though of a structure that may help.  This structure define areas 
and polygons.  An area is made of an external polygon and may have zero 
to n islands.  Islands are still polygons and areas for others and 
thus share boundaries.  This structure should reduce the number of funtions 
because polygons are always defined the same way; ex. the surface of an 
area is the surface of the external polygon minus the surfaces of the 
islands polygons.  The polygons are only define once eventhough they are 
used in more than one area.


Struct Area {
  . . .

  polygonNo : External_polygon_No ;
        int : Nb_Island ;
polygonNo * :  List_Polygon_No ;

, . .  

}

Struct Polygon {
  polygonNo : Polygon_Number ;
  . . .
        int : Nb_Edge ;
   EdgeNo * : Edge_List ; 
  . . .
}

Struct Edge {
     EdgeNo : Edge_Number :
. . .
  segmentNo : Segment_Number ;
       Node : First_Node ; or direction ;
       Node : Last_Node ;
  . . .
}

Struct Segment {
  segmentNo : Segment_Number ;
   vertex * : Vertex_List
  . . .
}

With this structure, areas, islands and even linear features 
can share edges.  Areas can have islands which are areas that can 
also have islands.

This approch depend heavily on lists.

I willing to spend some time to identify the impact on the GRASS 
vector format and its topology.


Your comments?  Your interest?



-- 
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace at grr.ulaval.ca