Well, I have already found problems with this mod. I incorrectly assumed
that the clock-ness of the shells that were added as holes would be fixed by
later methods. That appears not to be true. Even though the mod makes the
holes appear correct, they still test bad with the QA tool. I'll have to
uncomment out the reverseRing loop.
@Michaël, surely you didn't make the mistake of thinking I knew what I was
doing? ;-) My check for ((shells.size()>1) && (holes.size()== 0)) is
simply an attempt to minimize any damage my hack might do. Sorry the code
had so many changes. I knew I needed to subroutine the inline code so I
copied the work that was already done in geotools 2.5.
regards,
Larry
On Fri, Apr 4, 2008 at 2:00 PM, Michaël Michaud <[EMAIL PROTECTED]>
wrote:
> Martin Davis a écrit :
>
> >Michaël Michaud wrote:
> >
> >
> >>... about the second point, as you know SFS a no one, you may have an
> >>answer to the following question :
> >>why polylines may be made of lines sharing their boundaries
> >>and multipolygons cannot be made of polygons sharing their edges (if
> >>that's what "shells can touch at any finite number of points" means)
> >>
> >>
> >>
> >That *is* what I meant by "shells can touch at any finite number of
> points".
> >
> >I can't see into the minds of the standards authors, but speaking as a
> >developer who has implemented the standard, the restriction on how
> >polygon shells touch makes for nicer topological assumptions, and hence
> >simpler code. With this rule you can assume that all edges in polygon
> >geometries are truly on the topological boundary - i.e that they divide
> >the polygon interior from the exterior. Without this assumption, you
> >have to basically do a "dissolve" to remove "interior" edges before
> >doing any further processing.
> >
> >Polylines don't offer quite such a strong topological distinction (they
> >don't divide the world into interior and exterior), so there aren't any
> >unpleasant implications to just letting their linework "go anywhere it
> >wants to".
> >
> >There are other assumptions which SFS could have made to make processing
> >simpler - such as enforcing an orientation for polygon rings. But I
> >guess they wanted to open the model up as much as reasonable, so as not
> >to make a whole bunch of geometry invalid. Although then they could
> >have allowed "inverted" polygons (self-touching at a point - ArcSDE
> >style) as well.
> >
> >M
> >
> >
> All that makes sense to me.
> Thanks for the detailed answer.
>
> Michaël
>
> >
> >
> >
> >
> >
> >
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
http://amusingprogrammer.blogspot.com/
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
