Re: [Tagging] How to Tag Steps in a Bridleway

[Jo]

That doesn't seem very helpful for cycling users of the map or its routers.
If there is a blue round sign with a bicycle on it, I'd call that
designated, or a blue rectangular one. Or the pavement is in a pinkish
colour (here in Belgium). If I find a sandy track in the forest, where it's
obvious horses are galloping there on a regular basis, I know to stay away
from them. One because it's very tiresome to advance on them, but more
importantly it's dangerous for cyclist, horseback rider AND horse when a
collision happens at galloping speeds.

Jo

On Mon, Apr 29, 2024, 17:28 Jass Kurn  wrote:

>
>
> On Mon, 29 Apr 2024 at 10:03, Peter Neale via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> It is "bicycles=yes" and not "bicycles=designated" because, for a
>> bridleway   https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbridleway
>> "Cyclists also have a right, unless the local authority makes orders to
>> the contrary ...The local authority is not obliged to ensure
>> suitability for bicycles, unlike for foot or horse users."#
>>
>
>
> Disagree with that, I always map a Public Bridleway as bicycle=designated.
> Cyclists have a statutory right to use these ways, which should be meaning
> behind the designated. The fact there is no requirement to maintain a
> Public Bridleway to a standard acceptable to all cyclists, does not impact
> on the right to use the way. It's a secondary matter that does not fall
> under "access". Or looking at this in another way. The fact a Public
> Footpath does not have to meet standards that would allow ALL pedestrians
> to use them, but does not mean a public footpath should be tagged foot=yes
>
> Jass
> ___
> 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] How to Tag Steps in a Bridleway

[Jo]

I was wondering about that myself. They seem to be 'long' steps. So a horse
wouldn't have too much trouble with them. Also parallel with it on the
other side of the small river there is a cycleway with no steps. That one
is on Mapillary.

Jo

Op ma 29 apr 2024 om 00:15 schreef Graeme Fitzpatrick :

> Completely aside from mapping them in OSM, but how do horses handle the
> steps in the bridleway?
>
> Thanks
>
> Graeme
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] edit war related to tagging of a bus-only major road

[Jo]

Maybe you can find middle ground in highway=tertiary? highway=service is a
possibility, but I'd usually use it in bus stations or on stretches that
are exclusively used by buses, that don't even have sidewalks for example.

Polyglot

On Wed, Dec 9, 2020 at 5:41 PM Jmapb  wrote:

> On 12/9/2020 9:36 AM, Michael Tsang wrote:
>
> > Des Voeux Road Central is considered one of the most important roads
> > in the area which I
> > tagged it as highway=secondary, however another editor has repeatedly
> > changed
> > it to highway=service on the fact that that road is closed to motor
> > vehicles
> > except buses
> >
> Hi Michael, my understanding is that this type of access restriction has
> no bearing on the correct value of the highway tag. That doesn't mean
> that a bus-only road can't be 'highway=service', but my armchair opinion
> is that this one deserves a higher classification,
> 'highway=unclassified' at minimum. Obviously a local consensus would be
> best.
>
> As far as the access tags go, from your description I imagined
> 'access=private' plus 'bus=yes', and 'foot=yes' if there's sidewalk that
> isn't mapped separately. The segment you linked to (
> https://www.openstreetmap.org/way/242113655 ) has tags that are a bit
> more complicated; no doubt they make sense in context. It's worth
> noting, though, that it currently allows bicycle traffic.
>
> Here's a photo showing the bus-only segment and signed restrictions --
>
> https://www.mapillary.com/app/?pKey=V6xCvni7pFMnBkHoXfZcIw=photo=22.2806400619=114.16016743519445=17=0.5090835219500857=0.5090768471784388
>
> Jason
>
>
>
>
> ___
> 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] Inclined elevators

[Jo]

I couldn't resist looking them up.

This is a very long one and there is even an operator in it:
https://www.youtube.com/watch?v=Wh0NxK6sslM

Most are the length of the escalators they are adjacent to.

Polyglot

On Thu, Dec 3, 2020 at 2:19 PM Guillaume Chauvat 
wrote:

> Hi,
>
> My apologies if this has already been discussed several times or if it's
> not the place to ask.
>
> I was mapping a public inclined elevator in a dedicated building (it only
> contains the elevator and three parallel escalators). This is really a
> standard elevator running parallel to the escalators, not a funicular.
> Those elevators are very common here in Sweden, although most often inside
> metro stations.
>
> What is the best way of mapping it? I used a way tagged with
> highway=elevator as the wiki recommends, but this does not seem supported
> by any tool (the default editor, the map on openstreetmap.org, or osmand).
>
> Regards,
> Guillaume
> --
> Sent from my Android device with K-9 Mail. Please excuse my
> brevity.___
> 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] Animal trails

[Jo]

>
>
> +1, same here for wild boars. “animal path” does not provide sufficient
> information what kind of object it is, because these paths are quite
> different depending on the animals. The mentioned cow paths are probably
> always suitable for humans, while others may not.
>
> your feet may sink into the mud though and beware the BULL :-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Jo]

They do NOT mean the same thing. How they differ has already been mentioned
2 or 3 times in this thread.

On Tue, Oct 20, 2020, 06:59 Robert Delmenico  wrote:

> Essentially though, they mean the same thing:
> man_made=bridge is for areas
> bridge=yes is for ways
>
> Both refer to to say there is a bridge and each assumes each others
> meaning - I wouldn't think we would use natural=bridge.
>
> Perhaps there could be a proposal to change man_made=bridge to bridge=yes
>
> On Tue, 20 Oct 2020, 3:41 pm Mateusz Konieczny via Tagging, <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> 20 paź 2020, 00:52 od rob...@rtbk.com.au:
>>
>> Perhaps the use of man_made could be dropped all together as it is
>> somewhat superfluous.
>>
>> Ie. man_made=bridge is the same as bridge=yes
>>
>> Are you aware that we have bridge=yes
>> and man_made=bridge used with a
>> different meaning?
>>
>>
>> Perhaps all of the existing man_made=[value] tags should be changed to
>> [value]=yes
>>
>>
>> Rob
>>
>> On Tue, 20 Oct 2020, 9:46 am Robert Delmenico, 
>> wrote:
>>
>> Please read this article:
>>
>>
>> https://www.btb.termiumplus.gc.ca/tpv2guides/guides/pep/index-fra.html?lang=fra=usage_7_gender_neutral_writing_questions_usage
>>
>>
>>
>>
>> 'Not really, and "man_made" does not mean that it was made by males.'
>>
>> Yes it does. Why would society also use women-made?
>>
>>
>>
>>
>>
>> 'It seems to me that a lot of males like to speak for women on these
>> issues.
>> Why? Can't they speak for themselves?'
>>
>> Hence why I said who am I to decide!
>>
>>
>>
>>
>> 'Marriam-webster:
>> ==
>> Definition of man-made
>> : manufactured, created, or constructed by human beings'
>>
>>
>>
>> https://www.weforum.org/agenda/2016/03/not-everything-is-man-made-13-amazing-inventions-you-can-thank-women-for/
>>
>> Should we use the term man-made if it is made entirely by women?
>>
>> Also, check out the translations in the Collins dictionary - what do you
>> notice?
>> https://www.collinsdictionary.com/amp/english/man-made
>>
>>
>>
>>
>>
>> 'As I mentioned in another email, we do use terms such as midwife.'
>>
>> Midwife actually translates as 'with woman'. The wife part relates to the
>> person giving birth.
>>
>>
>>
>>
>>
>> On Tue, 20 Oct 2020, 8:44 am Niels Elgaard Larsen, 
>> wrote:
>>
>> Robert Delmenico:
>> >
>> > I originally put the call out really to gauge if there was much
>> interest in changing
>> > the term man_made because of its use of 'man', and was interested in
>> hearing the
>> > thoughts from other mappers as really this proposal isn't just mine. If
>> there was no
>> > interest I would just abandon it and move on - that's how the system
>> works yeah?
>> >
>> > Here's my thoughts based on the feedback received so far
>> >
>> > Regardless of the origin of the term, the current use of 'man' is to
>> identify adult
>> > males.
>>
>> Not really, and "man_made" does not mean that it was made by males.
>>
>> > I don't think the use of 'man_made' offends women, but who am I to
>> decide that as I
>> > am a adult male.
>>
>> It seems to me that a lot of males like to speak for women on these
>> issues.
>> Why? Can't they speak for themselves?
>>
>> > I feel that by using any masculine or feminine terms where a suitable
>> alternative
>> > exists instills the stereotypes based on these terms.
>>
>> Marriam-webster:
>> ==
>> Definition of man-made
>> : manufactured, created, or constructed by human beings
>> ==
>>
>>
>> > We don't refer to firefigters as firemen anymore, not do we refer to
>> airline
>> > attendants as airline hostesses. The world is changing and OSM should
>> adapt to these
>> > changes if there is enough interest from the OSM community.
>>
>> As I mentioned in another email, we do use terms such as midwife.
>>
>>
>> --
>> Niels Elgaard Larsen
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Proposal to change key:man_made to key:human_made

[Jo]

Bridge=yes is used as a complementary tag on highway and railway objects.

I was thinking of construction=bridge, but that already has another meaning
in OSM context.

I really don't like artificial as a tag. Maybe constructed_by_people...
Can't say that I like that either.

Polyglot

On Tue, Oct 20, 2020, 00:55 Robert Delmenico  wrote:

> Perhaps the use of man_made could be dropped all together as it is
> somewhat superfluous.
>
> Ie. man_made=bridge is the same as bridge=yes
>
> Perhaps all of the existing man_made=[value] tags should be changed to
> [value]=yes
>
>
> Rob
>
> On Tue, 20 Oct 2020, 9:46 am Robert Delmenico,  wrote:
>
>> Please read this article:
>>
>>
>> https://www.btb.termiumplus.gc.ca/tpv2guides/guides/pep/index-fra.html?lang=fra=usage_7_gender_neutral_writing_questions_usage
>>
>>
>>
>>
>> 'Not really, and "man_made" does not mean that it was made by males.'
>>
>> Yes it does. Why would society also use women-made?
>>
>>
>>
>>
>>
>> 'It seems to me that a lot of males like to speak for women on these
>> issues.
>> Why? Can't they speak for themselves?'
>>
>> Hence why I said who am I to decide!
>>
>>
>>
>>
>> 'Marriam-webster:
>> ==
>> Definition of man-made
>> : manufactured, created, or constructed by human beings'
>>
>>
>>
>> https://www.weforum.org/agenda/2016/03/not-everything-is-man-made-13-amazing-inventions-you-can-thank-women-for/
>>
>> Should we use the term man-made if it is made entirely by women?
>>
>> Also, check out the translations in the Collins dictionary - what do you
>> notice?
>> https://www.collinsdictionary.com/amp/english/man-made
>>
>>
>>
>>
>>
>> 'As I mentioned in another email, we do use terms such as midwife.'
>>
>> Midwife actually translates as 'with woman'. The wife part relates to the
>> person giving birth.
>>
>>
>>
>>
>>
>> On Tue, 20 Oct 2020, 8:44 am Niels Elgaard Larsen, 
>> wrote:
>>
>>> Robert Delmenico:
>>> >
>>> > I originally put the call out really to gauge if there was much
>>> interest in changing
>>> > the term man_made because of its use of 'man', and was interested in
>>> hearing the
>>> > thoughts from other mappers as really this proposal isn't just mine.
>>> If there was no
>>> > interest I would just abandon it and move on - that's how the system
>>> works yeah?
>>> >
>>> > Here's my thoughts based on the feedback received so far
>>> >
>>> > Regardless of the origin of the term, the current use of 'man' is to
>>> identify adult
>>> > males.
>>>
>>> Not really, and "man_made" does not mean that it was made by males.
>>>
>>> > I don't think the use of 'man_made' offends women, but who am I to
>>> decide that as I
>>> > am a adult male.
>>>
>>> It seems to me that a lot of males like to speak for women on these
>>> issues.
>>> Why? Can't they speak for themselves?
>>>
>>> > I feel that by using any masculine or feminine terms where a suitable
>>> alternative
>>> > exists instills the stereotypes based on these terms.
>>>
>>> Marriam-webster:
>>> ==
>>> Definition of man-made
>>> : manufactured, created, or constructed by human beings
>>> ==
>>>
>>>
>>> > We don't refer to firefigters as firemen anymore, not do we refer to
>>> airline
>>> > attendants as airline hostesses. The world is changing and OSM should
>>> adapt to these
>>> > changes if there is enough interest from the OSM community.
>>>
>>> As I mentioned in another email, we do use terms such as midwife.
>>>
>>>
>>> --
>>> Niels Elgaard Larsen
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
> 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] Proposal to change key:man_made to key:human_made

[Jo]

It would be best to first consider the consequences of such a change. Weigh
the benefits against what we lose in time (humanhours?) and
resources/energy. And then there is still the point that many objects will
get new timestamps for a change that's not really a change.

Anyway, artificial sounds like made up to me. artificial=dyke, not really a
dyke, but it looks like it.

man_made has the advantage of being succinct. Most people will immediately
understand what is meant by it. Almost nobody will think women were not
involved in the creation of the feature.

Polyglot

On Mon, Oct 19, 2020 at 12:42 PM Robert Delmenico 
wrote:

> Nice investigating Nathan,
>
> I would be open to using artificial instead of human_made.
>
>
> Would it be best to change the proposal or start a second proposal?
> Change man_made= to artificial=
>
> Rob
>
>
> On Mon, 19 Oct 2020 at 21:14, nathan case  wrote:
>
>> Pros and cons aside, “human-made” is not a term that is in current
>> widespread usage. As a native English GB speaker, I find it clunky and
>> somewhat distracting.
>>
>> A better gender neutral term might be “artificial”, which is already a
>> synonym for “man-made” and is already widely used.
>>
>> Indeed, the Handbook of Nonsexist Writing suggests: "artificial,
>> handmade, hand-built, synthetic, manufactured, fabricated, machine-made,
>> and constructed" as options instead of man-made. Presumably the majority
>> (if not all) of OSM "man-made" tags relate to objects which are not
>> naturally occurring. Therefore "artificial" seems to hold.
>>
>> Other sources:
>> https://writingcenter.unc.edu/tips-and-tools/gender-inclusive-language/
>>
>> https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0053.html
>> https://dictionary.cambridge.org/dictionary/english/man-made
>>
>> An issue may arise if artificial is already being used as a tag however.
>>
>> Best,
>>
>> Nathan
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Proposal to change key:man_made to key:human_made

[Jo]

Are they really people who see the tag man_made and go:

Oh, women didn't contribute to this! The tag says so...

Isn't it obvious that man in this case stands for its original meaning:
Mensch, ser humano, etc?

Changing it in the database is trivially easy. Letting everyone who uses
OSM data know and give them a chance to adapt to the change, not so much.

Polyglot

On Mon, Oct 19, 2020 at 10:16 AM Shawn K. Quinn 
wrote:

> On 10/18/20 16:04, Oliver Simmons wrote:
> > Doing this would make over 3M objects have their date updated to the
> > present, when the last meaningful change may have been over 5 years ago.
> > It creates the illusion of data being up-to-date when all that was
> > changed was a tag key.
>
> +1
>
> In addition to this, it increases revision and changeset counts needlessly.
>
> --
> Shawn K. Quinn 
> http://www.rantroulette.com
> http://www.skqrecordquest.com
>
> ___
> 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] [OSM-talk] maps/navigation data source

[Jo]

House numbers are also exhaustively complete in The Netherlands.


Jo

On Sat, Sep 5, 2020, 22:46 Niels Elgaard Larsen  wrote:

> Martin Koppenhoefer:
> >
> >
> > sent from a phone
> >
> >> On 5. Sep 2020, at 16:43, ben.ki...@mail.de wrote:
> >>
> >> Which are the world regions OSM data is better in? Which are world
> regions OSM data is equal good?
> >
> >
> > generally urban areas and touristic monuments are covered, few countries
> have good coverage in the country side, but there’s a lot to do everywhere,
> it may also depend on the kind of data ;-)
> >
> > For example housenumbers are incomplete even in the most active
> countries,
>
>
> House numbers are complete in Denmark. They are imported from official
> data.
>
> --
> Niels Elgaard Larsen
>
> ___
> 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] Rail segment in a bike route

[Jo]

I added that it's not needed for ferries in the proposal on the wiki. It's
alright if we have more than 1 way to do it and leave it up to the mapper
to decide whether to map as a single route relation or split them and use a
superroute relation.

If I start doing a bicycle tour, I want to know in advance if I'll be able
to cycle the whole stretch, or if there will be waiting time for other
means of transportation. I would also like to know if there will be a fee
to pay for these means of transportation and whether it's necessary to
hurry, in case there is only 1 per x hours, or they don't function at
night. By using separate route relations, it becomes possible to add
opening hours and a frequency/period on them.

Jo

On Mon, Aug 31, 2020 at 8:52 AM Peter Elderson  wrote:

> 'transport' role, 'transportation' role ... is this in use and
> documented somewhere?
>
> In bicycle routes, when the ways are different for the two directions,
> forward and backward roles apply to the ways in the relation.  If a
> transfer/transport/transportation is to be applied as well, how would you
> combine this? Multiple roles are currently not defined.
>
> Vr gr Peter Elderson
>
>
> Op ma 31 aug. 2020 om 08:16 schreef Warin <61sundow...@gmail.com>:
>
>> On 31/8/20 8:25 am, Volker Schmidt wrote:
>> > Keep it simple, if the simple solution does not limit you.
>> >
>>
>> Agreed. I see no reason why a way as a member of a simple route relation
>> could not have the role 'transport'.
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Rail segment in a bike route

[Jo]

We've been doing it for years for ferries, so in that case I agree that
it's somewhat overkill.

In the case of transferring to a train or bus, I don't think it's overkill
to be explicit about it though. It seems really odd to me to have railway
ways or highway ways with bicycle=no|use_sidepath as members of a bicycle
route relation, which is what would happen in the case of the specialised
bus that takes bicycles through a tunnel.

The alternative is that we change the validator to disregard ways with the
role transport. Sure that would work as well.

Jo

On Mon, Aug 31, 2020 at 8:16 AM Warin <61sundow...@gmail.com> wrote:

> On 31/8/20 8:25 am, Volker Schmidt wrote:
> > Keep it simple, if the simple solution does not limit you.
> >
>
> Agreed. I see no reason why a way as a member of a simple route relation
> could not have the role 'transport'.
>
>
>
> ___
> 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] Rail segment in a bike route

[Jo]

I know that it's possible to look at the type of the child route relation,
but I don't think it hurts to be explicit about it in the role.

Regarding the 'complex' bicycle relations. I want to use superroutes for
other purposes as well.

Jo

On Sun, Aug 30, 2020 at 7:53 PM Peter Elderson  wrote:

> Route hierarchy is regular practice.The parent relation holds child
> relations. This is the case for many types of route,
>
> As far as I can see, there are two new elements:
>
> 1. A child relation (route section) can be of a different route type.
> 2. Provided it has a special role
>
> Since the type is in the child relation, you don't need to specify that in
> the role.
>
> This is valid for many route types. I would suggest not to present it as a
> complex bicycle route, but as a way to incorporate transfer sections of
> different types in routes of any transport type.
>
> Best, Peter Elderson
>
>
> Op zo 30 aug. 2020 om 17:52 schreef Jo :
>
>> Hi Francesco,
>>
>> I started a proposal on the wiki:
>>
>> https://wiki.openstreetmap.org/wiki/More_complex_cycle_routes
>>
>> It will probably need to be moved to the proposal name space, but we can
>> work on it over there before putting it up for a vote.
>>
>> Jo
>>
>> On Sun, Aug 30, 2020 at 3:09 PM Francesco Ansanelli 
>> wrote:
>>
>>> I saw your changes... LGTM.
>>> Thanks!
>>> It would be great to have a page to document your proposal.
>>> Cheers
>>> Francesco
>>>
>>> Il dom 30 ago 2020, 12:03 Jo  ha scritto:
>>>
>>>> Hi Francesco,
>>>>
>>>> I will create the superroute and route relations as an example. If you
>>>> don't like the solution, feel free to remove those relations again
>>>> afterwards. I will only fix a small error in the original relation, but
>>>> keep it for now, so both solutions can be analysed next to each other.
>>>>
>>>> I don't really like the idea of a role 'transfer' on all those railway
>>>> ways in a single route relation. In the case of your example, there is only
>>>> a single railway, but in theory there could be one for each direction of
>>>> travel of the train. So if you want to describe that in the route relation,
>>>> you would need role forward/backward in the route relation, which cannot be
>>>> combined with role transfer.
>>>>
>>>> Jo
>>>>
>>>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli <
>>>> franci...@gmail.com> wrote:
>>>>
>>>>> Dear Polyglot,
>>>>>
>>>>> it sounds good to me. But what roles do you suggest for such
>>>>> superroute?
>>>>> Many thanks
>>>>> Francesco
>>>>>
>>>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>>>> scritto:
>>>>>
>>>>>> How would you feel about mapping it with a superroute relation?
>>>>>>
>>>>>> The superroute would then contain 3 route relations.
>>>>>>
>>>>>> 1 for the first part by bicycle
>>>>>> 1 for the middle part by train
>>>>>> 1 for the last part by bicycle
>>>>>>
>>>>>> If we give the train part a different role in the superroute, we can
>>>>>> make it such that the continuity line in JOSM is still drawn.
>>>>>>
>>>>>> This solution might also work to indicate that certain parts of a
>>>>>> bicycle route need to be done on foot. Although creating separate route
>>>>>> relations for such short stretches may feel like overkill.
>>>>>>
>>>>>> The other 'interruption' of a bicycle route I can think of, is where
>>>>>> a ferry needs to be taken. In theory this could also be a funicular. In
>>>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>>>> it's unlikely we'll create a route relation for this, but not
>>>>>> impossible/unthinkable).
>>>>>>
>>>>>> In JOSM PT_Assistant there will soon be a convenience button to
>>>>>> extract route relations from route or superroute relations, to make a
>>>>>> conversion from route to superroute+route relations easier to do.
>>>>>>
>>>>>> Polyglot
>>>

Re: [Tagging] Rail segment in a bike route

[Jo]

Hi Francesco,

I started a proposal on the wiki:

https://wiki.openstreetmap.org/wiki/More_complex_cycle_routes

It will probably need to be moved to the proposal name space, but we can
work on it over there before putting it up for a vote.

Jo

On Sun, Aug 30, 2020 at 3:09 PM Francesco Ansanelli 
wrote:

> I saw your changes... LGTM.
> Thanks!
> It would be great to have a page to document your proposal.
> Cheers
> Francesco
>
> Il dom 30 ago 2020, 12:03 Jo  ha scritto:
>
>> Hi Francesco,
>>
>> I will create the superroute and route relations as an example. If you
>> don't like the solution, feel free to remove those relations again
>> afterwards. I will only fix a small error in the original relation, but
>> keep it for now, so both solutions can be analysed next to each other.
>>
>> I don't really like the idea of a role 'transfer' on all those railway
>> ways in a single route relation. In the case of your example, there is only
>> a single railway, but in theory there could be one for each direction of
>> travel of the train. So if you want to describe that in the route relation,
>> you would need role forward/backward in the route relation, which cannot be
>> combined with role transfer.
>>
>> Jo
>>
>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
>> wrote:
>>
>>> Dear Polyglot,
>>>
>>> it sounds good to me. But what roles do you suggest for such superroute?
>>> Many thanks
>>> Francesco
>>>
>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>> scritto:
>>>
>>>> How would you feel about mapping it with a superroute relation?
>>>>
>>>> The superroute would then contain 3 route relations.
>>>>
>>>> 1 for the first part by bicycle
>>>> 1 for the middle part by train
>>>> 1 for the last part by bicycle
>>>>
>>>> If we give the train part a different role in the superroute, we can
>>>> make it such that the continuity line in JOSM is still drawn.
>>>>
>>>> This solution might also work to indicate that certain parts of a
>>>> bicycle route need to be done on foot. Although creating separate route
>>>> relations for such short stretches may feel like overkill.
>>>>
>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>> it's unlikely we'll create a route relation for this, but not
>>>> impossible/unthinkable).
>>>>
>>>> In JOSM PT_Assistant there will soon be a convenience button to extract
>>>> route relations from route or superroute relations, to make a conversion
>>>> from route to superroute+route relations easier to do.
>>>>
>>>> Polyglot
>>>>
>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>> franci...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> a new example that could benefit of this proposal:
>>>>>
>>>>> https://www.openstreetmap.org/relation/10605853
>>>>>
>>>>> Can someone please go ahead and make a proposal?
>>>>>
>>>>> Many thanks
>>>>> Best regards
>>>>> Francesco
>>>>>
>>>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>>>> scritto:
>>>>>
>>>>>> For the record, I think a transfer role is a generic solution
>>>>>> for the issue raised here, applicable to the cable car transfer and other
>>>>>> types of transfer in routes, but I will not propose a new role value any
>>>>>> time soon.
>>>>>>
>>>>>> Anyone who wants to do it has my support, though.
>>>>>>
>>>>>> Vr gr Peter Elderson
>>>>>>
>>>>>>
>>>>>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>>>>>> dieterdre...@gmail.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> sent from a phone
>>>>>>>
>>>>>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>>>>>> >
>>>>>>> > Normal OSM access is assumed to be access=yes, where some access
>>>>>>> is restricted then in OSM it should be marked *=no.
>>>>>>>
>>>>>>>
>>>>>>> for roads access=yes is assumed, it is not necessarily the default
>>>>>>> for all kind of features.
>>>>>>>
>>>>>>>
>>>>>>> Cheers Martin
>>>>>>> ___
>>>>>>> Tagging mailing list
>>>>>>> Tagging@openstreetmap.org
>>>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>>>
>>>>>> ___
>>>>>> Tagging mailing list
>>>>>> Tagging@openstreetmap.org
>>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>>
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>>> 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] Rail segment in a bike route

