[postgis-users] shp2pgsql inner/outer ring detection bug

[strk]

jeffloun wrote:
> I looked at the file you sent and it is really hard for me to tell what is supposed
> to be happening visually when there are 25 rings, some of which are inside and some
> of which are not and other multipolygons. Can you attempt to create a contrived
> shape file example that has as few polygons as possible that still results in the
> errors you are encountering. I just don't have a good idea of what the problem
> really is with this data.

I'm sorry, but the only easy way I have to create a new shapefile is with
pgsql2shp so it won't be a good way to go...

I think the problem can be generally put in these words:

	- Shapefile file format requires shapefiles to contain
	  clockwise ordered vertex for outer rings and
	  counterclockwise ordered vertex for inner rings
	  (we are talking about POLYGON type shapes).

	- Postgis requires Polygons to have outer ring listed
	  first and inner rings (holes) listed after that.

	- shp2pgsql does its best to transform inner/outer 
	  information from one format to another.
	
	- *ASSUMING* shp2pgsql does not mess with vertex ordering
	  the resulting pgsql polygon records *SHOULD* have the
	  first ring defined by clockwise-ordered vertex and the
	  others by counterclockwise-ordered vertex.

If the ASSUMPTION in the last statement is TRUE, then it will be
easy to test wheater shp2pgsql is doing the right think just checking
for the coherent consequence (first ring clockwise, other rings
counterclockwie).

This is what I did, and I found out this is not
always the case. I used the area-computation trick I found in 
ring_check for it, so I think it is not a problem to do it yourself.
I don't know how easy it would be doing this check directly in the
shp2pgsql code since it looks like ring_check does a lot of work
also printing out SQL code snippets thus making it hard to do a final
check on the vertex order, but for sure it can be done with a stored
procedure like area2d (without using absolute value of course).

If the *ASSUMPION* above is FALSE I'll try to
find another reason why shp2pgsql should render a hole like
an outer ring (the vertex ordering in pgsql made me think the
shapefile was not dirty as I though at the beginning, even when
seing other shapefile viewer rendering it in the right way)

> 
> As well, Chris was wrong, it was the pgsql2shp code that has been update to do with
> vertex ordering just lately...
> 
> Also, I just want to confirm that you relize the database format for multipolygons
> has nothing to do with vertex ordering(shapefiles on the other hand do). The
> database just required the form
> multipolygon((outer,inner,inner,inner),(outer,inner),(outer),(outer, inner,
> inner))  I just want to make sure that we are understanding the correct output
> format shp2pgsl is trying to achieve and hopefully that will help you isolate the
> problem exactly, then I will know exactly what to fix...
> cheers,
> -Jeff
> 
> strk wrote:
> 
> > chodgson wrote:
> > > I think this code has been updated since 0.7.3. You should really try the CVS
> > > version. Let us know if it that solves the problem or not.
> >
> > These are the changes between 0.7.3 and current CVS:
> >
> >         106c106
> >         <       char    *start, *end1, *end2 = NULL;
> >         ---
> >         >       char    *start, *end1, *end2;
> >
> > By the way.. I made some other tests importing from shapes to
> > postgis and then exporting back with shp2pgsql and pgsql2shp.
> > Each time a different polygons layout is generated in the database...
> > The shapefiles keep their original size but I can imagine the
> > oriantation of polygons are different between runs.
> >
> > I think the ring_check function has to be controlled, it's
> > not easy to tell since the shp2pgsql code is pretty messy.
> >
> > --strk;
> >
> > >
> > > Chris
> > >
> > > Quoting strk <strk at freek.keybit.net>:
> > >
> > > > Hi jeff,
> > > >
> > > > I'm using shp2pgsql from postgis version 0.7.3.
> > > > The inner/outer ring detection code fails for this shape:
> > > >
> > > >     ftp://ftp.refractions.net/pub/refractions/dirty.tgz
> > > >
> > > > In particular the resulting record with gid=2 will be a MULTIPOLYGON
> > > > with 26 polygons inside. The last one (geometryN 25) have just one ring
> > > > with vertex defined in counterclockwise order.
> > > >
> > > > It is supposed to be a hole ( the shapefile is not dirty )
> > > > but shp2pgsql created a new polygon for it instead of defining
> > > > it as an inner ring.
> > > >
> > > > Apart from this peculiar shapefile i think this is a general issue.
> > > > If I'm not wrong shp2pgsql should *never* create a polygon with
> > > > first/outer ring defined in counterclockwise order or a inner/hole
> > > > ring defined in clockwise order ...
> > > >
> > > > Can you please check this out ?
> > > >
> > > > --strk;
> > > >
> > > > _______________________________________________
> > > > 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