Re: [Tagging] Tagging Digest, Vol 40, Issue 15

[Michael Patrick]

Just my clarification ... we are blessed just about all those bridge types
except the gondola. First,on first glance 'movable' subsumes all the other
movable types. if it is exclusive of those, I might suggest
'movable_other', or something similar (our former I-520 Evergreen Point
bridge had a bulge, which had a 'retractable' span (see
http://ww1.hdnux.com/photos/03/01/47/793032/3/628x471.jpg ). Also, when the
bridge has multiple types of structures and spans, how is that addressed -
i.e. beam, floating, truss, and viaduct probably simultaneously exist on
the same named 'bridge, is each way segment named the same but separately?
Or just the primary distinctive feature? Could you tag the I-90 Bridge from
Seattle to Bellevue as an example (Tunnel - beam - viaduct - float - beam -
etc.)?

Thanks,
Michael Patrick


On Fri, Jan 11, 2013 at 4:00 AM, tagging-requ...@openstreetmap.org wrote:

 Send Tagging mailing list submissions to
 tagging@openstreetmap.org

 To subscribe or unsubscribe via the World Wide Web, visit
 http://lists.openstreetmap.org/listinfo/tagging
 or, via email, send a message with subject or body 'help' to
 tagging-requ...@openstreetmap.org

 You can reach the person managing the list at
 tagging-ow...@openstreetmap.org

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of Tagging digest...


 Today's Topics:

1. Feature Proposal - RFC - roller_coaster key (Deanna Earley)
2. Re: Source tag - deprecated for use on objects? (Deanna Earley)
3. Re: Feature Proposal - RFC - roller_coaster key (Rob Nickerson)
4. Feature Proposal - RFC - Bridge types (Christopher Hoess)
5. Re: Feature Proposal - RFC - Bridge types (Clifford Snow)
6. Re: Feature Proposal - RFC - Bridge types (Christopher Hoess)


 --

 Message: 1
 Date: Thu, 10 Jan 2013 15:58:55 +
 From: Deanna Earley d...@earlsoft.co.uk
 To: tagging@openstreetmap.org
 Subject: [Tagging] Feature Proposal - RFC - roller_coaster key
 Message-ID: 50eee53f.7060...@earlsoft.co.uk
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 Hi all.

 I have proposed the start of the roller_coaster key as way to
 standardise on tagging of roller coaster features. Especially now we're
 getting details enough to be able to include this extra information.

 http://wiki.openstreetmap.org/wiki/Proposed_features/key:roller_coaster

 The initial proposal is just for the track and station values but other
 values will be valid.

 Any and all comments and feedback are welcome on the talk page

 http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/key:roller_coaster

 Many thanks
 (Resent as my original on 2012/12/10 doesn't seem to have been approved)

 --
 Deanna Earley (d...@earlsoft.co.uk)

 web:http://www.earlsoft.co.uk
 phone:  +44 (0)780 8369596



 --

 Message: 2
 Date: Thu, 10 Jan 2013 16:12:11 +
 From: Deanna Earley d...@earlsoft.co.uk
 To: tagging@openstreetmap.org
 Subject: Re: [Tagging] Source tag - deprecated for use on objects?
 Message-ID: 50eee85b.6000...@earlsoft.co.uk
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On 07/01/2013 22:16, Pieren wrote:
  On Mon, Jan 7, 2013 at 9:57 PM, Eckhart W?rner ewoer...@kde.org wrote:
  Except that source-tag-on-object does not work either for real-world
 mapping. Source tags are rarely updated when the source changes.
 
  Eckhart
 
  I think this discussion and previous ones about this topic
  demonstrates one point : sourcing in OSM will never be perfect.
  Because we have elements with history from multiple contributors and
  with attributes from multiple sources. Because we cannot expecte
  people to always have a single source per changeset. Because we cannot
  expect people to always insert or update the tag source each time they
  modify something.

 Exactly.
 A changeset I uploaded the other day had some data realigned with Bing
 (from OS StreetView), local knowledge and GPS traces.

 Doing this with source on changeset would require bits and pieces of
 work, many changesets (no doubt, I'd forget a bit) or a single This
 data came from Bing, GPS, my knowledge, OS streetview, I'll let you
 guess what and where

 This is the reason there are tags like source:name, source:othertag, etc.

 Regarding changing the source when it's realligned, sadly people don't
 do things properly, but that's why we have the history.

 --
 Deanna Earley (d...@earlsoft.co.uk)

 web:http://www.earlsoft.co.uk
 phone:  +44 (0)780 8369596



 --

 Message: 3
 Date: Thu, 10 Jan 2013 19:25:05 +
 From: Rob Nickerson rob.j.nicker...@gmail.com
 To: tagging@openstreetmap.org
 Subject: Re: [Tagging] Feature Proposal - RFC - roller_coaster key
 Message-ID:
 
 cak4yqtmdnjunjnlnjfza+cf_ya2znwo8ibmjfxqnxq_cieo...@mail.gmail.com
 Content-Type: text/plain; charset=iso-8859-1

 

Re: [Tagging] Tagging Digest, Vol 40, Issue 15

[Christopher Hoess]

On Fri, Jan 11, 2013 at 8:52 AM, Michael Patrick geodes...@gmail.com wrote:
 Just my clarification ... we are blessed just about all those bridge types
 except the gondola. First,on first glance 'movable' subsumes all the other
 movable types. if it is exclusive of those, I might suggest 'movable_other',
 or something similar (our former I-520 Evergreen Point bridge had a bulge,
 which had a 'retractable' span (see
 http://ww1.hdnux.com/photos/03/01/47/793032/3/628x471.jpg ). Also, when the
 bridge has multiple types of structures and spans, how is that addressed -
 i.e. beam, floating, truss, and viaduct probably simultaneously exist on the
 same named 'bridge, is each way segment named the same but separately? Or
 just the primary distinctive feature? Could you tag the I-90 Bridge from
 Seattle to Bellevue as an example (Tunnel - beam - viaduct - float - beam -
 etc.)?

Michael,

Comments at the bottom of the proposal have also suggested creating a
separate tag for the types of movable bridge. I think I like the
bridge:movable suggestion made there. (So movable bridges would be
tagged, e.g., bridge=movable; bridge:movable= bascule and so forth.)
That also makes it a little easier to parse for a (hypothetical)
downstream piece of routing software; it doesn't care to learn about
all the different varieties of movable bridge, it just needs to be
able to spot bridges that could open and leave you stuck in a traffic
jam.

In the case of complex bridges, there would be a different way segment
for each type of span the way passed over. (If you have, say, several
consecutive truss spans, I don't see a need to break that into
multiple segments.) This is my approximation for the eastbound lanes
of I-90, moving from west to east. Segment 1 (over roads):
bridge=yes; bridge_type=beam. Segment 2: bridge=yes;
bridge_type=truss. (bridge=viaduct might be OK for this, too;
that's sort of a matter of taste.) Segment 3: bridge=yes;
bridge_type=arch. Segment 4: bridge=yes; bridge_type=floating.
Segment 5: bridge=yes; bridge_type=arch. Segment 6: bridge=yes;
bridge_type=beam.

That seems rather extreme, but in practice, I think people will
largely continue using bridge=yes for most road and highway bridges
and largely concentrate on marking charismatic things like covered
bridges, (stone) arches, and so on; detailed tagging like this example
will probably be the province of bridge aficionados. And this kind of
span-by-span breakdown does have some potential when it comes to
navigation. In bridges crossing navigable estuaries, it's not uncommon
to have a long series of fixed spans with a movable span somewhere in
the middle over the navigation channel. In that case, it's certainly
useful to distinguish between the movable and the fixed spans, as it
defines the location of the channel.

Yours,

-- 
Chris Hoess

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