Hallo redd,
sorry für die Verzögerung, ich war auf Reisen,
.
>uellenangabe ist im OSM Wiki hier dokumentiert: source=*#Specific_values

OK, das ist aber doch der key "source" und nicht der Hochlade-Kommentar von JOSM. Ich finde das nicht plausibel:

* Ein user mappt ein Gebaude nach BING Luftbild, "source" = "Bing"
* Dann ergänze ich addr:street mit extrapolation als source oder JOSM-Kommentar?

Hallo Redd,

Danke für die Nachricht:
> "eigene Recherche" ist keine korrekte Quellenangabe.

Gibt es eine Liste empfohlener Quellen bzw. Quellen-Texte? Gerne werde ich mich daran halten.

Im vorliegenden Fall ist die einzige Quelle OSM selbst: Ich habe den Ortsnamen und das PLZ-Gebiet abgefragt und auf unvollständige Adress-Daten geprüft. Dabei finde ich z.B. Hausnummern ohne Straßenname, fehlende PLZ-Werte, Garagen mit Hausnummer changeset/175097518#map=19/48.740818/11.601390 etc. Das korrigiere oder ergänze ich; den Straßennamen finde ich z.B. im JOSM-Download.

Ich hoffe, damit ist Einiges erklärt.

Viele Grüße, Michael

Danke für den Hinweis, ich habe den Änderungssatz 174091965 revertiert.

Auslöser der Änderung war, dass JOSM einen Fehler wegen doppelter Hausnummern bemängelt hat. Beim Ansehen der Gebäude und Straßen erschien mir die Änderung logisch.

Hmm, ich habe von der Seite
https://www.electronic-center.ch/
diese Nummer:
Tel. 041 711 91 81
International also:
+41 41 7119181

Und das ist doch hier
node/5998503700
eingetragen ...

Ratlose Grüße
Michael

Hallo,

Danke, hatte die Nummer im www recherchiert. Inzwisvchen hat ein anderer User das auf "moblie" geändert. Falls noch etwas fehlt, gib mir bitte Bescheid..

Hallo,
Danke für den Hinweis; ich bitte um Entschuldigung für den Fehler; natürlich ist Buckenhof eine eigene Gemeinde https://de.wikipedia.org/wiki/Buckenhof?uselang=de und soll meines Erachtens als Wert in addr:city stehen.
Ich habe die beiden Changesets revertiert.
Ursache des Fehlers ist, dass Overpass für area["name"="Erlangen"] auch Buckenhof ausliefert:
https://overpass-turbo.eu/s/2dp5
Der Grund dafür ist mir schleierhaft. Ich fände es gut, wenn Du im Forum https://community.openstreetmap.org/c/communities/de/56 danach fragst; mir fehlt die Ortskenntnis, um etwaige Rückfragen dort beantworten zu können. Hinterlasse mir aber gerne hier die URL zu einem Posting dort.
Gruß
Michael

Hallo,

Willkommen bei OpenStreetMap und Danke für den Eintrag!
Ich habe noch die Telefonnummer auf das hier übliche Format geändert (siehe 8167 / 950087) und ein Detail hinzugefügt.

Für Fragen stehe ich gerne zur Verfügung.

Danke und viel Spaß noch mit OpenStreetMap.

Viele Grüße
Michael

Hallo Claudia,
Danke für den Hinweis - ja natürlich, der Ländercode war ein Tippfehler. Ich habe alle nach "DE" berichtigt.
Viele Grüße
Michael

Hallo Klaus,
danke für den Hinweis, jetzt sehe ich es auch.
Ist geändert!
Ich bitte um Entschuldigung für den Fehler.
Gruß
Michael

Danke Klaus,

habe es revertiert.

Gruß
Michael

Danke; ich wünsche Dir viel Erfolg!

Danke Dir!

Danke, das Problem ist dass die Gebäude auf der Grenze liegen, siehe
way/1174592897#map=17/48.106400/11.761072

Das kann eigentlich nicht sein, vielleicht ist das Grenzpolygon falsch?

Ich habe addr:city etc. geändert.

Hallo flo2154,

Danke für die Nachricht. Ich habe das in JOSM mit Luftbild angeschaut und vermute, dass die Trennung zwischen Gebäude und Garage nicht korrekt ist. Nach Luftbild mit BING wäre der nördliche "Wurmfortsatz" die Garage, das südliche Polygon das Wohnhaus.

Örtlich prüfen kann ich das zur Zeit nicht, habe aber erst mal die "17" hinzugefügt; das erscheint mir richtiger als alles andere ...

Hallo flo2154,

sorry für die Verzögerung, war durch technische Gründe einige Tage offline.

Sicher bin ich nicht, aber diese Seiten sagen mir, dass eher meine Zuordnung korrekt ist:

way/124228863#map=15/48.10064/11.77552

https://de.wikipedia.org/wiki/Grasbrunn#Neukeferloh

Was denkst Du?

Bitte beachte auch die Häufigkeit der keys:
https://taginfo.openstreetmap.org/keys/compressed_air%3Acharge#overview
versus
https://taginfo.openstreetmap.org/search?q=compressed_air%3Afee
Das war der Grund, dass ich die "Bereinigung" eingetragen habe ...
Vielleicht ist ein Kompromiss, im Wiki
„compressed_air:fee=<yes/no/value currency> zu dokumentieren?

M.E. kann das nur jemand beantworten, der die Tags nutzt (auswertet). Beide sind natürlich möglich. aber vollkommen redundant: Mit „compressed_air:charge=0.50” ist klar, dass „compressed_air:fee=yes” ist.
Wenn ich jetzt in einer Region POIs mit kostenloser Druckluft-Bereitstellung suche, müsste ich
„compressed_air:fee=no”
OR
„compressed_air:charge=0.00”
OR NOTexist „compressed_air:charge"
abfragen. Ich finde das extrem umständlich, vor allem müssten dem Fragesteller alle keys bekannt sein, denn man kann nicht unterstellen, dass _immer_ beide keys gesetzt werden.

Ja. Wäre es für Dich OK, die nach Deiner Meinung richtigen Tags zu setzen und ggf. compressed_air:fee zu löschen? Ich werde mich in Zukunft an diesen keys nicht mehr arbeiten ...

Hallo mcliquid, habe es gemäß https://community.openstreetmap.org/t/idee-wochenaufgabe-tankstellen/131367/18 angeglichen und compressed_air:fee=yes gesetzt. War das verkehrt?

Hallo ShardikFanatic,

Danke für Deine Mitarbeit bei OpenStreetMap. Nach Deinem Hinweis
note/4784201#map=15/48.42668/11.65834
habe ich den Eintrag von "shop" auf "amenity = "vending_machine" geändert. Falls es auch ein Ladengeschäft gibt (das nicht 24/7 geöffnet ist) können wir einen weiteren Punkt setzen. Den Hinweis können wir dann auf "erledigt" setzen.

Weiterhin viel Freude hier; melde Dich gerne, falls es Fragen gibt.

Gruß, Michael