Elemente mit mehreren gleichwertigen Tags/Features

Nop · 2009-05-23T18:36:58.000Z

TEL0000:

Potlatch ist da mal ein relativ gutes Beispiel wie das zuweisen der Relationen aussehen könnte. Dort erstellt man einfach eine Relation, und fügt die sozusagen wie einen Tag hinzu. Mit einem Klick darauf kann man dann die Tags der Relation bearbeiten. Beim hovern wird angezeigt was zur relation dazugehört. Sehr übersichtlich also…

Solange Du nur eine Relation anschaust, wirkt es immer einfach. Der Spaß beginnt bei mehreren Relationen, die die gleichen Tags mit unterschiedlichen Werten haben.

Mirko_Küster · 2009-05-24T00:56:14.000Z

Mit den Relationen ist eine Super Idee. Ich durfte heute schon dreimal meine Arbeit in die Tonne kippen, weil ich versuchte aus einem elendig langem und frei erfundenem Radweg, real existierende Wohnstraßen zu machen. Wenn da nur nicht gleich eine Relation dranhängen würde, die von Bayern bis an die Ostsee reicht.

In der Zwischenzeit fummeln da natürlich andere dran herum, die Version ändert sich und das ganze wird dann einfach abgewiesen. Da hilft auch kein händisches änder der Version, die API m,erkt auch unterschiede bei Wegen. Wenn nun jeder Kleinmist auch noch an einer Relation hängen würde, behindert sich jeder gegenseitig. Es ist dann reine Glückssache, einen Zeitpunkt zu erwischen, wo man exklusiv daran arbeitet. Ich versuche es dann mal morgen um 6 Uhr. Vielleicht habe ich ja Glück…

Also alles, bloß keine Relationskonstrukte für jeglichen Kleinscheiß. So wie das jetzt ist ist das auch gut so. Und gerade bei komplexen Dingen steigt keine Sau mehr durch. Viele trauen sich schon jetzt kaum an einfache Relationen heran oder versauen einiges beim Versuch damit zu arbeiten.

dgdg · 2009-05-24T07:16:10.000Z

Mirko Küster:

So wie das jetzt ist ist das auch gut so. . Und gerade bei komplexen Dingen steigt keine Sau mehr durch. Viele trauen sich schon jetzt kaum an einfache Relationen heran oder versauen einiges beim Versuch damit zu arbeiten.

Das stimmt. Und irgendwann mappen nur noch ein paar wenige Informatiker. Mit steigender Komplexität wird die Anzahl der Mapper abnehmen.

Andererseits habe ich hier gerade versucht ein kleines Einkaufszentrum mit ein paar wenigen separaten Läden zu mappen. Da kommen ganz schnell mal 10 Nodes auf kleinstem Raum zusammen (eigentlich alle mit der gleichen Koordinate). Zumindest in Potlatch reicht der maximal Zoom schon nicht mehr aus. Und in JOSM sieht das auch nicht viel übersichtlicher aus.

Also so wie das jetzt ist, ist es eben leider nicht gut.

Detlef

S-A-L · 2009-05-24T08:06:15.000Z

Ich denke mal, dass Relationen im kleinen Massstab (Maximal Stadtgroesse) nicht so grosse Probleme machen duerften wie Relationen die ueber mehrere Bundeslaender gehen. Da die Wahrscheinlichkeit der Gleichzeitigen Bearbeitung stark sinken duerfte.

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

Rundling · 2009-05-24T08:32:51.000Z

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

Jau!

lutz · 2009-05-24T09:08:24.000Z

warum muß alles so kompliziert gemacht werden?
reicht es nicht aus, das zb. so zu gestallten:

amenity restaurant, biergarten yes

amenity hotel, restaurant yes

amenity einkaufszentrum, blumenladen yes usw.

mfg lutz

Nop · 2009-05-24T10:09:57.000Z

S-A-L:

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

Ja!

Mirko_Küster · 2009-05-24T10:13:01.000Z

dgdg:

Andererseits habe ich hier gerade versucht ein kleines Einkaufszentrum mit ein paar wenigen separaten Läden zu mappen. Da kommen ganz schnell mal 10 Nodes auf kleinstem Raum zusammen (eigentlich alle mit der gleichen Koordinate). Zumindest in Potlatch reicht der maximal Zoom schon nicht mehr aus. Und in JOSM sieht das auch nicht viel übersichtlicher aus.

Sowas wie hier? http://www.openstreetmap.org/?lat=51.18447&lon=11.92808&zoom=16&layers=B000FTF

Da habe ich eher das Problem mit den noch nicht vorhandenen Schlüsseln. In dem Fall fehlte mir die Spielothek, Modeschmuck, Juwelier, reine Lebensmittel wie Schokoladenverkauf… Und dann ist da noch ein Problem. Einige seit Ewigkeiten vorhandenen Schlüssel werden selbst weit und breit alleinstehend seit Jahren nicht gerendert. Und das bringt uns zum Hauptproblem.

Bei den Renderern schleift es einfach gewaltig. Es ist doch klar, dass dort keine Lösung kommt. Man hat daran schlicht noch nicht gerabeitet, so wie man es versäumt die Features auf dem aktuellen Stand zu halten.

Vieles ließe sich schon mit biligsten Mitteln lösen. Ein Beispiel. Aussischtspunkt, Infotafel, Bank auf 4 Quadratmetern. Der Punkt und die Bank hat einen Namen. Malt man hier für die Renderer, müsste man bescheißen. Wenn es dumm läuft braucht es 50m Abstand. Ist das erfassen vor Geodaten? Nein das ist liederliches hinklatschen wie das bei handelsüblichen Karten der Fall ist und OSM praktitisch überflüssig macht, da wir uns hier einen der riesen Vorteile von OSM selbst verbauen.

In dem Fall könnte man alles wunderbar an einen Node pappen. Die Software muss es nur richtig verwerten. Entweder malt sie sich für die Kombination eine Hilfstabelle in denen die Icons nebeneinander gelegt werden, oder man hinterlegt für den Anfang grafisch fertige Iconbalken an, die bei auftreten der Kombinationen gleich so gerendert werden können. Die Renderules sind ja quasi schon halbe Stylesheets. Und jetzt sage keiner, dass es so nicht geht. Das habe ich selbst mit meinen dürftigen Programmierkenntnissen dutzende male in PHP für Webseiten umgesetzt.

Wenn man daran wirklich nachweislich gearbeitet hat, das ganze wirklich aus rein technischen Gründen scheitern sollte, dann kann man sich mal über anderweitige Lösungen unterhalten. Ich bin aber definitiv nicht bereit, das aussitzen von Problemen auf dem Rücken der Mapper auszutragen. Schon garnicht in die Richtung mit komplizierten Hilfskonstrukten, die ein mitmachen für jeden zunichte machen wird.

TEL0000 · 2009-05-24T10:17:19.000Z

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

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.

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.