Add option for alternate name of hwy_data directory

[jteresco]

As part of an attempt to get a preliminary railway version of TM up and running, I noticed that the directory name hwy_data is hard-coded into the site update program. This could become a command-line parameter, or possibly we could make hwy_data the default name when the repository is called HighwayData and rail_data when the repository is called RailwayData.

[jteresco]

An alternative is to rename it as plain data in both repositories, with the idea that it's obviously "highway data" or "rail data" based on the name of the repository. This would eliminate any need for future names like bike_data or ski_data or trail_data if TM continues to expand into other types of travel.

[yakra]

Plain data sounds reasonable. Keep it simple.

---

Similarly, maybe rename some classes, like
HighwaySegment -> Segment
HighwaySystem -> RouteSystem
etc.

[jteresco]

I think I'd like the site update to look for data by default. I don't think it's worth renaming it in the HighwayData repository. Git should be able to maintain history if we do, but I worry about getting everyone who has a clone up to date, especially when they have partially completed work not yet committed to the origin repository. We should able to add a symbolic linkdata -> hwy_data. The other repositories new data repositories can easily enough just have them renamed as vanilla data. @yakra would you like me to make that change in site update code, or would you prefer to make it?

[jteresco]

I'm going ahead and making this change since I have a good chance to do it tonight. Just in C++.

[yakra]

OK. Doesn't look like this would cause merge conflicts with anything I have in the pipeline.
Looks like 54fecf1 gets the 3 crucial files here. I'll take a closer look in a bit.

The crawl_hwy_data function still works of course, but may not have the most appropriate name anymore.
crawl_repo_data?
crawl_route_data?
crawl_data?

[jteresco]

I was thinking about that as well. I'm not sure what term works best..

[jteresco]

https://forum.travelmapping.net/index.php?topic=5647.msg31783;topicseen#msg31783

[yakra]

May be worthwhile to add an option to specify the data subdirectory, for compatibility with HighwayData commits before fe7ce91.

---

@jteresco wrote:

Just in C++.

Should this be taken as a semi-official "beginning of the end" for siteupdate.py?
It'll be compatible with existing HighwayData, but not new non-highway TM flavors going forward.

[yakra]

grep -ni HIGHWAYDATAPATH `find . -name \*.h` `find . -name \*.cpp`

This will produce merge conflicts.
Less important & can wait a bit, right?

[jteresco]

Definitely can wait.

[yakra]

Simply DATAPATH, maybe?

[jteresco]

Probably just DATAPATH is good. No rush at all on it.

[jteresco]

Should this be taken as a semi-official "beginning of the end" for siteupdate.py? It'll be compatible with existing HighwayData, but not new non-highway TM flavors going forward.

Yes, I am comfortable with only C++ being updated from now on. I doubt we'd have need to go back to Python for anything production going forward. The only possible advantages I see in maintaining Python are that 1) it's an independent program that we can use to see if the C++ code is producing the same results, and 2) I know the code much better than I know the C++ code.