> 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
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
