Kleine Topokunde. Ich habe die Top 50 CDs und tiefer für alle Länder in fast jeder Version da. Unterschieden wird nach Ausbauzustand, und dass einheitlich nach festen Kriterien, farblich untermalt nach der Verkehsbedeutung, unterteilt in Fern- und Regionalverkehr. Die gesetzliche Klassifizierung ist an jeder Straße eingezeichnet. Regionale Bedeutung und Verkehrsdichte spielen keine Rolle, da man das nicht einheitlich abbilden kann. Letzteres macht eh keinen Sinn. Da müsste ich einige Landstraßen höher als die Autobahn taggen. Denn die Autobahn wird derzeit kaum genutzt. Ist zwar Fakt, aber für den Kartennutzer so wichtig wie ein drittes Ei. Ausbauzustand: Schnellverkehrsstraße, mindestens 4 Fahrstreifen. Klein darin die RiFa Breite und das Deckmaterial, z.B. 2x11A. Also 2 RiFa mit 11m Breite, asphaltiert. Hauptstraße, mindestens 6m Breite. Auch darin klein die genaue Angabe, z.B. 6(8)A. 6m Straßenbreite, 8m Gesamtbreite, asphaltiert. Nebenstraße, mindestens 4m Breite. Angabe, z.B. 4(6)P. 4m Straßenbreite, 6m Gesamtbreite, gepflastert. Hauptweg mit Angabe der Breite. Nebenwege. Befestigt mit durdcgehendem Strich, unbefestigt mit Strichlinie. Fuß- oder Radwege mit feinerer Strichlinie. Gesetzliche Klassifizierung: E, A, B, L und K an jeder Straße. Verkehsbedeutung Fernverkehr rot. Alle Autobahnen, Schnell- und Bundesstraßen. Regionalverkehr gelb. 99% der Landesstraßen. Nur kurze wirklich unbedeutende bleiben weiß. Nach dem letzten Stand (V 5) in meiner Ecke sind die teilweise ohnehin schon abgeschossen, oder stehen kurz davor. International wird in Karten meist nur zwischen Highway, Main, Secondary und Carriage Way unterschieden. Ausbauzustand, Bedeutung usw. spielen keine Rolle. Das Pendant zur Bundesstraße, ist z.B. in Südamerika teilweise ein Feldweg. Mit der Auswertung des ref ist soweit richtig, setzt aber sauberes taggen vorraus. Falsche oder fehlende Angaben führen zu Fehlern. Wir haben hier dutzende Straßen die zwar farblich zum Großteil richtig klassifiziert wurden, aber ohne oder mit falscher ref in der Datenbank abhängen. Nach letzten Check oft seit Potlatch 5 nicht mehr angefasst. Eine Auswertung einzig anhand der Ref, wird also noch lange Zeit kein einigermaßen fehlerfreies Ergebnis liefern. Dafür bräuchte es erstmal eine massive Quallitätsoffensive. Große Teile wurden durch “Fremdmapper” erfasst. Die haben zwar beim durchfahren die Klassifizierung erkannt und anhand der Farbe ausgedrückt, jedoch oft keine weiteren Angaben notiert haben. Rein optisch sind die Netze gut voran gekommen. Im Detail hinkt es es noch arg nach. Lustig wenn dann wieder irgendwer eine annähernde Fertigstellung an die Presse meldet. Quantitativ kann man das mit Bauchschmerzen machen. Quallitativ sehe ich noch sehr viel Arbeit und Zeit. Ein altes Problem besteht weiterhin. Vorfahrts- und Durchgangsstraßen. Eine Wohnstraße die wegen ihrer Vorfahrt mit Tertiary höher eingestuft wurde, könnte in einigen Fällen als Abkürzung fehlinterpretiert interpretiert werden. Zum einen optisch durch Kartenanwender, zum anderen durch die Navisoftware, welche den Gedanken dahinter nicht kennen kann und rein nach der höheren Bedeutung geht. Eine wunderbare Art die Anwohner zu ärgern, wesshalb ich lieber warte, bis man Vorfahrtsregeln unabhängig von Klassifizierungen vergeben kann.
OK, da sind wir uns ja alle grundsätzlich einig: ref-Tag wird für die Nummer benötigt width/lanes wird für den Ausbauzustand benötigt, alternativ highway (fürs Grobe) Daraus ergibt sich doch, dass das highway-Tag eigentlich überflüssig ist. Dann kann man taggen, wie man will, oder? Das ist aber wohl das einzige Tag, das bei jeder Straße zur Anwendung kommt. Und jetzt? Qualitätsoffensive bedeutet, fast alle Straßen anzufassen, oder? Zugegeben ein bisschen schwarz gemalt, aber was fehlt sind ordentlcihe Reglen und nicht 3-4 Seiten mit unterschiedlichen Empfehlungen. Wikipedia machts ja so ähnlich. Es gibt da wirklich noch viel zu tun. Ich habe so ein bisschen die Hoffnung, dass Druck von Außen (“Fremd”-Anwender) hier beschleunigend wirkt. Andererseits aber auch die Befürchtung, dass wegen den beschriebenen “Missständen” Fremdanwender abgeschreckt werden. Und was raten wir jetzt unserem Eingangs-Poster Ersthelfer (und mir 
)?
Sehe ich genau so. Bei der kleinen Topokunde von @Mirko wurde bereits der Einstieg angedeutet, obwohl mir das da doch ein wenig zu hurtig ging. Ich muss mich erst einmal schlau machen über RiFa; 2x11A und dergl. Wenn aber gemeinsam ein Schema erarbeitet werden kann, bei dem sowohl der “Anfänger-Mapper” als auch der “Berufs-Mapper” jeden Schritt nachvollziehbar gestalten kann, so werden die an anderer Stelle genannten negativen Nachahmereffekte umschifft. Jetzt muss nur einer den Stein ins Wasser werfen.
Stein? Das wird wohl ein Felsbrocken. Das geht nur, wenn alle anfassen. Und alle einverstanden sind. Wie gesagt: OPENStreetMap. Ich wäre dabei! Vielleicht sollte ein erfahrener Mapper das Kommando geben, dass alle gleichzeitig anheben (um beim Bild zu bleiben). Aber das ist ein Thema für einen eigenen Threat.
Das klappt aber auch nur dann, wenn denn für vieles endlich mal feste Regeln anstatt dutzender Empfehlungen vorhanden sind. Umso dichter die Datenmenge, umso schwieriger wird das ganze. Die müssen ja nicht endgültig sein. Aber einheitlich. Denn sollte sich das ganze irgendwann doch nochmal sinnvoll ändern, kann man alles schneller identifizieren und größtenteils gleich automatisch lösen. Im Moment kocht jeder sein eigenes Süppchen und das bedeutet Handarbeit. Seit letztem WE versuche ich ja schon in Thüringen so viel wie möglich zu fixen. Alle arbeiten an der gleichen Sache aber jeder Mapper macht doch irgendwie etwas eigenes. Vieles kann ich beheben, nur wird das leider nicht von Dauer sein. Denn ohne feste Vorgaben ist es nur eine Frage der Zeit, bis die alten Fehler auch wieder die neuen sind. Im Moment läuft folgendes. Knapp 1000 Fehlverbindungen wie fehlende Nodes, Tunnel, Brücken Layer, nicht verbundene Straßen oder Straßen die Parkflächen kreuzen sind bereits gefixt. Ref die fälschlicherweise als Name eingetragen wurden sind auch beseitigt. Als nächstes kommen Kreuzungspunkte mit Gewässern. Fehlende Brücken, Durchlässe und Layer, etwa 400 Fehler. 370 Urwälder sind wohl eher Forest, ich bin dran. Landuses mit Layer sind auch nicht wenige vorhanden. Da muss der Layer raus und bei Bedarf ein Multipoly gebildet werden. Nicht immer einfach, da nicht selten einfach eckig gezeichnet wurden und ein genauer gezeichneter Landuse einfach überlappt. Multipolys über 2000 Nodes müssen API 0.6 tauglich werden, also unter max. 2000 Nodes. Die alten true und false werden auf yes bzw. no vereinheitlicht. Fehlverbindungen in Radwegen warten ebenso. Dann ist zwar schon vieles behoben, sauber ist das ganze aber noch lange nicht. Es bleiben viele Fehler die der Ortskundige im Einzellfall überprüfen muss.
Ja, ein Haufen Arbeit! Und Du ackerst und ackerst und dann wird einiges wieder verschlimmbessert. Das Zauberwort heisst auch meiner Meinung nach feste Regeln. Und die werden idealer Weise von den Tools wie JOSM angewendet oder das api weist unpassende Daten ab. Vieles könnte automatisch angepasst/korregiert werden (Drehen der way-Richtung und Anpasssen von left und right etc.). Aber da sind wir noch weit entfernt. Was mir als recht frisches Mitgleid noch unklar ist, wie so etwas angestoßen wird. Wer hat dafür offene Ohren? Es muss ja dann ein Gremium geben, das Regelvorschläge erarbeitet. Diese müssen dann zur Diskussion gestellt werden. Als Ergebnis muss dann eine verbindliche Regel herauskommen, die dann ggf. in Software gegossen wird. Hm… Zur Zeit mappe ich unser Dorf fertig (Bürgersteige etc.) und natürlich die Umgegend (Tracks…). Die “Hauptstraßen” sind soweit schon erfasst (übrigens entgegen meiner obigen Behauptung nicht immer durchgängig! Und Wälder sind auch zum Teil auf layer-5 vergraben). “Fremde” nodes/ways habe ich bisher nur angefasst, wenn ich sowieso damit befasst war. Wie gesagt, ich würde da schon tätig werden (Überarbeitung der vorhandenen Daten, Regeldefinition etc.)
Ja, Junge mach mal … einfach anfangen! Ich als “non-native” habe da so manchmal meine Schwierigkeiten mit den deutschen Sprachregeln, so dass ein Urgermane dieses bestimmt besser kann. Du stehts ja mit der Aufgabe nicht allein da und wirst schnell viele Helfer haben.
Gremium gibts nicht. Einer arbeitet irgendwas aus, stellt es zur Abstimmung, und eine Hand voll die davon weiß stimmt zu oder lehnt ab. Ansonnsten viel Laber hier und Laber da. Was dann letztendlich angenommen wird, muss ja auch noch implementiert werden. Da schleift es ebenso. Siehe z.B. farm vs. farmland. Der Mapper darf dann den Reformstau ausbaden. Für vieles gibts nur Empfehlungen die jeder anders auslegen kann. Das ganze noch durch Wiedersprüche und Fehler innerhalb des Wiki selbst und zwischen Wiki und Editoren bestärkt. Für vieles eigentlich oft gebrauchte gibts gleich garnichts. Jeder denkt sich so seinen quasi Standard aus. Was und wann sich letztendlich durchsetzt… frage die Glaskugel. Das rührt von der Idee her, die Standards finden sich im Prozess selbst, wesshalb man ohne startete. Ansich keine schlechte. Aber man hat eines anscheinend nicht bedacht. Umso mehr Daten da sind und durch fehlende Standards auseinanderlaufen, umso schlechter lässt sich das ganze Pflegen. Die Erfassung und Menge hat das andere überrannt. Irgendwann haben wir zwar jeden Busch in der DB, aber für vieles wird noch immer kein Standard vorhanden sein. Und wenn du offensichtliche Fehler findest, hau rein. Wenn hier jeder auf einen anderen wartet, wird es nie etwas. Mehr als das dich jemand anschreibt kann nicht passieren. Dann schreibst du halt zurück. Am Ende lernt derjenige vielleicht etwas dazu und vermeidet den einen oder anderen Fehler in Zukunft. In der Zwischenzeit habe ich schon wieder alle true und false auf yes und no umgestellt und alle Straßen Klassifizierungen um fehlende/überflüssige Lerrzeichen bereinigt/ergänzt. Im gleichen Zug wurde die korrekte Trennung von mehreren refs mit Semikolon berichtigt. Keine “,”, “/” oder “-” mehr.
Und natürlich von der Idee, dass auf diese Weise ein Gutteil der “Macht” über Standards in den Händen der Anwendungsprogrammierer und Mapper bleibt. Was ebenfalls eine gewisse Berechtigung hat, um die Praktikabilität und Verwertbarkeit sicherzustellen.
Manuell? Wenn ja, dann ist das ein klassisches Beispiel für eine Arbeit, die man eher einer Maschine überlassen sollte. Übrigens halte ich diejenigen Uneinheitlichkeiten in unseren Daten, die eine Software beheben kann, nicht für die eigentlichen Probleme, denn dort gibt es naturgemäß keine Interpretationsprobleme. Und natürlich bleibt noch…
Na, dann gründe doch eins! Wenn dein Gremium sauber dokumentierte, sinnvolle und möglichst nicht zu sehr von der aktuellen Verwendung abweichende Regeln zur Verfügung stellt und das geeignet kommuniziert, kannst du damit durchaus Einfluss nehmen. Ganz ohne offiziellen Auftrag. (Von woher sollte der auch kommen.)
Im Moment ist es doch so. Es wird in der Mailingliste ausdiskutiert. Mal sinnvoll und mal zum Augen rollen. Einer macht daraus ein Proposal. Das liegt dann eine Weile herum und wird dann von 0,03% der Community abgesegnet oder abgelehnt. Zum Teil wird das gleiche später wieder durchgekaut und umgeworfen. Die Datenbank wächst ungeachtet dessen Tag für Tag in alle Richtungen. Ich sagte ja, die Idee ansich ist gut. In der Praxis fährt da aber ein aufblasbares Gummiboot mit ausausgeworfenem Schiffsanker. Du musst die Daten wieder und wieder anfassen. Denn entweder hat es sich wieder jemand anders überlegt, oder es kommt endlich ein lange überfälliger Tag dazu. Zeit in der man anderes erfassen könnte. Ich will hier auch niemanden irgendwelche “Macht” aus der Hand nehmen. Mir geht es um gewisse Grundstandards die einheitlich aussehen und die Pflege erleichtern.
Natürlich nicht per Hand. Per Hand nur das, was kein Script sicher lösen kann. Nur wenn ich warte bis da irgendwer mal irgendwann anfängt, bin ich schwarz. Wenn ich einmal dabei bin, kann ich mich gleich allen bekannten Fehler widmen. Wie schon geschrieben sind die Fehler teilweise schon mit Potlatch 5 enstanden und liegen seither unbeachtet in der DB.
Die Frage nach dem Gremium kam nicht von mir. Habe auch nicht geschrieben das ich eines will. Wenn ich die Diskussion um die S-Bahn in der Liste lese dann gleich garnicht. 
Das Wort Gremium kam von mir! Einfach eins zu gründen? Dann hätten wir noch eins und nichts wäre anders. Jeder, der hier ein proposal erstellt, handelt ja in guter Absicht. Nur häufig interessiert es niemanden.
Nein. Da du aber zutreffend einige existierende Probleme beschrieben hast, bleibt noch die Frage nach Möglichkeiten, etwas an ihnen zu ändern.
Noch eins? Wir haben bisher keins. Ob das gut oder schlecht ist, lass ich gerne dahingestellt.
Ich würde ja gerne sagen das ich etwas in der Schublade hätte, habe ich aber leider auch nicht. Den richtigen Zeitpunkt für einheitliche Grundstandards hat man eigentlich schon verpasst. Das hätte man ganz zu anfang festlegen müssen. Es hätte ja nicht super detailiert sein müssen, aber einheitlich verbindlich. Zu spät. Über einen Punkt wird wenigstens schonmal nachgedacht. Das ist die Kommunikation. Wenn bereits die Ausarbeitungsphase in der Breite bekannt wird, kann man nur gewinnen. Wenn das funktioniert, dann könnte es schonmal Paralelentwicklungen zum gleichen Thema eindämmen und durch mehr Regionalwissen die eine oder andere Unzulänglichkeit gleich bei der Ausarbeitung beseitigt werden. Wer wichtige Einwände hat, kann das gleich in der Ausarbeitung mit einbringen, nicht erst im zufällig gefundenem Proposal. Wird das Proposal weit bekannt, könnte die Abstimmung schonmal beschleunigt werden. Proposal → sofortiger Aufruf an die Community → z.B. 2 Wochen Frist oder 100 Stimmen Mindestbeteiligung → Entscheidung. Ein weiterer Punkt wäre eine lange überfällige Qualli Offensive im Wiki. Wir brauchen da zwar keine Mod Auswüchse wie bei Wikipedia, aber einen oder zwei, die ein Auge auf die Konsitenz haben und vernachlässigten Artikel auch mal auf die Beine helfen. So wie bisher scheint das nicht zu funktionieren. Das muss immer aktuell sein und muss in sich und zusammen mit den Editoren passen. Noch ein Punkt wären die “kann so, muss aber nicht” Entwicklungen. Eines geht nur, klar abgegrenzter verbindlicher Standard oder unverbindliche Empfehlung, wobei ersteres klar Vorfahrt haben sollte und letzteres wirklich nur bei absolut unklaren Notfällen angewendet werden sollte. Zuviel Spielraum bedeutet Wildwuchs. Siehe hier das Urpsrungsthema. Das verleitet jeden zu subjektiven uneinheitlichen Entscheidungen. Da wäre z.B. der Punkt Bedeutung. Da kann man sich ruhig an der Topo orientieren. Fernverkehr/Regionalverkehr. Es interessiert keinen, ob die Landstraße K 367 die wichtigste Verbindung zu irgendeinem Nest ist. Entscheidend ist die Bedeutung im Regionalen Netz. In Erfurt haben wir auch eine als Schnellstraße ausgeführte Landstraße. Die gehört in Verbindung mit der A 71 zum Ring. Regional bedeutet hier bei Landestraßen das Netz des jeweiligen Landes, bei Kreisstraßen das Netz des Landkreises. Und so kann es schonmal sein, dass die persönlich wichtige und als Secondary getaggte Stichstraße K 367, in Wirklichkeit ganz hinten steht, analog in der Topo keine Farbe besitzt. Entsprechend klar muss das ganze auch hier definiert sein.
Wobei man trotzdem eine RFC-Frist beibehalten sollte, während einer Abstimmung sollte man schließlich nichts mehr ändern.
Das würde erheblich erleichtert, wenn wir im Wiki die “Semantic Media Wiki”-Technologie zur Verfügung hätten (diskutiert an den unterschiedlichsten Stellen, unter anderem hier, sporadisch auf verschiedenen ML usw. 
. Dann könnte man nämlich erstens Listen, Tabellen, verschiedene Sprachversionen etc. automatisch synchron halten und zweitens die Informationen aus dem Wiki maschinenlesbar exportieren (=> verwendbar in Editoren, Validatoren usw.). So wie es jetzt ist, macht so was zu viel Aufwand. Ich würde mehr Arbeit ins Wiki stecken, wenn man geeignete Werkzeuge hätte, um Aussicht auf Erfolg zu haben. Ich habe kürzlich erst wieder die Elementtypen auf Map Features mit denen auf den Detailbeschreibungsseiten abgeglichen. Das wird aber nicht lange vorhalten, weil schon wieder Leute anfangen, Änderungen nur an einer Stelle vorzunehmen. Das muss daher automatisch passieren. Haupteinwand gegen ein SMW sind momentan anscheinend die Performanceeinbußen im ohnehin schon langsamen Wiki. Kaum zu glauben, dass wir uns nicht mal einen besseren Wiki-Server leisten können als das da…
Das ist kein Einwand, das ist trauriger Fakt. Eine Lösung benötigt es so oder so. Ich habe eine 6000er Leitung und warte trotzdem oftmals mehr als eine Minute, oder immer öfter auch vergebens. Man kann förmlich zuschauen wie die Möre Woche für Woche spürbar immer schneller unter immer mehr Aufrufen zusammenklappt. Bevor es zum Stillstand kommt, muss sowieso eine bessere Lösung her. Und wenn es soweit ist, spricht auch nichts degegen, in einem Rutsch auch gleich die Software umzustellen. Bisher habe ich nur einmal vor grauer Vorzeit ein Wiki umgestellt. Ich glaube mich zu erinnern, das SMW irgendwo eine recht brauchbare Importfunktion hatte. Das ging zumindestens damals fehlerfrei und schnell über die Bühne. Also nicht darüber diskutieren wie sich das SMW auf die derzeitige Möre auswirkt, sondern gleich an die zuständigen Leute treten und auf das ganze Problem hinweisen. Die Software ist letztendlich egal, das Problem ist der schleifende Taschenrechner auf dem das ganze läuft. Der geht auch mit dem jetzigen Wiki absehbar krachen.