[postgis-users] bug in st_difference() ?
birgit.laggner at vti.bund.de
Thu Mar 10 02:02:33 PST 2011
I have to correct me: it's not vertexes 4 and 8, I am worried about,
it's vertexes 3 (3597943 5323120) and 9 (3606024 5322587) and they are
both vertexes in both input polygons.
But, I thought about your explanation again and I think, I understand
now, what you are talking about: These 2 float points of the second
input polygon are probably located slightly within the first input
polygon (although, we are talking about nanometers!!!). Therefore
PostGIS takes them as vertexes for the result polygon and takes the next
vertexes too, because at these points the borders match again. Well, I
got the coordinates of the 2 float points from an intersection with
another polygon - how am I supposed to get the correct coordinates
causing no artefacts during ST_Difference() (Just mentioning: I am using
PostGIS 1.5, so ST_Snap() is no option)? Wouldn't it be easier to make
ST_Difference() not more precise than ST_Intersection()? What use has
such a high coordinate precision if the functions (or im- and export
modules?) can't handle it.
Thank you anyway (allthough it took a while for me to understand ;-) ),
On 10.03.2011 09:03, Birgit Laggner wrote:
> Hi Ralf,
> sorry, I don't understand. I don't want these two points in the result
> polygon of the difference, because they are located in a region that
> should be erased by the difference. I don't need them to become more
> precise. Or am I misunderstanding what you are saying?
> On 09.03.2011 16:04, Ralf Suhr wrote:
>> Hi Birgit,
>> this is only a topoligie Problem. Your secound polygon is computed
>> PostGIS and numeric precision are lost by import. In this case
>> and other PostGIS function can have results with very small errors.
>> You can clean the second polygon by move all points to the borders
>> from first.
>> 3597691.18360053 5323329.04452537 becomes
>> 3597691.183600531425327 5323329.044525371864438 and so on.
>> Am Mittwoch 09 März 2011, 15:05:43 schrieb Birgit Laggner:
>>> Dear list,
>>> when I am using ST_Difference(), I often have the problem, that the
>>> resulting geometries contain vertexes lying outside of the supposed
>>> geometry extent. My impression is that the function tries to preserve
>>> vertexes of the input geometries and does not check properly, whether
>>> the point lies inside the extent of the new geometry or not.
>>> Here an example:
>>> select st_astext(st_difference(a_geom, b_geom)) from
>>> st_geomfromtext('POLYGON((3580359 5328360,3588529 5330935,3597943
>>> 5323120,3606024 5322587,3612951 5315217,3608155 5306691,3603804
>>> 5305093,3596166 5306159,3591105 5310244,3584799 5310688,3576540
>>> 5317437,3580359 5328360))',31467) as a_geom,
>>> st_geomfromtext('POLYGON((3597691.18360053 5323329.04452537,3597943
>>> 5323120,3606024 5322587,3611561.81746298 5316695.02444028,3611480
>>> 5316582,3605931 5322425,3597573 5323069,3597691.18360053
>>> 5323329.04452537))',31467) as b_geom;
>>> results in:
>>> "POLYGON((3580359 5328360,3588529 5330935,3597943
>>> 5323120,3597691.18360053 5323329.04452537,3597573 5323069,3605931
>>> 5322425,3611480 5316582,3611561.81746298 5316695.02444028,3606024
>>> 5322587,3612951 5315217,3608155 5306691,3603804 5305093,3596166
>>> 5306159,3591105 5310244,3584799 5310688,3576540 5317437,3580359
>>> Vertexes 4 (3597691.18360053 5323329.04452537) and 8 (3611561.81746298
>>> 5316695.02444028) are out of the supposed geometry extent.
>>> I am using PostGIS 1.5.2 with GEOS 3.2.2 on a 8.4.5 PostgreSQL-DB on
>>> 64-bit SUSE Linux.
>>> Maybe, there is a simple explanation, why this behavior might be wanted
>>> - if not, I would like to complain this as a bug (or at least
>>> suggest an
>>> improvement of the function in future versions)...
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
> postgis-users mailing list
> postgis-users at postgis.refractions.net
More information about the postgis-users