Nun, wie gesagt, ich habe es vorm Hochladen in mehrere MPs geteilt. Aber alle Teil-MPs leben immernochâŠseit ungefĂ€hr 5 Monaten bis jetzt. Mal schauen.
Wie kommst Du drauf, dass Du jetzt eine bahnbrechende Idee haben könntest, die noch keinem der 10.000 Powermapper gekommen ist?
Naja, bahnbrechend ist die Idee nicht. Aber auch fĂŒr Datenbanken gilt das KISS-Prinzip ( http://de.wikipedia.org/wiki/KISS-Prinzip ), das m.E. in einem freien Projekt wie OSM, an dem Freiwillige mit unterschiedlichem Kenntnisstand arbeiten, zwingend sein sollte.
Wenn ich zudem daran denke, dass vielleicht irgendwann durch api 0.7 oder spĂ€ter die simple features sinnvollerweise auch in OSM gelten, und mir vor diesem Hintergrund unsere MPâs und meine zwei Beispiele betrachte, dann ist der Aufwand nĂ€mlich gröĂer als du denkst, da dann u.a. die inner-FlĂ€chen, welche gemeinsame Linienteile mit der outer-FlĂ€che haben, abgetrennt werden mĂŒssten. Auch einzelne Felder mit gemeinsamen Linien mĂŒssten auseinandergezupft werden.
OSM-Inspector setzt hier ja schon mit âtouching inner ringsâ an.
Im Zusammenhang mit den Powermappern gratuliere ich zum aktuellen Platz 111 ( http://www.odbl.de/world.html ), gegen den ich als gerade mal unter 3500 natĂŒrlich abstinke.
GebĂ€ude, SpielplĂ€tze, ParkplĂ€tze usw., wobei dann noch StraĂen als Grenzen genommen werden, obwohl da einige Meter Abstand sind und so manche FlĂ€chen (Friedhof) mit einer Mauer umgeben sind. DafĂŒr habe ich einfach kein VerstĂ€ndnis.
Ich denke dabei auch an Diskussionen, wie das Mappen von GebĂ€uden: DachĂŒberstand â GrundriĂ.
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.
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.
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.
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.
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âŠ
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.
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.
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