Elemente mit mehreren gleichwertigen Tags/Features

Mirko_Küster · 2009-05-24T10:28:21.000Z

TEL0000:

Es arbeiten nicht auf einmal mehr Leute an einem Objekt, nur weil es als Relation getaggt wird…

Bei größeren Relationen in aktivem Gebiet habe ich quasi alle 5 Minuten einen Konflikt. Das merkt man erst seit API 0.6, da man hier schon an der Versionsnummer scheitert. Früher griff da höchstens nur Precondition.

Ich musste gestern händisch das modify aus dem File nehmen, die Relation also unangetastet lassen. Anderfalls wäre keine Bearbeitung möglich gewesen. Und bei immer mehr Mappern und noch mehr Relationen steigt die Gefahr sich zu behindern immer mehr. Das geht definitiv nicht gut.

TEL0000:

Zur Zeit sind Relationen für Neueinsteiger schwer zu verstehen. Das wundert mich auch nicht. Es ist ein totales Tagging-Durcheinander. Vor allem bei Multipolygonen. Wenn man dort einfach die Relation taggen würde, dann wär das viel leichter zu verstehen.

Es scheitert schon an einfachen Relationen. Entweder lassen die viele gleich ganz sein und behelfen sich anders, oder es wird aus Unwissenheit versaut. Egal wie man den Mist nun nennen möge, viele werden sich nicht mehr rantrauen.

dgdg · 2009-05-24T11:28:10.000Z

S-A-L:

Aber meint ihr echt, dass Relationen so schwer zu verstehen sind fuer den Otto-Normal-Mapper?

Definitiv. Der Otto-Normal-Mapper denkt maximal in Nodes und Wegen und Flächen. Ein bischen Geometrie hat jeder in der Schule mitbekommen. Relationen sind dagegen eine abstraktes Gebilde.
Neben dem Verständnisproblem kommt dazu noch die nicht gerade trivale Handhabung im Mapping-Tool.

Wie gesagt, ich habe nichts gegen Relationen als Organisationsobjekt in der Datenbank. Aber was habe ich als Mapper damit zu tun, wie die Datenbank organisiert ist?

Wir könnten ja mal einen Umfrage starten, welche Ausbildung die Mapper haben, die aktiv mit Relationen arbeiten. Und wieviel Prozent der Mapper das überhaupt sind.

Detlef

dgdg · 2009-05-24T11:32:33.000Z

TEL0000:

Vor allem bei Multipolygonen. Wenn man dort einfach die Relation taggen würde, dann wär das viel leichter zu verstehen.

Verständnisfrage: Was meinst du mit “Relation taggen”?

Detlef

TEL0000 · 2009-05-24T21:42:07.000Z

dgdg:

TEL0000:

Vor allem bei Multipolygonen. Wenn man dort einfach die Relation taggen würde, dann wär das viel leichter zu verstehen.

Verständnisfrage: Was meinst du mit “Relation taggen”?

Na statt dem Way die Tags mitzugeben, einfach die Tags in die Relation schreiben. Das Problem ist nur, dass es momentan nicht gerendert wird.

Mirko_Küster · 2009-05-24T21:50:46.000Z

Genauso wie es keine logischen Verknüpfungen oder Vererbungen gibt. Relationen sind einfach gesagt noch zu dumm um mehr damit anzustellen. Keine Software könnte derzeit unterscheiden ob denn nun die Landstraße, die Fahrradroute oder die Busrelation Priorität in der Darstellung hat. Deswegen taggen wir ja die Priorität Hardcode an den Weg, in dem Fall die Landstraße. Die road Relation ist derzeit nur tote Materie und nur für spezielle Auswertungen tauglich. Und auch dort beklagt man Darstellungsprobleme mit mancher Software. Die Cycle Map pennt ja bis heute bei Multipolygonen.

Mit Relationen hat man derzeit also rein garnichts gekonnt. Ob nun verdeckte POI’S oder Relationen, an beidem müsste man erstmal arbeiten um Probleme zu lösen.

TEL0000 · 2009-05-24T21:52:13.000Z

Ich finde Relationen zur Zeit auch unnötig kompliziert.

