Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
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? Selbst wenn man die Gemarkung betrachtet, ist die Flächennutzung des Wohngebietes (Siedlung) i. d. R. nur ein Bruchteil innerhalb dieser administrativen Grenze. Und wenn man die durch Eingemeindung enstandene im Allgemeinen verstandene administrative Grenze (Gemeindegrenze) einer Siedlung betrachtet, dann liegen oft weitere Flächennutzungen ganz anderer Wohngebiete (ehemals eigenständiger Siedlungen) innerhalb dieser Grenze. Und selbst ohne Eingemeindung gibt es oft Wohnplätze (offizielle Bezeichnung!) in Alleinlage, die sich durch ihre Enwicklung zu Wohngebieten vergrößert haben. 'Natur'gemäß ist es hier nicht so komplex, da die Flächennutzung eines Wohngebietes ziemlich offensichtlich von Nicht-Siedlungsflächen (sic!) umgeben ist. Gruß Georg ___ 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. September 2011 18:23 schrieb Christian Müller cmu...@gmx.de: Am 10.09.2011 14:13, schrieb Martin Koppenhoefer: Wie bereits wiederholt geschrieben: das ist ein Fall für die [tagging]-Mailing-Liste. Da Deine User-Seite im Wiki auf Englisch ist, gehe ich davon aus, dass Du dort problemlos weiterdiskutieren könntest. Könnte ich, das macht aber keinen Sinn. Schließlich verwende ich landuse in Deutschland und wir haben in unserer gesamten Diskussion dazu sowohl dt. Sprache als auch dt. Recht verwendet. Wir behandeln längst ein strukturelles Problem, dem wir Tags zuordnen können und nicht bestimmte Tags, denen wir Struktur geben wollen. Zum einen hat unser Tagging sehr wenig mit dem deutschen Recht zu tun, und zum anderen ist Dein Anliegen, die englischen Wiki-Seiten zu ändern (bzw. hast Du das schon getan aufgrund einer Diskussion hier auf talk-de). M.E. sollten wir auf tagging diskutieren, wenn wir die allgemeinen Definitionen anpassen wollten. Gruß Martin ___ 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. September 2011 19:57 schrieb Christian Müller cmu...@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. Gruß Martin ___ 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. September 2011 15:12 schrieb Frederik Ramm frede...@remote.org: On 09/10/2011 02:46 PM, Martin Koppenhoefer wrote: 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. klar, oft ist das so. Das bestreitet niemand, aber es bedeutet nicht, dass es immer so ist. Daher ist das auch keine Grundregel. Settlements (im Sinne von Siedlungsgeografie) und Verwaltungsgrenzen sind 2 verschiedene Dinge. 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. dieses admin_centre zu setzen geht nur, wenn es sich wirklich um das admin_centre handelt. Das ist nicht immer der Fall. Ich wuerde zumindest anstreben, place-Polygone zu vermeiden. wie bereits erwähnt: von allen cities weltweit hat bereits ein Viertel ein Place-Polygon, das ist die OSM-Realität. Auf tagging wurde schon öfters über dieses Thema gesprochen und es ist dort AFAIR anerkannt, dass sowohl place- als auch admin-boundary-Polygone gleichzeitig Sinn machen. 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. wenn man jetzt schon erkennt, dass es nicht für alle places gehen kann (auch nicht für suburb und village, hamlet), wieso sollte man es dann anstreben? und damit praezise sagen will, was gemeint ist, dann muesste es fuer diese Area ja auch eine offizielle oder wenigstens dokumentierte Begrenzung geben, und dann kann man die vielleicht auch so taggen. -1, es muss keine offizielle oder dokumentierte Begrenzung geben, sondern die Mapper mappen das, was sie vor Ort erkennen. Offizielle Daten sind für das Mappen in OSM nicht erforderlich. Verwaltungs- und Staatsgrenzen bilden da eine der wenigen Ausnahmen. Landuse wuerde ich komplett unabhaengig von administrativen Dingen sehen. +1, genauso wie es auch von place unabhängig ist. 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. +1, jedoch wenn da keine Leute wohnen, keine Häuser stehen, es sich aber rechtlich um ein Wohngebiet handelt, wieso schreibst Du dann, dass diese Gebiete gleich wie ein bewohntes Wohngebiet getaggt werden sollen? Das ist m.E. schlecht mit unseren allgemeinen Prinzipien (Ground truth) vereinbar. Ich sehe bei Landuse den beschreibenden Charakter im Vordergrund - das hier sieht aus wie ein Wohngebiet. Der Informationsgehalt ist fuer mich dabei gleich, egal, ob ich 10 direkt aneinandergrenzende Flaechen habe oder eine grosse - +1 Landuse heisst das hier sieht aus wie ein Wohngebiet, und wenn das da drueben auch aussieht wie ein Wohngebiet, dann ist es vom Informationsgehalt her wurscht, ob ich da eins, zwei, oder dreizehn Landuses draus mache. für den landuse ja, wenn einen Wohngebiete (settlement) interessieren, dann spielt es eine Rolle. Damit wären wir wieder beisammen. Nur haben wir keine lückenlose Erfassung der Verwaltungsgrenze abzgl. aller Betriebs-, Verkehrs- und Abbauflächen. Das waere auch zu kompliziert fuer OSM. +1, folglich macht es Sinn, places als Flächen zu erfassen. Wir muessen da ein bisschen auf dem Boden bleiben. OSM ist kein akademisches Projekt, war es nie, kann es nie sein. darum geht es auch nicht. Logische Strukturen sind aber nicht komplexer oder schwieriger zu durchschauen als wild gewachsene, in sich unlogische, sondern im Gegenteil einfacher zu durchschauen und auch zu erweitern. Wenn bei bestimmten einzelnen Aspekten unseres Tagging-Schemas sich durch schlichtes Machen solche einzelnen unlogischen Stellen eingeschlichen haben und man es später bemerkt, dann ist das für mich ein Grund, durch Erweiterungen zu versuchen, wieder ein stimmiges Gesamtgerüst herzustellen. Die Ergänzung von place=neighbourhood zum Tagging-Kanon stört sich überhaupt nicht mit den bisher eingetragenen Daten und ist voll kompatibel. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Siedlungsflächen exportieren
Hallo Frederik und Christian! Danke für die Antworten! @Frederik: Das ist leider nicht ganz leicht. Zwar gibt es Flaechen, die in OSM mit landuse=residential als Wohnflaechen eingetragen sind, aber die sind mitnichten komplett. Schau Dir z.B. mal diese Karte von Muenchen an: http://www.openstreetmap.org/?lat=48.15772lon=11.53345zoom=16layers=M Nur im Nordosten des Bildes, im Stadtteil Ebenau, ist tatsaechlich eine Siedlungsflaeche eingetragen (etwas dunkleres Grau). Der ganze Rest (helleres Grau) hat keine Siedlungsflaeche. Das liegt daran, dass die Mapper wenig Motivation haben, eine Siedlungsflaeche in einer schon mit Strassen und Haeusern dicht befplasterten Gegend einzuzeichnen (man sieht ja, dass da Leute wohnen). Hm, das scheint in München tatsächlich nicht ganz unproblematisch zu sein. Jedoch trifft dies regional mit unterschiedlicher Intensität auf - so mein Eindruck. Beim Kontrollieren meiner ländlichen (!) Untersuchungsregionen (links und rechts des Rheins bei Karlsruhe/Mannheim) habe ich eine schöne Konsistenz den Einsatz des residential-Tags betreffend vorgefunden. Aber natürlich können auch dort Fehlerflecken auftauchen. Nichtsdestotrotz wäre es einen Versuch wert. Der Kartenausschnitt, den ich damit zeigen möchte, ist zudem so groß, dass es nicht auf vergessene Gewerbegebiete oder Neubaugebiete ankommt, sondern vielmehr um die Lage der Siedlung innerhalb ihrer Gemeindegrenze. Also, solange keine eklatanten Missstände auftreten, sind die kleinen Fehler zu vernachlässigen. Ein Landuse-Shapefile kannst Du Dir u.a. auf den folgenden Wegen selbst erzeugen: 1. osm2pgsql - geht auch fuer grosse Dateien, erfordert PostGIS (danach pgsql2shp), auf einem aktuellen Ubuntu/Debian-System kann man das aber alles als fertige Pakete installieren. 2. osm2shp aus dem OSM-Subversion-Repository (svn.openstreetmap.org/applications7utils/(export/osm2shp) - musst Du selbst compilieren und im C-Source angeben, was Du exportieren willst; sehr einfaches Programm, kann keine Multipolygone 3. osmjs, ein Teil von Osmium (wiki.openstreetmap.org/wiki/Osmium), das ist das beste, was es in Sachen Shape-Erzeugung derzeit gibt, kann Multipolyone und wird ueber ein Javascript-Schnipsel gesteuert; auch da musst Du allerdings selber compilieren und dann in Javascript definieren, was Du genau exportieren willst. Ach, ich sehe schon, ein echter Traum für jeden Nicht-Informatiker. :) Nicht beleidigt seien, aber zum großen Teil verstehe ich hier nur Bahnhof. Was mich wiederum zum nächsten Thema überleitet... [Alles zusammen hat mich mehrere Stunden meiner Arbeitszeit gekostet - was irgendwie nicht Sinn der Sache sein sollte/kann] Du kannst ja ueberlegen, was Du dazu beitragen kannst, dass es besser wird ;) Also, als jemand, der seine Kenntnisse tendenziell außerhalb von Programmiersprachen und Netzwerklogiken verorten würde (s.o.), sehe ich da wenig Möglichkeiten, konkret Abhilfe zu schaffen. :) Insgesamt ist mir ein wenig schleierhaft, wie es unzählige Möglichkeiten des Datenexports geben, aber (fast) keine davon benutzer- und einsteigefreundlich sein kann. Immerhin hat es die OSM-Gemeinde ja schon geschafft, die Dateneingabe soweit zu vereinfachen, dass man mittlerweile wirklich behaupten kann jeder kann mitmachen. Davon sind wir - meiner Meinung nach - beim Datenexport aber noch meilenweit entfernt (was Dienstleistern, wie der Geofabrik nicht unbedingt sauer aufstoßen sollte :) ). Aber gerade Menschen, die diese Daten wirklich nutzen möchten, aber kein Verständnis von den notwendigen Prozeduren haben (wie meine Wenigkeit), sehen sich hier schnell vor dem Scheitern. Somit bleibt für mich als außenstehenden Mapper offen, inwiefern OSM denn wirklich frei-zugängliche Daten haben soll. @Christian: .. 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 ;-) Eeeben. Gerade *weil* die Datenerfassung doch so (zeit-, nicht technisch) aufwendig ist, muss man das gleiche Spiel doch nicht noch einmal auf der anderen Seite der Datenebene durchkauen. :) Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Siedlungsflächen exportieren
Hallo Rhinhold. Auf der einen Seite gebe ich dir recht: Ja, OSM könnte an vielen Stellen (end-)benutzerfreundlicher werden, gerade auf Exportseite. Auf der anderen Seite ist aber genau das das Problem: Auch als Informatiker hilft mir ein benutzerfreundlicher Editor, denn das Bearbeiten der Daten ist immer weitgehend gleich oder zumindest vergleichbar. Die Nutzung der Daten ist dagegen aber leider so extrem facettenreich, dass es einfach nicht genug Interessenten gibt, um eine benutzerfreundliche Lösung in einer Facette so weit voranzubringen. Es gibt Nischen, in denen das ja schon passiert: - Die Geofabrik-Extrakte bedienen alle, die einfach nur Ausschnitte für bestimmte Länder brauchen - diverse Garmin-Karten bedienen zwar mit vorgegebener Auswahl, aber doch die Gruppe der Garmin-Nutzer - Der Export von Bildern als SVG oder Rastergrafik direkt auf der Webseite bedient Grafiker, Layouter oder sonstwen, der einfach mal eben ein Kartenbild braucht. - Nominatim etc. bedienen alle, die nur mal nachschlagen wollen, wo Hintertupfingen liegt. und so weiter. Die Zielgruppe für alle Siedlungsgebiete ist nunmal (aus deiner Sicht leider) ziemlich klein. Wenn da dann niemand dabei ist, der es umsetzen will und kann - oder sich jemanden sucht, und davon überzeugt, dass das sinnvoll investierte Zeit ist, dann ist das halt ein Problem, aber kein Grund, sich darüber zu beschweren (kein Vorwurf, die Beschwerde war zumindest nicht deutlich, aber man könnte sie in deine Mail reininterpretieren). Wenn Du nun argumentierst, du könntest da nicht helfen, dann stelle ich, ohne mich damit als Programmierer direkt anbieten zu können, doch einfach mal die Frage zurück, die nämlich keine Programmierkenntnisse voraussetzt: Wie sollte denn die Exportmöglichkeit (als Programm, Web-Schnittstelle oder was auch immer) aussehen, die du dir vorstellst? Denk dran, dass eben nicht genau dein Problem das wäre, was diese Komponente leisten müsste, sondern solche Anfragen aller Art, die auch von beliebigen anderen Usern aus anderen Anwendungsbereichen kommen könnten. Vielleicht hast du ja eine Idee, die sich tatsächlich umsetzen ließe - und die jemanden findet, der das gerne tun würde. Gruß Peter Am 11.09.2011 13:04, schrieb Rhinhold: Hallo Frederik und Christian! Danke für die Antworten! @Frederik: Das ist leider nicht ganz leicht. Zwar gibt es Flaechen, die in OSM mit landuse=residential als Wohnflaechen eingetragen sind, aber die sind mitnichten komplett. Schau Dir z.B. mal diese Karte von Muenchen an: http://www.openstreetmap.org/?lat=48.15772lon=11.53345zoom=16layers=M Nur im Nordosten des Bildes, im Stadtteil Ebenau, ist tatsaechlich eine Siedlungsflaeche eingetragen (etwas dunkleres Grau). Der ganze Rest (helleres Grau) hat keine Siedlungsflaeche. Das liegt daran, dass die Mapper wenig Motivation haben, eine Siedlungsflaeche in einer schon mit Strassen und Haeusern dicht befplasterten Gegend einzuzeichnen (man sieht ja, dass da Leute wohnen). Hm, das scheint in München tatsächlich nicht ganz unproblematisch zu sein. Jedoch trifft dies regional mit unterschiedlicher Intensität auf - so mein Eindruck. Beim Kontrollieren meiner ländlichen (!) Untersuchungsregionen (links und rechts des Rheins bei Karlsruhe/Mannheim) habe ich eine schöne Konsistenz den Einsatz des residential-Tags betreffend vorgefunden. Aber natürlich können auch dort Fehlerflecken auftauchen. Nichtsdestotrotz wäre es einen Versuch wert. Der Kartenausschnitt, den ich damit zeigen möchte, ist zudem so groß, dass es nicht auf vergessene Gewerbegebiete oder Neubaugebiete ankommt, sondern vielmehr um die Lage der Siedlung innerhalb ihrer Gemeindegrenze. Also, solange keine eklatanten Missstände auftreten, sind die kleinen Fehler zu vernachlässigen. Ein Landuse-Shapefile kannst Du Dir u.a. auf den folgenden Wegen selbst erzeugen: 1. osm2pgsql - geht auch fuer grosse Dateien, erfordert PostGIS (danach pgsql2shp), auf einem aktuellen Ubuntu/Debian-System kann man das aber alles als fertige Pakete installieren. 2. osm2shp aus dem OSM-Subversion-Repository (svn.openstreetmap.org/applications7utils/(export/osm2shp) - musst Du selbst compilieren und im C-Source angeben, was Du exportieren willst; sehr einfaches Programm, kann keine Multipolygone 3. osmjs, ein Teil von Osmium (wiki.openstreetmap.org/wiki/Osmium), das ist das beste, was es in Sachen Shape-Erzeugung derzeit gibt, kann Multipolyone und wird ueber ein Javascript-Schnipsel gesteuert; auch da musst Du allerdings selber compilieren und dann in Javascript definieren, was Du genau exportieren willst. Ach, ich sehe schon, ein echter Traum für jeden Nicht-Informatiker. :) Nicht beleidigt seien, aber zum großen Teil verstehe ich hier nur Bahnhof. Was mich wiederum zum nächsten Thema überleitet... [Alles zusammen hat mich mehrere Stunden meiner Arbeitszeit gekostet - was irgendwie nicht Sinn der Sache sein sollte/kann] Du kannst ja ueberlegen, was Du
[Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Hallo, Am 09/11/2011 02:26 PM, schrieb Peter Wendorff: Die Nutzung der Daten ist dagegen aber leider so extrem facettenreich, dass es einfach nicht genug Interessenten gibt, um eine benutzerfreundliche Lösung in einer Facette so weit voranzubringen. das sehe ich nur eingeschränkt so. Eine Facette im Sinne von ich möchte nur die Siedlungsflächen oder ich möchte nur 24h-Tankstellen in Soundso-Land lässt sich meistens in eine Kombination aus Tags und umschließenden Polygonen übersetzen. Damit ist im Grunde jedes Export-Tool parametrisierbar. Ein benutzungsfreundliches Export-Tool, das diese Parametrisierung beherrscht, würde schon vielen helfen. Es gibt Nischen, in denen das ja schon passiert: - Die Geofabrik-Extrakte bedienen alle, die einfach nur Ausschnitte für bestimmte Länder brauchen - diverse Garmin-Karten bedienen zwar mit vorgegebener Auswahl, aber doch die Gruppe der Garmin-Nutzer - Der Export von Bildern als SVG oder Rastergrafik direkt auf der Webseite bedient Grafiker, Layouter oder sonstwen, der einfach mal eben ein Kartenbild braucht. - Nominatim etc. bedienen alle, die nur mal nachschlagen wollen, wo Hintertupfingen liegt. Eine All-in-one-Lösung wäre aber auch schön! Wenn Du nun argumentierst, du könntest da nicht helfen, dann stelle ich, ohne mich damit als Programmierer direkt anbieten zu können, doch einfach mal die Frage zurück, die nämlich keine Programmierkenntnisse voraussetzt: Wie sollte denn die Exportmöglichkeit (als Programm, Web-Schnittstelle oder was auch immer) aussehen, die du dir vorstellst? Gute Frage! Mir schwebt in etwa Folgendes vor: Ein Web-Interface oder Programm mit GUI, in dem ich ein Rechteck oder Polygon über eine Karte ziehe und sage, welche Daten (Tags) ich möchte. Das Programm holt für mich die Daten und filtert sie, wandelt sie ggf. um, und dann kann ich damit tun, was ich möchte (z.B. in QGIS laden oder in eine DB importieren). Weil die Probleme aber schon beim Holen der Daten anfangen (XAPI down, Länderextrakte zu groß oder zu klein usw. usf.), arbeite ich weiterhin an der Generierung von Tiles von OSM-Daten, die als Grundlage für ein solches Export-Tool dienen könnten. (Beim OSM-Camp in Nürnberg werde ich vielleicht schon etwas zeigen können.) Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Aktualisierung Toolserver-Karte
Hallo, weiß jemand, von wann die Daten der mehrsprachigen Karte sind, bzw. wie man diese dann zum Neurendern bewegen kann? http://toolserver.org/~osm/locale/__all.html Ich habe bereits versucht, an die Kachel-URL ein /dirty zu hängen und er sagt auch, dass ein Neurendern angefordert wurde, aber /status zeigt, dass dies nicht passiert. Und ja, ich habe die URLs von den Kacheln der Beschriftungen genommen... Alex ___ 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. September 2011 02:40 schrieb Frederik Ramm frede...@remote.org: Und Ausdifferenzierungen in Gewerbe-, Industrie- und gewisse Arten von Abbaugebieten (quarry z.B.) gibt es schon _ewig_. Die funktionieren ja auch ganz gut. Wenn ich was sehe, was wie ein Steinbruch aussieht, tagge ich das als landuse=quarry. Das versteht doch jeder. Aber schon die Ausdifferenzierung in retail/commercial/industrial funktioniert in Deutschland z.B. nicht so gut, weil bei uns ein auf Schildern ausgewiesenes Gewerbegebiet mal mehr commercial und mal mehr industrial-Charakter hat. 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. 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. ereich 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). das ist das, was derzeit das WIki schreibt: geplante Flächen (die Info kann nur aus amtlicher Planung kommen) gleich zu taggen wie reale Nutzung. Würde ich gerne ändern und nur die reale Nutzung taggen. Es wird immer Unklarheiten geben. Wir muessen die Leute dazu erziehen, in dieser fuzzy-Welt zu arbeiten und daraus Nutzen zu ziehen, anstatt zu versuchen, Regeln und verlaessliche Modelle zu schaffen, die dafuer sorgen, dass es eine richtige Art gibt, etwas zu tun, und alle anderen Arten sind falsch. Das ist genau das, was ich dem Martin zuweilen vorwerfe - der Versuch, das einzig richtige festzuschreiben (und in Konsequenz natuerlich dann jenen auf die Finger zu klopfen, die es falsch machen). ja, zugegebenermaßen bringt uns falsch-richtig-Argumentation wenig, und ich bedauere sehr, durch ein paar unbedachte Worte anfangs hier viel Kredit verspielt zu haben. Systematik im Tagging schadet uns allerdings nicht, im Gegenteil, erleichtert sie allen das Mappen. Der Grund ist, das wir auch mit allen Bots der Welt nicht sicherstellen koennen, dass sich jeder an die Regeln haelt. Wir duerfen es daher nicht so weit kommen lassen, dass wir mit unseren eigenen Daten nur noch was anfangen koennen, wenn sich alle an die Regeln halten. +1. Nein. Es wird immer Struktur fehlen, und die Herstellung dieser Struktur waere nicht etwa eine willkommene Verbesserung des Projekts, sondern der Anfang vom Ende. Mehr und mehr Struktur in das Projekt hineinzupressen, ist nicht der richtige Weg. es gibt schon weitgehend Struktur, anders wären wir schon längst verzweifelt. Wenn Straßen und Wege z.B. mal in highway mal in anderen Keys aufgehoben wären. Jetzt wird bestimmt wieder irgendjemand kommen und meine Saetze so interpretieren, dass ich die Leute auffordern will, Fluesse als Autobahnen zu taggen oder so. Natuerlich gibt es Regeln, die aber fast alle einfach so evolutionaer entstanden sind - erst haben das ein paar Leute gemacht, dann haben es ein paar andere gut gefunden oder verbessert, und dann haben es irgendwann alle irgendwie aehnlich gemacht. +1. durchgesetzt haben sich dabei die Dinge, die von der Mehrheit für sinnvoll erachtet wurden, und das Kriterium dabei war, ob es aus Sicht der Mapper Sinn macht, etwas auf eine bestimmte Art zu erfassen. no comment - Du hast Bücher geschrieben, die tausende Mapper vor einen Karren gespannt haben dürften.. Naja, in den Buechern hab ich aber beschrieben, was gebraeuchlich ist, und nicht, wie ich mir eine bessere Tagging-Welt vorstellen wuerde. jein, da sind schon auch ein paar Dinge so drin, wie Du (Ihr) es gerne hättest und sinnvoll findest, die nicht unbedingt allgemeiner Konsens sind, und mit dem Buch hast Du natürlich einen größeren Hebel, als Joemapper, der für sich alleine vorgeht. Ich hatte den Eindruck, dass ihr beide in Euren Definitionsvorschlaegen bereitwillig auf Begriffsdefinitionen und Informationen zurueckgreift, die man vielleicht im Flaechennutzungsplan oder im Kataster oder im Grundbuch findet, aber nicht, wenn man mit seinem GPS und seinem Notizblock vor Ort steht. -1. Ich kenne zwar das offizielle System, wie Nutzungen in Deutschland klassifiziert und festgelegt sind, aber ich versuche nicht, dieses System auf OSM überzustülpen, nur damit irgendwelche deutschen Verordnungen umgesetzt sind. Martin und ich haben in erster Linie und im Dialog eruiert, /was/ überhaupt im Bereich Baufläche/Baugebiet abgebildet werden kann, Mir ging es noch nie um Bau in dieser Diskussion, sondern immer um Bestand. Planungen mit der Realität
Re: [Talk-de] Siedlungsflächen exportieren
Am 11. September 2011 13:04 schrieb Rhinhold rhinh...@googlemail.com: Also, als jemand, der seine Kenntnisse tendenziell außerhalb von Programmiersprachen und Netzwerklogiken verorten würde (s.o.), sehe ich da wenig Möglichkeiten, konkret Abhilfe zu schaffen. :) Insgesamt ist mir ein wenig schleierhaft, wie es unzählige Möglichkeiten des Datenexports geben, aber (fast) keine davon benutzer- und einsteigefreundlich sein kann. Immerhin hat es die OSM-Gemeinde ja schon geschafft, die Dateneingabe soweit zu vereinfachen, dass man mittlerweile wirklich behaupten kann jeder kann mitmachen. Davon sind wir - meiner Meinung nach - beim Datenexport aber noch meilenweit entfernt (was Dienstleistern, wie der Geofabrik nicht unbedingt sauer aufstoßen sollte :) ). Aber gerade Menschen, die diese Daten wirklich nutzen möchten, aber kein Verständnis von den notwendigen Prozeduren haben (wie meine Wenigkeit), sehen sich hier schnell vor dem Scheitern. Somit bleibt für mich als außenstehenden Mapper offen, inwiefern OSM denn wirklich frei-zugängliche Daten haben soll. der Export unterstellt, dass man die Daten in einem anderen System als dem von OSM brauchen würde, aber mit OSM kann man direkt arbeiten, die Tools dafür stellt das OSM-Ökosystem frei zu Verfügung. Auch ohne Informatiker zu sein kann man z.B. mit maperitive anspruchsvolle Karten rendern, quasi auf Knopfdruck. Für die Nutzung der Daten ist der Export nach Shapefiles nicht nötig, und wer Shapefiles braucht, wird sich in der Regel auch etwas auskennen mit GIS Systemen, Geodatenbanken, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODbL Statistik für V1 Objekte
Ich hab auf http://odbl.poole.ch/ im Abschnitt EXPERIMENTAL, für Deutschland, Irland und der Schweiz mal neue Statistiken gemacht, die als Erweiterung auch den Effekt von Edits von nicht-Zutimmer (aller Art) berücksichtigen. Die interessantesten zusätzlichen Daten sind im Tabellenabschnitt Objects impaired by Edits zu finden. Die Tabellen enthalten übrigens alle Mapper, die je in dem Bereich gearbeitet haben von denen ein erstelltes oder bearbeitetes Objekt noch sichtbar ist. Also z.B. auch Mapper die keine V1 und auch keine last edit Objekte mehr haben. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM-Server down?
Hallo, Ist irgendwas am OSM-Server? Ich kann nichts hochladen und osm.org ist auch nicht erreichbar... Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Server down?
Ja. Im Augenblick zickt was. Mehr dazu auf #osm-dev Simon Am 11.09.2011 17:15, schrieb Alexander Matheisen: Hallo, Ist irgendwas am OSM-Server? Ich kann nichts hochladen und osm.org ist auch nicht erreichbar... Alex ___ 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] Relation Analyzer noch state of the art?
Hallo zusammen, der relation analyzer wurde überarbeitet - einesteils schön, anderesteils - naja. Die Informationen und Möglichkeiten, die man hier früher bekommen hat, waren meiner Meinung nach erheblich besser - mir fehlen jetzt ganz einfach: * die Infos zur Streckenlänge; * zu den Unterbrechnungen und der hierzu gehörenden Streckenlänge, * die Möglichkeit zur Anzeige der Route bei googleEarth (!) (bessere/übersichtlichere Darstellung als in OSM, auch wegen der farbigen Aufbereitung der unterschiedlichen Streckenabschnitte) * die Möglichkeiten zum Export. Zwei Fragen: * Warum wird eigentlich die alte Version nicht mehr bereitgestellt bzw. bleibt nicht mehr online, solange die neue nicht über diese Features verfügt? * Warum ändern sich die Links zum Aufruf des Analyzers? Ich habe diesen beispielsweise in Webseiten eingebunden, um auch unbedarfte Leute an das Thema heranzuführen. Wenn diese Links jetzt einfach von heute auf morgen nicht mehr funktionieren, dann ist das nicht gerade ein Pluspunkt für OpenSource die Community... ...ich hab mich jetzt erst mal mit der Mailingliste beschäftigt und die Diskussion aus dem August gefunden - schade, hätte auch da schon gern was gesagt, ist mir aber durch die Lappen gegangen. Kann nur die dort vertretene Meinung wiederholen, ich nutz(t)e den Relation Analyzer sehr gern, da es ein ziemlich mächtiges Tool war - in der alten Form. Die Fragen nach der Nutzung (wer, wie oft...) sollten eigentlich nicht auftauchen müssen - auf dem Server könnten ja die entsprechenden Daten geloggt werden. m.E. sollte das ohnehin automatisch passieren - die Logs müssten doch nur ausgewertet werden? Für weitere Diskussionen stehe ich gern zur Verfügung :-) Trotz der etwas harschen Kritik oben: Danke an die Verantwortlichen, die hier Ihre Zeit investieren. Ich mappe bisher nur, da ich vor allem leider auch viel wenig zeit finde, um konzentriert an Entwicklungsthemen mitzuarbeiten :-( Muss schon so genug entwickeln in meinem Hauptjob... Andererseits: warum eigentlich nicht? ... die Zeit wird's zeigen. Gruss - uku69. -- u...@gmxpro.de / Uwe R. Kunzmann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Am 11.09.2011 15:29, schrieb ant: Hallo, Am 09/11/2011 02:26 PM, schrieb Peter Wendorff: Die Nutzung der Daten ist dagegen aber leider so extrem facettenreich, dass es einfach nicht genug Interessenten gibt, um eine benutzerfreundliche Lösung in einer Facette so weit voranzubringen. das sehe ich nur eingeschränkt so. Eine Facette im Sinne von ich möchte nur die Siedlungsflächen oder ich möchte nur 24h-Tankstellen in Soundso-Land lässt sich meistens in eine Kombination aus Tags und umschließenden Polygonen übersetzen. Damit ist im Grunde jedes Export-Tool parametrisierbar. Ein benutzungsfreundliches Export-Tool, das diese Parametrisierung beherrscht, würde schon vielen helfen. Das stimmt, aber ob dieses Tool benutzungsfreundlich für nicht-techniker bleiben kann, die sich auch nicht mit dem tagging-schema in allen Varianten auseinandersetzen wollen oder können, bezweifle ich. Osmosis wird durch osmembrane schon ziemlich benutzerfreundlich, finde ich. Trotzdem muss der Nutzer immer noch ein natürlich sprachlich formuliertes Problem irgendwie in die Filter umsetzen. Klar, man könnte eine Datenbank von pipelines anbieten, die häufige Aufgaben einfach abrufbar macht ((warum) gibt's das eigentlich noch nicht?). Aber es wird immer wieder Anfragen geben, die in dem Katalog nicht da sind, oder Facetten, die eben anders interpretiert werden könnten. Gehören Verkehrsflächen jetzt zu den Wohngebieten dazu oder nicht? Gehören Treppen zu den Wegen oder nicht? Wenn man sich mit den Tags selbst auseinandersetzen will/kann, dann gibt es die entsprechenden Tools. Wenn nur eine Frage in natürlicher Sprache vorliegt, wird kein Tool im Allgemeinen die Antwort liefern können. Es gibt Nischen, in denen das ja schon passiert: - Die Geofabrik-Extrakte bedienen alle, die einfach nur Ausschnitte für bestimmte Länder brauchen - diverse Garmin-Karten bedienen zwar mit vorgegebener Auswahl, aber doch die Gruppe der Garmin-Nutzer - Der Export von Bildern als SVG oder Rastergrafik direkt auf der Webseite bedient Grafiker, Layouter oder sonstwen, der einfach mal eben ein Kartenbild braucht. - Nominatim etc. bedienen alle, die nur mal nachschlagen wollen, wo Hintertupfingen liegt. Eine All-in-one-Lösung wäre aber auch schön! Stimmt. Aber enorm aufwändig, und durch die zentrale Wartung potentiell ziemlich fragil. Vielleicht wäre eine Art Plugin-basiertes Exporttool tatsächlich eine interessante Variante... Eine Oberfläche, die durch plugins um verschiedene Exporte erweitert werden kann. Die meisten existieren ja schon irgendwo/irgendwie. Wenn Du nun argumentierst, du könntest da nicht helfen, dann stelle ich, ohne mich damit als Programmierer direkt anbieten zu können, doch einfach mal die Frage zurück, die nämlich keine Programmierkenntnisse voraussetzt: Wie sollte denn die Exportmöglichkeit (als Programm, Web-Schnittstelle oder was auch immer) aussehen, die du dir vorstellst? Gute Frage! Mir schwebt in etwa Folgendes vor: Ein Web-Interface oder Programm mit GUI, in dem ich ein Rechteck oder Polygon über eine Karte ziehe und sage, welche Daten (Tags) ich möchte. Das Programm holt für mich die Daten und filtert sie, wandelt sie ggf. um, und dann kann ich damit tun, was ich möchte (z.B. in QGIS laden oder in eine DB importieren). Weil die Probleme aber schon beim Holen der Daten anfangen (XAPI down, Länderextrakte zu groß oder zu klein usw. usf.), arbeite ich weiterhin an der Generierung von Tiles von OSM-Daten, die als Grundlage für ein solches Export-Tool dienen könnten. (Beim OSM-Camp in Nürnberg werde ich vielleicht schon etwas zeigen können.) In Sachen Web-Interface ist die JXapi doch einen Schritt in die Richtung unterwegs, als Desktop-Anwendung fehlt Osmembrane im Grunde nur noch relativ wenig auf dem Weg zu einer benutzbaren Filteranwendung (z.B. wäre eine Karte praktisch, um boundingbox oder -polygon zu definieren) Gruß Peter ___ 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
[Talk-de] Wochennotiz Nr.60
Hallo, die Wochennotiz Nr. 60 mit allen Neuigkeiten aus dem OpenStreetMap-Universum ist da: http://blog.openstreetmap.de/2011/09/wochennotiz-nr-60/ Viel Spaß beim Lesen wünscht die gesamte Redaktion. :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aktualisierung Toolserver-Karte
On 11.09.2011 16:08, Alexander Matheisen wrote: weiß jemand, von wann die Daten der mehrsprachigen Karte sind, bzw. wie man diese dann zum Neurendern bewegen kann? toolserver hat gerade etwas Stau beim Rendern. Kann noch einige Tage dauern... Stephan ___ 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 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] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Moin, Am 09/11/2011 06:25 PM, schrieb Peter Wendorff: Das stimmt, aber ob dieses Tool benutzungsfreundlich für nicht-techniker bleiben kann, die sich auch nicht mit dem tagging-schema in allen Varianten auseinandersetzen wollen oder können, bezweifle ich. Osmosis wird durch osmembrane schon ziemlich benutzerfreundlich, finde ich. Trotzdem muss der Nutzer immer noch ein natürlich sprachlich formuliertes Problem irgendwie in die Filter umsetzen. wenn ich in Potlatch ein Restaurant eintragen will, klicke ich auf das Symbol mit Messer und Gabel und fertig. Das kommt der sprachlich formulierten Aufgabe schon sehr nahe. Wer dennoch spezielle Tags eintragen möchte, klickt auf Advanced und tippt Schlüssel und Wert ein. Dieses Konzept lässt sich auf beliebige Anwendungen übertragen. Bei einer guten Export-GUI müsste ein Datennutzer nicht unbedingt wissen, welche Tools im Hintergrund die Arbeit machen, welche Entity Streams wie gefiltert werden usw. Im Übrigen geht es mir nicht primär um die Tags - ich gehe davon aus, dass ein potenzieller Nutzer der Daten weiß, an welchen Tags er interessiert ist. Anders sieht es jedoch bei der Kenntnis der Kommandozeilentools - die nötig ist, um OSM-Daten nutzbar zu machen - aus. Klar, man könnte eine Datenbank von pipelines anbieten, die häufige Aufgaben einfach abrufbar macht ((warum) gibt's das eigentlich noch nicht?). Aber es wird immer wieder Anfragen geben, die in dem Katalog nicht da sind, oder Facetten, die eben anders interpretiert werden könnten. Gehören Verkehrsflächen jetzt zu den Wohngebieten dazu oder nicht? Gehören Treppen zu den Wegen oder nicht? Wenn man sich mit den Tags selbst auseinandersetzen will/kann, dann gibt es die entsprechenden Tools. Wenn nur eine Frage in natürlicher Sprache vorliegt, wird kein Tool im Allgemeinen die Antwort liefern können. Um beim Potlatch-Bild zu bleiben: Simple hieße bei unserem Tool nunmehr Tag-Kombinationen eingeben, Bbox ziehen und Enter drücken; advanced hieße, bei Bedarf die Prozess-Pipeline an den gewünschten Stellen manipulieren zu können. Grüße ant ___ 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. September 2011 23:10 schrieb Christian Müller cmu...@gmx.de: Am 11.09.2011 11:31, schrieb Martin Koppenhoefer: 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? Wenn es bei den administrativen Grenzen noch Lücken geben sollte, dann wird man die sicher auch noch schließen, aber ich bin nach wie vor der Meinung, dass für den Bezug hier die administrativen Grenzen nicht interessieren, sondern das Mapping unter siedlungsgeographischen Gesichtspunkten gemacht wird. Frederik hatte das in einer seiner frühen Mails zum Thema schon mal ganz gut beschrieben: vor Ort weiss jeder, wo das Wohnviertel ist, (und wenn er nachdenkt wird er vermutlich auch sagen können, wo es aufhört, also die Grenze ist), aber nach welchen Kriterien sich das genau ergibt, kann er meist nicht sagen (ein Urbanist könnte das allerdings schon, interessanterweise deckt sich das intuitive lokale Wissen normalerweise mit dem, was ein Urbanist nach wissenschaftlichen Kriterien herausarbeiten würde). Man muss kein Spezialist sein, oder wissenschaftliche Kriterien anwenden, um so was wie ein Wohngebiet im eigenen Lebensumfeld zu identifizieren. 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. und oft ist es gar keine admin-rechtl. Grenze, die das Wohnquartier definiert. 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. das ist oft nicht so. 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. es gibt immer eine fuzzyness in der Geometrie, das meiste kannst Du auch 2 Meter verschieben und die Karte ändert sich nicht, und wird vielleicht richtiger, vielleicht falscher aber genau sagen kannst Du es nicht. Eine grobe Schätzung einer Fläche ist z.B. obwohl nur angenähert meistens viel aussagekräftiger als ein Node. Auch wenn man sich um einen Straßenzug vertan hat ist das meistens genau genug. Und weiter verfeinern kann man ja sowieso immer. Ansonsten: +1 zu praktisch allen Punkten Deiner vorherigen Mail von 18:31h. Ich freue mich, dass Du auch klare einfache Bedeutungsstrukturen einem komplexen Gemisch mit div. Abhängigkeiten vorziehst. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de