Oh, das war nicht beabsichtigt. Korrektur:
Die Länge der Antworten ist leider beschränkt, viel länger geht es leider nicht.
Viele Grüße
Michael
Das klingt schon besser! Rechtschreibung: 2x “Wohgebiet”.
Es wird suggeriert dass landuse=highway empfohlen ist während area:highway noch Proposal ist. Beide sind aber nur Proposals. In der Nutzung liegt area:highway stark vorn. Area:highway umfasst aber nur Straßenteile, dagegen landuse=highway den gesamten Bereich inkl. Graben. Ich würde schreiben: “Die Straßenfläche kann mit einem zukünftigen Flächentagging erfasst werden.”
Ich meinte auch landuse=road, hab das nur zu der späten Stunde verwechselt.
Schön zu lesen, dass der Tag area:highway schon so oft verwendet wird.
Man brauch jetzt “nur” eine Visualisierung in Mapnik auf dem höchsten Zoom level.
Grüße,
Marek
Und was wäre daran so abartig?
Ich verklebe zwar keine Straßen mehr mit der Landnutzung, aber eher weil ich auf landuse=road warte, als dass mich die Gegenargumente überzeugt hätten.
Meine andere Meinung liegt wohl vor allem daran, dass für mich ein Acker etwas anderes ist als das abstrakte landuse, welches nur die überwiegende Nutzung beschreibt.
Die tatsächliche Landnutzung wie leisure- und amenity-Flächen sind konkreter und haben eine exakte Ausdehnung.
Deshalb würde ich bei
das Acker durch Ackerland ersetzen. Das “bis zur Fahrbahnmitte” klingt für mich auch negativ, denn die Gebiete reichen beim Verkleben bis Straße, und die wird im Moment als abstrakte Linie an der Position der Fahrbahnmitte eingezeichnet.
“Verkleben” klingt für mich auch negativ, für mich ist es ausrichten.
Die erste Frage wäre ja eigentlich, wo treffen sich die Grenze von Wohngebiet und Ackerland?
a) auf der Seite des Wohngebiets
b) auf der Seite des Ackerlands
c) genau in der Mitte
d) sie haben keine gemeinsame Grenze, die Grenzen liegen so dicht wie möglich an dem Straßen-way
d) sie haben keine gemeinsame Grenze, die einzelnen Grenzen liegen weiter auseinander, weil ein landuse=road dazwischen gehört
Für mich wäre es bei landuse (aber nicht bei leisure, amenity etc !) die Mitte. Dabei finde ich c) besser als d) mit drei separaten Linien.
Am besten fände ich eine Ausrichten der Grenze an den Straßen-Nodes ohne eine Verkleben, d.h. separate Nodes. Das ginge dann Richtung Gehrkes Layer.
Wie gesagt, ich verklebe nichts mehr, aber bei den Antwortmöglichkeiten finde ich mich auch noch nicht wieder. Am ehesten passt noch
,
aber “Landnutzungsflächen sollte dort aufhören, wo sie in vor Ort aufhören” passt für mich nicht, weil landuse für mich abstrakter ist und area:highway sollte nicht mit landuse verklebt werden.
Also in etwa:
Zwischen das Wohngebiet und das Ackerland wird eine Landnutzungsfläche für die Straße (landuse=highway) eingetragen Die genauen Grenzen werden noch das kommende landuse=highway festgelegt
Gruß
Daniel
Hm. Ihr erwischt mich eiskalt 
Bis etwa vor zehn Tagen war ich tatsächlich noch Landuse-an-Straßen-Ankleber. Und zwar von der Hardcore-Sorte: mit Multipolygonen. Ich fand es elegant, jede benötigte Linie, ob landuse-Grenze oder highway, nur ein einziges Mal in die Karte zu zeichnen und dreifach zu nutzen.
Ich finde es immer noch elegant. Eine Karte abstrahiert nun einmal.
Gegen die exzessive Multipolygonie+Ankleben spricht aber ganz einfach, daß dazu jeder Straßenkilometer in etliche Segmente geteilt werden muß (nämlich immer, wenn rechts oder links der landuse wechselt), was einer Wanderwegrelation von 200 km, die das Pech hat, so eine Straße zu benutzen, schnell Tausende von Elementen beschert. Wenn man nicht den Relationseditor in JOSM nutzt, wird es wohl auch sehr schnell unübersichtlich (und auch da wird es, in der Liste habe ich irnkwann zwölf Multipolygone untereinander, die alle „Wiese“ heißen, solange ich nicht alle Einzelwiesen pro Kilometer in eine einzige Relation nehme).
Gegen die Shared-Nodes-Variante habe ich zunächst mal das Argument, das mich auch so schnell zu Multipolygonen gebracht hat: die bessere Editierbarkeit. Nehmen wir an, ein Track wird im wahrsten Sinn des Wortes upgegradet, von 3 auf 1. In JOSM ist es zwar kein Problem, aus drei übereinanderliegenden Linien die gewünschte zu selektieren, aber was machen die iD-Kollegen? Ich weiß gar nicht, wie es da geht, nie ausprobiert. Mit der Multipolygonlösung hätten die dagegen kein Problem, als selektierbares Element ist ja nur der highway in der Datenbank, der Rest definiert sich über inner und outer.
Ins Grübeln über das Ankleben kam ich allerdings, als ich eine Wiese in eine sehr spitze Abzweigung reinmultipolygonisiert habe. Mit dem Ergebnis, daß Mapnik die Wiese mindestens 10 Meter länger findet als Reality. Hm. Nicht schön.
Ich mappe viel in North Yorkshire. Da sind die Straßen links und rechts von Feldmauern eingefaßt, die das Weideland umgeben. Erleichtert die Entscheidung, weil da natürlich die landuses an die barrier=wall angeklebt werden und nicht an die Straßen. Aber wieso sollte dann die Abwesenheit von Mauern hier gleich das Mapping ändern, abgesehen davon, daß halt die Mauern nicht drin sind?
Heute mache ich es so:
-
Unterschiedliche Landuses, die wirklich unmittelbar aneinandergrenzen (kein Brachland dazwischen), bekommen shared nodes. Also beispielsweise meadow/forest oder meadow/farmland, aber auch residential/farmland.
-
Highways, die erkennbar über ein landuse führen (ein Feldweg über eine Wiese), wo man sich also beim Drüberlaufen vorstellt, die Wiese ginge unter einem durch, mappe ich einfach in das landuse rein, ohne Lücken. Ist ja auch nur eine einfache Linie.
-
Bei Highways, die erkennbar zwischen landuses hindurchführen, wo man sich also beim Drüberlaufen vorstellt, die Wiese höre links und rechts von der Straße jeweils auf, wird das landuse nach Luftbild gemappt. Also mit Abstand zur Highway-Linie. Ackerland hört da auf, wo auch der Pflug des Bauern aufhört, der Grasstreifen zwischen Straße und Acker bleibt weiß (kann natürlich auch landuse=grass bekommen). Nach Möglichkeit versuche ich die Linien parallel zum Highway zu führen (siehe dazu mein Thread von letzter Woche), um ein elegantes Kartenbild zu bewahren. Diese „grob ausgeschnittenen“ Lücken sehen einfach grauenhaft aus. Wenn zwischen highway=unclassified und landuse=meadow an einer Stelle noch etwas Gehölz steht und deshalb der Abstand steigt, dann mappe ich halt noch ein schmales natural=wood dazwischen (das dann mit der Wiese shared nodes hat, zum Highway aber Abstand hält).
Soweit meine 2 Cent. Und jetzt weitermachen, happy mapping!
Ich finde OSM ist eine Datenbank.
Was der geneigte Kartenbastler daraus mach bleibt Ihm überlassen.
So könnte man linienförmige Objekte weiterhin als Linie erfassen, am besten mit Breitenattribut. Das ist einfacher als Straßen u.ä. wie Flußbetten zu erfassen.
Und die Flächen so wie sie sind, auch ruhig direkt aneinander.
Linien über Flächen (überwiegende Nutzung) bleiben auch weiterhin so, die Linie hat ja eine Breite.
Wer jetzt eine Karte ohne Zwischnräume zwischen Linienelementen und Flächen haben möchte, kreiert sich einen Stil, der diese nach seiner Meinung am besten füllt.
Wo kämen wir hin, wenn wir für “den Renderer” mappen?
Nur leider basteln sich die Meisten keine eigenen Karten, sondern versuchen lieber Leute davon zu überzeugen, dass der Mapnik Stil aktuell nicht gut (also Ihrer Auffassung nach) die “Wirklichkeit” abstrahiert.
Bevor man sich die Mühe macht Linienobjekte als Flächen zu erfassen, sollte man lieber anfangen, auf einer der vielen weißen Stellen unserer Datenbank Grundlagen zu erfassen. Couchmapping in fremden Ländern, ist allerdings nicht so populär, habe ich den Eindruck.
Hier in Deutschlad/Europa müssen wir uns eh bald auf die Pflege der vorhandenen Daten beschränken, anstatt jeden Strohalm erfassen zu wollen.
Meine 2ct, und jetzt: frei nach Kreuzschnabel - weiter neues mappen .
Nochmal North Yorkshire: Ein schönes Beispiel ist Skelgate Lane (einst sicher ein vielbenutzter Weg aufs Moorland, heute ein einsamer Trampelpfad zwischen Mauern): http://www.openstreetmap.org/#map=17/54.39180/-1.95210&layers=N. Umgeben von Weideland, aber das endet natürlich an den Mauern (shared nodes). Wären die Mauern nicht da, ginge das Weideland aber auch nicht dichter an den Weg. Dazwischen wäre Zaun, Graben oder Brache. Es gäbe also IMHO keinen Grund, die Außengrenze der landuses woanders zu ziehen.
–ks
Weil dann alle sofort anfangen würden die Straßen aus Wohngebieten auszuschneiden und mit landuse=road zu taggen. Das gäbe ein heilloses Durcheinander und wäre wohl (korrigiert mich, wenn ich falsch liege) ohne MPs gar nicht machbar, was dann wieder die Neuankömmlinge mit deren super tollen MP-freundlichen iD-Editor freut.
Was für einen Mehrwert sollte es bringen, Straßen als Flächen zu Erfassen?
Braucht es der Router oder der Renderer?
Selbst wenn wir später aus mir unbekannten Gründen mal Straßen als Flächen mappen würden, kannst du nicht davon ausgehen, das die Editoren noch auf den Stand von heute sind.
Die machen das dann schon, wenn es soweit ist…
Wir bilden die Realität ab?
Indem wir Kreuzungen mit vielen lustigen Einbahnstraßen mappen, und drei Brücken nebeneinander, wo nur eine existiert, nur weil der Radweg extra gezeichnet werden muß?
Mappen wir jede Phase der Hochspannungsleitung extra?
Nein, wir Abstrahieren weil die Realität so vielseitig ist, das wir sie gar nicht graphisch abbilden können.
Damit reiht sich “Und wir bilden die Realität ab” ins Lexikon der beliebtesten Phrasen bei OSM ein. 
Ich behaupte sogar, je deteillierter die OSM-Datenbank wird, umso abstrakter werden wir in der Zukunft im Editor zeichnen.
Schon aus dem einfachen Grund, weil es sonst ohne technische Zeichenausbildung gar nicht mehr handhabbar wäre.
Das Lanes-Tagging ist schon ein erster Schritt in die Richtung:
http://wiki.openstreetmap.org/wiki/Lanes
Ich weiß von einem Mappertreffen, das viele Mapper deswegen Straßen und Landflächen nicht “Zusammenkleben”, weil es durch einige Editoren schwer zu Bearbeiten ist.
Das sollte aber eher ein Grund sein die Entwickler der Editoren auf die Füße zu treten, anstatt mit fadenscheinigen Begründungen eine seit langen etablierte Mapping-Methode
zu verunglimpfen…
Für einen Fiat Panda Fahrer ist es natürlich einfach lauthals 100 kmh auf der Autobahn zu fordern
Ich kann mit Josm übrigens sehr wohl damit umgehen 
Einzig würde ich mir wünschen, das beim ersten Klick auf eine “Zusammenverklebte” Linie immer zuerst die Straße ausgewählt wird.
Falls ein Josm-Entwickler mitliest, das wäre cool 
So richtig habe ich den Grund der Umfrage nicht verstanden.
Irgendwie habe ich den Verdacht, das dasErgebnis dann als Link im Changeset-Kommentar herhalten muß,
wenn übereifrige Mapper fleißig Straßen und Landuse wieder auftrennen.
Zur Not macht das halt wie immer eine Sockenpuppe…
Grüße von Lutz
Was Lutz sagt … und/oder/aber:
Mir gehen die angeklebten Flächen auch des öfteren wirklich derb auf den Sack, aber mal Hand aufs Herz, es ist auch immer eine Frage, wo, ob und wie REELL Dinge angrenzen oder nicht. Extrembeispiele gefällig? Es gibt real Häuser, die direkt an Strassen kleben. Es gibt real Häuser, die direkt an Sidewalks kleben.
Es gibt real asphaltierte (meist abschüssige) Strassen, die am Rand einen Betonsteinrand+Kanaldeckel haben, daneben ein Bordstein+Fussweg+Hecke+Haus. Mappe mir das mal wer ohne zu kleben (Ohne jetzt eine Lanze fürs Ankleben zu brechen, aber die Diskussion ist überflüssig.)
Man kann solche Dinge bis ins feinste Detail zerreden, ohweh, ich hab noch die Fuge zwischen Betonstein und Bordstein vergessen. Und … ohweh … zwischen Bordstein und Sidewalk ist auch eine mit Gras und zwischen Sidewalk und Haus mit Unkraut bewachsene Fuge.
Natürlich ist es ein Graus einen (bspw.) Feldweg vom Feld wieder zu lösen, aber wer einen Feldrain malen will, der muss da eben durch. Und wer da noch eine Drainage findet, der muss eben den Feldrain vom Feld lösen. Und und und.
Ach und was Strassen-areas betrifft, die ham kein rechts und links. Sinnvolles tagging, aber sehr grenzwertig. Wo hab ich bspw. auf ner Area sidewalk=left, both oder right? Badusch!
Beides … der Renderer braucht Straßen als Flächen und der Router als Linien.
Gruß Klaus
Wir haben zahlreiche Beispiele wofür wir das brauchen können. Es gibt sehr oft Asphalt bzw. Betonflächen in industriellen Gebieten die Befahrbar sind. Momentan bilden wir dies mit highway=service ab und die ganze, sehr oft unregelmäßige Ausdehnung ist nicht vorhanden.
Hmmm…also ich tagge so etwas bei größeren Flächen durchaus als area.
Ich weiß nicht, ob ich Lachen, oder Heulen soll…
Was hat das eine mit dem anderen zu tun?
Wir geben der Straße im Editor die Breite mit, und der Renderer kann wenn er das will berücksichtigen.
Es muß im Editor doch nicht Maßstabsgetreu gemappt werden, wo soll denn das hinführen?
An der Linie werden so viele Infos wie möglich gemappt, und die Darstellung obliegt dem Renderer.
Das Editieren, muß so einfach wie möglich gestalltet werden.
Jeder, auch der ohne Hochschulabschluß, sollte mit einer Linie und ein paar Klicks im Editor eine komplexe Straßenkreuzung in einer Großstadt mappen können.
Darauf sollte hingearbeitet werden, sonst bleibt ihr Techniker ewig unter euch…
grüße von lutz
Ich bin strikt dagegen Straßenknoten als landuse zu verwenden.
Hauptgrund: Extrem änderungsunfreundlich.
bridge=yes heißt nicht “Brücke” sondern “der Weg verläuft über eine Brücke”. Man_made=bridge gibt es und wird auch demnächst im Standardstil gerendet. Das Bsp. zieht also nicht.
Ihr könnt bei euren Argumentationen zu landuses und highways nicht in einen Topf werfen. Highways sind eindimensionale Informationen für das logische Routing, die man so gut es geht auf der Mitte der Straße erfasst. Renderer errechnen sich halt behelfsmäßig über deren Attribute dann ein visuelles Bild. Landuses und Gebäudeumrisse sind zweidimensionale Informationen, die man tatsächlich an der Stelle einträgt wo sie auch wirklich vorkommen.
Deswegen gibt es ja auch landuse=highway (wobei mir landuse=traffic – für Verkehrsflächen – besser gefallen würde), als auch area:highway um Renderern einen zweidimensionalen visuellen Hint zu geben, der unabhängig von den logischen Informationen auf dem Highway selber ist. Diese Flächen können dann miteinander verbunden werden (als auch Häuser die an Gehsteigen angrenzen, usw…). Auf der Proposalseite http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway#Suggestion_for_renderers hab ich damals eh ein paar Mockup-Screens hinzugefügt, wie das ganze auf hohen Zoomstufen aussehen könnte (sogar mit an Gehsteigen angrenzenden Gebäuden).
Kommerzielle GIS-Systeme machen es ja auch nicht anders. zum Beispiel das GIS-System vom Land Oberösterreich:
• Bei Zoomlevel 9 werden noch die Highways selber rendert: http://maps.doris.at/?x=70928&y=350675&zoom=9&layer=op&marker_x=70733&marker_y=351821&popup_x=70733&popup_y=351821&popup_text=Linz
• Bei Zoomlevel 10 werden dann die zweidimensional erfassten Flächen angezeigt und vom Highway selber wird nur mehr der Name, oder Linien der Öffi-Verbindungen darübergelegt: http://maps.doris.at/?x=70924&y=350678&zoom=10&layer=op&marker_x=70733&marker_y=351821&popup_x=70733&popup_y=351821&popup_text=Linz
Deswegen verstehe ich die Diskussion eigentlich nicht, weil es keinen Grund gibt hier das Rad neu zu erfinden, wenn sich schlaue Köpfe, die das beruflich machen, bereits vor langer Zeit einmal den Kopf darüber zerbrochen haben.
Die Frage ist doch, müßen wir im Editor Areas malen, oder kann der Renderer diese anhand von Zusatzinfos errechnen, und dann darstellen?
Ich bin mir sicher, ohne es beweisen zu können, das auch ohne gezeichnete Areas ein ähnliches Bild wie auf deinen Mockup-Screens zustande kommen kann…
Aber das ist nicht der Punkt!
Egal wo OSM hingeht, entweder zu einem Abstrakten oder zu einem Area zeichnen, das wird die Zeit entscheiden.
Es bedarf auf keinen Fall vorauseilenden Gehorsam um bestimmte Mapping-Techniken zu verdammen, oder als heilig hinzustellen.
Dies sollte dem mündigen Mapper selbst überlassen werden…
Und ich denke auch, das wenn sich das Area-Mapping durchsetzt, die “Zusammenkleber” von ganz alleine ihre Gebiete anpassen werden.
Denn das sind in der Regel gewissenhafte Mapper.
Dazu bedarf es keine Gebietsüberwacher und Regeln-vor-sich Hinbeter!
Grüße von Lutz