Yes wiki is & should be guidance and also it describes the current mainly used tagging scheme. If there are (e.g. local) deviations it's fine, but it would be nice if these are also documented. I couldn't find a local tagging difference documentation, is there one?

I agree, if the population tag already exists the classification adds mainly no more additional info'. But in case renders are using place instead of population it could be helpful for showing different font sizes. (btw. to you know a renderer who prioritize 'population' over 'place' tags?)

For significant history and administrative data i would recommend to use different tags (not place - place describes the dimension of a settlement from small to big and not the importance).

You might look into wiki pages like Key:historic, boundary=administrative, Key:admin_level.

Further i could imagine tags like Key:start_date in general, or in particular for Trakai e.g. historic:capital.

I'm (and I think the wiki is) still okay with man_made=mast. Maybe add even more details by using mast:type=* or mast=*. If you still think it's too digressive you might change it to man_made=pole or add tags like support=pole, feel free :-)

Thanks for checking.

I changed the classification form 'village' to 'hamlet'.
For my and wiki's understanding hamlets have a dimension of 100-200 citizens. So far i know osm, the definitions are based on osm wiki and not bonded to official status.

But if you prefer that an settlement with a population of 16 people is a 'village' instead of 'hamlet' in this region i'm okay with it.

Thanks for fixing

Hi Tomas,

thanks for the interests of my changes. I and our wiki (man_made=mast - "A man_made=mast is usually a small, narrow mast of only a few meters height. [...]") thinks that also small (with ~3meters) units are okay for man_made=mast.

I double checked the height of the mast object at the linked mapillary picture. Next to the hgv truck the height of the mast looks like at least rather 4m than 3m. I added it, see here cs: changeset/92287507

Maybe the rendering logic at topographic maps could be adjusted, so that they only show masts which have big value of height=*

L___I

comment fix: enf.-details

An einer Stelle ja, (an dem Stück was ich gelöscht hatte, allerdings hatte ich das zunächst übersehen, dass sie dort tatsächlich bereits dran waren - an diesen kurzen Verbindungsstücken, werden die trun:lanes aber häufiger mal vergessen...) an anderer Stelle suboptimal gesetzt (hiermit: changeset/87820318 nun wieder optimiert).

Na da bin ich gespannt, was beim Routing noch so schönes herrauskommt...

Danke für die tr's - ja, die sind 'nice to have', aber der Vollständigkeit halber ;-)

Ich verstehe das Argument mit den Ansagen vom Navi. Mit der von mir erstellten Kreuzungsgeometrie hat es das Navi schwerer eine vernünftige "Bitte biegen sie links ab"-Ansage zu generieren.

Von daher habe ich auch nichts dagegen wenn die Geometrie so bleibt.

Unverständlich ist mir allerdings wie es zur Routenänderungen kommen konnte, oder spielte da eventuell der andere vorherige Änderungssatz (https://osmlab.github.io/changeset-map/#87804574) mit rein?

Nebenbei, könntest Du die doch eher sinnvollen revertierten Änderungen (2x turn-restrictions) & Anpassungen an turn:lanes (an https://pewu.github.io/osm-history/#/way/47223736) wieder einbauen, oder soll ich?

Grüsse

Danke für Info, habe gerade dazu im Forum geschrieben, meine Nachricht wird wohl dort erst in einer Weile freigeschalten:

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

Schöne Grüsse

- "... die lokale Mapping-Art ..."
Wie definierst Du in diesem Zusammenhang "lokal"?

- "... Oder bestimmst Du jetzt, ..."
Ich nahm an, die wiki gibt Empfehlungen wie in ganz Deutschland oder gar Weltweit was wie gemappt wird?

- "... Änderungssatz reverten"
Verstehe ich Dich richtig, Du möchtest (Du forderst) einen vollständige Rückgängigmachung eines Änderungssatzes, bei dem die expliziert besprochenen Änderungsdetails rund weniger als 5% des Änderungssatzes ausmachen?

Hallo
danke fürs Interesse - sehr gut beobachtet.

traffic_sign=DE:310
sollte auch passen, siehe verschiede wiki-Artikel:
a)
traffic_sign=*#Tagging
"It is common to use both human-readable values (like city_limit) as well as national traffic sign IDs (like DE:310) where they exist."

und

b)
traffic_sign=DE:310
osm.wiki/DE:Tag:traffic_sign%3DDE:310

Da es hierfür scheinbar 2 gleichwertige Taggingschemen gibt (wohl ähnlich wie phone vs. contact:phone) setze ich die folgende Systematik um:
- menschenlesbar (z.B. city_limit/maxspeed) am Punkt(node)/Line(way) direkt auf der 1D-Navi'-linie
- maschinenlesbar (z.B. DE:310/DE:274-100) an dem Punkt(node) neben der Straße, an dem der Verkehrszeichenpfahl steht.

Viele Grüße
L___I

Korrektur:
(wegen falscher Link)

Kreuzung verschoben, siehe: https://overpass-api.de/achavi/?changeset=80657299

Kreuzung verschoben, siehe: https://overpass-api.de/achavi/?changeset=80580195

PS: eine weitere nicht erwähnte Hauptintension des CS ist es 6 vorher nicht vorhandene Abbiegebeschränkungen hinzuzufügen.

Hallo PT-53,

danke fürs Interesse und die Nachfrage.

Das Wegsegment:
https://pewu.github.io/osm-history/#/way/102888295
habe ich entfernt, weil dort zwischen Wegsegment
https://pewu.github.io/osm-history/#/way/102888295
und Wegsegment
https://pewu.github.io/osm-history/#/way/769923491
laut diesem Strassenbild
https://openstreetcam.org/details/1459698/393
keine bauliche Trennung besteht. Ist das Bild aktuell genug? Wurde zwischenzeitlich eine physische Trennung aufgebaut?