Klar denken zur Zeit alle in Nodes und Ways, und die wenigsten haben einen Plan was eine Relation überhaupt ist.

Wenn man Nodes und Ways garnicht taggen könnte, dann bräuchte sich der Mapper damit auch nicht besonders beschäftigen. Für uns wäre das ein Umdenken, für neue Mapper wärs aber einfacher zu verstehen. Und zudem wärs noch flexibler…

@Mirko: Nur weil der Briefkasten um die Ecke dann nichtmehr nur ein Node, sondern auch eine Relation mit dem einen Node als Mitglied wäre, arbeiten da nicht gleich mehr Leute dran. Das Problem tritt nur bei großen Objekten auf, und dafür benutzen wir bereits Relationen. Es macht also keinen Unterschied. Dass heißt, dass es so oder so ein Problem ist, welches gelöst werden muss.

Mirko_Küster · 2009-05-24T22:02:30.000Z

Ich verstehe nur noch immer nicht den Sinn einer Relation für einen einzigen Punkt. Das ist doch so als würde man dem Briefkasten noch ein großes Schild mit Briefkasten aufsetzen. Überflüssig, sinnfrei und komplizierter. Und die Darstellungsprobleme wären damit noch immer nicht gelöst. Bei dichten Objekten müsste die Software noch immer trennen. Mit der Realation hast du da doch rein garnichts gewonnen. Die Position bezieht sich damit doch noch immer auf den Node. Wozu muss ich dann erst Tag und Koordinate Datenbanktechnisch trennen, wenn die eigentliche Information doch letztendlich die gleich bleibt? Ich habe einen Node mit der Koordinate und die Beschreibung in der Relation. Damit gebe ich der Datenbank nur Mehrarbeit und mache das mappen komplizierter, ansonsten machts keinen Sinn.

S-A-L · 2009-05-25T06:47:16.000Z

Wenn der Briefkasten aber nicht nur ein Briefkasten ist, sondern gleichzeitig noch ein Briefmarkenautomat, könntest du zwei Relationen damit Verknüpfen und hättest dann keine Probleme damit die Tags dem richtigen Objekt zu zu ordnen sollten beide Objekte teilweise dieselben Tags mit unterschiedlichen Werten haben.

Tordanik · 2009-05-25T10:03:13.000Z

S-A-L:

Wenn der Briefkasten aber nicht nur ein Briefkasten ist, sondern gleichzeitig noch ein Briefmarkenautomat, könntest du zwei Relationen damit Verknüpfen und hättest dann keine Probleme damit die Tags dem richtigen Objekt zu zu ordnen sollten beide Objekte teilweise dieselben Tags mit unterschiedlichen Werten haben.

Und wie oft kommt das vor? Oft genug, um eine Komplettumstellung des Taggings zu rechtfertigen?

Ganz abgesehen davon: Ich halte die Information, dass sich Briefkasten und Briefmarkenautomat ein Gehäuse teilen und nicht etwa nebeneinander stehen (was man vermutlich damit ausdrücken will, dass man einen gemeinsamen Node nimmt) für ziemlich nebensächlich. Ich finde auch ohne diese Info beide Einrichtungen. kann trotzdem Briefkasten- und Automatenkarten erstellen…

Ich finde es daher etwas fragwürdig, zugunsten einer solchen Nebeninformation die Erfassung der Basisinformation zu erschweren. Viel sinnvoller wäre es da doch, die Objekte einzeln zu erfassen und die Beziehung “teilen sich ein Gehäuse” als Relation zu erfassen - auf diese Weise müssten sich nur die mit Relationen auseinandersetzen, die sich überhaupt für diesen Detailgrad interessieren.

Natürlich ist es denkbar, dass mit einem geeigneten Editor und geänderten Anwendungen eine Anpassung des Datenmodells von Vorteil wäre und keine kompliziertere Bedienung zur Folge hätte. Bis jetzt habe ich aber keine Zeile Code und nicht einmal ein Bedienkonzept für einen solchen Editor gesehen.

TEL0000 · 2009-05-25T10:18:57.000Z

Tordanik:

S-A-L:

