[Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService

2008-07-15 Diskussionsfäden Henry Loenwind
Bernd Wurst wrote:
 Voll dafür. So lange mein proprietäres Navi mehr Infos über eine Kreuzung 
 liefert als wir erfassen können, läuft was schief. :)

Das war auch bei mir der Auslöser mir diese Gedanken zu machen.

 Zu deinem Vorschlag vom letzten Mal:
 rechts halten und links halten sollte auch noch möglich sein, für den 
 Fall 
 wenn sich eine mehrspurige Straße teilt und es kein Abbiegen nach halb-rechts 
 ist. 

Jepp, hab ich drin.

Ebenso habe ich jetzt komplexere Kreuzungen vorgesehen, also welche, die 
viele Nodes, Abbiegespuren, Überleitungen etc. haben. Ein Autobahnkreuz 
läßt sich jetzt als eine Kreuzung beschreiben. Eine Kreuzung mit 6 
Straßen, 9 Radwegen, 4 Fußgängertunneln und einem Zebrastreifen auch.

 Wichtig wäre IMHO, dass du das was du letztes mal geschrieben hast (plus das 
 oben) in eine Wiki-Seite umformulierst. Ich wäre dein erster User dieser 
 Relation.

Erst mal hier, da bekomm ich mehr Verrisse ...ähm... Feedback ;)

 Und für die Kritiker: Eine 08/15-Kreuzung, die das Navi auch korrekt aus den 
 Daten interpretieren kann, muss man natürlich nicht so erfassen. Nur weil das 
 letztes Mal gleich als das-ist-so-viel-Arbeit-Argument kam. :)

Genau. Hab ich jetzt auch oben reingechrieben.

So, hier der Entwurf. Ich muss nochmal nachschauen, ob ich Crossing 
lasse, oder ob Junction o.ä. besser wäre.

=Advanced Crossing Relation

==General

The advanced crossing relation (ACR) is intended to describe all 
possible transitions from one street to another that can happen at a 
crossing. As such it is quite complicated, but it is not intended to 
replace existing relations or tags, but to help model crossings that can 
not be described correctly using these. So if a simple turn restriction 
relation is enough for your crossing, just use that easier tun 
restriction relation.

==About the model

The ACR sees a crossing as a number of ways that have exactly 2 ends and 
a number of nodes that connect those ways. Any possible path then can be 
describes as a series of ways and nodes, starting and ending with a way. 
For any of those paths, the ACR describes how a human driving 
(cycling/riding/walking/...) along it would experience it. Or, to name 
the expected usage, what a satnav (a.k.a. GPS, a.k.a. navi) would have 
to announce so the human would take that path.

==Type

The type of the relation is ACR.

==Roles

All ways and nodes belonging to the crossing (that includes the ways 
that only have one end at the crossing) are included in the relation 
exactly once. Their tag must be an unique (within the relation) string 
containing numbers and letter only. Please note that that is a 
difference to other relations that have fixed role names.

==Tags

Every tag describes one path in the crossing, that may be a complete 
path through the crossing, or just one step. Generally speaking one path 
corresponds to one announcement of the satnav system.

===Tag Keys

Tag keys are constructed from the role names. Again here the ACR differs 
from other relations that use fixed key names.

To construct the key, concatenate the role names of all parts of the 
path, separated with an underscore (_).

===Tag Values

The value describes the path. Possible values are:

no - this path cannot be taken (this is the default for all thinkable 
paths that are not modeled).

auto - this path will be taken automatically by following the road. A 
satnav does not need (nor should) announce anything.

straight - to take this path, you must go straight ahead, leaving the 
road you're on.

right, left - turn right or left to take this path.

sharp right, sharp left - make a sharp turn. Use this only if you've 
already have used up the right/left or if it would be difficult to 
follow the satnav's directions with a simple left/right announcement.

half right, half left - see sharp

uturn - this is a u-turn at a position where it is allowed and possible. 
Use this one for special u-turn lanes. The satnav should announce this 
as a definite instruction.

possible uturn - here it is possible to turn, but there are no special 
lanes or signs. The satnav should announce this with care, e.g. by 
adding if possible to it's instruction. (Please note that a pedestrian 
can always and everywhere do a u-turn. No need to model that...)

exit right, exit left - this is an exit from a motorway or trunk road, 
or some construct that looksfeels the same.

right lane, left lane, center lane - here the driver has to chose the 
right lane, that later will move away from the main body of the street. 
No turning involved.

parallel lane - this is the special lane at large motorway crossings 
that runs parallel to the main body and leads to the real exits. Hint: 
To use such a crossing you'd need to follow exit, exit or exit, 
parallel, exit.

roundabout 1, roundabout 2, etc. - this is a path leading through a 
roundabout, the number says which exit from the roundabout to the, e.g. 
leave the roundabout at the 3rd exit. As an exception to the 

