Question

GML posList mixed up?


Badge +10

Hi, I'm struggling reading geometry from an xml file. When looking at a part of the (0.7Gb) large xml, I can see it has coordinates that reference a location I do not expect:

<gml:LineString srsName="urn:ogc:def:crs:EPSG::4258" gml:id="GEOMETRY_98ce8c1e-3676-4a60-b2a8-d7e63fe97d1d">
<gml:posList srsDimension="3">51.77106873325691 5.459700336196274 49.41166353587596 3.2520665388839736 47.937498062913775 8.934025947231504 51.771400476701494 5.460105669526139 49.412014702926356 3.25205099130662 47.937476504785614 8.934700858000644 51.77170841095756 5.460502642204418 49.412240574188026 3.252040990938717 47.93746470527796 8.935070205423436 51.771910436397455 5.46090045825306 49.41302764854071 3.2520061426583493 47.9374374566226 8.935922993715176 51.77277383456701 5.462819713112839 
.
.
.
</gml:posList>
</gml:LineString>

The 3D coordinates seem to alternate, which might have something to do with a side view from the data, I guess. When I look at the data in the viewer, it looks like: KnipselNot all of the features in the xml file show this behavior. I tried a number of approaches to get rid of the outliers, yet none had satisfying results. I did a bit of Python scripting to remove each second coordinate, or remove out-of-range coordinates, experimented with XMLXQueryExtractor, used textfile reader or GML reader or XML reader, I'm a bit disappointed now. Anyone has any idea how to tackle this? Accompanying is an .fmwt file containing a simple workspace and data-extract to reproduce the problem. Any input would be greatly appreciated. 

 

O, forgot to tell, using FME(R) 2022.0.1.0 (20220602 - Build 22346 - WIN64). 


8 replies

Badge +20

The answer is simple:

srsDimension="2" not 3.

2D geometryBy splitting and joining the coordinates list I get the geometry in the image above.

Badge +11

Hi @Helmoet de Zwijger​ your data is probably not 3D, but more like 2D, so try to use X and Y and Z=0 for build

image

Badge +10

Hi @Helmoet de Zwijger​ your data is probably not 3D, but more like 2D, so try to use X and Y and Z=0 for build

image

Hi @muzhnasto​, thanks for your answer. I tried to replace all occurrences of srsDimension="3" into srsDimension="2" in a testing file, see picture below. However, I know the data is pure Dutch data, so I do not expect points near Zürich (Switzerland). The point (lat, lon) = (49.412, 3.252), the point next to your Z=0 remark above is also not within the Netherlands. I'm still hoping there is a way through XQuery to remove every second point in the posList, since I suspect these points to be some kind of profile or measuring data. You know something for that? Knipsel2

Badge +10

The answer is simple:

srsDimension="2" not 3.

2D geometryBy splitting and joining the coordinates list I get the geometry in the image above.

Hi @caracadrian​ thanks, I elaborated below on the 2D/3D issue.

Userlevel 1
Badge +21

Hi @muzhnasto​, thanks for your answer. I tried to replace all occurrences of srsDimension="3" into srsDimension="2" in a testing file, see picture below. However, I know the data is pure Dutch data, so I do not expect points near Zürich (Switzerland). The point (lat, lon) = (49.412, 3.252), the point next to your Z=0 remark above is also not within the Netherlands. I'm still hoping there is a way through XQuery to remove every second point in the posList, since I suspect these points to be some kind of profile or measuring data. You know something for that? Knipsel2

It looks like there's something fundamentally wrong with the data to me. But if for example you keep the first coordinate pair then skip two coordinate pairs you can build something that looks vaguely correct. This is the result for one of the embankments if you do that

imageI can share the python that will get you to this, but personally I wouldn't trust data that required this sort of manipulationimage 

Badge +10

Hi @muzhnasto​, thanks for your answer. I tried to replace all occurrences of srsDimension="3" into srsDimension="2" in a testing file, see picture below. However, I know the data is pure Dutch data, so I do not expect points near Zürich (Switzerland). The point (lat, lon) = (49.412, 3.252), the point next to your Z=0 remark above is also not within the Netherlands. I'm still hoping there is a way through XQuery to remove every second point in the posList, since I suspect these points to be some kind of profile or measuring data. You know something for that? Knipsel2

Thanks, this is what I thought too. I will try to contact the data source.​

Badge +20

Hi @muzhnasto​, thanks for your answer. I tried to replace all occurrences of srsDimension="3" into srsDimension="2" in a testing file, see picture below. However, I know the data is pure Dutch data, so I do not expect points near Zürich (Switzerland). The point (lat, lon) = (49.412, 3.252), the point next to your Z=0 remark above is also not within the Netherlands. I'm still hoping there is a way through XQuery to remove every second point in the posList, since I suspect these points to be some kind of profile or measuring data. You know something for that? Knipsel2

I apologize, I didn't mean you should try to replace the srs definition. EPSG 4258 is a 3D reference system after all.

ebygomm explained it best, something is wrong whith the data. It looks like it was parsed manually by someone.

Badge +10

Hi @muzhnasto​, thanks for your answer. I tried to replace all occurrences of srsDimension="3" into srsDimension="2" in a testing file, see picture below. However, I know the data is pure Dutch data, so I do not expect points near Zürich (Switzerland). The point (lat, lon) = (49.412, 3.252), the point next to your Z=0 remark above is also not within the Netherlands. I'm still hoping there is a way through XQuery to remove every second point in the posList, since I suspect these points to be some kind of profile or measuring data. You know something for that? Knipsel2

No worries , 😊​

Reply