koopjs / koop-osm Goto Github PK

The package from NPM has a folder SQL with the necessary sql files to set up the db tables and the states and counties.
These SQL files however are not present here in Github. I would like to change and add in these files, but as far as I can see now, these modifications cannot come back here.

I tried the OSM provider today and got myself some supermarkets visualized on the map in Connecticut :-)
However, since I'm from the Netherlands I'm not particularly interested in the USA, and the current way the routes configured in the provider doesn't work well for other countries, or event countries at all.

So I would like to propose to include the country into the route, for example:
'get /osm/:type/country/:country/state/:state/county/:county.:format': 'getCounty',
This will require a world map with all country borders
Furthermore, routes will be added for the Dutch administrative system: provinces and municipalities
this will look like this:
'get /osm/:type/country/:country/province/:province/municipality/:municipality/field/:field/:value/FeatureServer': 'featureserver',
This will work for a lot of other countries as well, but in some cases there are additional administrative levels, for instance France has regions, departments, cantons and municipalities. I'm not sure whether all levels are interesting, but it's something to think about.
This would require additional tables in the database for the provinces and municipalities.

There are some problems implementing these additional routes: when you try to use province and municipality on the USA data, it will return no data. So you need to know in advance which routes are suitable for which country
Other countries have other administrative systems, so Koop-osm could end up having a lot of routes to cater for all those systems. You might solve that by using more abstract types of administrative units, like /1stadmin, /2ndadmin which would translate to State and county in the USA and to province and municipality in the Netherlands, but I think these abstract types make the data less accessible.

Before I start to implement these improvements to the koop-osm provider (which I would like to do), I would like your opinion first. I want to get the OSM provider to work for Dutch data as well, but I also want my code for these improvements accepted in the koop project.

• https://www.npmjs.com/package/koop-osm (updated 15 days ago)
• https://www.npmjs.com/package/koop-osm-provider (updated a year ago)

Neither of which link to this repo (updated 5 months ago)... what's going on?