[Jo]

I was in a hurry to go and eat and forgot to say this:

In the Italian station, I added a footway through the station building and
across the rails. That's not correct, of course. This should be improved
with more detail. Is there a tunnel to cross the railway? A bridge? Do
people have to risk it at an unsupervised level_crossing?

If there is a tunnel or a bridge, most likely there is also a part with
stairs.

Possibly the train always arrives near the station building and never on
the southern track as it is mapped now?

I now added a role transfer in the superroute relation. Maybe a role
transfer_on_foot, transfer_by_train, transfer_by_ferry,
transfer_by_funicular would be more descriptive? For this we would need to
create a proposal, but at the moment I'm mostly interested in your
opinions. Creating a proposal and following up on it is a lot of work. I'm
not sure if I have the stamina for it. But anyone can do it, so if you feel
like it, go ahead.

Jo

On Sun, Aug 30, 2020 at 12:39 PM Jo  wrote:

> I uploaded my way to solve this:
>
> https://www.openstreetmap.org/relation/11560387
>
> Polyglot
>
> On Sun, Aug 30, 2020 at 12:03 PM Jo  wrote:
>
>> Hi Francesco,
>>
>> I will create the superroute and route relations as an example. If you
>> don't like the solution, feel free to remove those relations again
>> afterwards. I will only fix a small error in the original relation, but
>> keep it for now, so both solutions can be analysed next to each other.
>>
>> I don't really like the idea of a role 'transfer' on all those railway
>> ways in a single route relation. In the case of your example, there is only
>> a single railway, but in theory there could be one for each direction of
>> travel of the train. So if you want to describe that in the route relation,
>> you would need role forward/backward in the route relation, which cannot be
>> combined with role transfer.
>>
>> Jo
>>
>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
>> wrote:
>>
>>> Dear Polyglot,
>>>
>>> it sounds good to me. But what roles do you suggest for such superroute?
>>> Many thanks
>>> Francesco
>>>
>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>> scritto:
>>>
>>>> How would you feel about mapping it with a superroute relation?
>>>>
>>>> The superroute would then contain 3 route relations.
>>>>
>>>> 1 for the first part by bicycle
>>>> 1 for the middle part by train
>>>> 1 for the last part by bicycle
>>>>
>>>> If we give the train part a different role in the superroute, we can
>>>> make it such that the continuity line in JOSM is still drawn.
>>>>
>>>> This solution might also work to indicate that certain parts of a
>>>> bicycle route need to be done on foot. Although creating separate route
>>>> relations for such short stretches may feel like overkill.
>>>>
>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>> it's unlikely we'll create a route relation for this, but not
>>>> impossible/unthinkable).
>>>>
>>>> In JOSM PT_Assistant there will soon be a convenience button to extract
>>>> route relations from route or superroute relations, to make a conversion
>>>> from route to superroute+route relations easier to do.
>>>>
>>>> Polyglot
>>>>
>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>> franci...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> a new example that could benefit of this proposal:
>>>>>
>>>>> https://www.openstreetmap.org/relation/10605853
>>>>>
>>>>> Can someone please go ahead and make a proposal?
>>>>>
>>>>> Many thanks
>>>>> Best regards
>>>>> Francesco
>>>>>
>>>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>>>> scritto:
>>>>>
>>>>>> For the record, I think a transfer role is a generic solution
>>>>>> for the issue raised here, applicable to the cable car transfer and other
>>>>>> types of transfer in routes, but I will

Re: [Tagging] Rail segment in a bike route

[Jo]

I uploaded my way to solve this:

https://www.openstreetmap.org/relation/11560387

Polyglot

On Sun, Aug 30, 2020 at 12:03 PM Jo  wrote:

> Hi Francesco,
>
> I will create the superroute and route relations as an example. If you
> don't like the solution, feel free to remove those relations again
> afterwards. I will only fix a small error in the original relation, but
> keep it for now, so both solutions can be analysed next to each other.
>
> I don't really like the idea of a role 'transfer' on all those railway
> ways in a single route relation. In the case of your example, there is only
> a single railway, but in theory there could be one for each direction of
> travel of the train. So if you want to describe that in the route relation,
> you would need role forward/backward in the route relation, which cannot be
> combined with role transfer.
>
> Jo
>
> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
> wrote:
>
>> Dear Polyglot,
>>
>> it sounds good to me. But what roles do you suggest for such superroute?
>> Many thanks
>> Francesco
>>
>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>> scritto:
>>
>>> How would you feel about mapping it with a superroute relation?
>>>
>>> The superroute would then contain 3 route relations.
>>>
>>> 1 for the first part by bicycle
>>> 1 for the middle part by train
>>> 1 for the last part by bicycle
>>>
>>> If we give the train part a different role in the superroute, we can
>>> make it such that the continuity line in JOSM is still drawn.
>>>
>>> This solution might also work to indicate that certain parts of a
>>> bicycle route need to be done on foot. Although creating separate route
>>> relations for such short stretches may feel like overkill.
>>>
>>> The other 'interruption' of a bicycle route I can think of, is where a
>>> ferry needs to be taken. In theory this could also be a funicular. In
>>> Antwerpen there is a special bus service that takes cyclists through a
>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>> it's unlikely we'll create a route relation for this, but not
>>> impossible/unthinkable).
>>>
>>> In JOSM PT_Assistant there will soon be a convenience button to extract
>>> route relations from route or superroute relations, to make a conversion
>>> from route to superroute+route relations easier to do.
>>>
>>> Polyglot
>>>
>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> a new example that could benefit of this proposal:
>>>>
>>>> https://www.openstreetmap.org/relation/10605853
>>>>
>>>> Can someone please go ahead and make a proposal?
>>>>
>>>> Many thanks
>>>> Best regards
>>>> Francesco
>>>>
>>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>>> scritto:
>>>>
>>>>> For the record, I think a transfer role is a generic solution  for the
>>>>> issue raised here, applicable to the cable car transfer and other types of
>>>>> transfer in routes, but I will not propose a new role value any time soon.
>>>>>
>>>>> Anyone who wants to do it has my support, though.
>>>>>
>>>>> Vr gr Peter Elderson
>>>>>
>>>>>
>>>>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>>>>> dieterdre...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> sent from a phone
>>>>>>
>>>>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>>>>> >
>>>>>> > Normal OSM access is assumed to be access=yes, where some access is
>>>>>> restricted then in OSM it should be marked *=no.
>>>>>>
>>>>>>
>>>>>> for roads access=yes is assumed, it is not necessarily the default
>>>>>> for all kind of features.
>>>>>>
>>>>>>
>>>>>> Cheers Martin
>>>>>> ___
>>>>>> Tagging mailing list
>>>>>> Tagging@openstreetmap.org
>>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>>
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>> ___
>>> 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] Rail segment in a bike route

[Jo]

Hi Francesco,

I will create the superroute and route relations as an example. If you
don't like the solution, feel free to remove those relations again
afterwards. I will only fix a small error in the original relation, but
keep it for now, so both solutions can be analysed next to each other.

I don't really like the idea of a role 'transfer' on all those railway ways
in a single route relation. In the case of your example, there is only a
single railway, but in theory there could be one for each direction of
travel of the train. So if you want to describe that in the route relation,
you would need role forward/backward in the route relation, which cannot be
combined with role transfer.

Jo

On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
wrote:

> Dear Polyglot,
>
> it sounds good to me. But what roles do you suggest for such superroute?
> Many thanks
> Francesco
>
> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
> scritto:
>
>> How would you feel about mapping it with a superroute relation?
>>
>> The superroute would then contain 3 route relations.
>>
>> 1 for the first part by bicycle
>> 1 for the middle part by train
>> 1 for the last part by bicycle
>>
>> If we give the train part a different role in the superroute, we can make
>> it such that the continuity line in JOSM is still drawn.
>>
>> This solution might also work to indicate that certain parts of a bicycle
>> route need to be done on foot. Although creating separate route relations
>> for such short stretches may feel like overkill.
>>
>> The other 'interruption' of a bicycle route I can think of, is where a
>> ferry needs to be taken. In theory this could also be a funicular. In
>> Antwerpen there is a special bus service that takes cyclists through a
>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>> it's unlikely we'll create a route relation for this, but not
>> impossible/unthinkable).
>>
>> In JOSM PT_Assistant there will soon be a convenience button to extract
>> route relations from route or superroute relations, to make a conversion
>> from route to superroute+route relations easier to do.
>>
>> Polyglot
>>
>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli 
>> wrote:
>>
>>> Hello,
>>>
>>> a new example that could benefit of this proposal:
>>>
>>> https://www.openstreetmap.org/relation/10605853
>>>
>>> Can someone please go ahead and make a proposal?
>>>
>>> Many thanks
>>> Best regards
>>> Francesco
>>>
>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>> scritto:
>>>
>>>> For the record, I think a transfer role is a generic solution  for the
>>>> issue raised here, applicable to the cable car transfer and other types of
>>>> transfer in routes, but I will not propose a new role value any time soon.
>>>>
>>>> Anyone who wants to do it has my support, though.
>>>>
>>>> Vr gr Peter Elderson
>>>>
>>>>
>>>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>>>> dieterdre...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> sent from a phone
>>>>>
>>>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>>>> >
>>>>> > Normal OSM access is assumed to be access=yes, where some access is
>>>>> restricted then in OSM it should be marked *=no.
>>>>>
>>>>>
>>>>> for roads access=yes is assumed, it is not necessarily the default for
>>>>> all kind of features.
>>>>>
>>>>>
>>>>> Cheers Martin
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> 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] Rail segment in a bike route

[Jo]

How would you feel about mapping it with a superroute relation?

The superroute would then contain 3 route relations.

1 for the first part by bicycle
1 for the middle part by train
1 for the last part by bicycle

If we give the train part a different role in the superroute, we can make
it such that the continuity line in JOSM is still drawn.

This solution might also work to indicate that certain parts of a bicycle
route need to be done on foot. Although creating separate route relations
for such short stretches may feel like overkill.

The other 'interruption' of a bicycle route I can think of, is where a
ferry needs to be taken. In theory this could also be a funicular. In
Antwerpen there is a special bus service that takes cyclists through a
tunnel under river Schelde (for commuters, where a ferry was abolished,
it's unlikely we'll create a route relation for this, but not
impossible/unthinkable).

In JOSM PT_Assistant there will soon be a convenience button to extract
route relations from route or superroute relations, to make a conversion
from route to superroute+route relations easier to do.

Polyglot

On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli 
wrote:

> Hello,
>
> a new example that could benefit of this proposal:
>
> https://www.openstreetmap.org/relation/10605853
>
> Can someone please go ahead and make a proposal?
>
> Many thanks
> Best regards
> Francesco
>
> Il mer 24 giu 2020, 23:25 Peter Elderson  ha scritto:
>
>> For the record, I think a transfer role is a generic solution  for the
>> issue raised here, applicable to the cable car transfer and other types of
>> transfer in routes, but I will not propose a new role value any time soon.
>>
>> Anyone who wants to do it has my support, though.
>>
>> Vr gr Peter Elderson
>>
>>
>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>> dieterdre...@gmail.com>:
>>
>>>
>>>
>>> sent from a phone
>>>
>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>> >
>>> > Normal OSM access is assumed to be access=yes, where some access is
>>> restricted then in OSM it should be marked *=no.
>>>
>>>
>>> for roads access=yes is assumed, it is not necessarily the default for
>>> all kind of features.
>>>
>>>
>>> Cheers Martin
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Confusion bicycle_road <> cyclestreet

[Jo]

fietsstraat / rue cyclable are really 'a thing' in Belgium. Usually the
whole street is redesigned, it's not just a traffic sign on both ends. Red
asphalt, giant flower pots. Car drivers don't seem to realise that they are
not allowed to overtake cyclists in most of them though. So that's a bit
disappointing. They pass me by even when I'm going at 25km/h and they are
supposedly only allowed to go at 30km/h. I had no idea that their
'properties' were so different in The Netherlands and Germany.

I agree that their definitions should probably not be 'exported' to other
countries, until such time that something with the same semantics exists
there.

Polyglot

On Wed, Aug 26, 2020 at 2:44 PM Volker Schmidt  wrote:

> Yes, there is a legal difference
>
> *bicycle_road*
> A German "Fahrradstrasse" (which is the prototype on which this tag seems
> to be modeled) is a road exclusively  for bicycles in the sense that
> carries the the sign "Fahrradstrasse" without addition indicates that the
> carriageway of the road is reserved for bicycles, pedestrians, people on
> skayes, youn children on bicycles need to use the sidewalk (if available).
> lso an implied speed limit of 30km/h applies.
> In my opinion the "naked " German Fahrradstrasse is equivalent to
> highway=service|residential
> vehicle=no
> foot=use_sidewalk  or sidewalk=separate if there is a separate sidewalk
> bicycle=designated
> maxspeed=30
> So what do you "save" in tagging with bicycle_road=yes ?
> As far as I can see it replaces "vehicle=no" and "bicycle=designated" with
> "bicycle_road=yes"
> (the speed limit is not part of the the bicycle_road tag nor is there any
> indication about pedestrians)
>
> *cyclestreet*
> The prototype cycle street seems to be the Belgian "rue cyclable |
> fietsstraat" that describes a road that is not wide enough for creating
> separate cycle lanes or cycleways, hence the carriageway is shared between
> cyclists and motor vehicles. Motor vehicles are not allowed to overtake
> bicycles and there is an implicit speed limit of 30km/h
>
> Such a road would be equivalent to
> highway=service|residential
> foot=use_sidewalk  or sidewalk=separate if there is a separate sidewalk
> maxspeed=30
> overtaking:motorcar=no (this tagging is not defined in the wiki)
> What is the "saving" n using the cyclestreet=yes tagging?
> None, as both maxspeed and overtaking restriction are not part of the OSM
> tah cyclestreet=yes
>
> Basically I see no need for separate tags like bicycle_road and
> cyclestreet, as you can easily describe their properties with existing
> tags. Add to this the confusion between the two tags, and then add to the
> mix the myriad of variants on the subject in countries other than Germany
> and Belgium, respectively.
> These two tags should be discouraged.
> As that most likely is not possible, maybe we can at least discourage
> their "export" to other countries.
>
>
>
> On Wed, 26 Aug 2020 at 08:51, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> I am curious is there any difference in practical use of this two tags.
>>
>> Aug 25, 2020, 12:13 by vosc...@gmail.com:
>>
>> Hi,
>> I have come across a new (to me) street sign In Italy:
>> https://italy-cycling-guide.info/tips-advice/riding-in-italy/
>> The road is a one-lane residential road on which bicycles and pedestrians
>> can circulate.
>> I don't know the legal status, however (I am inquiring).
>>
>> In that contest I have noticed that we have two wiki pages defining two
>> tags, which seem to be describing nearly the same concept:
>> bicycle_road 
>> created 14:54, 7 August 2010
>> 
>> ‎
>> cyclestreet
>> 
>> created 09:58, 9 May 2018
>> ‎
>>
>>
>> The main difference, as I understand it, is that the bicycle road is for
>> bicycles only, unless there are additional signs, whereas
>> on a cycle street "cars are also allowed. However, this car use is
>> limited by the character and layout of the cyclestreet"
>>
>> To make the confusion perfect, both wiki pages use the same (German) road
>> sign as illustration for the situation in Germany.
>>
>> https://wiki.openstreetmap.org/wiki/File:Zeichen_244_-_Beginn_der_Fahrradstra%C3%9Fe,_StVO_1997.svg
>>
>> Taginfo:
>> bicycle_road=yes
>>  7906
>> cyclestreet=yes
>>  4076
>>
>> Volker
>> Padova, Italy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> 

Re: [Tagging] We should stop using hyphens to denote address ranges

[Jo]

Hi,

You probably meant 5, not 15. I think it's OK to repeat the address on that
entrance node.

Jo

On Sun, Aug 23, 2020 at 6:53 PM Thibault Molleman <
thibaultmolle...@gmail.com> wrote:

> Update on my example I gave. We changed it to
> addr:housename=Residentie Den Oude Post
> addr:housenumber=14
> addr:street=Kasteelstraat
> addr:unit=1A;2A;3A
>
>
> A more complex example:
> https://www.openstreetmap.org/way/699214532
>
> So this is Kasteelstraat 5
> The bank that's located on the bottom floor is on Kasteelstraat 5 (so the
> POI node has that address)
> At the side of the building there is an entrance for the flats/units.
> I mapped that as an entrance https://www.openstreetmap.org/node/7025498816
> Should that entrance node also have the
> addr:housenumber=15
> tag or is it assumed based on it being placed on the building's way?
>
> On Sun, 23 Aug 2020 at 12:16, Martin Koppenhoefer 
> wrote:
>
>>
>> sent from a phone
>>
>> > On 23. Aug 2020, at 10:17, Jo  wrote:
>> >
>> > The house number is not 12 and it is not 14, it actually is 12-14,
>> because 2 buildings were torn down and a single building was built instead
>> of it. This also happens when people or companies acquire 2 adjacent
>> buildings, they often also start using both house numbers as their address.
>>
>>
>> In Italy this happens all the time, because every door and shop window
>> (potential entrance) gets a housenumber, so it is very common that shops
>> have addresses with several numbers. Sometimes they use just a single
>> number of those that they “have” as address (not even necessarily the one
>> of the door, but the one they are registered under) in other cases (very
>> common) they use multiple numbers.
>>
>> I usually map both, individual numbers on entrances and windows and
>> coalesced ones for addresses on POIs (as they use them themselves).
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] ref on roundabout

[Jo]

PT_assistant can split the roundabout for you if you use JOSM

Jo

On Sat, Aug 22, 2020, 19:20 Volker Schmidt  wrote:

> That's the approach anyway for bicycle and bus route relations on
> roundabouts.
> Yes, it causes additional work, because you need to split the roundabout
> way,
> but I do not see a way to avoid that.
>
> Volker
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#m_-707115589998065_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sat, 22 Aug 2020 at 19:14, Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 22. Aug 2020, at 12:11, Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> wrote:
>> >
>> > I would expect roundabout to be split in parts where
>> > ref is applying and parts where it is not applying, in other words
>> > without any special handling and tag it as usual.
>>
>>
>> +1
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] We should stop using hyphens to denote address ranges

[Jo]

Hi, I changed it. I also added a url which has some additional background
information for the whole street.

I don't think we should drop hyphens in house numbers. The house number is
not 12 and it is not 14, it actually is 12-14, because 2 buildings were
torn down and a single building was built instead of it. This also happens
when people or companies acquire 2 adjacent buildings, they often also
start using both house numbers as their address.

I have no idea why they called the units 1A;2A;3A though. Now the address
for a single unit is Kasteelstraat 12-14/1A, I guess. Could have been just
12-14/1. It's unlikely a 1B, 2C or 3D will appear...

Jo

On Sun, Aug 23, 2020 at 7:49 AM Thibault Molleman <
thibaultmolle...@gmail.com> wrote:

> I think the old building at that location used to be split in 2 (thus the
> 2 housenumbers).
> So Kasteelstraat 12 does not exist anymore.
>
> I only just now realized I mapped this wrong (was one of my first things I
> mapped a couple years ago).
>
> By your photo, it looks like you could even put a building name in as well
>> "*Den Oude Post*"!
>
> yeah, also something I didn't realize back then
>
> Cheers,
>
> On Sun, 23 Aug 2020 at 00:43, Graeme Fitzpatrick 
> wrote:
>
>>
>>
>>
>> On Sun, 23 Aug 2020 at 05:55, Thibault Molleman <
>> thibaultmolle...@gmail.com> wrote:
>>
>>> This is a simple example: https://photos.app.goo.gl/wEQiB4X6BA3doK7T7
>>> one building, one unit/flat on each floor.
>>> mailbox at the front for all 3 units.
>>>
>>> https://www.openstreetmap.org/way/675768351
>>>
>>> currently mapped as:
>>> addr:housenumber=1A;2A;3A
>>> addr:street=Kasteelstraat
>>>
>>
>> But looking at the street, & the way it's numbered, it shows as 2, 4, 6,
>> 8, 10, this place, 16, 18, 20, 22 ...
>>
>> Assuming all those numbers actually appear?, personally, I would have
>> mapped it as
>> addr:unit / flats (whatever the default is in Belgium?)=1A;2A;3A
>> addr:housenumber=12-14
>> addr:street=Kasteelstraat
>>
>> By your photo, it looks like you could even put a building name in as
>> well "*Den Oude Post*"!
>>
>> Thanks
>>
>> Graeme
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Jo]

You could add all. My solution would be to add no stop_position nodes to
the route relations. I would suffice with a single platform node that
represents platform and has all the relevant details.

That's not how train stops are mapped atm though, and some platforms are
divided in zones. In that case I would have one such node per zone, but
again you might want to add each such zone to the train route relations.

Food for thought.

Polyglot (who is more into mapping buses than trains)

On Sat, Aug 8, 2020, 03:19 Jarek Piórkowski  wrote:

> On Fri, 7 Aug 2020 at 20:54, Andy Townsend  wrote:
> > https://www.openstreetmap.org/node/12004813 is a
> > "public_transport=stop_position" for a local station and is part of
> > https://www.openstreetmap.org/relation/6396491 among other relations.
> > The problem is that train lengths vary, and there are a number of stop
> > positions, each of which are actually signed on the platform for the
> > benefit of the drivers.  From memory I think that there's at least a
> > 2-car stop, a 4 car stop and 6/8 and 10/12 car stops.  The problem is
> > that the current node doesn't correspond to any of them.
> >
> > As I asked on the changeset that added the one above
> > https://www.openstreetmap.org/changeset/40603523 , how should these be
> > mapped and how should the PTv2 relations be set up for the different
> > services that use them, given that different train services will use
> > different stop locations here depending on train length?  Should each
> > stop position be mapped and should there therefore be different copies
> > of each relation for all the possible train lengths?  Should a "pretend"
> > average stop position be added which is actually never correct but will
> > at least look nice to data consumers that use PTv2 data?  Given that we
> > don't know the actual stop position perhaps the railway=station object
> > (in this case https://www.openstreetmap.org/node/7154300845 ) should be
> > used instead?
>
> Neither of these seem like great options. Personally: if the stopping
> positions for trains of different lengths have actually been surveyed,
> I don't have a problem with adding several stop_position nodes with a
> note=* or description=* or even an invented
> stop_position:train:cars=10;12. Don't put any other tags on them and
> they won't render, and it's hardly the most cluttersome of our various
> micromappings.
>
> There is however a problem if the Midland Main Line trains come in
> different lengths. I suppose you could create a separate route
> relation for each set service (from, to, calling at, and train length)
> and add the stop_positions to the appropriate relation, but that's
> pretty extreme relationing.
>
> (As a bit of background, I believe this is a German influence in the
> original PTv2 proposal: a given train ref (e.g. "ICE 13") refers to a
> single train that will have the same amount of carriages
> (extraordinary circumstances excepted). That's more specific than a
> "Midland Main Line: Sheffield => London St Pancras" relation.)
>
> > Maybe the public_transport=stop position should be omitted entirely?
> > This last option seems extreme, but one reading of
> > https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
> > where it says "However, marking the stop position adds no information
> > whatsoever when it is placed on the road at the point closest to
> > highway=bus_stop or on the tram tracks closest to railway=tram_stop. In
> > that case it can be abandoned. " might actually support that (and that
> > seems to be the view of one side of the argument in the USA).
>
> Note that this sentence was added in various edits in 2020, well after
> the initial proposal was approved. "adds no information" might well be
> true (given enough computing power), but "it can be abandoned" is
> someone's opinion.
>
> I'm personally fine with not having stop_position unless the actual
> stopping position is ambiguous due to some very unusual geometry, but
> to be clear, this is against the initially approved proposal.
>
> > Maybe the "correct" answer is none of the above?  With a "local mapper"
> > hat on I've managed to avoid PTv2 since it basically isn't relevant
> > anywhere I normally map things, largely because I don't tend to do that
> > near any actual public transport infrastructure, but with a DWG hat on I
> > haven't been able to avoid the question, hence me asking here.
>
> I hope the DWG hat is fireproof :) ptv2 is a topic that arouses passions.
>
>
> --Jarek
>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[Jo]

