FLOAT -> DOUBLE in four SQL tables / flippedroutes.log

[yakra]

FLOAT -> DOUBLE in four SQL tables
https://forum.travelmapping.net/index.php?topic=2065.msg26937#msg26937

• overallMileageByRegion
• systemMileageByRegion
• clinchedOverallMileageByRegion
• clinchedSystemMileageByRegion

---

Along for the ride:
flippedroutes.log lists routes that are flagged as reversed for processing ConnectedRoutes in 6-field .list entries.
It's very inexpensive to write, super-easy to code, and should come in handy when I want a quick reference for test cases to use in development.

[jteresco]

Thanks. Good to go for the next site update?

[yakra]

Good to go.

[jteresco]

And now a site update using this has completed.

[yakra]

I looked at https://travelmapping.net/logs/flippedroutes.log just for giggles. Chromium thinks it's in Scottish Gaelic. Giggles confirmed.
The results of translating it to English are... strange.

[michihdeu]

I looked at https://travelmapping.net/logs/flippedroutes.log

I never realized flippedroutes.log. What does it mean? It lists routes I maintain and I'd like to know if anything is wrong with them.... 😄

[yakra]

It's brand new with this pull request.
From the OP:

Along for the ride:
flippedroutes.log lists routes that are flagged as reversed for processing ConnectedRoutes in 6-field .list entries.
It's very inexpensive to write, super-easy to code, and should come in handy when I want a quick reference for test cases to use in development.

There won't be anything wrong with these routes unless flagged DISCONNECTED_ROUTE.

I guess I should put a blurb under Web Site Development and Site Update Logs

[michihdeu]

There won't be anything wrong with these routes unless flagged DISCONNECTED_ROUTE.

but why are they listed?

[yakra]

should come in handy when I want a quick reference for test cases to use in development.

Or, it can help streamline shell scripts.
For example, for the one in #490 to be fully functional it has to accommodate flipped routes for multi-region .list entries.
I could have the shell script re-create all the samesteps siteupdate does to flag a route as reversed -- a moderate PitA from scratch in bash -- or I could just say

if [ `curl https://travelmapping.net/logs/flippedroutes.log | grep -c ^$root$`== 1 ];then thing=$stuffelse thing=$SomethingElsefi

Much simpler!

but why are they listed?

Or do you mean, why are they flagged as reversed in the first place?
For some routes, the point order in the chopped route mismatches the root order in the connected route. For example,
MO US275chopped | connected
PA I-295chopped | connected (note how for the connected route, the PA exits count down from 10 to 3)
These routes must be taken into account in order for multi-region .list line processing to work.
https://forum.travelmapping.net/index.php?topic=3648.msg19036#msg19036
https://forum.travelmapping.net/index.php?topic=3652.msg19105#msg19105

[michihdeu]

There won't be anything wrong with these routes unless flagged DISCONNECTED_ROUTE.

No, they are listed because there IS something wrong although they are NOT flagged DISCONNECTED_ROUTE!
I fixed the routes mentioned in flippedroutes.log but:

Reported correctly:

frages.n019
frabfc.n019
frahdf.d100160
fraidf.d100160
frahdf.d100160cha

Reported incomplete:
frages.d0002f88mar
because the other chopped routes are not listed - WHY?:

frages.d0002f88
frabfc.d0002f88

There are more flipped reports where only one chopped route is listed.

Cool data check though. Love it 😄

[yakra]

I think I see what you mean here -- there's something wrong with the routes stylistically, from a consistency perspective; their points (or connected roots) are just plain in the wrong order for that region and/or system and should be reversed in the HighwayData itself. (Right?) Fair enough.

My threshold for "something wrong" was a datacheck error that'd potentially affect how users' travels are calculated from a .list line.

• If there's no DISCONNECTED_ROUTE error, the software flags a route as "reversed" behind the scenes, preventing stuff like this, and life goes on.
• If there is a DISCONNECTED_ROUTE error, all bets are off; a multi-region .list entry may or may not work correctly.

Cool data check though. Love it 😄

My intent wasn't for this to be a datacheck per se (though you can certainly use it as one if you wish), more of just a handy-dandy quick reference to use for development purposes (thus I think it should be listed here rather than here).

So, for a route to be reported "correctly" in flippedroutes.log, it just has to be one of the routes flagged behind the scenes as reversed, for having its point order opposite the connected root order.

