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 <[email protected]>: > Hi Martin > > 2013/2/10 Martin Raifer <[email protected]>: >> 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 <[email protected]>: >> 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 <[email protected]>: >> >>> 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 >> [email protected] >> http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
