Feature Layer can't be added, issue at createNewLayer() with geojson.geometry == null

[ahalota]

L.esri.featureLayer({url: 'http://services.arcgisonline.com/arcgis/rest/services/Reference/World_Boundaries_and_Places/MapServer/0'}).addTo(map);

Runs into issues in FeatureLayer.js at line 37:

  createNewLayer: function (geojson) {
    var layer = GeoJSON.geometryToLayer(geojson, this.options);
    layer.defaultOptions = layer.options;
    return layer; },

layer is null, i.e. GeoJSON.geometryToLayer failed.
geojson.geometry shows as null.

[jgravois]

that specific feature service is a very rare example of one that has stripped itself of a query operation altogether to deny folks the ability to fetch actual JSON features.

i'm not sure if this is a requirement of vendors/providers supplying content to Esri hosted services or a means to restrict server load. either way, we could trap for it in this library.

[ahalota]

Ah! A few more tests on my actual dataset show this. I am working with a published services for a raster mosaic gdb, which has layers for imagery, footprint, and boundary.

The boundary layer:
https://maps.nccs.nasa.gov/server/rest/services/gliht/201703_PuertoRico_test/MapServer/16
can be added.

However, the footprint layer has the same error as above:
https://maps.nccs.nasa.gov/server/rest/services/gliht/201703_PuertoRico_test/MapServer/17

Fortunately I needed the boundary layer after all so I'm all set, but something to keep in mind.

[jgravois]

its deceiving that the footprint layer advertises itself as esriGeometryPolygon because the features don't actually have any geometry

https://maps.nccs.nasa.gov/server/rest/services/gliht/201703_PuertoRico_test/MapServer/17/query?where=1=1&returnGeometry=true&f=json

"features": [
    {
      "attributes": {
        "Name": "20170301_PRday1b-108-70"
      }
    },
    {
      "attributes": {
        "Name": "20170301_PRday1b-122-30"
      }
    },
    {
      "attributes": {
        "Name": "20170301_PRday1b-92-68"
      }
    }

either way, it'd be good for us to trap for edge cases like this within Esri Leaflet instead of forcing developers to hunt down the cause themselves.