<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi, James.<br>
<br>
This is definitely a GEOS issue. <br>
<br>
What you're seeing, of course, is the usual issue of robustness
problems - likely due to "nearly coincident" linework during the
second union. This is where I'd expect to see problems, since if
your input data is a properly noded coverage, then the first union
is simply dissolving common line segments.<br>
<br>
The only short-term recommendations is the usual one to reduce the
precision of the input geometry as much as possible (using I think
ST_SnapToGrid). This may still not solve the problem, however. The
ultimate solution is perform snap-rounding over the entire input
set. I don't think ST_Snap is doing this - AFAIK it's doing some
heuristic-based snapping only.<br>
<br>
From the long series of ticket replies, it seems like C handling of
floating point might be causing some problems too, since GEOS seems
to be somewhat less robust than JTS in these various cases (although
JTS itself is not 100% robust either).<br>
<br>
It would help if you can post the data, or a subset of it which
exhibits the problem. The problem area should be in the close
neighbourhood of the lines reported in the exception.<br>
<br>
On 2/26/2012 10:25 PM, James Sewell wrote:
<blockquote
cite="mid:E3EF1FFCCEE6124887687AF1B41B686A0A7713E7@mail-mel"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1975257140;
mso-list-type:hybrid;
mso-list-template-ids:-800971772 201916417 201916419 201916421 201916417 201916419 201916421 201916417 201916419 201916421;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New","serif";}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hello All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m never sure which list to fire these
GEOS problems from PostGIS issues to, so I’ll try them both
this time.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m using the following:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">PostgreSQL 9.1.2 on i686-pc-linux-gnu,
compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44),
32-bit<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">POSTGIS="2.0.0alpha7SVN"
GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 September 2009"
LIBXML="2.6.26" USE_STATS<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I have been closely following the updates
to GEOS / PostGIS at the end of last year with regards to
overlay routines. Since the advent of ST_UnaryUnion and the
updates in the BinaryOp code as of r3552 I have been trying to
get our overlay code working again. We currently do the
following:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->Break left layer and
right layer into smaller regions (both are multipolygons)<o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->For each region <o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0
level2 lfo1">
<!--[if !supportLists]--><span
style="font-family:"Courier
New","serif""><span style="mso-list:Ignore">o<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->Use ST_Snap to snap the
left layer (which in this case is less accurate) to a
collection of the right layer at 10E-8<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0
level2 lfo1">
<!--[if !supportLists]--><span
style="font-family:"Courier
New","serif""><span style="mso-list:Ignore">o<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->Dump the left and the
right layers to linework and collect them to two geoms<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0
level2 lfo1">
<!--[if !supportLists]--><span
style="font-family:"Courier
New","serif""><span style="mso-list:Ignore">o<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->Perform a ST_UnaryUnion
on each layer, then collect them together<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0
level2 lfo1">
<!--[if !supportLists]--><span
style="font-family:"Courier
New","serif""><span style="mso-list:Ignore">o<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->Perform a ST_UnaryUnion
on the collection (I found using this two tiered Union
approach sometimes resolved nodding errors, obviously at the
cost of speed though). If I get a non-noded intersection
problem it is here 100% of the time.<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0
level2 lfo1">
<!--[if !supportLists]--><span
style="font-family:"Courier
New","serif""><span style="mso-list:Ignore">o<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->Polygonize the output<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0
level2 lfo1">
<!--[if !supportLists]--><span
style="font-family:"Courier
New","serif""><span style="mso-list:Ignore">o<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]-->Perform overlay map to
pull through gids from original left and right layers<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At one point I did translate to the origin
before any Union operations, but this broke down as the
linework got more complex (which unfortunately happens every
month as new polygons are added).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At the moment the problem I face is the
same as my old problem (when using ST_Union, see
<a moz-do-not-send="true"
href="http://trac.osgeo.org/geos/ticket/392">http://trac.osgeo.org/geos/ticket/392</a>).
When performing the second ST_UnaryUnion of the collected left
and right lineworks (which are valid) I get the following:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">GEOSUnion: TopologyException: found
non-noded intersection between LINESTRING (149.169 -37.739,
149.169 -37.7391) and LINESTRING (149.169 -37.7391, 149.169
-37.739) at 149.16916209449002 -37.739087184984776<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This year I’ve been familiarising myself
with the code and reading through all the old posts I can find
which apply to this.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I just wanted to throw this list post out
there to see what others had to say about this issue. It seems
to have been round for a while now, and from what I can tell
it’s not an easy fix.
<o:p></o:p></p>
<p class="MsoNormal">Yum install<o:p></o:p></p>
<p class="MsoNormal">Is it likely to be a precision issue? I am
currently upgrading my GCC version so I can try this
<a moz-do-not-send="true"
href="http://trac.osgeo.org/geos/ticket/504">http://trac.osgeo.org/geos/ticket/504</a>,
does anyone have any thoughts on if that might help?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Or is the issue more likely to be as
described here? <a moz-do-not-send="true"
href="http://trac.osgeo.org/geos/ticket/459">
http://trac.osgeo.org/geos/ticket/459</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Sorry for the long post, just hoping to get
some discussion going. I will try to post a fresh testcase
which causes the error tomorrow.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif"">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">James
Sewell </span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999"><br>
</span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">Solutions
Architect </span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999"><br>
</span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">LISAsoft </span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999"><o:p></o:p></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">
<hr style="width:315.0pt" align="left" size="2"
width="420">
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><b><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">Ph: </span></b><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">+61
3 8680 3250 <b>Fax: </b>+61 3 8680 3299 </span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999"><br>
</span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">Level
9, 601 Bourke St, Melbourne Vic 3000<o:p></o:p></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999">
<hr style="width:315.0pt" align="left" size="2"
width="420">
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#4F81BD"><a
moz-do-not-send="true" href="http://www.lisasoft.com/"><span
style="color:#4F81BD;text-decoration:none">http://www.lisasoft.com</span></a></span><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#999999"><br>
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<hr>
<font size="1" color="Gray" face="Arial">The contents of this
email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made
that this email is free of viruses or other defects. If you have
received this communication in error, you may not copy or
distribute any part of it or otherwise disclose its contents to
anyone. Please advise the sender of your incorrect receipt of
this correspondence.<br>
</font>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
geos-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:geos-devel@lists.osgeo.org">geos-devel@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/geos-devel">http://lists.osgeo.org/mailman/listinfo/geos-devel</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<p class="" avgcert""="" color="#000000" align="left">No virus
found in this message.<br>
Checked by AVG - <a moz-do-not-send="true"
href="http://www.avg.com">www.avg.com</a><br>
Version: 2012.0.1913 / Virus Database: 2114/4833 - Release Date:
02/26/12</p>
</blockquote>
</body>
</html>