proposal: add landmarks
Devin Braun
The landmark names would be searchable as origins or destinations in
addition to points of interest already shown on Google Maps.
Example:
stop_id,stop_name,stop_desc,stop_lat,stop_lon,zone_id,landmark_name
11111,Main St @ 4th Ave,Sea World Main Entrance,-123.4567,43.210,2,Sea
World
Joe Hughes
> The landmark names would be searchable as origins or destinations in
> addition to points of interest already shown on Google Maps.
Hi Devin,
Good idea--I agree that points of interest are helpful in many
existing trip-planning applications, since in many cases the street
addresses of large landmarks like airports, sports stadiums, parks,
and malls aren't well-known or even well-defined. Google Maps is
equipped to make use of POI data (as you can see by searching on
college names, airport codes, and even transit stop names today.)
Brandon, does Graphserver have any provision for POI-based search that
could use this information if it was in the GTFS?
It seems like the basic information you need for a POI is a name and a
geocode, so there are 2 main approaches I could see to POI
representation in GTFS:
(1) Turn stops.txt into something that represents locations other than
just stops, and add a location_type field to the file that determines
which type of location it is. (This would also make it easier to
provide station entrances--stay tuned for a proposal on that.) The
only field in stops.txt that's only specific to transit stops right
now is zone_id, which isn't too bad. Example:
location_type:
Defines what sort of location a stops.txt row represents.
0 (or omitted) - transit stop
1 - point of interest
Example stops.txt:
stop_id, stop_name, stop_lat, stop_lon, location_type
11111, SeaWorld San Diego, 32.761836, -117.226868, 1
(2) Create a separate pois.txt file containing just names and
geocodes:
Example pois.txt:
poi_name, poi_lat, poi_lon,
SeaWorld San Diego, 32.761836, -117.226868
Who has POI data that they're willing to post in these proposed
formats so that we can see how they behave with real data?
Joe Hughes
Google Transit
Devin Braun
> (1) Turn stops.txt into something that represents locations other than
> just stops, and add a location_type field to the file that determines
> which type of location it is.
This is an interesting idea, that when coupled with your proposal for
station entrances, would allow an agency to show the actual locations
of certain entrances, stations, and POIs to get better walking
directions. In addition to station entrances, it could allow an
agency to basically define a "shortcut" or walking path off the street
network to any stop or station. I know that other trip planning
software programs provide this functionality.
> (2) Create a separate pois.txt file containing just names and
> geocodes:
>
> Example pois.txt:
> poi_name, poi_lat, poi_lon,
> SeaWorld San Diego, 32.761836, -117.226868
>
This proposal would be very helpful to add many different searchable
places that transit patrons are interested in, such as major transit
centers, shopping malls, schools, etc. especially since most
passengers don't know the street address or intersection of where
they're going. However, I would suggest adding stop_id as an optional
field to this file. This would associate a certain stop to a
searchable point of interest. This would be very beneficial for
people going to an airport, where there might only be one geocoded
location, but several stops all at different terminals. The person
should be able to receive a trip plan to the bus stop that is
considered closest to their destination to avoid lengthy walks around
parking lots or pedestrian-unfriendly places. The lat/long would be
the geocoded location of the actual point of interest and the bus stop
might have a different geocoded location, so the final walking
directions to the destination would be between the two coordinates.
Example pois.txt:
poi_name, poi_lat, poi_lon, stop_id
SeaWorld San Diego, 32.761836, -117.226868, 11111
San Diego Airport Commuter Terminal, 32.451254, -117.562454, 22222
San Diego Airport Terminal 1, 32.451222, -117.562488, 33333
San Diego Airport Terminal 2, 32.451288, -117.562668, 44444
The Transit Store, 32.245556, -117.68421
Devin Braun
San Diego MTS
bad...@gmail.com
The GTFS could describe non-stop points of interest by simply
including them in the stops list. For example, Joe's example would
simply read:
stop_id, stop_name, stop_lat, stop_lon
11111, SeaWorld San Diego, 32.761836, -117.226868
or even allow NULL in th stop_id, like:
stop_id, stop_name, stop_lat, stop_lon
, SeaWorld San Diego, 32.761836, -117.226868
The description of the stops table would be modified to read:
"stops.txt - Required. This file contains information about individual
locations where vehicles pick up or drop off passengers and non-
disembarkation points of interest."
If a stop_id is null or never referenced by a stop_time it could still
be used to geolocate a point of origin or destination.
-B
Joe Hughes
> In addition to station entrances, it could allow an
> agency to basically define a "shortcut" or walking path off the street
> network to any stop or station. I know that other trip planning
> software programs provide this functionality.
Interesting--could you tell me more about how you would want to define
walking paths?
> > (2) Create a separate pois.txt file containing just names and
> > geocodes:
> >
> > Example pois.txt:
> > poi_name, poi_lat, poi_lon,
> > SeaWorld San Diego, 32.761836, -117.226868
> >
> I would suggest adding stop_id as an optional
> field to this file. This would associate a certain stop to a
> searchable point of interest. This would be very beneficial for
> people going to an airport, where there might only be one geocoded
> location, but several stops all at different terminals. The person
> should be able to receive a trip plan to the bus stop that is
> considered closest to their destination to avoid lengthy walks around
> parking lots or pedestrian-unfriendly places. The lat/long would be
> the geocoded location of the actual point of interest and the bus stop
> might have a different geocoded location, so the final walking
> directions to the destination would be between the two coordinates.
Could you give an example from the MTS data where the stop that's
closest to a POI isn't the preferred one to take? If we can avoid the
need to maintain explicit mappings between POIs and stops, that would
mean less work for the data providers. (It would also let us avoid
figuring out what to do when two different routes have two different
"best stops" for a given POI.)
I imagine that you've come across situations in your work where the
explicit stop association was useful, though, so if you could provide
examples of those, it would help illuminate our discussion here.
Thanks,
Joe Hughes
Google Transit
Joe Hughes
The minimalism and simplicity of your proposal is certainly in line
with the philosophy of the GTFS! If we did POIs this way, though, we
wouldn't have any way to tell between POIs and stops with no service.
It's been fairly common to have unused stops in initial feeds that
we've gotten from various publishers--the FeedValidator utility checks
for them--so I'd be worried that data providers would end up
expressing those as accidental POIs.
Joe Hughes
Google Transit
T Sobota
with named locations (name, geocode, address, category), used for
their associated trip planning interface, that would export nicely to
a proposed pois.txt type of feed file.
Also, for clarification, can Google users presently use locations that
happen to be stored in their user profile from the Google Maps as an
origin or destination in the Google Transit environment? If not
available, this would seem to be a nice function whereby users could
more easily generate transit itineraries from frequently used
locations that they store to their profile.
Joe Hughes
> Our particular transit scheduling software package contains a table
> with named locations (name, geocode, address, category), used for
> their associated trip planning interface, that would export nicely to
> a proposed pois.txt type of feed file.
Thanks for the data point, Tim.
> Also, for clarification, can Google users presently use locations that
> happen to be stored in their user profile from the Google Maps as an
> origin or destination in the Google Transit environment? If not
> available, this would seem to be a nice function whereby users could
> more easily generate transit itineraries from frequently used
> locations that they store to their profile.
Unfortunately, the Google Maps address book feature is currently
disabled on Google Transit. (This will likely change in the future.)
However, note that you can specify POIs that Google Maps recognizes to
plan trips in Google Transit--for example, "Portland State University"
to "PDX" works fine. (We should also consider the needs of
applications other than Google Transit when designing new GTFS
features.)
Joe Hughes
Google Transit
Mike Gilligan
source transit applications but I think the addition of POIs should be
looked at carefully, before an over-simplified approach is adopted.
Here is my idea, though more complex than those above. Add 3 files to
the GTFS for POIs/landmarks, landmarks.txt or pois.txt to define the
landmarks, landmark_alias.txt to define alias names such as Portland
International Airport = PDX, and landmark_stops.txt to define an
explicit relationship between landmarks and stops. All files would be
optional. If a landmarks.txt is included in the feed but not a
landmark_stops.txt, Google could use closest stop.
landmarks.txt (optional)
landmark_id, landmark_name, latitude, longitude
........
164,Rose Quarter Transit Center,45.531533,-122.666718
178,Washington Park Zoo,45.509748,-122.714644
213,Portland International Airport,45.589848,-122.599268
landmark_alias.txt (optional, requires landmarks.txt)
landmark_id, alias_name
........
178,Zoo
178,Oregon Zoo
213,PDX
landmark_stops.txt (optional, requires landmarks.txt)
landmark_id, stop_id
........
164,1097
164,1098
164,2592
164,8340
164,8377
164,11814
178,10120
178,10121
178,10299
213,10579
My 2 cents,
-Mike