In Antwerpen there is a bus that you can only take, as a cyclist, so
accompanied by a bicycle. It's a subsidised service of the harbour, free
for its users (commuters). The bus replaces a ferry and goes through a
tunnel, prohibited for cyclists riding a bicycle.

Polyglot

On Thu, Jul 23, 2020, 17:35 Matthew Woehlke 
wrote:

> On 23/07/2020 09.59, Philip Barnes wrote:
> > On Thu, 2020-07-23 at 09:35 -0400, Matthew Woehlke wrote:
> >> I'm trying (and failing) to imagine a road/path/whatever that you
> >> are allowed to walk on *iff* you are pushing a bicycle (or moped
> >> or...). Do you know of any examples?
> >
> > I cannot think of many roads where you can walk but not cycle, other
> > than pedestrianised streets in town centres but you can walk on lots of
> > footpaths where you can push a bicycle. Some are too long and totally
> > unsuitable.
> >
> > A few of examples from my local big town
> > https://www.mapillary.com/map/im/HW9qSNB-1JlkQAC3SH_gZQ
> > https://www.openstreetmap.org/way/23896048
> >
> > https://www.openstreetmap.org/way/350458507
> >
> > https://www.openstreetmap.org/way/318709194
>
> All of those examples appear to allow regular pedestrians (foot=yes),
> which is common. I am asking if there are any places where walking is
> allowed *only* if you are pushing a bicycle, i.e. "no bicycle, no
> access". IOW, where your joke about dogs isn't a joke.
>
> (OT: Airline transponders may be IFF — note the capitalization —
> although I wonder about that because I always think of IFF as more a
> military thing. I'm not sure if civilian transponders are really meant
> to *identify friend or foe*, or if they're more just "transponders".)
>
> On 23/07/2020 09.59, bkil wrote:
> > For example, bicycle=dismount should be understood that bicycle
> > access is only allowed if a rider dismounts. However, if we had to
> > write bicycle=dismount + foot=no, then the meaning basically becomes:
> > neither riding your bicycle nor walking is allowed here, which is
> > quite the opposite compared to what bicycle=dismount would mean if it
> > were placed alone on the POI. Hence the correct way to tag this
> > should be bicycle=no + foot=no.
>
> Right, that's what I was suggesting, because the only plausible
> interpretation I can come up with for foot=no + bicycle=dismount is that
> you may traverse the way [on foot] iff you are pushing a bicycle. The
> question was, does that ever actually happen? I'm not *quite* willing to
> rule it out...
>
> --
> Matthew
>
> ___
> 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] nhd tags - documentation page review

[Jo]

If you enabled expert mode, you can download from Overpass directly into
JOSM.

Polyglot

On Sun, Jun 14, 2020, 23:29 Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Jun 14, 2020, 22:55 by vosc...@gmail.com:
>
> Is it not possible to get people who were involved in the original import
> to check these.things?
>
> Good idea, any idea how to identify accounts that added this tags into OSM?
>
> Standard way to to this failed - loading all objects tagged with this in
> Overpass Turbo
> would fail - 600 MB of data would crash browser.
>
> Next idea is to hunt for various download areas across USA, but I hope for
> a better method.
>
> without knowing what information these codes carry ore once carried,
>
> That is why I created pages documenting what kind of info is stored in
> imported tags
> ___
> 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] Fwd: Section numbers in hiking routes

[Jo]

By the way, superroute relations in JOSM now show continuity correctly if
the last node of the last way is the same as the first node of the first
way in two sequential route relations. (It was a feature request I made and
someone developed it).

Jo

On Sat, May 23, 2020 at 8:47 PM Kevin Kenny  wrote:

> > For now, I just want an alternative for the section/segment/leg numbers
> or refs that are often in the name tag now.
> > They are there to get neat ordered lists in tools and applications. That
> seems to work fine, but it abuses the name tag, which I am told is a
> problem for searching routines. A name tag should contain a proper name as
> found on the street, and nothing else, that's the short version of some
> very long rants I have encountered...
> >
> > At the moment, I move comments, descriptions, distance and trail refs to
> the appropriate tags.
> > From-via-to information I copy to the from, via and to tags.
> > I just need a nice and intuitive tag to copy the ordering information to.
>
> If the section number is an official identifier, then it's a ref (or
> possibly an unsigned_ref). There should be no collision because
> nothing keeps a superroute from having a ref of its own.
>
> If you're identifying a section number in order to sort the members of
> a superroute, Don't Do That.  Keep the superroute in order.
> https://www.openstreetmap.org/relation/919642 remains a worked
> example; the sections are listed from south to north. Route relations
> are ordered; they're not just buckets of members.
>
> ___
> 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] Section numbers in hiking routes

[Jo]

oh, I'm mapping public transport too much. I actually did mean to write
superroute.

Jo

On Sat, May 23, 2020 at 7:44 PM Yves  wrote:

> While the original question was about a good tag to record the section
> number, whick look like a reference, I would be tempted to answer Jo that
> to know which country you're in, you should look at Your OSM Database!
> Joke aside, such a cross border route makes a good candidate for a super
> route.
> Yves
>
> Le 23 mai 2020 18:49:31 GMT+02:00, Jo  a écrit :
>>
>> So in the case of a route that passes through The Netherlands, Belgium
>> and France, the part in The Netherlands and Flanders will have the same
>> name (in Dutch)? And the parts in Wallonia and France will have the same
>> name as well, but in French instead? No indication which country/region
>> they are passing through?
>>
>> Jo
>>
>> On Sat, May 23, 2020 at 6:42 PM Peter Elderson 
>> wrote:
>>
>>> Hold on to your hat.... In the name tag I will store...The Name Of The
>>> Route!
>>>
>>> Op za 23 mei 2020 om 18:18 schreef Jo :
>>>
>>>> In the end, what will be left in the name tag exactly?
>>>>
>>>> Polyglot
>>>>
>>>> On Sat, May 23, 2020 at 5:53 PM Peter Elderson 
>>>> wrote:
>>>>
>>>>> I am trying to improve on the name-tag mess in the many hiking/foot
>>>>> routes in Nederland. All kinds of information is packed in those names. I
>>>>> am not doing any cleaning (yet) until all this information can be stored 
>>>>> in
>>>>> proper tags and is handled or scheduled by significant renderers/data
>>>>> users/tools. There must be reasons for this (ab)use, because it is done 
>>>>> all
>>>>> over the globe.
>>>>>
>>>>> It's very common to store - and sometimes  in the name
>>>>> tag. That's an easy one: we have from=*, via=*, to=*.
>>>>>
>>>>> Sometimes a complete description, a comment or a note (.e.g. about a
>>>>> temporary detour) is added to the name. Easy: we have description=, 
>>>>> note=*,
>>>>> comment=*.
>>>>>
>>>>> A ref in the name: store in ref=*.
>>>>>
>>>>> Another item is *section number*. This is often used when the route
>>>>> is split in sections, often according to the sectioning given by the
>>>>> operator/website. So firstly it's a sort of reference, secondly its an
>>>>> ordering and sorting mechanism.
>>>>> Sometimes sections have their own name. I see that a lot in
>>>>> international (super)routes.
>>>>>
>>>>> Any ideas how to do this without (ab)using the name tag? Is there a
>>>>> proper tag that springs to mind, or should we invent one?
>>>>>
>>>>> Peter Elderson
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>>> 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] Section numbers in hiking routes

[Jo]

I would say the route name goes on the routemaster relation. That way it's
possible to differentiate in the names of the route relations and make them
more specific. That's probably not what Peter is proposing though.

Jo

On Sat, May 23, 2020 at 7:40 PM Tod Fitch  wrote:

> I was under the impression that the consensus was that a route name should
> be in a route relation that holds all the segments and that the segment
> names, if different from the route name, were on the segment.
>
> Has that consensus changed or has my impression been wrong?
>
> Cheers!
> Tod
>
> On May 23, 2020, at 9:41 AM, Peter Elderson  wrote:
>
> Hold on to your hat In the name tag I will store...The Name Of The
> Route!
>
> Op za 23 mei 2020 om 18:18 schreef Jo :
>
>> In the end, what will be left in the name tag exactly?
>>
>> Polyglot
>>
>> On Sat, May 23, 2020 at 5:53 PM Peter Elderson 
>> wrote:
>>
>>> I am trying to improve on the name-tag mess in the many hiking/foot
>>> routes in Nederland. All kinds of information is packed in those names. I
>>> am not doing any cleaning (yet) until all this information can be stored in
>>> proper tags and is handled or scheduled by significant renderers/data
>>> users/tools. There must be reasons for this (ab)use, because it is done all
>>> over the globe.
>>>
>>> It's very common to store - and sometimes  in the name
>>> tag. That's an easy one: we have from=*, via=*, to=*.
>>>
>>> Sometimes a complete description, a comment or a note (.e.g. about a
>>> temporary detour) is added to the name. Easy: we have description=, note=*,
>>> comment=*.
>>>
>>> A ref in the name: store in ref=*.
>>>
>>> Another item is *section number*. This is often used when the route is
>>> split in sections, often according to the sectioning given by the
>>> operator/website. So firstly it's a sort of reference, secondly its an
>>> ordering and sorting mechanism.
>>> Sometimes sections have their own name. I see that a lot in
>>> international (super)routes.
>>>
>>> Any ideas how to do this without (ab)using the name tag? Is there a
>>> proper tag that springs to mind, or should we invent one?
>>>
>>> Peter Elderson
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Section numbers in hiking routes

[Jo]

So in the case of a route that passes through The Netherlands, Belgium and
France, the part in The Netherlands and Flanders will have the same name
(in Dutch)? And the parts in Wallonia and France will have the same name as
well, but in French instead? No indication which country/region they are
passing through?

Jo

On Sat, May 23, 2020 at 6:42 PM Peter Elderson  wrote:

> Hold on to your hat In the name tag I will store...The Name Of The
> Route!
>
> Op za 23 mei 2020 om 18:18 schreef Jo :
>
>> In the end, what will be left in the name tag exactly?
>>
>> Polyglot
>>
>> On Sat, May 23, 2020 at 5:53 PM Peter Elderson 
>> wrote:
>>
>>> I am trying to improve on the name-tag mess in the many hiking/foot
>>> routes in Nederland. All kinds of information is packed in those names. I
>>> am not doing any cleaning (yet) until all this information can be stored in
>>> proper tags and is handled or scheduled by significant renderers/data
>>> users/tools. There must be reasons for this (ab)use, because it is done all
>>> over the globe.
>>>
>>> It's very common to store - and sometimes  in the name
>>> tag. That's an easy one: we have from=*, via=*, to=*.
>>>
>>> Sometimes a complete description, a comment or a note (.e.g. about a
>>> temporary detour) is added to the name. Easy: we have description=, note=*,
>>> comment=*.
>>>
>>> A ref in the name: store in ref=*.
>>>
>>> Another item is *section number*. This is often used when the route is
>>> split in sections, often according to the sectioning given by the
>>> operator/website. So firstly it's a sort of reference, secondly its an
>>> ordering and sorting mechanism.
>>> Sometimes sections have their own name. I see that a lot in
>>> international (super)routes.
>>>
>>> Any ideas how to do this without (ab)using the name tag? Is there a
>>> proper tag that springs to mind, or should we invent one?
>>>
>>> Peter Elderson
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> 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] Section numbers in hiking routes

[Jo]

In the end, what will be left in the name tag exactly?

Polyglot

On Sat, May 23, 2020 at 5:53 PM Peter Elderson  wrote:

> I am trying to improve on the name-tag mess in the many hiking/foot routes
> in Nederland. All kinds of information is packed in those names. I am not
> doing any cleaning (yet) until all this information can be stored in proper
> tags and is handled or scheduled by significant renderers/data users/tools.
> There must be reasons for this (ab)use, because it is done all over the
> globe.
>
> It's very common to store - and sometimes  in the name tag.
> That's an easy one: we have from=*, via=*, to=*.
>
> Sometimes a complete description, a comment or a note (.e.g. about a
> temporary detour) is added to the name. Easy: we have description=, note=*,
> comment=*.
>
> A ref in the name: store in ref=*.
>
> Another item is *section number*. This is often used when the route is
> split in sections, often according to the sectioning given by the
> operator/website. So firstly it's a sort of reference, secondly its an
> ordering and sorting mechanism.
> Sometimes sections have their own name. I see that a lot in international
> (super)routes.
>
> Any ideas how to do this without (ab)using the name tag? Is there a proper
> tag that springs to mind, or should we invent one?
>
> Peter Elderson
> ___
> 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] Permanent ID/URI --- off topic email

[Jo]

JOSM's Mapillary plugin makes it easy to add mapillary tags to OSM objects.
On the Mapillary site it's possible to remote control JOSM so it opens with
data around the image.

I agree that it's not entirely convenient and may be slow. But Mapillary
welcomes ALL geotagged images. On Wikimedia Commons a contributor may
consider your picture not noteworthy enough or violating Panorama Rights, I
forget the correct term.

Polyglot

On Tue, May 19, 2020 at 2:30 PM European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Hi Jo and Paul,
>
> I am currently uploading the images to Mapillary  but
>
>  the workflow is painful and will only get more painful if the image
> volume picks up. There is no image receipt on upload so all the images get
> renamed.
>
> I get links to the uploaded images using the mapillary api and find the
> closest fountain in the osm database .. and then am currently manually
> editing the osm objects.
>
> For the second part of this process, whether the images stay on our
> server, go to commons or on mapillary :
>
> If I want to  be able to edit the nodes and add the image links using the
> OSM api directly without using ID or JOSM:  in layman terms, I need to make
> a oauth 1.0a connection and then pass commands to the OSM API by passing
> back and forth json objects ? (I have no idea to do any of this, but it
> could be a good challenge).
>
> Best regards,
>
> Stuart
>
> On Tue, 19 May 2020 at 14:24, Paul Allen  wrote:
>
>> On Tue, 19 May 2020 at 13:09, Jo  wrote:
>>
>>> Another possibility is to add the image to Mapillary and then use the
>>> mapillary tag to refer to it.
>>>
>>
>> I find Mapillary to be so slow as to be unusable.  I think it's more that
>> my
>> computer doesn't have enough memory to handle all the funky stuff
>> Mapillary does without extensive swapping, but it's such a pain I never
>> bother with it.  If you're happy for people to die of thirst whilst
>> waiting for
>> mapillary to display...
>>
>> --
>> Paul
>>
>> ___
>> 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] Permanent ID/URI --- off topic email

[Jo]

Another possibility is to add the image to Mapillary and then use the
mapillary tag to refer to it.

On Tue, May 19, 2020, 14:05 Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> May 19, 2020, 13:41 by europeanwaterproj...@gmail.com:
>
> >Is it possible to use an API to add image tags to osm objects  ?
>  Adding image tags to each of the objects would be the best solution.
>
> Every single OSM edit is done via OSM API.
>
> So, you can make OSM editor editing also image tag.
>
> Note that you need to handle (for example) already present image tag
> and host images somewhere.
>
> image tag (or wikimedia_commons tag) is solely a link.
> ___
> 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] Permanent ID/URI --- off topic email

[Jo]

If the fountains don't have identifiers that are suitable for ref, you may
be able to add them to wikidata (if they are 'notable' enough for that
project and you have permission to add them to a cc0 licensed project). You
can only do that for fountains that YOU have added yourself though, you
can't add them to wikidata if someone else mapped them, due to license
incompatibility between ODBL and cc0.

Polyglot.

On Tue, May 19, 2020 at 11:41 AM Simon Poole  wrote:

> It should be noted that (for Nodes) id + version is actually stable (Ways
> and Relations are more complicated).
>
> So if you have id + version, you can
>
> - check that it is the current version of the object (all fine and dandy)
>
> - check if there is a later (undeleted) version, check if it (depending on
> your criteria) is still the "same object", update version in your reference
>
> - if the last version is deleted or your criteria for it being the same
> object doesn't hold, search in the vicinity for a replacement object.
>
> Doing the same for Ways and Relations requires including a location
> reference of some kind as geometry changes are not reflected in the
> versions, but can work in principle the same.
>
> Simon
> Am 19.05.2020 um 09:43 schrieb European Water Project:
>
> Dear All,
>
> I am looking for a way to create permanent links  to specific objects
> (fountains and cafés) with images within our application ... and I have a
> couple of questions.
>
> How quickly do OSM node and ways numbers mutate ?  What percentage should
> I expect to change each year.  If the percentage of ids mutates slowly
> enough .. maybe this is still the best bad short term option ?
>
> I was pointed to this wiki :
> https://wiki.openstreetmap.org/wiki/Permanent_ID
>
> On the discussion page, it is mentioned that a solution is being targeted
> for end 2020 . Will there be a tool to translate actual osm node and ways
> numbers to the new permalink ids.
>
> Apparently Mangrove uses GEO URI to create perma links towards objects.
> https://en.wikipedia.org/wiki/Geo_URI_scheme. How do they deal with node
> repositioning ?  I could create a link name with first 5 latitude num
> followed by first 5 longitude num... but as soon as someone moves the node
> I would get a broken link...
>
> Thanks for your help and advice
>
> Best regards,
>
> Stuart
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] relations & paths

[Jo]

On Thu, May 14, 2020 at 12:49 PM Steve Doerr 
wrote:

> On 14/05/2020 09:31, Jo wrote:
>
>
>
> On Wed, May 13, 2020, 17:44 Jmapb  wrote:
>
>> Regarding the original question -- in what circumstances are
>> single-member walking/hiking/biking route relations a good mapping practice
>> -- what would be your answer?
>>
>
> Always
>
>
> Doesn't that violate
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element ?
>
> --
> Steve
>
>
No, because on the way you set all the properties of the way (width,
surface, name possibly) and on the route relation you set all the
properties of the route/itinerary.

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

Re: [Tagging] relations & paths

[Jo]

On Wed, May 13, 2020, 17:44 Jmapb  wrote:

> On 5/13/2020 10:12 AM, Paul Johnson wrote:
>
>
> We've had relations for over a decade now, IIRC.  It's time to stop
> treating this basic primitive as entity-non-grata.  If tools *still* can't
> deal with this, this is on the tools and their developers now.
>
> Sure. Regarding the original question -- in what circumstances are
> single-member walking/hiking/biking route relations a good mapping practice
> -- what would be your answer?
>

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

Re: [Tagging] iD semi automatic adding public_transport to aerialway=station

[Jo]

It only makes sense if the teleférico can be used all year around and is
useful for the whole public. If it's only there to get skiers up a
mountain, I don't think it's part of the public transport network.

Jo

On Sun, Apr 19, 2020 at 10:43 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 18. Apr 2020, at 23:13, Gegorian Hauser  wrote:
> >
> > I know that in the aerialway=station wiki site is nothing written about
> public_transport.
> > But there should be the description about when the public_transport
> tagging is allowed and when not
>
>
> for all kinds of stations, public_transport=yes/no could make some sense
>
>
> Cheers Martin
> ___
> 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] iD semi automatic adding public_transport to aerialway=station

[Jo]

When I was in Bursa, Turkey. There was a 'teleférico' that, I suppose ,was
meant to bring people from the city to a skiing area. Since I was there in
the summer though, I simply used to cool off in the mountains and escape
the heat from the city below. I had to get a ticket, so I would consider
that one to be public transport.

Jo

On Tue, Mar 31, 2020 at 10:33 AM Martin Koppenhoefer 
wrote:

> Am Di., 31. März 2020 um 04:22 Uhr schrieb Gegorian Hauser <
> grenhau...@mail.com>:
>
>> There are over 15000 aerialway stations in Europe and over 1000 are just
>> tagged also with public_transport
>>
>> For me these combination is in the most situations wrong and for this iD
>> should not have this "fixing" function.
>>
>
>
>
> I agree that in most occasions (of which I am aware), tagging of aerialway
> stations with public transport seems strange (they are services related to
> leisure and not to necessary transportation). The numbers you are citing do
> not seem completely at odds with this (only 6,6% of aerialway stations
> tagged as public transport). I would not generally exclude that some
> aerialways are part of what is considered the public transport network, but
> I would also expect some of these tagged as public transport which are
> probably not by common understanding.
>
> Cheers
> Martin
> ___
> 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] Which languages are admissible for name:xx tags?

[Jo]

Well, since I'm able to communicate in Esperanto, albeit not fluently
anymore, I would definitely like to keep name:eo, probably interlingua and
those as well.

I'm not expecting an invasion of Klingons or Elven, so those don't seem all
that useful.

Roman, you mean Latin? It existed, people communicated using it, and I know
the name of my city and a few others in Latin (thank you Asterix), so that
one makes sense too, I'd say. Don't know about Sumerian or Egyptian
hieroglyphs...

There are also transliterations between alphabets. Those depend on how the
person doing the transliteration thinks the name should be pronounced and
even if people agree on how to pronounce the name, they might still
transliterate differently because they use those characters for different
sounds in their own language.

I have been considering to add IPA to the street names of Brussels... No
matter which voice language I choose in OSMAND, part of the name will
always be pronounced wrong.

It even almost gets funny in the case of "Rue Conscience -
Consciencestraat". That should always be pronounced the French way, never
the English way, but alas.

Polyglot

On Wed, Mar 25, 2020 at 10:27 AM Frederik Ramm  wrote:

> Hi,
>
> the "name:xx" tags are something of an exception in OSM because while we
> defer to "local knowledge" as the highest-ranking source normally, this
> is not being done for name:xx tags. It is possible for no single citizen
> of the city of Karlsruhe to know its Russian name, but still a Russian
> name could exist. Who is the highest-ranking source for that?
>
> My guess is that about 5% of name:xx tags in OSM actually represent a
> unique name in its own right; all others are either copies of the name
> tag ("this city does not have its own name in language XX but I want
> every city to have a name:xx tag so I'll just copy the name tag"), or
> transliterations (or, worst case, even literal translations).
>
> A while ago we had a longer discussion about Esperanto names; in that
> discussion, it was questioned whether Esperanto could be in the name tag
> but nobody disputed that adding name:eo tags is ok, even though
> Esperanto is an invented (or "constructed") language.
>
> Yesterday someone added a few dozen Klingon names to countries in OSM. I
> have reverted that because of a copyright issue, but I think we also
> need to discuss which languages we want to accept for name:xx tags.
>
> In my opinion, a name:xx tag should only be added if you can demonstrate
> that people natively speaking the living language xx are actually using
> this name for this entity. I think we have a very unhealthy inflation of
> names in OSM that are added by "single-purpose mappers" - they come in,
> stick a name:my-favourite-language tag onto everything, and go away
> again. Nobody knows if these names are even correct, and nobody cares
> for their maintenance. The country North Macedonia changed its name
> almost one year ago, yet roughly half of its ~ 170 name tags are still
> what they were before this change. Nobody cares; these names suggest a
> data richness that is not backed up by an actual living community that
> cares for them.
>
> What are your opinions on which languages should be accepted in name
> tags? What do you think about
>
> * niche constructed languages (say, FredLang which has 2 words I
> invented just now)
> * popular constructed languages (Klingon, Elvish) - note place names in
> these languages will often be algorithmically derived from the English
> or local name
> * "serious" constructed languages (Esperanto)
> * languages that once existed but are not natively spoken any more (Roman)
> * languages that are natively spoken but their speakers do not have
> their own name for the entity in question (instead they use the same
> name the locals use, possibly transcribed into a different alphabet)
> * ...
>
> Or if you don't have the time to think about this in detail, just answer
> the question: tlhIngan Hol - Hlja' or ghobe'?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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 - RFC - Public Transport v3

[Jo]

This is how I would map a solitary tram stop:

https://www.openstreetmap.org/node/611673223
<https://www.openstreetmap.org/node/611673223/history>
Disregard the public_transport=platform, tram=yes. If I were mapping it
fresh today, I might not add those tags anymore.

Also note the pt=stop_position node:

https://www.openstreetmap.org/node/2000795897

I usually only map them If I plan to split the way (start or end of an
itinerary). It only has 2 tags, no further details and it is NOT a member
of the route relations.
I might stop mapping these altogether, since carto rendering decided to not
support the 'new' scheme. I don't see the point anymore. But that's not the
point.

And this is one with a platform:

https://www.openstreetmap.org/node/220369167

It's also served by buses.

The platform way is mapped separately:
https://www.openstreetmap.org/way/210281532

This is about as simple as it can get, no duplication, but still contains
all the relevant information. That is the point.

Polyglot

On Thu, Mar 12, 2020 at 9:11 AM Jo  wrote:

>
>
> On Thu, Mar 12, 2020 at 4:20 AM Jarek Piórkowski 
> wrote:
>
>> On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg
>>  wrote:
>> > >  In inclement weather, passengers may well be found waiting in
>> > the transit shelter 8 metres to west, and the tram will stop for them
>> > if they are waiting in the shelter. It might also stop if you are
>> > waiting a little bit beyond the shelter
>> >
>> > In this case it sounds like the tram operators are allowed to stop in
>> > several different places.
>> >
>> > I would pick the place where the tram normally stops: either at the
>> > sign or the location of the shelter, depending on the standard
>> > practice in the local area. Either way, tram riders will be directed
>> > to the correct location by routing apps: an 8 meter difference is not
>> > significant.
>>
>> But why pick one and not the other? Only for the sake of having one
>> point rather than two in a database? Especially in this case where
>> they can be fairly reasonably described as "stop position" (the sign)
>> and "waiting area" (the shelter).
>>
>
> platform=stop_position is a node that is part of the way. As far as I'm
> concerned, they are not super important. What you call stop position (the
> sign) in the above paragraph seems to be what corresponds to
> highway=bus_stop, if it were a bus stop. That's the node, detached from the
> way that I would map as railway=tram_stop for representing the stop in the
> route relations, with all its details.. Of course, when you only have
> aerial imagery, it may be difficult to know that exact position. If there
> is a shelter I would put this node near to it, if there is nothing, I would
> place that node somewhere in the middle of a typical tram's length.
>
> If there is only a sidewalk, we would be done. If there is an actual
> platform, I would add a way or a closed_way with railway=platform, and
> possibly its height, tactile_paving and wheelchair. No name, no other
> details, they are on the node that represents the stop.
>
> If there is a shelter, I would map it with a closed_way; amenity=shelter,
> shelter_type=public_transport.
>
>
>> > >  Berlin mapping of streetside tram stops like
>> https://www.openstreetmap.org/way/389400777
>> >
>> > I have not visited that location in person, and the aerial imagery is
>> > not high enough resolution to see if there is a separate platform, so
>> > it is hard for me to say.
>> >
>> > The "gold standard" is survey: visiting the stop in location (and
>> > riding the tram perhaps)
>> >
>> > Do you know if the "platform" here is separate from the sidewalk in
>> > some way? It should either be a different height, or a different
>> > surface, or at least marked with a painted / thermoplastic line.
>> > Otherwise the length of this "platform" way would be arbitrary: why
>> > not include the whole block?
>>
>> In this particular case, there is not a platform that can be
>> distinguished - it's a curbside stop. The length of the "platform" way
>> appears to roughly match the length of the vehicles and thus the area
>> where the vehicles can be boarded (all-door boarding is in effect).
>> Berlin doesn't have many curbside stops but where they do exist, this
>> seems to be the prevailing local tagging.
>>
>> --Jarek
>>
>> ___
>> 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 - RFC - Public Transport v3

[Jo]

On Thu, Mar 12, 2020 at 4:20 AM Jarek Piórkowski 
wrote:

> On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg
>  wrote:
> > >  In inclement weather, passengers may well be found waiting in
> > the transit shelter 8 metres to west, and the tram will stop for them
> > if they are waiting in the shelter. It might also stop if you are
> > waiting a little bit beyond the shelter
> >
> > In this case it sounds like the tram operators are allowed to stop in
> > several different places.
> >
> > I would pick the place where the tram normally stops: either at the
> > sign or the location of the shelter, depending on the standard
> > practice in the local area. Either way, tram riders will be directed
> > to the correct location by routing apps: an 8 meter difference is not
> > significant.
>
> But why pick one and not the other? Only for the sake of having one
> point rather than two in a database? Especially in this case where
> they can be fairly reasonably described as "stop position" (the sign)
> and "waiting area" (the shelter).
>

platform=stop_position is a node that is part of the way. As far as I'm
concerned, they are not super important. What you call stop position (the
sign) in the above paragraph seems to be what corresponds to
highway=bus_stop, if it were a bus stop. That's the node, detached from the
way that I would map as railway=tram_stop for representing the stop in the
route relations, with all its details.. Of course, when you only have
aerial imagery, it may be difficult to know that exact position. If there
is a shelter I would put this node near to it, if there is nothing, I would
place that node somewhere in the middle of a typical tram's length.

If there is only a sidewalk, we would be done. If there is an actual
platform, I would add a way or a closed_way with railway=platform, and
possibly its height, tactile_paving and wheelchair. No name, no other
details, they are on the node that represents the stop.

If there is a shelter, I would map it with a closed_way; amenity=shelter,
shelter_type=public_transport.


> > >  Berlin mapping of streetside tram stops like
> https://www.openstreetmap.org/way/389400777
> >
> > I have not visited that location in person, and the aerial imagery is
> > not high enough resolution to see if there is a separate platform, so
> > it is hard for me to say.
> >
> > The "gold standard" is survey: visiting the stop in location (and
> > riding the tram perhaps)
> >
> > Do you know if the "platform" here is separate from the sidewalk in
> > some way? It should either be a different height, or a different
> > surface, or at least marked with a painted / thermoplastic line.
> > Otherwise the length of this "platform" way would be arbitrary: why
> > not include the whole block?
>
> In this particular case, there is not a platform that can be
> distinguished - it's a curbside stop. The length of the "platform" way
> appears to roughly match the length of the vehicles and thus the area
> where the vehicles can be boarded (all-door boarding is in effect).
> Berlin doesn't have many curbside stops but where they do exist, this
> seems to be the prevailing local tagging.
>
> --Jarek
>
> ___
> 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 - RFC - Public Transport v3

[Jo]

>
>
> But if the originally, more common
> tag highway=bus_stop is already used, there is no need to add bus=yes.
>
>
OK, but if we have to keep  highway=bus_stop anyway, then one could also
say that it's not needed to add public_transport=platform to such nodes
anymore.

And if we do that, then those nodes don't really need roles in the route
relations either,

The problem with PTv2 is that it was an attempt to streamline how buses
were mapped based on how railway was mapped, where it would have made more
sense to go in the other direction and map railway the way buses are mapped.

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Jo]

That stop_position nodes became optional is probably because of my
influence. In the beginning they were definitely part of how PTv2. I
disliked this very much because all of a sudden we were using 2 objects to
define a single stop, duplicating details, which seemed like a very bad
idea. And it was.

About the stops, I would have all the details on a single node,
highway=bus_stop, railway=tram_stop next to the road where the passengers
wait. If there is a physical platform, I would add a way highway=platform,
railway=platform. This way would only have tags describing the attributes
of the platform like wheelchair and tactile_paving.

Only the  highway=bus_stop, railway=tram, which has the details like name,
ref, etc would be a member in the route relations.

I think it's good that we are discussing how to map PT in a reasonable way.
My take on all this, is that I would prefer to 'simplify' it by adding
another layer of subrelations in between.

This would definitely make it easier to reroute several bus itineraries in
one go. Or fix several by making a single intervention.

It would not be clear anymore which buses use which ways directly, but that
would be the effect of the current proposal as well.

Anyway, the reason why I am not making an official proposal for years now,
even though I'm telling myself I should is that

1. it would be very hard to get it to pass
2. even if it passes, it may not be adopted in some places

Polyglot

PS: I saw PT_Assistant mentioned a few times. I'm glad it's being used. If
it doesn't work like you expect, let me know, maybe we can improve it.
Also, not all validator warnings are of the same importance. If your bus
travels against a oneway restriction, or the route is interrupted, it would
be good to fix that. If it complains about first or last way not matching
with first or last stop, it may be that the stops aren't ordered correctly.
If it complains about the first or last way isn't split near the stop,
that's not crucially important, I'd say.



On Wed, Mar 11, 2020 at 12:46 PM Peter Elderson  wrote:

> I get the impression that consensus and general adoption will not be
> reached during my lifetime.
>
> Good luck with it, I'm out!
>
> Vr gr Peter Elderson
>
>
> Op wo 11 mrt. 2020 om 12:13 schreef alan_gr :
>
>> John Doe wrote
>> > I don't understand why the critics of PTv2 seem to think stop positions
>> > are such a big deal - they are optional!
>>
>> My memory of starting to map bus stops a few years ago is that it wasn't
>> clear from the documentation that stop positions are optional. I certainly
>> formed the impressions that they were required, and came to regret
>> spending
>> so much time mapping both stop positions and platforms. At that time I
>> think
>> the main reference for how to map using PTv2 was the proposal page itself,
>> now archived at https://wiki.openstreetmap.org/w/index.php?oldid=625726.
>> That doesn't indicate that stop_position is optional (see "the Schema in
>> short", where stop_area is explicitly described as optional, but
>> stop_position is not).
>>
>> It seems other wiki pages have since been edited to make this optionality
>> clearer. I notice that they also refer to adding bus=yes etc to platforms
>> representing bus stops, which was not part of the PTv2 proposal, but I
>> guess
>> tries to deal with one of the issues that led people to prefer
>> highway=bus_stop.
>>
>> Bringing this closer to the original topic ... if the proposal for PTv3 is
>> "PTv2 with some exceptions", is there a single coherent reference for what
>> is meant by "PTv2"?
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] hiking and foot route relations - is there any consistent difference?

[Jo]

If I remember well, there is also route=walking...

You are right that it doesn't make very much sense to make the distinction.
But now to get all mappers to choose for either hiking or foot will prove
to be an impossible task. As usual it will be status quo that wins, like
you saw in the result of the previous discussion about this.

Anyway, I wish you the best of luck with this, you'll obviously need it to
get anything to change.

Polyglot

On Sat, Jan 11, 2020 at 2:59 PM Joseph Eisenberg 
wrote:

> Back in August there was a thread titled "Merging tagging scheme on
> wiki pages of Hiking, route=hiking, route=foot and Walking routes"
> which led to a new template
>
> https://wiki.openstreetmap.org/wiki/Template:Tagging_scheme_for_hiking_and_foot_route_relations
> - used on route=hiking and route=foot pages.
>
> However, I'm disappointed that the text ended up claiming this:
>
> "route=foot is used for routes which are walkable without any
> limitations regarding fitness, equipment or weather conditions. As a
> guideline, you could say that walking shoes (at a pinch, even
> flip-flops) are adequate for this type of walking trail."
>
> This is all quite subjective. Folks here in Indonesia climb 3500 meter
> mountain passes in flip-flops.
>
> "route=hiking is used for routes that rather match Wikipedia's
> definition: "A long, vigorous walk, usually on trails, in the
> countryside"). As a guideline, you could say that a hiking trail needs
> hiking boots because you will encounter sharp rocks and/or heavy
> undergrowth and/or muddy terrain and/or have to wade through shallow
> streams."
>
> Again, very Western / European perspective to mention "needs hiking boots".
>
> I asked about this on the wiki talk page, and Brian de Ford said:
>
> "Google walking versus hiking and you will get many results agreeing
> that there is a distinction. No two of them entirely agree on what the
> differences are, but there is core agreement that hiking is more
> vigorous than walking. One insists that there must be a change in
> elevation (just about every road and sidewalk around here involves
> changes in elevation, so by that definition I hike to the shops).
> Several agree that equipment required makes a difference (style of
> footwear and need for a cane/stick). Many say that the nature of the
> surface makes the difference. Others say it's the terrain. There's a
> difference, but it may be hard to agree on definitions for OSM. BTW,
> parts of the UK also have "hillwalking" (which appears to be hiking
> where hills are involved) and rambling (essentially unmappable because
> there is no route)."
>
> It sounds like there is no verifiable difference between route=foot
> and route=hiking, so database users should not expect these tags to be
> used in a consistent way. Each mapper has there own idea of what they
> mean.
>
> - Joseph Eisenberg
>
> ___
> 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] Rail segment in a bike route

[Jo]

My take on this would be to create a separate route relation for the
funicular part and add that to the bicycle route relation. For validation
purposes that would be the simplest and clearest way of doing things.
Simply adding the rails would mean that you'd have to cycle on the rails,
or at least try and most likely fail.

Polyglot

On Sat, Dec 14, 2019, 14:37 Richard Fairhurst  wrote:

> Francesco Ansanelli wrote:
> > I added a bicycle route that implies the use of a funicular
> > (railway). I'm not sure how to "tell" in the relation that
> > you have to take the train and not ride the railway.
>
> Just add the railway to the bike route relation, and make sure that each
> end
> of the railway is directly connected to bike-routable ways. Here's
> cycle.travel routing via the Tauern Tunnel:
> https://cycle.travel/map?from=Salzburg=Grado
>
> (Unfortunately someone appears to have broken the relation since I last ran
> a routing update, removing the tunnel from it, so that'll need fixing...
> sigh. https://www.openstreetmap.org/relation/2771761 )
>
> cheers
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> 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] Rail segment in a bike route

[Jo]

Jesus would float, obviously, but what about his bicycle?

On Fri, Dec 13, 2019, 20:59 Peter Elderson  wrote:

> We  happily add ferry transfers to hiking routes. Nobody has been found
> trying to walk on the water. Nobody that we know of...
>
> Fr gr Peter Elderson
>
>
> Op vr 13 dec. 2019 om 20:39 schreef Martin Koppenhoefer <
> dieterdre...@gmail.com>:
>
>>
>>
>> sent from a phone
>>
>> On 13. Dec 2019, at 18:37, Francesco Ansanelli 
>> wrote:
>>
>> I added a bicycle route that implies the use of a funicular (railway).
>> I'm not sure how to "tell" in the relation that you have to take the
>> train and not ride the railway.
>> Can you give me some hint?
>>
>>
>>
>> I am not sure there is an agreed way to express this. From a cycling
>> point of view the route is interrupted at this point
>> We would have to introduce multimodal relations to cater for situations
>> like this
>>
>> Cheers Martin
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Real time in public transport

[Jo]

I mean url, not URL

On Tue, Nov 19, 2019, 17:17 Jo  wrote:

> He means the URL of a dedicated page for a stop on the operator's website.
>
> My preference would be to simply use URL for this purpose.
>
> Polyglot
>
> On Tue, Nov 19, 2019, 15:40 Janko Mihelić  wrote:
>
>> There is a mailing list for public transport, it's
>> talk-tran...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>> And I don't understand the intention. Do you mean a tag for a URL to the
>> timetable of a line?
>>
>> uto, 19. stu 2019. u 13:24 A A  napisao je:
>>
>>> Hello everyone.
>>>
>>> What do you think about the possibility of standardizing the use of a url
>>> in "departures_board" or "passenger_information_display" tags to be able to
>>> report arrival times in real time at a stop or train / subway / bus station?
>>>
>>> I think it can be very useful information. If it is added in a simple
>>> way through a tag, it could be easily implemented by mapping and navigation
>>> software and used for navigation in public transport or simply for querying
>>> the waiting time at a specific stop or public transport station.
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> 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] Real time in public transport

[Jo]

He means the URL of a dedicated page for a stop on the operator's website.

My preference would be to simply use URL for this purpose.

Polyglot

On Tue, Nov 19, 2019, 15:40 Janko Mihelić  wrote:

> There is a mailing list for public transport, it's
> talk-tran...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
> And I don't understand the intention. Do you mean a tag for a URL to the
> timetable of a line?
>
> uto, 19. stu 2019. u 13:24 A A  napisao je:
>
>> Hello everyone.
>>
>> What do you think about the possibility of standardizing the use of a url
>> in "departures_board" or "passenger_information_display" tags to be able to
>> report arrival times in real time at a stop or train / subway / bus station?
>>
>> I think it can be very useful information. If it is added in a simple way
>> through a tag, it could be easily implemented by mapping and navigation
>> software and used for navigation in public transport or simply for querying
>> the waiting time at a specific stop or public transport station.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] emergency=no on hospitals is ambiguous

[Jo]

the confusion is that emergency may refer to rooms, but usually in
OpenStreetMap it refers to access for emergency vehicles.

On Sun, Nov 3, 2019 at 8:58 AM Andrew Errington 
wrote:

> We have a local hospital. It is tiny and has no emergency room.
>
> Andrew
>
> On 03/11/2019, Francesco Ansanelli  wrote:
> > Hello list,
> >
> > I don't know is anybody wrote about this before, but I have noticed that
> > the emergency tag changes meaning on hospitals and the result is weird:
> > emergency tag indicate whether an emergency vehicle has access to the
> > way/point, but on hospitals his value is about emergency rooms.
> > I cannot imagine an hospital that disallowed access to emergency
> vehicles,
> > but the editors by example forgot about this and indicate so...
> > To avoid any ambiguity a rename could clarify the situation:
> > emergency -> emergency_room
> > On every hospital and we can assume emergency=yes on them (it's hard to
> me
> > to imagine a place that is emergency=no btw).
> > What do you think?
> > Cheers,
> > Francesco
> >
>
> ___
> 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] Tourist bus stop

[Jo]

Forgot the link:  https://zonnetrein.be/en/

On Thu, Sep 19, 2019 at 1:04 PM Jo  wrote:

> It's indeed a lot like that train in Tenerife.
>
> Since it's solar powered (supposedly), it's called Zonnetrein.
>
> Not a real train, no rails, more like a bus, but specifically targeted to
> tourists or group events.
>
> It's true we don't have a way to map this, so for now I would have been
> inclined to use highway=bus_stop with a specific operator on them.
>
> The original poster seems to be talking about bus services with schedule,
> for those too I would simply use highway=bus_stop.
>
> For the chartered services, they only have load/unload spots near the
> tourist attractions and parking areas. For those spots, it would be good to
> have a dedicated tag.
>
> Polyglot
>
> On Thu, Sep 19, 2019 at 11:14 AM Steve Doerr 
> wrote:
>
>> On 19/09/2019 00:29, Warin wrote:
>> > On 19/09/19 07:02, Steve Doerr wrote:
>> >> On 18/09/2019 18:57, Steve Doerr wrote:
>> >>>
>> >>> Sounds like a road-train to me.
>> >>>
>> >>
>> >> Actually I've reallized that the expression I was looking for was
>> >> 'land train'.
>> >>
>> >
>> > I don't think so ...
>> >
>> >
>> > https://en.wikipedia.org/wiki/Road_train
>>
>> https://en.wikipedia.org/wiki/Trackless_train is the relevant entry for
>> what I have in mind.
>>
>> --
>> Steve
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>>
>> ___
>> 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] Tourist bus stop

[Jo]

It's indeed a lot like that train in Tenerife.

Since it's solar powered (supposedly), it's called Zonnetrein.

Not a real train, no rails, more like a bus, but specifically targeted to
tourists or group events.

It's true we don't have a way to map this, so for now I would have been
inclined to use highway=bus_stop with a specific operator on them.

The original poster seems to be talking about bus services with schedule,
for those too I would simply use highway=bus_stop.

For the chartered services, they only have load/unload spots near the
tourist attractions and parking areas. For those spots, it would be good to
have a dedicated tag.

Polyglot

On Thu, Sep 19, 2019 at 11:14 AM Steve Doerr 
wrote:

> On 19/09/2019 00:29, Warin wrote:
> > On 19/09/19 07:02, Steve Doerr wrote:
> >> On 18/09/2019 18:57, Steve Doerr wrote:
> >>>
> >>> Sounds like a road-train to me.
> >>>
> >>
> >> Actually I've reallized that the expression I was looking for was
> >> 'land train'.
> >>
> >
> > I don't think so ...
> >
> >
> > https://en.wikipedia.org/wiki/Road_train
>
> https://en.wikipedia.org/wiki/Trackless_train is the relevant entry for
> what I have in mind.
>
> --
> Steve
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> 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] Tourist bus stop

[Jo]

In my own city we have an electric train like bus that has a few stops and
is specifically meant for tourists. Not double decker with an open roof and
it's slow, but OK. It has an itinerary and dedicated hop on/hop off stops.
I would like to be able to map it.

I would also like to be able to map the stops/waiting areas of those long
distance bus lines. At the moment, I was simply using highway=bus_stop for
them and an approximate itinerary.

Polyglot

On Wed, Sep 18, 2019 at 12:47 PM Martin Koppenhoefer 
wrote:

> btw.: those "sightseeing buses" that have been mentioned before, might
> merit their own tags, too. In Rome these are quite common (hence locals
> don't like them because they are competing for space in the traffic), they
> are not public transport (I guess they can not use bus lanes for example),
> but they are different from "regular" coaches too. Usually these are open
> on the top, you buy a ticket to use them for a certain time (1-2 days) and
> they follow routes and have stops (dedicated, not shared with public
> transport) and you can hop on and off as much as you want. They are typical
> for tourist destinations, e.g. can be found in Seville, Edinburgh, Paris,
> Palma de Mallorca, Malaga, Barcelona, Amsterdam, Athens, Dublin, Lisbon,
> Budapest, Brussels (just to copy from one of the companies, surely there
> will be similar offerings in other parts of the world).
>
> Example foto:
> https://www.rometoolkit.com/Images/xcity_sightseeing_bus_rome_1.jpg.pagespeed.ic.qtzVNApps0.jpg
>
> There are several companies which provide this kind of service, and I
> guess they are not compatible (you cannot use the same ticket for different
> companies), and with limited routes and pricing at something like 16-25EUR
> per person and 24h (they will only operate for example from 8:30-19:30
> though), these are not an alternative to public transport (1,50 EUR for 2
> hours).
>
> I will not map them (unless they pay for it ;-) ), but we should take care
> that they are NOT mapped as highway=bus_stop, or generally with public
> transport tags, that's why I mention them.
>
> Cheers,
> Martin
> ___
> 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] Tourist bus stop

[Jo]

What about long_distance_bus, if you don't like coach? motorbus doesn't
really convey much information. All buses we are talking about have a
motor. The only exception I can think of is this Italian pedibus, which
isn't really a bus at all. (Accompanied children who take the same
itinerary on a daily basis on their way to school).

When I saw the initial conversation in Italian, I thought the person asking
was asking about coach buses that were transporting tourists on an on
demand, or on group reservation basis. For such buses there are dedicated
areas where they can load / unload people, but that's more like parking.

In fact, if we're talking about Flixbus, Eurolines, Greyhound, etc. I think
highway=bus_stop is just fine. Add a tag for operator or network and it's
obvious and clear those are not bus stops for the local bus lines.

Polyglot

