Der Nachteil des Detailmappings

[SunCobalt (Thomas)]

@hurdygurdyman

@SunCobalt

…
Nun bleibt mal aufm Teppich. Mein größtes MP, das ich aber vorm hochladen geteilt habe, hatte ca. 65.000 Nodes und über 300 Ways. Das ging auch. Und niemand verlangt von Dir, dass Du das aufräumst. Wenn Du das nicht willst, lass es einfach und tue “sinnvolleres”

Bin wieder unten
Kannst du uns hier auch verraten, ob dein Riesen-MP dauerhaft gehalten hat?
Mir geht es darum, wie man die Erfassung vereinfachen kann, damit sie trotz zunehmender Detaillierung weniger fehleranfällig, besser für Renderer verwertbar, und für den Gelegenheitsmapper keine Spaßbremse ist.

Immerhin geht es hier um die Nachteile des Detailmappings (und seinen Folgen, zu denen m.E. auch die MP-Inflation gehört).

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?

[hurdygurdyman]

@SunCobalt

Nun, wie gesagt, ich habe es vorm Hochladen in mehrere MPs geteilt. Aber alle Teil-MPs leben immer noch…seit ungefähr 5 Monaten bis jetzt. Mal schauen.

Glückwunsch!

@SunCobalt

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.

[Radeln]

@chris66

@hurdygurdyman

Ich hatte auch nicht die Absicht, hier wieder eine Diskussion über die MP’s allgemein oder deren Sinn loszutreten. Mich treibt hier nur die Befürchtung, dass durch Detailmapping die Zahl der MP’s samt der damit verbundenen Fehleranfälligkeit aus (unbedarften) Änderungen und die daraus resultierende Korrekturnotwendigkeit erheblich zunimmt. Deshalb meine Überlegung, wie und wann MP’s vermeidbar sein könnten.

Sooo, kompliziert sind MPs auch nicht. Du gibst an, was ist die Aussenbegrenzung, was die Innenbegrenzung und fertig.
Verwirrend sind nur die verschiedenen Taggingmöglichkeiten (Tags an Relation und/oder an Aussenlinie).

Und wenn jeder Acker einzeln gemappt wird, werden auch weniger MPs benötigt, als wenn man ein Gebiet
großflächig braun färbt und jeden Wald/Residential/etc. per MP ausstanzt.

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ß.

Josef

[hurdygurdyman]

@Radeln

…
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.
…
Josef

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.

[tiototo (Tomas Labios)]

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.

[Radeln]

@hurdygurdyman

@SunCobalt

Nun, wie gesagt, ich habe es vorm Hochladen in mehrere MPs geteilt. Aber alle Teil-MPs leben immer noch…seit ungefähr 5 Monaten bis jetzt. Mal schauen.

Glückwunsch!

@SunCobalt

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.

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

[aighes (Henning)]

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.

[Dennis_B]

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.

[Weide]

Hi,

@hurdygurdyman

Was haltet ihr von folgender Regel (auch für Renderer):
Befindet sich ein kleines Polygon mit Flächeneigenschaften innerhalb eines anderen größeren Polygons mit anderen Flächeneigenschaften auf demselben Layer, so gilt in diesem Bereich die Flächeneigenschaft des kleinen Polygons als “Ausschnitt” aus dem größeren Polygon.

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

[hurdygurdyman]

@Weide

…
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.

[aighes (Henning)]

@'Dennis[B

']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.

Kennst du area:highway=* ?

[Dennis_B]

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…

[errt]

Wird aber ja noch nirgends gerendert, oder?

[flaimo]

@'Dennis[B

']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…

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 :-).

[chris66]

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:

http://maps.cloudmade.com/?lat=51.793302&lng=7.752442&zoom=15&directions=51.788802665367236,7.761282920837402,51.79741595481177,7.7545881271362305&travel=car&styleId=1&geocoding=city:drensteinfurt&active_page=0&results_number=10&search_bbox=51.78791337231385+7.620048522949219,51.817423224978924+7.727851867675781&bbox=51.78791337231385+7.620048522949219,51.817423224978924+7.727851867675781&opened_tab=1

Schaltet man hier von “schnellster” auf “kürzester” Weg routet er noch verrückter.
(Hab noch nicht untersucht, ob die Daten korrekt sind).

Chris

[monotar]

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.

[rab]

So umgehst du immerhin 2 Ampeln.
rab

[BBO]

@chris66

(Hab noch nicht untersucht, ob die Daten korrekt sind).

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

[Zartbitter]

@chris66

es handelt sich um eine stinknormale Kreuzung mit Abbiegespuren

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

[chris66]

@BBO

Edit: Bei der Kleiststraße gehört an das Kreuzungsmittelstück auch eher oneway=yes statt -1.

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