[postgis-users] AsSVG inner poly reversed

Sean M. Montague smontague at ATSDenver.com
Tue Apr 5 11:30:59 PDT 2005 

I am not sure if this is relevant, but I created a simpler example just to see what would happen, and in the SVG output the inner poly comes first.  Still has the same result as the original, display problems with the intersected polygon.  I attached the two SVG files.  They are very small and simple to read.  Off the top of my head, it would seem that applying the ForceRHR() function would be difficult.  What if I have city boundary such as Denver, which has many holes in it, an annoying feature of western US cities, how do I distinguish the outer from the inner polygon to apply the ForceRHR() function?  Just a thought.  I think doing it internally would be best.

-----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 12:06 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] AsSVG inner poly reversed

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
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svg.zip
Type: application/x-zip-compressed
Size: 728 bytes
Desc: svg.zip
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20050405/9cb6f3fe/attachment.bin>

More information about the postgis-users mailing list