Re: [Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService

2008-07-15 Diskussionsfäden Frederik Ramm
Hi,

 Tag keys are constructed from the role names. Again here the ACR  
 differs
 from other relations that use fixed key names.

 To construct the key, concatenate the role names of all parts of the
 path, separated with an underscore (_).

Das waer fuer mich ein ganz grosser showstopper. Das schreit ja  
geradezu nach bitte bitte erzeuge inkonsistente Daten, mit denen  
keiner mehr was anfangen kann.

Wenn Du spezielle Tags an Ways haengen willst, die nur innerhalb der  
Relation gelten, dann hast Du zwei Moeglichkeiten: (a) Relations in  
der Datenbank so erweitern, dass es statt role=x beliebig viele  
Tags pro Member geben kann. Oder (b) ueberall da, wo Du Ways in  
Deiner Relation hast, nutze stattdessen Relations (d.h. die Member  
Deiner Kreuzungsrelation sind Relationen, die jeweils einen Way  
enthalten sowie alle Spezialtags dazu).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09 E008°23'33




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de


Re: [Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService

2008-07-15 Diskussionsfäden Henry Loenwind
Frederik Ramm wrote:

 To construct the key, concatenate the role names of all parts of the
 path, separated with an underscore (_).

 Wenn Du spezielle Tags an Ways haengen willst, die nur innerhalb der  
 Relation gelten, dann hast Du zwei Moeglichkeiten: (a) Relations in  
 der Datenbank so erweitern, dass es statt role=x beliebig viele  

Nicht wirklich realistisch, oder?

 Tags pro Member geben kann. Oder (b) ueberall da, wo Du Ways in  
 Deiner Relation hast, nutze stattdessen Relations (d.h. die Member  
 Deiner Kreuzungsrelation sind Relationen, die jeweils einen Way  
 enthalten sowie alle Spezialtags dazu).

Und das erzeugt bei einer normalen X-Kreuzung 17(!) Relationen, wenn man 
sie komplett erfasst. Solche Monster wollte ich eigentlich vermeiden, 
das kann kein Mensch mehr warten.

cu
Henry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de


Re: [Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService

2008-07-15 Diskussionsfäden Frederik Ramm
Hallo,

 Und das erzeugt bei einer normalen X-Kreuzung 17(!) Relationen, wenn man 
 sie komplett erfasst. Solche Monster wollte ich eigentlich vermeiden, 
 das kann kein Mensch mehr warten.

Deine vorgeschlagene Relation auch nicht.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09 E008°23'33

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de


Re: [Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService

2008-07-15 Diskussionsfäden Andreas Jacob
Am Dienstag, 15. Juli 2008 20:04:36 schrieb Frederik Ramm:
 Hallo,

  Und das erzeugt bei einer normalen X-Kreuzung 17(!) Relationen, wenn man
  sie komplett erfasst. Solche Monster wollte ich eigentlich vermeiden,
  das kann kein Mensch mehr warten.

 Deine vorgeschlagene Relation auch nicht.

Ich halte so etwas schon für wartbar. Allerdings bedürfte es dafür wohl ein 
sehr cleveres grafisches Frontend. Ich stelle mir das in etwa so vor, dass 
man sich die Kreuzung im Baukastenprinzip aus Grundbausteinen zusammen setzen 
kann, und im Hintergrund dann die entsprechenden Relationen erzeugt werden. 
Umgekehrt muss sich natürlich aus den Relationen auch wieder das 
Kreuzungsbild erzeugen lassen - eigentlich logisch.

Gruß Andreas

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de


Re: [Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService

2008-07-15 Diskussionsfäden Bodo Meissner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas Jacob wrote, on 15.07.2008 20:54:
| Am Dienstag, 15. Juli 2008 20:04:36 schrieb Frederik Ramm:
|
| Und das erzeugt bei einer normalen X-Kreuzung 17(!) Relationen, wenn man
| sie komplett erfasst. Solche Monster wollte ich eigentlich vermeiden,
| das kann kein Mensch mehr warten.
| Deine vorgeschlagene Relation auch nicht.
|
| Ich halte so etwas schon für wartbar. Allerdings bedürfte es dafür
wohl ein
| sehr cleveres grafisches Frontend.

Wenn man sowieso ein Frontend braucht, dann ist es egal, ob da alle
Fahrtmöglichkeiten mit seltsamen Schlüsseln in eine Relation gestopft
werden oder 17 einzelne Relationen erzeugt/bearbeitet werden.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh9G3sACgkQnMz9fgzDSqd6dwCeLLTxIDS6m24XyoNOm/Bsqm5M
+DYAmwaWWsGB8a91plIOGqa4/NTbt3H6
=jiji
-END PGP SIGNATURE-

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de