Author Topic: Endpoints inconsistencies on USA borders  (Read 4780 times)

0 Members and 1 Guest are viewing this topic.

Offline SSOWorld

  • Full Member
  • ***
  • Posts: 222
  • Last Login:Yesterday at 09:35:08 pm
Endpoints inconsistencies on USA borders
« on: July 29, 2020, 09:24:17 am »
I have been finding inconsistencies with the borders between USA and CAN/MEX
Just a sample - using the new long entry format
```CA I-5 MEX/USA WA I-5 WA/Can``` ???
```MT I-94 0 MI I-94 MI/Can```` ???

Some of these follow a convention of USA/CAN or CAN/USA - others follow a convention of MI/Can or Mex/TX, other still use the province/state name even on the international border

Note this affects multiple users (@ovoss (CA, NM, BC, QC, SK, YT) @compdude (WA, ID) @jteresco @yakra (TX, NH, ME, AB, MB, NB, NH, NY), @rickmastfan67 (ON) @the-spui-ninja (MT, ND) @mapcat (MI) @ajfroggie (MN, VT) @neroute2 (All MEX)

for AZ (no maintainer) - the border points are shown as MEX/USA so I did nothing to pull in this. 

Just a quick glance at EU shows entries having FRA/BEL, FRA/LUX, etc. as (@si404 @michihdeu) has at France/Belgium/Luxemburg.

I did not take the time to comb through all the possibilities.

Serious inconsistencies IMO exist here.  What is the correct way?  Can this be displayed consistently on the HB (obviously keep deprecated ones until such time as we have no need for them.

Cross-posted to https://github.com/TravelMapping/HighwayData/issues/4069
Completed:
* Systems: DC, WI
* by US State: AR: I&; AZ: I; DE: I; DC: I, US, DC; IL: I; IN: I*; IA: I, KS: I; MD: I, MA: I, MI: I; MN: I; MO: I*; NE: I; NJ, I; OH: I; RI: I; SD: I; WA: I; WV: I; WI: I,US,WI; (AR, IN pending expansions.)

*Previously completed

Offline oscar

  • TM Collaborator
  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1524
  • Last Login:Today at 01:36:37 am
    • Hot Springs and Highways pages
Re: Endpoints inconsistencies on USA borders
« Reply #1 on: July 29, 2020, 11:13:33 am »
This has long been an issue, and is being gradually resolved, as I've done for California and New Mexico since all their route files with Mexico border points needed other changes anyway. Still some inconsistencies for Alaska and Yukon, since none of their route files with international border points (including YT routes extending into BC) have needed any other work lately.

I think there's no urgency to this, other than to make sure new/updated route files get it right.
« Last Edit: July 29, 2020, 12:10:05 pm by oscar »

Offline si404

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1944
  • Last Login:Today at 07:32:16 am
Re: Endpoints inconsistencies on USA borders
« Reply #2 on: July 29, 2020, 11:31:32 am »
When I drafted cross-border routes in Ireland, Tim told me to change the labels use GBR/IRL (or vice versa) from NIR/IRL (or vice versa) as I had used (will ignore this border's special cases that make that rather controversial) because it was an international border and needed to use country codes. The rule didn't exist until that time, and, as I found out later reviewing a system with border points, apparently never did.

I'm pretty sure that, when I took over maintenance and drafted state route systems in those regions, I converted MT and ID, as well as AZ, to 'the rule', depreciating in use labels.

Offline SSOWorld

  • Full Member
  • ***
  • Posts: 222
  • Last Login:Yesterday at 09:35:08 pm
Re: Endpoints inconsistencies on USA borders
« Reply #3 on: July 29, 2020, 12:13:50 pm »
Sounds like we're aware then.  The GitHub issue should be a reminder as would this post.
Completed:
* Systems: DC, WI
* by US State: AR: I&; AZ: I; DE: I; DC: I, US, DC; IL: I; IN: I*; IA: I, KS: I; MD: I, MA: I, MI: I; MN: I; MO: I*; NE: I; NJ, I; OH: I; RI: I; SD: I; WA: I; WV: I; WI: I,US,WI; (AR, IN pending expansions.)

*Previously completed

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
Re: Endpoints inconsistencies on USA borders
« Reply #4 on: July 29, 2020, 01:35:28 pm »
The difference in label styles is a historical relic of changing practices during the early days of CHM...

Ok,  let's start the peer-review feedback with a general question:
I found SK/MB labels at canmbp routes. In Europe, we always use the country name: USA/CAN. I've checked some MB border labels to USA and also found:
USA/CAN @ US59, MN89, MN310, MN313
ND/Can @ US81, I-29, US83
Don't we have a standard here? Especially Can instead of CAN is quite odd.
Was this discussed before? Any consens?
ND/Can (Yes, "Can", not all-caps) was the original style used on CHM back in the dark ages when we first started drafting United States Numbered Highways. It was later deprecated/superseded. There will still be a lot of these labels around the USA, on usaus especially.
By the time we'd got the first state/provincial systems going, we'd migrated to more of a "MT/MB" style.
The manual says "As an exception, these subdivision border labels can also be used on the USA/CAN and USA/MEX borders instead of using the countries in the label." As an exception. Allohttps://forum.travelmapping.net/index.php?topic=3754.msg20014#msg20014wable, but not the preferred first choice.
IIRC @oscar convinced me to switch to MEX/USA when drafting usatx.
I agree that USA/CAN style makes the most sense, with country boundaries tr--used to be a perfectly fine verb. Faust came to Portland in July 2018. Told us to get a new president. overriding subdivision boundaries.
Makes sense to re-examine these in all my regions. I'll have to make a shell script to grep for them.

Some of these follow a convention of USA/CAN or CAN/USA - others follow a convention of MI/Can or Mex/TX, other still use the province/state name even on the international border
There are no longer any "Mex/TX" style primary labels in the HighwayData repo (some AltLabels remain).
for rg in `ls`; do grep -is '^Mex/.. ' $rg/*/*.wpt; done
executed in hwy_data/ produces no results.

I standardized all my regions back in October. Presumably Oscar updated CA & NM at some point. I was a little surprised to discover AZ already used MEX/USA labels by the end of CHM.

Just a quick glance at EU shows entries having FRA/BEL, FRA/LUX, etc. as (@si404 @michihdeu) has at France/Belgium/Luxemburg.

I did not take the time to comb through all the possibilities.
I want to say all of EUR will be fine; things were standardized by the time EUR got underway, with regions only rarely subdivided. ESP, DEU & FRA were subdivided after the transition to TM, and should of course be fine. There was a country (KAZ? UKR?) that was subdivided (in CHM?) but then combined in TM. I presume if any inconsistencies existed they would have been eliminated at the time.
The only potential sticking point I can think of is the UK; per Si's comment above it sounds fine.

What is the correct way?
As noted in my first quote block, USA/CAN is preferred.
ME/NB is allowable too, "as an exception".
I used to think that "ND/Can" would be out, but rereading that rule, I'm more willing to say it's a gray area.

I think there's no urgency to this, other than to make sure new/updated route files get it right.
Ditto.

Nonetheless, some lists:

Remaining "../Can" style labels:
MI/usai/mi.i069.wpt:MI/Can +999 http://www.openstreetmap.org/?lat=42.998621&lon=-82.423382
MI/usai/mi.i075.wpt:MI/Can +999 http://www.openstreetmap.org/?lat=46.508289&lon=-84.360664
MI/usai/mi.i094.wpt:MI/Can +999 http://www.openstreetmap.org/?lat=42.998621&lon=-82.423382
ND/usai/nd.i029.wpt:ND/Can +999 http://www.openstreetmap.org/?lat=49.000435&lon=-97.237633
ND/usaus/nd.us081.wpt:ND/Can http://www.openstreetmap.org/?lat=49.000435&lon=-97.237633
ND/usaus/nd.us083.wpt:ND/Can http://www.openstreetmap.org/?lat=48.999620&lon=-101.017871
ND/usaus/nd.us281.wpt:ND/Can http://www.openstreetmap.org/?lat=48.999317&lon=-100.052426
VT/usai/vt.i089.wpt:VT/Can +999 http://www.openstreetmap.org/?lat=45.015514&lon=-73.084617
VT/usai/vt.i091.wpt:VT/Can +999 http://www.openstreetmap.org/?lat=45.005836&lon=-72.088251
VT/usaus/vt.us005.wpt:VT/Can http://www.openstreetmap.org/?lat=45.005745&lon=-72.099366
VT/usavt/vt.vt225.wpt:VT/Can http://www.openstreetmap.org/?lat=45.011540&lon=-73.296318
WA/usai/wa.i005.wpt:WA/Can +999 http://www.openstreetmap.org/?lat=49.001957&lon=-122.756166
WA/usaus/wa.us097.wpt:WA/Can http://www.openstreetmap.org/?lat=49.000091&lon=-119.462757
WA/usaus/wa.us395.wpt:WA/Can http://www.openstreetmap.org/?lat=49.000000&lon=-118.223888


State/Province style labels on USA/Can border:
SK/cansk/sk.sk002.wpt:MT/SK http://www.openstreetmap.org/?lat=48.999648&lon=-106.378040
SK/cansk/sk.sk004.wpt:MT/SK http://www.openstreetmap.org/?lat=49.000000&lon=-107.831755
SK/cansk/sk.sk021.wpt:MT/SK http://www.openstreetmap.org/?lat=48.999958&lon=-109.731531
SK/cansk/sk.sk036.wpt:MT/SK http://www.openstreetmap.org/?lat=48.999535&lon=-105.407810
SK/cansk/sk.sk037.wpt:MT/SK http://www.openstreetmap.org/?lat=48.999500&lon=-108.389171
ND/usand/nd.nd001.wpt:ND/MB http://www.openstreetmap.org/?lat=49.000250&lon=-98.364941
ND/usand/nd.nd003.wpt:ND/MB http://www.openstreetmap.org/?lat=48.999317&lon=-100.052426
ND/usand/nd.nd004.wpt:ND/MB http://www.openstreetmap.org/?lat=48.999585&lon=-99.346957
ND/usand/nd.nd014.wpt:ND/MB http://www.openstreetmap.org/?lat=48.999419&lon=-100.555640
ND/usand/nd.nd018.wpt:ND/MB http://www.openstreetmap.org/?lat=49.000461&lon=-97.556942
ND/usand/nd.nd020.wpt:ND/MB http://www.openstreetmap.org/?lat=48.999982&lon=-98.937662
ND/usand/nd.nd030rol.wpt:ND/MB http://www.openstreetmap.org/?lat=48.999282&lon=-99.658742
ND/usand/nd.nd032.wpt:ND/MB http://www.openstreetmap.org/?lat=49.000493&lon=-97.908525
ND/usand/nd.nd256.wpt:ND/MB http://www.openstreetmap.org/?lat=48.999479&lon=-101.296477
ND/usand/nd.nd008sta.wpt:ND/SK http://www.openstreetmap.org/?lat=48.998835&lon=-102.275135
ND/usand/nd.nd028.wpt:ND/SK http://www.openstreetmap.org/?lat=48.999303&lon=-101.627945
ND/usand/nd.nd040.wpt:ND/SK http://www.openstreetmap.org/?lat=48.999366&lon=-103.004894
ND/usand/nd.nd042.wpt:ND/SK http://www.openstreetmap.org/?lat=48.999282&lon=-103.486791
SK/cansk/sk.sk008.wpt:ND/SK http://www.openstreetmap.org/?lat=48.999303&lon=-101.627945
SK/cansk/sk.sk009.wpt:ND/SK http://www.openstreetmap.org/?lat=48.998835&lon=-102.275135
SK/cansk/sk.sk035.wpt:ND/SK http://www.openstreetmap.org/?lat=48.999502&lon=-103.809438
SK/cansk/sk.sk039.wpt:SK/ND http://www.openstreetmap.org/?lat=48.998991&lon=-102.552347
SK/cansk/sk.sk047.wpt:ND/SK http://www.openstreetmap.org/?lat=48.999366&lon=-103.004894
SK/cansk/sk.sk350.wpt:ND/SK http://www.openstreetmap.org/?lat=48.999282&lon=-103.486791
QC/canqca/qc.a015.wpt:NY/QC http://www.openstreetmap.org/?lat=45.008991&lon=-73.452315
VT/usavt/vt.vt105a.wpt:VT/QC http://www.openstreetmap.org/?lat=45.011847&lon=-72.588247
VT/usavt/vt.vt108.wpt:VT/QC http://www.openstreetmap.org/?lat=45.016341&lon=-72.825456
VT/usavt/vt.vt139.wpt:VT/QC http://www.openstreetmap.org/?lat=45.015078&lon=-72.662517
VT/usavt/vt.vt141.wpt:VT/QC http://www.openstreetmap.org/?lat=45.012666&lon=-71.560253
VT/usavt/vt.vt147.wpt:VT/QC http://www.openstreetmap.org/?lat=45.010679&lon=-71.793498
VT/usavt/vt.vt235.wpt:VT/QC http://www.openstreetmap.org/?lat=45.014388&lon=-72.978004
VT/usavt/vt.vt243.wpt:VT/QC http://www.openstreetmap.org/?lat=45.007300&lon=-72.416033
VT/usavt/vt.vt253.wpt:VT/QC http://www.openstreetmap.org/?lat=45.013402&lon=-71.505337
QC/canqca/qc.a055.wpt:VT/QC http://www.openstreetmap.org/?lat=45.005836&lon=-72.088251
WA/usawa/wa.wa009sprsum.wpt:WA/BC http://www.openstreetmap.org/?lat=49.002400&lon=-122.263713
WA/usawa/wa.wa009.wpt:WA/BC http://www.openstreetmap.org/?lat=49.002418&lon=-122.265086
WA/usawa/wa.wa021rep.wpt:WA/BC http://www.openstreetmap.org/?lat=49.000091&lon=-118.503449
WA/usawa/wa.wa025.wpt:WA/BC http://www.openstreetmap.org/?lat=48.999972&lon=-117.831545
WA/usawa/wa.wa031.wpt:WA/BC http://www.openstreetmap.org/?lat=48.999975&lon=-117.299738
WA/usawa/wa.wa539.wpt:WA/BC http://www.openstreetmap.org/?lat=49.002238&lon=-122.485049
WA/usawa/wa.wa543.wpt:WA/BC http://www.openstreetmap.org/?lat=49.002090&lon=-122.735342
« Last Edit: July 29, 2020, 01:44:46 pm by yakra »
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4555
  • Last Login:Yesterday at 04:04:16 pm
Re: Endpoints inconsistencies on USA borders
« Reply #5 on: July 29, 2020, 02:18:46 pm »
As noted in my first quote block, USA/CAN is preferred.
ME/NB is allowable too, "as an exception".
I used to think that "ND/Can" would be out, but rereading that rule, I'm more willing to say it's a gray area.

The exception should be eliminated...

Offline froggie

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 801
  • Last Login:Yesterday at 07:53:11 pm
Re: Endpoints inconsistencies on USA borders
« Reply #6 on: July 29, 2020, 06:03:20 pm »
I would argue that using the states/provinces should be the standard, not the exception or "eliminated".

Offline SSOWorld

  • Full Member
  • ***
  • Posts: 222
  • Last Login:Yesterday at 09:35:08 pm
Re: Endpoints inconsistencies on USA borders
« Reply #7 on: July 29, 2020, 11:33:58 pm »
I would argue that using the states/provinces should be the standard, not the exception or "eliminated".
Then how do you handle Outside NA?

Si404 - Is it correct that all other continents use country codes?  What's so special about the USA and Canada that we have to use states/provinces.  Also that significant work to change them if true.
Completed:
* Systems: DC, WI
* by US State: AR: I&; AZ: I; DE: I; DC: I, US, DC; IL: I; IN: I*; IA: I, KS: I; MD: I, MA: I, MI: I; MN: I; MO: I*; NE: I; NJ, I; OH: I; RI: I; SD: I; WA: I; WV: I; WI: I,US,WI; (AR, IN pending expansions.)

*Previously completed

Offline the_spui_ninja

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 721
  • Last Login:Yesterday at 01:38:28 pm
  • THE Western SD Highway Nut
Re: Endpoints inconsistencies on USA borders
« Reply #8 on: July 29, 2020, 11:38:09 pm »
I used to think that "ND/Can" would be out, but rereading that rule, I'm more willing to say it's a gray area.
Eh, I'll take it out anyway.
I would argue that using the states/provinces should be the standard, not the exception or "eliminated".
Then how do you handle Outside NA?

Si404 - Is it correct that all other continents use country codes?  What's so special about the USA and Canada that we have to use states/provinces.  Also that significant work to change them if true.
At least as I conceptualize crossing the border, I always think of "going to Canada" not "going to Sasketchewan" (even though I've never done it; my friend from Detroit does talk about going to Canada and not going to Ontario and he's actually done that), so I think country codes would be preferable.
An adventure is only an inconvenience rightly considered. An inconvenience is only an adventure wrongly considered. - G.K. Chesterton

Offline si404

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1944
  • Last Login:Today at 07:32:16 am
Re: Endpoints inconsistencies on USA borders
« Reply #9 on: July 30, 2020, 07:17:53 am »
I would argue that using the states/provinces should be the standard, not the exception or "eliminated".
I would argue that the more important thing at the USA/CAN or USA/MEX border is that it's an international border. It's more relevant information than it being the MN/MB or whatever.

A total I-5 clinch, for instance, is between the Mexican and Canadian borders, not between two BC borders!

It shouldn't be I-5 CA BC/CA WA WA/BC. It should be I-5 CA MEX/USA WA USA/CAN.
Si404 - Is it correct that all other continents use country codes?
Actually, looking, I've found an exception on the Franco-Dutch border (which is bizarre as no one would ever call it the Saint-Martin / Sint Maarten border). Though that's in North America, so isn't 'other continents' :P.

But yes. Ever since that Ur example (which is the inter-country border in the world most likely to be referred to as Country/Region rather than Country/Country) countries has been what's been used by me, even when countries are subdivided (internal borders obviously use province/state/whatever codes) - as is the case in that original example (GBR rather than NIR).
Quote
Also that significant work to change them if true.
Very true. As well as most North American border points, every French, Spanish and German border point would be divergent from that standard - or at least the ones on their shared borders: if one side is a country, should we have the mismatch?

I think anything like ND/Can needs to be changed due to being neither one thing nor the other. 'Can' rather than 'CAN' is clearly odd, but also inconsistency with what the border is: ND/CAN is still not right because Canada is split just like the USA. Whether that's ND/SK or USA/CAN is a different question, but I've given my answer above in favour of countries.

But it's a bit different with borders of multi-region countries and single-region countries. You could possibly make the case for OCC/CT (Occitan/Catalonia) for the FRA/ESP (France/Spain) border points at the eastern end of that border - I think it's hard, but... But is it OCC/AND and AND/CT for the Andorran borders? Is it the Oder the Brandenburg-Poland border, or the German-Poland border? The latter seems better.
« Last Edit: July 30, 2020, 07:22:18 am by si404 »

Offline the_spui_ninja

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 721
  • Last Login:Yesterday at 01:38:28 pm
  • THE Western SD Highway Nut
Re: Endpoints inconsistencies on USA borders
« Reply #10 on: July 30, 2020, 10:56:39 pm »
I think anything like ND/Can needs to be changed due to being neither one thing nor the other. 'Can' rather than 'CAN' is clearly odd, but also inconsistency with what the border is: ND/CAN is still not right because Canada is split just like the USA. Whether that's ND/SK or USA/CAN is a different question, but I've given my answer above in favour of countries.
Technical question, does capitalization matter when the site runs list files? I'm going through the ND border points now and the one on US 85 is labeled "USA/Can", and I was wondering if I needed to save that specifically as an alternate name or if any lists with that label in them will just run USA/CAN as being equivalent.
An adventure is only an inconvenience rightly considered. An inconvenience is only an adventure wrongly considered. - G.K. Chesterton

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4555
  • Last Login:Yesterday at 04:04:16 pm
Re: Endpoints inconsistencies on USA borders
« Reply #11 on: July 31, 2020, 12:39:47 am »
Technical question, does capitalization matter when the site runs list files?

No. It is only relevant for how it is displayed on the site.

Offline the_spui_ninja

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 721
  • Last Login:Yesterday at 01:38:28 pm
  • THE Western SD Highway Nut
Re: Endpoints inconsistencies on USA borders
« Reply #12 on: July 31, 2020, 07:59:12 pm »
Technical question, does capitalization matter when the site runs list files?

No. It is only relevant for how it is displayed on the site.
Cool, thanks. I'll take care of that then.
An adventure is only an inconvenience rightly considered. An inconvenience is only an adventure wrongly considered. - G.K. Chesterton

Offline vdeane

  • Sr. Member
  • ****
  • Posts: 387
  • Gender: Female
  • Last Login:Yesterday at 09:23:42 pm
    • New York State Roads
Re: Endpoints inconsistencies on USA borders
« Reply #13 on: July 31, 2020, 08:24:56 pm »
Technical question, does capitalization matter when the site runs list files?

No. It is only relevant for how it is displayed on the site.
As exemplified by this error that suddenly appeared on my .list file:
Code: [Select]
Waypoint label WATGLESP not found in line: NY NY419 NY329 WatGleSP
Please note: All comments here represent my own personal opinion and do not reflect the official position of NYSDOT or its affiliates.

Offline SSOWorld

  • Full Member
  • ***
  • Posts: 222
  • Last Login:Yesterday at 09:35:08 pm
Re: Endpoints inconsistencies on USA borders
« Reply #14 on: July 31, 2020, 09:10:48 pm »
The search algorithm would need to "ignore case" (I assume because "tl:dr" that the "regular expression" algorithms are used here which would need the "i" qualifier (techno babble unless the developer understands it) ;) ).  If not, it's case sensitive.

I would also be careful with case insensitive situations though because one could possibly turn up a false positive.
Completed:
* Systems: DC, WI
* by US State: AR: I&; AZ: I; DE: I; DC: I, US, DC; IL: I; IN: I*; IA: I, KS: I; MD: I, MA: I, MI: I; MN: I; MO: I*; NE: I; NJ, I; OH: I; RI: I; SD: I; WA: I; WV: I; WI: I,US,WI; (AR, IN pending expansions.)

*Previously completed