Re: [Tagging] Feature Proposal - RFC - via_ferrata

[bredy]

For me all path are equiped with some technical equipment are via ferrata,
because with this tag you see in the map that in that point the path have
some technical equipment. And because the first scale grade of via ferrata
say "No equipment requaired".

All map write cross in the point with technical equipment.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-RFC-via-ferrata-tp5776186p5779437.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[fly]

Am 28.09.2013 15:10, schrieb Christopher Hoess:

Hey

> I'm officially agnostic on that question! I know both "tunnel=culvert"
> and "culvert=yes" are used much more frequently in OSM than
> "bridge=culvert"; I think one of them predominates, but I don't know which.

tunnel=yes; culvert=yes ?

I would go for tunnel=culvert.

fly

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[Martin Koppenhoefer]

2013/9/30 fly 

> tunnel=yes; culvert=yes ?
>
> I would go for tunnel=culvert.
>


how would you tag a culvert in a tunnel?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[fly]

Am 30.09.2013 15:51, schrieb Martin Koppenhoefer:
> 
> 2013/9/30 fly  >
> 
> tunnel=yes; culvert=yes ?
> 
> I would go for tunnel=culvert.

man_made=pipeline; location=tunnel/underground and probably a tunnel
relation.
I am not sure about tunnel=* as it depends on the tunnel.

cu
fly



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[Martin Koppenhoefer]

2013/9/30 fly 

>
> man_made=pipeline; location=tunnel/underground and probably a tunnel
> relation.



IMHO a culvert is different from a pipeline as a pipeline is an end to end
connection.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[fly]

Am 30.09.2013 16:12, schrieb Martin Koppenhoefer:
> 
> 2013/9/30 fly  >
> 
> 
> man_made=pipeline; location=tunnel/underground and probably a tunnel
> relation.
> 
> 
> 
> IMHO a culvert is different from a pipeline as a pipeline is an end to
> end connection.

OK, I get your point but you have to admit that most of the times we
have to deal with the standard situation and not with multi-use tunnels.

So, there might be situations where tunnel=* and culvert=yes might be
ok. I wonder which waterway tag you choose though. ? waterway=culvert ?

cheers
fly


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - via_ferrata

[fly]

Am 30.09.2013 10:37, schrieb bredy:
> For me all path are equiped with some technical equipment are via ferrata,
> because with this tag you see in the map that in that point the path have
> some technical equipment. And because the first scale grade of via ferrata
> say "No equipment requaired".
> 
> All map write cross in the point with technical equipment.

I understand your point in diversifying climbling and other routes with
required equipment but I would not use highway=* for this.

I think it is much easier to either add no highway tag at all and/or
highway=path plus sac_scale and add extra information as via_ferrata=*
and subtags.

cu
fly


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[François Lacombe]

2013/9/30 fly 

>
> OK, I get your point but you have to admit that most of the times we
> have to deal with the standard situation and not with multi-use tunnels.
>

That's because multi-use tunnels are not so mapped in OSM.
On the other hand, be sure we can encounter many cases of multi-use tunnels
in the world.

Security galleries, parallel of road or train tunnels are more and more
used for power transit and telecommunication cables roll out for instance.

Far more globally, hosting a feature inside another is the central question.
Are we forced to use relations ?


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[Philip Barnes]

And canal tunnels, there is usually a towpath through the same tunnel, but we 
have to map them as separate tunnels, then there are double track railway 
tunnels.

Phil (trigpoint)
--

Sent from my Nokia N9



On 30/09/2013 15:42 François Lacombe wrote:





2013/9/30 fly 



OK, I get your point but you have to admit that most of the times we
have to deal with the standard situation and not with multi-use tunnels.



That's because multi-use tunnels are not so mapped in OSM.

On the other hand, be sure we can encounter many cases of multi-use tunnels in 
the world.


Security galleries, parallel of road or train tunnels are more and more used 
for power transit and telecommunication cables roll out for instance.


Far more globally, hosting a feature inside another is the central question.

Are we forced to use relations ?




François Lacombe

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[fly]

Am 30.09.2013 17:27, schrieb Philip Barnes:
> On 30/09/2013 15:42 François Lacombe wrote:
>> 2013/9/30 fly > 
>> 
>> OK, I get your point but you have to admit that most of the times we
>> have to deal with the standard situation and not with multi-use tunnels.
>>
>> That's because multi-use tunnels are not so mapped in OSM.
>> On the other hand, be sure we can encounter many cases of multi-use
>> tunnels in the world.
>> 
>> Security galleries, parallel of road or train tunnels are more and more
>> used for power transit and telecommunication cables roll out for instance.
>> 
>> Far more globally, hosting a feature inside another is the central question.
>> Are we forced to use relations ?

> And canal tunnels, there is usually a towpath through the same tunnel,
> but we have to map them as separate tunnels, then there are double track
> railway tunnels.

Wait a minute we are talking about culverts and not about general
tunnels. These are not well mapped and lots of tunnel relations are
missing but thats a different story. Not talking about tunnel systems
either.

The question asked was "how to tag a culvert in a tunnel" and better why
can it make sense to use tunnel=yes plus culvert=yes.

cu
fly



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[Martin Koppenhoefer]

2013/9/30 Philip Barnes 

> And canal tunnels, there is usually a towpath through the same tunnel, but
> we have to map them as separate tunnels, then there are double track
> railway tunnels.





IMHO this is the same as for bridges: we don't have a general standard how
to map a bridge or a tunnel, all we (there are exceptions, speaking about
the general consensus how "normal" mapping is done) currently do is
attaching an attribute to a road (or sth. else) stating that it is on a
bridge or in a tunnel, but we do not map the bridge or tunnel itself.

The solution could be a bridge object or a tunnel object (could be either
geometry or a relation) which would represent the actual structure, would
get tags like name (name of the bridge / tunnel, not of the road, i.e.
goodbye bridge_name), and so on. In the case of geometry this would be an
area outlining the feature, in the case of relations I think there is
already a proposal, but not very much used.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[fly]

Am 29.09.2013 16:27, schrieb bredy:
> The automated_external_defibrillator proposal has now been stable for some
> time. It 
> is therefore time to announce the voting on this proposal. 
> 
> http://wiki.openstreetmap.org/wiki/Proposed_features/automated_external_defibrillator
> 
>   

Major problem I find is that using a abbreviation is not the way we tag
in OSM and it is often misleading.

Please change the tag into some human readable words and let software do
the abbreviation.

Thanks
fly


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[fly]

Am 30.09.2013 18:19, schrieb Martin Koppenhoefer:
> 
> 2013/9/30 Philip Barnes mailto:p...@trigpoint.me.uk>>
> 
> And canal tunnels, there is usually a towpath through the same
> tunnel, but we have to map them as separate tunnels, then there are
> double track railway tunnels.

> 
> IMHO this is the same as for bridges: we don't have a general standard
> how to map a bridge or a tunnel, all we (there are exceptions, speaking
> about the general consensus how "normal" mapping is done) currently do
> is attaching an attribute to a road (or sth. else) stating that it is on
> a bridge or in a tunnel, but we do not map the bridge or tunnel itself.
> 
> The solution could be a bridge object or a tunnel object (could be
> either geometry or a relation) which would represent the actual
> structure, would get tags like name (name of the bridge / tunnel, not of
> the road, i.e. goodbye bridge_name), and so on. In the case of geometry
> this would be an area outlining the feature, in the case of relations I
> think there is already a proposal, but not very much used.

Sure, man_made=bridge/tunnel for the outline and bridge/tunnel relation
which are often both needed.

fly


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[François Lacombe]

Ok fly, sorry for this sidetrack on the main thread ;)

Nevertheless, +1 for separating structures (bridges, tunnel) from features
(roads, rails, ...).

But all this (tunnels, bridges, culverts) need a better support of layering
and extra attributes like elevation beside lat & lon.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2013/9/30 fly 

> Am 30.09.2013 18:19, schrieb Martin Koppenhoefer:
> >
> > 2013/9/30 Philip Barnes  p...@trigpoint.me.uk>>
> >
> > And canal tunnels, there is usually a towpath through the same
> > tunnel, but we have to map them as separate tunnels, then there are
> > double track railway tunnels.
>
> >
> > IMHO this is the same as for bridges: we don't have a general standard
> > how to map a bridge or a tunnel, all we (there are exceptions, speaking
> > about the general consensus how "normal" mapping is done) currently do
> > is attaching an attribute to a road (or sth. else) stating that it is on
> > a bridge or in a tunnel, but we do not map the bridge or tunnel itself.
> >
> > The solution could be a bridge object or a tunnel object (could be
> > either geometry or a relation) which would represent the actual
> > structure, would get tags like name (name of the bridge / tunnel, not of
> > the road, i.e. goodbye bridge_name), and so on. In the case of geometry
> > this would be an area outlining the feature, in the case of relations I
> > think there is already a proposal, but not very much used.
>
> Sure, man_made=bridge/tunnel for the outline and bridge/tunnel relation
> which are often both needed.
>
> fly
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[Philip Barnes]

On Mon, 2013-09-30 at 18:22 +0200, fly wrote:
> Am 29.09.2013 16:27, schrieb bredy:
> > The automated_external_defibrillator proposal has now been stable for some
> > time. It 
> > is therefore time to announce the voting on this proposal. 
> > 
> > http://wiki.openstreetmap.org/wiki/Proposed_features/automated_external_defibrillator
> > 
> >   
> 
> Major problem I find is that using a abbreviation is not the way we tag
> in OSM and it is often misleading.
> 
> Please change the tag into some human readable words and let software do
> the abbreviation.
> 
> Thanks
> fly
+1

I added the same observation to the wiki discussion. Abbreviations are
always prone to misinterpretation.

Phil ( trigpoint)



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[bredy]

+1 infact in italiy the abbreviation is DAE, only the symbol is same in all
state.

I'm not the writer of this proposal, but it's possible to change it now that
the vote it start?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-automated-external-defibrillator-tp5779375p5779481.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - via_ferrata

[bredy]

the via ferrata have different scale of difficult respect the sac_scale, but
I'm not the writer of this proposal. I only want to proceed with it.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-RFC-via-ferrata-tp5776186p5779482.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[Matthijs Melissen]

On 30 September 2013 18:22, fly  wrote:

> Major problem I find is that using a abbreviation is not the way we tag
> in OSM and it is often misleading.
>

We do use abbreviations for keys/values: for example mtb, bmx, hgv, psv,
url, rcn.

In this particular case, I think more people have familiarity with the
abbreviation than with the full term, so I see here nothing wrong with
sticking to the abbreviation. Or are you proposing to start using
uniform_resource_locator as well?

-- Matthijs
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[François Lacombe]

This proposal sounds unclear to me : It says the tag to use is currently
under discussion, so what are we voting for ?

Not to mention the abbreviation problem...

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2013/9/30 Matthijs Melissen 

> On 30 September 2013 18:22, fly  wrote:
>
>> Major problem I find is that using a abbreviation is not the way we tag
>> in OSM and it is often misleading.
>>
>
> We do use abbreviations for keys/values: for example mtb, bmx, hgv, psv,
> url, rcn.
>
> In this particular case, I think more people have familiarity with the
> abbreviation than with the full term, so I see here nothing wrong with
> sticking to the abbreviation. Or are you proposing to start using
> uniform_resource_locator as well?
>
> -- Matthijs
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[Martin Koppenhoefer]

2013/9/30 Matthijs Melissen 

> In this particular case, I think more people have familiarity with the
> abbreviation than with the full term, so I see here nothing wrong with
> sticking to the abbreviation.



-1

the fact that other tags haven't been chosen well or particularly
understandable for non-english mappers (rcn,psv,hgv,...) in the past
doesn't imply we have to continue...


cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - via_ferrata

[fly]

Am 30.09.2013 18:55, schrieb bredy:
> the via ferrata have different scale of difficult respect the sac_scale, but
> I'm not the writer of this proposal. I only want to proceed with it.

You can use both if needed and I have no problem via_ferrata_scale=*.

fly


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[John F. Eldredge]

On 09/30/2013 11:59 AM, Matthijs Melissen wrote:
On 30 September 2013 18:22, fly > wrote:


Major problem I find is that using a abbreviation is not the way
we tag
in OSM and it is often misleading.


We do use abbreviations for keys/values: for example mtb, bmx, hgv, 
psv, url, rcn.


In this particular case, I think more people have familiarity with the 
abbreviation than with the full term, so I see here nothing wrong with 
sticking to the abbreviation. Or are you proposing to start using 
uniform_resource_locator as well?


-- Matthijs



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
I think that it would be better to use the spelled-out term 
automated_external_defibrillator rather than the acronym AED, to avoid 
potential confusion.  The OpenStreetMap database is intended for 
international use, and the spelled-out term is less ambiguous. It would 
be possible for the wiki to link the AED acronym to the page listing the 
spelled-out term, and the wiki could explain why the spelled-out term is 
preferable for tagging.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[Philip Barnes]

On Mon, 2013-09-30 at 18:59 +0200, Matthijs Melissen wrote:
> On 30 September 2013 18:22, fly  wrote:
> Major problem I find is that using a abbreviation is not the
> way we tag
> in OSM and it is often misleading.
> 
> 
> We do use abbreviations for keys/values: for example mtb, bmx, hgv,
> psv, url, rcn.

Those are mostly familiar terms, where the abbreviation is better known
than the actual words. BMX and URL in particular. I do not know MTB or
RCN are however. 
> 
> 
> In this particular case, I think more people have familiarity with the
> abbreviation than with the full term, so I see here nothing wrong with
> sticking to the abbreviation. Or are you proposing to start using
> uniform_resource_locator as well?

Outside of the medical profession I doubt anyone has  heard the term
AED. I certainly hadn't until I saw it in this thread. There may be some
familiarity with them within factories, we have some at work. Then again
I work for a large company with a strong health and safety culture, and
a large number of employees to split the cost over.

Outside of factories and the like, they are still very rare. I know of
one, in Loppington, a small North Shropshire village, but thats because
I am an observant mapper. It has a numerical keylock on it, so imagine
that maybe you phone 999 and ask for the code? 

I have never seen one anywhere else, and yes I have looked and keep my
eyes open. Most people will not be aware such things even exist.

Phil (trigpoint) 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[Brad Neuhauser]

Just FYI, they are becoming more common in public places (offices, malls,
airports, schools, etc) in the US.


On Mon, Sep 30, 2013 at 1:22 PM, Philip Barnes  wrote:

> On Mon, 2013-09-30 at 18:59 +0200, Matthijs Melissen wrote:
> > On 30 September 2013 18:22, fly  wrote:
> > Major problem I find is that using a abbreviation is not the
> > way we tag
> > in OSM and it is often misleading.
> >
> >
> > We do use abbreviations for keys/values: for example mtb, bmx, hgv,
> > psv, url, rcn.
>
> Those are mostly familiar terms, where the abbreviation is better known
> than the actual words. BMX and URL in particular. I do not know MTB or
> RCN are however.
> >
> >
> > In this particular case, I think more people have familiarity with the
> > abbreviation than with the full term, so I see here nothing wrong with
> > sticking to the abbreviation. Or are you proposing to start using
> > uniform_resource_locator as well?
>
> Outside of the medical profession I doubt anyone has  heard the term
> AED. I certainly hadn't until I saw it in this thread. There may be some
> familiarity with them within factories, we have some at work. Then again
> I work for a large company with a strong health and safety culture, and
> a large number of employees to split the cost over.
>
> Outside of factories and the like, they are still very rare. I know of
> one, in Loppington, a small North Shropshire village, but thats because
> I am an observant mapper. It has a numerical keylock on it, so imagine
> that maybe you phone 999 and ask for the code?
>
> I have never seen one anywhere else, and yes I have looked and keep my
> eyes open. Most people will not be aware such things even exist.
>
> Phil (trigpoint)
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[bredy]

