Hi again!
Well, this is always the same problem, if I do linemerge(union()), I
have to force multi to prevent errors. Then, simplifying to linestring
seems to consume resources.
On way, would to do a view which determine if the union would lead to a
multi or a linestring.
But I don't know how to achieve this.
I have no idea either if this would also be greedy on resources.
Denis
On 03/27/2012 05:43 PM, Nicolas Ribot wrote:
Yes, it is 2.0
http://postgis.refractions.net/documentation/manual-svn/ST_CollectionHomogenize.html
Well, I am turning around the problem...
I have to do a cast, as I used
ST_Multi(ST_LineMerge(ST_Union(wkb_geometry)))::geometry(MultiLineString,xxx)
in the first view to prevent errors of unconnected lines.
Right now the best solution I have is to let the view being unusable, and
another view to report errors.
This is not very satisfying as if a problem occurs, I cannot use my view
until I fix the geometric errors.
Basically, I need to compute a view with a LineMerge returning LineString
(i.e. leaving away features leading to MultiLineString) and another view
returning IDs of features leading to MULTI.
I thought about using ST_Touches but it only uses two geometries and I can
have more in the LineMerge. No idea what to look for...
Thanks for your help. I could go deeper in the problem!
Greetings
I would then create 3 views:
One doing the actual computation (linemerge(Union)), then one view
where st_numgeometries(the_geom) = 1, and one view where
st_numgeometries(the_geom)> 1.
nicolas
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
