stop_features description

[J. R. Westmoreland]

Please forgive me for asking this here …

I’m trying to find the description for the stop_features file.

Could someone please point me to it?

I’m ready to use it in some code.

 

Thanks in advance.

 

Regards,

J. R.

 

--------------------

J. R. Westmoreland

E-mail: j...@jrw.org

Twitter: GeneralJR

 

[Joe Hughes]

Hi J.R.,

Mike Gilligan from TriMet posted a proposed format for stop_features last March:
http://groups.google.com/group/gtfs-changes/web/stop-amenity-proposal?hl=en

That followed from this earlier thread:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/5910790204c0d5b2

So far, it looks like TriMet has been testing this extension from the
publisher side, though I haven't heard of any consumers. Having a
consumer of that data will help move this proposal closer to inclusion
in the official spec, so please let this group know if you start
testing an app built on this information.

Thanks,
Joe

[J. R. Westmoreland]

Thanks, Joe.
Sendero is going to use this data, if possible, in the GPS system they sell
for the use of blind folks.
Charles and I will be posting a more detailed posting soon.

Thanks,

J. R.

--------------------
J. R. Westmoreland
E-mail: j...@jrw.org
Twitter: GeneralJR

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Joe Hughes
Sent: Thursday, September 03, 2009 4:04 PM
To: gtfs-c...@googlegroups.com
Subject: [gtfs-changes] Re: stop_features description


Hi J.R.,

Mike Gilligan from TriMet posted a proposed format for stop_features last
March:
http://groups.google.com/group/gtfs-changes/web/stop-amenity-proposal?hl=en

That followed from this earlier thread:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/5910790204c
0d5b2

So far, it looks like TriMet has been testing this extension from the
publisher side, though I haven't heard of any consumers. Having a
consumer of that data will help move this proposal closer to inclusion
in the official spec, so please let this group know if you start
testing an app built on this information.

Thanks,
Joe

On Thu, Sep 3, 2009 at 2:48 PM, J. R. Westmoreland <j...@jrw.org> wrote:

> Please forgive me for asking this here .

[brett....@gmail.com]

On Sep 3, 3:03 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:

> So far, it looks like TriMet has been testing this extension from the
> publisher side, though I haven't heard of any consumers.  Having a
> consumer of that data will help move this proposal closer to inclusion
> in the official spec, so please let this group know if you start
> testing an app built on this information.

I've been using the stop_features data from TriMet for a while now.
Results at: http://www.poi-factory.com/node/6753

-- Brett Warden

[J. R. Westmoreland]

Brett,

I guess that makes two of us now.
The Java code I have running now handles the dtat if is exists.

J. R.

--------------------
J. R. Westmoreland
E-mail: j...@jrw.org
Twitter: GeneralJR

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Brett....@gmail.com
Sent: Friday, September 11, 2009 9:55 AM
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: stop_features description

[Joe Hughes]

Thanks for the info, Brett. Can you say more about how you treat the
experimental TriMet stop_features data in your conversion?

Thanks,
Joe

[brett....@gmail.com]

In my software, written in Perl, I defined a hash to catalog all the
proposed features:

my %features = (
1000 => "Shelter",
2000 => "Furniture",
2100 => "Bench",
2200 => "Trash Can",
2300 => "Bike Storage",
2310 => "Bike Rack",
2320 => "Bike Locker",
2400 => "Vending Machine",
2410 => "Ticket Vending Machine",
2420 => "Food Vending Machine",
2500 => "Phone",
3000 => "Pavement Features",
3100 => "Curbcut",
3200 => "Sidewalk",
3300 => "Paved Landing",
3310 => "Paved Front Door Landing",
3320 => "Paved Back Door Landing",
3400 => "Crosswalk",
4000 => "Information Display",
4100 => "Schedule Display",
4110 => "Printed Schedule Display",
4120 => "Electronic Schedule Display",
4200 => "Real Time Arrival Display",
5000 => "Lighting",
5100 => "Shelter Light",
5200 => "Street Light",
);

