Incorrect valid area of CRS http://www.opengis.net/def/crs/EPSG/0/25832

[lgoltz]

opengeospatial/teamengine#309 (comment)

[lgoltz]

As http://www.epsg-registry.org/ is the official registry from the EPSG I assume it describes the area of use correctly. Furthermore the textual area (Europe - 6°E to 12°E and ETRS89 by country) does not match the Bounds on http://spatialreference.org/ref/epsg/25832/.
Correct area of use from http://www.epsg-registry.org/:

• South Bound Latitude | 0
• West Bound Longitude | 6
• North Bound Latitude | 84
• East Bound Longitude | 12

The test data are inside this area.

The domain of validity is requested from the CRS using geotoolkit org.geotoolkit.geometry.Envelopes#getDomainOfValidity:

ets-gml32/src/main/java/org/opengis/cite/iso19136/data/spatial/GeometryAssert.java

Line 117 in 58c335c

Envelope crsDomain = Envelopes.getDomainOfValidity(gmlGeom.getCoordinateReferenceSystem());

[lgoltz]

As far as I see it is not possible to configure the domain of validity with an improved WKT configuration or within Geotoolkit.
@keshav-nangare Can you recheck this? Solves an update to a newer version of geotoolkit the test failure. Otherwise a workaround for this CRS in GeometryAssert could solve this.

[keshavnangare]

@lgoltz

As the geotoolkit dependency is part of the geomatic-geotk dependency not the ets-gml32, I think this issue is similar to #32 with geotoolkit, maybe we need to wait for new release.

[lgoltz]

As the geotoolkit dependency is part of the geomatic-geotk dependency not the ets-gml32, I think this issue is similar to #32 with geotoolkit, maybe we need to wait for new release.

Do you know if this issue will be fixed in a new release? Otherwise we should ask or create a bug for it.

[keshavnangare]

@lgoltz

The domain of validity is requested from the CRS using geotoolkit org.geotoolkit.geometry.Envelopes#getDomainOfValidity:

ets-gml32/src/main/java/org/opengis/cite/iso19136/data/spatial/GeometryAssert.java

Line 117 in 58c335c

Envelope crsDomain = Envelopes.getDomainOfValidity(gmlGeom.getCoordinateReferenceSystem());

