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

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] 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=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] 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] 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 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 

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

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


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://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 f...@zz.de 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] [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 michal.bor...@gmail.com 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] 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 ba...@swipnet.se 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=18lat=56.01628lon=12.72438layers=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] 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 hills...@cutr.usf.edu 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



 ___
 Talk-transit mailing list
 Talk-transit@openstreetmap.org
 

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 hills...@cutr.usf.edu 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 

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 arun.plane...@gmail.com 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] 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 michal.bor...@gmail.com:
 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]

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 jenuk1...@googlemail.com 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] 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 roland.olbri...@gmx.de 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_ids 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]

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 hills...@cutr.usf.edu 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 moment, we are rethinking the 

[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]

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 roland.olbri...@gmx.de 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