Use of PROJ string or WKT string is prone to definition ambiguities

[jfbourgon]

We recently faced an issue using PROJ4J as our PROJ String wasn't recognized properly by the PROJ4J parser.

Here is a Scala snippet illustrating the issue

scala> import geotrellis.proj4._
import geotrellis.proj4._

scala> CRS.fromString("+proj=lcc +lat_1=49 +lat_2=77 +lat_0=49 +lon_0=-95 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs")
res1: geotrellis.proj4.CRS = lcc-CS
scala> res1.epsgCode
res2: Option[Int] = Some(3978)

scala> CRS.fromString("+proj=lcc +lat_0=49 +lon_0=-95 +lat_1=49 +lat_2=77 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs")
res3: geotrellis.proj4.CRS = lcc-CS
scala> res3.epsgCode
res4: Option[Int] = None

Above PROJ definitions are corresponding to string representation that are returned respectively from GDAL2 (PROJ4) and GDAL3 (PROJ6/7) utility tools. PROJ4J will only recognized the first one because the current PROJ4J parser seems to perform strict exact string matching in projection lookup and switching parameters ordering is affecting this parsing.

We would recommend avoiding the use of PROJ string or WKT string as it could be prone to definition ambiguities as illustrated above and as also reported in #65.

The expected behavior would be that both representations should resolve as EPSG code 3978 without the need to explicitly maintain various representation of the projection definition.

PROJ6/7 also introduced a new approach for projection definition management (proj.db) that can potentially be leveraged here.