koopjs / featureserver Goto Github PK

If a provider denotes an idField in its metadata, the FeatureServers layer info service returns a fields array that contains both an OBJECTID field object as well as a separate object representing the provider's idField. For example, if the provider's metadata has idField: 'featureId' the the layer services field array will contain:

[       
  {
    "name": "OBJECTID",
    "type": "esriFieldTypeOID",
    "alias": "OBJECTID",
    "defaultValue": null,
    "domain": null,
    "editable": false,
    "nullable": false,
    "sqlType": "sqlTypeOther"
  },
  {
    "name": "featureId",
    "type": "esriFieldTypeInteger",
    "alias": "featureId",
    "defaultValue": null,
    "domain": null,
    "editable": false,
    "nullable": false,
    "sqlType": "sqlTypeOther"
  }
]

However, the query service squashes the two above field objects together into one object in the fields array.

{
  "name": "featureId",
  "type": "esriFieldTypeOID",
  "alias": "featureId",
  "sqlType": "sqlTypeOther",
  "domain": null,
  "defaultValue": null
}

The upshot is that the layer and query services have fields arrays of different lengths, and the query service doesn't have a field with name OBJECTID which causes client errors.

Version 1.12.6 of winnow was just published.

This version is covered by your current version range and after updating it in your project the build failed.

winnow is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

When processing a request where returnCountOnly=true but the where clause is such that no features match so the resulting count is 0, I get the following error:

SELECT properties as attributes, esriGeom(geometry) as geometry FROM ? LIMIT 2000 { returnCountOnly: true,
  limit: 2000,
  toEsri: true,
  collection: undefined,
  where: undefined,
  geometry: undefined,
  spatialPredicate: undefined,
  fields: undefined,
  order: undefined,
  aggregates: undefined,
  groupBy: undefined,
  offset: undefined,
Trace: TypeError: features.some is not a function
  projection: undefined,
    at limitQuery (/koop-provider-marklogic/build/koop/node_modules/winnow/dist/executeQuery.js:39:12)
  classification: undefined,
    at Object.Winnow.query (/koop-provider-marklogic/build/koop/node_modules/winnow/dist/index.js:34:36)
  dateFields: [] }
    at query (/koop-provider-marklogic/build/koop/node_modules/featureserver/dist/query.js:32:56)
    at execQuery (/koop-provider-marklogic/build/koop/node_modules/featureserver/dist/route.js:43:16)
    at Object.route (/koop-provider-marklogic/build/koop/node_modules/featureserver/dist/route.js:32:14)
    at /koop-provider-marklogic/build/koop/node_modules/koop-output-geoservices/index.js:9:24
    at /koop-provider-marklogic/build/koop/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/koop-provider-marklogic/build/koop/marklogic.js:41:8)
    at execQuery (/koop-provider-marklogic/build/koop/node_modules/featureserver/dist/route.js:45:52)
    at Object.route (/koop-provider-marklogic/build/koop/node_modules/featureserver/dist/route.js:32:14)
    at /koop-provider-marklogic/build/koop/node_modules/koop-output-geoservices/index.js:9:24
    at /koop-provider-marklogic/build/koop/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/koop-provider-marklogic/build/koop/marklogic.js:41:8)

Changing the query to return a count other than 0 works fine.

The result returned from the getData() function looks like this

{ type: 'FeatureCollection',
  metadata: { name: 'GDeltGKG' },
  filtersApplied: { geometry: true, where: true, offset: true },
  count: 0 }

In non-production environments, check incoming GeoJSON validity. If not valid, add console warning with explicit explanation.

When requesting the descriptor for a layer like

/<service>/FeatureServer/3

The id property in the response is always 0 but it should be the id of the layer requested. My provider implementation returns an id attribute in the metadata section but this is ignored as well.

In the fields array of responses, objects of type string and date have a length property that is automatically set to 128 and 36, respectively. We might want to consider having the set value sourced to the provider with a default and a max value check.

Request:

POST http://koop.dc.esri.com/github/smartchicago/chicago-atlas/db::import::zipcodes/FeatureServer/0/query HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: ArcGIS Pro 1.3.1 - ArcGIS Pro
Host: koop.dc.esri.com
Content-Length: 66
Connection: Keep-Alive
Pragma: no-cache

