CRS.fromWKT doesn't handle WKT with no EPSG record.

[metasim]

Input

This WKT is from calling org.opengis.referencing.crs.CoordinateReferenceSystem#toWKT on data read from a random shapefile via GeoTools.

CRS.fromWKT("""|GEOGCS["GCS_WGS_1984",
               |DATUM["D_WGS_1984",
               |SPHEROID["WGS_1984", 6378137.0, 298.257223563]],
               |PRIMEM["Greenwich", 0.0],
               |UNIT["degree", 0.017453292519943295],
               |AXIS["Longitude", EAST],
               |AXIS["Latitude", NORTH]]
               |""".stripMargin.replaceAll("\n",""))

Output

None.get
java.util.NoSuchElementException: None.get
	at scala.None$.get(Option.scala:347)
	at scala.None$.get(Option.scala:345)
	at geotrellis.proj4.io.wkt.WKT$.getEpsgCode(WKT.scala:70)
	at geotrellis.proj4.CRS$.fromWKT(CRS.scala:87)

Related: #2870

[metasim]

I also think it would be beneficial for CRS.fromWKT to automatically call the .replaceAll("\n","").

[CloudNiner]

I'm under the impression from the way the issue here is written that you'd expect the WKT string you provided to be successfully parsed by the CRS.fromWKT method. Is that true? If so, #3074 updates the CRS.fromWKT to return an Option[CRS] rather than crash outright.

As far as I can tell, with existing code, we're only able to parse WKT strings that we can retrieve an EPSG code from or have already parsed parameters for. Unless I'm missing the correct call using some other method, this issue will require a bit more effort to resolve since this WKT string is missing an authority.

[metasim]

@CloudNiner You're correct; I filed this bug before I understood that it only worked for embedded EPSG codes. However, I do think that it will also throw (or swallow?) an exception in the case where it does have an embedded EPSG code, but also has newlines.

[CloudNiner]

Sounds good. For now I'll just check for and address the newline issue if that's still a problem.

[CloudNiner]

Updated #3074 -- WKTParser now automatically strips newlines before attempting to parse. There was an old test that demos how newlines can be stripped manually, updated that to just compare a multiline vs single line string: 24c17c0

[metasim]

Should this be closed then? The "convert all the things" version is probably more of a Proj4j issue anyway...

locationtech/proj4j#49

[CloudNiner]

Certainly looks like it. Will close with the merging of #3074.