[postgis-users] strange beahviuors by GEOS

[James S reid]

hi - Im testing a polygon in polygon selection using the within() operator
on two tables and have come across some odd return sets. essentially, I can
confirm the 'proper' results in arcview (booh hiss) but postgis (using geos)
returns 1 less poly for no reason that i can see!

trying a different selection on a dataset with islands brings back the
correct number of records but, (at least when pgsql2shp'd and viewed in av3)
a very messy mix of correct polys and spurious 'join the dots' type polys.
Im not sure if the latter is the fault of the  geos computation or the
dumper or a result of accepting the loaders defaults for the original
shapefile load?

anybody shed any light on this - Im particularly confused by the first
problem - unless its a precision thing?

cheers

james
----- Original Message ----- 
From: "Ralph Mason" <ralph.mason at telogis.com>
To: "PostGIS Users Discussion" <postgis-users at postgis.refractions.net>
Sent: Monday, February 23, 2004 2:24 PM
Subject: Re: [postgis-users] Light WeightLight Weight Geometry
(LWGEOM)Proposal


> Mark Cave-Ayland wrote:Anyhow a couple of suggestions:
>
> >>Be able to use the extra bit to specify floats for a bounding box.  I
> >>think this would almost always be a good optimization.
> >>A way to specify that the data is in floats not doubles.
> >>Perhaps using
> >>the extra space in the geometry type field.
> >>
> >>
> >
> >I think the main reason for this is the the OGC spec specifies the use
> >of doubles so if PostGIS were to use floats then it would no longer be
> >compliant OGC compliant :(. I can also see more issues arising with
> >accuracy when converting between floats/doubles that would alter the
> >geometric data - for example what if I were to take a dataset using
> >double coordinates and transfer to a DB compiled to use float
> >coordinates? I'm guessing that at the moment, the pg_dump would have to
> >be in WKB format since this contains endian information required for
> >transferring across machines - so how would we indicate to the user that
> >their GIS data had been altered? Perhaps we do need to include endian
> >information in the type byte after all...
> >
> >
> If the  bounding box is just an optimization so it doesn't need to be
> calculated for each row during a select where a non geometric index is
> being used, then a float representation should be just as good, so long
> as it's inflated enough that it covers the loss in precision.  Seems you
> always need to use a 'real' operator after a bounding box operation
> anyway.  Thus cutting the side in half appears to have no unwarranted
> side effects except perhaps a very small amount of false positive matches.
>
> As for the 'dump' it is problematic, the WKB type field is 32 bits, so
> perhaps if the user has specified a column that isn't compliant a non
> compliant WKB (or not so well known binary) is dumped with some
> 'extended' types.
>
> The main idea here is, if a float or an int32 high enough resolution for
> the application, why force a dataset that is twice as large to be
> 'compliant'.  The user knows best what they want to do, and how they
> want to do it. Using an a couple of  int32's I can specify any point on
> the planet down to a 10cm square area, what do the extra 8 bytes give me
> if i don't need them? I personally am looking at a dataset of about 14gb
> in shapefiles.  A little loss of resolution for speed is an option I
> would like to have, even if I'm non compliant.  I can also think of
> other examples like cad applications - integer data is probably
preferable.
>
> It seems that WKT would be an easy go-between for non compliant types.
> Then to get a 'confirming' table you can create a view that takes it
> between a WKT and then to a conformant WKB with a function that can
> create WKB from WKT and a set of flags saying the desired extended format.
>
> >>Another Idea, use the spare bit to indicate an extended type byte
> >>(coming after the type byte).
> >>
> >>This could be something could have extra flags if present.
> >>
> >>Bounding box data type
> >>Float bounding box
> >>Int16    bounding box
> >>Int32   bounding box
> >>
> >>Data Type
> >>Float data
> >>int 16 data
> >>int32 data
> >>
> >>
> >
> >Extensibility seems interesting. Was there a particular application that
> >you had in mind for this feature?
> >
> >
> Keeping room to extend a data format is always worthwhile.
>
> Ralph
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users