Nach Überprüfung der Umgebung keine größeren Auffälligkeiten.
JET und alle Freien (Supermarkt etc.) fehlen komplett.
Die Positionen sind gegenüber OSM leicht verschoben, der OSM-Eintrag wird erkannt. Wenn auf eine Positionsverschiebung verzichtet würde, könnte man zufrieden sein.
addr:postcode bei fehlender sonstiger Adresse macht wenig Sinn.
Telefonnummern haben in OSM meist gefehlt, Öffnungszeiten gelegentlich.
Wenn bei Mo-Sa … Su noch Su,PH ergänzt würde, ginge dieser Nachtrag i.O.
Bei OSM steht der Markenname öfter unter name=, der Eintrag unter brand= bei NAVADS scheint mir korrekter, denn das ist kein Eigenname.
Die ref:navads=* sind verzichtbar, wenn nichts öffentlich Auswertbares dahinter steht.
Habe auch ein paar angeschaut. Das PH wird gestrichen, das finde ich problematisch. Einmal gab es eine Änderung der Öffnungszeiten die den Angaben auf der Website widersprach, ansonsten Ergänzungen von Öffnungszeiten was ich für gut halte (wenn sie stimmen). Aber die Position sollte nicht verschoben werden, meistens sind die amenity=fuel-Tags an den Zapfsäulen, anders als nun in dem geplanten Import. Und ref:navads halte ich auch für problematisch, vor allem solange nicht ersichtlich ist was es damit genau auf sich hat und weil es möglicherweise Neulinge davor zurückhält am Tag was zu ändern.
Hier in meiner Gegend (südl. Kreis BB) fallen insbesondere fehlende Tankstellen auf (Freie, Total, HEM, aber auch eine ARAL).
Bei zwei vorhandenen scheint mir einmal die Öffnungszeit 24/7 falsch. https://www.openstreetmap.org/node/4467795790
Hat man sich eigentlich schon irgendwo drauf geeinigt, was bzw. wie denn nun das brand bei diversen Tankstellen auszusehen hat? Explizit geht es mir um diese AVIA Tankstelle die er gerne von brand=AVIA in brand=Avia umsetzen möchte
PS: Ach ja, bei mir in der Gegend, v.a. bei den AVIAs möchte er gerne opening_hours=24/7 setzen, haben die aber definitiv nicht…
Also ich habe jetzt mal über die AVIA Tankstellensuche mal im größerem Umkreis nach den Öffnungszeiten geschaut, Navads ist dort immer der Meinung es wäre 24/7, aber in keinem einzigen Fall konnte mir das die AVIA Tankstellensuche bestätigen.
=> ja, opening_hours sollte wohl definitiv nicht importiert werden.
Ach und noch etwas, was aber jetzt nicht soo tragisch ist, aber trotzdem irgendwie falsch: das Telefonnummernformat passt nicht. Also entweder ich nehme die offizielle internationale Spezifikation her, oder ich richte mich nach nationalen (Vorwahl) Gegebenheiten:
036797 22097 (avia) vs. +49 3679 722097 (navads) <= die 7 der Rufnummer gehört eigentlich zur Vorwahl
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.