Hi, Nic Roets wrote: > On Mon, Jun 16, 2008 at 7:45 AM, Jon Bright <[EMAIL PROTECTED]> 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 _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/routing