f=json&returnCountOnly=true&where=1%20%3d%201&returnGeometry=false

Response: Cannot POST /github/smartchicago/chicago-atlas/db::import::zipcodes/FeatureServer/0/query

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Would it be possible to add a new property to the filtersApplied object that would optionally skip the Winnow query all together?

Maybe something like (open to suggestions):
filtersApplied.skipWinnowQuery

Background
I'm currently using Koop as a pass-through provider where we are doing all of the filtering, offset, and limiting directly in the database call. I marked the filtersApplied.where and filtersApplied.geometry to true, but I received an error like this:

OFFSET >= features length: [object Object]

After some digging, I deduced that Winnow was trying to execute an additional query against my dataset, which we don't need for our application of Koop. Adding an optional parameter that allows the user to skip that query would be a huge help.

I am happy to provide the PR if requested. Thanks!

Update
I think there is more to this issue than I previously thought. I am going to close it for now until I can dig a little deeper.

When there is nothing specified in metadata.idField FeatureServer (by way of Winnow) will generate objectids automatically starting from zero. Because it always starts from zero you could have different source features given the same objectid. This results in bugs due to caching by ArcGIS clients.

Relevant code is here:

https://github.com/koopjs/winnow/blob/master/src/executeQuery.js#L66
https://github.com/koopjs/winnow/blob/master/src/executeQuery.js#L79-L84

FeatureServer and Winnow should avoid this situation with a more intelligent way of generating object ids.

Some options:

1. don't generate an objectid automatically at all (this may break some clients)
2. calculate a numeric hash of a feature (this may hurt performance)
3. generate a random object id per feature (unknown effect on arcgis clients)
4. add a numeric prefix that maps to the source request where the source features were requested (may be some complex logic here if the clients try to query the source for the same individual feature)

@rgrzywinski

When the JSON is wrapped in a callback (JSONP) the content type should be application/javascript

It is now being sent as text/html which doesn't work when the server also returns X-Content-Type-Options: nosniff. (At least not in Chrome)

There is code that tries to recognize when a layer is actually a table but this is not working when the metadata is actually for a table.

The provider returns this for the metadata:

          id: 1,
          name: 'All',
          decription: 'All US ZIP code boundaries (table-only)',
          idField: 'OBJECTID',
          displayField: 'zipcode',

No extents and no geometryType are set.

This results in the following stack trace:

Trace: TypeError: features.forEach is not a function
    at module.exports (/koop/node_modules/esri-extent/index.js:8:12)
    at Object.getExtent (/koop/node_modules/featureserver/dist/utils.js:24:17)
    at /koop/node_modules/featureserver/dist/info.js:83:29
    at Array.forEach (native)
    at Object.layersInfo (/koop/node_modules/featureserver/dist/info.js:82:10)
    at execInfo (/koop/node_modules/featureserver/dist/route.js:73:21)
    at Object.route (/koop/node_modules/featureserver/dist/route.js:36:14)
    at /koop/node_modules/koop-output-geoservices/index.js:9:24
    at /koop/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/koop/marklogic.js:45:8)
    at execInfo (/koop/node_modules/featureserver/dist/route.js:80:52)
    at Object.route (/koop/node_modules/featureserver/dist/route.js:36:14)
    at /koop/node_modules/koop-output-geoservices/index.js:9:24
    at /koop/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/koop/marklogic.js:45:8)

You currently have to over the point.json (or line, fill-symbol, polygon) files in \node_modules\featureserver\templates\renderers\symbology to override FeatureServer symbology. Please add the ability to pass a custom json file at the provider level.

Per the http://<featureservice-url>/<layerId> spec here http://resources.arcgis.com/en/help/arcgis-rest-api/#/Layer/02r3000000w6000000/, there are many properties that can be returned to describe each layer. Some of these would be dictated by the features that koop supports but many of them are really the responsibility of the provider to specify them.

For example, timeInfo and relationships should be able to be specified via the provider.

At a minimum, can you specify which of the properties the provider can control and what metadata property to use to set them?

Related to #53...

We have a pass-through Koop provider, with a maxRecordCount of 1000.

Unfortunately the Koop Feature Service is always showing exceededTransferLimit as false, even when the SCF API returns a total record count of 26,810 (e.g.). I've verified (via console logging) that geojson.metadata.limitExceeded is correcting being set to true inside our Koop provider.

