Sorry, Tippfehler ...

... Das blockiert auch Fahrzeuge die von der Unteren Domberggasse kommend die Heiliggeistgasse Richtung Ottostraße benutzen wollen ...

Hallo lukfunk.,

Du hast in diesem Changeset einen barrier=bollard mitten auf die Straßenkreuzung Heiliggeistgasse/Sondermüllerweg gesetzt.

Das blockiert auch Fahrzeuge die von der Unteren Domgasse kommend nur die Richtung Ottostraße benutzen wollen - u.A. Ruftaxis, Busse, ...Heiliggeistgasse.

Kann es sein, dass der Bollard nur den Sondermüllerweg betrifft?

Viele Grüße
Toni

Hi,

eventuell analog zu

node/6539410948

und

osm.wiki/DE:Key:healthcare

und

healthcare=physiotherapist

und

osm.wiki/DE:Key:healthcare#Spezialisierung_von_Psychotherapeuten_.28healthcare.3Dpsychotherapist.29

ohne Garantie, aber dann immerhin korrekt in der Datenbank

Gruß
Toni

Hi Manuel,

Du hast auf das gate ...

access=customers
motorcar=yes

gesetzt.

motorcar=yes hebt access=customers wieder auf, d.h. *jeder* darf dort rein, sofern er im Auto sitzt.

Ich hatte das bei anderen Nodes auch schon gesehen

access=customers
bicycle=yes
foot=yes,
motorcar=yes
motor_cycle=yes

auch hier heben die letzten 4 das erste wieder auf (für diese spezielle Zugangsart).
Am Wertstoffhof und hier am Autokino reicht access=customers vollkommen aus und entspricht auch der Realität.

Viele Grüße
Toni

Na, leider nicht. - Sesselmapping, Fehlerkorrektur.

Typos: ... demiloshed:highway=* war wohl auch nicht parallel zu highway=construction gemapped ...

... demolished:highway=* war wohl auch *noch* parallel zu highway=construction gemapped ...

Hi,

die Straße scheint ja noch zu existieren, ist noch nicht vollständig abgetragen ...

Mein Anliegen war aber, die falsche Verwendung von highway= und construction= zu korrigieren, demiloshed:highway=* war wohl auch nicht parallel zu highway=construction gemapped - also nicht ganz konsistent.

Was mir noch nicth klar ist, wie die Anbindung zu "Hochbruck" aussieht.

Die originalen Änderungen stammen von woody-soft, ein Mapper mit bisher 50 Edits.

Gruß
Toni

... oops, da haben sich einige Tippfehler eingeschlichen. Bin noch nicht so ganz warm gelaufen ...

Hallo Xanos,

weißt Du zufällig wie lange die Baustelle/Sperrung bestehen wird.

Wenn es nur wenige Tage/wochen sind, dann werden solche Baustellen nicht gemapped. Das bringt zu viel Ungenauigkeit rein.

Sperreungen im Allgemeinen werfdden auch nicht mittels access=no oder so gemapped, sondern entweder mit

access:conditional = no @ (2019 Aug 12-2019 Sep 06)

oder

temporary:access = no @ (2019 Aug 12-2019 Sep 06)

wobei ich die erste Variante bevorzuge, da sie eine spezielle Form von

xxx:conditional = yyy (zzz)

ist.

Hintergrund meiner Mail: die Standardkarte mag solche Sperrungen innerhalb von wenigen Minuten anzeigen (außer osm.wiki/Tag:lanes=). Navis bekommen diese Änderungen u.A. nur einmal im Monat mit und dann bleiben Sperrungen bis zum nächsten Update wirksam. OsmAnd z.b. zieht die Daten von OSM am 1. jeden Monats ab und stellt sie den Smartphones am 6.-10. des Monats zur Verfügung. Eine Sperre, die am 3.09. aufgehoben und in OSM entfernt wird würde in OsmAnd auf den Handies dann bis zum 6.10. oder 10.10. wirksam sein (sofern denn der Besitzer regelmäßig Updates der Daten runterläd). Anderen auf OSM basierenden Navis machen das nicht anders.

