[postgis-devel] troubling test case

[Carl Anderson]

sympatheic parties,

This is a plea for help.  I need a some ideas about where to start to 
hunt down
a solution to this failure case.

the cause of the failure could be plpgsql or GEOS or postgis or the
interaction between them.

you will need to
create a test schema
and
run 2 sql scripts prepping the test environment
and
run a plpgsql function


-------------------------------

get http://wms.co.fulton.ga.us/data/postgis/diff_test.tar.gz

unpack in a temp directory


create the schema zoning
create the test tables
  psql mytab < build_tables.sql
build the test function
  psql mytab < build_fcn.sql
run the test function
  select zoning.make_zoning('102-01-2004',-1-,-1);

the function essentially applies shapes to a non overlapping canvas 
where no other case
has been previously applied (voids if you want).  the function  alters 
the incoming
geometry by  finding its difference wiht all geometries already on the 
canvas.

you should get lots on NOTICES and an error during the operation
 on shapes with the geo_oids of 7897 and 7899.

NOTICE:  2000Z -0151 (7897)
NOTICE:         vs (7899) 102667 102667 MULTIPOLYGON
NOTICE:  TopologyException: no outgoing dirEdge found 
(2.26362e+06,1.49141e+06)
CONTEXT:  PL/pgSQL function "make_zoning" line 91 at assignment
ERROR:  GEOS difference() threw an error!
CONTEXT:  PL/pgSQL function "make_zoning" line 91 at assignment


if so then try again
  select zoning.make_zoning('12-01-2004',7897,7899);
you should be returned 3 table names.

the middle table name contains the two shapes that
ostensibly caused the error.  it's a temporary table with a
randomly generated name so you'll have to convert <table> to
the name returned in the following instructions.


now attempt
select difference(a.shape,b,shape) from <table> a, <table> b;
it may or may not throw an error.  For me this case does continue to
throw an error after copying the shapes to another table.  

However there are other cases where copying the  ?? target case  2 shapes
to another table, leaving psql (and closing the lwgeom.so and
 geos.so libs) and returning to psql and
computing the difference on only the two target shapes succeeds, and
does not throw an error.

so the question becomes why does the plpgsql function fail inside
the GOES difference function?

Paul Ramsey, without the aid of the info I present here, thought it was 
probably a precision issue.  An earlier patch to PostGIS implementing 
both a reduceprecision and a clean function effectively dealt with any 
precision issue that may exist arising from the source data, and have 
already been applied to this dataset.

all geometries have been precision reduced to a 
g->GetFactory()->getScale() of 1000,
ie 999,999.999 and have been "cleaned" so they are valid geometries;

if you want to further reduce precision then apply the recent reduce 
precision
patch and
    update zoning.zoning_all_geo set shape = reduceprecision(shape,0.1);
    update zoning.zoning_all_geo set shape = clean(shape)
          where not isvalid(shape);
to round to the nearest 10th  ie 999,990.000

C.