> fix for proper official name by Official change of German Foreign Ministry
for official name by official change of German Foreign Ministry you shoud use: official_name:de=Kyjiw

> and all of then will use new name
Leading German news portals and daily newspapers continue to use the spelling "Kiew" instead of "Kyjiw" even after the official change by the Foreign Ministry. The official change by the Foreign Office consequently only applies to official federal authorities.
We understand your wish for a change and correct spelling. But OSM does not reflect wishes but facts. "Kiew" is the common usage in Germany. Changes take time. For some names of Ukrainian cities this was quicker, others, such as Kiev and Odessa in particular, will probably take longer.
Which name or spelling in name:xyz belongs to native speakers of the language XYZ, not native ABC-speakers and not native KLM-speakers!

Hallo ADAC,
die Schreibweise von Kiew/Kyjiw ist in OSM genauso stark diskutiert wie auf Wikipedia.
Die Bundesregierung via Auswärtiges Amt kann die Schreibweise für Bundesbehörden und Regierungsstellen vorschreiben. OSM bildet jedoch in name:de nicht begriffsbildend gewünschte Namen, sonder deskriptiv den in der deutschen Sprache gebräuchlichen Namen ab. Hierfür gibt es durchaus auch verifizierbare Quellen (auf die auch Wikipedia Bezug nimmt). Der gebräuchliche Name (und Schreibweise) ist derzeit noch "Kiew". Für "Kyjiw" kann gern official_name:de genutzt werden.
Hinweis: das AA benutzt offiziell auch noch den Namen Pressburg, die slovakische Hauptstadt ist in OSM jedoch bereits mit dem gebräuchlicheren Namen name:de=Bratislava getaggt.
Die weitere Diskussion bitte im Forum führen
Zur aktuellen Diskussion: https://community.openstreetmap.org/t/name-de-kyjiw-oder-wie/109713/74

Hallo Anonymus 1715, an der größe der meadow würd ich mich nicht stören. Aber wenn Du es schon so detailliert machst, dann würde ich mir sorgfältigeres Arbeiten wünschen:
- keine Überlappungen von benachbarten landuses
- wenn meadow entlang eines Zaunes und mit diesem verbunden, dann bitte auch jeden Punkt vom Zaun mitnehmen (Tipp: Taste F folgt einer bereits vorhandenen Linie)
- Keine Flächen mit angrenzenden Straßen und Wegen "verkleben" (es sind bei Dir nur einzelne Punkte was auf unsauberes Arbeiten hindeutet)

Zur Genauigkeit der Gebäude beim oben verlinkte 15-Eck (ok, es hat nur 14 Ecken): nach meiner Einschätzung der zur Verfügung stehenden Luftbilder hast Du an der Südseite nun Terrassenfläche und eine ausgefahrene Markise in den Gebäudeumriss einbezogen - auch hier bitte sorgfältiger arbeiten und nicht einfach alles vom Luftbild abpinseln.
- wenn man dabei ist auch überlegen, ob die Ecken wirklich schiefwinklich sind oder ob man diese rechtwinklig macht - Tipp: Taste Q - entweder auf den gesamten Gebäudeumriss anwenden oder einzelne Ecken auswählen.
- Dieses Gebäude: way/143309946 ist für mich schwer vorstellbar, dass dieses 6 Ecken hat. Die Ecken am Dachfirst entstehen möglicherweise nur durch leichte perspektivische Verzerrung, oder nur das Dach hat diese seckseckige Form. Gebäudeumrisse sollten sich aber nicht am Dach, sondern am Grundriss orientieren. Und gerade in diesen Gegenden haben die Gebäude meist sehr ausladende Dächer, die deutlich über den Grundriss hinausgehen.

Ich halte Dir zugute, dass Du neu bist. Wir alle haben irgendwann mal angefangen und teilweise die gleichen Fehler gemacht. Nimm Dir bitte Ratschläge zu Herzen, die andere Mapper Dir geben werden.

