piebro/osm-data huggingface dataset:
pkm (2023-07-26 20:07:17+00:00): Hallo, ja ist er, die Beschilderung ist weiter vorne an der Kreuzung der Forstwege. https://www.openstreetmap.org/node/10570894765 (siehe web link mit dem Tafeltext) S2 ist nicht in Klammern, da hat mich meine Erinnerung wohl getäuscht. Direkt am Bergvorsäß beim Übergang des Tracks in den Pfad ist nur mehr Pfeil mit dem MTB Symbol. Von unten heraus ist der Weg nicht als MTB Route beschrieben. Wenn man die Namensregel streng auslegt, dann sollten man den Namen rausnehmen.
ToniE (2023-07-21 16:30:55+00:00): Hallo Julian,

diese Teilstrecke der RB 56 ist in OSM nun wieder doppelt gemapped, nachdem ich sie vor Kurzen gelöscht hatte. Die RB 56 ist komplett und korrekt gemapped: https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html#train_RB_56

Es ist bei "train" nicht üblich echte Teilstrecken nochmals zu mappen.

Was ist der Anlass, diese Teilstrecke - und nur diese Teilstrecke - wieder zu mappen?

Viele Grüße
Toni
julian123456789 (2023-07-21 16:50:19+00:00): Hi Toni,
erstmal sorry dafür. Ich benutze die Teilstrecken für eine Projektarbeit. Soll ich die Strecken wieder löschen oder wäre es in Ordnung, wenn ich die Strecken dafür besonders kennzeichen würde?

Gruß
Julian
ToniE (2023-07-21 17:03:23+00:00): Danke Julian, 

bitte löschen, privat genutze, doppelt vorhandene Daten gehören nicht in OSM rein - auch nicht mit einer besonderen Kennzeichnung.

Es gibt andere Möglichkeiten, private Daten basierend auf OSM zu nutzen.

https://umap.openstreetmap.de

Was mich stört, ist z.B. der Kommentar "nicht elektrifizierte Teilstrecke" für route=train. Elektrifiziert oder nicht ist in OSM eine Eigenschaft der Infrastruktur, wie Claudius schon erwähnte - route=tracks oder route=railway.

Ein Diesel-betriebener Zug (wie hier) kann wohl auch auf elektrifizierten Strecken.

Gruß
Toni
ToniE (2023-07-21 17:47:51+00:00): Sorry Julian,

das mag nun ein Schock gewesen sein: viel Arbeit ins Projekt gesteckt und dann kommt jemand daher und will dass die Daten gelöscht werden  - u.U. kurz vor der Abgabe.

Ich weiß nicht, was der Titel des Projektes ist: aber wenn du z.B. wissen willst welche (Regional-)Züge komplett "nicht elektrisch" fahren müssen, weil Teilstrecken noch nicht elektrifiziert sind?

Das könnte man mit einer Overpass-API-Abfrage auf die OSM-DB machen (oder mit Import nach QGIS und SQL) unter Verwendung der vorhandenen Daten und ohne weitere Daten hinzuzufügen (von Korrekturen mal abgesehen).

https://wiki.openstreetmap.org/wiki/Overpass_API

