[Gdal-dev] SDE Driver Change

Bill Thoen bthoen at gisnet.com
Fri Oct 27 10:09:39 EDT 2006


Watch out for MIF and TAB files... In MapInfo formats there are no enforced
associations between interior rings ordered deosil or widdershins (or
clockwise/counterclockwise) and whether they are holes or
contours/islands. In fact, the first ring isn't necessarily the exterior
ring either (although it usually is). I think MapInfo uses some sort of a
border crossing algorithm to determine what's a hole and what's a part of
the region (multipolygon). They definitely don't rely on ring point
ordering.

- Bill Thoen

 
On Fri, Oct 27, 2006 at 08:47:13AM -0400, Christian Ratliff wrote:
> 
>   Perhaps you can help me figure out this puzzle. In a multi-polygon,
> from what I can find, the OGRLinearRing::isClockwise() function is the
> way to determine if a ring is a contour (clockwise) or a hole
> (counter-clockwise). When reading GML, MIF, TAB and SHP if isClockwise()
> is true then the ring is a contour, otherwise it is a hole.  However,
> when reading from ARC/SDE the behavior was opposite.
> 
>   I would rather avoid encoding knowledge of the data source in to the
> OGR geometry processor code, up in my application.  Except for that
> option, how is one to determine the implication of isClockwise() or
> perhaps I totally flubbed and missed a 'isHole()' method somewhere?
> 
> Thanks!
> christian
> 
> -----Original Message-----
> From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
> Sent: Thursday, October 26, 2006 2:15 PM
> To: Christian Ratliff
> Cc: gdal-dev at lists.maptools.org
> Subject: Re: [Gdal-dev] SDE Driver Change
> 
> Christian Ratliff wrote:
> >  
> >   During the QA process for our product, we noticed polygons were 
> > being read from ARC/SDE with a reversed (left hand) winding.  This 
> > results in
> > isClockwise() returning the wrong value for all such polygons.  I 
> > updated the SDE driver with the change indicated below and then 
> > re-tested SDE and non-SDE data sources.  Everything looks good now:
> >  
> > src/ogr/ogrsf_formats/sde/ogrsdelayer.cpp
> > 719c723
> > <     nSDEErr = SE_shape_get_all_points( hShape, SE_DEFAULT_ROTATION,
> > ---
> >>     nSDEErr = SE_shape_get_all_points( hShape, 
> >> SE_RIGHT_HAND_ROTATION,
> 
> Christian,
> 
> There is no harm in doing this, but I would note that OGRPolygon rings
> are not guaranteed to have any particular handedness.  So it is unwise
> to build application on this assumption.
> 
> Best regards,
> -- 
> ---------------------------------------+--------------------------------
> ---------------------------------------+------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo,
> http://osgeo.org
> 
> 
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
> 



More information about the Gdal-dev mailing list