Norm,<div><br></div><div>That would be GREAT if you can post a test file! I'd love to run that thru Proj4J and see what breaks... 8^)</div><div><br></div><div>I know your reasons for liking CSV, and mostly I agree with them. For various reasons I often end up using a text editor to work with the files, and then they are quite difficult to read and get correct. </div>
<div><br></div><div>XML is the obvious other choice for format, and it seems like it might be easier to read in a text editor. It also provides some "tech cred". Anyway, there's no reason that we can't specify both formats - they should be easily interchangable.</div>
<div><br></div><div>Martin<br><br><div class="gmail_quote">On Tue, Aug 16, 2011 at 8:59 AM, Norm Olsen <span dir="ltr"><<a href="mailto:norm.olsen@autodesk.com">norm.olsen@autodesk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I have adopted the MetaCRS format for internal testing use, and hope to post a test file with some 195,000 test points in the next month or so. I really like
the CSV format. It’s easy to parse (CS-MAP includes a CSV file object written in C++) and you can use spreadsheet applications to examine, manipulate, and analyze the data fairly easily.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Norm<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> <a href="mailto:metacrs-bounces@lists.osgeo.org" target="_blank">metacrs-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:metacrs-bounces@lists.osgeo.org" target="_blank">metacrs-bounces@lists.osgeo.org</a>]
<b>On Behalf Of </b>Martin Davis<br>
<b>Sent:</b> Tuesday, August 16, 2011 9:33 AM<br>
<b>Cc:</b> <a href="mailto:metacrs@lists.osgeo.org" target="_blank">metacrs@lists.osgeo.org</a><br>
<b>Subject:</b> Re: [MetaCRS] Testing framework available to any GeoAPI implementation<u></u><u></u></span></p>
</div><div><div></div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Even better, why not provide these tests in the MetaCRS Test format? That way they are declarative, platform and API-independent, and hence more easily usable by all the various CRS projects.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">(I realize that this format hasnt got much traction beyond - ahem - Proj4J, and I have my reservations about CSV as a format, but nevertheless it has been presented and formalized and been proven in use).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Martin D2<u></u><u></u></p>
<div>
<p class="MsoNormal">On Mon, Aug 15, 2011 at 6:36 AM, Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.fr" target="_blank">martin.desruisseaux@geomatys.fr</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">On a related topic with my previous email, there is some news on the "testing" front (a while ago we talked on this mailing list about a shared database for test points).<br>
<br>
The GeoAPI project provides a "<tt><span style="font-size:10.0pt">geoapi-conformance</span></tt>" module which executes many JUnit tests on arbitrary implementations of the GeoAPI interfaces. I tried to make the test as implementation-independent as possible.
For example the current implementation uses only the points provided in the "Example" sections of EPSG guidance notice, or the example points provided by some authoritative sources like the French National Mapping Agency (IGN) - they are not points calculated
by a particular implementation.<br>
<br>
The tests are extensively documented, as you can see from here:<u></u><u></u></p>
<ul type="disc">
<li class="MsoNormal">
<a href="http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/referencing/MathTransformTest.html#testMercator1SP%28%29" target="_blank">http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/referencing/MathTransformTest.html#testMercator1SP%28%29</a><u></u><u></u></li>
</ul>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
The tests are also customizable. If your implementation does not support the calculation of projection derivatives, and if you need to relax the tolerance threshold value, just override the test method as below:<u></u><u></u></p>
<pre>@Override<u></u><u></u></pre>
<pre>public void testMercator1SP() throws FactoryException, TransformException {<u></u><u></u></pre>
<pre> isDerivativeSupported = false; // MathTransform.derivative(...) not supported by our implementation.<u></u><u></u></pre>
<pre> tolerance = 0.1; // Relax the tolerance threshold value from 1 cm to 10 cm.<u></u><u></u></pre>
<pre> super.testMercator1SP();<u></u><u></u></pre>
<pre>}<u></u><u></u></pre>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
By creating GeoAPI wrappers for Proj.4 (see my previous post), Proj.4 win a new tests suite for free :-) (or maybe to be more realist, I should said that the tests suite win a validation from a well etablished library).<br>
<br>
Regards,<br>
<span style="color:#888888"><br>
Martin</span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
MetaCRS mailing list<br>
<a href="mailto:MetaCRS@lists.osgeo.org" target="_blank">MetaCRS@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/metacrs" target="_blank">http://lists.osgeo.org/mailman/listinfo/metacrs</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</blockquote></div><br></div>