Posted by Aaron Lidman on 16 July 2013 in English (English)

openstreetPOIs in downtown Los Angeles When using OpenStreetMap data there’s a frustrating divide in the representation of a place. Something like a supermarket, a school, or a park. It can be as simple as querying [leisure=park] from an API but what are you going to get back? Probably a way (polygon) or a node (point) and depending on which one it is you have to do things a bit differently to get where you want. You can specify to only return nodes but you’re going to miss things, it’s going to be incomplete because some of them have been mapped as ways, some as nodes. Because of this mixed bag it can be frustrating to try and do even basic things with the data. I just want points of interest.

way vs nodes For those who really know what they’re doing the solution can be to load an extract into PostGIS and do a carefully crafted query to get exactly what they want. This isn’t easy for most users or me; PostGIS isn’t easy to setup, crafting that query takes previous knowledge of the schema and PostGIS functions, importing that data into the database will be slow and overly complete, and then can you start querying. I just want some GeoJSON.

openstreetPOI nodes are easy

The solution is pretty simple. Take the existing nodes, pass them through and convert the structure into the desired output. For GeoJSON this means creating a new feature, putting the coordinates in the right place, and changing the tags to properties. That’s it.

For ways it gets a little more involved because they aren’t self contained, the coordinates are kept elsewhere in the file. So we have to take the tags and references for each way, keep a list of all the necessary refs, and get all the coordinates we need to replace the refs. Then we can build the ways and use their centroid as the point. Along the way tag values like the names, phone numbers, or links can be normalized or filtered to only return a specified set of items.

openstreetPOIs with Maki icons I made openstreetPOIs to do this. You can specify the features you want based on their tags, and set a few options. The main goal is to take in any common OSM file, process it quickly, and do so without a database. There’s a growing list of features I want to add and some things this data makes easier to build. The long term goal is simple, clickable, POIs for an OSM based map with flexibility for customization, along with just having lots of useful POI data. Checkout the github repo for more.

Comment from Tordanik on 17 July 2013 at 01:04

You don’t mention relations. Does your code handle POI mapped as multipolygons, specifically if the tags are on the relation instead of the outer ring?

Comment from Aaron Lidman on 17 July 2013 at 01:16

Yeah there’s no consideration for multipolygons right now, it wouldn’t be too difficult to add but unless I learn of some compelling reason I don’t think I will. It’s just that I’m more concerned with shop, amenity, leisure keys and simple features like that which aren’t used with relations much. Do you know of any particular features that are tagged as such that might get missed?

Comment from Tom Chance on 17 July 2013 at 10:38

Nice work, you might also be interested in the method I use for OpenEcoMaps:

This takes data from the Overpass API and pulls out features whether they are nodes, ways, or relations, turning them into GeoJSON and KML files.

Comment from Tordanik on 22 July 2013 at 00:28

You will occasionally get multipolygons even for amenities, shops and the like. Some examples (found via overpass turbo):

Compared with ways and nodes they are of course quite rare – Taginfo says that 0.06% of shops are relations, and about 1% of amenity and leisure features. It’s up to you whether you think including them is worth the effort.

(Sorry for the slow answer, expected to be notified about replies somehow.)

Login to leave a comment