[Routing] [motorway_link] description of direction

[Jon Bright]

Hi,

Nic Roets wrote:
> On Mon, Jun 16, 2008 at 7:45 AM, Jon Bright <jon at siliconcircus.com> wrote:
>>>> signpost=Dortmund, Münster
> 
> I assume the intention was that the routing program outputs some
> instruction like 'Take the Dortmund exit' / 'Take the road makered
> Dortmund'

Sure.  "Follow the signs marked 'Dortmund, Münster'", something like that.

>> I don't really follow how "signpost" is motorcar or motorway-specific or
>> why you couldn't add free-form strings there.  The numbers variant is
> 
> My idea is to allow extremely varied instructions including "Open the
> gate on the left that appears to be locked, but isn't". We don't want
> the software to change it to "Take the Open the gate on the left that
> appears to be locked, but isn't exit"

Hm.  I'd guess we'd want two different tags.  "signpost", for when there 
are signposts and following them is all that's required (reducing the 
data size, the tagging effort and leading to more standardised messages) 
and "instruction" (or "text") for when more detailed information about 
what to do is necessary (which could apply equally to tiny African 
trails and large, complex motorway junctions).

>> I don't mind adding relations, but looking ahead for signpost messages
>> is a bad plan, imho.
> 
> The most complicated tagging I see is something like
> <relation>
> to=id type=way
> via=id type=node // Redundant ?

An example from Boulogne-sur-Mer of where this wouldn't be redundant:

http://maps.google.com/maps?f=q&hl=en&geocode=&q=boulogne-sur-mer&ie=UTF8&ll=50.697355,1.612533&spn=0.004574,0.009398&z=17&iwloc=addr

(Sorry, the data's not complete in OSM.)  The tightly looping curve from 
the N416 to the N1 forbids lorries but allows cars and bikes, so 
different sets of users would be needing different guidance.

> from=id type=way
> warn1=id type=node message='Keep right'
> warn2=id type=node message='Take the middle lane'
> warn3=id type=node message='Keep left'
> 
> The thing is that the routing program will need to know what the
> ultimate destination is, which intermediate ways it has chosen and
> from that determine what instructions to provide to the user.
> Examining the intermediate ways to determine which relations are
> active is what I describe as looking ahead.

OK, agreed.

How about something like this:

<relation>
<member type="way" role="from" ref="123" />
<member type="way" role="to" ref="321" />
<member type="way" role="via" ref="654" /> // optional
<tag k="type" v="route_info" />
<tag k="step" v="0" /> // I guess could be optional for one-step things
<tag k="lane" v="3" /> // optional
<tag k="node" v="12345" /> // The node which this action is relevant to,
                            // not the node where the announcement should
                            // start, which most things will work out by
                            // themselves
<tag k="signpost" v="Dortmund, Münster" /> // optional
<tag k="text:en" v="Take the rightmost lane" /> // optional
</relation>

<relation>
<member type="way" role="from" ref="123" />
<member type="way" role="to" ref="321" />
<member type="way" role="via" ref="654" />
<tag k="type" v="route_info" />
<tag k="step" v="1" />
<tag k="lane" v="0" />
<tag k="node" v="56789" />
<tag k="signpost" v="Dortmund" />
<tag k="text:en" v="Take the left lane" />
</relation>

Which could equally be:

<relation>
<member type="way" role="from" ref="123" />
<member type="way" role="to" ref="321" />
<tag k="type" v="route_info" />
<tag k="step" v="0" />
<tag k="lane" v="2" />
<tag k="signpost" v="Boulogne Ports" />
</relation>

...or...

<relation>
<member type="way" role="from" ref="123" />
<member type="way" role="to" ref="321" />
<tag k="type" v="route_info" />
<tag k="step" v="0" />
<tag k="text" v="Go through the gate, hoot like an owl, etc." />
</relation>

So, for things that want programmatic descriptions of stuff (and if I'm 
going to get to the stage where I can have Celine Dion's voice croon at 
me from some OSM-based portable nav device that my heart must go 
straight on*, programmatic stuff is needed), we can tag 
programmatically.  For more detailed descriptions where they're needed, 
we can add text.  And finally, we can detail signposts.  If we ever get 
to the stage of having photos of useful nav aids in the DB, we could add 
that too, possibly as another <member>.

I've changed via from node to way because there may well be no "forking" 
node which is unique to the route being travelled.  Intermediate nodes 
which only have two connections will, I imagine, frequently be ignored 
by routing software, as they're not relevant to the calculations at 
hand.  Whereas two different ways to do the same thing implies a fork, 
which implies two different way IDs.

* To think of a slightly less terrifying prospect, think of things like 
http://discord.ensued.net/rightlane.png - a nav system might have a 
range of these available for display and would need to programmatically 
know which to use.

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com