ST_GetFaceGeometry - don't intercept the UniverseFace

[aperi2007]

Hi, when executing:

SELECT topology.ST_GetFaceGeometry('topo_test2',0);

the ST_GetFaceGeometry should return, as ask from the ISO specs,

an exception like:

"SQL/MM Spatial Exception - universal face has no geometry"

instead wrongly the ST_GetFaceGeometry return a record with NULL value.

I guess this is the reason of error reported in the ticket

http://trac.osgeo.org/postgis/ticket/972

[aperi2007]

I commit a patch to resolve this in the ticket #971.

http://trac.osgeo.org/postgis/attachment/ticket/971/patch_topology.zip

[aperi2007]

Hi, I would report that the ST_GetFaceGeometry actually don't intercept the case of Universe face so calling the ST_GetFaceGeometry

topology.ST_GetFaceGeometry('topo_name', 0);

with the UniverseFace will raise an error in other part of code because it return a record with NULL value.

It should be add a check for tha case "aface=0" the give the right exception.

If Ok , I could produce a patch for this.

[strk]

The specs say that ST_GetFaceGeometry should use ST_GetFaceEdges to construct the face, and the description of ST_GetFaceEdges does not say anything special about the universal face.

I don't see NULL being returned, but a multipolygon, where each "hole" in the universal face is represented as a polygon. This is equivalent to the union of all faces.

If not backed up by specs, do we still want to throw an exception here ?

[strk]

r7224 "fixes" the current behavior in the existing regress test. Can still be changed if we really think we should behave differently.

[aperi2007]

The ISO specs for ST_GetFaceGeometry to the point: 2.e.i say:

If aface is equal to 0 (zero), then an exception condition is raised: SQL/MM >Spatial exception – universal face has no geometry.

[strk]

Great, in this case I'll proceed in that direction. Does it say anything similar for ST_GetFaceEdges ?

[aperi2007]

Replying to strk:

Great, in this case I'll proceed in that direction. Does it say anything similar for ST_GetFaceEdges ?

No, the ISO specs don't want to exception for ST_GetFaceEdge when calling with UniverseFace.

The explanation is in the ISO specs:

They say:

ST_GetFaceEdges: for the provided topology-name and face ID, returns a table containing the integer edge IDs for the edges which bound the face, in counterclockwise order. Edge IDs will be negated in the query result if the face is right of the edge when looking in the direction of the edge from start to end node.

ST_GetFaceEdge formerly don't return the geometry but instead it return the Edges delimiting the Face. Even the UniverseFace has some edges to delimiting it. They are simply the edges that has the LEFT_FACE = 0 OR RIGHT_FACE = 0.

So the calling:

select ST_GetFaceEdges('toponame', 0)

will return the result of something like

select edge_id from 'toponame'.edge_data where ( (LEFT_FACE=0) OR (RIGHT_FACE=0) )

I guess a bit more complex because it should be in counterclockwise order..

[strk]

Fixed in r7234

It might have broken ST_GetFaceEdges… regression test didn't notice.

[strk]

For the record, yes, it broek ST_GetFaceEdges for universe face, see ticket #984