[OpenStreetMap talk-lu] OSM database interface

Tue Dec 4 14:02:00 GMT 2012

Hi Guillaume,

> This is really interesting. With the 2169 it produces and Greasemonkey, we could maybe even hack OSM POIs into the Geoportail :).

Never thought about that, but yes :D

> Did you know about the xapi implementation that spits out geojson ( https://github.com/osm-spline/xappy.js )? Of course, it doesn't produce all the other formats osm2web does, and your small python app is, in my opinion, more readable.

I've heard about it, but never looked to close though. Since we have our 
own database and frequently use other coordinate systems than 
900913/3857 it was never a choice for us.

> Caching web content is what I'm currently doing at work. It would be great if we could work together, and maybe even make the service available through something like http://osm2web.openstreetmap.lu . What do you think?

Yes, that sounds interesting. I didn't think a lot about the caching 
mechanism yet but I had a request based caching solution in mind. Since 
the interfaces' intend is to be used by applications rather than humans, 
at least the initial request by an application can be cached. I thought 
about identifying requests by bbox, key, value and file type. Such a 
initial request would store its result on disk and each subsequent 
request requesting (omg) the same data again would be served the file 
instead of doing the database search again. Cache invalidation would 
simply be done by age, like 6 hours or so. But these are just my simple 
considerations so far. But I'm open to anything so we can make something 
up together ...

Concerning publishing the service on http://osm2web.openstreetmap.lu or 
wherever, sure why not? I guess the application needs some polishing and 
testing beforehand, and maybe a bbox restriction to the Great Region 
maybe, mainly due to performance issues, but in general I support the idea.

Let's see if there are some more opinions on this,

Frank

> Guillaume
>
> On 4 Dec 2012, at 08:55, Frank Broniewski <brfr at metrico.lu> wrote:
>
>> Hi all,
>>
>> I've developed an read-only interface to our OSM world database and I want to contribute this to the community in order to give something back.
>>
>> It's a simple interface, as you can query features by key=value or by OSM id. There're plans for a query language which allows broader queries but I haven't started yet. Where're using the interface in our OpenLayers Webapps and it's easy to integrate the URL as a Layer in OpenLayers. Several outputformats are supported, namely GeoJSON, GML, KML and GPX.
>>
>> Things are best explained by example:
>>
>> Query for restaurants:
>> http://www.gis-hosting.lu/osm2web/export/points/amenity/restaurant.geojson
>> Query for motorways:
>> http://www.gis-hosting.lu/osm2web/export/lines/highway/motorway.geojson
>> Query for restaurants:
>> http://www.gis-hosting.lu/osm2web/export/polygons/landuse/forest.geojson
>>
>> ... you get the idea: http://www.gis-hosting.lu/osm2web/export is a fixed part of the URL, the next part tells about the geometry type you want to retrieve, and the next two parts are the well known key=value combinations from the map features page in the OSM wiki. The file extension after the value part tells what kind of format you want to retrieve. Simply add any of the above mentioned output formats in lower case as file extension.
>>
>> A mandatory parameter is a bounding box (bbox=minx,miny,maxx,maxy) in order to limit the region of the query. At the moment I only check if the parameter is set, but I don't check the size. So you could go ahead and download all restaurants in the world -  but I *strongly* discourage that. So please keep your bounding box small. Downloading all restaurants in Luxembourg isn't a deal though ...
>>
>> There's one more thing I'd like to mention. We support all coordinate systems in the well known Proj4 database. So if you want LUREF coordinates, pass srid=2169 as an additional parameter. As a convenience feature, the bounding box needs to have the same CRS as the srid. The default srid is 3857, which is also the srid for the databases native CRS. So you can pass in the the srid as an additional query param to OpenLayers, add the BBOX Strategy and you're ready to go:
>>
>> var layer = new OpenLayers.Layer.Vector(
>>     'Restaurants in LUREF',
>>     {
>>         'strategies': [
>>             new OpenLayers.Strategy.BBOX()
>>         ],
>>         'protocol': new OpenLayers.Protocol.HTTP({
>>             'url': 'http://www.gis-hosting.lu/osm2web/export/points/amenity/restaurant.geojson',
>>             'format': new OpenLayers.Format.GeoJSON(),
>>             'params': { 'srid': 2169 }
>>         })
>>     }
>> );
>> You probably need to set OpenLayers.ProxyHost [2] in order to use the layer like this
>>
>> The other URL I implemented takes a geometry type - any of points, lines, polygons - and an OSM id as parameter and returns exactly one feature.
>> http://www.gis-hosting.lu/osm2web/export/points/id/1887429277.gpx for example is a hotel in Cape Verde. This URL doesn't take any additional parameters and returns the data always in WGS84 coordinate reference system.
>>
>> You'll get the full osm2pgsql schema, that means probably a lot of empty values in your attributes. But that's difficult to change right now. In the future I want to enhance the application further. The most important thing for me right now is a enhanced query language and SRID/EPSG support for the export by OSM id, but I don't have a timeline set up. I also plan on caching features retrieved from the database in order to speed up the deliverance through the web.
>>
>> There's a bitbucket repo at [1] where any changes should show up.
>>
>> I hope you'll find this project useful. Any feedback, positive or negative, or any questions are welcome.
>>
>>
>> Thanks for reading the email up to the end :-),
>>
>> Frank
>>
>>
>>
>>
>>
>> [1] https://bitbucket.org/metrico/osm2web
>> [2] http://trac.osgeo.org/openlayers/wiki/FrequentlyAskedQuestions#ProxyHost
>> --
>> Frank BRONIEWSKI
>>
>> METRICO s.à r.l.
>> géomètres
>> technologies d'information géographique
>> rue des Romains 36
>> L-5433 NIEDERDONVEN
>>
>> tél.: +352 26 74 94 - 28
>> fax.: +352 26 74 94 99
>> http://www.metrico.lu
>>
>> _______________________________________________
>> talk-lu mailing list
>> talk-lu at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-lu
>

-- 
Frank BRONIEWSKI

METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN

tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu