#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
Change History (10)
comment:1 by , 13 years ago
comment:2 by , 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 , 13 years ago
Status: | new → assigned |
---|
follow-up: 6 comment:4 by , 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 , 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.
comment:6 by , 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.
:)
follow-up: 8 comment:7 by , 13 years ago
Great, in this case I'll proceed in that direction. Does it say anything similar for ST_GetFaceEdges ?
comment:8 by , 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 , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed in r7234
It might have broken ST_GetFaceEdges... regression test didn't notice.
comment:10 by , 13 years ago
For the record, yes, it broek ST_GetFaceEdges for universe face, see ticket #984
I commit a patch to resolve this in the ticket #971.
http://trac.osgeo.org/postgis/attachment/ticket/971/patch_topology.zip