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!
It is probably worth clarifying that in osm the only times that one
would need the additional bearing or street tags is when there is an
element of doubt about which the road is the correct one due to the
bus stop being close to a junction or being directly between two close
parallel roads.
By contrast as a gtfs data supplier where the final road datasets
unknown then it would be advisable to always provide a bearing for on-
street stops in case the location of the roads in the roads dataset
are offset from the position of the stops in the gtfs dataset due to
accumulated positional errors resulting in the stops being positioned
on the wrong side of the road.
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
