koopjs / koop-osm

An OSM provider for Koop (experimental).
http://koop.dc.esri.com/osm/points/state/Colorado/county/Larimer/field/amenity/pub/
5 stars 1 forks source link

Support for OSM outside USA #2

Open PeaceNlove opened 9 years ago

PeaceNlove commented 9 years ago

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.

chelm commented 9 years ago

I finally found this comment. Sorry it's taken me a while, I saw it come in and then couldn't remember what repo it was in!

This is really great suggestion @PeaceNlove and by all means makes total sense. However it is also a very tricky problem (as you point out the admin areas are different for different countries). I'd really like this to happen in some way. I've been looking for a series of admin level datasets (0-5) for the whole globe and have realized that its really hard to find. I actually have not looked into what OSM already has here though. So I may look into that.

I think that if you're able to get something going we should use that as a start point to make this happen.

PeaceNlove commented 9 years ago

I've been thinking more about this and we should use the OSM administrative levels and hopefully, also their data is suitable, see this page for more info: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries

However, we cannot require from the koop users to know all these administrative levels, so I think we should implement aliases to these levels in the routes.

So level2 is the national border, level4 US states, level6 counties for the current US administrative levels and for the dutch situation you would have level2 for the national border, level4 for the provinces and level8 for the municipalities so a route would look like this OLD: 'get /osm/:type/country/:country/state/:state/county/:county.:format': 'getCounty', NEW: 'get /osm/:type/level1/:level1/level4/:level4/level6/:level6.:format': 'getCounty', Downside here is that the user has to know which level is a US state and which level is a US county So if we can put aliases on each level, you can build the nice routes like before. This has however one complication, because a 'Province' in one country can be on another administrative level in another country. So these administrative aliases should be created for each country.

Implementing all these administrative levels is also a something to think a little bit more about. You don't want to enter all administrative levels in your route, because it makes them very long and some levels just don't make sense for some countries. The user should get the data using only two or three admin levels, the first one is required: level2 and below this level, the user can specify any other level, and as a third level, the user can specify any other level below the second administrative level. See for example the new route for the USA state and county route: 'get /osm/:type/level1/:level1/level4/:level4/level6/:level6.:format': 'getCounty',