id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
12188	ProjectionRegressionTest failure after [9106]	bastiK	team	"After [9106], there is a considereable change for the projections ""NAD27(76) / MTM"" and ""Monte Mario / Italy"" with offsets of up to several hundred meters: [https://josm.openstreetmap.de/jenkins/job/JOSM/jdk=JDK7/lastCompletedBuild/testReport/org.openstreetmap.josm.data.projection/ProjectionRegressionTest/regressionTest/ test report]

The reason for this is a missing datum in the definition and how this is handled by JOSM. Before r9106, we would implicitly add `+towgs84=0,0,0`, now we add `+nadgrids=null`. The first means that the ellipsoids are converted, but it is assumed they have the same center and orientation. The second skips datum conversion entirely and ""casts"" the lat/lon value.

I've changed this to mimic the behavior of the proj.4 software (unaware that we already have entries with unspecified datum).

Now is this change good or bad? I'm not sure, but I've tested [http://map.toronto.ca/servlet/com.esri.wms.Esrimap?ServiceName=OrthoImagery&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetCapabilities toronto wms] and it matches much better than before. Therefore, I keep it like this for now. If the previous version is preferred, it should be specified explicitly in the projection definition (add `+towgs84=0,0,0`).

Before (EPSG:2019):
(`+proj=tmerc +lat_0=0 +lon_0=-79.5 +k=0.9999 +x_0=304800 +y_0=0 +ellps=clrk66 +units=m +bounds=-81.5,40,-77.5,60 +towgs84=0,0,0 +wmssrs=EPSG:2019`)
[[Image(toronto-towgs84.png​)]]

After:
(`+proj=tmerc +lat_0=0 +lon_0=-79.5 +k=0.9999 +x_0=304800 +y_0=0 +ellps=clrk66 +units=m +bounds=-81.5,40,-77.5,60 +nadgrids=null +wmssrs=EPSG:2019`)
[[Image(toronto-nadgrids.png​)]]

"	defect	closed	normal	15.12	Core		fixed