One year of no discussion and now that start the vote many problem. AED is
actual in use in OSM then I don't see problem.
If user don't like this can vote no to proposal.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-automated-external-defibrillator-tp5779375p5779504.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[Philip Barnes]

On Mon, 2013-09-30 at 11:57 -0700, bredy wrote:
> One year of no discussion and now that start the vote many problem. AED is
> actual in use in OSM then I don't see problem.
> If user don't like this can vote no to proposal.
> 
Its not about voting No, the proposal is a good one. Its about making it
understandable and not using an abbreviation that is not in popular
usage.

Phil (trigpoint)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (automated_external_defibrillator)

[Martin Koppenhoefer]

2013/9/30 Philip Barnes 

> Its not about voting No, the proposal is a good one. Its about making it
> understandable and not using an abbreviation that is not in popular
> usage.
>



there are common guidelines for tagging that discourage abbreviations, for
good reason.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Bridge types)

[Dave Swarthout]

I'm a total newbie to OSM proposals and discussions like this one so let me
apologize in advance for this off topic post.

I'm still following along but I'm wondering how a person will ever see this
sort of detail in a map. I confess I mostly work on OSM so I can get
detailed and correct maps for use in a Garmin GPS in the areas I live and
work in, Alaska and Thailand primarily. I get all my maps from Lambertus at
garmin.openstreetmap.nl and while his rendering isn't perfect it serves my
purposes well enough.

Can one of you suggest a site where I can see details like those you
mention?


On Mon, Sep 30, 2013 at 11:34 PM, François Lacombe <
francois.laco...@telecom-bretagne.eu> wrote:

> Ok fly, sorry for this sidetrack on the main thread ;)
>
> Nevertheless, +1 for separating structures (bridges, tunnel) from features
> (roads, rails, ...).
>
> But all this (tunnels, bridges, culverts) need a better support of
> layering and extra attributes like elevation beside lat & lon.
>
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
>
> 2013/9/30 fly 
>
>> Am 30.09.2013 18:19, schrieb Martin Koppenhoefer:
>> >
>> > 2013/9/30 Philip Barnes > p...@trigpoint.me.uk>>
>> >
>> > And canal tunnels, there is usually a towpath through the same
>> > tunnel, but we have to map them as separate tunnels, then there are
>> > double track railway tunnels.
>>
>> >
>> > IMHO this is the same as for bridges: we don't have a general standard
>> > how to map a bridge or a tunnel, all we (there are exceptions, speaking
>> > about the general consensus how "normal" mapping is done) currently do
>> > is attaching an attribute to a road (or sth. else) stating that it is on
>> > a bridge or in a tunnel, but we do not map the bridge or tunnel itself.
>> >
>> > The solution could be a bridge object or a tunnel object (could be
>> > either geometry or a relation) which would represent the actual
>> > structure, would get tags like name (name of the bridge / tunnel, not of
>> > the road, i.e. goodbye bridge_name), and so on. In the case of geometry
>> > this would be an area outlining the feature, in the case of relations I
>> > think there is already a proposal, but not very much used.
>>
>> Sure, man_made=bridge/tunnel for the outline and bridge/tunnel relation
>> which are often both needed.
>>
>> fly
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging