#5606 closed defect (fixed)
Position of srsDimension in GML structure
Reported by: | bildsoe | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 2.0.0 |
Component: | OGR_SF | Version: | 1.11.0 |
Severity: | normal | Keywords: | gml srsdimension |
Cc: |
Description
When trying to convert a GML to another format using ogr2ogr, the srsDimension must be set on posList instead of on the surface. Is this a bug? The following GML will not parse as 3-dimensional.
<gml:surfaceProperty>
<gml:Surface srsName="EPSG:25832" srsDimension="3">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
710820.22 6180637.52 36 710818.14 6180633.83 36 710825.47 6180629.71 36 710827.55 6180633.4 38.25 710828.6 6180637.3 38.25 710825.18 6180638.36 38.25 710824.22 6180635.27 36 710820.22 6180637.52 36
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</gml:surfaceProperty>
Change History (7)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
So this is in fact a bug? since it is not working when it is specified at the surface level?
"In my view we should discourage the practice of putting srsDimension on pos/posList; I think that if NTS does not accept srsDimension on geometries then it is broken." From the discussion you reference.
comment:3 by , 10 years ago
trunk r27576 "GML: parse correctly GML geometries whose srsDimension attribute is on top-level geometry element and not on posList (#5606)"
The GML generation side still generates srsDimension on posList. This should likely be fixed, probably through a configuration option, since there are other software in the wild, like PostGIS GML importer that only accept (and generate) srsDimension on posList
My recent work for 2.5D in MapServer has also lead to generating srsDimension on posList...
comment:4 by , 10 years ago
So you're supporting the notion of it being a bug? It parses it as 2D, when the srsDimension is on the top level. I think it is good if it can handle srsDimension at both toplevel or posList.
comment:5 by , 10 years ago
It is fixed now by r27576 and parsing behaves as you suggest. I guess that Even left the ticket open because GDAL still writes srsDimension on posList and he considers to change the behaviour.
comment:6 by , 10 years ago
Component: | default → OGR_SF |
---|---|
Keywords: | gml srsdimension added |
Milestone: | → 2.0 |
Resolution: | → fixed |
Status: | new → closed |
This discussion from geotools-dev list gives some background
http://osgeo-org.1560.x6.nabble.com/Adding-srsDimension-at-the-posList-level-too-td5087644.html
"Pages 58-59 of the GML 3.2.1 spec (OGC 07-036) note that it is expected that SRS attributes "will be specified at the direct position level only in rare cases". It seems to me that srsDimension goes hand-in-hand with srsName. Furthermore (p56): "The optional attribute srsDimension is the number of coordinate values in a position. This dimension is derived from the coordinate reference system. When the srsName attribute is omitted, this attribute shall be omitted." "