Talk:Essen Developers Workshop/Topics

Abolition of segments

I can't make the Essen meeting, but am interested in the segments discussion, so am posting a couple of follow-up comments here. Feel free to move to another page or to the dev list. --Richard 09:58, 13 February 2007 (UTC)

• What is to be gained from the abolition of segments?
  • Simplified database makes accessing the database much faster
  • Removes opportunity for 'wrong' data where segments are ordered confusingly
  • Formalises the status quo in which ways are tagged, not segments
  • Improves UI for those editors that follow the data model closely (e.g. JOSM), simplifies 'abstraction' for those that don't (e.g. Potlatch)
  • Rendering and editing code becomes less complex, more transparent
• What changes will be required in the editors, and perhaps also in the way we map?
  • Potlatch code will require very little alteration. Can't speak for JOSM or the applet.
  • I think this largely formalises existing best practice in mapping, though of course not everyone does things the same way.
• What new features will have to be introduced to compensate - superways, areas?
  • I think the jury's still out on this one. No consensus as yet.
• What's the transition strategy: How can we have a lossless conversion of the old data, and do all clients have to switch at the same time or can we "have it both ways" for a time to ease migration?
  • Lossless, automated conversion can be achieved by creating ways from adjacent segments with the same attributes. Worth tagging them with "source=converted segments".
  • It is possible for editors to simulate "ordered lists of nodes" while still writing segments via the API, so that users can get used to the concept before the switch is made, and so that editor authors can refine their UI. This may however require API changes for efficiency, and may not be the most efficient use of dev time.
• Do we have a halfway complete inventory of clients accessing the API?
  • Editing is probably the best list of editing clients.
  • Renderers/other read-only clients: Mapnik, Osmarender/Tiles@Home, Freemap, Planet dump... any others?
• Do we want it?
  • Anything that makes the project simpler and faster with little/no adverse effect gets a +1 from me. --Richard 09:58, 13 February 2007 (UTC)

Error Tracking into the OSM Database

• File an error against the spelling of a street name "Correct spelling is ..."

-- If you can file this, why don't you correct it immediately