[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