Koop-core should JSON.parse any incoming req.query that arrive as JSON strings.

It would be nice to not have to fork a provider if you wanted to append or transform data. For example, if my provider is the AGOL provider and I want to take a layer's results from AGOL on the fly and enrich the data (change some values or add additional fields) it would nice to have a place in the koop layer that exposes the results of the provider with a way for you to mutate it before its sent out vs having to extend the provider for every use case.

Ideally there would be an option for the winnow query to be run against the transformed dataset to apply the query against the transformed data (to filter it further)

I'm trying to send geo data to arcgis utilizing my own custom Koop provider, however even though the resulting query recognizes the z value of a POINTZ and prints it as such in the geometry, the "hasZ" field of the overall query is still "false". I've looked around the docs but I have not found any way to manually change it to "true" either. Is there a way to fix this issue?

Pictures for more context:

The devDependency gh-release was updated from 3.3.3 to 3.3.4.

🚨 View failing branch.

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

gh-release is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• Replace dependency @hapi/joi with joi ^17.1.0
• Update dependency config to v3.3.9
• Update dependency ejs to v3.1.9
• Update dependency sinon to v9.2.4
• Update dependency body-parser to v1.20.2
• Update dependency easy-table to v1.2.0
• Update dependency express to v4.18.2
• Update dependency featureserver to v4.1.1
• Update dependency lint-staged to v10.5.4
• Update dependency @koopjs/cache-memory to v5
• Update dependency @koopjs/output-geoservices to v7
• Update dependency lint-staged to v14
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency @koopjs/cache-memory to v2.0.3
• Update dependency chalk to v4.1.2
• Update dependency @koopjs/logger to v5
• Update dependency chalk to v5
• Update dependency featureserver to v5
• Update dependency gh-release to v7
• Update dependency husky to v8
• Update dependency sinon to v15
• Update dependency standard to v17
• Update dependency supertest to v6
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Currently, output-plugin routes are bound before a provider's routes. Thus, any routing conflicts default to the output-plugin routes. This limits the ability of a provider to add custom routes to supersede a output-plugin route. Therefore, the binding order should be switched.

Version 3.3.0 of supertest was just published.

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

supertest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Has anyone tested AWS API Gateways with Koop and Lambda. Seems serverless might actually be a reality at some point. This would be extremely powerful for multiple reasons, one is it would allow you to scale unique authentication per service or per group of services.

I am going to do some work in this space and report back what I have found.

It would be helpful to allow provider plugins to use a pass a Stream.Readable instead of GeoJSON to the output plugins.

This would allow the output plugins to begin processing data as soon as it's available instead of having to wait for the entire result of a request to be loaded into memory beforehand.

Version 1.3.0 of koop-output-geoservices was just published.

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

koop-output-geoservices 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 🌴

In generic plugin registration an error is currently thrown if the plugin name is defined.

  const name = Plugin.name || Plugin.plugin_name
  if (name) throw new Error('Plugin is missing name')

Probably should be the opposite of that?

Version 5.0.9 of sinon was just published.

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

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The Esri python API passes in 'True' and 'False' for boolean parameters. Can you fix this to handle this variation in case?

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 🌴

I tried to register an output with routes with uppercase request methods like GET but it failed. Turning the request method back to the lowercase worked.

It should accept both lowercase and uppercase for the route request method.

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 🌴

🚨 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 💜 🚚💨 💚

Find out how to migrate to Snyk at greenkeeper.io

The dependency @koopjs/logger was updated from 2.0.4 to 2.0.5.

🚨 View failing branch.

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

@koopjs/logger 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 🌴

previously I used cache.append with key = result of createKey now i think I must use createKey::data.

trying to avoid trial and error process ...

The devDependency mocha was updated from 6.2.1 to 6.2.2.

🚨 View failing branch.

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

mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The logic at src/index.js:334 seems to be backwards. When creating a plugin as a class or function, the name property is a read-only property from the Function object. In this scenario, we will never get to the plugin_name property. This causes an issue when uglifying code, because the value of Plugin.name becomes the new unrecognizable name given to the function in the uglification process. If the logic was instead: Plugin.plugin_name || Plugin.name, the name property would serve as a fail-safe and the plugin_name property would act as an override.

If this is not the intended use of plugin_name, then a different solution needs to be explored to resolve the bug introduced by uglifying logic.