The support for #1453 was primarily done to allow one to pre-register custom projections without an epsg.io lookup and invasive viewer HTML modification to pre-register such projections.
In my particular case, this was to allow me to pre-register an "older" proj4 definition of EPSG:26741 that did not require a me to download the 13MB ntv2_0.gsb grid shift file and load these bytes into proj4.nadgrids. The proj4 defn from epsg.io now requires this grid file be registered with proj4js. In my case, all I wanted was for my example map of Redding, CA in its native projection to easily mash up with an OSM/Stamen XYZ tile backdrop. I was happy to accept this loss of precision.
But there may be others where this loss of precision is unacceptable, and therefore we must be able to provide the means of declaring one or more grid files that need to be downloaded and registered with proj4 as part of viewer init.
The support for #1453 was primarily done to allow one to pre-register custom projections without an
epsg.iolookup and invasive viewer HTML modification to pre-register such projections.In my particular case, this was to allow me to pre-register an "older" proj4 definition of
EPSG:26741that did not require a me to download the 13MBntv2_0.gsbgrid shift file and load these bytes intoproj4.nadgrids. The proj4 defn fromepsg.ionow requires this grid file be registered with proj4js. In my case, all I wanted was for my example map of Redding, CA in its native projection to easily mash up with an OSM/Stamen XYZ tile backdrop. I was happy to accept this loss of precision.But there may be others where this loss of precision is unacceptable, and therefore we must be able to provide the means of declaring one or more grid files that need to be downloaded and registered with proj4 as part of viewer init.