[MetaCRS] Standard (and simple) format for conversion tests.

[Frank Warmerdam]

Landon Blake wrote:
> I will be helping Martin Davis on some testing and improvements to 
> Proj4J. One of my tasks will be to test some of the improvements we are 
> making to the coordinate conversion calculations. I think this testing 
> is currently being done with Java unit tests. A while back on this list 
> I remember we discussed a simple format for test data that could be 
> provided to software tests. I think the goal would be to assemble a 
> standard library of test data files that could be used by different 
> coordinate conversion projects.
> 
>  
> 
> Is there still an interest in this?

Landon,

I am interested in such a thing existing.  In my Python script for
testing PROJ.4 (through OGRCoordinateTransformation) I have:

###############################################################################
# Table of transformations, inputs and expected results (with a threshold)
#
# Each entry in the list should have a tuple with:
#
# - src_srs: any form that SetFromUserInput() will take.
# - (src_x, src_y, src_z): location in src_srs.
# - src_error: threshold for error when srs_x/y is transformed into dst_srs and
#              then back into srs_src.
# - dst_srs: destination srs.
# - (dst_x,dst_y,dst_z): point that src_x/y should transform to.
# - dst_error: acceptable error threshold for comparing to dst_x/y.
# - unit_name: the display name for this unit test.
# - options: eventually we will allow a list of special options here (like one
#   way transformation).  For now just put None.
# - min_proj_version: string with minimum proj version required or null if unknown

transform_list = [ \

     # Simple straight forward reprojection.
     ('+proj=utm +zone=11 +datum=WGS84', (398285.45, 2654587.59, 0.0), 0.02,
      'WGS84', (-118.0, 24.0, 0.0), 0.00001,
      'UTM_WGS84', None, None ),

     # Ensure that prime meridian changes are applied.
     ('EPSG:27391', (20000, 40000, 0.0), 0.02,
      'EPSG:4273', (6.397933,58.358709,0.000000), 0.00001,
      'NGO_Oslo_zone1_NGO', None, None ),

     # Verify that 26592 "pcs.override" is working well.
     ('EPSG:26591', (1550000, 10000, 0.0), 0.02,
      'EPSG:4265', (9.449316,0.090469,0.00), 0.00001,
      'MMRome1_MMGreenwich', None, None ),
...

I think one important thing is to provide an acceptable error threshold with
each test in addition to the expected output value.  I also think each test
should support a chunk of arbitrary test which could be used to explain
the purpose of the test (special issues being examined) and pointing off
to a ticket or other relavent document.

Actually one more thing is a name for the test, hopefully slightly
self-documenting.  I suppose if each test is a distinct file, we
could use meaningful filenames.

The other dilemma is how to define the coordinate systems.  I feel that
limiting things to EPSG defined coordinate systems is a problem though of
course otherwise we have serious problems with defining in the coordinate
system in an interoperable fashion.   So, perhaps starting with EPSG codes
is reasonable with an understanding that eventually some tests might need
to be done another way - perhaps OGC WKT.

If you wanted to roll out something preliminary I would be interested
writing a Python script that would run the test against OGR/PROJ.4.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent