wie soll man Ortschaften einzeichnen

Hallo,
Ich möchte gerne die Umrisse von Orten aus Landsat abzeichnen ,weiß aber nicht wie ich sie bezeichnen soll und welche Ebene die dann erhalten ,damit die Orte auf dem Navi nicht so sehr stark eingezeichnet sind und man noch Wege erkennt.
Viele Grüße RufusB

Könnte man das nicht nicht mit landuse residential
machen ??

Als Layer irgendeine Ebene tief unten, sie sich nicht mit den andern Wegen beißt. Z.b. -3

Oder ??

Nicht immer ist der ganze ort residential, aber wenn die lanuses korrekt vergeben sind sollte das schon eine schöne Darstellung ergeben.

Ansonsten kann man die Ausdehnung eines Ortes auch mit place=Art_des_Ortes angeben: http://wiki.openstreetmap.org/wiki/DE:Key:place

Mit der Darstellung in Navis kenne ich mich aber nicht aus.

Die Umrisse eines Ortes als place-Polygon einzuzeichnen ist sicherlich in Ordnung, mit guter Chance wird das allerdings weder beim Renderer noch auf dem Navi zu sehen sein.

Wenn das bisher leeres Land ist, dann ist landuse=residential auch nicht schlecht. Es ist zwar nicvh 100%-ig richtig, da es in den Orten ja auch noch andere Nutzung gibt, aber es ist besser als nichts.

Was kompletter Pfusch ist, ist der Vorschlag mit dem layer-Tag. Denn das soll ja ein physikalisches Oben bzw. Unten ausdruecken, und die Ortschaften sind ja nicht irgendwo im Boden vergraben, sonst warenen sie auf den Bildern ja nicht zu sehen.

Nebenbei gefragt: Sind fuer diesen Zweck die Landsat-Bilder besser geeignet als die Yahoo-Bilder in niedriger Aufloesung? In meiner Gegend reichen die hochaufloesenden Yahoo-Bilder naemlich leider nicht weit, und das der Rest zum Grossteil einfach nur weisse Flaeche ist, stoert doch ein wenig

Gruss
Torsten

Also das ist wirklich kompletter Quatsch.
Die Layer werden doch nur benutzt, um Ebenen darzustellen (Brücke über Straße, Bach in Röhre unter Straße etc.).
Die mit landuse bezeichneten “Wohnbereiche” liegen nun wirklich nicht drei oder vier Ebenen in der Tiefe der Erde verborgen oder muss man per Bergwerksschacht dorthin kommen?

Ich vergebe die Layer unter der Erde, da ansonten JOSM rumeckert… “Wege ohne Verknüpfung” Seit dem ich die Wege die keine Wege sind mit einem Layer (unter der Erde vergebe sie existieren ja physisch nicht wirklich sondern sind nur logisch vorhande) gibts keine Konflikte. Ich habe noch keine Grenze als Weg in der Landschaft gesehen, geschweige denn ist jede Grenze als Schneise in die Landschaft gehauen.
Ein Layer ist (für mich) bis jetzt eine logische (und keine physische) Ebene. (Is in der EDV ja auch so…).
In JOSM exsistieren ja auch zig Layer logisch nebeneinander die man nach belieben veschieben kann.

JOSM (bzw. der Validator von JOSM) unterscheidet nicht zwischen einem Gebiet und einem Weg. Fuer ihn sind alles wege, deshalb meckert er rum. Das muss nicht zwangslaeufig bedeuten, dass es falsch ist was man gemacht hat. Der Validator ist da halt noch nicht so intelligent was das betrifft. Wegen dem musst du das Layer Tag also nicht vergeben.

Das Problem ist, dass wenn du ein Layertag setzt, du bei allem was du machst immer schauen musst, dass sich die Layer nicht beissen, deshalb sollte das Layer nur dann verwendet werden wenn die Renderer Aufgrund des Objekttyps nicht auch von alleine entscheiden koennen was sie darunter und was darueber anzeigen.

