Zum einen braucht es dafür ein gutes Werkzeug. Dieses muss die vorhandene Situation in den Daten analysieren können und dem Nutzer dann eine einfache Art der Bearbeitung ermöglichen und anschließend die Änderungen wieder in die Daten schreiben. An sich sehe ich hier aber kein Hindernis.
Die andere Sache ist, dass wir ein Schema brauchen, dass von den vorhandenen Editoren angezeigt werden kann, vom Mapper zumindest erkannt werden muss, was es ist, damit es beim Editieren nicht kaputt gemacht wird.
Ich denke OSM ist hier an einen kritischen Punkt angekommen. Einfach einen Weg zeichnen kann (fast) jeder. Komplexe Kreuzungen mit ihren Spuren, Restriktionen usw. zu erfassen ist schon deutlich schwieriger. Ein entsprechender Editor könnte die Erfassung zwar erleichtern, aber verringert nicht die Komplexität des zu erfassenden Objektes.
Das wird viele Mapper abschrecken, bzw. einige werden daran scheitern. Reicht es dann also aus, wenn nur noch eine Handvoll Spezialisten solche Sachen mappen können? Ich denke z.B. an die diversen ÖPNV-Schemata. Das war (ist?) ständig im Wandel, jedes Jahr gab es ein “neues ÖPNV-Schema”. Man hat versucht immer mehr Besonderheiten aufzunehmen; mit dem Resultat, daß sich viele Mapper, wie auch ich, sich völlig vom Thema ÖPNV verabschiedet haben.
Ich finde die Idee sympatisch, mehr Informationen für das Routing einzupflegen, allerdings immer mit dem Hintergedanken dabei, dass es möglich ist, auch ebenso einfach zu mappen, wie es bis dato der Fall ist.
Das bedeutet: Neue Straßen kann ich weiterhin einfach mit Punkten und Linien einfügen, die erlaubte Geschwindigkeit und den Straßennamen erfassen und fertig. Auch muss sichergestellt werden, dass der gemeine Pöbel vom Land, wie ich einer bin, die mit einem Routing-Schema versehenen Kreuzungen editieren kann, ohne Angst haben zu müssen, dass er die Routinginformationen zerstört und hinterher der Angepöbelte ist.
Das läuft dann wieder darauf hinaus, dass es einen geeigneten Editor gibt, der darüber wacht, dass keine Fehler produziert werden. In einem vorigen Thema wurde einer mal vorgestell in einem Videot. Ohne darauf zu achten, welche Attribute er wie und woran setzt, Relationen erstellt u.s.w., finde ich die grafische Oberfläche gut.
Und dann soll dieser intelligente Routing-Editor auch auf unterschiedlichen Editoren (JOSM, Potlach, …) laufen. Das dürfte die größte Herausforderung werden.
Das ist eben das Problem, um die Realität gut wiedergeben zu können braucht man komplexere Modelle, damit aber der Crowdsourcing-Ansatz funktioniert, müssen diese aber möglichst einfach sein. Werkzeuge wie Editoren können da nur unterstützen, die Funktion und Bedeutung der Elemente des Schemas muß man trotzdem kennen.
Und genau darin bin ich nicht der Meinung.
Ich weiß ja schon jetzt nicht, wie der Ablauf im einzelnen von Statten geht. Ich muss nicht wissen, wie das im Hintergrund abläuft. Es ist mir ja jetzt auch egal, wie die Daten auf den Server kommen, ich klicke nur und vertraue dann auf josm.
Wenn ein unbedarfter eine Kreuzung editiert, die Routingi-Iformationen enthält, bspw. durch Hinzufügen eines Nodes, um den Straßenverlauf besser abbilden zu können, soll es nicht seine Aufgabe sein, die unzäligen Tags und Relationen anfassen zu müssen. Oder er bekommt automatisch eine grafische Oberfläche angezeigt in welcher die Konflikte intuitiv gelöst werden können, wie in dem Video dargestellt.
Es wird wahrscheilich genauso wie jetzt laufen:
anfänger werden POI´s eintragen und eine ganze Menge anderer Informationen für die man kein schwierigeres Wissen benötigt. Und die Straßen? Ich glaube dass in einem Jahr in D,A,CH ist die Abdeckung schon so gut, dass nur kleinere Straßen gemappt werden müssen - also solche für die man kein derart mächtiges Werkzeug braucht.
Ich habe ein solches Modellierwerkzeug mit zwei Leuten die keine Erfahrung hatten getestet, ein dritter hat´s geschrieben (JOSM PlugIn). Es war vor 3 Jahren, hatte aber noch nicht alle Funktionen drin. Einigen wir uns auf eine Lösung, können wir auf dem open source Projekt weiterbauen. Wir haben genug gute Leute die sowas in Java schreiben können.
Dein Gedanke, marek, funktioniert aber nur unter der Voraussetzung, dass die großen Straßen nicht wieder von neuen Mitstreitern angefasst werden. Das wird aber nicht funktioniert - soll es auch gar nicht. Wenn ein Neuling eine geänderte Straßenführung im Kreuzungsbereich ändern möchte, dann soll er das auch mit dem Werkzeug bequem machen können, ohne die Routing-Informationen unbrauchbar zu machen.
Wenn das Werkzeug nicht entsprechend mächtig ist, habe ich schon jetzt die Diskussionen wieder vor dem geistigen Auge in welchen sich die alten Hasen beschweren, dass die Kreuzungen kaputt sind. Dann wird jemand kommen und behaupten, dass das Tagging zu kompliziert ist und ein neues Schema vorschlagen. Bestes Beispiel dafür ist der schon angesprochene ÖPNV. Auch ich wollte da mal was eintragen, wusste nicht nach welchem Schema ich vorgehen soll und habe es deshalb nicht gemacht. Richtig verstanden hatte ich keines davon.
Für JOSM-User mag das ja hilfreich sein, allerdings benutzen die Nicht-Experten-Benutzer, die hier Unterstützung bräuchten, eher Potlatch… Wollt Ihr das auch leisten?
Ich benutze selbst Potlatch obwohl ich JOSM kenne- die Frage interessiert mich also auch. Die Frage ist also, ob wir dafür die Umgebung der Potlatch Entwickler gewinnen können, denn ohne sie geht´s nicht. In diesme Fall bräuchten wir aber eine Lebby Arbeit der Community selbst.
Es gibt ja noch viel mehr Editoren als Potlatch und josm und es ist auch nichts neues, dass man mit dem einen Editor gewisse Sachen einfacher editieren kann als mit anderen. Wobei das ganze auch in anderen Bereichen so üblich ist. Als Anwender muss man sich dann den passenden Editor raus suchen. Es meckert ja auch keiner rum, dass man einen Roman nur sehr schwerfällig in notepad etc. schreiben kann.
Das Tagging steht und fällt aber mit dem Verständnis durch die Mapper. Ein Mapper, der eine Straße editiert muss wissen, was er beachten muss. Sprich er muss zumindest erkennen, dass an dem Wegstück Spurinfos vorhanden sind und wie er damit umzugehen hat. Das heißt aber nicht, dass jeder Mapper das Ganze bis ins Detail verstanden haben muss. Aber auch das ist in OSM nichts neues. Auch als erfahrener Mapper schaue ich recht häufig ins wiki, wie ich eine Sache eintragen muss.
Das Mappen nach dem neuen System wird von dem Mapper Sachen verlangen, die einfach sind und gut beobachtbar, daher vermute ich, dass sich dieses System ausbreiten kann.
nun müssten wir uns zum dritten Garchinger Treffen verabreden…
Moeglicherweise hilft in der Hinsicht etwas wenn man automatische Tests ueber die grossen Strassen laufen laesst und somit erkennt wenn etwas kaputt geht. Dann kann man das recht schnell wieder fixen. Natuerlich waere es besser wenn Sachen gar nicht erst kaputt gehen und das sollte auf jedenfall das Ziel sein, aber besser Qualitaetskontrollen wuerden auch helfen.
Eine sehr primitive Version von (semi) automatischen Qualitaetskontrollen ist z.B. das routing Grid, das die routing Distanz zwischen verschiedenen Staedten ermittelt. Wenn groessere Kreuzungen kaputt gehen, kann man das vermutlich in der erhoehten Distanz sehen.
Dort sieht man z.B. das an vielen Deutschen Autobahnen das maxspeed tag zu fehlen scheint. Da OSRM ein default von nur 90km/h fuer highway=motorway annimmt, sind die Zeiten die OSRM ausspuckt wesentlich laenger als die von google’s routing.
Es sieht so aus als haette ich gerade die Strassenbahnlinie in der Mitte der Strasse getroffen. Da werde ich wohl den Startpunkt etwas verschieben muessen…
Ich konnte kaum glauben, dass da teilweise so große Differenzen rauskommen, speziell Stuttgart-München habe ich mir mal angeschaut. Daher habe ich mal schnell eine Maxspeed Karte gebastelt. Maxspeed ist fast durchgängig auf der Autobahn zwischen S-M vorhanden. http://suncobalt.dyndns.org:82/maxspeed.php?zoom=9&lat=48.51432&lon=10.43152&layers=TB
Es muss also einen anderen Grund geben. Wer sagt, dass Google stimmt?
Wenn ich das richtig verstehe, wird im Code nur eine Umrechnung von Meilen in km/h gemacht sowie evtl. ein Parameter berücksichtigt, der ggfs. das Minimum von Maxspeed und Default-Geschwindigkeit verwendet. Parameter heißt im speedprofile.ini: takeMinimumOfSpeeds und ist im car-Profile normalerweise auf “no” gesetzt. maxspeed=none finde ich dagegen nicht.
Auf der anderen Seite: im Mittel wird man wohl kaum großartig über 120km/h hinauskommen je nach Verkehr.
Schnuckelig
bau bitte noch “auf die Schnelle” maxspeed:forward und maxspeed:backward ein und dann kann man die schon mal für QA verwenden. Farben pro Speed sind nicht so wichtig.
Grund: ich habe entweder maxspeed, maxspeed:forward/backward oder nix. und gegen “nix” sollte man was tun.
Gruss
Walter
p.s. mapserver ist schon was feines. 5 Minuten bis zum fertigen Overlay. Hätt ich den vor einem Jahr schon gekannt
