Hi, der `name`=* Tag sollte nicht als Beschreibung verwendet werden und nur dann gesetzt werden wenn etwas wirklich einen Eigennamen besitzt der nicht nur eine generelle Beschreibung des Objekts ist. (Dafür gibt es den `description`=* Tag)

lg, Woazboat

osm.wiki/Names#Names_are_not_for_descriptions

Hallo,
Benannte Wander- bzw. Spazierrouten sollten nicht als eigene Wege hinzugefügt werden sondern als route relations [1] die die bereits bestehenden Wege verwenden.

So wie es derzeit gemappt ist existieren zwei duplizierte und überlappende Wege, das sollte es nicht geben.

lg, Woazboat

[1] osm.wiki/DE:Tag:route%3Dfoot

@fkv: Wie gesagt, dass `access`=* nur die rechtliche Situation betrifft ist de-facto nicht richtig. Wenn man das durchsetzen möchte bräuchte man eine Zeitmaschine (und einen Vorschlag für ein alternatives Taggingschema um diese Feinheiten abbilden zu können). Fakt ist, dass das tagging von `access`=* von allen Routern verwendet und benötigt wird um sinnvolles routing zu ermöglichen. Das ist schon seit langer Zeit gängige Konvention in OSM und wird sich auch nicht so schnell ändern. Kein Router wird einfach so Änderungen durchführen und die Daten anders interpretieren wenn sie dadurch ihren Zweck (i.e. sinnvolles routing) nicht mehr erfüllen können, nur um irgendwelchen Idealvorstellungen zu entsprechen die jahrelangen Konventionen und der de-facto vorhandenen Realität in den Daten widersprechen.

Wir mappen in OSM sehr wohl für data consumers wie renderer und router, sonst wäre das gesamte Projekt eine sinnlose Übung ohne jeglichen Nutzen. Alle Daten in OSM sind im Endeffekt dazu da um von irgendjemanden genutzt zu werden und nicht einfach so für den Selbstzweck um eine Datenbank zu befüllen die keine Nutzer hat. Was wir dabei _nicht_ tun ist die Daten falsch einzutragen oder zu verändern dass sie der Realität oder etablierten OSM Konventionen widersprechen nur um einen Effekt in einzelnen data consumers zu erreichen, diese Daten dadurch aber für das Gesamtprojekt (und andere data consumers) nutzlos werden.

> Zum PS: Wenn du mit Fällen argumentierst, die real nicht vorkommen, kannst du genausogut access-Tags für Drachen und Klingonen setzen.

Hier ein Beispiel wenn du glaubst das so etwas nicht existiert: node/21271804

> Mein eigenes PS: Während einer laufenden Diskussion mit einem Revert loszufahren ist nicht in Ordnung!

Wenn du den revert changeset anschaust wird dir auffallen, dass dadurch nichts verändert wurde um das es hier in der Diskussion geht. Die access tags der Schranken sind unverändert (sie waren ja auch nie da). Das einzige das hier relevant für diese Diskussion ist, dass ich die `description=Schranke nur bei Lawinengefahr geschlossen.` tags wieder hergestellt habe, aber da sind wir uns glaube ich alle einig dass diese wiederhergestellt gehören. Die ursprüngliche Löschung hatte ja auch nichts mit diesen tags zu tun.

Daten aus diesem changeset wurden in changeset/119448104 teilweise wiederhergestellt

Dieser revert wurde in changeset/119448104 wieder teilweise rückgängig gemacht um Daten die unnötigerweise durch den vollständigen revert zerstört wurden wieder herzustellen

Hi,
dass `access`=* tags in Österreich nur auf Straßen getaggt werden und nicht auf barrier nodes stimmt so nicht. Es ist sehr wohl wichtig diese Barriere-Nodes mit entsprechenden access tags zu versehen um anzugeben ob diese für bestimmte Fortbewegungsmittel passabel sind oder nicht. So wie es derzeit getaggt ist wird diese Straße von Routern als komplett gesperrt für Autos betrachtet:
http://brouter.de/brouter-web/#map=14/47.8765/15.6919/standard&lonlats=15.671482,47.864051;15.695198,47.853775&profile=car-fast

Dass mit `access`=* nur die rechtliche Erlaubnis getaggt werden soll/darf entspricht nicht der Realität. Ob das idealerweise so sein sollte kann man sich streiten (dafür kommt die Diskussion aber Jahrzehnte zu spät). De-facto wird in den meisten Fällen bei access=* nicht wirklich zwischen rechtlichen und baulichen/physikalischen Beschränkungen unterschieden, sondern es besagt nur ob man mit einem bestimmten Fortbewegungsmittel durchkommt oder nicht. Das wird von absolut allen data consumers (i.e. Router) so gehandhabt.

Der Umstand dass es Situationen geben könnte an denen der Schranken sporadisch geschlossen ist spielt hier nicht wirklich eine Rolle (besonders wenn diese Situationen nicht vorhersehbar sind wie bei einem Unfall). Wenn der Schranken im Normalfall geöffnet ist, dann ist das so einzutragen. Ausnahmen können mit conditional tags (osm.wiki/Conditional_restrictions) eingetragen werden.

P.S.: Selbst wenn es nur um die rein rechtliche Situation gehen würde sollte diese auf Barrieren getaggt sein. Z.b. kann es Situationen geben wo eine Straße von beiden Seiten eines Schranken befahrbar ist (mit verschiedenen Einfahrten), aber nur bestimmte Personen diesen Schranken öffnen und hindurchfahren dürfen.

