Handle split lametro / lametro-rail stops

[remulasce]

metro bus and rail use separate agencies.

We currently swap in the correct agency right before heading to the network.
But the scraper-generated files are separated, too.

So we need to handle split mapping files now too.

[remulasce]

So the quick way to do this would be to just join the rail / bus tables.

Then use the existing everything, everywhere.

The problem is that then we have to have this specific agency code in the app forever.
And, we have to specially handle remaking the combined table.

[remulasce]

The other option is to actually handle having multiple tables.

The proper way to do this would be to extend Nighelles's regionalization component to specifically return which tables to use, then pull suggestions from all of them and merge them.

Each entry should then know what agency it comes from, so we can get rid of #192 and do all the regionalization up front in the input.

[remulasce]

In terms of implementation, the rest of the milestone doesn't depend on this. We can use only bus or only rail to test the rest of the app (the speedup part), then include the agency in the input stops, and then finally input the multi-agency support. Even if we don't get to this part, we would have enough to manually do an LA merge.

[nighelles]

I already made the combined table this afternoon for testing.

On Sun, May 3, 2015 at 11:40 PM, remulasce notifications@github.com wrote:

So the quick way to do this would be to just join the rail / bus tables.

Then use the existing everything, everywhere.

The problem is that then we have to have this specific agency code in the
app forever.
And, we have to specially handle remaking the combined table.

—
Reply to this email directly or view it on GitHub
#237 (comment).

[remulasce]

Ok, that's good.
I implemented the speed savings, which are pretty cool.
Now onto the rest of the fixing...

[remulasce]

This is indev.

Progress:

• Multiple databases are packaged into app. Including lametro, lametro-rail, actransit, and some assorted LA-region munis.
• Regionalization helper has been extended. It now knows which agencies should be queried, given that those agencies are setup at app load.
• Preloaded sql reader now can be set to read any database, and knows its agency, so it no longer depends upon LaMetroUtil

Remaining:

• The master sql provider needs to be able to handle multiple agencies, including creating readers and merging results.

Notes:
Tested out switched versions of the databases and was mildly impressed at how well the whole 'set it up at input stage' thing worked. It was like 2 LOC to switch between lametro and actransit.

[remulasce]

...And this is handled now!

And, pretty cleanly.

@nighelles

Notes:

-Backward compatibility is maintained. Stops now have Agencies, but if no agency is set, the Predictions will fallback to LaMetroUtil to figure out their agency.

• RegionalizationHelper is modified. The string you put in, representing a whole metro area, is ignored (except for the aforementioned fallback). Now you set a list of Agencies which will be searched.
• You need to do platform-specific work to take advantage of multi-agency.

Suggested work:

• call stop.setAgency with a hardcoded AcTransit wherever you currently make ServiceRequests. This should allow us to ditch the old workarounds for good.
• I think you can figure out how to actually implement multi-agency support. All the work should be done on the input section, before the Request is added.