Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 09:26, schrieb Georg Feddern: Wären alle dafür notwendigen Flächennutzungen bereits definiert, eingetragen und auch noch an den passenden Stellen parzelliert, wäre es möglich, diese Informationen daraus abzuleiten - so existiert aber in meinen Augen derzeit durchaus ein Bedarf für solch eine Zwischen- bzw. Näherungslösung. +10 das ist genau das, was ich Martin darauf schrieb.. Eine Erfassung des place-polygons kann nur als /Zwischenlösung/ Sinn machen, wenn es an landuse=* /mangelt/. Weil es schnell gehen soll, behebt man nicht den Mangel, sonder begnügt sich mit dieser Näherung. Das ist ok, aber in einem größeren zeitlichen Kontext ist es verschwendete Zeit, weil OSM ja die Erfassung des landuse=* prinzipiell schon will. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:15, schrieb Martin Koppenhoefer: -1, ich würde nicht reinschreiben, was _nicht_ erfasst wird, sondern das, was erfasst wird. Ja, da bin ich eigentlich bei Dir. Evtl. macht aber eine Definition von beiden Seiten (was wird eingeschlossen, was wird ausgeschlossen) Sinn, gerade dann, wenn man mit der einschließenden Definition des Begriffs fuzzy bleibt. Zudem weiß ich schneller was gemeint ist, wenn sowohl Beispiele für einschließend, als auch ausschließend gegeben werden. Denn ich muss mir gewisse Ausschlüsse nicht aus der einschließenden Definition ableiten. _Vorrangig_ zum Wohnen verwendet Grenze dort, wo vor Ort beobachtbar die Flächennutzung wechselt sind einschließend, aber das damit die admin.-rechtl. Grenze ausgeschlossen ist, muss ich mir erst überlegen. Admin-rechtliche Gebiets- und Flächengrenzen sind in X besser aufgehoben. +1, das steht da auch schon klar drin: sie werden mit boundary=administrative und admin_level getaggt. Gebietsnamen werden üblicherweise über place nodes getaggt. -1. Sie können als place Node oder area getaggt werden. Ein _Gebiet_ nur als Node zu taggen beinhaltet immanent einen gewissen Grad von Unvollständigkeit. Ich bezog mich auf amtliche Gebietsnamen.. In der gesamten mail. Sorry, dass ich es gerade in diesem Satz nicht nochmal explizit erwähnt hatte - mein Fehler. Und amtliche Gebiete zu erfassen ist unsinnig, wenn Du schon ein +1 oben setzt. Nur darum geht es. Wie die Siedlungsfläche, als nicht-amtliches Gebiet besser über die landuses-Relation erfasst wird, hatte ich auch schon geschrieben - aus Mangel an landuse-Daten kann ein place-polygon hier /temporär/ Sinn machen. Andere nicht-amtliche Gebiete, die auch keinen bekannten Bezug zu anderen Daten haben, können gerne als place-polygon erfasst werden. Dem hatte ich mich bei place=locality schon teilweise angeschlossen. Diese place Grenzen stellen dann ja auch keine Dopplung zu anderen Daten dar. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:35, schrieb Martin Koppenhoefer: Christian, da Du gerne die Wikipedia zitierst hier 2 Links, die Dich interessieren dürften: http://de.wikipedia.org/wiki/Stadtviertel Ein Stadtviertel ist ein überschaubares, häufig nur aus einigen Straßenzügen bestehendes, soziales Bezugssystem, das sich sowohl räumlich/geografisch als auch von der sozialen oder ethnischen Struktur seiner Bewohner her von anderen Stadtvierteln abgrenzt. Eine offizielle Grenzziehung existiert dabei meist nicht. Das Gebiet wird durch seine Bewohner definiert und ist unabhängig vom Gebiet eines Stadtteils oder Stadtbezirks. analog würde ich auch Wohngebiete auf dem Land sehen. würde ich -- das ist deine Sichtweise.. wir wollen aber das, was allg. verständlich und anerkannt ist. Die Wikipediadef. zu 'Stadtviertel' deckt sich mit OSMs Sichtweise. Dort heißt es in der Regel nur statistische oderhistorische Unterteilung / mostly statistical, historic Ein Problem ist, dass der Wikipedia-Teil durch seine Bewohner sicherlich für die Begriffsdefinition des Stadtviertels taugt, aber eigentlich nicht für die Erfassung geografischer Daten. Streng genommen, kannst Du die Stadtviertelgrenze dann erst eintragen, wenn Du weißt, das die Bewohner einen Konsens über ihren Verlauf haben. Sonst trägst Du /deine/ Realität ein, die in OSM aber behauptet /allgemeingültig/ zu sein. An der Stelle ist die Erfassung der Realität für einen Mapper immens schwer, denn er muss nicht nur eine Person, sondern mehrere des Stadtviertels befragen, um zu sehen, ob sich Aussagen decken. Die Erfassung nicht-gegenständlicher und zugleich nicht-amtlicher geografischer Information bedeutet also, will man es ordentlich machen, viel Arbeit. Es steht glasklar da: Eine offizielle Grenzziehung existiert dabei meist nicht. Da OSM weder Malen nach Zahlen noch meines Erachtens oder wir würfeln eine Grenze aus ist, hat eine Grenze, die nicht offiziell existiert, auch nichts in OSM verlorenund schon gar nicht im namespace border=_administrative_ Da wäre dann wohl border=residential_guess angebrachter. In aller Regel wird aber eine offizielle Grenze für die meisten Stadtviertel tatsächlich existieren, gerade wenn ein Amt zu Statistik für ein Stadtviertel erstellt. Zweiter Link: http://de.wikipedia.org/wiki/Ortsteil Ortsteil, je nach Art der Gebietskörperschaft (Verwaltungseinheit) auch Stadtteil, Gemeindeteil, Ortschaftsbestandteil oder Fraktion, ist in Siedlungsgeografie, Demographie und Raumplanung ein unspezifischer Sammelbegriff für abgegrenzte und mit eigenem Namen versehene Teile einer Siedlung (einem Ort, einer Ortschaft im allgemeinem Sinne). Ja, ist so allgemein gehalten, dass es unser beider Auffassungen nirgendwo im Weg steht. /Wodurch/ abgegrenzt wird, und /wer/ Namen vergibt ist im einzelnen zu betrachten. Und wenn von einer Verwaltungseinheit gesprochen wird, so fängt der Satz an, dann doch bitte durch die Verwaltung.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:24, schrieb Martin Koppenhoefer: -1, diese schmale Flächenverbrauchsseite in der Wikipedia, ohne vernünftige Quellenangaben, ist für mich nicht die Bibel. Da Du Wikipedia's Defintion von Flächenverbrauch nicht traust, schaust Du vielleicht mal auf die Seite des statistischen Bundesamtes dazu: http://www.destatis.de/jetspeed/portal/cms/Sites/destatis/Internet/DE/Content/Statistiken/Umwelt/UmweltoekonomischeGesamtrechnungen/Flaechennutzung/Content75/FlaechennutzungInfo.psml Auch keine Bibel, aber sehr viele Leute, die sich auf eine Begriffsdefinition geeinigt haben, wo Du dein eigenes Bier braust. (im Zusammenhang bebaute Ortsteile). steht der sezifischeren Def. nicht entgegen. Je nach Sinn und Zweck bzw. Kontext sind die Kriterien teilweise unterschiedlich. Wir erfassen bisher keine Verkehrsflächen explizit, daher sollte unsere Siedlungsgrenze auch nicht darauf aufbauen. Place ist unser Tag für Orte. Die können gesetzlich normativ definiert sein, müssen das aber nicht. Es reicht, dass es sie gibt. Nochmal, willst Du die Realität abbilden oder eine erfinden? In ersterem Fall hat man sich nunmal an ein paar Konventionen zu halten. Sonst schreib halt Fantasy-Computerspiele.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 12.09.2011 13:24, schrieb Martin Koppenhoefer: ..Fantasy-Computerspiele.. Das war etwas arg pauschal, sorry. Meistens mag ich es nicht, wenn meine Argumente mit solchen pauschalen Aussagen weggewischt werden, hier also nochmal kurz die Beweggründe hinter dieser Aussage: - Siedlungsgeografie erfassen: ja - admin.-rechtliche Grenzen erfassen: ja - die unscharfe Grenze eines Stadtviertelbewohners aufnehmen: wenn's sein muss Aber eben bitte so, dass das unterscheidbar bleibt, als Datennutzer will ich doch wissen, wo welche Daten herkommen, bzw. in welchem Zweck bzw. Kontext sie stehen. Ich kann doch nicht alles unter einem Tag zusammenmanschen, schließlich sollen die Datennutzer kreativ werden, bei dem was sie mit den Daten anstellen, nicht die Datenerfasser. D.h. - für die Siedlungsgeografie den wiss. Definition folgen und nicht neue erfinden, dieser Begriff entstammt doch schon einem Spezialgebiet! - welche zwei Laien unterhalten sich über 'Siedlungsgeografie' ohne wenigstens den Anspruch daran zu haben, dieses wiss. Gebiet einigermaßen greifen zu können? - für admin.-rechtliche Grenzen border=administrative verwenden - dokumentieren, welche place values amtl. Anspruch haben, welche nicht - da place amtl. und nicht-amtl. mischt - unscharfe Grenzen geeignet taggen, damit erkennbar bleibt, dass das die Auffassung des Mappenden ist, ohne Anspruch auf eine sonstige Korrektheit Wenn wir bei OSM Dinge mischen wöllten, die so lala zusammengehören, anstatt sauber auszudifferenzieren, dann wäre die Ausdifferenzierung eines highways auch nie begonnen worden, da reicht ja dann: hier verläuft ein Weg welche Art Weg interessiert nicht, es kommt nur darauf an da ist ein Weg Was interessiert, sollte, so als Zielvorstellung, der Nutzer bestimmen (können). Es ist also nicht verkehrt, Struktur zu suchen und zu dokumentieren, wo sie existiert, anstatt die Hände in den Schoß zu legen und zu meinen das grobe wird dem Nutzer schon reichen. Wer das grobe erfassen will, weil er nicht mehr Infos hat, der nutzt, um bei highway zu bleiben, highway=road Damit ist anderen Mappern klar, wie genau diese Information ist - nämlich sehr grob, ein Platzhalter für jemanden der dort weitermappen will. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Hi, Am 11.09.2011 16:11, schrieb Martin Koppenhoefer: Ist die Folge von was anderem: die Einteilung die wir haben spiegelt die amerikanische Realität wieder, daher haben wir in Deutschland Probleme. Wir hätten bei einem deutschen Schema neben industrial was für Gewerbegebiet erfunden. Könnte man nachträglich z.B. mit einem Zusatztag zur Intensität (light/heavy) oder so lösen. +1 siehe ISIC, könnte evtl. alle glücklich machen.. Frage ist, wie values auf landuse=grob grob=detail verteilt werden. Mir ging es noch nie um Bau in dieser Diskussion, sondern immer um Bestand. Planungen mit der Realität im selben Tag zu mischen halte ich für einen großen Fehler, weil es eben diesen Unterschied verwischt. +1 ich meinte mit Baufläche auch nicht construction sondern bebaute Fläche ..Meint 'Baufläche' im amtsdeutsch denn nur geplante Fläche? Mein Eindruck war, dass Baufläche keinen zeitlichen Bezug hat, also sowohl bebaute Fläche, als auch zu bebauende Fläche. Demnach wären dann Bauflächen in Planung für landuse auszuschließen, oder so etwas wie: landuse=meadow proposed=residential wenn der Mappende mehr weiß. Die Antwort auf die Frage, ob Flaechen an Ways geklebt werden sollen, ist eine Geschmaeckssache. es gibt klar Vor- und Nachteile bei beiden Vorgehensweisen. Die wurden inzwischen weitgehend in diesen Threads der letzten Wochen erörtert (vor allem zu Beginn) und jeder kann sich selbst überlegen, was er für wichtig hält. Ich denke, das nach einer besseren Ausdifferenzierung der Tags dazu mehr Klarheit 'entsteht'. Flächennutzungsgrenzen an andere Flächennutzungsgrenzen zu kleben ist gängige Praxis, daraus lässt sich für das Wiki ableiten, dass Flächennutzungsgrenzen dort sind, wo Nutzungsarten wechseln. Bis landuse=traffic erfasst wird, wäre das Kleben an highway=* übergangsweise 'ok'. Um landuses nicht übermäßig zu fragmentieren, kann landuse=traffic über anderen landuse=* liegen (IMHO, dazu hat sich bis jetzt niemand geäußert). Damit bleibt die Frage beantwortbar, ob die Telefonzelle im Park oder an der Straße steht, obwohl der Park links und rechts der Straße als ein landuse-polygon erfasst wird. Der anfangs zitierte Straßengraben kann als line oder area innerhalb landuse=traffic liegen, sollte aber ein anderes Tag bekommen, denn das Entwässerungssystem gehört zur Verkehrsfläche, ändert also den landuse=* nicht. Da gab es 'ditch' irgendwo.. Wer das Kleben mit seinem Editor als mühsam oder schwer umsetzbar empfindet, schreibe bitte einen Bugreport für josm/portlatch/merkaartor. Wir taggen nicht für Editoren, wenn ich das mal von wir taggen nicht für Renderer adaptieren darf. +1. Da steht, dass man eine Fläche, die überwiegend durch Wohnen genutzt wird, als landuse=residential taggen soll. Das dass aber ein Wohngebiet im siedlungsgeographischen Sinne sei steht da nirgends, zumindest nicht auf der englischen Seite des wiki In der Tat ist die englische Seite dazu besser, als die deutsche - da wird von Mischgebieten, Wohngebieten usw. gesprochen - diese Begriffe sollten dorft maximal stehen, um von Ihnen abzugrenzen. An area of land mit Gegend zu übersetzen, anstatt Gebiet schließt Missdeutungen hin zu amtl. Gebiet eher aus. Fluren und Gemarkungen fallen in den Themenkreis Toponyme und sind zusätzliche Informationen in einer anderen Ebene als administrative Grenzen oder Bodennutzung. Es geht nicht darum, das Mappen einfacher oder komplexer zu machen, sondern diesen Aspekt der Realität abzubilden. +1 Mir war insbesondere wichtig, dass nicht mit der Bodennutzung zu vermischen. Dennoch sollten Fluren und Gemarkungsgrenzen als administrative Grenzen erfasst werden, sofern sie noch aktuell im Kataster liegen. Die Toponomastik ist die Ortsnamenkunde _beliebiger_ geografischer Objekte (lt. Wikipedia). Ortsnamenkunde bringt uns insbes. in einem geschichtlichen Kontext weiter; z.B. wenn es um Grenzstreitigkeiten geht, es hilft uns aber wenig bei der Ermittlung von Grenzen der Realität, wie sie jetzt real vorhanden sind. Ich lehne mich mal etwas aus dem Fenster und behaupte, dass Du zu jedem amtl. Ortsnamen des Katasters Ortsnamenkunde betreiben kannst. Das ist siedlungsgeografisch und historisch eine interessante Angelegenheit, aber für OSM momentan einfach zu weit weg vom Tellerrand. Für nicht-amtl. Ortsnamen hingegen ist evtl. nur über die Ortsnamenkunde ein Grenzverlauf ermittelbar - ein Mapper muss halt abwägen, welche Ressourcen er da hat. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 10.09.2011 22:42, schrieb Frederik Ramm: (*) landuse=* ist _nicht_ an einen admin.-rechtlichen Raum gekoppelt (reale Flächennutzung ohne Katasterbezug, Flächengrenzen dort, wo der Mapper den Wechsel der Flächennutzung vermutet/beobachtet) Was davon ist denn realistisch durch eine Horde von Mappern, die nicht gerade beruflich/ausbildungstechnisch mit Landvermessung zu tun haben, umsetzbar? Was entspricht am ehestem den Bauchgefuehl, nach dem Mapper vorgehen werden? Doch nur die mit * bezeichnete Variante. +1 siehe letzte mail. das entspricht exakt meiner meinung. nur müsste es dann eben auch so dokumentiert werden und nicht anders. Allein schon ueberhaupt einen Unterschied zwischen Gebiets- und Flaechennutzungsgrenze zu machen, ist etwas, womit man 95% der Mapper ausschliessen wuerde, denen das dann naemlich zu kompliziert wird. -1 Es gibt Mapper denen das egal ist und immer sein wird - da stimme ich Dir zu. Das sind dann aber nicht die Mapper, die längere Zeit Flächennutzungen erfassen. Macht man das längere Zeit, keimen automatisch die Fragen hoch, auf die wir hier eine Antwort suchen. Die Realität abzubilden erfordert einen gewissen Entdeckergeist. Ich nehme doch nicht das Datenmodell her und erfasse dann systematisch Dinge der Realität, die ich mit dem Datenmodell erfassen kann. Ich kann nicht für andere sprechen, aber für mich war das Wesen von OSM bisher eher: Ich entdecke Dinge in der Realität, indem ich sie mit offenen Augen durchschreite, und trage sie /danach/ in OSM ein. Dazu informiere ich mich /dann/ im Wiki oder anderen Quellen, /wie/. Die Informationsquellen sind aber eben an vielen Stellen unklar, bzw. verbesserungswürdig. Nach meinem Verständnis gibt es da auch kein feature-freeze, denn das würde ja heißen, das jemand behauptet, das bisherige Modell reichte aus, um alle Dinge der Realität widerspruchsfrei zu erfassen. Jeder Mapper kommt im Prinzip mit einer Information oder einem Sachverhalt der Realität und schaut /dann/, wie es am besten in die DB aufgenommen werden kann. Dazu konsultiert er die Dokumentation, i.e. Wiki oder Vorlagen. Wenn dann also widersprüchliche Dinge mit demselben Tag erfasst werden, liegt die Schuld nicht beim 'Durchschnittsmapper', sondern an mangelnder Vorstellungskraft oder mangelndem Wissen des Wikifiddlers. Das ist kein Vorwurf, niemand ist perfekt. Der Vorwurf ist hier, dass es nicht weitergeht, wenn besseres Wissen da ist. Anders gesagt, ein Kolumbus eines weißen Landstrichs wird sich für die nähere Ausdifferenzierung auch zukünftig nicht interessieren. Jahre später haben sich die Dinge aber weiterentwickelt und während es dann immer noch weiße Landstriche gibt, in denen eine Ausdifferenzierung nicht gebraucht wird, gibt es andere, in denen Kreativität mit mehr Struktur befördert wird. Jetzt mal ganz ehrlich - WER behauptet, alle Tags des OSM-Universums zu kennen? Ist es nicht vielmehr so, dass sich ein Mapper im Laufe der Jahre auf das Subset spezialisiert, dessen Erfassung ihm wichtig ist? Ich kenne mich z.B. mit dem deutschen Stromnetz überhaupt nicht aus, dennoch erlaubt das Datenmodell die Erfassung von Spannungsdaten, Generatorentypen und weiß der Geier was: Da kräht auch niemand danach, auf dem Boden zu bleiben oder hat Angst, dass ein mehr an Struktur 'Durchschnittsmapper' (gibt es ihn überhaupt?) vergraulen könnte. Es geht auch nicht darum, im Wiki Regeln aufzustellen, die für jedermann verbindlich sind. Es geht um eine Guidline, eine Empfehlung, der Mapper folgen können, wenn sie - nicht weiter wissen - selbst einen Anspruch an Genauigkeit haben - selbst Strukturtiefe suchen - Dispute lösen wollen Diese Mapper sollen Antworten im Wiki finden und zwar korrekte, brauchbare und, wenn gewünscht, beliebig genaue. Oft wird das Wiki auf Mailinglisten zitiert, es stellt also schon auch eine gewisse Referenz dar und sollte deshalb möglichst nicht Widersprüche in sich beinhalten oder Begriffe neu definieren, die in ihrem geografischen Sinn gesellschaftlich und rechtlich bereits genau definiert sind. Ich schreibe sollte, weil die Ressourcen der Community auch begrenzt sind, aber anpeilen lässt es sich zumindest. Solche Konstrukte lassen sich langfristig in OSM nicht durchsetzen, sie wuerden eine voellig andere Projektstruktur erfordern; eine, in der Eintrittsbarrieren nicht weiter verringert werden (wie das fuer OSM immer wieder gefordert wird), Das sehe ich völlig anders. Gerade eine Ausdifferenzierung /ermöglicht/ es doch, die Eintrittsbarrieren zu verringern. Am konkreten Beispiel: - wenn reale Flächennutzung gemappt wird, können in der Definition rechtlich-admin. Sachen explizit ausgeschlossen werden - ein Mapper der nur die Flächennutzung mappen will, muss sich weder um admin. Gebietsnamen, noch admin. Gebietsgrenzen Gedanken machen - die Eintrittsbarriere wird deshalb einfacher, weil die Definition der
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 11.09.2011 02:40, schrieb Frederik Ramm: Die, die sich fuer mehr interessieren, koennen ja auch mehr mappen. Sie koennen bloss nicht erwarten, dass, die, die sich nicht dafuer interessieren, sich an komplizierte Regeln halten. Ja, aber die, die mehr mappen, können von denen die weniger mappen schon erwarten, dass ihre Arbeit erhalten bleibt, oder? Das gleitet langsam in die Diskussion ab, ob Raucher den Nichtrauchern im Lokal Rechte wegnehmen, schließlich kann der Nichtraucher doch auch draußenbleiben. Andersrum wird ein Schuh draus: Wenn die Struktur der 'komplizierten Regeln' (Zauberei ist nur, was man nicht weiß) im Wiki dokumentiert ist, haben alle Mapper die Möglichkeit in einem dicht bemappten Gebiet Informationen hinzuzufügen oder zu korrigieren, ohne Bestehendes unbewußt zu zerstören. Die 'Möglichkeit', nicht die Pflicht. Außerdem, ist die Struktur der 'komplizierten Regeln' nicht dokumentiert, sind auch die Daten eines Mappers, der Details erfasst hat, weniger gut bis gar nicht auswertbar. Du vergraulst damit alle, die mehr mit OSM machen, als nur weiße Landstriche zu füllen. Weiße Landstriche gibt es eben nicht mehr überall. Da kann ich Dir aus dem Stand ein paar strukturell identische, aber unterschiedlich getaggte Gebiete aufzaehlen - ein Zeichen dafuer, dass wir mit dieser Granularitaet die Grenze dessen erreicht haben, was wir den Mappern flaechendeckend zumuten koennen. Du tust so, als ob wir landuse=* feiner granulieren möchten. Das ist nicht der Fall, wir wollen nur genauer definieren, was ein landuse ist, damit dessen Verwendung eindeutiger wird, und nicht mehr fälschlicherweise für das Taggen von admin. Gebieten verwendet wird. Es geht um eine Ausdifferenzierung in der Breite, nicht in die Tiefe. Weiterhin schreiben wir niemandem vor, dass er admin-rechtliche Grenzen taggen /soll/ - es geht ums /können/. Klar gibt es Datennutzer, die sich fuer mehr interessieren, und einzelne Mapper vielleicht auch, aber in der Flaeche wird das nix - wenn ich mich jetzt hinstelle und im Wiki die Definition verfeinere, wird das an der Situation in Deutschland nichts aendern. Doch, es ändert zwei Dinge: - Dispute werden kleiner, weil spezifischer (Flächennutzungsthema vs. Thema admin. Gebiet) - Mapper haben eine bessere Dokumentation des Tags, die sie nutzen können - auch Validatoren sind bezogen auf einzelne Tags wesentlich einfacher zu schreiben Ich sage nicht, dass die neue Definition nicht auch streitbar ist, aber sie sollte weniger streitbar und damit verlässlicher sein, als die jetzige. Außerdem verhindert sie, dass irgendzwei Mapper mit dem gleichen Problem, die selbe Zeit auf eine Lösung verwenden, die Martin und ich darauf verwendet haben. Dass sich die Daten dadurch nicht von heute auf morgen ändern, ist mir auch klar. Meiner Ansicht nach sollte man versuchen, dafuer zu sorgen, dass etwas brauchbares herauskommt, wenn jeder ohne viel Kommunikation nach seinem eigenen Verstaendnis mappt, anstatt den Versuch zu unternehmen, zu verhindern, dass jeder ohne viel Kommunikation nach seinem Verstaendnis mappt. Du vernachlässigst dabei den Fakt, dass kaum jemand _nur_ nach seinem eigenen Verständnis mappt. Gerade wenn es ins Detail geht (unclassified/road, natural wood/forest, landuse=*) informiert sich die überwiegende Zahl genau im Wiki, anstatt blind tags zu setzen. Der Gedanke, dass man einfach nur praezise Regeln aufstellen muesse, und dann klappe alles schon, ist Illusion. -1 Die Vorlagen der Editoren widersprechen dir da. Sobald die Ausdifferenzierung der Geschäfte verfügbar war, wurden auch ungleich öfter Geschäft korrekt erfasst, anstatt nur supermarkets. Das gilt verschaerft dann, wenn der Bereich des vor Ort Erfahrbaren verlassen wird, wenn ich also beginne, in meine Definitionen Dinge einzubauen, die ein Mensch mit normaler Sensorik vor Ort nicht mehr erfassen kann (z.B. Informationen aus dem amtlichen Flaechennutzungsplan). +1 Genau darum geht es: Es soll bitte nur das erfasst werden, was ich mit meiner Sensorik erfassen kann. D.h. auch, dass eben _nicht_ amtliche Gebietsgrenzen mit Grenzen vermischt werden, die ich vor Ort pi mal Daumen ermittle, denn das hat weniger etwas mit einem Abbild der Realität zu tun, als vielmehr mit einer Fälschung. Ich kann vor Ort Flächengrenzen anhand von - in den Boden eingelassenen Grenzsteinen ermitteln - durch den sichtbaren Wechsel der Flächennutzung Wenn ich letzteres durchführe, ermittle ich eine Flächengrenze der Fläche, die bewohnt wird - keine Wohngebietsgrenze, denn das ist etwas amtliches, etwas dass ich vor Ort nur __unscharf__ erfahren kann. Ich kann __scharf__ den amtl. Namen des Wohngebietes ermitteln, indem ich einen Anwohner frage, aber i.d.R. nicht dessen amtl. Grenze. D.h. ich kann einen place node setzen, aber keine border=administrative ohne mehr Informationen. Mapper können die
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 11.09.2011 09:13, schrieb Georg Feddern: Moin, Christian Müller schrieb: Auf unser Problem übertragen: Auf dem Land wird es (i.d.R.) wenige Menschen interessieren, dass es ein Unterschied macht, ob man die administrative Grenze eines Wohngebietes betrachtet, oder seine Flächennutzung, weil durch die geringere Komplexität beides oft zusammenfällt. also diese Bemerkung irritiert mich als kleinen Mapper vom Lande doch ganz gewaltig. Wo bitte schön fällt auf dem Lande die Flächennutzung eines Wohngebietes (Siedlung) mit der administrativen Grenze zusammen? These war: Die administrative Grenze eines Wohngebietes, nicht administrative Grenze des Gemeindegebietes fällt auf dem Land häufiger mit der realen Wohnflächennutzungsgrenze zusammen. Wohngebiete haben wie Gemeindegebiete administrative Grenzen, die von den Ämtern in Liegenschaftskatastern verwaltet werden. Deine restlichen Betrachtungen zur Gemeindegrenze und Gemarkungsgrenze fasse ich genauso auf, da sie allg. Definition entsprechen. LG Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 11.09.2011 11:31, schrieb Martin Koppenhoefer: Zum einen hat unser Tagging sehr wenig mit dem deutschen Recht zu tun, Das trifft insbesondere für border=administrative _nicht_ zu. Das ist ja das ganze Argument. Wenn admin-rechtliche Gebiete teilweise bis zur Gemarkungsgrenze in OSM notiert werden, warum stellt man diesen Sachbezug dann nicht auch für tiefere, innergemeindliche Gebietsgrenzen korrekt her? Im allg. Sprachgebrauch ist das weniger wichtig, als bei der Erfassung von Geodaten. Spreche ich z.B. mit anderen Leuten vom Wohngebiet Hammermühle in Zdorf plappere ich nur nach, was ich irgendwo gehört habe. Mir ist in dem Moment nicht bewußt, dass dieses Wohngebiet eine admin-rechtl. Grenze hat und das dessen Name genau das Gebiet innerhalb dieser Grenze bezeichnet. In OSM bilden wir aber die Realität ab und nicht /meine/ oder eine /andere/ Realität. Realität ist, dass dieses Wohngebiet, das wir erfassen wollen, bereits eine reale Grenze hat - die im Amt hinterlegt ist. Philosophen könnten jetzt fragen, ob wir dann nicht die /Realität des Amtes/ abbilden. Dem würde ich entgegnen, dass ohne die amtliche Benennung des Gebietes zum Zeitpunkt X es keinen späteren Zeitpunkt geben kann, an dem plötzlich eine Menge Leute dieses Gebiet unter demselben Namen verstehen. Und frage mal einen Bewohner, ob er die Grenze seines Wohngebietes genau kennt: i.d.R. Schulterzucken. D.h. während unter dem /amtlichen/ Namen ein über die Jahre immer unschärfer abgegrenztes Gebiet in den Köpfen (und im Amt) /real/ vorhanden ist (*), gibt es die /genaue, scharfe/ Gebietsgrenze als Teil der Realität nur aufgrund des Amtes. (*) .. was für die Erfassung als place node spricht Im allgemeinen Sprachgebrauch ist das nicht wichtig, weil mir dort die unscharfe Grenze reicht, aber wenn ich aus der Realität nun eine scharfe Gebietsgrenze ermitteln will, die nicht mit meiner Sensorik beobachtbar, aber dennoch durch das Amt (als Teil der Realität) da ist, schlage ich fehl. Und in OSM kann ich nur exakte Grenzen erfassen. Es gibt keine fuzzy Grenze im Datenmodell, die müsste ein Editor dann ja als Farbverlauf darstellen. M.E. sollten wir auf tagging diskutieren, wenn wir die allgemeinen Definitionen anpassen wollten. +1 da bin ich bei Dir. Ich habe mir dazu die engl. Seiten der landuse=* noch nicht angesehen. Evtl. gibt es dort (für landuse) keinen Änderungsbedarf, wenn ausschließlich die reale Flächennutzung darunter verstanden wird. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 11.09.2011 12:14, schrieb Martin Koppenhoefer: Am 10. September 2011 19:57 schrieb Christian Müllercmu...@gmx.de: Am 10.09.2011 14:46, schrieb Martin Koppenhoefer: Wieso sollten wir erst alles andere drum rum taggen müssen, nur damit man dann durch komplexe Operationen auf die Ausdehnung der Siedlung schließen kann? Du kannst die Siedlungsfläche auch einfach als Relation erfassen, in die Du alle entsprechenden landuses aufnimmst. Damit hättest Du sie auch explizit erfasst. Das bedeutet zwar immer noch Pflegeaufwand, der dürfte aber einfach sein, als eine Repäsentation in der Basisgeometrie. Das kann ich nicht tun, weil auch die Zwischenräume zur settlement-Fläche gehören, z.B. Verkehrsflächen. Nochmal, Du kannst deine eigene Definition von Siedlungsfläche gerne ausdenken und dann verwenden. Für OSM sollten aber bereits gebräuchliche verwendet werden - siehe Flächenverbrauch in der Wikipedia. Wenn Du die Verkehrsfläche dazu nimmst, sprichst Du von Siedlungs- und Verkehrsfläche (kurz SuV) Du kannst gerne SuV als settlement im engl. verstehen, musst dann aber settlement area beim Übersetzen ins dt. als SuV übersetzen und nicht rein als Siedlungsfläche - weil die gebräuchliche Definition im dt. Verkehrsfläche in der Siedlungsfläche _nicht_ einschließt. Und seit wann kann ich eine Relation nicht erstellen, nur weil es Zwischenräume gibt? Innerhalb eine Gemeindegrenze, kann es durchaus mehrere unabhängige Flächen geben, in denen sich SuV findet. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Siedlungsflächen exportieren
Hallo Rhinhold, Am 10.09.2011 12:06, schrieb Rhinhold: Da die administrativen Grenzen logischerweise nur die Gemarkungsgrenzen darstellen, nicht aber die Siedlungsschwerpunkte, benötige ich nun noch die Siedlungsflächen (v.a. residential). Wie Frederik schon schrieb, dürftest Du dazu in OSM bisher nur Datenfragmente bekommen. Wie Siedlungsfläche und amtl. Wohngebietsgrenzen am besten in OSM erfasst werden, wurde in den vergangenen Tagen auf dieser Liste debattiert. Evtl. hast Du Lust, Dir ein paar Mails davon anzuschauen und begründete Ansichten zum Thema beizusteuern. Damit würde sich dein Wunsch in Zukunft einfacher realisieren lassen. Momentan wirst Du um eine Annäherung über die Daten aus landuse=* und building=* Ansammlungen nicht umherkommen. .. habe ich mir angeschaut, bin aber dann schnell an fehlender Einsteigerhilfe und Fehler bei der Ausführung gescheitert. [Alles zusammen hat mich mehrere Stunden meiner Arbeitszeit gekostet - was irgendwie nicht Sinn der Sache sein sollte/kann] Die Datenerfassung in OSM kostet ebenso zahlreiche Arbeitsstunden, irgendwie beschwert sich da niemand über den Sinn der Sache ;-) Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wohnbaufläche vs. Wohngebiet in der BauNVO
Hi, um den /Flächennutzungscharakter eines Wohngebiets (WG)/ --- genauer zu beschreiben, könnte OSM der Tabelle der Nutzungskombinationen in [1] folgen. Die BauNVO teilt WG nach ihrem Charakter in folgende Hierachie auf: (1) reines WG(2) allgemeines WG(3) besonderes WG (Anm.: Ein 'Kleinsiedlungsgebiet' entspricht grob dem allg. WG) Die Definitionen der BauNVO lassen sich auf drei Arten für eine genauere Definition von WG für OSM wiederverwenden: a) nur (1) b) (1) oder (2) c) (1) oder (2) oder (3) a) ist für OSMs Zwecke zu scharf, c) ist /imho/ zu weich. b) entspräche textlich: Reine und allg. WG nach BauNVO werden in OSM als Wohngebiet erfasst. Besondere WG nach BauNVO sollten unterteilt werden. Besondere WG nach BauNVO würden dann als multipolygon erfasst werden, falls man eine amtliche Vorlage in OSM umsetzen möchte. Eine Alternative dazu wäre, grundsätzlich alle Arten von WG nach BauNVO als Wohngebiet zu erfassen und in einem zusätlichen Tag anzugeben, um welche genaue Art Wohngebiet es sich handelt. --- um die /Gebietsgrenze eines WG/ --- in OSM genauer zu definieren, taugt die BauNVO m.E. nicht. Sie stellt in [2] in den Abschnitten (1) und (2) zwar noch einen Zusammenhang zwischen /Bau_flächen/, also 'Wohnbauflächen' (W) 'gemischte Bauflächen' (M) 'gewerbl. Bauflächen' (G) 'Sonderbauflächen' (S) und /Bau_gebieten/ her, also Kleinsiedlungsgebiete, reine WG, allg. WG, besond. WG (WS, WR, WA, WB) Dorf-, Misch-, und Kerngebiete (MD, MI, MK) Gewerbe-, und Industriegebiete (GE, GI) Sondergebiete (S) aber befasst sich weder mit deren Grenzbildung, noch mit der Namensgebung letztgenannter Gebiete (darauf keine Garantie, ich habe nicht die komplette BauNVO gelesen, aber nach bestimmten Wörtern durchsucht). --- Das Problem mit landuse=* in OSM lässt sich jetzt noch einmal exakter benennen: - /Baufläche/ ist eine mögliche Interpretation - /Baugebiet/ ist eine andere - /Bauflächengrenzen/ entsprechen direkt Verwaltungsgrenzen (i.e. Flurstücke) - /Baugebietsgrenzen/ muss es geben, ohne sie kein /Baugebiet/, aber - durch wen werden sie verwaltet? - wer vergibt die Namen an Baugebiete? - evtl. weitere offene Fragen.. ---wüschtüsch Bei der Flächengrenzbestimmung eines landuse=* werden bisher die Def. /Bauflächengrenze/ und /Baugebietsgrenze/ zusammengemanscht und bei der Flächenbestimmung die Def. /Baufläche/ und /Baugebiet/. Das ist der Grund des Problems. --- Als nächsten Schritt, sollte man erstmal das internationale Verständnis von landuse=* erörtern. Wird dort auch zusammengemanscht, oder wird dort klarer unterschieden? In letzterem Fall hätten wir die dt. Übersetzungen anzupassen, in ersterem können wir entscheiden, wie wir eine Ausdifferenzierung selbst in Tagform gießen und diese dann international bewerben. Gruß Christian [1] http://de.wikipedia.org/wiki/Baunutzungsverordnung#Bauliche_Nutzung_von_Baugebieten [2] http://www.gesetze-im-internet.de/baunvo/BJNR004290962.html#BJNR004290962BJNG000101307 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wohnbaufläche vs. Wohngebiet in der BauNVO
- /Baufläche/ ist eine mögliche Interpretation - /Baugebiet/ ist eine andere .. natürlich nur in Bezug auf landuses, die baulichen Charakter haben. Für landuse=farmland müsste man sich sprachlicher Konstruktionen bedienen, die nicht allg. Sprachgebrauch entstammen (i.e. An_bau_ von Getreide - Baufläche). Wesentlich ist der Unterschied zwischen Fläche und Gebiet. Mehrere Flächen bilden ein Gebiet, diese Ausdifferenzierung wird beim bisherigen Gebrauch von landuse=* nicht bewußt umgesetzt. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 10.09.2011 14:46, schrieb Martin Koppenhoefer: Selbst wenn da etwas Redundanz da wäre, dann machte das die Daten stabiler in einem Projekt, wo zig Tausend Leute unkoordiniert editieren. So ein Unsinn, dazu gibt es die history und nicht umsonst werden Changesets erstellt, so dass sich Änderungen nachvollziehen lassen. Redundanz macht Daten nicht stabiler, was auch immer Du damit meinst. Tagge ich ab jetzt jede Fläche innerhalb Bornsdorf, mit (name=Bornsdorf place=village) damit sich irgendeine wahllose, willkürliche Zuordnung erleichtert? Sorry, das ist fernab jeglicher ratio. OSM war von Anfang an ein Klassifizierungsprojekt, musste es sein, damit sich ein Abbild der Realität überhaupt schaffen lässt. Redundanz ist an begründeten Stellen unverzichtbar. Solche Gründe liegen hier mitnichten vor und Du hast auch keine vorgeschlagen. Davon rede ich doch die ganze Zeit. Es gibt keinen Bedarf für ein place-polygon. Was sollte es auch abbilden? Die 'Siedlungsfläche' ist ein landuse=*. Das Landuse ist die Bodennutzung. Übrigens laut Wiki sogar die geplante Bodennutzung. -- tagging Warum schreibst Du nicht einfach +1.. Deine Aussage ergänzt meine doch nur, die Siedlungsfläche ist ein Verbund bestimmter Bodennutzungen. Wir waren schonmal bei Flächennutzungen, ich weiß jetzt nicht, weshalb Du daraus Bodennutzung machst. Willst Du dich von deiner Aussage landuse=* ist Flächennutzung wieder distanzieren? Siedlungsfläche von Bornsdorf ist die Gesamtfläche innerhalb seiner Verwaltungsgrenze, abzgl. aller Betriebs-, Verkehrs- und Abbauflächen. Siedlungs- und Verkehrsfläche von Bornsdorf ist die Gesamtfläche innerhalb seiner Verwaltungsgrenze, abzgl. aller Betriebs- und Abbauflächen. Damit wären wir wieder beisammen. Nur haben wir keine lückenlose Erfassung der Verwaltungsgrenze abzgl. aller Betriebs-, Verkehrs- und Abbauflächen. Klar haben wir eine lückenlose Erfassung der Verwaltungsgrenzen, für Gemeindegrenzen auf jeden Fall, oft sind die Gemarkungsgrenzen eingemeindeter Dörfer auch vorhanden. Wo sie fehlen, wären sie zu erfassen. Weiterhin ist die lückenlose Erfassung des landuse=* (z.B. in der Ausgestaltung reale Flächennutzung) möglich. Jetzt - nimmst Du die Verwaltungsgrenze (Gemeinde, Gemarkung, whatever), und - schneidest alle Daten außerhalb dieser Grenze weg. - Übrig bleiben die Flächen mit ihren landuse=* innerhalb der Grenze. - Von denen entfernst Du alle Betriebs- und Abbauflächen. - Alles was übrig bleibt ist Siedlungs- und Verkehrsfläche. Einfacher wird es nicht. Die Siedlungsflächengrenze extra zu erfassen bringt nur Redundanz und weitere Fehlermöglichkeiten, denn 'Siedlungsfläche' innerhalb einer Verwaltungsgrenze muss geometrisch nicht zusammenhängen, politisch aber evtl. schon. Für den einfachen Fall einer zusammenhängenden Siedlungsfläche kannst Du dir vorstellen, dass die Siedlungsflächengrenze durch die Vereinigung aller Flächen erhältst, die nach obigem Verfahren übrig sind. Willst Du die _reine_ Siedlungsfläche erhalten, musst Du noch die Verkehrsfläche abziehen - die haben wir (noch) nicht flächendeckend, das ist richtig. Aber das ist im kommen. Bis dahin könnte man sich eine Norm zur Straßenbebauung raussuchen und die üblichen Straßenbreiten gepaart mit der Angabe von lanes=* verwenden, um eine gute Näherung der _reinen_ Siedlungsfläche zu erhalten. Für das Rendering von Flächennutzungsplänen spielt das erstmal keine entscheidende Rolle. Dazu rendert man die Flächennutzungskarte anhand der landuse=* Flächen und rendert die Straßen darüber, sofern man sie überhaupt will. Natürlich ist die Verkehrsfläche dann nicht exakt repräsentiert, aber genauer sind die Daten in OSM eben noch nicht. Wir haben bis auf den Schienen- und Luftverkehr noch nicht mal Einverständnis zum Taggen von Verkehrsflächen. Wir brauchen auf landuse=traffic erstmal wenig Rücksicht nehmen. Diesbzgl. stellt sich nur die Frage, ob landuse=traffic über anderen landuse=* schweben darf, oder ob keine zwei landuse=* übereinanderliegen dürfen. Das lässt sich aber separat diskutieren. Wer dafür ist, landuse möglichst großflächig zu erfassen, wird sich für sie Schwebevariante entscheiden, wer gerne parzelliert für die andere. /Falls/ landuse /Gebiete/ erfasst, wäre es unsinnig zu parzellieren, denn es geht dann um die vorwiegende Nutzung. Ein Ackerland als Gebiet wäre dann an der Straße die durchführt nicht zu teilen. /Falls/ landuse /Flächen/ erfasst, müsste parzelliert werden, denn die Acker/fläche/ ist dort zu Ende, wo die Verkehrsfläche beginnt. Allerdings ist die Fläche im Place-polygon das was dort oben als Siedlungsfläche bezeichnet wird plus die dazugehörigen Verkehrsflächen. Ja, noch so ein Grund, place als polygon abzuschaffen - es ist so unklar definiert, dass mit jedem Versuch es zu fassen, festzustellen ist, dass dieser Aspekt bereits durch andere Mittel
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 10.09.2011 14:46, schrieb Martin Koppenhoefer: Wieso sollten wir erst alles andere drum rum taggen müssen, nur damit man dann durch komplexe Operationen auf die Ausdehnung der Siedlung schließen kann? Du kannst die Siedlungsfläche auch einfach als Relation erfassen, in die Du alle entsprechenden landuses aufnimmst. Damit hättest Du sie auch explizit erfasst. Das bedeutet zwar immer noch Pflegeaufwand, der dürfte aber einfach sein, als eine Repäsentation in der Basisgeometrie. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Hi, Am 10.09.2011 15:12, schrieb Frederik Ramm: Ich stehe place-Polygonen auch kritisch gegenueber. Traditionell ist place ein Node, und ja, wir haben oft eine Dopplung eines place mit einer zugehoerigen Admin-Boundary. In manchen Laendern ist es sogar ueblich, den Place dann in die Boundary-Relation mit aufzunehmen - so nach dem Motto das hier ist die Stadtgrenze, und dort etwa ist die Stadtmitte). Das ist eine etwas unschone Dopplung von Informationen (mal nur place, mal nur boundary, mal beides), aber da hab ich gerade auch keine Patentloesung fuer, die nicht die halbe Welt vor den Kopf stossen wuerde. Die Siedlungsfläche als Relation der relevanten landuses=* zu erfassen, wäre doch keine schlechte Lösung, anstatt Basisgeometrie zu zeichnen. Die boundary Relation besteht dann aus border ways place node in der Rolle admin_centre landuse relation in der Rolle settlement_centre Die Relation der Siedlungsfläche bildet ab, welche Einzelflächen der Realität zur Siedlungsfläche gehören. Damit ist das Wissen explizit in der DB vorhanden, anstatt implizit über die Definition des Begriffs. Ich wuerde zumindest anstreben, place-Polygone zu vermeiden. Wenn ich einen place zu einem Polygon aufblasen moechte, dann sollte ich eine geeignete Admin-Boundary-Relation dafuer finden. Das wird nicht fuer alle Places gehen (man denke an place=isolated_dwelling), aber anstreben kann man es ja. +1 für die Zielvorstellung. .., dann muesste es fuer diese Area ja auch eine offizielle oder wenigstens dokumentierte Begrenzung geben, und dann kann man die vielleicht auch so taggen. Ja, gleiche denke hier. Landuse wuerde ich komplett unabhaengig von administrativen Dingen sehen. Wenn da ein Gebiet mit vorrangig Wohnnutzung ist, dann ist das landuse=residential, und es spielt ueberhaupt keine Rolle, ob die Leute da wild wohnen oder ob das ein ausgewiesenes Wohngebiet ist, ob das zu einer Gemeinde gehoert oder nicht und so weiter. D.h. Du bist für eine vom rechtlichen Sprachgebrauch vollends entkoppelte Definition von landuse=residential. Dafür bin ich im wesentlichen auch. Aber das bedeutet, dass wir uns von Begriffen wie Wohngebiet als direkte Übersetzung für landuse=residential verabschieden müssen, denn dieser Begriff ist ein Rechtsbegriff, ebenso wie das Verständnis der vorrangigen Wohnnutzung an sich - das entspringt direkt dem Gesetzestext. Die dt. Administration nutzt, wie wäre es anders zu erwarten, diese Begriffe vollständig. Baufläche, Bauflächengrenze, Baugebiet, Baugebietsname und Baugebietsgrenze sind in rechtlich belastbarer Form im Liegenschaftskataster in konkreter geografischer Ausgestaltung enthalten. Unsere eigene, auch OSMs bisherige, Definition danebenzustellen, stiftet Verwirrung oder, schlimmstenfalls, Streit. Die Administration ist ein Teil der Realität. Als solche können wir sie in OSM abbilden. Aber nicht, indem wir bestehende Definitionen neu vereinbaren. Das hieße, die Realität zu ändern, nicht abzubilden. Die Implikationen einer rechtsfreien Definition von landuse=*, die ich ausdrücklich aufgrund internationaler Belange (^.^) befürworte, hatte ich schon erwähnt: - landuse erfasst nur die reale Flächennutzung - die Benennung (name=*) der landuses wäre unsinnig (denn der Name suggerierte, dass es sich um ein admin. Gebiet handelt, und damit, dass die Grenzen eines benannten landuse administrative Grenzen wären, was wir ja per Def. nicht wollen) - Flächengrenze dort, wo Flächennutzung wechselt - Def. landuse=residential - /im deutschen/ 'Wohnbaufläche' /ohne/ Rechtsbezug Damit ließe sich ein lückenloses Mosaik der realen Flächennutzungen anstreben. Einen Disput über Flächengrenzen wäre ohne weiteres auflösbar. Der administrative Teil der Realität sollte durch die Mechanismen in OSM abgebildet werden, die bereits schon länger für das Abbilden der Administration bestehen, d.h. von der Gemeindegrenze nach unten hin geeignet fortsetzen: 'Wohnbaugebietsname' (*)- als place=(neighbourhood/residential/etc. oder area - siehe mail) 'Wohnbaugebiet' (*)- als border=administrative - Wohnbaugebiete sind Ansammlungen von Bauflächen mit vorrangig Wohnbauflächen 'Wohnbaufläche' (*)- als border=administrative - Wohnbaufläche entsteht durch den Schnitt von Flurstücksgrenze mit realer Flächennutzung Da wir die amtliche Flächennutzung nicht erfassen, kann es bei letzterem Fehler geben, z.B. wenn ein erschlossenes Gebiet nocht nicht wohnbebaut ist. - OSM gibt dann die reale Nutzung von Flurstücken aus - das Liegenschaftskataster die amtl. Nutzung (evtl. extra tag für amtl. Nutzung) (*) alle Begriffe in ihrer rechtlich-administrativen Bedeutung, siehe mail von gestern, 15:45 Uhr Ich sehe bei Landuse den beschreibenden Charakter im Vordergrund - das hier sieht aus wie ein Wohngebiet. Ja und das ist eben Mist.
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Hi, Am 09.09.2011 07:52, schrieb Georg Feddern: Aber während Wohngebiete oder Stadtviertel in der Gründungsphase recht scharf umgrenzte Gebiete sind, verschwimmen die Grenzen im Laufe der Jahrzehnte und Jahrhunderte allerdings immer mehr, so dass eine trennscharfe Grenzziehung hier zwangsläufig immer umstritten sein wird. Das spricht umsomehr für eine Entkopplung von landuse=residential als reine, reale Flächennutzung von der polit.-admin. Grenze eines Wohngebietes. Denn um die polit. Grenzziehung, ja sogar den Namen eines Wohngebietes lässt sich streiten, weil, deinen Argumenten folgend, die Grenzziehung mit dem Alter des Gebietes unschärfer werden kann. Die namenlose, reale Flächennutzung lässt sich mit offenen Augen bestätigen oder nicht. E.g. Das Grundstück wird zum Wohnen genutzt - es liegt innerhalb einer landuse=residential Fläche. Das Grundstück liegt auf der Grenze zweier Wohngebiete, die nur unscharf definiert ist. Ob es dann dem einen oder dem anderen Wohngebiet zugerechnet wird, bleibt klar eine Entscheidung der Mapper, die sich um die (unscharfe) polit. Grenze kümmern. Die könnten dann evtl. den Besitzer oder das Amt fragen um letzte Fragen zu klären. Wenn es nicht zu klären ist, können die Grenzen (border=administrative) ja auch überlappen, so dass es polit. beiden Gebieten zugeordnet wird. Die MapperInnen, welche landuse=residential mappen, bräuchte letzteres überhaupt nicht zu interessieren, weil weder ein name=* tag involviert ist, noch die Flächennutzungsgrenze eine politische wäre. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 09.09.2011 13:20, schrieb Martin Koppenhoefer: Das tut er aber nicht, wenn ich die parallele Diskussion hier zusammenfassend betrachte. Es bestand Einigkeit darin, dass in einem Wohngebiet/-siedlung auch andere landuses vorkommen können, daher ist die Siedlung kein landuse-feature, auch wenn sie vorwiegend aus einem bestimmten landuse besteht, sondern ein Siedlungsfeature. Allein schon -siedlung deutet stark Richtung place. Der Name war frei erfunden als Beispiel für ein Wohngebietsname. Bleibt nur noch die Frage, was mit Polygonen anzustellen ist, die landuse=residential place=town name=Musterdorf tragen. Das tritt vgl.-weise selten auf und es gibt korrespondierend dazu einen place _node_ mit den gleichen Informationen place=town name=Musterdorf Ich schlage vor, die Dopplung der tags im Polygon zu entfernen, da a) Der Name nicht für die Siedlungsfläche vergeben wurde, sondern für die gesamte Fläche innerhalb der Ortsgrenzen. b) Die Siedlungsfläche bereits über alle landuses innerhalb der Ortsgrenzen, abzgl. Betriebs-, Verkehrs- und Abbauflächen [1], gegeben ist. (Alles unter der Annahme, dass das place-polygon 'Siedlungsfläche' repräsentiert. 'Siedlungsfläche' ist aber schon durch landuse=* gegeben, siehe andere mail.) Gruß, Christian [1] http://de.wikipedia.org/wiki/Fl%C3%A4chenverbrauch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 09.09.2011 16:27, schrieb Martin Koppenhoefer: Von daher würde man wohl den landuse vom place-polygon abspalten müssen. Ja, genau so ist das. Ich schlage vor, die Dopplung der tags im Polygon zu entfernen, da -1. Ich würde auf keinen Fall den Namen vom place-polygon entfernen, da das die einzige Möglichkeit ist, den Bereich der Siedlung überhaupt klar zuzuordnen. Es gab vor einiger Zeit einigermaßen Einverständnis in der Auffassung, dass ein place-node auch dann sinnvoll ist, wenn es bereits ein Polygon für das place-Objekt gibt. (s. hierzu im Archiv von tagging und evtl. talk-osm). Lesen! Ich sprach von Dopplung, i.e. in allen Fällen ist bereits ein place node da, der die gleichen Informationen enthält. Häufig ist außerdem korrekt die Verwaltungsgrenze erfasst - die enthält nochmal die gleiche Information. Es ist also eine, von vielen weiteren, und besseren Möglichkeiten. Wenn es sich auf Verwaltungsgrenzen bezieht, dann müsste anstatt des place ein boundary-polygon ran. Davon rede ich doch die ganze Zeit. Es gibt keinen Bedarf für ein place-polygon. Was sollte es auch abbilden? Die 'Siedlungsfläche' ist ein landuse=*. b) Die Siedlungsfläche bereits über alle landuses innerhalb der Ortsgrenzen, abzgl. Betriebs-, Verkehrs- und Abbauflächen [1], gegeben ist. stimmt so nicht, weil nicht klar ist, _welche_ Siedlung es ist, vor allem in Ballungsräumen. Stimmt so doch: In Ballungsräumen existieren Verwaltungsgrenzen mit admin_level=10, bzw. 11 selbst die suburbs haben ihre Ortsgrenze (Gebietsgrenze, nicht im Sinne der StVO), womit Siedlungsfläche immer zuordenbar ist. Bitte gib in Zukunft konkrete Beispiele, um deine Thesen zu untermauern und wirf anderen Leuten nicht pauschale Aussagen entgegen, deren Gründe sie erraten müssen. :o) Verkehrsflächen sind genauso wie alle anderen Betriebs-, Produktions- und Verkaufsflächen Teil der Siedlung. Siedlung hat im deutschen Sprachgebrauch übrigens auch verschiedene Bedeutungen, führt das evtl. zu Verwirrung? Mein Gebrauch von Siedlung hier ist ein Oberbegriff für solche Dinge wie Großstadt, Stadt, Kleinstadt, Dorf, Weiler, Einzelsiedlung. Nochmal, der Wikipediaartikel zum Flächenverbrauch gibt an, was unter Siedlungs- und Verkehrsfläche zu verstehen ist. Wikipedia schreibt, dass dieser Begriff klar definiert ist, d.h. schätzungsweise nicht durch Wikipedia selbst, sondern durch eine administrative Entität. Es spricht mit Sicherheit nichts dagegen, diese Definition zu übernehmen, da sie dem allg. Sprachgebrauch nicht entgegensteht. Beide Begriffe (Siedlungs-, als auch Verkehrsfläche) definieren sich übrigens ausschließlich über die Flächen_nutzung_, Wikipedia spricht von Flächen_verbrauch_. Ich unterstelle das Flächenverbrauch = Flächennutzung im Sinne des Gebrauchs von landuse=* in OSM. E.g. Bornsdorf hat eine Verwaltungsgrenze. Die Gesamtfläche von Bornsdorf innerhalb dieser Grenze ist nach mehreren Kriterien aufteilbar. Administrativ wird die Fläche in weitere Verwaltungsgrenzen unterteilt (Stadtteil, Grundstücks-, Flur-, Gebietsgrenzen, etc.). Wird die Fläche anhand ihrer (verschiedenen) Nutzungsarten unterteilt, erhält man eine Flächennutzungskarte. Siedlungsfläche von Bornsdorf ist die Gesamtfläche innerhalb seiner Verwaltungsgrenze, abzgl. aller Betriebs-, Verkehrs- und Abbauflächen. Siedlungs- und Verkehrsfläche von Bornsdorf ist die Gesamtfläche innerhalb seiner Verwaltungsgrenze, abzgl. aller Betriebs- und Abbauflächen. Siedlungsfläche eines Stadtteils von Bornsdorf ist die Gesamtfläche innerhalb der Verwaltungsgrenze des Stadtteils, abzgl. aller Betriebs-, Verkehrs- und Abbauflächen. Das sollte logisch nachvollziehbar sein, aber es müsste dokumentiert werden. Es werden keine neuen Begriffe erfunden, die Sätze sind nur Ableitungen bestehender Definitionen. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Hi, Am 09.09.2011 17:39, schrieb Martin Koppenhoefer: Auch empfinde ich es als groben Unfug /Siedlungsfläche/ als place=* getaggte area zu erfassen. I.A. lassen sich für die meisten place=* _nodes_ zugehörige, administrative Grenzen angeben, eine Zuordnung... das ist auch Dein gutes Recht, aber viele andere sehen das anders, weil die Realität so ist. Niemand zwingt Dich dazu, places als Polygone zu mappen, aber um im Wiki zu behaupten, man solle das nicht machen, reicht Deine Meinung nicht aus. Das ist nicht meine Meinung, sondern a) auch deine Meinung (Nutzungsflächen sind als landuse=* zu taggen) b) per Definition des Begriffs so, ich gebe diese nur wieder. b) sollte wohl ausreichen, um das auch ins Wiki zu schreiben. Das wäre besser, als zu warten, bis dort eine andere Definition drinsteht, die mit der allgemeinen unverträglich ist und in ein paar Jahren auf Mailinglisten wieder für illustres Rätselraten sorgt. Weil Du beim Trollen warst: Meine textliche Arbeit, die versucht sich stark an bestehende Definitionen zu halten, als Meinung abzutun, anstatt die Definition konstruktiv mit mir zu prüfen und ihre Tauglichkeit für OSM herauszuarbeiten, ist schon ein wenig trollig. Das widerum ist mal meine Meinung. :-) place - administrative boundary das empfinde ich als groben Unfug, im besten Fall eine Doppelung von Informationen. _Grund_? Wieder so eine pauschale Aussage, ohne Grund. Eine Empfindung ist hier wesentlich uninteressanter, als eine Begründung. Außerdem ist nichtmal klar /was/ Du hier als groben Unfug empfindest? Das mapping an sich? Wie gesagt, ist doch in the wild schon seit Jahren praktiziert, es ist daher eher eine Beobachtung, als ein Zukunftswunsch. Und die best practice dazu im engl. Wiki ist die Dokumentation dazu. Die Definition war offensichtlich überholt. Eine Dopplung gäbe es im name=* tag, meinst Du das? Der place node gibt aber auch das admin_centre an und ist als solcher nicht entbehrbar. Wir könnten noch diskutieren, ob der name=* der boundary oder des place nodes entbehrlich ist, wenn beide über eine Relation verbunden sind. Schließlich würde es reichen, wenn der name=* in der Relation getaggt wird. Nun ja, bei Multipolygonen sind auch häufig die outer ways mit den gleichen tags versehen, wie das multipolygon. Zumindest das ist in manchen Validatoren eine Warnung wert, weil ein way in der outer-Rolle ja auch noch an anderen multis teilnehmen kann. Dieser Randpunkt führt uns aber nur vom eigentlichen Thema weg und bewegt am Ende nichts, weil der Fokus dann wieder auf allem liegt. Wir sollten beim Thema bleiben .., weil ja auch die Ortsnamen von __administrativer Stelle__ für die Gebiete innerhalb administrativer Grenzen vergeben werden, i.e. ein place=* node [..] als admin_centre amtlich mit dieser Grenze verknüpft [ist]. wie gesagt, das trifft nicht mal in Deutschland überall zu Nenne Beispiele. Ohne Beispiel - deine Meinung. Mit Beispiel - deine begründete Meinung. Deine unbegründete Meinung kann Dir niemand nehmen, aber über eine begründete Meinung lässt sich reden ;-) Dass die administrativen Grenzen mit den Ortgrenzen zusammenfallen trifft ggf. in Ballungsräumen zu, wenn zwischen den einzelnen settlements kein Abstand ist. Die Ortsgrenzen fallen _immer_ mit den Verwaltungsgrenzen zusammen, nicht nur in Ballungsräumen. Ortsgrenzen sind Verwaltungsgrenzen. Wenn bei Dir eine Ortsgrenze _keine_ administrative Grenze ist, was ist sie dann? Meinst Du mit Ortsgrenze die Siedlungsflächengrenze? Das ist etwas anderes und braucht, siehe andere mails dieses Freds nicht extra erfasst werden, wenn alle landuses der Gesamtfläche des Ortes korrekt erfasst worden sind. Was soll denn die 'Siedlungsfläche' deiner Meinung nach sein? Laut Wikipedia [1] ist der Begriff der 'Siedlungsfläche' genau definiert und zwar als Oberbegriff bestimmter Flächen, für welche wir in OSM direkte landuse=* Entsprechungen haben. Sie als place-polygon zu erfassen wäre unnötig und falsch, sowohl nach [1], als auch nach dem Begriff an sich, der mit dem Kopf des Kompositums -fläche- anzeigt, in welche Kategorie er zu stecken ist. Nach dem durch Dich favorisierten (und durchaus sinnvollen) Verständnis von landuse als /Flächennutzung/ gehört der Begriff der Siedlungsfläche abermals zum Namespace landuse=*. [1] http://de.wikipedia.org/wiki/Flächenverbrauch Die von Dir zitierte Seite setzt Siedlungsfläche in Gegensatz zu Verkehrsfläche und ist daher nicht das, wovon ich spreche. Das kann ich gar nicht feststellen. Im Gegenteil, sie spricht von Siedlungs- und Verkehrsfläche als einer Sinnheit. Ich spreche von Siedlung im Sinne von von Menschen gemeinsam besiedelter Ort, im engl. Settlement. Ja, das kannst Du tun, das wäre dann widerum deine Meinung, die für mich nachvollziehbar ist, weil Du Gründe angegeben hast. Ich finde jetzt nicht unbedingt, dass das der Definition in [[Flächenverbrauch]]
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Hier noch ein heißer Hinweis, was mit administrativen Grenzen eingemeindeter Gebiete passiert: http://de.wikipedia.org/wiki/Gemarkung Die Gemarkungsgrenze wird dort als nächste Hierachieebene unterhalb der Gemeindegrenze verkauft. Der Artikel erklärt, dass viele Dörfer als Gemarkungsgrenze weiter im Liegenschaftskataster bestehen, wenn ihr dasein als selbstständige Gemeinde endet. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Hi, ich denke wir bewegen uns aufeinander zu, obwohl deine Lösungsansätze umwälzender und unverträglicher mit bisherigem sind, als meine. Ich bin nicht der Meinung, dass wir das gewonnen Verständnis in der Mailingliste begraben sollte, denn ein geringeres Maß an Interpretationsfreiheit bestimmter Tags kommt allen zugute und führt zu hochwertigeren Daten, mit denen man auch wieder kreativer sein kann. +1 zu deiner begrifflichen Klarstellung von 'Wohngebiet' im allg. Sprachgebrauch und 'Wohngebiet' im Sinne Baunutzung. Ich habe, sofern letzteres gemeint war, häufig von 'Wohnfläche' gesprochen, um den engeren Bezug zur Flächennutzung herzustellen. Am 07.09.2011 20:09, schrieb Martin Koppenhoefer: Es gibt einen Unterschied zwischen administrierter Fläche (boundary=administrative) und Siedlungsfläche (place-polygon), daher braucht man auch beide. Als best_practice würde ich vorschlagen, für places eine Relation zu machen und den place-node mit der Rolle settlement_centre dort mit der Place-Fläche zu verknüpfen. au contraire: Siedlungsfläche != place-polygon(siehe unten) Außerdem kämpfst Du an der Stelle mit dem falschen Menschen. Ich habe die best practice auf der englischen Wiki-Seite, die übrigens _durchaus_ den allg. Fall und nicht den speziellen beschreibt, nicht verfasst. Ich stimme ihr nur zu, weil sie Sinn macht, und habe lediglich die Unstimmigkeit zwischen dieser best practice und der Definition der place area beseitigt. Du bist wieder einmal dagegen, sel a vi.. Auch empfinde ich es als groben Unfug /Siedlungsfläche/ als place=* getaggte area zu erfassen. I.A. lassen sich für die meisten place=* _nodes_ zugehörige, administrative Grenzen angeben, eine Zuordnung place - administrative boundary existiert also - anhand zahlreicher, bereits existierender Relationen zu sehen. Hauptsächlich deshalb, weil ja auch die Ortsnamen von __administrativer Stelle__ für die Gebiete innerhalb administrativer Grenzen vergeben werden, i.e. ein place=* node ist oft in der Tat sogar als admin_centre amtlich mit dieser Grenze verknüpft. Genau diesem Aspekt trägt (und trug bereits vor meiner Änderung) die Wiki-Seite Rechnung. Ich werde das also nicht rückgängig machen. Was soll denn die 'Siedlungsfläche' deiner Meinung nach sein? Laut Wikipedia [1] ist der Begriff der 'Siedlungsfläche' genau definiert und zwar als Oberbegriff bestimmter Flächen, für welche wir in OSM direkte landuse=* Entsprechungen haben. Sie als place-polygon zu erfassen wäre unnötig und falsch, sowohl nach [1], als auch nach dem Begriff an sich, der mit dem Kopf des Kompositums -fläche- anzeigt, in welche Kategorie er zu stecken ist. Nach dem durch Dich favorisierten (und durchaus sinnvollen) Verständnis von landuse als /Flächennutzung/ gehört der Begriff der Siedlungsfläche abermals zum Namespace landuse=*. Was sonst soll also als place-polygon erfasst werden, wenn nicht die administrative Grenze, die zu den meisten place=* nodes gehört? Es gibt Ortsnamen, die nicht von admin. Stelle vergeben und gepflegt werden, die in OSM leider auch unter den Namensraum place=* fallen - z.B. place=locality. Aber selbst da macht ein place-polygon m.E. wenig Sinn, weil eine genaue Grenze für eine locality selten ermittelbar sein dürfte. In Ausnahmefällen ist eine Erfassung einer nicht-administrativen Grenze sinnvoll, dann aber kein Grund, die locality mit der /Flächennutzung/ zu vermischen. Ein 'Ort' /ist/ keine Grenze. Das Tag heißt place=* und nicht place's_border=*. Ein 'place-polygon' kann der Renderer aus dem 'place-node' willkürlich erstellen, z.B. als disc, deren Größe eine Eigenschaft des Ortes wiederspiegelt - e.g. population, das hätte aber in der DB nichts zu suchen. Reale Ausgestaltungen des Begriffs sind bereits an andere Tags vergeben: Ein Ort /besitzt/ sowohl eine Flächenaufteilung, als auch eine administrative Grenze, für diese Fälle gibt es in OSM landuse=* und border=administrative. Für diese Thematiken bliebe 'place-polygon' also unbesetzt und der POI-Charakter von place=* begründet. [1] http://de.wikipedia.org/wiki/Flächenverbrauch redundant wäre das nur, wenn man zusätzlich noch mal eine große landuse-Fläche drum rum bauen würde. Redundante Geometrie würde im Gegenteil dann entstehen, wenn man _nicht_ die Grundstücksflächen (Hypothese aus Deiner Mail, man hätte sie) dafür verwenden würde sondern nochmal extra ein Polygon drum rum zieht. Das ist nicht wahr. Das taggen ein und der gleichen Information an jeder parcel ist redundanter, als diese Information genau einmal für eine große Summe an parcels zu beschreiben. Ich sprach nicht von redundanter Geometrie, sondern von redundanter Information. Eine Polygon-Geometrie, die extra um die Parcels gezogen wird, um landuse=residential zu pflegen ist genau dann nicht redundant, wenn diese Information an den einzelnen parcels fehlt. Das macht insbes. dann Sinn, wenn es eine
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Noch eine Anmerkung zu diesem Beispiel - .. und das dort, wo das tatsächlich der Fall ist, z.B. in kleinen villages, dieses gemeinsame Polygon ausreicht - admin_centre des Wohngebietes wäre dann identisch mit admin_centre des Dorfgebietes - also, komplett im Überblick - [DG] Dorfgrenze (boundary=administrative admin_level=X) - [PLC] Name (place=village name=Bornsdorf) - [WG] Wohngebiets- und Flächennutzungsgrenze Evtl. ist es für villages, welche nur ein Wohngebiet enthalten, noch einfacher, sich vorzustellen, dass dieses Wohngebiet im administrativen Sinne gar nicht erfasst wird. Man erfasst dann nur die Flächennutzungsgrenze und gut ist. Der einzige Unterschied zu bisher wäre, dass für diese Fläche eplizit kein Name erfasst würde. Das macht auch Sinn, denn wenn es _nur ein einziges_ Wohngebiet gibt, ist dessen Name in aller Regel identisch mit dem Siedlungsnamen. Für die wenigen Ausnahmen kann dann immer noch die admin. Grenze mit (place=neighbourhood name=obskurer_Name_der_vom_Siedlungsnamen_abweicht) erfasst werden. Vorteile: - es ist eindeutig geklärt, wo die Flächennutzungsgrenze von (landuse=residential) verläuft (nämlich dort, wo Flächennutzungsarten wechseln - der Name eines Dorfes wird nicht zweimal erfasst (Redundanzfreiheit) Nachteile: - die Landnutzungsfläche wäre in der XAPI nicht mehr durch ihren Namen beziehbar, sondern nur durch ihre Lage (bbox) - da der Name nie eindeutig ist, wäre der Nutzen, den man mit Namen hat, aber sowieso zweifelhaft - das äquivalente Verhalten erreicht man einfach dadurch, für jede bbox um place=* mit entspr. name=X nach landuse=* zu fragen - m.E. wartbarer, da bisher z.B. durch Schreibfehler, beide Anfragen unterschiedliche Resultate liefern können (z.B. wenn in name=* von landuse=residential ein Tippfehler ist im Vgl. zu name=* von place=village) - streicht man die Redundanz muss man sich nur noch um evtl. Tippfehler in place=* kümmern Eine Neuerfassung für viele ländliche Gebiete wäre damit nicht nötig. Man versteht einfach nur die dort bereits getaggte Fläche anders. D.h. falls in Zukunft jemand an dieser etwas korrigieren will, wüßte er in welche Richtung er zu korrigieren hätte und muss sich keine Gedanken darüber machen, ob er die admin. Grenze vom Amt einholen sollte, oder ob es i.O. ist, wenn er die Flächennutzungsgrenze exakt durch Luftbilder ermittelt. Den redundanten Namen von landuse=residential kann man entfernen, insofern ein place node mit identischem Namen inneliegt. In diesem Fall hat der name=* von landuse=residential sowieso keinen Mehrwert. Was bringt es, wenn ein und derselbe Ort in den Suchergebnislisten fünfzig mal auftaucht? Ein weiteres Argument _für_ dieses Vorgehen wäre, dass es auch der Realität entspricht: Der Ort /besitzt/ _ein_ Wohngebiet, welches nicht benannt ist. Niemand würde Sätze konstruieren wie Im Wohngebiet Bornsdorf in Bornsdorf findet ein Radrennen statt. Eher Im Bornsdofer Wohngebiet findet ein Radrennen statt. Unbenannte Wohngebiete sollten in OSM nicht benannt werden. Bei Diskrepanzen wird natürlich nichts entfernt und stattdessen im Wiki eine Liste hinterlegt, mit der bitte um Prüfung oder Berichtigung. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Hi, in [1] wird z.B. admin_level=10 für 'Stadtteile' und admin_level=11 für 'Stadtviertel' verwendet. Evtl. ließen sich dort level 20, 21, 22, 23 (*gebiet, Flur, Grundstück, Flurstück) einrichten. Ich bin mir unschlüssig, ob sich die *gebiete, welche durch Gemeinden beplant werden, sich über mehrere Fluren erstrecken können, oder ob nicht doch eine Identität besteht, also Flur = *gebiet - dann entfiele ein level. In [2] werden Gebietsnamen durch ein Amt vergeben, bzw. verwendet. Gruß, Christian [1] http://wiki.openstreetmap.org/wiki/Talk:Key:boundary#Use_of_border_types_in_Germany_2 [2] http://www.amt-franzburg-richtenberg.de/Amt/inhalt/gewerbe.php?amtId=1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Noch ein Nachtrag: in [1] taucht der Begriff neighbourhood zusammen mit der Übersetzung 'Stadtviertel' auf. place=neighbourhood gehört also bisher (als admin_centre) zu admin_level=11 einer border=administrative. Da ein 'Stadtviertel' nicht gleich einem Wohngebiet entspricht (oder?), bin ich also dagegen place=neighbourhood für Wohngebiete zu entfremden. Da bräuchte man einen passenderen Begriff - also entweder place= ..., suburb, neighbourhood, area oder place= ..., suburb, neighbourhood, residential, industrial, commercial, oder place= ..., suburb, neighbourhood, residential_area, industrial_area, commercial_area (place=area wäre nicht sehr intuitiv - es entspringt dem Gedanken eines Oberbegriffs für residential, industrial, commercial, .., areas.) place=* hält damit in seiner traditionsreichen Rolle weiterhin den Namen administrativ benannter Gebiete.. Gruß, Christian [1] http://wiki.openstreetmap.org/wiki/Key:admin_level#11_admin_level_values_for_specific_countries ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Hi, Am 07.09.2011 02:38, schrieb Martin Koppenhoefer: hier kann ich nicht mehr folgen. Es ging ja nie um Grundstücksflächen sondern zum einen darum, welche wo die landuse-Grenzen gezeichnet werden sollen und zum anderen dann um Wohngebiete. Insbesondere /Dir/ ging es tatsächlich um Grundstücksflächen. Deiner Meinung nach sollte landuse=residential für Gruppen aneinanderhängender Grundstücksflächen herhalten, die für den Zweck des Wohnens benutzt würden, womit /Du/ landuse=residential-Grenzen _eindeutig_ entlang Grundstücks/Flurgrenzen zu zeichnen hättest. M.E. ist die Verwendung von landuse=residential so wie sie ist, weil der Renderer dann wie in vielen anderen Karten auch in Übersichts-Zoombereichen einen durchgehenden grauen Hintergrund unter die Siedlung legt, und das ganz gut aussieht. Zu viel Fragmentierung würde nur unruhig wirken und stören. Eigentlich also klassisches taggen für die Renderer. Ein Viertel der cities sind schon als places erfasst, auch wenn das in den OSM-renderern nicht dargestellt wird. Würde mapnik in Zoom 9-12 anstatt der Stadt-landuses place-Flächen rendern, dann hätten wir sehr schnell auch die übrigen 3/4 erfasst ;-) Das Rendering war nie Bestandteil unserer Diskussion, warum fängst Du jetzt damit an? Weshalb es durchaus Sinn macht, Flächen an Wege zu taggen und weshalb nicht, haben wir m.E. ausreichend erörtert - ich werde meine (und deine) Ausarbeitungen dazu nicht wiederholen. Das MapperInnen Flächen an Wege /rein des Renderings wegen/ pappen, ist reine Spekulation. Wir brauchen eine bessere Differenzierung des Wohngebietes (welchem landuse=residential bisher hauptsächlich zurechenbar sein dürfte) auf der einen und der Wohngrundstücksfläche (welche von der Begrifflichkeit evtl. dem Tag landuse=residential sogar näher steht), auf der anderen Seite. Aus der Diskussion ist ein Proposal für Untereinheiten von Orten entstanden, womit man Wohngebiete als das deklarieren kann, was sie sind: besiedelte Gebiete mit Namen, Untereinheiten einer größeren Siedlung, also place in OSM: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/place%3Dneighbourhood Das ist nett, aber noch keine vollständige Lösung. Meines Erachtens sollten die place-Tags hauptsächlich einen POI-Charakter behalten (village, locality, hamlet, etc.), weil die ihnen zuzurechnende Fläche bereits durch boundary=administrative gegeben ist. Das wird zudem als /best practice/ im Wiki empfohlen. Demnach kann dein Vorschlag aus Konsistenzgründen nur sein: - erfasse einen node mit place=neighbourhood und name=* im Zentrum der Nachbarschaft - erfasse die Grenze als boundary=administrative mit entspr. admin_level - füge den node als admin_centre in die boundary-Relation Ich kann dann, wie ich bereits im Beispiel für eine gesamte Stadt schrieb, die neighbourhood-boundary als Multipolygon verwenden, um mir alle enthaltenen Daten, also auch die Flächennutzungen, auszuschneiden. Damit hättest Du erfolgreich die Flächen/nutzung/ von der sprachlichen Implikation gelöst, die durch die Begriffswahl des Gebietes entsteht, innerhalb welchem die Fläche liegt. D.h. eine neighbourhood kann dann mehrere Flächen mit verschiedener Flächennutzung beinhalten, also der Begriff Wohngbiet würde dann nicht mehr _alle_ seine enthaltenen Flächen an landuse=residential binden. (A)- /Das/ ist, so wie ich die community verstanden habe, weder gewünscht noch notwendig - denn die Auffassung ist: Ein Wohngebiet (Du nutzt Nachbarschaft) impliziert landuse=residential. - dabei spielt es keine Rolle, ob noch andere Flächennutzungen im Spiel sind (Spielplatz, Bäcker, Obstladen, etc.) (B)- Selbst wenn wir diese saubere Trennung von /admin. Gebietsdefinition/ und /Flächennutzung/ hätten: - die Flächennutzung würde dann _nicht_ durch admin. Gebiet vorgegeben/vererbt - Wohngebiet impliziert dann _nicht_, dass jede enthaltene Fläche zum Wohnen verwendet wird - wo gehören die Grenzen der Flächennutzung (landuse=residential) dann deiner Meinung nach hin? - bist Du dann wieder an der Grundstücksgrenze? - sozusagen als kleinstes admin. Gebiet, welchem man dann eine konkrete Flächennutzung (landuse) zubilligen darf? - die Grenze der größten Fläche, die man dann mit (landuse=residential) taggen dürfte, verliefe an der äußeren Grenze zusammenhängender Grundstücke der gleichen Nutzungsart Auf die Gefahr hin, dass ich mich wiederhole: (B) ist nicht unlogisch, aber es steht in krassem Gegensatz zu (A), der momentan etablierten Nutzung von landuse=residential. Daher weitherhin mein Vorschlag: - parcel data als Grenze eintragen - von mir aus auch neighbourhoods als Grenze eintragen - die Flächennutzung innerhalb dieser admin. Gebiete aber durch den Schnitt mit den restlichen Daten ermitteln Landuses, insbes. landuse=residential, wären dann weiterhin als größte
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Hi Martin, Hallo Frederik, hallo Liste, die links unten sind in Ordnung, sie helfen, zu verstehen, wie die Terminologie land use außerhalb von OSM genutzt wird. Bei manchen Karten ist man sich unsicher, ob die Datenrepräsentation nicht doch gröber ist und die Straßen einfach nur drüber gerendert worden, aber das ist erstmal nicht so wichtig. Zu unterscheiden sind nach wie vor: - Gebiete - Grundstücksflächen Fakt ist, das bisher in OSM, landuse=residential eher grob Verwendung fand - die meisten Mapper, die landuse=residential neben die Straße gezeichnet haben, haben das nicht getan, weil sie eine genaue Grundstücksgrenze kannten, sondern weil sie nach dem Schema jede Fläche kriegt ihre eigene Grenze verfahren sind. Selbst wenn der Versuch unternommen wurde, die Grundstücksgrenze zu erfassen, kann diese nur als good guess erfasst worden sein, denn i.A. dürften amtliche Daten nicht zur Verfügung gestanden haben. Die meisten links deiner mail haben als Granularität aber die Grundstücksfläche. Diese Granularität gab es in OSM bisher nicht oder sehr, sehr begrenzt. Auch deswegen wuchs zumindest im deutschen Raum die Verwendung von landuse=residential so, dass die meisten Gebiete, welche das Tag tragen eben Gebiete und keine Grundstücksflächen sind. Wir brauchen eine bessere Differenzierung des Wohngebietes (welchem landuse=residential bisher hauptsächlich zurechenbar sein dürfte) auf der einen und der Wohngrundstücksfläche (welche von der Begrifflichkeit evtl. dem Tag landuse=residential sogar näher steht), auf der anderen Seite. Grund: Wenn official parcel data demnächst zur Verfügung steht und die Leute anfangen, die Grundstücksgrenzen automatisch zu importieren, wird sich die Frage stellen, wie das zu taggen sei. Die Wiki-Seite Parcel hat dazu schonmal den dümmsten Vorschlag dazu gemacht, den man machen kann: Importierte Daten mit landuse=residential zu schmücken verwässert die bisherige Verwendung des Tags völlig. Als Nutzer der Daten ist dann nicht mehr zu entscheiden, ob das Tag nun eine Grenze meint, die ein ortskundiger Mensch erstellt hat, oder ob es amtliche Daten sind. Deine Lösung, /landuse=residential/ auf /place=xx/ umzumünzen, ist eine brute-force Attacke auf das assoziative Gedächtnis der meisten MapperInnen. Da (exakte/amtliche/importierte) Grundstücksflächen noch nicht häufig in OSM zu finden sind, schlage ich vor, einen Weg geringeren Widerstands zu gehen und stattdessen vernünftige Tags für eine Grundstücksgrenze (parcel) zu definieren. Mein Vorschlag dazu: Eine Grundstücks/grenze/ dürfte im Namensraum /boundary/ anzusiedeln sein, da sie weder physisch ist, noch direkt die Nutzung vorgibt (ich rede von der Grenze). Die Grundstücks/fläche/ wäre dann die Summe aus * Grundstücksgrenze (an administrative boundary?) und * unterliegender Flächennutzung - da steckt ein wenig der OO-Gedanke dahinter (die Flächennutzung vererbt sich auf das Gebiet innerhalb der Grenze), denn diesen haben wir bereits an anderer Stelle * für eine Stadtgrenze tragen wir auch nicht explizit _ein_ landuse=*, d.h. * will ich wissen, /wie/ die zur Stadt gehörige Fläche genutzt wird, die innerhalb der Stadtgrenze liegt * nutze ich die Stadtgrenze als Polygon und arbeite dann mit den ausgeschnittenen OSM-Daten weiter * mehrere landuses (die nichts mit den Grundstücken zu tun haben!) sind i.d.R. im Ergebnis zu finden * gleiches sollte für eine Grundstücksgrenze gelten, denn a) auf einem großen Grundstück kann es durchaus mehrere Flächennutzungen geben (z.B. farmland/farmyard dürften Teil eines Grundstücks sein) b) eine Grundstücksgrenze unterteilt die Flächennutzung nach Belieben - der Mensch schafft ja die Grundstücke, um ein größeres Gebiet, das zum Wohnen genutzt wird (landuse=residential) zu unterteilen - nicht umgekehrt D.h., nicht das Grundstück bestimmt die Nutzung, sondern /wo/ das Grundstück liegt (in einem Wohngebiet/Industriegebiet/etc.). Es gibt daher keine Notwendigkeit, für jedes Grundstück (oder eine Reihe davon) extra anzugeben, wie sie genutzt werden, solange das durch ihre Lage ableitbar ist. Vgl. dazu Stadtplanung - das Parzellieren erfolgt zum Schluss, am Anfang steht _ein_ Gebiet und die Frage, was man damit machen will. Weiterhin würden wir strikt physische Nutzung von administrativer Aufteilung eines Gebietes trennen. Ich denke, damit sollte man arbeiten können. Es ermöglicht zudem die Erstellung klassischer land use Karten zu denen Du Beispiele gegeben hast (e.g.: (s1) rendere alle Gebiete, (s2) rendere alle Straßen, (s3) rendere alle Grenzen). In dieser Reihenfolge ist es egal, ob in (s2) Straßen als Flächen vorliegen, oder nicht - die Straße würde extra koloriert, genau wie auf den land use Plänen. Gruß, Christian Am 30.08.2011 20:23, schrieb Martin Koppenhoefer: Am 29. August
Re: [Talk-de] wieder mal - Flächen und Wege
Hi, Original-Nachricht Datum: Sun, 28 Aug 2011 10:50:24 +0200 Von: Joerg Fischer o...@jfis.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] wieder mal - Flächen und Wege Nochmal, es gibt auf jedem Markt den ich kenne nicht nur eine große asphaltierte und völlig reglos mit Buden bebaute Fläche, sondern Wege, auf denen die Belieferung erfolgt, an denen einzelne Stände in Reihen aufgebaut sind. Mir ist das real genug. Dann kennst Du andere Märkte als ich - kann ja sein. Es klang erst so, als wenn Du highway=service künstlich setzt, wo real kein Weg ist. Wenn die Gasse z.B. nur dadurch ensteht, dass Markstände zu Marktzeiten auf bestimmte Art und Weise angeordnet werden, hat das in OSM imho nichts verloren. Das ursprüngliche Beispiel bezog sich auf eine Marktgrenze, die dem Verkehr auf voller Länge die Querung ermöglicht. Wir taggen doch keine täglichen oder wöchentlicher Aufsteller, sondern die Objekte, die dauerhaft da sind, also den leeren Platz. Ein Autofahrer mit der Navi-Anweisung queren sie den Marktplatz kann zu Marktzeiten nicht blindlings in dessen Stände fahren, das ist klar. Das verhält sich analog zur Tagesbaustelle oder anderen Obstruktionen, die in OSM nicht zu finden sind. Auch mit Navi lässt sich der Verstand nicht gänzlich abschalten. Nein ;-) Dann wird es Zeit das die Relevanzdiskussion geführt wird. Die sinnlos übergenauen französischen Häuser, die hier schon Thema waren, sind nur ein weiterer Aspekt. Das war ein Spaß - deswegen der Smiley.. Gruß Christian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Original-Nachricht Datum: Sun, 28 Aug 2011 10:43:34 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] wieder mal - Flächen und Wege Der key landuse ist in OSM als Gebiet definiert, was üblicherweise erschließende Straßen und Wege einschließt. soweit ich weiss, ist das nirgends so dokumentiert. Das ist wie manche Leute es gerne hätten, andere machen es anders. Es ist eine erlaubte sich der Dinge, weil, wie Du selbst schreibst, sich das Datenmodell nicht näher über die Nutzung auslässt. Das bedeutet aber auch, dass deine Sicht der Dinge ebensowenig dokumentiert ist. /Damit/ die Diskussion hier nicht ständig wiederaufkeimt, könnte man es ja dokumentieren. Das setzt natürlich eine Einigung vorraus (bestenfalls auch die der zukünftigen Mapper). Damit das, was man dokumentiert, intuitiv und verständlich bleibt, sollte der Begriff /Wohngebiet/ im Datenmodell nicht all zu fern von der Vorstellung liegen, die üblicherweise mit ihm assoziiert wird. Wenn Du jemanden fragst, welche Dinge zu einem Wohngebiet gehören, wirst Du als Antwort _nicht_ ausschließlich Grundstücke erhalten, sondern eher so etwas wie Wohnhäuser, Straßen, Parkplätze, Spielplätze, etc. Vielleicht erschließen sich Dir ja auf diesem Weg die Gedanken mancher Leute.. Nein, man kann die Grenzen eines Gebiets (z.B. Industriegebiet, Gewerbegebiet) im allgemeinen nicht aus den Nutzungen von Einzelgrundstücken ableiten. doch, genau das kann man m.E. sehr wohl. Ich wüsste nicht, wie man es anders machen sollte. Fragen zum Beispiel - das Amt. Oder einen Ortskundigen. Es fallen einem sicher auch noch andere Methoden ein - deine ist auch eine, die würde aber landuse=* völlig überflüssig machen. Und eine automatisierte Deduktion eines Wohngebietes von Grundstücken wird auch seine Schwächen haben - da habe ich Daten lieber separat - Wohnhäuser und den Umriss des Gebietes, über den sich ein Mensch beim Eintragen gewissentlich Gedanken gemacht hat. Gruß, Christian -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Hi Martin, Original-Nachricht Datum: Sun, 28 Aug 2011 11:11:25 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege) * vgl. wenn vor Ort die Verwendung als solches festgestellt wurde +1, m.E. ist das klar, weil wir das mappen, was vor Ort ist, daher ist vg. die Definition. Hm, ist das wirklich so? Die Position einer Telefonzelle ist vgl.-weise einfach ersichtlich. Eine Wohngebietsgrenze schon weniger - schließlich klebt da kein weißes Band auf dem Boden und Zäune gibt es auch nicht überall, wo ein Grundstücksgrenze liegt. Ich kann zwar recht einfach vor Ort feststellen, /ob/ ich mich in einem Wohngebiet befinde, aber dann dessen Grenze zu finden, ist schon recht schwer (wenn es nicht gerade mit einer Straße endet). * Welcher Zshg. besteht zu administrativen Grenzen? keiner Der Gedanke dahinter war: Manche Stadteile sind historisch mit anderen zusammengewachsen. Die Verwaltung aber evtl. noch nicht. Trennen wir die Wohngebiete dann an der Stadtteilgrenze oder nicht (Anm.: es gibt Mapper, die name= an landuse=residentials vergeben). * Wieviel Interpretationsspielraum braucht das tag? legt der Mapper fest Es soll Mapper geben, die sich im Wiki informieren, bevor sie etwas taggen. Dort wird für manche Tags ein größerer Interpretationsspielraum gelassen, als für andere. Viele Tags, die anfänglich zu unscharf definiert waren, wurden nachträglich durch Zusatztags präsiziert (z.B. highway=service), womit der Interpretationsspielraum sinkt. Deshalb diese Frage in Bezug auf landuse=residential. Legt der Mapper fest ist nicht brauchbar, wenn er Rat sucht. [...] * sonstige Bezüge (Wohngebiet - admin. Grenze; Wohngebiet - Stadt/Stadteil; etc.) * an welchen Relationen kann ein Wohngebiet teilnehmen? wir taggen jeweils das, was zutrifft. D.h. z.B. der Name eines (Wohn-)gebiets sollte alle Teile umfassen, die dazugehören. Eine Industrienutzung würde ich z.B. aus der Wohngebietsnutzung (landuse) ausnehmen. Ich habe das Gefühl, dass das a) sehr unkonkret ist und b) nicht auf meine Frage eingeht. Nach meinem Verständnis ist die Existenz eines Wohngebietes immer auch an die Existenz von Straßen allg. gekoppelt, egal, ob das nun eine Spielstraße (living_street), Wohnstraße (residential) oder Hauptstraße (secondary, tertiary) ist. Das bedeutet, dass auch die Straßen _Teil_ der Wohngebiete sind - man baut Straßen, um ein Gebiet zu erschließen. ja, ein Grundstück muss erschlossen sein, damit es bebaut werden darf. Daraus kann man aber nicht ableiten, ob die Straße (oder die halbe Straße ;-) ) zum Gebiet gehört oder nicht. Sorry, sehe ich vollkommen anders. Wieso kann man das nicht? Du nennst keine Gründe und weiterhin leitest Du doch noch ganz andere Dinge ab - z.B. ganze Gebiete aus Grundstücken. Kann man das? Ein Vorschlag der durchgängig für alle Flächenarten das gleiche Vorgehen empfiehlt ist m.E. für den Mapper und für den Auswerter einfacher umzusetzen. Das wird nicht zum Ziel (höhere Genauigkeit) führen, denn es generalisiert unzulässig - Fläche ist eben nicht gleich Fläche, Eigenschaften und Funktion bestimmen teilweise Lagebeziehungen mit, aber das habe ich bereits erschöpfend ausgeführt. m.E. ist das bereits dadurch gewahrt, dass die Straße und das benachbarte Gebiet in OSM enthalten sind. Eine Straße, die an einer Gebietskante entlangläuft kann man auch erkennen ohne das Gebiet zur Straßenmitte zu ziehen. Das beschreibt die Zugehörigkeit nur schwach. Was machst Du mit Straßen, die zwar entlang laufen, aber _tatsächlich_ nicht zum Gebiet gehören. Z.B. wird eine Autobahn nicht zum Wohngebiet gehören, Wohngebiete können aber tatsächlich sehr dicht an ihnen entlang laufen. Das ist nur ein Beispiel, es lassen sich sicher noch mehr finden. es gibt z.B. auch eine Abhängigkeit von Brücken und Flüssen darunter, trotzdem folgt daraus nicht, dass man die Brücke mit dem Fluss verbinden sollte. Aber immerhin ziehe ich die Brücke über den Fluss, anstatt sie daneben zu zeichnen. Weiterhin ist das semantisch völlig korrekt - schließlich berührt die Brücke den Fluss nicht, auch gibt es keine Contains-Beziehung. Weder ist der Fluss in der Brücke enthalten noch umgekehrt. Die Straße des Wohngebietes gehört aber nunmal zum Gebiet. Die Adresse eines Hauses z.B. enthält doch auch den Straßennamen? Ein Schelm wer daraus etwas ableitet. 1) Die Straße führt durch ein Wohngebiet. Bisherige OSM-tagging Praxis ist, die Straße einfach über/durch das Gebiet zu zeichnen. Zu bemerken ist, dass das Wohngebiet an Straßen, die durch es hindurch führen, nicht in separate Flächen aufgetrennt wird. je nachdem. Ob man das
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Hi, Original-Nachricht Datum: Sun, 28 Aug 2011 14:26:46 +0200 Von: Wolfgang wolfg...@ivkasogis.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege) Bei größeren, besonders bei baulich getrennten Straßen kann man statt dessen auch für den Straßenraum landuse=highway (analog landuse=rail) einfügen. Das wird zwar noch nicht gerendert, aber darauf sollte man wie üblich nicht warten. Wäre doch aber imho das gleiche, wie die Straße als Fläche zu zeichnen und dann area=yes highway= zu setzen. Siehst Du dann landuse=highway als shortcut? Ähnlich wie die riverbank das shortcut-Tag zum als Fläche gezeichneten rivers wäre? Gruß Christian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Original-Nachricht Datum: Sun, 28 Aug 2011 14:45:22 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege) Grundstücksmapping ist auch nicht mein Anliegen. Grundstücksscharfes Mappen der Landnutzung impliziert nicht, dass man jedes Grundstück einzeln mappt. I.d.R. kann man ganz gut einzelne Flächen/Grundstücke mit anderer Nutzung unterscheiden, wo das nicht geht, kann man es natürlich auch nicht machen. Womit auch eine allg. Regel flachfällt.. Zusätzlich bezweifele ich, dass grundstücksscharfes Mappen ohne Amtsdaten Sinn macht. Ist es nicht eher ein Minenfeld, wenn das Luftbild mit einer vermeintlichen Grundstücksgrenze frohlockt, die im Flächennutzungsplan des Amtes doch ganz wo anders liegt? Rechtlich gesehen gehören zumindest in Deutschland die Straßen explizit nicht zur Nutzung, aber das muss für OSM nichts heissen. Wie es in OSM sinnvoll ist das diskuttieren wir ja gerade kontrovers. Referenz? Hast Du dazu einen passenden link? IMHO orientiert sich das Recht stark am Begriff der Fläche, daraus folgen die Aspekte Flächenbesitz und -nutzung. Für landuse=* ergibt sich daher die Frage, ob man landuse als Flächennutzung oder Gebietsnutzung auffasst. Je nachdem, tendiert man dann eher zu rechtskonformen oder -abweichenden Definitionen für OSM, allerdings bringen rechtskonforme Definitionen wieder mehr Wunsch nach amtlicher Korrektheit, die ohne Freigabe schwer zu erreichen ist. Gruß Christian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Original-Nachricht Datum: Sun, 28 Aug 2011 15:59:06 +0200 Von: Frederik Ramm frede...@remote.org An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege) In dem Moment, wo man im Sprachgebrauch anfaengt, zu sagen: Der Park schliesst an das Wohngebiet an oder das Wohngebiet geht bis zu dieser Strasse - dann ist es sinnvoll, da auch das landuse=residential enden zu lassen. +1 Ich finde die Orientierung am Sprachgebrauch, soweit sich keine Inkonsistenzen ergeben, auch richtig. Schwierig wird es bei Begriffen wie Haltestelle, die im ÖPNV-Schema als Relation mit Haltepunkt, Platform und psv-furniture umgesetzt wurden, aber auch hier wird nicht gegen den Sprachgebrauch gearbeitet, allenfalls präzisiert. Gruß -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Original-Nachricht Datum: Sun, 28 Aug 2011 16:46:42 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege) also mappen wir bei die Fabrik liegt im Wohngebiet auch kein landuse=industrial? Oder überlappen wir beide? Letzteres war bisher nicht allzu gern gesehen. Bei so einer Enklave wäre die Nutzung eines Multipolygons eine Überlegung wert.. Nutzt Du ja auch. Wenn die Fabrik aber nur aus einer Garage besteht, reicht es vermutlich das Gebäude entsprechend zu taggen und den gröberen landuse zu belassen. Überhaupt wären Multipolygone ohne Objekte in inner-Rolle eine Alternative zu den overlapping ways. Wie ist hier das credo? - sollten Multipolygone nur erzeugt werden, wenn sie echt mehrere Vielecke haben, oder ist auch ein Vieleck mit ways in outer-Rollen ok? - Folge wäre eine schwierigere Auswertung, weil ich landuse=residentials dann zusätzlich in relations suchen müsste, ways allein sind nicht mehr ausreichend. Gruß -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Hi, Original-Nachricht Datum: Sun, 28 Aug 2011 17:28:02 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege) Da bereits das Baugesetzbuch Verkehrsflächen explizit als geforderten Inhalt erwähnt ist klar, dass diese nicht zu den Nutzungen nach BauNVO gezählt werden. Was ist der Vorteil, wenn wir es in OSM anders machen? Betrifft das hier bisher geschriebene nur landuse=residential, oder kann man das auf alle landuses ausdehnen? Das Wiki schreibt übrigens ziemlich klar [1]: There are users advocating both ways of whether or not to draw the boundaries along the highways or as new nodes next to the road, so neither is yet strictly invalid. is yet .. If you had access to land parcel data, you'd draw the ways with landuse=residential along the parcel edges, which are (mostly anyway) some distance away from the road centerline, i.e. behind the sidewalk. ganz so selbstverständlich scheint der Fall nicht zu sein in OSM. Wir haben aber keinen Zugriff auf Amtsdaten, bzw. die Berechtigung sie in OSM zu verwenden. Weiterhin stellt sich die Frage, ob rechtskonforme Definitionen für die Tags Sinn machen, wenn wir die Ressourcen zu rechtskonformem Mapping nicht haben. Weiterhin spricht das Recht von Flächennutzung, wir sprechen aber von Gebieten - unterliegen wir einem Übersetzungsfehler? Es ist offenbar entscheidend, ob wir landuse als Flächen Gebiets Land -nutzung auffassen. Wohnfläche != Wohngebiet Sprachgebrauch: Wohnflächen, Straßenflächen, Parkflächen, Parkplatzflächen sind Teile eines Wohngebietes. Gruß, Christian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete als Siedlungsteile (place) (war Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Weg
Original-Nachricht Datum: Mon, 29 Aug 2011 01:22:44 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: [Talk-de] Wohngebiete als Siedlungsteile (place) (war Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)) ich schlage vor, Wohngebiete als Untereinheit von Siedlungen in place unterzubringen. Landuse ist meiner Ansicht nach eher nicht der geeignete Tag dafür, um diese Art von Gliederung zu bilden. So könnte man bei Bedarf und Lust die Nutzung auch von einzelnen Grundstücken angeben (was m.E. der Sinn von landuse ist) ohne dass man anderen Leuten ihr Wohngebiet kaputt macht. OK, das bedeutet, Du verstehst landuse als Flächennutzung nicht als Gebietsnutzung. Dass ausgewiesene Wohnflächen etwas anderes sind als Wohngebieten, müsste mittlerweile klar sein. An beide das gleiche Tag zu vergeben ist das Problem.. ;-) Allerdings bin ich schon der Meinung, dass bisher landuse=residential praktisch als Tag für Wohngebiete verwendet wurde, anstatt für Wohnflächen. Das zeigt ja auch gerade die Nicht-Trennung an durchgehenden Straßen. Gruß Christian -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Original-Nachricht Datum: Mon, 29 Aug 2011 02:15:24 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege) [...] d.h. in der Praxis wird man pro Verwaltungseinheit öfter mehrere Wohngebiete haben. Das wird ja in OSM bereits getrennt erfasst mit boundary=administrative und vielleicht bald auch mit place (bisher wohl teilweise mit landuse-Gebieten). Dürfte schwer sein, dass jetzt umzuwidmen, nur weil Du es so willst. Ich finde deinen Vorschlag nichtmal verkehrt: sed -e 's/k=.landuse. v=.residential./k=.place. v=.residential_area./g' wäre zwar mal 'ne Maßnahme, aber unsere endlosen Threads, die hier zum Erkenntnisgewinn geführt haben, wird sicherlich niemand lesen wollen. Zumal das ja auch falsch wäre, denn bisher sind Daten, die eher Wohnfläche repräsentieren /und/ Daten, die eher Wohngebiete repräsentieren unter demselben Tag erfasst worden - je nachdem wie der jew. Mapper es verstanden hat, es war ja im Wiki nicht näher spezifiziert. Also, wie verkaufen? ;-) Das ist ein Problem des sich evolutionäre entwickelnden Datenmodells - hinterher ist man immer schlauer.. Happy osm'ing, Christian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Hi, Am 27.08.2011 16:55, schrieb Martin Koppenhoefer: Am 27. August 2011 14:45 schrieb Wolfgangwolfg...@ivkasogis.de: Ich habe das Gefühl, dass bei der ganzen Diskussion vergessen wird, dass wir keine Grundstücke wie beim Kataster erfassen, sondern mit landuse nur Gebiete. es geht nicht nur um landuse sondern allgemein um Flächen, aber auch bei landuse stellen sich Fragen. Ich finde Wolfgang hat recht. Um zu einem Konsens zu kommen, sollte man die Dikussion thematisch beschränken, anstatt auszudehnen. Dabei sollte entweder auf landuse=*, bzw. besser gleich konkret auf landuse=residential fokussiert werden. Das Thema zu generalisieren, um dann zu einer Lösung zu kommen, hat wenig Erfolg, denn der semantische Bezug der Objekte untereinander ist vom konkreten Flächentyp abhängig. Es ist immer noch nicht geklärt 1) /was/ wir in OSM unter einem Wohngebiet verstehen * verständliche, für andere Mapper nachvollziehbare Definition * vgl. wenn vor Ort die Verwendung als solches festgestellt wurde * vgl. wenn es auf dem Luftbild so aussieht * vgl. wenn es amtlich so ausgewiesen ist * Ist jedes Gebiet, auf dem ein Wohnhaus steht, automatisch Wohngebiet, oder ist die Ansammlung wichtig? * Welcher Zshg. besteht zu administrativen Grenzen? * Wieviel Interpretationsspielraum braucht das tag? 2) /welche/ semantischen Bezüge zu anderen Objekten gibt es und wie stellen wir diese durch OSM-Mittel / Datenmodell dar? * räumliche Lagebezüge / Topologie * welche Objekte grenzen an * welche Objekte liegen innen (Multipolygon getrennt betrachten) * wann wäre Erstellung eines Multipolygon zwingend? (z.B. Industrieenklave im umschließenden Wohngebiet) * welche inneren Objekte können ohne Multipolygon inne liegen? * sonstige Bezüge (Wohngebiet - admin. Grenze; Wohngebiet - Stadt/Stadteil; etc.) * an welchen Relationen kann ein Wohngebiet teilnehmen? * etc. Nach meinem Verständnis ist die Existenz eines Wohngebietes immer auch an die Existenz von Straßen allg. gekoppelt, egal, ob das nun eine Spielstraße (living_street), Wohnstraße (residential) oder Hauptstraße (secondary, tertiary) ist. Das bedeutet, dass auch die Straßen _Teil_ der Wohngebiete sind - man baut Straßen, um ein Gebiet zu erschließen. Diese unmittelbare Abhängigkeit sollte im Datenmodell gewahrt bleiben. Ich bin überzeugt davon, dass das Kleben von Wohngebieten an ihre zugehörigen Straßen richtig ist, weil es eine funktionale Abhängigkeit des Wohngebietes von der Straße gibt. Wohngebiete ohne Straßen gibt es nicht. Eruieren wir nun die Fälle, welchen Lagebezug Straßen zu Wohngebieten haben können: 1) Die Straße führt durch ein Wohngebiet. Bisherige OSM-tagging Praxis ist, die Straße einfach über/durch das Gebiet zu zeichnen. Zu bemerken ist, dass das Wohngebiet an Straßen, die durch es hindurch führen, nicht in separate Flächen aufgetrennt wird. Das ist intuitives Verständnis von Mappern und ein direktes Abbild der Beobachtung im Datenmodell: Die Straße führt durch ein Wohngebiet. 2) Die Straße beendet das Wohngebiet Das ist eigentlich nur der Fall, wenn A) eine einseitige Bebauung entlang der Straße erfolgt, sprich der landuse der rechten Seite ein anderer, als der der linken Seite ist, oder B) die Bezeichnung / die Art des Wohngebietes wechselt In beiden Fällen ist zu beobachten, dass die Straße notwendig für das Erreichen der Wohnhäuser des links oder rechts liegenden Wohngebietes ist. Gleiches gilt IMHO für die meisten Durchgangsstraßen. Da wir nicht von einzelnen Grundstücken sprechen, sondern von einer groben Gebietsnutzung (vgl. die Aussage ein Grundstück ist Teil des Wohngebietes) und in 1) die Sache klar zu sein scheint, gibt es für mich nur eine sinnvolle Schlussfolgerung, wenn man auf Konsistenz aus ist: das Wohngebiet an die Straße zu kleben, wenn es mit ihr endet. Es spielt keine Rolle, ob eine Straße nur rechts- oder linksseitig mit Wohnhäusern bebaut ist, Fakt bleibt, dass die Straße Teil des Wohngebietes sein muss, denn die Wohnhäuser, und damit das Wohngebiet, sind funktional von ihr abhängig. Da die Straße also auch bei einseitiger Bebauung Teil des Wohngebietes ist, ist es nicht nur konsistent und intuitiv wenn man das Wohngebiet an sie klebt, sondern fast notwendig. Ansonsten wäre um der Konsistenz der Daten Willen für 1) gefordert, dass Wohngebiete an JEDER Straße aufgetrennt werden. Vgl. hierzu die möglichen Aussagen, die man treffen kann: Eine Straße, die durch ein Wohngebiet führt, gehört nicht zum Wohngebiet (dazu). * Konsequenz wäre, überall Wohngebietsflächen aufzutrennen * Es gäbe kein einziges Wohngebiet, durch welches eine Straße führt (nach Def.) * Anzahl der landuse=residential Flächen explodiert Eine Straße, die durch ein Wohngebiet führt, gehört zum Wohngebiet
Re: [Talk-de] wieder mal - Flächen und Wege
Am 27.08.2011 19:51, schrieb Johannes Huesing: footways und residentials auf denselben nodes ist natürlich Unsinn. +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 23.08.2011 15:11, schrieb Georg Feddern: Unscharf begrenzte Flächen wie residential, industrial klebe ich durchaus an die begrenzende Straße. Andere, eher scharf begrenzte Flächen wie Weide- oder Ackerflächen, die durch Zaun oder Knick zur Straße begrenzt sind oder neben einem ländlichen baulich getrennten straßenbegleitenden Fuß-/Radweg liegen, klebe ich dagegen nicht an den Weg. Hey, das stützt meine mail von heute, dass die Klebarbeit je nach Flächentyp unterschiedlich gehandhabt werden sollte, also Ackerland beispielsweise nicht geklebt wird, weil die Semantik das nicht hergibt - niemand würde davon sprechen, dass die Straße zum Ackerland gehört, während das allein schon sprachlich bei Wohn- und Industriegebieten anders aussieht.. Ackerland an tracks zu kleben wäre schon wieder einen Gedanken wert, zumindest des stärkeren semantischen Bezugs als zu residentials wegen ;-) Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Hi, Am 23.08.2011 17:23, schrieb Joerg Fischer: Ich lege zwischen die beiden Straßen einen highway=service, und zwar da, wo üblicherweise die Belieferung des Marktes erfolgt. Wenn es diesen highway gar nicht gibt, erfindest Du deine Realität.. Solche Hilfswege, die real nicht existieren, würde ich vermeiden und nur einsetzen, wenn mir gar nix anderes mehr einfällt. An den kann ich dann sogar dran schreiben für welche Art von Fahrzeugen der Markt befahrbar ist Das gehört an den Markt.. , und eine ungefähre Geschwindigkeit, usw. Routing quer über Flächen ist übrigens ein großes Problem, lies mal das Archiv der Mailingliste. Die Chancen das _Deine_ Lösung mit den meisten Routern nicht funktioniert sind hoch. Was soll ein Navi an der Stelle eigentlich ansagen? Fahren Sie im Winkel von 22° nach rechts, achten sie auf heute möglicherweise herumstehende Verkaufsbuden, versuchen Sie dann am Ende des Marktes die Gasse zu treffen. Wie wäre es mit: Queren sie den Markt. Mehr ist IMHO nicht notwendig und die Genauigkeit reicht für Flächen, die _echt_ einen fließenden Übergang zu angrenzenden Straßen haben, auch aus. Du, meine ersten Edits sind aus dem Frühjahr 2007, ich weiß so ungefähr was ich tue. Alter vor Schönheit, wie? ;-) Ich finde das irrelevant, mein erster edit ist aus 2008 - so what? Das sagt an sich wenig darüber aus, wie erfahren jemand ist. Überspitzt gesagt, wenn einer mir erzählt, dass er seit 30 Jahren den Führerschein hat, weiß ich auch nicht wie er sein Auto fährt. Du möchtest die Ebene sachlicher Diskussion nun verlassen? Eher hinkommen - die Idee war: hier ist meine changeset url, urteile selbst.. Wie wäre es mit Bäumen+Typbestimmung? Ich seh schon, wir brauchen eine Relevanzdiskussion. Kannst Du Dir möglicherweise vorstellen, das nicht alle Daten die irgendwie einen Zusammenhang mit Koordinaten haben, gleich nach OSM gehören? Nein ;-) indoor-routing (teilweise schon begonnen). Fällt Dir eine praktische Anwendung dafür ein? Fluchtpläne in der Oper oder so? Relevanz für OSM? Ich habe es nicht begonnen, Du müsstest die Leute Fragen, die dazu schon eine Map online haben - ein link dazu war mal in der OSM Wochennotiz.. Gulli-Deckel Wozu? Nur weil es theoretisch geht? Die urspr. Frage war relativ offen, die Antworten daher nur als Denkanstoß zu verstehen. Ich sehe auch keinen Grund die einzutragen, bin aber auch der Überzeugung, dass der menschliche Ideenreichtum wenig Grenzen hat, man also allein solche pauschalen Aussagen, wie - das werden wir nie brauchen - oder - D ist annähernd komplett erfasst - nicht treffen sollte. Grüßle, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 26.08.2011 12:41, schrieb Garry: Ansonsten führt vielfach jede Genauigkeitsverbesserung eines Objekts zu Lageungenauigkeiten eines anderen Objektes. man erstmal erfassen muss oder zu ungenau wenn zu wenig Stützpunkte vorhanden sind. Versteh ich nicht Eine Aussage Die Strassebreite ist an dieser Position mit der Breite Xm erfasst worden nützt wenig.da man für alle anderen Postionen damit keine Aussage treffen kann. +1 Die Straßenbreite würde ich auch nicht zu Flächenberechnungen und Lagebeziehungen heranziehen. Dafür streut zum einen die Erfassung der Mittellinie zu stark und zum anderen ist es nur für einen Teil der Straßen praktikabel, die über längere Strecken tatsächlich die gleiche Breite haben. Wenn Straßen ständig für Abbiegespuren ausbuchten, fängt man an, darüber zu grübeln, ob die Abbiegespur extra gezeichnet werden soll, oder der Wert der Straßenbreite pro Segement anzupassen ist. Das wäre sehr aufwendig. Sie mit width anzugeben ist ok. Es ist dann als hint im Renderer nutzbar, aber für Contains-Anfragen zu fehleranfällig, imho. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl nodes pro Objekt
Hi, Am 25.08.2011 15:18, schrieb Martin Koppenhoefer: Am 24. August 2011 22:34 schrieb Paul Hartmannphaau...@googlemail.com: On 08/24/2011 09:04 PM, Christian Müller wrote: Tools Simplify Way ist eine JOSM-core Funktion und benutzt Douglas-Peucker (genau wie Merkaator). Dieser Algorithmus zerstört allerdings kleine Strukturen, wie rechtwinklige Ausbuchtungen und kann bei geschlossenen Wegen nicht den Anfangs- bzw. Endpunkt löschen. +1, soweit ich das sehe spielen Winkel bei diesem Algorithmus überhaupt keine Rolle, d.h. er wird auch anderer Stelle höchstens suboptimale Ergebnisse bringen (je nachdem, was man braucht, wenn man für low-zoom extrem vereinfachen will, wird er dagegen vermutlich genau das richtige sein). Ich habe nie vorgeschlagen, DP für die Datenverbesserung in OSM zu verwenden und das Winkel bei DP eine Rolle spielen würden, hat hier IIRC auch niemand behauptet. Ich hatte den Wikipedia Link gepostet - da wird die Arbeitsweise verständlich beschrieben. DP reduziert die Genauigkeit, indem ein Schwellenwert angegeben wird, der bestimmt, wie weit in einem zu approximierenden Streckenzug Punkte maximal vom durch DP erzeugten, neuen Streckenzug entfernt sein dürfen. Wählt man den Schwellwert groß genug, degeneriert man damit jeden Streckenzug zu dessen Start und Endpunkt. Damit werden auch spitze Erker und whatnot flachgeklopft. Es sei denn natürlich, sie bestehen aus zwei Wegen, die an der Spitze getrennt sind. Da Winkel überhaupt nicht in der Rechnung betrachtet werden, ist es, je nach Schwellwert, möglich, dass Gebäude verschwinden, indem der ursprüngliche Streckenzug zu Start- und Endpunkt (bei geschlossenen Wegen identisch) degeneriert. Wie gesagt, für die Weiterverarbeitung von Daten aus OSM für verschiedene Anwendungen eignet sich das Verfahren ganz gut. Evtl. degenieren manche Gebäude je nach Größe und Schwellwertwahl zum Start- und Endpunkt ihres ways, aber auch das ist anwendungsbezogen akzeptabel. Ohne jetzt die Detailfülle franz. Gebäude gesehen zu haben, war und bin ich der Meinung, dass es evtl. jemanden gibt, der diese Detailfülle braucht - deswegen pro Genauigkeit. Douglas-Peucker kann keine Genauigkeit erzeugen, wohl aber reduzieren und damit unerwünschtes Detail entfernen. Da die Reduktion ein Oneway-Ticket ist, ist es gut in OSM die genaueren Daten zu haben: Weil sich die Genauigkeit kontrolliert reduzieren, aber eben nicht erzeugen lässt. Ich habe das nur als Ermutigung für Mapper verstanden, nicht für Leute, die Architektengrundrisse importieren. Frederiks Bedenken zum Datenkollaps teile ich. Schließlich ist OSM (noch?) keine Immo-Datenbank. Weiterhin teile ich ebenso die Auffassung, dass automatisierte Imports wenig Sinn machen, wenn nicht ein Mench geeignet tags vergibt, um die Geometrien besser klassifizieren, sprich Gartenhäuschen von Appartments trennen zu können. Das Plugin Simplify Area wurde speziell für die sanfte Vereinfachung von importierten Gebäuden geschrieben. Es gibt da mehrere Parameter, an denen man schrauben könnte, aber noch keine bequeme GUI, mit der das möglich wäre. weisst Du, ob man da anstatt oder zusätzlich zu einer Entfernung auch Winkel als Parameter angeben kann? Winkelbezogene Tools, die ich in JOSM bisher nutze, sind rectify ways und align ways. Simplify Areas klingt vielversprechend, habe ich aber noch nicht näher betrachtet - müsste man mal in den JOSM Prefs schauen, welche Parameter zur Verfügung stehen. Simplify Ways hingegen hat momentan den Vorteil, dass es sowohl in osmosis als auch in josm zur Verfügung steht. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 24.08.2011 10:28, schrieb Hartmut Holzgraefe: On 08/23/2011 09:19 PM, Dimitri Junker wrote: In OSM würde dann die Telefonzelle im Park stehen, eigentlich steht sie aber auf der Straße. Nein, denn wenn der Abstand Straßenmittellinie - Telefonzelle kleiner ist als die Straßenbreite wird sie in der Straße gerendert, nur in Josm wo die Straße eine Linie ist scheint sie im Park zu liegen. Aber wer Josm nutzt sollte das soweit verstanden haben, daß es ihn nicht verwirrt. ich glaube nicht das ST_CONTAINS() Josm-Wissen eingebaut hat, genau so wenig wie ST_TOUCHES() beachtet ob zwei sich berührende Flächen durch eine ausdehnungslose Straße getrennt sind. Code sollte sich an das Datenmodell anpassen - nicht umgekehrt. Wenn sich Software nicht an uns anpasst, sondern wir uns an die Software, könnten wir ja gleich mit SQL Statements mappen. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Anzahl nodes pro Objekt (war Re: Hinweis zum Mappen in Frankreich)
Am 24.08.2011 16:48, schrieb popp...@hm.edu: Sehr oft bestehen Gebaeude aus bis zu 60 (!) Punkten, wenn es 7-8 auch tun wuerden. Da ist jede Rundung und jede Ecke modelliert. Vereinzelt habe ich das korrigiert, aber die Masse der Faelle erschlaegt einen. Wie soll man sowas korrigieren ? Von Hand ? Für Osmosis gibt es ein plugin simplify ways [1], welches mittels Douglas-Peucker [2] nodes auf Wunsch aus den ways eines Datenextraktes entfernt. Das Ergebnis sollte man dann aber bitte nicht verwenden, um es wieder in OSM einzuspeisen. Die Reduktion der Genauigkeit ist für manche Anwendungen sinnvoll, für andere nicht. Da diese Reduktion relativ einfach und automatisiert angewandt werden kann, das ganze aber ein oneway ticket ist, ist es besser in OSM die genaueren Daten vorzuhalten. Dann kann sich das jeder nach Bedarf selbst reduzieren. Ob ein Mapper einen Kreis bei gleichem Radius nun mit 8, 16 oder 32 nodes darstellt, ist für meine Begriffe nicht diskussionswürdig. Statt einer quantitativen Aussage, wieviel nodes für einen Kreis verwendet werden sollten, tut es daher evtl. auch eine qualitative: So viele wie nötig und so wenige wie möglich. Simplify ways gibt es auch als josm plugin, wobei ich nicht weiß, ob das auch auf dem Douglas-Peucker basiert. Auf bestehenden Daten verwende ich es in JOSM äußerst selten - z.B. wenn erkennbar ist, dass ein way ohne Nachbearbeitung aus einem gpx log mit einsekündlichen Intervallen erzeugt wurde. Ungetaggte, funktionslose nodes, die nach dem Löschen den Verlauf des Weges nicht ändern, verleiten oft zum Löschen. Hier muss man sich aber fragen, ob evtl. nicht doch eine zukünftige Verwendung angedacht worden ist - Luftbild konsultieren, evtl. GPX-Tracks vom OSM-Server ziehen. Auch die history des nodes ist manchmal hilfreich.. Gruß, Christian [1] https://github.com/podolsir/osmosis-simplifyways [2] http://de.wikipedia.org/wiki/Douglas-Peucker-Algorithmus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Hi Jörg, Am 22.08.2011 20:30, schrieb Joerg Fischer: Das fiel mir nur auf weil das Routing von openrouteservice und meinem Garmin merkwürdig und unlogisch war. Da waren dann residentials und footways übereinander gelegt, Parkpätze und Fußgängerzonen und IIRC sogar Gebäude, alle fröhlich auf gemeinsamen Nodes. Das ist total off-topic, sorry. Deine Aussage stellt klar, dass hier Dinge zusammengebaut wurden, die _nicht_ zusammengehören. Um die geht es uns nicht. Wenn das routing nicht mehr funktioniert, wurden ganz klar Dinge geklebt, die nicht zusammengehören. Beispiel, wo es richtig wäre: Stelle Dir zwei parallele Straßen vor, zwischen denen sich ein Marktplatz befindet. Du willst doch sicher auch, dass ein Router den Weg über den Marktplatz findet, wenn dieser zu den Straßen hin nicht baulich getrennt, sprich offen ist. Würdest Du den Marktplatz nicht an die Straßen kleben, gäbe es für den Router keine Verbindung. ) um einen node in mehrere ways einzufügen - node zeichnen, J drücken ) um durch mehrere mögliche overlapping ways zu wechseln - eine der Tasten / # * probieren ) siehe http://wiki.openstreetmap.org/wiki/Potlatch_2/Shortcuts ) know your editor.. Und das findest Du intuitiv und fehlerfrei? Auch für Anfänger? Ich nicht. Du mischt hier zwei paar Schuhe zusammen. Es ging nicht darum, ob ich einen Editor intuitiv finde, sondern ob/wann ich Daten als qualitativ gut, sprich topologisch richtig, einstufe. Ich habe Leuten, die ihren Editor offenbar nicht kennen, nur die Hilfen an die Hand gegeben, die sie schon längst hätten mal lesen sollen - der Programmierer schreibt doch so etwas nicht umsonst. Und ich habe, wie schon beschrieben, bereits eine Menge solcher wilden Konstrukte aufgelöst. Da Du hier von mir gänzlich unbekannten Daten sprichst, ich also nicht weiß, was Du wo aufgelöst hast, kann ich auch nicht urteilen, ob das gerechtfertigt war. Aber vielleicht hast Du ja tatsächlich erfolgreich Mapper verdrängt, welche die Datenqualität in deinem Gebiet erhöht auf längere Sicht erhöht hätten. Weiß man nicht. Dass sich niemand beschwert hat, muss ja nicht heißen, dass es alle gut fanden. Auf jeden Fall hättest Du die Mapper, die für das falsche routing verantwortlich waren, pers. anschreiben können (vor oder nach edit) ;-) Meist fällt das erst auf wenn man sich die Stelle bei keepright anguckt oder weil das Routing nicht klappt und mich der Garmin irgendwohin schickt wo ich garantiert nicht hin wollte. Zu viele Mapper erfassen im Stil von: Hauptsache es sieht danach optisch auf der Karte doll aus. Es sollte optisch doll und korrekt. Für mich ist das kein Widerspruch. Wenn das routing nicht klappt, ist auch nicht richtig gemappt worden - oder der Router ist Schrott. Was fehlt Dir denn noch, dass es den Datenbestand mehr als ein paar Prozent vergrößern wird? Wie wäre es mit Bäumen+Typbestimmung? Wie wäre es mit indoor-routing (teilweise schon begonnen). Oder gleichbleibend gutem Erfassungsstand in allen Gebieten? Millionen von buildings dürften fehlen, weil sie nicht gerade in einer Gegend liegen, wo Microsoft Material gekauft hat.. Ich schätze außerdem, dass in den Gebieten mit guten Sat-Bildern auf lange Sicht Straßenlampen, Gulli-Deckel etc. zu finden sein werden, sowie, tada, als Flächen erfasste Straßen (vgl. river - riverbank) Ja, aber ich denke immer noch, verbundene Wege erhöhen gerade die Komplexität. der Rechnung ja, nicht aber des Speicherplatzes. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 23.08.2011 02:26, schrieb Martin Koppenhoefer: Gemeint war: Flächenausdehnungen bewusst falsch zu zeichnen. Schon wieder falsch ;-). Wir haben fast keine Möglichkeit, die Flächenausdehnung korrekt zu erfassen - OSM ist keine Katasterkarte. Hier ist warum: 1) Oft wissen wir nicht, wem Land gehört, das auf Luftbildern zu sehen ist - das wäre für die Flächenausdehnung aber wichtig, denn oft endet die Fläche und ihre Nutzung mit der Grundstücksgrenze. Solche Daten können wir mit dem Anspruch auf Korrektheit bestenfalls vom Amt einholen. 2) Das Abschätzen einer Fläche per Luftbild hat keine Vermessungsgenauigkeit. Selbst genaues Abzeichnen führt damit nicht zur Belastbarkeit der Daten (für amtliche/rechtliche/sonstige Zwecke) - damit stellt sich die Frage, welchen Mehrwert genaues Abzeichnen hat, auch im Zshg. mit 1) 3) Tags in OSM präzisieren oft gar nicht, wo genau eine Fläche aufhört. D.h. das Datenmodell (vgl. Frederiks mail) schreibt nicht in letzter Instanz vor, was richtig oder falsch im Sinne des Datenmodells ist. Z.B. wird ein Wohngebiet als landuse=residential kodifiziert, aber es gibt keine genauere Definition dazu, in welchen Grenzen ein Wohngebiet existiert. Es wird weder definiert, dass wir uns dabei an irgendeine amtliche Katasterkarte halten, noch, dass wir überhaupt nur Gebiete als Wohngebiet taggen, die amtlich so gewidmet worden sind. Ein Vergleich amtl. Katasterkarten mit OSM-Daten wird hier erstaunliche Differenzen zu Tage treten lassen. Wir stellen fest, dass es also einen Interpretationsspielraum gibt. In dem Sinne kannst Du nicht davon sprechen, dass es falsch wäre, Flächen bis zur Straße auszudehnen. Das könntest Du doch überhaupt erst dann, wenn Einigkeit über die Grenzen bestünde, sprich eine Definition dazu durch Konsens entstanden wäre. Im Sinne des Datenmodells kann eben die Aussage das Wohngebiet wird durch die Straße begrenzt selbst dann richtig sein, wenn dort noch ein Graben und eine Leitplanke dazwischen ist. Solange es keine genauere Grenzdefinition von Gebieten durch das Datenmodell gibt, entscheiden wir durch Mapping-Praxis was evtl. mal Teil des fortlaufend spezifizierten Datenmodells wird. Da OSM keine Katasterkarte ist und vermutlich auch nicht sein wird, hat /für mich/ topologisch korrektes Mappen (also wie stehen Objekte in Bezug zu anderen Objekten) einen wesentlich höheren Stellenwert, als das submetergenaue Taggen der Flächenausdehnungen von Flächen, deren Grenzen nicht klar definiert sind und nur durch amtliche Bestätigung überhaupt eine Belastbarkeit erfahren würden. Falls OSM doch irgendwann zur Katasterkarte mutiert, also fast alles als Flächen erfasst wird, erübrigt sich der Wunsch nach korrekter Topologie innerhalb der Basisgeometrie, die wäre dann automatisch gegeben. Dann wird aber vermutlich ein linienhafter Routing-Layer übrig bleiben, der nicht mitgerendert wird. Damit hätten wir dann auch die Routing-Leute von den Flächenerfassern getrennt, *freu*. Grüßle, Christian ich halte es für einen Irrweg, der weitere Verfeinerungen erschwert und dem Mapper der dort etwas ändern will unnötige Komplikationen bereitet. Andere halten das für einen sehr guten Weg, der ihnen das Editieren/Programmieren/Abbilden erleichtert und zudem die Qualität der Daten erhöht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 22.08.2011 07:10, schrieb Joerg Fischer: Und der Nächste, der einen fehlenden Weg ergänzt, der mit der bereits vorhandenen, aber fälschlicherweise an die Fläche gepappten Straße verbunden ist? Der muß entweder ganz genau hingucken (umständlich) das er den neuen Weg mit der Straße und nicht mit der Fläche verbindet Ganz genau hinschauen muss er eher, wenn die Fläche /nicht/ an den Weg gepappt ist - denn dann ist es fast Zufall bei entsprechender Zoomstufe, ob der node in den Weg der Fläche eingefügt wird, oder in den Weg. Sind beide aneinander geklebt, wird der node in beide Wege eingefügt. Da gibt es überhaupt kein Problem. Man kann viel mehr falsch machen, wenn zwei Wege dicht beieinander liegen - und die Fehler die daraus resultieren, sehe ich auch immer wieder. mal ehrlich: eine eingezeichnete Fläche hat wahrscheinlich noch niemanden daran gehindert, weitere Details einzutragen, nachdem er sie in der Realität entdeckt hat und/oder mit dem Kartendetailgrad unzufrieden ist. Doch. Mich. Schon oft. Es genügt das ich den Straßennamen nachtragen will oder ein maxspeed oder was auch immer. Stets muß ich die Scheißfläche (sorry) und den Weg auseinander fieseln nur weil der Vormapper das nicht konnte oder wollte. Na der wird sich bei Dir bedanken. Weshalb musst Du das denn auseinander fieseln, nur weil Du den Straßennamen ändern willst? Nutzt Du einen alten oder raren Editor? In JOSM: Mittelklick _oder_ selectaction.cycles.multiple.matches=true in den Prefs setzen In Potlatch2: ) um einen node in mehrere ways einzufügen - node zeichnen, J drücken ) um durch mehrere mögliche overlapping ways zu wechseln - eine der Tasten / # * probieren ) siehe http://wiki.openstreetmap.org/wiki/Potlatch_2/Shortcuts ) know your editor.. Falls etwas nicht wie erwartet funktioniert, wäre wohl ein Bugreport zu schreiben - dokumentiert ist es jedenfalls. Rechentechnik tendierte in den letzten Jahren nicht dazu langsamer zu werden. Ich glaube nicht, das wir ab jetzt, wo Deutschland ja sehr gut erfasst ist, das Moorsche Gesetz noch schlagen können. Tschaui, Jörg Deutschland ist mitnichten sehr gut erfasst. Ich wäre nichtmal bei einem zufriedenstellend.. Und wenn Du jetzt nicht gerade auf Quantencomputer wartest, gibt es sehr wohl Gründe, Komplexität im Auge zu behalten. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 22.08.2011 19:35, schrieb M∡rtin Koppenhoefer: Am 22. August 2011 11:54 schrieb Dimitri Junkero...@dimitri-junker.de: Aber nenn mir doch mal ein konkretes Bsp wo die getrennten Linien Sinn machen, also folgende Bedingungen erfüllt sind: ... Gegenfrage: wieso sollte man es beim Rendern dem Zufall (der Straßenbreitendarstellung) überlassen, wo eine Fläche aufhört? Was soll daran besser sein, wenn der Park auf dem Gehweg oder im Rinnstein endet anstatt dort, wo er tatsächlich zu Ende ist? Gerade beim Rendern von großen Zoomstufen ist es doch erwüscht, auch Details erkennen zu können, eine Vergrößerung der Flächen potentiell bis zur Straßenmitte (wenn man nur ein Haarlinie rendert oder die Straße ganz weglässt) schadet mehr als sie vermeintlich nützt. war hier nicht das credo, dass wir nicht für renderer taggen? und der Renderer überlässt nichts dem Zufall, er rendert an der Stelle die Fläche, an der die Straße aufhört. Wenn es topologisch richtig gemappt ist, kann der Renderer also entscheiden, wie groß die Überhöhung der Breite der Straße im jew. Zoomlevel ausfällt und damit, wo mit dem Rendern der Fläche begonnen werden soll. Das ist nämlich dann gar nicht mehr die Entscheidung des Editierenden, sondern desjenigen, der das Layout der Karte bastelt. Features die in der Straßenkante auftauchen, weil sie topologisch falsch gemappt sind, sind ein Hack des Editierenden, um etwas in der Karte anzuzeigen, das der Layouter berücksichtigen müsste - der, welcher den Rendercode bzw. das Stylesheet schreibt. meine 5cent, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 21.08.2011 18:59, schrieb M∡rtin Koppenhoefer: Am 14. August 2011 16:40 schrieb Christian Müller cmu...@gmx.de: Am 14.08.2011 15:57, schrieb Bartosz Fabianowski: Wegesrand an. Ein Aneinanderkleben ist daher IMHO geographisch nicht korrekt. Geographisch evtl. nicht, topologisch hingegen schon. M.E. sollte man für die Topologie-Fanatiker eine Relation oder irgendwas einführen, damit die Graphen-Flächen-Inkompatibilität überwunden wird. Flächen bewusst falsch zu zeichnen, damit sie mit dem Graphen-Modell der Straßen topologisch verbunden sind, sehe ich als Irrweg. Erst recht, da dadurch das Editieren fehlerträchtig und umständlicher wird. Es ist nicht umständlicher, es ist nur eine Gewohnheitssache. Flächen werden nicht falsch gezeichnet, sondern nach dem Stand des Wissens. Sobald jemand mehr Informationen hat, wird er einen Grünstreifen (z.B.) als Fläche dazwischenpacken und mit diesem Edit das Wissen ergänzen und die Genauigkeit erhöhen. Ich hatte mich schon in einer längeren mail dazu ausgelassen, dass man bei OSM nicht ständig von falsch sprechen sollte, sondern maximal von ungenau. Die Genauigkeit lässt sich immer durch Fleißarbeit erhöhen, das geht aber eben nun nicht alles auf einmal, sondern ist die Arbeit von Jahren. Bis hierhin ist ja auch schon einige Zeit vergangen. Gruß, Christian Der Wegesrand beginnt, topologisch gesehen, links und rechts des Weges, welcher in OSM durch eine Linie repräsentiert wird. wobei es hier nicht darum ging, den Wegrand zu mappen, sondern um angrenzende Flächen. Es ging darum, ob ein Gebiet, dass an einen Wegrand grenzt, an den Weg zu kleben ist, oder nicht. Wenn auch der Wegrand durch die Mittellinie repräsentiert wird, was der Fall ist, da die Linie den ganzen Weg repräsentiert, kann ein Gebiet geklebt werden. Um einer Diskussion vorzubeugen, mit der wir uns wieder im Kreis drehen: Ich rede vom unmittelbar angrenzenden Gebiet, welches, nach Stand der Daten, genauer (z.B. ein Kiesstreifen) oder ungenauer (z.B. ein Wohngebiet) sein kann. Vorteile: - kein Niemandsland zwischen Straße und Gebiet m.E. kein Vorteil, das gaukelt nur Vollständigkeit vor, wo eigentlich Details hingehören (könnten) ;-) Wir lassen _nirgend_ sonst Löcher der Vorsorge Willen. Warum hier? Und mal ehrlich: eine eingezeichnete Fläche hat wahrscheinlich noch niemanden daran gehindert, weitere Details einzutragen, nachdem er sie in der Realität entdeckt hat und/oder mit dem Kartendetailgrad unzufrieden ist. - mehr Übersicht im Editor (vgl. tausende nodes an einer Kreuzung) m.E. das Gegenteil: völlig unübersichtlich, da alles auf eine Linie läuft, auch wenn es gar nicht zusammengehört. Eine Linie für ein Objekt ist m.E. übersichtlicher. Wenn es nicht zusammengehört, dann gehört es auch nicht auf eine Linie. Wir sprachen von Dingen, _die_ zusammengehören, nämlich aneinandergrenzende Features. - weniger nodes das stimmt, aber ist nicht unbedingt ein Vorteil, es sind dadurch ja auch weniger Informationen enthalten. Wenn die Dinge zusammengehören, sind weniger, aber genauere Informationen enthalten. Ein node, der momentan eine Fläche begrenzt und nicht mit dem nahe liegenden Weg verknüpft ist, sitzt momentan oft sowieso an der falschen Stelle. Da ist die topologisch korrekte Information dann auch mehr Wert, als guess-work, basierend auf unscharfen Luftbildern. - geringere DB Größe / weniger Ressourcenverbrauch ja, am kleinsten wird sie, wenn man alles löscht ;-) haha, lustig. Trägt aber nichts zur Sache bei ;-) - das ist z.B. interessant, wenn ein großes Datenset in den Editor geladen wird, oder man die Daten für mobile Geräte fit machen möchte dazu braucht man Informationen nicht weglassen: Editoren könnten auch mit größeren Datenmengen umgehen, wenn sie dafür optimiert werden Hast Du dich denn schonmal mit ein paar Programmzeilen von JOSM auseinandergesetzt oder den Leuten, die versuchen, der Datenexplosion, die die Mapper kreieren, Herr zu werden? Oder bist Du der Chipindustrie Advocat? Auf einer teuren Workstation kannst Du momentan einen germany-extract mit JOSM öffnen (bringe entsprechende Zeit mit). Wenn sich die node-Krankheit in OSM weiter ausbreitet geht das irgendwann nicht mehr. Exponentiell wachsende Probleme sind in der Informatik nach wie vor die interessantesten, weil sie schwer bis gar nicht zu lösen sind. Wenn wir uns nicht mehr Gedanken über Datenhygiene machen, wird OSM irgendwann uninteressant, auch wenn es kostenlos ist. Ganz einfach weil mit den Daten dann selbst der Ärmste (das sind i.A. nicht die mit den fetten Workstations) nichts mehr anfangen kann. Und eigentlich ist man ja angetreten, weil it's better when it's free. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 21.08.2011 19:08, schrieb M∡rtin Koppenhoefer: Am 15. August 2011 02:14 schrieb Christian Müller cmu...@gmx.de: Um nochmal auf den Zaun zurückzukommen. Einfach gesprochen, wenn der eine Fläche einsäumt, lassen Mapper m.W. auch keinen Platz zur Fläche - hier ist das Verkleben ein Automatismus. Die Ausnahme ist hier nur die Straße, wo einige behaupten, der Mittelgraph wäre die Fläche (m.E. wird man irgendwann - und einige machen das jetzt schon - Straßen zusätzlich als Fläche eintragen, und dieses Thema löst sich von selbst), bei Zäunen gibt es kein Problem. Ja eben, und dann wird man auch Flächen, die an die Straßenfläche grenzen kleben. Das ist ja gerade mein Punkt: da sind wir noch nicht. Momentan wird die Straßenfläche durch die Linie repräsentiert, also kann ich die Fläche, die an die Straße grenzt, an die Linie kleben. Derjenige, der dann die Straßenfläche einzeichnet, klebt die grenzende Fläche dann nicht mehr an die Linie, sondern an die Straßenfläche. Das sind aber eben noch ein/zwei Jahre, bis das großflächig Einzug hält. Und Du kannst ja Leuten, die jetzt (noch nicht in OSM existierende,) angrenzende Flächen eintragen, nun nicht vorschreiben, dass sie jedesmal, wenn sie mit dieser Fläche an eine Straße geraten, gefälligst gleich die Straßenfläche zusätzlich zu ihrer Arbeit eintragen. Gewünscht ist das vielleicht, evtl. machen es schon einige, vorschreiben will und sollte das aber wohl niemand. Dennoch können wir uns wünschen, dass Zusammengehörigkeit in den Daten korrekt ausgedrückt wird (auf der Genauigkeit, auf der wir momentan sind). Gruß Wir taggen den way mit barrier=fance und die Fläche, die er umschließt, auf demselben way mit landuse=* - da gibt es auch kein Niemandsland dazwischen. das ist nicht unbedingt so: Spaghetti-Mapping geht sicherlich so, aber man kann auch zweimal denselben Weg zeichnen, einmal als Line-Feature (Zaun) und einmal als Flächenfeature (Landuse, leisure, natural, etc.), was dann für Klarheit sorgt, wenn man weitere Tags ergänzt (z.B. name, wo ein Mensch noch einigermaßen sicher sagen kann, dass sich das wohl auf die Fläche bezieht, ein Computer es aber u.U. auch auf den Zaun beziehen würde). Na super, und der zweite Weg wird dann irgendwie ins Wilde gezeichnet? Obwohl die Fläche bis zum Zaun reicht? Oder sprichst du mit denselben Weg davon, dass Du einen way über dieselben Nodes zeichnest (was ja gerade topologisch richtig wäre)? Als Verbesserung dieser Methode würde man anstatt eines doppelten Weges ein Multipolygon für die Fläche verwenden (mache ich persönlich z.B. so). Ja, und das gefällt mir. Denn das ist topologisch richtig und doppelte nodes hast Du auch nicht (wenn der Zaun-way als Rolle outer/inner am Multipolygon teilnimmt). Das ist ein gutes Beispiel für weniger Daten aber besseres Wissen. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 21.08.2011 20:06, schrieb Dimitri Junker: Also meiner Meinung nach gibt es nur 2 Möglichkeiten, entweder wir bleiben bei 1D-Straßen und nehmen diese auch als Flächenbegrenzung oder wir zeichnen die Straßenränder und nehmen diese dann als Grenzen. Bei Flüssen benutzen wi ja beide Varianten. Bei Straßen wäre es meiner Meinung nach übertrieben, es sei denn sie wird zu einem breiten Platz. +1 Danke, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 14.08.2011 15:57, schrieb Bartosz Fabianowski: Es gibt hier keinen etablierten Standard. Ich selbst habe lange Zeit Wege und Landnutzungsflächen aneiandergeklebt bis mir die Probleme zu denen das führt erklärt wurden und ich aufgehört habe. Das gängige Argument fürs Aneinanderkleben ist daß die Landnutzung da anfängt wo die Straße aufhört. Das Gegenargument dazu ist daß wir ja nur die Mittellinie der Straße mappen. Die Landnutzung dagegen fängt erst am Wegesrand an. Ein Aneinanderkleben ist daher IMHO geographisch nicht korrekt. Geographisch evtl. nicht, topologisch hingegen schon. Der Wegesrand beginnt, topologisch gesehen, links und rechts des Weges, welcher in OSM durch eine Linie repräsentiert wird. Ein Standard ist nicht etabliert, ich pers. klebe Flächen gern aneinander aus folgenden Gründen: Vorteile: - kein Niemandsland zwischen Straße und Gebiet - mehr Übersicht im Editor (vgl. tausende nodes an einer Kreuzung) - weniger nodes - geringere DB Größe / weniger Ressourcenverbrauch - das ist z.B. interessant, wenn ein großes Datenset in den Editor geladen wird, oder man die Daten für mobile Geräte fit machen möchte Nachteile: - ein wenig mehr Aufwand, wenn ein Gebiet / Straße umverlegt wird - mit JOSM: 2 nodes auswählen, Gebiet trennen, die 2 nodes mit neuem way verbinden (evtl. wieder über existierende ways), und, nicht vergessen, alten Streckenzug löschen Beim Editieren zeigen sich zwei Hauptunterschiede. *) Der Verlauf nicht geklebter FlächenStraßen kann (oder muß, je nach use case) getrennt voneinander editiert werden. Das wird bes. von Neulingen als Vorteil empfunden, weil sich beim Verschieben von Objekten keine Gedanken über evtl. Abhängigkeiten gemacht werden muss. *) Bei geklebten Flächen/Straßen bleibt eine Änderung solange einfach, wie die Topologie erhalten bleibt - ich muss nicht, wie in 1), beides getrennt voneinander ändern, wenn ich in der Tat beides auf gleiche Weise ändern möchte. Das kommt häufig vor, wenn man Straßenverläufe verfeinert. Ändert sich die Topologie, muss aber der Kleber entfernt werden und für den neuen Streckenverlauf evtl. neue Knoten erstellt werden. Hat man sich daran gewöhnt, ist der Aufwand imho nicht höher, als bei der anderen Variante. Für mich überwiegen daher die Vorteile des Aneinanderklebens. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 14.08.2011 16:50, schrieb Bartosz Fabianowski: Absolut unverständlich ist es mir jedoch, wenn Wald und Wiese (ohne Weg dazwischen) aneinander stoßen und es dennoch keine gemeinsamen Punkte gibt. Das stimmt. Da klebe ich auch. Ein Fall den ich öfters diskutiert habe und immer noch nicht sicher bin sind Parkplätze und Gebäude: Reicht ein Parkplatz bis an die Gebäudewand und wird geklebt oder sollte da Platz zwischen bleiben? Du mappst die Realität. Wie genau Du das machst, bleibt Dir überlassen. Wenn der Parkplatz bis zur Wand heranreicht ist es klar - kleben. Falls ein Blumenbeet dazwischen ist, kannst Du ja das Blumenbeet mitmappen ODER Du verstehst es als zum Parkplatz gehörig ODER es gehört zum Gebäude und geht in dessen landuse=* mit ein.. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 15.08.2011 00:53, schrieb Garry: Am 14.08.2011 16:40, schrieb Christian Müller: Geographisch evtl. nicht, topologisch hingegen schon. Der Wegesrand beginnt, topologisch gesehen, links und rechts des Weges, welcher in OSM durch eine Linie repräsentiert wird. Ein Standard ist nicht etabliert, Was verstehst Du unter Wegrand? Zwischen der Verkehrsfläche und dem Wald, Wiese etc. liegt fast immer noch was anderes - Entwässerungsgraben, Schutzfläche, Lärmschutzwand, Gebüsch,... Solange das nicht gemappt ist, interessiert es in OSM nicht. Wenn Entwässerungsgraben, Schutzfläche, etc. gemappt werden, wird die Topologie geändert. Der Wegesrand ist dann detailierter erfasst, die Aussage Gebiet beginnt am Wegesrand wird dann zu Gebiet beginnt an Schutzfläche oder, noch genauer Gebiet beginnt an Schutzfläche, welche an Wegesrand grenzt. In diesem Moment zieht man in OSM die Grenzen neu, weil man mit der Aufnahme neuer Daten den Detailgrad erhöht. Ich verstehe die Arbeit an OSM also als inkrementelle Arbeit. Details die in OSM nicht erfasst sind, sollte man nicht berücksichtigen (bis sie erfasst werden), weil sich über sie (noch) keine Aussage treffen lässt. Vgl. das Erfassen eines großen Waldes. Erst wird grob der Umriß gezeichnet, später packt ein anderer Löcher rein. Solange ich nur zwei Datenobjekte in OSM habe, spreche ich davon, dass das Gebiet an die Straße grenzt. Die Aussage ist solange genau genug, bis jemanden stört, dass da noch etwas dazwischen ist. Aber bis dahin ist sie eben genau genug, das ist entscheidend. Wenn das dazwischen interessiert, sollte es gemappt werden. Interessiert der Entwässerungsgraben, mappe ihn, interessieret der Grünstreifen zwischen Graben und Straße, mappe auch ihn. Egal bei welchem Detail Du ankommst, die Aussage ein Gebiet grenzt an ein nächstes wird immer korrekt sein, solange Du nicht über noch konretere Dinge sprichst. Solange der Graben also nicht interessiert, er also nicht gemappt ist, wir also nicht wissen dass er da ist, geht er als (noch nicht gemapptes) Detail im gröberen Gebiet/landuse unter. Du könntest nun argumentieren, ein Stück Niemandsland als Platzhalter mache Sinn, weil da noch etwas sein könnte. Das ist aber genau so falsch oder richtig, wie es wäre, wenn Du das Gebiet anklebst. Denn zum einen könnte da tatsächlich nichts mehr sein, das uns noch interessiert und zum anderen, wenn da noch ein Graben ist, müsstest Du bei allen neu erfassten Waldflächen überall vorsorglich Löcher zeichnen, denn in denen könnte ja auch immer noch etwas sein. Ich will damit nur aufzeigen, dass es keinen Sinn macht, über Dinge zu sprechen, die noch nicht gemappt sind, wenn man sich über Topologie unterhält. Die werden erst relevant, wenn man sie einträgt, bzw. zur DB hinzufügt. Auf dem Detailgrad, den man hat, ist es IMHO besser und hübscher, wenn die Flächen verklebt sind. Auch wenn wir nicht für sie mappen, gibt es z.B. für Renderer Vorteile, denn die Übersichtlichkeit kommt auch dort, gerade bei hohen Zoomstufen, an. Für mich bleibt als einzig wesentliches Argument gegen das Verkleben nur, dass es für Einsteiger auf den ersten Blick einfacher ist, zu sehen, was wo hingehört und wie etwas zu ändern ist. IMHO begründet sich das auf einem bessern visuellen Feedback des Editors. Denn man sieht die Grenze auch ohne das Gebiet markiert zu haben. Grüße Christian ps: noch ein prakt. Beispiel Interessant wird die Geschichte, wenn wir z.B. folgendes betrachten: Eine Straße, welche an ein Gebiet grenzt, das von einem Zaun umschlossen wird. Uns interessieren nur diese Features, nicht, ob dort noch etwas dazwischen ist. Zaun und Straße werden in OSM als Linienfeature erfasst, sie liegen in der Realität aber nicht aufeinander, also müssen sie getrennt voneinander gezeichnet werden, um dann das Gebiet mit dem Zaun zu verkleben - je nachdem, ob das Gebiet am Zaun endet, oder doch am (hier nicht näher spezifizierten) Straßenrand. Zaun und Straße werden aber nicht verklebt, zwischen ihnen ist aber kein Niemandsland, sondern der Abstand Straßenrand-Straßenmitte. Würden wir die Straße als Fläche erfassen, was sie eigentlich ist, würden wir sie mit dem Zaun verkleben, denn letzerer trennt Gebiet von Straße fast mit einer Breite von null (bzgl. OSM-Verhältnissen). Die Straße /mit ihren Rändern/ wird aber in OSM als Linie abstrahiert. Solange ihre Grenze (hier: der Zaun) nicht näher gemappt ist, können wir also davon sprechen, dass die Linie nicht nur Mitte, sondern auch den Rand repräsentiert (linker oder rechter ist egal, denn durch die Abstraktion werden diese Details ja weggeworfen). Wir können also auf jedem bel. Detailgrad davon sprechen, dass etwas an etwas anderes grenzt und das kann man doch topologisch dann auch so darstellen und mappen, oder nicht? Es geht ja in OSM um ein Abbild der Realität, das einen begrenzten Detailgrad hat. Für diesen (aktuellen) Detailgrad, sollte IMHO die Topologie so gut sein, wie es geht. Um nochmal auf
Re: [Talk-de] Zeichenstil
Am 13.08.2011 09:49, schrieb Bodo Meissner: Am 12.08.2011 22:34, schrieb Christian Müller: Grundsätzlich sollten Löcher in Vielecken (eine innere Linie ist Grenze eines Lochs im Polygon) andere Tag-Werte haben, als das äußere Vieleck des Multipolygons - denn nur dann macht es i.d.R. Sinn, ein Loch zu erfassen. Diese Bedeutung der Fehlermeldung ist IMHO nicht erkennbar. Vielleicht wäre es besser, anstelle von Zeichenstil das Wort Eigenschaften zu verwenden: Eigenschaften der inneren Linie mit Multipolygon identisch +1 sehe ich auch so, das sollte man in JOSM ändern, dort wird das Wort Zeichenstil im Sinne der Eigenschaften gebraucht Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baumreihen, Alleen an Straßen
Am 12.08.2011 15:23, schrieb Albrecht Will: Ich vergaß noch zu erwähnen, dass beim Hochladen von natural=tree_row eine Fehlermeldung kam, die Fläche sein nicht geschlossen. Ich habes trotzdem erstmal hochgeladen. IIRC unterstützt JOSM natural=tree_row noch nicht. Ähnliches gilt für Mapnik - solange niemand das Stylesheet anpasst, wird die Allee also vermutlich nicht auf der Karte erscheinen. Das ist aber kein Beinbruch - es gibt viele Daten in der DB, die nicht auf der Karte erscheinen, aber trotzdem für Anwender der Daten wichtig sind / sein können. Es ist davon auszugehen, dass das Mapnik-Stylesheet tree_row irgendwann unterstützt, denn einzelne trees werden ja auch gerendert. Die Frage ist halt nur, wann sich jemand findet, der es einarbeitet. Grüße Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeichenstil
Möglich, dass die Daten aus dem anderen Ort auch schon unkorrekt sind. Grundsätzlich sollten Löcher in Vielecken (eine innere Linie ist Grenze eines Lochs im Polygon) andere Tag-Werte haben, als das äußere Vieleck des Multipolygons - denn nur dann macht es i.d.R. Sinn, ein Loch zu erfassen. Angenommen wir erfassen einen Wald, der mehrere größere Wiesen umschlingt. Dann bekommt das äußere Vieleck (und/oder die Relation des Multipolygons) die Tags für den Wald, die inneren Vielecke, bzw. Löcher werden mit den Tags für die Wiese versehen. Falls ein inneres Vieleck die gleichen Tags wie das umgebende, äußere Vieleck hat, sollte das innere Vieleck nicht erfasst werden, denn dessen Inhalt ist schon mit den Tags des äußeren Vielecks beschrieben. Manchmal macht es Sinn, Wald in Wald darzustellen, etwa weil z.B. der Besitzer oder die Flora wechselt - das spiegelt sich dann aber in den Tags (operator/denotation/etc.), womit Du dann wieder einen unterschiedlichen Zeichenstil hättest. Es gibt noch komplexere Multipolygone mit höherer Verschachtelungstiefe, es ist z.B. denkbar, dass in einem der Löcher ein weiteres ist, z.B. inmitten der Wiese, um beim obigen Beispiel zu bleiben. Dann erhält die Grenze des Teichs wieder die Rolle outer. Wenn Dich das näher interessiert, siehe hier: http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon Gruß Am 12.08.2011 21:53, schrieb Albrecht Will: Tut mir leid, wenn ich nerve. Aus einer Fehlermeldung fürs Hochladen: Zeichenstil für innere Linie mit Multipolygon identisch Ich habe von einer gleichen Situtation in einem anderen Ort abgekupfert und finde das winzige i-Pünktchen anscheinend nicht raus. Im Englischen kann ich nicht suchen, weil ich keine Übersetzung d/e weiß. Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baumreihen, Alleen an Straßen
Am 11.08.2011 21:13, schrieb Albrecht Will: Hallo Martin und Tobias, das ist doch schon was. ABER: Ich denke, die Information ist nicht ausreichend. Gutes Kartenmaterial macht es vor - Baumreihe links oder rechts oder beidseitig. So müßte es sein. Von CAD her gedacht, sind solche Liniensignaturen durchaus nichts besonders. (Linie + Kreis, definierter Abstand zur Linie und Anstand der Kreise untereinander). Je nach Richtung der Linie sitzen die Kreise links oder rechts. Ließe sich das machen? Nein - Josm oder OSM sind kein CAD, sondern captured reality. Es wäre IMHO sogar falsch im Editor solche komplexen Funktionen zur Konstruktion anzubieten, denn es verleitet dazu, die Realität mathematisch genauer abzubilden, als sie es ist. OSM sammelt Daten der Realität. Beim CAD geht es mehr darum, sie zu manipulieren. Vgl. ein math. Modell eines erträumten Landschaftsparks, der dann gebaut wird. Wenn Du das Ergebnis dann in OSM erfasst, sollte es Ziel sein, der Realität näher zu sein, als dem CAD-Vorbild. Auf dein Beispiel bezogen: Ein Baum der Allee könnte fehlen, nicht alle Bäume haben evtl. den gleichen Abstand, etc. pp. Weiterhin, wenn Du mit natural=tree_row denotation=avenue eine Linie neben die Straße setzt, lässt sich ausrechnen, ob eine Allee die Straße säumt. Alternativ kannst Du Allee und Straße auch mittels Relation verknüpfen. Das wird z.B. häufig bei straßenbegleitenden Rad- und Fußwegen praktiziert. Während der Planungsphase einer zu gestaltenden Landschaft ist es in CAD-Systemen durchaus wünschenswert, Allee und Straße im Datenmodell so verknüpft zu haben, dass sich die Allee automatisch mitbewegt, wenn man die Straße verlegt (oder umgekehrt). Im Abbild der Realität, welches OSM nahe kommen möchte, ist das weniger nötig - häufig betreffen Änderungen (Baumaßnahmen) dann nur ein Feature - also Abholzen der Allee, Umnutzung der Straße, Renaturierung, etc. Es gab eine ganze Zeit lang viele Proposals, welche zum Ziel hatten, die Erfassung von Linienbündeln zu vereinfachen. Einige Lösungen blieben dabei, nur eine Linie für eine 4-spurige Straße mit 2 Tramgleisen, sowie Fuß- und Radwegen links und recht zu erfassen, um dann mit einem Plethora an Tags zu beschreiben, was diese Linie eigentlich darstellen soll. Andere waren dafür, selbst für jede Fahrspur eine Linie zu erfassen und den gemeinsamen Bezug über eine Relation darzustellen. Heute ist ein Mix in OSM zu finden - bei kompliziert abzubildenden Kreuzungen ist schonmal ein way pro Fahrspur zu finden, unkomplizierte Straßen bei welchen alle Features weitgehend parallel verlaufen werden tatsächlich mit einer noch überschaubaren Menge an Tags erfasst (etwa lanes=2, footway=track, cycleway:right=lane). Ich persönlich halte es so, dass all das, was baulich getrennt ist, durchaus auch getrennt erfasst werden sollte. Konkret wird also z.B. eine Fahrradspur als Tag der Straße, auf der sie markiert ist, erfasst (etwa cycleway:right=lane) und ein baulich getrennter Radweg als extra Linie/way, denn oft hat der auch andere Eigenschaften, z.B. Oberflächenbeschaffenheit oder Zugangsbeschränkungen. Es ist aber nicht falsch wenn Du z.B. während der Erfassung einer größeren Straße einfach cycleway=track setzt, wenn Du weißt, dass links und rechts baulich getrennte Radwege verlaufen, aber keine Lust hast, sie separat zu zeichnen / zu erfassen. Ich verstehe auch eine Bordsteinkante als bauliche Trennung, andere verstehen erst unüberwindbare Hürden als bauliche Trennung (z.B. Grünstreifen mit Busch, etc.) - das ist also z.T. eigene Ermessensfrage des jew. Mappers. Zurück zu deiner Allee: Sie ist baulich getrennt, also sollte sie getrennt erfasst werden. Wenn Du oft zur Straße strikt parallele Alleen erfassen willst, empfehle ich Merkaartor - der Editor kann parallele Ways zeichnen. In Josm kannst Du Dir mit der Funktion behelfen, die Flächen rechteckig macht - Fläche tempörär zeichnen, auf den gleichen Knoten, welche die parallel zu richtenden Ways stützen, dann q drücken, temp. Fläche wieder löschen. Vorteile: Leute, die es später überhaupt nicht interessiert, ob da eine Allee ist, können die Geometrie ohne viel Aufwand filtern. Umgekehrt lässt sich ausrechnen, ob eine Allee neben der Straße existiert und wenn der Verlauf nicht interessiert, dann einfach per Tag am highway hinzufügen. Nachteile: Die Erfassung erfordert das Hinzufügen von Geometriedaten/Linie+Tags. Es gibt große Ähnlichkeiten des Problems zu den Abwägungen, die bei der Erfassung eines straßenbegleitender, baulich getrenntem Radweges zu treffen sind - daher habe ich die Darstellung oben auch mit aufgenommen. Schlussendlich musst Du selbst entscheiden, wie weit Du gehst: - erfassen als Attribut der Straße/highway - erfassen als Linie+Tag neben der Straße/highway - evtl. zusätzliches Binden der Geometrie an die Straßenrelation Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org
Re: [Talk-de] Baumreihen, Alleen an Straßen
Es gibt natural=tree_row welches Du auf ways verwenden kannst. Das ist in der DB zwar häufig anzutreffen, aber wird von Mapnik oder den Josm-Vorlagen noch nicht unterstützt. Die Bäume einer so erfassten Baumreihe dann nochmal einzeln mit nodes auf dem way zu erfassen ist unüblich, aber nicht unmöglich. IIRC ist natural=tree_row ein noch nicht abgeschlossenes Proposal. Vereinzelte Bäume taggst Du mit natural=tree auf nodes. Für Gebiete gibt es Tags für Forste und Naturwald - siehe Wiki. Gruß, Christian Am 10.08.2011 14:17, schrieb Albrecht Will: Lange gesucht und nichts gefunden, habe ich den Wald vor lauter Bäumen nicht gesehen? Bitte mal ein Tip Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rekultivierte Mülldeponie
Am 08.08.2011 12:50, schrieb Albrecht Will: Danke Christian, und zum selben Ort noch eine weitere Frage: Der tag barrier=gate steht für eine Tor, das der Passant selbst öffnen und schließen kann. Ich habe einen 2. tag mit acces= no gesetzt, da das Betreten nur autorisierten Personen erlaubt ist. Reicht das? Hi Albrecht, wenn autorisierten Personen das Betreten erlaubt ist, besser access=private setzen. access=no wird z.B. verwendet, wenn der Zugang generell nicht erlaubt ist, aber für mehrere Nutzer Ausnahmen gemacht werden, z.B. access=no psv=yes forestry=yes - verbietet jedem den Zutritt, außer dem öffentlichem Nahverkehr und der Forstwirtschaft Es handelt sich immer um Zutrittsbefugnisse, also um ein dürfen, nicht um ein können. bicycle=yes z.B. beschreibt nur, dass auf einem Weg Fahrrad gefahren werden darf, _nicht_ ob der Weg dazu geeignet ist. Er kann z.B. in einem so miserablen Zustand sein, dass kein Radfahrer ihn nutzen würde. Nähere Details zu access-Arten findest Du im Wiki: http://wiki.openstreetmap.org/wiki/DE:Key:access Grüße Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rekultivierte Mülldeponie
disused=yes *http://wiki.openstreetmap.org/wiki/DE:Key:disused *evtl. noch http://wiki.openstreetmap.org/wiki/Key:start_date und http://wiki.openstreetmap.org/wiki/Key:end_date Gruß, Christian Am 07.08.2011 14:08, schrieb Albrecht Will: Hallo in die Runde, was müßte ich bei einer geschlossenen und/oder rekultivierten Mülldeponie taggen ausser landuse= landfill? Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kernkraftwerke?
Am 01.04.2011 21:05, schrieb Ulf Lamping: Am 01.04.2011 20:18, schrieb Philip Gillißen: Am 01.04.2011 20:08, schrieb Gary68: wie finde ich weitere in deutschland? oder sind das alle??? Ich würde einfach die Liste der Wikipedia nehmen. Daraus darfst du auch in OSM eintragen, da beide Projekte eine eine CC-BY-SA-Lizenz nutzen Ähm, dann ist eine Zustimmung zur ODBL nicht mehr möglich, die beiden Lizenzen sind inkompatibel ... Na prima, dass das niemandem vorher aufgefallen ist. Das macht die Zusammenarbeit zwischen den Projekten, die ja eigentlich gewünscht und forciert wird, zumindest vordergründig, ungemein schwerer. Bedeutet das z.B. auch, dass ich eine Koordinate der WP theoretisch nicht benutzen kann, um das Feature, dass sie beschreibt, in OSM einzutragen? Wäre ein Jammer.. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnort
Am 20.03.2011 14:35, schrieb Markus: PS: Vor allem die flächigen Attribute sind m.E. oft ziemlich willkürlich und ohne konkrete valide Aussage. Hi Markus, meist sind sie schon konkrete Luftbild-Schätzungen von Wohngebieten, die einem Wanderer oder Geocacher sehr genau sagen, wo er mit höchster Wahrscheinlichkeit privaten Grund betritt. Rechtliche Belastbarkeit hat landuse nicht, das hat aber auch der Rest von OSM kaum und diese interessiert Nutzer i.A. auch gar nicht. Bekannte administrative Grenzen sind in OSM anderweitig erfasst. landuse hat m.E. halt einfach andere Nutzungsfälle, z.B. - ich filtere mit Osmosis alle Gebäude raus, weil ich einen kleinen Datensatz haben möchte, die landuse Flächen sind dann sehr hilfreich, so wie die POI - es gibt tausende von Ortschaften, wo Häuser (noch) nicht gemappt sind - es sind viele Filtervarianten denkbar, bei denen mir es nicht hilft, nur die Gebäudemodell zu kennen ) Mapper können ohne weiteres Hand anlegen und Fehler in landuse-Flächen beheben. ) Du kannst natürlich auch landuse=residentials filtern (osmosis, josm, etc.), wenn Dich die Dinger stören Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 2x Fragen zum OSMAND
Am 10.03.2011 21:16, schrieb o...@tappenbeck.net:
hi !
ich habe zwei kleine Fragen auf die ich bisher keine Antworten im Netz
gefunden habe.
* wie kann man die Karten updaten ?
Ich nehme an, Du willst Dir aktuelle Vektordaten zusammenstellen:
1) hole https://osmand.googlecode.com/svn/trunk
2) baue DataExtractionOSM (ant laufen lassen)
3) in DataExtractionOSM/build OsmAndMapCreator.bat oder
OsmAndMapCreator.sh laufen lassen
4a) in OsmAndMapCreator File Select OSM File um ein obf komplett zu
wandeln
4b) in OsmAndMapCreator File Select OSM File Region um einen
rechteckigen Ausschnitt eines obf zu wandeln
Achtung: bei mir läuft OsmAndCreator _momentan_ nur sauber durch, wenn
ich das Häkchen bei Build Address Index.. entferne
- Ergebnis sonst: NullPointerException..
Wenn Du nur bereits gerenderte Tiles vorladen willst, dann mit
Linksklick Gebiet auf der Karte wählen und oben rechts Preload Area
wählen. In beiden Fällen steht Dir das Ergebnis dann in ${HOME}/osmand
zur Verfügung, was nach meiner Erfahrung nicht konfigurierbar ist.
Existiert osmand nicht, legt der MapCreator das Verzeichnis in deinem
HOME an..
Falls Du an OpenRouteService-Support in osmand interessiert bist -ich
habe da mal was geschrieben (tm)-, siehe hier:
http://code.google.com/p/osmand/issues/detail?id=370
Gruß,
Christian
* Navigation: bei mir ist nur ein spanisches Sprachpaket verfügbar.
Gibt es keine deutsche Version ??
keine Ahnung, ich nutze die Sprachnavigation nicht..
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Noch ein Gedanke zur Trennung von Verwendbarkeit/Rechtmäßigkeit: Wenn dürfen und können in den Schlüsseln so strikt unterschieden würden, wie die Liste das macht, hätten wir schon access:bicycle=known_values usability:bicycle=yet_to_be_defined_values or vote counts on usability oder meinetwegen auch umgekehrt: bicycle:access=* bicycle:usability=* (vote counts - http://www.mail-archive.com/talk-de@openstreetmap.org/msg82532.html) Ich wage aber zu bezweifeln, dass die community bereit wäre, alle bicycle=* values nach access:bicycle=* zu verschieben, eben weil nicht davon ausgegangen werden kann, dass jeder Mapper diesen Wert rein rechtlich im Sinne der Def. des Wikis verwendet hat. Als solches ist dann auch die scharfe Definition des Tags anhand der hier argumentiert wird nicht wirklich belastbar. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 08:23, schrieb Ulf Lamping: Ich halte es auch nicht für sonderlich intuitiv, für jeden einzelnen Fahrzeugtyp erraten zu müssen, ob man da langfahren kann / will, wenn ein anderer eingetragen wurde. Wenn du jetzt ein bicycle:trek=yes gesetzt hast: - will ich da auf einer Radtour lang? - komme ich da nur zur Not lang? - komme ich da mit einem Rollstuhl lang? - ...? Ein smoothness=bad ist vielleicht vom Begriff her erstmal unklarer, kann aber alle diese Frage tatsächlich beantworten - und ist letztlich einfacher zu setzen ohne noch 10 andere Tags setzen zu müssen, die letztlich auch nicht mehr sagen. Übertreibungen sind immer sehr konstruktiv. 1) es geht nicht um 10 tags, sondern um 3 2) für einen einzelnen Mapper geht es nicht um 3 tags, sondern um 1 (ein Trekker tagt nur bicycle:trekking) 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen 4) smoothness=bad sagt mir - will ich da auf einer Radtour lang? - komme ich da nur zur Not lang? - komme ich da mit einem Rollstuhl lang? - mir sagt es das mitnichten - bicycle:trekking=yes (ok, man muss nicht abkürzen) sagte mir schon, dass einer die strecke als für ein trekking rad geeignet erachtet - plane ich touren, betrachte ich natürlich, mit welchem Radtyp ich unterwegs bin - es gilt also konkret ein tag auszuwerten, wenn es existiert - das für meinen Radtyp - smoothness muss meinetwegen nicht abgeschafft werden, faktisch ist es, zumindest in meinem Raum kaum in Verwendung selbst wenn Sie definiert sein sollten - da smoothness in seiner Def.variante auch, wie Du schon feststellst, nicht gerade gängig ist, wohl auch aufgrund seiner undefinierten Historie, ?!? Die Definition war bereits Bestandteil des Proposals. Dann gab es damals noch kein Proposal. Ich meine mich zu erinnern, dass auf jeder tollen Liste über die Definitionen gezankt wurde, bis jemand kam, der Rad- und Inlinertypen auf die Werte dieses Tags gepresst hat (und nicht andersherum). möchte ich nochmal auf das was Du schreibst eingehen, denn wenn man die access-Methodik auf die Fahrradtypen anwendet, ergeben sich schon feiner (und auch objektiver) granulierbare Taggings. Die Aussage, mit welchem Fahrradtyp man da langfahren kann oder will, ist mit deinem Schema genauso (wenig) objektiv wie bei smoothness. Das ist falsch. Bitte setze Dich mit meinem Vorschlag auseinander. Ich schrieb schon, dass die klare begriffliche Trennung vermutlich dazu führen wird, dass Trekker eher :trekking, MTBler eher :mtb und Rennradler eher :race nutzen werden - also pro Typ das Tag von einem Mapper, der am ehesten beurteilen kann, ob seine Radkategorie auf dem Weg nutzbar ist, gesetzt wird. Das ist eben mit smoothness mitnichten der Fall: hier weiß ich nicht, ob der tagger/mapper tatsächlich zu Fuß, mit dem Rad oder per Inline-Skates unterwegs war und auf welcher Grundlage er den Wert für smoothness entschieden hat. Ich habe also wesentlich weniger Information, um deine Fragen oben zu beantworten. Und für Rollstuhlfahrer gibt es wheelchair=*, btw.. bicycle=yes sagt (nur) aus ob man dort langfahren *darf*, nicht ob man dort langfahren will oder kann. Eben. Etwas anderes habe ich nie behauptet. Woher soll OSM wissen was ein Nutzer _will_? Bei kann sieht es schon anders aus. tatsächlich wird bicycle= wird auch gesetzt, schon wenn man nur dort langfahren *kann* - siehe designated auf [http://wiki.openstreetmap.org/wiki/Key:access]. Dort heißt es bei law or otherwise. Es geht bei der Zugangsbeschreibung nicht nur um die rechtliche, sondern auch um die tatsächliche Verwendung (wobei letzteres wieder subjektiver ist). Das lenkt aber vom Thema ab. Ich will mich nicht mit der Sinnhaftigkeit von access=* Werten auseinandersetzen. Denn die sind eigentlich etabliert, wenngleich Du scheinbar nur deren rechtlichen Aspekt beleuchtest 2) gerade wenn ich den access-Wertebereich auf bicycle:trek=* anwenden kann, lässt sich speziell für diese Radkategorie sehr schön unterscheiden (Weg von amtlicher/offizieller Seite für Trekking-Räder vorgeschlagen, oder nur yes, womit ersichtlich wäre: ja, es geht) Der Tagname ist etwas unglücklich. Rein logisch würde ich bei bicycle:trek=* annehmen, das man dort mit einem Trekking Fahrrad rechtlich langfahren *darf*. Das willst du aber ja nicht aussagen. Doch, genau das will ich sagen. Ich will die gleiche Bandbreite an Werten, die für das normale bicycle-tag zur Verfügung stehen und dort ausdrücken, ob Räder dort langfahren dürfen oder es tatsächlich überwiegend tun. Eine Mischung von rechtlichen Einschränkungen und Vorlieben der Radfahrer sollten wir hier tunlichst vermeiden um nicht noch mehr Unverständlichkeit zu produzieren.
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 08:39, schrieb Heiko Jacobs: Am 02.03.2011 03:27, schrieb Ulf Lamping: [1] Natürlich könnte man eine Art wissenschafliche Untersuchung starten (Welligkeit, Löcher, Rillen, ..., jeweils mit Höhe, Abstand, Form, Größe, Tiefe). Will sich aber wohl keiner antun. ... weil Ergebnis nur bis zum nächsten Regen gültig smoothness gilt immerhin bis zur nächsten Holzabfuhr ;-) ... womit wir schon beim Thema wären, dass eins daneben bei tracktype und smoothness im Rauschen der jahreszeitlichen Änderungen in Wald und Flur untergehen, wodurch sich jedes exaktere tagging eh obsoletiert ... Da steckt sehr viel Wahrheit drin. Da OSM aber das aktuelle Weltbild wiederspiegelt, ist das dann eben auch dynamisch - es gilt den aktuellen Zustand zu erfassen und der kann sich natürlich ändern. Die OSM-Daten haben kein absolutes Ziel, sie werden sich immer wandeln (müssen), so wie die Karten von traditionellen Herstellern auch. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo Rainer, Wenn die existierenden Tags (highway, tracktype, bicycle, surface, smoothness) korrekt und konsequent verwendet werden sind Renn- und Trekkingfahrer optimal versorgt. Oder anders ausgedrückt: für Renn- und Trekkingradler kann man eine Klassifizierung, wie Christian sie vorschlägt, aus den vorhanden Tags ableiten. Sie ist redundant und somit überflüssig. Und für die MTBler gibt es ja mtb:scale ;) Für eine Lösung auf Basis der existierenden Tags spricht auch, dass davon auch Nicht-Radfahrer einen Nutzen haben. Ich stimme in vielen Punkten mit Dir überein. Mir geht es auch nicht darum, Tags abzuschaffen, sondern welche hinzuzufügen. Du sprichst gerade das Problem an, dass ich habe. Tracks ohne tracktype und ohne surface, aber mit bicycle=yes. Ich finde halt, dass es falsch ist, ein so vielgestaltiges Fortbewegungsmittel, wie das Fahrrad, in einem Tag zusammenzuschmelzen. Gerade Anfänger taggen nicht mit komplettem Satz an existierenden Tags, geben aber schnell mal bicycle=yes ein. Wenn die ihre Zugangsbeschränkungen mit dem Tag eintragen würden, dass ihrem Radlerprofil entspricht, könnte man daraus Informationen extrahieren, die durch das Fehlen vieler anderer Tags noch nicht zur Verfügung stehen (tracktype, surface, smoothness). Als redundant sehe ich diese Tags nicht an, da sie radspezifische Verwendung rechtlich und nach Gebrauch beschreiben und, vordergründig, zumindest nicht direkt Aussagen zur Wegbeschaffenheit treffen. Das heißt nicht, dass man keine Implikationen auf die Beschaffenheit treffen kann, aber erst mit dieser (und dem Regelgerüst in deiner mail) stellt sich ein gewisser Redundanzgrad ein - der ist aber eher unscharf. Und angenommen alle Tags werden verwendet, dann dient das für andere MapperInnen fast zur Plausibilitätsprüfung, ich sehe darin also eher einen weiteren Vorteil. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 09:28, schrieb Chris66: Am 02.03.2011 02:13, schrieb Christian Müller: Hallo, Alles schön und gut aber wie willst Du garantieren dass die Mapper sich dran halten wenn sie schon das einfache Schema nicht kapieren und wild taggen ? Guter Punkt. Wenn man aber davon ausgeht, dass das einfache Schema evtl. deshalb nicht kapiert wird, weil es zu unscharf/ungenau oder unverständlich ist, hätten wir auch einen Grund, zusätzliche Möglichkeiten des Taggens wenigstens zur Verfügung zu stellen. Das ist doch das Problem der Standardisierung allgemein. All das, was im Papier nicht spezifiziert ist, ist in der Implementation frei wählbar. Und so ist das dann auch in jedweder Industrie (ob Soft- oder Hardware). Die Frage ist nur, ob ich mit einer Änderung des Standards tatsächlich näher spezifiziere (als vorher) oder eben nicht. Das Anpassen des Tagging-Schemas bei OSM ist ja ohnehin ein mehr oder weniger evolutionärer Standardisierungsprozess.. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 09:32, schrieb Henning Scholland: Hallo, du hast sicher recht, dass tracktype und smoothness subjektiv sind. Allerdings sollte man dabei nicht vergessen, was es bedeuten würde, dass ganze in objektive Kriterien zu gießen. Kaum einer würde mit einem Zentimetermaß die tiefe der Schlaglöcher nachmessen oder deren Abstand. Auch eine Statistik über die vorherrschende Größe der Kiesel halte ich für zu aufwändig, als dass es eine große Anzahl wirklich macht. Die Folge dürfte sein, dass die Masse der Mapper diese objektiven Kriterien ohnehin nur abschätzt. Dann macht es meiner Meinung aber auch keinen Unterschied zu einem Abschätzen von smoothness=bad. Nochmal, es geht mir nicht darum, smoothness=* abzuschaffen, oder dessen Definition in Frage zu stellen. Fakt ist, dass es sich nicht selbst erklärt, so wie es aber fast jedes andere tag in OSM tut (..erm.. tun sollte). Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 12:45, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 09:15 schrieb Frederik Rammfrede...@remote.org: Zugleich ist es aber nicht nach der Art von OSM, irgendwelche Schwammkategorien zu verwenden. (= also kein smoothness=bad - was fuer den einen bad, ist fuer den anderen superb) bad ist genau definiert. Das bedeutet, dass man stabile Räder benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann (robust_wheels) trekking bike, normal cars, Rickshaw and all below . Eine Stufe schlechter (very_bad) bräuchte man schon ein Auto mit großer Bodenfreiheit oder ein MTB, eine Stufe besser (intermediate) kommt man mit allgemeinen Fahrzeugen wie Rollstühlen und Citybikes auch noch durch. vielleicht sollte man die smoothness-Werte überdenken und gleich die Erklärungen, statt der schwammigen Wörter verwenden.. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 16:41, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 16:29 schrieb Christian Müllercmu...@gmx.de: 1) es geht nicht um 10 tags, sondern um 3 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen es geht um 3 zusätzliche tags allein für Radfahrer. Danach kommen die Rollstuhlfahrer mit 3 Typen, die Inlineskater mit 2 Typen, 4 Typen Kinderwägen, Tretroller, Einkaufswägen, Stelzen, verschiedene Arten von Schuhen, etc. Der Ansatz skaliert einfach ziemlich schlecht. Evtl., der bisherige aber auch: foot motorcar motorcycle motor_vehicle bicycle wheelchair psv hgv Wenn die Inliner kommen, sollen sie ihre Tags haben, genauso wie die anderen Leute. We can't have it, because it does not fit the spec. hatten wir schon vor OSM.. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 16:43, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 15:18 schrieb Rainer Klugerklug...@web.de: Das hatte ich schon befürchtet. Meine positive Meinung zu Tracktype muss ich wohl revidieren. Ob ein Weg befestigt ist, also asphaltiert, betonniert oder mit glatten Betonsteinen gepflastert, oder nur eine extrem kompaktierte Oberfläche hat, macht für mich schon einen erheblichen unterschied. Bei Regen und oft auch noch in den Tagen nach dem Regen sind solche Wege meist mit erheblicher Schmutzbildung verbunden und auch ein extrem kompaktierter Belag wird sich bei Dauerregen an der Oberfläche aufweichen. Vor ich eine Tour auf so einem Weg plane, will ich daher zumindest wissen, ob er befestigt ist oder nicht. ja, ich auch. Daher setze ich auch explizit den surface key, z.B. mit asphalt, concrete, paving_stones, ground, ... Der surface=* key z.B. ist in einem wesentlichen Punkt auch überladen: 1) Unterscheidung paved | unpaved (dt. befestigt | unbefestigt) 2) Materialien (manche Programme hinterlegen Listen, um best. Materialen auf paved | unpaved zu mappen.. da sich die Liste im Wiki erweitert/ändert - not good) Persönlich ist mir surface=* vor den anderen, sprachlich schlecht definierten Tagwerten (smoothness/tracktype mainly), noch am liebsten. Man kann surface=*, ohne groß das Wiki zu konsultieren, aus der Realität ableiten und umgekehrt direkt aus dem DB-Wert auch den Oberflächentyp wieder bestimmen. Das funktioniert hervorragend (in der Praxis!) - für tracktype=* hingegen schlecht und für smoothness=* fast gar nicht. Ich kenne die Wiki-Definition zu tracktype genau, aber sie ist eben ohne Wiki unbrauchbar (grade1-5 - was soll ein noob damit anfangen, wenn er das Wiki nicht kennt und es. evtl. gerade nicht verfügbar ist). tracktype/smoothness sollten m.E. die gleiche, _unmittelbare_ Aussagekraft erreichen, wie surface. Dann würde man sie in der Datenbasis auch häufiger und in richtiger Verwendung antreffen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 17:10, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 17:04 schrieb Christian Müllercmu...@gmx.de: Nochmal, es geht mir nicht darum, smoothness=* abzuschaffen, oder dessen Definition in Frage zu stellen. Fakt ist, dass es sich nicht selbst erklärt, so wie es aber fast jedes andere tag in OSM tut (..erm.. tun sollte). Dein Vorschlag widerspricht allerdings diversen Regeln: 1.Beförderungsmittel=yes/no/designated ist eine legale Attributierung. Von daher erklärt es sich auch nicht selbst, sondern verleitet zu Fehlinterpretationen. Ich schätze Du meinst rechtlich (engl. legal). Ja, Fehlinterpretationen möglich, in demselben etablierten Maße, wie für bestehende Beförderunsmittel - das ist ja gerade der Vorteil. Die meisten Mapper müssen nichts hinzulernen, denn sie kennen den Katalog rechtlicher Attribute bereits. 2. Tags sind auf Englisch. Welches meiner Tags ist nicht auf Englisch? 3. Wir verwenden keine Abkürzungen. Das wurde schon erklärt. Man muss sich nicht daran aufhängen, ob nun trek oder trekking verwendet wird. Ansonsten ist mir nicht klar, was Du mit 3. meinst. Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. da drückt man ein Auge zu, ganz korrekt im Sinne des Schemas ist das auch nicht. Ich verstehe nicht, wie Du darauf kommst - was sonst wäre denn im Sinne des Schemas? Das OSM-Schema ist ein evolutionäres Produkt und wächst mit den Anforderungen, wenig daran wurde wirklich durch-designed - it just-works (tm) or not, abhängig davon, was Du damit anfangen willst. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 17:19, schrieb Frederik Ramm: Hallo, On 03/02/2011 12:45 PM, M?rtin Koppenhoefer wrote: bad ist genau definiert. Das bedeutet, dass man stabile Räder benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann (robust_wheels) trekking bike, normal cars, Rickshaw and all below . bad ist ein ganz normales Wort des alltaeglichen Sprachgebrauchs und bedeutet schlecht. Instinktiv werden Leute es also bei einer schlechten Oberflaechenbeschaffenheit verwenden, und die Definition kannst Du in der Pfeife rauchen. Na endlich - ich dachte schon, dass mich hier gar niemand versteht :) Das ist exakt das, was ich sagen wollte. Es geht mir nicht darum, dass die Wiki-Definition eindrucksvoll, hübsch und komplett ist, sondern dass das Tag selbst schwach ist. Das Schema schlechtzureden bringt nichts. Schlechtreden kann man nur etwas, was an sich gut ist. Ich finde das Schema schlecht. Meine Alternative ist, das Mapping von Oberflaechenqualitaeten abseits von tracktype und surface sein zu lassen. Solang Leute das fuer sich selber als Hobby benutzen, mir egal, aber in dem Moment, wo jemand ankommen sollte und sowas sagen wie zu einer guten Erfassung von Wegen gehoert auch smoothness, werde ich dem widersprechen. +1 Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 17:57, schrieb Frederik Ramm: Hi, On 03/02/2011 05:50 PM, Christian Müller wrote: Der surface=* key z.B. ist in einem wesentlichen Punkt auch überladen: 1) Unterscheidung paved | unpaved (dt. befestigt | unbefestigt) 2) Materialien (manche Programme hinterlegen Listen, um best. Materialen auf paved | unpaved zu mappen.. da sich die Liste im Wiki erweitert/ändert - not good) Da musst Du mir als nicht-Bauingenieur aber mal nachhelfen. Kann denn eine Strasse mit z.B. surface=cobblestones mal paved und mal unpaved sein, oder wie muss ich das verstehen? Nein, es geht nur darum, dass surface Heimat für zwei Arten von Klassifikationen ist a) einer groben (befestigt, unbefestigt) b) nach verwendetem Material Konsistent bleibt das ganze, klar, weil sich Materialen i.d.R. der einen oder anderen, groben Klasse zuordnen lassen. Problematisch finde ich, dass durch neue Materialientypen, verschiedenste Softwareprojekte ständig ihre Klassifikation nachpflegen müssen, wenn sie surface=* verwenden (denn sie können sich ja nicht einfach darauf verlassen, dass paved oder unpaved drinsteht, sondern müssen alle Materialen auswerten, selbst wenn sie nur zw. paved|unpaved entscheiden wollen). Und was macht man z.B. mit Holz? Ich würde schon sagen, dass manche hölzerne Wege als befestigt gelten können (Hausbrücken z.B.), andere, wo nur ein paar logs verstreut im Sumpf liegen, eher nicht. surface=* ist auch nicht perfekt, aber es ist _wesentlich_ besser zu handhaben und brauchbarer, auch was die unmittelbare Lesbarkeit des tags betrifft, als tracktype/smoothness.. Grüße, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 18:11, schrieb Henning Scholland: Da versteh ich dich nicht so ganz... paved und unpaved sind allgemeine Werte, die man weiter spezifizieren kann, in dem man stattdessen das Material explizit erfasst. Hier gibt es keinen Widerspruch. Wenn Programme Listen führen, können diese Programme diese Listen genauso erweitern, wie es das wiki auch kann. Ich führe auch so eine Liste, die ich ab und an an das wiki bzw. an Taginfo anpasse. Das muss man aber generell bei jeder Auswertung machen. Eben, angenommen paved/unpaved würde extra erfasst (ich glaube da gab es sogar mal ein proposal, dass surface:material verwendet hat, um das Material konkret zu erfassen), müsstest Du, insofern Du an einer genauen Auswertung gar nicht interessiert bist, auch nicht diese Listen ständig mitpflegen.. deshalb meinte ich das tag sei überladen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 18:16, schrieb Simon Poole: Ein trekking bike ist in etwa so Englisch wie ein handy. Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone). Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht halbwegs klar definiert sind (wir taggen ja auch nicht typische residentials in Bergdörfern mit lambo=no oder subaru=yes). bitte dann den korrekten namespace verwenden motorcar:lambo=yes motorcar:subaru=no ;-) Dann mach halt einen besseren Vorschlag.. Im übrigen ist das gar nicht so verkehrt - es gibt ja auch unterschiedliche Klassen an Fahrzeugen. USVs, Pickups, etc. Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse ist. Und ein Engländer kennt doch sehr wohl auch den Unterschied zwischen Rennrad und Mountainbike. Wenn ihm die Kategorie Trekking nicht bewußt ist, ist das nur ein Zeichen, das hier das marketing versagt hat, oder andere Wege gegangen ist.. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 18:22, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 18:02 schrieb Christian Müllercmu...@gmx.de: in demselben etablierten Maße, wie für bestehende Beförderunsmittel - das ist ja gerade der Vorteil. Die meisten Mapper müssen nichts hinzulernen, denn sie kennen den Katalog rechtlicher Attribute bereits. verstehe ich jetzt nicht, Du willst es doch gerade nicht für ein Verbot, sondern für die Eignung verwenden. Deine Beispiele verwenden bicycle für eine Empfehlung (sandiger Weg - no), das ist nicht die Bedeutung des bicycle-tags. Hier bin ich Opfer der unscharfen Definition des access-tags in der Wiki. Viele OSMer auf _dieser_ Liste beschränken access=* auf rein rechtliche Gegebenheiten. Die englische Wiki zieht Eignung mit in den Wertebereich von access=* - bei designated z.B. (by law or otherwise). Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Dennoch müsst ihr auch hier wieder unterscheiden: 1) Die schöne, rechtlich orientierte, Definition von bicycle=* im Wiki 2) Die Verwendung in der Realität 3) Problem hier wieder: kein Namespace - nicht selbsterklärend Eigentlich spezifiziert, nach der Meinung dieser Liste, wenn ich es richtig aufgenommen habe, das bicycle=* Tag access=* näher, so dass, bei Verwendung eines Namespaces, die Daten eigentlich so aussehen müssten: access=* access:bicycle=* access:psv=* etc. So hübsch ist aber die OSM-Welt nicht, weswegen vermutlich auch viele Newbies bicycle=* und andere nicht im Sinne der Zugangsbeschränkung, sondern als Eignungswert verwenden. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 19:07, schrieb Andreas Perstinger: On 2011-03-02 18:46, Christian Müller wrote: Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Nur zur Info: zumindest Rennräder kennt der Gesetzgeber hier in Österreich. § 4. (1) Als Rennfahrrad gilt ein Fahrrad mit folgenden technischen Merkmalen: 1. Eigengewicht des fahrbereiten Fahrrades höchstens 12 kg; 2. Rennlenker; 3. äußerer Felgendurchmesser mindestens 630 mm und 4. äußere Felgenbreite höchstens 23 mm. (2) Rennfahrräder dürfen ohne die in § 1 Abs. 1 Z 2 bis 8 genannte Ausrüstung in Verkehr gebracht werden; bei Tageslicht und guter Sicht dürfen Rennfahrräder ohne diese Ausrüstung verwendet werden. (BGBl. II, Nr. 146/2001 - Fahrradverordnung) Rein interessehalber: Gibt es auch rennradbezogene Ge- und Verbote, was die Wegnutzung betrifft? z.B. Wege, auf denen ein Fahrradverbot besteht, Rennräder aber ausnahmsweise erlaubt sind? In diesem Fall müßte ich mein Implikationsschema überdenken. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 19:35, schrieb Andreas Perstinger: On 2011-03-02 18:27, Christian Müller wrote: Am 02.03.2011 18:16, schrieb Simon Poole: Ein trekking bike ist in etwa so Englisch wie ein handy. Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone). Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht halbwegs klar definiert sind (wir taggen ja auch nicht typische residentials in Bergdörfern mit lambo=no oder subaru=yes). bitte dann den korrekten namespace verwenden motorcar:lambo=yes motorcar:subaru=no ;-) Dann mach halt einen besseren Vorschlag.. Ich denke, das Grundproblem bei Deinem Vorschlag ist, dass Du das Problem der unzureichenden bzw. lückenhaften Kennzeichnung der Tauglickeit von Wegen mit Fahrradtypen lösen willst, deren Einteilung genauso subjektiv ist, wie smoothness oder tracktype. Dadurch wird mMn die Situation nicht klarer. Eben doch. Natürlich bleibt die Subjektivität, aber mit der Klassenbildung trage ich das (subjektive) Urteil, ob ein Weg benutzbar ist, oder nicht, an die konkreten Nutzer heran. Das habe ich auch schon in anderen mails geschrieben. Das ist ein feiner, wesentlicher Unterschied zu smoothness, wo jeder kommen kann, und einem Wegnutzer (Rennradler, Trekker, MTBler) vorsetzen kann, wofür er den Weg als geeignet erachtet. Und das _ohne_ dass derjenige, der die Daten nutzt, eine Vorstellung davon hat, wie derjenige der smoothness=* erfasst hat, den Weg benutzt hat. Wozu erfassen wir (hauptsächlich) den Oberflächenzustand - um dem Datennutzer eine Entscheidungshilfe zu seiner geplanten Nutzung dieses Weges zu geben. /Wer/, wenn nicht ähnliche Nutzer, kann dem Datennutzer am besten/ehesten mitteilen, ob der Weg für ihn brauchbar ist? smoothness=* ist einfach nicht das gleiche. Der Ansatz der Erfassung für einen Fahrradtyp kommuniziert einem Nutzer gleichen Fahrradtyps wesentlich mehr, als typ-unspezifische tags, weil er i.d.R. davon ausgehen kann/darf, dass sich die gleiche Zielgruppe mit der Erfassung solcher tags beschäftigt. Zieht dazu bitte einfach die Parallele zu den Mountainbikern - die handhaben das schon so. Ein Fußgänger wird kaum für einen MTB-Profi Daten erfassen, weil er _nicht weiß_ inwiefern die Strecke für MTB geeignet ist. Also gibt es den mtb: namespace. Warum dort aufhören und alle anderen Fahrradtypen in einen Topf werfen? Ich finde bei der Erfassung von smoothness ist es fast weniger die Subjektivität, die eine Rolle spielt, als vielmehr noch, dass der Anwender nicht darauf vertrauen kann, dass die Einschätzung des Datenerfassers /für sein Anwendungsgebiet/ eine richtige ist. Das ist, mit der Gewißheit, dass der Erfassende zur gleichen Radlerkategorie wie man selbst gehört, immer noch nicht gegeben, aber die Einschätzung wird _wesentlich_ qualifiziert sein, als eine fachfremde. Es geht mir nicht darum, smoothness zu ersetzen oder zu verbessern - das schrieb ich von Anfang an. Mein Ansatz hat mit smoothness=* eigentlich überhaupt nichts zu tun. Dass einige dass hier so zu einem Brei vermengen, mag daran liegen, dass viele aus dem Oberflächenzustand direkt die Nutzbarkeit für ihren Radtyp ableiten. Das ist nicht falsch, aber mit meinem Vorschlag geht es mir ganz konkret darum, die Verwendbarkeit von Daten dadurch zu erhöhen, dass die Fachleute/Mapper eines Radtyps auf genau die Datennutzer desselben Radtyps treffen. Wenn es um Verwendbarkeit geht, und Verwendbarkeit eine subjektive Sache ist, dann können wir Präzision nur auf die Art und Weise erreichen, dass die Erfasser von Daten der gleichen/ähnlichen Gruppe entspringen, wie die Nutzer der Daten. Dazu müssen die Tags aber kommunizieren, /wer/ erfasst hat, bzw. /wer/ adressiert wird. Das tut smoothness nicht. Es gibt auch nicht die Programmiersprache, sondern viele anwendungsspezifische (DSL) - nicht, weil man keine generelle Sprache hat, die DSL überflüssig machen können, sondern weil DSL dem Problem kurz, bündig und adequat begegnen können. Von der Anwendersicht lässt sich generalisieren, wenn die Kriterien messbar sind und objektiviert werden können, smoothness ist hier bereits ein Grenzfall. Smoothness versucht die Quadratur des Kreises, indem /jeder/ kommen kann und eine passende Verwendbarkeit für /spezifische/ Anwender erfasst. Das funktioniert einfach nicht. Der Kommunikationskanal ist hier gebrochen - smoothness=* ist, kommunikationstechnisch betrachtet ein Broadcast ohne Absenderadresse. Bei der ganzen konservativen Denke, frage ich mich, wie es die MTBler geschafft haben, eine ganze Reihe von Änderungen beizusteuern. Vermutlich haben die ohne viel fuzz gleich Tatsachen geschaffen :) Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 20:55, schrieb Peter Wendorff: Am 02.03.2011 16:32, schrieb Christian Müller: Am 02.03.2011 08:39, schrieb Heiko Jacobs: Am 02.03.2011 03:27, schrieb Ulf Lamping: [1] Natürlich könnte man eine Art wissenschafliche Untersuchung starten (Welligkeit, Löcher, Rillen, ..., jeweils mit Höhe, Abstand, Form, Größe, Tiefe). Will sich aber wohl keiner antun. ... weil Ergebnis nur bis zum nächsten Regen gültig smoothness gilt immerhin bis zur nächsten Holzabfuhr ;-) ... womit wir schon beim Thema wären, dass eins daneben bei tracktype und smoothness im Rauschen der jahreszeitlichen Änderungen in Wald und Flur untergehen, wodurch sich jedes exaktere tagging eh obsoletiert ... Da steckt sehr viel Wahrheit drin. Da OSM aber das aktuelle Weltbild wiederspiegelt, ist das dann eben auch dynamisch - es gilt den aktuellen Zustand zu erfassen und der kann sich natürlich ändern. Die OSM-Daten haben kein absolutes Ziel, sie werden sich immer wandeln (müssen), so wie die Karten von traditionellen Herstellern auch. !? Ja, aber doch nicht im jahreszeitlichen Wandel! Wenn jemand große Ereignisse, langfristige Baustellen etc. einträgt und die hinterher wieder entfernt - okay. Aber hiermit forderst du explizit, dass das komplette Wegenetz auf Verdacht mindestens viermal im Jahr gesichtet werden muss - das halte ich für Blödsinn. Wenn die Holzabfuhr (das war das Beispiel auf das ich geantwortet hatte) einmal durch ist und das Wegenetz zerstört UND hinterher nichts daran gemacht wird, ist kaum anzunehmen, dass es durch den jahreszeitlichen Wechsel wieder besser wird. Für Wege, die regelmäßig überflutet werden, gibt es andere Sachen, wie flood_prone=* - das wäre auch für andere reale Änderungen, die an Jahreszeiten gebunden sind, denkbar. Davon sprach ich aber nicht, sondern von längerfristigen Änderungen, z.B. ein Weg ist drei Jahre durch Rennradler befahrbar, weitere 4 durch Trekking, irgendwann ist die Qualität hin und die bumpiness so groß, dass sich die Mehrheit der Trekking-Radler das nicht mehr antut. Ergo wieder umtaggen zu MTB. Alles unter der Vorraussetzung, dass in der Zeit nichts am Weg gemacht wurde. Diese Änderungen gilt es zu erfassen - ergo ist nichts in OSM wirklich final (bis vielleicht auf die place-tags).. Selbst die coast_line ändert sich, aber das trägt nicht mehr zum Thema bei.. Ein anderer Aspekt ist - jemand der bei feuchtem Wetter Wege erfasst wird tendentiell den Weg eher abwerten, obwohl er ihn bei Trockenheit vielleicht besser bewertet hätte. Da haben wir auch schon wieder (jahreszeitlich gebundene) Subjektivität. Deshalb ist in einem solchen Fall surface=* objektiver (Mud/Dirt), als smoothness=* (das sich evtl. stark nach der Bodenfeuchte richtet) oder tracktype=* - das schrieb auch Heiko schon. Jahreszeitliche Änderungen lassen sich schwerlich aufnehmen, sicher, da sind andere Sachen an/in OSM wichtiger. Eine Karte in Abhängigkeit des aktuellen Wetters zu rendern und dann bei Regen tracktype und smoothness automatisch abzuwerten wäre aber aus momentaner Sicher nur ein Ressourcenproblem. Natürlich könnte der Radler das Wetter auch selbst in Betracht ziehen, so wie der Klimaforscher seine Berechnungen auch von Hand rechnen lassen könnte :-) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 21:39, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 21:26 schrieb Christian Müllercmu...@gmx.de: Ein Fußgänger wird kaum für einen MTB-Profi Daten erfassen, weil er _nicht weiß_ inwiefern die Strecke für MTB geeignet ist. Also gibt es den mtb: namespace. Warum dort aufhören und alle anderen Fahrradtypen in einen Topf werfen? mtb, wenn auch aus ähnlichen Gründen wie Dein Vorschlag schon des öfteren kritisiert, macht wenigstens nicht den Fehler, sowas wie mtb=yes/no einzuführen. Der mtb-namespace ist klar getrennt vom rechtlichen Aspekt des Verbots für bestimmte Fahrzeugtypen und lädt nicht zu Verwechslungen ein. So wie das Fehlen des access: präfix an allen sonstigen, für rechtliche Aspekte verwendeten Tags zum Fehler begehen einlädt, meinst Du? Haare spalten kann ich auch.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 21:39, schrieb M∡rtin Koppenhoefer: Der mtb-namespace ist klar getrennt vom rechtlichen Aspekt des Verbots für bestimmte Fahrzeugtypen und lädt nicht zu Verwechslungen ein. Vielleicht sollte man generell von bicycle=yes Abstand nehmen, wenn man bicycle=permitted meint.. Wieder so ein Stückchen OSM, wo ohne Wiki gar nichts geht? Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 22:15, schrieb Andreas Perstinger: Gilt das nur für Nachtfahrten, oder müssen in D Rennräder auch am Tag ein Licht mitführen? In AT braucht man das eben nicht AFAIK (ich bin zumindest noch nie deswegen angehalten worden). Laut http://www.polizei.bremen.de/sixcms/detail.php?gsid=bremen09.c.3499.de schon. (siehe ganz unten auf der Seite) Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 22:31, schrieb Simon Poole: Am 02.03.2011 18:27, schrieb Christian Müller: Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse ist. Und ein Engländer kennt doch sehr wohl auch den Unterschied zwischen Rennrad und Mountainbike. Wenn ihm die Kategorie Trekking nicht bewußt ist, ist das nur ein Zeichen, das hier das marketing versagt hat, oder andere Wege gegangen ist.. Noch den obligaten Wikipedia Link zum Thema: http://en.wikipedia.org/wiki/Mixed_Terrain_Cycle-Touring Genial, danke. Die Types of dort sind ja schonmal ein prima Wertebereich, da bräuchten wir nur noch nen passenden Schlüssel - die smoothness-Leute werden ihren ja sicher nicht hergeben :-) .. Vielleicht kann man die smoothness-Beschreibung wenigstens in den Wertebeschreibungen um die Typen ergänzen, gerade für die engl. smoothness-Version bestimmt nicht uninteressant. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Moin, Am 02.03.2011 23:35, schrieb Simon Poole: Ich wollte ja eigentlich noch was dazu schreiben, hab es aber dann sein gelassen, jetzt aber trotzdem noch: Eins der Probleme an deinem Vorschlag ist das du die Art des Fahrradfahrens krampfhaft versuchst am Fahrzeugtyp festzumachen (was bei Fahrrädern nicht wirklich gut geht). Schlussendlich willst du aber ja eigentlich wissen: kann ich da ein Zeitfahren machen, oder kann ich die Strecke über wechselnde Unterlage ohne grosse technische Hindernisse (im MTB Sinne) gemütlich abfahren usw. Da steige ich nicht dahinter - das geht doch hervorragend. Die Fahrradtypen werden ja auch genau terrainspezifisch vermarktet: mtb - rough ride trekking - long ride road_bike - fast ride Wer denkt bitte beim Zeitfahren an ein Trekking- oder MTB-Rad? Anhand der Implikationsvorschläge war auch zu erkennen, inwiefern ich mir über Überschneidungen Gedanken gemacht habe. Natürlich kann ich mit einem MTB auch auf Straßen und Tracks fahren - dafür kauft man sich i.d.R. aber kein MTB. Wir benutzen diese etablierten Marketingbegriffe doch nur, weil i.A. jeder weiß, was unter einem mtb/trekking/race bike zu verstehen ist und eben gerade deren Hauptanwendungsgebiete kennt und einordnen kann. Insofern gebe ich den Esel zurück und frage, warum Du das krampfhaft auseinanderdividieren willst? =) So was kann man vermutlich nicht wirklich vernünftig an einzeln Wegen taggen, aber bei Radrouten wäre das sicher möglich (und wird ja mindestens für MTB ja auch gemacht) , vielleicht ist da ein Ansatz um dein Anliegen weiter zu bringen. Das wollte ich gerade nicht - siehe erste mail. Das wäre auch völlig fatal: Def. Radroute - Menge von Wegabschnitten, deren Beschaffenheit und Oberfläche völlig unterschiedlich sein kann. Ich kann mit einem tagging der Route dann überhaupt keine Rückschlüsse auf die Befahrbarkeit ihrer Segmente ziehen. Klar kann ich sagen, eine Route wurde speziell für Trekking-Räder zusammengestellt. Das hat dann aber rein empfehlenden Charakter und lässt sich z.B. bei Routing-Software auch schwerlich verwenden. Siehe erste mail: mir geht es um den Weg, nicht um Routen, und das aus gutem Grund. Ausnahme evtl. knotenbasiertes, niederländisches cycle-network.. Was man noch machen könnte, ist, Relationen zu benutzen um die Nutzung/Verwendbarkeit von Teilsegmenten darüber zu taggen, also z.B. eine Relation trekking-geeignet und da dann alle Segmente rein. Dann könnte ich aber auch die Zugangsbeschränkungen komplett über Relationen lösen (Relation bicycle=yes und dort entsprechend alle Ways rein, die jetzt direkt dieses Tag tragen). Problem wäre dann auch, dass solche Relationen sich einer bounding-box Abfrage widersetzen. Angenommen ich will dann z.B. die treking-geeignet-Liste für Leipzig, ziehe ich mir eine Riesenrelation, in der ein Haufen Wege sind, die mich nicht interessieren und aufgrund derer ich dann vorfiltern müsste. Das kann es dann auch nicht sein - Parent-Childrelationen zu nutzen würde _hier_ die Komplexität noch weiter aufblähen. M.E. gehört die Eignung -subjektiv oder nicht- daher an den Way und nicht in eine Relation. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags / Tag-Voting für subjektive Kriterien
Am 02.03.2011 23:55, schrieb Ulf Lamping: Am 02.03.2011 17:37, schrieb Christian Müller: Am 02.03.2011 16:41, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 16:29 schrieb Christian Müllercmu...@gmx.de: 1) es geht nicht um 10 tags, sondern um 3 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen es geht um 3 zusätzliche tags allein für Radfahrer. Danach kommen die Rollstuhlfahrer mit 3 Typen, die Inlineskater mit 2 Typen, 4 Typen Kinderwägen, Tretroller, Einkaufswägen, Stelzen, verschiedene Arten von Schuhen, etc. Der Ansatz skaliert einfach ziemlich schlecht. Evtl., der bisherige aber auch: foot motorcar motorcycle motor_vehicle bicycle wheelchair psv hgv Beim diesem Ansatz geht es um die rechtliche Einsortierung, diese ist (größtenteils) jeweils unabhängig von den anderen Verkehrsteilnehmern. Wenn es irgendwo ein Verbot für Motorräder gibt, hat das keine Auswirkungen für die anderen. Es muß daher für jede Verkehrsart ein unabhängiger Eintrag vorhanden sein, weil man sonst die Kombinatorik nicht hinbekommt. Ja, ist mir doch alles klar - dennoch bläht allein diese Zahl der Attribute das tagging eines Weges schon auf, dass das Argument wir können hier nicht noch mehr gebrauchen einfach nicht zieht. Zumal alle o.g. zusätzlich alles andere als Neuling-freundlich sind, aber ich wiederhole mich: - kein access: präfix - hgv / psv nicht ausgeschrieben (entgegen der OSM Konvention) - Verwendung nicht selbstdokumentierend (an unterschiedlichen Stellen im Wiki findet man evtl. sogar unterschiedliche Erklärungen..) Bei smoothness (oder ähnlichem) ist das aus meiner Sicht anders. Hier haben wir (in erster Näherung) einen linearen Übergang von gut nach schlecht, die bei einem bestimmten Wert Auswirkungen für alle Teilnehmer hat. Ja, auch das habe ich nie in Frage gestellt. Ich will auch nicht in Konkurrenz zu smoothness treten, hm, sagte ich das schon? Wäre es da nicht vielleicht besser, das (bislang etwas brachliegende) Thema smoothness zu forcieren und zu schauen wie weit wir damit kommen? Erachte ich als sinnlos - all die Jünger, die jetzt nach langer Diskussion mit ihrem gefundenen Kompromiss damit glücklich sind, werde ich nicht überzeugen können. smoothness=* ist eine Religion. Das merke ich schon an den ganzen Antworten und dem ständigen flachgebügele meines Vorschlags mit dieser streitbaren Definition. Wenn ich dich recht verstehe, willst du wissen ob du bzw. ob du zur Not mit einem Trekkingrad über einen Weg kommst. Das sollte mit smoothness doch machbar sein ... Nein das ist es nicht, zumindest nicht ganz. Was ich will, habe ich in epischer Breite in der ersten Mail zum Thema erklärt und, vielleicht wichtiger, hier: http://www.mail-archive.com/talk-de@openstreetmap.org/msg82510.html Es geht mir darum, tags zu schaffen, die END-to-END kommunizieren, ob ein Weg für meine Nutzungsart etwas taugt, oder nicht. Wenn schon subjektiv, dann gleich fachspezifisch. Aber bitte lies die mail, ich habe mir Mühe gegeben, dass so detailiert darzulegen, wie möglich. Natürlich haben all die Leute recht, dass auch ein Trekking-Radler nicht die gleichen Präferenzen hat, wie der nächste. Aber das Urteil dürfe näher an dem dran sein, was ich haben will, als wenn es von einem Rennradler (da würde ich nie im Leben lang fahren und kann mir auch nicht vorstellen, dass andere Radler das tun) oder MTBler kommt - die wissen eben in ihrem Feld Bescheid. Wenn man sich die Menge der Trekker z.B. mal vor Augen hält, sieht das vielleicht so aus: Hardcore-Trekker (fast MTBler) .. Normalo-Trekker .. Sonnenschein-Trekker (fährt nur asphaltierte Wege) Die Normalo-Trekker, die Waldwege mit in Betracht ziehen, wenn sie nicht zu stark verwurzelt sind, bilden am ehesten (da mittig) das ab, was dann zu taggen wäre. Natürlich kann ich nicht ausschließen, dass der Fast-MTB-Typ kommt und mir meinem Verständnis der Kategorie entgegentritt. Das Problem habe ich aber mit allen Tags, wo nur ein mü Interpretationsspielraum für den Wert besteht. Mir ist noch ein anderer Gedanke gekommen, mit dem ich für die geplanten Kategoriebegriffe Quasi-Objektivität (im Sinne einer Mittelwertsbildung) aus der Subjektivität der Taggenden extrahieren könnte. Das wird umso besser, je mehr Leute ihren Senf zur Klassifikation eines Ways hinzugeben. Ich nenne das Verfahren mal tag-voting. Idee ist folgende (bitte haltet euch nicht wieder an den konkreten Namen auf, sondern am Konzept, über die konkreten Bezeichnungen lässt sich am Ende reden): trekking:thumbs_up erfasst alle yes-votes der Trekker (=Leute, die sich kompetent fühlen zum Thema trekking-Befahrbarkeit eines Ways eine Aussage zu treffen) trekking:thumbs_down erfasst alle no-votes dieser Trekker Angenommen /ich/ befinde einen Weg als
Re: [Talk-de] Status Fahrradwege-Tags
Am 03.03.2011 00:31, schrieb Heiko Jacobs: Am 02.03.2011 18:13, schrieb Christian Müller: Und was macht man z.B. mit Holz? Ich würde schon sagen, dass manche hölzerne Wege als befestigt gelten können (Hausbrücken z.B.), andere, wo nur ein paar logs verstreut im Sumpf liegen, eher nicht. surface=* ist auch nicht perfekt, aber es ist _wesentlich_ besser zu handhaben und brauchbarer, auch was die unmittelbare Lesbarkeit des tags betrifft, als tracktype/smoothness.. surface=asphalt ohne smoothness hilft Dir aber auch nix. Ich habe auch schon surface=asphalt in smoothness=intermediate oder in wenigen Fällen m.E.n. gar in bad eingestuft. Ja, kenne ich, solche Fälle gibt es hier in der Gegend auch en masse. Zwischen smoothness=intermediate smoothness=bad smoothness=horrible mag ich aber nicht entscheiden. Sicher kann ich für den gemeinen Trekking-Freund eine passende Klassifizierung finden, dann lyncht mich aber der Inliner, der sich auf meine smoothness=good Klassifikation verlassen hat (die inkompetent war, da ich eben nicht skate). smoothness ist für all seine Anwender/Nutzer nicht nur schwammig, sondern auch zu allgemein - meine Meinung :) Eine grobe Peilung kann es liefern, aber mir ging es in diesem Thread NIE, auch wenn ich mich wiederhole, um die Sinnhaftigkeit oder Abschaffung dieses einen Tags. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Status Fahrradwege-Tags
Hallo, kurz zu mir selbst. Ich lese ab und an die Diskussionen auf dieser Liste mit und versuche gute Vorschläge bei meiner Arbeit an OSM umzusetzen. Ich tagge seit 2008 im Südraum Leipzig und lege mehr Wert auf Qualität (so wie die Masse, schätze ich), als schnell die DB zu stopfen. Über das Tagging zu Radrouten und -wegen wurde auf dieser Liste schon viel diskutiert. Ich will daher kurz mein Anliegen einordnen. Es geht mir um das Taggen von Fahrradwegen (nicht Radroutenrelationen o.ä.). Ich habe mir oft gedacht, dass das bisherige tagging der Radwege nicht nur schlecht, sondern für vielerlei Zwecke auch völlig unzureichend ist - wobei das nicht heißt, dass ich es aus Mangel an besseren Ideen nicht selbst verwendet habe. Also es geht um Radwege und ihre Nutzbarkeit für unterschiedliche Arten von Radlern. Momentan gibt es genau zwei etablierte Tags, die einen mit _Radwegen_ arbeitenden Radfahrer interessieren und weniger etablierte: * surface= unpaved| paved| etc.. * bicycle= yes| no| designated| official| etc.. - mtb: (mountainbike namespace, healthy and alive) - smoothness (hat sich nie so richtig durchgesetzt, weil Einschätzung größtenteils subjektiv) Lasst mich weiterhin festhalten, wofür genau die tags momentan verwendet werden: bicycle=* 1) im Wiki: klar als Zugangsbeschränkung (beschilderter Radweg, offizielle Nutzungsart, usw.) 2) in-the-wild: jeder Weg, der als für Radfahrer geeignet erscheint bekommt bicycle=yes verpasst surface=* ) beschreibt objektiv die Oberflächenbeschaffenheit ) nicht aber den Zustand!! smoothness=* ) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort fahren kann, weil a) die subjektive Ansicht des Taggenden im Wert steckt und b) ich die Entscheidungsbasis des Taggenden nicht kenne (ein Inliner wird strenger sein, als z.B. ein Radfahrer, etc.) Was will ich also ändern, was sind meine Ideen? Ziele: a) sowohl Mensch als auch Maschine (routing services) sollen in der Lage sein, eine für Radfahrer geeignete Route aus den Daten abzuleiten b) der Taggende soll objektiv entscheiden und nach Möglichkeit mit wenigen Werten arbeiten können, um a) zu erreichen (praktischer) Ansatz: (Idee während des Radelns :) ) 1) es gibt im wesentlichen 3 Kategorien von Radfahrern, welche i.d.R. ihre Präferenzen nach den unterschiedlichen Wegoberflächen/-beschaffenheiten richten (wichtig!) 2) Monotonie: MTB Trekking RaceBike ein MTB kann auch auf ausgewiesenen trekking und race Strecken fahren, umgekehrt geht dies i.d.R. nicht, bzw. ist nicht erwünscht (ich kenne niemanden, der sein Rennrad auf unpassenden trails schrottet) konkreter Tagging-Vorschlag: *) bicycle:mtb=(alle mgl. Zugangsbeschränkungen) *) bicycle:trek=(alle mgl. Zugangsbeschränkungen) *) bicycle:race=(alle mgl. Zugangsbeschränkungen) *) bicycle=(alle mgl. Zugangsbeschränkungen) Implikationen: _) bicycle:race impliziert, sofern für die anderen Tags nichts angegeben, bicycle:trek bicycle:mtb bicycle mit demselben Wert _) bicycle:trek impliziert, sofern für die anderen Tags nichts angegeben, bicycle:mtb bicycle mit demselben Wert _) bicycle:mtb impliziert keine weiteren bicycle Tags _) bicycle impliziert, sofern für die anderen Tags nichts angegeben, bicycle:trek bicycle:mtb mit demselben Wert Wobei letzteres die Rückwärtskompatibilität zu bestehendem Tagging gewährleistet. Beispiele *) ich habe einen sandigen Fußweg, der auch von MTBlern benutzt wird: bicycle=no bicycle:mtb=yes foot=yes highway=path surface=sand *) ich habe einen fein geschotterten Waldweg: bicycle=yes bicycle:trek=yes (:mtb wird impliziert, :trek eigentlich auch, ist aber für Menschen da, um zu sehen, dass man sich hier nach dem erweiterten Schema Gedanken gemacht hat - man könnte auch nur :trek verwenden, dass bricht dann aber die Kompatibilität) foot=yes highway=track surface=fine_gravel *) eine asphaltierte Straße, die für Rennräder geeignet ist bicycle=yes bicycle:race=yes (:mtb, :trek werden impliziert, können aber angegeben werden, z.B. auch wenn es für unterschiedliche Radtypen unterschiedliche Zugangsbeschränkungen gibt) foot=yes highway=secondary surface=asphalt *) eine (alte) asphaltierte Straße, die nicht für Rennräder geeignet ist bicycle=yes bicycle:race=no foot=yes highway=secondary surface=asphalt *) eine (alte) asphaltierte Straße, die so kaputt ist, dass man sie selbst mit Trekking-Rädern meiden sollte/nicht mehr befahren kann bicycle=yes bicycle:trek=no bicycle:race=no foot=yes highway=unclassified surface=asphalt *) eine (alte) asphaltierte Straße (Alternative, semantisch äquivalent) bicycle=no bicycle:mtb=yes foot=yes highway=secondary surface=asphalt Was sind die Vorteile einer Adaption dieses Schemas, dieser Erweiterung? - Zugangsaussagen pro
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 03:27, schrieb Ulf Lamping: Am 02.03.2011 02:13, schrieb Christian Müller: smoothness=* ) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort fahren kann, weil a) die subjektive Ansicht des Taggenden im Wert steckt und b) ich die Entscheidungsbasis des Taggenden nicht kenne (ein Inliner wird strenger sein, als z.B. ein Radfahrer, etc.) Auch wenn diese Aussagen immer wieder kolpotiert werden, stimmen sie nicht. Die Werte mit den entsprechenden Bedeutungen sind dokumentiert: http://wiki.openstreetmap.org/wiki/Approved_features/Smoothness#Tag.2C_Values_and_Usage OK, ich hatte das sogar mal gelesen. Damals war es allerdings noch nicht approved. Dennoch, good/bad/intermediate sind Begriffe, die nicht gerade intuitiv auf die Verwendbarkeit hindeuten, selbst wenn Sie definiert sein sollten - da smoothness in seiner Def.variante auch, wie Du schon feststellst, nicht gerade gängig ist, wohl auch aufgrund seiner undefinierten Historie, möchte ich nochmal auf das was Du schreibst eingehen, denn wenn man die access-Methodik auf die Fahrradtypen anwendet, ergeben sich schon feiner (und auch objektiver) granulierbare Taggings. Wenn du jetzt anfängst, zu taggen ob etwas für einen Trekkingradfahrer geeignet ist: yes vs. no, stößt du doch an exakt die gleichen Probleme. Was für den einen durchaus noch geht ist für den anderen geht garnicht - genauso viel oder wenig Ansichtssache. Ja und nein. 1) bicycle=yes wird momentan auf Wege gesetzt, die nur von MTB zu befahren sind - wenn smoothness vergessen/nicht ausgewertet/nicht nach Wiki-Def verwendet wird, bin ich als Trekker auf einem Pfad gelandet, der definitiv nichts für mich ist 2) gerade wenn ich den access-Wertebereich auf bicycle:trek=* anwenden kann, lässt sich speziell für diese Radkategorie sehr schön unterscheiden (Weg von amtlicher/offizieller Seite für Trekking-Räder vorgeschlagen, oder nur yes, womit ersichtlich wäre: ja, es geht) 3) natürlich kann ich nicht ausschließen, dass bicycle:trek=yes einen gewissen Spielraum hat - der dürfte aber (praktisch!) einen wesentlich kleineren Spielraum haben, als nur bicycle zu verwenden, oder sich auf smoothness zu verlassen.. und wenn die Kategorie trekbike dann vielen Leuten später zu breit ist, kann ich diese (die schon eine spezielle ist) immer noch feiner granulieren, indem ich z.B. (wie bei track, weil Du es ansprachst), weitere Werte einführe 4) die richtige Verwendung von smoothness ergibt sich ohne Wiki nicht - mein Vorschlag einfach die 3 wichtigen Fahrradkategorien auf vorgeschlagene Weise zu benutzen ist selbstdokumentierend Dann können wir aber auch gleich smoothness nehmen - das halte ich sogar für die praktikablere Alternative, sowohl für den Eintragenden als auch für den Verwender. Durch den Verlauf von gut nach schlecht sind die Grenzfälle sogar wohl wesentlich besser zu taggen und auszuwerten. Das sehe ich natürlich nicht so, würde ich dem zustimmen ergäbe meine mail auch wenig Sinn :) Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Open-Data-Feuerwehr
Am 26.12.2010 13:56, schrieb Heiko Jacobs: Am 23.12.2010 22:38, schrieb Michael Kugelmann: Am 23.12.2010 21:29, schrieb Norbert Kück: im Open Data Blog von Zeit-Online gibts einen Beitrag über die Nutzung von OSM für die Amsterdamer Feuerwehr: http://blog.zeit.de/open-data/2010/12/23/open-data-feuerwehr/ eigentlich krass, dass die Amsterdamer Feuerwehr quasi eine do-okratie ist... Und das wo sonst bei Feuerwehren alles genormt und fünf mal geprüft wird. Stelle mir das gerade bildlich vor ... - OSM-Mapper sieht was brennen - ruft Feuerwehr an - denkt sich Ach, ich setze die Straße mal auf disused=yes bis sie weider frei ist - Feuerwehr lädt Daten für aktuelle Route - Navi lotst weiträumig um den Brandort diese Adresse ist nicht erreichbar ;-) Korrekterweise würde er allerdings per access= steuern, dass FW-Fahrzeuge Zufahrt haben ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am 14.12.2010 13:00, schrieb talk-de-requ...@openstreetmap.org: Message: 1 Date: Tue, 14 Dec 2010 12:10:39 +0100 From: Wolfgang wolfg...@ivkasogis.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung Message-ID: 201012141210.39739.wolfg...@ivkasogis.de Content-Type: Text/Plain; charset=utf-8 ..source=gps oder so ?hnlich hei?en. Dann k?nnte das survey f?r wirkliches survey benutzt werden und aussagen, dass die Koordinaten deutlich genauer als ±10 cm ermittelt sind. Das stimmt so nicht. source=survey heißt in OSM lediglich, dass die Daten durch Beobachtung vor Ort erhoben wurden. Über die Professionalität der Beobachtung sagt dieses Tag nichts aus. Vermessung ist nur eine Übersetzung des Wortes [1], in OSM hat man sich laut Wiki für eine weitfassendere Bedeutung entschieden [2]. Diese Bedeutung nachträglich zu spezifizieren macht keinen Sinn, da festzustellen ist, dass dieses tag bereits millionen-mal mit bisheriger Spezifik verwendet wird. Für Vermessungsgenauigkeit wird deshalb ein neues tag vergeben werden müssen. Gruß, Christian [1] http://de.wiktionary.org/wiki/survey [2] http://wiki.openstreetmap.org/wiki/Key:source ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am 14.12.2010 21:24, schrieb talk-de-requ...@openstreetmap.org: Message: 1 Date: Tue, 14 Dec 2010 18:04:08 +0100 From: Bernd Wurst be...@bwurst.org To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung Message-ID: 201012141804.11541.be...@bwurst.org Content-Type: text/plain; charset=iso-8859-1 Dieses Tag sagt als nur aus, dass da irgendwie irgendein GPS-Signal mit im Spiel war. Der Nutzen dieser Aussage war mir nie klar und wird mir wohl auch nicht so schnell klar werden. Ich ignoriere source und l?sche es wenn ich Objekte wesentlich ver?ndere. Hi Bernd, hallo Liste, bitte nimm davon Abstand, dass einfach zu löschen. source=survey liefert die wertvolle Information, dass die eingetragenen Daten vor Ort entweder gesammelt oder überprüft wurden. Ein Beispiel: * jemand hat ein amtliches Straßenverzeichnis, in OSM ist fast jede Straße der Stadt erfasst * zwei/drei Straßen sind nicht benannt * aufgrund der Lage unbenannter Straßen lässt sich schließen, dass a) eine der beiden Osterfelder Weg genannt wird (weil sie Rtg. Osterfeld führt) b) die andere Am Winkel heißt (weil sie übrig bleibt und es keine weiteren erkennbaren residentials gibt) Es ist fast unmöglich, aufgrund der Indizien, dass der Mapper sich irrt, er nicht hätte logisch schließen dürfen und die Straßen umgekehrt hätte benennen sollen. Dennoch hat er die Information nicht anhand eines Straßenschildes überprüft. Deshalb setzt er für seine Informationen auch nicht source=survey. Umgekehrt gehe ich davon aus, dass wenn source=survey gesetzt ist, die Information vor Ort zumindest überprüft wurde. Angenommen mir liegen anderslautende Informationen vor (Sekundärquelle in schriftlicher Form, die ich rechtlich gesehen nutzen darf), dann bedeutet das für mich, dass _bevor_ ich diese Information auf den Stand ändere, den ich für richtig erachte, _vor Ort_ nachzuprüfen ist, ob nicht doch die bestehenden tags richtig sind. Es geht bei source=survey nicht notwendigerweise um Lage-Informationen der OSM-Primitiven, sondern auch um ihre Auszeichnungen / tags. Weiterhin gibt es manche Mapper die Mühe, gezielt für jedes Tag anzugeben, woher eine Information stammt, z.B. source:ref=survey source:name=knowledge source=yahoo Prinzipiell wäre eigentlich auch noch eine Datumsangabe erforderlich, so dass Nutzer der Daten entscheiden können, wie aktuell die Information ist. Grob kann jemand anhand des Datums des Changesets abschätzen, dass die Information nicht jünger sein kann als der Upload und mit großer Wahrscheinlichkeit ein/zwei Wochen vor dem Upload erhoben wurde. Das geht natürlich für Eintragungen, die von Luftbildern abgemalt wurden schief. Deshalb ist es wünschenswert, dass source=bing oder source=yahoo gesetzt werden, wenn Luftbilder benutzt worden sind und keine andere Methode benutzt wurde. Wenn ich die Straße real begutachtet habe und dann das Luftbild zur Positionsbestimmung nutze, ist source=survey natürlich sinnvoller, da ich dann weiß, dass das Bild noch die Realität wiedergibt. Oft gibt es z.B. Verzeichnisse, die Mapper nutzen (sofern sie dürfen), um zu bereits erfassten Primitiven in OSM Informationen nachzutragen, etwa das ref-tag, oder shelter=yes bei Bushaltestellen. Mit source:shelter=survey sage ich: Ich war dort, ich habe es überprüft. Fehlt diese Angabe, kann ich keine Aussage über die Quelle der Information treffen - der Mapper kann Sekundärquellen, Luftbilder, Logik, Hören/Sagen oder Lokalwissen benutzt haben. Natürlich muss ich der source-Angabe vertrauen können, das gilt aber für Daten des gesamten Projekts, so dass wir i.d.R. glauben können, dass die source-Angabe nicht fehlerhafter ist, als die Objektangaben. Ich persönlich leite aus source=survey die Information ab, dass sich der Eintragende beim Erheben der Information die Mühe gemacht hat, sie aus einer Primärquelle zu ziehen - das, was sich OSM zu Beginn auf die Fahne geschrieben hat. Die Luftbilder (Sekundärmaterial!) sollten eigentlich nur beim Erfassen helfen, aber _nicht_ die Datengrundlage sein. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 53, Issue 36
Kleiner Typo es ist tatsächlich flood_prone=yes _nicht_ flood_prones=yes .. ist aber auch durch den Wiki-Link der gleichen mail ersichtlich. Gruß, cmuelle8 Am 09.12.2010 11:08, schrieb talk-de-requ...@openstreetmap.org: und Eisenbahnunterfuehrungen, die gerne mal unter Wasser stehen, mit highway=footway tunnel=yes flood_prones=yes floodplain_probability=1 surface=asphalt;water;ice ;-) cu, stw -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
