On 15 Jul 2010, at 11:21, Joe Hughes wrote:
Peter,
I think it would be helpful to look at GTFS data from a few diverse
providers when testing ideas about imports, as data tends to reflect
the historical practices of the particular agency in ways like
naming patterns, which details are present, etc. There's a great
deal of GTFS data on gtfs-data-exchange.com, but I'd recommend, say,
TriMet and Port Authority of Allegheny County in addition to the
SFMTA data that you're already examining.
As you mentioned, the street and directional information should be
optional, as there are boundary cases like stops in shopping centre
parking lots, large station complexes, and underground private ways
which might make it difficult to provide reasonable street/direction
values. By and large I could see how that information would be
useful for snapping stop points to varying road network data sets
(setting aside the issue of how to deal with stop points on traffic
islands in the centre of the road). In general, though, we should
be careful not to depend too much on things which are likely to be
available from source data in only some parts of the world.
(Consider places where not all roads have agreed-upon names.)
Thanks for your continued efforts on this issue!
Thanks Joe,
We are going taking a look at Chicago data next as I am going to be
there shortly and we will then look at the others you recommend to see
what will work in different places. Btw, if anyone has any contacts in
Chicago then do let me know.
In general in osm there should nearly always be a highway way
associated with on-street stops which is used by the vehicle and there
should also be a node where people wait for the vehicle by the way.
Where the highway doesn't have a name, or has a name that is not
unique then I would suggest that a relation is used to bind the stop
to the way.
Some bus bays don't usefully have a direction - if they are reverse
out bus bays for example, and also in some other situations but these
are generally not considered to be 'on-street'.
With reference to the proposal to define the use of the bus stop by
the services that use it I think one is in danger of getting into
circular definitions which get confusing when mistakes are make. Which
is wrong, the stop, or the service? In the UK it has been very useful
to first settle which side of the road the bus stops are on using the
bearing and then to ensure that the correct services are connected to
them and sort them out any cross wiring which might mean moving some
services to the other stop of the pair.
Re stops in the middle of the road, the rule at the ordnance survey in
the UK is that a road should be represented as two parallel ways where
there is a central barrier, divider or structure such as a bus stop in
the middle. I am not sure how a bus stop would be described in NaPTAN,
possibly there would be two nodes, one for each direction or possibly
just one with no bearing.
As you say Joe, lets review many different systems and see what will
work in different places.
Regards,
Peter
Cheers,
Joe
On Thu, Jul 15, 2010 at 8:53 AM, Peter Miller <peter.mil...@itoworld.com
> wrote:
I have been looking at the GTFS data for San Francisco over the past
few days and considering how one could do a bus stops/tram stop
import for the place and more generally for the GTFS data.
However... in the process I want to be be 100% clear which road the
stop serves and in which direction to improve the quality of map
rendering which is not possible with the current bus stop tagging.
Here is the general bus stop positioning problem for bus stops in
osm as I see it.
The osm community has agreed to place the bus stop beside the road
at the place where people wait which is good, however if that stop
is close to a junction or to two roads that run parallel then it is
not clear which road it serves.
This is a problem when it comes to creating clear map rendering
where one wants to snap the stop to correct side of the correct road
and not left them floating as they are currently. An additional
complication comes when one wants to position the symbol correctly
when the road widths on the rendering are exaggerated requiring the
node to be nudged sideways for it to not appear within the junction
itself.
I propose that we formalise a couple of NaPTAN tags into the main
bus stop schema and try these with a SF import.
'Street' tag: to indicate the name of the associated street
'Bearing' tag: to indicate the direction in which vehicles leave the
stop, to be clear this is the immediate direction taken, not a sight-
light to the next bus stop. NaPTAN uses compass points N, NE E etc'.
Here are some examples of where the addition tags are useful. In the
first case it is not clear without the street tag which of two
parallel streets are served, and in the second it is not clear which
of three nearby streets are served.
http://www.openstreetmap.org/browse/node/816289382
http://www.openstreetmap.org/browse/node/817535874
With these tags we should then be able to do an automatically
import. Here are some initial observations on the data.
In general the data is good except for a few places where there
appear to be duplicates for some stops in similar but not identical
locations. This would require a manual clean-up of some busy streets
following the import.
Stops on either side of the road have the same name. This is not a
problem if the bearing field is set correctly from the schedule data
- setting the bearing is non-trivial but can be done.
The stop naming is 'street & street' where the first street name is
for the street that the stop serves. This will allow the stops to
have the 'street' field set.
Sometimes the location of the stop is wrong and places the stop on
the other side of the road. This can be sorted manually afterwards
given that the bearing field and street fields will show what is
actually required.
There is a licensing issue for the SF data which is currently only
available on a 'limited, and revocable license' which 'does not
include any right to sublicense'.
http://www.sfmta.com/cms/asite/transitdata.htm
Clearly this is not sufficient as it stands and we would need to get
approval for what we wanted prior to doing the actual work.
Any thoughts on the tagging proposal?
Regards,
Peter
_______________________________________________
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
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
