Hallo,
On 17.01.2011 12:38, M∡rtin Koppenhoefer wrote:
Am 17. Januar 2011 11:21 schrieb ant<antof...@gmail.com>:
Ich glaube, manche wollen einfach ignorieren, dass es in gewissen
Anwendungsfällen Defaults gibt und auch geben muss. Siehe z.B. die
Implikationen fürs Routing [1].
wertet das denn jemand aus?
Weiß ich nicht, ob das so schon genutzt wird. Wenn nicht, ist das
immerhin aber schonmal eine gute konzeptionelle Grundlage für zukünftige
Anwendungen.
Die expliziten Maxspeeds in Kombination
mit source:maxspeed haben halt den Vorteil, dass sie transparent sind,
bereits von Anwendungen (z.B. Garminkarten) ausgewertet werden
Für Routing oder fürs Auffinden ungemappter maxspeeds?
und
dennoch ggf. bei Gesetzesänderungen (Änderung des Default) problemlos
angepasst werden können. Mit dem Polygon müsste man ggf. die komplette
Stadt runterladen um zu prüfen, ob es schon ein Polygon gibt, ob sie
geschlossen und vollständig sind, ob sie geometrisch gültig sind, und
sobald jemand das Polygon durch sein Mappen ungültig macht, (z.B.
Lücke) gehen alle Anwendungen baden.
Eben das gleiche, was für admin-boundaries auch gilt. Interessanterweise
ist der "is_in"-Key weitestgehend in Verruf geraten, wenn mich nicht
alles täuscht.
Wir können nicht ernsthaft danach streben, durch explizites Tagging
sämtliche Defaults überflüssig zu machen. *Das* ist nämlich fehleranfällig,
weil OSM nie vollständig sein wird.
m.E. ist der Rückschluss genau das Gegenteil: je mehr explizite Tags
dran hängen, um so sicherer wird es, eben weil die Daten nicht
vollständig sind. Sich da auf Defaults zu verlassen ist doch extrem
riskant.
Andererseits wäre es fatal, sich ausschließlich auf das Vorhandensein
der source:maxspeed-Tags zu verlassen. Ein Fallback ist also immer sinnvoll.
Grüße
ant
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
