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

[Joseph Eisenberg]

Sure, network= and operator= are useful, but the are not required.

Minibus services, the most common public transit in Indonesia, have no
operator here; every vehicle is privately owned and operated.

Joseph

On Sun, Aug 4, 2019 at 6:16 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 3. Aug 2019, at 03:19, Joseph Eisenberg 
> wrote:
> >
> > 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.
>
>
> and a network or operator tag? I find this useful to distinguish bus stops
> by different operators (e.g. regional service from urban transport), even
> if you map just the stop and not yet the route.
>
> Ciao 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] Rethinking Map Features

[Yuri Astrakhan]

The biggest issue with using Lua/Server side scripting with large lists is
that every single data item used on a wiki page requires a separate SQL
query (or even multiple ones), due to how mediawiki + wikibase is
implemented.  On the other hand, relying on TagInfo has some shortcomings -
TagInfo does not (yet) understand data items, relying on its own wiki page
parser, it is very fixed in a way it can present information, and every
wiki page view also uses makes 1 or more external call to taginfo (higher
chance of something going down).

There is a popular middle ground that can solve it for us -- very flexible,
highly performant, uses a common data source (data items), and relies on a
single system.  Essentially it is a bot-updated wiki markup:

* an editor adds a special template at the top of a wiki page, where they
specify a SPARQL query for the data they want - i.e. "find all
label+description+image of data items, whose type is a 'tag' and whose key
is 'denomination'".  A bot would run that query on occasion (e.g. once a
day), and append query results to that same page after the template.  Thus,
the result becomes a regular wiki markup, without any significant server
costs.  See https://www.wikidata.org/wiki/Template:Wikidata_list

The PROs:
* The bot can run at any moment, by anyone, to update the data
* In the worst case of a bot completely dying, wiki markup could be edited
by hand until the bot is fixed
* very flexible - a complex query could get any data needed for the output,
and the output is templated to show in any kind of a list/table format.

CONs:
* every list update is essentially a wiki page edit, slowly increasing
history. This is not that big of a deal because size wise the growth is
small and has very little performance impact, plus it makes it possible to
track changes with time.

On Sat, Aug 3, 2019 at 5:25 PM Andrew Hain 
wrote:

> Now the wiki has data items and scripting in Lua I have been wondering
> whether they are a useful alternative to Taginfo-driven lists.
>
> Advantages of server scripts:
>
>1. Descriptions can be generated from data items, tharefore they can
>be in a language where there is no long form documentation for the key.
>This resolves the issues that have limited use of taglists in languages
>other than English because descriptions can be rolled out quickly and some
>can be copied from the old map features templates.
>2. Tables at the top of pages are visible immediately,
>3. A successful connection to tagindo.openstreetmap.org is unnecessary.
>
> Advantages of taglists driven by Taginfo:
>
>1. The technology aleady exists and can be rolled out.
>2. Separate scripts avoid overloading the server (Map Features in
>Polish, Ukrainian and Japanese hits wiki limits).
>3. The web scripts are free-standing and can be hosted on another
>website outside the wiki,
>
> (crossposted from
> https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists
> )
>
> --
> Andrew
> Talk:Taginfo/Taglists - OpenStreetMap Wiki
> 
> Languages. This is a very cool feature! One question: Could the template
> get the langugage automatically? I know this is done on some templates
> (e.g. Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a
> template wizard.
> wiki.openstreetmap.org
>
> --
> *From:* Joseph Eisenberg 
> *Sent:* 02 August 2019 14:22
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] Rethinking Map Features
>
> Andrew,
>
> I now think it is a good idea to switch to taglists for all of the Map
> Feature page templates. It will make it much easier to keep the pages
> consistent and to a reasonable length if all of the descriptions are
> pulled from the wiki pages directly (just as is done for descriptions
> used by Taginfo).
>
> This just means that any deprecated or discouraged tags which are
> currently "strikethrough" on Map Features will need something in the
> description that mentions that they are discouraged. This is a good
> idea anyway, so that the documentation is consistent.
>
> Joseph
>
> On 7/7/19, Andrew Hain  wrote:
> > I have been working on a scheme to improve the cross-language quality of
> Map
> > Features.
> > [
> https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features
> ]
> >
> > Of course the page may deserve a bigger or deeper rethink.
> >
> > --
> > Andrew
> > Talk:Map Features - OpenStreetMap
> > Wiki<
> https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features
> >
> > amenity=school rendering colour. amenity=school is displayed in the page
> as
> > a light-purple area for ways, whereas mapnik renders them as a pale
> yellow
> > colour
> > wiki.openstreetmap.org
> >
> >
>
> ___
> Tagging 

Re: [Tagging] Rethinking Map Features

[Andrew Hain]

Now the wiki has data items and scripting in Lua I have been wondering whether 
they are a useful alternative to Taginfo-driven lists.

Advantages of server scripts:

  1.  Descriptions can be generated from data items, tharefore they can be in a 
language where there is no long form documentation for the key. This resolves 
the issues that have limited use of taglists in languages other than English 
because descriptions can be rolled out quickly and some can be copied from the 
old map features templates.
  2.  Tables at the top of pages are visible immediately,
  3.  A successful connection to tagindo.openstreetmap.org is unnecessary.

Advantages of taglists driven by Taginfo:

  1.  The technology aleady exists and can be rolled out.
  2.  Separate scripts avoid overloading the server (Map Features in Polish, 
Ukrainian and Japanese hits wiki limits).
  3.  The web scripts are free-standing and can be hosted on another website 
outside the wiki,

(crossposted from 
https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists)

--
Andrew
Talk:Taginfo/Taglists - OpenStreetMap 
Wiki
Languages. This is a very cool feature! One question: Could the template get 
the langugage automatically? I know this is done on some templates (e.g. 
Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a template 
wizard.
wiki.openstreetmap.org


From: Joseph Eisenberg 
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Rethinking Map Features

Andrew,

I now think it is a good idea to switch to taglists for all of the Map
Feature page templates. It will make it much easier to keep the pages
consistent and to a reasonable length if all of the descriptions are
pulled from the wiki pages directly (just as is done for descriptions
used by Taginfo).

This just means that any deprecated or discouraged tags which are
currently "strikethrough" on Map Features will need something in the
description that mentions that they are discouraged. This is a good
idea anyway, so that the documentation is consistent.

Joseph

On 7/7/19, Andrew Hain  wrote:
> I have been working on a scheme to improve the cross-language quality of Map
> Features.
> [https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features]
>
> Of course the page may deserve a bigger or deeper rethink.
>
> --
> Andrew
> Talk:Map Features - OpenStreetMap
> Wiki
> amenity=school rendering colour. amenity=school is displayed in the page as
> a light-purple area for ways, whereas mapnik renders them as a pale yellow
> colour
> wiki.openstreetmap.org
>
>

___
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?

[Martin Koppenhoefer]

sent from a phone

> On 3. Aug 2019, at 03:19, Joseph Eisenberg  wrote:
> 
> 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.


and a network or operator tag? I find this useful to distinguish bus stops by 
different operators (e.g. regional service from urban transport), even if you 
map just the stop and not yet the route.

Ciao Martin 
___
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?

[Markus]

Hi!

On Sat, 3 Aug 2019 at 20:38, yo paseopor  wrote:
>
> We need a new way of following the scheme. I think all the features are 
> needed: stop positions, platforms and stop area. [...]

Could you please give me an example where stop positions are needed?
In my experience, mapping stop positions and stop areas is only very
time-consuming (without a benefit), but also makes maintaining the
routes harder. (Of course, stop areas are helpful at stations,
especially at subway stations, in order connect the entrances to the
station.)

> We should deprecate all kind of stuff for public transport who does not not 
> have the public transport tag itself. Because a platform has no sense if is 
> not for public_transport. No more highway=platform, railway=platform, 
> seaway=platform, river=platform.

Apart from the fact that seaway=platform and river=platform don't
exist, 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.

[1]: https://www.mapillary.com/map/im/WzQODhqrCxxBLTYj2YJ-8g
[2]: https://www.mapillary.com/map/im/9HJR2HmtsEPsPVDV682kZQ

Regards

Markus

___
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?

[Markus]

Hi Daniel

On Fri, 2 Aug 2019 at 22:21, Daniel Koć  wrote:
>
> Routing software is reliable only if it connects points on the roads. How 
> would you propose to do it without them?

At best, stops (waiting areas) should be connected to the pedestrian
road network, but they don't need to be connected to the road. Even if
sidewalks are tagged on the highway=* way, it is important to know on
which side of the road the bus stops. The stop positions – which only
buses need to know – can then be calculated by projecting the stop to
the road that is part of the same route relation. As i've written in
the recent discussion on talk-transit, OsmAnd's public transportation
routing works very well in Stockholm, where only stops
(highway=bus_stop) beside the road are mapped.

Regards

Markus

___
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?

[yo paseopor]

We need a new way of following the scheme. I think all the features are
needed: stop positions, platforms and stop area.Well , at first sight would
seem complicated...but if you want to map a big station you have to use a
complicated system. And this system when you know how it works it is fast
and easy to follow. Because all kind of public transport would be mapped in
the same way. If it is bus? bus=yes. If it is also tram? tram=yes

We should deprecate all kind of stuff for public transport who does not not
have the public transport tag itself. Because a platform has no sense if is
not for public_transport. No more highway=platform, railway=platform,
seaway=platform, river=platform. Forget about the environment: it is a
platform for public transport. And that's it.
Also we should deprecate all the highway=bus_stop (because you have
public_transport=stop_position ), al the halts in a railway, etc...And all
these kind of things would be only public_transport=stop_position.

With this system you can catch an airport and make it a
public_transport=stop_position, for the planes. It is a powerful scheme,
and you only have to know one key and four or five values. You will never
ever misspelled the writing of bus stop? bus_stop? stop_for_bus? for what?
highway?railway?aerialway?seaway?riverway?

We should use scalable and easy of tagging schemes, should we?

Salut i transport public (health and public transport)
yopaseopor

On Sat, Aug 3, 2019 at 11:53 AM Jo  wrote:

> 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 <
> joseph.eisenb...@gmail.com> 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 

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?

[Joseph Eisenberg]

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 amenity=cafe node in
 a building to a shop=* area in another building across the city, by
 car. You have to jump from the node to the nearest highway, follow the
 highways to the other side of the city, and then jump back to the
 other node. So any router than can handle automobile directions can
 also manage bus stops or tram stops or platforms at the side of the
 road, without needing anything other than highway or railway ways and
 platform or bus stop nodes.
>>> I guess this is the example where this simple analogy fails:
>>>
>>> https://www.openstreetmap.org/node/334559271
>>>
>>> The route for personal journey might be undefined on the ends (drivers
>>> just use their eyes there), public transport routing is more strict.
>>>
>>>
 I wasn't able to understand enough of the link about updating transit
 features in Warsaw to see how the stop_position nodes were useful. I
 understand that some transit agencies provide data about stop
 positions, and that's the original reason that the stop_position nodes
 were created. There's no problem with keeping them in your city if you
 like them, but probably we shouldn't tell new mappers that they are
 needed, for example in developing cities around the world that
 currently lack any bus stops.
>>> Sorry for asking, but you probably know this documentation quite good -
>>> do we really tell people that every element of a public transport stop
>>> is needed just because it's documented somewhere?
>>>
>>>
 The complexity of the current system, as described on the main pages
 in the wiki, can discourage mapping anything (for example, I've been
 discouraged from trying to add any of the 

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

[Warin]

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 amenity=cafe node in
a building to a shop=* area in another building across the city, by
car. You have to jump from the node to the nearest highway, follow the
highways to the other side of the city, and then jump back to the
other node. So any router than can handle automobile directions can
also manage bus stops or tram stops or platforms at the side of the
road, without needing anything other than highway or railway ways and
platform or bus stop nodes.

I guess this is the example where this simple analogy fails:

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

The route for personal journey might be undefined on the ends (drivers
just use their eyes there), public transport routing is more strict.



I wasn't able to understand enough of the link about updating transit
features in Warsaw to see how the stop_position nodes were useful. I
understand that some transit agencies provide data about stop
positions, and that's the original reason that the stop_position nodes
were created. There's no problem with keeping them in your city if you
like them, but probably we shouldn't tell new mappers that they are
needed, for example in developing cities around the world that
currently lack any bus stops.

Sorry for asking, but you probably know this documentation quite good -
do we really tell people that every element of a public transport stop
is needed just because it's documented somewhere?



The complexity of the current system, as described on the main pages
in the wiki, can discourage mapping anything (for example, I've been
discouraged from trying to add any of the minibus routes in my part of
Indonesia, since it seemed so complicated to make so many features and
routes).

So maybe documentation should be just cleaned? And if I understand you
wrong, could you describe what was your problem there?


--
"Pojechałam truizmem, ale mogę, bo jestem trochę pierdołą" [P. Potocka]





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