[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