[Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)

Guenther Meyer d.s.e at sordidmusic.com
Do Jul 29 21:15:11 UTC 2010


Am Mittwoch 28 Juli 2010, 15:23:35 schrieb steffterra:
> Am 28.07.2010 um 08:05 schrieb Guenther Meyer <d.s.e at sordidmusic.com>:
> > ich weiss nicht, ob ich's sschon mal erwaehnt hatte, aber fuer
> > Fahrspurtagging
> > gab's schon mal ein Konzept, dass ohne separate ways auskommt...
> > Das ist also nichts neues.
> 
> Die seperaten ways helfen hier aber auch bei dem Problem der
> richtungsanhängigen ways und eben nicht nur bei der Abbildung von
> Fahrspuren!
> 
> Aber da Du es erwähnst: hättest Fu bitte einen Link für uns? Danke.
> 

nagel mich nicht drauf fest, aber ich glaub das war das hier:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg59559.html

Generell hatte der qbert biker damals recht interessante Konzepte...



> >> Latte an einem way, der dann ncoh die Gefahr birgt durch ein
> >> einfaches
> >> Drehen des way komplett über den Haufen geschmissen zu werden. Abe
> >> r das
> >> wurde auch alles schon einmal besprochen.
> > 
> > die Drehproblematik ist wirklich hinreichend behandelt; ebenso dass
> > es keines
> > neuen Schemas bedarf, um *diese* in den Griff zu kriegen.
> 
> Das mag für Dich gelten, ich kenne hier aber keine Diskussion des
> letzten Monats, das es zu irgendeinem Konsens brachte.
> 

an das wirst du dich bei OSM gewoehnen muessen ;-)

Es gibt hier leider zu viele Leute, die alles und jeden kritisieren, aber auf 
den Versuch einer konstruktiven Diskussion nicht eingehen.


> Zumal das Thema ja immer wieder aufs neue aufs Tapet gebracht wird ;-)
> 
> Du meinst es gibt kein Problem mit richtungsanhängigen tags, andere
> denken schon. Aus diesem Grund entstand mein Engagement für dieses
> Thema mit der Gruppierung von ways wie im Eingangsposting ausführlich
> geschildert.
> 

Fuer mich ist das Problem hausgemacht. Hat aber auch wieder mal mit 
"gewachsener Struktur" zu tun:

Am Anfang gab es die Richtung des ways, die dann irgendwann zur 
Richtungsanzeige von Einbahnstrassen verwendet wurde. Die Moeglichkeit, diese 
im Editor zu drehen, mag da durchaus noch sinnvoll sein.
Spaeter wurden dann alle moeglichen Tags drangehaengt, und schon gab es die 
ersten Probleme. Inzwischen koennen die Editoren das wohl besser handlen, aber 
das grundlegende Problem bleibt bestehen (ein Editor kann nicht immer jedes 
neue Tag kennen, das hier beruecksichtigt werden muesste).

Deswegen mein Loesungsvorschlag:
Lasst die grundlegende Richtung in Ruhe, diese bleibt die Referenz.
Wenn ein Attribut gedreht werden muss, dann dreht das Attribut, und nicht die 
Referenz, an der noch andere Dinge dranhaengen.
Das ist schnell und einfach machbar.
Nehmt es an, oder auch nicht! Schlagt was besseres vor, oder auch nicht!
Aber meckert nicht nur rum.

sorry fuer den kurzen Ausfall, zurueck zum Thema:

wenn es nur darum geht, das "Richtungsproblem" zu loesen, finde ich deinen 
Vorschlag absoluten Overkill.
Nichtsdestotrotz ist es ein interessantes Konzept, das denke ich, mehr bringen 
kann als die Losloesung von der Richtung.


> Wenn Du diese Diskussion positiv beeinflussen möchtest, bitte ich
> Dich, etwas konstruktiv dazu beizutragen, anstatt hier groß zu
> erklären, dass doch alles in Butter ist. Mache bitte gerne
> _diskussionslos_ so weiter wie bisher, denn im Moment gibt es eh keine
> andere Möglichkeit.
> 
> Aber bitte demotiviere nicht andere, neue, evtl. bessere
> Lösungsansätze zu verfolgen.
> 
Dann hast du mich vielleicht falsch verstanden. Leute demotivieren ist das 
letzte was ich vorhabe. Nur bin ich auch so realistisch, dass ich weiss,
dass es nicht so einfach ist, technisch durchdachte Dinge und vor allem 
Veraenderungen dem OSM-Volk nahezubringen. Das beste Konzept nutzt nunmal 
nichts, wenn es keiner benutzt...

Ich habe uebrigens nie behauptet, das alles in Butter ist. Ganz im Gegenteil, 
bei OSM gibt es jede Menge an Dingen, die verbessert werden koennten und auch 
muessten. Nur ist mein Weg eher der, auf Basis des vorhandenen die einfachste 
Loesung zu finden. Und ich denke, die gibt es fuer viele Dinge durchaus.



 
> > Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache
> > Relation. Die automatische Erstellung durch den Editor aendert daran
> > genau
> > nichts.
> 
> Woher weißt Du dass es nichts anderes ist? Wäre das technisch die
> Lösung, das gewollte so umzusetzen?
> 

Irgendwie musst du die Gruppierung ja in der Datenbank speichern.
Das naheliegendste ist da natuerlich eine einfache Relation.
Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu taggen 
(wahrscheinlich sogar die bessere).


> Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle
> _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/
> sinnvoll), die dieses Model bietet.
> 

wie jetzt, dein Modell?
da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm).
Ich schau's mir an, und versuche dann mal, dasselbe auf "meine" Weise zu 
relaisieren...


> > Warum willst du was neues erfinden, wenn es genau das, was du
> > brauchst, bereits gibt?
> 
> Hmm dann nenne es eine _neue_ Relation, wenn "mein Modell" mit der
> Gruppierung technisch dasselbe wäre.
> Doch sollte sie so umgesetzt Erden, wie es in meinem Eingangsposting
> steht: benutzerfreundlich. Wie es benutzerfreundlich wäre, steht auch
> dort.
> 

richtig, das Frontend ist das wichtige.
Ob sich dahinter drei ways mit ein paar Tags oder nur ein Way mit vielen Tags 
verbergen, ist doch eigentlich egal.


> Hmm kann ja doch noch konstruktiv werden. Hängt ein wenig von Deiner
> Antwort ab. Freue mich auf Deinen Vorschlag zur technischen Umsetzung
> _dieses_ Modells mit einer Relation, die in allen Situationen
> funktioniert.
> 
> Für den Anfang würde mir schon reichen, wenn Du dies anhand der
> Beispiele zeigst, die ich in meinem (vor?)letzten Posting dazu
> beschrieben habe, als ich das bisherige und das tagging im neuen
> Modell erklärt habe.
>
 
das ganze ist ein wenig unuebersichtlich, das liegt aber eher am Medium.
Werd's mir anschaun.


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 198 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20100729/488efdf1/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de