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

0 Members and 1 Guest are viewing this topic.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1904
  • Last Login:Today at 01:06:46 pm
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: 111
  • Last Login:Yesterday at 05:20:54 am
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: WI
* by US State: AR: I; AZ: I; DE: I; IA: I, KS: I; MN: I; MA: I; MO: I; NE: I; RI: I; SD: I; WA: I; WI: I,US,WI;

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1904
  • Last Login:Today at 01:06:46 pm
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

  • Full Member
  • ***
  • Posts: 190
  • Gender: Female
  • Last Login:Yesterday at 06:17:56 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: 1904
  • Last Login:Today at 01:06:46 pm
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: 2849
  • Last Login:Today at 12:55:55 pm
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 »

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2818
  • Last Login:Today at 03:19:07 am
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.