Und gerade weil diese Flaeche, wie du ja schon gesagt hast, nicht phzsisch sondern nur logisch existiert, kann der Renderer wunderbar selbst entscheiden wie er sie darstellen soll, denn sie kommt physisch sowieso keinem in die Quere.

Genau, und ebensowenig hast du bisher eine Grenze als Steinwand in 5 Meter tiefe gesehen und deswegen wird in der Regel auch kein layer-tag vergeben. Denn kein Layer bedeutet, dass der Renderer es so darstellen kann wie er es als am logischsten empfindet. Einer logischen Grenze ist es egal wo die Strassen, Tunnel und Haeuser liegen, aber wenn du layer=-3 setzt machst du es quasi zu einer physischen Grenze, die z.B. mit Tunnels die auch auf layer-3 liegen kollidieren kann. Ohne Layer ist keine Kollision moeglich.

Also Layer werden wirklich nur verwendet um zu sagen “Diese Strasse liegt in Wirklichkeit tiefer als die andere”. Eine Ortsgrenze liegt in Wirklichkeit aber nicht tiefer oder hoeher als irgendetwas anderes, sie liegt quasi ueber allem als mehr oder weniger transparentes layer ohne genaue zuordnung, so dass renderer sie nach belieben anzeigen koennen.

Was hat welche EDV mit den layer-tags in OSM zu tun?
Diese Schlussfolgerung kann ich nicht nachvollziehen und ist - wie einige schon angemerkt haben - absoluter Murks.
Halte Dich an die Regeln und verunsichere nicht noch zusätzlich die OSM-Gemeinde mit dieser “Regelauslegung”.
Nimm einfach mal einen guten Ratschlag an!

Und wieso meckerte dann der Validator von JOSM ??

Ich bin mit Layer Null angefangen und da hatte er da rumgemeckert. (Überscheidende Wege ohne gemeinsamen Punkt) Wo ich den Layer geändert hatte, hat er nicht gemeckert.
Da habe ich mir gedacht, daß es wohl nur logische Eben sein muss… Bei Brücken muss man ja auch den Layer wechseln. (wenn sich Wege ohne gemeinsame Punkt überschneiden)
Wo kann man den nu verbindlich nachlesen was ein Layer in OSM ist. Hast du einen Link?
Zum Layer-konzept hab ich bisher nix gefunden.
Im Wiki steht "Gibt die Höhenstaffelung verschiedener Wege oder einer Fläche an (0 = Grundhöhe, -1 = unter Grundhöhe, 1 = über Grundhöhe; Brücke in ebener Straße über Bach: layer=1). "
Ein logische Grenze hat keine Höhe… ist ja nur virtuell., und es gibt keinen gemeinsamen Punkt wenn sich eine Grenze mit einem Weg überschneidet.
Kann man da nicht das Wiki etwas deutlicher machen?

Weil der Validator auch nur so gut ist, wie der Mensch, der ihn programmiert hat.

http://wiki.openstreetmap.org/wiki/Layer
http://wiki.openstreetmap.org/wiki/DE:Key:layer

“Grundhöhe” sollte als “Ausgangsebene” verstanden werden. Alles was “ueber” dieser Ebene verlaeuft hat eine Layer “+x” und alles “darunter” einen Layer “-x”. Meist kommt man mit +/-1 aus. Bei komplexeren Ueberschneidungen (Autobahnkreuze usw.) braucht man halt entsprechend mehr Ebenen um zu beschreiben, was “uebereinander” und was “untereinander” verlaeuft.

Danke, das war jetzt eine fundierte Rückmeldung.
Jetzt hab es sogar ich kapiert.
“Landuse-Wege” und virtuelle Grenzen haben gar kein Layer-tag. (Das war mir bisher nicht klar)
Ich dachte (mein Fehler), daß jeder Weg einen logische Ebene gebraucht.
Werde “meine” Daten daraufhin überarbeiten.

Aber Rückmeldung wie “totaler Quatsch…” und so sind nicht wirklich hilfreich, und erzeugen nur Unmut.

Danke PHerison für die Klarstellung und Begründung in “vernünftigen Ton”.

