Re: [Talk-transit] Tagging a public transport route which uses buses and trams simultaneously

[Jo]

If the itineraries between the stops are all the same, I would probably map
it as

route=tram

and consider the buses replacement service.

Why do they do that? Are there too few tram vehicles? Not enough tram
wattman? Are the trams too big/costly at some hours of the day?

Polyglot

On Mon, Oct 19, 2020 at 5:59 PM Michael Tsang  wrote:

> Dear all,
>
> How should I tag a public transport route which is simultaneously a bus
> and a
> tram route? It is operated using both trams (on street-running railway)
> and
> buses on the same way with the same platforms, using the same number.
>
> Regards,
> Michael
> --
> Sent from KMail___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Talk-transit Digest, Vol 104, Issue 1

[Jo]

Number of seats may work. But it would have to be a ballpark figure. Over
here in Belgium, the same line uses bendy and normal buses depending on the
hour of the day, or on what they have available at that specific time.

On Wed, Oct 14, 2020, 14:09 Tony Shield  wrote:

> Hi Alex
>
> Michael Tsang asked a very similar question  about minibus routes a few
> days ago.
>
> My view is that a minibus as just that - a small bus differentiated by the
> number of seats. From that I take the view that perhaps we should be noting
> the number of seats/places available on a bus service - e.g some double
> deckers have 80 seats, single deckers 15-60, bendy-buses - approx 140.
>
> Using seats metric could also be applied to other transport formats - so a
> Settle-Carlisle class 156 2 car train set has approx 150 seats, a class 800
> 9 car train set has 611 seats; Sydney ferries have capacities between 400
> and 1150.
>
> So service capacity may be a better metric.
>
> Tony Shield
>
> TonyS999
> *I'm looking for community consensus about minibus routes (public
> transport routes which are operated by light passenger vehicles of roughly
> 8 to 20 seats with no standing allowed in general). As of present, there
> are two kinds of tagging for minibus routes:*
>
> * A. route=minibus (~30 routes around the world)*
> * B. route=bus & bus=minibus (~300 routes around the world)*
>
> * None of the tags seem to have widespread usage.*
>
> * Currently I can't see any renderer support for both tagging. For option
> A, no renderer shows them at all. For option B, they are shown as regular
> bus routes.*
>
> * Moreover, I can think of different regulatory scenarios, which may match
> the different usage:*
>
> * X. The minibus services are regulated as a separate class of service to
> full-sized bus routes, with different operators, network and fare
> structures, which may even with numbers overlapping (e.g. a minibus route
> 25 and another full sized bus route 25 serving the same area)*
>
> * Y. The minibus services form a part of the bus network but with distinct
> identities (e.g. a range of numbers reserved for minibus routes and another
> range for full sized bus routes, with different fare scales but still in
> the integrated ticket structure)*
>
> * Z. There are no distinction in the branding between bus and minibus
> services, the vehicle used mainly depend on the environment.*
>
> * Tagging A will match scenario X and tagging B will match scenario Z,
> with scenario Y in between in my thinking.*
>
> * I'm looking for input how other people map their minibus routes, and how
> are their routes regulated.*
>
>
> On 13/10/2020 12:27, Alex Dhawan wrote:
>
> Hi all,
>
>
>
> Never actually sent a message to this list, hopefully this works.
>
>
>
> We’ve got a number of minibus routes around the Yorkshire Dales here in
> Northern England. Currently the ones that appear in OSM are just tagged as
> route=bus – with nothing distinguishing them from full size standard buses.
>
>
>
> Personally of your options I’d be tempted to go with B – at least here
> they are treated as bus routes in most ways, just happen to be minibuses.
> They do mostly have different branding, but in most cases are intregrated
> fare and ticket wise, and in some cases to overlap with standard bus
> routes, but do have different numbers, although there is not a set “range”
> so unless you know in advance you couldn’t tell from just the number. At
> least from my local experience they are close enough to standard bus routes
> for most purposes.
>
>
>
> That said to give one example – precovid I used to take groups walking or
> caving, and we often went on the buses and usually made a specific point of
> avoiding the minibus routes. We’d take out all the seats if we turned up.
> In the PDF timetables it will be marked if a route is a minibus, but not on
> journey planners/Google maps.
>
>
>
> Skifans
>
>
>
>
>
>
>
> *From: *talk-transit-requ...@openstreetmap.org
> *Sent: *13 October 2020 12:09
> *To: *talk-transit@openstreetmap.org
> *Subject: *Talk-transit Digest, Vol 104, Issue 1
>
>
>
> S
>
>
>
> ___
> Talk-transit mailing 
> listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?

[Jo]

Hi Daniel,

If you would like to participate in a Hangout, I can explain to you how
PT_Assistant can help you with this task.

We can even do that in Spanish, si te gusta.

Personally, I would also only map highway=bus_stop (with or without
public_transport=platform) on nodes next to the highway, so no real need
for stop_area relations.

Polyglot

On Sat, Jul 18, 2020 at 7:36 PM Mateusz Konieczny via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
>
> Jul 18, 2020, 19:17 by dcapil...@gmail.com:
>
> Hi!
>
> I'll try to check the bus routes in Malagá. [1] I haven't checked them for
> a long time because I have been busy with other mapping tasks and because
> there were many changes in the central area of Málaga. The bus routes
> changed too often. Now it seems to be stabilizing, there are less and less
> changes, and I thought it would be a good time to check the mapping. I'd
> like to ask you something first.
>
> When we started mapping the bus routes in Málaga, Alan Grant and I came to
> the conclusion that it was not necessary to add "stop_area" relations due
> to the type of bus stops in Málaga, [2] where there are no actual stop
> areas (only a stop position in the own road and a pole on the sidewalk
> usually).
>
> Is that solution correct? Should we add "stop_area" relations at every bus
> stop position? I would have to create a lot of additional relations, only
> with the stop position and the platform features. I am not sure if that
> would be reasonable/useful for any purpose. What do you think?
>
> highway=bus_stop node is typically sole useful and needed part of mapping
> bus stop
>
> (additional tags on this node, starting from name are obviously useful)
>
> stop_position, stop_areas and so on are generally not useful, except
> extremely rare cases
>
> I would rather map bus routes than and do other OSM mapping over pointless
> duplicating
> of information available thanks to highway=bus_stop
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] bus=yes opinion

[Jo]

Let's go back to 2012. An attempt was made to solve a 'problem' and the
'new' model for mapping public transport was proposed.

Some people were mapping stops on the rail/highway, others were mapping
them next to the highway.

For rail, and especially if you have only a single OSM way to represent
multiple tracks, it made sense to map them as a node on the OSM way.

For bus stops however one wants to know on which side of the road the
passengers have to wait, so there it makes most sense to map them as a node
alongside the highway.

The bright mind that created the new model was apparently more used to
mapping railway.

So a stop alongside the way supposedly didn't need a mode of transport.

When I tried to adopt this new way of mapping stops, I thought, like many
others that eventually public_transport=platform would replace
highway=bus_stop. For it to be able to do that, information was missing
though. So I asked on the mailing lists and the answer was to add the mode
of transport to public_transport=platform as well.

Over the course of 8 years the people responsible for rendering were
dragging their feet, first it was technical issues, bus/tram/... was not in
their postgresql tables, later it was simply unwillingness.

Anyway, about a year ago, or maybe already 2 by now it became clear that
public_transport=... will never replace highway=bus_stop,
railway=tram_stop, etc.

So, my conclusion is that the whole public_transport scheme has become
moot. It even causes problems, because people are adding identical details
like name, ref, route_ref, operator, network to both the platform and the
stop_position and are adding both of them to the route relations, which
makes maintenance harder.

If it were me,  I would just map the stop nodes next to the highway with
highway=bus_stop and be done with it. If it serves as a tram stop as well,
I would add railway=tram_stop to that node next to the highway.

I've never mapped public_transport=stop_position very much. Except at the
beginning and the end of the itinerary, as I want to split the way there
anyway.

Polyglot

On Sat, Jul 11, 2020 at 7:34 AM Agustin Rissoli 
wrote:

> What are your opinion of adding bus=yes along with
> public_transport=platform + highway=bus_stop?
> I can't find info on the wiki that supports this practice, I know it was
> introduced by iD, but I don't see where this has been discussed.
> My question arises because there is only one user who is adding bus=yes
> (and train=yes on railway platforms, etc.), to all stops in Argentina,
> probably correcting the errors that iD marks.
>
>
> Saludos, Agustín.
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Making bus lines more specific

[Jo]

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. (OK,
it's not a highway and my preference is to map it next to the highway)


public_transport=platform

was designed at first to not need a mode of transport like
bus=yes/tram=yes. I am the one who proposed adding it, so that it COULD
start replacing highway=bus_stop back in 2012.

There is not always a platform present, so it's a bit of a misnomer as well.

Anyway, someone who wants to render a bus stop ideally wants to look at a
single tag, not a combination of 2, apparently. For a long time it was
supposedly a technical problem, but as soon as that was resolved somewhere
around 2017, it was still considered problematic to look at 2 tags.

I wish you good luck with proposing another way of mapping public
transport. Many have tried before you. It's really hard to beat status quo.
And the status quo is not the same across the planet. If you can propose
something that is both simpler, more elegant and still expressive enough
for all usecases, I'll vote yes on it.

Polyglot

On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke  wrote:

> Indeed, these are good points. I would say, that the „platform“ is enough.
> This could then mean either the „stop pole“ of the station (which I would
> not say is the most important piece as that could also just be a sticker on
> a shelter or a lamp post) close but not at the station (sadly there are big
> inconsequent uses in real life), or the area of the visible platform, if
> applicable.
>
> But the rest of the community will have to accept the death of (old) tags,
> when it is voted for. If this mailing list could come up with a proposal
> most users here could live with, we all vote for it (with the spelling of
> the end to certain tags) and it is accepted that way, the community will
> have to accept that. The first iteration was just to „nice“ to that
> conservative fraction. Public transport can be complex, but this is why it
> needs dedicated (own, simple) tags instead of legacy nonsense.
>
> This is, why I would be happy to have many people work on this „ideal“
> solution, that is simple on the one hand, but powerful on the other hand. I
> will make a Document where I put in my personal critique and goal for a new
> scheme, and am then looking forward to input on it. Will share it here when
> I have a framework of what the current scheme says and have some changes in
> it. Then, the specifying of the bus lines, the simplifying of the bus
> stations (so that one or two tags can replace bus_stop but still do the
> same thing functionally) and other points could be put in there.
> Maybe we actually end up with a useful consensus, that one could propose.
>
> The more people get on board, the more acceptable it can become...
>
> KR
> RobinD
>
> Am 28.04.2020 um 10:07 schrieb Jo :
>
> For years and years we have tried to convince the people working on carto,
> our default rendering to start supporting public_transport=platform/bus=yes
> instead of highway=bus_stop.
>
> They have clearly stated that this will never happen. Conclusion:
> highway=bus_stop is NOT a legacy tag.
>
> That's my conclusion anyway. In Belgium I'm even considering to drop
> public_transport=platform on the bus stop nodes, but that's not
> straightforward either anymore,, since the editor software started to
> depend on them.
>
> stop_position nodes, I have never considered them to be important, so I
> never mapped them for ALL the stops. I do map them for initial and terminus
> stops, was I want to split the way there anyway. What I will definitely not
> do, the way I see it done in Germany is to duplicate information.
>
> I want to have a single object, preferably a node, that has all the
> details of the stop AND I want to include this object in the route
> relations. 1 object per stop, so not a sequence of
> stop_position/platform/stop_position/platform.
>
> As I don't consider the stop_position nodes to be important enough to map
> them everywhere I don't put name/ref/ etc on them. In Belgium most
> stop_position nodes will have only 1 extra tag, the mode of transport.
>
> For me it's an advantage that highway=bus_stop can only be used on a node.
> I want to map the object that represents the bus stop as a node anyway,
> next to the highway on the side where the passengers wait.
>
> If there is a physical platform, then it makes sense to map it as a way or
> a closed_way/area. In that case it gets highway=platform and possibly
> tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
> repetition of name,ref,route_ref,operator,network, etc.
>
> If there is to be a next version of how we map public transport we should
> think a

Re: [Talk-transit] Making bus lines more specific

[Jo]

For years and years we have tried to convince the people working on carto,
our default rendering to start supporting public_transport=platform/bus=yes
instead of highway=bus_stop.

They have clearly stated that this will never happen. Conclusion:
highway=bus_stop is NOT a legacy tag.

That's my conclusion anyway. In Belgium I'm even considering to drop
public_transport=platform on the bus stop nodes, but that's not
straightforward either anymore,, since the editor software started to
depend on them.

stop_position nodes, I have never considered them to be important, so I
never mapped them for ALL the stops. I do map them for initial and terminus
stops, was I want to split the way there anyway. What I will definitely not
do, the way I see it done in Germany is to duplicate information.

I want to have a single object, preferably a node, that has all the details
of the stop AND I want to include this object in the route relations. 1
object per stop, so not a sequence of
stop_position/platform/stop_position/platform.

As I don't consider the stop_position nodes to be important enough to map
them everywhere I don't put name/ref/ etc on them. In Belgium most
stop_position nodes will have only 1 extra tag, the mode of transport.

For me it's an advantage that highway=bus_stop can only be used on a node.
I want to map the object that represents the bus stop as a node anyway,
next to the highway on the side where the passengers wait.

If there is a physical platform, then it makes sense to map it as a way or
a closed_way/area. In that case it gets highway=platform and possibly
tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
repetition of name,ref,route_ref,operator,network, etc.

If there is to be a next version of how we map public transport we should
think about making it simpler. What I see in Germany is way too complicated
and error prone, as information is duplicated across objects.

Polyglot




On Tue, Apr 28, 2020 at 9:45 AM Robin Däneke  wrote:

> Hello everybody,
>
> I have lately been thinking about somehow reworking (or giving a new push
> to) the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted,
> not a lot has changed in which tags are rendered, how certain things are
> hence mapped and the Wiki-Pages on the topic have also changed in the last
> years without any visible going through another proposal process.
>
> When I started mapping in 2011, and first read the german and then the
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
> platform nodes. The point of the public_transport tags is, among other
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the
> innicial ideas of the v2, maybe refine a few small details (like is
> stop_position required, or just platforms, can relations of route-parts be
> used in route relations to save on redundancy…) and then put it forward for
> voting. If accepted, we would possibly now have more leverage to get the
> editor and render-programers to actually properly implement it this time
> around.
>
> Maybe I could find some time to write my suggestions into a document, and
> we could collect the ideas for those extra tags in there too. I think it
> would make more sense that way, than just the addition of a few tags to the
> current scheme, to then be ignored by the rest of OSM once again.
>
> Kind Regards
> Robin D. (emergency99)
>
>
> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
> ways, even relations, highway=bus_stop can only be a node. This old tag
> should go the same way as the farm tag, which was (forcefully) abandoned a
> couple of years back. There it worked, why not for the „new“ p_t scheme?
>
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
> gbragaal...@gmail.com>:
> >
> > I read your responses and I tend to agree that the opening_hours tag is
> enough to characterize services that are only operated during peak hours.
> >
> > On the other hand, it seems to me that there is also agreement on the
> relevance of having tags to differentiate bus services.
> >
> > How can we expand this debate and expand this discussion? It may be
> interesting for other members of the list to speak out, and then we can
> create or redeem a proposal for implementing new tags.
> >
> > P.S .: I don't know if this message will enter the reply queue
> correctly; I hope I'm not opening a new topic. I apologize for my
> inexperience with maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-transit
>
>
> 

Re: [Talk-transit] Real time information

[Jo]

For the stops that I have in mind, the url with the real time information
is the only site I will want to link to, so the tag 'url' would do just
fine. If there is an additional website for that particular stop, we could
use 'website'. The advantage is that all tools already work with this tag.

Polyglot

On Thu, Nov 28, 2019 at 1:07 PM A A  wrote:

> 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? Many operators have real time information about arrival time in
> its website.
>
> 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.
>
> I think "departures_board" or "passenger_information_display" tags are
> more convenient than "website" or "url" tags because these may be used with
> other url (for example an url with general information about the station)
> and  "departures_board" or "passenger_information_display" are more
> specific tags.
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] Mapping bus lines in Zambia using JOSM's PT_Assistant plugin

[Jo]

Hi,

Tonight at 21:00 CEST I'll do a hangout where we'll map or correct some bus
lines in Zambia. Let me know if you are interested, then I'll invite you 5
minutes before it starts.

Jo (Polyglot)
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Public transport validator+generator from Maps.Me

[Jo]

Here in Flanders, Belgium we have some market (single day/week) and school
(only 1 or 2 trips/day) buses and also some lines with a circular pattern
that only have a single route relation in the route_master relation. It's
unusual, but it's not wrong. Let me know if you need examples.

Jo

On Tue, Jun 11, 2019 at 6:14 PM Alexey Zakharenkov via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> Hi, Noémie, Mateusz and others!
>
> I’ve extracted all the generated error messages from our subway validator
> source and list them below with some comments. You’ll see that most of them
> concern topology of a transport network which requires much programming and
> cannot be expressed in terms of MapCSS rules.
> Please express your opinion if you consider some checks to be arguable.
>
> *) "Stop area has multiple stations".
> This error prevents from ambiguous binding of
> stop_position/platform/subway_entrances to a station, as well as from
> accidental duplicating of stations.
>
> *) "Tracks in a stop_area relation"
>
> *) "Only exits for a station, no entrances"
>
> *) "No exits for a station"
>
> *) "Stop position is not a node"
>
> *) "Not a stop or platform in a route relation"
>
> *) "Multiple stops for a station in a route relation"
>
> *) "Cannot find nodes in a railway".
> Detects broken OSM ways with 0 or 1 node.
>
> *) "Stop is nowhere near the track"
>
> *) "Public transport version is 1".
> We encourage to convert relations with public_transport:version=1 to newer
> scheme.
>
> *) "Ambiguous station in route. Please use stop_position or split
> interchange stations".
> This happens if a station object (i.e. a railway=station, not a
> stop_position) is in a route relation, and this station is included into
> several stop_areas; or when there are multiple stations of the same
> transport mode in a stop_area.
>
> *) "Found an out-of-place stop/platform".
> The correct (from the validator's point of view) variants of
> stops/platforms order in a route relation are:
>  - "st_1  st_2  st_3  st_4" (only stops)
>  - "pl_1  pl_2  pl_3  pl_4" (only platforms)
>  - "st_1 pl_1  st_2 pl_2  st_3 pl_3  st_4 pl_4" (stops and platforms
> grouped by station)
>  - "st_1 pl_1  pl_2 st_2   st_3  pl_4" (somewhere only a stop, somewhere
> only a platform, somewhere both)
>  - "st_1 st_2 st_3 st_4  pl_1 pl_2 pl_3 pl_4" (all stops first, then all
> platforms)
>  Incorrect order:
>  - "st_1  st_2 pl_2  st_3  pl_1  st_4" (pl_1 or st_1 or both are out of
> place)
>
> *) "Untagged object in a route".
> Occurs quite often, for example when all tags from a stop_position were
> transferred to another node but old node is kept in a route relation.
>
> *) "An under construction stop/platform in route".
> Though it's unclear to me whether under-construction features should be
> added to routes.
>
> *) "Missing station= on a feature".
> Requires that railway=station/halt object be tagged with
> 'station=subway/light_rail/monorail' or have '=yes’. ’train’ mode is
> silently assumed for railways.
>
> *) " is not connected to a station in route".
> Occurs when a stop_position/platform is not included in a stop_area or the
> stop_area is missing a station object.
>
> *) "Route has no stops"
>
> *) "Route has only one stop"
>
> *) "Angle between stops around  is too narrow,  degrees".
> A sharp twist of a route most probably indicates incorrect stops order.
>
> *) "Route has different network from master"
>
> *) "Incompatible PT mode: route_master has  and route has "
>
> *) "Route in two route_masters"
>
> *) "Stop area belongs to multiple interchanges"
>
> *) "An empty route master. Please set construction:route if it is under
> construction"
>
> *) "Only one route in route_master. Please check if it needs a return
> route".
> Non-circular route must have a reversed one. For circular route this is a
> warning.
>
> *) The validator also compares the number of found stations/routes in a
> network with predefined values from CSV. This kind of checksumming helps to
> detect station/route disappearing or opening new ones.
>
> **) Warnings are generated about missing/wrong station/line colour,
> different colour/ref of route and route_master, holes in rails,  "Subway
> entrance is not a node", "Stop position in a 'platform' role in a route",
> "Platform in a 'stop' role in a route", "St

