koopjs / koopjs.github.io

Home of the Koop Geospatial Server.
https://koopjs.github.io
Apache License 2.0
14 stars 28 forks source link

normalize provider status #10

Closed ungoldman closed 7 years ago

ungoldman commented 9 years ago

Currently going to http://koop.dc.esri.com/providers gets you something like this (routes removed for readability)

{
  "Socrata": {
    "name": "Socrata",
    "hosts": true,
    "routes": {},
    "status": {
      "version": "0.4.1"
    }
  },
  "ckan": {
    "name": "ckan",
    "hosts": true,
    "routes": {}
  },
  "Github": {
    "name": "Github",
    "routes": {}
  },
  "Gist": {
    "name": "Gist",
    "routes": {}
  },
  "agol": {
    "name": "agol",
    "hosts": true,
    "pattern": "/:id/:item",
    "routes": {},
    "status": {
      "version": "0.3.2"
    }
  },
  "acs": {
    "name": "acs",
    "pattern": "/:year/:state/:variable/:for",
    "routes": {}
  },
  "osm": {
    "name": "osm",
    "routes": {}
  },
  "OpenData": {
    "name": "OpenData",
    "hosts": true,
    "routes": {},
    "status": {
      "version": "1.1.4"
    }
  },
  "FDA": {
    "name": "FDA",
    "hosts": false,
    "routes": {},
    "status": {
      "version": "1.0.0"
    }
  }
}

I think providers need a standard for this kind of info (what's required? what's relevant/important/useful? what's optional?). http://koop.dc.esri.com/status has a lot less info than what's on /providers too.

chelm commented 9 years ago

@ngoldman sounds like a good idea. For some background this endpoint was built to provide as much info about an installed provider as possible. Its not used anywhere :) EXCEPT i have a project i've been working on or a koop-ui which does use this.

I'll share that, its an angular ui and I really want it to be the electron app we've talked about.

chelm commented 9 years ago

also "name" is redundant, probably not needed.

The UI uses this route property to build a UI that shows how to make requests to provider routes.

hosts is used to make a request and a UI for each registered host.

ungoldman commented 9 years ago

@chelm Are you talking about Koop UI in this context?

ungoldman commented 9 years ago

Moving towards a structure like this:

{
  // required
  name: String,
  type: String,
  version: String,

  model: function,
  controller: function,
  routes: function,

  // optional
  hosts: Boolean,
  pattern: String // most likely to be deprecated
}

This structure will be automagically enforced by koop-provider.

var provider = require('koop-provider')

module.exports = provider({
  name: 'example',
  version: '1.0.0',
  model: require('./model'),
  controller: require('./controller'),
  routes: require('./routes')
})

In the above case, type is inferred, hosts is set to false by default, and pattern is omitted.

status currently provides no useful status-related information (version is a constant until the server is restarted with a new version) and is only used if served by the parent express application (see koop-dc-esri, opendata-koop). My plan is to remove status from the objects providers export altogether and instead have the koop sub app return more valuable information dynamically with its own /status route (jobs processed, connections, etc).

ungoldman commented 7 years ago

Looks like koop-provider has been retired, sad to see it never got used. Also think this issue is in the wrong repo, and I'm not sure what the status of koop status is anymore.

Keep up the great work @dmfenton (& friends)!

jgravois commented 7 years ago

using koop-provider-sample as a reference, its now a whole lot easier to create a new provider than it used to be.

you just update the getData() function in 'model.js' to fetch and massage into GeoJSON and you're good to go. knocked out one for the devil in the name of hurricane relief last night!

https://github.com/jgravois/koop-walmart/blob/9c2d7b274b32fe67287c04ac7deaa1f4220374ab/model.js#L15-L39

miss you!

ungoldman commented 7 years ago

Nice! Looks a lot saner than early days. 💯