Re: stops.txt: add city, state/province, postal code as optional fields

[Dan]

Does anyone have any negatives to this?  It seems like an easy and non-breaking change if they are added as optional.

On Wednesday, March 20, 2013 10:56:38 AM UTC-4, Dan wrote:

As a consumer of this data, i have to either force one value for each when i import this data or do a reverse-geocode based on the coordinates.  The entity that creates the stops.txt file likely knows this information and could populate it if it was sanctioned.

The usage for me is to import the stops into a schema that doesn't allow NULLs for those columns.  For most people they would be decorative but i would suppose that this information could be valuable under certain circumstances.

The reverse geocoding elements from the MS maps REST interface are:

AddressLine

AdminDistrict (state)

AdminDistrict2 (county)

Locality (city)

PostalCode

I am not stating we have to use these but it is a good place to start the discussion.

[Brian Ferris]

If agencies are interested in providing it and you using it, then go for it.  My one comment is that I would make the fields consistent with the GTFS field-naming style (prefer under_scores to CamelCase).  I'd also prefer administrative area to district, as area seems to be more commonly used in my experience.  Finally, I'd add country, so you can take your transit app worldwide ; )

So, as result:

address_line (eg. "221B Baker Street")

admin_area (state)

admin_area_2 (county)

locality (city)

postal_code

country

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
To post to this group, send email to gtfs-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/gtfs-changes?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dan Holmes]

the field names you have are fine with me.  Are these going to be added to the spec's documentation?  I might have a hard time convincing anyone to add them if they aren't.

[Brian Ferris]

So the general rule-of-thumb is that we don't add anything to the spec UNTIL you convince someone to start providing the data ; )  As outlined at https://developers.google.com/transit/gtfs/changes, we'd like to see someone producing data using the proposed extension along with someone actually parsing and using it in some way.  The goal is to avoid adding a lot of speculative things to the spec that no one will actually be able to produce or consume in practice.

[Dan Holmes]

Thank you for the direction; i hadn't read that.  The feeds i produce will now include these fields and i will encourage my producers to include that information as well.