Nur wer getreten wird, erfährt den Schmerz …
Aber auch die Vorposter haben Dir das Problem der Layeranwendung doch schon recht deutlich dargestellt. Also beklag Dich nicht und freu Dich über die jetzt gewonnenen Erkenntnisse.

Ich dachte bisher immer ,das die layer etwas mit der Darstellung auf der karte zu tun haben aber scheinbar ist das nicht der Fall ,aber wie stelle ich dann eine Gartenanlage innerhalb eines Ortes dar ? Wenn beide den gleichen Layer haben wird die Gartenanlage auf dem Navi übermalt .Also werde ich die Orte nicht abzeichnen und lieber zusammenhängende Wohngebiete innerhalb von Orten mit landuse residential taggen
Gruß RufusB

solange kein physischer Weg unter oder über der Gartenanlage liegt, musst du gar kein Layer vergeben. Erst wenn z.B. die Gartenanlage künstlich erhöht über einem Parkplatz gebaut wäre, müsstest du ihr ein Layer=1 verpassen.

Wenn sie auf dem Navi übermalt wird obwohl sie keinen Layer hat und nichts physisches über ihr liegt, dann hat entweder jemand für das residantial-tag einen Layer vergeben (was ja falsch wäre) oder der Renderer hat einen Fehler. Das wiederum wäre aber das Problem das Renderers. Denn vergiss nie: Wir mappen nicht für die Renderer!

Wenn du uns mal einen Link mit dem Fehler postest, können wir dir evtl. sagen ob da jemand was falsch getaggt hat.

Ich habe gerade mal geschaut und der Ort hatte einen Layer-2 habe das mal rausgelöscht mal schauen wie das nächstes mal angezeigt wird
Gruß RufusB

Wenn zwei Polygone eine gemeinsame Schnittmenge haben, dann hat man da ein Problem gebaut.

Meiner Meinung nach ist das ein Fehler, weil wir bei OSM ja allgemein nicht mit ueberlappen Elementen arbeiten. (Wir zeichnen ja auch nicht eine Linie mit highway=secondary und legen darueber eine zweite Linie mit maxspeed=50 dort wie die Strasse durch einen Ort fuehrt, sondern wie zeichnen getrennte Linien ausserhalb und innerhalb des Ortes und tragen beide Tags an der selben Linie ein.)

Vielleicht wird nicht so ganz klar, was ich sagen will. Ich probiere es noch mal so: Bei der einen Flaeche sagst du, dass es sich um eine Gartenanlage handelt und sonst nichts. Bei der anderen Flaeche sagts du, dass es sich um eine Ortschaft handelt und sonst nichts. Ein Renderer hat nun das Problem, dass er fuer die Schnittmenge wiederspruechliche Aussagen hat: Ist da nun eine Ortschaft oder ist da nun eine Gartenanlage.
Um das (nach meinen Verstaendniss) korrekt einzutragen, musst du der Flaeche von der Gartenanlage beide Attribute geben, sowohl Ortschaft als auch Gartenanalage. Und der Flaeche des Ortes ausserhalb der Gartenanlage halt nur das eine Attribut.

Andere Leute sehen das nicht so streng und meinen, dass in solchen Faelle die Attribute aller umhuellenden Polygone gleichzeitg gelten sollen. Davon halte ich nichts, weil es a) nicht unserem Vorgehen bei den Strassen entspricht und b) ziemlich schnell sehr unuebersichtlich wird.

Als weiterer Punkt bleibt noch die Sache mit der Flaeche Ortschaft abe rnicht Gartenanlage (ich vermute mal, dass die Gartenanlage mitten im Ort, d.h. nicht am Rand liegt.) Fuer Flaechen mit “Loch” gibt es im Prinzip zwei Ansaetze:

