Highway Data Discussion (CHM/TravelMapping)

[rickmastfan67]

All "Exit 0" datacheck errors and most "duplicate coordinate" errors have now been marked as FPs thanks to conversion from CHM's list.

Missed two.

wv.us040;I-70(0A);;;EXIT0;
wv.us250;I-70(0A);;;EXIT0;

Also, on the 'unmatchedfps.log' file, maybe add a line to it to say when it was last modified?

[Jim]

All "Exit 0" datacheck errors and most "duplicate coordinate" errors have now been marked as FPs thanks to conversion from CHM's list.

Missed two.

wv.us040;I-70(0A);;;EXIT0;
wv.us250;I-70(0A);;;EXIT0;

Also, on the 'unmatchedfps.log' file, maybe add a line to it to say when it was last modified?

Strange - those are in the .csv file and I don't see them in the unflagged errors on the page.  Are they showing up there for you?

Good suggestion on the log.  Until I can do that, note that it's generated at the same time as everything else you see in http://www.teresco.org/~terescoj/travelmapping/logs/.

[rickmastfan67]

All "Exit 0" datacheck errors and most "duplicate coordinate" errors have now been marked as FPs thanks to conversion from CHM's list.

Missed two.

wv.us040;I-70(0A);;;EXIT0;
wv.us250;I-70(0A);;;EXIT0;

Also, on the 'unmatchedfps.log' file, maybe add a line to it to say when it was last modified?

Strange - those are in the .csv file and I don't see them in the unflagged errors on the page.  Are they showing up there for you?

You're right, they aren't there.  Wondering why they would then show up in the unmatchedfps.log file then.

[Jim]

You're right, they aren't there.  Wondering why they would then show up in the unmatchedfps.log file then.

Sure enough, they're in the log file but also marked as FPs in the database.  I'll have to check it out.  Thanks.

[Rothman]

I-485 isn't a complete loop?

[oscar]

I-485 isn't a complete loop?

It is, but mapping it in TM is still in the queue, as are all the new and extended Interstates in Texas. In the past week, we added I-41 in Illinois and Wisconsin, and new I-49 mileage in southern Arkansas and northern Louisiana.

[Rothman]

I-485 isn't a complete loop?

It is, but mapping it in TM is still in the queue, as are all the new and extended Interstates in Texas. In the past week, we added I-41 in Illinois and Wisconsin, and new I-49 mileage in southern Arkansas and northern Louisiana.

Thanks!  Really looking forward to this project coming together.

[rickmastfan67]

