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)
Moin, Christian Müller schrieb: Am 13.09.2011 18:13, schrieb Martin Koppenhoefer: PS: Bitte nicht immer border schreiben, es heisst boundary. Ich spreche von der basisgeometrischen Grenze, dem mit 'border=*' getaggten way, der in OSM Grundlage von boundary-Relationen ist. Oh - muss ich jetzt alle meine boundary=* - Keys umschreiben? =-O Der way, der in OSM als Grenze getaggt wird, wird mit boundary=* getaggt, _nicht mit border=*_! 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
Moin, Christian Müller schrieb: http://de.wikipedia.org/wiki/Toponomastik klärt unser Missverständnis auf Die Seite schreibt, dass im deutschen 'Ortsname' doppelt verwendet wird, - zum einen als Synonym für "Toponym" (und genau dort sehe ich place=* angesiedelt) - zum anderen ///im Speziellen/// als Name einer Siedlungsstelle (dort siehst Du place=* offenbar) Letzteres grenzt zigtausende bisherige Verwendungen von place=* aus. place ist in OSM _nicht_ nur eine Siedlungsstelle. Auch, aber eben nicht nur. place values erfassen Toponyme in Größenordnungen von Kontinenten bis runter zu Waldlichtungen. Da ist keine Systematik erkennbar, bis auf eben den Fakt, dass es Toponyme erfasst. 1. Martin hat place als Synonym für Toponym (hä? Ein Hoch auf Wikipedia ...) nie angezweifelt, im Gegenteil, er hat es immer bestätigt als eine Örtlichkeit, sei es Siedlung, Flur, Gebiet, Region etc. 2. Wie kommst Du darauf, dass Martin place _nur_ als Name einer Siedlungsstelle belegen will? Aber der Name einer Siedlungsstelle ist eben _auch_ ein Toponym. 3. Kannst Du Dir nicht vorstellen, dass man für solch ein Toponym (einer Region) in OSM auch mal eine Ausdehnung benötigt? Wie soll man ein Toponym einer weitläufigen Region (Polynom ... quatsch ... Polygon) verarbeiten, wenn diese Information nur in einer einzigen Koordinate (node) in OSM enthalten ist, man aber nur einen (mehr oder weniger großen) Randbereich dieser Region bearbeitet? Gruß Georg ___ 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 =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl
Am 14. September 2011 19:28 schrieb Christian Müller : > boundary=administrative > border_type=city > > Aber weshalb dann nicht > > boundary=administrative > boundary_type=city m.E. reicht hier admin_level aus, border_type oder boundary_type braucht man für administrative Grenzen, soweit ich das derzeit überblicke, nicht. Für places brauche ich die auch nicht, weil der place-Wert ja schon sagt, was es ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15. September 2011 02:22 schrieb Christian Müller : >>> .. verrauschtes "noise" bitmap. >> Nein, dass wären 'falsche' Renderregeln. > Angenommen ich würde jedes Grundstück mit einem einzelnen landuse=* taggen. > Stell Dir Mischgebiet vor. Nun wird gerendert. Ich zoome heraus, und > voila: Noise. Der nächste Schritt ist, dass die Renderregeln angepasst > werden, und erst auf einer tieferen Ebene landuse=* gerendert wird Die Renderregeln können ja auch komplexer sein, als nur Flächen eines bestimmten Landuses in einer bestimmten Farbe einzufärben. Wenn sich im Laufe der Zeit dadurch, dass sich die Differenzierung der Welt auch in OSM wiederfindet, in einem bestimmten zoomlevel die landuses zu noise werden, wie Du befürchtest, dann könnte man z.B. - sofern die Daten das hergeben - auch als Renderer herausfinden, dass ein bestimmtes Gebiet eine bestimmte Nutzungsmischung hat, und das grafisch in die Karte einarbeiten. Z.B. könnte man größere, gröbere Gebiete automatisch aus feiner und differenzierter aufgelösten Gebieten berechnen und sich dabei je nach Karte, die man erstellt, entscheiden, welche Nutzungen man nicht differenzieren will, und welche einem, wenn sie auch klein sein mögen, dennoch wichtig genug sind, sie einzeln zu zeichnen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15. September 2011 01:34 schrieb Christian Müller : > Am 14.09.2011 15:17, schrieb Garry: > Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit in > die Karte aufnehmen. > Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne > Detailverlust im Wald) sind: wieso sollte das kein Detailverlust sein? > Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Hi,
Am 14.09.2011 11:23, schrieb Georg Feddern:
"'vorrangige', reale Flächennutzung"
Das ist durchaus eine sinnvolle, nicht-strikte Definition.
Aber warum erwartest Du dann, das man sich _strikt_ an eine nicht
näher angegebene Größenordnung hält?
Wo muss man diese Größenordnung ziehen?
Erwarte ich nicht -> siehe letzte mail + die mail zur Datenhaltung
'vorrangig' bezieht sich sowieso nicht auf die Größenordnung, denn
'vorrangig' oder 'überwiegend' ist auf bel. Größe/geograph. Ausdehnung
ermittelbar..
Das Problem ist, dass die momentane Datenhaltung von landuses=* mittels
"closed ways" "uns" nicht erlaubt, die Micromapper mit den Makromappern
zusammenzubringen.
Deshalb kommt Quark dabei heraus, wenn sowohl ein Micromapper, als auch
ein Makromapper landuse=* verwendet.
Der Micromapper zerlegt das Gebiet des Makromappers, obwohl die größere
Fassung (Du schreibst, Deutschland besteht 'vorrangig' aus Agrarfläche),
doch wohl auch Sinn macht!
Und -vice versa- killt der Makromapper mini-landuses von der
OSM-Bildfläche, weil er der Meinung ist, ein landuse=* sei kein building=*
Nur aufgrund dieses Mißstands bestand von Anfang an der Wunsch
landuse=* größenordnungsmäßig zu begrenzen.
Weil wegen der technischen Art der Erfassung Micromapper und Makromapper
nicht oder nur schlecht (overlapping ways..) koexistieren können.
.. verrauschtes "noise" bitmap.
Nein, dass wären 'falsche' Renderregeln.
Angenommen ich würde jedes Grundstück mit einem einzelnen landuse=*
taggen. Stell Dir Mischgebiet vor. Nun wird gerendert. Ich zoome
heraus, und voila: Noise. Der nächste Schritt ist, dass die
Renderregeln angepasst werden, und erst auf einer tieferen Ebene
landuse=* gerendert wird
Die Granularität bestimmt die Breite der definierten landuses. (Leider
wird/wurde bei OSM oft zu schnell in die Breite gegangen, statt zu
staffeln. :-( )
+1 bessere Staffelung ist eine Lösung des Problems.. zuviele Werte in
einem key sind schlecht.. schlecht strukturierbar, schlecht für Einsteiger
Erstens endet die landuse-Granularität z. Z. spätestens an der
Grundstücksgrenze - den so sinnlosen landuse=grass mal außen
vorgelassen - und gleiche Nutzungen nebeneinander ergeben eine
gemeinsame Fläche, im Zweifelsfall den von Martin angesprochenen Block
(zwischen Verkehrswegen) - den man ja nicht auf Krampf unterteilen
muss. Aber setzt sich der landuse=road durch, ist dort dann sowieso
Schluss, falls sich der Schwebe-Ansatz nicht durchsetzt.
Mit multipolygons besteht das Problem nicht.. Da schwebt alles Makro
dann über Micro, ohne sich zu stören. Die Frage ist nur, ob man die
Editoren soweit bringen kann, dass Mapper damit keine Probleme haben..
Und zweitens werden ab einem gewissen Zoomlevel landuses rendermäßig
zusammengefasst (landwirtschaftlich, bebaut/besiedelt) sowie kleine
Flächen weggelassen.
Das ist interessant. Machen Renderer tatsächlich den Aufwand
Flächengrößen zu berechnen, bevor gerendert wird?
.. (für jedes Gebäude finde ich unter Garantie 25 verschiedene
Bodennutzungsarten ringsum).
Hier hätte ich gerne Belege für (diese Übertreibung) ...
;-)
Das ist für landuse=*, useless=*..
Allerdings - aber in meinen Augen eben auch nicht zwangsläufig zu
befürchten.
Insbesondere nicht, wenn man sinnvoll staffeln würde, statt weiter nur
(oft unüberlegt) in die Breite zu gehen.
The thing is.. Staffelst Du sinnvoll, erhälst Du kleinere Flächen, weil
die Staffelung dann ja (hoffentlich) auch für die Ausdifferenzierung der
verfügbaren Fläche genutzt wird. Damit gehen aber (ohne overlapping
ways und ohne multipolygons) die Flächen verloren, welche die gröbere
Einteilung, die gröbere Staffelung beinhalten.
Dein wie auch mein Argument dazu würde sein, dass man sich die gröberen
Flächen ausrechnen kann - das zieht hier aber nicht:
- zum einen sind die Gebiete nicht immer ausrechenbar sind (z.B.
dann nicht, wenn das gröbere Gebiet einen Namen hat - den müsstest Du
dann auf jedem feingranularen Gebiet auch angeben, und das
feingranularere Gebiet könnte dann keinen eigenen Namen mit name=* mehr
erhalten)
- zum anderen sehr viele Leute die gröberen Gebiete verwenden (es
damit Verschwendung wäre, wenn jeder für sich rechnet)
Wird ein grobes Gebiet unter Nutzung der Grenzen der feineren Gebiete
mittels multipolygon erfasst, kann man auch nicht direkt davon sprechen,
dass redundante Information in der DB wäre, denn es ist nur die
Information enthalten, wie aus den feineren Gebieten, dass größere
konstruiert wird). Die Regel an sich ist redundant in der DB ("wie
konstruiere ich die Siedlungsfläche aus den micro-landuses"), aber keine
Daten.
Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels
multipolygon gemappt wird, womit sich 'genaue' und 'vorranige'
Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag
aufmachen, um landuse micromapping zu betreiben..
Denn landuse micromapping erhöht Eintr
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 14.09.2011 15:17, schrieb Garry: Es ist ein Alleinstellungsmerkmal und erhöht die Auffindbarkeit solcher Besonderheiten. Wenn Du z.B, eine OSM-Garminkarte verwendest in der aus Platzgründen keine Häuser dargestellt werden siehst Du an der Stelle des Hauses nur Wald, ohne eigenem landuse ist so ein Haus dann auf der Karte unauffindbar. Und nein, ich sehe dass nicht als Mappen für den Renderer an sondern ein Mappen der Realität zur besseren Nutzubarkeit der Daten. Ich verstehe dein Anliegen vollkommen, solche Problem habe ich in der Datenweiterverarbeitung auch, aber das ist die Datennutzbarkeit /eines/ Anwendungsfalls. Der nächste wird es genau anders brauchen.. Auch /deinem/ Anwendungsfall ist damit nicht geholfen, wenn dies das Ziel sein soll: - jedes Haus hat irgendein Alleinstellungsmerkmal - wenn auf dieser Grundlage landuse=* erfasst und fragmentiert wird, bringt die Filterung von building=* bald nichts mehr.. Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit in die Karte aufnehmen. Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne Detailverlust im Wald) sind: - filtere nur building=* aus den Daten, die innerhalb landuse=residential liegen - tagge die building=* im Wald mit einem Alleinstellungs-tag (z.B. secluded=yes), dann danach filtern - place-node nutzen (wenn die Häuser im Wald durch ein Toponymeinen Namen? häufig schon..) Es gibt keinen echten Grund /dafür/ (für dieses Problem) feingranulare landuse=* zu erfassen. Da bieten andere Problemstellungen bessere Gründe, siehe unten.. Ich versteh Martin mit "das Gebiet zweier dauerhaft bewohnter Häuser"so dass er die Summe der beiden Grundstücke als eine landuse=residential Fläche mappen und nicht die Gebäude selbst als einzelne landuse-Flächen mappen will. Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Rechtfertigen - ein/zwei einzelne Bäcker innerhalb einer Fläche, die überwiegend zum Wohnen genutzt wird - ein/zwei Häuser innerhalb einer Fläche, die überwiegend durch die Forstwirtschaft genutzt wird eine Extrafläche, oder nicht? === Ich denke wir sind uns alle einig, wenn wir sagen "landuse=* erfasst die reale Flächennutzung vor Ort" Worüber wir hier also noch diskutieren ist, ob "vorrangig", "überwiegend" oder "bedeutsam" mit in diese Definition aufgenommen werden sollte oder nicht. Diese Attribute bestimmen aber _nicht_ die Granularität der Flächenausdehnung (Maßstab). Die 'fuzzyness', um es mit Frederiks Worten zu sagen, brauchen wir auf _jedem_ Maßstab. Egal wie klein der Flächeninhalt einer Fläche wird, ihr wird _nie_ eine 'eindeutige' Nutzung zuschreibbar sein. Es gibt immer mehrere Nutzungen, von denen aber eine oder mehrere "überwiegen". Eine Gebietsgröße, im Sinne einer Definition für die Flächenausdehnung eines landuse=* kann nicht gegeben werden, auch nicht als ///Empfehlung///. Wir werden keine quantitativen Zahlen angeben können, die definieren, dass eine Bodennutzungsfläche mindestens 1ha groß sein muss. Weiterhin nicht, wieviele Leute es braucht, die das Gebiet auf eine bestimmte Weise nutzen, bevor ein extra landuse=* gerechtfertigt erscheint: Es lässt sich weder sagen, dass, wenn das Flächenverhältnis von kleinerer zu größerer Fläche < 1/10 ist, wird die kleinere Fläche nicht erfasst, noch sagen, dass 10 Menschen, die im Forst wohnen, die Bodennutzung eines Forstes zugunsten des Wohnens ändern. noch sagen, landuse=* hat immer eine größere räumliche Ausdehnung als Gebäude Einesorts kann es durchaus Gebäude geben, die ausdehnungsmäßig viel größer sind, als die Ausdehnung eines landuse anderenorts. Wer es mathematisch exakt braucht, ermittle die durchschnittliche Größe aller Gebäudeflächen (GF) zum einen, und die aller Bodennutzungsflächen (BF) zum anderen. Wenn die Werte in etwa gleich sind, oder BF < GF, hat das nichts mit dem bisherigen Verständnis von landuse=* zu tun, aber falsch im Sinne der angestrebten Bodennutzungsdefinition wäre es nicht. === Würden diese Fälle eintreten hätten wir ein MICROmapping von landuse=*, das dann aber bitte auf ISIC-Level 4.. Das als Ziel anzustreben, verprellt alle Nutzer, die an dieser Granularität nicht interessiert sind, also sollten wir explizit ///keine Empfehlung/// zur Granularität geben. Das zeigt unsere Diskussion an sich - die Tatsache, das wir darüber diskutieren. Für den einen ist die Fläche des Bäckers oder das Waldhaus im Wald nach dem Kriterium der Bodennutzung vernachlässigbar, für den anderen nicht. Hier werden wir also nicht zusammenfinden. Stattdessen können wir die Beziehung verschieden großer Flächen der Bodennutzungen untereinander erkennen und diese Struktur gemeinsam m
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl
Am 14.09.2011 14:59, schrieb Martin Koppenhoefer: es gibt weltweit insgesamt 196 mal border in der Datenbank. Sind die alle von Dir? Nein, und das habe ich Dir schon gesagt: Die sind nicht von mir. Und /ja/, der key, der in OSM für das Taggen von Grenzen verwendet wird ist, wie in den Relationen /boundary/ und nicht border Sorry für diesen Fehler.. Also: boundary=administrative border_type=city Aber weshalb dann nicht boundary=administrative boundary_type=city ? Merken sollte man sich noch, dass place als Fläche/area /hier/ bestritten wird (verschiedene Auffassungen), im Wiki stand von Anfang an ausdruecklich, dass nodes und Flaechen sinnvoll sind. Nicht alles, was in einer Bibel steht, ist gut: http://www.bibelzitate.de/gbz.html Wie gesagt, das Wiki ist eine Karre. An den Stellen, wo sie im Dreck steckt, muss man versuchen sie herausziehen. Ein Indikator, wo sie im Dreck steckt, können stark unterschiedliche Auffassungen sein. Evtl. gibt es Teile im Wiki, die nur sehr schwachen bis gar keinen Konsens haben/hatten oder sich mittlerweile überholt haben, weil mehr Wissen da ist. Wiki, wie in Wikipedia - werden dort Dinge entdeckt, die nicht oder schlecht haltbar sind, fliegen sie auch raus und werden ersetzt.. Auch Wikipedia, so verlässlich sie an vielen Stellen ist, ist kein Heiligtum, sondern ein Vehikel, dass sich fortbewegt - hoffentlich zum "guten". Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenhaltung: Flächen und Flächen_grenzen_
Am 14.09.2011 08:52, schrieb Martin Koppenhoefer: Am 14. September 2011 00:28 schrieb Christian Müller: Am 12.09.2011 19:47, schrieb Martin Koppenhoefer: place-polygon heisst nicht, dass dieses Polygon unbedingt durch einen doppelten Way gemappt werden muss, Multipolygone rechne ich da natürlich auch dazu. Dann hätten wir theoretisch einen Konsens. Theoretisch deshalb, weil der "way" eines landuse=* geschlossen sein muss. Man korrigiere mich, wenn das nicht zwingend notwendig ist. Bisher ist es in Validatoren zumindest eine Warnung, wenn ein nicht geschlossener way mit Flächen-Tags (landuse) versehen ist. Wenn diese Warnung ignoriert werden kann, haben wir auch praktisch einen Konsens. Die Warnung kommt doch nur, wenn man die einzelnen ways taggt. Wenn die tags dort sind, wo sie hingehören (Relation) gibt es AFAIK auch keine Warnung. +1 Es ist mehr ein Editor-Ding: Wenn ich eine bestehende, basisgeometrische Fläche habe, also -- mit Flächentag (z.B. landuse) getaggter "closed way" -- .. kann ich diesen "closed way" u.a. auf folgende Weise teilen a) erzeuge n einzelne Segmente (neue ways) weise --jedem Segment-- die Flächen-Tags des Originals zu b) erzeuge ein multipolygon, addiere die n Segmente als "outer" weise --dem multipolygon-- die Flächen-Tags des Originals zu Die Funktion b) gibt es in Editoren bisher nicht - das macht MapperIn zeitraubend step-by-step. a) gibt es, liefert aber Müll, insofern man darauf aus ist, die originale Fläche zu behalten. b) wäre eine Schnittstelle zwischen Flächenerfassung auf - basisgeometrischer Grundlage (closed way) und - relationaler Grundlage (relation + outer members) outer members -> 2+ Flächengrenzen closed way -> genau eine Flächengrenze closed way == relation mit closed way als outer member (macht keiner, Spezialfall) Ein Editor könnte auch beide Fälle näher aneinander führen - und dem Mapper von vornherein diesen Zusammenhang zeigen - indem jede Fläche als multipolygon erfasst wird. Also, salopp formuliert, ich zeichne einen closed way und tagge ihn mit landuse=residential. Ergebnis ist ein closed way und ein multipolygon mit (dem tag und dem closed way als member). Der Vorteil dieses Verfahrens liegt auf der Hand: Teile ich den closed way in der Basisgeometrie, werden die neuen Segmente korrekt in der gleichen Rolle in die Relation aufgenommen, die der "closed way" hatte. So etwas funktioniert nicht, wenn _nur_ der closed way mit Flächentag existiert, dann ist a) das Ergebnis. Bitte beachten, dass nicht jeder "closed way" eine Fläche ist.. Was Fläche ist, wird in OSM durch tags auf "closed ways" bestimmt (area=yes, landuse, leisure, etc.). Idealerweise müsste mich also der Editor fragen, ob ich ein multipolygon erstellen möchte (oder es gleich tun..), wenn er erkennt, dass ich einen closed-way mit einem Flächentag tagge. In dem Fall, dass ich einen bereits vorhanden "closed way" mit Flächentag teile, sollte b) möglich sein. Will man overlapping ways vermeiden, wäre dieses Editorverhalten die Lösung. /Einen/ closed-way innerhalb einer multipolygon-Relation gäbe es nämlich immer nur solange, wie die Fläche isoliert von anderen ist. Sobald irgendeine andere Fläche, an den "closed way" grenzt, muss der "closed way" entsprechend fragmentiert werden - das multipolygon dazu wäre dann entweder schon da oder muss erstellt werden. Echte isolierte Flächen dürften seeehr selten sein (z.B. eine Enklave ohne weitere Unterteilung und ohne tiefer verschachtelte Enklaven). Overlapping ways sind eine Alternative dazu, Nachteile: - Ablehnung durch eine nicht unbedeutende Zahl an Mappern - algorithmisch aufwändigere Herstellung des Flächenbezugs - höhere Fehleranfälligkeit Overlapping ways sind in gewisser Weise das Produkt eines mangelnden Verständnisses des Bezuges zwischen Fläche und Flächengrenze, sprich des Bezuges von Flächen untereinander. Overlapping ways machen den Fokus auf eine einzelne Fläche einfach, aber erschweren den Fokus auf das Flächengefüge/-netzwerk. In Editorslang: - Bei overlapping ways wird das Flächengefüge mittels "durchklicken", bzw. "durchrotieren" ersichtlich - Bei multipolygonen selektiere ich einen way und sehe das Flächengefüge in der Relationsliste (i.e. an welchen Flächen nimmt dieser way als Flächengrenze teil) Der Vorteil von letzterem wird in Editoren dadurch zunichte gemacht, dass die Relationsliste nicht übersichtlich ist. Angenommen, ich habe einen way, der an 5 Flächen-Relationen (type=multipolygon), 12 Routen-Relationen (type=route), etc. teilnimmt - dann ist es mühsam, sich die passende Relation herauszupicken. Auch deshalb nehmen evtl. viele von multipolygon Abstand. Besserer Support für multipolygon und eine bessere Dokumentation des Flächen-Flächengrenzen-Bezugs (für alle Flächentypen, nicht nur für administrative Flä
[Talk-de] Ortsteil-Geometrien Berlin jetzt unter CC BY erhältlich
http://daten.berlin.de/datensaetze/ortsteil-geometrien-berlin Alex -- http://de.wikipedia.org/wiki/Benutzer:Alexrk2 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen - ISIC im Web
Die Wikipedia-Seite zur ISIC enthält nur die obere Ebene der ISIC,
hier gibt es mehr Infos, wenn das näher interessiert:
http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=27
Kulturelle Sachen, Erholung und Unterhaltung werden dort unter Kategorie
R geführt - sind also in diesem Standard auf der Top-Ebene von
restlicher "Industrie" unterschieden.
Für OSM würde ich, wenn man dazu "reale Flächennutzung" erfassen will,
aber nur Theater- und/oder Musikerviertel mappen - wenn sich
Kulturbetriebe in größeren Städten in einem Gebiet konzentrieren.
Das einzelne Kleinkunsttheater rechtfertigt m.E. noch nicht die
'vorrangige' Flächennutzung zu ändern. Da reicht die Erfassung auf
tieferer Ebene durch amenity=..
Wenn das Kulturviertel auch zum Wohnen 'bedeutend' genutzt wird, evtl.
landuse=residential;cultural oder
landuse=residential;arts
("Mischgebiet" im OSM Sinne)
Gruß
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen - Übersicht international gebräuchlicher Klassifikationssysteme
Eine Übersicht international gebräuchlicher Klassifikationssysteme für Industrie ist in http://en.wikipedia.org/wiki/Industry_classification zu finden. ISIC ist auf dieser Seite die einzige Klassifikation, die sowohl international ist und nicht (primär) markt-orientiert ist. ISIC gibt es seit 1948 und ist durch die begrenzte Einteilung sehr universell. Also ideal geeignet, um landuse daran anzudocken.. Eine weitere internationale Klassifikation ist der GICS Global Industry Classification Level Der hat seine Wurzeln in der Partnerschaft zweier Privatunternehmen: S&P und Morgan Stanley. Die Klassifizierung erfolgt marktorientiert. Davon würde ich pers. Abstand nehmen, aber vll findet daran ja ein anderer Mapper Gefallen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 13.09.2011 17:58, schrieb Martin Koppenhoefer: Du bist mit siedlungsgeographischen Daten nicht "falsch", genauso wie admin. Grenzen nicht "falsch" sind. Beide können in OSM koexistieren, sofern man in der Lage ist, sie auseinanderzuhalten. Wenn admin. Grenzen mit historischen oder siedlungsgeographischen, die durch die Flächennutzung bestimmt werden, vermanscht werden, dann freilich nicht. Ganz genau. Du warst es, der im Wiki bei place das Gegenteil geschrieben hat, schon vergessen? ;-) Ich habe das Zusammengemansche von place node als amtl. admin_centre border=administrative und border=landuse (i.e. Siedlungsflächengrenze) gelöst, indem ich den place node, den bestehenden best practices dieser Wiki-Seite folgend, /weg/ von einem ominösen place polygon gerückt habe. Du siehst an diesem Sachverhalt, dass sowohl als auch place in Relation zur Verwaltungsgrenze place in Relation zur Siedlungsflächengrenze steht. Der /Ortsname/ ist so unscharf, dass er durch keine Grenze eindeutig besetzt wird, weder durch die Siedlungsflächengrenze, noch durch die Verwaltungsgrenze. Denn man versteht _beides_ darunter. Warum sollte es eine Gewichtung geben, indem man place=* als Siedlungsfläche wiederverwendet? Diese Gewichtung gibt es in der Realität nicht, sie ist gar nicht quantifizierbar. Genau deshalb sollte man dafür sein, den POI-Charakter von place=* zu erhalten. Man kann festhalten: /Ein/ Ortsname steht in Bezug zu /mindestens/ einer Grenze. /Mehrere/ Ortsgrenzen, auch unscharfe, können /ein und demselben/ Ortsnamen zugeordnet sein. (Es gibt auch gleiche Ortsnamen an geografisch völlig unterschiedlichen Orten.. Das ist hier nicht gemeint) Das ich kein Einzelfall bin, der das so sieht, zeigt Dir wieder einmal, u.a., Wikipedia http://de.wikipedia.org/wiki/Ortsgrenze -> Es wird /nicht/ nur die Siedlungsflächengrenze als Ortsgrenze verstanden, /auch/, aber nicht nur. http://de.wikipedia.org/wiki/Toponomastik klärt unser Missverständnis auf Die Seite schreibt, dass im deutschen 'Ortsname' doppelt verwendet wird, - zum einen als Synonym für "Toponym" (und genau dort sehe ich place=* angesiedelt) - zum anderen ///im Speziellen/// als Name einer Siedlungsstelle (dort siehst Du place=* offenbar) Letzteres grenzt zigtausende bisherige Verwendungen von place=* aus. place ist in OSM _nicht_ nur eine Siedlungsstelle. Auch, aber eben nicht nur. place values erfassen Toponyme in Größenordnungen von Kontinenten bis runter zu Waldlichtungen. Da ist keine Systematik erkennbar, bis auf eben den Fakt, dass es Toponyme erfasst. Du kannst helfen, die Unterscheidbarkeit zu verbessern, indem Du die Siedlungsfläche (egal ob nach deiner oder meiner Lesart) nicht mit place=* vermischen würdest.. Vielleicht als type=multipolygon boundary=settlement mit /ways/ border=landuse als Mitglieder.. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse - gewerbliche Flächen
Am 13.09.2011 18:17, schrieb Martin Koppenhoefer: +1, hört sich vernünftig an. Ob es Hotels oder Restaurants (oder beides) sind, ergibt sich ja aus den POIs. man könnte übrigens auch einfach zusätzlich landuse:ISIC=H taggen (wenn es Sinn machen sollte, diese ISIC als Grundlage anzuerkennen). +1 Dann aber wirklich nur zusätzlich, sonst lassen sich ohne den Standard die Daten nicht mehr interpretieren. Einen Standard zu nutzen, ist besser, als sich von ihn abhängig zu machen.. Wenn für eine Fläche möglich, kann so die Einordnung in weitere Standards angeben werden, ohne "human readable" kaputt zu machen.. landuse=commercial commercial=hospitality landuse:ISIC=H landuse:SIC=... SIC ist ein Pendant zur ISIC (UNO / EU). Schätzungsweise ist ISIC ein superset von SIC (keine Garantie auf die Aussage). http://en.wikipedia.org/wiki/Standard_Industrial_Classification Ich würde aber die SIC nicht als Basis für eine Kompatibilitätssuche zu landuse=* nutzen, da sie wesentlich strukturierter/umfassender zu sein scheint, und zudem kein internationaler Standard ist. Das ist was für später, wenn die Datenlage in OSM so gut ist, dass sich Mapper langweilen. 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 13.09.2011 18:13, schrieb Martin Koppenhoefer: Ich verweise nochmals darauf, dass border=administrative in OSM bereits für jede Nation ausdifferenziert wird, d.h. border=administrative entsprechen ab admin_level 3 den innernationalen Verwaltungsgrenzen. Die kleinste Einheit bei den Verwaltungsgrenzen in D ist und bleibt die Flurstücksgrenze. Das OSM das bisher nicht so abbildet ist ein (ohne größeren Aufwand) lösbares Problem. hast Du da eine Quelle dafür? http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#admin_level (Ausdifferenzierung in Abh. der Administration) http://de.wikipedia.org/wiki/Flurstücksgrenze (Feststellung im Verwaltungsverfahren der Behörden -> Verwaltungsgrenze) http://www.gll.niedersachsen.de/live/live.php?navigation_id=10669&article_id=50951&_psmand=34 "Verwaltungsgrenzen (Administrative Grenzen des Liegenschaftskatasters)" "Diese Administrativen Grenzen des Liegenschaftskatasters bestehend aus Flur-, Gemarkungs-, Gemeinde- und Landkreisgrenzen [...]" http://www.landesvermessung.sachsen.de/inhalt/produkte/lika/alk/alk_detail.html (Foliendefinitionen betrachten, Gemarkungs- und Flurgrenzen sind keine _politischen_ Grenzen, Verwaltungsgrenzen hingegen, sprich _administrative_ Grenzen, aber schon) http://de.wikipedia.org/wiki/Kataster#Aufbau_eines_Katasters "Aufgrund der chronologischen Fortschreibung des immerwährend aufzubewahrenden Katasters können bei Bedarf Grenz- und Vermessungspunkte örtlich aufgesucht und fehlende Vermarkungen oder Sicherungen wiederhergestellt werden. Die Verbindung zweier Grenzpunkte bildet eine Flurstücksgrenze." Damit wäre, wenn GPS genau genug arbeiten würde, die Erfassung der Flurstücksgrenze in OSM vor Ort durchführbar. Weil Vermessungspunkte vor Ort wiederspiegeln, was im Kataster steht und vice versa. Wenn man erkennen könnte, welche Grenzpunkte an einer Gemarkungsgrenze, bzw. Wohngebietsgrenze teilnehmen, könnten man damit /praktisch/ auch amtl. Grenzen /in/ der Realität exakt erfassen - nur lassen sich eben mit unseren GPS-Receivern keine Grenzsteine vermessen.. Evtl. taugt aber ein gut aufgelöstes Luftbild im Zshg. mit Information, die man vor Ort gesammelt hat.. PS: Bitte nicht immer border schreiben, es heisst boundary. Ich spreche von der basisgeometrischen Grenze, dem mit 'border=*' getaggten way, der in OSM Grundlage von boundary-Relationen ist. http://en.wikipedia.org/wiki/Border "borders define /geographic/ boundaries" Es gibt auch "boundaries", die nicht-geografisch sind, die betrachten wir hier aber nicht. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 14.09.2011 03:14, schrieb Christian Müller: Am 13.09.2011 17:14, schrieb Martin Koppenhoefer: ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor. welchen Sinn soll das haben? so kommen wir nicht weiter.. Es ist ein Alleinstellungsmerkmal und erhöht die Auffindbarkeit solcher Besonderheiten. Wenn Du z.B, eine OSM-Garminkarte verwendest in der aus Platzgründen keine Häuser dargestellt werden siehst Du an der Stelle des Hauses nur Wald, ohne eigenem landuse ist so ein Haus dann auf der Karte unauffindbar. Und nein, ich sehe dass nicht als Mappen für den Renderer an sondern ein Mappen der Realität zur besseren Nutzubarkeit der Daten. Die Granularität von landuse=* ist in OSM einfach nicht die von building=* und wenn sie das wäre, wäre landuse=* für die meisten Datennutzer useless=* Ich versteh Martin mit "das Gebiet zweier dauerhaft bewohnter Häuser"so dass er die Summe der beiden Grundstücke als eine landuse=residential Fläche mappen und nicht die Gebäude selbst als einzelne landuse-Flächen mappen will. Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das weder fordern noch pauschal ausschließen wollen. Ja, können sie ja machen - haben wir die Ressourcen? Macht das in OSM Sinn? In Bezug auf Einzelhäuser im Wald ist das nicht wirklich ein Argument Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur Bodennutzung bleiben. Bei so einer gravierende Nutzungsänderung wie hier die kleine bewohnte Fläche in einem riesigen unbesiedelten Gebiet sollte man schon differenzieren... Beim Taggen von landuse=* über seine Grenzen, macht aber auch ein amtlicher Datenimport keine Probleme. Man legt das einfach über das, was in OSM da ist, taggt die ways des Imports als border=administrative source=official und erstellt Multipolygone mit type=multipolygon landuse=xyz official_key1=* official_key2=* official_key3=* source=official Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter mappen für eine OSM-Definition von landuse=* geeignet ist. Natürlich gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht "strikt" gestalten. "'vorrangige', reale Flächennutzung" Du musst auch mal überlegen, welche Konsquenzen das hätte: landuse=* würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf allen anderen gibt's ein verrauschtes "noise" bitmap. Weiterhin hatte sich jemand über die Fülle der Daten in Frankreich durch den Import aufgeregt. Wenn die Flächennutzung auf der Granularitätsebene von Baufenstern (oder nahe diesen) arbeitet, hätten wir zum Schluss 25*Anzahl der building Polygone an Daten in der Stadt (für jedes Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten ringsum). Das ist für landuse=*, useless=*.. Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag aufmachen, um landuse micromapping zu betreiben.. Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu senken.. Je kleiner man diese Einheiten macht (bis zu Flächen, die keine Straßen mehr beinhalten, einzelne Blumenbeete meine ich damit nicht), um so einfacher wird es für die folgenden Mapper, dort weiterzuarbeiten. Irrglaube, denn Du hast dann statt Struktur, "rohe" Komplexität abgebildet. brute-force, statt elegance. Es gibt keinen Bezug deiner Mini-Flächen untereinander. Man sieht sprichwörtlich den "Wald vor lauter Bäumen" nicht mehr. Wenn deine Mini-Einheit was bringen soll, dann nur über die Multipolygon-Methode, mittels derer diese Mini-Flächen wieder zu groben, fassbaren Flächen gruppiert werden können, bis zu dem Punkt, wo man wieder von 'vorrangiger', realer Flächennutzung sprechen kann, was landuse=* jetzt ist. woher kommt eigentlich dieser Wunsch, die Realität in diesem Punkt nicht (in unserem Rahmen) möglichst genau abzubilden, sondern grobe unfragmentierte Gebiete haben zu wollen? Kann man das nicht durch Datenverarbeitung hinterher machen, wenn man gerne vereinfachte Geometrien haben will? Nein, aus dem gleichen Grund, aus dem Du die Erfassung der Siedlungsfläche (nach deiner Definition) "explizit" wünschst. Um es mal auf dein Beispiel mit der dt. Staatsgrenze zu übertragen: Die ist auch explizit erfasst, obwohl man sie aus der Summe aller nächsttieferen Grenzen berechnen kann. Und die nächsttieferen Grenzen wiederum aus den nächsttieferen.. ad absurdum Der Grund weshalb man das nicht berechnet, ist, neben dem Rechenaufwand, dass wir in OSM selbst die Information der Realität
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl
Am 14. September 2011 00:51 schrieb Christian Müller : > Am 13.09.2011 13:20, schrieb Martin Koppenhoefer: >> Am 13. September 2011 07:01 schrieb Rainer Kluge: > +1 in allen Punkten. Kleine Korrektur, für Grenzen wird > - auf dem /way/ border=* es gibt weltweit insgesamt 196 mal border in der Datenbank. Sind die alle von Dir? > - in der /relation/ boundary=* gem. Taginfo gibt es border_type 43728 mal. Die Werte dafuer sind city (15073) (bei insgesamt 2 cities in der db), county, town, village etc. und gem. Wiki ist dieser tag parallel zu place zu nutzen. > Merken sollte man sich noch, dass > > place als Fläche/area /hier/ bestritten wird (verschiedene Auffassungen), im Wiki stand von Anfang an ausdruecklich, dass nodes und Flaechen sinnvoll sind. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Moin, Christian Müller schrieb: Am 13.09.2011 17:14, schrieb Martin Koppenhoefer: ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor. welchen Sinn soll das haben? so kommen wir nicht weiter.. Seit wann muss ein "Hobby" einen Sinn haben? ;-) Die Granularität von landuse=* ist in OSM einfach nicht die von building=* und wenn sie das wäre, wäre landuse=* für die meisten Datennutzer useless=* Ich glaube kaum, dass Martin ein landuse-Polygon in den Grenzen des buildings 'malt'. Und auf dem Wohn-Grundstück finden sich evtl. Bäume - aber da haben die Forstarbeiter bestimmt keinen Zugriff drauf! Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das weder fordern noch pauschal ausschließen wollen. Ja, können sie ja machen - haben wir die Ressourcen? Macht das in OSM Sinn? Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur Bodennutzung bleiben. Schon wieder diese Sinn-Frage ... 'Wir' haben auch kaum übergreifend im ländlichen Raum die Resourcen, überhaupt landuses zu erfassen - sollen 'wir' das deshalb von vornherein lassen? Äußerst vorrangig besteht die Erdoberfläche aus Wasser - das spart unheimlich Resourcen! Noch(!) besteht Deutschland 'vorrangig' aus Landwirtschaftsfläche ... In meinem Dorf überwiegt eindeutig die residential-Nutzung - muss ich deshalb die trotzdem das Gesamterscheinungsbild prägenden Vollerwerbsbauernhöfe unterschlagen? Auf dem Grundstück im Wald steht definitiv kein 'forrest' - aber ich darf diese Besonderheit der Einzel-Streu-Besiedelung einer Gegend nicht erfassen, weil es jemandem nicht genehm ist? Ich bin hier die Resource vor Ort - und da nehme ich mir das Recht heraus, zu entscheiden, wofür ich diese Resource verschwende! ;-) Und ja, es macht Sinn für mich, wenn ich auf meiner kleinen großformatigen Karte das private Grundstück vom öffentlich zugänglichen Wald unterscheiden möchte. Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter mappen für eine OSM-Definition von landuse=* geeignet ist. Natürlich gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht "strikt" gestalten. "'vorrangige', reale Flächennutzung" Das ist durchaus eine sinnvolle, nicht-strikte Definition. Aber warum erwartest Du dann, das man sich _strikt_ an eine nicht näher angegebene Größenordnung hält? Wo muss man diese Größenordnung ziehen? Du musst auch mal überlegen, welche Konsquenzen das hätte: landuse=* würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf allen anderen gibt's ein verrauschtes "noise" bitmap. Nein, dass wären 'falsche' Renderregeln. Die Granularität bestimmt die Breite der definierten landuses. (Leider wird/wurde bei OSM oft zu schnell in die Breite gegangen, statt zu staffeln. :-( ) Erstens endet die landuse-Granularität z. Z. spätestens an der Grundstücksgrenze - den so sinnlosen landuse=grass mal außen vorgelassen - und gleiche Nutzungen nebeneinander ergeben eine gemeinsame Fläche, im Zweifelsfall den von Martin angesprochenen Block (zwischen Verkehrswegen) - den man ja nicht auf Krampf unterteilen muss. Aber setzt sich der landuse=road durch, ist dort dann sowieso Schluss, falls sich der Schwebe-Ansatz nicht durchsetzt. Und zweitens werden ab einem gewissen Zoomlevel landuses rendermäßig zusammengefasst (landwirtschaftlich, bebaut/besiedelt) sowie kleine Flächen weggelassen. Und wenn dort kein Pixel für den Verkehrsweg mehr bleibt (=> weggelassen) ergibt sich auch dort grafisch eine durchgehende Fläche. Wenn die Flächennutzung auf der Granularitätsebene von Baufenstern (oder nahe diesen) arbeitet, hätten wir zum Schluss 25*Anzahl der building Polygone an Daten in der Stadt (für jedes Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten ringsum). Hier hätte ich gerne Belege für (diese Übertreibung) ... Das ist für landuse=*, useless=*.. Allerdings - aber in meinen Augen eben auch nicht zwangsläufig zu befürchten. Insbesondere nicht, wenn man sinnvoll staffeln würde, statt weiter nur (oft unüberlegt) in die Breite zu gehen. Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag aufmachen, um landuse micromapping zu betreiben.. Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu senken. Sehe ich - mittlerweile - anders. Multipolygone oder riesige Flächen schrecken da eher ab, nach meiner bisherigen Erfahrung. diese Einheiten macht (bis zu Flächen, die keine Straßen mehr beinhalten, einzelne Blumenbeete meine ich damit nicht), um so einfacher wird es für die folgen
Re: [Talk-de] Nominatim
Am 13.09.2011 21:27, schrieb Dimitri Junker: Hallo, Das stand doch genau da?!1elf Ups, da sah für mich nichts nach Ortsname aus, sorry. Erstes wird gefunden, zweite nicht. Ich habe einen Bugreport erstellt Danke, hätte ich jetzt auch gemacht. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OT: Petition gegen Vorratsdatenspeicherung
Hallo zusammen, das ist OffTopic, aber ich denke den Meisten die bei OpenStreetMap mitmachen ist klar, was man mit gesammelten Daten so alles machen kann. Stand jetzt benötigt die Petition bis heute Nacht 14.09.2011 24:00 Uhr noch rund 5.500 Mitzeichner, damit Kai-Uwe Steffens die Petition persönlich im Bundestag vortragen kann. Die allgemeine Zeichnungsfrist endet am 06.10.2011 http://zeichnemit.de/ Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