1. Man trennt die Flaeche auf, so dass man zwei Flaechen ohne “Loch” erhaelt. Das ist zwar nicht sonderlich trickreich, funktioniert aber ohne Probleme. Wenn man will, kann man noch eine Relation spendieren, die ausdrueckt, dass die beiden Flaechen Teile von einem einzigen Objekt sind. Auch da verweise ich aber wieder auf die Strassen, wo wir sowas auch nicht haben.
2. Gibt es die multipolygon-Relation, bei der man fuer eine Flaeche eine aeussere und eine innere Kannte angeben kann. Ich persoenlich halte von dieser Loesung allerdings nichts. Die entstehenden Konstrukte werden zu kompliziert (man kann sowas dann ja auch schachteln), so dass die meisten Mapper sie nicht mehr verstehen und auch die verschiedenen Auswerteprogramme ziemliche Probleme damit haben. So kann der Mapnik-Renderer sowas nur darstellen, wenn man den Randpolygonen die Richtungen in einer bestimmten Weise waehlt. Und wenn dein Navi ein Garmin-Geraet ist, dann wird das da mit der Darstellung der multipolygon-Relationen auf absehbarer Zeit auch nichts werden.

Auf alle Faelle gilt aber weiterhin: Das layer-Tag ist dazu da, um den physikalischen Zusammenhang zwischen den Objekte zu beschreiben, und nicht, um die Anzeige beim Renderer oder auf dem Navi zu steuern.

Gruss
Torsten

Also ich male Flächen innerhalb von Ortschaften (z.B. Parks, Friedhöfe, Industriegebiete, Parkplätze etc.) gandenlos über die alles umschliessende residential-Fläche drüber. Und das wird ordentlich gerendert und der Validator meldet mir keine Konflikte.

Ich kann doch nicht in einer Ortschaft jede kleine Fläche (womöglich per Relation) aus der residential-Fläche ausklinken. Wie lange soll man denn da an einer Ortschaft mappen? Vor allem reduziert sich die Anzahl der Mapper drastisch, die in der Lage sind sowas korrekt per Relation zu mappen. Dann haben wir hier in der Region in 10 Jahren noch weisse Flecken, wo eigentlich Ortschaften sein sollten.

Ein Renderer kann doch wohl erkennen, dass wenn ich eine Fläche innerhalb einer anderen Fläche male, dass dann die innere Fläche Vorrang hat. Das lässt sich auch problemlos mehrfach verschachteln. Wirkliche Konflikte und Mehrdeutigkeiten ergeben sich doch nur dann, wenn Flächen nur teilweise überlappen. Nur in diesem Fall weiss man nicht, welche Tags im Überlappungsbereich gelten. Sowas vermeide ich.

Warum soll ich von Hand mühsam mappen, was ein Renderer problemlos erkennen kann?

Detlef

Ich denke auch, dass dies ein gangbarer Weg ist, obwohl ich doch gern Multipolygone bevorzuge.
Aber jeder nach seiner Facon … und der Validator hat in beiden Fällen nichts zu meckern.

Die residential-Fläche für den ganzen Ort ist ja nur ein Behelfskonstrukt, damit man bei leeren Ortschaften auch was sieht. Eigentlich sollte das nur dort verwendet werden, wo Wohngebiete sind. Und wenn man das so macht, muss man da nichts “ausklinken”. Dann sind die Flächen nämlich alle überschneidungsfrei nebeneinander.

Übliches Argument: Weil wir kein Rendering-only-Projekt sind, sondern auch beliebige andere Dinge erlauben wollen. Etwa statistische Auswertungen (“wie viel Prozent der Fläche im Ort sind Industriegebiet”), Heuristiken für Navigationsgeräte (“befinde ich mich in einem Wohngebiet?” => “oh, dann gibts hier vermutlich viele parkende Autos und andere Hindernisse”) und so weiter.

Was ein Renderer erkennen kann, kann auch ein Statistik-Programm erkennen.

Ausserdem könnte man jederzeit vollautomatisch alle übereinanderliegenden Flächen in Multipolygon-Konstrukte umwandeln, wenn das gewünschte ist. Darüber sollen sich diejenigen Gedanken machen, die sich um die OSM Datenstrukturen und um die Auswertung kümmern. Ich werde mir als gemeiner Feld-, Wald- und Wiesen-Mapper da jedenfalls keinen Wolf mappen.

Detlef