Issue 357 in googletransitdatafeed: Merge Warnings - Stops.txt

[googletran...@googlecode.com]

Status: New
Owner: ----

New issue 357 by herbert....@gmail.com: Merge Warnings - Stops.txt
http://code.google.com/p/googletransitdatafeed/issues/detail?id=357

What steps will reproduce the problem?
1. run merge tool to merge two separate feeds
2.
3.

What is the expected output? What do you see instead?
Expect the merge to run successfully but receive warnings:
1) there are stops from the old feed and the new feed that could not be
merged because the stop names did not match.
2) There are stops in the old feed and new feed with the same id but they
could not be merged because they are too far apart.

Our transit agency relocates, eliminates, and add bus stops in coordination
with each schedule change based on request or consolidation studies.

It would be helpful if these changes would be reflected in the merged feed
instead of being dropped all together.


What version of the product are you using? On what operating system?
1.2.12
Windows XP Professional

Please provide any additional information below.

[googletran...@googlecode.com]

Comment #1 on issue 357 by devin.br...@gmail.com: Merge Warnings - Stops.txt
http://code.google.com/p/googletransitdatafeed/issues/detail?id=357

I think I know how this works...please correct me if I'm wrong -

The stops aren't dropped - they just aren't merged together, so there are
two records for the stop in your merged feed instead of one. One of the
records applies to the old schedule and one applies to the new schedule.
For most agencies, a customer will never notice the difference. But the
merge tool will change the stop_id throughout all the files in the feed (I
think it appends _a and _b to the stop_id). So if you have external systems
that reference these stop_ids, I don't recommend letting the merge tool
change them.

You have a couple options here if you want to just have one record and keep
the stop_id the same.

1) Go into the old feed and change the stops.txt values to match the new
version (location and name). Unless you are moving the stop on a certain
date, the stop has probably already been moved/changed and this would make
your feed more accurate.

2) When you are running the merge tool, if only the location has changed
and not the name, you can add the --largest_stop_distance flag and give it
a large value so that the stops will be merged no matter how far apart they
are.