frad/fram: France Routes Départementales / Routes Métropolitaines

[si404]

The region names within the future D system names should be English, not French!

OK, so that's just Brittany and Normandy's names changing...

Seriously - we've not Anglicised the new names (cf wikipedia), because we don't do that anymore as it is 'insulting'. Which is odd - it was a badge of honor coming from importance - if we didn't care, we wouldn't make the place name easier for us!

And it's not like we don't have names - Bourgogne has been Burgundy for a millenium, etc. But then the Côte-d’Azur, as a holiday destination, has long just had the French name (see also Spanish Costas).

[si404]

Is there an issue with concurrencies not quite being as they should that needs to be sorted out? I could potentially help out here...

Thanks for that - the concurrencies checker you've employed will always be useful.

TBH, it doesn't matter that much if they aren't fully concurrent - what matters is that concurrencies exist within the FRA region, and within the chopped regions. The concurrencies is a way of checking that the chopping has been done correctly - by matching stats and spotting discrepancies.

[si404]

@Si, I guess that you will provide all new fra list file entries again? Should we warn user in advance in "Welcome & Notices" and/or on the site?

When we get to that, we get to that.

Obviously there's no rushing in here.

[si404]

before any additional countries are broken into regions, I'd like to see if we can get that done with the test DB to avoid some of the admittedly minor issues that have arisen here.

Fine. I'd totally forgotten the test database existed!

As you admit, these issues are minor - they mostly come from michih being helpful and ignoring "IGNORE TEST" instructions to help with the process of splitting stuff. I'd argue that they were not even issues.

[si404]

we could duplicate the 40 files and name them test_michih, test_si404 etc.

I'm working on a way to automatically replace lines in .list files. Stay tuned...

That will be excellent

[michih]

The region names within the future D system names should be English, not French!

OK, so that's just Brittany and Normandy's names changing...

And Corse

Seriously - we've not Anglicised the new names (cf wikipedia), because we don't do that anymore as it is 'insulting'.

? We always did (since TM times) and we always do for all countries and regions. `
Who says that it's "insulting"?

[si404]

Seriously - we've not Anglicised the new names (cf wikipedia), because we don't do that anymore as it is 'insulting'.

? We always did (since TM times) and we always do for all countries and regions. `
Who says that it's "insulting"?

By 'we' I mean the Anglophonic people (especially Brits). The English name for Hauts-de-France is Hauts-de-France, rather than Upper France. We stopped creating English exonyms, and rolled back a few.

And yes, I don't get the insult either! At least not here - I get it with stuff like Chennai (nee Madras), but not here. I guess the assumption is that we are au fait enough with French, that we can pronounce it as the natives do, but it mostly seems like we're lazy.

And don't get me started on the mess that is "Bayern Munich"! Especially as we go with Torino, Napoli, Roma, etc despite English exonyms for those cities.

[michih]

Ok, got it. Thanks.

And don't get me started on the mess that is "Bayern Munich"! Especially as we go with Torino, Napoli, Roma, etc despite English exonyms for those cities.

Germans mix everything and say "eff zeh" Liverpool instead of "eff si" Liverpool and Arsenal "London" or Chelsea "London" (German with "o" not "ʌ").

[yakra]

Connected routes should be listed in the _con.csv in the same order as the points in the parent, unsplit file, yes?
E.G., fraar;A9;;;fraocc.a009,frapac.a009
----> fraar;A9;;;frapac.a009,fraocc.a009
...because fra.a009 starts at "21", where frapac.a009 starts, proceeding later to "PAC/OCC", where fraocc.a009 starts, etc.

My .list line replacer thingamajig relies on this assumption.
I'll make these changes in my local branch, and continue debugging...

https://github.com/TravelMapping/HighwayData/pull/2750

[yakra]

Is there an issue with concurrencies not quite being as they should that needs to be sorted out? I could potentially help out here...

Thanks for that - the concurrencies checker you've employed will always be useful.

TBH, it doesn't matter that much if they aren't fully concurrent

Assuming by "fully concurrent" you mean all of the segments (ie, everywhere) in each system. The logs were arranged by system mostly because it was easiest to code, the way the data is stored -- iterate thru HighwaySystems, then iterate thru Routes, then iterate thru HighwaySegments...

what matters is that concurrencies exist within the FRA region, and within the chopped regions.

