[postgis-users] st_union

[Martin Davis]

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