Daher ist es besser, Sperrungen mit access:conditional und einem Zeitraum anzugeben.

OsmAnd beherrscht das mittlerweile.

Viele Grüße
Toni

Hallo Marco,

tut mir auch echt leid. Ich hatte noch gehofft, dass meine Mail dich nach den ersten Edits erreicht, bevor du massenhaft änderst. Oder, dass du die Meldungen als Blödsinn abtust und dich bei mir beschwerst.

Ich hatte noch versucht die Änderung auf meinem PC zu testen, bevor ich es in die freie Wildbahn lasse, aber "Too many requests" vom Overpass-Server haben das immer wieder verhindert.

Sorry nochmals und viele Grüße
Toni

Hallo Marco,

ich habe PTNA noch korrigiert.

Bei bestimmten barrier=* ist bus=yes oder psv=yes nicht notwendig - u.A. toll_boot, border_control, height_restrictor, ...
Die meisten davon hatte ich nicht im Blick und sind mir erst heute morgen beim Anschauen der nächtlichen Analysen aufgefallen.

Die neue Auswertung lief grade eben.

Siehe auch: https://forum.openstreetmap.org/viewtopic.php?pid=758648#p758648

Viele Grüße
Toni

Hallo oberleg,

willkommen bei OSM.

Ich hätte da eine Anmerkung zu den drei Häusern:

- Sattler Huber

- Haus Laubmeier

- Haus Wolfgang Koller

Aus Datenschutzgründen und auch sonst ist es in OSM nicht erwünscht, die Adressen von Privatpersonen zu mappen.
Die Angaben sollten dann deshalb gelöscht werden.

Sollte es sich jedoch um Geschäfte, Firmen, ... oder dergleichen von Allgemeinintersse handeln, so würde ich hier noch den Typ des Geschäftes, ... mappen.

Siehe auch:

osm.wiki/DE:Map_Features#Gesch.C3.A4fte

osm.wiki/DE:Map_Features#Handwerk

osm.wiki/DE:Map_Features#Amt_.2F_B.C3.BCro_.2F_Dienststelle_.2F_Gesch.C3.A4ftsstelle

und so weiter.

Viele Grüße und viel Spaß noch
Toni

Servus Rainer,

