Supaplex030's Comments
Changeset | When | Comment |
---|---|---|
152420757 | about 1 year ago | Hallo IngoWo, das "is_sidepath"-Tagging wurde _genau deshalb_ entwickelt, weil es für Datenanwender nicht trivial ist, diese Information aus der Geometrie abzuleiten. Obwohl das Tagging noch nicht sehr weit verbreitet ist (da der "Entwicklungsprozess" noch nicht abgeschlossen ist), gibt es bereits verschiedene Anwendungen, die es benutzen (siehe osm.wiki/Proposal:Key:is_sidepath#By_applications). Ich selbst habe erst bei der letzten FOSSGIS ein Projekt vorgestellt, bei dem es um die Evaluierung der Radverkehrsqualität ist, wobei die "Straßenbegleitung" ein wichtiges Merkmal ist – und deren Ermittlung (ohne sidepath-Schema) derzeit etwa 95% der Rechenzeit verschlingt, um am Ende ein ungenaues, oft fehlerhaftes Ergebnis zu bringen. Aber ganz unabhängig davon ist es keine gute Idee, Tags zu löschen, die du für "überflüssig" empfindest. Denn OSM ist ein Community-Projekt und was nützlich ist und was nicht, darf jeder für sich selbst entscheiden. Wenn das zu "vielen" Tags an einem Objekt führt, dann musst du damit leben. (Das von dir beschriebene Phänomen einer Flut von access-Tags bleibt mMn davon unberührt, denn hier lässt sich tatsächlich häufig durch Verwendung der jeweiligen höheren access-Klassen "kürzen". Der Unterschied hierbei ist, dass kein Informationsverlust entsteht.) Es tut mir übrigens leid, dass es in Bremerhaven nicht so viele aktive Mapper gibt. Ich drücke dir die Daumen, dass sich das vielleicht noch ändert! lg, Alex |
151577964 | about 1 year ago | #bordsteinkantenlinienrichtung korrigiert, siehe https://resultmaps.neis-one.org/osm-discussion-comments?uid=9508237 |
151530421 | about 1 year ago | Hallo momabebra, du machst hier gutes Mapping, aber erneut musste ich viele deine Änderungen nachbearbeiten, da du systematisch viele Bordsteinkanten in die falsche Richtung zeichnest. Leider ist es nicht möglich, dich zu erreichen (vgl. die Historie deiner CS-Diskussionen: https://resultmaps.neis-one.org/osm-discussion-comments?uid=9508237), daher sehe ich mich gezwungen, noch einmal die DWG einzuschalten, bis du erreichbar bist, um dich auf solche systematischen Fehler aufmerksam zu machen.
|
151442452 | about 1 year ago | Hallo momabebra, wie schon öfter angemerkt hast du auch hier wieder Bordsteinkanten in falscher Richtung verwendet. Aber leider liest du ja keine CS-Kommentare...
|
151396227 | about 1 year ago | Hallo momabebra, wie schon öfter angemerkt hast du auch hier wieder Bordsteinkanten in falscher Richtung verwendet. Aber leider liest du ja keine CS-Kommentare...
|
138825033 | about 1 year ago | Hallo Bernd, danke für deine ausführliche Rückmeldung. Vielleicht kann ich noch ein paar Punkte aufklären: > warum sollte der Renderer auf der centerline darstellen, dass der Radweg separat gemappt ist cycleway*=separate lässt sich z.B. zur Generalisierung nutzen, insbesondere, da die Straßen ihre begleitenden Wege oft überdecken. "separate" wird dabei wie "track" behandelt. "Die beiden auf osm.org" tun das vielleicht nicht, aber anderen steht diese Option offen und ich habs z.B. schon selbst für Radkarten so verwendet. > ich habe auch schon diverse falsch getaggte Wege mit *:both gesehen Das mag sein, sehe ich auch regelmäßig. "Falsche" Daten (die sich korrigieren lassen, wenn es einem auffällt) sollte man aber mMn nicht mit "ungenauen" Daten vergleichen (die sich nicht korrigieren lassen, wenn man das Schema dafür nicht verwendet). > "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. Nein, dann interpretierst du die Daten falsch oder ungenau. "cycleway" gibt nicht an, wo du fahren darfst/sollst, sondern ist ein reines, richtungsabhängiges Attribut für Infrastruktur. Wo du fahren darfst/sollst, wird durch access-Tags angegeben. In diesem Fall ist durch "bicycle=use_sidepath" klar erkennbar, dass das Routing in beiden Fahrtrichtung über eine Nebenlinie stattfinden soll. Umliegende Geometrien müssen dafür nicht einbezogen werden (Router setzen einfach nur die Penalty für das Segment hoch oder schließen es sogar ganz aus). Aber nichts für ungut, du scheinst ja zumindest die Intention für das Tagging nachvollziehen zu können. lg, Alex |
138825033 | about 1 year ago | 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 |
138825033 | about 1 year ago | 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
(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...) |
151258052 | about 1 year ago | Hallo momabebra, du hast hier einige "public_transport=platform"-Linien gelöscht, obwohl es vielerorts/in Berlin üblich ist, die Wartebereiche der Bushaltestellen auch als Linien zu erfassen. Außerdem hast du einmal mehr Einfahrten gelöscht, die ich wiederherstellen musste. lg, Alex |
151158181 | about 1 year ago | So you identified the problem in the 5 meter long section at the southern end of the street, where the sidewalk geometry has already merged into the street, but is still tagged "sidewalk=separate" and "foot=optional_sidepath"? Then it would be appropriate to split the street line at this point, not to falsify the tags along the entire road section. Your change had no added value for the routing imho, as no "use_sidepath" was used here. But even if using "use_sidepath", a router that assumes a general ban instead of a strong penalty for such short sections should considered to be broken (there is currently a discussion about this in the community forum). With your change from sidewalk:right="separate" to "yes", on the other hand, you have effectively introduced a second sidewalk or duplicated data, which is definitely wrong. Regarding "optional_sidepath", of course thats an uncommon tag, but it seems to make sense to me here, as the street is a "living_street", so you can walk there, but there is also an optional sidewalk. In the bicycle context, "optional_sidepath" is often used in such situations, so it is logical to use it for pedestrian traffic as well (even if this situation rarely occurs). (Sorry for the harsh discussion, but I am more and more annoyed that remote mappers often edit already very detailed data with supposedly good intentions, but make it worse in the process.) |
151106072 | about 1 year ago | |
151098415 | about 1 year ago | Hi Daniela, you are obviously not aware that you have added your changes to the public OSM geodatabase or that OSM is not a database for private location markers. Please use other tools and services like "UMap" (https://umap.openstreetmap.fr) for this. I have already reverted the changes. Best, Alex |
151154168 | about 1 year ago | Hallo Ni26, ich habe diese Änderung rückgängig gemacht, da sie nicht der Art und Weise entspricht, wie Radwege in OSM üblicherweise erfasst werden. Der oben genannte Link von Stefan ist sicherlich ein guter Einstiegspunkt, um sich näher damit zu beschäftigen. Ansonsten vielen Dank für deine weiteren Beiträge zu OSM. Du scheinst die Anmerkungen zu deinen früheren Änderungen erhalten und überwiegend beherzigt zu haben. Wir freuen uns auch sehr über eine kurze Rückmeldung von dir :) Und weiterhin gilt, dass du dich gern bei mir oder anderen melden kannst, falls du Fragen hast oder unsicher mit einer Änderung bist. Gerade beim Einstieg in OSM kann und darf immer mal wieder ein Fehler vorkommen, umso wichtiger ist es aber, sich auch gegenseitig auszutauschen. lg, Alex |
151158181 | about 1 year ago | Once again I had to revert your "corrections" because they falsified correct or meaningful tags. Please stop blindly working through lists without dealing with the local situation (e.g. with street photos) or without trying to understand what mappers might have had in mind when tagging. In this case, I recommend wiki pages osm.wiki/Tag:sidewalk%3Dseparate and osm.wiki/Tag:bicycle%3Doptional_sidepath, which you could have found/be aware yourself. Alex |
150999074 | about 1 year ago | Hallo Ni26, du hast hier einige Adressen als Punkte ergänzt, die jedoch bereits an den Gebäudeflächen erfasst waren. Daher habe ich die doppelten Informationen wieder entfernt. Wie bereits bei einer früheren Änderung von dir jemand bemerkt hat: Bitte achte darauf, dass du keine doppelten Informatioen ergänzt. Falls du Fragen zum Mappen in OSM hast oder ich dich sonst irgendwie bei deinen ersten Schritten in OSM unterstützen kann, melde dich gern. lg, Alex |
150999898 | about 1 year ago | Hallo Ni26, herzlich Willkommen bei OSM und vielen Dank für deine aktuellen Beiträge! Ein Hinweis zu deinen Änderungen: Bitte lade nicht jede Änderung einzeln hoch, sondern lade Änderungen am besten erst dann hoch, wenn du in einem Gebiet ("Ergänzungen entlang der Stubenrauchstraße") oder mit einem "Thema" (z.B. "Bäume ergänzt", "Läden aktualisiert") fertig bist. Das würde es anderen deutlich einfacher machen, deine Änderungen nachvollziehen zu können und ggf. auf Fehler zu prüfen :) Beste Grüße
|
150938063 | about 1 year ago | P.S. Ich habe diese Fehler an dieser Stelle bereits korrigiert. |
150938063 | about 1 year ago | Hallo momabebra, auch hier in deinen Changesets entlang der Südostallee hast du systemtisch viele Bordsteinkanten in falscher Richtung gezogen (vgl. osm.org/changeset/150857735). Zudem hast du einige Straßenparkplätze als Flächen gemappt und sie als "Parkbuchten" ("street_side") getaggt, obwohl es sich um Parkplätze auf der Fahrbahn ("lane") handelt. Es wäre in diesem Fall zudem gut gewesen, die Parkrauminformationen an der Straßenlinie zu entfernen bzw. durch "parking*=separate" zu ersetzen, damit der Parkraum nicht redundant erfasst ist. Das wäre alles nicht so schlimm – wenn man dich erreichen könnte, um dich auf solche Fehlerchen aufmerksam zu machen, damit sie nicht immer wieder passieren. Aber das ist leider nicht möglich. lg, Alex |
150857735 | about 1 year ago | Hallo momabebra, eine der neuen Bordsteinkanten, die du in diesem Changeset erstellt hast, zeigt in die falsche Richtung: osm.org/way/1279479985 (Bordsteinkanten haben in OSM ein "oben" und "unten"). Da mir das in der Vergangenheit bereits häufiger bei dir aufgefallen ist, würde ich dich gern auf diesen (vermutlich versehentlichen) systematischen Fehler aufmerksam machen, aber leider ist das ja nicht möglich, da du nicht auf Changeset-Diskussionen eingehst... lg, Alex |
150805188 | over 1 year ago | Hallo MisterMapy, vielen Dank für deine vielen Prüfungen der Berliner Straßenbrunnen! Ein Kommentar zu deiner Änderung hier: Die drei von dir hier gelöschten Brunnen habe ich wieder hergestellt und mit dem in OSM gebräuchlichen Life Cycle Prefix "removed:" versehen, sodass sie als "ehemaliger Standort" weiterhin in der OSM-Datenbank bleiben. Siehe dazu auch hier: osm.wiki/DE:Berliner_Stra%C3%9Fenbrunnen#Nicht_mehr_vorhandene_bzw._abgebaute_Brunnenstandorte liebe Grüße
|