Wenn der Briefkasten aber nicht nur ein Briefkasten ist, sondern gleichzeitig noch ein Briefmarkenautomat, könntest du zwei Relationen damit Verknüpfen und hättest dann keine Probleme damit die Tags dem richtigen Objekt zu zu ordnen sollten beide Objekte teilweise dieselben Tags mit unterschiedlichen Werten haben.

Und wie oft kommt das vor? Oft genug, um eine Komplettumstellung des Taggings zu rechtfertigen?

Ja! Nicht unbedings das Briefkastenbeispiel, aber es gibt so viele andere Beispiele…

Man kann dann Objekte mit beliebig vielen Ways und Nodes machen, und die Nodes für verschiedene Objekte doppelt nutzen.
Dann würden auch Fragen wie “wie mache ich eine T-Förmige Straße?” aufhören, da durch die Trennung von Geografie und Objekttagging alles klar wär.

TEL0000 · 2009-05-25T10:24:31.000Z

Wenn ich so drüber nachdenke… Das ganze muss ja auch nicht von der Datenbank kommen. Das war nur mein Gedanke, weil die Editoren sehr datenbankbasiert sind. Natürlich kann die Editor-Software das einfach so getrennt Handhaben, und dann je nachdem wie es am sinnvollsten ist, als Relation oder als Node eintragen.

KaChing_Cacher · 2009-05-25T10:36:35.000Z

Kann man denn nicht auch einfach 2 values in einen Key packen?
Also z.B. amenity=hotel;restaurant?
Das wäre doch die einfachste Lösung!

TEL0000 · 2009-05-25T10:43:07.000Z

KaChing_Cacher:

Kann man denn nicht auch einfach 2 values in einen Key packen?
Also z.B. amenity=hotel;restaurant?
Das wäre doch die einfachste Lösung!

Möglich, aber das verstehen die Renderer zur Zeit genausowenig. Und da hättest du wieder ein Problem, wenn du zu den einzelnen amenities Zusatztags angeben möchtest.

Mirko_Küster · 2009-05-25T10:47:41.000Z

Briefkasten mit Automat? Habe ich im Leben noch nie gesehen. Sowas gibts hier im weiten Umkreis definitiv nicht. Sowas gab es getrennt, als wir noch eine richtige Post hatten. Seit der Postagentur ist der Automat aber Geschichte.

Und zwei Eigenschaften für ein Objekt ginge auch so. Man müsste nur die Tags weiter flexibilisieren. Bei meinem Beispiel als Haupttag den Aussichtspunkt. Dazu Bank=ja, Informationstafel=ja. Es muss den Renderern nur beigebracht werden. Nur wenn ich da wie z.B. Beispiel beim Baumarkt Ewigkeiten umsonst warte, kann es ja nichts werden. Genau das gleich bei der Cycle Map. Was nützt mir ein Multipolygon, wenn man bei Cloudmate zu faul ist, die Software mal auf ein aktuelle Version anzupassen? Wir können hier ausklaspern was wir wollen. Wenn man sich bei den ausführenenden Anwendungen weiterhin die Eier schaukelt, bringt uns das keinen Schritt weiter.

Für Straßen haben wir ja die Road Relation, nur wird die wie bereits gesagt noch garnicht vernünftig verwertet. Das alte Problem eben. Des weiteren bräuchte man dann für eine Straße dutzende Relationen, wenn man auch das Tagging in Relationen auslagern würde. Man müsste nämlich noch immer für maxspeed usw. Splitten. Dann hätte man dutzende Relationen die man in einer großen zusammenfassen muss. Das ist das gleiche atomisierte Chaos, nur in noch komplexer.

Und wo ist das Problem bei einer T förmigen Straße? Ich habe hier nahezu in jedem Dorf eine Straße mit mehreren Stich- oder gar Paralelstrecken. Manch Dorf hat komplett nur einen Straßennamen. Ganz kleine keinen, da gilt der Ortsname. Da kriegt jede ihren Namen und Eigenschaften, aus die Maus.

TEL0000 · 2009-05-25T10:59:12.000Z

Mirko Küster:

