Travel Mapping

Highway Data Discussion => Updates to Highway Data => Topic started by: SSOWorld on July 29, 2020, 09:24:17 am

Title: Endpoints inconsistencies on USA borders
Post by: SSOWorld 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
Title: Re: Endpoints inconsistencies on USA borders
Post by: oscar 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: si404 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: SSOWorld 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: yakra 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 (http://travelmapping.net/hb/?units=miles&u=yakra&r=tx.tx004&lat=25.898703&lon=-97.497480&zoom=17) 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 (https://github.com/yakra/HighwayData/commit/ed75c1956d8c0adf9303903b38c673c4ee3ff67e) all (https://github.com/yakra/HighwayData/commit/6b9c1d5e855a71ff68ffc0393788593de131ec25) my (https://github.com/yakra/HighwayData/commit/e2d1ce84c0520ceadc81381faa55c0f18208d1db) regions (https://github.com/yakra/HighwayData/commit/e273eb1a9994c50c8783463d51614ba8aa7e8209). I'll have to make a shell script to grep (http://forum.travelmapping.net/index.php?topic=3245) 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 (https://forum.travelmapping.net/index.php?topic=3754.msg20014#msg20014) 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 (https://travelmapping.net/devel/manual/wayptlabels.php#country).
ME/NB is allowable too, "as an exception" (https://travelmapping.net/devel/manual/wayptlabels.php#subdiv).
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
Title: Re: Endpoints inconsistencies on USA borders
Post by: michih on July 29, 2020, 02:18:46 pm
As noted in my first quote block, USA/CAN is preferred (https://travelmapping.net/devel/manual/wayptlabels.php#country).
ME/NB is allowable too, "as an exception" (https://travelmapping.net/devel/manual/wayptlabels.php#subdiv).
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...
Title: Re: Endpoints inconsistencies on USA borders
Post by: froggie 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".
Title: Re: Endpoints inconsistencies on USA borders
Post by: SSOWorld 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: the_spui_ninja 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: si404 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: the_spui_ninja 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: michih 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: the_spui_ninja 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: vdeane 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
Title: Re: Endpoints inconsistencies on USA borders
Post by: SSOWorld 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.
Title: Re: Endpoints inconsistencies on USA borders
Post by: Jim on July 31, 2020, 09:32:46 pm
We support case insensitivity of many things, including matching of waypoint labels, by converting everything to uppercase internally.  Those interested can find lots of calls to .upper() in https://github.com/TravelMapping/DataProcessing/blob/master/siteupdate/python-teresco/siteupdate.py .
Title: Re: Endpoints inconsistencies on USA borders
Post by: SSOWorld on July 31, 2020, 10:00:30 pm
We support case insensitivity of many things, including matching of waypoint labels, by converting everything to uppercase internally.  Those interested can find lots of calls to .upper() in https://github.com/TravelMapping/DataProcessing/blob/master/siteupdate/python-teresco/siteupdate.py .
Perfect! Curious to why vdeane's entry did not work.  (Isn't Python great or what?)
Title: Re: Endpoints inconsistencies on USA borders
Post by: Jim on July 31, 2020, 10:19:40 pm
The actual point label in NY419 is "WatGlenSP".  Which looks like it was changed recently and should have gotten an alt label with the old one.  @yakra would you like to add that or should I?
Title: Re: Endpoints inconsistencies on USA borders
Post by: vdeane on July 31, 2020, 11:03:14 pm
The actual point label in NY419 is "WatGlenSP".  Which looks like it was changed recently and should have gotten an alt label with the old one.  @yakra would you like to add that or should I?
Not only was the label changed, it was moved.  That's probably where there's no alt label.
Title: Re: Endpoints inconsistencies on USA borders
Post by: Jim on July 31, 2020, 11:18:40 pm
The actual point label in NY419 is "WatGlenSP".  Which looks like it was changed recently and should have gotten an alt label with the old one.  @yakra would you like to add that or should I?
Not only was the label changed, it was moved.  That's probably where there's no alt label.

Though with no updates entry that was probably not the intent.
Title: Re: Endpoints inconsistencies on USA borders
Post by: yakra on August 01, 2020, 12:03:43 pm
Whoopsie. I must have been on autopilot; I don't think I was even aware of "fixing" the label in the process.
Will add the AltLabel; there are 9 people still using it.
I'll also have a look at NY409 while I'm at it.

Edit: Oh boy. NY409 is a bit of an unexpected doozie.
Shapefiles have the end at the railroad crossing just outside the park boundary (https://parks.ny.gov/documents/parks/WatkinsGlenTopographicalMap.pdf) (see also: ESRI).
I can't immediately find a name for the RxR, but "Station Rd" appears to pass the not concurrent (https://travelmapping.net/devel/manual/wayptlabels.php#continuing) test per shapefiles (this sign (https://www.google.com/maps/@42.373907,-76.8932526,3a,15y,263.88h,85.26t/data=!3m6!1e1!3m4!1s8va1B7in2mopqIp_rHhsYA!2e0!7i13312!8i6656) helps too).
The 2014 TDR (https://www.dot.ny.gov/divisions/engineering/technical-services/hds-respository/NYSDOT_Traffic_Data_Report_2014.pdf) and 2019 TVR (https://www.dot.ny.gov/divisions/engineering/technical-services/hds-respository/NYSDOT_2019TrafficVolumeReport-Routes.pdf) both put the total length at 1.69 mi; add in the CHM fudge factor and we get 1.73 mi, which matches what I get if I gisplunge NY409 from the MilepointRoute2015 shapefiles and load the results into WPTedit.
OTOH:
The first reference marker (https://www.google.com/maps/@42.3740897,-76.8927821,3a,16y,76.74h,83.34t/data=!3m6!1e1!3m4!1swOu1ouikgO2CPXi0mVQHPQ!2e0!7i13312!8i6656) is just inside the park limits, with the END sign (https://www.google.com/maps/@42.374237,-76.8925414,3a,75y,233.01h,84.09t/data=!3m6!1e1!3m4!1s-WPmFCjnXuq8yE5rugjkxQ!2e0!7i13312!8i6656) a wee bit farther in.
Seems that a traveler would see the END sign, say "Grand, I clinched it!", and turn around at the handy-dandy dirt pullout right at the park boundary without making it to the RxR.
WatGlenSP +WatGleSP http://www.openstreetmap.org/?lat=42.374063&lon=-76.892860
might be a better match for the situation in the field.
Title: Re: Endpoints inconsistencies on USA borders
Post by: michih on August 19, 2020, 12:21:20 pm
As noted in my first quote block, USA/CAN is preferred (https://travelmapping.net/devel/manual/wayptlabels.php#country).
ME/NB is allowable too, "as an exception" (https://travelmapping.net/devel/manual/wayptlabels.php#subdiv).
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.

We agreed to change the rule. The exception was removed:

https://travelmapping.net/devel/manual/wayptlabels.php#country

Quote
International borders use the 3-letter country codes with a slash in between. Put them in the order that matches the waypoint order. USA/CAN is the first waypoint for a Canadian highway beginning at the USA border, or the last waypoint for a USA highway ending at the CAN border.

https://travelmapping.net/devel/manual/wayptlabels.php#subdiv (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.)

Quote
Subdivision (state/province/oblast etc.) borders are included only for countries that we subdivide.