Re: [Talk-transit] Adding highway=bus_stop to nodes with public transport=platform bus=yes

[Jo]

I think it's standard practice to add highway=bus_stop to nodes for bus
stops, as they won't render otherwise anyway.

I don't see parrticular need to ask for permission to add it, but if you
do, you have my vote to add it. I'm starting to have a tendency to move
away from public_transport=platform/bus=yes, but that's another story, of
course.

Polyglot

On Tue, May 28, 2019 at 1:24 PM Mateusz Konieczny 
wrote:

> In Poland there are some bus stops mapped solely as public
> transport=platform bus=yes
> nodes, without highway=bus_stop.
>
> One of local mappers noticed this problem and asked for fixing the
> problem, what resulted in
> automatic edit proposal being accepted by a local community as it is
> considered preferable
> for bus stops to include standard highway=bus_stop, at least in Poland.
>
> In this bot edit:
>
> * Editing is limited to Poland
> * Editing is limited to nodes with public_transport=platform bus=yes
> * Nodes with nearby (within 250 meters) highway=bus_stop are ignored[1]
> * Elements with highway tag are skipped
> * To remaining highway=bus_stop is added
>
> [1] To handle cases like
> https://www.openstreetmap.org/node/4004954618#map=19/50.04537/19.85997
> https://www.openstreetmap.org/node/1726904219#map=19/50.04537/19.85997
> In this case adding highway=bus_stop would not improve data quality
>
> Documentation page with more detail, including source code is at
>
> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/add_highway%3Dbus_stop_tag_where_only_public_transport%3Dplatform_bus%3Dyes_is_present_in_Poland
>
> I just noticed during writing a post to this thread about this bot edit
> that
>
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct#Document_and_discuss_your_plans
> has
> "and if your edit affects a specialist subject, such as oil rigs or public
> transport
> which has its own list then you should also discuss your plans on that
> mailing list."
>
> Unfortunately, bot edit was already started and made some modifications.
>
> I am sorry for not doing it before, I stopped script after noticing it and
> submitted this thread.
>
> PS What is the name of mailing list about oil rigs? I am unable to find it
> on
> https://lists.openstreetmap.org/listinfo
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Jo]

Nodes can change, the tags can change, the position can change.

They are easy to work with, both for the mappers, the users and the
software.

Going from a node to a (closed)way and then having to update all the route
relations, that is cumbersome.

Having to maintain the same data across multiple objects, that is
cumbersome.

The node 'represents' the stop, both on the map and in the itineraries, its
coordinates are the stop's general whereabouts. It could be the exact
location of the pole, but if there are 2 operators that serve the stop and
each has a pole, it would still be a single node (Unless that other pole is
1,5 bus length away in a bus station situation and they have different
platform numbers or letters).

Polyglot

On Tue, May 14, 2019 at 3:50 PM DC Viennablog 
wrote:

> @Polyglot:
> I do think you are thinking to much of software that uses the date rather
> than of the mappers and the database. For both of those, it is better to
> habe less objects to contend with (mapper) and less objects with
> potentially redundant values/positions (database). The fact that maybe a
> router or the api has to calculate a possible middle of a platform polygon
> should, in that context, be the least of our worries.
>
> And the thing with a stop being a node for it‘s lifetime, that does then
> not truly stand with it being a real thing. Because real things tend to
> change over time...
>
> And if it doesn‘t and is just a pole in the field, than it would stay a
> „platform“-node for it‘s lifetime. Objective achieved.
>
> KR
> RobinD (emergency99)
> --
> *Von:* Jo 
> *Gesendet:* Dienstag, 14. Mai 2019 14:37:39
> *An:* Public transport/transit/shared taxi related topics
> *Betreff:* Re: [Talk-transit] Ideas for a simplified public
> transportation scheme
>
> For maintenance and for the stability of the data it is, however, better
> to keep the object that represents the stop, the same during its lifetime,
> instead of migrating it from node to way objects.
>
> We are perfectly well capable of having a node to represent the stop with
> highway=bus_stop and another object to represent the platform with
> highway=platform or railway=platform or both.
>
> For working with the data, it's enough to have the highway=bus_stop/
> railway=tram_stop in the route relations and given that they are nodes,
> their geometry doesn't need to be calculated over and over.
>
> The thread is about simplifying the scheme. That is about as simple as it
> can get.
>
> Polyglot
>
> On Tue, May 14, 2019 at 1:29 PM Markus  wrote:
>
> On Tue, 14 May 2019 at 12:31, Dave F via Talk-transit
>  wrote:
> >
> > 1) highway=bus_stop is a physical object. In OSM we map physical
> > objects. To clarify - What do you mean by 'logical'?
>
> While stops (and stations, too) can be observed (PT vehicles stop
> there), they aren't physical objects. Physical objects are platforms,
> poles, shelters or road markings. They can usually be found at a stop
> or station, but don't have to.
>
> > 2) Why to they need to be "mapped on the same area"? They are separate
> > entities. Objects close to each other can be easily found as OSM is
> > geospatially aware.
>
> They don't need to be mapped on the same area, but it were easier
> (just one object). And if there is a real platform, it is the waiting
> area of the stop.
>
> Regards
>
> Markus
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Jo]

For maintenance and for the stability of the data it is, however, better to
keep the object that represents the stop, the same during its lifetime,
instead of migrating it from node to way objects.

We are perfectly well capable of having a node to represent the stop with
highway=bus_stop and another object to represent the platform with
highway=platform or railway=platform or both.

For working with the data, it's enough to have the highway=bus_stop/
railway=tram_stop in the route relations and given that they are nodes,
their geometry doesn't need to be calculated over and over.

The thread is about simplifying the scheme. That is about as simple as it
can get.

Polyglot

On Tue, May 14, 2019 at 1:29 PM Markus  wrote:

> On Tue, 14 May 2019 at 12:31, Dave F via Talk-transit
>  wrote:
> >
> > 1) highway=bus_stop is a physical object. In OSM we map physical
> > objects. To clarify - What do you mean by 'logical'?
>
> While stops (and stations, too) can be observed (PT vehicles stop
> there), they aren't physical objects. Physical objects are platforms,
> poles, shelters or road markings. They can usually be found at a stop
> or station, but don't have to.
>
> > 2) Why to they need to be "mapped on the same area"? They are separate
> > entities. Objects close to each other can be easily found as OSM is
> > geospatially aware.
>
> They don't need to be mapped on the same area, but it were easier
> (just one object). And if there is a real platform, it is the waiting
> area of the stop.
>
> Regards
>
> Markus
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Jo]

Indeed, that's were we don't seem to be able to agree.

Let's say all bus stops are mapped on nodes to get started.

Then a mapper notices there is a platform near to some of them. Those
platforms can simply be drawn, in addition, to the nodes that represent
such stops. No need to transfer from a node to a way and update all the
route relations where that stop is used.

If I'm not mistaken, in the Netherlands, all house numbers are mapped on
nodes, which are contained within building outlines. I don't really like
that a spatial query is needed to connect buildings to addresses, but as
far as 'tranquility' in the data goes, it's a nice solution.

Back to PT. What most data consumers need is to know where can I
board/alight from the vehicles. A set of coordinates near to where the bus
passes + an indication on which side of the street the doors will open.

For drawing maps we need that + an overview of the itineraries, i.e. the
ways the bus passes on.

For routing we basically only need the stops in the right order +
timetables that come from elsewhere. But it's nice to have the coordinates
of the stops directly available.

Polyglot

Polyglot



On Mon, May 13, 2019 at 8:36 AM Tijmen Stam  wrote:

> On 13-05-19 00:14, Jo wrote:
> > I like to keep things simple, the best way to accomplish that, is by
> > having a single object for each stop that holds all the details for its
> > "lifetime". That's why I don't like the idea of 'upgrading from a node
> > to a way/area or a relation.
>
> I don't agree with you on that point. With that view we can't change
> things in OSM anymore to a more precise mapping.
>
> IMHO it shouldn't be the internal OSM database ID that makes something a
> "logical object", but the ref on that object.
> Say you're transitioning from a node to a way for a bus stop, simply
> copy the relevant tags from that node to the way.
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Jo]

I like to keep things simple, the best way to accomplish that, is by having
a single object for each stop that holds all the details for its
"lifetime". That's why I don't like the idea of 'upgrading from a node to a
way/area or a relation.

So a node next to the highway per stop.

I started adding public_transport=platform/bus=yes to these nodes, but to
be honest, I am not sure why. anymore What matters to get them rendered is
to add highway=bus_stop to them. And that's not going to change anytime
soon.

Think of these nodes as logical objects that represent the stops. The nice
thing about them is that they have coordinates directly, no need to
recalculate center points over and over and over and over again.

Of course, if there are physical platforms, it's easy to map them as
separate objects, tagged with highway=platform or railway=platform on a way
or an area. No need to repeat all the details on them though.

About the stop_area relations, they're not needed everywhere, but they
could be used to show what belongs together. Of course, that would mean all
the objects related to the stop at one side of the street, not both sides.

public_transport=stop_position, I only use them at the beginning and the
end of the itineraries. We could also simply split the way on a node that
doesn't have tags.

Polyglot





On Sun, May 12, 2019 at 8:55 PM Tijmen Stam  wrote:

> On 07-05-19 15:29, Dave F via Talk-transit wrote:
> > On 06/05/2019 19:53, Stephen Sprunk wrote:
> >> On 2019-05-03 12:09, Dave F via Talk-transit wrote:
> >>>
> >>> This reinforces my point about misappropriation of tags. A platform is
> >>> a physical construction higher than the surrounding ground to allow
> >>> easier boarding.
> >>
> >> It's a logical platform whether it physically exists or not.
> >
> >  A 'logical platform'?
> >
> >  From OSM's main welcome page:
> > https://www.openstreetmap.org/welcome
> > "OpenStreetMap is a place for mapping things that are both /real and
> > current/"
> >
> > "What it /doesn't/ include is... hypothetical features,"
>
> a "public_transport=platform" is not defined as being "platform" (raised
> good concrete flooring) but as "the place where people wait to board a
> bus/tram/train". Whatever form that is.
>
> It is not uncommon for key/values to be misnomers in OSM. Clearest
> example is private-access ways being tagged as highway=* (plus
> access=no) which is a misnomer in British English (which we use), as
> highways are public-access roads by legal definition. (see
> https://en.wikipedia.org/wiki/Highway#Terminology)
>
> >>   It's pretty well established that using a platform node for a mere
> >> pole is valid.
> >
> > But you're mapping them as areas.
> > As bus stop tags are by far the more established, why not use that to
> > map a."mere pole".
>
> This is circular reasoning. We can't use the new thing because the old
> thing is much more usual.
> Besides, the new thing (public_transport=platform in PTv2) has been
> voted on in 2011, with overwhelming majority (83 to 6)
>
> >  From the bus stop wiki page:
> > "A bus stop is a place where passengers can board or alight from a bus."
> > Which is what you're claiming platform areas are. As I said it's pure
> > duplication.
>
> No, changing of tagging, not replication.
> There is no need to map with highway=bus_stop anymore (save for
> rendering on osm_carto)
>
> >>   People wait there to be picked up, regardless of the actual surface
> >> type (which can change over time anyway).
> >
> > Unsure why you believe surface is relevant, but as I said, your examples
> > of platforms are imaginary, inaccurate & arbitrary.
>
> He says the surface is irrelevant (regardless).
> I find it a losing argument by saying Stephen's examples are "imaginary,
> inaccurate and arbritary"?, even when he hardly gives an example in the
> post you quote.
>
> >>> A platform:
> >>> https://s0.geograph.org.uk/geophotos/04/76/30/4763016_2416f5ee.jpg
> >>>
> >>> Not a platform:
> >>>
> https://i.pinimg.com/originals/38/90/a0/3890a0f451e1a6900d174b29125b3c80.jpg
>
> That is a "place where people wait to board" (or in this instance, where
> people just alighted)
>
> >>> If (& I believe it's a big if), a separate tag is required to as you &
> >>> Markus suggest, one with a unique, non-confusing value should be used.
> >>>
> >>> Many public_transport=platform are tagged on the same node as
> >>> highway=bus_stop. They have no raised construction Therefore they're
> >>> redundant - routing can use the bus stop tag for the "stop node beside
> >>> the
> >>> road" as Markus described it.:
> >>> https://www.openstreetmap.org/node/469760546#map=19/51.51026/-0.18630
>
> The reason double tagging exists, is that public_transport=platform
> isn't rendered yet.
>
> >> I'd be fine with saying that highway=bus_stop implies
> >> public_transport=platform, except that some mappers put bus stops on
> >> the way instead of beside the way and argue with anyone who tries to
> >> fix them, so in those 

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Jo]

The thing is, as the area around Stockholm clearly shows, highway=bus_stop
is indeed sufficient. If I were to remove all the
public_transport=platform/bus=yes tags from the stops in Belgium, it's very
likely that nobody would notice. If I were to remove highway=bus_stop, all
of  sudden it would seem that Belgium doesn't have bus stops anymore.

"Killing off" highway=bus_stop is what I have been trying to do (somewhat
passively, or at least not very actively) for the past few years. Since
about a year I came to the conclusion that forsaking public_transport tags
would be more straightforward if we really want a simplification.

And double tagging everyting to please everyone is quite likely the easiest
thing to keep doing, even though it's awkward every time when you have to
explain a highway=bus_stop isn't actually a highway and a
public_transport=platform isn't actually a platform in 90% of the bus stops
involved.

This is probably what is going to happen, because the people who would like
to abolish the public_transport tags will never agree with the people who
want to abolish the highway=bus_stop tags.

Polyglot, le défaitiste

On Thu, May 9, 2019 at 9:46 PM DC Viennablog 
wrote:

> Yes, one object would be nice, however, I think it should be versatile
> enough to be able to be a node, line or polygon.
> So basically what public_transport=platform is.
> I also don't mind it being called "platform", even if there is only a pole
> stuck in a field.
> That would not make p_t:v2 mapping futile, but enable a simpler scheme.
> Also, we would not have the problem of having "bus_stop", "tram_stop",
> "train_stop" being different things.
>
> The highway=bus_stop tag is a thing that locks the mode of transport in to
> much. That should be killed of, especially because a bus waiting area is
> pushing the "highway" tag a little bit (as are things like
> "highway=footway", but I don't want to fully open that box here now!).
>
> Those tags like hw=bus_stop or railway=station were thought up at a time,
> when those things (in OSM) were not seen as a group (public_transport) but
> as they are in reality pretty similar in use and form of amenity, I think
> it is suitable to go the way of unifying it as much as possible under the
> p_t-umbrella.
>
> Also, any tag that is duplicating p_t tags in the "railway"-key-area
> should possibly be looked at, but I think we would first need to simplify
> the p_t in order for any other keys to be fitted to that.
>
> So how would people like the suggestion:
>
>
>- Keeping only public_transport=platform as a needed object, without
>hw=bus_stop
>   - (as it should also be used for trams, trains and any other mean
>   of public_transport – thinking things like the "Emirates Air Line" in
>   London).
>- In a route relation, also only have that platform (with role "stop")
>and the streets/rails.
>   - You would still need to make sure the first/last street of the
>   relation ends on a node near the platform point/area!
>- Additional, purely convenient tags to say which mode of transport
>stops there (bus=yes, tram=yes...)
>
> That would only be a slight tweak, that would still make the mapping more
> straight forward, but also make it more dynamic in the usage-possibilities.
>
> Also, I think stop_area-relations should be rethought as grouping many
> stations that could be interchanged between together. Take the Hauptbahnhof
> in Vienna for example. The "Fernbusbahnhof", the regional bus terminal, the
> station "Hauptbahnhof" of 13A/69A, the station "Hauptbahnhof Süd" of the
> 69A and possibly even "Gertrude-Fröhlich-Sandner-Straße" are all just
> situated at or near exits of the train station. So they are all part of
> that "station-area". So I think, the stop-area should be kept, but as a
> more useful relation to sum up stop/station complexes. That is a much
> greater use for a relation than just telling within the database that one
> thing belongs to another that is right next to it...
>
> And if required, the deletion/retagging of
> stop_position/bus_stop/(tram_stop) nodes in areas where
> "platform"-nodes/ways exist could be done in a semi-mechanical edit.
>
> Then, maybe the renders would also hail this only available tag as
> something worth showing...
>
> KR
> RobinD. (emergency99)
> --
> *Von:* Jo 
> *Gesendet:* Donnerstag, 9. Mai 2019 20:22
> *An:* Public transport/transit/shared taxi related topics
> *Betreff:* Re: [Talk-transit] Ideas for a simplified public
> transportation scheme
>
> I have been holding off to respond to this. 

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Jo]

I have been holding off to respond to this. Almost a decade ago I started
asking for public_transport=platform combined with bus=yes to be rendered,
so it would become possible to drop highway=bus_stop.

After all those years it has become obvious that there is no willingness to
do so. So it makes sense to drop the public_transport tagging scheme
instead as it clearly failed to deliver on its promise to streamline
mapping of public transport.

As far as I am concerned a few things are important:

* 1 single object to represent a bus stop.
* This object should clearly show on which side of the way the stop is
located.
* My preference is to have this mapped on a single node, which keeps
representing the stop for its 'lifetime'.
* There is no problem to use highway=bus_stop for such a node.

So far, so good.

In Belgium, the cities of Antwerp and Ghent and all the villages along the
coast have trams which are operated by the same operator as the buses. This
means that it can happen that the pole next to where the passengers wait
serves for both buses and trams. The operator assigned a single reference
number to these, so for me it's obvious that such tram stops go on those
same nodes and by extension so do all the other tram stops.
Apparently though tram and other rail infrastructure does have nodes, but
those nodes seem to be mapped as nodes on the railway itself and that's
where things start to clash. Not really a big deal, unless you meet a
mapper who insists those nodes should be on the railway ways...

By analogy I would also have nodes next to the railway for subway and maybe
even for train, but I never actually got around to mapping train
infrastructure, the 7 bus and tram stops were enough to keep me busy.

Polyglot

On Thu, May 9, 2019 at 1:19 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
> On 08/05/2019 20:56, Tijmen Stam wrote:
> >
> > I never understood the whole railway=platform discussion.
> > IHMO hw=bus_stop, hw=platform and rw=platform should die, and all be
> > replaced by public_transport=platform
>
> You fail to say why.
>
> > I have updated entire public transport concessions with almost all
> > stops having a platform way or area. In places where I did make
> > something _new_, I didn't include highway=bus_stop and deleted the old
> > one,
>
> Please clarify what you mean by the "old one"
>
> > under the "don't tag for the renderer" idea, and everything works fine
> > on my preferred renderer (osmand)
>
> That isn't the only rendering
>
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Help with bus route consisting of a round trip

[Jo]

This summer it will see an additional improvement for routes with
loops/spoons if the GSoC project gets accepted.

Jo

On Fri, Mar 22, 2019 at 12:10 AM seirra  wrote:

> (replied to using a backup because my other email is currently down) I
> find the automatic sort button in the relations editor is a great tool for
> mapping routes
> On 3/19/19 1:55 AM, David Suárez wrote:
>
> Oh, I couldn't find the problem, but I will keep working on improving
> other routes. I hope to become more skillful in a couple of months.
>
> Thanks again,
> David
> El 18/03/19 a las 19:10, Jo escribió:
>
> I removed two ways from the relation. One where there are 2 parallel ones,
> but only one of those can serve that stop. The other was a part that I
> deleted as well. It was probably the result from a split that went bad.
>
> Jo
>
> On Tue, Mar 19, 2019 at 1:05 AM David Suárez  wrote:
>
>> Yes, I'm using it, but I am just beginning. If you don't mind, I would
>> ask you what was the problem? I could swear there was no segment missing.
>>
>> Gracias,
>> David
>> El 18/03/19 a las 17:22, Jo escribió:
>>
>> Hola David,
>>
>> Now it's continuous. Do you know about the PT_Assistant plugin?
>>
>> Jo
>>
>> On Mon, Mar 18, 2019 at 11:57 PM David Suárez 
>> wrote:
>>
>>> Hello,
>>>
>>> I am trying to improve public transport route in my city following the
>>> PTv2 scheme. However, I get a validation warning regarding the existence
>>> of a gap. I checked all the way segments but I cannot find any issue,
>>> except for a couple of segments which appear in the wrong direction when
>>> using the relation editor in JOSM. Nonetheless, both segments are
>>> ordered correctly in the route and they are marked as two-way paths.
>>> Hence, I don't know if the validation problem is related to the route
>>> being a round trip or what I am missing.
>>>
>>> This is the route: https://www.openstreetmap.org/relation/9402608 and
>>> the problematic segments seem to be:
>>> https://www.openstreetmap.org/way/499715621 and
>>> https://www.openstreetmap.org/way/96613480
>>>
>>>
>>> Thank you for your help,
>>> David
>>>
>>>
>>>
>>> ___
>>> Talk-transit mailing list
>>> Talk-transit@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-transit
>>>
>>
>> ___
>> Talk-transit mailing 
>> listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>
> ___
> Talk-transit mailing 
> listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>
>
> ___
> Talk-transit mailing 
> listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Help with bus route consisting of a round trip

[Jo]

I removed two ways from the relation. One where there are 2 parallel ones,
but only one of those can serve that stop. The other was a part that I
deleted as well. It was probably the result from a split that went bad.

Jo

On Tue, Mar 19, 2019 at 1:05 AM David Suárez  wrote:

> Yes, I'm using it, but I am just beginning. If you don't mind, I would ask
> you what was the problem? I could swear there was no segment missing.
>
> Gracias,
> David
> El 18/03/19 a las 17:22, Jo escribió:
>
> Hola David,
>
> Now it's continuous. Do you know about the PT_Assistant plugin?
>
> Jo
>
> On Mon, Mar 18, 2019 at 11:57 PM David Suárez  wrote:
>
>> Hello,
>>
>> I am trying to improve public transport route in my city following the
>> PTv2 scheme. However, I get a validation warning regarding the existence
>> of a gap. I checked all the way segments but I cannot find any issue,
>> except for a couple of segments which appear in the wrong direction when
>> using the relation editor in JOSM. Nonetheless, both segments are
>> ordered correctly in the route and they are marked as two-way paths.
>> Hence, I don't know if the validation problem is related to the route
>> being a round trip or what I am missing.
>>
>> This is the route: https://www.openstreetmap.org/relation/9402608 and
>> the problematic segments seem to be:
>> https://www.openstreetmap.org/way/499715621 and
>> https://www.openstreetmap.org/way/96613480
>>
>>
>> Thank you for your help,
>> David
>>
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>
> ___
> Talk-transit mailing 
> listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Help with bus route consisting of a round trip

[Jo]

Hola David,

Now it's continuous. Do you know about the PT_Assistant plugin?

Jo

On Mon, Mar 18, 2019 at 11:57 PM David Suárez  wrote:

> Hello,
>
> I am trying to improve public transport route in my city following the
> PTv2 scheme. However, I get a validation warning regarding the existence
> of a gap. I checked all the way segments but I cannot find any issue,
> except for a couple of segments which appear in the wrong direction when
> using the relation editor in JOSM. Nonetheless, both segments are
> ordered correctly in the route and they are marked as two-way paths.
> Hence, I don't know if the validation problem is related to the route
> being a round trip or what I am missing.
>
> This is the route: https://www.openstreetmap.org/relation/9402608 and
> the problematic segments seem to be:
> https://www.openstreetmap.org/way/499715621 and
> https://www.openstreetmap.org/way/96613480
>
>
> Thank you for your help,
> David
>
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] identifier in ref:xOperatorx=y0yyyy to url=http://mijnlijn.be/y0yyyy

[Jo]

Our bus stops in Flanders have unique identifiers visible to the public on
the flags of the stop poles.

I started by entering those in the ref tag, then later decided to use
ref:De_Lijn=y0, as some of those stops are served by other operators as
well.

For several years now itt's possible to obtain real-time information about
the buses on a url+identifier, so I want to add that to those stops. As i
don't like to duplicate information I'd prefer to drop the ref:De_Lijn
though.

So all of those stops would have:
url=http://mijnlijn.be/303079(<- you can test this, the url is
expanded/translated to a url on www.delijn.be)

For the conversion, I'd like to launch a Belgian "Project of the month", so
the position of the stops can be verified once more by locals, but also
shelters and bus_bays can be added and if cycle ways split off to go around
those bus bays, that detail can be added as well.

I know that that is what we have been doing for the past 5+ years, but now
it would get some more dedicated focus.

For several years I thought having the identifier n a dedicated ref:X tag
and then telling everyone about how to turn it into such a url was the way
to go,. That doesn't actually work though. Nobody knows how to get from the
identifer to the url. Giving potential passengers a url they can simply
click through on, seems to be the better way of doing this for this use
case.

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Hi Tony,

Could you also have a look at the proposal I created?

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

At the moment I'm looking into how to represent that in meaningful ways
using MapCSS in JOSM, but I don't think that makes too much sense.

For your use case where you want to do routing. The timetable relations
give the possibility to calculate when a bus passes at a particular stop at
a given time of day. And it's possible to see how long it takes to get from
there to another stop or calculate at what time one arrives there. For
complex routing involving transfers this will involve quite a bit of
recursion, but it should be feasible.

At the moment I'm looking how this can be rendered in meaningful ways and
how data entry can be made as convenient as possible. (I think we need
spreadsheet like functionality to accomplish that, I made an attempt here:
https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
.
But we need more possibilities for indicating where a specific time on the
schedule came from.

Right now I have the following:

Line (route_master relation)
   contains several:
 Itineraries composes of (longest) stop sequences including ways (route
relation)
if referred to by 1 or more
   Actual stop sequences with time deltas (timetable relation)
   The stops in these relations are always a subset of the
referre route relation

I would also include a public_holidays relation in each route_master
relation to avoid duplication but still enable which days get Sunday
schedules and which days are in school holiday periods.


If anyone feels like doing a Google Hangout to discuss this, let me know. I
have time tonight and Friday evening

Polyglot

Op wo 7 nov. 2018 om 12:24 schreef Tony Shield :

> Hi
>
> I have worked in data analysis for many years, recently become interested
> in PT and added routes to my locality. I look at PT timetables frequently
> as much of my travel is by PT.
>
> My use case is that I want to find times and routes from A to B, I do not
> know the route numbers or their actual route. I expect the system to be
> able to give times and routes and any interchanges.
>
> As a system I fail to see how putting the timing detail on each stop will
> enable me to efficiently perform that use case. From what is described
> system would have to identify route, then iterate route to check if
> destination is on route, if on route then  select time entry in A then a
> time entry in B and ASSUME that they both relate to the same journey and
> have been updated correctly. For connections/interchanges the same rules
> apply. Those assumptions make storing the data against a stop
> extraordinarily unreliable, the proposed method does not take shortened
> journeys - eg school or factory journeys where the whole route is not
> travelled  - into account.
>
> I suggest that the best way to get timetable data is to replicate the
> present system that most PT organisations do - a table related to the
> route. A timetable could be associated with an OSM route. A system will be
> required to generate meaningful times and itineraries, so should we be
> asking those existing OSM routing people what  is their preferred way to
> store timetable data that can be updated reliably.
>
> Here in the UK timetable data is in the public domain - is that the case
> in other places?
>
> TonyS
>
>
>
> On 06/11/2018 19:59, Jo wrote:
>
> 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 alrea

Re: [Talk-transit] [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
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Great to hear that. when I get back home I'll further elaborate on the
spreadsheet idea. Now with a full timetable for one general direction of
travel

On Wed, Nov 7, 2018, 13:59 Tony Shield  Hi Jo
>
> I've looked at your proposal and I'm starting to understand it and like it.
>
> I looked at your spreadsheet and this is the style of data entry which I
> think will work, using a spreadsheet then processing it to OSM data
> formats. If we use a spreadsheet then why not put the whole timetable in
> there and then process it. In that case short journeys are allowed
> wherever they start and end, not having to calculate journey time and
> apply to a stop is easier and allows direct look up of departures from
> the stop - as Leif originally wanted, spreadsheet processing then allows
> for peak hour times; and the source and style of the data matches that
> in OSM - so traceability is resolved.
>
> Using the route_master to hold the timetable is good.
>
> Can't help with MapCSS - I don't know how it fits in.
>
> Sorry - busy tonight and Friday so can't talk.
>
> Regards
>
> Tony
>
>
>
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Hi Tony,

Could you also have a look at the proposal I created?

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

At the moment I'm looking into how to represent that in meaningful ways
using MapCSS in JOSM, but I don't think that makes too much sense.

For your use case where you want to do routing. The timetable relations
give the possibility to calculate when a bus passes at a particular stop at
a given time of day. And it's possible to see how long it takes to get from
there to another stop or calculate at what time one arrives there. For
complex routing involving transfers this will involve quite a bit of
recursion, but it should be feasible.

At the moment I'm looking how this can be rendered in meaningful ways and
how data entry can be made as convenient as possible. (I think we need
spreadsheet like functionality to accomplish that, I made an attempt here:
https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
 .
But we need more possibilities for indicating where a specific time on the
schedule came from.

Right now I have the following:

Line (route_master relation)
   contains several:
 Itineraries composes of (longest) stop sequences including ways (route
relation)
if referred to by 1 or more
   Actual stop sequences with time deltas (timetable relation)
   The stops in these relations are always a subset of the
referre route relation

I would also include a public_holidays relation in each route_master
relation to avoid duplication but still enable which days get Sunday
schedules and which days are in school holiday periods.


If anyone feels like doing a Google Hangout to discuss this, let me know. I
have time tonight and Friday evening

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [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: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

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 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 »
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> L

Re: [Talk-transit] [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: [Talk-transit] [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
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Bus Service - Route - end of life

[Jo]

Hi Tony,

At the moment we don't have anything in place to do that. When itineraries
disappear, their corresponding route relations are deleted. When entire
lines disappear their route_master and route relations are deleted. If they
are renamed and/or their identifier changes and it's obvious that it's all
based on an already mapped predecessor, you could 'reuse' the relations.

But we don't have any way to indicate when the new situation starts or the
old situation ceases.

The same goes for (long term) detours. We can't represent that.

Polyglot

Op ma 24 sep. 2018 om 13:32 schreef Tony Shield :

> Hi
>
> My local bus operator has ceased to operate a route, so the question is
> what is the best way to handle this end-of-life cycle?
>
> Should I delete the relation or is there an end date tag which says that
> the route is no longer running?
>
> Conversely is there a start date tag?  - my operator announces new  bus
> routes in advance - I can create the relations in advance but should
> they be published in advance of them actually running?
>
> And do the PT maps groups respect such start and end-dates?
>
> When I get answers should I update the wiki?
>
> Regards
>
> Tony
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] PT_Assistant new functionality to add itineraries more conveniently

[Jo]

Hi,

I'm still beta testing it, so it's not available for general use yet, but I
wanted to show you a peak preview of new functionality in PT_Assistant,
that's going to change how we add ways to route relations for bus lines in
an impressive way:

https://www.youtube.com/watch?v=dvxZLOFsNzI

It should become available for everyone in about 2 weeks. If you want to
help with beta testing, contact me and I'll send you a script to start up
JOSM-latest + download the development version of PT_Assistant on Linux.

Jo
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Documentation issues of PT tagging schemes

[Jo]

oh, in case stop_area relations are added, it makes sense to duplicate the
name of the stop on them.

Op do 26 jul. 2018 om 12:38 schreef Jo :

> Way 0:
>
> node next to highway/railway
> hw=bus_stop/rw=tram_stop
> pt=plaform
> bus=yes
> tram=yes
> name
> ref
> operator
> network
>
> IF there is a platform:
>
> way or area with:
> hw=platform and/or rw=platform
> optionally pt=platform
> optionally tactile_paving=
> optionally wheelchair=
> nothing else (details are on platform node)
>
> IF you like:
> node as part of highway/railway
> pt=stop_position
> bus=yes
> tram=yes
> other_modes_of_transport=
> nothing else (details are on platform node)
>
> At the start or end of the itinerary (route relation) split on this node
> and only keep the part of the way in the route relation that connects to
> the rest of the itinerary.
>
> Of course it's possible to add:
> amenity=shelter/shelter_type=public_transport
> bench=yes
> waste_basket=yes
> etc. as separate objects
>
> This way of mapping is highly continuous between the original way and what
> was proposed in 2011.
>
> If done right, everything hinges on the platform nodes, which are the main
> representation of the stops, both for indicating where they are on the map
> (rendering) as for using them in the route relations.
>
> Things I don't see as unnecessary redundancy:
> on these platform nodes:
> bin=yes
> shelter=yes
> bench=yes
> even when they are also mapped as separate objects
> and
> route_ref=1;2;E;128A
> Even if thisi can be deduced from membership of route relations.
>
> All of the last ones could be used for validation. (PT_Assistant now
> checks for correspondence of route_ref with ref tags in route relations and
> warns if they are different, only if route_ref is present, obviously)
>
> This is about as simple as it gets. Or could be.
>
> Polyglot
>
> Op do 26 jul. 2018 om 11:31 schreef DC Viennablog  >:
>
>> Hi,
>>
>> I would also be OK with only the stop in the relation (with all tags
>> possible (Way 1) or as Way 2 (see below)) and the other aspects just as
>> additional pieces, however, a bit of redundance could be there to make the
>> platform and relations also human-readable. I know, people dealing with
>> anything IT despise redundancy. But in this case it does not add to
>> confusion, but helps eleviate it. If I have a stop_position called
>> "Hospital" and then a platform that is only referenced in the editor by
>> it's way-number and the fact that it is a platform, then figuring out that
>> these go together is quite tricky, even with a stop-area relation. Sure,
>> when it is in a relation, that argument could be taken down to me being a
>> noob there, but then at least the stop area also needs to have the name,
>> once again adding a needed, not confusing level of redundance.
>>
>> The way that relations are supposed to work is, that all tags of the
>> relation (at least in case of stop_area and also some buildiing relations)
>> is, that the tags should be inherited by the items contained inside of
>> them. So if we either accept that, or do not accept that, there are two
>> ways of doing it:
>>
>> --
>>
>> *Way 1*: (ignoring the theoretical inheritance of tags):
>>
>> *On a node on the road / tracks*:
>>
>>- public_transport=stop_position
>>- bus=yes / trolleybus=yes / tram=yes / train=yes
>>- name
>>
>> optional tags:
>>
>>- network
>>- operator (as in the company that actually maintaines the stop
>>(stop-position+platform), which can differ from the line operators)
>>- local_ref
>>- alt_name
>>- uic_name
>>- old_name
>>- note
>>- description
>>
>>
>> *On a node, way or polygon/multipoligon on the side of the road/track *(*as
>> a platform*):
>>
>>- public_transport=platform
>>
>> optional/redundant/maybe even discouraged tags:
>>
>>- bus=yes / trolleybus=yes / tram=yes / train=yes,
>>- name / ref
>>- network
>>- note
>>- description
>>
>> Those two elememts (and others of the same station area/complex)  then *need
>> to be *put in a* stop_area *relation:
>>
>>- public_transport=stop_area
>>- bus=yes &/ trolleybus=yes &/ tram=yes &/ train=yes
>>- name
>>
>> optional tags:
>>
>>- network
>>- old_name
>>- alt_name
>>- uic_name
>>- note
>>- descript

Re: [Talk-transit] Documentation issues of PT tagging schemes

[Jo]

ack *(*as
> a platform*):
>
>- public_transport=platform
>- highway=platform in case that makes sense
>- area=yes  (shouldn't that be implied by
>highway=platform on polygons anyways)?
>
> optional tags:
>
>- note
>- description
>
> Those two elememts (and only those two) then *need to be *put in a*
> stop_area *relation:
>
>- public_transport=stop_area
>- bus=yes / trolleybus=yes / tram=yes / train=yes
>- name
>
> optional tags:
>
>- network
>- operator (as in the company that actually maintaines the stop
>(stop-position+platform), which can differ from the line operators)
>- local_ref
>- alt_name
>- old_name
>- note
>- description
>
> then, if there are multiple stop_positions & platforms for the same
> stop-complex, *multiple stop_area relations need to *belong to a 
> *stop_area_group
> *relation:
>
>- public_transport=stop_area_group
>
> optional tags:
>
>- name=*
>- alt_name
>- uic_name
>- old_name
>- note
>- description
>- wheelchair & wheelchair:description  (if you can access the complex
>at all with one)
>
> possibly discouraged/redundand tags (they are conceptually reversly
> inherited from the relation-members):
>
>- bus=yes &/ trolleybus=yes &/ tram=yes &/ train=yes
>- network
>- operator
>
>
> --
>
> Way 1 is easier as a concept, but has more redundance, Way 2 is closer to
> a good database, but more load on the editors.
>
> --
>
>
> I think it would be time for a think-tank and following proposal of some
> sort to ammend the p_t:v2 to a "simpler to edit" and "to describe in the
> wiki", but also "as close to database-concept as possible"-scheme.
>
> Kind Regards
> RobinD (emergency99)
>
> PS:
> Signs I use in the mail:
> " / " = or
> " &/ " = and/or
>
> *PPS: My firstmessage failed to send to the list. So for reference: here
> is my initial message that only went to Jo:*
>
> Hello,
>
> I have been following the discussion about p_t:v2 and would like to also
> throw in my point of view.
>
> In my opinion, a few things need to change, but some should stay as they
> are now.
>
>
>1. I would love to have the highway=bus_stop tag depricated. The whole
>confusion I think comes from the highway=* and railway=* tags. Those should
>mostly be dropped in regards to stop positions.
>2. The public_transport tags should become the new main attraction. I
>would leave the stop_position tag. That would go as follows:
>
> *On a node on the road / tracks*:
>
> public_transport=stop_position
>
> bus=yes / trolleybus=yes / tram=yes / train=yes
>
> name=*
>
> optional tags: network, local_ref, alt_name, uic_name, note, description...
>
>
> *On a node, way or polygon/multipoligon on the side of the road/track *(*as
> a platform*):
>
> public_transport=platform
> maybe optional: bus=yes / trolleybus=yes / tram=yes / train=yes
> optional tags: name, network, operator (as in the company that actually
> maintaines the station, which can differ from the line operators), note,
> description ...
>
> Those two elememts could be put in a* stop_area *relation, and multiple
> stop_area relations that belong together in a * stop_area_group *relation,
> that can be tagged with:
> name=*
> optional tags: network, operator (as explained above), alt_name, uic_name,
> note, description...
>
> Then, the tags like railway=halt and railway=station, which in my opinion
> are to specific for osm could be removed, making mapping the stops of
> raillines much easier. (In german, that is the endless discussion whether a
> trainstop is a station (Bahnhof) or halt (Haltestelle). That is quite
> unimportant in most cases. If need be, we could map the infrastructure
> (landuse or building) as a public_transport=station or
> public_transport=halt instead)).
>
> In terms of the route relation, we then could add the stop_area relations
> to the route relation with a *stop *role.
>
> 3. One problem adressed some time earlier was the great amount of
> redundance that the route relations add to the database. There was a, not
> even that bad, though somewhat inpractible sugesstion, to sum up some roads
> in route part relations, and always when those routes would need to be
> added to a relation, we add the relation of routes instead. I had a look
> around vienna and found a few instances, where that would work great, and
> some, where that would potentially yield the same amount or more

Re: [Talk-transit] Documentation issues of PT tagging schemes

[Jo]

For me the fact that highway=bus_stop is only allowed on nodes is a plus,
not a minus.

The reason why I would like us all to use nodes for representing the stops
is that a route relation with  a single node for each stop and then a
continuous linked string of ways is conceptually about as simple as it can
get.

I would prefer no to use stop_area relations in the route relations as it
adds a layer of indirection, which I feel is unneeded.

Oddly I wouldn't mind that for the ways though. For those it would indeed
be beneficial to group them in sub route relations. We need support in
editors though. I created some tickets to improve JOSM in that direction
(show continuity line if first way in sub relation connects to last way in
route / same for last way/next way in route). That would have to be part of
another proposal though.

I'd like to simplify first and then propose these sub relations for the
ways. Drawing the continuity line is one thing, visualising the whole
itinerary is another that become harder to do.

Anyway, you are saying that you think it's alright to duplicate details
between stop_position node/platform node, platform way and stop_area
relation and that is exactly what I think is the main problem with the
current way of mapping. The details should go onto 1 single object that
represents the stop and that object should be the (only) one added to the
route relations. stop_area relations can be useful to show which objects
belong together, but only if there is one for each stop. If they just group
everything for several stops that are near to one another, they can just as
well be left out.

Polyglot



Op do 26 jul. 2018 om 09:09 schreef DC Viennablog :

> Hello,
>
> I have been following the discussion about p_t:v2 and would like to also
> throw in my point of view.
>
> In my opinion, a few things need to change, but some should stay as they
> are now.
>
>
>1. I would love to have the highway=bus_stop tag depricated. The whole
>confusion I think comes from the highway=* and railway=* tags. Those should
>mostly be dropped in regards to stop positions.
>2. The public_transport tags should become the new main attraction. I
>would leave the stop_position tag. That would go as follows:
>
> *On a node on the road / tracks*:
>
> public_transport=stop_position
>
> bus=yes / trolleybus=yes / tram=yes / train=yes
>
> name=*
>
> optional tags: network, local_ref, alt_name, uic_name, note, description...
>
>
> *On a node, way or polygon/multipoligon on the side of the road/track *(*as
> a platform*):
>
> public_transport=platform
> maybe optional: bus=yes / trolleybus=yes / tram=yes / train=yes
> optional tags: name, network, operator (as in the company that actually
> maintaines the station, which can differ from the line operators), note,
> description ...
>
> Those two elememts could be put in a* stop_area *relation, and multiple
> stop_area relations that belong together in a * stop_area_group *relation,
> that can be tagged with:
> name=*
> optional tags: network, operator (as explained above), alt_name, uic_name,
> note, description...
>
> Then, the tags like railway=halt and railway=station, which in my opinion
> are to specific for osm could be removed, making mapping the stops of
> raillines much easier. (In german, that is the endless discussion whether a
> trainstop is a station (Bahnhof) or halt (Haltestelle). That is quite
> unimportant in most cases. If need be, we could map the infrastructure
> (landuse or building) as a public_transport=station or
> public_transport=halt instead)).
>
> In terms of the route relation, we then could add the stop_area relations
> to the route relation with a *stop *role.
>
> 3. One problem adressed some time earlier was the great amount of
> redundance that the route relations add to the database. There was a, not
> even that bad, though somewhat inpractible sugesstion, to sum up some roads
> in route part relations, and always when those routes would need to be
> added to a relation, we add the relation of routes instead. I had a look
> around vienna and found a few instances, where that would work great, and
> some, where that would potentially yield the same amount or more entries
> than in the first place. But that sugestion could also be a possibility at
> also allowing that, in addition to single roads in a route relation.
>
> I hope my description of my idea is understandable.
>
> Kind Regards
> Robin D (emergency99)
>
> PS: I mapped all bus-lines in Vienna the way that I think the p_t:v2
> scheme is supposed to work (keeping to the wiki as much as it doesn't
> contradict itself). The problem with the highway=bus_stop tag is, that it
> is only allowed on nodes. So as soon as the platform becomes
> "micro-mapped", the bus_stop has to move from the platform to the
> stop_position, which to me, as a new mapper in 2014, screamed: "That node
> is the most important part of the whole thing". Which obvously it isn't but
> tell that to an 

Re: [Talk-transit] [Tagging] Transport mode on platforms? (Was: Re: Documentation issues of PT tagging schemes)

[Jo]

Very soon after PTv2 was 'accepted' I understood that if we would ever
replace hw=bus_stop NODES with pt=platform, the mode of transport would
need to be added on these nodes.

Ever since it's a back and forth pulling between yes the mode of transport
can be added on them and NO the platforms don't need a mode of transport.

In the mean time, I'm not so sure that there is willingness to 'deprecate'
highway=bus_stop, not even sure if there ever was, and I guess there is no
real need for it etiher. The problem with that kind of thinking is that it
can lead to the conclusion the whole public_transport scheme is not needed
for the stops.

Now I don't mind using it, just like I wouldn't mind dropping it.

What I do mind is the use of multiple objects in the route relations to
represent the same stop and the perceived need to 'upgrade' stops from
nodes to ways/areas during their lifecycle if there are actual platforms
for passengers to wait on.

I created a 10 minute screencast showing some new functionality in
PT_Assistant, but more importantly it also shows the public_transport tags
are a bit confusing to some. In this case the stops mapped nicely as nodes
alongside the way got stop_position instead of platform as the value.

https://www.youtube.com/watch?v=KVcKredS0kA

PT_Assistant's validator will tell you about this and JOSM will make it
easy to correct the situation.

After stopping the recording I went on to fix the from/to tags and adding a
route_master relation before uploading. But I wanted to keep the screencast
concise and to the point.

Polyglot

Op wo 25 jul. 2018 om 22:56 schreef SelfishSeahorse <
selfishseaho...@gmail.com>:

> Hi
>
> It seems that the only problem with PTv2 that remains is the rendering
> of public_transport=platform, i.e. whether public_transport=platform
> (and maybe public_transport=station too) should get the transport mode
> tag(s) (bus=yes/tram=yes/...).
>
> Note that the PTv2 proposal suggested to map the *stop position* 'as
> an icon depending of the vehicle type that is stopping at the
> position',[1] which may have led to some people mapping only
> stop_position's, others mapping only platform's and still others
> mapping stop_position's and platform's which in turn has led to
> complication and confusion.
>
> [1]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3
>
> As this question pops up every now and then, it might make sense to
> finish discussing this.
>
> I'm double posting this message on the transport mailing list, so that
> the discussion can continue there.
>
> Regards
> Markus
>
> On Wed, 25 Jul 2018 at 19:25, Roland Olbricht 
> wrote:
> >
> > Hi,
> >
> > > What I would like to see is how to map a Public Transport Route in
> > > version 3 .. that has the bear minimum of things to have and the rules
> > > that make the route valid.
> >
> > This is where the problem sits; the point of view of what a route is
> > vary wildly. Few people are even willing to pinpoint and tell their
> > personal definition.
> >
> > Things that exist under the notion of route:
> >
> > - Urban bus/tram/subway services (many stops, many departures, route
> > taken always or almost always the same, route through the street grid
> > practically fixed, often unchanged for years to decades)
> >
> > - Peak services, special routes to depot, school services (few
> > departures, many stops, also many route variants, frequently changing,
> > making it impractical to route them all)
> >
> > - Hail bus services: the bus is promised to serve a certain street and
> > stops on hail (many departures, route taken always or almost always the
> > same, route through the street grid practically fixed, often unchanged
> > for years to decades)
> >
> > - Urban and regional train lines (many stops, many departures, route and
> > platforms fixed). Those routes are often in parts or completely land
> marks.
> >
> > - Long distance train lines (many stops, many departures, route and
> > platforms may or may not vary, can stop at a different platform of the
> > same station for operational reasons)
> >
> > - Long distance bus services (few stops, few departures, route between
> > stops often changing on the fly)
> >
> > - Ferry lines (often only two stops, completely different
> > infrastructure)
> >
> > Further kinds of routes may exist. For example, some communties use
> > virtual metro lines that connect station node to station node. This is
> > most often because the communties lack the ressources to map the actual
> > underground structures.
> >
> > I personally map only urban bus/tram/subway services and urban and
> > regional train lines (and do not delete other routes). For these
> > services it is sane to have marked the stops and the route on the grid.
> >
> > The route on the grid is straightforward: this is in any PT scheme a
> > sequence of way members that together form a continuous trajectory. Hail
> > sections get a special role for these members.
> >
> > The stop 

Re: [Talk-transit] [Imports] [OSM-talk] Automated edit for bus lines in Paris area

[Jo]

A tool to help with this kind of integration is being developed as a Google
Summer of Code project. It's in early stages and focused on GTFS feeds, but
we can look into doing this for lists of stops with approximate coordinates
as well.

Polyglot

Op di 5 jun. 2018 om 08:59 schreef Stefan de Konink :

> If this will be allowed, I would want to do the same for The Netherlands.
>
> Stefan
>
> On dinsdag 5 juni 2018 06:45:22 CEST, Mateusz Konieczny wrote:
> > "Summary: Adding values for two existing tags to bus stops"
> >
> >  example edit changes three tags.
> >
> > The same in the proposed changes etc comment.
> >
> > "This provides a link between the OSM node and the STIF stop_id."
> >
> > And how this match is obtained?
> >
> > Is source code of program generating matches and making edit
> > published somewhere?
> >
> > How edits will be split to avoid mega-edit changing thousands
> > of objects with massive bounding box?
> >
> > I see no mention of changeset tags - and wiki recommends adding some.
> >
> > 5 Jun 2018, 00:15 by ok...@johnfreed.com:
> > I am planning an automated edit to improve our coverage of two
> > existing tags in the Paris region. The data source is the
> > regional transit coordinating agency, Île-de-France Mobilité,
> > formerly STIF.
> >
> > There is a question about wheelchair access that I would like feedback
> on.
> >
> > If there is no need for a significant change, I plan to
> > implement this around June 20.
> >
> > Please make comments here or on the Discussion page attached to
> > the proposal:
> >
> > https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis
> >
> > Thanks,
> >
> > John
> >
> > !DSPAM:1,5b16340e79641880612683!
>
> --
> Stefan
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Jo]

The node doesn't describe the platform. The naming is unfortunate, but I
think we're stuck with it. The node represents the stop. What stop platform
way and stop_position node belongs together can be expressed using a
stop_area relation. Then it's needed only once. There is no need to do it
over and over again in the route relations.

If it's such a problem that mapped stop_positions are not in the route
relations, my next step (for Belgium at least) is to remove the ones that I
added from the OSM. The route relations I'm maintaining will continue to
have 1 object per stop.

Unfortunately, my colleague in Brussels read the wiki and he is adding
stop_position nodes everywhere and adding them to the route relations of
the STIB/MIVB operator. The consequence is that I won't be maintaining
those (not really a problem, as I wasn't doing that anyway), but those
stops are being used by the other 2 operators too, of course. And I won't
be able to remove those stop_position nodes AND I won't be adding them to
the route relations, so it becomes impossible to comply with what the wiki
'dictates' at present (it didn't just a few months ago).

What I mean by stability of the data is the following:

A mapper comes along and maps a bus stop on a node. Another mapper adds it
to some route relations. Then a mapper passes by and adds a way for the
platform, transferring all the tags and adding the way to the route
relations.

Then somebody read the wiki and adds a stop_position node as well and adds
this to all the route relations as well.

Lots of changes to the relations, no real change to the itineraries. If the
second mapper had simply added a highway=platform and maybe a stop_area
relation, the route relations would have remained stable.

Anyway, I'll keep going the way I like mapping PT and the rest of the world
can do it in more complex ways, each slightly different from the other,
depending on when they read the wiki. It's all fine. I'd like to see it
become simpler, more inclusive for everyone. Now most mappers simply say:
public transport I don't touch it. Tried to read the wiki, gave up. Let the
'specialists' handle it.

I'll continue working on PT_Assistant and of course I'll try to make it
work for simple and complex ways of mapping alike.

Polyglot

2018-04-16 20:51 GMT+02:00 Stephen Sprunk <step...@sprunk.org>:

> Jo,
>
> IMHO, if a stop_position exists but isn't in a relation, consumers can't
> be sure which routes/platforms it applies to, and that means it's just
> clutter rather than useful data.  Given how many of them seem to be
> flat-out wrong, though, we definitely need to document it better--and make
> maybe it optional so mappers aren't forced to add something that they don't
> really understand.
>
> If there's a way/area for the platform, then IMHO one should not add a
> separate node for the platform; that is redundant.  If you need a single
> point for some purpose, you can just compute the centroid.  I don't see
> what "stability" has to do with it; once it's mapped, it's not going to
> change much over time unless the physical platform itself is changed, and
> one shouldn't expect stability in that case.  One can tag either just as
> easily too, so I don't understand that argument at all.
>
> When I map a building, I can make a node and put all the tags there, or I
> can make an area and put all the tags there.  Nobody expects a a way for
> the outline and a separate node inside it with all the tags--or more
> likely, a conflicting set of tags because some mappers didn't notice the
> redundancy.  Why should a platform be any different?
>
> S
>
>
> On 2018-04-16 13:20, Jo wrote:
>
> I knew this was going to be hard. Anyway, I made sure that it's definitely
> allowed to tag bus stops as platform nodes. Every few months I look at the
> wiki and each time it changes. At present it says that if a stop_position
> node is present for a bus stop, it has to be added to the route relations.
> I definitely don't agree with that and I won't do that. The route relations
> I'm creating only contain 1 object per stop. Having said that, I won't be
> removing stop_position nodes or platform ways from route relations, if they
> are already present. Unless this proposal passes somehow, then I will help
> with the conversion.
>
> My proposal does not say that it's not allowed or possible to map
> platforms as ways or areas.
>
> It only says that for stability of the data, it would be better to map all
> the detail tags on 1 node and only add that node to the route relations.
>
> If a platform is present, it's perfectly possible to tag it with
>
> highway=platform or railway=platform
> and optionally
> tactile_paving=yes
> wheelchair=yes/limited/no
>
> Jo
>
> 2018-04-16 19:17 GMT+02:00 Stephen Sprunk <step...@sprunk.org>:
>
>

Re: [Talk-transit] stop_position proposal

[Jo]

It's not a coincidence that there are few 'failures' in Belgium. Over the
years I added 70k of them and cleaned up the existing ones as I got along,
maybe 1k. As I chugged along, I didn't read the wiki every time it changed
and when I went to have a look in neighbouring countries, I noticed the
mapping was done differently there. Of course, now I am the one who is
doing things differently, but the way I see it, I'm doing it in as simple a
way as possible, while still complying with what matters of PT v2. Anyway,
I didn't feel like adding 140k objects, so there will be relatively few
stop_position nodes compared to the number of platform nodes. If you look
more closely at the data, you will find that platform ways are actually
mapped, where they exist. It's also not that I'm not mapping any
stop_position nodes. Where lines start/end and where a node is needed to
split the way anyway, I am mapping them consistently.

Polyglot

2018-04-16 19:50 GMT+02:00 Roland Olbricht :

> Dear all,
>
> there is another proposal, distinct from Polyglot's proposal that is in
> RFC since some days:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_
> stop_positions_and_platforms
>
> Before I tell a personal opinion, I would like to present some related
> facts. The basic idea is to look how the tags are actually used.
>
> Taginfo tells us
> http://taginfo.openstreetmap.org/keys/public_transport
> that there are more platform tags than stop_position tags
> and both are so many that you cannot reasonably view them all on a map.
>
> About two thirds of elements with public_transport=platform
> bear also highway=bus_stop
> https://taginfo.openstreetmap.org/tags/public_transport=plat
> form#combinations
> but there are at least more than 100'000 nodes (not ways, not relations,
> hence not fully mapped platforms) that are public_transport=platform but
> not highway=bus_stop.
>
> These are still too many to reasonably show them on a map (and to not talk
> what should happen about them). For you convenience, I have added a bbox
> limited request for those that you need to move to your area of interest:
> https://overpass-turbo.eu/s/xWI
> From my fist impression, most of them are simply not tagged with
> highway=bus_stop. However, the first hit in Rome is a tram stop that for a
> good reason is not tagged as highway=bus_stop.
>
> It is much less compelling to retag public_transport=stop_position as
> highway=bus_stop. Less than one third of them is tagged as
> https://taginfo.openstreetmap.org/tags/public_transport=stop
> _position#combinations
> And here, many belong to railways. Again, a bbox bounded query:
> https://overpass-turbo.eu/s/xWM
>
> Another matter are definitely wrong public_transport=stop_position,
> because they are off any highway, railway, or ferry. There is a surprsingly
> large number of them. I have made an area related request because we need
> the statistics in a moment:
> https://overpass-turbo.eu/s/xWF
>
> Running this request for Germany, France, Belgium, the Netherlands,
> Austria, and Switzerland shows that more than half of all global uses of
> stop_position are in these six countries (go to "Data", read the first
> entry). This is not an arbitrary selection - all these six countries have
> about 1000 to 2000 stop_positions per million inhabitants, but for
> comparision UK has only 150 stop_positions per inhabitant.
>
> However, the number of failures are significant, between 5% and 10% (with
> the exception of Belgium). The uneven distribution suggest that these
> relates to specific users, but the total number of users is more than 500,
> suggesting that there is a problem to explain the difference between
> stop_position and platform.
>
> All in all, I do agree that there is definitely room for the improvement
> of public transport mapping. But making the tagging of 500'000 nodes
> deprecated and neglecting both problems with that and the more presseing
> problems is probably not a good way to go forward. Given that Ilya refuses
> for unknown reasons to read this mailing list, please discuss the matter on
> the discussion page if he wiki page.
>
> Best regards,
>
> Roland
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Jo]

Here in Belgium, we have normal buses and longer ones, either can have 2
doors or 3 doors. There is no way of knowing which of those buses is going
to serve which stops at a given time. The only thing we do know for sure,
is that we are supposed to get on in front, except for wheelchairs and
parents with strollers. I fail to understand why stop_positions are
considered to be that important. Especially for buses. For trains I might
understand, but even there it's impossible to predict where exactly the
doors will be when the train stops. And it's not important, what matters is
when there are zones on the platforms, those we can map by splitting those
platforms.

Jo

2018-04-16 20:17 GMT+02:00 Ed Loach <edlo...@gmail.com>:

> Stephen wrote:
> > If a consumer doesn't care about stop_position members, it's trivial
> > to
> > ignore them.  If the current spec says they're mandatory, then
> > propose
> > making them optional; I would support that.  I don't support
> > prohibiting
> > or removing them.
>
> They are optional in the current spec. I don't bother with them in bus
> route relations as physically a bus has to stop on a relation member way
> close enough to the bus stop (platform) node for passengers to get on (with
> the exact stop position depending whether the particular bus has doors at
> front, middle or rear).
>
> Ed
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Jo]

I knew this was going to be hard. Anyway, I made sure that it's definitely
allowed to tag bus stops as platform nodes. Every few months I look at the
wiki and each time it changes. At present it says that if a stop_position
node is present for a bus stop, it has to be added to the route relations.
I definitely don't agree with that and I won't do that. The route relations
I'm creating only contain 1 object per stop. Having said that, I won't be
removing stop_position nodes or platform ways from route relations, if they
are already present. Unless this proposal passes somehow, then I will help
with the conversion.

My proposal does not say that it's not allowed or possible to map platforms
as ways or areas.

It only says that for stability of the data, it would be better to map all
the detail tags on 1 node and only add that node to the route relations.

If a platform is present, it's perfectly possible to tag it with

highway=platform or railway=platform
and optionally
tactile_paving=yes
wheelchair=yes/limited/no

Jo

2018-04-16 19:17 GMT+02:00 Stephen Sprunk <step...@sprunk.org>:

> On 2018-04-16 08:11, Philip Barnes wrote:
>
>> On 16 April 2018 07:46:13 BST, Jo <winfi...@gmail.com> wrote:
>>
>>> Anyway, you're right in that the main point of my proposal is to get
>>> people to add 1 object per stop to the route relations.
>>>
>>
>> I think this is a good idea for bus routes as they are quite simple.
>> There is a sign, the passengers wait thereabouts, the bus stops so the
>> door is at this point and the passengers can then board, pay or show
>> their pass to the driver. Making this too complicated will deter
>> mappers from adding public transport.
>>
>> If mappers want to add additional information then they should be free
>> to do so but it should not be compulsory.
>>
>
> To me, this is the crux of the debate.  If mappers have put in additional
> data or detail that you don't care about, then you should ignore it rather
> than remove it (or demand that they do so), because some other consumer may
> want that additional data.  Ignoring data that is present but not needed is
> always easier and more reliable than trying to deduce data that is needed
> but not present.
>
> If a consumer doesn't care about stop_position members, it's trivial to
> ignore them.  If the current spec says they're mandatory, then propose
> making them optional; I would support that.  I don't support prohibiting or
> removing them.
>
> If a consumer only wants a node for the platform but it's mapped as a
> way/area, then it's trivial to detect that and compute the centroid.  I
> don't support replacing existing ways/areas with nodes or prohibiting new
> ways/areas in the future.  If the current spec says they must be
> ways/areas, then propose making nodes allowed too; I thought that was
> already the case, but if not, I would support fixing that.
>
> S
>
>
> --
> Stephen Sprunk  "Those people who think they know everything
> CCIE #3723 are a great annoyance to those of us who do."
> K5SSS --Isaac Asimov
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Jo]

