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" (osm.org/relation/934455 für Wiedenzhausen dann evtl. admin_level=9 oder =10?) und auch "postal_code" (osm.org/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:

osm.org/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:

osm.wiki/Key:building:min_level

osm.wiki/Key:building:levels

osm.wiki/Simple_3D_buildings

Viele Grüße,
Toni

Hallo K.-H.,

ich werde das mal korrigieren.

Man kann - auch im iD - eine Straße spalten/teilen (splitten). Ich weiß nicht genau wie das in iD geht, ich nutze nur JOSM.

Ich werde das mal entsprechen ädern.

VG
Toni

Hallo JJ,

ich denke, ein Teil der Einbahstraßen können wieder auf "beide Richtungen" gemapped werden.

- von Osten her kommend kann man doch vermutlich bis zur Kläranlage, zum Parkplatz an der Isar und zur "SG Isarau, Ismaning" fahren?

- von Westen her bis zu den beiden Parkplätzen und wieder zurück?

Für Navis reicht es eh aus, nur die Heckerbrücke als "oneway" zu mappen.

VG
Toni

Hallo Anwohner1,

so weit ich das nun gelesen habe, ist eigentlich doch nur der Kreuzungbereich Richtung Salmdorf betroffen, oder?

Ist denn die Feldkirchener Straße auf der gesamten Länge im Ortsgebiet für Motor-Fahrzeuge aller Art gesperrt, oder nur ein Teil?

Nach der jetzigen Lage kommen ich von Süden her nicht bis an die Weißenfelder Straße, und die ist doch als Umgehung ausgeschildert, oder?
Oder ist die Vaterstettener Straße ganz im Süden als Umgehung gedacht?

Bei motor_vehicle=no auf der geamten Länge dürfen dann auch die Anwohner/Kirchgänger/Friedhofsbesucher nicht rein? Wäre auf einem Teilstück dann motor_vehicle=destination besser?

Für "kurzzeitige" Sperrungen würde ich statt

motor_vehicle=no

lieber

motor_vehicle:conditional=no @ (2019 Jun 29 - 2019 Oct 04)

setzen. Einige Navis verstehen das schon und man ist als Anwender nicht auf einen Update der Daten aufs Navi genau am 4. Oktober angewiesen. Das Problem mit motor_vehicle=no ist, dass diese Einstellung so lange gültig ist, bis das/die Navi(s) wieder mit neuen Daten gefüttert wird (Oktober, November, Dezember, ...).

OsmAnd z.B. holt sich neue Daten meist am 1. eines Monats und bietet sie den Anwendern so ab 10. eines Monats zum Download an. Die Freigabe der Baustelle hier liegt nun genau dazwischen ... und wird für die Anwender wohl erst ab 10. November wirksam sein.
Leider "versteht" OsmAnd "x:conditional" nicht - also irgendwie ist dann beides eine nicht optimale Lösung.

Siehe auch St 2079 zwischen Putzbrunn und "Beim Forstwirt" (bei Harthausen).

Viele Grüße
Toni

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

Hi ManOfSteal,

ich werde die Straße nun wieder als residential mappen.

Ein Blick auf

http://osmtools.de/traffic_signs/?signs=240,1020-30

mit dem dort enthaltenen Hinweis

"Aufgrund von "Anlieger frei" eventuell als highway=residential oder service einzustufen."

hat mich darin bestärkt.

Viele Grüße
Toni

Danke, interessant, was da auf uns zu kommt.

222, 222V, 222W, ...

VG
Toni

Danke.

Ich habe das im OSM-Wiki mal unter

osm.wiki/M%C3%BCnchen/Transportation#Fahrplan.C3.A4nderungen

aufgelistet.

BTW: der MVV hat seine GTFS-Daten und die öffentlichen Fahrplandaten der Regionalbusse freigegeben (ausdrücklich auch für OSM).

osm.wiki/M%C3%BCnchen/Transportation/MVV-GTFS

https://forum.openstreetmap.org/viewtopic.php?id=66772

Viele Grüße
Toni

Servuce landini,

Wow, wenn ich mir den derzeitigen Verlauf des 224ers anschauen, dann wird der ab Dezember einen ganz schönen Umweg machen müsssen. Oder wird's doch eher der 227er sein?
Gruß
Toni

Hi ManOfSteal,

as you did not reply to my last mail, I assume there are no objections to what I said. It is common sense for local mappers here to have it as 'residential'.

I will re-tag the Eichendorff-Straße back to residential in the next days, adding an appropriate comment to leave that as 'residential'.

Best regards,
Toni

Hi,

der route_master tauchter in der Analyse von RBO nicht auf, weil 'network=...VLP' gesetzt war, und RBO nicht enthalten ist.

Ich habe nun 'network', 'network:short', 'network:guid', operator' und 'operator:short' angeglichen und überall gesetzt.

VG
Toni

Hallo,

... was lange währt ...

Ich glaube nun stimmts in etwa, oder?

Es erscheint noch ein Punkt, weil "wir" in OSM für "Psychotherapie" noch kein Icon/Bildchen definiert haben. Immerhin: ein Punkt mit dem Namen - das ist besser als noch vor zwei Jahren, da kam nichts.

Bei Fragen, gerne nochmal melden

Viele Grüße
Toni

Hallo Klaus,

'fixme', 'note' usw. sind schlichtweg unter der Kategorie "Fehler" aufgelistet, da sie ja auf Fehler hinweisen sollen.

'network' und so weiter ... viele Dinge sind im PTv2-Proposal als 'optional' oder 'recommended' definiert. Es hat sich aber gezeigt, dass z.B. "Sketch-Line" (Overpass-Tool) einige Dinge als 'mandatory' erwartet um gescheit funktionieren zu können. "Sketch-Line" kennt PTv2 (insbesondere "route_master") nicht, benötigt aber den Wert des 'network'-tags

Insgesamt ist das PTNA Tool an vielen Stellen puristischer als das PTv2-Proposal und macht oft 'optional' und 'recommended' zu 'mandatory', dort wo es Sinn macht und die REdundanz eine gescheite Qualitätssicherung unterstützt.
Ich selber bin kein Fan von 'minimalistischem Mappen' sonder eher von Redundanz.

Das PTv2-Proposal (osm.wiki/w/index.php?title=Proposed_features/Public_Transport&oldid=625726) sagt, dass bei mehr als einer Route-Variante, alle type=route Relationen in einer (Sammel)-Relation type=route_master, route_master=bus (z.B.) zusammengefasst werden sollen.
Z.B.: Bus 6120 osm.org/relation/9748935
den Du ja vor 13 Stunden erfasst hast. Warum der allerdings angemeckert wird, weiß ich grad' nicht, warten wir mal moregan ab.

BTW. bzgl 'source = http://www.vlp-passau.de/fileadmin/user_upload/Linienfahrplaene/Fahrplanaenderung_zum_01.03.2019/6120_beide_99.pdf '
Bitte stelle sicher, dass Du hier kein Copyright verletzt. Wenn der VLP nicht die Erlaubnis gegeben hat, dann dürfen wir die Infos nicht benutzen.

Siehe:

MVV und osm.wiki/Contributors#Bayern

und

osm.wiki/DE:Permissions#ab_2019

Viele Grüße
Toni