[postgis-users] AsSVG inner poly reversed

Tue Apr 5 11:06:16 PDT 2005

On Tue, Apr 05, 2005 at 07:04:29PM +0200, klaus Förster wrote:
> to produce a hole in svg path-elements you indeed need oposite ring 
> directions - http://svg.cc/pg/assvg/posts/20050405/normal.svg shows the 
> outer ring running clockwise and the inner ring running 
> counterclockwise. after intersection both run the same direction so the 
> hole disappears - http://svg.cc/pg/assvg/posts/20050405/intersect.svg
> 
> as strk pointed out, postgis doesn't need a specific direction to 
> distinguish a hole from a shell and it seems to convert directions 
> during intersection. strk, can the ForceRHR() function solve this issue?
> will it revert direction of the interiorRing back to the original?

It should. It is "Force Right Hand Rule".
If SVG *requires* this we might do this internally.
--strk;

> 
> klaus
> 
> Sean M. Montague wrote:
> >AsText returns the inner poly in the reverse direction also.  I'm still 
> >using 0.91 since I'm still learning PostGIS basics and didn't want to 
> >bother with constantly uninstalling and reinstalling.  When I first 
> >noticed the problem, I posted on the yahoo SVG group to identify why I was 
> >having display problems.  Doug Schepers responded with this:
> >
> >"I haven't looked at it closely, but I suspect that the inner path is 
> >going the wrong way (that is, deasil or widdershins) with respect to the 
> >outer path."
> >
> >Sure enough, this is exactly what is happening.  When I compare the two 
> >geometries, the intersect returns the inner ring in the opposite 
> >direction.  Whether going the wrong way is opposite or the same as the 
> >outer poly I'm not sure, I just know one works and one does not.  I will 
> >try the ForceRHR() function and test it on several cases, but in the past 
> >I haven't had this problem.  So I wonder if it is limited to certain 
> >shaped polys.  For instance, the hole I created is a circle created with 
> >ArcView 3.x.  I will investigate this.
> >
> >I have attached two very small SVG files zipped.  The intersect.svg is 
> >exactly that, what is returned when I intersect it with a box, and 
> >normal.svg is just the_geom where Name = "One".  This way you can see the 
> >SVG text returned and view it in a web browser.  Thank you for your 
> >responses.
> >
> >
> >-----Original Message-----
> >From: postgis-users-bounces at postgis.refractions.net 
> >[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of 
> >strk at refractions.net
> >Sent: Tuesday, April 05, 2005 1:31 AM
> >To: PostGIS Users Discussion
> >Subject: Re: [postgis-users] AsSVG inner poly reversed
> >
> >I don't think AsSVG checks ring directions, and postgis doesn't
> >need a specific direction to distinguish an hole from an shell.
> >
> >If the SVG format really requires specific direction I think
> >AsSVG() should take care of that. 
> >
> >Check out the ForceRHR() function to change vertex order manually.
> >
> >--strk;
> >
> >
> >On Tue, Apr 05, 2005 at 09:12:05AM +0200, klaus Förster wrote:
> >
> >>hi Sean,
> >>
> >>does this occur when you use AsText() as well or is it limited to 
> >>AsSVG()? are you using the latest PostGIS version? AsSVG(the_geom,0,8) 
> >>seems to be the notation for an old version where precision was 
> >>specified by number of significant digits and there some other bugs in 
> >>this version as well.
> >>Could you give an example with the original inner ring? you're using 
> >>"..." to indicate you ommit some coords and the inner ring presented 
> >>here is 4 units wide so it's hard to visually figure out direction with 
> >>marker-symbols.
> >>i think it's not true that in the first poly "the inner path is returned 
> >>in the same direction as the out polygon." outer and inner path have to 
> >>follow different directions to create a hole in SVG.
> >>
> >>klaus
> >>
> >>Sean M. Montague wrote:
> >>
> >>>In my efforts to try and narrow my problem down and simplify my examples
> >>>of some intersection problems, I've run across another oddity.  PostGIS
> >>>is returning the inner polygon AsSVG of an intersection in reverse order
> >>>to the outer polygon, causing display problems.  The inner polygon
> >>>should be a hole, and when returned properly, have no fill.  Below are
> >>>two sets of sql statements from my PHP code.    The first is just the
> >>>poly "One" from table "test_02".  The SVG is below that.  This displays
> >>>properly because the inner path is returned in the same direction as the
> >>>out polygon.
> >>>
> >>>$sql = ("SELECT  AsSVG(the_geom,0,8) As the_geom
> >>>	From test_02
> >>>	WHERE Name='One'");
> >>>
> >>>--The outer polygon coords follow the first M, and the inner follows the
> >>>second M.  I added comas and deleted the cords between the first 4 and
> >>>last 4 for simplicity purposes.  These are in the correct order.
> >>>
> >>>(outer)M -358 -4857 2866 -4235 3090 -2614 5520 -89 3969 4284 -651 4605
> >>>-4978 2965 -5719 -1842 -2978 -4556 -358 -4857
> >>>(inner)M 2083 -447, 2082 -497, 2081 -548, 2079 -598, ... 2079 -295, 2081
> >>>-346, 2082 -396, 2083 -447
> >>>
> >>>--This is how it would look normally.
> >>>
> >>>M -358 -4857 2866 -4235 3090 -2614 5520 -89 3969 4284 -651 4605 -4978
> >>>2965 -5719 -1842 -2978 -4556 -358 -4857 M 2083 -447 2082 -497 2081 -548
> >>>2079 -598 ... 2079 -295 2081 -346 2082 -396 2083 -447
> >>>
> >>>
> >>>The second is the intersection between the_geom from table "test_02" and
> >>>a poly defined by the coordinates $theXMax and so on.
> >>>
> >>>$theXMax= 5651;
> >>>$theYMax= 5009;
> >>>$theXMin=-6072;
> >>>$theYMin= -4732;
> >>>
> >>>$sql = ("SELECT  AsSVG(intersection(the_geom,
> >>>PolygonFromText('POLYGON(($theXMin $theYMax, $theXMax $theYMax, $theXMax
> >>>$theYMin, $theXMin $theYMin, $theXMin $theYMax))',32767)),0,8)
> >>>	As the_geom
> >>>	From test_02
> >>>	WHERE Name='One'
> >>>	AND the_geom && PolygonFromText('POLYGON(($theXMin $theYMax,
> >>>$theXMax 	$theYMax, $theXMax $theYMin, $theXMin $theYMin, $theXMin
> >>>$theYMax))',32767)");
> >>>
> >>>--Notice that the inner poly cords are reversed.  This causes display
> >>>problems.  The inner poly has a fill when it should not.
> >>>
> >>>(outer)M -358 -4857 2866 -4235 3090 -2614 5520 -89 3969 4284 -651 4605
> >>>-4978 2965 -5719 -1842 -2978 -4556 -358 -4857
> >>>(inner)M 2083 -447, 2082 -396, 2081 -346, 2079 -295, ... 2079 -598, 2081
> >>>-548, 2082 -497, 2083 -447
> >>>
> >>>Any insight would be appreciated.
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>postgis-users mailing list
> >>>postgis-users at postgis.refractions.net
> >>>http://postgis.refractions.net/mailman/listinfo/postgis-users
> >>
> >>-- 
> >>        O-.
> >>        /_ )
> >>         | (U
> >>klaus*   /|
> >>       / /
> >>       ~ ~
> >>_______________________________________________
> >>postgis-users mailing list
> >>postgis-users at postgis.refractions.net
> >>http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >_______________________________________________
> >postgis-users mailing list
> >postgis-users at postgis.refractions.net
> >http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >postgis-users mailing list
> >postgis-users at postgis.refractions.net
> >http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> -- 
>          O-.
>          /_ )
>           | (U
> klaus*   /|
>         / /
>         ~ ~
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users