CZE

[michihdeu]

https://www.skyscrapercity.com/posts/198627894
https://www.skyscrapercity.com/posts/198635922

[michihdeu]

Consi check failure is FP. E442 was relocated, I17 + I35 remain as-is.

[michihdeu]

@jteresco I'm not sure that this behavior is as intended.
The check is against E442. I guess because it is a tier 3 route while the other routes are tier 4 + tier 5, or alphabetical order?

• the first check result is for I35_HomE but that's the second wp being changed. The first updated wp is D35/I17 that also got new coords on I17. Why is the first change not output? The claimed incorrect coords on I17 are for II305_S but also for the I17_W wp coords of I305. I didn't expect that I305 would be output. I wonder what will be output when I relocate a route with dozens of wps.
• the 2nd check result is for 166(D35). It compares against the 3rd wp II305_N. This confuses but can be ignored.
• the 3rd check result is for +X96(D35). It compares against the 4th wp I17/I35 and thus outputs four un-updated files.
• the 4th check result is for 171(D35). It compares against the fifth D35(166).
• I wonder why the next E442 wp II357_N (no. 6) was not output. In general, 8 wps of E442 have been replaced by 6 wps. No. 2 to 5 were output. Why not no. 6?

https://github.com/TravelMapping/HighwayData/actions/runs/32627460354/attempts/1#summary-97164894660

Is that as intended?

If so, I think it would help maintainers investigating the output, if you'd add the old wp label to the souce label e.g.
Inconsistent Update: Waypoint I35_HomE (previously II305_S)
Inconsistent Update: Waypoint 171(D35) (previously I17/I35)
Inconsistent Update: Waypoint 171(D35) (previously D35(166))

thanks!