A few years ago it was meant as a way to comply with the PT v2 scheme. For
me a nice side effect is/was that JOSM assigns a platform role
automatically when adding them to route and stop_area relations. But it
wouldn't be hard to reprogram it to do that for simply
highway=bus_stop/railway=tram_stop.

Dropping the public_transport tags on stops is covered by Ilya's proposal
though. I'm somewhat indifferent to whether we do or don't drop those tags.

My proposal is mostly about not adding 2 objects to the route relations for
each stop and to keep all the stop's details together on that one object
that is added to the route relations, preferably a node.

Polyglot

2018-04-13 19:48 GMT+02:00 Selfish Seahorse :

> On 11 April 2018 at 19:38, Roland Hieber  wrote:
> > However, a main reason why the Public Transport schema was adopted [1]
> > was exactly this differentiation between stop position on the route and
> > platform position/waiting area for the passengers.  This was done to
> > increase the expressiveness of OpenStreeMap data, and to make
> > information more easier obtainable for routing software.  After all, the
> > two things are at different positions, and you cannot generally infer
> > the one from the other.  Reverting to the old schema would therefore
> > take away that expressiveness.
> >
> > [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport#Goal_of_this_public_transport_proposal
>
> If the waiting area is mapped as a node, it can be projected on the
> road or rail, thus making a separate stop position node on the road or
> rail unnecessary.
>
> However, I think it is not very straightforward that this node is
> proposed to be tagged public_transport=platform and a possible
> physical platform highway=platform. In my opinion, tagging the waiting
> area node only highway=bus_stop or railway=tram_stop would be much
> less confusing. Besides these tags are self-explanatory. (And, as you
> wrote, these tags will probably remain needed for rendering purposes
> for a long time to come. Why double tagging then?)
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Jo]

Mapping stop_position nodes is just fine. I would simply not add them to
the route relations.

Mapping platforms as ways or areas adds enhances detail. But no need to add
them to the route relations.

The proposal is about having 1 object to represent the stops for its whole
lifetime and nodes happen to be the most suitable kind of object for this.

Add all the pertinent details to this object and only add this object to
the route relations, once each time the vehicle serves it for that
particular itinerary variation. (route relation)

I've been using this scheme in Belgium, a country with 3-4 PT operators for
several years now and it works really well. I knew it was going to be hard
to propose a change, that for some is somewhat radical.

It does not mean that we're reverting back to PT "v1" though. Everything
can still be expressed in as much detail as needed or wanted. But to
enhance the detail during the lifetime of the stop, it won't be needed to
transfer tags from one object to another, or to replace objects in the
route relations.

We need a scheme that is easy to maintain by anybody and what I see
happening in Germany mostly, but also elsewhere around Europe, based on
what is described in the wiki is overly complex, thus making it only for
"experts", and we don't have enough of those.

Polyglot

2018-04-11 19:38 GMT+02:00 Roland Hieber <li...@rohieb.name>:

> On Mon, Apr 09, 2018 at 07:19:32PM +0200, Jo wrote:
> > Here goes my proposal for a reform in mapping public transport:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport_map_all_stops_as_nodes
> [...]
>
> As I understand it, in Public Transport schema speech, this proposal
> comes down to removing all public_transport=stop_position nodes (i.e.
> the position where a train/bus/… stops on the street) from the route
> relations, and retaining the public_transport=platform information
> (i.e. where the passengers wait or where the station pole is located).
> This would be effectively reverting part of the Public Transport schema,
> and going back to the way platforms were mapped previously.
>
> However, a main reason why the Public Transport schema was adopted [1]
> was exactly this differentiation between stop position on the route and
> platform position/waiting area for the passengers.  This was done to
> increase the expressiveness of OpenStreeMap data, and to make
> information more easier obtainable for routing software.  After all, the
> two things are at different positions, and you cannot generally infer
> the one from the other.  Reverting to the old schema would therefore
> take away that expressiveness.
>
> [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport#Goal_of_this_public_transport_proposal
>
> Furthermore, quoting from the proposal:
>
> > Rationale
> >
> > - nodes are convenient to work with and move, if needed, also using
> >   mobile apps
>
> This is true, but per the Public Transport schema you can already map
> both public_transport=stop_position and public_transport=platform as
> single nodes.  Your additional argument that both a node and a way could
> be added for the platform would not lead to more expressiveness, but
> only to more duplication of data.  (As simple as possible, as complex as
> necessary.)
>
> > - nodes have coordinates directly, no extra calculation required
> > - nodes are easy to work with using MapCSS, [...]
>
> See above.  Also, every way consists of nodes, which have a coordinates.
> Just take any.
>
> > - making comparison of location and tags with external sources is
> >   straightforward
>
> I don't know how this is meant, but the complexity of tag extraction
> from objects will be the same whether they are mapped on a node or
> mapped on a way.  Also the main work here is probably to match the
> external database schema to the OpenStreetMap data schema, as they will
> most probably not be very similar.
>
> That's all I can think of for now.
>
>  - Roland
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Jo]

2018-04-10 16:23 GMT+02:00 Stephen Sprunk :

> But for the thousands of platform ways/areas that do already exist, you're
> proposing that someone has to go back and add nodes, move all the tags
> over, change which is the relation member, etc.?  That's not very friendly.
>
You can rest assured that if the proposal happens to make it, I'll make
sure there are tools to help with that conversion. Compared to the
thousands upon thousands of stops and route relations that still need to be
mapped, their number is relatively small.

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Jo]

The proposal doesn't say that it's not possible to map the actual platforms
as ways or areas in ADDITION to that node, if they are actually present.

What it says is that it's not necessary to transfer all the details from
the node to the way/area and replace the node in the route relations.

The node REPRESENTING the stop keeps fulfilling this function for the
lifetime of the stop's 'existence'.

Jo



2018-04-10 2:43 GMT+02:00 Bill Ricker <bill.n1...@gmail.com>:

> On Mon, Apr 9, 2018 at 1:19 PM, Jo <winfi...@gmail.com> wrote:
> > Here goes my proposal for a reform in mapping public transport:
>
> [nodes not platforms]
>
> If this applies to Heavy Rail and Light Rail rapid transit and not
> just Bus Stops, I object.
>
> The Transport layer on OpenStreetMap is much more useful at high zoom
> levels with Platform entities in the DB than it would be without them.
>
> From
> https://www.openstreetmap.org/query?lat=42.34752=-71.
> 09989#map=18/42.34678/-71.09936=T
> one can see that the two lines do NOT share a platform so that one can
> not change directions with a wheelchair without taking two elevators,
> either of which may be out of service; but if there was only one
> platform between two lines, one could.
> THIS IS USEFUL TO MAP.
>
> I support simplicity, but agree with Einstein: Things should be as
> simple as possible, but not simpler. This proposal goes too far.
>
>
> --
> Bill Ricker
> bill.n1...@gmail.com
> https://www.linkedin.com/in/n1vux
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Uploading public transport data on OSM

[Jo]

That is why I think it's important not to go with ref:gtfs, but use
ref:operator1, ref:operator2. Where operator1 and operator2 are the names
or short names for the different operators. In many cases you'll find that
these refs are also what the public sees on the stops (if the operators
decide to put it there) or in internet urls when using the operator's
website.

Here in Belgium, we have 3 operators extending into the other operator's
mostly served area and some lines extend into neighbouring countries, so we
had to namespace the ref tag a few years ago, already.

Polyglot

2018-01-16 22:07 GMT+01:00 Stephen Sprunk <step...@sprunk.org>:

> AFAIK, the operator ID is only guaranteed to be unique within a
> single GTFS feed, but it's reasonably safe to assume they'll also be unique
> between feeds with overlapping geographical areas.  It's probably not safe
> to assume that's transitive.
>
> Where operators don't cooperate and produce a single joint feed, you'll
> inevitably face the "same" stops appearing in multiple feeds.  Imagine a
> single roadside bus stop pole with signs from two or three different bus
> operators on it, and that pole would have a different ID and probably even
> different lat/long in each feed.  Ideally, a local OSM editor would be able
> to merge them into a single stop object--and that merger would survive
> later bulk imports from all those GTFS feeds.  This would cut down on map
> clutter and allow routing apps to more easily recognize transfers, but I'm
> not sure how to design such a schema.
>
> It's been a while since I read the spec, but I think GTFS also has a
> similar concept to stop_areas, and that will probably have similar problems
> to stops.
>
> Routes appear simpler to deal with since they're unique to each operator,
> but they're inherently built on top of stops (or stop_areas), so they may
> present new problems when we get there.
>
> S
>
>
> On 2018-01-16 14:35, Jo wrote:
>
> Is there a common pattern to these GTFS IDs? Are they guaranteed to be
> unique across operators?
>
> Or is that not important and is it only important that they are stable
> between versions of GTFS files for a region?
>
> Adding a ref:gtfs tag would not be very hard to do, but I would prefer a
> scheme with ref:OPERATOR, because some stops may be served by multiple
> operators and thus be present in multiple GTFS feeds.
>
> Polyglot
>
> 2018-01-16 21:07 GMT+01:00 Stephen Sprunk <step...@sprunk.org>:
>
>> On 2018-01-16 08:30, Mike N wrote:
>>
>>> On 1/16/2018 7:37 AM, Yash Ganthe wrote:
>>>
>>>> What caught my attention is a project called Go Sync
>>>> https://wiki.openstreetmap.org/wiki/GO-Sync
>>>> The description indicates that it is for syncing GTFS with OSM. But I
>>>> am not sure what type of account is needed for that.
>>>
>>>
>>>
>>>  From what I recall, Go-Sync only synchronizes stops but not the GTFS
>>> route paths with OSM route relations.
>>>
>>>  The routing samples on the OpenStreetMap web site will not
>>> automatically give public transport trip routing because the full GTFS
>>> schedule information is not in OSM.   It would require a separate
>>> local site such as OpenTripPlanner which automatically combines full
>>> GTFS with OSM data.   There are some companies providing large scale
>>> instances of OpenTripPlanner which may cover your area.
>>
>> What I'd like to see is some sort of tag on OSM objects (stops, routes,
>> etc.) listing the GTFS ID numbers so that tools can more easily connect the
>> two; that should be easy enough if someone defines a scheme and gets the
>> few relevant tools to use it.
>>
>> The lat/long for stops in GTFS data is often questionable, so it would be
>> good to have some way for folks to be able to fix the stop locations in OSM
>> and not get overwritten by another import later.  In many places
>> (especially in the US), GTFS data will change every few months, so if we
>> want it in OSM at all, we need a scheme that can deal with regular bulk
>> imports without losing quality where local OSM editors have improved things
>> by hand.
>>
>> S
>>
>> --
>> Stephen Sprunk  "Those people who think they know everything
>> CCIE #3723 are a great annoyance to those of us who do."
>> K5SSS --Isaac Asimov
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>
> _

Re: [Talk-transit] Uploading public transport data on OSM

[Jo]

Is there a common pattern to these GTFS IDs? Are they guaranteed to be
unique across operators?

Or is that not important and is it only important that they are stable
between versions of GTFS files for a region?

Adding a ref:gtfs tag would not be very hard to do, but I would prefer a
scheme with ref:OPERATOR, because some stops may be served by multiple
operators and thus be present in multiple GTFS feeds.

Polyglot

2018-01-16 21:07 GMT+01:00 Stephen Sprunk :

> On 2018-01-16 08:30, Mike N wrote:
>
>> On 1/16/2018 7:37 AM, Yash Ganthe wrote:
>>
>>> What caught my attention is a project called Go Sync
>>> https://wiki.openstreetmap.org/wiki/GO-Sync
>>> The description indicates that it is for syncing GTFS with OSM. But I am
>>> not sure what type of account is needed for that.
>>>
>>
>>
>>  From what I recall, Go-Sync only synchronizes stops but not the GTFS
>> route paths with OSM route relations.
>>
>>  The routing samples on the OpenStreetMap web site will not
>> automatically give public transport trip routing because the full GTFS
>> schedule information is not in OSM.   It would require a separate
>> local site such as OpenTripPlanner which automatically combines full
>> GTFS with OSM data.   There are some companies providing large scale
>> instances of OpenTripPlanner which may cover your area.
>>
>
> What I'd like to see is some sort of tag on OSM objects (stops, routes,
> etc.) listing the GTFS ID numbers so that tools can more easily connect the
> two; that should be easy enough if someone defines a scheme and gets the
> few relevant tools to use it.
>
> The lat/long for stops in GTFS data is often questionable, so it would be
> good to have some way for folks to be able to fix the stop locations in OSM
> and not get overwritten by another import later.  In many places
> (especially in the US), GTFS data will change every few months, so if we
> want it in OSM at all, we need a scheme that can deal with regular bulk
> imports without losing quality where local OSM editors have improved things
> by hand.
>
> S
>
> --
> Stephen Sprunk  "Those people who think they know everything
> CCIE #3723 are a great annoyance to those of us who do."
> K5SSS --Isaac Asimov
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Uploading public transport data on OSM

[Jo]

Hi, the very first question that comes to mind is: is it under a suitable
license, or can you get explicit permission from the operator to contribute
it to OpenStreetMap?

The next issue is that there is no direct way to add GTFS to OSM. stops.txt
can be converted to nodes for the stops, but the other files need to be
processed to generate route relations containing lists of these stops.

Sometimes there are shape files in GTFS, if that permission is granted
these can be used as guides to know where the buses pass, but converting
them to something useful in OSM (route and route_master) relations is very
involved.

I'm proposing a project for GSoC (Google Summer of Code) to create a web
interface to help with such conversion and followup on its progress, so if
you know students who know Python, Django and PostGIS, let them contact me.

Polyglot

2018-01-16 12:44 GMT+01:00 Yash Ganthe :

> Hi,
>
> If I have a GTFS data of my agency, can I upload it to OSM? Do I need to
> convert it to any other format before uploading? Do I need to create a
> special account in OSM to be able to upload the data? Will it start showing
> the public transport options on the map similar to Google Maps?
>
> Regards,
> Yash
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] Hangouts on Air Screencast on public transport

[Jo]

Hi,

I'd like to regularly do Webinar meetings on mapping public transport
mapping in OpenStreetmap using JOSM.

The first one will be at 8pm CEST next Tuesday:

https://www.youtube.com/watch?v=XTiiR7tjpcU

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] Google Summer of Code 2017 JOSM PT_Assistant plugin

[Jo]

Giacomo Servadei was accepted  for continuing development on the JOSM
PT_Assistant plugin. Darya Golovko started to work on this plugin last
year  and she succeeded in making the mapping and correcting of public
transport route relations a lot more convenient and efficient. She will be
co-mentoring the project this year. Michael Zangl will help by doing review
of the Java code, even though he is mentoring another JOSM related GSoC
project.

