WikiProject Austria/plan.at/WasTun
Contents |
plan.at, Was Tun ?
Diese Seite soll der Diskussion über den - meiner Meinung nach verunglückten - Datenimport von plan.at dienen, und wie man - nun da er einmal geschehen ist - weiter damit umgehen soll.
Als Einstiegs-Statement platziere ich hier Ausschnitte aus meinen Beitrag zur Mailingliste [talk-at][1].
Re: [Talk-at] plan.at Bereinigung
> Ich hätte einen Vorschlag zur Bereinigung mancher plan.at Probleme in OSM:
Ich auch: Herr Wasserburger soll die Quelldaten veröffentlichen, dann
machen wir die Koordinatentransformation selbst, und dieses Mal richtig!
Dann löschen den ganzen MapSpam und spielen's neu ein, und zwar *mit*
Einbindung der lokalen Mapper!
> Ein weiterer Problemkreis sind die mit dem Ortsnamen beschrifteten
> Feldwege (leider sind's nicht nur Feldwege, sondern auch viele "normale"
> Straßen). Ein Gedanke wäre, zumindest die Feldwege zu sanieren, indem
> man für alle highway=track, die von plan.at importiert sind, generell
> das name= löscht
Löschen? NEIN! (Auch miese Daten sind besser als gar keine)
> (oder in obiges plan.at:name umwandelt).
Das scheint mir sinnvoller.
> Meinungen dazu?
Man sollte jetzt nicht den selben Fehler machen wie WWW. : über alle
Köpfe hinweg zu agieren. Dieselbe Maßnahme, die in einem Gebiet
sinnvoll ist, mag woanders kontraproduktiv sein.
Beispiel: Im Bezirk Innsbruck-Stadt waren 99,5% der plan.at Daten
unnütz, und sind auch recht flott wieder verschwunden. Aber schon in
der Nachbargemeinde Rum war plan.at nützlich, hier hauptsächlich um die
Namen der schon eingezeichneten (und lagerichtigen) Straßen
einzutragen.
Aber genauso kann mir vorstellen, dass plan.at in Gegenden, wo noch
wenige Daten vorhanden sind, der Karte einen satten Aufschwung zu
geben vermag.
IMHO wäre es sinnvoll:
- den plan.at namespace zu nützen für
o Anleitungen zum Umgang mit plan.at
o Angeboten zur automatischen 'Korrektur' der Daten
o Erfahrungsaustausch
PS:
> > ("wir tracken nicht für Renderer")
Ja, schon, aber man muss sich auch gegen MapSpam zur Wehr setzen...
--edit BorisC 21:27, 7 May 2009 (UTC)
Besser schlechtes Material als gar keines?
Manche Mitglieder meinen, schlechtes Material sei besser, als gar keines. Deshalb habe ich mir einige Wege angeschaut, die ich selbst abgefahren bin und die sich jetzt mit vollkommen falschen Mappings durch den missglückten Import-Versuch von Herrn Wasserburger vermischen.
- Völs bei Innsbruck: Hier wurden hunderte von unzusammenhängenden Punkte importiert, die überhaupt keinen Sinn machen. Mit ein bisschen Fantasie könnten die als Straßen gewertet werden, aber der Nachbearbeitungsaufwand ist sicher höher, als wenn man diese Straßen gleich neu mappt. Außerdem ist die Gemeinse Völs ohnehin schon sehr gut erfasst. Meine Meinung: Sämtliche http://plan.at Imports löschen.
- Mühltal zwischen St. Peter und Ellbögen im Wipptal: Hier wurde der Mühltaler Bach von http://plan.at übernommen. Der echte Weg ins Tal liegt stets links vom Bach. Laut neuer Karte kreuzt dieser Weg jetzt aber ständig den Bach, mal liegt er links, mal rechts. Als Wanderer würde es mich sehr irritieren, wenn ein Bach zu meiner Linken wäre, der laut Karte zu meiner Rechten liegen müsste. Da wäre mir lieber, wenn ein solcher Bach auf der Karte erst gar nicht verzeichnet wäre. Auch hier mein Fazit: löschen!
- Voldertal: Der Weg nach Volderwildbad liegt teilweise 50m von dem Weg entfernt, den ich getrackt habe. Manchmal zu weit im Westen, manchmal im Osten. Auch passt die Kurventopologie nicht zu den von mir abgefahrenen Wegen. Ein systematischer Fehler, z.B. bei der Koordinatenumrechnung, kann es also nicht sein, da muss schon das Rohmaterial von http://plan.at fehlerhaft sein. Weniger lustig finde ich eine Kirche, die durch ein Kreuz (als Pfad!) dargestellt wurde.
Das einzige was man aus den http://plan.at Daten übernehmen kann, sind die Gemeinegrenzen. Erstens verwirren falschen Daten keinen Wanderer und zweitens ist hier schlechtes Material immer noch besser als gar keines. Aber für alle anderen Daten, also die die mit dem Auge zu erfassen sind, bin ich der Meinung, dass die Daten von http://plan.at ungesehen gelöscht gerhörten.
--galbum 23:30, 5 April 2009 (UTC)
Alternative
Ich glaube nicht dass es technisch moeglich ist, jetzt noch die Reihenfolge von name:plan.at auf plan.at:name umzustellen. Dies waere von vornherein die bessere Art gewesen (IMHO) - da einige Renderer eben dann eben nicht betroffen gewesen waeren (mkgmap fuer Garmin jedoch genauso).
Ich rendere einige Hybridkarten fuer Garmin Mapsource - dabei muss ich ueber Layer arbeiten. Also z.Bsp. ein Layer nur fuer Tunnel bzw Bruecken, Einer nur fuer Einbahnen - da hier das plan.at Prefix/Suffix dann fehlt - sehe ich viele zusaetzliche Einbahnen und Bruecken zusaetzlich im gerenderten Ergebnis. Andererseits sind dort wo viele Daten schon vorhanden sind die Importe eigentlich schon zu 95% eingearbeitet - selbst wenn kein Mapper sich fuer die Gegend extra gemeldet hat. Die schon auf "fertig" stehenden Bezirke sind sowieso schon bearbeitet.
Mein Vorschlag falls moeglich waere eher dass die Daten noch 2 Monate zur Verfuegung stehen sollen - und danach alle komplett unbearbeiten Objekte rausgeloescht werden.
Insgesamt hat uns der Import ja ordentlich vorangebracht in der Quantitaet und vor allem bei Straßennamen (in den letzten 4 Monaten hat sich der eingearbeitete Datenbestand an Straßen in AUT etwa verdreifacht - und das bei Wetter wo wenige Mapper am GPS-Tracken waren; die noch mit plan.at Suffix bestehenden Daten nicht mitgerechnet.). Das Hauptproblem sehe ich darin dass viele (gerade neue) Mapper nicht wissen was es mit den Daten auf sich hat.
Gut waere bei allen von plan.at Objekten ein Link auf die Import Seite hier gewesen. So haette jeder sofort hier die Seite anlesen koennen und wuesste was er mit den Daten machen soll (also insbesondere dort wo es nur um die Straßennamen und PLZ ging).
Zum Vorwurf die lokalen Mapper sind nicht eingebunden worden. Auf den Treffen in Wien war W.W. anwesend und da wurde der Vorgang so besprochen. Das Gemeinden wie Moedling importiert wurden war nicht so besprochen - ich kann W.W. jedoch verstehen, dass er die Bezirke wo sich etwa 2 Monate lang niemand gemeldet hat dann um weniger Arbeit zu haben - halt auf einmal reingeschoben hat.
--Extremecarver 22:50, 2 April 2009 (UTC)
Technische Machbarkeit - (Antwort auf Extremecarver)
Technisch machbar ist (beinahe) alles! Es ist echt kein Problem, mittels world.osm und ein paar geschickten XPath expressions ein changeset zu erstellen. Auch die Postleitzahlen von den plan.at Daten auf bestehende zu übertragen, wäre machbar (dabei nimmt man aber die fragwürdige Datenbasis von plan.at in Kauf).
Aber das ist genau das, was ich zur Diskussion stellen will: Soll man wirklich alles machen, was technisch möglich ist, und wenn ja, mit welcher Legitimation? Hr. W. hatte die Zustimmung von Mikel Maron, einem Mitglied des Boards der OSM-Foundation, und trotzdem ist alles schief gegangen, was nur schief gehen konnte.
IMHO ist eine Löschung der Daten zu einem bestimmten Zeitpunkt nur begrenzt sinnvoll! Ich hätte es lieber, wenn es die Möglichkeit gäbe, Gebiete öffentlich zur 'Säuberung' vorzumerken, und wenn es keine Einwände gibt, auch die notwendigen Tools zur Verfügung zu stellen. Von ad hoc Ideen á la Wasserburger habe ich zur Zeit ernsthaft die Schnauze voll.
--BorisC 01:06, 3 April 2009 (UTC)
- Gebiet zur Säuberung vormerken => Alle Bezirke, die unter WikiProject_Austria/Import_plan.at#Mit-Mapper als abgeschlossen markiert sind, würden sich dafür eignen. Dort können IMHO die Dateileichen (nicht zusammengeführte plan.at-Daten) raus und ev. auch die Daten in aktiven Daten, etwa die acad-id. --Christian Wirth 06:30, 3 April 2009 (UTC)
Fertig Bearbeiten
Meine Meinung dazu: Was spricht dagegen, die Daten weiter zu bearbeiten? D.h. zu überprüfen ob die Straße schon vorhanden ist, wenn ja die ev. fehlenden Zusatzinfos (Name, PLZ) ergänzen und plan.at-Import löschen, wenn nein den plan.at-Namespace rausgeben und schauen, dass es mit den restlichen Straßen verbunden ist. Dazu ist nicht unbedingt Ortskenntnis notwendig. Und es scheint ja die Meinung vorzuherrschen, dass ungenaue Daten besser als gar keine sind.
Ein durchschnittlicher Bezirk lässt sich so in ein paar Stunden überarbeiten (siehe Steiermark), wenn's viel zu berichtigen gibt soll's halt eine Woche dauern, aber es ist auf jeden Fall ein Abschluss in Sicht. Ich werde das jedenfalls wenn ich Zeit habe so weiter machen, wenn Andere mithelfen wird ganz Österreich bald fertig sein, wahrscheinlich bevor diese Diskussion hier ein Ergebnis bringt. -- A uller 11:14, 3 April 2009 (UTC)
- Einspruch! Ungenaue Daten sind wesentlich schlechter als gar keine!! Einzelne Ausnahmen sind sinnvoll (z.B. Lücken auf wichtigen Verbindungen wegen Routing), gehören aber klar gekennzeichnet (fixme=resurvey)!!! Es ist abgesehen von einer gewissen geilen Freude über Gesamt-Kilometerzahlen in der OSM-Statistik doch völlig sinnlos, bekanntermaßen alte und unkorrekte Daten wie plan.at unverifiziert zu importieren.
- Besonders krass ist das m.E. bei den Tracks: Wo man leicht Vergleiche anstellen kann (z.B. zwischen Stockerau und Tulln), findet man 30-50% Diskrepanzen (abgesehen von Offsets) zwischen plan.at und halbwegs aktuellen Luftbildern. Wenn aber diese Art von Daten ersteinmal drin sind, kümmert sich doch (im Gegensatz zu PKW-befahrenen Straßen, und mit Ausnahme von Radwegen) kein Schwein mehr drum. Es sind so schon genug plan.at Daten übernommen worden, wo der Bearbeiter nichteinmal die bestehenden GPS-Tracks der Gegend zur Kontrolle eingeblendet hat!
- Wir haben noch so viele Lückenschlüsse zu machen, weil plan.at ja auch Riesenlöcher hat(te). Ein weisser Fleck animiert vielleicht einen neuen User, mitzumachen; genügend falsche Daten schrecken einen Ortskundigen eher ab. --QEDquid 14:18, 3 April 2009 (UTC)
- Widerrede! Du hast recht, ungenaue Daten sind schlecht. Wesentlich schlechter jedoch sind sie nur in Bereichen, wo es bereits etwas gibt, woran sie sich messen lassen. Ich plädiere für die selektive Löschung, d.h. es gibt eine Wiki-Seite, wo man Löschungen beantragen kann, und in welchem Ausmaß, dann diskutiert man darüber. Wenn sich eine klare Meinung herauskristallisiert, wird sich auch sicher ein 'Guru' finden, der sie auch umsetzt. --BorisC 22:26, 6 April 2009 (UTC)
- Nur FYI (@QEDquid): alle importierten Daten haben seit dem Import einen Fixme-tag, den zumindest ich nur dann rauslösche, wenn ich die korrekte Lage der Straße anhand von Luftbildern, eigenem Wissen oder GPS-Tracks sicherstellen kann. --Christian Wirth 09:28, 7 April 2009 (UTC)
Update der Statusseite
Ich würde als ersten Schritt anregen, dass alle Beteiligten ein Update der Statusseite machen - wir hätten dann einen Überblick, wo noch was und wieviel zu tun ist. Mir scheint das nicht ganz aktuell zu sein. Danach Aufteilung der Überarbeitung auf Freiwillige (also uns ;-)
Dazu ein Zeichenschlüssel, wie gut der Import abgearbeitet ist (fertige Bezirke sind jetzt z.B. teilweise durchgestrichen).
Und abschließend möchte ich noch eine Lanze für Wolfgang brechen - wer den Import mitverfolgt hat, weiß, was er da an Arbeit reingesteckt hat. Dass das Ergebnis Nacharbeit bedarf, war glaub ich jedem klar, mir scheint es derzeit an "manpower" zu fehlen, um den den Datenstock zurechtzuschleifen. Ich glaube, wir haben uns das zu leicht vorgestellt.
-- Klainkaliber 16:06, 3 April 2009 (UTC)
Straßenende automatisch verbinden
Waere es jemand moeglich Straßenende zu verbinden wenn diese innerhalb von X Metern enden? Leider geistern durch den Import - aber auch sonst abseits der Straßen - sehr sehr viele unverbundene Straßen herum. Wenn der Abstand der Straßenenden kleiner als rund 5m ist, faellt es einem kaum auf der Karte auf - selbst wenn man sehr weit hereinzoom.
Noch schlimmer sind Stellen wo die Nodes der Straßenenden uebereinander aber eben trotzdem nicht verbunden sind. Auch bei Straßenkreuzugen ist dieses Problem haeufig anzutreffen - hier ist es meisten ein Problem von Potlach wo beim verruckeln der Maus (je groeßer die Bildschirmaufloesung umso leichter passierts) die Straßen nicht verbunden werden - und man dies im nachhinein auch nicht erkennen kann. Zumindest beim Verbinden von Straßenenden die innerhalb von 5m Abstand liegen - duerfte man kaum auch in Wirklichkeit nicht von Straße A auf Straße B fahrbare Enden zusammenfuegen. Autorouting ist bei nicht verbundenen Straßen halt quasi unmoeglich (außer man stellt dann hier seitens des Programms eine Toleranz ein - aber so wird man das Problem der nichtverbundenen Straßen erst recht nicht loesen koennen.
--Extremecarver 22:52, 5 April 2009 (UTC)
- im JOSM das Validator-Plugin starten, das prüft (unter anderem) genau das.
- Automatisch verbinden: bitte nicht; das hat zwar gelegenlich funktioniert, meist aber nicht, da die plan.at-Daten ja doch um ein paar Meter zur Realität verschoben waren, und damit einerseits falsche, andererseits irreführende Zick-Zack-Verbindungen erfolgt sind. Mein Argument ist immer noch: manuelles Bereinigen, anstatt jetzt noch großartig (automatisiert) an den Plan.at-Daten herumzupfuschen. In OÖ sind wir fast schon fertig damit. --Christian Wirth 06:04, 6 April 2009 (UTC)
Bitte nicht! In Innsbruck-Umgebung war bzw. ist es an vielen Stellen genau das umgekehrte Problem: Die plan.at Daten sind teilweise willkürlich mit den bestehenden Daten verschnitten (hatten also gemeinsame Knoten. aber nicht an der richtigen Stelle). Dadurch sind sie nur mit großem Aufwand verschiebbar, was aber unerfahren Usern zum Teil nicht auffällt. Allein schon deswegen musste ich selbst in dem Bereich, der vom Import verschont worden ist, vielen Schaden rückgängig machen.
Im Gegenteil, IMHO wäre wünschenswert - wenn man überhaupt den Weg der semiautomatischen Reparatur des Imports gehen möchte - in Bereichen, die noch nicht bis wenig überarbeitet wurden, die plan.at Daten von allen bestehenden Daten abzulösen. Dann könnte man die Straßen an den richtigen Platz schieben (vorausgesetzt es gibt Referenz-Tracks oder gute Yahaoo-images). Und dann die Verknüpfungen einzusetzen, scheint mir doch sehr viel weniger Arbeit zu sein.
Zudem hätte man jetzt ein Kriterium, was man eventuell löschen könnte, nämlich schwebende Elemente.
--BorisC 20:22, 6 April 2009 (UTC)
Bravo, Herr Wasserburger!
Ich bin eigentlich nur ein OSM-User, und zwar ein recht neuer (ich hab' mit vor einem Monat einen Nokia N810 mit GPS gekauft). Jetzt war ich damit eine Woche in Laa an der Thaya auf Wellnessurlaub, vor allem Wandern, und ein Auto-Ausflug nach Tschechien. Die Karten waren in Österreich besser. Am Abend hab' ich dann immer die GPS Tracks hochgeladen, und die Wege korrigiert (ein paar fehlten, andere waren nicht richtig verbunden, einmal war einer "doppelt"). Die Straßen hab' ich auf die GPS Tracks gezogen (es gab auch ein paar fremde). Das entspricht, wie Herrn Wasserburgers Tat, dem Wikipedia-Motto "be bold". Wenn es die Wasserburger-Daten nicht gegeben hätte, hätte die Karte ganz schon leer ausgeschaut! Ich glaube, daß die ungenauen Daten die "Angst vor der weißen Leinwand" so weit senken, daß auch OSM-Dummies wie ich - davon gibt es Millionen in Österreich - die Fehler korrigieren können, während es wahrscheinlich nicht mehr als ein paar hundert Experten geben wird, die wirklich von Null weg "Mappen" können. Mein Vorschlag: einfach abwarten, bis alles manuell korrigiert ist, und eventuell ein gutes Potlach-Handbuch für Dummies schreiben!
--Petersteier 19:50, 10 April 2009 (UTC)
Ich bin grad dabei in einer kleinen Ortschaft Daten zu korrigieren und muss sagen, die Daten sind gar nicht so schlecht. Die Abweichungen lassen sich wahrscheinlich dadurch erklären, dass das Material sehr alt ist und nicht immer mit dem notwendigen Aufwand erhoben wurde. Wenn man aber ortskundig ist, kann man das korrigieren. Man geht halt die Straßen ab, korrigiert die Positionen/Namen/Kreuzungen. Rom wurde auch nicht an einem Tag erbaut! Viel wichtiger wären vernünftige und legale Orthofotos mit denen man viel schneller kontrollieren könnte. Und was ist mit den ganzen Attributen? Soll man die nach der Korrektur löschen? Hab ja mal gelesen, dass das löschen von fremden Attributen ein absolutes "don't" ist. Vielleicht gibts auch Antworten... Mein Senf. HTK 18:58, 15 April 2009 (UTC)
- Najo, Löschen von fremden Keys is nicht nett, wenn du die Keys nicht kennst; Falsche Keys zu löschen kann nicht verboten sein, wenn du dir sicher bist, es besser zu wissen als der erste Autor. Ein "fixme=..." kannst du durchaus löschen, wenn du die gewünschte Verbesserung durchgeführt hast; die plan.at-"acadid" oder falsche Ortsnamen sollten auch niemandem abgehen. Daten wie "source" hingegen würde ich schon drinnen stehen lassen, rein aus Höflichkeit. --Christian Wirth 20:07, 15 April 2009 (UTC)
Das Ausmaß der Verwüstung
Ich hab mir gerade den OSM-Inspector-View (http://tools.geofabrik.de/osmi/?view=plan_at&lon=15.97668&lat=47.99654&zoom=9) genauer angeschaut, nachdem die alte Diskussion auf der Mailingliste gerade wieder aufflammt. Nachfolgend ein Versuch, das ganze ein bißchen zu quantifizieren - evtl. lässt sich daraus dann eine Prioritätenliste ableiten.
- ref=0 - das scheint ein sehr lokal begrenztes Phänomen zu sein, zu sehen im nördlichen Kufstein, den Bezirken Wr. Neustadt und Neunkirchen (ein schöner Bogen um die Steiermark) , sowie im Norden und Norwesten von Wien. Da ref=0 wohl keinen Sinn ergibt, ließe sich das imho zentral löschen.
- Gattungsname wie name=Graben etc. - schön über ganz Österreich verteilt, allerdings nicht besonders häufig. Ist wahrscheinlich mit einer konzertierten Aktion in 2 Tagen aus der Welt geschafft.
- Geister-Waterway - ebenfalls nicht allzu häufig, fällt teilweise mit anderen "water-Tags" zusammen. Local knowledge vorausgesetzt, kombiniert mit Luft- und Satellitenbild, scheint das auch in endlicher Zeit machbar.
- Geister-Landuse - kommt ebenfalls eher selten vor und rührt teilweise vom Versuch, bestimmte Berge zu bezeichnen. Da wäre wohl ein Point-Tag besser(?). Ansonsten benamste Wälder sowie residential areas, die durchaus Nutzen haben könnten. Local knowledge gefragt, aber machbar.
bis hierher war's einfach ;-)
- Geister-Highways - interessanterweise ist hier das Problem sehr ungleich über Österreich verteilt. Während Steiermark, Oberösterreich, Burgenland und Kärnten fast "sauber" sind (mit Ausnahmen), ist Niederösterreich, Tirol und Salzburg stark betroffen. Da hilft wohl nur local knowledge, und es ist ein mühsamer Prozess. Über die Lagerichtigkeit gibt der OSM-Inspector keine Auskunft - wenn die nicht gegeben ist, dann wird's schwierig.
- at:maxspeed - das trifft wohl alle Bundesländer gleichermaßen, anscheinend ist ganz Kärnten Ortsgebiet (war dort nicht mal 160 erlaubt ;-). Jeden Weg einzeln zu überprüfen scheint mir eine Sisyphus-Arbeit, die in den meisten Fällen wohl nur auf's Löschen rausläuft.
- is_in ist gemeinsam mit fixme=check_import defacto nur ein Zeichen, dass der Way importiert wurde, genauso wie plan_at_acad_id, uploaded_by... etc. Vielleicht kann man dem is_in mit plausiblen Gemeindegrenzen beikommen - die gibt es oft schon, sind in der Steiermark, dem Burgenland und in Vorarlberg vollständig (zumindest sehen sie so aus), in den anderen Bundesländern ebenfalls in großen Teilen vorhanden (siehe OSM-Inspector-View "Boundaries"). Das sollte doch für ganz Österreich machbar sein (vielleicht sind die ways schon da, und es fehlen "nur" die Relationen?). Imho würde uns das mehr bringen, als der Versuch, "is_in" auf Vordermann zu bringen. (Klainkaliber 17:34, 2 January 2010 (UTC))
Links
- Statement eines verärgerten 'OSM newbie' (Antwort 1 )
