[OSM-dev] Is there any API to get data from OSM as geoJson?

[Stefan Keller]

To Martin:
I see now, that GeoJSON is calculated at client-side in Overpass Turbo.

To Pavel:
Nice work. But I'm still not sure if OWL API is a solution to the question here:
The doc says "Returns a list of changesets that affect given tile."
But what we are after here is a set of regular GeoJSON objects (point,
linestring, polygon).
If one can hand over a date-in-history parameter to OWL API which
requests a state of this tile say 10 days ago that's would be
something optional.

What I also ever wondered is, how this Kothic alike API handles
linestrings and polygons which cross tile borders.

Yours, Stefan

2013/2/10 Stefan Keller <sfkeller at gmail.com>:
> Hi Martin
>
> 2013/2/10 Martin Raifer <tyr.asd at gmail.com>:
>> Btw: I think you are mistaken when it comes to Overpass API: it does *not*
>> return GeoJSON or any GeoJSON like geometry (LineStrings, etc.) [1]. Where
>> did you see ways as LineStrings as a response from Overpass?
>
> That's what I conclude from [1] i.e. <osm-script output="json">  ...
> </osm-script>
>
> Yours, Stefan
>
> [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide#Choose_file_format
>
> 2013/2/10 Martin Raifer <tyr.asd at gmail.com>:
>> Hello Stefan
>>
>> I mentioned client side generation of GeoJSON from OSM data as an
>> alternative to a "central GeoJSON API" approach (which API is not available
>> yet; see below).
>>
>> As always, it depends on the actual use case. When your application has its
>> own geo database already, it's probably best to implement the GeoJSON export
>> there. On the other hand, when you handle only few data from a source that
>> provides only OSM data (like the main API or Overpass API), it doesn't
>> really matter where you do the conversion. Or, if you are not interested in
>> displaying "live" (minutely updated) data, it may be best not to bother any
>> API on each request at all and do the conversion beforehand.
>>
>> That said, the original question for a "central GeoJSON API" is a more
>> complicated issue, as the conversion from OSM to GeoJSON is not always
>> trivial. An OSM object can be a LineStrings or a (Multi)Polygon in GeoJSON
>> depending on context! E.g. one can interpret an administrative boundary as a
>> border line [LineString] or the containing area [Polygon]. It gets even more
>> non-trivial for some of the more abstract relation types (turn restrictions,
>> enforcements, etc.). That said, it may be possible to write such a GeoJSON
>> API, but it must consider these contexts in some way.
>>
>> Btw: I think you are mistaken when it comes to Overpass API: it does *not*
>> return GeoJSON or any GeoJSON like geometry (LineStrings, etc.) [1]. Where
>> did you see ways as LineStrings as a response from Overpass?
>>
>> Cheers,
>> Martin
>>
>> [1]
>> http://overpass-turbo.eu/?Q=%3Cosm-script%3E%0A%20%20%3Cunion%3E%0A%20%20%20%20%3Cquery%20type%3D%22way%22%3E%0A%20%20%20%20%20%20%3Chas-kv%20k%3D%22cuisine%22%20v%3D%22pizza%22%2F%3E%0A%20%20%20%20%20%20%3Cbbox-query%20%7B%7Bbbox%7D%7D%2F%3E%0A%20%20%20%20%3C%2Fquery%3E%0A%20%20%20%20%3Crecurse%20type%3D%22way-node%22%2F%3E%0A%20%20%3C%2Funion%3E%0A%20%20%3Cprint%2F%3E%0A%3C%2Fosm-script%3E&C=47.39803;8.61975;18&R
>> (go to "data" tab)
>>
>>
>> Am 10.02.2013, 02:06 Uhr, schrieb Stefan Keller <sfkeller at gmail.com>:
>>
>>> To Martin and Ander:
>>> Martin suggested to use Overpass output. He also pointed to
>>> OSM4Leaflet.js which does resolve node id's in ways to linestrings.
>>> I would avoid such client-side calculations (except perhaps it's about
>>> an editor or admin too) since this can be done on server-side.
>>> But I think Overpass can already do that:
>>> [...]
>>>
>>> The response includes nodes and ways (which are eal GeoJSON
>>> linestrings) because  of the "magic" recurse syntax.
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/dev