[Talk-transit] Bus stops in North America from GTFS data

[john whelan]

Currently bus tops mapped locally in Ottawa seem to be either untagged or
tagged in different ways.  Maperitive default rules displays the icon and
the name field.  The GTFS (General Transit Feed Specification was Google TFS
at one time) has three relevant tags these are stop_code, stop_name, and
stop_id.

The *stop_code* field contains short text or a number that uniquely
identifies the stop for passengers. Stop codes are often used in phone-based
transit information systems or printed on stop signage to make it easier for
riders to get a stop schedule or real-time arrival information for a
particular stop.

The *stop_name* field contains the name of a stop or station. Please use a
name that people will understand in the local and tourist vernacular.

The *stop_id* field contains an ID that uniquely identifies a stop or
station. Multiple routes may use the same stop. The *stop_id* is dataset
unique.

I'm proposing that the name field be built by concatenating the stop_code
and stop_name fields.  In the case of Ottawa the stop code is four digits
and is displayed on each bus stop.  The stop_name is displayed to the driver
so he can announce the stops.

An example is below.

http://picasaweb.google.ca/lh/photo/qETGqJTUCEYzFln-38ugXQ?feat=directlink

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

Re: [Talk-transit] Bus stops in North America from GTFS data

[john whelan]

The problem with name=stop_name is it does not identify the bus stop.  In
Ottawa each stop is labeled with the stop_code and you can call a phone
number to find out the time of the next bus or use a web site to plan your
trip using that stop_code.  The route planners display the stop code on the
stop that you should be standing at to catch the bus so that's the one that
is best displayed on the map in the name field.

If you are mapping then the only value you can see on the bus stop is the
stop_code.  The GTFS system's stop_name is the name displayed to the bus
driver and no one else.  There is no way to get this value unless you import
it from a GTFS file and currently we have not yet determined if the license
lines up with OSM.

Basically if you are mapping on the ground then the only value available is
the stop_code.  If this is dropped in the name field it displays nicely on
the map.   Concatenate this with the stop_name and you know what to ask the
bus driver for.

Do you have a pointer to the British/German standard?

If we are importing then we can pull in the stop_id for free.  Having it
available means an application can then make use of it or a bot can verify
the values in the other fields more easily.  In database terms having a
value that is dataset unique is important.

Cheerio John



On 10 June 2010 16:05, Michał Borsuk  wrote:

> IMHO merging is not necessarily the best idea. You will create yet another
> standard.
>
> I'd keep the names as name=stop_name, and add the stop_code with another
> tag. Propose something that will be relevant with more North American
> cities, yet that does not disturb other regions. You may want to follow
> British/German standard. There is a tag that identifies stops uniquely,
> sorry can't recall at the moment. The last time I saw it was Siegburg/Bonn
> train station.
>
> The *stop_id* is dataset unique, but is there sense at all to import it to
> OSM?
>
> Grüsse,
>
>
> Michał
>
>
> On 10 June 2010 12:49, john whelan  wrote:
>
>> Currently bus tops mapped locally in Ottawa seem to be either untagged or
>> tagged in different ways.  Maperitive default rules displays the icon and
>> the name field.  The GTFS (General Transit Feed Specification was Google
>> TFS at one time) has three relevant tags these are stop_code, stop_name, and
>> stop_id.
>>
>> The *stop_code* field contains short text or a number that uniquely
>> identifies the stop for passengers. Stop codes are often used in phone-based
>> transit information systems or printed on stop signage to make it easier for
>> riders to get a stop schedule or real-time arrival information for a
>> particular stop.
>>
>> The *stop_name* field contains the name of a stop or station. Please use
>> a name that people will understand in the local and tourist vernacular.
>>
>> The *stop_id* field contains an ID that uniquely identifies a stop or
>> station. Multiple routes may use the same stop. The *stop_id* is dataset
>> unique.
>>
>> I'm proposing that the name field be built by concatenating the stop_code
>> and stop_name fields.  In the case of Ottawa the stop code is four digits
>> and is displayed on each bus stop.  The stop_name is displayed to the driver
>> so he can announce the stops.
>>
>> An example is below.
>>
>> http://picasaweb.google.ca/lh/photo/qETGqJTUCEYzFln-38ugXQ?feat=directlink
>>
>> Cheerio John
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>
>
> --
> 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] Bus stops in North America from GTFS data

[john whelan]

Ottawa is different.  The passengers complain if the bus is one minute early
or five minutes late.  Quite unlike London in the UK where I used to live.
I think it stems from the minus 30c in winter time, with wind chill it can
be even colder, the passengers typically turn up about two minutes before
the bus.

Thanks for your thoughts.

Cheerio John

On 10 June 2010 20:25, Roland Olbricht  wrote:

> > > You may want to follow
> > > British/German standard. There is a tag that identifies stops uniquely,
> > > sorry can't recall at the moment. The last time I saw it was
> > > Siegburg/Bonn train station.
>
> Do you mean the "ref" tag as on node 160621? I'd strongly advice not to
> follow
> that way. The "ref" has also been used to list the lines stopping there and
> should not be used for something else.
>
> I've never seen any item that identifies bus stops uniquely in Germany or
> Britain and is visible to the ordinary passenger. It is also not needed -
> all
> bus stops with the same name in the same town are usually very close
> together
> (just stops for different directions). But being unique would be never
> stated
> as a formal constraint. Buses sometimes stop at two nearby stops with the
> same
> name. Thus there is nothing comparable to the stop_code here in Germany.
>
> John, I would advice you to just set name to the stop_code if this is the
> thing displayed on the bus stops. It is very different from the northern
> European system. But passenger (or traveller) information is the primary
> goal
> of the OSM data. Thus a useful information in the tag that is expected to
> be
> crucial ("name") is probably the best solution for Ottawa.
>
> Cheers,
>
> Roland
>
> ___
> 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] GTFS compatibility

[john whelan]

I'm currently looking at Bus stops in Ottawa in OSM and finding similar
issues with the existing bus_stops.  I'm seriously wondering where
stop_codes exist if one approach might be to import bus_stops using GTFS
data and use the GTFS tags such as stop_code etc from stops.txt
http://code.google.com/transit/spec/transit_feed_specification.html#stops_txt___Field_Definitions

Tools such as JOSM have a search facility so we should be able to search for
bus_stops without a stop_code then reconcile them with the ones that have a
stop_code tag.  If the GTFS data is wrong then we should be able to send a
report somewhere probably the transit authority saying we think this stop is
incorrect.

My personal view is while we should respect work done already adding extra
tags in this way doesn't remove this work and it is up to the rendering
rules to either omit or include a particular bus_stop for display.  This can
be selected by the presence or absence of a stop_code tag, certainly in
Maperitive.

If we were to do this we would probably need some sort of wiki write up and
a standard way to label bus_stops.  Currently in Ottawa I've seen at least
four different ways the ones with the bus route on being the least useful as
they tend to be out of date.

I don't think mapping routes works at all well.  Certainly in Ottawa the bus
stops and stop_codes stay in the same physical place but the bus routes can
be modified three or four times a year.  Some changes are greater than
others and the transit route planning system that can be accessed from the
web or by phone includes school buses which are not listed in the stop but
do sometimes provide a useful and quicker way to get from point A to point
B.

Cheerio John


On 30 June 2010 09:25, Hillsman, Edward  wrote:

> Our center has a project to explore the use of OSM as a repository and tool
> for supporting multimodal trip planners (for example, bike to transit, ride
> the bus, walk or bike to final destination). We are keenly interested in the
> current discussion of transit and GTFS in OSM, because one of our tasks is
> to develop software to import from GTFS into OSM, and then update the import
> as a transit agency modifies its routes or stops, taking into account that
> OSM mappers may have found and corrected errors in what was uploaded (or may
> have introduced errors). I'm writing to share some of our experience and get
> your suggestions. We will make the software we develop in this project (for
> uploading, matching, and updating GTFS data in OSM) publicly available.
>
> We think it should be relatively easy to upload a set of GTFS stops into an
> area where no one has mapped bus stops into OSM. Generating the route
> relations will be harder and we may not accomplish that as part of this
> project. And we think that updating such data will be relatively simple,
> because it can rely on tags identifying and cross-referencing the stops;
> software would look for changes, and manual work would be needed to
> reconcile them. The hard part is going to be designing the initial upload
> process to work in areas where OSM already includes some bus stops, but not
> all of them. In the state of Florida, where we are working, there are about
> 450 stops already in OSM, many in areas served by transit agencies with GTFS
> data. Obviously, we want to respect what has been mapped. Things that
> complicate the initial upload include:
>
> (1) Locational errors in the GTFS data. These are not systematic, and some
> are surprisingly large. One is more than 200 meters from its actual
> location, and only about 10 meters from another stop that GTFS has within 10
> meters of its actual location (and that is mapped accurately in OSM). We
> came into this project knowing that there is locational error in GTFS. Now
> we are trying to figure out how to deal with it. The GTFS locations do match
> those appearing in Google Transit, by the way.
> (2) Locational errors in the OSM data. These aren't systematic either but
> tend to be much smaller, except that in a few cases the stop has been
> recorded on the wrong side of the street, and a mapper in one city has
> recorded stops as nodes defining the street way rather than as points to the
> sides of the street.
> (3) Incomplete and inconsistent tagging of the OSM stops.
> (4) The presence in an area of stops for multiple agencies, only one of
> which has GTFS data. Our campus has a shuttle bus circulator system with no
> GTFS data (they operate without a set schedule but with a target 10-minute
> headway, and frequency changes during the day and with the university class
> schedule). The area's main public transportation agency has several routes
> that pass through the campus, and has GTFS data. Most of the public-agency
> stops on campus, but not all, are also campus shuttle stops, and there are
> many more shuttle stops on campus than there are public-agency stops.
> (5) Incomplete mapping of stops for each agency in OSM.
>
> At the momen

Re: [Talk-transit] GTFS compatibility

[john whelan]

Could it be enhanced to handle stop_code?  That would remove any ambiguity
about which stop was which when merging existing mapped stops with ones from
stops.txt.

Thanks John

On 1 July 2010 09:48, Roland Olbricht  wrote:

> > But we are still in the thinking-about-this stage, haven't made any
> >  decisions, and are looking for suggestions and comments (hence this
> >  posting).
>
> Let me make a suggestion: instead of producing duplicates and leaving
> mappers
> with the frustrating task of tiding up, you could use JOSM to do a semi-
> automatic import. JOSM will offer quite powerful and versatile editing
> capabilities to solve conflicts immediately. I've extended the Public
> Transport Plug-In to offer an experimental GTFS import (for stops only at
> the
> moment). The aim of this software is to avoid cluttering the database with
> duplicates and to maintain the data model as consistent as possible. At the
> moment, the stops as treated as bus stops, because I can't find a stop type
> in
> the GTFS specification.
>
> Installation instructions:
> - download JOSM: http://josm.openstreetmap.org
> - Run with "java -jar josm-tested.jar"
> - Open "Edit > Preferences > Plugins" and select "public_transport"
> - Restart JOSM
>
> I suggest the following workflow:
> - Download an area to work on into JOSM
> - Import the respective GTFS file (stops.txt) with the plug-in
> - The plugin will pre-sort on load
> - work through the nodes that remain "pending": mark a line in the
> dialogue,
> press "Enable" to add the node, the "Show" and "Mark" to center on the
> node.
> If you want to join it with an existing node, this
>
> What happens on load of stops.txt:
> - Every stop that is outside the bounding box of the currently loaded area
> in
> JOSM will be set to state "outside"
> - Every other stop that is more than 1000m away from any existing bus stop
> (recognized as "highway"="bus_stop") will be added to the map (state:
> "added")
> - Every stop nearby existing bus stops is set to state "pending".
>
> What you can do within the plugin:
> - The button "Enable" adds all stops currently marked as lines in the
> dialogue
>  as nodes with
>  "highway"="bus_stop"
>  "stop_id"=[stop_id]
>  "name"=[stop_name]
>  to the map.
> - The button "Disable" removes the stops marked as lines from the map.
> - The button "Catch" drags an existing, marked node on the map to the
> position
>  of the imported stop and tags it as explained above. An existing name is
>  preserved.
> - The button "Join" does the same as "Catch", but the node remains at the
>  position of the existing node.
> - The buttons "Mark" and "Show" mark resp. show a stop (must be enabled)
> from
>  the dialogue on the map. The button "Find" marks lines the dialogue that
>  correspond to marked nodes in the map.
>
> Possible extensions or modifications to make life easier:
> - Use remote control and a server application to only detect those areas
> where
>  conflicts exist.
> - Reuse existing "stop_id"s to match imported stops there. This would
> greatly
>  simplify later updates.
> - Use other attributes from "stops.txt"
> - Make the workflow smoother, e.g. use key shortcuts for sequences like
>  "Enable", "Show", "Mark".
> - do something with "agency.txt".
> and of course any idea you might have.
>
> Cheers,
>
> Roland
>
> ___
> 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] GTFS compatibility

[john whelan]

Since the JOSM plug_in will become the defacto standard since it will be
used by many people who don't read posts here or understand the issues may I
request that it uses the GTFS tag of stop_name and stop_code rather than the
tag of name.

In one location two stops with the same stop_name actually have different
buses serving them.

At one intersection in Ottawa I have four different bus stops each with
different routes heading in different directions.  Each stop has a physical
stop_code on the stop.  When I ran the import it imported one stop at a
different location to the four on the junction.  I'm unable to tell if it is
one of the four at the junction and should replace the existing mapped ones
or it is the stop before the junction.  The same value in the stop_name
field appears to be used for different stops on the same route.

That way if we are consistent then the rules in the renders can just render
the appropriate stop_code or stop_name if not present.

Many thanks

Cheerio John

On 1 July 2010 09:48, Roland Olbricht  wrote:

> > But we are still in the thinking-about-this stage, haven't made any
> >  decisions, and are looking for suggestions and comments (hence this
> >  posting).
>
> Let me make a suggestion: instead of producing duplicates and leaving
> mappers
> with the frustrating task of tiding up, you could use JOSM to do a semi-
> automatic import. JOSM will offer quite powerful and versatile editing
> capabilities to solve conflicts immediately. I've extended the Public
> Transport Plug-In to offer an experimental GTFS import (for stops only at
> the
> moment). The aim of this software is to avoid cluttering the database with
> duplicates and to maintain the data model as consistent as possible. At the
> moment, the stops as treated as bus stops, because I can't find a stop type
> in
> the GTFS specification.
>
> Installation instructions:
> - download JOSM: http://josm.openstreetmap.org
> - Run with "java -jar josm-tested.jar"
> - Open "Edit > Preferences > Plugins" and select "public_transport"
> - Restart JOSM
>
> I suggest the following workflow:
> - Download an area to work on into JOSM
> - Import the respective GTFS file (stops.txt) with the plug-in
> - The plugin will pre-sort on load
> - work through the nodes that remain "pending": mark a line in the
> dialogue,
> press "Enable" to add the node, the "Show" and "Mark" to center on the
> node.
> If you want to join it with an existing node, this
>
> What happens on load of stops.txt:
> - Every stop that is outside the bounding box of the currently loaded area
> in
> JOSM will be set to state "outside"
> - Every other stop that is more than 1000m away from any existing bus stop
> (recognized as "highway"="bus_stop") will be added to the map (state:
> "added")
> - Every stop nearby existing bus stops is set to state "pending".
>
> What you can do within the plugin:
> - The button "Enable" adds all stops currently marked as lines in the
> dialogue
>  as nodes with
>  "highway"="bus_stop"
>  "stop_id"=[stop_id]
>  "name"=[stop_name]
>  to the map.
> - The button "Disable" removes the stops marked as lines from the map.
> - The button "Catch" drags an existing, marked node on the map to the
> position
>  of the imported stop and tags it as explained above. An existing name is
>  preserved.
> - The button "Join" does the same as "Catch", but the node remains at the
>  position of the existing node.
> - The buttons "Mark" and "Show" mark resp. show a stop (must be enabled)
> from
>  the dialogue on the map. The button "Find" marks lines the dialogue that
>  correspond to marked nodes in the map.
>
> Possible extensions or modifications to make life easier:
> - Use remote control and a server application to only detect those areas
> where
>  conflicts exist.
> - Reuse existing "stop_id"s to match imported stops there. This would
> greatly
>  simplify later updates.
> - Use other attributes from "stops.txt"
> - Make the workflow smoother, e.g. use key shortcuts for sequences like
>  "Enable", "Show", "Mark".
> - do something with "agency.txt".
> and of course any idea you might have.
>
> Cheers,
>
> Roland
>
> ___
> 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] GTFS compatibility

[john whelan]

In the UK streets are tagged with the value on the sign at the end of the
street and this works very well with printed maps.  When I lived in London a
group of bus stops might be labeled A-E  but in general bus stops do not
have a name or id painted on the bus stop.  Unfortunately UK practice is not
followed by other parts of the world.  In Ottawa each bus stop has a four
digit number painted on it in General Transit Feed Specification (GTFS)
terms this is known as the stop_id.  The GTFS stop_name value is not
apparent to the mapper.

The GTFS file contains bus stop location information but this information
can be up to 200 meters out.  In Ottawa the convention is to name the stop
after the nearest cross street.  Add in town planning where through traffic
is discouraged from travelling on residential roads but footpaths have been
placed to give access to bus stops and you can have two or three different
bus stops with the same stop_name value but different stop_id values.

Does it matter what we call the stop?  Well having the stop_id value
available means that local mappers can at least map the bus stops to the
correct location.  Without the stop_id value it becomes more difficult.  The
current Ottawa GTFS stops.txt file is incomplete, some stops appear to be
missing, mapping with the stop_id makes it easier to identify them.

We now have applications that process the tags on an osm file.  Maperitive
for example will search tags to locate points of interest.  shop=florist
finds local florists.  There are many GTFS aware applications that know the
GTFS tag names so reusing them in OSM makes sense.  Routing systems for
example work better if the bus stop is in the right place and correctly
labeled.

With the NAPTAN import some one decided which NAPTAN field should be placed
in the name tag and I suspect the original field in the NAPTAN database
wasn't simply name.

Locally my personal preference for the name tag would be to concatenate the
GTFS stop_id and stop_name fields but also retain them as separate tags.
That way some one could set up the rendering rules for bus stops to display
either should they wish to do so.

By the way even street name signs are not always simple.  In OSM the rule is
to use the name on the street sign at the time of mapping.  Recently in
Ottawa there has been a move to bilingual street signs so Leduc Crescent
becomes "croissant Leduc Crescent".  If you tag street name:"croissant Leduc
Crescent" then you get into issues of what do you expect a casual user to
enter on a find or search command adding in that some streets were mapped
before the new street sign rules.

Cheerio John


On 4 July 2010 06:23, Jenny Campbell  wrote:

> In the UK, following the NAPTAN import, all stops use name, not stop_name.
> A name tag on a bus stop implies that the tag is referring to the name of
> the stop anyway, no risk of mix ups there! We use name in the same way for
> everything else on the map, why should a bus stop be different?
>
> Jeni
>
>
> On 01/07/2010 17:08, john whelan wrote:
>
>> Since the JOSM plug_in will become the defacto standard since it will be
>> used by many people who don't read posts here or understand the issues may I
>> request that it uses the GTFS tag of stop_name and stop_code rather than the
>> tag of name.
>>
>>
> ___
> 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 additional tags for bus stops and an import of San Fracisco data

[john whelan]

I don't think this is a good idea as Ottawa certainly changes the bus
routes or lines four times a year.  Some lines are stable for many
years but many are not.  The stops themselves remain in the same place
its just the buses that serve them change their numbers and routes.

Cheerio John


>
> As far as I know, the current trend is to add the bus stop to the lines
> (relations) which stop there.
> http://www.openstreetmap.org/browse/node/354589964
> Does that fit your situation?
>
>
> Regards,
>
> LMB
>
> --
> Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: 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] Proposed additional tags for bus stops and an import of San Fracisco data

[john whelan]

You are talking about verifying 10,000 bus stops four times a year.
Are you assuming that this would be done through GTFS?  Currently in
Ottawa there is no way to tie the physical bus stop to GTFS and the
GTFS locations are not always accurate.  Not all bus stops are
included in the file.   At one local junction I still haven't worked
out which bus stops are included and which ones are not.

We do have a stop_id on the bus stop, its just not included in the
GTFS file and the other issue we have is licensing.

Cheerio John

2010/7/15 Michał Borsuk :
> So you change the associated bus stops. Can be done.
>
> Greetings,
>
> LMB
>
> On 15.07.2010 14:50, john whelan wrote:
>>
>> I don't think this is a good idea as Ottawa certainly changes the bus
>> routes or lines four times a year.  Some lines are stable for many
>> years but many are not.  The stops themselves remain in the same place
>> its just the buses that serve them change their numbers and routes.
>>
>> Cheerio John
>>
>>
>>
>>>
>>> As far as I know, the current trend is to add the bus stop to the lines
>>> (relations) which stop there.
>>> http://www.openstreetmap.org/browse/node/354589964
>>> Does that fit your situation?
>>>
>>>
>>> Regards,
>>>
>>> LMB
>>>
>>> --
>>> Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: 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
>>
>
>
> --
> Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: 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] GTFS compatibility

[john whelan]

An old one but I was looking at JOSM.  It appears that if you save an
OSM file from JOSM that has modifications to be uploaded it tags them
in the XML file.  So it should be be possible to save an .osm file,
edit it in some way then get JOSM to upload the changes.

Sort of an off line plug-in.

Cheerio John

On 1 July 2010 12:20, Arun Ganesh  wrote:
> I had proposed a spreadsheet editing mode in josm that would make data
>  driven tasks such as this a lot simpler.
>
> Ticket: https://josm.openstreetmap.de/ticket/5038
> UI Wireframe:
> https://josm.openstreetmap.de/attachment/ticket/5038/josm%20table%20edit.png
> I have still not ironed out the details for the import function, which would
> try to match the osm data objects to some information in the imported
> spreadsheet and update the data. Worth a look for any plugin authors.
>
> --
> http://j.mp/ArunGanesh
>
> ___
> 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] simplified relations for transit

[john whelan]

I've been playing with editing an OSM file in Visual Basic, you save
the .OSM file from JOSM or grab it in some other way then edit the XML
file, putting a modify tag on anything changed, load it into JOSM then
upload the changes.  I actually wanted an automated way to generate a
name:fr tag on a street name and add it to the local street names in
Ottawa, its possible to work out an algorithm to do most of these in
an automated way.

So it's a sort of mini bot.  I can forward you a copy of the program
source but wouldn't like it to spread around too far as it is very
easy to do a lot of damage very quickly with this sort of tool.

If you have a stop_code on the bus stop then the local mapper can
correctly position the bus stop.  Now given the route is just a
collection of bus stops you can pick out the bus stops in the OSM file
and update the bus route numbers using Visual Basic, then feed the
updates back with JOSM.

In theory you should even be able to set a relationship of bus stops
or way for the route that could display the particular route when
rendered.  I think the colour can be suggested in the GTFS file.
Maperitive would you lots of control over rendering, possibly let a
student lose on it as a project?

Cheerio John

On 16 August 2010 14:52, Hillsman, Edward  wrote:
> During the past month or so, the members of this listserv have had some
> discussion of importing bus stops in GTFS format into OSM and the use of
> relations to group such data.  Several members have expressed reluctance to
> get involved in creating a full set of route relations (i.e., bus stops plus
> street paths for the actual travel path of the bus) and maintaining those
> relations in OSM when large public transportation agencies change routes
> with a fair amount of frequency.  And our experience and that of others on
> the listserv is that these GTFS bus stop datasets contain some locational
> errors and ambiguities that complicate creating the street path portions of
> the relations, especially by automated means..
>
>
>
> It seems there are several possible uses of the stop and route information
> in OSM, and these need different types of data:
>
>
>
> 1)   Electronic Map - The visual electronic equivalent of a paper map,
> which someone can consult to see where the bus routes go, or find which bus
> route might serve a destination. This probably would be most effective if
> the map could display the linear route (including the direction of travel)
> for the reader, rather than just the bus stops. Lines order the stop data,
> even if the stops are not displayed.
>
> 2)  Generating trip information - Finding “trip paths” between an origin
> and a destination, using only OSM data for streets, sidewalks, transit
> routes, etc., and then displaying the resulting path of the trip overlaid on
> the map. Most likely, the algorithm that identifies the pathway for the
> journey would benefit from knowing the sequence as well as the locations of
> the stops, and again the linear route through the street network would be
> valuable for this.
>
> 3)  Generating trip information, with transit exception - Similar to the
> second application above, it stores bus stop locations in OSM and uses OSM
> data for walking and biking directions, but it uses route and schedule data
> contained in the GTFS file (and not stored within OSM), for transit
> directions. The two sets of trips then are linked using bus stop location
> information from the GTFS dataset. This is the approach taken by
> OpenTripPlanner.org.  OpenTripPlanner uses OSM sidewalk, street, etc. data
> to generate biking and walking trips, but uses GTFS datasets to generate
> transit trips.
>
>
>
> Ultimately, because OSM is not designed to store the detailed timetable data
> needed to plan trips at different times on different days, some reference to
> timetable and route data outside of OSM will be necessary for cases #1 and
> #2 above, even if OSM is perfectly good for the supporting infrastructure
> (which I believe it generally is).
>
>
>
> While it would certainly be good to have the stop sequence (i.e., route
> path) recorded in OSM, to support all three of these uses, creating and
> maintaining this is potentially a lot of work, and for some applications it
> is not necessary. Plus, there is the problem that route path relations seem
> to be easy to break and hard for beginning mappers to maintain. On the other
> hand, it is actually pretty simple and straightforward to create a relation
> for each of a transit agency’s routes, and to put just the stops into the
> proper relations when importing or updating them.
>
>
>
> So, would there be anything wrong with putting only the stops into route
> relations, without trying to figure out and code route paths as part of that
> relation? The only negative we can see is that the route path part of the
> relation would not exist, and so the data would not support the use cases #1
> and #2 for transit.  OpenTripPlanne

Re: [Talk-transit] simplified relations for transit

[john whelan]

Taking this a bit further there is a blog that talks about displaying
routes on a map, the last example on the page has a route number on it
which might be useful.
www.gravitystorm.co.uk/shine/archives/2008/05/29/look-ma-no-hands/

Cheerio John

On 16 August 2010 14:52, Hillsman, Edward  wrote:
> During the past month or so, the members of this listserv have had some
> discussion of importing bus stops in GTFS format into OSM and the use of
> relations to group such data.  Several members have expressed reluctance to
> get involved in creating a full set of route relations (i.e., bus stops plus
> street paths for the actual travel path of the bus) and maintaining those
> relations in OSM when large public transportation agencies change routes
> with a fair amount of frequency.  And our experience and that of others on
> the listserv is that these GTFS bus stop datasets contain some locational
> errors and ambiguities that complicate creating the street path portions of
> the relations, especially by automated means..
>
>
>
> It seems there are several possible uses of the stop and route information
> in OSM, and these need different types of data:
>
>
>
> 1)   Electronic Map - The visual electronic equivalent of a paper map,
> which someone can consult to see where the bus routes go, or find which bus
> route might serve a destination. This probably would be most effective if
> the map could display the linear route (including the direction of travel)
> for the reader, rather than just the bus stops. Lines order the stop data,
> even if the stops are not displayed.
>
> 2)  Generating trip information - Finding “trip paths” between an origin
> and a destination, using only OSM data for streets, sidewalks, transit
> routes, etc., and then displaying the resulting path of the trip overlaid on
> the map. Most likely, the algorithm that identifies the pathway for the
> journey would benefit from knowing the sequence as well as the locations of
> the stops, and again the linear route through the street network would be
> valuable for this.
>
> 3)  Generating trip information, with transit exception - Similar to the
> second application above, it stores bus stop locations in OSM and uses OSM
> data for walking and biking directions, but it uses route and schedule data
> contained in the GTFS file (and not stored within OSM), for transit
> directions. The two sets of trips then are linked using bus stop location
> information from the GTFS dataset. This is the approach taken by
> OpenTripPlanner.org.  OpenTripPlanner uses OSM sidewalk, street, etc. data
> to generate biking and walking trips, but uses GTFS datasets to generate
> transit trips.
>
>
>
> Ultimately, because OSM is not designed to store the detailed timetable data
> needed to plan trips at different times on different days, some reference to
> timetable and route data outside of OSM will be necessary for cases #1 and
> #2 above, even if OSM is perfectly good for the supporting infrastructure
> (which I believe it generally is).
>
>
>
> While it would certainly be good to have the stop sequence (i.e., route
> path) recorded in OSM, to support all three of these uses, creating and
> maintaining this is potentially a lot of work, and for some applications it
> is not necessary. Plus, there is the problem that route path relations seem
> to be easy to break and hard for beginning mappers to maintain. On the other
> hand, it is actually pretty simple and straightforward to create a relation
> for each of a transit agency’s routes, and to put just the stops into the
> proper relations when importing or updating them.
>
>
>
> So, would there be anything wrong with putting only the stops into route
> relations, without trying to figure out and code route paths as part of that
> relation? The only negative we can see is that the route path part of the
> relation would not exist, and so the data would not support the use cases #1
> and #2 for transit.  OpenTripPlanner appears to be a very popular routing
> engine which is available in many geographic areas.  Thus, for a software
> tool we’re developing we’re leaning towards not including transit route
> information within OSM per case #3.  As with anything in OSM, individuals
> map what they know or are interested in, and may ignore or omit features
> that they are not interested in. Someone who comes along later and decides
> that the route paths are really important could code them into the route
> relations.
>
>
>
> Are there other applications that might require a representation of the path
> for use cases #1 and #2 above, that we should be considering?
>
>
>
> Edward L. Hillsman, Ph.D.
>
> Senior Research Associate
>
> Center for Urban Transportation Research
>
> University of South Florida
>
> 4202 Fowler Ave., CUT100
>
> Tampa, FL  33620-5375
>
> 813-974-2977 (tel)
>
> 813-974-5168 (fax)
>
> hills...@cutr.usf.edu
>
> http://www.cutr.usf.edu
>
>
>
> 

