I add service=something to the relation to roughly describe what the type
of service is. The ones I use a service=city, service=country,
service=express, service=park_and_ride.
I also add a rough weekday frequency (number of buses per hour off-peak).
That way people can pick out stuff they want
Hello,
The problem with rendering transit lines right now is that the busy lines
are rendered the same as the lines that go a few times a day. Those
differences between lines should be seen right away, but we don't have that
information in the database right now.
I agree that the best solution
Personally, I think adding transit schedule data to OSM is not a good idea.
Firstly, in many areas, schedules are highly variable over time, so
this sort of information tends to become obsolete soon after it is
added.
Secondly, GTFS is already a good, widely used, open format for transit
On Wed, Feb 29, 2012 at 8:03 AM, Bryce McKinlay bmckin...@gmail.com wrote:
Secondly, GTFS is already a good, widely used, open format for transit
schedules. Introducing a new set of tags for this stuff in OSM would
be like reinventing the wheel. In many cases GTFS data is provided and
kept
Dana srijeda, 29. veljače 2012., korisnik Bryce McKinlaybmckin...@gmail.com
je napisao:
If its just having a service frequency hint for renderers that is
required, then I'd suggest keeping it very simple. For example,
transport_frequency=frequent,
With my tag, it would be
Am 29.02.2012 16:07, schrieb Janko Mihelić:
Hello,
The problem with rendering transit lines right now is that the busy lines
are rendered the same as the lines that go a few times a day. Those
differences between lines should be seen right away, but we don't have that
information in the
