[GRASS5] Changes between 5.0.0 release and current release branch

[David D Gray]

Eric G. Miller wrote:
> On Thu, Nov 28, 2002 at 09:26:39AM +0100, Radim Blazek wrote:
> 
>>On Thursday 28 November 2002 03:29 am, Eric G. Miller wrote:
>>
>>>*  Fixes interior boundary winding (shapefiles have exteriors clockwise,
>>>   interiors counterclockwise) for areas with holes.  AFAIK,
>>>   Vect_get_area_points and Vect_get_isle_points always return clockwise
>>>   polygons. So isle point orders are reversed. Isles will come up
>>>   twice, once as interior and once as exterior. (If my understanding of
>>>   these API's is incorrect, someone please let me know.)
>>
>>I thought that direction for areas/isles is the same in grass as in shapefile
>>and Vect_get_isle_points returns counterclockwise vertices:
>>
>>struct P_isle {
>>  plus_t  *lines;  /* Boundary Lines (Negative means N2 to N1
>>                      counter-clockwise) */
>>}
>>
>>int Vect_get_isle_points () {
>>      if (Isle->lines[i] < 0) {
>>          start = Points.n_points - 1; inc = -1 ; end = 1;
>>      } else {
>>          end = Points.n_points - 2; inc = 1 ; start = 0;
>>      }
>>}
>>
>>It is strange if shapefiles with reverted order of isles are correct.
>>Did you check it in ArcExplorer or other ESRI SW (AE runs on Linux)?
> 
> 
> I checked w/ ArcGIS 8.1 against screen dump of the drawn map as GRASS
> areas and they rendered the same (vs. earlier version with direction
> reversal for "isles").  And areas were the ones I wanted.  If I remember
> correctly, other folks checked as well and reported success.
> 
> The above snippet is identical in Vect_get_area_points.  They are
> reversing edges that natively are in the opposite order of the flow
> around the polygon.  I guess we'd have to hunt around the build code to
> see how the edges are ordered to build areas and isles.  I still think
> both "areas" and "isles" are built in clockwise order...
> 

Hi Eric

The code for v.in.shape as it is now requires the points to be ordered 
in the 'correct' order, ie. clockwise for outer ring and anti-clockwise 
for islands. If, as sometimes happens with AV 3.x at least, an outer 
ring say is ordered the wrong way, the shape is not imported, but a 
warning is given, eg:

++++++++++++++++++++++++++++++++++++++++++++++++++++++

       POLYGON (SHAPE) NUMBER  131

   Polygon contains 0 outer rings and a total of 0 holes.
   The structure is in an inconsistent state with 1 dangling holes.
   Area point is not provided.
   No height co-ordinates are supplied for the vertices.

++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Counts are wrong because the operation is not completed]

But, shapes exported with the pre-changes v.out.shape are re-imported OK 
with v.in.shape, so the islands in the shape file must circulate the 
right way. That would suggest they are in the right order in the 
dig_plus file also. I'll check this with the new module.

The polygon control code (v.in.shape/polygon.c) should be modified to 
not depend on rings' direction of circulation. This is in v.in.shape now 
and is to be more general for 5.1 (eg. interface to OGR). That was a low 
priority and I wasn't going to deal with it for stable, but now I think 
I'll move it up the queue a bit.

David