Re: [Talk-transit] How to map named bus stop platform/positions

[john whelan]

Since most renders only display the name to make it useful to the
casual map user I'd suggest
"A name" or "B name" in the name field.  There is a similar problem
with the GTFS stop_code.

Cheerio John

On 31 August 2010 14:17, Magnus Bäck  wrote:
> In the Skånetrafiken public transport network in southmost Sweden, bus
> stops are identified not only by name but also by a capital letter that
> identifies this particular platform (or stop position, if you will). In
> most cases you have an "A" platform for one direction and a "B" platform
> across the street for buses heading the other direction. Example below.
>
> http://openbusmap.org/?zoom=18&lat=56.01628&lon=12.72438&layers=BT
>
> How should this be entered into OSM? I think the information is useful
> since bigger bus stations may have tens of platforms, but I don't feel
> any of the existing tags really cover this case. For now I've included
> it in the name ("Helsingborg Biblioteket (B)" etc, see above), but this
> is hardly ideal. I suppose the ref attribute wouldn't be completely off,
> but it seems more geared towards network-internal reference numbers that
> are unknown to and useless for the travellers. The platform identifiers
> should be displayed on maps but perhaps not as prominently as the stop
> names.
>
> --
> Magnus Bäck
> ba...@swipnet.se
>
> ___
> 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] [GTFS import] How to automatically add bus stops to relations?

[john whelan]

What is the licensing on the GTFS data?

Thanks John

On 8 September 2010 10:26, Michał Borsuk  wrote:
> Hello.
>
> Thanks to Roland Olbricht's "Public Transport" plugin, I have successfully
> merged existing bus stops with "my" GTFS data. There was a part of the work
> that required manual human intervention, e.g. mapping existing bus stops to
> the imported ones, but the second part, that is mapping bus stops (nodes) to
> lines (relations) can be done automatically.
>
> Any ideas how to do it?
>
>
>
> --
> 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] GTFS and the like

[john whelan]

The thing to watch out for with GTFS data is the stop location.  Some
transit systems have very accurate data, such as Ottawa, typically is used
for announcements on buses for blind people, others have bus stops that can
be 300 meters out.

There are tools to import the bus stops from the GTFS file into JOSM.

Cheerio John


On 2 April 2014 12:29, Florian Lohoff  wrote:

>
> Hi,
>
> i am now that busy with public transport but i got a mail from the regional
> public transport authority who show interest in publishing data or work
> together with OSM. I am not really the public transport guru, i just read
> a bit
> here and there and had looked at the GTFS stuff.
>
> Is there a consolidated approach to not only bus stops (which i take
> as solved) but time table, live data etc? Probably Germany only?
>
> What file format is the "defakto" standard. Is GTFS the solution
> and one day all data consumers for public transport will use GTFS?
>
> I think currently the whish for locals is to simply take the data
> and have some nice clickable map with timetables and all those
> bells and whistles. I havent seen that approach yet so i ask.
>
> Flo
> --
> Florian Lohoff f...@zz.de
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIVAwUBUzw63JDdQSDLCfIvAQjKxg/+K/KgA3S4kJaKU5GzXXfE74riHIAnPf3q
> XdRU78NkQVaQcZoleDPLws7OdhJoaBgKBPGOB+DPZQ8KZkoC0wJbW8z8QTP9nsuy
> 046yK+eUlzlWmLZoYg/c7wlijQXfQTuTC0CFJQu16V6teYWoL/hnuFQ/KfTN43vR
> CWzgnRRBxaXrN9U8o45mBinH54qdJ7k94Jof6TQpgd5Un5JlS1aswRGUSqiQV3WL
> vfi0GF7nkVsD+Nok6PU5sj7CTTiDPgBncRLzOU28GiBRCtmVtE6w7XsznVw9gq1a
> Atvs+hSo15YxUHoBFlTqBzR+zHVkf5PofG9NqOhrHxcB74sAuDe+S8vURixDZGXw
> PM89CiIiqS/FuK6Y1tFGpsNLAP9Qz1ifgDoMGtudqeQxZ9d79ohlmcZULF2ZQxgO
> E1i7IFVUsJ4G2ms9PWeDs3u9SHirL4B7Q4tYqJrCOw08JbEnuewIiZFB8Z3LqXng
> 7IgtOyK34xIdCXtJh62UeCzi+8JoL5S3f5BdzV5gH6dazwSPhKF+acTrrGDtIqqi
> UUbsyQ3vk50Y1cfCG6BOM/I5Nh8cApDe/OPJQnAd9HRwSOMKG4XuTO9ILRK58qzJ
> NIjVizbw8nxL1jDjhdRvDUSrrRyt6jAXN3bLDBAgHNWzbgmAWQMOLAyVyhnk3uiK
> ukcvKYKFc5g=
> =kZ39
> -END PGP SIGNATURE-
>
> ___
> 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?

[john whelan]

Ottawa has all its bus stops in and rendered in OMAND and the normal
rendering web sites.  The city has links to the maps on its web site for
some years but all the bus stops are labelled highway=bus_stop and are
tagged with the stop numbers so you can text or phone a number to find out
when the next three buses are coming.

The only issue we have is new mappers adding or editing the bus stops.

Cheerio John


On 12 August 2014 10:02, Jo  wrote:

> 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 :
>
>> 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ć :
>>
>> 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 :
>>
>>> 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  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 
>
>> 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] Uploading public transport data on OSM

[john whelan]

Within a geographic area could we accept that all bus stops with a specific
tag were GTFS tags for a particular transit company?

Thanks John

On 16 Jan 2018 7:42 pm, "Johnparis"  wrote:

