Essen Developers Workshop/Topics

Please use this page to list/discuss what topics you want to work on at the workshop.

Data replication

(Added by User:Hakan)

The results of the first late night talk is in Essen Developers Workshop/Data Replication

JOSM

Unfortunately Imi couldn't attend due to "real life" :) deadlines. We collected some wishes and ideas during the workshop which can be found on Essen Developers Workshop/JOSM.

Future of rendering

(Added by User:Frederik Ramm - because I'm interested, not because I know answers)

• Discuss inherent Osmarender limits - how far will we get with Osmarender, is it really a "dead end"?
• Is Mapnik, at least in principle, able to render anything we might ever want, or does it have its limits?
• Are there alternatives?
• As a conclusion, will we need to build a full-blown rendering engine of our own, or is it better to spend our time improving (or helping to improve) the existing ones?

• Side thread: Oceans, large rivers/woodland areas, filling and clipping problems - how to deal with them in general, and in the tiles@home context
  • Discuss need for API to return all nodes and segments that belong to a way (even if outside the bbox). This would solve the issue with filling/clipping of large lakes etc and also ensure there are no incomplete ways in JOSM.
• tiles@home: only a workaround because Osmarender is so slow, or an idea with interesting potential?

(Added by User:Hakan

• Can tiles@home be expanded to render tiles from VMAP0 (for political boundaries, land/water boundaries etc) where no data exists in the OSM database?
• Would in that case the server notice that there is no data and send on-the-fly converted data to the tiles@home client?

Data Model

(Add questions)

Where are we going, data-model-wise?

Abolition of Segments

The much-talked-about abolition of segments seems to be nothing more than much-talked-about.

• What is to be gained from the abolition of segments?
• What changes will be required in the editors, and perhaps also in the way we map?
• What new features will have to be introduced to compensate - superways, areas?
• 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?
  • Consider an intermediate, "alternative" API that describes ways without using segments. An .osm converter can easily produce this and clients can choose to use the new format if it suits them. Something like this can be derived automatically with no change to the database:

<way>
 <seg id='98765' fromNode='123' toNode='456'>  (Segment id's preserved so that the transform can be bi-directional)
   <tag k=... (for segment level tagging)
 <seg fromNode='456' toNode='789'>
 ...
</way>

• Do we have a halfway complete inventory of clients accessing the API?
• Do we want it?

Introduction of New Structures

• With or without segments, will we need/do we want something that is on a higher level than a way - a superway or something?
• How can we effectively model and edit relations between things (e.g. "no left turn from a to b") without running the risk of referenced items being changed/removed by someone ignorant of the relation?

Integrate Notification / Error Tracking into the OSM Database

Things we need as the map improves User:Josy

• Similar as software projects track the bugs in their software with bugzilla, the OSM project should track bugs in its OSM-Database (Streets, ) in a integrated bug tracking system.

Examples:

• Leave an note to others that this area needs a new maintainer
• Leave an note to others that this area had been reviewed and the ways should be complete
• Leave a note that this way had not been positioned exact and need to be reviewed
• File an error against the spelling of a street name "Correct spelling is ..."
• Notify others that this track should be reviewed.
• Please review direction of this one way-street.

To be discussed:

• How to integrate this into the OSM tool chain? (Data model, Editor, Web interface)
• How to search for Errors / Notifications for a certain area?
• How to track bug state changes?
• Which attributes have to be associated with an error or notification?

API

• Should the API include elements that contain copyright [and attribution] information? Osmarender currently includes the following in it's SVG output. Should the API response include something like this (all or part) in its output?

<!--

    Copyright (c) 2007 OpenStreetMap
    www.openstreetmap.org
    This work is licensed under the
    Creative Commons Attribution-ShareAlike 2.0 License.
    http://creativecommons.org/licenses/by-sa/2.0/

-->
<metadata id="metadata">
  <rdf:RDF xmlns="http://web.resource.org/cc/">
    <cc:Work rdf:about="">
      <cc:license rdf:resource="http://creativecommons.org/licenses/by-sa/2.0/"/>
      <dc:format>image/svg+xml</dc:format>
      <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
      <dc:title/>
      <dc:date>2007-03-12</dc:date>
      <dc:source>http://www.openstreetmap.org/</dc:source>
    </cc:Work>
    <cc:License rdf:about="http://creativecommons.org/licenses/by-sa/2.0/">
      <cc:permits rdf:resource="http://web.resource.org/cc/Reproduction"/>
      <cc:permits rdf:resource="http://web.resource.org/cc/Distribution"/>
      <cc:permits rdf:resource="http://web.resource.org/cc/DerivativeWorks"/>
      <cc:requires rdf:resource="http://web.resource.org/cc/Notice"/>
      <cc:requires rdf:resource="http://web.resource.org/cc/Attribution"/>
      <cc:requires rdf:resource="http://web.resource.org/cc/ShareAlike"/>
    </cc:License>
  </rdf:RDF>
</metadata>

• Is OSM in violation of its own license if it doesn't?