As I iterate through the stops, I append the individual amenities
(sorted by feature_type) to the textual description I've built up for
the stop. I'm creating CSV files for import into Garmin navigation
devices, where the third field is the item's title, and the fourth
field is the description.

A sample entry like this:
-122.677654,45.518878,"7625: SW 5th & Morrison","Stop ID 7625/Fareless
Square
Southbound stop in Portland
1: Vermont
8: Jackson Park/NE 15th
12: Barbur/Sandy Blvd
94: Sherwood/Pacific Hwy Express"

becomes:

-122.677654,45.518878,"7625: SW 5th & Morrison","Stop ID 7625/Fareless
Square
Southbound stop in Portland
1: Vermont
8: Jackson Park/NE 15th
12: Barbur/Sandy Blvd
94: Sherwood/Pacific Hwy Express

Shelter
Bench
Curbcut
Sidewalk
Paved Front Door Landing
Paved Back Door Landing
Crosswalk
Street Light"

So, it's really just supplemental information that's displayed only
when you actually view the details for a stop. Currently, if the
proposed specification changes, I will have to update my code. It does
warn me, however, if it encounters an unknown feature_type.

-- Brett Warden

[J. R. Westmoreland]

Brett,

I guess good minds run alike.
I have done something very similar with the stop feature data in the Sendero
Group GPS navigation system for visually impaired users.
I say that because I also have produced a HashMap for the data using Java.
My initial output almost looks like yours with just a slight bit of
reordering.
I will, however, be storing the data in a SQLite database of transit stops
such that when you approach, etc, one of them using the system it will tell
you that you are approaching stop such and such and you can then ask for the
description of the stop which will then give you the rest of the data.

The only tricky thing I'm doing is having the Java code call some JNI C++
code to use some of our existing COM modules.

Best,

J. R.

--------------------
J. R. Westmoreland
E-mail: j...@jrw.org
Twitter: GeneralJR

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Brett....@gmail.com
Sent: Friday, September 25, 2009 1:48 PM
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: stop_features description

[Joe Hughes]

J. R., are you just creating a textual description that includes all
the amenities, like Brett is, or are you doing more in-depth
processing/filtering? So far, it sounds like Brett's use case could
conceivably be met using a single free-text field.

Joe

[J. R. Westmoreland]

I'm reading the stops file for each stop retrieving the stop_id and lat/lon.
I then read the stop_features file with that stip_id to generate a list of
features at the stop.
I then have to pick through the stop_times, trips and routes file to
generate a set of routes that are serviced at this stop.
After all this data is collected I then process the data such that it can be
read as a map feature by the routing engine.
As part of this processing the feature gets an address and other GIS data.
The rest is currently handled as descriptive information which is available
to the user.

That is how it currently works. Well, at least it would work that way if I
could solve the last hitch with JNI. :)

[brett....@gmail.com]

On Sep 28, 1:28 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> So far, it sounds like Brett's use case could conceivably be met using a single free-text field.

While a single text field would be slightly easier for me, I'm still a
fan of the separate table, if nothing else, for the sake of avoiding
redundant text. It might be interesting to include another table that
maps amenity IDs to textual descriptions so I don't have to hard-code
it, but that threatens the use of consistent codes. Alternately, such
a table could be published along with the specification itself.

In J.R.'s application, I see a use case for filtering nearby stops by
presence of shelter, especially in rainy Portland.

-- Brett

[J. R. Westmoreland]

Brett,

I like that. We don't have a way to deal with your type of idea but the
right application could be really nice.
The ability to say show me the closest stops to me which have a shelter, or
some other amenity could be a great function in an application.

Regards,

J. R.

--------------------
J. R. Westmoreland
E-mail: j...@jrw.org
Twitter: GeneralJR


-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Brett....@gmail.com
Sent: Tuesday, September 29, 2009 9:47 AM
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: stop_features description

[Joe Hughes]

Yes, I definitely agree that the semantic information about amenities
*could* be useful--I'm mostly trying to figure out whether it's being
exercised by any existing applications, or whether everyone is just
dumping it back into a blob of text.

Joe