[GeoNetwork-devel] extract-gml, converting GML to JTS failure w/posLists

[Kim_Mortimer]

Hi all,

My colleague Ryan wrote a message about this same issue back in January and never got a response. I’ve circled back around to the issue now, after Ryan left, and am trying to finally come up with a solution.

This is on…

Firefox 68.0.2
GeoNetwork Version 3.4.4.0
Java Version: openjdk version "1.8.0_181"
Tomcat Version: 8.0.53

Here’s Ryan’s original message - https://sourceforge.net/p/geonetwork/mailman/message/36511449/

Here’s the type of error I see:

2019-09-06 19:44:19,109 ERROR [geonetwork.index] - Failed to convert gml to jts object: <gml:Polygon xmlns:gml="http://w

ww.opengis.net/gml/3.2">

gml:exterior

gml:LinearRing

gml:posList21.29475 -158.020516667 21.29475 -157.243516667 20.9242333333 -157.243516667 20.9242333333 -158.02051

6667 21.29475 -158.020516667</gml:posList>

</gml:LinearRing>

</gml:exterior>

</gml:Polygon>

Parsing failed for Polygon: java.lang.ClassCastException: java.lang.String cannot be cast to com.vividsolutions.

jts.geom.LinearRing

In this example above, the coordinate order is Latitude - Longitude, which is the same ordering shown in the GeoRSS/GML example here http://www.georss.org/gml.html#gmlboundary

However, I get the same error even if the ordering is Longitude-latitude, as shown below

<gml:Polygon xmlns:gml=“http://www.opengis.net/gml/3.2”>
gml:exterior
gml:LinearRing
gml:posList-158.020516667 21.29475 -157.243516667 21.29475 -157.243516667 20.9242333333 -158.020516667 20.9242333333 -158.020
516667 21.29475</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>

Both examples are in clockwise coordinates from the north-west corner and are closed.

From everything I’ve read about GML and GeoTools, the formatting is correct (even if the ordering of the axes remains ambiguous, in this case, one ordering should be valid and the other should not, due to the coordinate between less than -90 in longitude), as is the XML surrounding it. So I am really puzzled why I am seeing an error for both cases.

I currently have three best guesses:

1. This is due to me using gml/3.2 within my plugin (Seems possible, but I haven’t seen any evidence to suggest this structure has changed between 3.1 and 3.2)

2. Something in the underlying GeoNetwork code is pulling it out as a string instead of a complete object. (Seems like it should impact everyone on GeoNetwork, not just me)

