Status of Travel Mapping

[SD Mapman]

Site update finishing up now with a few minor highway data updates and .list file updates submitted today.  We're up to 55 .list files being processed.

Speaking of North Dakota, according to their 511 road condition site, US 85 is routed along the Watford City Bypass to the west, ND 23 is to the east, and the former routes are now business routes. Oh, and the ND 23 Truck route in the HB is marked as ND 23A. Not sure what that means.
http://www.dot.nd.gov/travel-info-v2/ (It won't let me save the location, sorry)

[yakra]

Thanks. The Watford City bypass has been on my radar, but I've held off on updating that while I try to get a few bits of info sorted out. If you've been to the area and seen how any of this is signed, can you provide any insight?

ND 23:
Does it end at US85Bus, or overlap with it for that last little bit to US85 / ND200, as OpenStreetMap & Google would suggest?

Old ND 23:
Is this actually signed as a ND 23 Business bannered route now?
Does it still end, as ND 23 used to, at Main St & 2nd Ave? Does it overlap with US 85 Business to meet ND 23 proper?

ND 23A / ND 23 Truck:
GMSV (old, lo-res imagery) shows this signed as ND 23 Truck. So in it went.
I get the impression that that ND ##A (and other letter suffixes) are internal designations, for routes signed in the field as ND ## Alt (click on the middle work zone icon on the 511 map and you'll see it described as such), or in this case, Truck.
With a real proper truck bypass to the southeast now, would this even still remain a signed truck route? Maybe 23 Alt instead? Or have its signage/designation removed entirely?

[SD Mapman]

I'm just pulling this off of the Internet, but I might be in that area this spring (don't quote me on that). I would assume that ND 23 goes all the way to US 85; it's an important route and I think it would be confusing if it just spurred off of a business route. Also, I'm pretty sure Bus 23 would be signed along Bus 85 and along the old routing.

Here's some more pdfs (the second one is a big one; the relevant info starts at about page 124)
http://www.dot.nd.gov/dotnet2/news/docs/2014releases/20141028-watfordbypasses.pdf
http://www.dot.nd.gov/divisions/planning/docs/highwayinfo/williston.pdf

[johnintx]

Thanks. The Watford City bypass has been on my radar, but I've held off on updating that while I try to get a few bits of info sorted out. If you've been to the area and seen how any of this is signed, can you provide any insight?

ND 23:
Does it end at US85Bus, or overlap with it for that last little bit to US85 / ND200, as OpenStreetMap & Google would suggest?

Old ND 23:
Is this actually signed as a ND 23 Business bannered route now?
Does it still end, as ND 23 used to, at Main St & 2nd Ave? Does it overlap with US 85 Business to meet ND 23 proper?

ND 23A / ND 23 Truck:
GMSV (old, lo-res imagery) shows this signed as ND 23 Truck. So in it went.
I get the impression that that ND ##A (and other letter suffixes) are internal designations, for routes signed in the field as ND ## Alt (click on the middle work zone icon on the 511 map and you'll see it described as such), or in this case, Truck.
With a real proper truck bypass to the southeast now, would this even still remain a signed truck route? Maybe 23 Alt instead? Or have its signage/designation removed entirely?

Long time lurker, first time poster...

I was in North Dakota this summer, and was on both the new US 85 bypass and the old road through Watford City. I do remember that ND 23 has been extended to the new US 85 bypass. I do not remember any of the other signage. :-)

[bejacob]

OH 794 no longer exists even though it still appears on Google Maps.

On 10/4/2015, I was south of Springfield, OH and drove what used to be OH 794. From what I can tell, it was decommissioned as a state route and turned over to Clark County in late 2013. All state signage has been removed along the entirety of the route.

This may already be in the queue for updates in Ohio (along with OH 762 and OH 38/238). If not, I wanted to make sure it got added.

[yakra]

I've decided how I'm going the handle the Watford City bypass and related changes:

ND23:
I'll do as OSM, Goog, and SD Mapman suggest and run ND23 all the way to US85 proper.

ND23Bus:
Although there's some precedent for bannered routes only connecting to the parent at one end (ND23TrkWat (as it is shown now, pre-bypass, US85 <-> ND23), ND200AltHil), I'll go with SD Mapman's suggestion and overlap it with US85Bus. The concurrency is shown in OSM; that's enough to tip the scales in favor of convincing me. If we find out it's incorrect later, we can cut it back; if we need to avoid breaking .list files we can set the (deprecated) labels from the truncated portion to map to the new terminus.

ND23Trk:
I'll just go with the status quo and leave this in for now, albeit with changed labels for the termini (at ND23Bus). If we find out later that it's been removed (either via updated NDDOT maps or someone finally getting out there in the field to clinch some stuff), we can handle that then.

Edit: Pull request is in:
https://github.com/TravelMapping/HighwayData/pull/127

[Jim]

Some site functionality is not working at the moment.  The last update I ran failed part way through the DB update.  My guess is that with some new users and highway data, we've reached a point where some SQL statement needs to be broken up into multiple statements or something like that.  I might be able to investigate tonight.  If not, I'll do my best to fix it tomorrow.