Und wo ist das Problem bei einer T förmigen Straße? Ich habe hier nahezu in jedem Dorf eine Straße mit mehreren Stich- oder gar Paralelstrecken. Manch Dorf hat komplett nur einen Straßennamen. Ganz kleine keinen, da gilt der Ortsname. Da kriegt jede ihren Namen und Eigenschaften, aus die Maus.

Ich wollte damit nur sagen, dass es für einen Einsteiger einfacher zu verstehen wäre. Momentan will ein Neueinsteiger einen Way ungerne splitten, weil es für ihn das Objekt ist. Man brauch halt ein Konzept, um die die Geografie vom Tagging zu trennen. So hast du ja selber schonmal ein ähnliches Konzept beschrieben, mit dem Unterschied das es mit der aktuellen Datenbank so nicht umzusetzen gewesen wäre…

Aber ich wollte mit dem Konzept garnicht so viel aufsehen erregen, da es sich eh nie durchsetzt. Um zum Thema zurückzukommen: Meiner Meinung nach spricht nichts dagegen für die beiden Objekte jeweils eine Relation zu erstellen, und diese entsprechend zu taggen. Gerendert werden wird es zwar erstmal noch nicht, aber das liegt nicht am Schema, sondern an den Renderern, die Grundsätzlich noch nichts rendern, was in Relationen steht. Das kann sich aber auch schnell ändern.

Wie du jetzt zwei Objekte an einen Node hängen willst, das hab ich nicht verstanden. Kannst du das mal näher erläutern?

dgdg · 2009-05-25T12:44:12.000Z

KaChing_Cacher:

Kann man denn nicht auch einfach 2 values in einen Key packen?
Also z.B. amenity=hotel;restaurant?
Das wäre doch die einfachste Lösung!

Da sind wir wieder am Anfang der Diskussion (bitte nochmal weiter oben lesen). Wie vergibst jetzt eindeutige Namen für das Hotel und das Restaurant?

Detlef

KaChing_Cacher · 2009-05-25T12:49:29.000Z

Ich würde vorschlagen name:restaurant oder name:hotel.
Und so könnte man das mit allen anderen Sachen doch auch machen.
z.B. natural=cliff, name:cliff=x.

Mirko_Küster · 2009-05-25T12:54:55.000Z

Wenn das Hotel nicht ohnehin “Hotel und Restaurant zur Quarknase” heißen sollte, die Tags ohnehin reformiert werden, gilt gleiches auch für den Name Tag. Wo ist das Problem neben old_name, alt_name, vor_name, kose_name… meinetwegen restaurant_name, hotel_name oder wie auch immer einzuführen?

Die Schlüssel sind nichts für die Ewigkeit. Die kann man alle beliebig abschaffen, verändern oder erweitern. Der Akt wäre der gleiche wie wenn man Relationen, Klumpen oder Cluster erfinden würde. Die Anwendungen müssen es umsetzen. Eine Hürde die für alles gleichsam hoch ist. Also kann man gleich das bestehende besser ausarbeiten, ohne das Rad abzureißen und komplett neu aufzubauen.

KaChing_Cacher · 2009-05-25T13:00:58.000Z

Allerdings sollte es ein festes Prinzip für “Unterkeys” geben.
Denn wenn man restaurant_name und maxspeed:hgv benutzt blickt man irgendwann nicht mehr durch,
wann man was wie rum verwendet.
Ich würde letzteres bevorzugen, da das “maxspeed” ja über dem “hgv” steht.

Mirko_Küster · 2009-05-25T13:16:43.000Z

Ist doch im grunde Latte wie das am Ende konkret aussehen soll.

Ich wollte damit nur sagen, dass sich hier manche Probleme machen, wo eigentlich garkeine sind. Das Problem ist nicht das Tagging. Das können wir jederzeit problemlos umwerfen. Das Problem sind die Anwendungen die den Fortschritt einfach nur ignorieren und ihr eigenes Ding fahren. Wir können uns hier ausdenken was wir wollen. Fakt ist eines. Die Cycle Map wird auch in 5 Jahren genauso aussehen, wenn man nicht den Finger aus dem Hintern zieht, und von der Steinzeitversion des Rendereres auf etwas aktuelleres geht. Von sich aus wid aus MS Paint nunmal kein Photoshop.