> I believe OSM-Sync creates nodes with "gtfs_id" as the tag key. The value
> is typically something like "StopPoint:48:5001".
>
> In response to Jo/Polyglot's concern, the gtfs_id is not unique globally;
> it is unique within a GTFS feed. So, for instance, the Paris area's
> transport agency, STIF (now IDFM), has unique IDs within the Paris region.
> It is theoretically possible that these could be duplicated somewhere else
> in the world (though that likelihood is extremely small, given the
> numbering scheme they use). The STIF scheme is StopPoint:x:y, where x is
> the (internal STIF) code of the agency providing the stop times for each
> trip, and y is an arbitrary number guaranteed to be unique within the
> agency. (The agency codes are in the agency.txt file in the GTFS feed. It
> gets quite arbitrary; for instance the RATP, which runs the Paris transport
> system, has an agency code of 59 for purposes of bus StopPoints but a code
> of 100 for some other purposes. Weird.)
>
> I agree with Stephen Sprunk about the need to sync with a unique ID. I
> have begun using gtfs_id (easily changed to, for example,
> ref:FR:STIF:gtfs_id), with the idea that changes would first be synched
> against the existing ID. STIF does not guarantee that the gtfs_id for a
> stop is permanent; however, it seems to be the case. (STIF did guarantee
> that a different code would be permanent, but it seems to have abandoned
> that recently, and GTFS is becoming the de facto standard.) It makes my
> life a little simpler to use gtfs_id instead of ref:FR:STIF:gtfs_id because
> the matching logic is simpler. (I started with ref:FR:STIF:gtfs_id but then
> in JOSM for instance I could not do a search for "gtfs_id -ref" because the
> "-ref" includes any ref, even ref:FR:STIF:gtfs_id. Using just gtfs_id
> avoids that problem.)
>
> The problem I run into most frequently is when someone "on the ground"
> (that is, a mapper) has created a bus stop (usually with a position much
> more accurate than the agency's data) but the stop doesn't have useful
> information to derive the gtfs_id. (For instance, if the node had an
> accurate stop name and the number of a bus line that serves it, I could
> derive the gtfs_id, but often there isn't anything more informative than
> "highway=bus_stop".) As a result, I have been importing nodes for each bus
> line from the STIF data (with permission), then manually merging the nodes
> with those already in place on the ground. I save myself lots of time when
> I encounter a new line that uses existing gtfs_ids.
>
> I have a couple of thoughts about GSoC projects for JOSM plugins that
> might be useful.
>
> -- One would deal with the aforementioned node-merging problem (an
> interesting theoretical problem; mostly you want to match the closest stop
> on the same side of the road, assuming it's within a reasonable distance).
>
> -- Another would be a route-builder. My idea would be (a) I provide a
> starting way and direction, (b) at the end of each way, I indicate left,
> right, straight or other to continue. I think this would greatly speed the
> creation of routes.
>
> Perhaps these tools already exist. I'd love to see them.
>
> John
>
>
>
>>
>>
>> --
>>
>> Message: 5
>> Date: Tue, 16 Jan 2018 21:35:54 +0100
>> From: Jo 
>> To: "Public transport/transit/shared taxi related topics"
>> 
>> Subject: Re: [Talk-transit] Uploading public transport data on OSM
>> Message-ID:
>> > ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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 :
>>
>> >
>> >
>> > 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
>> 

Re: [Talk-transit] Public Transport Timetables

[john whelan]

I'm not sure if I can post to the transit group.

The GTFS bus stop data is of varying quality.  Locally we have an automated
system that calls out the bus stop names and generally the position in the
GTFS file is accurate to within a meter.

Some other transit systems are not as accurate, and the GTFS location for a
bus stop can be more than 100 meters out.

Just something to bear in mind.

Cheerio John


On Thu, 8 Nov 2018, 4:23 pm Kevin Dalley  There's real time GTFS and static GTFS files.
>
> The static files have the current schedule, routes, bus stops, etc
> contained in files. The files can be downloaded, but each transit agency
> has its own location.
>
> GO-Sync, from University of Southern Florida synchronizes some static
> GTFS data with openstreetmamp, route and stop info. This is info which
> is useful in openstreetmap since it is a natural part of a map.
>
> https://github.com/CUTR-at-USF/gtfs-osm-sync
>
> While static GTFS files contain schedule information GO-Sync does not
> handle this information.
>
> OSM might include information which GTFS does not include, such as the
> existence of a bench at a stop.
>
> The schedule might have frequency, but it often has the expected times
> at each bus stop for a given run. That's a lot of information, and would
> take some work to match up to OSM. It isn't impossible, but it is more
> information than in the proposal.
>
> There might be advantages to having this information in OSM. It's nice
> to look up the expected schedule even when you don't have a network
> connection. And you might not have a connection when you're underground
> waiting for the next bus.
>
> Real time GTFS has current, more or less real time, information  on the
> location of the bus, including expected arrival time. You could find out
> about the 10 minute delay in your bus. This couldn't be in the static
> OSM map, though the location of the information could in OSM.
>
>
> On 11/8/18 10:20 AM, Mike N wrote:
> > On 11/8/2018 12:06 PM, Leif Rasmussen wrote:
> >>
> >> I think that creating a new GTFS server would be better than using
> >> transit land or transitfeeds.com , because
> >> OSM would have full control over what happened to the servers and
> >> which licencing was used.
> >>
> >> Does anyone with experience in GTFS know how an integration like that
> >> could work?  Also, is what I am imagining even possible?
> >
> >
> >   I would tend to think that using the GTFS standard would be the best
> > approach.  The only "duplication of effort" is that there is an
> > optional? inclusion of the route geometries in the GTFS feed.
> >
> >   In the one case I am familiar with - OpenTripPlanner, the local
> > network build process could always download the GTFS from any source as
> > part of the build process.   The only advantage I see for adding another
> > feed source is to add the capability of publishing a GTFS from other
> > than an official source.  This allows a public GTFS feed for a city
> > which is otherwise too small to maintain an electronic schedule.
> >
> >
> > ___
> > 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

[john whelan]

I'm a little unclear about the advantage of using something other than
highway=bus_stop.  Ottawa has a fairly large number of bus stops currently
tagged and mapped.  They get reported from an open data source every few
years.  There are people who hold the view that they should all be mapped
individually but the import does give us all the stops together with their
reference numbers.

In theory just dropping in the reference numbers should give us the
relationship for a route.

Thoughts?

Thanks John

On Sun, Apr 28, 2019, 7:47 AM Dave F via Talk-transit, <
talk-transit@openstreetmap.org> wrote:

> Hello
> General points:
>
> Are Stop_Areas required?
> What are they for?
> Are they in use?/Who uses them?/Will they ever be used?*
> If there is a purpose for them, what should they consist of? I've seen
> shops, bike racks, litter bins included. Surely they're irrelevant?
>
> Remove public_transport=station/train=yes &
> public_transport=platform/train=yes from railways.
> They are purely duplication of the existing, much used
> railway=station/railway=platform respectively. They provide no
> additional information. Duplication is wasted effort. It leads to
> confusion & errors.
>
> The use of 'platform' seems to have been hi-jacked by PT to represent a
> stopping place instead of it's original true meaning of a physical
> raised area above road level to aid vehicle boarding. Is
> public_transport=platform required at all on bus stops? As with
> railways, use existing tags.
>
> * I think these questions need to be asked of all PT tags. From what I
> can ascertain the various schemas were developed in great detail to look
> good on paper, but appear to have little relevance to real world usage.
> I think this is further borne out by PT tags not being widely implemented.
>
>
> DaveF
>
> On 26/04/2019 16:10, Markus wrote:
> > Hi all,
> >
> > I've added, updated and corrected several dozen public transportation
> > routes in the past few years using the PTv2 scheme. As is the case
> > with most route relations, they often break (e.g., because the course
> > of a road or rails is modified, a new roundabout is built, a stop is
> > displaced or simply by accident). However, with all the stop_positions
> > and stop_areas, maintaining these routes and stops is very much
> > time-consuming.
> >
> > There have been several ideas to simplify and improve public
> > transportation mapping (e.g. [1] or [2]), however they either faced
> > too much opposition or are inactive. Therefore I've worked out three
> > different drafts for an improved public transportation scheme and
> > would like your opinion. After that, i plan to write a full proposal
> > for the option that got the most support.
> >
> > In order to better understand how I came up with the ideas below, I
> > have first listed the deficiencies of the current public transport
> > schemes:
> >
> > Deficiencies of PTv1:
> >
> >* No separate route relation per direction and route variant.
> >* Platforms at stations cannot be added to route relations, which
> > prevents a better routing.
> >* Stops (highway=bus_stop/railway=tram_stop) are often placed on the
> > road or rail, which is not optimal for routing.
> >
> > Deficiencies of PTv2:
> >
> >* public_transport=stop_position and public_transport=stop_area make
> > mapping and maintaining complicated and time-consuming. Besides,
> > public_transport=stop_position is unnecessary, as it can be calculated
> > from public_transport=platform (which provide a more exact routing).
> >* Counter-intuitive public_transport=platform: its meaning depends
> > on whether used on way/area (where it means a platform) or on node
> > (where it means a waiting area w/o platform).
> >* Not possible to add transport mode tags (e.g. bus=yes) on
> > public_transport=platform because they are also used to set access.
> >
> > Now for the possible solutions:
> >
> >1. Sticking to PTv1 tags, but with separate route relations per
> > direction/variant and by placing stops at the point where passengers
> > wait. A stop with a platform get a railway/highway=platform way/area
> > and a railway=tram_stop/highway=bus_stop node. (Except at stations, a
> > stop_area relation is not required because the stop node is placed on
> > the platform.) -- Advantage: Widely used tags, least retagging
> > required. Disadvantage: A stop with a platform needs two elements (as
> > railway/highway=platform + railway=tram_stop/highway=bus_stop can't be
> > combined).
> >
> >2. Sticking to PTv2 tags, but abandoning
> > public_transport=stop_position and introducing a new transport_mode=*
> > tag. -- Advantage: Only one element per stop. Disadvantage: The rather
> > counter-intuitive public_transport=platform remains.
> >
> >3. Abolishing public_transport=stop_position and
> > public_transport=platform and introducing a new public_transport=stop
> > tag (node/way/area) for the waiting area at stops, which can be
> > combined with rai

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

[John Whelan]

So can the proposal build on existing highway=bus_stop?  On reason for 
this is a number of cites have imported their bus stops from Open Data 
which ensures completeness.  ie all the bus stops in the city are 
present and occasionally they are reimported to catch any new bus stops 
or removal of others.  Changing from bus stops means everyone who does 
this sort of import has to reconfigure their import system and doing 
that will be awkward and may lead to a bus stop being mapped twice.


Also there are existing tutorials on how to map a bus stop.  Many will 
be local so finding them to correct them will be a major problem.


Thoughts?

Thanks

Cheerio John

Dave F via Talk-transit wrote on 2019-05-04 10:53 AM:

Hi

On 04/05/2019 11:12, Wiklund Johan wrote:
At least in Norway, highway=bus_stop is a free floating node 
representing the location of a stop,


public_transport=platform is also 'free floating'.


not the geometry of a stop.


147 platforms are nodes.

In the examples of your overpass public_transport=platform doesn't 
represent the geometry of a stop, just arbitrary areas of pavement 
adjacent to bus stop poles. Other furniture maybe present (shelter, 
bench etc) but they can either be added as extra tags to the more 
abundant highway=bus_stop or, preferably, as separate items.


I should also say that platforms are abundant in Norway, especially 
in the Oslo region where consistent mapping is in place. 
http://overpass-turbo.eu/s/IGK


There are 300 more bus stops than platforms 
http://overpass-turbo.eu/s/IHi


Bus stops can be tagged to provide the same data. Think of the time & 
effort saved if they'd been utilised.


Just because something was mapped incorrectly in the past it doesn't 
mean it should continue. It should be corrected to improve the 
database Please remember this thread (& others) were started in an 
attempt to "simplified public transportation scheme". To achieve that, 
remapping & code rewriting will have to occur.


PS This one doesn't look right: 
https://www.openstreetmap.org/way/361309229


Cheers
DaveF



/Johan

-Original Message-
From: Dave F via Talk-transit 
Sent: fredag 3. mai 2019 23.56
To: talk-transit@openstreetmap.org
Cc: Dave F 
Subject: Re: [Talk-transit] Ideas for a simplified public 
transportation scheme


Hi Johan

Is there reason it can't use highway=bus_stop,& equivalents for trams 
etc, which were already in the database & more abundant than 'platform'?


DaveF

On 03/05/2019 21:48, Wiklund Johan wrote:

In response to:
Please show me a router which uses platforms as I'm struggling to 
see the benefits atm.

And:

This reinforces my point about misappropriation of tags. A platform 
is a physical construction higher than the surrounding ground to 
allow easier boarding.


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/3890a0f451e1a6900d174b29125b3
c80.jpg
We use public_transport=platform abundantly in routing with OTP, and 
it is a key component in specifying the origin of walk links. We use 
it as an area, or a way. We need these to make direct contact 
between our stops (separate database) and the foot-routing network 
of OSM.


I further see no problem in extending the usage of the platform 
(public_transport=platform) to any waiting area for public 
transport. To force correct word description would force one to use 
terms like "street_waiting_area" "dirt_pit", "ditch" or "sidewalk" 
which would only be hairsplitting. If the usage of the word platform 
is misappropriation, I think it is the wording in the scheme that is 
too narrowly defined, rather than the widespread usage being wrong.


However, don’t get me wrong. I don’t really care what it's called as 
long as there is an area which can represent where passengers wait, 
and to which public transport vehicles arrive. This is of course the 
needs of our own journey planner, and we have no stake in the wider 
public transport scheme of OSM. I just wanted to show that there are 
indeed routers which use the platforms, and have great emphasis on 
their usage.


In case you were wondering which router I'm talking about:
https://en-tur.no/ (https://github.com/entur/opentripplanner)

Sincerely (and possibly missing a few points because I haven't been
reading the whole discussion),

Johan Wiklund
Entur




-Original Message-
From: Dave F via Talk-transit 
Sent: fredag 3. mai 2019 19.09
To: Public transport/transit/shared taxi related topics
; selfishseaho...@gmail.com
Cc: Dave F 
Subject: Re: [Talk-transit] Ideas for a simplified public
transportation scheme

Hi

(This amalgamates replies to Markus's points in his last post.)

On 30/04/2019 18:34, Stephen Sprunk wrote:

A platform is where people wait to board; if they stand at a pole
(typical for buses), then the pole is logically the platform.
This reinforces my point about misappropriation of tags. A platform 
is a physical construction highe

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

[john whelan]

>
> .
>
> I don't understand. Tutorials are local, or do you mean bus stops? Local
> to what? All entities are locatable.
> Please expand.
>
> Cheers
> DaveF
>

Unfortunately people make notes often on paper.  So someone leading a
mapping group will refer to their notes when repeating the exercise.
Finding those notes and correcting them is not easy.

Experience is what you get when you don't get what you expected.

Cheerio John

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

[john whelan]

So if we connect a bus_stop to a highway with a path would that address the
routing concerns?  Or is that idea too simple?

Thanks John

On Tue, May 7, 2019, 3:53 PM Jarek Piórkowski,  wrote:

> Sorry, crossed my wires while editing at one point:
>
> > 9a. Because we must retain hw=bus_stop per #3 and #5, any
> > accommodation of these cases must either be initially of tags, or
> > guidance on how to place highway=bus_stop tags
>
> make that:
>
> 9a. Because we must retain hw=bus_stop per #3 and #5, any
> accommodation of these cases must either be new tags, or guidance on
> how to place highway=bus_stop tags
>
> And just to be clear:
>
> > 11b. stop_area is currently mentioned but not recommended in the wiki [2]
>
> make that:
>
> 11b. stop_area is currently mentioned, but not specified as required,
> in the wiki [2]
>
> ___
> 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] Old railways

[john whelan]

>Btw, do you know of a way to copy data from one layer in JOSM to
another, while keeping it at the exact same position?


Create a new layer down load a tiny area with nothing in it works fine.

Select what you want to copy and copy to new layer.

Cheerio John

On Sun, May 12, 2019, 1:46 PM Tijmen Stam,  wrote:

> On 12-05-19 17:48, Jarek Piórkowski wrote:
> > On Sun, 12 May 2019 at 07:54, Tijmen Stam  wrote:
> >> In my environment, some people are adding old ("razed" railways to
> >> openstreetmak, of which no trace is visible in the field.
> >> It concerns both old railways which have been gone since 1933, e.g.
> >> https://www.openstreetmap.org/way/592259029 (Note that this piece still
> >> is somewhat visible, as it is now a road and partially a cycle path).
> >
> > Hi Tijmen,
> >
> > The "canonical" answer is that things that no longer exist in real
> > life and there is no trace of them do not belong in OpenStreetMap.
> >
> > How strict you want to interpret this probably depends more on local
> > community consensus than on talk-transit guidance.
> >
> > Tagging of removed railways that are now paths _in the same alignment_
> > seems relatively uncontroversial. https://osm.org/way/583243933 is an
> > example local to me.
>
> Yeah, I hold that same thing too. Basically path and track I still
> double-tag as railway=abandoned, but when it becomes a proper highway, I
> generally don't.
> I do tag razed when most of a longer railway is still (very) visible in
> the field, but short sections are no longer, as e.g. they have become a
> highway through/around a village. E.g.
>  or
>  (that latter should've
> been razed, not abandoned)
>
> > Your example of way 592259029 seems to me a bit
> > ambitious in that it traces alignment where it is no longer evident,
> > such as over houses, and https://osm.org/way/592259043 is a bridge
> > that no longer exists... I would not include this in OSM.
>
> >> Another example is a tram line in Amsterdam that has been gone for a
> >> year now , the area has
> >> been completely redeveloped, no trace of the old tram tracks remains.
> >
> > IMO this should not be in OSM.
>
> Then we think alike.
>
> >> I only recently found out about openrailwaymap, but I can't find much
> >> information about it. It seems it gets its data from the OSM database.
> >>
> >> Is there a way to store "razed" railways somewhere else, so they will
> >> show up on openrailwaymap but not on OSM (they are rendered on some
> >> renderers, e.g. OSMAND)
> >
> > There does exist
> > https://wiki.openstreetmap.org/wiki/Open_Historical_Map which is a
> > separate database intended for things that used to exist but don't
> > anymore.
> >
> > Although this would be technically and legally possible, I doubt that
> > OpenRailwayMap currently integrates data from OHM.
>
> Thank you so much!
>
> To not "lose" the hard work of others, I have copied (part of) the
> abandoned/razed railways from OSM to OHM, added it with data from
> Wikipedia. Now I have to remove the data from OSM, but that's quite some
> work so I will do that later.
>
> <
> http://www.openhistoricalmap.org/?edit_help=1#map=16/52.7820/4.8315&layers=H
> >
>
> Thanks for that!
>
> Btw, do you know of a way to copy data from one layer in JOSM to
> another, while keeping it at the exact same position?
>
> ___
> 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] USA

[John Whelan]

OpenStreetMap originated in the UK and Germany but these days it is far 
more widespread.


Are you asking if anyone in the US adds bus stops?  Or saying you think 
that the recommended practices for mapping bus stops should be different 
in the US.


OSM is often used by apps to show routing or when the next bus is coming 
etc.  Some are used for partially sighted people or others with 
disabilities.  They depend on standard field names and values which is 
one reason why there are recommendations on what goes where.  The apps 
don't just work in the US.


Cheerio John

80hnhtv4agou--- via Talk-transit wrote on 2019-09-25 9:31 PM:

that OSM,
is a product of the united kingdom,
are there any united states bus editors out there ?


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


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

Re: [Talk-transit] [Talk-GB] Mapping train services in Great Britain

[john whelan]

One problem I had when living in the UK was deciding which station to use
to travel up to London.  Mother who worked as a midwife had been told one
station by the nurses at the hospital.  Fine except it was a 20 minute
drive to get there and the fairly high frequency but stopping tube would
get you into the city fairly quickly.  Later I used the station that was
ten minutes walk away.  That saved the 20 minute drive and has fewer stops
at stations.  Years later I found another station 15 minutes walk away that
ran into Liverpool street with only one stop.  Much the fastest but I'd
been living there more than ten years before I uncovered it.  There was
another line I used occasionally that ran into Kings Cross and occasionally
that would best depending on where you were going to.

So it is a mixture sometimes of which station to use and how that gets you
to your destination.  Don't get me started on tickets and which to use.

The route planners make it much easier than obtaining the old paper
timetables and pouring through them.

Does all this complexity belong in OSM?  Probably not our strength I think
is in the mapping of stations etc and let someone else sort the rest out.

Cheerio John



On Tue, Jun 1, 2021, 11:29 Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> What's wrong with consulting a timetable?
>
> Maps show you where you can go, timetables tell you when .
>
> DaveF
>
> On 01/06/2021 01:18, Michael Tsang wrote:
>
> > I think you are missing the point that GB is not a city.
>
> > Cities are densly pack and urban transport systems reflect this. In
> London tube trains simply stop at every station.
>
> > This structure will not work when it comes to rural stations, and what
> we have works very well. It would not be efficient to stop every trains
> at stations which only have a few dozen passengers in a day.
>
> Other European countries are doing it much better. The routes are
> numbered. There are designated express services with stops only in big
> cities. The rural stations have only local stopping services which call at
> every stop en-route.
>
> We don't even have a useful route map from train companies that can work
> out which train I should take without consulting the timetable.
>
>
> ___
> 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