Das Wegsegment:
https://pewu.github.io/osm-history/#/way/102888273
habe ich belassen, weil dort zwischen Wegsegment
https://pewu.github.io/osm-history/#/way/102888273
und Wegsegment
https://pewu.github.io/osm-history/#/way/769923491
laut dem selben Strassenbild
https://openstreetcam.org/details/1459698/393
eine bauliche Trennung besteht. Ist das Bild aktuell genug? Wurde zwischenzeitlich eine physische Trennung abgebaut?

Viele Grüsse
L___I

Hallo PT-53,
"..ich finde es super, .." das klingt für mich recht ironisch. Ist das wirklich so gemeint?
Die Anpassung an ein Luftbild war hier im CS nebensächlich. Hauptintension ist die Kreuzungsinformationen bzgl. lanes und (Spurmapping vs. Spurtagging), turn:lanes und die Klassifizierung zu verändern. Wenn Du den Versatz kennst, nenne ihn bitte. Dann darfst Du gerne alles um diesen Offset verschieben, oder ich übernehme das selbst. Aber ein Revert wäre recht schade.
Viele Grüsse
L__I

Zur Übersicht:
https://overpass-api.de/achavi/?changeset=80580195

Hallo j1scad,
danke für Deine Mitteilung und den Hinweis. Ich habe dementsprechend eine Änderung vorgenommen, siehe Verweis zur grafischen Darstellung der Änderung unten[1]. Schaust Du bitte mal drüber, ob das so okay ist, oder ob jetzt immer noch zu viel "Vorgarten" erfasst ist.
Danke und Grüsse
LI
[1] https://overpass-api.de/achavi/?changeset=78311842

Hallo theophrastos,

danke für's Interesse und die Hinweise. Ich habe die turn:lanes Informationen an den von Dir zwei genannten osm-ways entfernt, das sind sowieso nur recht kurze Stücken. Ich bin nicht sicher, ob die von Dir genannte Info':

"[...] ist der Wechsel auf den Beschleunigungs- bzw. Verzögerungsstreifen durch eine durchgezogene Linien untersagt, dementsprechend ist das slight_right dort unnötig. [...]"

tatsächlich Grund genug wäre dies zu entfernen, ist aber für mich nicht so wichtig. Bei OSM werden für turn:lanes meiner Meinung nach (und die Meinung der wiki nach) nicht ausschliesslich rechtliche Umstände erfasst, da diese Daten auch für Streckenabschnitte eingetragen werden können, bei denen dies durch Verkehrszeichen angezeigt wird.

Bezüglich des zweiten Punktes "Verzögerungsstreifen/Beschleunigungsstreifen und merge_to_left/slight_right"
Da bin ich derzeit anderer Meinung. Ich würde wie es die wiki beschreibt, die turn:lanes dort setzen, für die Stellen wo entweder durch Pfeile auf der Fahrbahn oder durch Schilder die Richtungen angezeigt werden. Die Werte für (turn:lanes=)xyz würde ich dann entsprechend der Information, die auf den Pfeilen auf der Strasse, oder die auf den Schildern zu erkennen ist, eintragen.

merge_to_left oder merge_to_right sehe ich ausschliesslich an den Stellen, bevor ein Fahrstreifen endet und deswegen die Verkehrsteilnehmer den Streifen wechseln müssen.
Also so ähnlich, wie es auch hier folgend in der wiki gezeigt wird (vgl. Tabelle vorletzte und drittletzte Zeile): osm.wiki/w/index.php?title=Key:turn&uselang=en#Values

Nebenbei, wenn sich z.B. hier am Autobahnkreuz jemand an den genannten Stellen verfahren hat, kann er auch auf dem rechten Streifen bleiben („slight_right“) und noch eine Runde durchs Kreuz fahren, bis er die für sich passende Richtung gefunden hat.

Viele Grüsse
L___I

Hi,
die durch diesen CS geleerte Uni-Relation relation/2176008 habe ich durch diesen Änderungssatz changeset/65221980 wieder aufgefüllt...
Gruss

Hi atarico,
.
thanks for updating the map.
.
Are you sure all of these 4 parallel mapped lanes have a physically separation (for instance kerbs etc.) "on-the-ground"?
https://overpass-api.de/achavi/?changeset=62551004
Otherwise the previous mapping was correct.
.
Could you please double check if there is a physically separation between the separate mapped lanes .
.
Thanks
.
By the way, there might be an other issue, it seems some route-relations are also broken now after this edit, maybe local mappers could check as well. Or maybe entire revert could be a solution...

Hallo SvenTi,
vielen Dank für die neue Kreuzungsgeometrie (Kreisweg):
way/625569872/history
.
Zwei Wege waren nicht mit dem Kreis verbunden, dies habe ich soeben mit der Änderung: https://overpass-api.de/achavi/?changeset=62697529 erledigt.
.
Nebenbei, welche Art Kreis ist das? Also gibt es eine überfahrbare Mittelinsel? Falls ja wäre das ein: osm.wiki/DE:Tag:highway%3Dmini_roundabout
.
Gibt es ein Zeichen 215 (osm.wiki/File:Zeichen_215_-_Kreisverkehr,_StVO_2000.svg) an den Kreiseinfahrten? Falls ja, dann kommt an den Kreisweg noch die Eigenschaft "junction=roundabout" in Frage.
.
.
Weitere Info's dazu sind unter folgenden Artikeln zu finden:
osm.wiki/DE:Tag:junction=roundabout
.
osm.wiki/DE:Tag:highway%3Dmini_roundabout
.
Viele Grüsse