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 <michal.bor...@gmail.com> 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 <jwhelan0...@gmail.com> 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