Support import of common TIGER projection without warning (add Polyconic spherical)

[anonymous]

What steps will reproduce the problem?

1. Go get a TIGER line file, at ​https://www.census.gov/cgi-bin/geo/shapefiles/index.php .
2. Using the OpenData plugin, open the .shp file contained in the .zip file.
3. Receive the error in the attachment, 'Unable to find a strict mathematical translation'.

What is the expected result?

IMO, JOSM should be able to find the translation for this set, given all TIGER lines seem to come in this projection. The .prj file elements (what's there, and what isn't) suggest that this is ESRI 4269, see ​https://gis.stackexchange.com/a/27713 and ​https://epsg.io/4269 .

What happens instead?

JOSM doesn't see

GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

as a meaningful projection.

The OGC WKT on ​https://epsg.io/4269 indicates:

GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]]

Same core elements, slightly different fields, but with the key addition of the EPSG authorities. Can JOSM translate one to the other to accept that this is 4269, if it's agreed this is correct?

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-06-30 01:04:46 +0200 (Sat, 30 Jun 2018)
Revision:13985
Build-Date:2018-06-30 01:32:07
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (13985 en) Mac OS X 10.13.5
OS Build number: Mac OS X 10.13.5 (17F77)
Memory Usage: 5044 MB / 5120 MB (4424 MB allocated, but free)
Java version: 10.0.1+10, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 69680128 1440x900
Maximum Screen Size: 1440x900
Dataset consistency test: No problems found

Plugins:
+ ImportImagePlugin (34219)
+ apache-commons (34109)
+ ejml (34126)
+ geotools (34125)
+ jts (34038)
+ log4j (34038)
+ opendata (34335)
+ pbf (34296)
+ utilsplugin2 (34286)
+ wikipedia (v1.0.1)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[Don-vip]

The problem is not understanding that GCS_North_American_1983 is equal to EPSG:4269, the plugin is already doing that. The problem occurs when searching for a mathematical transformation between this projection and WGS84:

2018-07-01 18:55:43.600 INFO: GCS_North_American_1983: Bursa wolf parameters required.
2018-07-01 18:57:10.469 WARNING: Polyconic spherical case not implemented, falling back on the elliptical equations

This is a limitation of the underlying projection library (​Geotools).

[elliottplack]

I did a bit of analysis and it appears that that assumed EPSG:4269 to JOSM default reprojection slightly off. Therefore, I think the warning is warranted until the underlying projection library supports it.

I manually reprojected some data in Maryland, USA (39 N) in ArcGIS Pro and compared it to how JOSM renders EPSG:4269 on the fly. The EPSG:4269 is slightly is not quite in the correct place.

[Don-vip]

I have updated GeoTools to latest version (22.0) but the problem is still here. I have created ​https://osgeo-org.atlassian.net/browse/GEOT-6386

[historic_bruno]

Hi, I encountered this same problem with the ​USGS NHD dataset, and decided to examine Geotools myself. The fix is rather simple, I haven't submitted it yet, as I'm still processing their contribution guidelines, but at least it works (tested separately and integrated into opendata/josm) -- as far as the polyconic spherical projection is concerned.

However even after implementing that, I still receive the "Unable to find a strict mathematical transformation" warning. I'm quite new to GIS in general, and haven't fully explored the geotools or opendata plugins, but is the warning still necessary given the above? If not, how to suppress it?

[Don-vip]

​https://osgeo-org.atlassian.net/browse/GEOT-6386 has been resolved in GeoTools 24-RC.

[taylor.smock]

This should be fixed since we updated to GeoTools 27 (see r36008/osm).