[OSM-talk] Bridge Names

Matt matt at openforeveryone.co.uk
Tue Oct 2 11:58:03 BST 2007


I agree, Bridge objects look like a better solution, splitting a way to 
make a bridge would then become unnecessary, but how would one describe 
the location and shape of the bridge?

Creating a new way to represent a bridge seems to be a good solution but 
for bridges carrying only one way this would lead to ways on top of 
other ways. Would this be difficult using the current editors?

Would it be better just to use a relation object to describe a bridge 
object that describes something along the lines of  'carries way 200 
from node 100 to 120 and way 201 from node 116 to 106' and then tag the 
relation with the bridge name, reference and any other relevant features?

This might look something like:

<relation id="99">
    <member type="way" ref="200" role="carry_a" />
    <member type="node" ref="100" role="from_a" />
    <member type="node" ref="20" role="to_a" />
    <member type="way" ref="201" role="carry_b" />
    <member type="node" ref="16" role="from_b" />
    <member type="node" ref="26" role="to_b" />
  <tag k="type" v="bridge" />
  <tag k="name" v="My Bridge" />
</relation>

But this use of the "role" attribute might look a little ugly to some.

Matt

Frederik Ramm wrote:
> Hi,
>
>   
>>> For example, I could imagine creating a way for the bridge only, and
>>> another way for the road that crosses it, and then a relation saying
>>> "this road uses that bridge". This would give us the additional
>>> advantage of being able to model multiple ways going over the same
>>> bridge.
>>>       
>> Is this not just causing ways to become what segments were supposed to once do?
>>     
>
> Not in my opinion, no.
>
> It is a method of creating objects in the database that represent
> objects in the real world. You have a bridge in the real world - you
> create a bridge object in the database. (As opposed to "a piece of a
> way that is tagged to say it leads over a bridge".) Unlike before, the
> bridge would now have a life of its own in the database, and you could
> add any tags to the bridge *or* the ways using the bridge. You can
> even start mapping bridges properly (e.g. from sat images), showing
> their true extent. And if someone deletes the way that crosses the
> bridge, the bridge remains.
>
> I'm not saying we have to do it, I'm just saying it is a possibility.
>
>   
>> I do see an advantage to this approach, essentially that 'segments'
>> are now essentially several nodes long, rather than 2.
>>     
>
> Bye
> Frederik
>
>   





More information about the talk mailing list