3. GeoTools may be running on an older version which does not expect gml:posList, but instead only accepts gml:coordinates (deprecated and replaced by posList in later revisions of GML), which is still used in extract-gml.xsl for the core iso19139 plugin (We initially tried the original code from here https://github.com/geonetwork/core-geonetwork/blob/3.4.x/schemas/iso19139/src/main/plugin/iso19139/extract-gml.xsl but it was outputting an invalid list of coordinates)
   Any insight from others on which of these three directions to go is the correct solution would be helpful.

Kim

···

Kim Mortimer

Data Manager

MERIDIAN - Marine Environmental Research Infrastructure for Data Integration and Application Network

Institute for Big Data Analytics, Faculty of Computer Sciences, Dalhousie University

p: + 1 902 494 1812 m: +1 902 880 1863

a: 6050 University Ave, Halifax, NS, B3H 4R2, Canada

w: https://meridian.cs.dal.ca e: k.mortimer@anonymised.com

[Kim_Mortimer]

Hi all,

Apologies for the double email. After taking a break from GeoNetwork to do some hurricane preparation, I remembered the cause of, and therefore solution to, this problem.

It’s all to do with the URI declaration of theGML namespace in extract-gml - and while I’m not entirely sure why, changing it back stops GeoTools from complaining when trying to handle the original coordinate list. I haven’t done further tests with a posList - more just happy to know that I was able to resolve those errors.

Initially I caused the error because with us changing our plugin to GML 3.2, I wanted to update every reference to GML. This time, I had just done some troubleshooting of harvesting (failures due to conflicting template names) and one step along that process was to try changing the GML version declared (this was unrelated to the issue) in those few files. I then, perhaps foolishly, expanded my search just to enure I had been consistent.

So, for anyone finding this message in the future, looking for a fix - ensure the xmlns:gml in extract-gml of your plugin has a URI identical to the ones used in the core GeoNetwork schemas.

Kim

···

---

From: Kim Mortimer
Sent: 06 September 2019 17:03
To: geonetwork-devel@lists.sourceforge.net geonetwork-devel@anonymised.coms.sourceforge.net
Subject: Re: extract-gml, converting GML to JTS failure w/posLists

Hi all,

My colleague Ryan wrote a message about this same issue back in January and never got a response. I’ve circled back around to the issue now, after Ryan left, and am trying to finally come up with a solution.

This is on…

Firefox 68.0.2
GeoNetwork Version 3.4.4.0
Java Version: openjdk version "1.8.0_181"
Tomcat Version: 8.0.53

Here’s Ryan’s original message - https://sourceforge.net/p/geonetwork/mailman/message/36511449/

Here’s the type of error I see:

2019-09-06 19:44:19,109 ERROR [geonetwork.index] - Failed to convert gml to jts object: <gml:Polygon xmlns:gml="http://w

ww.opengis.net/gml/3.2">

gml:exterior

gml:LinearRing

gml:posList21.29475 -158.020516667 21.29475 -157.243516667 20.9242333333 -157.243516667 20.9242333333 -158.02051

6667 21.29475 -158.020516667</gml:posList>

</gml:LinearRing>

</gml:exterior>

</gml:Polygon>

Parsing failed for Polygon: java.lang.ClassCastException: java.lang.String cannot be cast to com.vividsolutions.

jts.geom.LinearRing

In this example above, the coordinate order is Latitude - Longitude, which is the same ordering shown in the GeoRSS/GML example here http://www.georss.org/gml.html#gmlboundary

However, I get the same error even if the ordering is Longitude-latitude, as shown below

<gml:Polygon xmlns:gml=“http://www.opengis.net/gml/3.2”>
gml:exterior
gml:LinearRing
gml:posList-158.020516667 21.29475 -157.243516667 21.29475 -157.243516667 20.9242333333 -158.020516667 20.9242333333 -158.020
516667 21.29475</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>

Both examples are in clockwise coordinates from the north-west corner and are closed.

From everything I’ve read about GML and GeoTools, the formatting is correct (even if the ordering of the axes remains ambiguous, in this case, one ordering should be valid and the other should not, due to the coordinate between less than -90 in longitude), as is the XML surrounding it. So I am really puzzled why I am seeing an error for both cases.

I currently have three best guesses:

1. This is due to me using gml/3.2 within my plugin (Seems possible, but I haven’t seen any evidence to suggest this structure has changed between 3.1 and 3.2)

2. Something in the underlying GeoNetwork code is pulling it out as a string instead of a complete object. (Seems like it should impact everyone on GeoNetwork, not just me)

3. GeoTools may be running on an older version which does not expect gml:posList, but instead only accepts gml:coordinates (deprecated and replaced by posList in later revisions of GML), which is still used in extract-gml.xsl for the core iso19139 plugin (We initially tried the original code from here https://github.com/geonetwork/core-geonetwork/blob/3.4.x/schemas/iso19139/src/main/plugin/iso19139/extract-gml.xsl but it was outputting an invalid list of coordinates)
   Any insight from others on which of these three directions to go is the correct solution would be helpful.

Kim

Kim Mortimer

Data Manager

MERIDIAN - Marine Environmental Research Infrastructure for Data Integration and Application Network

Institute for Big Data Analytics, Faculty of Computer Sciences, Dalhousie University

p: + 1 902 494 1812 m: +1 902 880 1863

a: 6050 University Ave, Halifax, NS, B3H 4R2, Canada

w: https://meridian.cs.dal.ca e: k.mortimer@anonymised.com