[OSM-talk] Bridge Names

[David Earl]

If it is too complicated, they just won't get added. Even now, most 
bridges are missing, there are just crossing ways.

I think a range of solutions is desirable so the simplest cases remain 
simple and the complex cases can be described.

My hierarchy would be

(1) exactly as now: a way is marked as a bridge. (A simplification would 
be to assume layer=1 for ways marked bridge=yes unless otherwise stated).

(2) a relation marked as a bridge groups several ways, where the ways 
define the bridge. This would allow rendering of a single bridge 
carrying more than one way (e.g. a road and adjacent cycle track, or two 
carriageways of a dual carriageway), and/or would allow a bridge to be 
named independently of the way(s). No need for role, but otherwise much 
as Matt's original example, but the ways are still split at the ends of 
the bridge.

(3) something more complicated for weird bridges where the bridge shape 
doesn't match the ways it carries or other complexities, for example a 
way describing the footprint of the bridge linked as one role in a 
relation, the ways crossing it as others and so on.

David


On 02/10/2007 11:58, Matt wrote:
> 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
>>
>>   
> 
> 
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>