Opened 7 years ago

Closed 7 years ago

Last modified 7 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: trunk
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 Changed 7 years ago by aperi2007

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

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

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by strk

Status: newassigned

comment:4 Changed 7 years ago by 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 ?

comment:5 Changed 7 years ago by strk

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

comment:6 in reply to:  4 Changed 7 years ago by 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.

:)

comment:7 Changed 7 years ago by strk

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

comment:8 in reply to:  7 Changed 7 years ago by 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..

comment:9 Changed 7 years ago by strk

Resolution: fixed
Status: assignedclosed

Fixed in r7234

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

comment:10 Changed 7 years ago by strk

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

Note: See TracTickets for help on using tickets.