[Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jo]

2012/7/10 Rainer Kluge <rkluge50 at web.de>

> Hallo Jochen,
>
>
> On 10.07.2012 08:13, Jochen Topf wrote:
>
>> Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
>> Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.
>>
>
> Das liegt weniger am Konzept "Relation" als an der Komplexität mancher
> Anwendungsfälle, die wir mit Relationen in der Datenbank abbilden.
> Softwaretechnisch sind Relationen unproblematisch, auch mit einem
> Perl-Skript und einem XML-Extrakt kann man die Member von geschachtelten
> Relationen recht einfach ermitteln. Problematisch ist in der Regel der
> Umgang mit den Daten, sowohl für den Mapper als auch für den Entwickler.
> Für den Entwickler ist eine Relation allemal komfortabler als einzelne
> Knoten und Wege, die über identische Tags verknüpft sind.
>
> Auf der Mapper-Seite sehe ich das Problem in der Regel weniger im
> Datenmodell als im GUI des Editors. Wenn das Datenmodell die Realität und
> die Denkweise des Nutzers abbildet, dann versteht das auch jeder. Wer es
> nicht versteht, der hat auch den abzubildenden Anwendungsfall nicht
> verinnerlicht und sollte die Finger davon lassen, so wie ich von
> ÖPNV-Relationen. Aber dass eine Straße oder ein Wanderweg aus mehreren
> Abschnitten bestehen können, die man zusammenfasst und dass man den Namen
> nur einmal dem zusammengefassten Objekt zuweist, das versteht jeder. Wenn
> nicht, dann sollte er sich auf das Mappen von einfachen POIs beschränken.
>
> Ein echtes Problem sehe ich beim GUI. Selbst für den relativ simplen Fall
> von Routen-Relationen gibt es mW keine vernünftige Unterstützung und ich
> könnte auch nicht definieren, wie so etwas aussehen könnte.
>
> Das gilt auch auch für eine Tag-basierte Lösung. Je komplexer die Fälle
> werden, um so mehr (redundante) Tags muss Otto Normalmapper an jedes kleine
> Wegstück oder Gebäude hängen, Tags, deren Existenz, Syntax und Semantik
> sich ihm erst durch intensives Wiki-Studium erschließt. Man wird
> entgegenhalten: dann soll er diese Tags halt erst mal weg lassen, jemand,
> der es weiß, wird die dann schon erfassen. Dieser jemand ist dann aber
> sicher auch in der Lage mit Relationen umzugehen.
>
> Solange es keine zufriedenstellenden GUI-Lösungen für die komplexen
> Anwendungsfälle gibt, taugt der Hinweis auf den Normalmapper weder als
> Argument für noch gegen Relationen. Hier kam ja schon der Vorschlag, wer
> ein neues Konzept vorschlage, möge auch den Algorithmus für die Auswertung
> liefern. Wichtiger wäre, dass er beschreibt, wie es im Editor so umgesetzt
> werden kann, dass auch IT-unbedarfte Nutzer damit umgehen können.
>

Um es mich einfacher zu machen mit die Fahrradnetzwerke um zu gehen habe
ich in JOSM mapcss verwendet. So sieht es jetzt aus wie in Potlatch. Das
vorteil ist aber das ich die ein und ausschalten kann. Also wenn ich auf
Wandernetzwerke arbeite mach ich sichtbar, wenn Fahrradnetzwerke mit Knoten
schalte ich die ein. Und das geht auch gut mit OPNV-Netzwerke und ihre
Haltestellen. Fuer die Haltestellen kann man dan noch einfach waehlen ob
man die Namen oder die Zonen (zone numbers), oder etwas anderes sichtbar
machen will und sogar in unterschiedliche Farben.

Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls
in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das
warscheinlich noch etwas laenger dauern...

Polyglot