MetaCRS Tests in Proj4J (for GeoTrellis)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

MetaCRS Tests in Proj4J (for GeoTrellis)

DWinslow@radiantblue.com
Hello list,

Over the past several weeks I have been investigating some problems encountered with CRS transformations using Proj4J.  Because Proj4J has so much in common with proj.4 I've been using proj.4 as a reference to compare transform results against, and after resolving the first issue that I investigated I was considering generating a list of sample transformations using proj.4 and using that as a test case in the Proj4J test suite.  When I found that Proj4J already had some tests using this approach based on the MetaCRS format, I adopted it as well.  As these improvements are about to be included in a release of GeoTrellis I am posting here about my experience.

First off, some links:
MetaCRS test suite: https://github.com/geotrellis/geotrellis/blob/master/proj4/src/test/resources/proj4-epsg.csv
Test suite generator: https://github.com/geotrellis/geotrellis/blob/master/proj4/src/test/scala/geotrellis/proj4/GenerateTestCases.scala
Test suite executor:
https://github.com/geotrellis/geotrellis/blob/master/proj4/src/test/scala/geotrellis/proj4/MetaCRSTest.scala#L40

The test suite generator expects proj4's cs2cs to be on the PATH, and will execute one transformation for each EPSG code in proj4j's EPSG database.  Right now the transformation is from WGS84 to the tested coordinate system, and the input coordinate is always (1, -1).  I would like to extend it to choose coordinates based on the area over which the tested CRS is valid; I have started on customizing the test parameters per CRS by varying the tolerance based on the units.  For each conversion that does not generate an error from cs2cs, I also perform the conversion with proj4j, in order to flag each test case as "passing", "failing" (wrong results), or "error" (failed to produce a result because of an uncaught exception.)  Then I can manually edit the expectations per coordinate system to get error reports for just one failing CRS at a time, or regenerate the file if a change might affect many coordinate systems.  The expected results are stored in the "testMethod" field; otherwise I wasn't sure what it was intended for.  The existing proj4j MetaCRS test suites set the testMethod to "proj4j".

Anyway, I think that this approach to automatically generating test suites using MetaCRS may be a novel usage of the format and hope that it is of interest to the subscribers of this list.  If anyone is interested in developing it further (making some of the enhancements I mentioned earlier, perhaps doing some visualization of the results, or comparing results from other libraries like GeoTools Referencing or proj4js, or others I haven't considered) I'd love to hear about it.

--
David Winslow
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: MetaCRS Tests in Proj4J (for GeoTrellis)

Martin Desruisseaux-3
Hello David

Thank for the initiative. I'm a firm believer in the value of a
library-independent test suite.

One word of caution however: if I'm understanding right, this approach
takes Proj.4 as a reference implementation, is that right? I think we
should keep in mind that Proj.4 is not always right. In particular,
Proj.4 is (in my understanding) what EPSG calls an "early binding"
implementation, while EPSG rather recommends "late binding"
implementations. I can produce examples of coordinate transformations
where Proj.4 results are not in agreement with EPSG.

So my question is, why not using the GIGS tests
(http://www.iogp.org/Geomatics#2521115-gigs) instead than generating
values from a particular library?

    Regards,

        Martin


Le 11/03/16 19:24, [hidden email] a écrit :

> Hello list,
>
> Over the past several weeks I have been investigating some problems encountered with CRS transformations using Proj4J.  Because Proj4J has so much in common with proj.4 I've been using proj.4 as a reference to compare transform results against, and after resolving the first issue that I investigated I was considering generating a list of sample transformations using proj.4 and using that as a test case in the Proj4J test suite.  When I found that Proj4J already had some tests using this approach based on the MetaCRS format, I adopted it as well.  As these improvements are about to be included in a release of GeoTrellis I am posting here about my experience.
>
> First off, some links:
> MetaCRS test suite: https://github.com/geotrellis/geotrellis/blob/master/proj4/src/test/resources/proj4-epsg.csv
> Test suite generator: https://github.com/geotrellis/geotrellis/blob/master/proj4/src/test/scala/geotrellis/proj4/GenerateTestCases.scala
> Test suite executor:
> https://github.com/geotrellis/geotrellis/blob/master/proj4/src/test/scala/geotrellis/proj4/MetaCRSTest.scala#L40
>
> The test suite generator expects proj4's cs2cs to be on the PATH, and will execute one transformation for each EPSG code in proj4j's EPSG database.  Right now the transformation is from WGS84 to the tested coordinate system, and the input coordinate is always (1, -1).  I would like to extend it to choose coordinates based on the area over which the tested CRS is valid; I have started on customizing the test parameters per CRS by varying the tolerance based on the units.  For each conversion that does not generate an error from cs2cs, I also perform the conversion with proj4j, in order to flag each test case as "passing", "failing" (wrong results), or "error" (failed to produce a result because of an uncaught exception.)  Then I can manually edit the expectations per coordinate system to get error reports for just one failing CRS at a time, or regenerate the file if a change might affect many coordinate systems.  The expected results are stored in the "testMethod" field; otherwise I wasn't sure what it was intended for.  The existing proj4j MetaCRS test suites set the testMethod to "proj4j".
>
> Anyway, I think that this approach to automatically generating test suites using MetaCRS may be a novel usage of the format and hope that it is of interest to the subscribers of this list.  If anyone is interested in developing it further (making some of the enhancements I mentioned earlier, perhaps doing some visualization of the results, or comparing results from other libraries like GeoTools Referencing or proj4js, or others I haven't considered) I'd love to hear about it.
>
> --
> David Winslow


_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs