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

0 Members and 1 Guest are viewing this topic.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2732
  • Last Login:Today at 08:47:31 am
Re: Endpoints inconsistencies on USA borders
« Reply #15 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 .

Offline SSOWorld

  • Full Member
  • ***
  • Posts: 222
  • Last Login:Yesterday at 09:35:08 pm
Re: Endpoints inconsistencies on USA borders
« Reply #16 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?)
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 Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2732
  • Last Login:Today at 08:47:31 am
Re: Endpoints inconsistencies on USA borders
« Reply #17 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?
« Last Edit: July 31, 2020, 10:21:45 pm by Jim »

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 #18 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.
Please note: All comments here represent my own personal opinion and do not reflect the official position of NYSDOT or its affiliates.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2732
  • Last Login:Today at 08:47:31 am
Re: Endpoints inconsistencies on USA borders
« Reply #19 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.

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 #20 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 (see also: ESRI).
I can't immediately find a name for the RxR, but "Station Rd" appears to pass the not concurrent test per shapefiles (this sign helps too).
The 2014 TDR and 2019 TVR 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 is just inside the park limits, with the END sign 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.
« Last Edit: August 01, 2020, 02:36:43 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 #21 on: August 19, 2020, 12:21:20 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.

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.

Offline SSOWorld

  • Full Member
  • ***
  • Posts: 222
  • Last Login:Yesterday at 09:35:08 pm
Re: Endpoints inconsistencies on USA borders
« Reply #22 on: December 27, 2020, 12:59:09 pm »
I sent personal messages to a couple collaborators asking they update their files to reflect this.  There are still non-compliant states present.
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 michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4555
  • Last Login:Yesterday at 04:04:16 pm
Re: Endpoints inconsistencies on USA borders
« Reply #23 on: June 05, 2022, 12:13:11 pm »
Jim asked on Github:
Quote
These all addressed by now?

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4234
  • Last Login:February 13, 2024, 07:19:36 pm
  • I like C++
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2732
  • Last Login:Today at 08:47:31 am

Offline rickmastfan67

  • TM Collaborator (A)
  • Hero Member
  • *****
  • Posts: 1829
  • Gender: Male
  • Last Login:Today at 06:11:34 am
Re: Endpoints inconsistencies on USA borders
« Reply #26 on: June 10, 2022, 12:05:01 am »
Just pushed the only 4 in Ontario that needed updated (ON-11, ON-71, ON-137, & ON-405).

However, still might consider shortening ON-405 to the 'closed' interchange of PorRd.  That, or unhide the current shaping point near Niagara Parkway and making a closed point there as the end of the route instead, as there used to be a ramp to that from EB ON-405 back in the day (even used it before it was removed).

https://github.com/TravelMapping/HighwayData/pull/5849
« Last Edit: June 10, 2022, 12:07:48 am by rickmastfan67 »

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 #27 on: June 10, 2022, 09:16:53 am »
and making a closed point there
Like this one?

Is the bridge not part of the route itself, like some TX routes at the MEX border (e.g. I-69W)?
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline compdude787

  • TM Collaborator
  • Sr. Member
  • *****
  • Posts: 298
  • Gender: Male
  • Last Login:February 09, 2024, 02:19:30 am
Re: Endpoints inconsistencies on USA borders
« Reply #28 on: June 10, 2022, 08:56:46 pm »
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.002081&lon=-122.756510
WA/usaus/wa.us097.wpt:WA/Can http://www.openstreetmap.org/?lat=49.000091&lon=-119.462757

This will be taken care of with tomorrow's update:

https://github.com/TravelMapping/HighwayData/commit/cda16c317cbd17b9783ddc9b9e9aa9f55de504dd

Thanks for taking care of these. Sorry I haven't had a chance to fix them; just been a bit too busy lately. I think I'll have more time for TM in 2-3 weeks after I get back from my upcoming road trip out to the east coast (I'm not going to be driving across the country but taking the plane).

Offline rickmastfan67

  • TM Collaborator (A)
  • Hero Member
  • *****
  • Posts: 1829
  • Gender: Male
  • Last Login:Today at 06:11:34 am
Re: Endpoints inconsistencies on USA borders
« Reply #29 on: June 14, 2022, 12:50:22 am »
and making a closed point there
Like this one?

Is the bridge not part of the route itself, like some TX routes at the MEX border (e.g. I-69W)?

Possibly from what I've heard.