GDAL WKT sometimes does not match BNF ordering of tags.

[warmerdam]

Frank,

I've upgraded to GDAL 1.1.8, with multiple instances (i.e. multiple folders,
each with their own nmake.opt-s), and it all seems to build OK, and link with my
client code OK.

However, and there is always a "however", I've got a problem with your WKT.  The
following came from a GeoTIFF file (actually a DOQ):

PROJCS["unnamed",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS
1980",6378137,298.2572221010002,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4269"]],AUTHORITY["EPSG","26918"],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-75],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["unknown",1]]

Our WKT parser chokes on the "AUTHORITY["EPSG","26918"]" node.  This is nothing
wrong with the node itself, but our parser is expecting it at the end, i.e. in
the order specified in the EBNF definition in the CTS specification:

<projected cs> = PROJCS["<name>", <geographic cs>, <projection>, {<parameter>,}*
<linear unit> {,<twin axes>}{,<authority>}]

I'm no EBNF expert, so I'm open to persuasion.

Regards,
Martin

[warmerdam]

I have added a FixupOrdering() method on the OGRSpatialReference class.  The
importFromEPSG() method and GTIFFGetOGISDefn() function have been explicitly
modified to use this to correct WKT ordering before returning.

Applications requiring "correct" WKT are encouraged to use the method to cleanup
what the various drivers return.  As problems are encountered I will correct
the drivers.