On Sun, Sep 15, 2019 at 11:47 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 12. Sep 2019, at 02:44, Joseph Eisenberg 
> wrote:
> >
> > I agree that "[motor]coach=" might have been clearer, but I'm ok with
> > keeping "tourist_bus=*" since it may actually be easier to translate
> > into most languages, and "coach=*" can also be ambiguous, since it
> > used to refer to horse-drawn vehicles and passenger railway cars, so
> > "motorcoach" would have been needed. Also, some definitions of
> > "coach=" seem to be limited to larger inter-city style buses, with
> > seatbelts, individual seats instead of benches, etc.
> >
> > See also https://wiki.openstreetmap.org/wiki/Key:coach
>
>
> I would use “motorbus” for the bus class, motorcar and motorcycle indicate
> there’s a system. The coach word seems more complicated and maybe only
> referring to some kind of buses. The term “Coach” should be avoided unless
> there are specific provisions for coaches (couldn’t find anything so far).
>
> For access restrictions for public transport buses, “public_bus” would
> have been clearer than just “bus”, but I don’t think osm is going to change
> this...
>
> For tourist_bus there might be a realistic (?) possibility to rename it to
> motorbus.
>
> Cheers Martin
>
>
> ___
> 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] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Jo]

For what it's worth, I think your proposal makes sense.

Polyglot

On Sun, Sep 8, 2019 at 6:28 PM Janko Mihelić  wrote:

> Has no one any opinion on this? I have a feeling this is important for the
> future of the Openstreetmap - Wikidata relationship..
>
> Janko
>
> On Fri, Sep 6, 2019, 15:05 Janko Mihelić  wrote:
>
>> Last year there was a little discussion about unique wikidata ids in the
>> openstreetmap database:
>> https://lists.openstreetmap.org/pipermail/tagging/2018-August/038249.html
>>
>> It was more or less decided there was no problem with this. Nevertheless,
>> I think we should consider having a hard rule of "*A Wikidata item
>> cannot be connected to more than one OSM item*".
>>
>> Problems with not enforcing this rule:
>>
>> - the problem of a partially downloaded database, where one is never sure
>> if a wikidata item is fully downloaded unless the whole database is
>> downloaded.
>>
>> - we could get a flood of wikidata tags where one would, for example, tag
>> every building in a town with the wikidata id of the town, because that
>> building is a part of the town. Is that wrong tagging? Well, if the above
>> rule is not in place, I'm not sure.
>>
>> - if a road segment has two road routes that are using it, then we should
>> tag it as "wikidata=Q1234;Q5678". That means, if we want to find any
>> wikidata id, we should be prepared to parse all wikidata tags and be
>> prepared for semicolons. This slows down any wikidata searches
>>
>> - we can't enforce some rules like "tag leisure=stadium can only be
>> connected to something that is, or is derived from Q483110 (Stadium) in
>> Wikidata" because, if we tag all the parts of an entity, we can also tag a
>> water fountain in the stadium, because that is a part of it.
>>
>> So I propose we enforce this rule, and we tag, for example, railways only
>> on the route relation.
>>
>> If one wants to tag all route segments with a wikidata tag, I propose a
>> general usage "*part:wikidata=**" which would be used when a single
>> wikidata tag just isn't viable. Proposal wiki page here:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/part:wikidata
>>
>> Thanks for reading,
>> Janko Mihelić
>>
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

Indeed, but I don't think it makes sense to use them for each and every stop

On Wed, Aug 21, 2019, 10:11 marc marc  wrote:

> Le 21.08.19 à 09:58, Markus a écrit :
> > Otherwise, we need a new relation (maybe type=stop_position?) to
> > connect the stop position to the waiting area
>
> imho that's why stop_area relation exist
> ___
> 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] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Jo]

OK, I have fixed my fair share of route relations, both public transport
and bicycle and foot routes.

I find it easier to EDIT them, when they are sorted. To figure out there
are problems with them, when they are sorted. JOSM actually does a great
job with the sorting. For bicycle, foot and horse route relations it can
handle forward/backward roles very well, when they branch.

I've been developing PT_Assistant for the parts that are missing in JOSM.
It now comes with routing helper functionality, which works for bicycle
routes too since this summer.

Instead of having to manually select, split, deselect not needed part of
ways manually, you can simply direct it by pressing numbers, which
correspond to segments rendered in different colours. It would be wonderful
if that could be implemented in iD as well. No need to know much about the
underlying relations. If you know the itinerary you want to add, you're
good to go.

It takes into account oneway traffice and turn restrictions for the mode of
transport of the route relation you are editing. So it behaves differently
when you are closing gaps in bus route relations than when you're doing the
same for bicycle route relations.

It still requires lots of JOSM atm. I'll give a demo/workshop of how it
works during SotM in Heidelberg. In the mean time I'm creating videos on
Youtube.

https://www.youtube.com/user/yoyo7yoyo

Polyglot

On Mon, Aug 19, 2019 at 6:57 PM Andy Townsend  wrote:

> On 19/08/2019 17:21, Peter Elderson wrote:
>
>  the only way for the likes of me is to use detection tools and
> maintenance tools to order data by hand at the mapping level, so ordinary
> people can use waymarkedtrails to get usable linear gpx-s for their
> basecamps, route editors, trip planners, navigation apps and devices.
>
> You keep perpetrating this myth - you're suggesting again that ways in
> routes need to be sorted before they can be used in Garmin software and
> navigation devices.  It simply isn't true.  For about 11 years now I've
> been creating Garmin maps based on OSM data, and I've been walking along
> local and national trails in the UK for far longer.  Never have I needed to
> "follow a GPX" - it seems a very alien thing to want to do, and (as
> mentioned previously) isn't actually supported by any of the various Garmin
> hiking GPSs that I've used.  If you want to do that - fine - but not
> everyone does.
>
> I suspect that "Ordinary people" will just download OSM maps from
> http://garmin.openstreetmap.nl/or one of the alternatives - they'll see
> the route on-screen and they will navigate using that.  Sometimes they'll
> stray from it because they've arranged somewhere to eat or stay; they're
> not limited to "only walking along the actual ways that form the official
> route" which you seem to be.
>
> If you have a different requirement then that's very much a personal
> requirement for you; please don't try and dissuade "ordinary people" from
> contributing to mapping hiking routes.  If you want to manually sort and
> rearrange hiking route data in a way that doesn't prevent everyone else
> from contributing that's also fine, but please don't raise the bar to
> contributions so high that people can't contribute at all. You'd
> essentially be filling the role that Kevin Kenny identified above as
> "Someone in the community who can handle relations will then have the
> geometry already established, so tidying the topology becomes a clerical
> task".
>
> The people we want adding hiking routes to OSM are people who've just
> taken their boots off, know where routes have been diverted, and know what
> the surface tags etc. should be, not people who've never emerged from
> behind a PC.
>
> Best Regards,
>
> Andy
>
> ___
> 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] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Jo]

Peter, I think Martin's question comes from a misunderstanding. You
probably meant the route relations were broken by someone editing before
you. Martin seems to have understood that you have to check all those route
relations, after you edited them yourself.

Jo

On Fri, Aug 16, 2019 at 9:52 AM Peter Elderson  wrote:

> Josm of course. Is there another relation editor that can handle large
> nested route relations spanning up to say 4000 Km? In josm, before the edit
> I open all the relations that may be affected, check if they are correct as
> far as that section is concerned,  then perform the edit, then apply the
> change to each relation and check again if all is well. When I am not in a
> hurry and the affected relations have other gaps, I repair those as well.
>
> Mvg Peter Elderson
>
> > Op 16 aug. 2019 om 02:11 heeft Martin Koppenhoefer <
> dieterdre...@gmail.com> het volgende geschreven:
> >
> >
> >
> > sent from a phone
> >
> >> On 16. Aug 2019, at 00:20, Peter Elderson  wrote:
> >>
> >> Not seldom I have to check and repair 10-15 route relations after one
> edit (most often a split of a way to allow a route to attach there) on the
> map.
> >
> >
> > which editing software do you use?
> >
> >
> > Cheers Martin
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Jo]

On Thu, Aug 15, 2019 at 1:57 PM Sarah Hoffmann  wrote:

> Hi,
>
> (making this a new topic)
>
> On Thu, Aug 15, 2019 at 11:56:30AM +0200, Peter Elderson wrote:
> > I strongly prefer to have one relation for the main route, and separate
> relations for alternatives. Put those together in a relation with roles for
> the member relations, not for individual ways. So the lowest level always
> contains only ways, the higher level contains only relations.
>
> Using subrelations is not consistent with the current use of
> forward/backward roles.
> I'd consider alternatives, excursions and access routes to be equivalent
> to those.
>
> By doing that, you're basically saying that alternatives can't have
forward/backward roles. To me that doesn't make sense. We are using those
forward/backward roles to indicate that there are 2 branches for each
direction of travel along the route. This could easily happen along an
alternative part of the route as well.

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

Re: [Tagging] Route sorting

[Jo]

As far as I'm concerned junction=roundabout means that that OSM way is part
of a roundabout. That's how it behaves.

JOSM is perfectly capable of handling split or unsplit roundabouts, except
for ad hoc rendering of the routes. With unsplit roundabouts, they all have
'bulges'. Hence my preference to split them everywhere, but I already
noticed other mappers are less than happy with that. Far less.

Polyglot

On Fri, Aug 16, 2019 at 1:58 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 15. Aug 2019, at 23:25, marc marc  wrote:
>
> why would you not do it for roundabouts?
>
>
> when we split a building in several parts, we keep one building=*
> and use several building:part
>
> for roundabouts, the tag is the same. for the whole roundabouts and for
> part of it.
> So spliting one roundabout into many produce many junction=roundabouts,
> despite it's only one roundabouts.
>
>
>
> it depends on our interpretation of the tags.
>
> The wiki is not consistent, as the definition says the tag
> junction=roundabout is describing
>
> “A road junction where the traffic goes around a non-traversable island
> and has right of way. “
>
>
> Later on, in “how to map”, it is assumed that roundabouts can consist of
> several ways: “
>
>- Tag the OSM way(s) of the roundabout with junction
>=roundabout.”
>
>
> There are some parallels to the bridge key page, where the definition
> currently reads:
>
> A bridge is an artificial construction that spans features such as roads,
> railways, waterways or valleys and carries a road, railway or other
> feature.
>
>
> This doesn’t mean that every way with bridge=yes is defining its own
> bridge (indeed the definition should rather be updated to something like:
> “a property to say something is on a bridge”). We’ll happily split a
> highway with bridge=yes for every property of the road that changes
> somewhere on the bridge, and we won’t interpret this as adding bridges to
> the map.
>
> Similarly we could write that junction=roundabout is a property to say a
> way is part of a roundabout (although this would be ugly, because the tag
> naming suggests to be about a feature rather than a property).
>
> We could also keep the definition and create route relations for the
> roundabouts (only the relation gets the junction tag), or invent a new
> property roundabout=yes for parts of roundabouts.
>
>
> Cheers Martin
>
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

On Sun, Aug 4, 2019, 16:40 Martin Koppenhoefer 
wrote:

>
> it is just an excuse to insist on using pt=platform for things that aren’t
> platforms and justify it with saying it means waiting area.
> I don’t think we should define pt=platform for something different than a
> public transport platform, it would be asking for trouble.
> If you want a waiting area tag, name it like this.
>
That ship has sailed

Polyglot

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

Re: [Tagging] Multiple values in isced:level

[Jo]

Use semicolons, for a range use 4;5;6. Be explicit and keep with the
standard value separator.

On Sun, Aug 4, 2019 at 2:17 PM Andrew Harvey 
wrote:

> It could be cultural but I've always understood that the hyphen (-), ie.
> 1-3 would mean it covers 1, 2 and 3, while if you say 1;3 or 1,3 then it
> would cover 1 and 3 only, excluding two 2.
>
> So I think it depends, if you want a range use "-" if you don't want a
> range use a ";" or ",".
>
> I've tagged with isced:level many times and have commonly used a "-" to
> indicate a range, eg. 1-2.
>
> On Sun, 4 Aug 2019 at 19:29, Lanxana .  wrote:
>
>> Hi!
>> I would like to know how to indicate that a school offers several
>> educational levels. I've been seeing the isced: level tag, which is that I
>> think to use, but I have a question about how to separate multiple values.
>>
>> I have looked in taginfo and approximately in 15000 cases the semicolon
>> (;) is used, in 3000 the comma (,) and in 1000 cases the hyphen (-). It
>> would seem therefore that the general criteria is to use the semicolon.
>>
>> It really is that? Is there no risk of causing errors when converting
>> data to another format?
>>
>> Another option that I had valued, and of which I have not found use, is
>> to add the level in the label itself, thus being:
>>
>> isced: level: 1 = yes + isced: level: 2 = yes, for a center that offers
>> levels 1 and 2.
>>
>> What's your opinion?
>>
>> Thanks!
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

> highway=platform and/or railway=platform are needed, because
>> public_transport=platform doesn't mean a platform, but a waiting area.
>> And a waiting areas doesn't need to be a platform: some waiting areas
>> are just poles or signs beside the road [1], others are located on the
>> sidewalk [2]. Besides, there are platforms that aren't operated
>> (anymore) and therefore aren't waiting areas, that is
>> public_transport=platform's, anymore.
>>
>
> Well this is an error. For mi public_transport=platform should be a real
> platform. It has no sense to have an irreal tag.
> In the stop_position tag you can assure this with platform=yes or
> platform=no.
>

When the "new" public_transport tag came along, I asked how should I tag
the nodes beside the street that represent the bus stops? Regardless of
whether a platform is present. And the answer was to use
public_transport=platform. So no, this is not an error.

For more than half a decade I have been trying to convince the people
responsible for the rendering of the main map to render nodes with
public_transport=platform + bus=yes like highway=bus_stop.

It became clear by now that this will NEVER happen.

Thus public_transport=platform / bus=yes to replace highway=bus_stop became
unnecessary. I think I'm going to remove those 2 tags everywhere in
Belgium, when I review those 7 bus stops, this time with help of
Mapillary images for the positioning. They became pointless.

But until now, I was using them. I was also using highway=platform to
indicate the real bus platforms and railway=platform for the tram stops.
Either in combination with public_transport=platform, or not. What I was
not doing is duplicating information on these platform ways, or on the
occasional stop_position node I was adding. And they also don't go into the
route relations.

1 object per stop in the route relations should be enough. I'm using the
nodes that represent the bus stops / passenger waiting areas next to the
highways for the purpose of representing the stops along the itineraries.
Works great! And isn't overly complicated or needing a lot of unnecessary
maintenance.

We need the simplest way of doing things that works.

When Uber starts flying, we'll tackle that problem then. No need for a
future proof public_transport scheme for that purpose.

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

For a few years now, I've been considering to make a proposal for mapping
PT in a simpler way. I haven't done it because it's a lot of work and there
will always be quite a few mappers who prefer the status quo.

Anyway, I think we need 1 object which has all the properties of a stop as
tags and which is used in the route relations. A single object per stop,
preferably not 2 for each stop.

That part I've been pushing it slowly all along.

Regarding the itineraries, I think we should also start looking into how we
can simplify that in such a way that maintenance becomes easier for the
mappers.

So what if a route relation would consist of an ordered set of stops and a
link to another relation for the itinerary. This other relation contains
only relations. Those relations contain the ways for a 'segment' or an
'edge'. It's these small relations that get broken occasionally when
mappers split or combine ways. When this happens only those relations need
to be fixed and the effect will be that all the itineraries that use them
are fixed in one go.

There is more 'indirection', which may seem more complex at first sight,
but we can create tools to visualise the effect of the combined set of
relations in JOSM and I guess it can be done in iD as well.

As far as maintenance goes, this would simplify matters a lot.

Let me know if you think it makes sense to start a proposal for this. The
student who works on PT_Assistant this summer is laying the groundwork for
going into this direction.

Polyglot


On Sat, Aug 3, 2019 at 11:33 AM Joseph Eisenberg 
wrote:

> Re: > The relation needs both stops and ways
>
> Sure, it's nice for rendering the have the ways, but it's not always
> necessary.
>
> There are 2 cases where you can only do one or the other
>
> 1) Stops only: The buses don't always take the same route between
> stops, but just take whatever way is fastest. This is common for
> long-distance buses between towns, and in non-Western countries for
> all sorts of buses. In this case, just the stops are needed.
>
> 2) Ways only: the bus follows the same streets, but will stop
> anywhere. This is the standard for all minibuses in Indonesia, and in
> many other countries. In this case there are no bus stops, except at
> the start and end of the route.
>
> It's great to include both when possible, but I think it we should let
> new mappers know that they can just start with stops or just start
> with the ways, if that's all they know.
>
> On 8/3/19, Warin <61sundow...@gmail.com> wrote:
> > On 03/08/19 11:19, Joseph Eisenberg wrote:
> >> Yes, the only thing that needs to be changed is the documentation, in
> >> my opinion. We don't need more tags, and it's not even necessary to
> >> officially "deprecate" anything.
> >>
> >> Right now some pages suggest that a bus stop needs to be tagged
> >> highway=bus_stop + public_transport=platform + bus=yes at the location
> >> passengers wait, and that you also need a
> >> public_transport=stop_position + bus=yes next to this point (on the
> >> highway), and a type=public_transport relation with *=stop_area, which
> >> includes the 2 features, and maybe they all need a name or ref? Oh,
> >> and you need to make a type=route relation which includes at least one
> >> of these features, or maybe all of them, in addition to highway ways?
> >>
> >> That's 3 features with at least 10 tags, to define a simple bus stop,
> >> before you even make the route relation.
> >>
> >> But really all we need is highway=bus_stop + name=* or ref=* - 2 tags,
> >> to define a bus stop. And the route relation needs either the stops or
> >> the highways added (you could add both, but this isn't really
> >> necessary), plus maybe a ref, duration and interval, if known.
> >
> > The relation needs both stops and ways.
> >
> > Not every stop along a route may be used by service.
> >
> > The simplest way that a router finds between 2 stops may not be the
> service
> > route.
> >
> > The stops don't need a name or ref .. but they could be handy.
> >
> > The route relation does not need an operator, a name etc... but the name
> > would be appreciated, and other tags could be handy too.
> >
> >
> >> More
> >> complex tagging is only helpful at interchange stations - and maybe it
> >> isn't even necessary there, if the routing application is developed
> >> well.
> >>
> >> It would be nice if we could present this situation as the recommended
> >> and sufficient method for mapping bus routes - which are by far the
> >> most common type of fixed-route public transport globally - especially
> >> for new mappers.
> >>
> >> The public_transport=* tags would still exist and still would be
> >> documented clearly on their own wiki pages, but the main features
> >> lists and the page Public Transport could make it clear that these are
> >> optional, not required.
> >>
> >> On 8/3/19, Daniel Koć  wrote:
> >>> W dniu 03.08.2019 o 02:28, Joseph Eisenberg pisze:
>  Consider also how you would route someone from a 

Re: [Tagging] Was public_transport=platform intended to > always be combined with highway=bus_stop?

[Jo]

For platform numbers or letters I've seen local_ref being used succesfully.
For train platforms it is also possible they are divided into zones, where
one part of the train may have one destination, and the other another
destination. Such trains are split either in that station or a subsequent
one.

On Wed, Jul 31, 2019 at 7:07 PM Peter Neale via Tagging <
tagging@openstreetmap.org> wrote:

> Hi Markus,
>
> Thank you for your comments.
>
> I stand corrected on the Name v. Ref issue.  You are right; it would be
> better to map a platform and tag it with Ref= .
>
> As regards your other comment; I stand by my view that it is useful to
> know which services stop at a given station, but that any user wishing to
> travel would expect to check which platform to stand on, as that could be
> changed at short notice.  So adding that detail to the map would not (IMHO)
> be useful.
>
> Regards,
>
> Peter
>
> On Wednesday, 31 July 2019, 17:49:06 BST, Markus <
> selfishseaho...@gmail.com> wrote:
>
>
> On Wed, 31 Jul 2019 at 15:08, Peter Neale via Tagging
>  wrote:
> >
> > Within the station there will normally be several platforms, which may
> be named "Platform 1", "Platform 2"... ...or "Platform A", "Platform B"
> etc.  These could / should be mapped and given an name tag.
>
> Common practice is to use ref=*, not name=*, because it's the number
> or letter of the platform, not its name. (This also has the advantage
> that e.g. routers can translate it into other languages.)
>
> > Whilst trains for particular destinations may NORMALLY use a certain
> platform, that can vary, depending on breakdowns, delays, scheduling
> issues, etc. so the Platforms should not be tagged with further information
> about the trains / route(s) using them.
>
> I disagree. If the train normally uses the same platform, except in
> some rare moments, i think it helps to know from which platform it
> departs. Note that bus stops sometimes can also be displaced or even
> omitted because of roadworks, breakdowns, delays etc.
>
>
> Regards
>
> Markus
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

bus_bay = right | left | both (  https://www.openstreetmap.org/way/485293336
  )

For me the object that represents the bus stop, is always a simple node. I
don't see a problem for doing that in bus stations as well.

If there are actual platforms, whether in a bus station or somewhere along
a way, it can be tagged:

highway=platform (https://www.openstreetmap.org/way/304753571)

or

or railway=platform (https://www.openstreetmap.org/way/255344359)

for trams.

on a way.

These ways don't get the ref, name, route_ref, zone, local_ref, operator,
network, and so on, those go on the node that represents the bus stop. Only
that node needs to be added to the route relations. It doesn't get any
simpler than that.

https://www.openstreetmap.org/node/576656712  (example of a bus stop served
by 3 different operators near Brussels, I only put
public_transport=platform, bus=yes because for a few years that seemed like
the right thing to do. Today I wouldn't mind removing those 2 tags once
again.)

Those platform ways could get:

tactile_paving=yes
wheelchair=yes
height=

So there is no real conflict between highway=bus_stop or railway=tram_stop
on a node

and

highway=platform or railway=platform on a way or an area.

Polyglot

On Wed, Jul 31, 2019 at 2:13 PM Paul Allen  wrote:

> On Wed, 31 Jul 2019 at 12:52, Joseph Eisenberg 
> wrote:
>
>> Agreed, there are enough tags for public transport already. I don't
>> think anything new is needed.
>>
>
> There's something I haven't found a way of mapping.  That's a bus stop
> where there's a bay
> inlet into the pavement (aka sidewalk, aka causeway).  If it served a
> different purpose and
> had different road markings, it could be a lay-by (aka rest area) or a
> parking bay.  But it's a
> bus stop where the bus does not obstruct the flow of traffic.  There are
> four of those in
> my town, that I can think of (there may be others I've missed).
>
> Yes, I could use area:highway or add area=yes to a closed way, but those
> don't seem to render
> on a popular, well-known carto intended for mappers to check their work
> for anything but
> pedestrian ways.
>
> Is there a way of doing it that I've missed?  If not, could we have one?
>
> Example: https://www.openstreetmap.org/edit#map=20/52.08760/-4.65318
>
> --
> Paul
>
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

By the way, I don't think the 'schism' of some people/countries mapping the
stops as nodes of/on the highway and others nodes/ways next to the highway
comes from an import in Switzerland. I think it came from habits in mapping
of railway infrastructure. At one point, we had a single way for multiple
tracks, then we added more detail. Back then it made sense to have station
nodes on those ways. But that is more like a model and it doesn't represent
reality very well, once you want to start adding more detail, like the
separate platforms in the stations.

Polyglot

On Tue, Jul 30, 2019 at 11:41 AM Jo  wrote:

> duplicating information across multiple objects.
>
> I found that what works best is to have nodes on the side of the road to
> represent the stops. These nodes have positional information and can carry
> all the tags for the details.
>
> If there is an actual elevated platform, it can be represented by a way or
> an area, but I don't see any need to move the details tags from the node to
> that area. Nor do I see a need to move them to a shelter area, if there is
> one, or to a bench or a waste basket that has the typical colours of the
> operator. For these ways / areas highway=platform / railway = platform is
> enough. Additional tags can be wheelchair yes, tactile_paving=yes and maybe
> height.
>
> The platfrorms are just additional features that may be there, or not.
>
> When I still had the idea that one day public_transport=platform /
> stop_position would actually supersede highway=bus_stop / railway=tram_stop
> / station and so on, I started adding bus = yes to the pt=platform nodes.
> Now I see less point into continuing to do so. The only advantage it has,
> is that JOSM will automatcially assign platform roles to such nodes.
>
> Nowadays, I'd say let's indeed drop the whole public_transport schema.
> Somewhat radical, but a simple schema is better than a complex one.
>
> Polyglot
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

duplicating information across multiple objects.

I found that what works best is to have nodes on the side of the road to
represent the stops. These nodes have positional information and can carry
all the tags for the details.

If there is an actual elevated platform, it can be represented by a way or
an area, but I don't see any need to move the details tags from the node to
that area. Nor do I see a need to move them to a shelter area, if there is
one, or to a bench or a waste basket that has the typical colours of the
operator. For these ways / areas highway=platform / railway = platform is
enough. Additional tags can be wheelchair yes, tactile_paving=yes and maybe
height.

The platfrorms are just additional features that may be there, or not.

When I still had the idea that one day public_transport=platform /
stop_position would actually supersede highway=bus_stop / railway=tram_stop
/ station and so on, I started adding bus = yes to the pt=platform nodes.
Now I see less point into continuing to do so. The only advantage it has,
is that JOSM will automatcially assign platform roles to such nodes.

Nowadays, I'd say let's indeed drop the whole public_transport schema.
Somewhat radical, but a simple schema is better than a complex one.

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

A bus stop, a place where a bus halts to pick up and drop off passengers is
both real and current. Tying it to a geographic object can be done in
various ways, as we've shown over the past years.

I read the wiki a few times over the past years and then I started looking
for something that works, both for mapping the stops and for adding them to
the route relations, WITHOUT

On Tue, Jul 30, 2019 at 3:39 AM Joseph Eisenberg 
wrote:

> I think you might be referring to this proposal from Zverik last
> summer, which suggests stopping using
> public_transport=stop_position/platform/station, but keeps the
> relations:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport
>
> - =stop_position is not really needed for routing; doubles work for mappers
> =platform is ambiguous; use =bus_stop, highway=platform (if the bus
> stop has a physical platform) railway=platform etc
> = public_transport=station is not specific, use amenity=bus_station,
> railway=station etc).
>
> re: > "It's hard to ascertain precisely why PT was originally created"
>
> According to this comment, it started with imports, and a dispute
> between English mappers and a few Central European mappers (or just
> one?): back in 2010 there were 200,000 highway=bus_stop mapped beside
> the road in England, at the location of the bus stop sign. But there
> was data available in Switzerland that could be imported that had the
> node in the center of the highway, probably for bus operator purposes,
> and a mapper started importing these and changed the wiki to say this
> was better. There was a dispute about this. To resolve it, the
> proposal that was eventually approved created specific tags for
> stop_position (on the highway) which could use access tags like
> "bus=yes" to specify the vehicle and "platform" (for the bus stop),
> and a stop_area relation.
>
> This wasn't sufficient information to render bus stops differently
> than tram / light rail platforms, so the original tagging method
> remained more common up until now.
>
> This hasn't stopped some mappers  from claiming that there is a
> "version 2" of mapping for transit which should replace the "old"
> tags, and editing the wiki pages to put this view at the forefront,
> going so far as to suggest public_transport=platform and =station for
> ferry terminals and taxi stops, where this tagging is very rare.
>
> I've made to various wiki pages to describe the current situation. I'm
> also working on making specific wiki pages for tags like bus=yes (used
> for both access restrictions and to specify the type of public
> transport vehicle at a feature).
>
> Joseph
>
> On 7/30/19, Dave F via Tagging  wrote:
> > Hi
> >
> > This is not a criticism of Joseph.
> >
> > This post confirms what I've been saying for the past year - PT tags add
> > nothing but confusion to OSM, which directly leads to errors.
> >
> > highway=bus_stop is a completely separate tag to any in the PT schema.
> > It was created long before the invention of the PT schema and is the
> > original & the most popular, accurate way to map a bus stop.
> >
> > The PT schema purely duplicates existing, well used, clearly defined
> > tags. It adds no extra detail or information.
> >
> > A platform is a raised physical object compared to the surrounding area
> > to aid vehicle boarding. Popular tags such as railway=platform,
> > tram=platform are used for such entities.
> > Public_transport=platform has been hijacked by PT to falsely represent a
> > bus stop as an imaginary area on a pavement. As defined in OSM's welcome
> > page: "OpenStreetMap is a place for mapping things that are both /real
> > and current/ ".
> >
> > It's hard to ascertain precisely why PT was originally created but it
> > appears to be that the existing tags weren't complete. However instead
> > of adding that missing data, somebody though it would be a great idea to
> > start from the very beginning with a completely new set of tags & try to
> > paper over the gaps. The irony is that, after a lot of discussion over
> > tag names & locations & quickly waning enthusiasm for adding them to the
> > database,  PT is *less* complete than the original data. What a waste of
> > time. It's a mess.
> >
> > Over on the transit forum the PT schema has become so convoluted even
> > those who helped create it are baffled. At least one is advocating its
> > removal.
> >
> > It's time for the PT schema to be redacted.
> >
> > DaveF
> >
> >
> >
> > On 29/07/2019 15:29, Joseph Eisenberg wrote:
> >> I read up on the rather exhausting history of public transport tagging.
> >>
> >> The strange thing is that the approved proposal which introduced
> >> public_transport=* and the current public_transport pages suggest
> >> using bus=yes only for public_transport=stop_position. In contrast,
> >> public_transport=platform doesn't have bus=yes added.
> >>
> >> Does this mean that tagging highway=bus_stop on the same node as
> >> public_transport=platform is the 

Re: [Tagging] About the diaper key

[Jo]

At some point diapers need to be changed...

Polyglot

On Wed, Jun 12, 2019 at 6:44 PM Valor Naram  wrote:

> Oh thanks. Corrected it
> https://wiki.openstreetmap.org/wiki/Key:changing_table and I also
> notified all downstream users that this feature replaces Key:diaper
>
> On Wed, 2019-06-12 at 16:28 +, marc marc wrote:
> > I was looking at the proposal and diaper page :)
> > somes changes
> > diaper=bench -> changing_Table=limited
> >
> > diaper=room -> changing_table=yes + changing_table:location=room
> > (you
> > can't assume that the room is dedicated)
> >
> > Le 12.06.19 à 18:10, Valor Naram a écrit :
> > > Hi marc,
> > >
> > > you can find the conversion table at
> > > https://wiki.openstreetmap.org/wiki/Key:changing_table
> > >
> > > I promised to create such a table and I am not one who breaks his
> > > promises
> > >
> > > On Wed, 2019-06-12 at 14:41 +, marc marc wrote:
> > > > Hello,
> > > >
> > > > Le 12.06.19 à 16:14, Valor Naram a écrit :
> > > > > "What do we do with the POIs having the Key:diaper?"
> > > >
> > > > I had proposed that a conversion table be added,
> > > > this would have avoided reopening the thread :)
> > > >
> > > > imho the best thing to do, in order:
> > > > - create the wiki page(s) for the new key(s) and values
> > > > - add in the wiki page diaper the correspondence table and have
> > > > a quick talk here to make sure everyone agrees.
> > > > - inform all project that declare using it. ideally their preset/
> > > > validator /datause could take into account both for example 1
> > > > month,
> > > > time for everyone to adapt the code and publish it (often
> > > > monthly)
> > > > - post a message on talk for "mecanical edit request"
> > > > - pray that there is no opponent who would need to split
> > > > the operation to take into account his opposition
> > > > - pray that a editor will not secede by considering
> > > > that the community choice is stupid
> > > > - wait for code update for projects
> > > > - do the mecanical edit
> > > > - inform all project it's done
> > > >
> > > > Regards,
> > > > Marc
> > > > ___
> > > > Tagging mailing list
> > > > Tagging@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/tagging
> > >
> > > ___
> > > Tagging mailing list
> > > Tagging@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/tagging
> > >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> 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] A modest proposal to increase the usefulness of the tagging list

[Jo]

Who's going to keep the tally? Maybe we need an actual tool to help with
this (I'm not proposing to write one or figure what could be used for doing
so). But what if the 4 proposals are reached? Or someone feels the need to
post 40 comments during a month? How do we stop the flood?

Polyglot

On Sun, Jun 2, 2019 at 10:49 AM Simon Poole  wrote:

> As a reader of this list I'm slightly overwhelmed by it right now.
>
> Besides the longish off topic discussions that should have been held
> somewhere else, we've had a massive increase in the number of proposals
> and comments on these. As these typically will require looking at the
> proposal, potentially commenting on its talk page and here, the increase
> in noise has led to even a cursory examination of proposals for obvious
> flaws (see the police proposal) not being possible at the current rate
> of a new proposal every second day.
>
> In the interest of keeping the list at least half usable, I would
> suggest that we all, starting now, voluntarily submit to:
>
> - not posting more than 30 times per month (the 30 comes from the WMF
> mailing lists, where it seems to work quite well)
>
> - not more than one proposal per person per month
>
> - not more than 4 new proposals per month in total
>
> Simon
>
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Jo]

Indeed not a platform, just a bus stop with a bench and maybe a shelter,
not sure. If the kerb were a bit higher where the bus halts, I'd say
platform, but this is just a sidewalk.
That we map such a node with public_transport=platform/bus=yes doesn't make
it a platform. That's just convention since the PT v2 scheme appeared.

Polyglot

On Fri, May 24, 2019 at 12:20 AM Graeme Fitzpatrick 
wrote:

>
>
> On Fri, 24 May 2019 at 04:49, Dave F via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>> Platform should only be tagged when their is a *physical* object of a
>> raise platform, not just an imaginary area of pavement.
>>
>
> Sorry, but do you mean that this:
> https://www.google.com/maps/@-28.0841684,153.4150288,3a,75y,46.69h,72.55t/data=!3m6!1e1!3m4!1s4hTF-eOoQp3yhcCIfyJelw!2e0!7i13312!8i6656
> is *not* a public_transport=platform, which iD defines highway=bus_stop
> as?
>
> If not, then what is it?
>
> Thanks
>
> Graeme
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Jo]

a platform, whether tagged as public_transport=platform, highway=platform
or railway=platform is always accessible and routeable for pedestrians. So
no need to explicitly tag them with highway=footway or foot=yes or
something of that nature.

Polyglot

On Thu, May 23, 2019 at 6:28 PM Nick Bolten  wrote:

> I'm confused, because these two statements seem incompatible. If it's
> redundant, how can it also have a conflict like different address
> restrictions? I'd like to know how, as a data consumer, I should reliably
> interpret existing platforms without the tag added by iD.
>
> Taking a step back, can anyone name an instance where a linear transit
> platform is not a footway?
>
> On Thu, May 23, 2019, 12:49 AM Markus  wrote:
>
>> I agree that adding highway=footway to platforms is not only
>> redundant, but (as pointed out by Michael) is bad because platforms
>> often have different access restrictions than highway=footway. iD's
>> validation rule should be removed.
>>
>> Regards
>>
>> Markus
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> 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] Misuse of name tag for route description

[Jo]

OK, so I tested and I renamed one of the many bus routes I'm maintaining,
moved from name to description. And you know what: both JOSM and the web
interface now show the ref instead of the description, so until that gets
resolved there is not very much chance people will want to move from the
name tag to the description tag.

As always, there is, of course, a reason why we 'abuse' the name tag for
this purpose. Personally I also don't think it's abusing the tag.

For the people proposing t use what is on the 'film' on the front of the
bus: there are itineraries where this text changes midway, so that's
definitely not the name fo that specific itinerary either.

Jo

On Sat, May 11, 2019 at 8:54 PM Philip Barnes  wrote:

> On Sat, 2019-05-11 at 19:09 +0100, Paul Allen wrote:
>
> On Sat, 11 May 2019 at 18:53, Mateusz Konieczny 
> wrote:
>
> The question is whatever it requires separate proposal to fix old proposal
> or is invoking
> general rule "name tag is for name, description tag is for description"
> sufficient.
>
>
> Sometimes, and not  just for bus routes, the name and the description are
> identical.
>
> Not far from me is a house that is painted red.  Its name is Ty Coch (in
> less sloppy
> orthography it would be Tŷ Coch, but it's lost the accent over time).  The
> name has long
> been Ty Coch.  It's Welsh for "Red House."  There are a LOT of house names
> around here
> that, if they weren't in Welsh, some mapper checking my work would think
> I'd entered the
> description rather than the name.  I recently mapped an events venue in a
> converted
> farm building that calls itself "The Shed" because it's in a large shed.
> And mapped the
> building used as a play area for a campsite as "The Barn" because that's
> what the operators
> have named it, it just happens to be in what is a Dutch barn.  There are a
> lot of buildings
> that used to be mills which have names like "White Mill," "Red Mill,"
> "Garnon's Mill,"  Etc.
>
> Be careful not to insist that something cannot be the name of a thing
> because it also
> happens to be a description of that thing.  People are lazy and have
> limited imaginations:
> sometimes the description is used as the name.
>
>
> Not necessarily lazy, but names come from before the time of mass
> literacy.
>
> Back in time you would have said you live at Tŷ Coch and someone who could
> not read would find your house.
>
> The same with pub name, they are often descriptions of the picture, hence
> we still have names such as The White Lion, The Dog and Pheasant or Y Llew
> Coch.
>
> 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] Misuse of name tag for route description

[Jo]

And I like to see all that prepended with the name of the operator...

Polyglot

On Sat, May 11, 2019 at 7:32 PM Markus  wrote:

> On Fri, 10 May 2019 at 18:16, Markus  wrote:
> >
> > On Fri, 10 May 2019 at 13:50, Hufkratzer  wrote:
> > >
> > > It would probably better to use description=* than from=* and to=*
> > > because not all routes have a named starting point or destination
> point,
> > > like e.g. a roundtrip route around some village.
> >
> > That's true. I didn't think about that.
>
> But circular lines or trips have an intermediate stop or location,
> thus it should work with via=* even if from=* and to=* are the same.
>
> Regards
>
> Markus
>
> ___
> 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] Proposal: add Tag:route=share_taxi and Tag:route=minibus for public transportation relationship

[Jo]

If we're expanding the list of possible tags for buses, we shouild probably
also consider route=coach, for long distance travel on a regular schedule.

Polyglot

On Mon, Mar 18, 2019 at 11:57 AM Martin Koppenhoefer 
wrote:

> I admit I am not familiar with the situation on the ground, but your
> suggestions sound reasonable.
>
> Cheers,
> Martin
> ___
> 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] Superroutes - good, bad or ugly?

[Jo]

When I start mapping a bus line, I have several route relations which
contain all the stops for each variation in itinerary.

When I add the ways, it would be nice to reuse subroute relations for the
parts where ways are shared between lines.

When I come back later and I want to compare whether the number of
variations for a line is still the same, I want to compare against
sequences of stops in the route relations, hence the reason why I would not
add the stops to the subroute segments. (Compare against data from the
operator or GTFS)

We also have 'express' lines that skip stops. if the stops are put in the
subroute relations, then they can not be reused for those lines.

As far as I'm concerned, the sequence of stops is the 'signature' defining
each variation in itinerary.

Polyglot

On Fri, Mar 15, 2019 at 6:55 PM seirra blake 
wrote:

> key: almost tagging should occur here | data may be reused in parent |
> data may be reused in parent and any 'adjacent' (with the same letter)
> parent
>
> *public transport network* [A]
>
> *route_master=public transport *[B]
>
> *route variant* [C]
>
> *combined stop/way relation suitable for public transport v2* [E]
>
> *shared way relation* [G]
>
>
> *road network* [A]
>
> *road *[C]
>
> *shared way relation* [G]
>
>
> *cycle network* [A]
>
> *cycle route *[C]
>
> *shared way relation* [G]
>
>
> _
>
> potential new tags that may be required:
>
> [C]: shared=yes (to tell the software there is use of shared ways, but the
> software probably should be able to work that out)
>
> [E/F/G]: route=shared (this is considered in case type=route explicitly
> requires a route=* key)
>
>
> _
>
> notes:
>
>- [G] may be infinitely nested as required to prevent duplicate sets
>of ways (although this should rarely be required)
>- [G] may require names in some cases and should always require
>type=route, but should include no other tags unless it very specifically
>relates to only the members of the relation and can't be included in any
>parent relation (unicorns are probably more common)
>- [G] should almost always not be used for a single way unless it will
>assist in maintainability. if a
>- I don't believe route_master=public transport actually exists, but
>the same concept should work for any public transport
>- the route=* tag should not be required until you move up to [C],
>shared way relations and bus stop relations should be open to any route
>type to increase re-usability
>- as they are just a connected line of ways, shared way relations
>should be usable in either direction, the direction to use could be
>specified via a role. although reusable for routes going in the same
>direction, [E] will rarely be reusable for both directions of a route
>because it contains both platforms and stops, and platforms usually differ
>depending on direction.
>- if this becomes accepted it may become a good idea to specify a
>members limit for relations (at which point it should be split up). such
>ways should probably
>- I may consider adding a rough idea on perceived pros/cons, depending
>on demand
>- I may add a more visual version, depending on demand
>- I may add an actual example, depending on demand (if you wish to add
>your own as well, or an inspired version please base it heavily on reality
>if it is on main OSM. do not make any existing route relations unusable)
>
>
> _
>
> changelog:
>
> #0
>
>- initial concept
>
> #1
>
>- removed [D] and [F]. [D] was meant to be removed prior to sending,
>[F] is not required.
>- added a few more notes so it may be referred to on its own
>- the bus example applies to any public transport really, adjust
>language accordingly
>- warned against damaging existing relations' usability/the creation
>of fictional data
>- added extra details on a request if needed basis
>- added this changelog and relevant versioning to help people keep
>track. this should be traceable to the (unlabelled) version 0
>
> special thanks:
>
>- you may request your name here and optionally credits for ideas you
>contributed (being kept in an opt in basis in case people don't want their
>names shown)
>
> On 3/15/19 2:37 PM, seirra blake wrote:
>
> I can see *a lot* of shared routes in my area because most of the buses
> heavily use a star topography (everything must take you to a central
> station) as opposed to a hybrid mesh/star topography (everywhere has access
> to a service to a central station, but there are circular routes to allow
> quicker travel in some circumstances). for example my local service has one
> incredibly early train station detour (presumably for long 

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

Good analysis Seirra,

I would not "reuse" route=road in other route=* relations though.
route=bicycle might share segments with route=foot/walking/hiking, but I'd
keep everything related to bus/trolley_bus and coach together in terms of
sharing of subroutes not mix it with other route types.

For public transport the biggest benefit will be ease of maintenance.

The way I see it route=bus relation should describe a single variation in
itinerary, and thus include all the stops for that variation. So in my view
the subroutes only contain ways.
I would create subroutes for each direction of travel, so no
forward/backward roles need to become involved. If the subroute would only
contain a single way, a subroute relation probably wasn't needed.

Paul Allen, I did read your objections to this, but that bus route is
wildly exceptional, whereas buses travelling along 'corridors', reusing the
same roads as the rest of the lines is very common (as that is where the
stops are, obviously).

Maybe I should try to create an example somewhere. Preferably a small
island

Polyglot

On Fri, Mar 15, 2019 at 3:38 PM seirra blake 
wrote:

> I can see *a lot* of shared routes in my area because most of the buses
> heavily use a star topography (everything must take you to a central
> station) as opposed to a hybrid mesh/star topography (everywhere has access
> to a service to a central station, but there are circular routes to allow
> quicker travel in some circumstances). for example my local service has one
> incredibly early train station detour (presumably for long distance
> commuters), the two main routes (incoming/outgoing) and a route that stops
> at the bus depot. all 4 of these routes share a large part of it and that's
> just one route number! such route segments could help shrink and simplify
> maintaining the relations a lot. for example if there's a detour due to
> roadworks, you don't have to edit the very large number of relations
> individually, (our bus station has around 20 bays, each taking multiple
> services...) just the shared child relations. I don't think we need a
> specially labelled super route relation, but perhaps we do need a way to
> tell the data user that a segment is shared. these are the problems I see:
>
>1. where do the tags go?
>2. do you need a separate one for each direction?
>3. is type=super_route or similar the best idea?
>4. how far can they nest?
>5. a shared route is being used for public transport, should the stop
>positions and bus stops be included with all the ways?
>
> so... what do we do? this is what I see as a solution:
>
>1. if a route is shared, tags should be minimal and only related to
>the physical route itself perhaps not even including the usual route tag
>(AFAIK wouldn't just about any route relation in existence define the route
>tag? so this would just be another pointer to the software that this isn't
>your regular route. but maybe it still is best to tag it, in which case
>maybe route=shared?), rather than things such as what bus routes it is part
>or anything, this can easily be seen simply by looking at parent relations
>2. maybe use the roles forward/backward? I don't think these are used
>for much any more
>3. what do we gain? I think this can more easily be solved by simply
>adding another tag such as shared=yes which can tell the software that
>there are route relations that are intended to be treated as just one big
>way. see below for a more detailed explanation.
>4. I don't see a reason to limit the nesting, I imagine in most use
>cases, the benefit of sharing duplicate relation data probably outweighs
>any impact from processing nesting
>5. if a shared route is used for both a numbered road route and public
>transport it's probably unfair on the road user that doesn't need them if
>they are included. also this would make it difficult to work out where to
>place it in a public transport V2 relation.. as they have stops at the top,
>ways at the bottom but this has both!
>
> so here's an indented, somewhat simplified example of how it roughly would
> nest based on the idea of a public transport route, a cycle route and a
> road relation that share the same set of ways (*underlined*=can be shared
> in parent nesting level, *bold*=can be shared in nesting levels outside
> of the parent one, italic=the level at which main tagging should occur. for
> easier referencing each equivalent level of nesting has been assigned a
> letter):
>
>
> ___
>
> *bus network* [A]
>
> *route_master=bus *[B]
>
> *route variant* [C]
>
> *route segments* [D]
>
> *combined bus stop/way relation suitable for public transport v2* [E]
>
> *shared bus stop relation* [F]
>
> *shared way relation* [G]
>
> *road network* [A]
>
> *road *[C]
>
> *shared way relation* [G]
>
>
> *cycle network* [A]
>

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

I would definitely want routes to be composed of subroutes which are shared
with other routes, hence the reasoning of keeping the stop sequences in the
route relations.

Polyglot

On Thu, Mar 14, 2019, 15:41 Paul Allen  On Thu, 14 Mar 2019 at 11:21, Tony Shield 
> wrote:
>
> Am I right in thinking that a superroute is a sequence of ways and
>> relations of ways?
>>
>
> I'm not 100% certain.  The documentation on the wiki isn't entirely
> clear.  I suspect some of it
> may have been scrubbed by those who dislike the concept of superroutes for
> any purpose
> whatsoever, but it may just never have been written in the first place.
>
> As I understand it (possibly entirely inccorectly) it would be analogous
> (using a slightly
> different mechanism) to having the Wales Coast Path be a relation
> comprising the
> route for the Pembrokeshire Coast Path, the Ceredigion Coast Path, etc.  A
> relation of
> relations.
>
>
>> The relation of ways could be called a route-segment or similar. A I see
>> it routes for most trains and buses are a sequence of ways and
>> route-segments, and a route-segment could be used by many routes.
>>
>
> I wasn't intending to share segments between routes.  I'm not sure if I
> could make that work for
> some of my purposes (I haven't thought about it enough to be sure).  It
> probably won't be
> universally applicable anyway, there are going to be routes that share a
> particular segment but
> not all of the stops on that segment.  Also fan-out of routes is going to
> result in a lot of very
> tiny segments that are possibly more trouble than they're worth and it's
> probably less work to
> make them longer segments.
>
> --
> Paul
>
> ___
> 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] Superroutes - good, bad or ugly?

[Jo]

I think we should move to subrelations for bus routes at some point.
Actually doing it is somewhat tricky. We'd definitely need editor support
to show that a route which consists of subroutes is continuous or not. The
biggest point of contention seems to be whether the stops should go into
the subroute relations as well. I'd say no. Keep the stop sequences for a
particular variation in itinerary together in a route relation per
variation. And only use the subroutes to collect continuous sequences of
ways.

At the same time, some people would think it's more logical to have a
sequence of ways, then a stop, then the next sequence, a stop, and so on.
For that too, it would be nice to have editor support that shows that the
way before and the way after actually connects, or not.

If we go the way of subroutes for PT routes, I/we can probably coerce a
GSoC student to create support for it in PT_Assistant over the summer.

Polyglot

On Wed, Mar 13, 2019 at 11:20 PM Graeme Fitzpatrick 
wrote:

>
>
> On Thu, 14 Mar 2019 at 00:05, Paul Allen  wrote:
>
>> or should I stick to eating babies as that would be more socially
>> acceptable?
>>
>
> I guess that sort of depends on whether or not they're Irish babies
> https://en.wikipedia.org/wiki/A_Modest_Proposal
>
> & we're having Roast Peasant under Glass for dinner tonight - feel like
> joining us? :-)
>
> & as for super-relations - ??? :-)
>
> Thanks
>
> Graeme
> ___
> 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] Public Transport Timetables Proposal RFC

[Jo]

Regarding the proposal, feel free to try and apply it on your bus routes.
And if you mapped say a hundred, you can even change the proposal's status
and bring it up for a vote. Be prepared for quite a bit of resistance
though, but for what it's worth, I'm likely to vote in favour. The main
point people will have against it, is that it is data that is very hard to
maintain and keep up-to-date.

Also, maybe you find flaws in it, so if you can improve on it, go for it.

Once I have a bit more time, I'll probably move forward with the agency
proposal.

Polyglot

On Fri, Feb 15, 2019 at 8:04 PM santamariense  wrote:

> > I also created a proposal, but I knew in advance it wouldn't be practical
> > to duplicate full GTFS functionality in OSM.
>
> Well, this is not a so simple question. There're many countries around
> the world that have no GTFS. And, it's just what happens to us in
> Brazil. We are mapping intercity bus routes in the state where I live.
> So, if we have this data in OSM, maybe we are going to be the pioneer.
>
> Do not map GTFS in OSM for me sounds like do not map building in city
> X because it's available in town hall.
>
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> I didn't follow the discussion but this proposal is at least helpfull.
> Why do not map xx:xx in the same route relation? Role examples:
> stop@00:20, stop_exit_only@03:45, stop_entry_only@00:25-00:31, and for
> bus stops where the timetable is approximated (like in Brazil) use "~"
> for the usual times, examples: stop@~00:27-00:30,
> stop_exit_only@~00:46
>
> > https://wiki.openstreetmap.org/wiki/Public_transport_agencies
>
> It has gone to my wiki watchlist so I can follow it in its developing.
>
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures
>
> This proposal is as simple as possible and it's better to be so.
> However it doesn't cover all situations. For example, stops that have
> checkpoint, in another words, that have exact time to arrive and/or
> leave intermediaries stops. Many times only duration=* cannot be
> enough to accurate times in intermediaries stops.
>
> LeifRasmussen, what do you think about to attach "duration in roles"
> to complement the proposal? It is supposed to be used not in all
> stops, but only in those that have exact time to arrive/leave, or at
> least a well known usual time.
>
> ___
> 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] Public Transport Timetables Proposal RFC

[Jo]

I think most people will be against having variable roles in the route
relations.

Polyglot

On Fri, Feb 15, 2019 at 8:04 PM santamariense  wrote:

> > I also created a proposal, but I knew in advance it wouldn't be practical
> > to duplicate full GTFS functionality in OSM.
>
> Well, this is not a so simple question. There're many countries around
> the world that have no GTFS. And, it's just what happens to us in
> Brazil. We are mapping intercity bus routes in the state where I live.
> So, if we have this data in OSM, maybe we are going to be the pioneer.
>
> Do not map GTFS in OSM for me sounds like do not map building in city
> X because it's available in town hall.
>
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> I didn't follow the discussion but this proposal is at least helpfull.
> Why do not map xx:xx in the same route relation? Role examples:
> stop@00:20, stop_exit_only@03:45, stop_entry_only@00:25-00:31, and for
> bus stops where the timetable is approximated (like in Brazil) use "~"
> for the usual times, examples: stop@~00:27-00:30,
> stop_exit_only@~00:46
>
> > https://wiki.openstreetmap.org/wiki/Public_transport_agencies
>
> It has gone to my wiki watchlist so I can follow it in its developing.
>
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures
>
> This proposal is as simple as possible and it's better to be so.
> However it doesn't cover all situations. For example, stops that have
> checkpoint, in another words, that have exact time to arrive and/or
> leave intermediaries stops. Many times only duration=* cannot be
> enough to accurate times in intermediaries stops.
>
> LeifRasmussen, what do you think about to attach "duration in roles"
> to complement the proposal? It is supposed to be used not in all
> stops, but only in those that have exact time to arrive/leave, or at
> least a well known usual time.
>
> ___
> 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] Public Transport Timetables Proposal RFC

[Jo]

I also created a proposal, but I knew in advance it wouldn't be practical
to duplicate full GTFS functionality in OSM:

https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

I'm creating this proposal, which does have information about the operators
/ agencies, which we don't have yet and which would be maintainable, but I
should work some more on properly defining it:

https://wiki.openstreetmap.org/wiki/Public_transport_agencies

Polyglot

On Thu, Feb 14, 2019 at 5:24 AM santamariense  wrote:

> > The last edit on that proposals says
> >
> > 'Made this proposal abandoned and noted that it has been replaced by the
> > proposed key "departures"' So look there?
>
> Yup. I've already read all proposal and it's no too clear for me where
> departures=* and interval=* go. I've understood that they go in the
> route relation itself. Or would it be in a public_transport=timetable
> relation? If the answer is the second option, it goes in every
> bus_stop, only in the start one or all ones that have checkpoints?
>
> What are the current valid examples?
> https://www.openstreetmap.org/relation/8873463 ? Would you have full
> examples to link into wiki?
>
> I feel the proposals is poorly exemplified.
>
> ___
> 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] Public Transport Timetables Proposal RFC

[Jo]

The proposal was voted upon.

On Mon, Feb 11, 2019 at 9:54 PM Tijmen Stam  wrote:

> On 31-10-18 00:54, Leif Rasmussen wrote:
> > Hello everyone!
> > I recently wrote up a proposal page for public transport schedule data.
> > This information would allow OpenStreetMap to store information about
> > when or how often certain buses or trains arrive at a platform.
> >
> > https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules
> >
> > Please feel free to look over the page and give feedback.  I am very
> > open to changing the proposal, so let me know if you have any ideas for
> > improvements to it.
> > Thanks,
> > Leif Rasmussen
>
> On January 3rd this year, Leif added the "Interval" and "duration" tags
> to the wiki for bus route:
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dbus=revision=1767271=1684316
>
> I have sideways followed this discussion, but I had the idea there was
> widespread opposition for having any timetable info added to OSM.
>
> I don't think we should have this on the wiki without proper proposal
> voting - or did I miss something?
>
> ___
> 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 - RFC - (Hierarchies route=bicycle)

[Jo]

The existing scheme for tagging cycle routes is robust. The problem I see
when 'reusing' it in a hierarchy of routes, is that we would need a role to
indicate that the sub route is traversed in reverse for a particular
"super" route. It would also help to have an indicator in JOSM to indicate
continuity in the super route IF the sub route is continuous AND the last
node of the way / relation before it is the first of the sub route's way
AND the same applies for the last waynode in the sub route and the next way
/ route in the superroute.

iD is not ideal for working with route relations. It could be changed,
obviously, if a developer can be found who wants to dedicate to such a
task, but at the moment JOSM is your best bet to have a reasonable
experience working on such routes. For now we're already glad if iD doesn't
break the route relations.

Polyglot

On Wed, Jan 2, 2019 at 6:39 PM Richard Fairhurst 
wrote:

> Axelos wrote:
> > Hello, I propose a concept for contributing cycling route.
>
> Many thanks for looking at this - the current state of bike route
> hierarchies is a mess, and trying to parse the many different tagging
> practices so that cycle.travel can display them properly has been a
> nightmare. It would be good to have a commonly agreed, intuitive standard.
>
> From the description on the wiki page, I'm not sure how your proposal
> differs from the practice documented at
> https://cycling.waymarkedtrails.org/help/rendering/hierarchies . Could you
> explain the difference?
>
>
>
> A few passing comments:
>
> > Example name = Boucle de la Moselle: Toul - Pompey
>
> Please don't do this - the name tag is for an object's commonly agreed
> name,
> and "Boucle de la Moselle: Toul - Pompey" is not the official name of any
> part of the route. You could perhaps use the description= or note= tag
> instead.
>
> There are lots of examples of this in your proposal: "name=PAN Segment 1",
> "name=Véloroute 50 : Étapes", and so on.
>
> (Similarly, some people have tagged sections of EuroVelo routes in one
> country with the network=ncn tag. This is wrong: EuroVelo routes aren't
> National, they're International. I think this is probably a mistaken
> attempt
> to get them to render on OpenCycleMap.)
>
> > To do this effectively, you will need a powerful editor: JOSM.
>
> This is a "tagging smell" (cf https://en.wikipedia.org/wiki/Code_smell).
> Any
> tagging scheme that requires a particular editor is probably a bad scheme.
>
> As it happens, you can certainly edit relations like this with Potlatch 2
> no
> problem and I guess you can with iD too; but before any tagging scheme like
> this is adopted, you should create a tutorial for iD users. It shouldn't be
> necessary to learn a whole new editor just to be able to tag a bike route -
> as you yourself say, "Is the hierarchy of cycle routes reserved for
> experts?". Bear in mind too that iD users _will_ edit these routes, so the
> scheme should be intuitive and robust (of course, that should be the case
> anyway!).
>
> cheers
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> 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] Trailhead tagging

[Jo]

Please don't add public transport stops to hiking route relations. That
would be really confusing.

Polyglot

On Wed, Jan 2, 2019 at 2:39 PM Dave Swarthout 
wrote:

> Peter: " Mapping a trailhead node as I suggested does not stand in the way
> of more complex options. My idea: begin with the simplest common element
> which supports all the other options. "
>
> +1
>
> On Wed, Jan 2, 2019 at 8:13 PM Peter Elderson  wrote:
>
>> Sometimes it would, sometimes it would not. If the node actually
>> represents the start of the trail, it is already in the relation because it
>> is part of the way that belongs to the route. In the situation that a
>> trailhead node represents a named cluster of helpful facilities/amenities
>> in the vicinity of several trails or networks, you wouldn't want to add it
>> to all the relations, because a. it's not actually part of the routes and
>> b. maintenance of all the routes would be quite error-prone and not really
>> intuitive.
>>
>> A site relation has been suggested for the more complex trailheads. You
>> would include the node there, the parking(s), the information booth or
>> guide stands, maybe PT-stops, possibly the route relations you can access
>> from the site...
>>
>> Mapping a trailhead node as I suggested does not stand in the way of more
>> complex options. My idea: begin with the simplest common element which
>> supports all the other options.
>>
>> Op wo 2 jan. 2019 om 12:04 schreef Tobias Wrede :
>>
>>> Wouldn't it make sense to add the trail head (node) to a route relation
>>> with role=trail_head?
>>>
>>> Am 01.01.2019 um 12:54 schrieb Peter Elderson:
>>> > At this point, I settle for just requiring that it's a named location
>>> > visibly designated as access point for one ore more recreational
>>> routes.
>>> >
>>> > So just a node tagged highway=trailhead and name=>> trailhead>.
>>> >
>>> > Which node? Well, if it's just the start with a name on a guidepost,
>>> > use the guidepost node. If it's an information board with the name,
>>> > use that. If there is a flagpole or a stele or say a statue of the
>>> > pioneer who walked it first, use that. If there is none of that, use
>>> > the location which presents itself naturally as a starrting point when
>>> > you get there. If there is no such location, then it's not a trailhead!
>>> >
>>> > Anything else: optional, map and tag as seems appropriate.
>>> >
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> Vr gr Peter Elderson
>> ___
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Follow-Up Proposal - voting ended - (Tramtrack on highway)

[Jo]

I look forward to a new vote and will vote in favour of what you're
proposing now.

Polyglot

On Mon, Dec 3, 2018 at 8:29 PM Nikulainen, Jukka K <
jukka.nikulai...@helsinki.fi> wrote:

> Hello Paul, and thank you for your input!
>
> You are indeed correct that my follow-up proposal would very radically cut
> corners and be, to say the least, unorthodox. I'm certainly sorry if it
> offended the sensibilities of anyone.
>
> I can see now that it could be construed as malicious and you are
> certainly right that implementing a new vote on a new proposal would not be
> an excessive amount of work.
>
> Indeed, doing a new proposal and a new vote seems the right thing to do,
> and I'll get to it soon!
>
> Please let me explain the rationale my odd follow-up proposal, as a few
> lines in your response did catch my eye:
>
> > 1) Your analysis is correct. The new proposal would meet with universal
> acclaim and pass unanimously.
>
> I don't quite understand how you could possibly have reached the
> conclusion that I would expect "universal acclaim" or unanimity, from
> anything that I've written in the follow-up. It seems to me painstakingly
> obvious that neither would ensue, judging only from the opposing votes and
> critical comments on the original proposal.
>
> Furthermore, responding to your second point, I was not aware that
> "universal acclaim" was required for a proposal to pass as you suggest. At
> least the proposal process wiki page seems to say otherwise. But of course
> I could just be moronically illiterate, in which case: mea maxima culpa!
>
> I would also argue that my follow-up proposal isn't based on blitheness.
> Rather it is based on the sixteen approving votes on the original proposal
> and the quite acute and perceptive critical comments they contained and
> conveyed. Nor is expediency alone my motivation (though I must admit, it is
> a consideration too).
>
> I, rather, worry whether enough people will be interested to vote again on
> a similar proposal only with changed tag-values. Many of the interesting
> critical comments and interested people in fact came forth only after
> voting had started and the proposal could no longer be changed. It would be
> a shame if the idea (which, again, _did_ garner support on the first round)
> would be lost in the absence of interest on a second proposal and vote. But
> maybe I just worry too much.
>
> Sincerely,
> Jukka Nikulainen (Tolstoi21)
>
> ___
> 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 - (Tramtrack_on_highway)

[Jo]

It is still possible to tag a highway with 1 single railway track on it
highway=* + railway=tram/train. But this proposal is for the case where the
highway has 2 railiway tracks which are already mapped separately because
the way railways curve is different from how how highways behave at
intersections.

This tag is only a hint for routers, so cyclists can try to avoid such
ways. What it really means is, there are railway tracks, BUT they are
already mapped on  separate OSM object that runs mostly parallel to this
highway.

Polyglot

El jue., 22 nov. 2018 a las 6:55, Yves () escribió:

> Sergio,
> This is not an issue, anyway some will argue that the highway is a highway
> AND a railway too, so they would be happy too.
> Yves ___
> 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 - (Tramtrack_on_highway)

[Jo]

The whole issue is that due to tram rails bending differently than road
ways, the tram rails are mapped on their own OSM ways. This gives a nicely
detailed rendering, a better description of reality, but now the
information that for the straight parts the rails are embedded into the
highway is missing. It's just a model, not a highly detailed architectural
plan.

I would also be in favour of not using railway=*,

embedded_rails conveys more information without going into conflict with
the railway ways. We don't want to render them 3 times if there are 2
tracks.

Polyglot

El mié., 21 nov. 2018 a las 10:04, Nikulainen, Jukka K (<
jukka.nikulai...@helsinki.fi>) escribió:

> Sorry, I forgot to comment on this earlier
>
> >embedded_rails=yes or even more precise
> >embedded_rails=tram | embedded_rails=railway.
> >The latter is even worse for bicycles, because the rail grooves are
> >broader.
>
> It is true that that would be more precise, but are there in fact any
> examples of this? I mean a railway that runs parallel to _and_ on a road?
> Usually highways do cross railways, but this is not a problem, since one
> approaches the rails (and the grooves) tangentially and they do not pose a
> great danger.
>
> But you are of course correct that this tag would allow for more specific
> tagging, if this is something that is needed.
>
> Sincerely,
> Jukka (Tolstoi21)
>
> ___
> 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] Public Transport Timetables

[Jo]

One thing that I found while trying this 'little' exercise is that it would
be good to have an object that 'represents' an operator or a network. I was
using this to keep track of holidays with Sunday schedule and when school
vacations are, because that influences the timetables, but it  could
definitely also serve to point to where one can find a GTFS for the
operator/network/agency and how GTFS fields translate to OSM tags:

In my region I have started to use ref:De_Lijn=102345, in the GTFS feed I
found this corresponds to the stop_code field.

What I plan to do is to add a url tag to all the stops, that lead to a web
page with realtime for each separate stop. On the route_master relations, I
plan to point to the operator's web site's page describing that particular
line.

Polyglot

Op do 8 nov. 2018 om 22:53 schreef Paul Allen :

>
> On Thu, Nov 8, 2018 at 9:27 PM Andy Townsend  wrote:
>
>>
>> FWIW I've just used https://www.traveline.info/ to find journey between
>> Porthmadog and Criccieth and Bearsden and Milton of Campsie (yes!  There
>> are ones at this time of night!) so the main site does  indeed work in
>> Wales and Scotland.
>>
>
> Yes, it works.  But it doesn't have an option to use Cymraeg.  Which would
> be a show-stopper
> for some people in Wales, who would rather use a site that is completely
> broken if it is in
> Welsh rather than a site that works but is only available in English.
>
> Also, the .cymru site has something the .info site does not, route maps.
> I just pulled up a local
> route and looked at its map.  Admittedly it is a very weird and
> complicated route (reminiscent of
> a spider web on drugs), but this route map gets it wrong in many, many
> ways:
>
> https://www.traveline.cymru/timetables/?routeNum=408_id=0_key=408MFRBA1
>
> Kinda reminds me of a Google bus route I looked at several years ago which
> apparently drew straight
> lines (through houses and across fields) between timetabled stops rather
> than following a road between
> them.  Told me to get to a location on the actual bus route by getting off
> a mile beyond and walking
> back because it had joined the stops with straight lines through fields.
> It was only by playing around
> that I got it to show the route it was using, which at one point ploughed
> through the middle of a small
> housing estate and took a straight line across farmland to the next
> timetabled stop.
>
>
>> Other than Traveline, plenty of other OSMers* have worked in the
>> transport / route planning area - both "startups" and more traditional
>> transport authorities.  I know of others have looked at consuming GTFS for
>> bus routes in England, and found that it can be a bit complicated as the
>> same numbered route can exist multiple times in the GTFS feed with only
>> minor differences for the variations - it's not just a simple case of "grab
>> all that data from there and use it" unless you're prepared to do quite a
>> bit of processing.  You really need to be an app to do anything useful with
>> the data (such as https://oeffi.schildbach.de/index.html - which works
>> everywhere in GB that I've tried it and presumably uses Traveline's feeds,
>> or something similar) - anything else would just be "reinventing GTFS".
>>
>
> So what's the copyright situation with Traveline's GTFS feeds?  Are we
> free to use any of them to add
> routes to OSM?  Obviously, they'd have to be sanity-checked...
>
> --
> Paul
>
> ___
> 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] Public Transport Timetables

[Jo]

(started writing this several hours ago)

The way this proposal is evolving, there will be 2  versions. One that
gives an approximate idea of how much time there is between 2 buses for a
given time of day/day of week. Those can be added as tags on the route
relations.

That one should not be dismissed outright.

And another that goes into full detail, listing all the departures at the
first stop and then lists all stops, with the most common times between
stops as roles. For this we would need separate public_transport=timetable
relations.

I've been trying how that could work and I can confirm what everybody
already knew: it's a lot of work, even for lines that seem relatively
simple at first sight! :-) An incredible time sink.

It is an interesting exercise though and I found some errors in the route
relations while doing it.

One of the shortcuts I took when creating route relations is that I only
mapped the longest variations. An advantage of adding the timetables the
way I'm proposing it, is that the stop sequences of the shorter variations
now also become visible. This may make validation easier to do. When stops
are not in order anymore in a route relation, the validator can detect that.

But it's a lot of data to add and it becomes stale very quickly, plus it's
hard to verify whether it's still OK, or not, even more so than the route
relations for the buses. The only advantage is that they don't
'deteriorate' due to other people mapping. Errors are introduced in route
relations all the time because they are so 'fragile', due to ways getting
split, removed/readded to OSM, but not to the relations, etc.

Anyway, I wanted to make sure that the proposal is as good as can be, but
I'm not convinced that it's maintainable for a larger region either.
Of course, 10 years ago, I was not convinced any small group of volunteers
would be able to create a detailed map of the world.

I think, at present, it's far more important we get to a way of mapping
public transport with a single object (preferably a node next to the
highway) to represent each stop.

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

Re: [Tagging] Public Transport Timetables

[Jo]

Indeed, a mapper who wants to add this and who can't find the information
on the internet or in a booklet, would have travel to the first stop, take
note of all the departure times and then establish the deltas between all
the stops of the itinerary.
If that's the case, such a mapper would probably better use the tags based
method on the route relations.

It all depends on how much detail you want to add (and maintain in the long
run).

Another weakness of the relation pet stop/route pair method is that it will
be very hard to encode the exceptions; not on Wednesdays, only on Fridays,
etc.

Jo

Op di 6 nov. 2018 om 20:22 schreef djakk djakk :

> Ok I see.
>
> I am still a bit reluctant to your proposal since the travelling time
> between 2 stops can vary during the day, especially for train routes.
> Ok there is the possibility of adding a new timetable relation ...
>
> Moreover, I think that data inputs from the ground can not be done with
> your proposal (it needs to know the timetable for the whole line), we’ll
> depend on GTFS file actually :-/
>
> Julien “djakk”
>
>
>
> Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>
>> Yes, very hard to debug and we already established some change every few
>> months. So after a change from the operator. One traveler will update one
>> of those schedules, Another may do so for 3 stops down the line, in the
>> mean time the stops in between and after are not updated yet. A maintenance
>> nightmare. The way I proposed it, suffers less from that problem. When
>> timetables change it's usually that trips are added or removed or their
>> start time changes slightly. The time to get from one stop to the next will
>> remain constant, most of the time.
>>
>> Jo
>>
>> Op di 6 nov. 2018 om 18:40 schreef djakk djakk :
>>
>>> I don’t get it ...
>>>
>>> With my point of view, one route with 15 stops has 15 timetables, each
>>> timetable describes the arrival time and the departure time of several
>>> trips at the stop.
>>>
>>> There must be the same number of trips along the stops’ timetables.
>>> (Otherwise this is an other route).
>>>
>>> You mean, if somebody messed up and add an extra trip inside a
>>> timetable, this would be hard to figure ?
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>>>
>>>> If you have a single one for a stop/route pair, no problem. As soon as
>>>> you have a few hundred and the information in them starts to conflict with
>>>> other another timetable relation for the same route it will be extremely
>>>> hard to figure out where it went wrong.
>>>>
>>>> Polyglot
>>>>
>>>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>>>>
>>>>> In which case a timetable per stop and per route is unmaintable ?
>>>>>
>>>>> Julien “djakk”
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>>>>> écrit :
>>>>>
>>>>>> I think it is important to have an osm object describing the
>>>>>> timetable user-oriented for simple editing without any tool.
>>>>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>>>>> import it later in osm without the need of any extra tool.
>>>>>> Validator can be inside a tool.
>>>>>>
>>>>>> Julien « djakk »
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>>>>> écrit :
>>>>>>
>>>>>>> Almost that ! Sometimes bus stops does not have their official
>>>>>>> timetable, the user have to refer to the closest previous bus stop 
>>>>>>> having
>>>>>>> an official timetable. So this kind of bus stop may not have a 
>>>>>>> timetable in
>>>>>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>>>>>> habits the schedule).
>>>>>>>
>>>>>>>
>>>>>>> Julien « djakk »
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>>>>>
>>>>>>>> You mean per stop/route pair? That's an incredible s amount of
>>>>>>>> relations! It seems to me that it would be a nighmare to try and 
>>

Re: [Tagging] Public Transport Timetables

[Jo]

If you have a single one for a stop/route pair, no problem. As soon as you
have a few hundred and the information in them starts to conflict with
other another timetable relation for the same route it will be extremely
hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk :

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a écrit :
>
>> I think it is important to have an osm object describing the timetable
>> user-oriented for simple editing without any tool.
>> The mapper is at a bus stop, takes a picture of the timetable, can import
>> it later in osm without the need of any extra tool.
>> Validator can be inside a tool.
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>> écrit :
>>
>>> Almost that ! Sometimes bus stops does not have their official
>>> timetable, the user have to refer to the closest previous bus stop having
>>> an official timetable. So this kind of bus stop may not have a timetable in
>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>> habits the schedule).
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>
>>>> You mean per stop/route pair? That's an incredible s amount of
>>>> relations! It seems to me that it would be a nighmare to try and maintain
>>>> it that way. At first sight it seems simpler, but with the new proposal i
>>>> came up with, you can see how the stops of a variation in itinerary tie
>>>> together.
>>>>
>>>> If the vehicle remains in the station longer, the roles could become
>>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>>> the vehicle left at its first stop.
>>>>
>>>> Seeing the stops in the timetable relation in the order they are served
>>>> also enables comparing this with the stops sequence in the route relation
>>>> they refer to, adding additional possibilities for validation of the data.
>>>>
>>>> The stops in a timetable sequence should always be a subset of the
>>>> stops in a route relation and appear in the same order.
>>>>
>>>> Polyglot
>>>>
>>>>
>>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>>>>
>>>>> I’ll agree with Leif, having a timetable relation per stop is better.
>>>>>
>>>>>
>>>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>>>> arrival-departure pair of time.
>>>>>
>>>>> Julien « djakk »
>>>>>
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>>>>> écrit :
>>>>>
>>>>>> In order to reduce the length of the value of the departures= tag,
>>>>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>>>>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>>>>
>>>>>> Julien « djakk »
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>>>>> écrit :
>>>>>>
>>>>>>> Martin, maybe locals do know their bus stop timetable, as they
>>>>>>> always use the service they may memorize the schedules ... ?
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>>>>>
>>>>>>>> Hi Leif,
>>>>>>>>
>>>>>>>> You made me do it! :-) I sort of stole your proposal and started
>>>>>>>> creating a new one. It differs in rather important ways from your 
>>>>>>>> proposal,
>>>>>>>> so I preferred not modifying your wiki page. I also think it's 
>>>>>>>> important to
>>>>>>>> decouple the (voting for a) full timetable solution from the solution 
>>>>>>>> where
>>>>>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>>>>>> which is a lot more likely to be accepted.
>>>>>>>>
>>>>>>>> So

Re: [Tagging] Public Transport Timetables

[Jo]

You mean per stop/route pair? That's an incredible s amount of relations!
It seems to me that it would be a nighmare to try and maintain it that way.
At first sight it seems simpler, but with the new proposal i came up with,
you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become
00:30-00:35 instead of simply 00:35 for the departure offset to the time
the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served
also enables comparing this with the stops sequence in the route relation
they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in
a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk :

> I’ll agree with Leif, having a timetable relation per stop is better.
>
>
> Yes Leif, there can be a delay expressed in minutes instead of an
> arrival-departure pair of time.
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a écrit :
>
>> In order to reduce the length of the value of the departures= tag, should
>> we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>> écrit :
>>
>>> Martin, maybe locals do know their bus stop timetable, as they always
>>> use the service they may memorize the schedules ... ?
>>>
>>> Julien
>>>
>>>
>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>
>>>> Hi Leif,
>>>>
>>>> You made me do it! :-) I sort of stole your proposal and started
>>>> creating a new one. It differs in rather important ways from your proposal,
>>>> so I preferred not modifying your wiki page. I also think it's important to
>>>> decouple the (voting for a) full timetable solution from the solution where
>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>> which is a lot more likely to be accepted.
>>>>
>>>> So here goes:
>>>>
>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>>
>>>> Please let me know what you think. What I still haven't figured out yet
>>>> is how to differ weekdays that fall in school holiday periods from "normal"
>>>> weekdays. So work in progress.
>>>>
>>>> Polyglot
>>>>
>>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>>>
>>>>> Polyglot:
>>>>>
>>>> I think that having a timetable relation for each stop is less
>>>>> complicated than having one per route.  There are several advantages to
>>>>> this:
>>>>> 1) People can easily add a single relation at a time, rather than
>>>>> having to do the entire line at one time.  This could make it much easier
>>>>> to, for example, have a StreetComplete quest asking "What are the arrival
>>>>> times of bus X at this bus stop?"  iD could also have a field at bus stops
>>>>> with "arrivals for each parent bus route" that would allow people to
>>>>> seamlessly create timetable relations.  It also makes more features
>>>>> possible in the future, such as additional tags to each timetable.
>>>>> 2) The system is easier for newbies to learn to use.
>>>>>
>>>>> The disadvantage is that there are now a ton of relations per bus /
>>>>> train / subway route.  Creating these could made easier by a new JOSM
>>>>> plugin.  Also, if someone wanted to delete all timetable relations that 
>>>>> are
>>>>> part of a route, they could simply use this overpass query to download the
>>>>> data into JOSM and then delete all of the timetable relations:
>>>>> https://overpass-turbo.eu/s/Dlf
>>>>>
>>>>> If people really prefer a single timetable relation for each route,
>>>>> then I will go with that.
>>>>>
>>>>> Julien:
>>>>> Why not have a "delay"=">>>> at this platform>" tag instead of separate arrivals/departures tags?
>>>>>
>>>>> Thanks,
>>>>> Leif Rasmussen
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>>> 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] Public Transport Timetables

[Jo]

Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a
new one. It differs in rather important ways from your proposal, so I
preferred not modifying your wiki page. I also think it's important to
decouple the (voting for a) full timetable solution from the solution where
tags are added to indicate interval during 'opening_hours' or a route,
which is a lot more likely to be accepted.

So here goes:
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

Please let me know what you think. What I still haven't figured out yet is
how to differ weekdays that fall in school holiday periods from "normal"
weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:

> Polyglot:
> I think that having a timetable relation for each stop is less complicated
> than having one per route.  There are several advantages to this:
> 1) People can easily add a single relation at a time, rather than having
> to do the entire line at one time.  This could make it much easier to, for
> example, have a StreetComplete quest asking "What are the arrival times of
> bus X at this bus stop?"  iD could also have a field at bus stops with
> "arrivals for each parent bus route" that would allow people to seamlessly
> create timetable relations.  It also makes more features possible in the
> future, such as additional tags to each timetable.
> 2) The system is easier for newbies to learn to use.
>
> The disadvantage is that there are now a ton of relations per bus / train
> / subway route.  Creating these could made easier by a new JOSM plugin.
> Also, if someone wanted to delete all timetable relations that are part of
> a route, they could simply use this overpass query to download the data
> into JOSM and then delete all of the timetable relations:
> https://overpass-turbo.eu/s/Dlf
>
> If people really prefer a single timetable relation for each route, then I
> will go with that.
>
> Julien:
> Why not have a "delay"=" this platform>" tag instead of separate arrivals/departures tags?
>
> Thanks,
> Leif Rasmussen
> ___
> 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] Public Transport Timetables

[Jo]

You are right, for the concrete case of De Lijn it will be better to link
to their realtime data from the stops and add a url to the route relations
for the timetables. I'm merely using these as a test case, a proof of
concept. I'm not planning to add all of them. I think it does make sense
for the school, market and student buses that run relatively infrequently.

Jo


Op za 3 nov. 2018 om 23:16 schreef OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com>:

> Considering De Lijn may share their data as GTFS, isn’t it a better effort
> to integrate instead of duplicate existing data?
>
>
> https://www.delijn.be/en/zakelijk-aanbod/reisinfodata/gebruik-onze-data.html
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public Transport Timetables

[Jo]

I'm mostly experimenting to figure out what can work. My initial though was
a relation per route/stop pair, but that means a lot of relations. Then I
was thinking: it would be nice to have an idea about the approximate time
to get to the next stop, which led to what I did now. Taking that idea a
bit further, why stop at only the next stop, if you can describe the whole
itinerary?

I do think we need a plugin to make handling the information easier. I
think it can easily be added to PT_Assistant if we manage to find someone
who can code in JAVA.

What I like about doing it this way, is that it becomes possible to
determine what will be the final stop for the particular bus that passes at
that stop at that time. This is something we didn't have yet.

The other thing that is nice is that we now have a basis to sort the stops
in the route relations on. (atm PT_Assistant has functionality to sort them
along the highways, if they are sorted correctly).

For someone entering the data, it's enough to enter the departures times
for the first stop. If the times between the stops are not known yet, the
roles remain empty at first. Or we could put sequence numbers in there.
About that, I do notice some have the same minute, it would be nice to have
a way to sort the stops based on the times though.

If someone entered the times at a stop somewhere in the middle of the
itinerary a tool can help adapt the times afterwards.

I'm going to try and apply this to this 'route from hell' (47 itinerary
variations!) :
https://b2cservices.delijn.be/rise-api-pdf/pdf/dienstregelingen/entiteit/4/lijnnummer/201/richting/10/lijnnummerpubliek/20a/dienstregeling_20a.pdf?gebundeldeLijnen=false=true=all=false=06-11-2018=1541278207591

That PDF only describes what itineraries it takes on weekdays outside of
school holidays...

Jo

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:

> Polyglot:
> I think that having a timetable relation for each stop is less complicated
> than having one per route.  There are several advantages to this:
> 1) People can easily add a single relation at a time, rather than having
> to do the entire line at one time.  This could make it much easier to, for
> example, have a StreetComplete quest asking "What are the arrival times of
> bus X at this bus stop?"  iD could also have a field at bus stops with
> "arrivals for each parent bus route" that would allow people to seamlessly
> create timetable relations.  It also makes more features possible in the
> future, such as additional tags to each timetable.
> 2) The system is easier for newbies to learn to use.
>
> The disadvantage is that there are now a ton of relations per bus / train
> / subway route.  Creating these could made easier by a new JOSM plugin.
> Also, if someone wanted to delete all timetable relations that are part of
> a route, they could simply use this overpass query to download the data
> into JOSM and then delete all of the timetable relations:
> https://overpass-turbo.eu/s/Dlf
>
> If people really prefer a single timetable relation for each route, then I
> will go with that.
>
> Julien:
> Why not have a "delay"=" this platform>" tag instead of separate arrivals/departures tags?
>
> Thanks,
> Leif Rasmussen
> ___
> 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] Public Transport Timetables Proposal RFC

[Jo]

I have been using commas between the times, maybe semicolon would be better
(not for readability though).

Op za 3 nov. 2018 om 14:01 schreef djakk djakk :

> Maybe we can put that optional piece of information inside the departures
> key : departures=7:40,7:45 ; 8:40,8:45 -> means the train or the bus
> arrives at the stop at 7:40 or 8:40 and leaves 5 minutes later.
>
> Arrival and departure time are separated by a comma, and different
> departures are separated by a semicolon.
>
> If no comma, it means departure time only - except for the last stop :
> means arrival time only.
>
>
> Should we use 0-24-25 hour format ? (when a trip starts at 23:45 and
> finishes 30 minutes later at 0:15, which is sometimes written 24:15 in a
> gtfs. )
>
>
> Julien “djakk”
>
>
> Le sam. 3 nov. 2018 à 12:53, Jo  a écrit :
>
>> For buses it's exceptional they stay at a stop longer than strictly
>> necessary, so I think the arrival times should be optional. If the tag is
>> added, it should have the same amount of entries as the departures though.
>>
>> Sometimes I do see buses that 'linger' at stops, but that's usually
>> because they are ahead of their schedule by more than a few minutes.
>>
>> Jo
>>
>> Op za 3 nov. 2018 om 12:02 schreef djakk djakk :
>>
>>> Jo, I did not try yet, but I think there should be a departure timetable
>>> AND an arrival timetable (trains often stop several minutes). And this, per
>>> stop.
>>>
>>> The mapper sees a timetable at a bus stop, he puts it directly into a
>>> relation associating the bus stop and the route. This enables to partially
>>> map the line.
>>>
>>> The first stop has departure timetable only.
>>> The last stop has arrival timetable only.
>>> An intermediate stop has both.
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le sam. 3 nov. 2018 à 11:38, Jo  a écrit :
>>>
>>>> I took it from the official timetables and generally this line doesn't
>>>> suffer too much from congestion. But yes. If the timetable shows bigger
>>>> variation in delay between stops over the day, then another method would be
>>>> necessary.
>>>>
>>>> Obviously this is what the operator plans to happen. In practice buses
>>>> will run later than their scheduled times. We have access to real time
>>>> information for each stop though. I think I'm going to add the direct urls
>>>> to the stops themselves.
>>>>
>>>> For the lines/routes a direct link to a url of this kind is probably
>>>> more helpful than trying to store all the detail:
>>>> https://www.delijn.be/nl/lijnen/lijn/3/301.
>>>>
>>>> But I'm trying to explore how we could add timetable information for
>>>> regions where this kind of service doesn't exist.
>>>>
>>>> Jo
>>>>
>>>> Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
>>>> matkoni...@tutanota.com>:
>>>>
>>>>> So this assumes that bus travels for the same time between stops both
>>>>> during night and
>>>>> during rush hour?
>>>>>
>>>>> 3. Nov 2018 11:19 by winfi...@gmail.com:
>>>>>
>>>>> When done this way, the departures in the tags are for the stop with
>>>>> role 00:00.
>>>>>
>>>>> Jo
>>>>>
>>>>> Op za 3 nov. 2018 om 11:09 schreef Jo :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm looking into this timetable relation and how it could be
>>>>>> implemented:
>>>>>>
>>>>>> https://www.openstreetmap.org/relation/8885374/history
>>>>>>
>>>>>> This is for a simple line...
>>>>>>
>>>>>> I added all the stops of the route relation and added the most common
>>>>>> times to get from one to the next. I realise things can get even more
>>>>>> complex if these differentials change during the day due to congestion 
>>>>>> that
>>>>>> was planned for in the time tables.
>>>>>>
>>>>>> When done this way, it's not a timetable relation for each stop/route
>>>>>> pair.
>>>>>>
>>>>>> I'll try to do something similar for a more complicated situation.
>>>>>> (telescopic line, i.e. not all trips are the same length)

Re: [Tagging] Public Transport Timetables Proposal RFC

[Jo]

I created a few more for a more 'complicated' line, which changes in length.

Normal northbound:
https://www.openstreetmap.org/relation/8886015

Shortened northbound:
https://www.openstreetmap.org/relation/8886014

I used the same route relation twice, because for telescopic lines I only
mapped the longer variants.

Normal southbound:
https://www.openstreetmap.org/relation/8886013

Shortened southbound:
https://www.openstreetmap.org/relation/8886011

This one refers to another route relation than the previous one, as it does
something different for the last 2 stops, so the bus is ready to start
again on the northbound journey.

Last fare on Saturday evening only goes to the railway station:
https://www.openstreetmap.org/relation/8886012

So 5 extra relations to describe the whole timetable. To make this
manageable (and interpret what it really means in reality) we will need
dedicated tools though.

Now I'll try with a route that changes on Wednesdays, so not all weekdays
are the same, because school ends at noon on Wednesdays over here.

Polyglot

Op za 3 nov. 2018 om 14:01 schreef djakk djakk :

> Maybe we can put that optional piece of information inside the departures
> key : departures=7:40,7:45 ; 8:40,8:45 -> means the train or the bus
> arrives at the stop at 7:40 or 8:40 and leaves 5 minutes later.
>
> Arrival and departure time are separated by a comma, and different
> departures are separated by a semicolon.
>
> If no comma, it means departure time only - except for the last stop :
> means arrival time only.
>
>
> Should we use 0-24-25 hour format ? (when a trip starts at 23:45 and
> finishes 30 minutes later at 0:15, which is sometimes written 24:15 in a
> gtfs. )
>
>
> Julien “djakk”
>
>
> Le sam. 3 nov. 2018 à 12:53, Jo  a écrit :
>
>> For buses it's exceptional they stay at a stop longer than strictly
>> necessary, so I think the arrival times should be optional. If the tag is
>> added, it should have the same amount of entries as the departures though.
>>
>> Sometimes I do see buses that 'linger' at stops, but that's usually
>> because they are ahead of their schedule by more than a few minutes.
>>
>> Jo
>>
>> Op za 3 nov. 2018 om 12:02 schreef djakk djakk :
>>
>>> Jo, I did not try yet, but I think there should be a departure timetable
>>> AND an arrival timetable (trains often stop several minutes). And this, per
>>> stop.
>>>
>>> The mapper sees a timetable at a bus stop, he puts it directly into a
>>> relation associating the bus stop and the route. This enables to partially
>>> map the line.
>>>
>>> The first stop has departure timetable only.
>>> The last stop has arrival timetable only.
>>> An intermediate stop has both.
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le sam. 3 nov. 2018 à 11:38, Jo  a écrit :
>>>
>>>> I took it from the official timetables and generally this line doesn't
>>>> suffer too much from congestion. But yes. If the timetable shows bigger
>>>> variation in delay between stops over the day, then another method would be
>>>> necessary.
>>>>
>>>> Obviously this is what the operator plans to happen. In practice buses
>>>> will run later than their scheduled times. We have access to real time
>>>> information for each stop though. I think I'm going to add the direct urls
>>>> to the stops themselves.
>>>>
>>>> For the lines/routes a direct link to a url of this kind is probably
>>>> more helpful than trying to store all the detail:
>>>> https://www.delijn.be/nl/lijnen/lijn/3/301.
>>>>
>>>> But I'm trying to explore how we could add timetable information for
>>>> regions where this kind of service doesn't exist.
>>>>
>>>> Jo
>>>>
>>>> Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
>>>> matkoni...@tutanota.com>:
>>>>
>>>>> So this assumes that bus travels for the same time between stops both
>>>>> during night and
>>>>> during rush hour?
>>>>>
>>>>> 3. Nov 2018 11:19 by winfi...@gmail.com:
>>>>>
>>>>> When done this way, the departures in the tags are for the stop with
>>>>> role 00:00.
>>>>>
>>>>> Jo
>>>>>
>>>>> Op za 3 nov. 2018 om 11:09 schreef Jo :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm looking into this timetable relation and how it could be
>>>>>&g

Re: [Tagging] Public Transport Timetables Proposal RFC

[Jo]

For buses it's exceptional they stay at a stop longer than strictly
necessary, so I think the arrival times should be optional. If the tag is
added, it should have the same amount of entries as the departures though.

Sometimes I do see buses that 'linger' at stops, but that's usually because
they are ahead of their schedule by more than a few minutes.

Jo

Op za 3 nov. 2018 om 12:02 schreef djakk djakk :

> Jo, I did not try yet, but I think there should be a departure timetable
> AND an arrival timetable (trains often stop several minutes). And this, per
> stop.
>
> The mapper sees a timetable at a bus stop, he puts it directly into a
> relation associating the bus stop and the route. This enables to partially
> map the line.
>
> The first stop has departure timetable only.
> The last stop has arrival timetable only.
> An intermediate stop has both.
>
>
> Julien « djakk »
>
>
> Le sam. 3 nov. 2018 à 11:38, Jo  a écrit :
>
>> I took it from the official timetables and generally this line doesn't
>> suffer too much from congestion. But yes. If the timetable shows bigger
>> variation in delay between stops over the day, then another method would be
>> necessary.
>>
>> Obviously this is what the operator plans to happen. In practice buses
>> will run later than their scheduled times. We have access to real time
>> information for each stop though. I think I'm going to add the direct urls
>> to the stops themselves.
>>
>> For the lines/routes a direct link to a url of this kind is probably more
>> helpful than trying to store all the detail:
>> https://www.delijn.be/nl/lijnen/lijn/3/301.
>>
>> But I'm trying to explore how we could add timetable information for
>> regions where this kind of service doesn't exist.
>>
>> Jo
>>
>> Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
>> matkoni...@tutanota.com>:
>>
>>> So this assumes that bus travels for the same time between stops both
>>> during night and
>>> during rush hour?
>>>
>>> 3. Nov 2018 11:19 by winfi...@gmail.com:
>>>
>>> When done this way, the departures in the tags are for the stop with
>>> role 00:00.
>>>
>>> Jo
>>>
>>> Op za 3 nov. 2018 om 11:09 schreef Jo :
>>>
>>>> Hi,
>>>>
>>>> I'm looking into this timetable relation and how it could be
>>>> implemented:
>>>>
>>>> https://www.openstreetmap.org/relation/8885374/history
>>>>
>>>> This is for a simple line...
>>>>
>>>> I added all the stops of the route relation and added the most common
>>>> times to get from one to the next. I realise things can get even more
>>>> complex if these differentials change during the day due to congestion that
>>>> was planned for in the time tables.
>>>>
>>>> When done this way, it's not a timetable relation for each stop/route
>>>> pair.
>>>>
>>>> I'll try to do something similar for a more complicated situation.
>>>> (telescopic line, i.e. not all trips are the same length)
>>>>
>>>> Polyglot
>>>>
>>>> Op za 3 nov. 2018 om 10:21 schreef Andy Townsend :
>>>>
>>>>>
>>>>> On 03/11/2018 04:55, djakk djakk wrote:
>>>>> > I do not see why timetables are hard to maintain ? Most bus lines do
>>>>> > not change their schedules for years (even in big cities, Paris for
>>>>> > example). Because changing the schedule means buy a new bus and hire
>>>>> > new drivers.
>>>>> >
>>>>>
>>>>> OSM has been described as a "do-ocracy".  Basically, if you think that
>>>>> other people should do something why don't you do it in your area for
>>>>> a
>>>>> period of time (maybe a couple of months) to demonstrate that it is
>>>>> possible and practical?
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> 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] Public Transport Timetables Proposal RFC

[Jo]

I took it from the official timetables and generally this line doesn't
suffer too much from congestion. But yes. If the timetable shows bigger
variation in delay between stops over the day, then another method would be
necessary.

Obviously this is what the operator plans to happen. In practice buses will
run later than their scheduled times. We have access to real time
information for each stop though. I think I'm going to add the direct urls
to the stops themselves.

For the lines/routes a direct link to a url of this kind is probably more
helpful than trying to store all the detail:
https://www.delijn.be/nl/lijnen/lijn/3/301.

But I'm trying to explore how we could add timetable information for
regions where this kind of service doesn't exist.

Jo

Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
matkoni...@tutanota.com>:

> So this assumes that bus travels for the same time between stops both
> during night and
> during rush hour?
>
> 3. Nov 2018 11:19 by winfi...@gmail.com:
>
> When done this way, the departures in the tags are for the stop with role
> 00:00.
>
> Jo
>
> Op za 3 nov. 2018 om 11:09 schreef Jo :
>
>> Hi,
>>
>> I'm looking into this timetable relation and how it could be implemented:
>>
>> https://www.openstreetmap.org/relation/8885374/history
>>
>> This is for a simple line...
>>
>> I added all the stops of the route relation and added the most common
>> times to get from one to the next. I realise things can get even more
>> complex if these differentials change during the day due to congestion that
>> was planned for in the time tables.
>>
>> When done this way, it's not a timetable relation for each stop/route
>> pair.
>>
>> I'll try to do something similar for a more complicated situation.
>> (telescopic line, i.e. not all trips are the same length)
>>
>> Polyglot
>>
>> Op za 3 nov. 2018 om 10:21 schreef Andy Townsend :
>>
>>>
>>> On 03/11/2018 04:55, djakk djakk wrote:
>>> > I do not see why timetables are hard to maintain ? Most bus lines do
>>> > not change their schedules for years (even in big cities, Paris for
>>> > example). Because changing the schedule means buy a new bus and hire
>>> > new drivers.
>>> >
>>>
>>> OSM has been described as a "do-ocracy".  Basically, if you think that
>>> other people should do something why don't you do it in your area for a
>>> period of time (maybe a couple of months) to demonstrate that it is
>>> possible and practical?
>>>
>>> Best Regards,
>>>
>>> Andy
>>>
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
> 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] Public Transport Timetables Proposal RFC

[Jo]

When done this way, the departures in the tags are for the stop with role
00:00.

Jo

Op za 3 nov. 2018 om 11:09 schreef Jo :

> Hi,
>
> I'm looking into this timetable relation and how it could be implemented:
>
> https://www.openstreetmap.org/relation/8885374/history
>
> This is for a simple line...
>
> I added all the stops of the route relation and added the most common
> times to get from one to the next. I realise things can get even more
> complex if these differentials change during the day due to congestion that
> was planned for in the time tables.
>
> When done this way, it's not a timetable relation for each stop/route pair.
>
> I'll try to do something similar for a more complicated situation.
> (telescopic line, i.e. not all trips are the same length)
>
> Polyglot
>
> Op za 3 nov. 2018 om 10:21 schreef Andy Townsend :
>
>>
>> On 03/11/2018 04:55, djakk djakk wrote:
>> > I do not see why timetables are hard to maintain ? Most bus lines do
>> > not change their schedules for years (even in big cities, Paris for
>> > example). Because changing the schedule means buy a new bus and hire
>> > new drivers.
>> >
>>
>> OSM has been described as a "do-ocracy".  Basically, if you think that
>> other people should do something why don't you do it in your area for a
>> period of time (maybe a couple of months) to demonstrate that it is
>> possible and practical?
>>
>> Best Regards,
>>
>> Andy
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging