Bei Parkplätzen, deren Parkbuchten direkt von der Straße erreicht werden, kann man m.E. die Straße als Begrenzung nehmen. Für alle anderen Beispiele stimme ich dir zu. Meine Beispiele zeigen genau diese Fehler für Felder in Wiesen in Wäldern und an Wegen.
Wir mappen für die Datenbank, nicht damits auf einer Karte gut aussieht. Kleine Objekte können erfasst werden, wer sie nicht will filtert sie hinterher wieder raus. Auch ein Form von Generalisierung kleinste Flächen einfach zu ignorieren. Im größten Maßstab kann man sie ja wieder reinnehmen.
Da bin ich ja mal gespannt, wenn es soweit ist. Müßte man da nicht jetzt schon gegensteuern und denn MP Fans, zumindest was einfache Gebilde angehen, in den Allerwertesten treten.
Josef
Naja auch mit einem neuen Typ Area wird sich an der Art und Weise nichts ändern, wie man die Objekte einträgt. Das Kind heißt dann halt nicht mehr Relation, sondern area oder sonstwie. Man braucht weiterhin eine äußere Begrenzung und auch weiterhin eine innere Begrenzung, wenn diese nötig ist.
Mal weg vom MultiPolygon und hin zum Detailmapping: Es fehlt eine Strategie, wie man die Teerfläche als Teerfläche zeichnet, welche dann in der Karte als “Straße” angezeigt wird, und zusätzlich dazu die Fahrspuren als Fahrspuren, welche dann vom Router ausgewertet werden. Oder kann man hier einfach die Straße als Fläche Zeichnen und mit Belag=Teer taggen? Eigentlich sollte das doch kein Problem sein. Es müsste nur etwas offizielles sein.
Hi,
Danke für die Gelegenheit, ein paar fundamentalistische Sätze loszulassen :-))
Das landuse-tag ist ein besonderes Tag, weil es eine “überwiegende” Nutzung beschreibt.
Daraus folgt direkt, dass landuse keine Überschneidungen hat, denn es können ja nicht zwei Sachen überwiegen.
Daraus folgt auch, dass man bei “landuse” keine Löcher machen muss, denn “überwiegend” besagt ausdrücklich, dass es in Teilgebieten anders sein kann.
Daraus folgt aber auch, dass nur solche Werte für “landuse” in Frage kommen sollten, bei denen die Frage nach dem “überwiegend” sinnvoll ist. Man kann bei gemischt industieller und landwirtschaftlicher Nutzung fragen: “welche Nutzung überwiegt?” Bei “forest” und “military” geht das dagegen nicht: Der Wald ist militärisch genutzt; da kann man nicht fragen, ob das hauptsächlich Wald oder hauptsächlich militärisch ist. Militärgelände sollten nicht mit dem landuse-tag beschrieben werden.
Da “landuse” mit “überwiegender” Nutzung zu tun hat, ist es wohl nur für große Gebiete gedacht.
Ich persönlich finde “landuse”-Gebiete unter einem Quadratkilometer oder einer Breite unter 200m nur selten sinnvoll und bezweifle, dass wir mehr als “industrial”, “agricultural” und “residential” haben sollten.
Ganz anders ist die Sache bei anderen Flächen. Hier gibt es kein “überwiegend”-Argument. Alle Flächen sollten in ihrer wirklichen Ausdehnung beschrieben werden und dazu gehört eben auch das Auslassen von inneren Gebieten anderer Art. Das KISS-Prinzip sagt mir dabei, dass das OSM-Objekt das gleich richtig beschreiben soll – es sollte nicht erst falsch beschrieben werden und dann in einem anderen Datenbankeintrag mit Ausnahmen versehen werden. (Damit meine ich Multipolygone mit den Tags am “outer” way. Ein solcher “outer” way an sich hat eine Bedeutung in OSM und die wird dann durch den Multipolygoneintrag verändert. Einen Datenbankeintrag sollte man so nehmen können wie er da steht, ohne erst alle anderen lesen zu müssen.)
Um den Eindruck zu vermeiden, dass ich die anderen Multipolygone mag (bei denen die Tags im Multipolygon sind):
Multipolygone sind m.E. ein Missbrauch der Relationen und sollten im nächsten API durch Flächenobjekte ersetzt werden. Relationen sollten OSM-Objekte zu einem größeren Ganzen zusammenfassen, also etwa einzelne Wege zu einem Wanderweg. Ein Multipolygon für einen See enthält aber z.B. zwei Bundestraßen und eine Gemeindegrenze, ohne dass jemand behaupten wollte, dass ein See ein abstraktes Objekt aus Bundesstraßen und Gemeindegrenzen wäre.
MfG
Weide
Ich danke dir für deine Ausführungen (auch die nicht zitierten). Das Datenmodell in OSM ist m.E. nur für max. eindimensionale Objekte geeignet, womit man Straßen als Linienzüge darstellen kann. OSM bedeutet ja auch nur OpenStreetMap und nicht OpenAreaMap (und ist mit der Datenstruktur nicht für OpenGeoMap geeignet). Bevor wir neue Krücken für 3D schaffen, sollten wir erst mal 2D in den Griff bekommen.
Kennst du area:highway=* ?
Ja, aber so wirklich beschrieben ist da noch nicht wirklich viel… Ich mache dafür mal einen eigenen Thread auf, da sich das sonst hier alles zu viel vermischt…
Wird aber ja noch nirgends gerendert, oder?
hab ich schon mal vor einiger zeit angeschnitten: http://forum.openstreetmap.org/viewtopic.php?id=10522
hatte mit dem thema ziemlich viel gegenwind. ist mir auch mit dem parking_space proposal so gegangen (http://wiki.openstreetmap.org/wiki/Proposed_features/parking) und wird bei meinem access proposal vermutlich nicht anders sein (http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5). aber das ist nun mal so wenn man seiner zeit voraus ist :-).
Gestern habe ich die Kreuzung befahren, es handelt sich um eine stinknormale
Kreuzung mit Abbiegespuren. Nur dass der Router nicht mehr sagt:
“Nach 200m rechts abbiegen” sondern:
“Nach 200m rechts abbiegen auf Abbiegespur, dann nach 20 m rechts abbiegen auf B54”
oder so…
Die folgende Kreuzung 3 km weiter östlich bringt den Router auch ins Schwitzen:
Schaltet man hier von “schnellster” auf “kürzester” Weg routet er noch verrückter. 
(Hab noch nicht untersucht, ob die Daten korrekt sind).
Chris
rechts abbiegen ist ja noch der Trivialfall. Links abbiegen dürfte deutlich interessanter werden, vor allem da man wohl nur Anweisungen für geradeaus fahren erhalten wird. Da nützen auch die turn restriction nichts, wenn der Fahrer die Anweisungen nicht mehr versteht.
So umgehst du immerhin 2 Ampeln.
rab
Die Einbahnstraße in östliche Richtung (“Eickendorf”) scheint zu weit getaggt. An den Punkten an denen die einzeln gezeichneten Spuren wieder zu einem Weg werden ist ein wenden oft nicht erlaubt/möglich-> überprüfen und ggf. Abbiegebeschränkungen einsetzen.
Edit: Bei der Kleiststraße gehört an das Kreuzungsmittelstück auch eher oneway=yes statt -1.
Gruß BBO
Meiner Meinung nach gehört sich das korrigiert. Hier meine ich korrigiert im Sinne von vereinfacht.
Ganz normale Abbiegespuren als eigene Ways, die irgendwann weit vor der Kreuzung vom “Hauptway” abzweigen? schauder
Stimmt. Schon verwirrend dass JOSM die Pfeilrichtung umkehrt, wenn man das Stück anklickt. 
http://www.openstreetmap.org/browse/way/96690890
Werde mir weitere Kreuzungen des Users Blue1000 mal anschauen…
Immerhin handelt es sich hier um Bundesstraßen. 
Edit: Korrigiert oneway=-1 → yes
Chris
Gottseidank sind an dieser Kreuzung keine Abbiegebeschränkungen (von Spur zu Spur) gemappt,
sonst wäre überhaupt kein Routing von S nach N mehr möglich. So findet der Router ja
immerhin einen “Workaround” indem er erst rechts abbiegt und dann über die durchgezogene
Linie wendet.
Chris
Aktuell ja, wenn die Kreuzung aber korrigiert ist gehören sie schon mit ran…
Ich habe aber soeben festgestellt das cloudmade scheinbar garnicht das to-Mitglied der Relation auswertet:
http://maps.cloudmade.com/?lat=50.703552&lng=11.622291&zoom=18&directions=50.70344335359651,11.622478365898132,50.703796689175235,11.621598601341248&travel=car/shortest&styleId=1&opened_tab=1
Gruß BBO
naja, aber das ist ja definitiv ein fehler in cloudmade, denn wenn man den kürzesten weg wählt und der länger ist als der schnellst ist da irgendwas im algorithmus faul