📦 Preview the website for this branch here: https://deploy-preview-16318--ol-site.netlify.app/.

In addition to this change, I'd be in favor of depecating the epsgLookupMapTiler() function, and eventually even use the resurrected https://spatialrefence.org/ API for the default epsgLookup() function, using https://spatialreference.org/ref/epsg/${code}/ogcwkt/. Those work quite well with proj4, and I can also add more known datums and aliases to proj4. It's not much data and prevents a common source of reprojection errors.

The spatialreference definition for EPSG:27700 gives results very close to those for the most accurate non-grid transform if Ordnance_Survey_of_Great_Britain_1936 is changed to OSGB36 (without the change most results are over 100 meters out) so if an alias was supported that would work.

I do not think maintaining aliases may be necessary. Many of the WKT definitions place the datum code in in the GEOGCS name, not in the DATUM name (which holds a description). I found patching the following code from Proj.js

  if (json.datumCode && json.datumCode !== 'none') {
    var datumDef = match(Datum, json.datumCode);
    if (datumDef) {
      json.datum_params = json.datum_params || (datumDef.towgs84 ? datumDef.towgs84.split(',') : null);
      json.ellps = datumDef.ellipse;
      json.datumName = datumDef.datumName ? datumDef.datumName : json.datumCode;
    }
  }

to

  if (json.datumCode && json.datumCode !== 'none') {
    var datumDef = match(Datum, json.datumCode);
    if (!datumDef && json.GEOGCS && json.GEOGCS.name) {
      var geogcsName = json.GEOGCS.name.toLowerCase();
      datumDef = match(Datum, geogcsName);
      if (datumDef) {
        json.datumCode = geogcsName;
      }
    }
    if (datumDef) {
      json.datum_params = json.datum_params || (datumDef.towgs84 ? datumDef.towgs84.split(',') : null);
      json.ellps = datumDef.ellipse;
      json.datumName = datumDef.datumName ? datumDef.datumName : json.datumCode;
    }
  }

produces accurate results. Otherwise it falls back to WGS84, which in the case of EPSG:27700 is equivalent the tourist with GPS standing on the line at the Greenwich observatory. Ideally the WKT parser should set json.geogcsName to avoid proj4 having the access the GEOGCS object. It might also make checks for names such as new_zealand_geodetic_datum_1949 in the WKT parser unnecessary.

That's a bit of a hack. Better to enable looking up datums by the datum name, which proj4 v2.14 does.

Hi, sorry for the inconvenience. We will fix the Coordinates API bug (returning default transformation proj4 and wkt for all the transformations) on the MapTiler side as soon as possible.

In addition to this change, I'd be in favor of depecating the epsgLookupMapTiler() function, and eventually even use the resurrected https://spatialrefence.org/ API for the default epsgLookup() function, using https://spatialreference.org/ref/epsg/${code}/ogcwkt/.

Done - proj4 v2.14 is required for fromEPSGCode to set an accurate transform.

Hi, the issue was solved on the MapTiler side. Now the proj4 and wkt correspond with the transformation code.