könntest Du bitte folgendes in die Quelle/Source (2. Zeile beim Upload-Dialog" aufnehmen? Das ist das, was der MVV sich wünscht.

"Münchner Verkehrs- und Tarifverbund GmbH (MVV); GTFS vom 26.03.2019"

Vielen Dank und bis Mittwoch beim Stammtisch
Toni

Ham mallok,

weißt du zufällig, wie lange diese Sperrung und auch die am Autobahnring Abfahrt Aschheim dauern wird? Monate, Wochen, ...?

VG
Toni

Hi,

hmm,

> An dieser Stelle gibt es immer Probleme, da Punkte von Nominatim & Co in falsche Relationen gesetzt werden.

Aber ist das nicht "mapping for nominatm & co"?

Soll heißen, Nominatim & Co. haben manchmal Probleme mit Zuordnungen.
Aber woran liegen deren Probleme und kann man diese in Nominatim & Co. lösen statt die OSM-Daten solange zu verändern bis das gewünschte Ergebnis rauskommt?

Optimal ist die Doppelnennung des Namens mit doppeltem place= nämlich auch nicht, zumal das landuse nicht die tatsächliche Ausdehnung des Orten wiederspiegelt (was ich als Fehler sehe).

Beim Ort Walchensee gehören die landuses süd-westlich und nord-östlich des von dir mit name=Walchensee versehenen landuse, sowie die Häuser entlang des Sees auch zum Ort Walchensee. Deren landuse haben aber kein name= (was ich als groben Fehler halten würde, 4 * name=Walchensee am landuse?).

Warum leifert Nominatim für "Am Silbertsgraben" korrekterweise
"Am Silbertsgraben, Walchensee, Kochel am See, Kochel am See (VGem), Landkreis Bad Tölz-Wolfratshausen, Oberbayern, Bayern, 82432, Deutschland"?

Viele Grüße
Toni

Hi,

Danke, das hört sich bzgl. Flurkarte gut an, obwohl ich kein Rechtsexperte bin.

Ich denke, der BayernViewer ist tabu, da er/die Daten vom Bayerischen Landesvermessungsamt kommt/kommen.

Wie gesagt, das Vermessungsamt ist da ziemlich penibel und die Data Working Group (DWG) von OSM ist schon mehrfach aktiv geworden und hat entsprechende Edits reverted.
Scheint mir auch so, dass die DWG Changeset-Comments wie diesen hier nach entsprechenden Stichwörtern scanned.

VG
Toni

Hallo flupflip,

du verweist recht häufig auf die "Flurkarte".

Welche ist das und unter welcher Lizenz dürfen wir die Daten aus der "Flurkarte" in OSM verwenden.

Wenn das der Bayernatlas (bayernatlas.de) ist, so ist uns die Verwendung der Daten ausdrücklich untersagt. Wir (OSM) hatten diesbezüglich schon Stress mit dem Bayerischen Landesvermessungsamt.

OSM darf lediglich die "Bayern (80 cm)" Luftbilder als Hintergrund zum Mappen verwenden - mehr nicht!

Hausnummern gemäß Bayernatlas sind also tabu und falls deine Edits darauf basieren, müssen die Informationen wieder gelöscht/rückgängig gemacht werden.

Viele Grüße
Toni

Hallo floempi,

die Diskussionen im Forum und auf den Mailinglisten gehen eher in die andere Richtung. Die überwiegende Anzahl solchcher Namen hängen an einem Punkt (node) mit place= und nicht an einer area.

Das "landuse=residential" definiert nicht den Bereich einer Gemeinde, sondern den Bereich einer Bebauung mit überwiegend Wohnungen.

Von daher wird name=Wiedenzhausen an diesem "landuse" als falsch betrachte, denn der Ort/der Ortsteil/die Gemarkung mit Namen "Wiedenzhausen" ist sicherlich größer.
Dazu gibt es dann wiederum andere Mechanismen wie "boundary" (relation/934455 für Wiedenzhausen dann evtl. admin_level=9 oder =10?) und auch "postal_code" (relation/1099879).

Nur zur Info: "is_in" wird als "deprecated", d.h. als veraltet betrachtet und u.U. in Zukunkt mal automatisiert entfernt.

Viele Grüße
Toni

Danke,

meine Frage ging in die Richtung des Gebäudes zwischen den beinden Brücken :-).

"HSE24 - Gebäude 16" ist wohl keine Brücke, oder?

Und: name="Bridge between 16 and 10" ist wohl nicht der tatsächloche/offizielle Name der Verbindungsbrücke.

osm.wiki/DE:Good_practice#Verwende_das_Name-Tag_nicht.2C_um_Dinge_zu_beschreiben

In diesem Fall wäre 'name' zu löschen, denn dass es eine Brücke ist und die Gebäude 16 und 10 verbindet ergibt sich aus den Tags (man_made=bridge, ...) und der Verknüpfung mit den anderen Gebäuden.

Ansonsten wäre 'name' vorzugsweise in "deutsch" (bzw. Landessprache) zu setzten und wenn in english, dann mit "name:en"

VG
Toni

Hallo maipablikkname,

eine Frage zum Gebäude (?) 16:

way/39775454

Ist das eine Brücke, oder ein Gebäude, welches erst im 1. Stock beginnt, somit auf Stelzen steht, ...?

Ein Gebäude bleibt ein Gebäude, selbst wenn das Erdgeschoss nicht vorhanden ist.

Siehe:

building:min_level=*

building:levels=*

osm.wiki/Simple_3D_buildings

Viele Grüße,
Toni