[Jim]

Some site functionality is not working at the moment.  The last update I ran failed part way through the DB update.  My guess is that with some new users and highway data, we've reached a point where some SQL statement needs to be broken up into multiple statements or something like that.  I might be able to investigate tonight.  If not, I'll do my best to fix it tomorrow.

Temp fix is in and things are up again.  My suspicion was correct - a few new users (not their fault) caused one of my SQL statements to get too long (it was over 85,000 lines long!).  I broke it up manually to get the DB populated for now.  I will have to make and test a couple minor changes before I run the next update.

[Jim]

Thanks to the work primarily of Si and Eric we have added around 1000 new routes recently (I think the actual number is 993).  Many in Europe (some in active systems), over 700 in Texas (all in-development for now there).  The new in-development systems are usatx, usatxl, and usatxs, for the Texas State Highway system, its loops, and its spurs, respectively.

We've had progress made toward the Utah State Highways being ready for activation.

More new users have submitted .list files, bringing Travel Mapping to over 65 active users.

There are now 17280 routes with a total of 366871 points and 349591 segments in 117 highway systems in the database.  The database update file now is over 2.8 million lines long.  Yet it still takes only about 10 or 12 minutes to generate, upload, and load into the system.

[bejacob]

Good news about the Texas routes. Looking forward to having those as part of the mix.

Any update on the progress on NM state routes? Last I saw, those were getting close to going live. It's nice to see so much happening.

[Jim]

Any update on the progress on NM state routes? Last I saw, those were getting close to going live. It's nice to see so much happening.

Oscar's compiled a fairly extensive list of (mostly minor) items that need fixing for NM at https://www.aaroads.com/forum/index.php?topic=15733.msg2092865#msg2092865.  I'll look at and take care of them when I have a chance (possibly not before Thanksgiving weekend or maybe even my Christmas/New Year break) but of course anyone is welcome to make fixes and submit pull requests to help move the process along more quickly.

[vdeane]

Is the site down?  Was halfway through a very large update to my .list file (since I FINALLY have time today) when the pages stopped loading, and now Chrome keeps prompting on whether to kill them or not every 10 seconds.

EDIT: things started working again after I chose "kill" instead of "wait".

[Jim]

Is the site down?  Was halfway through a very large update to my .list file (since I FINALLY have time today) when the pages stopped loading, and now Chrome keeps prompting on whether to kill them or not every 10 seconds.

EDIT: things started working again after I chose "kill" instead of "wait".

Guessing your timing was just bad.  The site goes into a bad state for about 30 seconds each time I run an update, as the old database tables are dropped then re-created and re-populated.  The site update is now complete and as far as I can see from here, all is well.

[vdeane]

Is the site down?  Was halfway through a very large update to my .list file (since I FINALLY have time today) when the pages stopped loading, and now Chrome keeps prompting on whether to kill them or not every 10 seconds.

EDIT: things started working again after I chose "kill" instead of "wait".

Guessing your timing was just bad.  The site goes into a bad state for about 30 seconds each time I run an update, as the old database tables are dropped then re-created and re-populated.  The site update is now complete and as far as I can see from here, all is well.

And then Chrome apparently gets into a bad state when that happens.

[wphiii]

This isn't really important, but just out of curiosity I was wondering if there's an explanation for the discrepancy in the stats displayed in the map viewer versus the stats that the log spits out. For instance, for me, the map viewer says 5032.12 of 18713.57 miles (26.9%) clinched for PA, while the log says PA: 4330.07 of 17455.54 mi (24.8%). Is there something weird going on with concurrencies, or...?

[Jim]

This isn't really important, but just out of curiosity I was wondering if there's an explanation for the discrepancy in the stats displayed in the map viewer versus the stats that the log spits out. For instance, for me, the map viewer says 5032.12 of 18713.57 miles (26.9%) clinched for PA, while the log says PA: 4330.07 of 17455.54 mi (24.8%). Is there something weird going on with concurrencies, or...?

That's a good question.  I would trust the ones in the logs more.  The ones shown on map view are done in PHP and JS and might not have the (I believe) accurate concurrency detection done in Python that's in the logs and the DB. At some point, the map pages will have an option for CHM-style tables showing mileages on each route on the map, each system on the map, and overall stats.  Those stats will come from the DB, and will match.

[Zeffy]

Given that my recent Virginia trip has added a bit more highway mileage to my life, is there anyway I could test out TravelMapping? I used to have a CHM username if that counts for anything. I haven't been following around too much, so I'm not sure what that would entail.

[oscar]

Given that my recent Virginia trip has added a bit more highway mileage to my life, is there anyway I could test out TravelMapping? I used to have a CHM username if that counts for anything. I haven't been following around too much, so I'm not sure what that would entail.

If you had a CHM list file, the "How To Use Travel Mapping" sticky topic on this board will tell you how to update your file and move it to Travel Mapping.

[Jim]

