[Talk-de] *:lanes und Straßenbahnschienen

Norbert Wenzel norbert.wenzel.lists at gmail.com
Sa Mär 16 09:55:38 UTC 2013


On 03/15/2013 09:41 PM, Martin Koppenhoefer wrote:
> Am 15. März 2013 15:18 schrieb Norbert Wenzel <norbert.wenzel.lists at gmail.com>:
>> On 03/15/2013 02:32 PM, Andreas Neumann wrote:
>>> On 03/15/2013 02:09 PM, Norbert Wenzel wrote:
>> Ja kann man, macht aber imo keinen Sinn es umzudrehen. Ich mein mit
>> Straßenbeschreibung nicht unbedingt die PKW Straße sondern die
>> umgangssprachliche Straße. D.h. den einen Way wo alles entlang geht mit dem
>> Namen XY.
>
>
> wobei der in OSM nicht unbedingt nur ein way ist, sondern manchmal
> eben auch mehrere, z.B. wegen baulicher Trennung werden ways parallel
> geführt, sie werden wegen sich ändernden Attributen gesplittet, etc.,
> d.h. was umgangssprachlich "eine Straße" ist, wird deshalb in OSM noch
> lange nicht als ein way gemappt. Das könnte man auch noch weiter
> spinnen, z.B. die "Weinstraße" (als touristische Route,
> umgangssprachlich "eine Straße", etc.)

Schon klar. Aber es braucht imo zwingend eine Möglichkeit diese beiden 
baulich getrennten Wege auf einen zu vereinen. Das sollte zumindest eine 
Relation sein, da das zusammenfinden ungefähr paralleler Ways außer 
rechenintensiv auch noch fehleranfällig ist. Relationen machen das 
Mapping aber (besonders für den von dir so oft beschworenen einfachen 
Mapper) kompliziert und fragil.

>> Man könnte auch sagen um eine perfekte Detailkarte in z19+ zu erstellen
>> erschwert man dadurch allen niedrigeren Zoomlevels das Arbeiten mit den
>> Daten. Selbst getrennte Fahrtrichtungen am Gleis kann man ja dann nicht ohne
>> Heuristik oder zusätzliche Datenstruktur zusammenfassen. Wenn ich hingegen
>> nur ein Gleis mappe und dabei die Anzahl der Gleise in jede Fahrtrichtung
>> angeb, hab ich das Problem nicht und kann bei Detailstufen halt von der
>> einfachen Linie auf die Doppellinie wechseln.
>
>
> das kann man immer sagen, dass mehr Abstraktion besser sei, wobei es
> in der Praxis durch mehr Abstraktion praktisch immer komplexer und
> schwieriger zu verstehen und editieren wird. Z.B. auch Spuren einzeln
> zu mappen (mit entsprechenden tags, nicht highway) wäre für den
> gemeinen Mapper viel einfacher zu verstehen und umzusetzen als das mit
> Attributen zu tun (und auch lagegenauer).

Aber mein Punkt ist nicht, dass das Erfassen einer perfekten Straße mit 
allen Spuren einfacher wird, sondern dass das Erfassen einer einfachen 
Straße einfacher wird bzw bleibt. D.h. der einfache Mapper zeichnet eine 
Linie und macht daraus highway=xy und der versierte Mapper verfeinert 
dann Spurtags.
Andersrum kann ein Mapper zwar viele Linien zeichnen wo eine Spur, ein 
Radstreifen, ein Fußweg, etc. ist, aber je mehre Wege und Relationen du 
hast, umso weniger Mapper sind in der Lage das fehlerfrei zu mappen. 
Aber die Information, dass es sich bei den 5 Wegen um einen Verkehrsweg 
handelt fehlt und, schlimmer noch, kann von dem unbedarften Mapper nicht 
als fehlend erkannt werden. Unter Umständen zerstört ein neuer Mapper 
sogar ein kompliziertes Tagging eines erfahreneren Mappers und bekommt 
erstmal als Begrüngsnachricht einen halbfreundlichen Link auf eine 
Wikiseite und einen Revert.

Das ist jetzt schon so und wird durch extensives Spurmapping nur noch 
mehr und mehr zunehmen. Je fragiler das Mappingschema ist (und ich halte 
Spurmapping, bei gleichzeitg halbwegs verwendbaren Daten für das 
komplexeste und fragilste mögliche Schema) umso mehr *muss* OSM wie 
Wikipedia werden, wo Admins praktisch jeden neuen Eintrag reverten, weil 
irgendwelche Kriterien bzw. Wikiregeln verletzt sind. Das ist dann auch 
aus Mappersicht nicht mehr erfreulich.

