[postgis-users] index-based inconsistencies

[Robert Hollingsworth]

Paul,
it may not help to attach the data dump to the bug report, because I created a small table dump with 3 of the offending district polygons, loaded it myself, but the mapserver and ST_Within problems did not occur.  That's probably a good clue, that the new table got built with different index state because fewer records, record order, whatever.

Robert

Er, open an issue and attach the relevant supporting files. The
smaller the test table, the better.

P

On Wed, Mar 11, 2009 at 2:04 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> If you can provide
>
> - a data table dump and
> - a SQL query that returns different results depending on whether
> _ST_Within() or ST_Within() is used
>
> that's enough to debug with. Open an issue in the tracker.
>
> P.
>
> Turn on statement logging in PostgreSQL, then run the Mapserver
> request that causes the
>
> On Wed, Mar 11, 2009 at 1:54 PM, Robert Hollingsworth
<reh2 at prodigy.net> wrote:
>> using postgresql 8.3.4
>> using postgis 1.3.3
>> using geos 3.0.0
>> using proj 4.6.1
>>
>> I'm encountering a couple of oddities which I'm pretty sure
are related.
>>
>> I have US Census Congressional districts modeled in PostGIS.
>>
>> I've got a simple php program that uses ST_Within( ) to check a
lat,lon
>> against the congressional district polygons.  A small number of the
>> districts are causing the query to return zero records incorrectly.
>>
>> I've also got a simple php-mapscript with a LAYER to simply
display all of
>> these congressional districts.  When zoomed out around 1:400k and
further
>> out, these peculiar districts appear along side their neighbors. 
When I
>> zoom in closer, these same districts stop appearing.
>>
>> I'm pretty sure this is a problem with the spatial indexes, which
were
>> created by shp2pgsql, because I converted the search program from
ST_Within(
>> ) to _ST_Within( ), which is advertised as skipping the indexing.
>> _ST_Within( ) is a bit slower, but finds these districts ok.
>>
>> I've run VACUUM ANALYZE on the table, but this hasn't changed
anything.
>>
>> I haven't dug into the mapserver pg driver to see if there is any
way for me
>> to manipulate the generated query into skipping indexes.
>>
>> I haven't yet dug into the records further to see if they have
pathological
>> bboxes or similar.
>>
>> There are no holes in these polygons.
>>
>> Anyone have any ideas on this?
>>
>> thanks,
>> Robert H.
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20090312/ea2d9094/attachment.html>