Ah entschuldigung, hat so ausgesehen als ob du hier das eine Gleis über das andere verschoben hättest. Hab mich wahrscheinlich verschaut

Hi,

Eins der Gleise die du hier eingezeichnet/verändert hast überlappt ein anderes bereits vorher bestehendes Gleis

way/264236406
way/33089569

lg

Hi, hab diesen changeset gerade erst bemerkt, daher der etwas verspätete Kommentar.
Ja, einfach nur die center node zu taggen ist 'ausreichend' für routing, aber die Ampeln einzeln zu taggen ist ebenfalls möglich und genauer (nicht redundant). Ich werde die einzeln getaggten Ampeln hier wieder herstellen.

lg, Woazboat

Ergänzung: Nicht nur die am Hauptplatz sondern auf quasi allen Plätzen in der Grazer Innenstadt changeset/111900184

Gleiches gilt für man_made=courtyard

way/85081255/history

Hi,
Du hast hier die Fußgängerzone von einigen Plätzen entfernt. place=square ist nicht gleichbedeutend und kein Ersatz sondern nur eine Ergänzung, d.h. highway=pedestrian + area=yes sollte nicht entfernt werden.

lg, Woazboat

Hi,
Wieso hast du denn hier die Fußgängerzone am Hauptplatz entfernt?

relation/3862445

https://pewu.github.io/osm-history/#/relation/3862445

lg, Woazboat

Hi, du hast hier in diesem Changeset ein paar public transport platforms verändert und die Tags von der platform node auf einen platform way verschoben (z.b. hier node/4123992755 -> way/419250569), jedoch leider ohne die dazugehörigen public transport route relations (z.b. relation/27176) zu ändern sodass sie die neuen platforms verwenden. (Habs inzwischen schon wieder gefixt)

lg, Woazboat

PS: Das OSM Inspector Tool kann beim arbeiten mit public transport routes recht hilfreich sein:

https://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=15.43348&lat=47.05706&zoom=17&overlays=ptv2_routes_,ptv2_routes_valid,ptv2_routes_invalid,ptv2_error_,ptv2_error_ways,ptv2_error_nodes

Fix public transport platforms/routes (josm bugged out and wouldn't let me add a changeset comment)

Hi, ja du hast recht. Ich war zwar vor kurzem dort (daher auch der neu eingetragene Kreisverkehr), aber den Zebrastreifen hab ich erst im Nachhinein nebenbei auf dem Luftbild gesehen und eingetragen da ich gedacht habe er fehlt. Hab jetzt auch nochmal auf Fotos nachgeschaut die ich dort in der Gegend gemacht hab und den Zebrastreifen gibt es wirklich nicht mehr wie du gesagt hast. Ich hab ihn jetzt wieder entfernt.

Welp, I just spent an hour writing a sizable comment in response only to lose it all because I acidentally clicked on a link while trying to resize the comment text box....

To sum it up:
I agree with the changes by @Friendly_Ghost and putting it into a single changeset. Changing `color` to `colour` is clearly correct with little chance of accidental harm. Having multiple spellings and variants of the same thing is harmful to OSM, leads to more unnecessary work for data consumers and has detrimental effects on the software ecosystem around OSM and the usefulness of the database as a whole. (Correcting for one mistake in software is fairly easy, correcting for hundreds is not. Things that could be fixed with a simple change like this in the upstream database have to be worked around a hundred times over in every single downstream application.)

Breaking up large changsets like this without any clearly disjoint clusters does not provide much benefit and has some clear disadvantages. Changesets exist to group changes that belong together. This benefit is lost when the changes are split up and understanding and working with multiple spread out changesets is much harder. Yes, having a changeset like this pop up in your feed when there's no acutal change in your area can be annoying, but the large bounding box cannot really be avoided when the changes actually are spread out across the world. Breaking up the changes into smaller areas does very little to avoid this as there will most likely still be one of these smaller changesets covering a particular area.

Eins noch, weil ich grad gesehen hab dass die Öffnungszeiten auch von dir eingetragen worden sind. Für Öffnungszeiten gibt es ein spezielles Format da sie maschinenlesbar sein sollten damit z.B. Apps automatisch erkennen können ob etwas gerade offen hat oder nicht.

opening_hours=*

Hier gibt es eine Website mit der man die Öffnungszeiten ganz leicht im passenden Format erstellen kann: https://projets.pavie.info/yohours/

Statt `täglich (kein Ruhetag) 10:00–22:00` würde hier `Mo-Su 10:00-22:00` passen

Telefonnummern sollten auch keinen '/' beinhalten, d.h. hier in dem Fall einfach `+43 660 700 2228` statt `+43 660/700 2228`.

phone=*

lg, Woazboat

Den Namenszusatz 'by Maykay' würde ich hier nicht in den `name`=* Tag schreiben. In `name`=* sollte der Name drinnen stehen der auch wirklich von Menschen verwendet wird wenn sie einen Ort benennen.

Den Zusatz `by Maykay` könnte man als `operator=Maykay` und/oder als `official_name=BOWLS & POTS by Maykay` eintragen.

lg, Woazboat

Servus!

Der `name`=* Tag sollte bitte nur für den wirklichen Namen eines Ortes eingesetzt werden. Zusatzinfomation wie 'derzeit geschlossen' gehören in die jeweiligen dafür passenden Tags.

lg, Woazboat