ticki_52's Comments
| Changeset | When | Comment |
|---|---|---|
| 182687105 | Hast Du schon diesen Datenbestand verarbeitet? -> https://umweltdaten.lubw.baden-wuerttemberg.de/repositories/geo_streuobsterhebung,1u23xqvenJF-caz88xUt/workbooks/Streuobsterhebung-Fernerkundung,3UdFlTdmfIZQiyPPRrD1/worksheets/Streuobsterhebung-Fernerkundung,VGyh47CdibLI6uQMQTHw?workbookHash=6vFMy0k87Z_N4_oOdWH7TRrtpm1i1R3X_fgUpBgER2rqr-hm&embeddingTargetId=streuobsterhebung-fernerkundung |
|
| 182687105 | Das Verständnis für diese Änderung hält sich bei mir in Grenzen, da ich derjenige war, der vor einigen Jahren das Tagging der Flächen vereinheitlicht hat , was unschwer zu erkennen gewesen wäre, wenn man sich die bestehenden CS angeschaut hätte. Eine Kontaktaufnahme mit mir, wäre sicher hilfreich gewesen, weil ich doch der Meinung bin, das Thema "Streuobstwiesen" vs. "Plantage" verstanden zu haben und aus dem Kartenmatieral BW DOP20 erkennen kann, um welchen Typ es sich handelt. Es gibt in der Backnanger Bucht nur wenige Flächen, die mit dem Primär-Tag "landuse=orchard" getaggt werden sollte. Eine davon ist z.B. way/107103300. Eine PROFESSIONELLE Anbeufläche der Firma Körner Obstbau in Backnang-Strümpfelbach. An diesem Beispiel ist unschwer zu erkennen, dass es sich nicht um eine Streuobstwiese handeln kann. Doch das Problem mit dem "Erkennen" der Flächen ist nur ein Thema im Zusammenhang mit den Streuobstwiesen. Ich kann Dir erklären, was ich meine, aber nicht in diesem Kommentar. Ich finde, dass das Ändern von landuse=meadow in landuse=orchard ein Fehler war und wieder zurückgeändert werden sollte. |
|
| 182687105 | Deine Massenänderungen an den Streuobstwiesen (landuse=meadow -> landuse=orchard) haben sicher einen Hintergrund. Kannst du diesen bitte mal darlegen? |
|
| 176707425 | ja, das hat BrummsLee wirklich elegant gelöste. Nochmal zu "noexit=yes": silversurfer schreibt zu noexit: "hat schon seine Berechtigung und wenn du ne Leiter brauchst um weiter zu kommen ist in meinen Augen Schluss." Deine augen trügen dich. danne geht es weiter mit "highway=ladder". Es ist wohl so, dass der Begriff "noexit" hier irreführt. Ich zitiere die englische Diskussionsseite zu noexit=yes: "Der beste Weg, die verschiedenen Missverständnisse zu beenden, ist, es gar nicht zu benutzen". |
|
| 188570823 | "Die Sache mit den Adressen" ????Kann ich bitte erfahren, was hiermit gemeint ist und eine Begründung, warum mein Tagging nicht passen soll.... |
|
| 188570823 | General accusations do not help to clarify the issue. Please specify which address you believe was incorrect.
|
|
| 185985772 | Hallo Matt, ich glaube, dass ich herausgefunden habe, warum das Routing bei BK-West spinnt. Der westliche Teil der neuen Brücke ist mit "access=no" getaggt und die zwei nachfolgenden Abschnitte in Richtung BK-Mitte auch. Es könnte sein, dass dieses Tagging den OSM-Nagivator durcheinander bringt. Könntest Du das bitte beheben und mir Bescheid geben, wenn die Änderung durch ist.... ich checke das dann gleich mal. |
|
| 187024214 | "Verboten"? Hab'ich irgendwo "verboten" geschrieben. Im OSM ist nichts verboten, sondern maximal "discouraged". Dieses Vorgehen ist Teil des Problems, dass jeder macht, was er will und wie er will. Zurück zur Initialen Frage von karaga: "why are you removing addresses from POI?" Für mich ergibt es keinen Sinn, an einem Einzelfall eine generelle Fehlentwicklung aufzuzeigen. Also gaaanz von vorne: Am Anfang war der Bauantrag und dann kam die Baugenehmigung (Roter Punkt) und damit wurde die offizielle Adresse des Bauwerks veröffentlicht. Der ausfmerksame Mapper wird nun, da er das neue Bauwerk sehscharf als osm-relevant erkannt hat, mit seinen Eigenschaften UND SEINER ADRESSE erfassen. Und dann, irgendwann, wird in dem Gebäude vielleicht ein Secondhandladen eröffnet und der aufmerksame Mapper bildet dies mit einem POI ("shop=clothes + second_hand=yes + name =*") korrekterweise OHNE Adressdaten ab, die ja schon seit Jahren beim Gebäude getaggt sind. Dieser Shop schließt wieder. Was ist im OSM zu tun? Es wird "disused:shop" getaggt und alles ist gut. SO SOLL ES SEIN! Was wäre zu tun, wenn die Adresse nicht am Gebäude getaggt ist, sondern am POI. Es müssten die Adressdaten vom POI auf das Geäude übernommen werden, da das Gebäude historisch ja KEINE Adressdaten hat. Ohne Adressdaten läuft die Adressermittlung der Navigatoren ins Leere. Ich möchte an dieser Stelle ausdrücklich darauf hinweisen, dass ein Hauptnutzen der Arbeit im OSM bei Navigieren auf Straßen entsteht. Im Übrigen möchte ich im Zusammenhang mit der Beanstandung von Karaga wegen Entfernung von Daten auf den Passus im Wiki zum "key:shop" -> Adressinformationen hinweisen:
|
|
| 187024214 | "Gelebte Praxis"= je öfter fehlerhaftes Mapping und Tagging vorkommt, desto eher werden diese Fehler toleriert. "Gelebte Praxis" ist für mich schlichtweg die permanente Weigerung bzw. Faulheit, bekannte Fehler zu korrigieren und stattdessen zum Standard zu erheben. Wer so denkt, der kann das OSM-Wiki gleich in die Tonne klopfen. |
|
| 187024214 | Adressdaten für genehmigungspflichtige Gebäude werden behördlicherseits mit der Bekanntgabe der Baugenehmigung vergeben. Adressdaten gehören also per Definition zum Gebäude, wie schon der Begriff "HAUSnummer" (engl. housenumber) sagt. Die doppelte Angabe von Adressdaten beim Gebäude UND beim POI oder nur beim POI, wenn es eine offizielle Hausnummer für das Gebäude gibt widerspricht der osm-regel "one feature - one element" und ist m.E. "tagging for the renderer". Der POI soll nur Daten enthalten, die den POI beschreiben und KEINE Adressdaten. So habe ich das im Raum Backnang getaggt und es sollten sich andere Mapper daran halten. Zug um Zug werde ich im Raum Backnang dieses Tagging vereinheitlichen und OSM-konform halten. |
|
| 187436562 | Dieses Chaos soll nicht in jedem Detail im OSM nachgezogen werden, aber die B14-Routenführung von BK-West bis BK-Mitte sollte schon funktionieren und wenn's auf dem Stand VOR den Bauarbeiten ist und wenn's dir an Zeit mangelt, dann würde ich das mal versuchen... |
|
| 187436562 | Hallo MattGPS, aktuell ist die Routenführung in diesem Bereich unterbrochen. Hängt wohl damit zusammen, dass das östliche Viadukt eingebunden ist, welches ja bis auf weitres nicht befahrbar ist. Der gesamte Verkehr wird über das (alte) westliche Viadukt geführt. Kannst Du Dir das mal anschauen? Gruß ticki_52 |
|
| 187024214 | Because there are TWO pois with the same address and adress data belong to the plot of land/building and not to pois like companies. "covered" corrected. |
|
| 186502968 | Vielen Dank für Deine Sichtweise.
|
|
| 176707425 | Hallo, habe mir das Mapping der Packstation mal angeschaut. Es sind auf zwei geneüberliegenden Seiten Boxen und diese sind jeweils als Packstation 115 gemappt. Vielleicht eher einen Node setzen.... |
|
| 186506224 | Nur weil OSM-Cha das als Fehler ausgibt, heißt das doch nicht, dass es sich um fehlerhaftes Tagging handelt. Die beiden Nodes sind an die Stelle gesetzt, wo sich innerhalb des Gebäudes sich die einzelnen Funktionen befinden. Das ist doch eine Information, die durchaus hilfreich sein kann. Also warum soll man diese weglassen? |
|
| 186387208 | wo hier? |
|
| 182659961 | Hallo MattGPS, die Wende kann nicht als Taxistand genutzt werden. Die beiden Fahrbahnen sind mit durchgezogenen Linien (und Pflanzkübeln) getrennt. Nur an der Wendestelle sind die Linien auf 4 m durchbrochen und eine Fahrbahnmarkierung "Taxi" ist angebracht. Andere Hinweise gibt es nicht. Btw: In Backnang ist der Haupt-Taxiwartestand am Bahnhof. An der Bleichweise warten nur noch bei besonderen Anlässen Taxis. Bei Anruf kommt das Taxi in der Regel vom Bahnhof zur Bleichwiese gefahren. (Sind ja bloß ein paar Minuten). |
|
| 186172937 | Ich habe das korrigiert, weil ein Taxistand als "node"zu taggen ist und nicht als Fläche. der node ist zu setzen an der Stelle, wo das erste Taxi in der Reihe wartet (bzw. warten würde.) Die Anzahl der maximal wartenden Taxi-Fahrzeuge wurde mit capacity=6 angegeben. Der separate weg ist notwendig, weil nur die Taxis rechts an den Pollern vorbei auf die Obere-Bahnhof-Straße ausfahren sollen. |
|
| 131585092 | 1. Das Tag natural=tree_row ist für andere Fälle vorgesehen.
|