Zum zusammenhängenden Waldgebiet: das in einem CS-Kommentar zu beantworten würde etwas den Rahmen sprengen. Da müssten wir uns besser ein anderes Medium suchen.
- ich stehe mit MP nicht unbedingt auf dem Kriegsfuß, vermeide und reduziere sie aber, wo es geht
- MP sind im Datenmodell von OSM erst sehr viel später implementiert worden um vorallem das Problem von inneren und äußeren Flächen zu lösen. Datentechnisch eine sehr saubere Lösung und damit kann man noch viel mehr machen (aus rein nerdiger IT-Sicht betrachtet finde ich das toll).
- Das System von Beziehungen von Daten zu verstehen kann sehr schnell sehr komplex werden. Die Beziehnung, was ist innen und was ist außen, ist da noch am einfachsten nachvollziehbar (und vorallem dafür waren MP gedacht). Komplexe MP-Relationen werden aber vorallem von Anfängern nicht verstanden, von einigen Editoren mehr schlecht als recht unterstützt (allen voran iD - aber der ist in den letzten paar Jahren auch deutlich besser geworden). OSM braucht ständig neue Mapper, Anfänger. Deshalb ist das KISS-Prinzip wichtig: Keep it simple, stupid. Damit auch nachfolgende Mapper zurechtkommen und beitragen können. Ich habe schon MPs gesehen, die seit zig Jahren nicht mehr angefasst wurden, obwohl dringend notwendig.
- die Komplexität steigt mit folgenden Punkten:
+ viele inner
+ mehrere bis viele outer
+ Mehrfachnutzung der outer für aneinandergrenzende Flächen (das bedeutet meist noch mehr Zerstückelung und noch mehr outer)
+ Mehrfachnutzung von highway=* als outer angrenzender landuse-Flächen (das ist noch schlimmer, als landuse mit highway zu verkleben)
- letztlich eine technische Grenze: ein Objekt in OSM sollte nicht mehr als 2000 Knoten haben. Diese Grenze wird mit zunehmendem Detailmapping bei großen Waldpolygonen schnell erreicht. Deshalb trenne (zersäbel) ich große Wald-MP gern in kleinere Stückchen und nutze hierfür möglichst sinnvolle "logische" Stellen: breite Straßen sowieso, aber auch breite gut ausgebaute Waldwege ("Waldautobahnen") wie hier den Katzenbronnweg (ich bin ihn zuvor abgefahren, der teilt den Wald gut sichtbar) aber auch Schneisen von Stromtrassen und Pipelines.
- Alternativen zu dieser Aufteilung: entweder man verwendet mehrere outer, wenn man an die 2000er-Grenze herankommt (dann hat man wieder die Probleme der MP-Relationen) oder man teilt den Wald an nicht nachvollziehbaren Stellen quer durch mit einer willkürlichen geraden Linie. Spart auch eine Menge Knoten, ist aber ansonsten völlig unlogisch.

Sodele, reicht erst mal.

Hallo welzheimerwald,
naja, die ganzen Schutzgebiete sind ne eigene Klasse in OSM und überschneiden sich nur teilweise mit den Streuobstwiesen. Dass es Streuobstwiesen sind ergibt sich aus dem Tagging, dass sie in Urbach liegen aus den Geodaten. Für mich wäre das auch eine Relation, die man auflösen kann.

Hallo welzheimerwald,
ich dachte auch, dass da kein Schild steht. foot=no hat man aber gern genommen, um Fußgängerrouter auf den Nebenweg zu "zwingen". Gibt grad auch ne Diskussion im Forum: https://community.openstreetmap.org/t/qs-ausgiebiges-foot-no-tagging/106342
Bessere Lösung habe ich auch nicht, außer es wieder zu entfernen. Gute Router sollten für Fußgänger automatisch den Weg daneben bevorzugen. foot=no kann aber das Fußgängerrouting auch wieder kaputt machen.
Aber wie würdest Du esheute machen?

Die trapezförmige Lücke ist vermutlich durch einen Fehler bei der Bearbeitung entstanden. Habe sie wieder geschlossen.

@welzheimerwald ergänzend: bis vor kurzem war maps4bw.de noch als lizenzrechtlich zulässige Quelle explizit vom LGL für die Nutzung durch OSM freigegeben, bis zu seiner Abschaltung. Das war hervorragend, um dieLagegenauigkeit an Markanten Gebäudeumringen auszurichten. Die Gemeindegrenzen waren allerdings schon recht grob generalisiert und lagen schon mal etliche Meter daneben.

Hallo welzheimerwald,

gibt es einen Grund, dass Du sämtliche Streuobstwiesen von Urbach in einer Relation zusammenfasst? Ist das notwendig

Hallo ticki_52,
danke für Deine Antwort. Allerdings muss ich Dir widersprechen. Unsegmentierte Kreisverkehre sind kein "wildes Mapping", schon gar nicht falsches Mapping, sondern Standard. Das, was Du zitierst, hast Du leider falsch verstanden. Es ist zugegebenermaßen missinterpretierbar geschrieben, aber "jede Straße" bezieht sich auf die einmündenden bzw. abgehenden Straßen. Dazwischen muss immer ein Kreissegment liegen, aber ein Kreissegment zwischen zwei Punkten auf einem Kreis bleibt auch dann ein Kreissegment, wenn der Kreis ein geschlossener, also nicht segmentierter Kreis ist.
Zudem steht nirgends, dass ein roundabout ein einzelne Kreissegmente zerlegt werden MUSS.
Das englische Wiki beschreibt dies detaillierter und bebildert:
junction=roundabout
Konkret: "Note that route relation such as bus relations are added sometimes with entire roundabout without splitting it, that is also fine but splitting it is also fine and there is no consensus which is preferable.
Und zu den verbundenen Wegen und den Segmenten dazwischen:
Do not directly connect approaching with departing roads.

Roundabout with correct connections
Each way which intersects with the roundabout should be connected to it with a separate node. Two ways which enter and exit a roundabout should never connect to the same node on the roundabout. This is required to allow routing applications and software to provide correct directions, otherwise the routing software will not correctly recognise the roundabout. With a segment of the roundabout between the entrance and exit, routers can safely recognise that a section of the roundabout has to be driven through.
Das passende Bild dazu:
osm.wiki/w/images/3/34/Roundabout_Connecting_Roads.png

Hallo welzheimerwald,
worin begründet sich denn das foot=no? Steht da ein Schild, dass Fußgänger verboten sind?

Hallo autinerd,
hier ebenfalls: worauf basiert die Annahme, dass hier Fußgänger verboten sind? Es gibt kein Schild

Hallo autinerd,

worauf basiert die Annahme, dass die Waiblinger Str. hier für Fußgänger verboten ist? Ich kenne kein entsprechendes Schild.

hallo welzheimerwald,
ich möchte Dich nochmals bitten, keine Multipolygone zu produzieren, wo diese nicht nötig sind. Nicht nur dass diese Konstrukte mit teilweise 30 verschiedene outer zunehmend komplex werden, sondern Du machst dabei zunehmend Fehler. In diesem CS z.B. hast Du die Insel im Nägeleswiesensee zwar korrekt als inner des Sees zugeordnet, aber eben auch - unverständlicherweise - als outer des umgebenden Waldes (Relation 7766). Das ist so nicht richtig. Der See ist ein inner vom Wald und die (bewaldete) Insel ein inner vom See. Mehr MP braucht es bei solchen verschachtelten MP nicht, schon gar nicht, dass das inner vom inner zugleich das outer von allem ist (osm.wiki/DE:Multipolygon_Examples).
Ich editiere selbst MPs mit iD, aber da sollte man extrem vorsichtig damit umgehen und sehr genau wissen, was man da tut, da der iD-Editor die MPs nicht optimal unterstützt und sehr schnell was kaputt geht bei editieren.

Danke

Haus Nr. 8 is dasVerwaltungsgebäude lt NRW Liegenschaftskataster (als Hintergrund)

Hallo Frauke,
jetzt haste aber ganz schön viel Lagerfläche südlich der Junkersstraße übersehen. auch wenn (nur teilweise) ein Zaun zwischen Junkersstr. und Lagerfläche steht.
Außerdem würde ich die Adresse nicht ausschließlich an der umzäunten Fläche festmachen, die Parkplätze, Verwaltungssitz und Besucherzentrum gehören sicher auch dazu.

Korrektur:
da liegt natürlich [dieser Punkt](node/10889413907#map=19/51.84565/7.85194&layers=N) (Erreichbarkeit vor der Lücke nicht durch access-Werte eingeschränkt)

Vermutlich versucht ein Router zum Schwerpunkt des Gebäudes "VEKA AG" zu routen, und da liegt natürlich [dieser Punkt](node/10889413907#map=19/51.84565/7.85194&layers=N) (vorher nicht durch access-Einschränkungen erreichbar) mit ca. 210 m näher als das Haupttor mit 350 m.

Vermutlich dürfte ein konsequentes access=private mit highway=service innerhalb des Firmengeländes reichen. Gibt es für Teile der von-Liebig-Straße irgendwelche Beschränkungen?

Als zweites würde ich den Namen Veka AG nicht an ein einzelnes Gebäude sondern an eine separate Gesamtfläche des Firmengeländes hängen, dann dürfte sich der Schwerpunkt verschieben. Oder direkt (bzw. nur) an das Verwaltungsgebäude bzw. das Welcome-Center - dann dürfte das Routing eher dort enden, was unweit vom Haupttor liegt.
Das Haupttor würde ich mit main_entrance versehen, ggf. für die Suche mit name=Veka AG Haupttor.

Letztendlich: bis die Lücke in der Straße bei den Routern ankommt, dauert das genauso lange, wie ein korrektes Mapping bei den Routern ankommt. Schneller geht es, wenn die Veka AG die korrekte Zufahrt im Ort und im Industriegebiet ordentlich ausschildert. Wie blöd müssen denn die LKW-Fahrer sein, sich kurz vorm Ziel ausschließlich auf ein Navi zu verlassen, anstatt mal die Augen offen zu halten.

ich habe da folgende Fragen:
- bis wohin genau wurden die LKW vorher geroutet?
- was wurde als Ziel angegeben?
- wohin sollen die LKW hin geroutet werden, wo ist der Haupteingang?
- warum ist eine Straße innerhalb des Werksgeländes hinter dem Tor nicht private?
- warum sind einige Straßen auf dem Werksgelände residential und nicht service?
- warum wurde nicht abgewartet, ob sich das locked am Tor auswirkt
- und welches LKW-Navi eigentlich?

Mit brachialer Gewalt ne Lücke in eine Straße zu hauen, damit eine spezielle LKW-Navi-App nicht hintenherum routen ist falsch, falscher und am falschesten. Dass das revertiert wird ist so sicher wie das Amen in der Kirche.

Beantworte bitte die gestellten Fragen und dann kann man Schritt für Schritt analysieren und verbessern, dass am Ende das Routing wie gewünscht klappt, ohne Daten zu zerstören.

Hallo ticki,

der zugrundeliegende Fehler bei StreetComplete wird mit der nächsten Version behoben sein. Dann kann man einen einfachen geschlossenen roundabout, über den Routen vetlaufen, nicht mehr mit SC aufteilen.