[postgis-devel] [PostGIS] #794: Deprecate (or delete) function ST_ModEdgesSplit and add ST_ModEdgeSplit

aperi2007 aperi2007 at gmail.com
Wed Jan 19 13:12:09 PST 2011


>I agree on considering this a new beginning, and would like to take the
>chance to even re-evaluate the model, as soon as I come out of the water.
>
>For example (just to put out some pointers) all the next/prev_edge fields
>in the edge table are currently completely unused, so would like to either
>drop them or use it (if tests show they help speeding up some uses).


In the esri coverages the arcs are described with

start-node, end-node, left-poly, right-poly, edge-id, user-id

so there-isn't the next-left-edge and next-right-edge.
But the esri topology is an old "arc-node" topology.

The sql/mm is instead a "face-arc-node" topology.

Another example of "face-edge-node" topology model come from oracle.
In Oracle the edge table is (from oracle topology docs)
more like sql/mm topology model.
Infact oracle edge table has more information:

edge-id, start-node-id, end-node-id, next-left-edge-id, 
prev-left-edge-id, next-right-edge-id, prev-right-edge-id,left-face, 
right-face, geometry

where
next-left-edge-id, next-right-edge-id are both for counterclockwise 
delineation of perimeters of faces left and right.

instead
prev-left-edge-id, prev-right-edge-id are both for clockwise delineation 
of perimeters of faces left and right

"More redundancy for more performances."

I think is better maintain next-left-edge and next-right-edge.
remove it is a downgrade to an old model like esri topology.

Regards,

Andrea




More information about the postgis-devel mailing list