Agreed, Andy. Good summary.
I think the operation also is meaningful for the case (line, polygon) =>
line (this is equivalent to a combination of line.difference(polygon)
and line.intersection(polygon) )
Having thought about this with an eye to implementation, I've take the
definition a bit further:
* The result of split(g1, g2) is a two-component GeometryCollection,
GC(c1, c2).
* The first component c1 is the portion of g1 which lies to inside, to
the left of, or before, g2 (depending on whether g2 is a polygon, line
or point). The second component c2 is the portion of g1 which lies
outside, to the right of, or after g2.
* The types of c1 and c2 are the same as g1. c1 and c2 may be empty, in
degenerate cases (e.g,. where one or more components of g1 are not
intersected, or intersected only at their boundary).
* Any components of g2 which have a position which is not well-defined
relative to g2 (e.g.which are not intersected, or which are intersected
only partially), are returned as components of c1 (--- this rule is
fairly arbitrary - a different strategy might make equal sense)
Andy Anderson wrote:
On Jun 4, 2008, at 11:49 AM, Martin Davis wrote:
To answer a question you posed on your blog, the reason that when you
subtract a line from a polygon you get basically the same polygon,
rather than say the polygon split into two halves, is that if the
latter was provided as a MultiPolygon it would be invalid, because
the halves would share line segments down the middle. Also, if the
line did not fully overlap the polygon there's no choice - you have
to return the original poly. The behaviour is thus consistent
between the two cases.
Unfortunately the SFS (and no other standard I'm aware of) doesn't
define the precise semantics of the overlay operations. So I made
'em up! Hopefully they are consistent and reasonable. There's no
doubt alternative definitions which might be useful in some cases -
but you have to choose one definition for any given function. (For
the situation above, many people would like a "cut polygon by line"
operation - hopefully that will get provided as a new function
sometime soon).
I've seen "split" as a term that is commonly used for such operations,
e.g.
geometry = ST_Split(geometry1, geometry2)
This should be defined for geometry1 of dimensionality D ≥ 1 and
geometry2 of dimensionality D or D-1, i.e. (polygon, polygon),
(polygon, line), (line, line), and (line, point). The result should be
GeometryType(geometry) == 'GeometryCollection' where for any n
GeometryType(ST_GeometryN(geometry, n)) == GeometryType(geometry1).
-- Andy
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
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
