[postgis-users] Preparing for Topology - St_CreateTopoGeo

[Chris English]

"POSTGIS="2.0.0SVN" GEOS="3.3.1-CAPI-1.7.1" PROJ="Rel. 4.6.1, 21 August 2008" GDAL="GDAL 1.9dev, released 2011/01/18" LIBXML="2.7.8" USE_STATS"
CREATE OR REPLACE FUNCTION st_makevalid(geometry)  RETURNS geometry AS'$libdir/postgis-2.0', 'ST_MakeValid'--> don't know that this clarifies anything   
I guess this is the latest svn.  By 'reducing' input data might that be saying take municipalities,a smaller number of multipolygons, as against a whole county?orI get the sense that "> Ideally you should be reducing your input data as much as possible> while still triggering the error." suggests that perhaps 20948 and 20949 are notthe 'actual' errors, but a point at which ST_CreateTopoGeo finally choked?
Is there a specific test I could apply to them, something to do with RHR comes to mind, though I don't know why.

I have been watching the pledge drive with interest, figuringthat the resultant incremental functionality would shieldor help shield users like myself who don't understand thatpigs are killed to make pork sausage.
If I had 250 euros, they would be yours today.
Chris


----------------------------------------
> Date: Fri, 2 Dec 2011 15:31:20 +0100
> From: strk at keybit.net
> To: postgis-users at postgis.refractions.net
> Subject: Re: [postgis-users] Preparing for Topology - St_CreateTopoGeo
>
> On Fri, Dec 02, 2011 at 07:59:09AM -0500, Chris English wrote:
>
> > ERROR: Edge 20949 has face 0 registered on the side of this face, while edge 20948 has face 7446 on the same sideSQL state: P0001Context: SQL statement "SELECT topology.AddFace('union_cty_topo', '01030000200B7D00000100000005000000C05BF04EE05F1F410065B68BD8AC24418417744EE05F1F416FD8ED8BD8AC244180CEEC4FE05F1F41C0518C8BD8AC24411E636950E05F1F4175BA548BD8AC2441C05BF04EE05F1F410065B68BD8AC2441', true)"PL/pgSQL function "st_addedgemodface" line 607 at EXECUTE statementSQL statement "SELECT topology.ST_AddEdgeModFace(atopology, snode_id, enode_id, rec.geom)"PL/pgSQL function "st_createtopogeo" line 152 at PERFORM
> >
> > The currently offending geoms:
> > 20948 --> "01060000200B7D0000010000000103000000010000000500000080CD197443872141804C827B8B72244160C59F12AC872141007C974465722441200CCDF85687214100F7FE58B6712441006624DF018721410032D76ED571244180CD197443872141804C827B8B722441"20940 --"01060000200B7D00000100000001030000000100000007000000204F2F7CE23C214140AA79907071244180EF6AE12B3D2141C0EF55BC50712441E0ACD564CC3C21414008958C7470244140F668FF823C2141C0C2B86094702441E0C3B6D3A23C21414066FBC5DD702441607EDAA7C23C2141C006372B27712441204F2F7CE23C214140AA799070712441"
> >
> > The run to this point took 12 hours and is 1/7th of the rows.
> > Any thoughts on further, better preparing my parcels prior to processing with St_CreateTopoGeo would be greatly appreciated.
>
> Are you running with lastest SVN revision ?
> Ideally you should be reducing your input data as much as possible
> while still triggering the error.
> It is most likely a robustness issue.
>
> The downside of ST_CreateTopoGeo is that it wants all-or-nothing
> while an incremental approach would get you further (and closer
> to the issue). The pledge at the signature is to get the incremental
> functionality.
>
> --strk;
>
> ,------o-.
> | __/ | Thank you for PostGIS-2.0 Topology !
> | / 2.0 | http://www.pledgebank.com/postgistopology
> `-o------'
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users