Has anyone else had any problems like this?

adding a timeInfo object as an optional addition to the Feature Service endpoint would allow koop-based services to appear to be time-aware for ArcGIS clients. timeInfo defines several basic items:

• startTimeField: field used as the start timestamp for a feature
• endTimeField: field used as the end timestamp for a feature
• timeExtent: [, ] in epoch milliseconds
• timeReference
  • timeZone
  • respectsDaylightSaving
• timeRelation
• defaultTimeInterval
• defaultTimeIntervalUnits
• defaultTimeWindow
• hasLiveData

The feature server currently recognizes strings that are formatted as ISO 8601 date formats in provider features as esriFieldTypeDate. The values for these fields should actually be milliseconds since epoch (January 1, 1970) in UTC though so they need to be converted in the response.

This creates a defined contract between the FeatureServer and koop providers that says that all date fields returned by a provider must be in ISO 8601 formatted strings and that the FeatureServer will convert those to milliseconds since epoch in UTC.

Add support for the provider to be able to set maxRecordCount and hasStaticData for the /FeatureServer response.

When generating a layer descriptor response using field metadata from a provider, OBJECTID fields are set to type esriFieldTypeInteger.

My provider is setting the field type for the OBJECTID field to "Integer" and this results in a the type in the layer descriptor response to be esriFieldTypeInteger. If I do not include field metadata for OBJECTID, koop sets it to the correct type of esriFieldTypeOID.

Is there a type that the provider should specify in the metadata to indicate that the field is an OID?

Using Koop 3.5.1

Request: https://koop-three.herokuapp.com/chicagoFood/FeatureServer/0/query?f=json&where=&returnGeometry=false&spatialRel=esriSpatialRelIntersects&outFields=*&groupByFieldsForStatistics=risk&outStatistics=%5B%7B%22statisticType%22%3A%22count%22%2C%22onStatisticField%22%3A%22risk%22%2C%22outStatisticFieldName%22%3A%22countOFrisk%22%7D%5D&outSR=102100

The call doesn't fail, but there are no results returned. There should be multiple categories that come back such has "Risk 1 (High)" and "Risk 3 (Low)". Noticed this when trying to bring in this Koop URL to the web map viewer and symbolize by the "risk" column.

Source GeoJSON @ https://data.cityofchicago.org/resource/cwig-ma7x.geojson

Some sample results for this column come back in a simple query: https://koop-three.herokuapp.com/chicagoFood/FeatureServer/0/query?where=1=1&outFields=risk

I'm wondering if anyone used Koop as a secure Feature Service. For example, has anyone tried implementing ArcGIS Server Token Authentication or OAuth with Koop? The former might is probably more simple, but the latter more ideal.

i am curious how to set up the feature service output to be time enabled (and z value for that matter) so that we can use the time sliders in portal for arcgis or agol.

I have hacked together a provider that does this but would much rather this be part of the core product.

Version 3.4.0 of mocha just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

A recent change set the length property of string fields to 128. Why was that done? Is 128 characters the maximum length of a string field? I do not see that documented anywhere.

Moved to koopjs/koop-provider-composite#4

According to the Esri documentation https://resources.arcgis.com/en/help/rest/apiref/fsservicequery.html, queries like

query?geometryType=esriGeometryPoint&geometry=-122.2465038,37.5073428

should be supported but they result in the following stacktarce :

