For some reason EPSG:2263 projections seem to be incorrect. The tile server works properly at all zoom levels as configured. However, the tiles are rendering at the incorrect latLong.

  • Origin was obtained from server's bounds: Only Top left (tl) works.
  • the transformation solution commented in code has no effect

Current Proj4Leaflet config:

var empireStateBldg = new L.latLng(40.7484444, -73.9878441),
// Bounds from server: Top left (tl) works as origin.
tl = L.point(700000.0,  440000.0),
br = L.point(1366666.6683464567, -4444.4455643044785),
tr = L.point(1366666.6683464567, 440000.0),
bl = L.point(700000.0, -4444.4455643044785);

var nycCrs = new L.Proj.CRS("EPSG:2263",
    "+proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666 +lat_0=40.16666666666666 " +
    "+lon_0=-74 +x_0=300000.0000000001 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 " +
    "+units=us-ft +no_defs",
    resolutions: [
        434.0277788713911, 303.8194452099737, 222.22222278215222, 111.11111139107611, 55.555555695538054,
        27.777777847769027, 13.888888923884513, 6.944444461942257, 3.4722222309711284, 1.7361111154855642,
        0.8680555577427821, 0.43402777887139105, 0.21701388943569552, 0.10850694471784776
    origin: [tl.x, tl.y],

    // (1, -x_origin, -1, y_origin)
    // transformation seems to have no effect
    transformation:new L.Transformation(1, -700000.0, -1, 440000.0),

var map = L.map('map', {

L.tileLayer.wms('http://maps.nyc.gov/geowebcache/service/wms/', {
    layers: 'dtm',
    format: 'image/png',
    maxZoom: nycCrs.options.resolutions.length,
    minZoom: 0,
    continuousWorld: true,
    tileSize: 512,
    worldCopyJump: false

map.setView(empireStateBldg, 0);



var popup = L.popup();

function onMapClick(e) {
        .setContent("You clicked the map at " + e.latlng.toString())

map.on('click', onMapClick);

The issue was due to incorrect proj4js.def data from epsg.io. I used the data from spatialreference.org and it worked perfectly.

I wonder if there is some leaflet or proj4leaflet setting for units that would have made epsg.io's definition work? It appears the difference was with units=us-ft vs datum=NAD83 +to_meter=0.3048006096012192

epsg.io provided this (incorrect): "+proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666 +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs"

spatialreference.org provided this (correct): "+proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666 +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs"

  • Note that according to the EPSG Geodetic Parameter Registry (epsg-registry.org) remarks ~ State law defines system in US survey feet. Federal definition is metric, so both may be regarded as correct by different camps, but strictly as EPSG is the authority for EPSG codes, and EPSG says units are in US survey feet (complying with state law) epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::2263 it's spatialreference.org that's incorrect. – nmtoken Sep 20 '19 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.