Meine PTNA-Seite https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html holt sich z.B. alle notwendigen Daten via Overpass-API ( https://ptna.openstreetmap.de/de/config.php?network=DE-Bahnverkehr#overpass-api ) und bereitete diese XML Daten dann auf. Overpass ist sehr mächtig und allerdings auch sehr kryptisch.

Gruß
Toni
julian123456789 (2023-07-22 08:47:48+00:00): Hi Toni,
so schlimm ist es zum Glück nicht. Ich muss einiges ändern, aber deine PTNA-Seite hilft enorm. Ich lösche jetzt alle von mir hinzugefügten Duplikate. 

Gruß 
Julian
ToniE (2023-07-22 09:58:44+00:00): Hi Julian,

prima. Neben der IST-Analyse bei OSM https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.htmlhaben wir vom NahVerkehr Baden-Württemberg (NVBW) auch noch die Real-Daten für den SPNV im echten und PTNA-aufbereiteten GTFS-Format.

echt
https://www.nvbw.de/fileadmin/user_upload/service/open_data/fahrplandaten_mit_liniennetz/bwspnv.zip

PTNS-GTFS
https://ptna.openstreetmap.de/gtfs/DE/routes.php?feed=DE-SPNV

Evtl. hilft das auch?

Gruß,
Toni
julian123456789 (2023-07-26 08:51:39+00:00): Hi Toni,
danke für deine Hilfe. Ich brauche nur die Routen, daher reicht die IST-Analyse vollkommen aus.

Gruß
Julian
ToniE (2023-07-21 16:33:51+00:00): Hi Julian,

auch hier bitte zunächst prüfen, ob die Linie nicht schon gemapped ist

https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html

Bitte auch zwischen route=train und route=tracks und route=railway unterscheiden

Gruß
Toni
Majidaghamirzaei (2023-07-21 16:47:29+00:00): That's right 
Information is true
literan (2023-07-21 17:38:18+00:00): но это не линк, это окончание Шереметьевской улицы
habi (2024-09-20 06:57:21+00:00): Ciao Beat
In diesem CHangeset hast du viele Gebäude zusammengefasst, die einzeln erfasst waren.
Alle diese Gebäude sind im Katasterplan Bern und in MOPUBE [1] als getrennt erfasst.
Aus meiner Sicht macht es Sinn, die getrennten Häuser auch getrennt zu erfassen, nicht?

Gruss,
Habi

PS: Ich bin 'hier', weil die Überbauung ännet der Emme (rund um https://www.openstreetmap.org/way/1316723372) fertig gebaut und bewohnt ist (ein Bekannter von mir zügelte dort hin).

[1]: Amtliche Vermessung Bern, vereinfacht: https://lists.openstreetmap.ch/archives/list/talk-ch@openstreetmap.ch/thread/ZTRUBX7AFIUI5LBON2UP44IF4GEP6IDS/
Beat Kaeser (2024-09-26 11:56:23+00:00): Ciao Habi

Ich habe Gebäude zusammengefasst, wo ich keine selbständigen Häuser sondern stattdessen einen gemeinsamen Baukörper und einen zusammenhängenden Umriss gesehen habe.  

Ich bin mit den Details, wie der Katasterplan im Kanton Bern zu Stande kommt und welche Ziele mit ihm verfolgt werden, nicht wirklich intim vertraut. Ich vermute allerdings viel rechtliche, insbesondere steuerrechtliche und  eigentumsrechtliche Motivation. Damit entstehen allerdings schon 'getrennte Häuser' wenn sich Gebäudeteile im rechtlichen Status unterscheiden. 

Katasterpläne - als Hilfsmittel des Grundbuchs - verwenden typischerweise als ordnende räumliche Einheit die Parzelle. Die Informationen im Grundbuchs beziehen sich dann auf eine konkrete Parzelle. Damit das auch für Gebäude funktioniert, dürfte es im Katasterplan keine parzellenübergrefenden Gebäude geben. Das entspricht aber nicht immer dem, was wir in OSM unter Gebäude (building=*) verstehen. Hier steht eher der physische Umriss im Vordergrund - und der kann sich problemlos über mehrere Parzellen erstrecken. 

Aus meiner Sicht macht es nicht unbedingt und nicht in jedem Fall Sinn, automatisch die Definition von 'getrenntem Haus' aus dem Katasterplan zu übernehmen. Wenn sich der physische Umriss, wie er z. B. vor Ort beobachtet werden kann und die Erfassung im Katasterplan unterscheiden, geben ich dem physischen Umriss  den Vorzug. Ich denke, das macht auch für die meisten Benutzer der Karte Sinn - man orientiert sich zuerst an dem, was man sieht und nicht daran, wer im Grundbuch als Eigentürmer eingetragen ist. 

Gruss,
Beat
habi (2024-10-21 20:30:12+00:00): Ich war in den Ferien, dein Changeset-Kommentar habe ich da vergessen...

Gerade in Bern sind auch die frei verfügbaren Address-Daten sehr gut, und häufig auch passend zu den geteilten Gebäuden im Katasterplan.
Deshalb erfasse ich solche Gebäude eigentlich immer getrennt,  damit sich die Gebäude-Teile auch. mit der korrekten Adresse versehen lassen...
Beat Kaeser (2024-10-24 07:40:07+00:00): Wenn zu einem Gebäude (Gebäudekomplex) mehrere Adressen gehören, versuche ich den Eingang zu identifizieren, zu dem die die jeweilige Adresse gehört. Das sollte die Nutzer der Karte, die ein Anliegen an dieser Adresse haben,  dort etwas abgeben oder jemanden besuchen wollen, gleich zum dafür am besten geeigneten Punkt am Gebäude führen.  

Wenn ich Gebäudeteile mit unterschiedlichen Tags versehen will,  strukturiere ich die Situation mittels building:part=yes. Damit lassen sich,  unabhängig vom Katasterplan, alle Arten von Gebäuden  differenziert beschreiben.
Allroads (2023-07-24 23:19:51+00:00): https://www.openstreetmap.org/relation/11915097/history
Then you could see that I forgot here to insert a inner https://www.openstreetmap.org/way/875076783#map=19/52.68786/5.90694

Did you noticed that?
Why not include the inner?
This should be right.
Now it is still wrong. Not cutting out the water.

Also for this way https://www.openstreetmap.org/way/874439809/history

Not a problem when you contact met up front.
Friendly_Ghost (2023-07-27 20:32:27+00:00): There are many cases of landuse polygons containing or intersecting water areas. It usually doesn't hinder rendering and it's at the very bottom of my priority list, also in all of my other changesets. 

If it makes a difference to you I could tidy up a bunch of them.
Allroads (2023-08-03 18:37:48+00:00): In the base, it is wrong, what rendering does, should not effect good tagging, leave it as it is, is wrong. 
As you did not mention that you have seen it, I assume that "you walked over it" Not noticed the situation, why there was a multipolygon, recognize my fault.
But still set back as a polygon.
This looks like a mechanical, so there is now a double mistake. I aspected with such a cleaning, that you noticed it, if you did it on purpose, that is not okay.

Did you notice the slope=yes tag?
Friendly_Ghost (2023-08-05 01:22:08+00:00): As you can see in the changeset source I was using the aerial imagery to verify each and every single one of all the objects that I changed. There wasn't anything "mechanical" about this edit. 

You can't claim that I added any mistakes to the map here, because the water bodies weren't part of the multipolygons in the first place. As I mentioned previously, this can still easily be done. I just don't happen to have my pc with me this week.

I did notice the slope tag, but since I have no idea what the tag means I didn't do anything with it.
Friendly_Ghost (2023-08-05 02:56:45+00:00): There are thousands of cases where landuse/natural polygons overlap with water, see for example this simple query for Amsterdam: https://overpass-turbo.eu/s/1ywp

Evidently, when you consider the whole Netherlands, the number of overlapping landuse and water polygons will become big enough that fixing them should be considered a separate project.
Allroads (2023-08-05 10:38:33+00:00): The point is that you did not see/understand my mistake and responded to it by adding the inner, my intention, which is correct then setting it to polygon.
Friendly_Ghost (2023-08-05 13:05:39+00:00): Did you just comment to complain about my changeset or do you want to improve the map together?
Allroads (2023-08-05 14:00:46+00:00): I noticed it at first here, the way relation change https://resultmaps.neis-one.org/osm-edits-tile/#14/52.6840/5.9059, now it is past 14 days. So now and then I look here what is changed in some area. I did this part of nature.
Asking myself, why, why not set the inner correct, my failure, that's why this reaction on the changeset is made, to make together a better map. So I brought it to your attention.
Obvious, in this case, I find it wrong. I did not watch other changes in the changeset. But if it is done like this case, then it is questionable. That is now my comment on the changeset, since you asked for it.
Friendly_Ghost (2023-08-05 14:41:58+00:00): Alright, that makes it very understandable. Thank you for clarifying.

You're right of course that I could have made proper multipolygons with the water, but since I wasn't looking for it I missed it.
ptarac (2023-08-18 16:16:05+00:00): Dlaczego oznaczyłeś jako landuse=construction? Modernizacja toru wodnego Szczecin-Świnoujście, a więc i budowa wysp na Zalewie Szczecińskim zakończyła się w maju 2022r.
maraf24 (2023-08-28 01:59:52+00:00): Nie ma tam żadnych prac i wyspy mają już swój ostateczny kształt?
ptarac (2023-08-28 19:35:55+00:00): Obrys wysp już się nie zmieni. Brysna funkcjonuje jako biotop dla ptaków w ramach kompensacji środowiskowej inwestycji. Tam już nie będzie żadnych działań. Wnętrze Śmięckiej stanowi kolejne pole refulacyjne i jako takie podlega ciągłym przekształceniom. Nie wynikają one z budowy (robót budowlanych), ale z jej przeznaczenia. Inne pola refulacyjne (m. in. Mańków, Świnoujście) nie mają oznaczenia landuse=construction.
maraf24 (2023-08-28 19:58:06+00:00): Dzięki. W takim razie trzeba to landuse usunać.
Ntw. żaden z dotychczasowych edytujących nie zamieścił informacji o zakończeniu budowy, a nawet gdy była w budowie to nie była tak oznaczona.
A ja sprawdzając nowsze zdjęcia aktualizowałem jej kształt, ktory się zmieniał, co wyglądało na trwającą budowę. 
Stąd to landuse=construction.
Bienson (2023-07-21 22:22:13+00:00): Telefonnummern müssen immer im internationalen Format eingetragen werden:

https://wiki.openstreetmap.org/wiki/DE:Key:phone
ptarac (2023-08-18 16:16:49+00:00): Dlaczego oznaczyłeś jako landuse=construction? Modernizacja toru wodnego Szczecin-Świnoujście, a więc i budowa wysp na Zalewie Szczecińskim zakończyła się w maju 2022r.
maraf24 (2023-08-28 02:02:16+00:00): Jest jakieś źródło na to?
ptarac (2023-08-28 19:44:30+00:00): Chociażby artykuł, który podajesz w description. On jest sprzed dwóch lat i w ostatnim zdaniu napisano: "Koniec prac zaplanowano na marzec 2022 roku.". I na tej podstawie oznaczyłeś wyspę, że jest w budowie...
Informacje o zakończeniu inwestycji znajdują się np. tu: https://www.ums.gov.pl/600-zakonczenie-modernizacji-toru-wodnego-swinoujscie-szczecin

Ponadto sam dodałeś start_date=2022-05-11, który - za wiki - "służy do podania daty otwarcia obiektu lub zakończenia budowy obiektu".
ptarac (2023-08-28 19:46:44+00:00): Sorki nie Ty dodałeś start_date, ale to i tak wskazuje, że nie jest to już plac budowy.
maraf24 (2023-08-28 20:05:57+00:00): ""Koniec prac zaplanowano na marzec 2022 roku.". I na tej podstawie oznaczyłeś wyspę, że jest w budowie..."

W przypadku budowy dróg takie inormacje prasowe często okazują się daleko odbiegać od rzecywistości. Dlatego ja nie wyciągam z tego żadnych wniosków skutkujących zmianami w obiekcie.
Zaktualizowalem obie wyspy. Dzięki z info, bo sam pewnie bym się zorienotawał za kilka miesięcy, przy ponownej aktualizacji kształtu wysp.
Bienson (2023-07-21 22:20:36+00:00): Parkplatz war bereits vorhanden
pitfire (2023-07-22 06:27:06+00:00): Hallo Jule_Beuel,
warum verlaufen die Wege jetzt übers Wasser?

https://overpass-api.de/achavi/?changeset=138823081
user_5359 (2023-07-22 10:22:11+00:00): Welcome to OSM (again)! Please see https://www.osm.org/changeset/138313496. Don't write the possible values of mtb:scale to the key!
sen_takeya (2023-08-11 19:24:58+00:00): こんばんはミイポンさん
あなたが追加した農地と重なるように公園が置かれましたけど本当にここは岩手県一関市の公園でしょうか？そうであれば名称をぜひ教えてください

農地
https://www.openstreetmap.org/way/1191273689
公園
https://www.openstreetmap.org/way/1191273690
sen_takeya (2023-11-22 09:32:37+00:00): Removed
https://www.openstreetmap.org/changeset/140572753
NorthCrab_upload (2023-07-21 17:20:22+00:00): Zauważyłem, że Twoja zmiana zawiera adresy wymagające dodatkowej uwagi. Przygotowałem listę obiektów oraz dodatkowe informacje:

Nazwa ulicy nie istnieje w okolicy.
https://www.openstreetmap.org/way/1191274900

Pozdrawiam! 🦀
ToniE (2023-07-22 12:09:51+00:00): Hello Leonardo,

There were many changes in route relations but route_master relations left unchanged. PTNA https://ptna.openstreetmap.de/results/CO/BOY/CO-BOY-Duitama-Analysis.html provides a daily analysis of the area of Duitama.

Could you please also check the CSV file for the Analysis https://wiki.openstreetmap.org/wiki/ES:Colombia:Boyac%C3%A1:Duitama/Rutas_Transporte_P%C3%BAblico and fix that?

Regards
Toni
Hola Leonardo,

Hubo muchos cambios en las relaciones de ruta pero las relaciones route_master no cambiaron. PTNA https://ptna.openstreetmap.de/results/CO/BOY/CO-BOY-Duitama-Analysis.html proporciona un análisis diario de la zona de Duitama.

¿Podrías por favor revisar también el archivo CSV para el análisis https://wiki.openstreetmap.org/wiki/ES:Colombia:Boyac%C3%A1:Duitama/Rutas_Transporte_P%C3%BAblico y arreglar eso?

Saludos
Toni


Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator
Leonardo Gutierrez (2025-12-08 22:49:24+00:00): Toni, 

Estoy revisando mis comentarios, doculpa que no te hubiera respondido, dentro de poco realizaremos una revisión en este sistema de Transporte.   Te cuento que las rutas maestras no las hemos mantenido, para la generacion de GTFS no son requeridas, pero si tu las requieres podemos hacer un esfuerzo por mantenerlas actualizadas. 

Saludos
ToniE (2025-12-09 12:26:39+00:00): Gracias, Leonardo.

Los datos de OSM no son correctos sin los cambios mencionados en las relaciones route_master.

Puedo modificar la lista CSV en la wiki de OSM si lo deseáis.

Saludos también a los Trufistas y a Christoph,
Toni
felipeeugenio (2023-07-21 19:45:30+00:00): Hola
gracias por las ediciones.
no existe el numero = S/N, por favor usar el tah nohousenumber=yes.
El otro eliminarlo.
saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/138824382
arjunaraoc (2023-07-22 09:10:07+00:00): The focus of mapping is on roads. It may be better to   just focus on that and not add buildings.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/138824567
mcliquid (2023-07-24 07:28:30+00:00): Hi, wieso hast du von der Adresse nur die Postleitzahl entfernt?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/138824799
pkm (2023-07-26 20:13:15+00:00): Sehr aufmerksam, war versehentlich, wollte nur die "note" löschen und mit der "description" ersetzen.
user_5359 (2023-07-21 19:26:21+00:00): Hello! Please take a look on https://www.osm.org/node/4236720623/history. You must pay to read a information board??
user_5359 (2023-07-21 19:27:51+00:00): By the way: The name of the streets are really numbers? Or ist the number of a plot?
Milroy1812 (2023-07-22 02:13:43+00:00): They are numbered camp sites for RVs (caravans).  Bing photo shows RVs parked in some of them.  Perhaps the camp sites could be marked with an area or node tagged like this:

tourism=camp_pitch
ref=*

where * is the number of the camp site.
Keith Helbley (2023-07-23 01:13:59+00:00): Re:@user_5359 the reason I tagged it with pay is it is an iron ranger - the location you pay for your campsite if the flesh and blood ranger is not around. it looks like this: https://ironrangersllc.com/indexpage2.htm

Re:@Milroy1812 
yes, the driveways are marked with the site number, as I found in some apps, they do not pull the full POI and instead use roads. one example is the app: Organic Maps. if you know a better way to mark site numbers, feel free to make the addition.
Milroy1812 (2023-07-24 03:24:36+00:00): It all looks fine to me.  My post was mainly directed to user_5359 who did not seem to understand the camp site layout.  I did not mean to step on your toes.  When I loaded edit mode in iD, I was able to see that you had already added the camp pitch nodes.  iD's map viewer does not show these features and I did not realize that they had already been placed.
bicyclett (2024-05-14 16:07:03+00:00): Hi,
mir ist aufgefallen, dass du an eigene Straßen (z.B. 4860882) den cycleway-tag geändert hast. Davor war noch die Seite auf der der Radweg ist spezifiziert (cycleway:right cycleway:left) und nach deiner Änderung war diese Info weg. Gibt es dafür einen bestimmten Grund oder ein Versehen?
bergaufsee (2024-05-14 20:03:52+00:00): Hallo,
das habe ich tatsächlich bewusst getan. Ich bevorzuge das KISS-Prinzip und verwende daher wenn möglich ein einfaches tagging.
Wenn also wie im Bsp. auf der Straße keinerlei Fahrradinfrastruktur vorhanden ist, ist somit ein einfaches cycleway=separate ausreichend, egal ob ein- oder beidseitig ein separater Radweg vorhanden ist.
Für den router ist das ausreichend, da er keine weitere Info benötigt als sinngemäß "kein Radweg auf der Straße, also such dir eine andere Strecke".
Auch zum datentechnischen Auswerten der Fahrradinfrastruktur ist es ausreichend, da hierfür eh die separaten Radwege mit einbezogen werden müssen.
Ich nutze cw:left|right=separate nur wenn auf der ggü. liegenden Straßenseite tatsächlich z.b. cw:*=lane o.ä. vorhanden ist.
schöne Grüße
bicyclett (2024-05-15 06:58:05+00:00): Hi,
verstehe und finde ich grundsätzlich auch gut möglichst simples tagging zu verwenden.
In dem Fall gehen allerdings ohne Angabe der Seite Informationen verloren bzw. ob der separate Radweg auf beiden Seiten ist oder eben auf welcher Seite. Es gibt Anwendungen für die diese Information sinnvoll ist.

Unabhängig davon hat sich die Angabe der Seite inzwischen großflächig durchgesetzt und die nicht-Angabe insbesondere das reverten von bestehenden Seitenangaben stellt ein besonderes Vorgehen dar:

räumlich für Brandenburg:
https://overpass-turbo.eu/s/1Lvm

zeitlich für Brandenburg
https://dashboard.ohsome.org/#backend=ohsomeApi&groupBy=key&time=2020-01-01T00%3A00%3A00Z%2F2024-04-22T00%3A00%3A00Z%2FP1W&filter=cycleway%3D*+or%0Acycleway%3Aboth%3D*+or%0Acycleway%3Aright%3D*+or%0Acycleway%3Aleft%3D*&measure=length&groupByKeys=cycleway%2Ccycleway%3Aboth%2Ccycleway%3Aright%2Ccycleway%3Aleft&adminids=-62504
Supaplex030 (2024-05-15 10:09:00+00:00): Hallo bergaufsee,

das Entfernen von seitenbezogenen Suffixen ist ein signifikanter Informationsverlust, da aus den Daten dann nicht mehr hervorgeht, ob – im Fall von "both" – tatsächlich beide Seiten gemeint sind oder diese Information einfach nur fehlt und sich evtl. nur auf eine Seite bezieht.

Da sich die Angabe des Seitenbezugs erst später in OSM etabliert hat als der cycleway-Tag selbst, kann man eben _nicht_ sicher davon ausgehen, dass sich ein Tag bei einem fehlenden Seitensuffix auf beide Seiten bezieht. Insbesondere in Einbahnstraßen führt das bis heute zu unklaren Datenlagen.

In jedem Fall ist eine explizite Angabe besser als keine Angabe, um diese Unsicherheit zu vermeiden. Diese Erkenntnis setzt sich – wie oben von bicyclett bereits angeführt – auch zunehmend in der Community durch. Die oben verlinkten Veranschaulichungen zeigen: In Brandenburg fehlen Seitensuffixe inzwischen nur noch an knapp 7% der Wege, insbesondere in deiner Ecke :)

Ich würde dich daher bitten, noch einmal darüber nachzudenken und die Seitenangaben zukünftig bestehen zu lassen. Das KISS-Prinzip bringt uns nichts, wenn dadurch Unsicherheiten in den Daten manifestiert werden.

liebe Grüße
Alex

(P.S. Da einige Mapper gezielt Wegsegmente ohne Seitensuffixe vervollständigen, wird es vermutlich auch nur eine Frage der Zeit sein, bis sie wieder ergänzt werden würden...)
Supaplex030 (2024-05-15 10:39:04+00:00): P.P.S. Ich sehe gerade, dass du sogar verschiedene Angaben wie "cycleway:left=no" und "cycleway:right=separate" zu einem "cycleway=separate" zusammengeführt hast. Das ist sehr ungünstig, da nun aus den Daten nicht mehr hervorgeht, auf welcher Seite sich der separate Weg befindet. Für verschiedenste Anwendungen, aber auch Renderer kann diese Information sehr nützlich sein.

lg, Alex
bergaufsee (2024-05-15 19:41:26+00:00): Hallo zusammen,

> P.P.S. Ich sehe gerade, ...
danke Alex, dass du meinen Beitrag leider gar nicht gelesen hast, da habe ich es bereits versucht zu erklären

> aber auch Renderer kann diese Information sehr nützlich sein...
warum sollte der Renderer auf der centerline darstellen, dass der Radweg separat gemappt ist, eine Fahrradkarte sollte den Radweg darstellen (die beiden auf osm.org tun auch nur dies)

> da aus den Daten dann nicht mehr hervorgeht, ob ... diese Information einfach nur fehlt ...
ich habe auch schon diverse falsch getaggte Wege mit *:both gesehen, eine erhöhte Fehlerquote kann ich auf das simple Schema daher nicht ableiten

> Insbesondere in Einbahnstraßen führt das bis heute zu unklaren Datenlagen.
ok, mir noch nicht aufgefallen, bin ich aber gern bereit mir anzuschauen

"cycleway:left=no"+"cycleway:right=separate" bei separatem Mehrrichtungsradweg sehe ich hingegen sogar kritischer weil irreführend wenn nicht gar falsch, da es im ersten Schritt suggeriert, dass ich left auf der Straße fahren kann/muss/soll, da ja keine Radinfrastruktur für die Fahrtrichtung vorhanden ist. Dies lässt sich aber nur aufklären indem ich dann doch den umliegenden Radweg mit in die Auswertung einbeziehe.

Aber gut, ich werde mich künftig diesbezüglich zurückhalten.
Es macht ja nichts wirklich kaputt, nur m.M.n. unnötig kompliziert ohne tatsächlichen Mehrwert.

Ich habe mich hier nur noch mal so ausführlich geäußert um auch zu zeigen, dass ich das so handhabe, nicht um jemanden zu ärgern oder einfach aus alter Gewohnheit, sondern ich mir darüber durchaus Gedanken gemacht habe.

LG
Bernd