[postgis-users] where to register to submit bug?

Ivan Mincik ivan.mincik at gmail.com
Mon Nov 19 13:40:57 PST 2007


thanks a lot. these wrong are coming from some special format of
cadastral data in my country.  data where first saved to ESRI
shapefile by OGR, then imported to postgis by shp2pgsgl. I think that
they are invalid also for the shapefile. can it be similar issue?

again thank you very much

ivan  mincik

On Nov 17, 2007 9:34 PM, Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk> wrote:
> On Mon, 2007-10-29 at 23:25 +0100, ivan minčík wrote:
> > I made pg_dump from the table. You can download it here:
> >           http://disk.jabbim.cz/hrach@jabber.cz/bug_db.tar.gz
> >
> > You have to:
> >     1. change my database user (called ivo) to Your user
> >     2. createdb somedb
> >     3. psql -U youruser -f bug_db.sql somedb
> >
> > try
> >     select simplify(the_geom,100) from bug_table where icutjcpa =
> > '8601232244003';
> >
> >
> >
> > is it ok that way?
> > thanks
> >     Ivan
>
>
> Hi Ivan,
>
> I finally found some time to look at this, and it turns out that what
> you're seeing is a symptom of another bug in the geometry parser.
>
> By enabling debug in the DP routines, I could see that the reason the
> simplifier was crashing was that it was trying to simplify a polygon
> consisting of a single point. Here is the text representation of your
> polygon here:
>
>
> bug=# select astext(the_geom) from bug_table where icutjcpa =
> '8601232244003';
> astext
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  MULTIPOLYGON(((-333399.63 -1270249.25,-333416.78 -1270247.43,-333415.54
> -1270231.88,-333411.49 -1270209.38)),((-333408.1 -1270235.32,-333408.8
> -1270244.32,-333401.1 -1270245.02,-333400.5 -1270236.12,-333408.1
> -1270235.32)),((-333397.27 -1270210.4)),((-333397.58 -1270214.37)))
> (1 row)
>
> bug=#
>
>
> Now what is interesting is that the PostGIS geometry parser should
> reject this input because your POLYGONs don't have closed rings. You can
> see this if you try the following:
>
>
> bug=# select astext('MULTIPOLYGON(((-333399.63 -1270249.25,-333416.78
> -1270247.43,-333415.54 -1270231.88,-333411.49 -1270209.38)),((-333408.1
> -1270235.32,-333408.8 -1270244.32,-333401.1 -1270245.02,-333400.5
> -1270236.12,-333408.1 -1270235.32)),((-333397.27
> -1270210.4)),((-333397.58 -1270214.37)))'::geometry);
> ERROR:  geometry contains non-closed rings
> bug=#
>
>
> Which is the correct behaviour. So how on earth did these invalid
> geometries get inserted into the database in the first place? Due to the
> fact I was able to restore your dump, the finger points towards the
> (E)WKB parser, and you can see this is true from the following:
>
>
> bug=# select
> astext('010600002011080000040000000103000000010000000400000052B81E855E5914C100000040E96133C1EC51B81EA35914C1E17A146EE76133C18FC2F5289E5914C114AE47E1D76133C15C8FC2F58D5914C114AE4761C16133C10103000000010000000500000066666666805914C11F85EB51DB6133C133333333835914C11F85EB51E46133C166666666645914C152B81E05E56133C100000000625914C1EC51B81EDC6133C166666666805914C11F85EB51DB6133C10103000000010000000100000048E17A14555914C166666666C26133C1010300000001000000010000001F85EB51565914C1EC51B85EC66133C1'::geometry);
>
> astext
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  MULTIPOLYGON(((-333399.63 -1270249.25,-333416.78 -1270247.43,-333415.54
> -1270231.88,-333411.49 -1270209.38)),((-333408.1 -1270235.32,-333408.8
> -1270244.32,-333401.1 -1270245.02,-333400.5 -1270236.12,-333408.1
> -1270235.32)),((-333397.27 -1270210.4)),((-333397.58 -1270214.37)))
> (1 row)
>
> bug=#
>
>
> So the real bug in this case is that the (E)WKB parser doesn't seem to
> attempt to validate any geometries being passed through it :(  I've had
> a look at the parser code and it's quite a complicated beast with not
> many comments, so I imagine a fix is going to a little time to come up
> with.
>
> However, for an immediate fix you need to either remove or correct the
> invalid geometries. The following SQL should locate these geometries for
> you:
>
>
> bug=# select gid, icutjcpa, isvalid(the_geom) from bug_table where
> isvalid(the_geom) = 'f';
>
>
>
> HTH,
>
>
> Mark.
>
> --
> ILande - Open Source Consultancy
> http://www.ilande.co.uk
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>


More information about the postgis-users mailing list