Error: bbox must be an Array of 4 or 6 numbers
at Object.validateBBox (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules//main.js:694:55)
at bboxPolygon (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules//main.js:20:13)
at module.exports (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/winnow/dist/geometry/transform-array.js:3:10)
at normalizeGeometry (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/winnow/dist/options/normalizeOptions.js:66:16)
at Object.prepare (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/winnow/dist/options/index.js:23:15)
at Model.getData (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/marklogic.js:25:28)
at /Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/koop/dist/models/index.js:13:14
at Cache.retrieve (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/koop-cache-memory/dist/index.js:75:38)
at Model.pull (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/koop/dist/models/index.js:9:14)
at Controller.Geoservices.featureServer (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/koop-output-geoservices/index.js:7:14)
at Layer.handle [as handle_request] (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/express/lib/router/layer.js:95:5)
at next (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/express/lib/router/layer.js:95:5)
at /Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/express/lib/router/index.js:281:22
at param (/Projects/github/ESRI/koop44/koop-provider-marklogic/build/koop/node_modules/express/lib/router/index.js:354:14)

Note that spatialRel is not specified so it should default to esriSpatialRelIntersects

Is it expected behavior for koop to turn empty parameters into 0 in the params passed to the provider? E.g., the following URL:

GDeltGKG/FeatureServer/3/query?f=json&orderByFields=

results in the following JSON params passed to the provider:

params: { id: GDeltGKG, layer: 3, method: query }, query: { f: json, orderByFields: 0 } }

Note that orderByFields is the number 0.

CLOSE THIS: This has to do with self signed HTTPS cert. Tested with a good SSL and all works fine.

--- original text----

I am not sure what is going on AGOL side but when loading up a koop map (webmap viewer) it makes a call back to AGOL for server side parsing of the koop layer definition file
ex. https://myOrg.maps.arcgis.com/sharing/proxy?https://100.14.60.227:12004/koop/arcgis/rest/services/koop/htrack-locations/FeatureServer/0?f=json
And only on that request does it 500. All the rest of the requests goto koop directly and work fine. I am not sure if that is critical or not. It seems to be some sort of feature detection server side. Oddly enough it seems like that only affects the rendering of the data if that call comes back instantaneous. If its is slowed down enough that the layer queries come back at roughly the same time things render properly. If I find anything I will update this ticket.

I am not sure this is relevant to the project but I thought I would throw it out there.

Add warning and or error response if a provider's metadata.geometryType has been set to an unsupported value.

After one of the recent updates (I'm not sure which one), there is logging that is outputting the query object to the console. It appears that it is code that is executed after the provider responds that is logging the requests.

Is there a way to disable it?

I originally posted this in the elasticsearch provider issues but now I wonder if it could be an issue with the feature server itself.

link to crossposting

essentially the request works fine with returnGeometry=true and it draws on the map, but it blows up with trying to show the data in the table (AGOL)

If the provider returns a response with an empty features array, the following error response is returned from koop:

{"error":"Cannot read property 'properties' of undefined"}

This happens a lot when extents are broken into a grid and each region is request separately as there will likely be some regions that have zero results.

Here's the trace

Trace: TypeError: Cannot read property 'properties' of undefined
    at normalizeCollection (/home/jkerr/projects/koop-provider-marklogic/node_modules/winnow/dist/options.js:36:41)
    at Object.prepare (/home/jkerr/projects/koop-provider-marklogic/node_modules/winnow/dist/options.js:15:17)
    at Object.Winnow.query (/home/jkerr/projects/koop-provider-marklogic/node_modules/winnow/dist/index.js:22:21)
    at query (/home/jkerr/projects/koop-provider-marklogic/node_modules/featureserver/dist/query.js:24:28)
    at execQuery (/home/jkerr/projects/koop-provider-marklogic/node_modules/featureserver/dist/route.js:44:16)
    at Object.route (/home/jkerr/projects/koop-provider-marklogic/node_modules/featureserver/dist/route.js:30:14)
    at /home/jkerr/projects/koop-provider-marklogic/node_modules/koop-output-geoservices/index.js:9:24
    at /home/jkerr/projects/koop-provider-marklogic/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/home/jkerr/projects/koop-provider-marklogic/marklogic.js:40:8)
    at execQuery (/home/jkerr/projects/koop-provider-marklogic/node_modules/featureserver/dist/route.js:46:52)
    at Object.route (/home/jkerr/projects/koop-provider-marklogic/node_modules/featureserver/dist/route.js:30:14)
    at /home/jkerr/projects/koop-provider-marklogic/node_modules/koop-output-geoservices/index.js:9:24
    at /home/jkerr/projects/koop-provider-marklogic/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/home/jkerr/projects/koop-provider-marklogic/marklogic.js:40:8)

Version 1.10.0 of winnow just got published.

This version is covered by your current version range and after updating it in your project the build failed.

winnow is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

When using the objectIds query field, if only one id is specified, an error is returned from koop.

When this url is passed in

FeatureServer/0/query?objectIds=1

this error is returned

{"error":"oids.map is not a function"}

It looks like it's not parsing the object ids to an array if there is just one value.