Yes. The chopped systems take care of the chopped regions, and the systems unique to FRA take care of FRA itself.
The checks were restricted to regions beginning with "FRA" to avoid checking outside France in the EUR systems.

The concurrencies is a way of checking that the chopping has been done correctly - by matching stats and spotting discrepancies.

Yep, 'swhat I figured was going on. Every segment in an existing system should have a corresponding segment in a new chopped system, thus every segment should have a concurrency list, with an even number of concurrent segments.
This should be a little more foolproof than checking just the raw mileage stats of each system, as it's possible that a missing border point or extra shaping point could not affect the mileage of the corresponding systems, leaving both of their mileages the same in region.php. Not likely, but possible.

Due diligence:
One missing highway on a given segment yields an odd number of concurrent routes; these cases get flagged. We've found & fixed a few of these.
Two missing highways on a given segment yield an even number of concurrent routes; these don't get flagged. It may not be too likely we've missed anything, but checking for a concurrent same-designated+bannered route in a different region is a good idea.

Toward the future:
Right now, the concurrency checker is hard-coded to check FRA & its systems. I want to adapt it to be useful in the future.
WRT compiling a list of systems, I think the simplest way to do it is to assume a scenario like we saw here: for each "connected" system in the parent country, add 'r' to the end to get the corresponding "chopped" system. Any potential problems with that; shall we make that the "official" way to check concurrencies during a split-up, assuming there are more that will be done? Edit: LOL nevermind; I did it anyway!

[yakra]

I was checking out the intentionally broken concurrencies just south of the Boulevard Péripherique. Don't know whether E50 is intentionally separate from A6b/E15, but the the point at 1(A6b) should be on both roads, what with the Texas-style inner<->outer sliproads here.

Labels:
frahdf.e15: IDF/HDF -> HDF/IDF
frahdf.a028: ToA16 -> E402_N -- unless, are you not using E routes in labels at all in FRA (sorta like the Trans-Canada Hwy)? Vanilla A16?

[yakra]

Per a note in dave1693.list:
A6a & A6b look like an intentionally broken multiplex. The north endpoint of A106 could match one or the other; matches neither.

[yakra]

The .list line replacer is complete.
UserData @ d3683391b9af43962eb2c45e2a35718fae559a6b
HighwayData @ 5c83f07fe6f35bbd8544e0c15dc6d494bffcd988
    si404 list  | diff
   michih list  | diff
  dsaneus list  | diff <-- a good example of a very straightforward diff.
everybody lists | diffs

This assumes that each chopped route in the original full region corresponds 1:1 to a connected route in new chopped regions. From my inspection of the connected route CSVs, this appeared to be the case.

New lines are listed in "canonical" order from the beginning of the connected route to the end, E.G.
FRA N2 FRA/BEL N370
becomes
FRA-IDF N2 N370 IDF/HDF
FRA-HDF N2 IDF/HDF FRA/BEL
I could enhance this so that the "direction" of the original .listed segment is retained, but I'm thinking this is too much labor for too little gain.

GitHub:
https://github.com/yakra/DataProcessing/tree/tmg2_cpp_redo/siteupdate/cplusplus
Or more permanently, here

For due diligence purposes, I should probably still add that additional sanity check to the concurrency checker, noted in redgreen text above.
Edit: Done. Looking good.

[michih]

I could enhance this so that the "direction" of the original .listed segment is retained, but I'm thinking this is too much labor for too little gain.

Thanks. I think it's fine. Is data automatically updated with Jim's site updates? I guess it's not and it should be fine.
We would just need to update it once again before the split is going live and copy the latest user list file entries to the forum so that each traveler can catch his lines (to preserve data long-term because some user do rarely check our site).

I like the idea with old entry commented and new lines directly subsequent.

[yakra]

Is data automatically updated with Jim's site updates? I guess it's not and it should be fine.

Correct, not updated with Jim's site updates.
I only added this feature to the C++ siteupdate program, with no plans to add it to siteupdate.py.
One option could be to temporarily add a line to localupdate.sh, but I can just keep on updating these manually as HighwayData & UserData get updated; this will be easy.

We would just need to update it once again before the split is going live and copy the latest user list file entries to the forum so that each traveler can catch his lines (to preserve data long-term because some user do rarely check our site).

Rather than add all that text to the forum, maybe just keep the new .lists on the server, and keep a link in the forum?