frages.n019
frabfc.n019
frahdf.d100160
fraidf.d100160
frahdf.d100160cha

N19 (Vesoul) had its chopped roots ordered east-to-west, with the point order therein west-to-east.
D1001-60 had its chopped roots ordered north-to-south, with the point order therein south-to-north.
I noticed that you changed the _con.csv order for these. Another solution that would have "fixed" these cases would have been to reverse the point order in the .wpt files instead. You know what's appropriate for France; I don't. (What's normal for France? S->N or N->S? W->E or E->W?)

Reported incomplete:
frages.d0002f88mar
because the other chopped routes are not listed - WHY?:

frages.d0002f88
frabfc.d0002f88

The chopped roots were listed east-to-west in fragesd88_con.csv.

• frages.d0002f88 & frabfc.d0002f88 have their points ordered east-to-west, same as the connected root order. They don't get flagged as reversed, and don't get put in the log file.
• Only frages.d0002f88mar has its points west-to-east, so it's the only only chopped route flagged as reversed.

There are more flipped reports where only one chopped route is listed.

Yes, I expect that this will be normal behavior, what we'll see most of the time, especially if there are no "errors" (i.e., routes unintentionally flipped) present.

[michihdeu]

I always order routes N-S and W-E but France is usually Paris centric (since N routes were drafted by Si)

I initially dealed wrong with GES 2F but think that I got it now 😄 Thanks!

[michihdeu]

My intent wasn't for this to be a datacheck per se (though you can certainly use it as one if you wish), more of just a handy-dandy quick reference to use for development purposes (thus I think it should be listed here rather than here).

It is not a nmplog but a general log. yep, go for it! I'd say between unprocessedwpts.log and https://travelmapping.net/graphs/ I could also do it but don't know how to describe it properly because of the two causes for routes being listed.

EDIT: Maybe...

List of flipped .wpt files
Waypoint files that are flagged as reversed for processing ConnectedRoutes in 6-field .list entries.

[michihdeu]

Once the file is linked, we should mention the new log file on the forum (contributor only?) to trigger the affected hwy data managers. Well... mostly Si

[yakra]

I always order routes N-S and W-E but France is usually Paris centric (since N routes were drafted by Si)
I initially dealed wrong with GES 2F but think that I got it now 😄 Thanks!

I think D1001 should have also hade the points reversed rather than the routes, to go N-S.

My intent wasn't for this to be a datacheck per se (though you can certainly use it as one if you wish), more of just a handy-dandy quick reference to use for development purposes (thus I think it should be listed here rather than here).

Oops, I wrote that post too fast, based on having looked at tools.php before. I meant to say "here rather than here"

It is not a nmplog but a general log. yep, go for it! I'd say between unprocessedwpts.log and https://travelmapping.net/graphs/ I could also do it but don't know how to describe it properly because of listed.

So yes, definitely not an NMP log.
While my intent for this was as more of a Web Site Development and Site Update Log, I could see the logic in listing it as a Highway Data Development Log instead. You've certainly made use of it for such purposes.
There's some stuff in it caused by data errors, and some stuff in it that's false positive, as is often the case.

the two causes for routes being

Sounds like you're thinking of...?

• reversed roots in _con.csv file
• reversed points in .wpt file

This can also be conceptualized as just one cause:

• the order of the roots in the _con.csv file and the order of the points in the .wpt file don't match.

Shrug -- Anyway!

EDIT: Maybe...

List of flipped .wpt files
Waypoint files that are flagged as reversed for processing ConnectedRoutes in 6-field .list entries.

Yeah, you get the idea, this is good.
If listing this as a Web Site Development and Site Update Log, maybe just use the bottom line, to keep with single-line descriptions.
If listing this as a Highway Data Development Log, use both lines, and keep the same visual presentation.

Though if I wanna get pedantic, I might say "multi-region" instead of "6-field" .list entries -- 6-field entries listing a single chopped route have always been immune to the breaks that route-flipping was designed to fix. 😄

Once the file is linked, we should mention the new log file on the forum (contributor only?) to trigger the affected hwy data managers. Well... mostly Si

Or, even before it's linked. Hey why not.

[michihdeu]

I think D1001 should have also hade the points reversed rather than the routes, to go N-S.

It is a former N route heading north from Paris 🤣