From @slibby
For geojson exports (and other formats) of large datasets, I think we may want to consider reducing decimal degree precision to reduce filesize. For complex polygon layers, the geometry section of the geojson file will take up the vast majority of the text space, and currently koop exports with 16-17 significant digits of precision:

"geometry": { "type": "Polygon", "coordinates": [ [ [ 85.275995105195037, 27.708265241160536 ], [ 85.273401891751973, 27.704288656786961 ], [ 85.268215466662468, 27.704288656786961 ], [ 85.265622253219405, 27.708265241160536 ], [ 85.268215466662468, 27.712241680589148 ], [ 85.273401891751973, 27.712241680589148 ], [ 85.275995105195037, 27.708265241160536 ] ] ] } }

Wikipedia shows us that 8 degrees of precision is down to 1mm of detail, which should be sufficient for most applications. Is it worth considering this when generating geojson, to save on disk and transfer overhead?

Allow the provider to control more of the service info response. It should be able to set/override all of the available fields including the available layers and tables.

Allow the provider to control more of the layer/table info response for each of the layers/tables. It should be able to set/override all of the available fields.

• It needs to convert "options.classificationDef" to Javascript Object
  function normalizeGeoservicesClassBreaks (options) in
  /build/koop/node_modules/winnow/dist/options/normalizeClassification.js

• URL : /marklogic/GDeltGKG/FeatureServer/0/generateRenderer?classificationDef=%7B%22type%22%3A%22classBreaksDef%22%2C%22classificationField%22%3A%22OBJECTID%22%2C%22classificationMethod%22%3A%22esriClassifyGeometricalInterval%22%2C%22breakCount%22%3A10%7D&f=json&where=1%3D1&

• req.query
  { classificationDef: '{"type":"classBreaksDef","classificationField":"OBJECTID","classificationMethod":"esriClassifyGeometricalInterval","breakCount":10}',
  f: 'json',
  where: '1=1' }

• Error :
  Error: Input classification type invalid:undefined
  at normalizeGeoservicesClassBreaks (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/winnow/dist/options/normalizeClassification.js:26:18)
  at normalizeClassification (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/winnow/dist/options/normalizeClassification.js:3:48)
  at Object.prepare (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/winnow/dist/options/index.js:32:21)
  at Model.getData (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/marklogic.js:24:28)
  at /Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/koop/dist/models/index.js:13:14
  at Cache.retrieve (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/koop-cache-memory/dist/index.js:75:38)
  at Model.pull (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/koop/dist/models/index.js:9:14)
  at Controller.Geoservices.featureServer (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/koop-output-geoservices/index.js:7:14)
  at Layer.handle [as handle_request] (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/layer.js:95:5)
  at next (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/route.js:137:13)
  at Route.dispatch (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/route.js:112:3)
  at Layer.handle [as handle_request] (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/layer.js:95:5)
  at /Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/index.js:281:22
  at param (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/index.js:354:14)
  at param (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/index.js:365:14)
  at param (/Projects/github/ESRI/koop12/21032018/koop-provider-marklogic/build/koop/node_modules/express/lib/router/index.js:365:14)

Per this spec https://resources.arcgis.com/en/help/rest/apiref/fsfeature.html clients should be able to request a feature as a resource using a URL like http://<featurelayer-url>/<featureId>

The feature id currently gets passed through to providers as the method but even if the feature is returned by the provider, the result returned from koop is

{"error":"Method not supported"}

Likely need a new route to handle this.

When I install from scratch and try to run a koop provider, I now get the following stack trace

module.js:557
    throw err;
    ^

Error: Cannot find module 'featureserver'
    at Function.Module._resolveFilename (module.js:555:15)
    at Function.Module._load (module.js:482:25)
    at Module.require (module.js:604:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/projects/koop-sample-app/node_modules/koop-output-geoservices/index.js:1:83)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)

This happens for both the MarkLogic provider I am working on as well as the koop-sample-app. The featureserver directory is there but there is no dist folder after running npm install.

If I have a polygon that crosses the positive/negative longitude line the feature server "normalizes" the points, which makes the polygon wrap around the entire world instead of crossing the boundary.
Example, this:
[
[179.83539094650206, -18.623051084066553 ],
[179.91769547325103,-18.487906116222785],
[180.08230452674894,-18.487906116222785],
[180.16460905349794,-18.623051084066553],
[180.08230452674894,-18.75808871660612],
[179.91769547325103,-18.75808871660612],
[179.83539094650206, -18.623051084066553 ]
]

Is turned into this:
[
[179.83539094650206, -18.623051084066553 ],
[179.91769547325103,-18.487906116222785],
[-179.917695473,-18.487906116222785],
[-179.835390947,-18.623051084066553],
[-179.917695473,-18.75808871660612],
[179.91769547325103,-18.75808871660612],
[179.83539094650206, -18.623051084066553 ]
]

Trace: TypeError: Cannot read property 'name' of undefined
at renderLayer (/Users//koop/providers/yelp/server/node_modules/featureserver/dist/templates.js:67:88)
at Object.layerInfo (/Users//koop/providers/yelp/server/node_modules/featureserver/dist/info.js:37:10)

Using koop-provider-sample when you hit /sample/FeatureServer this what you get:

{
    "error": "Cannot read property 'name' of undefined"
}

No logs are written to console and no easy way to find the reason, I had to use debugger and trace up to this:

40 name: geojson.metadata.name

You should provide defaults somewhere in the very beginning of the way (for example where router starts and receives geojson) and not to try to do it locally in every function, or use adequate getter like in lodash#get or ramda#path

@jkerr5 @dmfenton

For a koop query request, we get back invalid fields. Notice the outFields in the request.

Here is the request params.

f:json
geometry:{"xmin":-13633964.480821775,"ymin":4540069.018923454,"xmax":-13618753.512193045,"ymax":4553904.1210430525}
geometryType:esriGeometryEnvelope
inSR:102100
spatialRel:esriSpatialRelIntersects
outFields:date,OBJECTID //NOTICE WE ONLY ASK FOR 2 FIELDS (date, OBJECTID)
returnGeometry:true
maxAllowableOffset:38
outSR:102100
resultOffset:0
resultRecordCount:1000
where:1=1

Instead of Koop returning just the fields requested, it will send back additional (all the fields) in the response.

Here is a sample response. Notice the fields list contains too many fields (per above request).

{
	"objectIdFieldName": "OBJECTID",
	"globalIdFieldName": "",
	"hasZ": false,
	"hasM": false,
	"geometryType": "esriGeometryPoint",
	"spatialReference": {
		"wkid": 102100,
		"latestWkid": 3857
	},
	"fields": [{
		"name": "date",
		"type": "esriFieldTypeDate",
		"alias": "date",
		"length": null,
		"editable": false,
		"nullable": true,
		"domain": null
	}, {
		"name": "description",
		"type": "esriFieldTypeString",
		"alias": "description",
		"length": null,
		"editable": false,
		"nullable": true,
		"domain": null
	}, {
		"name": "title",
		"type": "esriFieldTypeString",
		"alias": "title",
		"length": null,
		"editable": false,
		"nullable": true,
		"domain": null
	}, {
		"name": "OBJECTID",
		"type": "esriFieldTypeOID",
		"alias": "ID",
		"length": null,
		"editable": false,
		"nullable": false,
		"domain": null
	}],
	"features": [{
		"type": "Feature",
		"attributes": {
			"date": 1045440000000,
			"OBJECTID": 1
		},
		"geometry": {
			"x": -13628245.578950467,
			"y": 4551415.036767305
		}
	}, {
		"type": "Feature",
		"attributes": {
			"date": 1045526400000,
			"OBJECTID": 2
		},
		"geometry": {
			"x": -13627745.45678585,
			"y": 4549486.239246354
		}
	}, {
		"type": "Feature",
		"attributes": {
			"date": 1045612800000,
			"OBJECTID": 3
		},
		"geometry": {
			"x": -13627759.946509149,
			"y": 4548404.142409862
		}
	}, {
		"type": "Feature",
		"attributes": {
			"date": 1045699200000,
			"OBJECTID": 4
		},
		"geometry": {
			"x": -13624472.414064351,
			"y": 4542558.103199204
		}
	}]
}

Per https://github.com/koopjs/FeatureServer/blob/master/src/generateRenderer/index.js#L23 koop doesn't support uniqueValueDef type for generate renderer.

Koop should be updated to support unique value statistics returned from the provider as well as class breaks.

Allow providers to override the renderer templates by providing renderer metadata of some sort.