[Talk-de] maxspeed
ant
antofosm at gmail.com
Mo Jan 17 11:51:22 UTC 2011
Hallo,
On 17.01.2011 12:38, M∡rtin Koppenhoefer wrote:
> Am 17. Januar 2011 11:21 schrieb ant<antofosm at 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
Mehr Informationen über die Mailingliste Talk-de