Mhh, ich wollte ja eigentlich schreiben, dass mir im Raum Berlin/Brandenburg nichts ins Auge gesprungen ist und hauptsächlich opening_hours, phone und ref:navads ergänzt wird. Aber dann bin ich nebenbei noch auf sowas gestoßen. Also eine Tankstelle ist da auf jeden Fall nicht.
Vielleicht ein Office für irgendeine Firma. Ich werde morgen mal nachschauen. Dieses Unternehmen ebenso (Meinecke Mineralölhandel GmbH).
“brand=Blablabla” ist doch wohl hoffentlich ein Testeintrag, der so nicht importiert wird? Auch die Telefonnummer scheint wild eingetippt worden zu sein, auch wenn es die Vorwahl tatsächlich gibt (ON Mittel-Gründau).
@Nakaner: Ähm, habe jetzt erst gesehen, dass man nach einem OAuth Login ja die entsprechenden Datensätze als OK, Don’t Change oder Skippen kann, sollen wir das jetzt “einzeln” tun, oder geht aus diesem Thread eine “Deutschlandweite” Empfehlung raus?
Hier (CH) gilt das meiste bis jetzt gesagte auch, bei den Öffnungszeiten bin ich ziemlich sicher das da ein Durcheinander zwischen Tankstellen-Shops und Öffnungszeiten für die Tankstelle selber herrscht (letzteres ist bei uns fast immer 24/7 mit Automat).
opening_hours sollte nicht importiert werden (oder wenn, dann nur, wenn es bisher nicht gesetzt ist?)
Ansonsten: addr:postcode: hat wenig Sinn ohne weitere Angaben…
Mit ref:navads hab ich eigentlich nicht wirklich ein Problem, solange die die Sachdaten der “Gegendatenbank” frei zugänglich und abfragbar ist, da ja OSM für solche Sachen keinen eigenenen festen ID für Objekte anbietet…
ich bin euch für eure Kommentare und Fehlermeldungen sehr dankbar. Wenn ich die Community vertreten würde, würde ich meine Auflistung der gefundenen Fehler mit folgenden Worten abschließen:
Fühlt sich jemand von diesen Worten nicht ausreichend repräsentiert? Vertritt jemand eine abweichende Meinung und möchte diese kundtun? Verbesserungsvorschläge für diese Zusammenfassung sind ausdrücklich willkommen.
Ich habe damit schon ein Problem. Wir schaffen hier einen Präzedenzfall für die SEO-Branche. Diese Fremdschlüssel sind eine faule [1] Alternative. Klar, man kann damit bei künftigen Aktualisierungsimporten einfache SQL-Abfragen schreiben, aber man verlässt sich darauf, dass einerseits niemand die Fremdschlüssel manipuliert hat und andererseits niemand den Node für etwas anderes verwendet, ref:navads=* aber nicht gelöscht hat. Die fachlich korrektere Alternative ist es, die OSM-Objekt-IDs und Versionsnummern der Tankstellen zu speichern. Wenn das Objekt zwischen dem ersten Import und der ersten Aktualisierung in OSM nicht (signifikant) bearbeitet worden ist, kann man automatisiert die Änderungen anbringen. Wenn das Objekt jedoch verändert worden ist, muss eine manuelle oder komplexere Änderungskonfliktlösung erfolgen. OpenStreetMap – zumindest hierzulande – ist ein Projekt von und für Menschen und kein Bot-Testfeld.
+1, auch für die übrigen Ausführungen von Nakaner.
Die Qualität der von Navads gelieferten Daten ist recht unterschiedlich. Es sind jede Menge falsche oder ungenaue Sachen dabei:
Die Tankstelle an der Raststätte Baden-Baden war früher Total und ist nach der Umgestaltung seit 5 Jahren Esso. Navads behauptet Aral mit falscher Postleitzahl.
In Deutschland ist der Tankstellenbestand bereits recht vollständig so dass gute Vergleichsmöglichkeiten bestehen. Es sollte aber berücksichtigt werden, dass ca. 1/3 der Tankstellen in OSM nicht vorhanden und somit reine Importe sind. Die Qualität dieser Daten ist schwer einzuschätzen:
Diese französische Intermarché-Tankstelle soll mitten im Supermarkt neu angelegt werden, obwohl sie bei OSM 100 Meter weiter südlich an der richtigen Stelle seit 11 Jahren vorhanden ist. Die von Navads angegebenen Öffnungszeiten beziehen sich wohl auf die Anwesenheit des Personals, aber an einigen Zapfsäulen kann mit EC-Karte 24/7 getankt werden, was ich aus eigener Erfahrung weiß.
Wenn man sich die obigen Positionen der von Navads gelieferten Tankstellen anschaut wird das Ausmaß des geplanten Importes deutlich. Daher sollte der Import nicht nur in Deutschland als unerwünscht eingestuft werden.
Tankstellen lassen sich sich auf dem Luftbild noch relativ einfach verifizieren. Aber im Hintergrund hat Navads nochmal die 4-fache Datenmenge (240.000 POIs), die auch irgendwie nach OSM sollen. Die Arbeitszeit der weltweiten Community ist zu Schade, um für kommerzielle Interessen die Spreu vom Weizen zu trennen.
Ist mir auch bei einigen aufgefallen: Die exakte Position des Nodes. In OSM setzen wir (laut Wiki) den Node da hin, wo es den Sprit tatsächlich gibt – also auf den Tankbereich der Tankstelle (z.B. mitten aufs Dach), nicht auf den Ladenraum zum Bezahlen und Brezelnkaufen. Dieser Import scheint den Node häufig auf die zugehörigen Geschäftsgebäude zu verschieben. Was im Fall einer Supermarkttankstelle ziemlich in die Hose gehen kann.
Die Tankstellen, die ich in meinem Umfeld angeschaut habe, hatten hinsichtlich der Daten keine Fehler. Nur die Tankstelle wurde an einer Stelle auf den Shop und nicht auf die Tankspuren gesetzt. Muss ich allerdings noch mal prüfen, ob das nicht auch schon vorher so gewesen sein könnte.
Ich denke dieser Import bringt uns nichts außer zusätzliche Arbeit der Überprüfung. Zumal freie Tankstellen überhaupt nicht berücksichtigt wurden. Das könnte sogar zu Wettbewerbsverzerrungen führen, wenn die Markentankstellen OSM für ihre Darstellung im Web nutzen.
+1 … und Korrektur schräger Positionen. Verbessert wird das Tankstellenmapping in Schland dadurch unterm Strich nicht wesentlich.
Was mich erstaunt, ist http://audit.osmz.ru/browse/navads_fuel/NVDS353_10027146, die in OSM noch fehlt, und das durchaus in meinem mittleren Aktivitätsgebiet. Walter, ist da eine Shell in Holzhausen a.d.H.? Wenn ja, bin ich schon paarmal dran vorbeigefahren, ohne ihre Unmappigkeit zu bemerken. Auf der Shell-Website ist sie auch.
Nach der Begutachtung der Daten und ein wenig Nachdenken stehe ich dem Import in jetziger Form eher ablehnend gegenüber. Nach meinem Beitrag #13 habe ich noch nach dem Zufallsprinzip etwas in Deutschland herumgestochert und bin mehrfach auf unstimmige Öffnungszeiten, Tankstellenmarken und Positionen gestossen. Insofern halte ich die Daten nicht wirklich für einen Gewinn und sehe sie eher als Garant für viel Nacharbeit. Dann lieber selbst mappen…