Thanks to a pull request submitted by theFXexpert, the TM highway browser and map overlay viewer now have options for Mapnik and MQOpen tiles.  Please let me know if you notice any problems with the new version.

[bejacob]

Thanks to a pull request submitted by theFXexpert, the TM highway browser and map overlay viewer now have options for Mapnik and MQOpen tiles.  Please let me know if you notice any problems with the new version.

Excellent addition. At first glance all map formats appear to we working fine. Using MQOpen gives the TM highway browser a very familiar look. 

[Jim]

A few people have noticed that the Travel Mapping site's database has been empty for a few hours this afternoon.  This was caused by some typos in new routes imported today.  While this usually doesn't cause such a big problem, here the specific type of errors (duplicate file "roots", such as "ny.i090", that are used as primary keys in the DB) do not show up until the DB tables from the previous update have been dropped and they are being re-created and re-populated from the new data.  I am adding a new check to the data processing script that will check for this kind of problem earlier in the process, so a DB update won't even be attempted if these kinds of mistakes exist.

It looks like I found all such errors for the latest site update run, and that the DB is back to being fully populated again.

[Jim]

Recent updates have pushed the number of waypoints plotted in the Travel Mapping database over 400,000.  This includes both active and in-development systems.

[Jim]

First attempt at custom map colors!  (I didn't feel like grading tonight.)

This is done entirely through query string parameters at this point.  Check out this URL:

http://tm.teresco.org/hbtest/mapviewt.php?rg=RI&u=terescoj&colors=usai:rgb%28255,0,0%29:rgb%280,255,0%29;usaus:rgb%28200,200,0%29:rgb%280,0,0%29;usari:rgb%280,0,255%29:rgb%280,0,128%29

You can type in '(' instead of '%28' and ')' instead of '%29'.  When I copied and pasted the URL, those codes were used.

Note the "mapviewt.php" instead of the normal "mapview.php".  The default "mapview.php" will get this functionality after some of you can help me test it out.

Colors are specified through the new query string parameter "colors".  It is a semicolon-separated list of system names along with the RGB colors to use to plot unclinched and clinched segments, respectively, separated by colons.  For example, I chose to make unclinched usai segments red which is rgb(255,0,0) and clinched usai segments green which is rgb(0,255,0).  Any routes plotted on the map that are part of a system that doesn't have an entry in the colors= qs parameter will go back to using the default colors.

Some day when we have a nice user interface in front of all of this, these query string parameters could be filled in in a more user-friendly way, but the infrastructure is at least in place.

Please let me know if this seems to be working for you, and if no major problems are reported, I'll merge this new functionality into the production version of mapview.php.

Enjoy!

[oscar]

Jim, could you please list the RGB values for the default colors for various types of roads? Other than to replace orange with something less fugly for my map printouts, I might just do mild tweaks from the defaults, but to make those tweaks it would help me to have the starting points. Also, is there a way to make certain route categories (such as unclinched routes) completely invisible?

I took a stab (before this new color change option) at printing out updated replacements for the CHM user maps in the binder I take with me on road trips. Contrary to my expectations, it looks like our traces for clinched routes have enough contrast that they don't get lost in the clutter from the base maps they overlay (especially with the new user option of using Mapnik, which I find less distracting than Google Maps). Unclinched routes can still get lost in the clutter, but I don't really care about those anyway.

I had expected down the road we'd need to go through the CHM exercise of (re)doing land and water boundaries, so we could create uncluttered user maps. Maybe we won't have to do that, and can just let the Google, Mapnik, etc. base maps take care of those boundaries for us.

[SD Mapman]

First attempt at custom map colors!  (I didn't feel like grading tonight.)

This is done entirely through query string parameters at this point.  Check out this URL:

http://tm.teresco.org/hbtest/mapviewt.php?rg=RI&u=terescoj&colors=usai:rgb%28255,0,0%29:rgb%280,255,0%29;usaus:rgb%28200,200,0%29:rgb%280,0,0%29;usari:rgb%280,0,255%29:rgb%280,0,128%29

You can type in '(' instead of '%28' and ')' instead of '%29'.  When I copied and pasted the URL, those codes were used.

Note the "mapviewt.php" instead of the normal "mapview.php".  The default "mapview.php" will get this functionality after some of you can help me test it out.

Colors are specified through the new query string parameter "colors".  It is a semicolon-separated list of system names along with the RGB colors to use to plot unclinched and clinched segments, respectively, separated by colons.  For example, I chose to make unclinched usai segments red which is rgb(255,0,0) and clinched usai segments green which is rgb(0,255,0).  Any routes plotted on the map that are part of a system that doesn't have an entry in the colors= qs parameter will go back to using the default colors.

Some day when we have a nice user interface in front of all of this, these query string parameters could be filled in in a more user-friendly way, but the infrastructure is at least in place.

Please let me know if this seems to be working for you, and if no major problems are reported, I'll merge this new functionality into the production version of mapview.php.

Enjoy!

When I tried to change the colors, it wouldn't work (although this might just be due to me missing something here, and not an actual bug).