>> Was ich also gemeint hab war, dass durch eine solche Art des Detailmapping
>> die grobe und schnelle Übersicht über die Daten erschwert wird, was erstmal
>> jeden, der auch nur mit den groben Daten arbeiten will, dazu zwingt, alle
>> Detailmappingschemen zu verstehen, bevor er sie für seinen Gebrauch
>> vereinfachen kann.
>
> das stimmt zwar, ist aber halt so. Da man Daten nur vereinfachen kann
> (automatisch), sie aber nicht automatisch mit Details anreichern kann,
> sollte es klar sein, welchen Weg man wählt (als Projekt).

Das ist zwar richtig, aber vollkommen am Punkt vorbei. Natürlich kann 
man Daten nicht einfach erfinden, aber man kann Daten, wenn sie 
entsprechend eingetragen sind, von einer Basislinie aus genauso 
hinzufügen, wie man eine komplizierte Kreuzung mit vielen extra 
gezeichneten Spuren vereinfachen kann.
Der Punkt ist also nur, ob die Daten erstmal für jeden kompliziert sind 
und vereinfacht werden müssen, oder erstmal einfach sind, und nur für 
komplizierte Anforderungen die Auswertung aller Tags auch kompliziert wird.

>> Oder auch dass man, um diese Detailstufen zu vereinfachen relative
>> rechenintsive geometrische Operationen ausführen muss, anstatt einfach
>> erstmal ein relativ einfaches Stringprocessing indem man Tags, die einen
>> nicht interessieren (bzw. die man noch nichtmal kennt) wegwirft. Man hätte
>> also erst den Aufwand wenn man die Details wie Schienen, Fahrspuren,
>> Fußwege, Radstreifen etc. auch wirklich braucht.
>
> wobei die Grundregel ist, sich nicht am Auswerter zu orientieren
> sondern am Mapper.

Ist mir als Grundregel neu, aber nehmen wir sie mal so an. Wenn wir uns 
nur darum kümmern, dass wir einfach Mappen und viele möglichst 
unbedarfte Leute schnell beim Mappen Erfolg und vor allem Spaß haben, 
dann führt das in letzter Konsequenz dazu, dass wir einen Haufen Leute 
am Mappen haben, die irgendwas, irgendwie eintragen, aber die Daten 
unverwendbar sind. Weil schließlich geht es ja um den Mapper und nicht 
um die Daten.

Wenn wir diese von dir postulierte Grundregel also als Maxime annehmen, 
und alle Gegenargumente mit dieser Grundregel erschlagen, dann ist OSM 
schön zum Spaß haben für die Mapper, aber die Daten unbrauchbar bzw. 
nicht mit sinnvollem Aufwand für irgendwas anderes als Flächenanalysen 
von Gullideckeln verwendbar.

Ok, ich übertreib hier ein wenig, aber der Punkt ist: es sollte ein 
Ausgleich geschaffen werden, zwischen der Datenqualität und -konformität 
und den Interessen der Mapper, denn bei allem Spaß den die Arbeit an OSM 
macht (und auch machen soll) darf man nicht übersehen, dass es sinnlos 
wäre, Daten zu sammeln, die nicht auch verwendet werden.

> Rechenintensive Operationen sind immer einfacher
> (Moore'sches Gesetz) von allen zu bewerkstelligen, je mehr die Zeit
> fortschreitet. Das kann im Prinzip schon jetzt jedes 2. Handy, in 10
> Jahren können das auch die Kühlschränke ;-)

Das ist alles nett und halbwegs richtig aber unerheblich. Es nimmt zwar 
die Rechenleistung zu (und das auch nicht mehr in der Geschwindigkeit, 
dafür wird mehr parallelisiert, was bei OSM auch noch viel bringt), aber 
die Komplexität der notwendigen Algorithmen muss nicht nur von einer CPU 
sondern auch von dem Programmierer dahinter bewältigt werden. Und wenn 
ich als Programmierer die Wahl hab, mir einen aufgeräumten 
Routinggraphen bei einem kommerziellen Anbieter zu kaufen, oder mir 
einen komplizierten Datenwulst von OSM zu holen, der sich zwar schnell 
aktualisiert, aber Aufgrund des hochkomplexen Taggingsschemas praktisch 
laufend irgendwo fehlerhaft ist und ich mit irgendwelchen Heuristiken 
versuchen muss den zu reparieren, dann überleg ich mir recht schnell, ob 
mir die Aktualität der Daten wichtig genug ist und ob der Preis, denn 
ich für die kommerzielle Lösung zahl nicht deutlich günstiger ist, als 
die Programmierstunden die ich ins Feintuning meiner Heuristiken stecken 
muss.

tl;dr
Allein auf das Mappingerlebnis achten und es möglichst einfach halten 
kann nicht immer das Ziel von OSM sein. Es müssen *alle* bei OSM 
involvierten Seiten berücksichtigt werden, also auch Datenkonsumenten 
für Routing und Rendering in <z19.




Mehr Informationen über die Mailingliste Talk-de