Opened 10 years ago
Closed 6 years ago
#2497 closed defect (fixed)
Incompatile PostGIS Topology export
Reported by: | strk | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.6.1 |
Component: | Vector | Version: | svn-trunk |
Keywords: | postgis, topology | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
I've tried exporting topology to PostGIS with v.out.postgis -l and the result was not correct.
First there was no record in TOPOSCHEMA.relation so that all the literal TopoGeometry values (written in the output feature layer) result empty.
Second all the calls to ST_GetFaceGeometry() return a null value, which I've yet to inspect/understand. All I noticed so far was that there were many negative face_id, which don't really have any special meaning in PostGIS/ISO (there's no difference between an area or an island, you only have faces, with roles being dependent on the upper abstraction level of the TopoGeometry).
Unfortunately, topology.ValidateTopology doesn't notice any of these problems (this would be a PostGIS bug).
Change History (6)
comment:1 by , 10 years ago
comment:2 by , 9 years ago
Milestone: | 7.0.0 → 7.0.5 |
---|
comment:3 by , 8 years ago
Keywords: | postgis topology added |
---|
comment:4 by , 8 years ago
Milestone: | 7.0.5 → 7.0.6 |
---|
comment:5 by , 7 years ago
Milestone: | 7.0.6 → 7.0.7 |
---|
comment:6 by , 6 years ago
Milestone: | 7.0.7 → 7.6.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Already fixed.
I've found that ST_GetFaceGeometry only returns a NULL value for faces with a negative id (which would make sense, assuming no edge would ever point to them as being on its right or left side.
Should these negative faces be put in a grass-specific table rather than polluting the ISO one ?