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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Richtig. Dafür müsste ein einheitliches Konzept her, damit das auch von Software ausgewertet werden kann… Ein Versuch sowas zu entwickeln gab es schonmal unter http://forum.openstreetmap.org/viewtopic.php?id=1284 (leider fehlen da durch die Forenumstellung die Zeilenumbrüche, daher ist es jetzt etwas unübersichtlich)
Die Relationen hätten den Vorteil, dass eine Software es ohne Probleme versteht (vorrausgesetzt sie kann schon mit Relationen umgehen)