Hi Martin 2013/2/10 Martin Raifer <tyr....@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....@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 <sfkel...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
