Highway Data Discussion (CHM/TravelMapping)

[Duke87]

So, essentially, you're saying that if collaborator Bob chooses to include truck routes in his states, and collaborator Bill chooses to ignore them in his states, that's fine? How do you explain that to a user who, familiar with one of Bob's states, submits a list of truck routes he's found in one of Bill's states, and asks that they be added? To the user, they will be the same; "No thanks, Bill doesn't deal with truck routes" won't seem like a valid explanation.

And what happens when Bob tires of the project, and Bill takes over one of his states? Do the truck routes stay, or do they go?

All that seems to assume that all truck routes are alike, or that different states have similar policies about truck routes. As has been noted, even within one state (NY), truck routes come in different flavors, with some more "official" (from NYSDOT's standpoint) than others.

Indeed, different states have different ways of doing things, and one cannot always broadly apply specific policies in a fair manner. For example, in states that have secondary routes signed with a different shield, they generally are not included in the state system here. But then you have Vermont, where some routes are signed with a different shield to denote local maintenance. The consensus ended up being that they should be included in the primary system for reasons that are difficult to objectively state, but intuitively it makes sense most who are familiar with the routes.

So, with regards to whether a particular state system should include certain bannered routes, I would likewise say this should be determined by community consensus - not by any one individual.

[vdeane]

Thinking about it some more, truck routes are striking me as similar to business interstates in some way.  It would also be nice to maintain consistency between systems where it makes sense.

[oscar]

In my now-completed review of the draft NM state routes, I just wanted to flag a few possible changes needed to US routes (US 84/285 reroute in Española, US 64 reroute and new business route in Farmington, US 82 Truck in Artesia), and an Interstate business route (I-40BL Grants), that may require changes to those route files, in addition to related changes to some state routes. Also, several routes that may need to be added or deleted in the NM state route set.

Over in the CHM forum, I've bumped a topic on a short rerouting of US 70 in Lordsburg. However, this one has zero effect on the NM state route set.

The rerouting of US 64 and the new business route in Farmington, the NM 547 point addition for I-40BL Grants, and the US 70 reroute in Lordsburg are all in the Travel Mapping HB. I'm satisfied, after reviewing the newest GMSV imagery, that we don't need to change anything in Española. I still need to take another look at the US 82 truck route in Artesia before implementing that change. Also, I-40BL Albuquerque appears to be decommissioned as a business (but not historic) route, which will require some point relabels on several intersecting state routes.

I'm starting on the state route file edits flagged in my long post on page 8 of this topic, which should get the state route set ready for activation. For some, I may need to check in with NMDOT, if I can't get clarity from GMSV.

[Jim]

Got a PM about this, and thought it worth reminding everyone.  TM's points in use are not in the DB, but they are in a log file.  I think both this file and the old CHM points in use should be consulted when deciding when a point can be renamed without breaking .list files.

http://tm.teresco.org/logs/pointsinuse.log

Once we get a large enough user base, we could probably not worry about the old CHM points in use anymore, but I think it's nice to keep looking there for now.  We seem to be picking up a few old CHM users as TM users each week lately.

[Jim]

New log file produced during site updates: a list of .wpt files in our hwy_data hierarchy, other than the boundaries data we are not (yet) using, that did not get processed into the DB as a result of a matching entry in a .csv file for a system in the systems.csv file.

http://tm.teresco.org/logs/unprocessedwpts.log

Many are files in partially-developed systems that don't yet have valid .csv files.  Some are files that will be added to a .wpt upon activation of a system (where a route already is active in another system).  Others are likely old junk that should be cleaned up.  Low priority to be sure, but something to take a look at occasionally anyway.

[yakra]

I've thought about this from time to time since the CHM days, how we've got this historical cruft building up.

On the one hand, it's neato for archaeological purposes, having these old WPTs around as a historical record.
OTOH, GitHub has the "Browse commits for this branch", "Browse the repository at this point in the history", etc. options.  Which are more complete, more powerful, and probably more appropriate.

[oscar]

I took a look at the unprocessed .wpts log. Some of the entries in my jurisdictions are wpts for deleted routes (some of them deleted years ago in CHM days). Most of them I'll delete later, after I've cleared my NM queue, though some of the California wpts are destined to be folded into other routes (like ca.086s.wpt) and should be preserved for now.

Then, for some reason, the PEI files include TCH files for other provinces. Weird.

[yakra]

Then, for some reason, the PEI files include TCH files for other provinces. Weird.

Sounds like the same weirdness that produced this: https://github.com/TravelMapping/HighwayData/issues/169
I've put in a pull request to delete them.

[Jim]

I've thought about this from time to time since the CHM days, how we've got this historical cruft building up.

On the one hand, it's neato for archaeological purposes, having these old WPTs around as a historical record.
OTOH, GitHub has the "Browse commits for this branch", "Browse the repository at this point in the history", etc. options.  Which are more complete, more powerful, and probably more appropriate.

Right - we can browse a complete history of our data from the time it was first imported to GitHub.  No sense keeping these old files around just for those purposes.

Thanks for the quick initial cleanup - we're down over 200 extraneous files already.

[english si]

Right - we can browse a complete history of our data from the time it was first imported to GitHub.  No sense keeping these old files around just for those purposes.

Speaking of which, do we want to bin the chm_final folder?

[Jim]

Right - we can browse a complete history of our data from the time it was first imported to GitHub.  No sense keeping these old files around just for those purposes.

Speaking of which, do we want to bin the chm_final folder?

I'd like to keep it as an easy point of reference, at least for now, with so many CHM users not yet participating in TM.

[Jim]

The datacheck page http://tm.teresco.org/devel/datacheck.php now breaks datacheck errors into 4 categories: errors in active systems that should be addressed with high priority, errors in preview systems that must be addressed before a system can be activated, errors in devel systems that should be addressed when a system is be prepared for promotion to preview status, and the known false positives (for routes in systems in any development status).

We have a handful of datacheck errors in active systems that should be checked out.

[mapcat]

It appears that someone jumped the gun on extending I-69 up to Henderson, KY. I was on the road from Henderson to Madisonville today and it's all still signed as the Pennyrile Pkwy, not I-69, on the route and on trailblazers. No Future I-69 signs either. Exits still use the Pennyrile exit numbers, although new signs are being erected with I-69's numbers, so those will match what's in the HB in the not-too-distant future.

Is there a new standard for elevating future interstates to interstates?

[mapcat]

Since there's no separate thread for Oklahoma yet:

US283 and OK44 might need reconfiguring north of Blair. There is a not-so-new diagonal 4-lane route for US283, but the fact that (per GMSV) the old routing is still signed (albeit as TO 283 or TO 44) makes me wonder if there is still some uncertainty about the reroute.  GMSV shows the rerouting of US283 as far back as 2008.

https://www.google.com/maps/@34.8128828,-99.334237,3a,75y,335.48h,85.33t/data=!3m6!1e1!3m4!1sjvUa5duM5AnSd7bqGyb_Dw!2e0!7i13312!8i6656

[yakra]

US283 and OK44 might need reconfiguring north of Blair. There is a not-so-new diagonal 4-lane route for US283, but the fact that (per GMSV) the old routing is still signed (albeit as TO 283 or TO 44) makes me wonder if there is still some uncertainty about the reroute.  GMSV shows the rerouting of US283 as far back as 2008.

https://www.google.com/maps/@34.8128828,-99.334237,3a,75y,335.48h,85.33t/data=!3m6!1e1!3m4!1sjvUa5duM5AnSd7bqGyb_Dw!2e0!7i13312!8i6656

Oh, bloody hell.
If Okladot would at any time pull their head out of their bottom, that would be lovely.
The Greer County control section map (date unknown, but the URL has a couple "2012"s in it) clearly shows US283 on the east side of the triangle, and OK6 on the diagonal. (US283 on the north side is less clear, and must be inferred.) Meanwhile, the General County Road map ("all data current to date of inventory September 2010" / "state system revised to September 2013" / whatever) shows US283 on both the north and east legs -- and OK6 on the east leg. ...Leaving the diagonal as, ostensibly... nothing? I'm laughing but I'm crying...
But regardless, a thru traveler trying to clinch the route is probably going to follow the signs, and finding that our route file doesn't match up would be a nasty surprise. All signage I see on GMSV on the thru route clearly directs travelers to the diagonal. The lone straggler faces travelers coming to the end of OK44 south: GMSV of apparently similar vintage to Mapcat's link (no, I'm not going to leave Lite Mode just to look at the date) shows a junction with US283 south and north -- and an END OK44 sign. The other signage at nearby junctions is pretty unambiguously TO OK44. So, OK44 should probably end where it already does. At a place signed in the field (?) as US283. But wouldn't be any actual route in our DB if US283 gets moved.

Oohh-kladot!!@#
I'd love it if my head would stop exploding for just a tiny little bit.
If only I could stop repeatedly bashing it into my desk...

-----

While checking out the routes involved here, I noticed that OK6 has been rerouted around the E1340 points, between OK9 & OK55. At least that much is straightforward. ...I hope.

[deathtopumpkins]

I'm having a bit of an issue with one specific route: VA 168. It's "active" as va168fwy, and "preview" as va168. However, in my log I get the following when I try to add them:

Waypoint label(s) not found in line: VA VA168 NC/VA US60
Unknown region/highway combo in line: VA VA168Fwy NC/VA 15A

Is there some issue with this one route? I can't imagine what I could be doing wrong. Also, it does count the part of VA 168Fwy concurrent with US 17 as clinched for me, if that helps.

[oscar]

I'm having a bit of an issue with one specific route: VA 168. It's "active" as va168fwy, and "preview" as va168. However, in my log I get the following when I try to add them:

Waypoint label(s) not found in line: VA VA168 NC/VA US60
Unknown region/highway combo in line: VA VA168Fwy NC/VA 15A

Is there some issue with this one route? I can't imagine what I could be doing wrong. Also, it does count the part of VA 168Fwy concurrent with US 17 as clinched for me, if that helps.

Same issue with several other routes such as VA 7, VA 28, and VA 262.

[Jim]

I'm having a bit of an issue with one specific route: VA 168. It's "active" as va168fwy, and "preview" as va168. However, in my log I get the following when I try to add them:

Waypoint label(s) not found in line: VA VA168 NC/VA US60
Unknown region/highway combo in line: VA VA168Fwy NC/VA 15A

Is there some issue with this one route? I can't imagine what I could be doing wrong. Also, it does count the part of VA 168Fwy concurrent with US 17 as clinched for me, if that helps.

Same issue with several other routes such as VA 7, VA 28, and VA 262.

Someone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem.  This is a problem every time we start developing a new system that has routes already in another system, but only plotted in part in the existing system.  If that makes any sense.  Anyway, the thing to do is to hold off any changes until the VA routes in the active system are extended to their full length.

[froggie]

Someone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem.

I'm presuming this is a temporary fix until the full usava system is brought online?

[Jim]

Someone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem.

I'm presuming this is a temporary fix until the full usava system is brought online?

Yes. Eric did this with some Texas routes when those full systems first got into our DB.  The usansf routes will go away when usatx and usava activate.

[yakra]

In usansf.csv, there is no Fwy abbrev for VA168. Thus, the highway name used in a .list file is VA VA168 (hence the 2nd error in deathtopumpkins.log) -- same as the route in the preview usava set. This causes a collision... :\

For the "VA VA168 NC/VA US60" line in deathtopumpkins.list, the "VA VA168" maps to the active route in the usansf set (whether this is due to this route being active and not preview, or the order in which the .csvs are listed and processed, slurped into & read from the DB, etc., I cannot say...). The usansf flavor is the partial route sans the US60 waypoint, hence the 1st error in deathtopumpkins.log.

Maybe add some code to the SiteUpdate script to produce a warning when this happens?

Someone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem.

I'm presuming this is a temporary fix until the full usava system is brought online?

Yes. Eric did this with some Texas routes when those full systems first got into our DB.  The usansf routes will go away when usatx and usava activate.

Yes, it looks like a Texas-style solution is appropriate here.
As far as planning to actually do this goes, I suggested it but fell just short of actually volunteering myself for the task, not wanting to put too much on my plate and spread myself too thin. (And then I went and took on NY & MA maintenance, 'cuz, you know... I'm nothing if not intellectually consistent...)

[oscar]

Is it any more difficult than (a) copying the "full" versions of the VA 7, VA 28, VA 168, and VA 262 files from your local usava directory to VA's usansf directory, (b) deleting the old va.va007fwy.wpt, etc. files from the local usansf directory, (c) renaming the new "full" files in that directory to the names of the corresponding deleted files, and (d) doing a pull request to get it all added to the GitHub master? No changes needed to .csv files, and no duplicate route files in different places on the master.

If so, that's something I could do tomorrow, since my family does its Christmas festivities tonight.

[yakra]

You'd still need to delete each line in usava.csv & usava_con.csv -- well, not need to, strictly speaking I guess, to avoid route name collisions, but I would still consider it best practice WRT the integrity of the data.

So yes, your approach works.
That said, I just don't like the idea of having the "(Freeway)" in the CSV City/description field, or the "fwy" appended to a Root/filename of a full-length route.
The latter item especially can be confusing for travelers: consider the inclusion of "VA VA168Fwy NC/VA 15A" in deathtopumpkins.list.

I suggest:
Things to do for each:
- Add/copy new file to usansf/
- delete old (va.va007fwy.wpt, etc.) file from usansf
- fix line in usansf.csv
- fix line in usansf_con.csv
- delete line in usava.csv
- delete line in usava_con.csv

While at it, a quick peer review of the extensions of each affected route wouldn't hurt.

Oh what the hell. With only four files (VA7, VA28, VA168, VA262) affected, this isn't as hard to do as my initial hesitation would suggest. I'll have a go at it in the next few hours.

[74/171FAN]

All I did was put my VA route information in a separate text file until the system is activated.  That has been how I have avoided issues for now.  Obviously I will copy and paste my temporary text file data into my normal .list file when VA is fully activated.

EDIT: Ok I was being skeptical but I will go ahead and put my VA data in my .list file and post here (or in the VA thread) if I notice any issues.

[yakra]

Of course, putting new info into your normal .list file does help us find issues to fix.