Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#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 Changed 7 years ago by Jukka Rahkonen

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

comment:2 Changed 7 years ago by bildsoe

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 Changed 7 years ago by Even Rouault

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 Changed 7 years ago by bildsoe

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 Changed 7 years ago by Jukka Rahkonen

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 Changed 7 years ago by Even Rouault

Component: defaultOGR_SF
Keywords: gml srsdimension added
Milestone: 2.0
Resolution: fixed
Status: newclosed

trunk r27581 "GML: add datasource option SRSDIMENSION_LOC=GEOMETRY to be able to write srsDimension attribute on top level geometry element, default on posList unchanged (#5066)"

comment:7 Changed 6 years ago by Even Rouault

Milestone: 2.02.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.