Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#973 closed defect (fixed)

ST_GetFaceGeometry - don't intercept the UniverseFace

Reported by: aperi2007 Owned by: strk
Priority: medium Milestone: PostGIS 2.0.0
Component: topology Version: master
Keywords: Cc:

Description

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

Change History (10)

comment:1 by aperi2007, 13 years ago

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

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

comment:2 by aperi2007, 13 years ago

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.

comment:3 by strk, 13 years ago

Status: newassigned

comment:4 by strk, 13 years ago

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 ?

comment:5 by strk, 13 years ago

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

in reply to:  4 comment:6 by aperi2007, 13 years ago

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.

:)

comment:7 by strk, 13 years ago

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

in reply to:  7 comment:8 by aperi2007, 13 years ago

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..

comment:9 by strk, 13 years ago

Resolution: fixed
Status: assignedclosed

Fixed in r7234

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

comment:10 by strk, 13 years ago

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

Note: See TracTickets for help on using tickets.