I'm not entirely sure if it's wise to cross post this message (so sorry if
it wasn't)

* To the JOSM-dev mailing list: please welcome Giacomo. He may have some
questions for you along the way. And maybe some of you want to help out by
looking at the code too.

* To the public_transport mailing list:

https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/PT_Assistant_Plugin

The above is what I have in mind to work on this year. Maybe you see things
I missed, or you want to help with beta testing. Please let me know. If the
plugin has issues, don't hesitate to create tickets on JOSM's bug tracker (
http://josm.openstreetmap.de/newticket)

I'm prepared to do Hangout sessions to discuss mapping of public transport
in OpenStreetMap.

I also want to extend the scope of the plugin, so  it works for hiking and
cycling route relations. The semantics are a bit different than public
transport version 2 route relations, but a lot of what is in the plugin can
be reused for those itineraries.

Due to how GSoC works, it may take until the end of June before we start
seeing results. During the month of May we are mostly doing preparation
during the community bonding period.

The plugin is already available to work with in JOSM though. And it is
already very useful for detecting problems and fixing some of them. So
please try it and give us some feedback.

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naming concepts

[Jo]

2016-10-30 21:27 GMT+01:00 Greg Troxel :

>
> Felix Delattre  writes:
>
> > There are different concepts of routes in OpenStreetMap and GTFS.
> > Sometimes they are not existent or ambiguous.
>
> I am a native speaker of en_US.
>
> > 1. A general public transport service (e.g. No. 38):
> > In OSM: "route_master" in GTFS: "route"
>
> I find route_master to be an odd term, and very much computer jargon vs
> human language.
>

For me that is a line. It has a line number. (which sometimes is not simply
numeric, so it's more of a symbol, but OK)

>
> > 2. A theoretical tour a bus takes, but without schedule information, it
> > represents one each for different direction, but also if one is shorter
> > than the other
> > In OSM: "route"; in GTFS: /not existent/
>
> I would call this a bus route.  Around me, it would have a number, and a
> set of stops.   Then there would be a schedule for the bus route that
> says what time the bus starts from each end and the time for at least
> some of the intermediate stops.   So I find the use of the word route in
> OSM natural.  It also parallels the use of route for a road, which is a
> sequence of ways, but without timing.
>

I would call those itinerary. If OSM had started out with that term, we
wouldn't have the ambiguity today. But route is used for foot/bicycle/horse
and PT itineraries. For PT I resorted to call them route variations, but
they are 'represented' by route relations in OSM.


> > 3. An actual tour a bus takes, on a certain time
> > In OSM" not existen; in GTFS: "trip"
>
> It makes sense to use "trip" in GTFS, and it makes sense that this is
> not in OSM because we don't represent that level of information.
>

Indeed. If we could figure out a way to represent it anyway, I think it
would be a plus. But I won't be holding my breath.


>
> > Route: Is used for different concepts (I guess because of British and
> > American English)
>
> I don't think it's en_GB vs en_US.  I've recently driven in Scotland and
> about 10 years ago in Ireland, and didn't find route to mean something
> significantly differently.  In the US, we use it as part of the name of
> a numbered highway, e.g. "Route 2" is a state highway that goes for
> about 200 miles.  It is signed the whole way and you change road name
> often, but you follow that sequence of roads to get from Boston to the
> New York border, more or less.  Perhaps that isn't used that way in the
> UK, but the notion of "bus route" seemed similar to me.
>
> > Routemaster:  Is a very technical term. I thinks, it's not
> > understandable when looking at it naively (isn't this the bus driver?)
>
> Agreed.  This is a defined term that doesn't mean anything to native
> speakers without reading the definition.
>
> Absent a definition, I wouldn't expect it to mean the driver.   I would
> expect it to mean the official at the transit organization or bus
> company that has the authority to decide what streets that route will go
> on (and can change the set of stops).
>

I'm sure whoever came up with the term wanted to make sure it had route in
the name, as it's grouping a bunch of route relations. For me this is the
'line'. Service line definitely doesn't sound very English to me. (But I'm
not a native speaker either). PT line, maybe?

>
> > It call them 1: Service Line; 2. Route Variant 3: Trip
> >
> > English native speakers, please help: Does this make sense to you? Would
> > you suggest other terms for the concepts to be even more understandable?
>
> Service line and variant don't give me the right idea.  But on really
> thinking I can see where you are coming from.
>
> My basic thoughts are to give the right impression and to align with
> GTFS.
>
> Your #1 I am not 100% sure what it is.  If it's essentially the string
> "Route 38" and doesn't contain information about where, then I would
> call it "route name".
>
> Your #2: I would use route to represent the set of stops and the choice
> of roads, and would expect this to be a pair for the two directions
> (usually; a route could be circular and not bidirectional).  I find it
> funny that GTFS doesn't have this, as the theory of putting databases in
> normal form would lead to representing the set of stops and then having
> sets of times.  However, I can see that this wouldn't quite work.  There
> are train routes near me where some trains skip some of the smaller
> stops.  So here I would expect the "route" to be a set of stops that
> might be made, and the "trip" to sometimes omit some stops.
>
> I do find "trip" to be pretty close to intuitive, although there is
> ambiguity about whether it is a scheduled trip that repeats on multiple
> days, or an actual single trip that happened.   That is not bothersome
> though.
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>

Re: [Talk-transit] Public Transport Mapping Party (3. Sep. 10:30h in Bremen, Germany)

[Jo]

Hi Raffael,

I hope you are aware of the public transport plugin for JOSM created by
Darya Golovko, as part of GSoC.

http://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant

2016-08-30 7:05 GMT+02:00 Rittmeier, Raffael :

> Hello everyone.
>
> The OpenStreetMap User Group Bremen invites you to our public transport
> mapping party (it will most likely be in German :-). You find more
> information at http://osm-bremen.de or at the wiki.
>
> We will have two presentations and a practical part that requires some
> knowledge editing OSM (we will be using jOSM).
>
> Do you have any suggestions regarding "must haves", topics that are
> important and should be mentioned?
>
> Cheers
> Raffael
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Bus routes forward/backward

[Jo]

Hi Hans,

Yes, that describes version 2. It's the currently used version, so version
1 route relations should be converted to several version 2 route relations,
one for each variant of the line.

There are a few things I don't agree with on that wiki page, like including
all the stop_positions to each and every route relation. I prefer to keep
things simple and only add all the platform nodes in the correct order to
the route relations. (This doesn't work in places where the details for the
stops are being added to the stop_position nodes).

Relating stop_positions to platforms (and shelters, waste_baskets, benches)
is better done using stop_area relations. But there too, my preference is
to create one such stop_area relation per direction of travel. If it's  not
done that way, those stop_area relations don't fulfill the purpose I have
for them, which is to relate platform nodes to corresponding ways via the
stop_position nodes.

Since life is too short, we need a scheme that is as simple as possible and
we need automation. I'm taking care of the second part. Of course, we make
sure that it works with whatever scheme people want to use. It's mostly
designed to fix problems with routing, making sure they are continuous,
don't travel against one way traffic or over unsuitable highways/railways.

Polyglot


2016-07-11 10:45 GMT+04:00 Hans De Kryger <hans.dekryge...@gmail.com>:

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route
>
> Is version 2?
>
> *Regards,*
>
> *Hans*
>
> On Sun, Jul 10, 2016 at 11:42 PM, Hans De Kryger <
> hans.dekryge...@gmail.com> wrote:
>
>> Thanks Jo,
>>
>> Is there agreement on the forward/backward roles in PT2? By that i mean
>> completely phasing them out. Or is it still an open discussion?​ I won't
>> add them anymore if the point is to phase them out.
>>
>> *Regards,*
>>
>> *Hans*
>>
>> On Sun, Jul 10, 2016 at 11:26 PM, Jo <winfi...@gmail.com> wrote:
>>
>>> Hi Hans,
>>>
>>> The semantics depend on public_transport:version.
>>>
>>> If 1 then yes.
>>> If 2 there should be no forward/backward roles anymore.
>>>
>>> Instead you add an ordered sequence of ways that is continuous.
>>>
>>> If you want a demo of how to map PT, we can do a hangout.
>>>
>>> Also, have a look at this:
>>> http://www.openstreetmap.org/user/Polyglot/diary/38980#comment35201
>>>
>>> Mapping public transport should become a lot more convenient by the time
>>> that GSoC project finishes.
>>>
>>> Polyglot
>>>
>>> 2016-07-11 10:08 GMT+04:00 Hans De Kryger <hans.dekryge...@gmail.com>:
>>>
>>>> If i remove the forward/backward tag on a section of a way (part of the
>>>> bus route) does that signify the bus goes both ways?
>>>>
>>>> *Regards,*
>>>>
>>>> *Hans*
>>>>
>>>> ___
>>>> Tagging mailing list
>>>> tagg...@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>>>
>>>
>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>>
>>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] GTFS, tools and pt tags generally

[Jo]

Darya (a GsoC student) is actually working on a project to help with the
routing. We haven't included conversion from GTFS and I'm not sure there
will be time for that. What's most time consuming, especially because of
changes/breakings caused by other mappers and PT itineraries subject to
change, is to keep the routing up to date and that's what the new plugin
aims to solve.

At the moment it hooks mostly into the validator (so less routes would be
broken due to other changes made to the geometry of the ways), but it's
still work in progress.

If you like, you can help with beta testing, of course. It does already
help with routes going against one way traffic flows.

It's called PT_assistant.

Polyglot

2016-06-25 6:54 GMT+02:00 Roland Olbricht :

> I'm sorry if I was unclear.  I didn't mean that one person should just
>> blindly dump every GTFS feed into OSM and leave it to others to clean
>> up.  I was thinking of something that an individual mapper could use to
>> import the feed(s) in their particular area and resolve conflicts or
>> errors before uploading, e.g. in JOSM.
>>
>
> Thank you for the clarification. Yes, I would agree to that. I could image
> to let a JOSM plugin produce a layer of coordinates from the GTFS stop data.
>
> There could as well be a feature to do routing along the sequence of stops
> that are provided with GTFS data.
>
> Perhaps it's different in Rightpondia, but here in Leftpondia, it's
>> common to see major (sometimes network-wide) changes to routes and
>> schedules every 3-6 months.
>>
>
> Thank you. This is indeed an important disctinction. Here, bus services
> are stable always at least a year, usually five to ten years and sometimes
> for decades. Services on rails are usually even more stable.
>
> For example, my ancient home town Wuppertal introduced a new bus network
> in 1994 and is mostly offering the same service right now.
>
> Best regards,
>
> Roland
>
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] different interpretations of v2 PT scheme

[Jo]

Scenario:

I have data from 'upstream'.
This data relates to public_transport=platform nodes next to the way

What I need now, is to figure out which nearby way 'belongs' to this
'platform'.

If there is a stop_area relation, this is easy (as long as there is a
stop_area relation which contains a platform and a stop_position pair).

(Note that there are also stops where several buses can stop one after
another, so it's not impossible to have more than 1 stop_position for a
single platform)

The opposite is also possible, but less likely to be needed.

It is true that there are many cases where the relation between platform
and stop_area can be made unambiguously based on proximity. Note that I'm
doing this in JOSM not in a geographically enabled database.

There are also times that a stop_position is not needed to get from a
platform to the candidate way that needs to be added to the route
relation.

Anyway, I wouldn't try to abolish stop_area relations, but rather make sure
that SA relations can be grouped together into stop_area_group relations.
This makes sense for bus stations where the separate stop_area relations
will have names with numbers or letters after them.

Jo

2015-07-02 15:52 GMT+02:00 Janko Mihelić jan...@gmail.com:

 If you are adding stop_areas, then there certainly have to be two of them,
 one on each side. One of them is put in the route that goes one way, the
 other one is put in the other way. I'm also pretty sure that the
 stop_area_group is not needed. If they are near each other, then it's a
 group. But to someone near each other means within 400m, to someone in a
 wheelchair it means ramps, to a blind person it means traffic lights with
 sound. What else can a group achieve that spatial placement can't? Maybe if
 a group has a ref.

 After all this, I'm not sure that stop_area is absolutely necessary.
 Stop_position and platform are nearby, so there is really not that much
 chance an algorithm is going to connect the wrong ones. If it was me, I
 would just add all the refs to the platform, like you did, and ignore all
 the refs on the stop_position. Job done, no relations needed.

 čet, 2. srp 2015. u 00:54 Jo winfi...@gmail.com napisao je:

 I tend to add the waste_basket that clearly 'belongs' to the bus stop,
 the bench, the shelter, the ticker/departures screen in as well. Most of
 the time they have a style you don't see elsewhere. Never occurred to me to
 add toilets or flowers or pubs though.

 But do we agree a stop_area relation is needed for each side of a street?
 and a stop_area_group to show that they belong together?

 Jo



 2015-07-02 0:31 GMT+02:00 Janko Mihelić jan...@gmail.com:

 To me it's logical to put all those ref, network and operator tags in
 the stop_area relation, not on the nodes or ways. The relation is the only
 element that describes the bus stop completely. If you only put the ref and
 operator on the platform, the stop position is missing.

 But if mappers in a city agree that they don't need stop_area relations,
 they can put ref and operator tags on platforms, or stop_areas. I think
 this can be reasonably flexible, but only between networks, or countries.

 Also, putting waste_baskets, benches, flowers, toilets, cafes and other
 things in the stop area relation is unnecessary. Who decides if a cafe is
 near enough to be in a stop_area? What do they have to do with public
 transport? Only the stop_position and platform are needed. But I'm not
 going to remove those from a stop_area relation, they don't hurt.

 sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com napisao je:

 What I'm doing comes down to mapping the poles. stop_positions could be
 shared for stops that are exactly across one another.

 I guess there is no choice but to rewrite the script(s) in order to
 cope with all variations of possible ways to map. Or else simply give up on
 it and move on. Not sure which I will choose.

 It would be nicer if we were able to come up with a totally consistent
 version 3 of mapping PT, but what I see, is we're moving in different
 directions. What is logical to me, apparently isn't for the rest of the
 world. What I do know is that I'm not going to be spending the next 2 years
 to make sure all the stop_positions (5 for a small country) are
 present. They're simply not important enough for that. I add them here and
 there and consistently for the terminal stops.

 What I want to focus on at the moment is to get all the itineraries in
 , the routes and their variations. To me that seems like a better use of my
 time.

 Polyglot

 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com:

 I am the mapper. I use the processing to assist me, like a tool. I
 also try to map them all in the same way for consistency. The problem is
 that apparently there was still room for interpretation in the 'version 2'
 of the public transport scheme.

 What I see happening in Germany is that information is duplicated
 needlessly. Moving it to the stop_area relation

Re: [Talk-transit] different interpretations of v2 PT scheme

[Jo]

2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com:

 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com:

 In retrospect public_transport=platform was a misnomer. Maybe we should
 have used public_transport=pole.

 A platform can be a pole, or a shelter, or a dock, or a boarding
 platform for a train... It is meant to abstract differences between
 different means of transport.


That's why I tought I was doing all right putting the details of the stop
on those public_transport=platform mapped as nodes. When there is an actual
platform, I map it separately as a way or an area, which goes into the
stop_area relation.


 Anyway, the attempt to clear up the distinction between mapping stops next
 to the road and as a node on the road has failed utterly, now all seems to
 be done twice, which is a total waste of time.

 The stop_position is where the bus, train, etc. stop on their way, while
 the platform is where passengers will be waiting to board. Both features
 are distinct and serve different purposes in real life, so why not store
 both in OSM ?


I don't mind having both. I do mind putting extra tags like name, ref,
operator, network, route_ref, zone on the stop_position nodes. It's enough
to have that information once.



 My problem is that when I'm adding stops as nodes in Germany and put the
 details on there, those nodes get cleared/removed. I can reinstate them,
 but it won't stick, so it's futile to do so.

 It seems to be more a problem with toxic mappers more than the PT scheme


They moved the details to the stop_position, which I don't consider for
processing.



 At some point I thought that starting to include the platform ways to the
 background database would help, but that's not the case if the details are
 mapped on the stop_position nodes.

 In theory, redundant details on the same stop should be put in the
 stop_area relation in order to reduce redundancy.


That only works if there is one stop_area relation per direction of travel.
At the moment the wiki states to use a stop_area relation for all PT
related stuff that is near to each other. I need to relate the platform
nodes to the nearby way, sometimes by means of a stop_position node,
sometimes with help of a stop_area relation.


 The stop_area relations combine both directions, That's useless. I don't
 know who abolished stop_area_group, But what good are these stop_area
 relations if they don't help to relate an individual platform with a
 stop_position?

 See above.

 Éric


 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] different interpretations of v2 PT scheme

[Jo]

I am the mapper. I use the processing to assist me, like a tool. I also try
to map them all in the same way for consistency. The problem is that
apparently there was still room for interpretation in the 'version 2' of
the public transport scheme.

What I see happening in Germany is that information is duplicated
needlessly. Moving it to the stop_area relation would be a logical step,
but information doesn't cascade through like that in OSM. In Belgium every
stop has its own ref, and of course if you calculate a route_ref from the
schedules this will not always yield the same result for both sides of a
street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann richard.mann.westoxf...@gmail.com:

 Your processing needs to be able to cope with these situations, using the
 latlon of the features, if the relationships aren't explicit. Get the
 computer to do the work, not the mappers.

 Richard

 On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com wrote:

 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com:

 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com:

 In retrospect public_transport=platform was a misnomer. Maybe we should
 have used public_transport=pole.

 A platform can be a pole, or a shelter, or a dock, or a boarding
 platform for a train... It is meant to abstract differences between
 different means of transport.


 That's why I tought I was doing all right putting the details of the stop
 on those public_transport=platform mapped as nodes. When there is an actual
 platform, I map it separately as a way or an area, which goes into the
 stop_area relation.


 Anyway, the attempt to clear up the distinction between mapping stops
 next to the road and as a node on the road has failed utterly, now all
 seems to be done twice, which is a total waste of time.

 The stop_position is where the bus, train, etc. stop on their way, while
 the platform is where passengers will be waiting to board. Both features
 are distinct and serve different purposes in real life, so why not store
 both in OSM ?


 I don't mind having both. I do mind putting extra tags like name, ref,
 operator, network, route_ref, zone on the stop_position nodes. It's enough
 to have that information once.



 My problem is that when I'm adding stops as nodes in Germany and put
 the details on there, those nodes get cleared/removed. I can reinstate
 them, but it won't stick, so it's futile to do so.

 It seems to be more a problem with toxic mappers more than the PT scheme


 They moved the details to the stop_position, which I don't consider for
 processing.



 At some point I thought that starting to include the platform ways to
 the background database would help, but that's not the case if the details
 are mapped on the stop_position nodes.

 In theory, redundant details on the same stop should be put in the
 stop_area relation in order to reduce redundancy.


 That only works if there is one stop_area relation per direction of
 travel. At the moment the wiki states to use a stop_area relation for all
 PT related stuff that is near to each other. I need to relate the platform
 nodes to the nearby way, sometimes by means of a stop_position node,
 sometimes with help of a stop_area relation.


 The stop_area relations combine both directions, That's useless. I don't
 know who abolished stop_area_group, But what good are these stop_area
 relations if they don't help to relate an individual platform with a
 stop_position?

 See above.

 Éric


 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] different interpretations of v2 PT scheme

[Jo]

I tend to add the waste_basket that clearly 'belongs' to the bus stop, the
bench, the shelter, the ticker/departures screen in as well. Most of the
time they have a style you don't see elsewhere. Never occurred to me to add
toilets or flowers or pubs though.

But do we agree a stop_area relation is needed for each side of a street?
and a stop_area_group to show that they belong together?

Jo



2015-07-02 0:31 GMT+02:00 Janko Mihelić jan...@gmail.com:

 To me it's logical to put all those ref, network and operator tags in the
 stop_area relation, not on the nodes or ways. The relation is the only
 element that describes the bus stop completely. If you only put the ref and
 operator on the platform, the stop position is missing.

 But if mappers in a city agree that they don't need stop_area relations,
 they can put ref and operator tags on platforms, or stop_areas. I think
 this can be reasonably flexible, but only between networks, or countries.

 Also, putting waste_baskets, benches, flowers, toilets, cafes and other
 things in the stop area relation is unnecessary. Who decides if a cafe is
 near enough to be in a stop_area? What do they have to do with public
 transport? Only the stop_position and platform are needed. But I'm not
 going to remove those from a stop_area relation, they don't hurt.

 sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com napisao je:

 What I'm doing comes down to mapping the poles. stop_positions could be
 shared for stops that are exactly across one another.

 I guess there is no choice but to rewrite the script(s) in order to cope
 with all variations of possible ways to map. Or else simply give up on it
 and move on. Not sure which I will choose.

 It would be nicer if we were able to come up with a totally consistent
 version 3 of mapping PT, but what I see, is we're moving in different
 directions. What is logical to me, apparently isn't for the rest of the
 world. What I do know is that I'm not going to be spending the next 2 years
 to make sure all the stop_positions (5 for a small country) are
 present. They're simply not important enough for that. I add them here and
 there and consistently for the terminal stops.

 What I want to focus on at the moment is to get all the itineraries in ,
 the routes and their variations. To me that seems like a better use of my
 time.

 Polyglot

 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com:

 I am the mapper. I use the processing to assist me, like a tool. I also
 try to map them all in the same way for consistency. The problem is that
 apparently there was still room for interpretation in the 'version 2' of
 the public transport scheme.

 What I see happening in Germany is that information is duplicated
 needlessly. Moving it to the stop_area relation would be a logical step,
 but information doesn't cascade through like that in OSM. In Belgium every
 stop has its own ref, and of course if you calculate a route_ref from the
 schedules this will not always yield the same result for both sides of a
 street.

 Jo



 2015-07-01 11:43 GMT+02:00 Richard Mann 
 richard.mann.westoxf...@gmail.com:

 Your processing needs to be able to cope with these situations, using
 the latlon of the features, if the relationships aren't explicit. Get the
 computer to do the work, not the mappers.

 Richard

 On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com wrote:

 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com:

 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com:

 In retrospect public_transport=platform was a misnomer. Maybe we
 should have used public_transport=pole.

 A platform can be a pole, or a shelter, or a dock, or a boarding
 platform for a train... It is meant to abstract differences between
 different means of transport.


 That's why I tought I was doing all right putting the details of the
 stop on those public_transport=platform mapped as nodes. When there is an
 actual platform, I map it separately as a way or an area, which goes into
 the stop_area relation.


 Anyway, the attempt to clear up the distinction between mapping stops
 next to the road and as a node on the road has failed utterly, now all
 seems to be done twice, which is a total waste of time.

 The stop_position is where the bus, train, etc. stop on their way,
 while the platform is where passengers will be waiting to board. Both
 features are distinct and serve different purposes in real life, so why 
 not
 store both in OSM ?


 I don't mind having both. I do mind putting extra tags like name, ref,
 operator, network, route_ref, zone on the stop_position nodes. It's enough
 to have that information once.



 My problem is that when I'm adding stops as nodes in Germany and put
 the details on there, those nodes get cleared/removed. I can reinstate
 them, but it won't stick, so it's futile to do so.

 It seems to be more a problem with toxic mappers more than the PT
 scheme


 They moved the details to the stop_position, which I don't consider

[Talk-transit] validator rule for public_transport=platform

[Jo]

Hi,

I'm getting messages from the validator claiming public_transport=platform
can only be used on way or closed_way. This is not true. It can be used
perfectly well on nodes. In that case the node represents the position of
the pole. I just checked it on the wiki.

http://wiki.openstreetmap.org/wiki/Buses

All the poles of Belgian transport companies De Lijn, TEC and MIVB/STIB are
mapped on nodes. If there is a platform, it is mapped, but that doesn't
replace the pole, nor does it get added to the route relations. All the
extra details like name, ref, route_ref etc also remain on the node
representing the pole. The platform ways and the stop_positions are
optional. Nice to have, but not at all crucial. The NODES with

highway=bus_stop
public_transport=platform
bus=yes

railway=tram_stop
public_transport=platform
tram=yes

are what define the bus/tram stops over here and those get the details and
those get added to the route relations.

So please correct the validator rule.

Kind regards,

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] validator rule for public_transport=platform

[Jo]

That's how it was added to the wiki ages ago. Since the start of the 'new'
schema.

The alternative is to add a new object public_transport=pole and a new role
for the routes. This was not deemed necessary back then though.

I must say I don't agree with adding the details of the bus stop to the
platform ways, but I cannot control how things are evolving in Germany and
to a lesser extent in France. All I can do is make sure it's standardized
across all Belgian transport companies.

Polyglot

