6 ms·

OSM has gained countless new capabilities since moving to API 0.6 in 2009. World-class, super-fast routing. Beautiful vector maps. A much easier raster map API.

OSM has gained countless new capabilities since moving to API 0.6 in 2009. World-class, super-fast routing. Beautiful vector maps. A much easier raster map API. A powerful and performant query language. To say that progress is being "blocked" is not at all accurate. Sure, these aren't provided by what's formally known as the "OSM API". They are provided by OSRM/Graphhopper, Mapbox GL/Tangram, Leaflet/OpenLayers 3, and Overpass respectively. Because that's, deliberately, how OSM works: it's the centre of an ecosystem, not a single service provider. The OSM API is for the use of map editing programs. It's an implementation detail for the authors of iD, JOSM, Vespucci and a few others. It isn't something that anyone who isn't writing an editor needs to concern themselves about; and I honestly haven't heard many comments from editor maintainers that they want the API to do things it doesn't at present (though, Bryan, Dirk, Simon, do jump in and correct me if I'm wrong).

WhitneyLand 9y ago
Do you have any connection to any company involved with OSM tech, just so I understand your perspective? Mentioning OSM has gained functionality is irrelevant, the article’s point is the API which serves a different purpose. What other companies offer is irrelevant that’s not OSM. Your other points seem to attempt to diminish the importance of the API, yet the state of modern software has become such that almost any significant software project can benefit from a rich, well implemented and maintained API. Not to mention maintaining a high quality API often in and of itself leads to improvements in the overall architecture of software, due to how it encourages careful thought about the purpose and organization of the system.
- rmc 9y ago
  The "OSM API" is an editing API, for editing the map. The OSM ecosystem has gained some new, much more powerful APIs, which Doctor_Fegg mentions. OSRM's API, GraphHopper's API, Overpass's API, these are all better than the APIs that were available in 2009
  - WhitneyLand 9y ago
    Again I would ask, how does that invalidate the article’s premise that the core software API hasn’t changed in ~10 years? What other significant, widely used software, depends only on the “ecosystem” for APIs development, while having no active API efforts in the core project? I can think of none. Maybe some examples exist somewhere, but at the least it’s unusual, especially given the overall context of the article.
    - rmc 9y ago
      The core editing API hasn't changed in years. HTTP/1.1 come out in 1997 and HTTP/2 in 2015. Was web programming in 2014 the same as web programming in 1998?
      - WhitneyLand 9y ago
        Have you ever designed and implemented a modern api? It doesn’t work like that. HTTP itself is fundamental and a different level of abstraction. We would not want monthly updates. A closer analogy is Wikipedia (see wikimedia api). It hasn’t had the fastest evolution, but it makes OSM look like the stone age. You could look at the github api as a project that’s invested more frequently. And it’s not just because these are projects with vast riches (even though WP’s multi-million budget is actually tight). There are countless smaller projects that keep a well maintained API. I just list these because they are well known. The role and importance of APIs in software has changed dramatically over the last 20 years. It’s true at one point it was more of a luxury and just wasn’t as central to many projects. Those days are far enough in the past and so anachronistic that a ~10 year stale API at this point should be considered architectural malpractice.
        maxerickson 9y ago
        This discussion might be more productive if you laid out what you believe the OSM API being discussed already does and what you think it should do in addition to that. And then you could lay out why those things should be done centrally rather than on separate servers. For example, there is a sophisticated data query api https://wiki.openstreetmap.org/wiki/Overpass_API https://wiki.openstreetmap.org/wiki/Overpass_API that keeps up with edits within a minute or two but is free to lay out the backing database in a way that is optimized for queries and people can run their own instance and so on.

WhitneyLand 9y ago

Do you have any connection to any company involved with OSM tech, just so I understand your perspective? Mentioning OSM has gained functionality is irrelevant, the article’s point is the API which serves a different purpose. What other companies offer is irrelevant that’s not OSM. Your other points seem to attempt to diminish the importance of the API, yet the state of modern software has become such that almost any significant software project can benefit from a rich, well implemented and maintained API. Not to mention maintaining a high quality API often in and of itself leads to improvements in the overall architecture of software, due to how it encourages careful thought about the purpose and organization of the system.

rmc 9y ago
The "OSM API" is an editing API, for editing the map. The OSM ecosystem has gained some new, much more powerful APIs, which Doctor_Fegg mentions. OSRM's API, GraphHopper's API, Overpass's API, these are all better than the APIs that were available in 2009
- WhitneyLand 9y ago
  Again I would ask, how does that invalidate the article’s premise that the core software API hasn’t changed in ~10 years? What other significant, widely used software, depends only on the “ecosystem” for APIs development, while having no active API efforts in the core project? I can think of none. Maybe some examples exist somewhere, but at the least it’s unusual, especially given the overall context of the article.
  - rmc 9y ago
    The core editing API hasn't changed in years. HTTP/1.1 come out in 1997 and HTTP/2 in 2015. Was web programming in 2014 the same as web programming in 1998?
    - WhitneyLand 9y ago
      Have you ever designed and implemented a modern api? It doesn’t work like that. HTTP itself is fundamental and a different level of abstraction. We would not want monthly updates. A closer analogy is Wikipedia (see wikimedia api). It hasn’t had the fastest evolution, but it makes OSM look like the stone age. You could look at the github api as a project that’s invested more frequently. And it’s not just because these are projects with vast riches (even though WP’s multi-million budget is actually tight). There are countless smaller projects that keep a well maintained API. I just list these because they are well known. The role and importance of APIs in software has changed dramatically over the last 20 years. It’s true at one point it was more of a luxury and just wasn’t as central to many projects. Those days are far enough in the past and so anachronistic that a ~10 year stale API at this point should be considered architectural malpractice.
      - maxerickson 9y ago
        This discussion might be more productive if you laid out what you believe the OSM API being discussed already does and what you think it should do in addition to that. And then you could lay out why those things should be done centrally rather than on separate servers. For example, there is a sophisticated data query api https://wiki.openstreetmap.org/wiki/Overpass_API https://wiki.openstreetmap.org/wiki/Overpass_API that keeps up with edits within a minute or two but is free to lay out the backing database in a way that is optimized for queries and people can run their own instance and so on.