Elemente mit mehreren gleichwertigen Tags/Features

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.

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.