Rothman, if you take a look at the 'old' forums (new ones for errors aren't up yet), you can see us still working on and closing threads there when the updated highway is put into TM.
http://clinched.s2.bizhat.com/index.php?mforum=clinched

[yakra]

mapping it in TM is still in the queue, as are all the new and extended Interstates in Texas. In the past week, we added I-41 in Illinois and Wisconsin, and new I-49 mileage in southern Arkansas and northern Louisiana.

Many Texas updates in my local files. I've started poring thru the trail of bread crumbs I've left thru various threads at the old forum, to compile a list of files to submit, and a rundown of the changes for each.

So far, the update will include:
* I-69W, I-169, I-69 inside I-610
* US190 relocation and business route, Copperas Cove
* US271 relocation and business route extension, Mount Pleasant
* other stuff

[oscar]

Mystery errors in my latest list file update:

Unknown region/highway combo in line: TX US259BusKil US259_S TX42_N
Unknown region/highway combo in line: TX US377BusWhi US377_S US377_N

The just-renamed route files are in the HB under the above names, but they're not parsing under their new names.

[Jim]

Mystery errors in my latest list file update:

Unknown region/highway combo in line: TX US259BusKil US259_S TX42_N
Unknown region/highway combo in line: TX US377BusWhi US377_S US377_N

The just-renamed route files are in the HB under the above names, but they're not parsing under their new names.

Looks like the .csv entries were not completely updated (Abbrev field).  I'll fix and rerun the update.

[Jim]

Looking at some datacheck error detection improvements, and I definitely have too many labels being flagged with the "US_BANNER" error.  CHM has just one:

TN US64 US41A/64BusWin_E uses an incorrect banner with US

I'm inclined to dump that error check altogether.  Opinions?

[Jim]

Tonight, improvements to the "label references own route" datacheck tonight, and an import of all of the FP reports of this type of error from CHM.  I don't pick up all of the errors CHM did, but I think I'm getting the ones most likely to be problematic.  See the unmatchedfps.log file for ones that were reported in CHM as FPs but weren't detected as errors in Travel Mapping, and let me know if you think any of those (and ones like them) really deserve to be detected.

[Jim]

So anyway, I think everything showing up in the datacheck report now are things that should be addressed by fixing the data or reporting as FPs.

[yakra]

Looks like the .csv entries were not completely updated (Abbrev field).  I'll fix and rerun the update.

D'OH!

See the unmatchedfps.log file for ones that were reported in CHM as FPs but weren't detected as errors in Travel Mapping, and let me know if you think any of those (and ones like them) really deserve to be detected.

md.md222;US1/222;;;LABEL_SELFREF;
I think this kind of error/check is worthwhile to add in. This one is a false positive because it references US222.


Thanks for adding these checks in.

[yakra]

Looking at some datacheck error detection improvements, and I definitely have too many labels being flagged with the "US_BANNER" error.  CHM has just one:

TN US64 US41A/64BusWin_E uses an incorrect banner with US

I'm inclined to dump that error check altogether.  Opinions?

It might not hurt to get rid of it. It's not checking for an error someone's likely to create by accident while editing route files; it just picks up on labels that don't conform to standards. The bulk of them were probably fixed when Tim created that error check, and that's it.

OTOH, there still is one to be addressed on the CHM datacheck page. Is this because it was newly created, or just because it was missed in the last route of fixing errors?

[mapcat]

Since we're correcting route names with errors now, someone might want to address I-94BL (Wilbaux, MT).  The name of the town it passes through is Wibaux (no L), so it ought to be mt.i094blwib instead of mt.i094blwil.

[oscar]

Regarding New Mexico, it looks like the following documents have been updated since I last used similar documents in updating NM's national system routes and drafting NM's state highways:

http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf
http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf
http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf

Do we think these are a definitive source about what routes exist and where?

I'm slowly looking through the NM state route set, in CHM's Highway Browser (easier to navigate than TM's, and I assume the contents are so far the same), to pick out routes in the HB that are not on the state highway list above, and routes with waypoints for intersecting routes that may not be in the state system. This is a running list, which I'll add to as I go along, but there are issues with a few route files apparently referring to state routes that aren't.

Routes in the HB, but not on the state list:

NM 598

Routes not in the HB, but on the state list:

NM 237

NM 300 -- unsigned in 2013, as previously noted

NM 345 -- a post elsewhere on this forum suggests this route may have been recently decommissioned, but I haven't followed up on that

NM 545

Route files showing intersecting state routes not on the state list:

NM 2:  339. 340, 507, 557, 558, 560

NM 11: 332

NM 76: 598

Other notes:

NM 16: Some online maps (Google, Bing) indicate route continues southeast on Gallisteo Dam Rd. to its end. State AADT list neither confirms nor disconfirms.

NM 30, NM 68, NM 369, and US 84/285: US 84/285 may have been rerouted through Española (per Google Maps and Bing, but not OSM); if so, would need to adjust north endpoint of NM 30, south end of NM 68, and west end of NM 369. Mapquest also shows rerouting of US 84/285, but suggests that part of all of the old route (Santa Clara Bridge Rd.) is NM 369 or part thereof; not sure I believe that, but something to check out. Complicating things some more: fragments of local news articles (mostly hidden behind paywalls) suggesting talks in recent months between city and state officials about exchanging roadways, but unclear which direction the exchange would go. This is something NMDOT probably could best explain.

NM 38: recenter waypoint NM522 (and corresponding point on NM 522)

NM 55: recenter waypoint NM131 (and corresponding point on NM 131)

NM 68 and other state routes: NM 68 junctions with NM 75, NM 76, NM 240, NM 291, and NM 585 should be recentered (one off by about 0.2 mile)

NM 75 and other state routes: NM 75 junctions with NM 68, NM 76, NM 518, and NM 580 should be recentered

NM 96: recenter waypoint NM112 (and corresponding point on NM 112)

NM 103: OSM and Google Maps suggest route extends about 1 mile east of End waypoint; state log does not confirm or disconfirm

NM 105 and NM 276: OSM indicates NM 105 loops through Rociada, and NM 276 meets NM 105 there. Other online maps disagree. But state log indicates NM 276 does not leave San Miguel County, which supports OSM's routings for both NM 105 and NM 276.

NM 111: recenter waypoint CR447

NM 112: recenter waypoint NM514 (and corresponding point on NM 514)

NM 115:  OSM (but not other maps), and state log, suggest route continues past waypoint CR455, south to and beyond Canjilon

NM 119: recenter NM451 waypoint (and corresponding point on NM 119)

NM 120: recenter NM434 waypoint (and corresponding point on NM 434)

NM 122: suggest/request new point at what Bing labels Berryhill Rd. about a mile north of waypoint NM606, and OSM calls Highway 605 (really old NM 605 at best, since you already have an NM 605 point further south on NM 122). This is the last intersection before westbound old US 66 turns into a two-lane road. From my 1965 road atlas, it seems to most closely approximates where we drove the old route on a family move to California in 1964, before switching over to the new I-40 freeway west of Grants.

NM 143: recenter waypoint NM198, and perhaps also flip waypoint order since route is milemarked north to south (from NM 549)

NM 150: ThuRd -> ThuRd_E (not necessary to add waypoint for ThuRd_W)

NM 161: delete waypoint CR12 (point far off route, CR 12 may not intersect NM 161); recenter NM518 waypoint (and corresponding point on NM 518)

NM 198: recenter waypoint NM143, and perhaps also flip waypoint order since route is milemarked north to south; End -> SprCanSP

NM 203: move west endpoint west to county line, per state log

NM 206: US70/NM267 -> US70/267

NM 220: recenter waypoint CRD003 on intersection with Paso Monte Rd.

NM 223: NM50/65 -> NM50/63

NM 227:  recenter NM478 (and corresponding point on NM 478)

NM 229/MN 357/new US82 Truck?: OSM (but not other online maps) suggests that there is new US 82 truck route in Artesia (state AADT log shows no US truck or other bannered routes anywhere), if so US82 -> US82/82Trk and NM357 -> US82Trk/357; also, Google Maps and Bing but not OSM suggest south end of NM 229 includes Four Dinkus Road back to US 285, which might explain difference between mileage in the HB and mileage in the state AADT log.

NM 236 and NM 267: OSM and Bing suggest NM 236 extends several blocks southeast from waypoint NM267_E along W. Fir St. to N. Ave. B in Portales, where it meets NM 267, which uses Ave. B over new railroad crossing to connect to US 70 and NM 206; state AADT log unclearly suggests that routing of NM 267

NM 240: recenter CamCul

NM 246: recenter CRB031, CRB020, CRB030

NM 290: recenter SprLn

NM 329: does route also include Mills Ave. between NM 65 and I-25BL? OSM, GM. Bing seem to think so, even though it's not in state AADT log.

NM 348: Part of the route seems to be in Texas, though the state AADT log has the whole route in two New Mexico counties. I'd be inclined to treat this as a minor mis-mapping of the state line and not break the route in two or three parts for supposed state line crossings.

NM 369:  recenter CR7

NM 371/NM 5001/new US 64 alignment/new US 64 Business:  OSM and other mapping services have US 64 through Farmington moved to a new alignment which used to be NM 5001 (which should be deleted from HB), with NM 371 continuing to the old alignment which is now US 64 Business. So for NM 371 route file, NM 5001-> US64, US64 -> US64Bus; conforming changes needed for US 64 route file, as well as a new one for US64BusFar.

NM 378: recenter both endpoints, and corresponding NM378 point for NM 522

NM 395: state AADT log indicates route is more than twice as long as shown in the HB, but truncated entry in online log does not indicate where to put the south end

NM 412: replace JefRd point (Mapnik doesn't show that road intersecting NM 412) with nearby LoriDr (more consensus among online maps on that intersection).

NM 419: JunRidRd -> CRC55A, and recenter

NM 442: HuRd -> LosHueRd

NM 466: waypoint NM300 refers to unsigned intersecting route not in the HB, though on the state AADT log; delete?

NM 475:  PasPri -> LaEnt (this point is useful for people who visited the popular Ten Thousand Waves spa north of this intersection, even if point is not needed for shaping)

NM 502:  Waypoint CR84 is nowhere near an intersection, or CR 84 (which appears not to intersect NM 502). Suggest making this a hidden shaping point, or substituting a nearby intersection point.

NM 511:  recenter waypoint CR4600

NM 518: missing waypoint for NM 434, to match NM518 waypoint in NM 434 route file -- note that I picked this up by accident, there might be other instances where a waypoint on one route lacks a corresponding point on an intersecting state route

NM 540: Mapnik and other online maps suggest this route has become a loop route, with the northern leg connecting back to NM 39, since the last AADT measurement in the state route log (which reflects only the southern leg).

NM 547 and I-40BLGra: State route log has route starting at Santa Fe Ave. (I-40BL) in Grants. Google Maps and Bing show south end of route at Santa Fe @ 1st St. That would mean adding a waypoint there (with corresponding new point on I-40BLGra), new RooAve_S point, and RooAve -> RooAve_N.

NM 552: recenter SR552Ext (is that another state route, though not shown in route log?) and End

NM 554: recenter CR477

NM 572 and NM 331: state route log indicates route runs twice as long as the HB has it, and extends to meet NM 331 at La Puente. Google Maps, but not Mapnik, sorta agrees. NMDOT online road conditions map also agrees, if you zoom it in just one level before it switches from DeLorme data to Bing at more detailed zoom levels.

NM 602: recenter BMWellRd (far from intersection as shown in Mapnik. but matches Google Map and satellite location), or perhaps delete point or relegate to shaping point.

NM 6563: PeaLn -> PieCanRd

There are many other waypoints that could be recentered, in the unlikely event you think I'm not being fussy enough. I've tried to focus on the more significant ones, especially at junctions between state routes.

[Jim]

Since we're correcting route names with errors now, someone might want to address I-94BL (Wilbaux, MT).  The name of the town it passes through is Wibaux (no L), so it ought to be mt.i094blwib instead of mt.i094blwil.

I'm running an update with this fix, and it will be in GitHub also very soon.  Thanks.

[Jim]

See the unmatchedfps.log file for ones that were reported in CHM as FPs but weren't detected as errors in Travel Mapping, and let me know if you think any of those (and ones like them) really deserve to be detected.

md.md222;US1/222;;;LABEL_SELFREF;
I think this kind of error/check is worthwhile to add in. This one is a false positive because it references US222.

I refined these checks quite a bit.  I picked up everything CHM did and a few others (in cases where a label in a route with a banner intersects its parent refers to that parent as part of a "slashed" label) like:

al.us072altdec;US43/72;;;LABEL_SELFREF;

There were about 20 of those, all of which I marked as FPs.  That seemed much easier than sinking more time into refining the "LABEL_SELFREF" checks to avoid flagging them.

Does anyone see anything of major concern in either the datacheck.php page list or in the unmatchedfps.log?  I don't mean the errors themselves (of which we still have many to deal with) but things showing up in datacheck that shouldn't or things still in unmatched that should be showing up.

If you see entries in unmatchedfps.log that refer to routes that no longer exist or parts of routes that have since changed, please go ahead and delete the corresponding entries from datacheckfps.csv.  I removed several tonight as I was working on improving the LABEL_SELFREF checks.  Hopefully before too long, both the datacheck.php page's first table (active routes) and unmatchedfps.log can be empty.

[yakra]

I think it would still be worthwhile to refine the code to avoid flagging examples like the one cited above.
Or for another example, tx.us077bushar;I-69E/77;;;LABEL_SELFREF;
It just doesn't sit right with me to flag these, as they're not really self-references at all, but references to the parent route. And especially in the tx.us077bushar case, a pretty legitimate one.

Of course, if you don't feel it's worth sinking much more time into, I can't fault you for that; it's not really fair for me to shout "Fix this!" and not do anything to that end myself...

Can you point me in the direction of the file containing this code on GitHub, and maybe the relevant lines if it's a huge-ish file? I can always have a look around & see what I can see, and scratch my chin thoughtfully... or let real life get in the way and forget about it completely... ;P

[Jim]

I think it would still be worthwhile to refine the code to avoid flagging examples like the one cited above.
Or for another example, tx.us077bushar;I-69E/77;;;LABEL_SELFREF;
It just doesn't sit right with me to flag these, as they're not really self-references at all, but references to the parent route. And especially in the tx.us077bushar case, a pretty legitimate one.

Of course, if you don't feel it's worth sinking much more time into, I can't fault you for that; it's not really fair for me to shout "Fix this!" and not do anything to that end myself...

Can you point me in the direction of the file containing this code on GitHub, and maybe the relevant lines if it's a huge-ish file? I can always have a look around & see what I can see, and scratch my chin thoughtfully... or let real life get in the way and forget about it completely... ;P

I agree wholeheartedly that the example above shouldn't flag an error, I just ran out of time to tweak the check to avoid flagging it.  I'd be very happy to bring in any change that avoided it if you get a chance to take a look and have ideas.  The relevant code is at https://github.com/TravelMapping/DataProcessing/blob/master/siteupdate/python-teresco/read_data.py starting around line 850.  It's possible (and I hope) that there's a quick fix that I didn't see.

[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.

[oscar]

Jim, I've finished my review of the draft NM state route files, with detailed notes a few posts upthread. Still some items requiring followup, such as to confirm possible changes to some US routes.

[Jim]

Jim, I've finished my review of the draft NM state route files, with detailed notes a few posts upthread. Still some items requiring followup, such as to confirm possible changes to some US routes.

Excellent, thanks.  I'm totally swamped right now, so I won't be making any fixes myself in the next few weeks at least, but would gladly process pull requests for any fixes you or others have time to put together to address at least parts of what we know needs addressing.