OpenStreetMap logo OpenStreetMap

Changeset When Comment
130998644 almost 3 years ago

Hi, you are changing a lot of place names across the US but you didn't provide a source for these changes.
What's the basis for these edits?

Regards, Woazboat

126546847 almost 3 years ago

Hi, please don't attach residential landuse (or any landuse really) to roads. It makes things much harder to edit.
lg, Woazboat

118859431 almost 3 years ago

Hi,

du hast hier in diesem Changeset einige Wege und Überquerungen hinzugefügt die (teilweise) bereits vorhandene Wege/Überquerungen duplizieren. Bitte achte darauf ob es schon bestehende Objekte gibt die man wiederverwenden kann/sollte.

Parallel laufende Rad- und Fußwege sollten nur getrennt gezeichnet werden wenn sie durch eine physische Barriere getrennt sind

lg, Woazboat

128697025 about 3 years ago

s/operator/brand/ , wobei hier beides gleich ist

128697025 about 3 years ago

> (...) dass Kunden in erster Linie nach "nextbike" suchen und nicht nach dem Standort.

Das ist aber immer noch kein Grund "nextbike" als Namen zu setzen. Das wäre falsches Tagging. Apps/Suchmaschinen können genauso gut nach `amenity=bicycle_rental` + `operator=<xyz>` suchen. Auf z.B. Bankomaten wird die betreibende Bank auch als `operator`=* getaggt und nicht als `name`=*.

128697025 about 3 years ago

Der Anbieter (e.g. "nextbike") gehört in den `operator`=* Tag und nicht in den Namen. Wenn kein expliziter Name für eine bestimmte Station angegeben ist dann gehört einfach keiner gesetzt (bzw. `noname=yes`)

125373826 over 3 years ago

Your interpretation of "there are no banned tags" is incorrect. It does not mean that you are free to add whatever nonsensial tags you like. What it means that you can add any information that is (among other things but most importantly):

1) Verifiable
2) Useful (i.e. actually provide meaningful information)
3) Accepted by the community
(This does not mean that absolutely everyone has to agree or even pre-approve, but it should at least follow local conventions. It also doesn't mean that you always have to ask first before inventing new tags, but if you don't you need to be prepared for pushback and disapproval like in this case)

125373826 over 3 years ago

> seek community consensus for this. Then you may make the change again.

Adding my 2 cents here to support the removal of `service=driveway2`. It does not provide any value whatsoever and does not convey any additional information. All service ways that can be considered drveways should be tagged with the already existing and widely accepted tag `service=driveway` and those that are not should NOT be tagged simply for the reason of having a `service`=* tag. The notion that "every `highway=service` absolutely needs to have a `service`=* tag" is plainly wrong. If there is some additional or extended classification of service roads that allows for more fine grained distinction and **actually means anything**, then sure, go ahead and tag that (after consultation with the community). `driveway2` does not fall into that category. (What is the 2 even supposed to mean?)

79446766 over 3 years ago

Um das Renderingproblem hier aufzuklären: `shop=supermarket` war gar nicht eingetragen. Ich hab's jetzt ergänzt.

122721699 over 3 years ago

Hmmm, I can't see anything on the aerial images that looks like a farm or farmland but I could be wrong.

In other places there's nothing left ( e.g.node/9839367684) which is why I retagged it to place=locality.
abandoned:place=farm would probably be better if there really was farm there at some point, but I didn't think of that at the time. place=farm is supposed to be for farms that are still in use, so I don't think it's the correct tagging for cases like this.

node/2399403377 should simply be merged with relation/7828912

122721699 over 3 years ago

node/2399403377 this also isn't really a `natural=bay`

122721699 over 3 years ago

Hi, I think your import has a few problems. A ton of locations are tagged as `place=farm`, which is clearly incorrect and sometimes duplicates already present information (e.g. node/9839367685)

110469259 over 3 years ago

Hi, amenity=ferry_terminal ist hier wohl etwas fehl am Platz. Für einen Fährhafen ist die Mur doch etwas zu klein. (Und SUPs als Fähren zu bezeichnen wäre etwas gewagt)

way/977911227

lg, Woazboat

120244540 over 3 years ago

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

119608497 over 3 years ago

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

83114963 over 3 years ago

@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.

110009868 over 3 years ago

Daten aus diesem changeset wurden in changeset/119448104 teilweise wiederhergestellt

110108795 over 3 years ago

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

83114963 over 3 years ago

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.

118083928 almost 4 years ago

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