ManuelB701's Comments
Changeset | When | Comment |
---|---|---|
146290596 | over 1 year ago | m.M.n. ist hier eher das Problem, das die Multipolygon-Linien (d.h. die Linien, die das Multipolygon ausmachen) selber die "boundary=postal_code" behinhalten, was aber offiziell falsch ist, da dies nur für Flächen (u.a. das Multipolygon) aber nicht für Linien definiert ist und es für die Linien an sich zu verwenden, ist ein Missbrauch davon. |
146238796 | over 1 year ago | Hallo LWillms, eigentlich werden Stationen nicht auf den Gleisen platziert, dass wird nur für die eigentlichen Haltepositionen gemacht. Bahnhöfe und HaltePUNKTE (nicht zu verwechseln mit den eben genannten HaltePOSITIONEN) werden stattdessen mittig der Station platziert. Grüße
|
146218974 | over 1 year ago | Ich habe übrigens die Brücke wiederhergestellt, natürlich mit dem demolished-Präfix. ;) |
145688265 | over 1 year ago | Hallo Michael, danke dass du bei OSM beiträgst. Allerdings gibt es für OSM definierte Tags, die man bevorzugt nutzen soll.
osm.wiki/DE:Key:opening_hours
"description", "name" und "webseite" sind hierbei OK, für "note" würde dann nur "Kein Ladengeschäft." ausreichen. Außerdem gehören Büros zum angehörigen Gebäude und nicht auf irgendwelchen Wegen. Grüße
|
145654219 | over 1 year ago | Hello. This sounds like a bollard. You can either chose them in iD by specifically searching for it or modify the point where it's located with a "barrier=bollard". |
145505593 | over 1 year ago | Die Daten sind definitiv eingepflegt, es dauert aber eine Weile, bis die anderen Karten aktualisiert werden. Nach einen Tag sollten die Änderungen allerdings kommen (ggf. mit Strg+F5 aktualisieren). |
145505593 | over 1 year ago | Hallo. Beim Anpassen der Kreuzung Flakweg-Frankfurter Straße hast du anscheinend die Relation der Buslinie 820 (Regionalpark => Flörsheim) kaputt gemacht; es gibt eine Lücke in der Route am Anfang der Relation (gut an der Verkehrskarte erkennbar). |
138316922 | over 1 year ago | Beim Edit hast du anscheinend einen Teil der Pfälsischen Maximiliansbahn als "disused:railway=rail" gemappt, was m.M.n. so nicht korrekt ist, nicht nur weil der Syntax nicht Standard ist, sondern auch, dass die benutzten Gleise dann zu den anscheindend "unbenutzten" Gleisen führen und auch die Linien, die darauf fahren, wurden nicht aktualisiert (sehe die Stelle im OSM Inspector nach). Ich habe hierzu einen in einen Hinweis erstellt, wo ich mich darüber gewundert habe (und m.M.n. dort weitergeführt werden soll):
|
145269293 | over 1 year ago | Die Idee ist, dass Relationen in OSM sich nicht nur um Datengruppen handeln sondern eine Listen von Daten sind d.h. es gibt innerhalb der Relationen eine Reihenfolge von Elementen.
Allerdings muss man auch sagen, dass iD wirklich nicht für Routen gedacht ist. Als ich beim letzten mal eine Route in iD hinzugefügt habe (Bus 69 in Mainz über Nackenheim), so habe ich zwar einerseits die Reihenfolge für die Gegenrichtung sowie einigen Straßen nicht beachtet, vielmehr aber ist es viel schwieriger, diese Liste dann dort zu korrigieren, da man die Elemente einzeln manuell verschieben muss und nicht immer ist die gewünschte Relation sichtbar.
|
145269293 | over 1 year ago | Hallo Hugo. Bei der Umleitung hast du die ganzen Relationen kaputt gemacht, wo die ganzen Reihenfolgen durcheinander gebracht worden sind.
Liebe Grüße
|
144860025 | over 1 year ago | Was ich eigentlich meine ist, dass ich glaube, der zweite Doppelpunkt sowie der Strich vertauscht sind. |
144860025 | over 1 year ago | Sicher, dass 19:00:20-30 richtig sei? |
144629146 | over 1 year ago | Das habe ich lediglich beim Vorbeischauen bemerkt, JOSM wirft hier keine Fehler ab (lediglich für "shop=yes", weil es so ungenau ist). Allerdings gibt es in JOSM Vorlagen (u.a. bei den Merkmalen, über den Tags), wo solche probleme verhindert / -mindert werden können. |
144629146 | over 1 year ago | Hallo, du hattest für den shop-Key aus Versehen shop=clothing=women angegeben anstelle von shop=clothing und dann clothing=women angegeben. Das habe ich mal korrigiert, beim nächsten mal aber bisschen vorsichtiger sein. ;) Grüße
|
144439709 | over 1 year ago | Sind die neuen Gebäude alle Teile der existierenden Gebäude? Wenn ja, dann sollte hierzu building:parts verwendet werden. |
144460344 | over 1 year ago | Eigentlich gilt "parking:lane:*" als veraltet und sollte nicht verwendet werden. Was ich eigentlich meinte ist, dass der Syntax zwischen dem alten und neuen Format unterschiedlich ist und das reine Entfernen von ":lane" von "parking:lane:*" meistens nicht ausreicht (die einzige Ausnahme ist, wenn kein Parken existiert, da sind beide Formate gleich). |
144460344 | over 1 year ago | Eigentlich ist es Street Parking, was hier wichtig ist: osm.wiki/Street_parking Jedenfalls, was ich meine ist, dass im alten "parking:lanes:*"-Tagging zuerst die Orientierung angegeben wird wie z.B. "parking:lanes:both=parallel" und dann mit der Orientierung die Art des Parkens wie z.B. "parking:lanes:both:parallel=on_street". Beim neuen "parking:*" aber ist "parking:both=parallel" ungültig, ebenso existiert "parking:both:parallel" nicht. Stattdessen verwendet man "parking:both" für den Typ (z.B. "parking:both=on_street") und für die Orientierung dann "parking:both:orientation". |
144460344 | over 1 year ago | Ja... nicht ganz, da habe ich den gleichen Fehler gemacht, als ich bei Darmstadt, Mainz und Wiesbaden die Parking-Tags erneuert habe.
|
144291023 | over 1 year ago | Mehr Details: https://community.openstreetmap.org/t/unusual-and-not-documented-shop-values/106183 |
143510274 | almost 2 years ago | Da war ich tatsächlich zu unvorsichtig. Ich habe jedenfalls die ganzen "parking:*"-Tags nochmal überarbeitet, was somit größtenteils behoben sein sollte (abgesehen von den einigen Straßen, wo der Typ nicht gegeben ist). |