[Talk-us] Proposed small import of UTA bus stops

Mike N niceman at att.net
Sun Apr 21 19:41:06 UTC 2013


 > COUNTY --> is_in:county
> CITY --> is_in:city
> ACCESS --> wheelchair = yes|limited|no
> BENCH --> bench = yes|no
> LOCATIONID --> uta:stop_id

This looks good - I'm also glad that you also included the shelter tag 
in the data because that's useful.

  Re: is_in*; it seems to be redundant because the nodes should be 
actually located in those admin boundaries.  The normal argument for 
using is_in applies if a highway spans beyond its normal boundary, such 
as a state highway spanning into another state.    That might be true 
for this data, where a stop in one city is under another's city's 
transportation organization (but I'm not sure of the meaning of is_in 
for that case).

  Are the bus stops identified by the LOCATION_ID?  That is, is the 
traveling public aware of those numbers; for example texting that number 
from a sign to get the delay until the next arriving bus time?   If so, 
I'd argue for including those as a name instead of database ID.

   There's also a line of thought that says the database ID is not 
generally useful for point data because if people add and remove nodes 
manually, updated data sets still need to be conflated by location. 
Some decent node conflation scripts now exist, but I haven't used them.

   I'd also recommend tagging for both old and new transportation 
tagging schemes:

   highway=bus_stop
   public_transport=platform

  Some software finds it easier to support the new scheme because the 
layout makes more sense, while some renders only support the old scheme.

   Also, I saw some extra translation applied:

     <tag k='is_in:city' v='Salt Lake is_in:city' />
    and Park City

   Regards,

   Mike






More information about the Talk-us mailing list