Re: [Talk-de] [bulk]: Re: [bulk]: Suburb vs. Village
Hallo mit'nander, okay, anscheinend gibt es beim Taggen von Gemeindeteilen noch Klärungsbedarf. Wie aber - und das war meine zweite Frage - händeln wir das bei Städten? Der Tag suburb bezieht sich ja laut Wiki auf Stadtteile. Nur: Wann ist eine Stadt eine Stadt? Beziehen wir uns da auf Größenklassen oder auf den tatsächlichen Besitz des Stadttitels (der sich bspw. auch durch historische Funktionen ergeben haben kann)? Beispiel: Stadt Philippsburg - besitzt mit Rheinsheim und Huttenheim zwei Gemeindeteile. Philippsburg fällt dabei eher klein aus. Prinzipiell ist man also geneigt, den beiden das village aufzukleben. 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 Frederik, ich habe gestern nun endlich mal die Zeit gefunden, die Siedlungsflächen anhand Deiner Geofabrik-Shapes zu integrieren. Soweit ich das nun überblicken kann, sehe ich nirgendwo Defizite bzgl. der Flächenqualitäten - im Detail muss ich das aber noch gegenchecken. Fürs erste jedoch taugt der Landuse-Layer absolut dazu, die Siedlungsschwerpunkte innerhalb der Gemeindeflächen darzustellen. ;) Um es einmal zu demonstrieren, hier ein Screenie: http://dl.dropbox.com/u/6528140/Siedlungsflaechen.jpg Den Ausschnitt habe ich bewusst so gewählt, denn gleich dazu noch eine Frage: Wie kommt es, dass der Pfälzer Wald (westlich von Neustadt und Landau) einen derartigen Clipping-Fehler aufweist, wo doch auf OSM-Karten die Flächen ordnungsgemäß kartiert scheinen? Also nochmals vielen Dank für das Bereitstellen! Viele Grüße, Rhinhold Hallo, On 09/19/2011 01:35 PM, Rhinhold wrote: Jedoch... tauchen bei mir im Falle von Baden-Württemberg und Rheinland-Pfalz keine Objekte im Landuse-Layer auf (Objektanzahl = 0). Oh. Da ist das .shx-File kaputt, daher kann das nicht richtig gelesen werden. Hab es verbessert und lasse neue Shapes generieren, kann aber ein paar Stunden dauern, bis die auf dem Server eintreffen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ 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
[Talk-de] Suburb vs. Village
Hallo, wahrscheinlich gab es dazu schon eine intensive Diskussion. In dem Fall wäre das hier nur eine Nachfrage nach dem Ergebnis/Konsens. :) Laut Wiki werden nur Stadtteile oder -viertel mit dem Tag suburb getaggt. Ist das wörtlich zu nehmen? Oder fallen darunter auch die sonstigen Gemeindeteile (umgangssprachlich.: Ortsteile)? Und woran wird hier Stadt festgemacht: am tatsächlichen Stadttitel einer Gemeinde? Mir sind in meiner näheren Umgebung sehr unterschiedliche Herangehensweisen aufgefallen. Viele Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Siedlungsflächen exportieren
Hi Frederik, erstmal herzlichen Dank, dass Du Dir die Mühe gemacht hast. Jedoch... tauchen bei mir im Falle von Baden-Württemberg und Rheinland-Pfalz keine Objekte im Landuse-Layer auf (Objektanzahl = 0). Woran könnte das liegen? Schöne Grüße, Rhinhold Hi, On 09/10/2011 01:09 PM, Frederik Ramm wrote: Ich kann mal schauen, ob ich in die naechtlichen Geofabrik-Shapes noch einen Landuse-Layer mit aufnehmen kann. Die werden allerdings mit osm2shp erzeugt und haben daher auch meine Multipolygone. Sollte ab jetzt fuer alle Geofabrik-Shape-Downloads mit drin sein, ein neuer Landuse-Layer. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ 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] Wohngebiete, landuse=residential Verwendung - continued
Am 16. September 2011 04:44 schrieb Christian Müller cmu...@gmx.de: Am 15.09.2011 19:14, schrieb Martin Koppenhoefer: Politische Grenzen _sind_ Ortsgrenzen (per Logik, per allg. Sprachgebrauch, per Gesetz, seit Lebzeiten), genauso wie die Grenze einer Siedlungsfläche eine Ortsgrenze /ist/. jetzt hast Du die Siedlungsgeographie und alles, was Du dazu gelesen hast, wieder vergessen? Vor ein paar Mails waren wir schon weiter. Mir wäre - als Geograph - sehr daran gelegen, wenn ihr den Begriff der Siedlungsgeographie aus dieser Diskussion herauslassen könnte. Die Siedlungsgeographie ist ein Forschungszweig der Geographie und beschäftigt sich mit der Siedlung als solches (Lage, Morphologie, Genese und Funktion) und deren Einflüsse und Verflechtungen mit ihrem umgebenden Raum, nicht aber mit administrativen oder raumordnerischen Grenzziehungen. Das ist eben Teil der Raumordnung (auf der dann die Raumplanung aufsetzt). Generell ist auch der Begriff der Siedlung hier falsch gewählt. Denn: Als Siedlung wird jede Form der menschlichen Niederlassung bezeichnet. Eine Siedlung besteht in der Regel aus einer oder einer Gruppe von Behausungen. Der Siedlungsbegriff umfasst den Lagerplatz einer Jägergruppe genauso wie die Millionenstadt, den Einzelhof ebenso wie das Stadtdorf, die Tankstelle ebenso wie die Ferienhauskolonie. (Borsdorf/Bender 2010: Allgemeine Siedlungsgeographie). Die einzige Grenze, die die Siedlungsgeographie kennt (und interessiert), ist die Gemarkung (das jedoch nicht im rechtlichen, sondern im strukturellen Sinne). Demnach ist die Gemarkung die der Siedlung begrenzendes, versteintes Gebiet. Die Gemarkung besteht dabei aus der Siedlung und der ihr zugehörigen Wirtschaftsfläche, welche wiederum aus der Flur besteht, die ihrerseits wiederum aus Flurstücken und Parzellen (also Besitzflächen) zusammengesetzt ist. Also, lange Rede, kurzer Sinn: Bleibt bei der Raumordnung! Dankeschön. ;) P.S.: Der Begriff Ortsgrenze ist weder rechtlich noch wissenschaftlich definiert. Nehmt stattdessen Siedlungsfläche (im raumordnerischen, nicht geographischen Sinne). Ich würde übrigens davon abraten, irgendwelche Grenzen außerhalb von Siedlungs- und Verwaltungsflächen zu definieren. Denn, was wollt ihr dann z.B. mit Aussiedlerhöfen tun? Es ist also genauso gültig das /place polygon/ (wenn es denn deiner Meinung nach schon eine Ortsgrenze darstellt) eher an die politische Grenze zu vergeben. es wäre prinzipiell genauso möglich, dann müsste man für geographische Ortsgrenzen einen neuen tag erfinden und hätte die administrativen Grenzen doppelt drin. Wieso sollte man das tun? Würde mich mal interessieren, wie so eine geographische Ortsgrenze aussieht... ;) Es gibt nicht /die/ Ortsfläche. Je nachdem in welchem Kontext und Sinn der Ortsname gebraucht wird, handelt es sich um völlig andere Flächen. _Alle_ konkreten Flächen (und mehr) sind aber der /Ort/. jaja. Die von den Verwaltungsgrenzen umschlossenen Flächen würde man allerdings eher nicht als Ortsfläche bezeichnen. Eher als Gemeinde, oder was es sonst ist. Genau. Die Gemeinde ist die kleinste sich selbst verwaltende politische Einheit im Staat mit räumlichen Territorium (Lexikon der Geographie). Dieses Territorium ist ihre Gemeindefläche (Gemarkungsfläche bzw. die Summe ihrer Gemarkungsflächen). Eine Gemeinde kann mehrere Gemarkungsflächen innehaben; z.B. dann, wenn Eingemeindungen stattgefunden haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Die einzige Grenze, die die Siedlungsgeographie kennt (und interessiert), ist die Gemarkung (das jedoch nicht im rechtlichen, sondern im strukturellen Sinne). Demnach ist die Gemarkung die der Siedlung begrenzendes, versteintes Gebiet. Die Gemarkung besteht dabei aus der Siedlung und der ihr zugehörigen Wirtschaftsfläche, welche wiederum aus der Flur besteht, die ihrerseits wiederum aus Flurstücken und Parzellen (also Besitzflächen) zusammengesetzt ist. die Siedlungsgeographie kennt doch wohl schon so was wie die Siedlung (z.B. Stadt, Dorf) und sowas wie einen Teil der Siedlung (Viertel, Wohngebiet, Ortsteil). Ja, natürlich tut sie das; insbesondere die Stadtgeographie (Teilbereich der Siedlungsgeographie) muss sich damit auseinandersetzen. Jedoch nimmt sie administrative Grenzen nicht als Gegenstand auf, sondern nimmt sie als einen Aspekt hin oder versucht sie durch die Genese (also z.B. Eingemeindungen, Suburbanisierung, Periurbanisierung, etc. etc.) zu be-/ergründen. Meiner Meinung nach darf sie sich aber auch nicht an den Verwaltungsgrenzen aufhängen, da Grenzziehungen nunmal selten anhand wissenschaftlicher Kriterien (sondern v.a. politisch motiviert) erfolgen und somit keine Grundlage bilden, im Sinne der Siedlungsforschung etwas erklärendes zu ziehen. Im Gegenteil: Da die amtlichen Grenzziehungen nur allzu oft Heterogenität zu homogenisieren wissen, braucht es den grenzlosen Blick, um diese wieder auseinanderzuflechten (Bsp.: Stadt mit ehemals traditionellen Dorfkernen im Umland, die nun Stadtteile sind und städtebaulich im Laufe der Zeit überprägt oder gar überrannt wurden). Die einzigen Grenzen, die es für die Siedlungsgeographie wirklich zu beachten gilt, sind die natürlichen (Gewässer, Topographie, Klima, Böden, etc.). Sorry, ist ein bisschen off-topic! ;) Es gibt nicht /die/ Ortsfläche. Je nachdem in welchem Kontext und Sinn der Ortsname gebraucht wird, handelt es sich um völlig andere Flächen. _Alle_ konkreten Flächen (und mehr) sind aber der /Ort/. jaja. Die von den Verwaltungsgrenzen umschlossenen Flächen würde man allerdings eher nicht als Ortsfläche bezeichnen. Eher als Gemeinde, oder was es sonst ist. Genau. Die Gemeinde ist die kleinste sich selbst verwaltende politische Einheit im Staat mit räumlichen Territorium (Lexikon der Geographie). Dieses Territorium ist ihre Gemeindefläche (Gemarkungsfläche bzw. die Summe ihrer Gemarkungsflächen). Eine Gemeinde kann mehrere Gemarkungsflächen innehaben; z.B. dann, wenn Eingemeindungen stattgefunden haben. +1 endlich jemand, der das genau gleich sieht. Geht eigentlich auch gar nicht anders. Man nehme nur mal eine größere Stadt und schaue in ihr Liegenschaftskataster - oder in Wikipedia. :) Schöne Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen
Fehlt noch etwas für Tourismus: Hotelanlagen, Residenzen, Hotels, Ferienwohnungen, Ferienbungalows, Spas, Tagungs- und Kongresszentren, Messen?, zugehörige (nicht-/halböffentliche) Sportanlagen, Pools, Strände, Golfplätze, Parks, ... Meiner Meinung nach fällt das dann auch in commercial, zusammen mit einem generalisierten subtag, wie etwa leisure, und einem spezifischen subtag. Ich persönlich wäre für folgende landuses: - residential - mixed_use Mischgebiet: Wohnungen, Büros, Praxen und Geschäfte (sogenanntes nicht-störendes Gewerbe, täglicher Bedarf) - commercial Büros (Bürokomplexe möglich, aber nicht zwingend), Geschäfte (Großgeschäfte wie Baumärkte, Großverbraucher möglich, aber nicht zwingend), kann auch Handwerksbetriebe und Praxen sowie Wohnungen der Gewerbebetreibenden enthalten Keine Industrie und kein stark störendes Gewerbe (Verschmutzung, Lärm) vorhanden Gewünschte Verfeinerung bei Bedarf im Subtag: office, retail, manufactoring - industrial Industrie, mindestens schweres Handwerk oder produzierendes Gewerbe (stark störendes Gewerbe) vorhanden, kann aber auch kleinere Handwerksbetriebe bzw. produzierendes Gewerbe enthalten Hm, und wo ziehst du dann die Abgrenzung zwischen Handwerksbetrieben im Sinne von commercial und im Sinne von industrial? Vorschlag meinerseits: Sofern der Verkauf von Waren und Dienstleistungen direkt am Standort erfolgt (z.B. Bäckereien, KFZ-Werkstätten, Schreinereien, etc.), sollte es als commercial getaggt werden. Demnach müssten dann eigentlich Lagerhäuser oder Umschlagplätze als industrial gekennzeichnet werden. Industrie meint im Übrigen auch nicht gleich, dass sie störend sein muss. Beim Einzelhandel würde ich die Abgrenzung zwischen commercial und mixed_use ziehen, sofern das Grundstück von anderen Nutzungen, wie z.B. Wohnungen separiert ist (Bsp.: Fachmarktzentren bzw. -agglomerationen). Ein Bäcker mitsamt Wohnung wäre somit kein commercial, sondern eben mixed_use. Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen
Fehlt noch etwas für Tourismus: Hotelanlagen, Residenzen, Hotels, Ferienwohnungen, Ferienbungalows, Spas, Tagungs- und Kongresszentren, Messen?, zugehörige (nicht-/halböffentliche) Sportanlagen, Pools, Strände, Golfplätze, Parks, ... Meiner Meinung nach fällt das dann auch in commercial, zusammen mit einem generalisierten subtag, wie etwa leisure, und einem spezifischen subtag. +1, m.E. ist das entweder commercial (Hotels, Kongresszentren, ...), oder ggf. brauchen wir gar keinen Landuse dafür (die Dinge, die in leisure fallen), oder wenn doch dann plädiere ich für einen Tag analog BauNVO Sondergebiete, die der Erholung dienen: (1) Als Sondergebiete, die der Erholung dienen, kommen insbesondere in Betracht Wochenendhausgebiete, Ferienhausgebiete, Campingplatzgebiete. Interessant wäre m.E. auch, commercial weiter subzutaggen, z.B. öffentliche Verwaltung / Regierung / Ministerien, private Verwaltung, Tourismus, ... Auch für Museen, Theater, Opern und derlei kulturelle Nutzungen fehlt m.E. ein landuse tag in OSM (landuse=cultural ?). Hm, bisher haben wir den Fall der Sondergebiete ignoriert (soweit ich das sehe). Sollten wir die aber reinnehmen wollen, machen wir uns ein neues Fass an Deklarationskonflikten auf. Z.B. sollte dann ein Kraftwerk nicht mehr industrial sein, sondern - aufgrund seiner Infrastrukturleistung - ein Sondergebiet darstellen. Ich finde aber unsere aktuelle Aufstellung durchaus leistungsfähig genug, das komplette Spektrum abzudecken. Zudem würde man dann nicht zu sehr in Konflikt mit ausländischen Definitionen kommen. Daher würde meiner Meinung nach das Einsortieren von touristischen und kulturellen Einrichtungen in commercial + subtag (dann leisure, cultural, usw.) am ehesten Sinn machen. Dagegen müsste man sich noch überlegen, was wir aus Bildungseinrichtungen und sonstiger, öffentlicher Infrastruktur machen (Mülldeponien, Wasseraufbereitung, Rathäuser, Ministerien, etc.) - am ehesten splitten in residential und industrial. Vorschlag meinerseits: Sofern der Verkauf von Waren und Dienstleistungen direkt am Standort erfolgt (z.B. Bäckereien, KFZ-Werkstätten, Schreinereien, etc.), sollte es als commercial getaggt werden. Demnach müssten dann eigentlich Lagerhäuser oder Umschlagplätze als industrial gekennzeichnet werden. werden sie ja auch. Bäckereien sehe ich nicht in commercial sondern in residential (ausser es sind Großbäckereien, dann industrial). Kfz-Werkstätten, Schreinereien etc. sind glaube ich eher in industrial zu finden (so sehen viele Ausländer industrial). Okay, bei den Bäckern sehe ich das ein - solange sie nicht im Verbund mit anderen Geschäften stehen (z.B. Fußgängerzonen, Stadtteilzentrum). Bei den Werkstätten und sonstigen Dienstleistern im Gewerbegebiet könnte ich mir hingegen vorstellen, dass man in Erklärungsnot bzgl. der Trennung von commercial kommt. Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Hallo alle miteinander, zu allererst finde ich es schön, dass hier offensichtlich die Bereitschaft zur offenen Diskussion vorhanden 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). Es sollte auch keine Beschwerde im ursprünglichen Sinne sein, sondern vielmehr eine Art, zu zeigen, wieviel Frust sich in einem anstauen kann, wenn es nicht gelingt, trotz Wille und Zeit Ergebnisse produzieren und am Ende jegliche Mühe als gescheitert ansehen muss. Dabei bin ich ein sehr genügsamer Mensch. :) Nun sehe ich aber vollkommen ein, wenn Peter einwirft, dass die Vereinbarkeit von OSM-Rohdaten und den spezifischen Nutzungswünschen nicht ohne weiteres zusammenzubringen ist. Da ich selbst ab und an kartiere, habe ich das unendliche Diskussionspotenzial um die Auslegung von Tags auch schon miterlebt. Daher wird es so oder so keine Perfektion geben - so wie eben das ganze OSM-Gebilde niemals perfekt sein kann und wird. Was man aber tun kann, ist einen größtmöglichen Spielraum zu schaffen, der - ständig weiterentwickelt - einen immer größer werdenden Nutzerpool (mit entsprechenden Bedürfnissen) erreicht. Aber zurück zur konkreten Ebene: Ich finde den Ansatz von ant sehr richtig, der da sagt: 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). Nichts anderes haben doch auch schon informationfreeway.org (wenn es denn mal gänge) und das Stuttgarter Pendant versucht und in Teilen erreicht. Sowohl beim einen als auch beim anderen definiere ich eine BBox und die Information, die ich haben will (mit der Voraussetzung, dass man sich mit den Tags etwas auskennt). Danach lasse ich mir das als gpx-, kml-, shp oder sonstige Datei ausgeben (je nachdem, wie die technische Umsetzbarkeit ist). Somit sind meiner Ansicht nach die Techniken doch schon vorhanden. Was lediglich fehlt, ist einfache Handhabung. Und hier kranken die meisten Ansätze meiner Meinung nach. Dabei geht es, wie ant auch schon angerissen hat, auch einfacher: 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. Übersetzt in die Export-Perspektive bedeutet dies, man müsste ein kleines und erweiterbares Sammelsurium an Vorlagen (oder besser: Tag-Pakete) bereitstellen. Diese könnten dann z.B. lauten: Ich möchte alle Gewässer! - darin enthalten sind dann sowohl Flüsse, Bäche, Seen, Polter, etc. Ich möchte alle Flüsse! - und er bekommt nur die Flüsse, nicht aber die Bäche und Seen, etc. Letztlich ist also doch nur eine Kombinatorik von Tag-Elementen erforderlich (außer vllt. bei Relations, oder?). Und alles, was die Vorlagen nicht erfassen (oder falsch erfassen), kann man mit einem Advanced-Button direkt selektieren oder eben de-selektieren. Also? Peter dazu: Alles in Allem schreit das für mich nach 'ner Aufgabe für osmembrane: Die Karte zur bbox-Auswahl sollte nicht so kompliziert sein, ein Polygon zu zeichnen auch nicht, bleibt die Vereinfachung der Tag-Auswahl. Dito. OSMembrane macht bereits vieles richtig, scheitert aber aus meiner Nicht-Informatiker-Sicht (noch) völlig an der Usability. Der Mehrwert dieser Applikation ist somit gegenüber der manuellen Texteingabe eher gering. Aber das Potenzial ist riesig, da die Basis ja schon steht. Soweit mein Senf. ;) Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Ich möchte alle Flüsse! - und er bekommt nur die Flüsse, nicht aber die Bäche und Seen, etc. Letztlich ist also doch nur eine Kombinatorik von Tag-Elementen erforderlich (außer vllt. bei Relations, oder?). in OSM ist das theoretisch einfach: alles mit waterway=river. Wenn Du aber genau hinsiehst, dann wird es komplizierter. Wann ist ein Fluss denn ein Fluss? Das ist überhaupt nicht allgemein definiert (z.B. über die Wassermenge), sondern z.T. auch historisch bedingt. Sehe ich ein. In der Tat ist das eine knifflige Angelegenheit. [In der Hydrogeographie behilft man sich mit Ordnungskennzahlen, die sich aus der Größe des Gewässersystems (bzw. der Summe der Gewässermitglieder) ergibt. Dennoch fehlt natürlich eine klare Definition.] Daher bleibt es uns OSM-lern überlassen, eine Klassifizierungslösung zu finden. Getan haben wir das ja auch schon bei den highway=track und den grade-Werten. Natürlich ist das nicht optimal, aber gerade zwischen Flüssen und Bächen könnte man da aufgrund ihrer geringen Anzahl (geg. Bächen und Kanälen) schon was auf die Beine stellen. Davon mal abgesehen, sollte dennoch bei meinem Beispiel Ich möchte alle Flüsse! der Tag waterway=river (und ggf. noch ein anderer) eingetragen werden. Über die Ausgabe-Qualität eines Tags bestimmt nun mal immer das OSM-Material - das Dilemma werden wir fast überall bekommen. Nichtsdestotrotz sollte der Export erst einmal möglich sein. Grüße, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Flüssen und Bächen; gesplittet von Exportmöglichkeiten
Sehe ich ein. In der Tat ist das eine knifflige Angelegenheit. [In der Hydrogeographie behilft man sich mit Ordnungskennzahlen, die sich aus der Größe des Gewässersystems (bzw. der Summe der Gewässermitglieder) ergibt. Dennoch fehlt natürlich eine klare Definition.] Daher bleibt es uns OSM-lern überlassen, eine Klassifizierungslösung zu finden. Getan haben wir das ja auch schon bei den highway=track und den grade-Werten. Natürlich ist das nicht optimal, aber gerade zwischen Flüssen und Bächen könnte man da aufgrund ihrer geringen Anzahl (geg. Bächen und Kanälen) schon was auf die Beine stellen. M.E. gibt es 2 Hauptarten von Fließgewässern in OSM: natürliche und künstliche. Bei den natürlichen haben wir 2 Arten: river und stream, wobei letztere prinzipiell kleiner sind als erstere, width als Breitenangabe ist auch nicht verkehrt, sofern man das kann. Im deutschen Sprachgebrauch gibt es hauptsächlich diese 2 Arten (Fluss und Bach, es gäbe noch Strom als Sonderfall von Fluss, aber nach unten ist das eigentlich alles), während das Italienische mehrere unterschiedliche natürliche, kleinere Wasserläufe kennt, daher gibt es hier öfters mal Nachfragen und Unzufriedenheit diesbezüglich ;-) Naja, wenn man meinen Professor fragen würde, hätte sicherlich auch der mehr als zwei Arten von Fließgewässern auf Lager. Aber ja, im Sprachgebrauch sind es hauptsächlich zwei. Bei den künstlichen haben wir 3 Arten: canal, drain und ditch (blöderweise scheint die Trennung, wenn man das Wiki streng liest, zwischen drain und ditch auch eine funktionale zu sein, wobei andererseits, wenn man immer noch streng liest, sich da eigentlich eine Lücke ergeben würde für künstliche Wasserwege, die nicht in einem Graben laufen und solche, die nicht für industrielle Abwässer oder Regenwasser geschaffen sind, (sondern z.B. zur Trockenlegung dienen, was ja drain prinzipiell als Wort abdeckt). Diese blöde Angewohnheit, Beispiele direkt in die Definition zu schreiben, sorgt, solange man das exklusiv interpretiert, für unnötigen Ballast. Praktisch sieht das aber m.E. kaum jemand so eng, sonst würde man ja eine Vielzahl von Fließgewässern gar nicht taggen können. Meine eigene Interpretation ist, dass auch die künstlichen Fließgewässer sich von groß nach klein differenzieren, also wie genannt canal, drain, ditch. Meiner Meinung nach genügt das unterscheiden zwischen Fluss und Bach auch völlig. Mehr noch, man sollte hier eigentlich aufhören können und alles weitere (z.B. Kanalisiert? Industrieabfluss? Zu- oder Ableitung? Schiffbar?) den Sekundärtags überlassen. Der Primärtag (also waterway) sollte nur für die grundsätzliche Größenbeschreibung da sein. Das Erscheinungsbild eines Fließgewässers ist doch hauptsächlich, die Art der Nutzung oder gar historische Umstände erst einmal nebensächlich. Wir definieren einen Feldweg ja auch erst einmal mit highway=track und danach erst dessen Zustand oder dessen Nutzung. Somit ließe sich das Problem der fehlenden Definition *eigentlich* leicht lösen. 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 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
[Talk-de] Siedlungsflächen exportieren
Hallo alle miteinander, für meine Diplomarbeit bastel ich mir gerade eine GIS-Karten-Grundlage mit QGIS von meinen Untersuchungsregionen zusammen. Bisher habe ich bereits die administrativen Grenzen (aus Institutsbestand) und Fernstraßen (aus OSM extrahiert) eingetragen. Da die administrativen Grenzen logischerweise nur die Gemarkungsgrenzen darstellen, nicht aber die Siedlungsschwerpunkte, benötige ich nun noch die Siedlungsflächen (v.a. residential). Jedoch stellt sich mal - wie so oft - ein banales Problem letztlich als ein aufwendiges dar. Die Datendienste von Cloudmade und Geofabrik stellen zwar viel zur Verfügung, aber bei den Shape-Files sind die Siedlungsflächen nicht berücksichtigt und bei den großen .osm-Auszügen rechnet sich mein Rechner in QGIS dumm und dämlich: Selbst nach 3h hatte ich noch kein Ergebnis. Wie soll da erst das Selektieren und Weiterverarbeiten werden? Und auch der Weg über informationsfreeway.org ist ein vergeblicher, da anscheinend der Dienst nicht funktioniert. Osmosis (+ OSMembrane) 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] Somit also nun meine Ratlosigkeit. :) Schöne Grüße und ein sonniges WE, Rhinhold ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