I am not sure about it, but while debugging I am able see that the above method (org.geotoolkit.geometry.Envelopes#getDomainOfValidity) is loading from the geotk-referencing-3.21 jar not geotoolkit. I think the issue is not related to geotoolkit. I have tried to search this jar in pom dependency but not able to find it. Or we can create bug for it.

[ghobona]

@keshav-nangare Please confirm whether this issue is solved.

[keshavnangare]

@dstenger @ghobona

Here are my findings:

1. A polygon with which we are trying to validate has the same projected bounds as mentioned on http://spatialreference.org/ref/epsg/25832/.
2. The provided example file coordinates are reduced to a smaller polygon using the computeConvexHull method.
   

   ets-gml32/src/main/java/org/opengis/cite/iso19136/data/spatial/GeometryAssert.java

   Lines 111 to 126 in ee05a58

   	public static void assertGeometryCoveredByValidArea(AbstractGeometryType gmlGeom) {
   	String srsName = gmlGeom.getSrsName();
   	Assert.assertNotNull(srsName, String.format("CRS reference not found for %s with id = %s.",
   	gmlGeom.getClass().getSimpleName(), gmlGeom.getId()));
   	// Geotk v3 does not recognize 'http' CRS identifiers
   	gmlGeom.setSrsName(GeodesyUtils.convertSRSNameToURN(srsName));
   	Envelope crsDomain = Envelopes.getDomainOfValidity(gmlGeom.getCoordinateReferenceSystem());
   	Polygon validArea = Extents.envelopeAsPolygon(crsDomain);
   	Geometry geom = GmlUtils.computeConvexHull(gmlGeom);
   	if (geom.getClass().equals(GeometryCollection.class)) {
   	return; // ignore unsupported geometry
   	}
   	Assert.assertTrue(validArea.covers(geom),
   	String.format("%s[@gml:id='%s'] is not covered by valid area of CRS: %s", gmlGeom.getClass().getName(),
   	gmlGeom.getId(), crsDomain.toString()));
   	}

Coordinates of the polygon used to validate:

POLYGON ((
265948.819050026 6417576.9372099,
677786.3628639532 6417576.9372099, 
677786.3628639532 7288831.70135825, 
265948.819050026 7288831.70135825, 
265948.819050026 6417576.9372099))

Coordinates of the polygon to be validated:

POLYGON ((
645686.612258753 6120255.80963253, 
645672.206768768 6120258.40910341, 
643215.95116155 6120748.31938359, 
642720.557327932 6121688.38803534, 
642712.756759229 6121705.31458999, 
642722.041579906 6121721.50129523, 
642758.446982473 6121769.17159208, 
643120.274630183 6121979.04887217, 
646985.918190325 6122911.86899933, 
647261.01604773 6120826.88339212, 
647258.938094967 6120786.62158729, 
647054.977136305 6120713.65643914, 
645686.612258753 6120255.80963253))

Can you help me to understand the polygon structure here?

[ghobona]

GML file of the coordinates are attached.

<?xml version="1.0" encoding="utf-8" ?>
<ogr:FeatureCollection
     gml:id="aFeatureCollection"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://ogr.maptools.org/ citetest3.xsd"
     xmlns:ogr="http://ogr.maptools.org/"
     xmlns:gml="http://www.opengis.net/gml/3.2">
  <gml:boundedBy><gml:Envelope srsName="urn:ogc:def:crs:EPSG::25832"><gml:lowerCorner>-508747.513660968 17555.291396234</gml:lowerCorner><gml:upperCorner>-313217.340878817 209155.209449095</gml:upperCorner></gml:Envelope></gml:boundedBy>
  <ogr:featureMember>
    <ogr:citetest3 gml:id="citetest3.0">
      <gml:boundedBy><gml:Envelope srsName="urn:ogc:def:crs:EPSG::25832"><gml:lowerCorner>-508747.513660968 105986.022805247</gml:lowerCorner><gml:upperCorner>-377083.980229771 209155.209449095</gml:upperCorner></gml:Envelope></gml:boundedBy>
      <ogr:geometryProperty><gml:MultiSurface srsName="urn:ogc:def:crs:EPSG::25832" gml:id="citetest3.geom.0"><gml:surfaceMember><gml:Polygon gml:id="citetest3.geom.0.0"><gml:exterior><gml:LinearRing><gml:posList>265948.819050026 6417576.9372099 677786.3628639532 6417576.9372099 677786.3628639532 7288831.70135825 265948.819050026 7288831.70135825 265948.819050026 6417576.9372099</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon></gml:surfaceMember></gml:MultiSurface></ogr:geometryProperty>
      <ogr:fid>citetest2.0</ogr:fid>
      <ogr:id>0</ogr:id>
    </ogr:citetest3>
  </ogr:featureMember>
  <ogr:featureMember>
    <ogr:citetest3 gml:id="citetest3.1">
      <gml:boundedBy><gml:Envelope srsName="urn:ogc:def:crs:EPSG::25832"><gml:lowerCorner>-472065.1361876 17555.291396234</gml:lowerCorner><gml:upperCorner>-313217.340878817 103038.33175828</gml:upperCorner></gml:Envelope></gml:boundedBy>
      <ogr:geometryProperty><gml:MultiSurface srsName="urn:ogc:def:crs:EPSG::25832" gml:id="citetest3.geom.1"><gml:surfaceMember><gml:Polygon gml:id="citetest3.geom.1.0"><gml:exterior><gml:LinearRing><gml:posList>645686.612258753 6120255.80963253 645672.206768768 6120258.40910341 643215.95116155 6120748.31938359 642720.557327932 6121688.38803534 642712.756759229 6121705.31458999 642722.041579906 6121721.50129523 642758.446982473 6121769.17159208 643120.274630183 6121979.04887217 646985.918190325 6122911.86899933 647261.01604773 6120826.88339212 647258.938094967 6120786.62158729 647054.977136305 6120713.65643914 645686.612258753 6120255.80963253</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon></gml:surfaceMember></gml:MultiSurface></ogr:geometryProperty>
      <ogr:fid>citetest2.1</ogr:fid>
      <ogr:id>1</ogr:id>
    </ogr:citetest3>
  </ogr:featureMember>
</ogr:FeatureCollection>

[ghobona]

@keshav-nangare Since the problem appears to be with the copy of the EPSG database that Geotk uses, I suggest looking into whether the database can be updated.

Could you please look into it?

[keshavnangare]

@dstenger @ghobona

I have verified with apache-sis lib and retrieved the CRS info and got the different bounding BOX as compared to Geotoolkit.

Following are the valid area polygon values(Retrieved from apache-sis):

239323.4449753131 4290144.074116954 
760676.555024687 4290144.074116954 
760676.555024687 9320086.206906216
239323.4449753131 9320086.206906216
239323.4449753131 4290144.074116954 

We can see the below screenshot with the highlighted portion, the polygon from the input file lies inside the valid area.

From the above analysis, we can say that the value of CRS can be different based on the EPSG database used in the test. Currently, the test suite using the geotoolkit database to retrieve the CRS details.

[keshavnangare]

@ghobona

Sure, I will look into it whether we can update the database or not.

Thank You!

[dstenger]

Conclusion: Replacing Geotoolkit dependency with apache-sis would solve the problem. However, updating the dependency is very complex.

[dstenger]

2021-01-18 meeting:

@keshav-nangare Can you please check if only one test is failing or if multiple tests are failing because of this problem (test data are available here: opengeospatial/teamengine#309)? Can you please create a list of the failing tests?
If the failure is an isolated test, we propose to just update this test to use apache-sis for determination of the valid area.

[keshavnangare]

I executed the test suite with provided file, the result shows the validSurfaceBoundary test is getting failed.

[keshavnangare]

As per the above comment, I tried to fix the test by adding the apache-sis dependency and implemented a new class providing method similar to the geotoolkit class reference. I am trying to build the test suite but many of the JUnit tests are getting failed with an exception: java.lang.NoClassDefFoundError: Could not initialize class org.apache.sis.measure.Units

[dstenger]

@keshav-nangare Can you please push your changes to a new branch? Then we can check it together.

[keshavnangare]

@dstenger I have pushed changes to issue#34 branch. Please check it.

[dstenger]

Indeed, there seems to be an incompatibility between apache-sis and geotoolkit as both libraries implement the same interfaces.

[ghobona]

@keshav-nangare

Some observations.

Item 1

The issue#34 branch still uses several geotoolkit classes. For example the CurveTests class.

To replace geotoolkit with apache-sis, you would have to replace all of the geotoolkit uses.

Item 2

The Units class is in the sis-utility library. It needs to be added to the pom file as a dependency.

[dstenger]

Discussion 2021-05-10:

• We decided to stick with geotoolkit for issue and do the apache sis migration later.
• Test the extend for this particular CRS programmatically (extent might be stored in CSV file) without using geotoolkit (as proposed in Incorrect valid area of CRS http://www.opengis.net/def/crs/EPSG/0/25832 #34 (comment)).