Snap-rounding might help somewhat, to deal with very small slivers. But
(as usual in data cleaning issues) its usefulness is going to be
dependent on the nature of the errors in the dataset. In my experience,
snap-rounding is more of a technique for improving the robustness of
overlay computation, rather than a general technique for gap/sliver
elimination. If the only thing wrong with the data is due to some minor
jitter in the coordinate precision, then SR can work. But often
datasets have gaps/slivers which are relatively large, to the point
where you would have to snap to a very coarse grid to get rid of them
all. This would lose too much precision in the coordinates. At this
point more specific algorithms are required to remove slivers.
But SR would certainly be worth having in the toolbox, for use when
necessary.
One slight issue is that SR has to be performed globally on a dataset,
not on pairwise geometries. So it could be built in to the ST_union
aggregate, but I'm not sure how you'd provide it in a more granular way.
strk wrote:
I was having similar issues with unioning country boundaries
from the gadm dataset [1], and was thinking how would snaprounding
deal with the issue (ie: what brings in, what dangers introduces).
What do you think Martin ?
Maybe it'd be worth exposing the snapping version more, possibly
taking a tolerance explicitly.
[1] http://www.gadm.org/
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
On Tue, Apr 13, 2010 at 09:05:07AM -0700, Martin Davis wrote:
PostGIS (actually GEOS, which mirrors JTS) doesn't use a tolerance
during geometry union operations. It's possible that Arc does, which is
why you're seeing a difference.
What this indicates is that your data is not 100% cleanly noded. You
could try snapping all your data to a small-size grid - that can
sometimes fix problems of this sort. Although it may also introduce
gaps...
Lee wrote:
Hi all, First post but have been lurking for a long time.
In the process of migrating some geoprocessing procedures over to our open
source stack, I came across a difference in results from postgis' st_union
vs. arcgis' dissolve. From what I can tell these functions should be
synonymous in theory, despite their naming. (?)
It seems like st_union is not doing a "clean" union, some slivers are
remaining.
Original parcel fabric: http://quimby.ca/original.jpg
Dissolved by ArcGIS: http://quimby.ca/dissolved_by_arcgis.jpg
st_union by postgis: http://quimby.ca/dissolved_by_postgis.jpg
The input to both functions was the same table in postgis. I am defining
the geometry simply as select
st_union(current_assessment_parcel.the_geom) AS the_geom
Postgresql 8.4.1
Postgis 1.4
Is this simply a difference in tolerance? or am I seeing something else
here.
Thanks,
Lee.
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