2015-05-07 11:18 GMT+02:00 michael spreng mailingl...@osm.datendelphin.net
:

 Hi

 On 2015-05-07 10:13, Jo wrote:


 I'm getting messages from the validator claiming public_transport=platform
 can only be used on way or closed_way. This is not true. It can be used
 perfectly well on nodes. In that case the node represents the position of
 the pole.


 A platform is not a pole...

  I just checked it on the wiki.


 The public transport schema has a lot of history, I don't know if I want
 to trust the wiki on that.

  highway=bus_stop
 public_transport=platform
 bus=yes


 I would rather drop the public_transport=platform for poles. I agree that
 highway is misleading. But do we really need to additionally explain that
 a platfrom is a pole?

 Kind regards
 Michael

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] validator rule for public_transport=platform

[Jo]

There is a reason why we are keeping the nodes representing the poles. They
have all the details since the beginning and we need them to keep track of
changes coming in from the PT operators upstream.

It's also easier to keep track of the history of that particular bus stop.
Moving from node to way breaks the continuity of the history. There is no
practical way to know what (deleted) node the new platform way was based on.

Polyglot



2015-05-07 11:26 GMT+02:00 Nounours77 kuessemondtaegl...@gmail.com:

 
  On 2015-05-07 10:13, Jo wrote:
  I'm getting messages from the validator claiming
 public_transport=platform
  can only be used on way or closed_way. This is not true. It can be used
  perfectly well on nodes. In that case the node represents the position
 of
  the pole.
 
  A platform is not a pole…
 

 It is also common practice in Switzerland to map poles with
 public_transport=platform. In difference to what jo writes, we normally
 do not have BOTH, poles and plateform. If the platform is mapped, the
 properties of the pole are then transfered to the platform, and the pole
 node removed.

 nounours77



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Mapping bus routes with doglegs and loops

[Jo]

Hi Paul,

How do passengers know where to go and stand if there are no physical
markers? I think a bus stop should be able to be defined by the fact the
driver knows where to halt and the passengers know where to wait. Isn't
that 'convention' also some sort of ground truth? Im sure this case
happens in many countries around the world, although in some of those
countries it may be the case a bus can be flagged at any point on its
itinerary. Of course, as soon as roads become busier, that's not
possible/practical anymore.

I've been working a few years adding almost 7 stops for a small
country. That was a lot of work, of course. But now I notice that adding
and maintaining the routes is even more work, hence the creation of the
script to automate the process where possible.

One of the problems I faced is that when I needed to fix a route, I had to
apply the same fix to all the variations of that route, over and over
again. Now I do it once, creating a 'golden  route', then letting the
script take care of the others. It's still some work, as I need to check
manually if the code got it right, route by route.

Concerning the roles, I guess they may help JOSM and iD when people split
ways, although I think JOSM gets that right without them already. A bigger
problem is people joining ways, which results in stumps that are not
connected to the next way anymore. And of course, deleting ways,
potentially replacing them by new ones.

Jo





2015-02-22 6:10 GMT+01:00 Paul Johnson ba...@ursamundi.org:

 On Sat, Feb 21, 2015 at 3:48 PM, Jo winfi...@gmail.com wrote:

 Hi Paul,

 I see what you mean now. I dropped the forward/backward roles on the ways
 a few years ago. Recently I thought that they should be a help for the
 sorting algorithm, but your example proves they aren't.


 Well, they do help for sorting out which way a route should be going and
 in which order to some extent.  Though I'm starting to wish we had a way to
 number the sequence.  Role wouldn't do it since we still need forward and
 backwards...


 I've been developing a script, which tries to use other good relations to
 fix the one it's currently run on.

 For that script to be able to work, you'd need the stops in the correct
 order though.

 It works like this:

 For a sequence of stops it tries to find other relations which have the
 same sequence. The other relation with the longest sequence in common
 'wins'.

 Then it finds the ways adjacent to the stops on each end of the sequence,
 then uses the sequence of ways that connects the stops.

 We can work that way, because we have received the stops and the
 timetables from the operators, but it's the opposite of what you start
 with, when you have to get on the
 bus to create a GPX to get an idea about one the variation routes of a
 line. (After that you'd use the unstable plugin to add the stops that are
 already mapped).


 Well, the GPX would gather the itinerary.  I still need to go back through
 and doublecheck about 1600 stops, since there's a very high number of stops
 that aren't signed in any way, shape or form that Code for America Tulsa
 received from Tulsa Transit.  And, as far as I'm aware, we expect some kind
 of permanently fixed marker recognizable as such to be able to map it as a
 bus stop.  If we *do* have some way to tag this situation despite a lack
 of ground truth in the physical sense, then, by all means, someone please
 let me know now, so I can back out of tagging stops for a minute, revert
 and repull.  In which case, I'll have the opposite problem I do now, which
 would be *adding* a large number of stops that *aren't* in the data we
 got from Tulsa Transit (which, IMO, is the less worse problem to have, even
 though that's a bigger project).

 The script works quite well, as long as you have some 'golden' routes it
 can grab way sequences from.


  Ouch!  Yeah, I'm not entirely sure that's going to be readily done given
 Tulsa's situation.  I wish this situation were unique, but I somehow think
 I'm going to be beating my head against the wall when I start working with
 the OK Coders to pull in Oklahoma City's transit systems.  And maybe in the
 future, the Iowa Pacific Railroad's upcoming regional transit system, the
 Eastern Flyer Express and it's associated bus network...

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Mapping bus routes with doglegs and loops

[Jo]

Hi Paul,

I see what you mean now. I dropped the forward/backward roles on the ways a
few years ago. Recently I thought that they should be a help for the
sorting algorithm, but your example proves they aren't.

I've been developing a script, which tries to use other good relations to
fix the one it's currently run on.

For that script to be able to work, you'd need the stops in the correct
order though.

It works like this:

For a sequence of stops it tries to find other relations which have the
same sequence. The other relation with the longest sequence in common
'wins'.

Then it finds the ways adjacent to the stops on each end of the sequence,
then uses the sequence of ways that connects the stops.

We can work that way, because we have received the stops and the timetables
from the operators, but it's the opposite of what you start with, when you
have to get on the
bus to create a GPX to get an idea about one the variation routes of a
line. (After that you'd use the unstable plugin to add the stops that are
already mapped).

The script works quite well, as long as you have some 'golden' routes it
can grab way sequences from.

Polyglot

2015-02-21 21:40 GMT+01:00 Paul Johnson ba...@ursamundi.org:

 On Sat, Feb 21, 2015 at 2:31 PM, Jo winfi...@gmail.com wrote:

 Hi Paul,

 It helps, when you select a subset of ways and only let JOSM sort those
 automatically.


 True, but if you've had to edit a section of a dogleg to add another, sub
 dogleg, this breaks, too.  The ground truth is breaking the tool.


 Can you select one of the relations, then do Ctrl-Shft-h, then copy that
 url.


 No problem, one such example is the 101 Suburban Acres southbound via
 Denver  49th and Westview
 https://www.openstreetmap.org/relation/4614100/history.  Towards where
 it heads off MLK to Osage Casino along East 63rd North Street, it has a
 dogleg with two branching doglegs, two of those doglegs also have a loop.

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Mapping bus routes with doglegs and loops

[Jo]

Hi Paul,

It helps, when you select a subset of ways and only let JOSM sort those
automatically. Can you select one of the relations, then do Ctrl-Shft-h,
then copy that url.

Jo

2015-02-21 21:12 GMT+01:00 Paul Johnson ba...@ursamundi.org:

 Is there an easy way to map these?  In JOSM, I run into problems with
 trying to sort when I edit that pretty much complicates the situation to
 the point where I end up having to start over if I get the order wrong, and
 the public transport plugin isn't the most stable thing in the world.
 Starting to bang my head into the wall with this.

 Several of many examples I'm running into can be found (as I've mapped
 them so far) with [route=bus][ref=101] in bounding
 box -96.0084915,36.1395383,-95.9528732,36.2658677

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Information board details in bus stops

[Jo]

On talk-be we were wondering what strip means.

Jo
On Aug 21, 2014 3:32 PM, Pieren pier...@gmail.com wrote:

 Hi,

 How would you tag an information board in a bus stop and mainly, if
 there is a timetable, map, etc.

 This picture on twitter suggests new tags:
 https://pbs.twimg.com/media/BvUsqMEIMAA3VRf.jpg

 information:name, information:map, information:timetable

 I didn't find an existing wiki proposal for such details.

 Pieren

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Information board details in bus stops

[Jo]

In Belgium the letters B U S are painted on the asphalt. Hence we wouldn't
call that strip, markings maybe.

Jo
On Aug 21, 2014 5:08 PM, Pieren pier...@gmail.com wrote:

 On Thu, Aug 21, 2014 at 4:52 PM, Jo winfi...@gmail.com wrote:
  On talk-be we were wondering what strip means.

 Good question. I guess it is the yellow lines marking the stop on the
 asphalt itself. But I'm not sure. I'll ask the contributor and forward
 his answer here.

 Pieren

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Stop according to new PT scheme not rendered?

[Jo]

If they need inspiration on how to convert the data to OSM format:

http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/De_Lijndata

If you think it would actually help, I can also stop adding
highway=bus_stop on the next few thousand of bus stops I'm adding. But I
don't think anybody would really care about whether Belgian or Swiss bus
stops get rendered or not.

Polyglot


2014-08-12 12:25 GMT+02:00 nounours77 kuessemondtaegl...@gmail.com:

 I just have a meeting with a big (well for Swiss scale) Public transport
 company. They want to tag and maintain (!) there lines in OSM. And they
 will obviously render the data.
 I was hesitating, but after our discussion here, I came to the conclusion
 that I will advise them to tag ONLY the new schema, and adapt there
 rendering accordingly.
 They more tagger/public transport companies will do the same, the more
 accepted the new tag will come.

 nounours77

 Am 12.08.2014 um 12:08 schrieb Janko Mihelić jan...@gmail.com:

 It only takes one great public transport map with routing, and the new
 scheme will come to life. Who cares about Openstreetmap default map. Who
 cares about the public transport layer on Openstreetmap which doesn't even
 have tram lines rendered. We need outside help with this :)

 Janko


 2014-08-12 0:55 GMT+02:00 Jo winfi...@gmail.com:

 Now that the new way of rendering with Carto instead of Mapnik is finally
 becoming reality, it becomes clear that highway=bus_stop will never (or at
 least not during my lifetime) be replaced by
 public_transport=platform/bus=yes.

 I started to double tag all the new stops I'm adding and the ones I'm
 updating.

 Some people claim that public_transport=platform/bus=yes is longer and
 less efficient than highway=bus_stop, but of course

 highway=bus_stop
 public_transport=platform
 bus=yes

 is even less so, but I stopped caring about that.

 Pity,

 Polyglot


 2013-12-11 21:41 GMT+01:00 Richard Mann 
 richard.mann.westoxf...@gmail.com:

 tag-transform is an osmosis plugin. It happens before conversion to the
 postgres database, so you can use any tags that exist in the wild


 On Wed, Dec 11, 2013 at 8:07 PM, Jo winfi...@gmail.com wrote:

 For a long time, public_transport was not transfered to the DB used for
 the rendering of Mapnik. At that time it didn't make sense to update
 stylesheets.

 Jo


 2013/12/11 Mike N nice...@att.net

 On 12/11/2013 11:07 AM, fly wrote:

 If you keep on adding both schemes simultaneously you will not notice
 the problem and there will be no reason for developers to adjust the
 software.


  One of the problems in this situation is the map rendering developers
 have not taken an interest in the new scheme.

   If someone has submitted a 'pull request' that included the new
 tagging scheme but it was ignored, that is a different story.  OSM is
 frequently described as a do-ocracy - in which finished and coded 
 solutions
 win out over what is needed.  And it's quite possible that we public
 transport mappers have been collecting and entering the information but
 have never gotten into CSS Map stylesheets, or whatever is the technology
 behind the renderers.



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit




 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Stop according to new PT scheme not rendered?

[Jo]

Now that the new way of rendering with Carto instead of Mapnik is finally
becoming reality, it becomes clear that highway=bus_stop will never (or at
least not during my lifetime) be replaced by
public_transport=platform/bus=yes.

I started to double tag all the new stops I'm adding and the ones I'm
updating.

Some people claim that public_transport=platform/bus=yes is longer and less
efficient than highway=bus_stop, but of course

highway=bus_stop
public_transport=platform
bus=yes

is even less so, but I stopped caring about that.

Pity,

Polyglot


2013-12-11 21:41 GMT+01:00 Richard Mann richard.mann.westoxf...@gmail.com:

 tag-transform is an osmosis plugin. It happens before conversion to the
 postgres database, so you can use any tags that exist in the wild


 On Wed, Dec 11, 2013 at 8:07 PM, Jo winfi...@gmail.com wrote:

 For a long time, public_transport was not transfered to the DB used for
 the rendering of Mapnik. At that time it didn't make sense to update
 stylesheets.

 Jo


 2013/12/11 Mike N nice...@att.net

 On 12/11/2013 11:07 AM, fly wrote:

 If you keep on adding both schemes simultaneously you will not notice
 the problem and there will be no reason for developers to adjust the
 software.


  One of the problems in this situation is the map rendering developers
 have not taken an interest in the new scheme.

   If someone has submitted a 'pull request' that included the new
 tagging scheme but it was ignored, that is a different story.  OSM is
 frequently described as a do-ocracy - in which finished and coded solutions
 win out over what is needed.  And it's quite possible that we public
 transport mappers have been collecting and entering the information but
 have never gotten into CSS Map stylesheets, or whatever is the technology
 behind the renderers.



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] One way multiple times in bus relation

[Jo]

In that case 1 relation is enough to describe the route. It will contain
some ways twice. No roles are needed on the ways. The order of the ways in
the relation matters.
In JOSM you will see double vertical line next to your ways when you're
done. The first and the last ways will close the loop with a U and upside
down U.

Polyglot


2014-03-03 18:14 GMT+01:00 Lubos lub...@gmail.com:

 Hi,

 I need to create a bus relation for this:
 http://www.mibus.com.pa/rutas/albrook-esclusas-de-miraflores/

 I already created two separate ways for Albrook - Esclusas Miraflores
 and Esclusas Miraflores - Albrook:
 https://www.openstreetmap.org/relation/3546520
 https://www.openstreetmap.org/relation/3546519

 but in reality, the bus route is one single Albrook - Esclusas
 Miraflores - Albrook. E.g. you can board at Albrook all the way to
 Esclusas and disembark again at Albrook.

 So my question is, should i add few ways multiple times to new
 single route or use backward/forward role? Or something else?

 Cheers,
 Lubos

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] a little idea for new public transport shema

[Jo]

Since I'm the one who proposed this initially, I'm going to add some more
detail.

Stops on opposing sides of a street are hardly ever, exactly opposite one
another, so usually there are 2 stop_positions. This means there will
usually be pairs of route_segment relations, one for each direction.

For stops near a crossing, where some bus lines go to the right, others
straight on and others to the left, the (high)way up to the crossing can
become member of up to 6 relations. But that's still better than to have
them as members of all route relations and their variations for a line.

Having a route_segment for each sequence of highways between two stops, is
a possibility, but there I don't see a reason why a segment couldn't
describe how the bus goes from A to E passing B, C and D.

Unfortunately, one of the advantages of the Oxomoa scheme (being able to
oversee immediately that a route is continuous in the relation editor)
would be lost with the use of subrelations. This can be fixed, given
support is programmed for it in the relation editor (thinking mostly of
JOSM here).


The biggest advantage is that now it's the route_segments wich become
broken instead of. It's a lot easier to fix those segments once instead of
fixing tens of route relations which would otherwise be present on those
highways.

Lastly I want to add that in some cases (around bus stations which are
mapped in full detail for example), there would still be a need to add
(high)ways to the route relations themselves in some cases.

Polyglot


2013/12/26 v...@freenet.de

 Hi,

 i have read some mails about problems with too much relations for public
 transport lines.
 Also I see a problem with stoppoints and platforms specaly by bus and tram
 lines.
 And maintain with other Data maybe not very easy esp. GTFS data.

 In most systems I know there are stored segemts between two stops and
 these segments together are a lineroute.
 These segemnts, I think, have some advantages:
 - only one relation for each direction on the between most stops
 - no need for stoppoints because the relation starts and ends at a
 stoppoint near the platform
 - easy to ad new lines because the can use existing segments
 - most flexibility because small segments ( this may be a disadvantage too
 because it need much work at the start)

 regards Jan


 ---
 Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! 
 Rundum
 glücklich mit freenetMail http://email.freenet.de/basic/Informationen

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Close stations having the same name

[Jo]

The addition of the (bus/tram) platform and its number are what is visible
on the ground (and in the data of the PT provider).

Jo


2013/12/19 Janko Mihelić jan...@gmail.com

 Naming them different than they are named on the ground is mapping for the
 renderer.
 Just add train=yes, bus=yes or tram=yes, and that should be enough. A good
 renderer will put a little train/bus/tram icon below the name of the
 station.


 2013/12/18 Jo winfi...@gmail.com

 Here the platforms for buses near to a railway station have names like:

 Gent Sint-Pietersstation Perron 3
 Mechelen Nekkerspoel Perron 1
 Wavre Quai 5

 (Perron/Quai means platform in Dutch/French)

 Whereas the name of the railway station itself would be:

 Gent Sint-Pieters
 Mechelen Nekkerspoel

 I think it's better to indicate they are related by a hierarchy of
 stop_area relations.

 Jo





 2013/12/18 Copro Grammes coprogram...@yahoo.fr

  Hi,

 Close to a main railway station, there are often other stations
 (underground, bus, tram, etc.) which have the same name (e.g. Somewhere
 Station).

 I wonder what is the best value for the key 'name' of these stations?

 There are examples where the transport type is added in the name: e.g.
 Gare de Lyon (métro 14) in Paris [1], or Hauptbahnhof (U-Bahn) in
 Frankfurt [2].

 Don't you think it is better to tag all these stations with their real
 name (Somewhere Station)? It isn't ambiguous since other tags than name
 allow to distinguish these stations [3]. And it gives to users/applications
 the real name, not a name for renderer.

 Cheers,
 Zigeuner

 [1] http://www.openstreetmap.org/export#map=18/48.84385/2.37467
 [2] http://www.openstreetmap.org/export#map=18/50.10769/8.66386
 [3] E.g. Gare de l'Est railway and underground stations can be
 distinguish by some renderers even though they are both tagged
 railway=station and name=Gare de l'Est:
 http://tile.openstreetmap.fr/?zoom=16lat=48.87451lon=2.359layers=B000FF

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Close stations having the same name

[Jo]

Here the platforms for buses near to a railway station have names like:

Gent Sint-Pietersstation Perron 3
Mechelen Nekkerspoel Perron 1
Wavre Quai 5

(Perron/Quai means platform in Dutch/French)

Whereas the name of the railway station itself would be:

Gent Sint-Pieters
Mechelen Nekkerspoel

I think it's better to indicate they are related by a hierarchy of
stop_area relations.

Jo





2013/12/18 Copro Grammes coprogram...@yahoo.fr

 Hi,

 Close to a main railway station, there are often other stations
 (underground, bus, tram, etc.) which have the same name (e.g. Somewhere
 Station).

 I wonder what is the best value for the key 'name' of these stations?

 There are examples where the transport type is added in the name: e.g.
 Gare de Lyon (métro 14) in Paris [1], or Hauptbahnhof (U-Bahn) in
 Frankfurt [2].

 Don't you think it is better to tag all these stations with their real
 name (Somewhere Station)? It isn't ambiguous since other tags than name
 allow to distinguish these stations [3]. And it gives to users/applications
 the real name, not a name for renderer.

 Cheers,
 Zigeuner

 [1] http://www.openstreetmap.org/export#map=18/48.84385/2.37467
 [2] http://www.openstreetmap.org/export#map=18/50.10769/8.66386
 [3] E.g. Gare de l'Est railway and underground stations can be
 distinguish by some renderers even though they are both tagged
 railway=station and name=Gare de l'Est:
 http://tile.openstreetmap.fr/?zoom=16lat=48.87451lon=2.359layers=B000FF

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Stop according to new PT scheme not rendered?

[Jo]

I went with the pragmatic solution, after being rebuffed several times.
You're not the first one who brings this up. :-)

