Jump to: content, navigation, search

Navigation menu

Working Group Minutes/EWG 2014-06-23: Difference between revisions

== Summary ==
 
* Osm2pgsql "multi backend" branch
* ''TODO''
** MapQuest have been porting osm2pgsql to C++ and adding a new backend.
** pnorman threw the whole planet at it, and it passed the statistics regression tests, which would probably have gotten regressions.
** The main blocker for merging is that we need to restore multiple core usage to the pending ways stage, as it was taken out during porting.
* Osm-carto & CI
** It would be nice to have some CI going to check that any pull requests for osm-carto compile to mapnik XML as a minimum, and even better, don't throw SQL errors.
** zere suggests using jenkins, shaunmcdonald is happy to put it on the ci.osm.org jenkins instance.
** pnorman puts it on his to-do board.
* CGImap and ordered / unordered results
** An implementation detail in the "read-only" instances of cgimap means they return OSM XML with elements sorted by their ID as well as their type.
** Although [http://wiki.openstreetmap.org/wiki/OSM_XML#Assumptions the docs] say "You can ''not'' be sure that ... blocks are sorted", it is still confusing, especially when many tools have exactly that (usually undocumented) assumption.
** Changing the behaviour will "fix" this, but we would need to change many bits of software before we could provide this as an API guarantee. Not sure what the performance impact would be - probably small, but not 100% sure.
** Sounds like the best option is to put it to the side unless we get some benchmark results.
* References to parent objects in OSM XML
** Zverik_h raised [https://github.com/openstreetmap/openstreetmap-website/issues/768] (adding references to parent objects to objects returned by API calls)
** There are already separate API calls to get parent relationships (e.g: node/#{id}/ways), but this proposed change would include those in all OSM XML responses.
** zere saw a couple of potential problems: 1) it changes the OSM XML format and require a version bump to 0.7, 2) it will impact performance of the queries but probably in a manageable way. Potentially it could be a soft version bump, since we could continue to serve 0.6 at the same time as 0.7.
** Zverik_h has been collecting together [http://wiki.openstreetmap.org/wiki/User:Zverik/API_0.7_Proposal a proposal for 0.7] which leaves out a lot of the "bigger" and more risky / time-consuming features (e.g: areas).
** Might be more productive to get some of the "smaller" API features out of the way and leave the more controversial ones for 0.8.
 
== IRC Log ==