Render bridge_name

[matthijsmelissen]

We should render lock_name and bridge_name for the name of locks and bridges, respectively.

See also https://trac.openstreetmap.org/ticket/3223.

[HolgerJeromin]

Not a perfect tagging style, but the useful information is there. Should be rendered if the way is long enough. Perhaps reject even a short name on a short way to avoid clutter.

What about tunnel_name? I am on mobile and have not checked if it exists.

[sommerluk]

About bridge_name: Following http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_Name this is still a proposal. One of the comments was, that bridge:name would be a better solution (making possible also bridge:int_name and bridge:alt_name and so on) I think that’s reasonable. It’s more flexible and more coherent and more intuitive. And at taginfo, we have 11 862 bridge:name tags, but only 5 107 bridge_name tags. So I would suggest to ignore bridge_name for rendering and render instead exclusivly bridge:name.

In principle I think the same arguments are also true for locks (but at taginfo we see that lock_name is used often, while lock:name is almost not used).

[dieterdreist]

we should IMHO not encourage this kind of tagging, but rather distinct objects like bridges and locks, and render names for these objects (tag: "name") where appropriate.

[matthijsmelissen]

What if a bridge has a different name from the street that is running over that bridge? Not an uncommon situation.

[dieterdreist]

Il giorno 04/ago/2014, alle ore 01:40, math1985 [email protected] ha scritto:

What if a bridge has a different name from the street that is running over that bridge? Not an uncommon situation.

There is no problem, you'll have a bridge with its name and a road with its name, both will have the default name in the name tag

[matthijsmelissen]

There is no problem, you'll have a bridge with its name and a road with its name, both will have the default name in the name tag

How can you have multiple name tags? Normally you would have a way with highway=primary, name=Main Street, bridge=yes, bridge_name=Old Bridge. How would you represent that?

[pnorman]

I'm not fully up on navigable waterway tagging, not having anything but rivers here. @systemed, thoughts on lock_name?

[systemed]

lock_name is (rightly) the accepted tag for the name of locks.

Typical usage is waterway=canal; name=Staffordshire & Worcestershire Canal; lock=yes; lock_name=Boggs Lock; lock_ref=34

Similarly bridge_name: highway=primary; name=St Ann Way; bridge_name=High Orchard Bridge.

(Incidentally, I was interested to see that the MapOut iOS app renders locks in a different, darker blue than the main channel of waterways - a good bit of design.)

[pnorman]

What's typical for locks on maps for rendering names?

We have bridges with names locally but they generally either have very boring names (e.g. the Granvillle Street Bridge that carries Granvillle Street), are part of a highway without a name, or join two streets with different names and have no clear name for the road itself in that section.

[systemed]

Here's an example of a common printed waterways guide that shows lock names.

[dieterdreist]

2014-08-04 9:25 GMT+02:00 Richard Fairhurst [email protected]:

lock_name is (rightly) the accepted tag for the name of locks.

Typical usage is waterway=canal; name=Staffordshire & Worcestershire
Canal; lock=yes; lock_name=Boggs Lock; lock_ref=34

Similarly bridge_name: highway=primary; name=St Ann Way; bridge_name=High
Orchard Bridge.

I am aware of this tagging scheme which creates implicit instances for
locks and bridges, but I don't think we should encourage this. Instead I
suggest to encourage adding explicit objects, e.g. (just an example)
waterway=lock on a lock, together with name (I guess this will typically be
either a node, or a linear way or an area at the lock position). Similarly
for bridges I would not rely on the bridge attributes for the ways going
over the bridge, but rather prefer having a dedicated bridge object
(man_made=bridge or similar, with tag name on an area or some kind of
relation). This would also solve the problem of "parallel" bridges where
there is just one in reality (and also successive problems occurring
otherwise, like name duplication any time the road had to be split on a
bridge or where several roads go over the same bridge). It would allow for
standard tags rather than namespaces for all attributes (like bridge_ref,
wikipedia:bridge, and what not).

[systemed]

The road over the bridge is called St Ann Way. It's only the bridge structure itself that is called High Orchard Bridge. (Similarly, the canal running through the lock is called the Staffs & Worcs, it's only the lock structure itself that's called Boggs Lock; and so on.)

Therefore both names need to be tagged. Given that locks and bridges are two-dimensional objects (well, 3D really, but you know what I mean), a node on the way isn't enough. So if you're determined to use the name= tag for the bridge, you have two choices:

• Two ways, sharing nodes. Difficult to edit; difficult to render (label collisions etc.); difficult to route (no routing software supports this, to the best of my knowledge); goes against OSM practice.
• Relations. Unnecessarily complicated for the newbie - naming a bridge is a trivial task that should be within the capability of a new mapper in their first five minutes.

Let's not architecture-astronaut this, and just continue to do what thousands of mappers are already doing. Whether the separator is a colon or an underscore or U+1F4A9 I don't really care.

[dieterdreist]

2014-08-04 12:18 GMT+02:00 Richard Fairhurst [email protected]:

The road over the bridge is called St Ann Way. It's only the bridge
structure itself that is called High Orchard Bridge. (Similarly, the canal
running through the lock is called the Staffs & Worcs, it's only the lock
structure itself that's called Boggs Lock; and so on.)

exactly. That's why I suggest to have dedicated objects for locks and
bridges

Therefore both names need to be tagged. Given that locks and bridges are
two-dimensional objects (well, 3D really, but you know what I mean), a node
on the way isn't enough. So if you're determined to use the name= tag for
the bridge, you have two choices:

agreed, both are 3D-objects, let's leave the height out and think polygons.

• Two ways, sharing nodes. Difficult to edit; difficult to render
  (label collisions etc.); difficult to route (no routing software supports
  this, to the best of my knowledge); goes against OSM practice.

in the case of the lock there will indeed be shared nodes (or a
multipolygon relation) if the waterway in that area is mapped as polygon
(area). If it is mapped as a linear way you can overlap the lock area
without sharing nodes. If you don't have a distinct object for the lock,
you'll get other problems later on, e.g. imagine a lock that was added
later to an existing canal. You'll want start_date and lock_start_date then

• basically you'd have to namespace all attributes or rely on
  interpretation instead of unambiguous tag assignment, e.g. bridge_wikipedia
  etc.

(please note that in my previous post when I wrote that the lock could be
represented as node, way or area I was confusing the lock with the lock
gate(s)).

In case of the bridge you won't get shared nodes (maybe you can have them
at the intersection of the bridge outline and the highway way).

• Relations. Unnecessarily complicated for the newbie - naming a
  bridge is a trivial task that should be within the capability of a new
  mapper in their first five minutes.

first you'll have to draw it, then you can simply add name=* etc., which
seems much easier for everyone instead of using cryptic tags like
bridge_name or bridge:name. We don't do that now, and this is creating a
lot of problems. Why are we drawing almost all objects, and only bridges,
which are generally quite important objects, should preferably be mapped
implicitly? That doesn't make sense to me.

Let's not architecture-astronaut this, and just continue to do what
thousands of mappers are already doing. Whether the separator is a colon or
an underscore or U+1F4A9 I don't really care.

I think that bridges are currently still under-architectured, that's why we
get so unsatisfying rendering results (it is not clear from the data how
many bridges there are, you can only say that there is a way over a
bridge). Not so sure about locks (I don't map them in my daily mapping),
but I have the impression that the problem is similar. The thousands of
mappers will also adapt to a superior data model if you convince them.

[systemed]

That's as may be, but completely changing the way that mappers tag one of the most common highway features is a little bit out of scope for this ticket. ;)

[pnorman]

exactly. That's why I suggest to have dedicated objects for locks and bridges

Which is, of course, entirely out of scope for this issue tracker.

[matkoniecz]

Changed it to request rendering bridge_name, lock name is covered by #157

[matthijsmelissen]

I'm not sure that this is no longer necessary now we render man_made=bridge.

[matkoniecz]

I'm not sure that this is no longer necessary now we render man_made=bridge.

Why it would be still necessary? Names of bridges are now rendered and therefore this workaround is no longer necessary.

What would be the pint of rendering name of bridge on the road? Especially as roads on bridges may have their own names, different from name of the bridge.

[dieterdreist]

sent from a phone

Am 28.08.2015 um 20:40 schrieb Mateusz Konieczny [email protected]:

Why it would be still necessary? Names of bridges are now rendered and therefore this workaround is no longer necessary.

What would be the pint of rendering name of bridge on the road? Especially as roads on bridges may have their own names, different from name of the bridge.

+1, bridge_name always was a strange workaround due to the fact that bridges for a very long time had been mapped only implicitly

[jojo4u]

Yes, we have man_made=bridge now, rendering the bridge name on the highway should be unnecessary.

[matthijsmelissen]

Closing per @matkoniecz.