It doesn't seem like there is a willingness to support the new scheme,
which leads me to say: ok, then it's not necessary to add the new tags, so
I don't. Then the rest of the mappers become annoyed because the validator
complains when they touch such route relations and even that is apparently
hard to fix without tagging on every route relation that it's only
implementing the new scheme half way through.

It's frustrating. I try to make the best of it. If you push me a bit, I'll
change the wiki page to reflect how I'm mapping at the moment. It may
relieve some frustration for new players, but it's more likely this will
cause an edit war on the wiki... which is why I didn't do it until now.

This situation is indeed ugly and not tenable.

Polyglot


2013/12/11 Ramas ies...@ramuno.lt


 On 11 December 2013 16:57, fly lowfligh...@googlemail.com wrote:

 I do not care about the renderer anymore as I did create tickets/issues
 about it a long time ago and I did not get any response.

 For new objects I only use the new scheme (even do not add area=yes to
 platforms).

 For existing objects I simply add the new scheme.


 Hi guys,
 yeah, it's hard to change rendering rules by just opening new ticket. You
 know, i have implemented my own public transport layer -
 http://openmap.lt/#l=51.97448,13.54597,7,MT
 I'm gonna upgrade my rendering rules to new scheme. Any feedback would
 help.

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Stop according to new PT scheme not rendered?

[Jo]

The point would be that it then becomes possible to leave out
highway=bus_stop by contributors who want to do that, thus opening the
possibility to migrate towards the new scheme.

Jo


2013/12/11 Richard Mann richard.mann.westoxf...@gmail.com

 Simply rendering public_transport=platform+bus=yes (if that's correct) as
 a bus stop is a matter of a few lines of xml in the tag-transform (to
 insert a highway=bus_stop tag in relevant nodes, which the normal rendering
 processes can pick up). Though since this is functionally the same as the
 mappers adding a highway=bus_stop tag to the nodes then you do rather
 wonder what is the point.

 Of course it's probably more complicated than that, which is why the
 people who use these tags need to state what needs to be done, and in what
 situations.

 See http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform


 On Wed, Dec 11, 2013 at 7:36 PM, Mike N nice...@att.net wrote:

 On 12/11/2013 11:07 AM, fly wrote:

 If you keep on adding both schemes simultaneously you will not notice
 the problem and there will be no reason for developers to adjust the
 software.


  One of the problems in this situation is the map rendering developers
 have not taken an interest in the new scheme.

   If someone has submitted a 'pull request' that included the new tagging
 scheme but it was ignored, that is a different story.  OSM is frequently
 described as a do-ocracy - in which finished and coded solutions win out
 over what is needed.  And it's quite possible that we public transport
 mappers have been collecting and entering the information but have never
 gotten into CSS Map stylesheets, or whatever is the technology behind the
 renderers.


 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] Using route part relations in Route relations

[Jo]

Hi,

I mapped all the PT going through my city during the past years. There are
many common parts to these itineraries and it's cumbersome to have to mend
them one by one on a regular basis.

It would be a lot easier if it were possible to create route part
relations, for example from one stop to the next and then be able to use
these relations in the actual route relations. This would enable to map
deviations for longer lasting road works as well.

I could of course simply do this, but then no map rendering will be
displaying them correctly anymore...

If we could, one day, get this through and decided, I can create a Python
script to help with the transition and another one to regularly do quality
control checks. These scripts would run inside JOSM.

Kind regards,

Polyglot
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Bus route relation finished. Do you have comments for it? relation/29780

[Jo]

Hi Niklas,

Signomi for the nodes I moved. I tossed away that useless mouse... Were you
able to look at the bus route relations running through my home town?

Cheers,

Jo

2012/4/16 Niklas Cholmkvist towards...@gmail.com

 Jo winfi...@gmail.com wrote:
  Something odd is going on with this one:
  http://www.openstreetmap.org/browse/node/1673963816/history
 Except the relation addition some nodes also moved away from their
 original positions. Like node 163331760, 163331759 and maybe more.

 Anyway I thank you for your input. After reverting your changes (except
 the relation and the changes that you intended to do) if you wish
 please show me some bus routes that you have mapped so I can look at
 them and get ideas. Only if you want to.

 Cheers and have fun!


 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Bus route relation finished. Do you have comments for it? relation/29780

[Jo]

Hi,

I created a new relation for one direction of this bus route:

http://www.openstreetmap.org/browse/relation/2139143

You can either delete it, or change the relation you created to reflect the
other direction of the route.

Polyglot

2012/4/15 Niklas Cholmkvist towards...@gmail.com

 Hello list.

 This is bus route line 26 of ΟΑΣΘ(oasth) in my city--
 http://www.openstreetmap.org/browse/relation/29780

 I had mapped it months or years ago as a bus route, and these past days
 by asking advice from mappers at the official #osm channel, I completed
 this bus route with some of their advice. I have both stop point and
 platform in it for every stop.

 In the past when I mapped bus routes I wanted an example to look at so
 I could get ideas how I would map my own, like a good example.
 Do you think this bus route could be an example of one of the ways
 to map a bus route?

 Looking forward to comments
 Cheers!

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Bus route relation finished. Do you have comments for it? relation/29780

[Jo]

Something odd is going on with this one:

http://www.openstreetmap.org/browse/node/1673963816/history

It's very far from its stop position.

In the new relation I created the way members don't need roles anymore and
the stops can simply have stop as a role. Creating two relations seems like
a cleaner way to define where the bus travels. It's also easier to write
software to check whether the line is continuous this way.

Polyglot

2012/4/15 Niklas Cholmkvist towards...@gmail.com

 Hello list.

 This is bus route line 26 of ΟΑΣΘ(oasth) in my city--
 http://www.openstreetmap.org/browse/relation/29780

 I had mapped it months or years ago as a bus route, and these past days
 by asking advice from mappers at the official #osm channel, I completed
 this bus route with some of their advice. I have both stop point and
 platform in it for every stop.

 In the past when I mapped bus routes I wanted an example to look at so
 I could get ideas how I would map my own, like a good example.
 Do you think this bus route could be an example of one of the ways
 to map a bus route?

 Looking forward to comments
 Cheers!

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Bus route relation finished. Do you have comments for it? relation/29780

[Jo]

I'm pretty sure I could write a Jython script which does exactly that, but
if one can do that, then what's the point?

Polyglot

2012/4/16 Mike N nice...@att.net

 On 4/16/2012 4:54 PM, Jo wrote:

 The reverse directions should be easy to find. I haven't added stop
 positions (yet) and there are many relations serving Leuven which still
 have their forward/backward roles.


 It should be possible to derive stop positions programmatically, once the
 stops have been defined.   I have been just adding stops with the intention
 of automatically adding stop positions if needed or useful to some
 application.


 __**_
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-transithttp://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NEW Proposed Feature

[Jo]

Here the buses travel over the same stretch of asphalt quite often.
Usually back and forth (what you call a spoon). Sometimes twice in the
same direction (on a roundabout with one stop that serves both
directions, so the bus that would exit the roundabout on the first
exit, now goes around to serve the stop, then passes the road it came
from, then exits to the right.)

Jo

2011/2/9 Michał Borsuk michal.bor...@gmail.com:
 On 02/02/2011 02:42 PM, Jo wrote:

 Is it possible to add a way to a relation twice with Potlatch?

 Out of 80 lines I manage, I have such a situation once (not a way, but a
 bus stop, actually). Is it an issue in your area?


 LMB



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NEW Proposed Feature

[Jo]

2011/2/2 Michał Borsuk michal.bor...@gmail.com:
 On 01/28/2011 02:45 PM, Jo wrote:

    Yes that's one option. I'm a bit reluctant to put in separate
    relations for each direction unless someone actually gives me a
    compelling reason to do so. I already have some ways with more than 20
    relations, and I don't really want to double that number without good
    reason.

 http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M
 http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M

 Lijn 7 uses Krijkelberg twice. Bus stop Sint-Kamillus is served by both
 directions. This can be mapped without ambiguity if there is one
 relation for each direction.

 Do we need such level of details if we can't present it to the user at
 present?

We're mapping for the future. öpnvkarte is not functioning anymore
anyway at present, so the only way of viewing routes is in an editor
like JOSM. What I mean, is that at present we can't present anything
to the user.



 http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M
 http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M

 Bus station in Leuven. It's perfectly clear where the buses will travel.
 Not so if both directions are in only one relation.

 Is the improvement worth the extra time?

That's something everyone will have to weigh for themselves.


 Sure it would be possible to program something to process a 1 route
 relation, but it would not be straightforward.

 Such situations are quite exceptional. I would know, because I've mapped a
 mixed urban-suburban area, where some lines are the perfect A-to-B straight
 lines, and some are pretty crazy (spoon shape is the least strange of all).

Not all that exceptional, over here it seems to happen in 5-10% of all
bus routes I'm mapping. Buses making loops and spoons, that is.

 So: how about two relations per line are to be optional in cases where one
 relation does not successfully explain the route?

Sounds fair. Maybe we should have a tag to indicate which approach was used.

paradigm=allinoneroute

or

paradigm=onerouteperdirection

I'm sure someone will come up with better names.

 Most importantly though,
 with one route relation per direction, it's a whole lot easier for the
 mappers to check that the relation is continuous.

 At the cost of extra time to enter and maintain, and confusion (it's not how
 it is on printed maps!).

Many things in OSM are not like in printed maps, since a printed map
is only one of the possible goals. For instance people also want to
create drawings of sequences of stops.

 I've managed to check continuity with one route, and if you're worried about
 continuity in the aspect of future routing, then it's irrelevant - routing
 software does not follow the route itself, but its bus stops.

 I am a die-hard opponent of relation-per-direction, but please convince me
 that it is really worth it.

If the examples I've presented a few days ago can't convince you, I'm
afraid nothing will, so 'I rest my case' :-)


 As far as routes go that have a shorter itinerary during the week, I
 wouldn't make an extra sets of relations for those. Simply put the
 longest road traveled in both relations.


 Sure, that's the way to go, but what is your proposal for routes with
 different paths? I have at least 2 such routes, each has 4 variants. I have
 so far mapped them as one relation, but this is suboptimal. Four relations
 are not much better, and if I were to apply one relation per direction, I'd
 have eight. That's an overkill.

I guess I'm fortunate our PT company assigns a new ref number when
such a situation occurs. This means there are many routes which share
large parts of their paths... So the number of relations doesn't
become less, but since the ref number is different, we don't have
another choice but to create separate relations for these cases.

Cheers,

Jo

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NEW Proposed Feature

[Jo]

2011/1/28 Richard Mann richard.mann.westoxf...@gmail.com

 On Thu, Jan 27, 2011 at 9:06 PM, Michael von Glasow
 mich...@vonglasow.com wrote:
  Following the call for a better proposal, Tiziano, Oscar and I have
 drafted
  up a simple proposal. It is based on how we have mapped the public
 transport
  networks in our cities (Padova, Ferrara and Milan), with some
 improvements
  that came up during this discussion.
 
  Our approach was to keep it simple, therefore we have deliberately not
  treated special cases. For now, we want to standardize the basics; once
 we
  have agreed on those, we can discuss special cases which might not be
  covered by the current proposal and draw up an amendment, to be decided
  separately.
 
  You can find the proposal at:
 
 
 http://wiki.openstreetmap.org/wiki/Proposed_features/Simplified_Public_Transport_Scheme
 
  Constructive feedback and suggestions are welcome and can be sent to the
  list or left on the proposal's discussion page.

 Many thanks for this.

 1) How do you envisage the mapping of loops (ie (say) six stops on
 one-way loop at one end of the route). I guess the two directions
 could be combined, or an arbitrary break made at some point round the
 loop. I think you need to suggest either one or the other or say that
 both are acceptable as long as they are ordered.


You look at the schedule for that line and determine which one is considered
the terminus by the PT company.

Jo
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NEW Proposed Feature

[Jo]

 Yes that's one option. I'm a bit reluctant to put in separate
 relations for each direction unless someone actually gives me a
 compelling reason to do so. I already have some ways with more than 20
 relations, and I don't really want to double that number without good
 reason.


http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M

Lijn 7 uses Krijkelberg twice. Bus stop Sint-Kamillus is served by both
directions. This can be mapped without ambiguity if there is one relation
for each direction.

http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M

Bus station in Leuven. It's perfectly clear where the buses will travel. Not
so if both directions are in only one relation.

http://www.openstreetmap.org/?lat=50.89623lon=4.47405zoom=17layers=M

Brussels Airport

http://www.openstreetmap.org/?lat=50.89648lon=4.4759zoom=17layers=M

All buses serve the airport over a dedicated road.

http://www.openstreetmap.org/?lat=50.86321lon=4.515999zoom=18layers=M

In Sterrebeek line 616 makes an extra loop to serve a bus stop on Tramlaan.

Sure it would be possible to program something to process a 1 route
relation, but it would not be straightforward. Most importantly though, with
one route relation per direction, it's a whole lot easier for the mappers to
check that the relation is continuous.

As far as routes go that have a shorter itinerary during the week, I
wouldn't make an extra sets of relations for those. Simply put the longest
road traveled in both relations.

Jo
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NEW Proposed Feature

[Jo]

route_ref does not seem obsolete to me. True, if the relation is defined, it
can be determined from that by routers. But as long as that hasn't happened,
this is the information that a mapper can take not of in the field.

Then afterwards, it can help to add the appropriate stops to the route
relation (semi-automatically if somebody codes it). We have quite a few
express buses here that only stop at some of the stops they pass by.

And then there are the school and marketbuses which might not even get route
relations because they only run once a day/week.

Jo

2011/1/27 Michael von Glasow mich...@vonglasow.com

  Following the call for a better proposal, Tiziano, Oscar and I have
 drafted up a simple proposal. It is based on how we have mapped the public
 transport networks in our cities (Padova, Ferrara and Milan), with some
 improvements that came up during this discussion.

 Our approach was to keep it simple, therefore we have deliberately not
 treated special cases. For now, we want to standardize the basics; once we
 have agreed on those, we can discuss special cases which might not be
 covered by the current proposal and draw up an amendment, to be decided
 separately.

 You can find the proposal at:


 http://wiki.openstreetmap.org/wiki/Proposed_features/Simplified_Public_Transport_Scheme

 Constructive feedback and suggestions are welcome and can be sent to the
 list or left on the proposal's discussion page.

 Michael
 OSM Mapper of the public transport network in Milan, Italy



 On 01/14/2011 11:52 AM, Oscar Formaggi wrote:

 I agree with Tiziano. I am among those interested in joining.

 Oscar
 OSM Mapper of the whole city bus network in Ferrara, Italy

 2011/1/14 Tiziano D'Angelo tiziano.dang...@gmail.com

   How about you, [...] develop a better proposal? We seem to share the
 understanding of the flaws; a new proposal may lead to a secession, which is
 the ugliest thing possible, but I am not sure we can continue to improve the
 current proposal.


 I am in :) and the proposal should aim also to keep the existing status
 quo for backwards compatibility (i.e. highway=bus_stop as the essential
 basic element of a bus stop). I know there are more people who are
 interested to join.

 Tiziano
 OSM Mapper of the whole city bus network in Padova, Italy

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing 
 listTalk-transit@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-transit



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Jo]

For the record: I prefer to have one relation for each direction of the bus
route, as this allows to indicate 'exactly' where the buses pass. We are not
mapping merely for the ability to draw a map of the bus routes, but also to
allow PT routing eventually.

Jo

2011/1/11 Michał Borsuk michal.bor...@gmail.com



 On 11 January 2011 07:24, Dominik Mahrer (Teddy) te...@teddy.ch wrote:

 Hi all

 One month ago I already posted an RFC on this proposal. In the meantime I
 got plenty of comments and I have extended/corrected/rewritten nearly the
 whole proposal.

 Please visit again
 http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

 Regards
 Teddych


 Extending my previous post: I've given a quick look to the proposal, and it
 seems to combine what is now used, with what oxomoa had proposed. Oxomoa has
 been criticized as unnecessarily complicated, and you seem not to have
 addresses this issue. What is now proposed is in my opinion worse that what
 was before, exactly because it does not address oxomoa's issues. The
 proposed schema is more complicated, i.e. instead of one point for a bus
 stop, three (!) are proposed: one for the place where the bus stops, and two
 platforms, if they exist.

 Moreover, the unnecessary in 99% of cases practice of using two relations
 for each line is kept, two relations (one in each direction), plus there's a
 mother relation, the so-called route master. A few important issues arise:


 * First of all, *Potlatch** does not allow the creation of nested
 relations*. Potlatch, when I last looked at statistics, was responsible
 for 1/3 of all edits. How do you plan to address this issue?

 * Secondly, the creation of such relations is neither easy, nor quick. It
 may discourage new mappers as *the learning curve would be much more
 difficult*. And it may be perceived as an unnecessary and discouraging.
 Not the way to go if we want to increase the quality of the map, which has
 to be done by humans.

 * Thirdly, Please again *elaborate on the efficiency* of such a solution,
 because it seems that the small gain in quality is offset by the huge loss
 in time necessary to achieve this. Also, maintaining lines in *three 
 *relations
 will be hell: any change of the line will require at least *double* work.
 Is there really a good reason for the double work? There have been other
 proposals how to deal with lines that have different trace in each
 direction, and those were easier than one relation in each direction
 (disclosure: one proposal was mine)

 As for the examples, all those below seem to be coming from you:
 http://www.openstreetmap.org/browse/relation/1342798/history
 http://www.openstreetmap.org/browse/relation/1244886/history
 http://www.openstreetmap.org/browse/relation/1281532/history

 Is there anybody else using it? I'd like to see more examples out of
 Germany or Switzerland, bitte.



 --
 Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,


 Michał Borsuk

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - RFC - Public Transport

[Jo]

I'm one of the people who would like to add data about Public Tranportation.
Since nobody likes to have to enter the same data several times, I can
understand the need for a 'definitive' way to map PT in such a way that all
downstream users (map rendereres, routers, etc) have the information they
need to work with. Apparently the system that you want to call established
does not completely cater for that, so people come up with improvements.

I like the proposal, the only thing I don't like about it is the massive
duplication of information in the route relations, which will make it harder
to maintain them in the long run. But I see why we would do it that way.
Maybe I'll come up with a proposal for 'proto-relations' made up of other
'routepart'-relations some time. Those could get converted to the massively
duplicated relations automatically then.

Cheers,

Jo

2010/12/13 Richard Mann richard.mann.westoxf...@gmail.com

 On Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy) te...@teddy.ch
 wrote:
  You both are right, old is the wrong word for what I wanted to say. I
 do
  not want to replace or deprecate highway=bus_stop. Because English is not
 my
  first language, I catched up to consult my dictionary and I think
  traditional or conventional would be the better word, expressing what
 I
  wanted to say.

 established would be a better term

 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] child relations in type=route, route=bus

[Jo]

I have no idea whether Potlatch can or can't. I've been waiting almost 2
years and now that I found the possiblity to work with child relations in
JOSM, I decided to to a little experiment with them. In the mean time, I'm
not entirely convinced it's the best way to go anymore. On the one hand
there is something to say for it, since so many bus lines are using the
parts of the same routes, but I'm pretty sure that if one gets the PT
companies to share their data, it's not going to be in there with child
relations. So I'll probably be deleting them once again, soon.

Jo

2010/9/29 Michał Borsuk michal.bor...@gmail.com



 On 29 September 2010 10:31, Richard Mann 
 richard.mann.westoxf...@googlemail.com wrote:

 Lots of
 relations is probably conceptually less complicated than child
 relations, so I'd probably go for that, editors-allowing.


 Can one deal with this in Potlatch, which is the entry-level editor for
 most mappers, and common editor for 1/3 of all users? (Mind you, there are
 things Potlatch can do that are hardly possible in Josm or Merkaartor)



 --
 Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,


 Michał Borsuk

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] bus stops/platforms with electronic display of when the buses pass through

[Jo]

Hi,

I didn't find a tag to use for synoptic displays indicating when buses are
coming through (either as a time left to wait, or a full display of normal
time+delay) at the bus stop level.

And another one (at the bus_station level) with all the buses that are
passing through (like the ones in train stations and airports). That one may
even deserve its own node to indicate where it is and possibly even an
indication in what direction it's facing.

Jo
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit