Those of us not involved in creating the new CHM/Travel Mapping site would love to hear updates regarding the status of the new site. What are you currently working on, and when do you expect to have various components complete?
Thanks to all of you who have volunteered to resurrect CHM.
I'm working at bringing files (mostly in Europe) up-to-date. As I have (half an hour ago) finished my last assignment for the summer, I could, in theory, get it done by a couple of weeks time. However, I doubt that urgency is needed, so I'll probably take my time with the remaining few countries (Spain, Germany, Poland, Sweden) and spend time finishing French N roads and other such future systems (and perhaps borders, though they are really boring).
Also (as a reminder to me) US6 in CO needs tweaking after the AASHTO decision.
Quick status update:
I have python code that can now read in all of the highway data and put it into a database. .list data next. It's the first database of any significance that I've designed, so I'm sure I've made some bad decisions. I hope to learn more about how to do it right as I continue.
My first visible evidence of progress is a very basic highway browser that reads its data from that database. All it can do is take a highway's internal "root" name, read the points from the database, and put those points in a table and onto a map. For example, to see I-88 in New York:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.i088 (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.i088)
Replace the "ny.i088" with your favorite plotted route in the US or Canada (Europe's not in the DB yet) to see others.
Anyone with some HTML/JS/PHP skills is welcome to take this basic model and come up with something more pretty and functional. There are several ways this could be managed - if interested let me know and we can figure out how you can get the file to populate your own database, or get you some read access to a database I can put somewhere for your development.
Quote from: Jim on June 09, 2015, 11:51:59 PM
My first visible evidence of progress is a very basic highway browser that reads its data from that database. All it can do is take a highway's internal "root" name, read the points from the database, and put those points in a table and onto a map. For example, to see I-88 in New York:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.i088 (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.i088)
It might be basic visually but damned if it isn't fully functional. I could map my travels using this no problem.
I actually like the little green d-pad dots more than the google pushpin balloons the old site had. Less visually cluttersome and they get in the way of each other a lot less since they don't stick out from the line as much.
Quote from: Duke87 on June 10, 2015, 12:06:38 AMIt might be basic visually but damned if it isn't fully functional. I could map my travels using this no problem.
Extra functionality is intersecting routes and alt labels. The former is very useful, the latter somewhat useful. Oh, and links back to the browser.
Great job!
Quote from: Duke87 on June 10, 2015, 12:06:38 AM
I actually like the little green d-pad dots more than the google pushpin balloons the old site had. Less visually cluttersome and they get in the way of each other a lot less since they don't stick out from the line as much.
They're tiny versions of a little icon that's supposed to be two roads intersecting (with dashed yellow lines separating lanes). Admittedly, much of the already limited detail was lost in shrinking down to 16x16 pixels.
Jim: good start. In addition to the other suggestions, I don't think it's necessary to list the shaping points, so that might be something for whomever follows up to work on in the next rendition.
All existing systems are now in the database and can be viewed by the draft highway browser.
Quote from: Duke87 on June 10, 2015, 12:06:38 AM
It might be basic visually but damned if it isn't fully functional. I could map my travels using this no problem.
I actually like the little green d-pad dots more than the google pushpin balloons the old site had. Less visually cluttersome and they get in the way of each other a lot less since they don't stick out from the line as much.
Amen and amen. It's not got a spiffy, tricked-out design, but the function is all there. The latter is much more important. And as far as I can see, it's got every highway in the old CHM plus all of the in-development systems too. I'm super delighted to see this. Also, I too like the intersection markers sitting on the intersection.
A couple quick improvements on the draft highway browser just now. Hidden waypoints are no longer shown in the table of waypoints, and clicking on a waypoint name in the table centers the map on that point. The intent is to bring up an "info window" pointing at the marker on the map like the old HB, but that's not happening for some reason.
The version that's up now, minus my mysql username and password, is available in Github in the TravelMapping/Web repository.
The last few days' efforts in detecting clinched segments and getting them into the DB in a meaningful way have finally paid off tonight with a big enhancement to the draft highway browser. This included my most complex DB queries yet (though anyone with real DB experience would probably laugh at them). The HB now takes a second query string parameter - the username of someone whose .list file has been processed into the DB, and will show that user's travels on a given highway.
For example, to see my travels to date on NY 5:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny005&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny005&u=terescoj)
A couple things:
- No concurrency detection, yet. But that is going to be relatively easily taken care of on the Python side, so the DB won't care if you clinched a segment because it was in your list or because some other concurrent segment was, and since the DB won't care, the HB won't care.
- I know it's ugly and not user-friendly and the markers are too big and all of that.
- I'm happy to bring in .list files of others who might want to be able to browse their travels this way and the next time I run a DB update, they'll be there.
I'm game. Where should I send my list file to for that?
Quote from: Jim on June 13, 2015, 10:37:20 PM
For example, to see my travels to date on NY 5:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny005&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny005&u=terescoj)
Jim, I just noticed an error in that file. Have you had a chance to update the reconfiguration of the US-20/NY-5/NY-438 area in the files? They replaced the separate intersections (w/ one traffic light) into a roundabout for all 3 routes. That means 'US20_Irv' needs to be merged with 'NY438'. Updates to all 3 routes are needed.
James: as I recall, we're focusing on getting an operational reader/browser/website before we look at route file updates.
Jim: feel free to use my .list
Excellent work, Jim!
Re the waypoint marker size: I don't think they're too big. Sure, for a route as long as NY5, there are so many that they obscure the route (as did the CHM markers), but for a shorter one, they're not bad at all.
Thanks to all who have volunteered their time so far. It's great to see that the project will live on.
Quote from: rickmastfan67 on June 14, 2015, 12:02:20 AM
Jim, I just noticed an error in that file. Have you had a chance to update the reconfiguration of the US-20/NY-5/NY-438 area in the files? They replaced the separate intersections (w/ one traffic light) into a roundabout for all 3 routes. That means 'US20_Irv' needs to be merged with 'NY438'. Updates to all 3 routes are needed.
Noted in the old CHM forum so I'll remember when the time comes, thanks.
Quote from: Jim on June 13, 2015, 10:37:20 PM
- I'm happy to bring in .list files of others who might want to be able to browse their travels this way and the next time I run a DB update, they'll be there.
Awesome. It will be great to be able to see the maps and states for individual routes again, as well as the log. I'm sure there's at least one typo somewhere in my .list file that I never saw.
I liked to it earlier, but here it is again, updated as recently as this morning: http://nysroads.com/files/aaroads/vdeane.list
Today was concurrency day. Concurrent segments are now detected, and travelers get credit for all concurrent segments if at least one of them is in their .list file.
See what segments were detected as concurrent, and which segments travelers were credited with based on concurrencies in http://www.teresco.org/~terescoj/travelmapping/logs/concurrencies.log (http://www.teresco.org/~terescoj/travelmapping/logs/concurrencies.log). Every single concurrent segment (the single segment between two consecutive waypoints) is reported, unlike the way the old CHM project joined these together into larger concurrent segments. Adding that is a low priority, I'd say.
There are now 15 .list files included. Any of those 15 should be able to see their travels on a single highway with a region, including detected concurrencies by visiting the same URL as in recent days, substituting the traveler name and route name as appropriate. E.g., http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny005&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny005&u=terescoj)
Also, some missing CA routes were added.
The next step needs to be some efficiency improvements. All steps are fast except processing .list files (now almost 5 minutes) and loading the DB (about 20 minutes, as it's now just a big old SQL file with 1,214,141 lines. I have learned of some better ways that I hope to try out the next time I have a chance to put some time into the project).
For now, I continue to welcome reports of anything odd in log files, or any errors you can find in the concurrency detection.
Quote from: Jim on June 14, 2015, 10:56:54 PM
Every single concurrent segment (the single segment between two consecutive waypoints) is reported, unlike the way the old CHM project joined these together into larger concurrent segments. Adding that is a low priority, I'd say.
Indeed. Seems to me at least this is "log for nerds who want to see code line by line", not so much something the average user would need to see. Presumably once stat pages are constructed any autodetected concurrencies would be reflected there, in a more graphical and user friendly way than this.
One thing I do like though is that it's only listing segments the algorithm is adding to a user's stats, not just every concurrency in the users travels, which I believe the old site did. For all my lines of autodetected concurrency, there are conspicuously none in Connecticut - because I have the whole state clinched, so the algorithm has nothing to add!
Just updated mine (nailed down the entirety of WA 503 yesterday... save for the Brush Prairie business loop).
Quote from: Duke87 on June 15, 2015, 01:45:47 AMIndeed. Seems to me at least this is "log for nerds who want to see code line by line", not so much something the average user would need to see. Presumably once stat pages are constructed any autodetected concurrencies would be reflected there, in a more graphical and user friendly way than this.
I'd call it the "log for the programmer who wanted to see exactly what the algorithm was doing." I'd like to either have something easier to understand in the either in per-user logs or a separate log like this one, and/or a map where one could browse the detected concurrencies, likely with a "u=" query string parameter to restrict to autodetected concurrencies for a given user. Again, that's for down the road.
After efficiency improvements, I think the priorities should be:
- Nail down data formats and convert (if needed) to them. I worry about this step until we get a route editor up and running with the new format. I don't think implementing a new editor is especially difficult, but I'm hoping someone else will take it on. I can continue on data processing work with the old format, but I do think we should make the switch before starting highway updates and adding new systems. There's a huge backlog of fixes to existing systems, several in-development systems that are probably close if not ready to activate, and a good number of people itching to contribute new things. It should be trivial for me to load in data in a new format if and when the format change happens - just a couple lines of the Python code will change.
- More maps. Both Google Maps and the image files like the old CHM project produced. I think everything needed to support these is in the DB now, but I'm sure I or others who implement these parts might want additional information or information in more convenient formats.
- Start generating some stats. I think this is mostly best done on the Python side when a site update is running, when so much information is in convenient to access data structures. The stats could be displayed in log form to start, then added to the database to be put onto pretty web pages. I'll probably start with things similar to what we see in the old CHM project, but I think there's all kinds of room to do interesting things here.
- Lots more of the web-facing infrastructure. I'm generating some pages that have the PHP code that queries the DB and puts up the basics, but I'm hoping others with better web design skills than me will take the lead on this.
I'm very excited about the newest enhancement to the draft highway browser, one that was always on my wish list in the old CHM project. Now, if you specify a region and a username, you will get a Google Maps plot of all routes in that region, with the user's travels highlighted. For example:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=MA&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=MA&u=terescoj)
Of course, you'll need to zoom in a bit to see anything useful with so many waypoint markers and routes plotted in most regions. It also is using the same code (so the same simple page design) used for viewing a single highway, and doesn't show any stats yet. But this is an important proof-of-concept that we can provide lots of interesting maps right from the DB. And it's fun to see my travels in this format, and including those after November 8, 2014.
Those whose list files are in the system, please browse around and look for any problems. I looked at quite a few regions with my own travels and everything looks good so far, but there are definitely many aspects of this that are lightly-tested at best. In particular, I am relying on things coming out of the DB in a particular order so any reports of odd-looking routes or incorrect clinches are welcome. Note that in-development systems will be included on the map, but your clinched segments will not be highlighted, even if they are specified in your .list (for now).
Enjoy!
Quote from: Jim on June 16, 2015, 06:31:40 PM
I'm very excited about the newest enhancement to the draft highway browser, one that was always on my wish list in the old CHM project. Now, if you specify a region and a username, you will get a Google Maps plot of all routes in that region, with the user's travels highlighted.
1. That's an awesome feature.
2. That's a killer awesome feature.
3. Thank you.
That said, on my California file, I noticed a gap in the 405 just east of Long Beach. I suspect, but don't know, that it may have something do with the order in which concurrencies are rendered (and whether they are in active vs. in-development systems). Maybe fixable, maybe a bug that can't be fixed. But there it is. Otherwise, like I said, it looks great and I can't find any other weirdness in it.
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=CA&u=sipes23
Edit to add: Yeah, same thing in MT too. Where MT 200 runs concurrent with I-90, it's gray. Maybe a layering thing.
You're welcome!
Quote from: sipes23 on June 16, 2015, 07:50:53 PM
...Maybe a layering thing.
Yes, that's exactly it. The inactive CA (and MT) systems are being drawn (as unclinched) on top of the clinchable ones (which were drawn as clinched). I'll see about adding a check for plotting activated systems only.
Love this! Thank you!
I like how concurrent routes are being rendered multiple times (the pink shading looks more vivid where two clinched routes overlap). Even in cases where my list file only included one of them, the concurrency still shows.
Well done, Jim!
Totally awesome there Jim!! Thanks to it, I noticed we have a major problem with one of the PA State Highways with two points in an incorrect order. I'll make a post about it in the old forums so we can fix it right away when we start doing that stuff.
For these regional maps only, would it be possible not to display the waypoints?
That is AWESOME. Not quite as nice as the regular maps, but still wonderful to be able to see the maps at least in some form again. I'm currently going over every state/province where I've clinched new roads since my last processed .list file at CHM.
I like. Easier to zoom in and get a feel for what you missed. (Though I had nabbed a few since 11/8/14 but was too lazy to send it - I'll get off my ass sooner rather than later :sombrero: )
Quote from: Jim on June 16, 2015, 06:31:40 PM
I'm very excited about the newest enhancement to the draft highway browser, one that was always on my wish list in the old CHM project. Now, if you specify a region and a username, you will get a Google Maps plot of all routes in that region, with the user's travels highlighted. For example:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=MA&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=MA&u=terescoj)
1. My browser crashed the first time it tried to load. I had to restart it. Then the site worked.
2. Is there a way to turn on/off the markers? It's hard to see the road underneath.
Quote from: Jeff Morrison on June 17, 2015, 05:44:33 PM
2. Is there a way to turn on/off the markers? It's hard to see the road underneath.
^This.
There are tons of improvements that yesterday's new mapping feature needs, and turning on/off the markers is definitely one. Once I fix the problem of inactive (unclinchable) segments greying out clinched segments by drawing right on top of them, that's likely next on the list.
Three improvements to the region-wide clinched mapping with Google Maps:
- checkbox to hide markers
- inactive systems now ignored to avoid overlaying unclinched over clinched segments
- lines are narrower to improve visibility when maps zoomed out
Quote from: Jim on June 17, 2015, 10:26:57 PM
Three improvements to the region-wide clinched mapping with Google Maps:
- checkbox to hide markers
- inactive systems now ignored to avoid overlaying unclinched over clinched segments
- lines are narrower to improve visibility when maps zoomed out
Another reason why inactive systems need to be ignored is that some of them have serious errors yet to be fixed by their maintainers. I know of a few in AK (major reroutes needed for AK 5 and one AK 10 segment) and at least two in CA (never-built -- not "relinquished" -- part of CA 39 between Azusa and La Habra, and CA 86 moved to and absorbing the former 86S). Those systems are inactive for a reason! Leave them undisplayed (or displayed separately from activated systems) until they're ready for prime time.
I'm back home from a long road trip, and will probably have more to add once I catch up on sleep.
Quote from: Jim on June 17, 2015, 10:26:57 PM
Three improvements to the region-wide clinched mapping with Google Maps:
- checkbox to hide markers
- inactive systems now ignored to avoid overlaying unclinched over clinched segments
- lines are narrower to improve visibility when maps zoomed out
Cool.
Now that's just too cool.
One odd thing I note is that unclinched segments are sometimes but not always layered on top of clinched ones. See for example here:
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FwSmyQhS.png&hash=4b416aadf1087ff40013e4469f849fb4460e1e3d)
Unclinched 298 is layered under clinched 481 (as, IMO, it should be), but unclinched 290 and 5/92 are layered over it.
I'm not seeing any particular pattern as to what goes over versus under. I even note that in cases where the same two routes cross multiple times, they don't necessarily maintain consistent layer order. My unclinched US 11 in VA is layering over my clinched I-81 in VA at almost all crossings... except the ones at exits 195 and 213. At those two spots US 11 is underneath.
I tried reloading a few times and it appears what goes over versus under remains consistent each time the map renders.
Quote from: Duke87 on June 17, 2015, 11:27:37 PM
One odd thing I note is that unclinched segments are sometimes but not always layered on top of clinched ones. See for example here:
Rendering order is determined only (at this point) by the order in which the routes are added to the DB, which is from the systems.csv file. That file is currently alphabetical by system code, with all active systems first then in-development systems (which are now ignored). So, when there's an overlap, the one last alphabetically will take precedence. In New York, usai routes go down first, usaif next, usany on top of those, then usaus, and finally usausb. In a future production system, we'd do something more appropriate (clinched on top? top-level systems on top?) or at least something intentional.
Thank you for working hard to push this project forward.
I (and I'm guessing others who enjoyed the CHM site) would like to know if this team has a tentative timeframe of when users will be able to submit .list (or whatever format) files. I expect it will take some time to get things working properly, but it looks like reasonable progress is being made. Not being a technical person, I can't guess whether the time to "completion" is being measures in weeks, months, or years.
Again, I thank you all for the effort and look forward to being to update my travels online once again.
-Brian
Quote from: Jim on June 17, 2015, 11:33:28 PMIn a future production system, we'd do something more appropriate (clinched on top? top-level systems on top?) or at least something intentional.
The obvious solution is backwards from now - higher numbers are going to be less important, and more important systems come first.
This is excellent - I can clearly spot errors I've made on my list file this way, as I can see where stuff doesn't join up.
I know we had some notion of "tiers" in the old site and it probably makes sense to use those. Maybe they should be put into the systems.csv file.
Brian: no timeline yet. A web domain has been reserved, but the programmers (i.e. Jim and others) are still working out the code.
Jim:
I reviewed some of the errors in my log file. Most of the ones I can't figure out have one or both waypoints starting with *:
Waypoint label(s) not found in line: KY I-66FutBow 20(65) *OldCumPkwy
Waypoint label(s) not found in line: FL US98 US98BusPen_W *OldUS98PSJ_W
Waypoint label(s) not found in line: VA US221BusBed US221_S US221_N
Waypoint label(s) not found in line: NC US29 SC/NC *I-85(82)
Waypoint label(s) not found in line: PE TCHPEI NB/PE *StrRd_W
Waypoint label(s) not found in line: PE TCHPEI *ChuRd_E Fry
Waypoint label(s) not found in line: KY CumPkwy 1 *OldCumPkwy
Waypoint label(s) not found in line: NB NB175 *OldNB1_W *OldNB1_E
Waypoint label(s) not found in line: PE PE9 *OldPE1 PE2
The data I checked seems to show both of the waypoints in each line, but for some reason one or the other isn't recognized by the list file parser, and my hunch is that it's the one starting with *.
The other weird one is for VA US221BusBed. Somehow, it got a duplicate of the route file for VA US250BusChr (which is shown correctly in the draft HB).
Quote from: froggie on June 18, 2015, 01:14:20 PM
Brian: no timeline yet. A web domain has been reserved, but the programmers (i.e. Jim and others) are still working out the code.
We will also have to setup our own forum when we're ready to go so people can post error reports. I'm happy to do that part as long as we want to stay with SMF since I know the most about that forum software.
Render unclinched first, layer 3 -> layer 1. Then render clinched segments, layer 3 -> layer 1.
Ignore the * when parsing waypoint labels, so whether "ChuRd_E" or "*ChuRd_E" is used, both will be recognized.
Quote from: yakra on June 18, 2015, 09:26:26 PM
Render unclinched first, layer 3 -> layer 1. Then render clinched segments, layer 3 -> layer 1.
Makes sense. I think I can make that happen next time I get back into the mapping code. I think the same ordering will be used for the static maps.
Quote from: yakra on June 18, 2015, 09:31:27 PM
Ignore the * when parsing waypoint labels, so whether "ChuRd_E" or "*ChuRd_E" is used, both will be recognized.
Yes, I'll fix this. I clearly misunderstood how the "*"s were supposed to be used. Related: if someone's list includes a valid hidden label and includes the "+" in the label, should it match?
Edit: fixed for *'s - let me know if any such errors remain.
Quote from: Jim on June 18, 2015, 10:17:41 PM
Quote from: yakra on June 18, 2015, 09:31:27 PM
Ignore the * when parsing waypoint labels, so whether "ChuRd_E" or "*ChuRd_E" is used, both will be recognized.
Yes, I'll fix this. I clearly misunderstood how the "*"s were supposed to be used.
What are the *s for anyway? I've never used them myself.
Quote from: Jim on June 18, 2015, 10:17:41 PM
Related: if someone's list includes a valid hidden label and includes the "+" in the label, should it match?
I don't think so? If a waypoint's label is hidden, it's probably because it's only for routing purposes and isn't really an entry/exit/intersection point.
Quote from: froggie on June 18, 2015, 01:14:20 PM
Brian: no timeline yet. A web domain has been reserved, but the programmers (i.e. Jim and others) are still working out the code.
If you guys wouldn't mind I'd be happy to host it on my site. :) I'm already paying for a VPS anyway and I'd rather host as much stuff as I can.
Quote from: sammi on June 18, 2015, 10:20:46 PM
Quote from: Jim on June 18, 2015, 10:17:41 PM
Quote from: yakra on June 18, 2015, 09:31:27 PM
Ignore the * when parsing waypoint labels, so whether "ChuRd_E" or "*ChuRd_E" is used, both will be recognized.
Yes, I'll fix this. I clearly misunderstood how the "*"s were supposed to be used.
What are the *s for anyway? I've never used them myself.
They indicate a point that traffic used to be able to leave the route. An example would be a closed interchange. We'd put the * in front of it so people could still mark that they left he highway there.
Quote from: Jim on June 18, 2015, 10:17:41 PM
Related: if someone's list includes a valid hidden label and includes the "+" in the label, should it match?
My own list file includes a few entries using hidden labels, one of which includes the "+" (the hidden labels are used where there isn't a labeled waypoint where I need it). I'll remove the "+" for the new file I'm about to send you, but other people might have "+"s lurking in their list files too.
Quote from: rickmastfan67 on June 18, 2015, 10:23:24 PM
Quote from: sammi on June 18, 2015, 10:20:46 PM
What are the *s for anyway? I've never used them myself.
They indicate a point that traffic used to be able to leave the route. An example would be a closed interchange. We'd put the * in front of it so people could still mark that they left he highway there.
Perhaps more common is where a highway was substantially realigned, and * points indicate where the new alignment peels away from the old alignment, so people who traveled the route pre-realignment would have covered it only up to a peel-away point. That's what happened in most of the log file error entries quoted in one of my posts above (the other was a closed interchange).
Quote from: Jim on June 18, 2015, 10:13:38 PM
Quote from: yakra on June 18, 2015, 09:26:26 PM
Render unclinched first, layer 3 -> layer 1. Then render clinched segments, layer 3 -> layer 1.
Makes sense. I think I can make that happen next time I get back into the mapping code. I think the same ordering will be used for the static maps.
Should be doing this now. It was a lot easier than I thought, accomplished using the zIndex option on Polylines.
Edit: note that if you have trouble getting maps to display your results, there's a good chance you have JS errors in your browser console because an old version of the JS code is cached. A shift-reload worked for me in Firefox.
For those reading the thread wondering what I mean by "layer", it's a concept Tim outlined back in 2010:
Layer 1: Freeway/motorway/expressway systems
Layer 2: Continental systems
Layer 3: State/prov. systems (big countries) and national systems (small countries)
Me, I further break Layer 1 down into:
Layer 1A: Freeway/motorway/ systems (displayed in blue on the static maps)
Layer 1B: Expressway systems (displayed in teal / light green on the static maps)
As an aside, The Layer 2 systems have 3 different color schemes:
* Red for USAUS, CANTCH, and EURE
* Purple for USAUSB
* Dark Green for USAIB
Minor improvements to the clinched segment overlay mapping:
1) overall clinched stats now report, will be adding breakdowns by system, highway, etc, as time permits.
2) line thickness changes with zoom level, so the zoomed-out maps aren't just a blur of fat lines overlapping each other.
So, I thought I would bring this up early in the process, but how are we going to deal with routes that have 'special' shields compared to what the other 'normal' shields are in the state/province/country?
Like the special 'toll' shields in Florida. Are we just going to use the same shield for all, or will we code exceptions to the rule (like the QEW and 407 in Ontario)?
Jim:
Is there a way for those of us who haven't yet signed up with GitHub to view our statistics and regional maps (as they now stand)?
I'm between road trips, and will sign up and get familiar with GitHub once my life calms down a little. But a central place for me to view my data would help me comment on the progress made to date.
Looks great, Jim! Thanks!
Is there any way to see a larger region (such as the USA) on a single map?
Also, would you be willing to make the "show markers" stay off if a user unchecks the box?
Edit: the stats are significantly different from CHM. Total mileage for Ohio, for example, comes to 21,000 miles, whereas it was 19,000 miles on CHM. Looking at a few other states, I'm seeing the same (Travel Mapping stats are always higher). Are concurrencies being double-counted now?
I'm sure he's starting small and working his way out.
Quote from: rickmastfan67 on June 21, 2015, 12:24:32 PM
So, I thought I would bring this up early in the process, but how are we going to deal with routes that have 'special' shields compared to what the other 'normal' shields are in the state/province/country?
Like the special 'toll' shields in Florida. Are we just going to use the same shield for all, or will we code exceptions to the rule (like the QEW and 407 in Ontario)?
A big issue in the British Isles, where all A roads are given primary 'shields' despite most being non-primary (black on white, rather than yellow on green). There's also stuff like the named freeway systems where there's a variety of different ones.
Quote from: mapcat on June 21, 2015, 01:02:50 PMEdit: the stats are significantly different from CHM. Total mileage for Ohio, for example, comes to 21,000 miles, whereas it was 19,000 miles on CHM. Looking at a few other states, I'm seeing the same (Travel Mapping stats are always higher). Are concurrencies being double-counted now?
Now they are, but they won't be. That hasn't been sorted yet if you read above.
Quote from: oscar on June 21, 2015, 12:25:36 PMIs there a way for those of us who haven't yet signed up with GitHub to view our statistics and regional maps (as they now stand)?
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=AK&u=oscar_voss <-just change the region code to the one you want.
Quote from: oscar on June 21, 2015, 12:25:36 PM
Jim:
Is there a way for those of us who haven't yet signed up with GitHub to view our statistics and regional maps (as they now stand)?
I'm between road trips, and will sign up and get familiar with GitHub once my life calms down a little. But a central place for me to view my data would help me comment on the progress made to date.
For now, you (or anyone) can send me your .list updates and they'll become part of the system. No list files in GitHub yet, and I am sure we would not require the average end user to be interacting with GitHub to update. I envision an upload form and project maintainers would take those updates and put them into some official place. But that's a ways off.
Quote from: mapcat on June 21, 2015, 01:02:50 PM
Is there any way to see a larger region (such as the USA) on a single map?
Not yet.
QuoteAlso, would you be willing to make the "show markers" stay off if a user unchecks the box?
As of now, there's no persistent state (DB modifications, cookies, etc), but I think the better short term solution is to make the default that the markers are not shown, as I expect most people find that view more useful.
Quote
Edit: the stats are significantly different from CHM. Total mileage for Ohio, for example, comes to 21,000 miles, whereas it was 19,000 miles on CHM. Looking at a few other states, I'm seeing the same (Travel Mapping stats are always higher). Are concurrencies being double-counted now?
No effort was made yet to avoid double-counting. Those stats are just the total of the segments clinched and the total segments. I haven't decided how much of the stats should be generated at site update time and stored in the DB and what should be computed on the fly when maps (and some day, other pages with stats) are viewed. I'm leaning toward the former, as all concurrencies are represented conveniently in the data structures at that time, and it's a whole lot easier to code things up in Python from existing data structures than it is in JavaScript, obtaining information from DB queries.
Quote from: Jim on June 21, 2015, 02:39:06 PM
Quote from: oscar on June 21, 2015, 12:25:36 PM
Jim:
Is there a way for those of us who haven't yet signed up with GitHub to view our statistics and regional maps (as they now stand)?
I'm between road trips, and will sign up and get familiar with GitHub once my life calms down a little. But a central place for me to view my data would help me comment on the progress made to date.
For now, you (or anyone) can send me your .list updates and they'll become part of the system. No list files in GitHub yet, and I am sure we would not require the average end user to be interacting with GitHub to update. I envision an upload form and project maintainers would take those updates and put them into some official place. But that's a ways off.
I wasn't asking about updating list files (which is by e-mail for now), but rather about viewing the resulting statistics and regional maps.
Quote from: oscar on June 21, 2015, 03:33:00 PMI wasn't asking about updating list files (which is by e-mail for now), but rather about viewing the resulting statistics and regional maps.
Quote from: english si on June 21, 2015, 02:36:34 PMQuote from: oscar on June 21, 2015, 12:25:36 PMIs there a way for those of us who haven't yet signed up with GitHub to view our statistics and regional maps (as they now stand)?
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=AK&u=oscar_voss <-just change the region code to the one you want.
Quote from: english si on June 21, 2015, 03:41:59 PM
Quote from: oscar on June 21, 2015, 03:33:00 PMI wasn't asking about updating list files (which is by e-mail for now), but rather about viewing the resulting statistics and regional maps.
Quote from: english si on June 21, 2015, 02:36:34 PMQuote from: oscar on June 21, 2015, 12:25:36 PMIs there a way for those of us who haven't yet signed up with GitHub to view our statistics and regional maps (as they now stand)?
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=AK&u=oscar_voss <-just change the region code to the one you want.
Thanks -- that takes care of the regional maps. Still leaves open the statistics Jim recently added.
Quote from: oscar on June 21, 2015, 03:46:50 PM
Thanks -- that takes care of the regional maps. Still leaves open the statistics Jim recently added.
The very limited stats so far are just displayed across the top of the regional map.
Any really meaningful stats are not yet computed, stored, or displayed.
Quote from: oscar on June 21, 2015, 03:46:50 PMThanks -- that takes care of the regional maps. Still leaves open the statistics Jim recently added.
It's at the top. It's very limited. eg, "4807.82 of 15359.05 miles (31.3%) clinched by oscar_voss." is what you have of IL.
And Jim beats me just to it...
Quote from: Jim on June 21, 2015, 02:39:06 PM
For now, you (or anyone) can send me your .list updates and they'll become part of the system. No list files in GitHub yet, and I am sure we would not require the average end user to be interacting with GitHub to update. I envision an upload form and project maintainers would take those updates and put them into some official place. But that's a ways off.
What I'm thinking of doing here is having three types of data sources. You can upload a .list file (directly to the website and not through email), OR you can have your .list file stored on the server and edit it through some web interface, OR you can provide a link to a GitHub repo so whenever it does an update it checks out the latest version.
Quote from: sammi on June 21, 2015, 05:04:14 PM
Quote from: Jim on June 21, 2015, 02:39:06 PM
For now, you (or anyone) can send me your .list updates and they'll become part of the system. No list files in GitHub yet, and I am sure we would not require the average end user to be interacting with GitHub to update. I envision an upload form and project maintainers would take those updates and put them into some official place. But that's a ways off.
What I'm thinking of doing here is having three types of data sources. You can upload a .list file (directly to the website and not through email), OR you can have your .list file stored on the server and edit it through some web interface, OR you can provide a link to a GitHub repo so whenever it does an update it checks out the latest version.
ISTM that the first and third options would require some form of virus/malware checking. I don't know if that can be done without human intervention. Submitting by e-mail might make the checking easier.
Ultimately, if and when we develop a web interface, that might become the primary (and my preferred) method of doing updates, with basic password protection to prevent kids from screwing around with our data, but no need for virus/malware checking. List files would then be used mainly for (a) initial data entry by users transitioning from CHM, and (b) assembling and spitting out modified list files reflecting changes made through the web interface, as a backup in case of a Travel Mapping system meltdown, or for users to consult offline to plan their travels (something I do quite a bit with my CHM list file, at times and places where I can't go online).
I don't see an issue with uploading .list files; anti-virus software could easily be installed on the server, we could make sure that ONLY .list files can be uploaded, make sure that uploaded files don't have execute permissions, etc. They'll only be used by the .list processing program, so making sure that program has good error handling capabilities (which is what most malware exploits) is the best protection, no matter what method of submission is used.
I have no concern (maybe I should?) about viruses with .list file uploads, but more with denial of service attacks or something as simple as people overwriting each others' files. It was my understanding that the main reason CHM didn't allow uploads was because it allowed the site not to need any user accounts. Anyone can look at anyone's maps and stats, and with a human processing the .list updates from an email and putting them in place, anything that came from the wrong place would just be ignored.
I think sammi's ideas sound good, though I'd have the same concerns Tim had from the original project about maintaining user accounts. I hadn't considered the possibility of having files from individuals' private GitHub repositories could be fetched automatically as part of a site update.
Fortunately, that can be treated as a separate issue.
I've separated out the "highway browser" functionality from the regional map viewer, reorganized some code, made better use of the screen real estate, and added multi-region support.
For example:
http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MA,NH,VT,ME,CT,RI&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MA,NH,VT,ME,CT,RI&u=terescoj)
will show all of my travels in the six regions of New England. Note in particular the new "mapview.php" part of the URL.
You can list as many regions as you wish, comma separated, in the rg= query string parameter. If you leave it out completely, it will attempt to show your global travels. I think it works, but the browsers I've tried weren't happy with a JS program that attempts to add several hundred thousand Polylines to a Google Map. You're welcome to try, but don't say I didn't warn you when your browser crashes.
The code reorganization should allow me to add support soon for things like showing an individual system (like usai, for example), optionally restricted to a subset of regions. Maybe tomorrow night, but it's looking like a busy week coming up.
Quote from: Jim on June 21, 2015, 11:33:15 PM
I think it works, but the browsers I've tried weren't happy with a JS program that attempts to add several hundred thousand Polylines to a Google Map. You're welcome to try, but don't say I didn't warn you when your browser crashes.
After several fails in Chrome, I got it to work on Firefox. Loading took several minutes and several clicks on "continue", and zooming in/out on the complete map still takes a while. But the result is awesome!
Quote from: Jim on June 21, 2015, 02:39:06 PM
For now, you (or anyone) can send me your .list updates and they'll become part of the system. No list files in GitHub yet, and I am sure we would not require the average end user to be interacting with GitHub to update. I envision an upload form and project maintainers would take those updates and put them into some official place. But that's a ways off.
I don't think there's an official thread for this (saw a bunch of these posts in another one), but please include my file! (http://cmap.m-plex.com/list/yakra.list)
Quote from: mapcat on June 22, 2015, 12:07:02 AM
Quote from: Jim on June 21, 2015, 11:33:15 PM
I think it works, but the browsers I've tried weren't happy with a JS program that attempts to add several hundred thousand Polylines to a Google Map. You're welcome to try, but don't say I didn't warn you when your browser crashes.
After several fails in Chrome, I got it to work on Firefox. Loading took several minutes and several clicks on "continue", and zooming in/out on the complete map still takes a while. But the result is awesome!
My browser won't crash! This is
Linux! :bigass:
I only have 3 GB of RAM though. I'd try it, but after closing all other programs and prolly a reboot for good measure.
mapcat: Kudos, good sir!
When loading in states/provinces to the RG= argument one at a time, is the request being refreshed each time the URL is entered, eg, I load up Oregon, then I add Washington, then California, and so on?
I wonder if using that approach would keep browsers from choking when users want to display continental or world wide travels, by only polling each new region instead of reloading what has already been added to the map because those states/provinces were already in cache. I doubt I'm articulating this as well as I should be.
Quote from: Bickendan on June 22, 2015, 11:36:06 AM
When loading in states/provinces to the RG= argument one at a time, is the request being refreshed each time the URL is entered, eg, I load up Oregon, then I add Washington, then California, and so on?
I wonder if using that approach would keep browsers from choking when users want to display continental or world wide travels, by only polling each new region instead of reloading what has already been added to the map because those states/provinces were already in cache. I doubt I'm articulating this as well as I should be.
There's no persistent state, and the way I've coded things so far, there's not a good way to augment what's displayed without recreating everything anyway. Whether it's good or not, I make no claims, but I rely on the order in which information comes out of the DB, and things would be intermingled differently each time a different subset of regions is loaded.
All that said, the bottleneck is not in querying the DB or generating the JS code, it's in getting all that data onto the map. So maybe it's worth (some day by someone) coding things up so markers and waypoints are added/deleted from the maps as things change. Not a priority for me right now, though.
You can now add a sys= query string parameter to the mapview.php page and restrict by system instead of region. This one will show my travels on the US Interstate system, including future and bannered (business loop/spur) routes:
http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?sys=usai,usaif,usaib&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?sys=usai,usaif,usaib&u=terescoj)
rg= continues to function as before, but it doesn't yet work to specify both rg= and sys= together, so just provide one or the other for now.
Also, anyone who sent me a .list should now be able to see their maps.
Note that the stat summary at the top still does not account for concurrencies properly, so don't use the numbers there on your tax returns or anything.
One more for tonight: routes in the mapview.php pages are now color-coded by system. A few of the colors could probably use some improvement, but it's another step, anyway. Enjoy.
Quote from: Jim on June 22, 2015, 09:22:20 PM
One more for tonight: routes in the mapview.php pages are now color-coded by system. A few of the colors could probably use some improvement, but it's another step, anyway. Enjoy.
The color-coding does improve contrast, and is nice.
But the underlying Google Maps image still creates clutter, that detracts from a view of traveled routes. Ultimately, for the maps shown in user stats pages for regions/subregions/localities, can we get something like the old CHM map display, that displays
only traveled routes (with route numbers added), untraveled routes (heavily faded, but also with route numbers), borders, and coastlines, against a white/pale pastel background? Of course, Google Maps is for now taking care of the borders and coastlines, so we'd need to render those in some other fashion (as CHM did, though rather roughly for most of the coastlines) if we don't have a map as the background.
Quote from: Jim on June 22, 2015, 09:22:20 PM
One more for tonight: routes in the mapview.php pages are now color-coded by system. A few of the colors could probably use some improvement, but it's another step, anyway. Enjoy.
Oddly enough, I was just about to suggest that.
It would seem that the big hole at this point with the new HB is the lack of an index page.
Quote from: vdeane on June 22, 2015, 09:47:08 PM
Quote from: Jim on June 22, 2015, 09:22:20 PM
One more for tonight: routes in the mapview.php pages are now color-coded by system. A few of the colors could probably use some improvement, but it's another step, anyway. Enjoy.
Oddly enough, I was just about to suggest that.
It would seem that the big hole at this point with the new HB is the lack of an index page.
For software in development, I'm sure it's on his To-Do list. Its something that the front-end designer can do as well.
Quote from: SSOWorld on June 22, 2015, 09:52:50 PM
Quote from: vdeane on June 22, 2015, 09:47:08 PM
It would seem that the big hole at this point with the new HB is the lack of an index page.
For software in development, I'm sure it's on his To-Do list. Its something that the front-end designer can do as well.
Yes, I'm hoping someone else will help out with those kinds of things. I am aiming to get a bunch of low-level building blocks in place that we (as a group) can put into a nice site.
Quote from: oscar on June 22, 2015, 09:43:20 PM
Quote from: Jim on June 22, 2015, 09:22:20 PM
One more for tonight: routes in the mapview.php pages are now color-coded by system. A few of the colors could probably use some improvement, but it's another step, anyway. Enjoy.
The color-coding does improve contrast, and is nice.
But the underlying Google Maps image still creates clutter, that detracts from a view of traveled routes. Ultimately, for the maps shown in user stats pages for regions/subregions/localities, can we get something like the old CHM map display, that displays only traveled routes (with route numbers added), untraveled routes (heavily faded, but also with route numbers), borders, and coastlines, against a white/pale pastel background? Of course, Google Maps is for now taking care of the borders and coastlines, so we'd need to render those in some other fashion (as CHM did, though rather roughly for most of the coastlines) if we don't have a map as the background.
Yes, I hope and intend that we'll have those at some point. For my own priorities, I'm thinking of getting the mechanism by which stats can be generated down soon. Anyone who'd like to try to get the non-Google maps sooner than it comes to the top of my list, the PHP code should be similar, but instead of adding things to a Google Map, they'd be drawn on the static map. We have C++ code from yakra that shows how to manage those maps in GitHub, as is all of my code to date.
EDIT: The boundaries and coastlines *are* in GitHub, *but not* my version of the DB. That will need to happen before those maps can be generated in a nice way.
The .list files I've been working with are now in a new GitHub repository TravelMapping/UserData . I'd like a few of you who have some experience with GitHub or are willing to learn to clone the repository, update or add a (i.e., your own) .list file, commit and push it back. I think this would create a pull request for me, as sole owner (for now) of the GitHub master of that repository, which I could then act on to get your update in, which I could then pull down to my own local clone used for site updates. It's totally possible I have the workflow wrong here or that it's not a good way to do it, but I'd like to figure out a way that one or more others could take over accepting and putting .list files into the repository.
Quote from: Jim on June 22, 2015, 10:20:00 PM
The .list files I've been working with are now in a new GitHub repository TravelMapping/UserData . I'd like a few of you who have some experience with GitHub or are willing to learn to clone the repository, update or add a (i.e., your own) .list file, commit and push it back. I think this would create a pull request for me, as sole owner (for now) of the GitHub master of that repository, which I could then act on to get your update in, which I could then pull down to my own local clone used for site updates. It's totally possible I have the workflow wrong here or that it's not a good way to do it, but I'd like to figure out a way that one or more others could take over accepting and putting .list files into the repository.
I tried to do that a little while ago and I'm getting this error. Of course, I'm pretty rusty with git, so it's possible I'm doing something wrong.
vdeane@QueenElsa ~/TravelMapping/UserData/list_files $ git push -u origin masterUsername for 'https://github.com': vdeane
Password for 'https://vdeane@github.com':
remote: Permission to TravelMapping/UserData.git denied to vdeane.
fatal: unable to access 'https://github.com/TravelMapping/UserData/': The requested URL returned error: 403
Quote from: vdeane on June 23, 2015, 08:59:28 PM
Quote from: Jim on June 22, 2015, 10:20:00 PM
The .list files I've been working with are now in a new GitHub repository TravelMapping/UserData . I'd like a few of you who have some experience with GitHub or are willing to learn to clone the repository, update or add a (i.e., your own) .list file, commit and push it back. I think this would create a pull request for me, as sole owner (for now) of the GitHub master of that repository, which I could then act on to get your update in, which I could then pull down to my own local clone used for site updates. It's totally possible I have the workflow wrong here or that it's not a good way to do it, but I'd like to figure out a way that one or more others could take over accepting and putting .list files into the repository.
I tried to do that a little while ago and I'm getting this error. Of course, I'm pretty rusty with git, so it's possible I'm doing something wrong.
vdeane@QueenElsa ~/TravelMapping/UserData/list_files $ git push -u origin masterUsername for 'https://github.com': vdeane
Password for 'https://vdeane@github.com':
remote: Permission to TravelMapping/UserData.git denied to vdeane.
fatal: unable to access 'https://github.com/TravelMapping/UserData/': The requested URL returned error: 403
You don't have push rights to the main repo. Fork it to, say, vdeane/UserData, then push to that repo instead, then make a pull request when you want it merged into the main repo. I did the same thing to sammdot/TravelMapping-Web and sammdot/TravelMapping-HighwayData.
Also, nice hostname. :)
Having to create separate repositories for every single person who wants to do something sounds like a very cumbersome way to handle things. When I worked in the computer field, the company I was at actually had everyone create separate branches for each change (though I didn't do that here because we don't have a convention nailed down on how to handle multiple users).
Quote from: vdeane on June 24, 2015, 09:09:10 PM
Having to create separate repositories for every single person who wants to do something sounds like a very cumbersome way to handle things. When I worked in the computer field, the company I was at actually had everyone create separate branches for each change (though I didn't do that here because we don't have a convention nailed down on how to handle multiple users).
We definitely wouldn't do that. I'll have more to say soon, as I've been experimenting with this. For now, I'll say that I think we might want to set things up so we could allow people to email/upload/etc somewhere with no knowledge of GitHub, allow the more advanced user to manage his/her own list updates by maintaining their own fork and creating pull requests when they want a new list file imported (it's very possible this is more trouble than it's worth). The main team of people responsible for user data maintenance would have course have the ability to push right to the master for themselves and your typical user who submitted new or updated list files outside of GitHub.
So anyway, here's what I'd like a few people with GitHub experience to try out:
Fork the TravelMapping/UserData repository into your account. Make a change to your .list (I just added a comment at the top when I did mine). Commit it to your fork. Create a pull request to send it back to the master. You can do all of this through the web interface if you'd like or use the other tools.
My experiment with this was based on my reading of https://help.github.com/articles/using-pull-requests/ (https://help.github.com/articles/using-pull-requests/).
Again, I don't envision this as the mechanism we'd require all users to employ, but I'd like to see if it's a reasonable option for those who'd like to do it.
Quote from: Jim on June 24, 2015, 10:05:22 PM
So anyway, here's what I'd like a few people with GitHub experience to try out:
Fork the TravelMapping/UserData repository into your account. Make a change to your .list (I just added a comment at the top when I did mine). Commit it to your fork. Create a pull request to send it back to the master. You can do all of this through the web interface if you'd like or use the other tools.
My experiment with this was based on my reading of https://help.github.com/articles/using-pull-requests/ (https://help.github.com/articles/using-pull-requests/).
Again, I don't envision this as the mechanism we'd require all users to employ, but I'd like to see if it's a reasonable option for those who'd like to do it.
Ok, I put a pull request in. It was a little crazy trying to do it so don't get confused by the forking. (Forking git - git it? :awesomeface: )
Quote from: SSOWorld on June 24, 2015, 11:06:21 PM
Ok, I put a pull request in. It was a little crazy trying to do it so don't get confused by the forking. (Forking git - git it? :awesomeface: )
Thanks. I believe I've pulled your changes in, and next time I update the DB this list file's contents should be reflected. It's definitely not an intuitive process, and probably not the way most people will choose to update their lists... But, it is doable!
you did, but I had a stray "A" in one of the lines - made the change
I *think* I finally successfully submitted a pull request for a file named mapcatOLD.list using the web interface.
Quote from: Jim on June 22, 2015, 09:22:20 PM
One more for tonight: routes in the mapview.php pages are now color-coded by system. A few of the colors could probably use some improvement, but it's another step, anyway. Enjoy.
Is this different than the maps in the /hbtest/ directory? I'm still only seeing red lines.
Are the maps going to be overlaid on Google when the user checks each page, or will the maps be featureless except for shapelines (as it is on the CHM site)?
Quote from: Jeff Morrison on June 25, 2015, 02:32:16 AM
Is this different than the maps in the /hbtest/ directory? I'm still only seeing red lines.
Both the single-route browser and the map overlay viewer (for lack of a better name) are in the the hbtest directory.
A sample browser URL, showing a single route, u= is optional:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny119&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny119&u=terescoj)
A sample map overlay URL, multiple routes by system(s) with sys= or region(s) with rg=, u= should be specified:
http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=NY&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=NY&u=terescoj)
QuoteAre the maps going to be overlaid on Google when the user checks each page, or will the maps be featureless except for shapelines (as it is on the CHM site)?
I hope we'll eventually support both. I can't promise I'll implement the CHM-style maps soon. I intend to do it, but won't be upset at all if someone beats me to it. There's a lot with error detection and stats generation that I am treating with higher priority.
I'd love to be able to view my LIST file as well. I hadn't even heard of GitHub until this thread, sorry. Thanks for the help - so glad to see that people who know what they're doing are taking up the charge for this (as opposed to people like me who don't know enough to contribute anything)!
http://cmap.m-plex.com/list/tag42481.list
It's possible that I used the one-eyed babysitter to give me the space to figure out how to push my updates to the repository. (And yeah, I feel dumb. It's as browser driven as I could want. School won't start soon enough.)
Quote from: TAG42481 on June 26, 2015, 01:28:54 PM
I'd love to be able to view my LIST file as well. I hadn't even heard of GitHub until this thread, sorry. Thanks for the help - so glad to see that people who know what they're doing are taking up the charge for this (as opposed to people like me who don't know enough to contribute anything)!
http://cmap.m-plex.com/list/tag42481.list
Not a problem - I'm sure we will never require anyone to deal with GitHub to be able to use the new site. I've added yours to my collection and you should be able to see your maps within a few hours, or as soon as I have a chance to run another site update.
Quote from: sipes23 on June 26, 2015, 01:53:08 PM
It's possible that I used the one-eyed babysitter to give me the space to figure out how to push my updates to the repository. (And yeah, I feel dumb. It's as browser driven as I could want. School won't start soon enough.)
It worked.
I love being able to zoom in on the maps. Already I've found a few mistakes I've made (false positives). One instance where I selected the wrong waypoint showed up on GA I-20 (I input 113 instead of 114). I go onto the freeway from US129/US441 and without being able to zoom in on the map, I would never have noticed my error, as 113 is a valid waypoint (just not the correct one). Zoom into this image where US129/441 & I-20 meet to see what I mean
http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=GA&u=bejacob (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=GA&u=bejacob). I'm not sure I would have discovered it without the underlying map and the ability to zoom. I'm still finding mistakes, and with new travel coming up this weekend, I hope to fix my .list file soon, maybe by July 4th.
In any case, what I'm seeing so far is amazing.
What I (as a non-technical user) will be looking for as things move forward are the summary stats like these http://cmap.m-plex.com/stat/travsummary.php?u=bejacob (http://cmap.m-plex.com/stat/travsummary.php?u=bejacob). At this point I'm less concerned with the accuracy of the mileage than I am with the number of highways traveled/clinched. Those of you who have been a part of CHM much longer doubtless would like to see some of this as well. I'm sure you all have your own wishlist :)
I have no idea what level of effort it will take to generate this, but based on what has happened already, it looks to just be a matter of time. As an avid travel/county collector who came late to the CHM party, I can't thank all of you enough for what you are doing. I spent countless hours putting together my .list file and did manage to get it uploaded in November, but never go to make corrections or add new routes before the site when dormant.
Keep up the great work. As more is developed, let me know through this forum. I will be happy to provide feedback and comments with somewhat of an outsider perspective.
Thanks again,
Brian
Quote from: bejacob on June 26, 2015, 10:17:57 PMWhat I (as a non-technical user) will be looking for as things move forward are the summary stats like these http://cmap.m-plex.com/stat/travsummary.php?u=bejacob (http://cmap.m-plex.com/stat/travsummary.php?u=bejacob).
Me too! It's what I'm working on next. The main complication is accounting correctly for concurrencies so segments aren't counted multiple times in summary. For example, take a segment that carries two interstate routes, a US route, and a state route. It should count just once in overall and regional stats, once each for system stats for I-, US, and the state's system, and once in each route's stats. There's also the issue that connected routes have not yet been included, which will be necessary for computing things like how much of I-90, across all states, has someone traveled.
Quote from: Jim on June 13, 2015, 10:37:20 PM
- I'm happy to bring in .list files of others who might want to be able to browse their travels this way and the next time I run a DB update, they'll be there.
Hi Jim,
(Quoting Arnold Horshack) Ooooh! Ooooh! Can I volunteer? :-)
Just came home for a weekend, updated my travels file, then started reading the forum to try to catch up on the progress you guys are all making. Happy to see progress, and am excitied to see a return of a functioning map site. Let me know if I can send you my file, Jim.
Many thanks,
-Ed S
Quote from: Jim on June 27, 2015, 09:15:46 AM
The main complication is accounting correctly for concurrencies so segments aren't counted multiple times in summary. For example, take a segment that carries two interstate routes, a US route, and a state route. It should count just once in overall and regional stats, once each for system stats for I-, US, and the state's system, and once in each route's stats.
I believe I have code in place that accounts for these situations, and I've generated regional and system mileage summaries that appear to match CHM's numbers. For now, they're just printed in an ugly log file. Before I go further, I'd appreciate some spot checking of these stats:
http://www.teresco.org/~terescoj/travelmapping/logs/clinchableroutes.log (http://www.teresco.org/~terescoj/travelmapping/logs/clinchableroutes.log)
If this looks accurate, I'll apply the same procedures to generate per-user stats, also in ugly log files to start. If that goes well, all of this information will go into the DB so those writing front-end stuff can include them in web pages.
Edit: More likely, I'll read in the as-yet-ignored-by-me _con.csv files to generate per-route lengths first, so for example we could see I-90's length as a single route across several states. Then on to per-user stats, then on to getting all of it into the DB.
Quote from: Jim on June 29, 2015, 11:49:29 PM
Quote from: Jim on June 27, 2015, 09:15:46 AM
The main complication is accounting correctly for concurrencies so segments aren't counted multiple times in summary. For example, take a segment that carries two interstate routes, a US route, and a state route. It should count just once in overall and regional stats, once each for system stats for I-, US, and the state's system, and once in each route's stats.
I believe I have code in place that accounts for these situations, and I've generated regional and system mileage summaries that appear to match CHM's numbers. For now, they're just printed in an ugly log file. Before I go further, I'd appreciate some spot checking of these stats:
http://www.teresco.org/~terescoj/travelmapping/logs/clinchableroutes.log (http://www.teresco.org/~terescoj/travelmapping/logs/clinchableroutes.log)
If this looks accurate, I'll apply the same procedures to generate per-user stats, also in ugly log files to start. If that goes well, all of this information will go into the DB so those writing front-end stuff can include them in web pages.
Edit: More likely, I'll read in the as-yet-ignored-by-me _con.csv files to generate per-route lengths first, so for example we could see I-90's length as a single route across several states. Then on to per-user stats, then on to getting all of it into the DB.
Looks like this is working. I spot checked the mileage of US highways per state and each individual Ohio state route and got very accurate results for both sets.
I took CHM data from the tables, which round the mileage to tenths, and your data rounds to hundredths, so rounding was responsible for most of the difference, which came to a maximum 0.05 mi per Ohio route. For the total mileage of US highways, some states were off by a little more, which I assume is the result of adding multiple routes that are off by a few hundredths. Texas, for example, has a total of 12,784.39 miles of US highways in your data and 12,784.1 in CHM, for a difference of 0.29 miles. This is still 99.9977% accurate. North Carolina was next furthest off (0.18 mi, 99.9965%), and only 9 other states were off by more than 0.1 mi. Given that there are so many different US highways in those states, the numbers certainly seem acceptable!
I would definitely say that is acceptable error. Seems like the computations are working properly.
I noticed that I-5 in all three states is reporting high mileage -- should be ~798 for California, 308.5 for Oregon, and 277 for Washington, allowing for the extra distance between the final exit and the next state's border (796, 308, 276). CHM stats show 806, 312, 279.
Quote from: Bickendan on June 30, 2015, 07:17:51 PM
I noticed that I-5 in all three states is reporting high mileage -- should be ~798 for California, 308.5 for Oregon, and 277 for Washington, allowing for the extra distance between the final exit and the next state's border (796, 308, 276). CHM stats show 806, 312, 279.
He's checking whether or not the mileages he's calculated match what CHM used (and these do match). Fixes to the data are coming later. As for the discrepancy, maybe this is where the 2% fudge factor comes in.
Quote from: mapcat on June 30, 2015, 08:49:05 PM
Quote from: Bickendan on June 30, 2015, 07:17:51 PM
I noticed that I-5 in all three states is reporting high mileage -- should be ~798 for California, 308.5 for Oregon, and 277 for Washington, allowing for the extra distance between the final exit and the next state's border (796, 308, 276). CHM stats show 806, 312, 279.
He's checking whether or not the mileages he's calculated match what CHM used (and these do match). Fixes to the data are coming later. As for the discrepancy, maybe this is where the 2% fudge factor comes in.
Exactly - if we're matching CHM that's good for now.
There will be a handful of things that don't match. For example, I had to remove NM 599 from the usansf system since it's also in usanm, which I hope will be activated fairly soon after we are ready to make data changes.
Quote from: Jim on June 30, 2015, 09:54:44 PM
There will be a handful of things that don't match. For example, I had to remove NM 599 from the usansf system since it's also in usanm, which I hope will be activated fairly soon after we are ready to make data changes.
As far as you can tell, which of the in-development systems from CHM are ready to be activated, once it's established that Travel Mapping is working as intended?
Quote from: mapcat on June 30, 2015, 11:41:36 PM
Quote from: Jim on June 30, 2015, 09:54:44 PM
There will be a handful of things that don't match. For example, I had to remove NM 599 from the usansf system since it's also in usanm, which I hope will be activated fairly soon after we are ready to make data changes.
As far as you can tell, which of the in-development systems from CHM are ready to be activated, once it's established that Travel Mapping is working as intended?
I'd say New Mexico, Utah, and Vermont state systems look to be closest, at least in the U.S.
Connected routes are now implemented in python and log files, but not yet in the DB. For tonight, this means you can now check out roads that are continuous across regions to get total mileages in the
http://www.teresco.org/~terescoj/travelmapping/logs/clinchableroutes.log (http://www.teresco.org/~terescoj/travelmapping/logs/clinchableroutes.log)
file. Next up, per-user stats in python and log files, then all of the stats into the DB so they can be accessed by web-facing parts of the new system.
Also, there's a DB update running now, likely done by the time almost everyone reads this, that will include all new and updated .list files I've received.
As part of this, I have temporarily commented out 7 in-development systems that had missing connected route files. For now, you won't see cannf, cansph, usaca, usafl, usaky4, usala1, and usasc in the new HB. Once we end the data "freeze", those should be able to be created quickly and get them back into the DB, and hence the new HB.
Here's a rundown of the remaining states without active SR systems, as far as I'm aware of things. Anyone who knows anything I don't, feel free to chime in.
AL: not officially in development. No significant obstacles to implementation.
AK: officially in development. No significant obstacles to implementation. State of completeness = ?
AR: not officially in development. Obstacle: many discontinuous routes in several segments.
CA: officially in development. No significant obstacles to implementation. Largely done but needs some reworking.
CO: not officially in development. No significant obstacles to implementation.
FL: officially in development. Obstacle: some routes have signed and unsigned portions. State of completeness = ?
GA: not officially in development. No significant obstacles to implementation.
IN: not officially in development. No significant obstacles to implementation.
LA: officially in development for low numbered routes only. Obstacle: lots of minor high numbered routes. State of completeness = ?
MS: not officially in development. No significant obstacles to implementation.
MT: officially in development. No significant obstacles to implementation for primary routes. State of completeness = ?
NM: officially in development. Almost ready to go.
SC: officially in development. No significant obstacles to implementation. State of completeness = ?
TN: not officially in development. Obstacle 1: some routes have signed and unsigned portions. Obstacle 2: secondary and primary systems not easily neatly separated, may have to be treated as all one system like Vermont.
TX: not officially in development, but rough draft of primary system has nonetheless been completed
UT: officially in development. Almost ready to go.
VA: not officially in development. No significant obstacles to implementation for primary routes.
VT: officially in development. Almost ready to go.
WY: not officially in development. No significant obstacles to implementation.
BC: not officially in development.
AB (Primary): officially in development. Call it 83% done.
AB (Secondary): not officially in development, but rough draft of AB500 - AB546 nonetheless completed.
SK (Primary & Secondary): not officially in development.
MB (Primary): not officially in development, but first rough draft has nonetheless been completed. Call it 50% done.
MB (Secondary): not officially in development.
ON (Secondary): not officially in development.
QC: not officially in development.
NL: not officially in development.
Quote from: Duke87 on July 01, 2015, 12:25:34 AM
Here's a rundown of the remaining states without active SR systems, as far as I'm aware of things. Anyone who knows anything I don't, feel free to chime in.
CO: not officially in development. No significant obstacles to implementation. Draft files made
IN: not officially in development. No significant obstacles to implementation. Draft files made
MT: officially in development. No significant obstacles to implementation for primary routes. State of completeness = awaiting peer review
MT (secondary): not officially in development. No significant obstacles to implementation. IIRC, draft files started
WY: not officially in development. No significant obstacles to implementation. Draft routes made
Other officially indev systems:
CAN "select named freeways" and "select provincial highways" - scrapping them
GBR "A roads (Zone 1)", "A roads (Zone 6)", "A roads (Zone 8)" and "A roads (Zone 9)" - almost ready to go.
And I'll leave my massive Europe phase 3 systems that are unofficially in dev for later. I'm trying to work out which order I'm going to release them, for a start!
I think the priorities go like this:
1) get Travel Mapping fully functional
2) get active systems up to date
3) get those systems listed above in darker green (and MT primary routes) active
Obviously there's overlaps on time lines, and general release won't happen until 1 and 2 have occurred. I'd say that NM, UT and probably VT have very good odds of being activated before that happens. GB A roads a reasonable chance too.
Quote from: Duke87 on July 01, 2015, 12:25:34 AM
Here's a rundown of the remaining states without active SR systems, as far as I'm aware of things. Anyone who knows anything I don't, feel free to chime in.
AL: not officially in development. No significant obstacles to implementation.
AK: officially in development. No significant obstacles to implementation. State of completeness = ?
AR: not officially in development. Obstacle: many discontinuous routes in several segments.
CA: officially in development. No significant obstacles to implementation. Largely done but needs some reworking.
CO: not officially in development. No significant obstacles to implementation.
FL: officially in development. Obstacle: some routes have signed and unsigned portions. State of completeness = ?
GA: not officially in development. No significant obstacles to implementation.
IN: not officially in development. No significant obstacles to implementation.
LA: officially in development for low numbered routes only. Obstacle: lots of minor high numbered routes. State of completeness = ?
MS: not officially in development. No significant obstacles to implementation.
MT: officially in development. No significant obstacles to implementation for primary routes. State of completeness = ?
NM: officially in development. Almost ready to go.
SC: officially in development. No significant obstacles to implementation. State of completeness = ?
TN: not officially in development. Obstacle 1: some routes have signed and unsigned portions. Obstacle 2: secondary and primary systems not easily neatly separated, may have to be treated as all one system like Vermont.
TX: not officially in development, but rough draft of primary system has nonetheless been completed
UT: officially in development. Almost ready to go.
VA: not officially in development. No significant obstacles to implementation for primary routes.
VT: officially in development. Almost ready to go.
WY: not officially in development. No significant obstacles to implementation.
MT primary, NM, and UT have gone through peer review, which puts them closest to activation. I'm not sure where VT stands there -- lots of discussion about the system, but I think not the kind of close review of specific routes typical of the peer review process.
BTW, I think such peer review should be continued, especially without Tim providing a last review (or not, thus holding up the system) before activation.
As for AK, it needs a little more work to get it ready for peer review, as well as a team decision on what to do with two unsigned segments of otherwise signed routes.
For TN, an additional complication is number duplication between the primary and secondary routes, with at least one major route alternating between primary and secondary segments, but other numbers are assigned to completely unrelated primary and secondary routes.
Quote from: english si on July 01, 2015, 05:04:58 AM
Other officially indev systems:
CAN "select named freeways" and "select provincial highways" - scrapping them
I don't think the "select named freeways" should be really scrapped, unless we can find a way for the ones in Ontario to be activated somehow.
Quote from: Duke87 on July 01, 2015, 12:25:34 AM
Here's a rundown of the remaining states without active SR systems, as far as I'm aware of things. Anyone who knows anything I don't, feel free to chime in.
CA: officially in development. No significant obstacles to implementation. Largely done but needs some reworking.
What specifically are we looking at here?
CA 44? Oscar should have a copy that just needs to be modernized.
Pass through all the routes and chopping them up per the stupid discontinuities caused by signage being removed where routes have been turnbacked despite a mandate to maintain guide signage?
Clean up on interstate and US routes, trimming down denser than needed routes?
Exit number conversions on the US routes?
Quote from: rickmastfan67 on July 01, 2015, 10:25:42 AMI don't think the "select named freeways" should be really scrapped, unless we can find a way for the ones in Ontario to be activated somehow.
They already are, in the canonf system.
Quote from: english si on July 01, 2015, 11:14:41 AM
Quote from: rickmastfan67 on July 01, 2015, 10:25:42 AMI don't think the "select named freeways" should be really scrapped, unless we can find a way for the ones in Ontario to be activated somehow.
They already are, in the canonf system.
Only the Gardiner and Don Valley, and they aren't really provincial routes.
VT, Froggie peer reviewed for me.
MT, I peer reviewed for Si.
Quote from: oscar on July 01, 2015, 08:05:42 AMMT primary, NM, and UT have gone through peer review, which puts them closest to activation.
Quote from: yakra on July 01, 2015, 12:38:38 PMMT, I peer reviewed for Si.
I'd forgotten that.
Do we want someone that is neither the author or peer reviewer to check the system over and then activate them?
Quote from: yakra on July 01, 2015, 12:54:14 AM
SK (Primary & Secondary): not officially in development.
MB (Primary): not officially in development, but first rough draft has nonetheless been completed. Call it 50% done.
MB (Secondary): not officially in development.
Would anyone need help with SK and MB, cause I can at least help provide information as needed. A lot of this technical stuff is over me, but I'd happily contribute in any way.
Here is my updated list file (https://www.dropbox.com/s/d0iyu1h3utb3cxq/thefxexpert.list?dl=0) for whenever you are able to do another database update. Thanks to everyone for keeping this alive.
Quote from: Duke87 on July 01, 2015, 12:25:34 AM
Here's a rundown of the remaining states without active SR systems, as far as I'm aware of things. Anyone who knows anything I don't, feel free to chime in.
FL: officially in development. Obstacle: some routes have signed and unsigned portions. State of completeness = ?
From what I could tell from browsing the old CHM, every road higher than FL802 hasn't been added yet. FL451 hasn't been added yet; FL429 and FL414 need to be modified in that area. FL293 needs to be extended.
Quote from: theFXexpert on July 01, 2015, 09:19:13 PM
Here is my updated list file (https://www.dropbox.com/s/d0iyu1h3utb3cxq/thefxexpert.list?dl=0) for whenever you are able to do another database update. Thanks to everyone for keeping this alive.
Quote from: Duke87 on July 01, 2015, 12:25:34 AM
Here's a rundown of the remaining states without active SR systems, as far as I'm aware of things. Anyone who knows anything I don't, feel free to chime in.
FL: officially in development. Obstacle: some routes have signed and unsigned portions. State of completeness = ?
From what I could tell from browsing the old CHM, every road higher than FL802 hasn't been added yet. FL451 hasn't been added yet; FL429 and FL414 need to be modified in that area. FL293 needs to be extended.
Yes, I'm aware of these tweaks. Some of them have been done in my personal copies, others haven't yet. FL got side tracked when I had to go back and 'update' several US highways in other states that I maintain to the current standards. Still have to finish a few more TN US highways, and some other updates to active routes, and then I can get back to work on FL's state highways.
Quote from: Bickendan on July 01, 2015, 11:03:40 AM
What specifically are we looking at here?
CA 44? Oscar should have a copy that just needs to be modernized.
Pass through all the routes and chopping them up per the stupid discontinuities caused by signage being removed where routes have been turnbacked despite a mandate to maintain guide signage?
Clean up on interstate and US routes, trimming down denser than needed routes?
Exit number conversions on the US routes?
The first item remains open for discussion. My inclination would be to chop, but the initial reaction of others on the team is like yours, to leave the routes intact. I can go with that if it remains the consensus. It doesn't hurt that, last time I was out there, many of the relinquished segments still have their old signage, with only a few jurisdictions feeling obligated to erect new signage. I've done almost nothing on the route-chopping, so little lost if we decide to forget it.
Another item is what to do with several routes not yet broken up at ferry crossings. We all know what Tim would've said, but "WWTD?" is no longer determinative. Especially since AASHTO just approved US 10 including a long ferry route across Lake Michigan, we might want to rethink our approach to shorter ferry crossings.
There are other issues, including the others you flagged, we can address later once it comes time to do a new instruction manual (I've volunteered to do that), and otherwise get going on developing California and other new systems.
On behalf of those of us who aren't actively involved with this project, I'd like to throw out a few questions to every working on the new travel mapping site.
1. Is the intent to keep the current method of uploading .list files? Have other methods for updating been considered or is that being delayed pending full functionality?
2. When is it appropriate to begin adding routes in states/regions under development? (Based on recent posts, it appears this will be phased in over time).
3. What is the likelihood of current waypoints changing thus requiring revisions to existing .list files?
4. How will we be able to find the correct waypoints for new systems or if existing ones change? (currently, I'm still going to CHM to look at the highway browser).
5. What other pieces of the old CHM site will be incorporated? (I love Jim's new maps). I imagine the highway browser and traveler stats are high on the list of priorities. (Here is one part of CHM that I look at often and would like to see http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra (http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra)
6. Will concurrencies be automatically updated as they are on CHM now? (I think this is already happening on the maps, but I'm curious how it will show up on the stats--see link in the previous question).
7. Are there things that those of who are not programmers can do to help (other than send Jim .list files and cheer everyone on :clap:)?
I've been using the map Jim produces from my .list file to go back and find errors or missing routes (I'm almost embarrassed at how many I've discovered :-()
I know there are a great many steps still ahead on this project and I expect many of them will take some time to implement. Right now, I'm thrilled to be able to update my file and see the new maps (something I never got to experience on CHM as I uploaded my first file in November and then all went quiet).
Thanks to everyone involved in development. I don't have the knowledge or expertise to participate fully is all the discussion taking place on this forum, but I am following along in hopes of understanding bits and pieces. I'll chime in from time to time, but otherwise, I'll just keep reading and updating my file as necessary.
Thanks again
-Brian
Quote from: bejacob on July 01, 2015, 10:26:24 PM
1. Is the intent to keep the current method of uploading .list files? Have other methods for updating been considered or is that being delayed pending full functionality?
I think I'd rather see everything working first before people can start adding their .list files. I'm definitely looking at direct upload and GitHub as uploading options.
Quote from: bejacob on July 01, 2015, 10:26:24 PM
3. What is the likelihood of current waypoints changing thus requiring revisions to existing .list files?
4. How will we be able to find the correct waypoints for new systems or if existing ones change? (currently, I'm still going to CHM to look at the highway browser).
There's a
labels_in_use field in the code that updates the database. I'm guessing that's there so that we know not to change labels if they're in use? If that
does happen, I'd like to see a changelog for the data that shows which labels have changed.
First per-user stats are now being computed and placed in the same log files as .list errors. I still need to add per-route stats and store things in the DB for display on the web, but it's another nice thing to be able to check out and a big step forward in overall functionality.
All .list files received as of 11:30 PM EDT are also in the DB now, so a few new people can see maps and even a start on stats.
Enjoy!
Quote from: bejacob on July 01, 2015, 10:26:24 PM
On behalf of those of us who aren't actively involved with this project, I'd like to throw out a few questions to every working on the new travel mapping site.
1. Is the intent to keep the current method of uploading .list files? Have other methods for updating been considered or is that being delayed pending full functionality?
2. When is it appropriate to begin adding routes in states/regions under development? (Based on recent posts, it appears this will be phased in over time).
3. What is the likelihood of current waypoints changing thus requiring revisions to existing .list files?
4. How will we be able to find the correct waypoints for new systems or if existing ones change? (currently, I'm still going to CHM to look at the highway browser).
5. What other pieces of the old CHM site will be incorporated? (I love Jim's new maps). I imagine the highway browser and traveler stats are high on the list of priorities. (Here is one part of CHM that I look at often and would like to see http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra (http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra)
6. Will concurrencies be automatically updated as they are on CHM now? (I think this is already happening on the maps, but I'm curious how it will show up on the stats--see link in the previous question).
7. Are there things that those of who are not programmers can do to help (other than send Jim .list files and cheer everyone on :clap:)?
I'll take my stab at these and I'm sure others will as well.
1) I expect we'll have multiple convenient options to update .list files. At this point, I'm willing to accept anyone's .list files by email (PM for address) as I am interested in testing at scale now.
2) I think this was addressed in a few places, but I believe the plan is to make many needed fixes to existing systems, then add in the nearly-complete systems, then look to expand. Maintaining and improving quality should take precedence over expansion.
3-4) I expect we'll adopt the CHM model: try not to break .list files but when it's necessary, there will be a change log.
5) I expect we'll have all CHM functionality and more. HB exists, just needs to look pretty. Stats are almost in place, need to make them show up on end-user pages. My overlay maps are good to go (need to add stats) and others are working on the static maps like CHM had. I'm hoping to have a lot more (and more configurable) stats pages.
6) Concurrencies should all be accounted for correctly in maps and stats now.
7) Look for errors in the data, maps, stats, being produced so far.
Quote1. Is the intent to keep the current method of uploading .list files?
Yes. For now, at the very least...
QuoteHave other methods for updating been considered or is that being delayed pending full functionality?
Considered, yes. Though I don't think very seriously or very in-depth yet. Most of that discussion has been here on AARoads, from what I remember. In any case, that would be something to think about after we have a fully functional site down.
Quote2. When is it appropriate to begin adding routes in states/regions under development? (Based on recent posts, it appears this will be phased in over time).
Edit: I initially read this as "When is it appropriate to begin adding routes ...
to my .list file?", which may or may not have actually been your intent. I wrote my reply accordingly. So, uhh... yeah. Nota Bene.
Whenever you want, really. If the system's not active yet, you'll just get a line in your log file such as "Ignoring line matching highway in inactive system: MT MT2 I-15/90 EliWarAve". It's just that you run the risk of, say, having to re-enter lines if waypoint labels change while the system is still in development. No big woof though.
Quote3. What is the likelihood of current waypoints changing thus requiring revisions to existing .list files?
It does happen, from time to time. When labels change, we try to keep the old label, if it's in use, in the file as a deprecated label.
For example, ME ME123 ME24 needs to be relabeled as ME24Bus. When I make that change, ME24 will stay in the file as a deprecated label, so existing lists using that point will work and changes will not be necessary.
Other times, a waypoint label will move a bit. TX US80 TX34 became TX34Bus. TX34 couldn't stay in place as a deprecated label, as it was needed for the new TX34 two blocks away. So, anyone using the old TX34 point will still have that line of their list file processed OK, but it will point to the wrong point, the new TX34, and their stats/maps will be off by a tiny bit. A .list revision will be needed.
Sometimes, changes are needed that will break a .list file line, usually when a highway is relocated. For example, CT US7 CT25 is no longer a valid waypoint; anyone still using it will have an error in his .log file.
In these last 2 scenarios, these changes have traditionally bee listed on the Highway Data Updates (http://cmap.m-plex.com/docs/hwyupdates.php?y=2014) page. The new project will need some kind of equivalent to this, but I haven't seen any discussion about it yet. I guess it's another fairly simple thing to get going after we have an operational site.
Quote4. How will we be able to find the correct waypoints for new systems or if existing ones change? (currently, I'm still going to CHM to look at the highway browser).
The current thinking is to have the new site start out with the same data as on the existing site, so all waypoint labels should start out the same. We'll keep on with efforts to keep the breaking of .list files to a minimum, so waypoints shouldn't change unless necessary. For new systems, and changes to existing ones, I'd say, the new HB, once it's operational.
Quote5. What other pieces of the old CHM site will be incorporated? (I love Jim's new maps). I imagine the highway browser and traveler stats are high on the list of priorities. (Here is one part of CHM that I look at often and would like to see http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra
I can't imagine that not being high on the list.
Quote6. Will concurrencies be automatically updated as they are on CHM now? (I think this is already happening on the maps, but I'm curious how it will show up on the stats--see link in the previous question).
I believe the intent is to have concurrencies automatically updated.
Quote7. Are there things that those of who are not programmers can do to help (other than send Jim .list files and cheer everyone on :clap:)?
Cheering us on is great! :D I would say, look for & report errors in the highway data, but I'd be getting ahead of myself; that's best saved for once the dust settles down and everything is online.
QuoteEdit: I initially read this as "When is it appropriate to begin adding routes ... to my .list file?", which may or may not have actually been your intent. I wrote my reply accordingly. So, uhh... yeah. Nota Bene.
Whenever you want, really. If the system's not active yet, you'll just get a line in your log file such as "Ignoring line matching highway in inactive system: MT MT2 I-15/90 EliWarAve". It's just that you run the risk of, say, having to re-enter lines if waypoint labels change while the system is still in development. No big woof though.
That's exactly what I meant. Sorry about not being clear. I've got a separate working file with routes under development. I'll plan on adding them to my .list at some point, though I may wait until I'm sure I've corrected all the missing/incorrect routes in my current file.
Thank you for the response (and to all who replied).
More stats! Per-route clinching stats are now in log files. Please let me know if you notice problems. My spot checks matched CHM for my routes except in cases where my .list has been updated or the data changed (like the NM 599 example mentioned upthread). I'm unlikely to get the stats into the DB tonight but that's my next project, so we'll be able to see things on web pages. Please remember that the stats in the logs aren't pretty nor are they intended to be. It's just a convenient way to see them, and I'm tempted to leave them in there even when they're available through other means. Or maybe they could be in a separate log file or something like that.
Quote from: Jim on July 02, 2015, 09:15:34 PM
More stats! Per-route clinching stats are now in log files. Please let me know if you notice problems. My spot checks matched CHM for my routes except in cases where my .list has been updated or the data changed (like the NM 599 example mentioned upthread).
My log looked accurate based on spot checks. The mismatches I found were known mismatches due to updates and further travel.
QuoteMS: not officially in development. No significant obstacles to implementation.
Like Arkansas, there are several discontinuous segments. And we'd have to figure out how to handle the MS 7xx/8xx/9xx routes, most of which are unsigned.
Quote from: Jim on July 02, 2015, 09:15:34 PM
More stats! Per-route clinching stats are now in log files.
I like this addition. It's been a huge help discovering concurrencies I overlooked. I'm using these stats to add routes to my .list (for completeness sake). It's also interesting to see which routes are almost to 100% (i.e. ones I might want to clinch next time I'm in the area :)).
Since my CHM stats are way off, I haven't bothered comparing, though did a few spot check on routes that I know are correct in CHM. Everything looks good.
Quote from: bejacob on July 04, 2015, 10:42:29 AM
I like this addition. It's been a huge help discovering concurrencies I overlooked. I'm using these stats to add routes to my .list (for completeness sake).
If Travel Mapping is picking up, and automatically crediting you for, concurrent mileage, you don't need to add lines to your .list file just for the concurrences. Only if you also racked up non-concurrent mileage on a route is a new line necessary.
My own .list file is bloated out by the concurrence-only lines I added long ago when CHM did not at first automatically credit concurrences. I'm not adding any new ones, and if I'm cleaning up old entries for a state I'll try to remove the old concurrence-only lines.
While I'm on the road I've taken a brief glance at my log file to look for under- or over-mileage in the user stats, starting with the systems for which I'm expecting either 100% or 0% mileage in a (sub)region. So far, the only errors I've picked up are from errors in my own .list file, which I'll fix in a few weeks, and a coordinates mismatch in Quebec at the A-20/A-85 junction (which is also in CHM), which I'll fix when we start updating route files (A-85 needs a lot of other work too).
The user stats as they now stand give me one item of information I was particularly looking for, on my overall coverage of U.S. routes.
I believe CHM has a per-user concurrency detection report. I never found it especially helpful so I went with a general concurrency detection shown in the log file. If people think it would be useful, I should be able to transform that report from every concurrent segment (that is, every connection between two waypoints that's shared by at least 2 highways) to reporting entire subsets of the highways that are concurrent. I don't think it's that hard, just hasn't been a priority yet.
Quote from: Jim on July 04, 2015, 11:56:06 AM
I believe CHM has a per-user concurrency detection report. I never found it especially helpful so I went with a general concurrency detection shown in the log file. If people think it would be useful, I should be able to transform that report from every concurrent segment (that is, every connection between two waypoints that's shared by at least 2 highways) to reporting entire subsets of the highways that are concurrent. I don't think it's that hard, just hasn't been a priority yet.
I suggest waiting with that until later. We have a decent algorithm in place now, but it might benefit later (how is the question)
Quote from: Jim on July 02, 2015, 09:15:34 PM
Per-route clinching stats are now in log files. Please let me know if you notice problems.
One route that popped up on my log is SC31 near Myrtle Beach. I can't figure out how. I drove US501 from into town from Conway and picked up US17 heading south. Perhaps there is a concurrency I'm missing :confused:. Here's my SC map http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=SC&u=bejacob (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=SC&u=bejacob) in case someone wants to take a look and can explain how that extra teal colored line showed up near Myrtle Beach.
The rest of the state looks fine except for the gaps left where I drove on SC state highways not yet part of the database (which I'm perfectly fine with since I know the reason). I didn't notice this route (SC31) when I first glanced at my map, but found it while reviewing the per-route stats. (So Jim, they are being put to good use. :)).
Quote from: bejacob on July 04, 2015, 01:30:20 PM
Quote from: Jim on July 02, 2015, 09:15:34 PM
Per-route clinching stats are now in log files. Please let me know if you notice problems.
One route that popped up on my log is SC31 near Myrtle Beach. I can't figure out how. I drove US501 from into town from Conway and picked up US17 heading south. Perhaps there is a concurrency I'm missing :confused:. Here's my SC map http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=SC&u=bejacob (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=SC&u=bejacob) in case someone wants to take a look and can explain how that extra teal colored line showed up near Myrtle Beach.
The rest of the state looks fine except for the gaps left where I drove on SC state highways not yet part of the database (which I'm perfectly fine with since I know the reason). I didn't notice this route (SC31) when I first glanced at my map, but found it while reviewing the per-route stats. (So Jim, they are being put to good use. :)).
Did you add 'Future I-74' there to your list file?
Quote from: rickmastfan67 on July 04, 2015, 02:12:59 PMDid you add 'Future I-74' there to your list file?
It appears that I did. I knew it had to be something wrong in my list, but I couldn't track down which route was causing my problem. I'll get the offending Future I-74 removed. :)
Thanks for the help.
Quote from: Jim on July 02, 2015, 09:15:34 PM
More stats! Per-route clinching stats are now in log files. Please let me know if you notice problems. My spot checks matched CHM for my routes except in cases where my .list has been updated or the data changed (like the NM 599 example mentioned upthread). I'm unlikely to get the stats into the DB tonight but that's my next project, so we'll be able to see things on web pages. Please remember that the stats in the logs aren't pretty nor are they intended to be. It's just a convenient way to see them, and I'm tempted to leave them in there even when they're available through other means. Or maybe they could be in a separate log file or something like that.
The map overlays look great and are particularly helping in spotting errors (as I have found numerous times). The stats appear to be accurate. It looks as though the engine behind the new site is functioning properly.
So what comes next?
Adding new systems? (I saw several posts discussing which systems were nearest completion).
Getting stats into a web based report that users can easily read and understand?
Some other functionality?
Enquiring minds want to know.
For my part, I plan to get the computed stats into the DB, so they're available for viewing on web pages. I was hoping this would happen tonight, but the evening is slipping away on me quickly... I also hope I can get the site update program reading from the new directory organization, which will make it possible to archive the "chm_final" data and start making fixes and improvements. As for new systems, I think it's best to get the current active systems up to date first before anything new is activated.
Then I'll be traveling for a while and won't contribute much (but do hope to check in on the discussion when possible).
For those wondering, there's been some important behind-the-scenes progress made this week. I think all of the stats I compute (including everything needed to support all of the stats and rankings CHM provided, unless I'm missing something) are now in the DB. I haven't updated any web-facing code to use them, but I might tinker with that tonight or tomorrow night. Or I might update the script to use the new directory organization first.
Some stats about the system so far:
- The Python program that analyzes the input files, generates logs and SQL takes about 3 1/2 minutes to run on my MacBook Pro.
- The SQL file contains 1,681,834 lines. Moving to the server takes about a minute to compress (bzip2 -9), transmit, and uncompress.
- It takes mysql less than a minute and half to ingest that SQL file. This is the only time when the site is not functional.
Well, before I do anything else, I need to fix up a problem I introduced that seems to show up as completely incorrect mapping results for state highway systems. I'll post again if and when I can get it fixed. In the meantime, ignore your maps...
Quote from: Jim on July 09, 2015, 09:29:32 PM
Well, before I do anything else, I need to fix up a problem I introduced that seems to show up as completely incorrect mapping results for state highway systems. I'll post again if and when I can get it fixed. In the meantime, ignore your maps...
And every system that isn't an interstate, so far as I can see. Interstate Business Loops are extremely odd. Like it's showing me that I've done an isolated chunk of I-25BLDou, which isn't in my .list at all yet. I'd have never caught it had I not been just *now* updating my .list file. After all, gotta log in the day's travel before I go and forget.
Edit to add: SSOWorld clears up the problem. (And I really appreciate all of the work that's gone in to an internet function I love.)
That be the database crunching numbers :sombrero:
Should be good now. I was relying on two DB queries to return things in the same order, and one stopped doing so with a recent change (dealing with connected routes). Once I tracked it down, it was an easy fix to the DB query to force both to have the same ordering. After tracking it down, I remembered worrying that I was relying on something that was probably not guaranteed, and sure enough, I was.
Let me know if you still see any errors.
Quote from: Jim on July 09, 2015, 11:25:25 PM
Should be good now. I was relying on two DB queries to return things in the same order, and one stopped doing so with a recent change (dealing with connected routes). Once I tracked it down, it was an easy fix to the DB query to force both to have the same ordering. After tracking it down, I remembered worrying that I was relying on something that was probably not guaranteed, and sure enough, I was.
Let me know if you still see any errors.
In my Florida region map (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=FL&u=thefxexpert), there is a gap in I-75 between waypoint 240 and what I guess is supposed to be a hidden waypoint. A straight line also displays between its two endpoints. My stats appear to be inflated due to the error as well. (It should be ~49%)
Quote from: theFXexpert on July 10, 2015, 11:48:53 AM
In my Florida region map (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=FL&u=thefxexpert), there is a gap in I-75 between waypoint 240 and what I guess is supposed to be a hidden waypoint. A straight line also displays between its two endpoints. My stats appear to be inflated due to the error as well. (It should be ~49%)
Looks like this is happening on all users' Florida maps.
Quote from: mapcat on July 10, 2015, 12:01:35 PM
Quote from: theFXexpert on July 10, 2015, 11:48:53 AM
In my Florida region map (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=FL&u=thefxexpert), there is a gap in I-75 between waypoint 240 and what I guess is supposed to be a hidden waypoint. A straight line also displays between its two endpoints. My stats appear to be inflated due to the error as well. (It should be ~49%)
Looks like this is happening on all users' Florida maps.
Bug squashed, thanks. It's another place that I was relying on a non-guaranteed ordering of values coming out of the DB. For some reason, it decided to provide I-75 FL starting with 240, down to 1, then back up to FL/GA then down the northern half. So I forced it to sort within a route by the waypoint ids created when the DB is populated. Something I should have done when I first implemented.
Keep any reports of odd behavior coming in.
Is there a way to display a specific road in the maps? Say I wanted to just look at what I'd driven on I-5. Could I add something similar to CHM's "r=ca.i005"?
Quote from: Purgatory On Wheels on July 10, 2015, 06:45:44 PM
Is there a way to display a specific road in the maps? Say I wanted to just look at what I'd driven on I-5. Could I add something similar to CHM's "r=ca.i005"?
Yes, that's still there in the draft highway browser, which was the first of the maps produced in the new project. For example:
http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny008&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=ny.ny008&u=terescoj)
Ah ok. I was leaving the mapview.php in the address and thought you might have disabled this. Thanks.
At some point, all of the functionality will be organized into a coherent site, so you won't have to remember URLs from this discussion board...
One suggestion for hbtest:
Presently the waypoint numbering starts at 0. I'd prefer it starting at 1 as on the old site. That way, waypoint numbers would correspond with line numbers in the text file, making it easier to look up & edit points in gedit or notepad++, etc.
Quote from: yakra on July 12, 2015, 01:29:15 PM
One suggestion for hbtest:
Presently the waypoint numbering starts at 0. I'd prefer it starting at 1 as on the old site. That way, waypoint numbers would correspond with line numbers in the text file, making it easier to look up & edit points in gedit or notepad++, etc.
Done, but barely tested. Hopefully I didn't break anything else (seems unlikely that the change I made would).
My site update script switched over to use the new hwy_data folder for its highway data tonight. I had to make a bunch of minor fixes (some missing files, files in incorrect locations, etc.) to the data but that's all committed and pushed, and the script is producing the same output as far as I can tell. I'm updating the DB now, should be live in a few minutes. Please let me know if you notice anything has broken with this switch.
At this point, we should not need to touch chm_final -- we'll retain it for historical purposes and for reference, but from this point forward, we'll be diverging from CHM's highway data.
I'd like to have a couple of experienced highway data maintainers who have fixes to put in fork a copy of the HighwayData repository and try to make a couple changes, then commit to your fork and when you're ready, submit a pull request. Let's start it small for the moment, and once we know the process works, we can get going on a full-scale update to fix up existing active systems with changes and corrections that have accumulated since last year.
Shouldn't we hold off on diverging from legacy CHM data for a bit longer, until there's more of an active user base, and an equivalent of labelsinuse?
Also, the Wisconsin problem I emailed you about last week still hasn't been resolved. I found one error (US53BusSol has the same mileage as US53BusSup) but suspect there's another one, since the data is still ~3 miles off, and am continuing to look. Details in this post (https://www.aaroads.com/forum/index.php?topic=15733.msg2078280#msg2078280).
Edit: added link to details.
Quote from: yakra on July 13, 2015, 02:48:13 AM
Shouldn't we hold off on diverging from legacy CHM data for a bit longer, until there's more of an active user base, and an equivalent of labelsinuse?
I'm ready to take in as many users as we wish, but do we have a way to invite them in other than this forum? I suppose we could grab everyone's list files from CHM. I think we'd end up with many out-of-date and unmaintained files, so I'm hesitant.
We do have the last points in use data from CHM still available, and the new system has the much smaller subset generated by our 32 users in log file form.
As the changes and corrections are made, would this also be a good time to explore redefining what makes a route worthy of being listed?
Examples that come to mind: adding New York's Cross County Parkway and Kentucky's Hal Rogers Parkway, among others, to US Select Named Freeways. The part of the NYST's Berkshire Connector that isn't I-90 also ought to be considered. IIRC, the argument against these was that they were either too short, or (in the case of the Hal Rogers Pkwy) mostly 2-lane.
Quote from: mapcat on July 13, 2015, 12:41:44 PM
As the changes and corrections are made, would this also be a good time to explore redefining what makes a route worthy of being listed?
Examples that come to mind: adding New York's Cross County Parkway and Kentucky's Hal Rogers Parkway, among others, to US Select Named Freeways. The part of the NYST's Berkshire Connector that isn't I-90 also ought to be considered. IIRC, the argument against these was that they were either too short, or (in the case of the Hal Rogers Pkwy) mostly 2-lane.
I have long been curious why the Hal Rogers Parkway wasn't included when all the other Kentucky Parkways were on the list. It is a fairly major route in that part of the state despite being mostly a 2-lane road.
Quote from: yakra on July 13, 2015, 02:48:13 AM
Shouldn't we hold off on diverging from legacy CHM data for a bit longer, until there's more of an active user base, and an equivalent of labelsinuse?
Obviously there's the question of pulling in .list files and whether we do it. A wider user base will be harder to attract with outdated data, and just creates more annoyed people when their list file has errors due to genuine can't-help-but-break-it changes that might be out there - on top of annoyed people who want to clinch a route they drove on months ago, but can't until the data is updated.
Also, surely (given we're using .wpt, rather than .wpt2), we have the older
labels in use in use that is correct but for the few changes made to .list files with our small test userbase?
I have updates that I sent to Tim a year ago and I'm just itching to finally get them published to the wider world.
Quote from: mapcat on July 13, 2015, 12:41:44 PMExamples that come to mind: adding New York's Cross County Parkway and Kentucky's Hal Rogers Parkway, among others, to US Select Named Freeways.
Or better yet: NY Parkways and KY Parkways respectively, rather than ussnf.
One thing I've wanted to see is breaking NY & KY Parkways and OK Turnpikes out into their own systems.
Didn't occur to me till just now though, that if it were just NY Parkways, that would exclude the Berkshire Connector. And that part of the Thruway that's neither I-87 nor I-90, if we want to get that nitty-gritty about it. Might be worthwhile to change the definition a bit...
NYST (inc Berkshire Connector) would surely (like the NY section of the GSP - which isn't a New York Parkway) just simply be in 'USA Named Freeways', not forming part of the specific set, but fine in the grab-bag?
Quote from: english si on July 13, 2015, 01:16:29 PM
Quote from: yakra on July 13, 2015, 02:48:13 AM
Shouldn't we hold off on diverging from legacy CHM data for a bit longer, until there's more of an active user base, and an equivalent of labelsinuse?
Obviously there's the question of pulling in .list files and whether we do it. A wider user base will be harder to attract with outdated data, and just creates more annoyed people when their list file has errors due to genuine can't-help-but-break-it changes that might be out there - on top of annoyed people who want to clinch a route they drove on months ago, but can't until the data is updated.
Also, surely (given we're using .wpt, rather than .wpt2), we have the older labels in use in use that is correct but for the few changes made to .list files with our small test userbase?
I have updates that I sent to Tim a year ago and I'm just itching to finally get them published to the wider world.
32 users is a large enough sample on which to test changes to the system. The work so far seems to have replicated CHM well, though there are still issues from time to time. Now that most of the underlying functionality is working it makes sense to move beyond CHM. Errors can still be identified and addressed. Gathering more users from CHM can be done at any time. Those of us here already (especially less technical folks like me) can continue to provide feedback and potentially ask the
stupid simple questions when we see things we don't understand.
I know that in addition to new systems and new/revised waypoints, there is still the web presence to develop. I would guess many CHM users will not be ready to use TM until more of that is in place. I've been able to figure out much of what I want using the stats in the log file and the map overlays. When pages like this http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra (http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra) are ready (whether similar or completely redesigned), I think more CHM users will want to participate.
As for the next steps, I say "go for it!"
I also wouldn't mind seeing the Oregon side of WA 433 (the Lewis and Clark Bridge), the Bridge of the Gods and the Hood River Bridge added, as they are the only substantial Columbia River crossings. And if the ferry portions of Washington's highways are included, that would include the Oregon side of WA 409 (I like how OSM flags WA 409 on Westport Ferry Rd in Westport, OR, lol).
Quote from: bejacob on July 13, 2015, 02:27:47 PM
Quote from: english si on July 13, 2015, 01:16:29 PM
Quote from: yakra on July 13, 2015, 02:48:13 AM
Shouldn't we hold off on diverging from legacy CHM data for a bit longer, until there's more of an active user base, and an equivalent of labelsinuse?
Obviously there's the question of pulling in .list files and whether we do it. A wider user base will be harder to attract with outdated data, and just creates more annoyed people when their list file has errors due to genuine can't-help-but-break-it changes that might be out there - on top of annoyed people who want to clinch a route they drove on months ago, but can't until the data is updated.
Also, surely (given we're using .wpt, rather than .wpt2), we have the older labels in use in use that is correct but for the few changes made to .list files with our small test userbase?
I have updates that I sent to Tim a year ago and I'm just itching to finally get them published to the wider world.
32 users is a large enough sample on which to test changes to the system. The work so far seems to have replicated CHM well, though there are still issues from time to time. Now that most of the underlying functionality is working it makes sense to move beyond CHM. Errors can still be identified and addressed. Gathering more users from CHM can be done at any time. Those of us here already (especially less technical folks like me) can continue to provide feedback and potentially ask the stupid simple questions when we see things we don't understand.
I know that in addition to new systems and new/revised waypoints, there is still the web presence to develop. I would guess many CHM users will not be ready to use TM until more of that is in place. I've been able to figure out much of what I want using the stats in the log file and the map overlays. When pages like this http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra (http://cmap.m-plex.com/stat/region.php?u=bejacob&c=usa&rg=oh&du=mi&sort=ra) are ready (whether similar or completely redesigned), I think more CHM users will want to participate.
As for the next steps, I say "go for it!"
I have been meaning to do this even before this project, where do I sign up?
I'll be offline a lot the next few weeks, and my time for the project will be much more limited when I get back. I'd like to focus my efforts on helping others get to the point where they can work on the web front end and get going on highway data updating and later, new development. I'd also like to get a few people to volunteer to take .list file updates from those who would prefer to keep their hands out of GitHub, and get them into GitHub on their behalf. For now, I think just accepting them by email to some alias (I'm willing to set one up), with some sort of upload system to be developed later to replace that process. I should be able to run occasional updates to my preliminary site a few times a week while I'm away, probably daily when I return. I hope we can transition fairly soon to a situation where multiple people can run updates. Anyone should be able to have a copy of the repositories and with Python can generate the .sql and .log files. I think only one other has done that so far, and I'd like to get more people up to speed with how to do that.
I've mentioned before that I'm not likely to do much on the front-end web side. I hope there are others more qualified than I am to do that part. I will try to encourage some students to work on it, but I don't want to promise anything. I think almost everything we need to replicate CHM is in the DB now, so it's a matter of writing PHP and JS code along the lines of what you see in the mapview.php and chmviewerfunc3.js in the Web repository to generate other maps and lots of stats.
As a note: I've been able to get PHP code working to draw the lines of the CHM style maps. However, I have not been able to get the clinched status to work yet. I haven't published it yet, but it is in a fork in my personal directory in GitHub. I'm trying to figure out how to filter out clinched points in the database. to properly draw the lines. At this point, the lines do plot the routes, but the clinched lines saturate and draw all over.
https://github.com/ssoworld/Web for the code. EDIT: VERY Prototype
EDIT 2: Need to change numbering scheme to start at 1. Won't work until then.
NOTE: haven't done anything for just over a week - so DB may not be accurate. Caution.
I'm not a programmer by any definition, but just wanted to pop up to say that I hope this effort comes to fruition. I'm sure there are a "lot" of other people like me lurking on the sidelines whose eyes sort of glaze over the technical details that are just waiting for a new site to come online so they can restart tracking their clinches.
Thanks to all that have been involved so far!
Quote from: SSOWorld on July 13, 2015, 09:37:54 PM
As a note: I've been able to get PHP code working to draw the lines of the CHM style maps. However, I have not been able to get the clinched status to work yet. I haven't published it yet, but it is in a fork in my personal directory in GitHub. I'm trying to figure out how to filter out clinched points in the database. to properly draw the lines. At this point, the lines do plot the routes, but the clinched lines saturate and draw all over.
https://github.com/ssoworld/Web for the code. EDIT: VERY Prototype
NOTE: haven't done anything for just over a week - so DB may not be accurate. Caution.
I owe you an email about this - I'll get back to you before I leave.
Quote from: Rothman on July 13, 2015, 09:39:32 PM
I'm not a programmer by any definition, but just wanted to pop up to say that I hope this effort comes to fruition. I'm sure there are a "lot" of other people like me lurking on the sidelines whose eyes sort of glaze over the technical details that are just waiting for a new site to come online so they can restart tracking their clinches.
Thanks to all that have been involved so far!
I'm very much in your situation. I've been sending updates of my list to Jim as I make them for inclusion each time he updates the database. So far things look great. Lots still to happen, but I will add my thanks to everyone working on the project. From my perspective, I submit my file and Jim waves a magic wand which produces a log, stats, and maps. Then I have to figure out why there is an extra line here or there. :hmmm:
Again, kudos to all of you who understand what goes on inside the black box. To many of us, it's still magic. :-D
Quote from: bejacob on July 13, 2015, 12:57:07 PM
Quote from: mapcat on July 13, 2015, 12:41:44 PM
As the changes and corrections are made, would this also be a good time to explore redefining what makes a route worthy of being listed?
Examples that come to mind: adding New York's Cross County Parkway and Kentucky's Hal Rogers Parkway, among others, to US Select Named Freeways. The part of the NYST's Berkshire Connector that isn't I-90 also ought to be considered. IIRC, the argument against these was that they were either too short, or (in the case of the Hal Rogers Pkwy) mostly 2-lane.
I have long been curious why the Hal Rogers Parkway wasn't included when all the other Kentucky Parkways were on the list. It is a fairly major route in that part of the state despite being mostly a 2-lane road.
Because it wasn't a full freeway. That was the sticking point for Tim. I had the file done at that time when the other Parkways went online, but Tim didn't want to add it because of that.
I know nothing about PHP or GitHub, but I can send my .list file and my states' folders (if necessary) to those in need of data if necessary.
Quote from: yakra on July 12, 2015, 01:29:15 PM
One suggestion for hbtest:
Presently the waypoint numbering starts at 0. I'd prefer it starting at 1 as on the old site. That way, waypoint numbers would correspond with line numbers in the text file, making it easier to look up & edit points in gedit or notepad++, etc.
Waypoints for interstates started at 0 at the state line. (Hence the "0 999" point entries.)
Quote from: Jeff Morrison on July 14, 2015, 01:57:36 AM
I know nothing about PHP or GitHub, but I can send my .list file and my states' folders (if necessary) to those in need of data if necessary.
Quote from: yakra on July 12, 2015, 01:29:15 PM
One suggestion for hbtest:
Presently the waypoint numbering starts at 0. I'd prefer it starting at 1 as on the old site. That way, waypoint numbers would correspond with line numbers in the text file, making it easier to look up & edit points in gedit or notepad++, etc.
Waypoints for interstates started at 0 at the state line. (Hence the "0 999" point entries.)
That's a reference to waypoint labeling. I mean numbering them, such as when for ME US1AltMil, US1_S is Waypoint 1 of 9 (as shown by WPTedit), KanRd is Waypoint 2 of 9, etc.
Quote from: Jim on July 13, 2015, 09:34:02 PM
I'll be offline a lot the next few weeks, and my time for the project will be much more limited when I get back. I'd like to focus my efforts on helping others get to the point where they can work on the web front end and get going on highway data updating and later, new development. I'd also like to get a few people to volunteer to take .list file updates from those who would prefer to keep their hands out of GitHub, and get them into GitHub on their behalf.
I'd like to keep updating my .list file as I add new routes and discover ones I've missed or entered incorrectly. Jim has been a huge help keeping me up to date in the database. If there is someone other than Jim I should send updates to, please let me know via personal message.
Thanks,
Brian
Quote from: rickmastfan67 on July 13, 2015, 10:30:59 PM
Quote from: bejacob on July 13, 2015, 12:57:07 PM
Quote from: mapcat on July 13, 2015, 12:41:44 PM
As the changes and corrections are made, would this also be a good time to explore redefining what makes a route worthy of being listed?
Examples that come to mind: adding New York's Cross County Parkway and Kentucky's Hal Rogers Parkway, among others, to US Select Named Freeways. The part of the NYST's Berkshire Connector that isn't I-90 also ought to be considered. IIRC, the argument against these was that they were either too short, or (in the case of the Hal Rogers Pkwy) mostly 2-lane.
I have long been curious why the Hal Rogers Parkway wasn't included when all the other Kentucky Parkways were on the list. It is a fairly major route in that part of the state despite being mostly a 2-lane road.
Because it wasn't a full freeway. That was the sticking point for Tim. I had the file done at that time when the other Parkways went online, but Tim didn't want to add it because of that.
I'm guessing that is the same reason roads like the
Blue Ridge Parkway and the
Natchez Trace Parkway were not included. Those seem notable omissions.
And yet the entire length of the Bronx River and Taconic State Parkways were included. :rolleyes:
As well they should be since even though they aren't full freeways, NY Parkways don't have to be and are important roads nonetheless.
Quick note: I have discovered an error in my concurrency detection. I traveled from Arnprior to Thunder Bay on ON 17, including its entire concurrency with ON 11 in North Bay and the part of their concurrency from Nipigon and Thunder Bay. My algorithm credited me with all of ON 11 between those concurrencies. I won't have time to fix this right away, but be aware that similar situations elsewhere are probably equally susceptible to this bug. Fixing this is at the top of my list for project work. I doubt it will be a big problem to fix.
Quote from: Jim on July 17, 2015, 10:14:51 PM
Quick note: I have discovered an error in my concurrency detection.
...
I'm glad I reported this only to myself, because it wasn't an error in the concurrency detection, it was a mislabeling in my .list file.
In the process, I was able to run a DB update. I think everything that's been sent to me recently is in. Please resend if not. Now that I think of it, I might not have pulled in an update or two that came through GitHub. I'll be sure to do those in the next update, likely within a few days.
Where have the colours gone?
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=WLS&u=si404 (http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=WLS&u=si404) had blue, red and brown a few days ago.
Edit: USA is fine http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=NV&u=si404 (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=NV&u=si404) has all the colours, including for non-clinched routes (which are grey in Europe).
Canada is like Europe - peach and gray.
Quote from: english si on July 22, 2015, 02:30:08 PM
Where have the colours gone?
http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=WLS&u=si404 (http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=WLS&u=si404) had blue, red and brown a few days ago.
Edit: USA is fine http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=NV&u=si404 (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=NV&u=si404) has all the colours, including for non-clinched routes (which are grey in Europe).
Canada is like Europe - peach and gray.
You have to go to mapview.php (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=WLS&u=si404).
Thanks!
So have all the pending road updates that were there last November been taken into account? I know Jeff had a lot of SD updates ready to go...
For my part, I still have a lot to be updated in my states and provinces, but still haven't gotten hip to GitHub yet...
I'm in the same boat as yakra here. I know I had some updates that were submitted to Tim between the last full site update and the last *.list update for the old CHM site. Just don't know what to do yet with GitHub. That, and I don't know when/if we're changing the format for them.
Quote from: SD Mapman on July 23, 2015, 12:46:00 AMSo have all the pending road updates that were there last November been taken into account? I know Jeff had a lot of SD updates ready to go...
Only I (and maybe Jim?) have updated any data from the base point of ~a year ago. Most of what I've updated is of little concern to people (deliberately started with that!).
I've just made a pull request (to test that system - having edit rights in the data folder meant I didn't need to) for Future I-11. I believe I did send that off to Tim summer/fall last year. I think that is the only one that was pending that I've uploaded (though I have synced a fair few regions, most of the updates were either me dragging Tim's regions that hadn't been touched in years to the present or were motorway openings that happened after I stopped emailing Tim. Bulgaria has the motorway that opened this week in the highway data folder (though not the browser yet as I only put it there yesterday!)).
As I have github working (well, online at least - the 'for Windows' program keeps mucking about), I can certainly get my regions' data up to date (though some works best with batch uploads that would be much better with the actual program) fairly quickly. I still need to proof read four of Tim's european regions - Spain took me a week (and I've still not done the E roads) and I hope Germany and Poland won't be that long, though they probably will (Sweden and Slovakia are the others. Slovakia is part done and at most a couple of hours, Sweden is full of long boring routes).
I'm going to be in one place for the most part next week, and I hope to nail down an appropriate GitHub-based procedure people can use to submit highway data updates.
To answer one other question briefly, I believe file format changes are on hold at least until we get current active systems up to date as much as we can.
I am confident that once all of us get comfortable with the GitHub based workflow, the whole process is going to be much smoother and more efficient.
I think we need a volunteer to be in charge of the list of "newsworthy" updates (new/deleted/extended/truncated routes, changes to waypoint names that could break .list files, etc.) and the list of sources. We don't really have a place to put them yet, but they should be tracked as we start updating, and later, expanding.
si -- I can't fathom why going over Spain's highways would take so long at all... x.x
Those systems were an absolute bear when I drafted them.
Is the online route editor we used still in existence? I can't find the relevant thread on the old forum.
Quote from: Bickendan on July 23, 2015, 11:34:53 AM
si -- I can't fathom why going over Spain's highways would take so long at all... x.x
Those systems were an absolute bear when I drafted them.
It's a bit better now gaps are filled and the exit number changeover process that you drafted your files during has gone further (some regions still holding out) - plus working with existing files I didn't have to think up how to deal with three exit numbering systems on the same route.
However, the pace of construction was insane and even though Tim kept fairly on top of it, there was a good several hundred km I had to add.
QuoteIs the online route editor we used still in existence? I can't find the relevant thread on the old forum.
Yes. It's in the tools.
How many segments of A/AP-7 did you have to stitch together? I think that was the worst one, with E-15 being the exit number monster since it's non-segmented.
Quote from: english si on July 23, 2015, 06:13:32 AM
Quote from: SD Mapman on July 23, 2015, 12:46:00 AMSo have all the pending road updates that were there last November been taken into account? I know Jeff had a lot of SD updates ready to go...
Only I (and maybe Jim?) have updated any data from the base point of ~a year ago. Most of what I've updated is of little concern to people (deliberately started with that!).
OK, thanks! Hopefully SD will get up to date soon. There was a lot that was going to be fixed.
Quote from: Jim on July 23, 2015, 08:18:43 AM
I'm going to be in one place for the most part next week, and I hope to nail down an appropriate GitHub-based procedure people can use to submit highway data updates.
When I worked at my last job, they used a system where people would create branches named with the issue number of the bug/feature they were working on, mark it as resolved when done, and the primary maintainer would mark the issue as closed when the branch was merged back into master.
There haven't been any recent updates on the stats pages and other features people besides Jim are working on. What's their status?
Quote from: mapcat on July 28, 2015, 04:56:36 PM
There haven't been any recent updates on the stats pages and other features people besides Jim are working on. What's their status?
I've been lagging badly :( - busy with work. I hope to get some work in on the map drawing this weekend.
Quote from: vdeane on June 22, 2015, 09:47:08 PM
It would seem that the big hole at this point with the new HB is the lack of an index page.
Hi Jim, et al,
I think my current question is tied into what Valerie is talking about in the above quote. I was wondering about the status to see all routes available in a given state so that I can tweak my .list file further. One route that I've been on (minimally) that would benefit from this is US1 Bypass in Kittery, ME. I can see there are waypoints for the route when I look at Maine, but when trying to find the route to look at it, I can't figure out what it's named. I tried the common names: me.us001bypkit, me.us001byp, me.us001altkit.
Many thanks,
-Ed S
bypass bannered routes tend to be part of the mainline (if the other route is a business route). However this one is a continuation of the bypass of the larger city of Portsmouth, NH so is me.us001byppor
Quote from: english si on July 31, 2015, 03:13:55 PM
bypass bannered routes tend to be part of the mainline (if the other route is a business route). However this one is a continuation of the bypass of the larger city of Portsmouth, NH so is me.us001byppor
I confirmed this with CHM's Highway Browser, which still works (though it identifies the route as ME US1BypPor -- route names in the HB, which are the ones you use in your list files, follow slightly different naming conventions than the names of the underlying route files, such as differences on capitalization and leading zeroes).
The HB has not been updated since last year, but then again the Travel Mapping database hasn't yet been updated much (including new routes) either. Such updates are among the next items on our to-do list. Until then, the CHM Highway Browser will be a good guide to the TM database.
I'm still hoping that others will take the lead on the web front end, as the time I can put into the project is going to me much more limited than it was during the initial implementation push. For now, I should be able to throw together a page that will at least let people get to the new draft HB in an easier way and without knowing the wpt file names, as well as a way to get to the Google Maps overlay mapping without having to know all of the region/system codes and an obscure URL. Slight chance this weekend, better chance in about a week. I could pretty easily put together a static page based on current data, but it would make more sense to use PHP and get all of the info right from the DB.
I can't be of much help on the "front end", since I never got beyond simple HTML (many generations ago) for my own rather basic websites, let alone anything like PHP or even JavaScript.
As soon as I get GitHub access to the project (my GitHub username is ovoss -- Jim, did you get my e-mailed request for access?) and can figure out how to use GitHub and our repository structure, I'll start with minor updates to existing route files that won't break anyone's route files. More significant changes can follow, once we have something like an Updates page to notify users of those changes. Separately, I'll also start on a new instruction manual, with drafts put out for comments in simple HTML and parked on one of my own webspaces, though once it's ready for prime time I would need some help translating it to a more modern format working better with the rest of Travel Mapping.
Quote from: Jim on July 31, 2015, 04:31:33 PM
I'm still hoping that others will take the lead on the web front end, as the time I can put into the project is going to me much more limited than it was during the initial implementation push. For now, I should be able to throw together a page that will at least let people get to the new draft HB in an easier way and without knowing the wpt file names, as well as a way to get to the Google Maps overlay mapping without having to know all of the region/system codes and an obscure URL. Slight chance this weekend, better chance in about a week. I could pretty easily put together a static page based on current data, but it would make more sense to use PHP and get all of the info right from the DB.
I'd like to work on the web frontend (I
did already put some work in on the waypoint editor and part of the front page), although I have so many projects I want to work on. I'll try to get some of this stuff done though.
Highway updates are now pulled into the DB from the updates.csv file. There's also a very simple (but complete) page that displays all updates in a big HTML table:
http://www.teresco.org/~terescoj/travelmapping/devel/updates.php (http://www.teresco.org/~terescoj/travelmapping/devel/updates.php)
As with CHM, I expect this list would only have new routes and systems, and other changes that would potentially affect an existing .list file. This would include extensions, truncations, deletions, renamings of routes or points. If we recenter a point or relabel a point no one is using, for example, no updates entry would be needed.
Date;Region;Route;Description. (Still semicolon-separated, right?) Looks pretty self-explanatory in format.
How is it used & implemented?
(One of these days I'm gonna hop on board the GitHub train...)
Quote from: yakra on August 08, 2015, 07:12:13 PM
Date;Region;Route;Description. (Still semicolon-separated, right?) Looks pretty self-explanatory in format.
How is it used & implemented?
Simple enough: just add entries to the file as you make newsworthy changes. Next update, they'll be used in DB population.
Quote
(One of these days I'm gonna hop on board the GitHub train...)
Good news on that: I'm working right now on a project-specific document that's aimed at those who will be contributing to the highway data updates to outline how to use GitHub to do all of this. Hope to have something to post tonight, but we'll see.
Something seems to have gotten seriously garbled. I'm noticing all of a sudden in region maps stuff is showing as clinched that I never marked and not clinched that I have. At least for NY and RI.
Quote from: Duke87 on August 08, 2015, 10:25:57 PM
Something seems to have gotten seriously garbled. I'm noticing all of a sudden in region maps stuff is showing as clinched that I never marked and not clinched that I have. At least for NY and RI.
Could you give me some specific examples to investigate? My own maps look OK.
Yeah, and the index page won't work for me. Is there something I'm supposed to do that I don't see?
Quote from: SD Mapman on August 09, 2015, 01:06:33 AM
Yeah, and the index page won't work for me. Is there something I'm supposed to do that I don't see?
You mean at http://www.teresco.org/~terescoj/travelmapping/ (http://www.teresco.org/~terescoj/travelmapping/) ?
That's only experimental, and doesn't do anything useful yet. It's just my place to see about populating menus and creating links from the DB. For now, you still need to enter the URLs manually to get to your maps for a given region or set of systems, or your log file with errors and stats.
I just ran an update with a whole bunch of Europe changes from Si now incorporated. My own maps and stats look fine, and please let me know if you see problems.
Quote from: Jim on August 09, 2015, 10:53:26 AM
I just ran an update with a whole bunch of Europe changes from Si now incorporated. My own maps and stats look fine, and please let me know if you see problems.
How to figure out what's the shortcut of a new route, for instance: 15-07-24 Switzerland A4 (Thayngen) New Route :confused:
Quote from: michih on August 09, 2015, 11:21:48 AM
Quote from: Jim on August 09, 2015, 10:53:26 AM
I just ran an update with a whole bunch of Europe changes from Si now incorporated. My own maps and stats look fine, and please let me know if you see problems.
How to figure out what's the shortcut of a new route, for instance: 15-07-24 Switzerland A4 (Thayngen) New Route :confused:
This is certainly not a long-term solution, but at the moment, one way to find them is to look in the .csv files in https://github.com/TravelMapping/HighwayData/tree/master/hwy_data/_systems (https://github.com/TravelMapping/HighwayData/tree/master/hwy_data/_systems)
As the project matures, I am expecting we'll develop a usable highway browser with at least as much functionality as the old one from the CHM project.
A short term thing we could do is require the route be specified in the updates.csv file using the "root" name like "ma.i091". Since those are unique, I could then look up other information about the route from the DB to be displayed in the updates page on the web.
A medium term thing would be that once the above entry is there and loaded into the DB, each entry in the updates table could be a link to the draft HB view of that route.
Quote from: Jim on August 09, 2015, 11:34:45 AMA short term thing we could do is require the route be specified in the updates.csv file using the "root" name like "ma.i091". Since those are unique, I could then look up other information about the route from the DB to be displayed in the updates page on the web.
A medium term thing would be that once the above entry is there and loaded into the DB, each entry in the updates table could be a link to the draft HB view of that route.
Both of these sound good. The latter is something I've wanted for ages. I will update (in a fork) the updates.csv file with routes for non-deleted files later today.
michih - che.a004tha (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=che.a004tha)
Quote from: Jim on August 08, 2015, 07:39:18 PM
Simple enough: just add entries to the file as you make newsworthy changes. Next update, they'll be used in DB population.
So, it's one master file rather than a small one detailing the changes in my own individual update.
Do I want to take care to add entries alphabetically, or does updates.php sort it automatically?
Quote from: yakra on August 09, 2015, 12:47:40 PM
Quote from: Jim on August 08, 2015, 07:39:18 PM
Simple enough: just add entries to the file as you make newsworthy changes. Next update, they'll be used in DB population.
So, it's one master file rather than a small one detailing the changes in my own individual update.
Do I want to take care to add entries alphabetically, or does updates.php sort it automatically?
I'd just make edits at the end. We can sort by things other than date with PHP later.
Quote from: Jim on August 09, 2015, 11:34:45 AM
Quote from: michih on August 09, 2015, 11:21:48 AM
Quote from: Jim on August 09, 2015, 10:53:26 AM
I just ran an update with a whole bunch of Europe changes from Si now incorporated. My own maps and stats look fine, and please let me know if you see problems.
How to figure out what's the shortcut of a new route, for instance: 15-07-24 Switzerland A4 (Thayngen) New Route :confused:
This is certainly not a long-term solution, but at the moment, one way to find them is to look in the .csv files in https://github.com/TravelMapping/HighwayData/tree/master/hwy_data/_systems (https://github.com/TravelMapping/HighwayData/tree/master/hwy_data/_systems)
That's perfect :)
Quote from: english si on August 09, 2015, 11:47:20 AMmichih - che.a004tha (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=che.a004tha)
In combination, I get the data I need :cool:
The updates.php page now has links to highway browser pages using the new "root" fields Si added today. Enjoy.
I got on a bit of a roll, and this was more fun than the things I should be doing/working on...
I enhanced my draft highway browser tonight. Main items, some more interesting than others:
- New URL: http://www.teresco.org/~terescoj/travelmapping/devel/hb.php (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php)
- If you don't give it any parameters, instead of a blank page with an empty map, it gives a crude but complete table showing all of the routes in the system, with a link to the highway browser for each in the last column.
- The PHP code has been updated to use a more modern and apparently more secure interface to mysql.
- You can still provide parameters directly if you already know your route's "root", so http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ny.ny103 (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ny.ny103) will still take you directly to the excitement that is NY 103.
- You can still tack on a u= parameter to get clinched segments shaded for a given user, such as http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ny.ny028&u=terescoj (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ny.ny028&u=terescoj)
The main good news is that there's at least a way now that the end user can figure out what routes we have and what the waypoint names are for those routes.
Of course, it's ugly and that's a huge table. Eventually I'd make it easier to select by various criteria like in the CHM HB, but I also wouldn't be upset if someone else beats me to it. The code for this as I've implemented so far will be in GitHub shortly.
Nice work, Jim!
Couple questions:
Would it be possible to set it up so that if I add ?u=mapcat (or something similar) to the end of http://www.teresco.org/~terescoj/travelmapping/devel/hb.php, it will automatically add that string to the url of whatever route I select? IOW, if I click on ak.ia001, it would direct me to http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ak.ia001&u=mapcat instead of just http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ak.ia001.
Also, does the appearance of the AK, MT, NM, UT, and VT state highway sets in the table mean that they'll be activated soon?
Thanks!
Quote from: mapcat on August 09, 2015, 11:30:38 PM
Would it be possible to set it up so that if I add ?u=mapcat (or something similar) to the end of http://www.teresco.org/~terescoj/travelmapping/devel/hb.php, it will automatically add that string to the url of whatever route I select? IOW, if I click on ak.ia001, it would direct me to http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ak.ia001&u=mapcat instead of just http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ak.ia001.
Also, does the appearance of the AK, MT, NM, UT, and VT state highway sets in the table mean that they'll be activated soon?
Thanks!
Thanks - I'll see about propagating the u= parameter next time I can put some effort into this part.
I made no distinction here between active and in-development systems, though I should. I do hope they'll be activated sooner rather than later, but their appearance here is nothing more than me not remembering to denote them as in-development somehow in the table.
The problem I was having was with the "view every route in this region" view, which with your recent revamp I'm not getting at all ("rg=RI&u=duke87" just takes me to the main list). I know it was marking Western NY as mostly done for me when there shouldn't be much, and my percent completion for NY had magically jumped from the 50s into the 60s.
I'm on the road currently and seeing all this on my phone. I haven't been able to check if the same thing happens on an actual computer.
Is there a new system that is ready for travelers to submit files?
Quote from: Duke87 on August 10, 2015, 08:34:33 AM
The problem I was having was with the "view every route in this region" view, which with your recent revamp I'm not getting at all ("rg=RI&u=duke87" just takes me to the main list). I know it was marking Western NY as mostly done for me when there shouldn't be much, and my percent completion for NY had magically jumped from the 50s into the 60s.
I'm on the road currently and seeing all this on my phone. I haven't been able to check if the same thing happens on an actual computer.
That functionality was superceded by the map viewer and had some definite problems, so I removed it from the draft highway browser. If it does something that you can't do/see with mapview.php, still in its old location, let me know.
Quote from: cabiness42 on August 10, 2015, 08:41:41 AM
Is there a new system that is ready for travelers to submit files?
"Ready" is a strong word, but you're welcome to send me .list files to be included in the system we have in development. Many things aren't pretty yet but it's a start. PM for my email address.
GitHub user Thing342 ("Thing 342" here, I assume) has contributed an enhancement that allows filtering of the routes in the draft browser by system and/or region. I'll gladly pull this into the new version unless anyone finds some major flaws with it. Give it a try at:
http://www.teresco.org/~terescoj/travelmapping/Thing342-devel/hb.php (http://www.teresco.org/~terescoj/travelmapping/Thing342-devel/hb.php)
Thanks for the contribution, Thing342.
The main thing I noticed is that the table overlaps the header text.
Two suggestions:
-Might be a good idea to note the filtering in the header and have a "clear" button or something to go to the full index (though just hitting search with no text does the same thing)
-Perhaps highways on in development systems could have their row colored gray or something instead of white.
Display is a bit off in Firefox 20.0
205.209.84.174/roads/images/chm/thing342.png
The enhanced version is now the primary one at
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php)
I'm happy to consider more fixes/improvements, of course.
Just a note (not crying out to be fixed anytime soon) that the draft highway browser includes some but not all in-development systems, including AK, NM, and UT state routes (but not, at least, CA and FL). AK is still incomplete, so people should hold off on recording their travels on that draft system.
The index to what routes are in the browser, in some form, is very helpful.```
Yep, FL is no where near ready as there as several routes I still need to fully weed out segments of 'hidden' state highways on US highways/Interstates. Only the routes up to 99 are in good shape of that (9B is on my HD, just not on the site yet).
The updates.php page is temporarily out of service. A change I made is on my main computer which went in for repairs today and I apparently forgot to push the change up to GitHub. Rather than re-coding, I'd like to let the updates.php page be broken for a few days until the computer is back.
Directed to Oscar, but how's California's state highway system looking? Seems like this one of the more anticipated systems.
The California state routes system is back-burnered for the time being. Basically, there is too much higher-priority work for the team to focus on first, such as getting the site up and running, and catching up with a lot of needed updates to already-activated systems (including in my own areas once I get the hang of GitHub, and also other areas previously handled by Tim and not yet taken over by other team members), which should keep us all busy and out of trouble for awhile. I also have Alaska state routes on my plate, a smaller system that's closer to activation (though it still needs some work, and whatever peer-review-like process we decide to do on new systems other than the four that have already been peer-reviewed).
I know California is much-anticipated -- including by me, a former resident and still-frequent traveler there -- but the greater anticipation is for getting the overall site in good shape first.
Quote from: Jim on August 10, 2015, 08:23:01 PM
The enhanced version is now the primary one at
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php)
I'm happy to consider more fixes/improvements, of course.
When I load an actual highway map from that page, I don't see any markers shown. Just the blue polyline. Is this the same for anyone else?
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ks.ks061
Quote from: oscar on August 11, 2015, 01:33:07 AM
The California state routes system is back-burnered for the time being. Basically, there is too much higher-priority work for the team to focus on first, such as getting the site up and running, and catching up with a lot of needed updates to already-activated systems (including in my own areas once I get the hang of GitHub, and also other areas previously handled by Tim and not yet taken over by other team members), which should keep us all busy and out of trouble for awhile. I also have Alaska state routes on my plate, a smaller system that's closer to activation (though it still needs some work, and whatever peer-review-like process we decide to do on new systems other than the four that have already been peer-reviewed).
I know California is much-anticipated -- including by me, a former resident and still-frequent traveler there -- but the greater anticipation is for getting the overall site in good shape first.
What still needs to be done for California and/or is it something that others can assist?
Quote from: yakra on August 11, 2015, 01:22:00 PM
Quote from: Jim on August 10, 2015, 08:23:01 PM
The enhanced version is now the primary one at
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php)
I'm happy to consider more fixes/improvements, of course.
When I load an actual highway map from that page, I don't see any markers shown. Just the blue polyline. Is this the same for anyone else?
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ks.ks061
Same here.
Quote from: yakra on August 11, 2015, 01:22:00 PM
When I load an actual highway map from that page, I don't see any markers shown. Just the blue polyline. Is this the same for anyone else?
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ks.ks061
Fixed, thanks.
The updates.php page is back, and now includes the large update from Si that was being discussed recently in GitHub. Many regions in both the US and Europe were affected, so check out your updated logs in case your .list needs updating. For example, anyone who's flown into DEN will want to add Pena Boulevard mileage.
If I get VirtualBox working on my laptop (Windows 10) and can get time while dispatched for work - I'll be able to pick back up on the CHM drawing app over the next month. I can't guarantee at the moment. It still sits in my fork of the Web repo. It draws, but the "Clinched" algorithm doesn't work yet.
Quote from: SSOWorld on August 11, 2015, 07:04:33 PM
If I get VirtualBox working on my laptop (Windows 10) and can get time while dispatched for work - I'll be able to pick back up on the CHM drawing app over the next month. I can't guarantee at the moment. It still sits in my fork of the Web repo. It draws, but the "Clinched" algorithm doesn't work yet.
This would be excellent. I think you definitely want to get all data from the DB, where the "clinched" algorithm has already been applied!
I'll run an update tonight, likely after pulling in the pending data updates (the SD update seems ok to go and yakra's small Maine update). If you have a .list update you'd like included, send that along today. After that, I'm out with limited network access and likely no chance to participate here until Sunday night or Monday.
Newest update is just about completed. All pending pull requests in GitHub are in, both highway data updates and list files.
Signing off until Sunday night or Monday - will fix any problems noted and process any new updates then.
Quote from: SSOWorld on August 11, 2015, 07:04:33 PM
If I get VirtualBox working on my laptop (Windows 10) and can get time while dispatched for work - I'll be able to pick back up on the CHM drawing app over the next month. I can't guarantee at the moment. It still sits in my fork of the Web repo. It draws, but the "Clinched" algorithm doesn't work yet.
VirtualBox is going to be tough to start on Windows 10 right now as I need to find the right version - they aren't supporting Windows 10 yet either. My work may not be restartable until next month at the earliest.
So the HB, logs, and Github are out of sync (mainly the HB and the logs). At least for me, anyway.
Quote from: Jim on August 11, 2015, 03:14:17 PM
Quote from: yakra on August 11, 2015, 01:22:00 PM
When I load an actual highway map from that page, I don't see any markers shown. Just the blue polyline. Is this the same for anyone else?
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ks.ks061
Fixed, thanks.
In the enhanced HB, the names of waypoints are not showing in popups for me:
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FyGYpsFs.png&hash=ec782c316c65564e31c1d84213104de558bf4f49)
Still works fine in the old one.
As for the issue I was having before, either it has been fixed or is strictly a mobile problem since now I'm home on my computer and the region views look fine.
Quote from: SD Mapman on August 15, 2015, 08:40:07 PM
So the HB, logs, and Github are out of sync (mainly the HB and the logs). At least for me, anyway.
I am back home but will not have a chance to check into this (and the other items I see have come up here and it GitHub) probably until late tomorrow. There's a good chance my last update didn't end up in the DB or the newest logs didn't end up copying properly or something like that.
Quote from: Duke87 on August 16, 2015, 11:38:19 AM
Quote from: Jim on August 11, 2015, 03:14:17 PM
Quote from: yakra on August 11, 2015, 01:22:00 PM
When I load an actual highway map from that page, I don't see any markers shown. Just the blue polyline. Is this the same for anyone else?
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=ks.ks061
Fixed, thanks.
In the enhanced HB, the names of waypoints are not showing in popups for me:
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FyGYpsFs.png&hash=ec782c316c65564e31c1d84213104de558bf4f49)
Still works fine in the old one.
As for the issue I was having before, either it has been fixed or is strictly a mobile problem since now I'm home on my computer and the region views look fine.
Now I see markers for all points, including the ones that should be hidden.
For example, ME I-95 (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=me.i095) has +x8, +x11, +x13, +x17, and the rest...
Quote from: yakra on August 17, 2015, 02:23:45 PM
Now I see markers for all points, including the ones that should be hidden.
For example, ME I-95 (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=me.i095) has +x8, +x11, +x13, +x17, and the rest...
No labels, visible or hidden, are showing up for me. It's something to check out. I don't see anything obvious. Straightening out the reported data problems and pulling in more updates will take priority, though.
Opened Issue #4 in TravelMapping/Web on GitHub.
I've just finished pulling in a bunch of highway data updates, added in a few .list updates, and run a site update. Please let me know if any of the problems mentioned here in recent days persist. What you see in GitHub and what you see on maps and logs should all be consistent. It's certainly possible, though, that some things did not go as planned with the updates from last week and this evening.
One set of changes (US 34 and NE 370) that span both Iowa and Nebraska are only implemented on the Iowa side, but I know yakra plans to get the Nebraska side in soon and I'll run another update at that time.
Somehow US85BusTor slipped through the cracks again, and is still hiding in GitHub without being visible to everyone else. (Proof I'm not mad (https://github.com/TravelMapping/HighwayData/blob/master/hwy_data/WY/usausb/wy.us085bustor))
EDIT: I think it's because it doesn't have the .wpt extension on it.
Quote from: SD Mapman on August 17, 2015, 11:27:03 PM
Somehow US85BusTor slipped through the cracks again, and is still hiding in GitHub without being visible to everyone else. (Proof I'm not mad (https://github.com/TravelMapping/HighwayData/blob/master/hwy_data/WY/usausb/wy.us085bustor))
EDIT: I think it's because it doesn't have the .wpt extension on it.
Good catch. It also doesn't have entries in the .csv files, so the misnamed file didn't generate an error or warning. I'm fixing now and will re-run the update before I call it a night. Look for it in 15-20 minutes.
Quote from: Jim on August 17, 2015, 07:57:05 PM
Quote from: yakra on August 17, 2015, 02:23:45 PM
Now I see markers for all points, including the ones that should be hidden.
For example, ME I-95 (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=me.i095) has +x8, +x11, +x13, +x17, and the rest...
No labels, visible or hidden, are showing up for me. It's something to check out. I don't see anything obvious. Straightening out the reported data problems and pulling in more updates will take priority, though.
Opened Issue #4 in TravelMapping/Web on GitHub.
In this case I'm referring not to the text waypoint labels, but the small round black & green graphic marking each waypoint.
Several more highway data updates are in this evening. Let us know if anything looks to have gone wrong.
The new segment of A-73 isn't showing up.
Also, it would be nice if the updates.php page would sort by date. Currently, one has to read the entire page to see what's changed with each update.
Quote from: vdeane on August 19, 2015, 05:38:28 PM
The new segment of A-73 isn't showing up.
Also, it would be nice if the updates.php page would sort by date. Currently, one has to read the entire page to see what's changed with each update.
At least for me, the updates page is sorted by date, with most recent entries on the top. I don't know if there's a way for users to change the sort order, but I got sort-by-date without lifting a finger.
The route file for A-73 St-Georges was missing from my pull request yesterday. I e-mailed Jim a copy a few hours ago, so he can add it to the DB. The other new Quebec route files are already in the DB, taking care of Quebec for now (until new Autoroute extensions open to traffic, probably A-20 and another A-410 extension later this year).
Quote from: vdeane on August 19, 2015, 05:38:28 PM
The new segment of A-73 isn't showing up.
Also, it would be nice if the updates.php page would sort by date. Currently, one has to read the entire page to see what's changed with each update.
As Oscar mentioned, the A-73 will be in when I run an update tonight. I have it now. There are also a couple others that will go in tonight.
I envision lots of improvements on the updates page - it's about as plain and simple as it can get for now. I'd want to be able to filter or sort by date, region, route, type of change, etc. It's not likely going to be a priority for me for a while (but I'll say again, I'll happily accept more enhancements from others).
An update just completed. This includes the missing A-73 segment and yakra's most recent submissions of updates in Maine, Kansas, and New Brunswick, plus a few .list updates.
I found and fixed a few bugs in the draft highway browser (the one in devel/hb.php). The "info windows" (the thought-bubble looking things) should now show up with all of the desired information when you either click on a waypoint icon on the map or the name of a waypoint in the table on the left. Hidden waypoints should now never have entries in the table or waypoint markers on the map.
Thanks to those who reported the problems and for everyone's patience until I was able to take a look.
Quote from: oscar on August 19, 2015, 05:56:34 PM
Quote from: vdeane on August 19, 2015, 05:38:28 PM
The new segment of A-73 isn't showing up.
Also, it would be nice if the updates.php page would sort by date. Currently, one has to read the entire page to see what's changed with each update.
At least for me, the updates page is sorted by date, with most recent entries on the top. I don't know if there's a way for users to change the sort order, but I got sort-by-date without lifting a finger.
The route file for A-73 St-Georges was missing from my pull request yesterday. I e-mailed Jim a copy a few hours ago, so he can add it to the DB. The other new Quebec route files are already in the DB, taking care of Quebec for now (until new Autoroute extensions open to traffic, probably A-20 and another A-410 extension later this year).
Mine sorts by region when at home. Interestingly, it sorts by date at work.
The St-Georges section of A-73 was listed in updates.php before it got put in the last update.
Quote from: vdeane on August 20, 2015, 01:30:52 PM
The St-Georges section of A-73 was listed in updates.php before it got put in the last update.
Yeah, my bad.
A big update has been pulled in and the site updated tonight. 3 minor NY changes by me, and 1251 changes by Si. In addition to what you see on the updates page, a few in-development systems make their first appearance: state highways in Colorado, Indiana, and Wyoming (I think that's it) plus a very early preview of the usanp system just starting to be discussed and developed. There might be some new things in Europe - Si can tell us specifics if he'd like.
There are sure to be at least some small problems with an update this big - let us know if you see anything.
One thing I know about - the datacheck error list didn't make it into the DB, and I need to figure out why. Since that's the last part that gets added to the DB, everything else should have loaded properly.
The last update was run with the list file I sent you earlier this week, this one now has reverted everything to the previous version I sent a couple months ago...
Quote from: Jim on August 20, 2015, 10:43:19 PMThere might be some new things in Europe - Si can tell us specifics if he'd like.
A new A road near Liverpool, some French corrections to do with the system .csv files, and Greece and Slovakia brought up to date. It's all in the update page, other than Greco-Slovak minor tweaks like waypoint names and minor shaping.
QuoteThere are sure to be at least some small problems with an update this big - let us know if you see anything.
Most of the size of the update was the new systems, though Greece and Slovakia add quite a bit, especially Greece.
Quote from: Duke87 on August 21, 2015, 12:38:07 AM
The last update was run with the list file I sent you earlier this week, this one now has reverted everything to the previous version I sent a couple months ago...
Yours and two others were not on my regular computer, which just came back from repairs. I have them (but had forgotten to commit them to the repository until just now). I'm running a new update
in a few minutes that just completed. Let me know if all looks OK now.
Quote from: Jim on August 21, 2015, 07:40:55 AM
Quote from: Duke87 on August 21, 2015, 12:38:07 AM
The last update was run with the list file I sent you earlier this week, this one now has reverted everything to the previous version I sent a couple months ago...
Yours and two others were not on my regular computer, which just came back from repairs. I have them (but had forgotten to commit them to the repository until just now). I'm running a new update in a few minutes that just completed. Let me know if all looks OK now.
The re-do for my file worked.
But a residual issue on the just-repaired MT US 89 route file: the southernmost waypoint should be WY/MT, rather than MT/WY.
Quote from: Jim on August 19, 2015, 10:29:06 PM
I found and fixed a few bugs in the draft highway browser (the one in devel/hb.php). The "info windows" (the thought-bubble looking things) should now show up with all of the desired information when you either click on a waypoint icon on the map or the name of a waypoint in the table on the left. Hidden waypoints should now never have entries in the table or waypoint markers on the map.
I think "all of the desired information" is sometimes too much, for instance: http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=grc.a029.
7
Waypoint 14
Coords.: 40.531580°, 21.180770°The waypoint
name is displayed on the left but it's difficult to refer the data of the info window bubble to the data of the table.
I think all data should be displayed in the table. The waypoint column could be greyed to imply that it's less important/should not be used.
Quote from: Jim on August 19, 2015, 10:29:06 PMThanks to those who reported the problems and for everyone's patience until I was able to take a look.
You're welcome :).
What's the status of the front end, is anyone working on it?
I think the current site is not pretty but it's sufficient for me. I just miss a simple navigation to the most important pages (log file/stats, update list, browser and my map :D).
I use a simple txt file with links:
http://www.teresco.org/~terescoj/travelmapping/logs/
http://www.teresco.org/~terescoj/travelmapping/devel/updates.php
http://www.teresco.org/~terescoj/travelmapping/devel/hb.php
http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=AUT,BEL,CHE,CZE,DEU,DNK,ESP,FRA,HUN,ITA,LUX,NLD,POL,ROU,SWE,AB,BC,ON,QC,IL,MI&u=michih
Are the list files also accessible on the server? Link?
Quote from: michih on August 21, 2015, 03:51:24 PM
Are the list files also accessible on the server? Link?
I'll have more of a look at your suggestion on the HB later, but for now, I'll handle this last one. They're not on the web server, or even in the DB in a form that you could see them, but they are in GitHub for any and all to look at:
https://github.com/TravelMapping/UserData/tree/master/list_files (https://github.com/TravelMapping/UserData/tree/master/list_files)
I try to remember to push the ones people email me and put in my local copy back up to GitHub every time I run an update.
Some more changes from Si are now in with the update that just completed.
https://github.com/TravelMapping/HighwayData/pull/53 (https://github.com/TravelMapping/HighwayData/pull/53)
Quote from: Jim on August 21, 2015, 04:02:05 PM
Some more changes from Si are now in with the update that just completed.
Hmm, I have an error in my log file now:
Waypoint label(s) not found in line: HUN M3 HunKor 187It wasn't detected on 19th August (I have an offline copy) or with any previous update but the modification was already done on 24th July:
15-07-24 Hungary M3 hun.m003 Route extended at west end from exit 267 to exit 280
15-07-24 Hungary M3 hun.m003 Route truncated at east end from Hungaria Korut to exit 10Quite strange!
btw: M3 west end / east end is mistaken ;)
Quote from: michih on August 21, 2015, 04:30:32 PMHmm, I have an error in my log file now:
btw: M3 west end / east end is mistaken ;)
Fixed!
The problem came when I made sure that all the files in regions I'd brought up to date.
There's a few places where I added some hidden points so as to not break people's .list files, but didn't have them all in my local files.
Oh dear, that problem of things getting garbled that I mentioned before? It's happening again. Since I'm at home now, a screenshot:
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F4oEzmNV.png&hash=7d35cbac75e0bc1f0140b189906755690406e746)
See all those random red segments not connected to anything else? These are not roads I've clinched and they're not in my list file.
Oddly enough, in my log file (http://www.teresco.org/~terescoj/travelmapping/logs/duke87.log) the stats are all correct and routes show the correct parts clinched when viewed in the highway browser individually (example) (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?r=mo.us050&u=duke87)
Also, I observe that this problem only affects US and state routes. In every state I look at, the interstates all show correctly. In Canada, Quebec autoroutes appear to be immune from the problem as well, but the TCH and provincial systems in Ontario and New Brunswick have similar issues.
Quote from: Duke87 on August 21, 2015, 09:10:39 PM
Oh dear, that problem of things getting garbled that I mentioned before?
I get a nice-looking view when I bring up that same map at http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87 (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87)
Strangely enough it also gives me slightly different stats from your screen shot. I wonder if you happened to catch it right in the middle of a database update. See if the above URL after a force reload gives you a good map.
Anyway, my guess is that I'm again relying on something coming out of the DB in a particular order that I have not forced to be the case...
Just wanted to say thanks to all of you working on this project, and I am eagerly awaiting the debut to the general public. I've traveled roughly 15,000 miles of new roads in the past 9 months and am excited to update a new .list whenever you've got things in a place where it's open to the public again. I've been following the updates and I'm impressed. Really! Great work!
Quote from: Jim on August 21, 2015, 09:31:53 PM
Quote from: Duke87 on August 21, 2015, 09:10:39 PM
Oh dear, that problem of things getting garbled that I mentioned before?
I get a nice-looking view when I bring up that same map at http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87 (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87)
Aha! So maybe my problem is I've been missing a piece of the URL. When I go back to what I took a screenshot of, it's still borked, but your link works fine.
My link: http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=MO&u=duke87
Your link: http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87
If I keep "mapview.php" in there and go to other states, they all look correct.
Quote from: Duke87 on August 21, 2015, 09:59:10 PM
Quote from: Jim on August 21, 2015, 09:31:53 PM
Quote from: Duke87 on August 21, 2015, 09:10:39 PM
Oh dear, that problem of things getting garbled that I mentioned before?
I get a nice-looking view when I bring up that same map at http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87 (http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87)
Aha! So maybe my problem is I've been missing a piece of the URL. When I go back to what I took a screenshot of, it's still borked, but your link works fine.
My link: http://www.teresco.org/~terescoj/travelmapping/hbtest/?rg=MO&u=duke87
Your link: http://www.teresco.org/~terescoj/travelmapping/hbtest/mapview.php?rg=MO&u=duke87
If I keep "mapview.php" in there and go to other states, they all look correct.
Yes, you're getting the defunct version of the highway browser. I'll remove that old code...
Edit: the old URL now redirects to the new hb.php. Note that the rg= won't work on the new HB. That functionality was replaced by mapview.
Jim, before you go back to teaching, could you provide a general update regarding the active and in-development systems?
I'm curious how many of the current regions (countries and states/provinces) still don't have anyone actively updating them. Are they orphaned, or have the collaborators just not had the time/ability to master the GitHub updating process?
Beyond that, are the most complete in-development systems (IIRC, this includes AK, MT, NM, UT, VT, the KY 1001-1500 set, and the rest of the GBR A-roads) still undergoing peer-review? Is the plan still to wait until all the active systems are fully updated, or can these be activated earlier than that?
Quote from: mapcat on August 22, 2015, 09:50:20 AM
Beyond that, are the most complete in-development systems (IIRC, this includes AK, MT, NM, UT, VT, the KY 1001-1500 set, and the rest of the GBR A-roads) still undergoing peer-review? Is the plan still to wait until all the active systems are fully updated, or can these be activated earlier than that?
Just commenting on my own in-dev system on your list (AK), it wasn't peer-reviewed under the old system, and still needs some work to be ready for whatever review process we decide to follow under the new system. At least some of the other systems you listed have cleared peer review, but might need some touch-up work, such as for updates since they were reviewed.
I'm pretty much leaving it to the other collaborators to decide, as a group, when the in-dev systems are good to go. Activating them will just be a matter of a quick file edit and re-running the update process. As far as what I need to do to get this ready, I think it's the datacheck system mentioned elsewhere in the forum.
There's a list of who's claimed what on the main wiki page on the HighwayData repository: https://github.com/TravelMapping/HighwayData/wiki It might need a bit of updating but that's what's up.
Quote from: Jim on August 22, 2015, 10:39:00 AM
I'm pretty much leaving it to the other collaborators to decide, as a group, when the in-dev systems are good to go.
OK, thanks. Are you all having this discussion elsewhere? Seems the only talk about activating them in this forum is coming from the rest of the users.
QuoteThere's a list of who's claimed what on the main wiki page on the HighwayData repository: https://github.com/TravelMapping/HighwayData/wiki It might need a bit of updating but that's what's up.
Thanks. I've reached out to dfilpus via CHM, so I hope he's still intending to maintain the states he worked on previously.
Quote from: mapcat on August 22, 2015, 10:47:30 PM
Quote from: Jim on August 22, 2015, 10:39:00 AM
I'm pretty much leaving it to the other collaborators to decide, as a group, when the in-dev systems are good to go.
OK, thanks. Are you all having this discussion elsewhere? Seems the only talk about activating them in this forum is coming from the rest of the users
It's been here, I think. There's no urgent discussion yet because we know there are a few things we need to get past first (catchup on existing systems, datacheck, sources, etc.).
I share your hope that these will be able to activate soon.
The server that houses my domain went down or fell off the network at some point in the last hour or so. If whatever is causing the problem doesn't resolve itself, I'll check into it on Sunday, but likely not until late. So until the web server comes back, Travel Mapping is offline.
Quote from: Jim on August 23, 2015, 12:02:39 AMSo until the web server comes back, Travel Mapping is offline.
It's back :)
Quote from: michih on August 23, 2015, 02:50:44 AM
Quote from: Jim on August 23, 2015, 12:02:39 AMSo until the web server comes back, Travel Mapping is offline.
It's back :)
Yes, looks like it was a network glitch, and (fortunately) nothing that was my fault or problem to fix.
Quote from: rschen7754 on August 11, 2015, 01:42:20 PM
What still needs to be done for California and/or is it something that others can assist?
One way for others to help out is to keep an eye out for things that might need to be updated on the state routes, including new interchanges, significant realignments, and new, split, truncated, or decommissioned routes (like the unbuilt gap in CA 39 between La Habra and Covina, the CA 78 reroute in Brawley, CA 86S folded into CA 86, and CA 225 in Santa Barbara effectively decommissioned), and post them on a California-specific topic in the Pacific Southwest part of the AARoads forum. If you got access to the old CHM forum before it stopped taking new users, you can post there too, but no assurance how long it will stay alive. Daniel Faigin's site seems a pretty good resource for me on some such issues, but it doesn't cover everything. CHM's Highway Browser, which still works for now, is a good guide to how the CA state routes are currently mapped.
New relinquishments, too, though I suspect we'll find a way to overlook most or all of them (one of the issues we'll need to nail down before major work resumes on the system).
Speaking of state route updates, is there a place where these should be noted? (I don't have the ability to post in the CHM forum).
I noticed in the CHM forum there is a post about the decommissioning of OH 238 and the realignment of OH 38. http://clinched.s2.bizhat.com/clinched-ftopic2383.html&highlight=238 (http://clinched.s2.bizhat.com/clinched-ftopic2383.html&highlight=238)
I can confirm that OH 238 no longer exists and that the new alignment of OH 38 follows the entirety of what was OH 238 to the junction with US 62/OH 3. There was still one shield on the old section og NB OH 38 just outside of Washington Court House, but all others appear to have been removed now that that segment has reverted to county control.
This issue looks to already be noted, so I imagine it will show up as updates to existing systems make it into the new database.
Update just complete with my minor tweaks in New York and a few new .list entries. However, stats might look a lot different as I also fixed a typo in the I-40 Business Spur in Winslow, Arizona. It had a point that was off by 100 degrees of longitude, which resulted in this 1 1/3 mile spur showing up as several thousand miles long. A big argument in favor of my next focus with the project being on datachecks!
Update just complete with lots of Europe changes from Si, and a couple of route renames from Oscar, and one or two .list file submissions.
Quote from: mapcat on August 22, 2015, 09:50:20 AM
Beyond that, are the most complete in-development systems (IIRC, this includes AK, MT, NM, UT, VT, the KY 1001-1500 set, and the rest of the GBR A-roads) still undergoing peer-review? Is the plan still to wait until all the active systems are fully updated, or can these be activated earlier than that?
I was doing Utah and thought it was ready to go. We'd addressed all the peer review issues AFAIK.
Quote from: NickCPDX on August 28, 2015, 02:30:05 PMI was doing Utah and thought it was ready to go. We'd addressed all the peer review issues AFAIK.
Anyone want to do some double checks?
Nick - are you happy to maintain UT? I've been working on the assumption that you would. NV, ID and AZ are yours if you want them also.
Quote from: english si on August 28, 2015, 02:45:35 PM
Quote from: NickCPDX on August 28, 2015, 02:30:05 PMI was doing Utah and thought it was ready to go. We'd addressed all the peer review issues AFAIK.
Anyone want to do some double checks?
Also, if he hasn't done so already, Nick should check for any new state routes, or other changes requiring updates to existing route files, after UT was peer-reviewed. A good idea for all the in-dev systems, but especially in a high-growth state like Utah.
Has anybody talked to dfilpus about this lately? I know he still reads the 'old' forums and the forums here, yet I haven't seen him post yet in here in this section about the project move.
Wow. I coulda sworn USAUT was already live.
I could have sworn usanm was live.
If there's not any objections by Tuesday, usanm and usaut are going live.
usamt, usavt, gbna1, gbna6, gbna8 and gbna9 are very close.
Quote from: english si on August 29, 2015, 03:27:49 AM
I could have sworn usanm was live.
If there's not any objections by Tuesday, usanm and usaut are going live.
usamt, usavt, gbna1, gbna6, gbna8 and gbna9 are very close.
usanm needs some touch-up work and perhaps updates before it goes live, some of which were flagged as open items on the CHM forum:
-- possibly adding back NM 497 in Deming (an on-again, off-again route that was signed last I was there in 2013)
-- removing references in route files to unsigned routes we're not mapping (for example, NM 11 route file has a waypoint for NM 332, which is not in our DB)
-- some discussion on the aaroads forum suggesting (I'm not sure how convincingly) that there might be some new state routes in the Albuquerque area; as with Utah, this in-dev system has been on hiatus long enough for new routes to pop up in the meantime
It's best that we take care of this stuff before activation, rather than catch up to it later and have to make a bunch of Updates entries on a new system.
Quote from: yakra on August 29, 2015, 02:52:58 AM
Wow. I coulda sworn USAUT was already live.
You can view it in the draft HB (ditto some of the other in-dev systems closest to activation), but you can't yet be credited for mileage on that system.
I know NM's my responsbility, but if anyone has a chance to investigate and make the changes needed to get it ready, I would appreciate the help.
I think we should make sure any system to be activated has a clean datacheck before it happens. I'll see if I can make some small improvements to the datacheck page to make it easier to use. For now, "Find in Page" is your friend.
Most of the datacheck errors showing up now in usanm and usaut are very likely FPs, but should be checked out. There are also a few others, like a label missing a right paren in UT 19 (which I fixed as I type this, so it will no longer be an error on the next site update) that might require fixes.
Hello everyone. I was a user on CHM and I am glad to see this new project coming online! I would like to volunteer to help get the SC State highways included in this project. I have looked at the data files in GitHub and have a general idea what is required to get things going. Does anyone have some tips on how to best construct/maintain these files (i.e. use certain links in Openstreetmap, set points, copy/paste)?
Quote from: pnrrth on August 29, 2015, 08:43:38 AM
Hello everyone. I was a user on CHM and I am glad to see this new project coming online! I would like to volunteer to help get the SC State highways included in this project. I have looked at the data files in GitHub and have a general idea what is required to get things going. Does anyone have some tips on how to best construct/maintain these files (i.e. use certain links in Openstreetmap, set points, copy/paste)?
We haven't yet developed all the tools needed for new team members to draft new route files and edit existing files. Most important is a waypoint editor similar to CHM's, which made route file creation and editing much easier. Also, a new instruction manual to help get new team members up to speed. CHM's manual still required a lot of mentoring and hand-holding for new team members, which we hope a new manual can reduce.
The waypoint editor is one of several things we need to do at the software "front end", in addition to catching up with updates to existing route systems (we're still busy with that process), to make Travel Mapping a fully-functional site, before we start adding new team members and having them develop new route systems.
Quote from: rickmastfan67 on August 28, 2015, 09:04:03 PM
Has anybody talked to dfilpus about this lately? I know he still reads the 'old' forums and the forums here, yet I haven't seen him post yet in here in this section about the project move.
I PM'ed him in CHM and asked if he was planning on maintaining his states on TM as well. His reply was essentially "I don't do GitHub" so it's unlikely he will continue without some additional prompting. There are at least two items in the usaoh set that need attention (OH 38/238 and OH 762) and who knows what with the others he maintained.
I formally handed over VT to froggie a little while back, after my latest VT pull request was merged. I believe the only potential stumbling block to it going live is a (proposed? pending? completed?) reroute of VT100 back onto VT100His, with the bypass to be redesignated as VT100Trk. Froggie, what's your opinion on this?
I don't think there should be any datacheck errors, but it's worth a look-over.
Quote from: mapcat on August 29, 2015, 10:39:20 AM
Quote from: rickmastfan67 on August 28, 2015, 09:04:03 PM
Has anybody talked to dfilpus about this lately? I know he still reads the 'old' forums and the forums here, yet I haven't seen him post yet in here in this section about the project move.
I PM'ed him in CHM and asked if he was planning on maintaining his states on TM as well. His reply was essentially "I don't do GitHub" so it's unlikely he will continue without some additional prompting.
That's how I felt at first, but slowly stumbled my way through trial-and-error to manage basic GitHub functions. And I'm pretty high on the technophobia scale (for example, I don't do Facebook, and am still using a dumb flip-phone rather than a smartphone).
I'm tempted to patch in the most major updates needed for Dave's other jurisdictions (most notably the completion of I-485, as part of getting us caught up on the Interstate routes), like I did to take over Quebec from Tim and update MD 200 in another of Tim's jurisdictions yet to be reassigned. But aside from my being busy with other stuff, that's no substitute for someone keeping up with lesser updates, including the ones not reported by users.
Quote from: mapcat on August 29, 2015, 10:39:20 AM
Quote from: rickmastfan67 on August 28, 2015, 09:04:03 PM
Has anybody talked to dfilpus about this lately? I know he still reads the 'old' forums and the forums here, yet I haven't seen him post yet in here in this section about the project move.
I PM'ed him in CHM and asked if he was planning on maintaining his states on TM as well. His reply was essentially "I don't do GitHub" so it's unlikely he will continue without some additional prompting. There are at least two items in the usaoh set that need attention (OH 38/238 and OH 762) and who knows what with the others he maintained.
He also had the Virginia State Routes very far along, enough that he had me proofread and offer input on the waypoints he had for the complete set of routes.
If he is really not going to continue on I am willing to do Virginia (hopefully be able to transfer over work already completed but if I had to, do it from scratch) but I would be a newbie in every sense of the term for this project...
Mike
Quote from: Mapmikey on August 29, 2015, 02:33:46 PM
If he is really not going to continue on I am willing to do Virginia (hopefully be able to transfer over work already completed but if I had to, do it from scratch) but I would be a newbie in every sense of the term for this project...
There's also North Carolina, and other states currently unassigned (such as Maryland), you've been exploring lately and in some cases adding to your website. I encourage you to think big.
I think we can have people maintaining highway systems who are unable or unwilling to work with GitHub, but someone who does GitHub would need to be willing to accept CHM-style updates from them.
Quote from: Jim on August 29, 2015, 03:58:03 PM
I think we can have people maintaining highway systems who are unable or unwilling to work with GitHub, but someone who does GitHub would need to be willing to accept CHM-style updates from them.
I could help out Dave with that if he wants to do it. I've figured out the 'basic' copy/paste interface in the web browser for my stuff. It wouldn't be too hard to just have him send me copies of the 'updated' routes that were never put onto the old site and I could then do the copy/paste for him to update them. I'd just want him to at least write the update entries for me in the current standard. Hopefully he reads this and posts here in this section about it.
A couple things that didn't get responses here.
Quote from: michih on August 21, 2015, 03:51:24 PM
What's the status of the front end, is anyone working on it?
Not that I'm aware of.
QuoteAre the list files also accessible on the server? Link?
Not on the server currently hosting the maps and logs. But they're all there in GitHub, available for all to see:
https://github.com/TravelMapping/UserData/tree/master/list_files (https://github.com/TravelMapping/UserData/tree/master/list_files)
Click on any of the files there and you get a page with that .list file. I try to remember to commit and push up any .list files I receive by email each time I run an update.
Site update just completed with I-99 New York and a couple other NY fixes, some changes to the draft Alaska state highways from Oscar, and several .list files received in the last few days.
I'm not sure if I'll have time to run another update before the holiday weekend, but keep submitting pull requests with highway data updates and sending .list updates via email or pull requests.
I don't know if when/if you're going to get to the point of adding new systems to the road, but I'd be very interested in seeing Indiana's state highways system added. I don't have anything to offer in the way of programming skills, but I have pretty good knowledge of the system that I could share to whomever is doing the work.
Quote from: cabiness42 on August 31, 2015, 08:56:51 AM
I don't know if when/if you're going to get to the point of adding new systems to the road, but I'd be very interested in seeing Indiana's state highways system added. I don't have anything to offer in the way of programming skills, but I have pretty good knowledge of the system that I could share to whomever is doing the work.
A draft of Indiana's state highways is in the highway data repository, but there are some steps we need to go through before it is ready to go. I'm sure your help will be very valuable checking over what we have plotted as it undergoes review before becoming part of our active data.
Quote from: yakraI formally handed over VT to froggie a little while back, after my latest VT pull request was merged. I believe the only potential stumbling block to it going live is a (proposed? pending? completed?) reroute of VT100 back onto VT100His, with the bypass to be redesignated as VT100Trk. Froggie, what's your opinion on this?
Hasn't been signed yet. I'll deal with it when it happens. Otherwise, I believe you and I are in full agreement regarding Vermont.
Quote from: MapmikeyIf he is really not going to continue on I am willing to do Virginia (hopefully be able to transfer over work already completed but if I had to, do it from scratch) but I would be a newbie in every sense of the term for this project...
I can help Mike in this endeavor. I'm sure Oscar would be willing as well.
Is there a labelsinuse.php equivalent for TravelMapping yet?
Also, I think it would be a good idea to have an index to all the current TravelMapping pages together in one place. Even a simple HTML file (here (http://www.teresco.org/~terescoj/travelmapping/), maybe?) would suffice. Right now, if I want a URL, I either search my browser history or hunt around the forums here. It's a bit tough to keep track of what does/doesn't exist, and where it all is, ATM.
Quote from: yakra on August 31, 2015, 12:47:03 PM
Is there a labelsinuse.php equivalent for TravelMapping yet?
There's a labelsinuse log, in the same directory as the stats/error logs generated off users' list files.
Quote from: yakra on August 31, 2015, 12:47:03 PM
Is there a labelsinuse.php equivalent for TravelMapping yet?
Also, I think it would be a good idea to have an index to all the current TravelMapping pages together in one place. Even a simple HTML file (here (http://www.teresco.org/~terescoj/travelmapping/), maybe?) would suffice. Right now, if I want a URL, I either search my browser history or hunt around the forums here. It's a bit tough to keep track of what does/doesn't exist, and where it all is, ATM.
I keep all the various pages in bookmarks at home. I also have a link to my NY map embedded in a comment on my website's about page.
Quote from: oscar on August 31, 2015, 12:57:29 PM
There's a labelsinuse log, in the same directory as the stats/error logs generated off users' list files.
http://www.teresco.org/~terescoj/travelmapping/logs/labelsinuse.log gets me a 404.
Quote from: yakra on August 31, 2015, 01:45:18 PM
Quote from: oscar on August 31, 2015, 12:57:29 PM
There's a labelsinuse log, in the same directory as the stats/error logs generated off users' list files.
http://www.teresco.org/~terescoj/travelmapping/logs/labelsinuse.log gets me a 404.
http://www.teresco.org/~terescoj/travelmapping/logs/pointsinuse.log (http://www.teresco.org/~terescoj/travelmapping/logs/pointsinuse.log)
"Labels in use" makes more sense, though, so I should rename it some time
Quote from: english si on August 28, 2015, 02:45:35 PM
Quote from: NickCPDX on August 28, 2015, 02:30:05 PMI was doing Utah and thought it was ready to go. We'd addressed all the peer review issues AFAIK.
Anyone want to do some double checks?
Nick - are you happy to maintain UT? I've been working on the assumption that you would. NV, ID and AZ are yours if you want them also.
I'll take NV and AZ. Reluctant to do ID because I think I've driven on one Idaho state highway in my life.
Quote from: froggie on August 31, 2015, 12:00:56 PM
I can help Mike in this endeavor. I'm sure Oscar would be willing as well.
I appreciate the future tutelage.
I have no problem taking over maintenance of VA, NC and MD if no one else is on those. Someone else offered to create SC and I am willing to proofread that if needed (a revamped SC Hwys page is on the way in the next couple months from me, so my knowledge has been resurrected). If I am not creating SC I could probably maintain PA if that remains vacant.
Mike
Quote from: oscar on August 29, 2015, 10:15:13 AM
Quote from: pnrrth on August 29, 2015, 08:43:38 AM
Hello everyone. I was a user on CHM and I am glad to see this new project coming online! I would like to volunteer to help get the SC State highways included in this project. I have looked at the data files in GitHub and have a general idea what is required to get things going. Does anyone have some tips on how to best construct/maintain these files (i.e. use certain links in Openstreetmap, set points, copy/paste)?
We haven't yet developed all the tools needed for new team members to draft new route files and edit existing files. Most important is a waypoint editor similar to CHM's, which made route file creation and editing much easier. Also, a new instruction manual to help get new team members up to speed. CHM's manual still required a lot of mentoring and hand-holding for new team members, which we hope a new manual can reduce.
The waypoint editor is one of several things we need to do at the software "front end", in addition to catching up with updates to existing route systems (we're still busy with that process), to make Travel Mapping a fully-functional site, before we start adding new team members and having them develop new route systems.
So if I wanted to add a couple truck routes in SD, I should talk to someone?
Quote from: Mapmikey on August 31, 2015, 07:49:38 PM
Quote from: froggie on August 31, 2015, 12:00:56 PM
I can help Mike in this endeavor. I'm sure Oscar would be willing as well.
I appreciate the future tutelage.
I have no problem taking over maintenance of VA, NC and MD if no one else is on those. Someone else offered to create SC and I am willing to proofread that if needed (a revamped SC Hwys page is on the way in the next couple months from me, so my knowledge has been resurrected). If I am not creating SC I could probably maintain PA if that remains vacant.
Mike
Mike, I would be happy to help with the SC Highways. Based on some responses to my original post offering to help with this endeavor, I looked into getting the Waypoint Editor to work on my home PC (one issue sited was that there wasn't good tooling available so I got the code for the wpteditor from github). I was able to do so and played around with creating .wpt2 files for several state highways. Before going too far with this, however I would like to ensure that I am following correct standards for naming waypoints (hidden waypoints, concurrencies, default direction that should be taken -- North to South or east to west, etc)
Tim
Quote from: SD Mapman on September 01, 2015, 11:13:23 PM
So if I wanted to add a couple truck routes in SD, I should talk to someone?
We added last month a US 85 Truck in Lead, and updated a few others in SD. http://www.teresco.org/~terescoj/travelmapping/devel/updates.php We'll also be adding in the next few days US 16 and US 385 truck routes in Hill City.
If there are more, please flag them for us, either in this part of the forum or this forum's Central States board (I suggest both, especially if they're new routes of more general interest, not just old routes we've missed). You're also a registered user on the old CHM forum, which we still watch for new posts while it lasts, so you can mention them over there too.
Quote from: oscar on September 02, 2015, 03:11:49 AM
Quote from: SD Mapman on September 01, 2015, 11:13:23 PM
So if I wanted to add a couple truck routes in SD, I should talk to someone?
We added last month a US 85 Truck in Lead, and updated a few others in SD. http://www.teresco.org/~terescoj/travelmapping/devel/updates.php We'll also be adding in the next few days US 16 and US 385 truck routes in Hill City.
If there are more, please flag them for us, either in this part of the forum or this forum's Central States board (I suggest both, especially if they're new routes of more general interest, not just old routes we've missed). You're also a registered user on the old CHM forum, which we still watch for new posts while it lasts, so you can mention them over there too.
OK, here's the CHM topic: http://clinched.s2.bizhat.com/clinched-ftopic2250.html (http://clinched.s2.bizhat.com/clinched-ftopic2250.html) They've been around for years.
Quote from: SD Mapman on September 02, 2015, 10:06:35 AM
OK, here's the CHM topic: http://clinched.s2.bizhat.com/clinched-ftopic2250.html (http://clinched.s2.bizhat.com/clinched-ftopic2250.html) They've been around for years.
Good, when we do the next update, we'll be current in SD.
Good to see lots of updates coming in through GitHub this week. I might be able to run an update tonight but if not, I'll definitely make time tomorrow afternoon or evening.
Site update is complete, bringing in some highway data updates from during the past week. Let me know if you see any trouble. A few files I had to fix to run the update will be pushed back to the master on GitHub tonight.
I have Wisconsin I-41 and related files ready to go but I have one question: Do I need to modify files for all the highways that intersect 41 between Green Bay and Milwaukee so that the waypoint is I-41 with US41 as a hidden name?
Quote from: Jeff Morrison on September 04, 2015, 10:45:10 PM
Do I need to modify files for all the highways that intersect 41 between Green Bay and Milwaukee so that the waypoint is I-41 with US41 as a hidden name?
That would be recommended, especially if they removed the US-41 at the on-ramps themselves and just have I-41 shields now.
Quote from: rickmastfan67 on September 04, 2015, 11:01:17 PM
Quote from: Jeff Morrison on September 04, 2015, 10:45:10 PM
Do I need to modify files for all the highways that intersect 41 between Green Bay and Milwaukee so that the waypoint is I-41 with US41 as a hidden name?
That would be recommended, especially if they removed the US-41 at the on-ramps themselves and just have I-41 shields now.
I'll put in a pull request to add Jeff's files to the GitHub master, once I synch his Interstate and bannered US routes .csv file changes with the ones yakra just made down in Arkansas (we just happened to be working on the same files at roughly the same time). Label changes for routes intersecting the part of I-41 that once was non-Interstate can be done separately and later.
I would leave alone labels for intersections with the parts of I-41 west or south of Milwaukee. Those segments are concurrent with I-94 or I-894, and the labels in intersecting route files already include one of those I- numbers.
Hi Jim, et al,
Driving in Maine for my job, I decided one day to take "that Haynesville Road" (trucker song "Tombstone Every Mile"), US 2A, to get up to Easton for a load of McCain fries. I planned to clinch it, but when I got to Houlton, I found that it continued on Bangor St instead of bearing right to meet US1/US2 at the corner as it shows on CHM/TrvMap. Any chance to update that, or do you need more info?
Thanks,
-Ed S.
I'll look into it.
MDOT GIS shapefiles have US2A bearing right onto Military St. The most sensible route to have eastbound traffic link up to the parent route, IMO.
GMSV: Nothing eastbound approaching the Bangor/Military split, though this may have changed by the time you passed thru. Westbound Military St has a single-headed arrow for US2A (https://www.google.com/maps/place/Houlton,+ME/@46.123442,-67.844184,3a,67.2y,274.61h,83.39t/data=!3m4!1e1!3m2!1sBANweKlvmHZ8uQZHbcBMEQ!2e0!4m2!3m1!1s0x4ca4c1923717c66f:0xc021d6deb8bf68cf) instead of a double-headed one. While there's plenty of signage at US1/2 & Bangor, there's also a US2A sign on westbound Military (https://www.google.com/maps/place/Houlton,+ME/@46.123937,-67.841328,3a,66.8y,252.09h,86.84t/data=!3m4!1e1!3m2!1sylBB-3UcSDa06SiGTo0_yw!2e0!4m2!3m1!1s0x4ca4c1923717c66f:0xc021d6deb8bf68cf). Just enough ambiguity added into the situation, as I see it.
Signage can be sloppy at times in Urban Compact Municipalities. For example, back before it was moved onto I-295 in 2007, US1 in Portland was signed on both Valley St and Saint John St. Elsewhere, the northbound alignment was signed to the west of the southbound alignment, taking Forest Ave all the way to Park Ave. I took this latter example as an effort to guide traffic a bit closer to the central business district. I see the signage at Military & US1/2 similarly guiding traffic to/from the CBD. Less as gospel. (MDOT likes to omit [TO] signs.) Thus I agree with Cameron Kaiser (http://www.floodgap.com/roadgap/me/r?2a)'s assessment that the signs "are probably indicating the through route but not necessarily the actual alignment."
I'm going to go with what's in the shapefiles and leave this route as-is.
A site update has just completed with lots of upper midwest updates including the addition of I-41. Thanks to Jeff for doing them and Oscar for getting it all into GitHub. A number of .list file updates are also included. See the updates page for details of newsworthy changes.
A site update has been run with lots of Texas updates, including new interstates there, and lots of Europe changes. Plus, .list updated received since the weekend. See the updates page for details of newsworthy changes.
Site update just complete with some more Europe and Texas, and a couple .list submissions.
Edit 10:30 PM EDT: now some Oklahoma, too.
Quote from: Jim on September 09, 2015, 11:10:13 PM
A site update has been run with lots of Europe changes.
What's that?
15-09-10 Switzerland A821 che.a821 (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=che.a821) New Route
The 10 new or updated .list files have been processed - welcome to the 8 new users!
Fun fact: the .sql file that is generated by the site update program to populate the database is now 1,982,562 lines long. Which update will push it past the 2,000,000 mark?
The very good news: even as the data grows, it still takes only about 5 minutes to run the program and under a minute each for file transfer and database repopulation. Scalability so far is better than I hoped.
Quote from: michih on September 11, 2015, 12:16:03 PM
What's that?
15-09-10 Switzerland A821 che.a821 (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=che.a821) New Route
Seems to be corrected to A861.
My log file (http://www.teresco.org/~terescoj/travelmapping/logs/michih.log) contains:
System deua by region:
CHE: 0.00 of 0.53 mi (0.0%)
DEU: 7809.47 of 8035.38 mi (97.2%)0.53 mi of the German Autobahn network are in the Switzerland now?
btw: Thanks for the European updates :)
Quote from: michih on September 12, 2015, 04:10:44 AM0.53 mi of the German Autobahn network are in the Switzerland now?
What else would you consider that route? All the hobbyist sites consider it an extension of the German road to the north. I'm very open to renaming it.
Quote from: english si on September 12, 2015, 04:17:12 AM
Quote from: michih on September 12, 2015, 04:10:44 AM0.53 mi of the German Autobahn network are in the Switzerland now?
What else would you consider that route? All the hobbyist sites consider it an extension of the German road to the north. I'm very open to renaming it.
I would call it A861 or Zubringer Rheinfelden as part of the Swiss network because the road is in the Switzerland! It's not an extraterritorial road but the Swiss traffic regulation is in force there.
Quote from: michih on September 12, 2015, 10:33:35 AMI would call it A861 or Zubringer Rheinfelden as part of the Swiss network because the road is in the Switzerland! It's not an extraterritorial road but the Swiss traffic regulation is in force there.
If it's A861, then it's part of the German numbering system and thus part of deua. cf pa.ny017, etc. It's in Switzerland in TM by virtue of being che.a861!
Zubringer Rheinfelden in eursf makes sense - I call it that.
At the rate I'm getting through the files, Germany ought to be brought up to date by the end of tomorrow!
Quote from: english si on September 12, 2015, 10:55:39 AMAt the rate I'm getting through the files, Germany ought to be brought up to date by the end of tomorrow!
Cool. I already clinched the new A4, A21, A26 and A66 sections :D.
Poland will be a challenge.
I've made pull requests for Germany and Austria, leaving just Sweden, Portugal (which I've mostly done, but need to check whether or not a load of the A roads are actually signed) and Poland to bring up-to-date in Europe.
A site update is just complete with several new .list files and lots more Europe updates from Si.
Quote from: yakra on September 05, 2015, 03:15:35 PM
MDOT GIS shapefiles have US2A bearing right onto Military St. The most sensible route to have eastbound traffic link up to the parent route, IMO.
GMSV: Nothing eastbound approaching the Bangor/Military split, though this may have changed by the time you passed thru. Westbound Military St has a single-headed arrow for US2A (https://www.google.com/maps/place/Houlton,+ME/@46.123442,-67.844184,3a,67.2y,274.61h,83.39t/data=!3m4!1e1!3m2!1sBANweKlvmHZ8uQZHbcBMEQ!2e0!4m2!3m1!1s0x4ca4c1923717c66f:0xc021d6deb8bf68cf) instead of a double-headed one. While there's plenty of signage at US1/2 & Bangor, there's also a US2A sign on westbound Military (https://www.google.com/maps/place/Houlton,+ME/@46.123937,-67.841328,3a,66.8y,252.09h,86.84t/data=!3m4!1e1!3m2!1sylBB-3UcSDa06SiGTo0_yw!2e0!4m2!3m1!1s0x4ca4c1923717c66f:0xc021d6deb8bf68cf). Just enough ambiguity added into the situation, as I see it.
Signage can be sloppy at times in Urban Compact Municipalities. For example, back before it was moved onto I-295 in 2007, US1 in Portland was signed on both Valley St and Saint John St. Elsewhere, the northbound alignment was signed to the west of the southbound alignment, taking Forest Ave all the way to Park Ave. I took this latter example as an effort to guide traffic a bit closer to the central business district. I see the signage at Military & US1/2 similarly guiding traffic to/from the CBD. Less as gospel. (MDOT likes to omit [TO] signs.) Thus I agree with Cameron Kaiser (http://www.floodgap.com/roadgap/me/r?2a)'s assessment that the signs "are probably indicating the through route but not necessarily the actual alignment."
I'm going to go with what's in the shapefiles and leave this route as-is.
Hi Yakra,
Thanks for verifying. I had another run that took me through Houlton in the last week or so (drove from Calais to Easton), and to make sure I had the road clinched, I drove straight onto Military St then made the tight right turn onto Bangor, then left back onto US1/US2. FWIR, I can't say for sure if I saw a sign heading eastbound to that intersection. I went with what we had here. I don't plan to take the route again anytime soon. ;-)
Regards,
-Ed S
Quote from: english si on September 17, 2015, 07:29:33 AM
I've made pull requests for Germany and Austria
Thank you! :clap:
Some notes:
Germany E422 wrong link
a422 -->
e422
Germany E42 wrong link
a042 --> e42
Germany E36 deu.e26 wrong link e
26 --> e
36
(UK) England A5115 Date missing
What's new? Links do not work:
Austria A12 (Landecker Tunnel) aut.a012lan New Route
Austria A13 (Innsbruck) aut.a013inn New Route
Austria A14 (Bregenz) aut.a014bre New Route
Austria A23 (Inzersdorf) aut.a023inz New Route
Austria A2 (Klagenfurt) aut.002kla Route extended at east end from L77 to B91 wrong link "a" missing; are you sure that this part is A2, source?
The new 1.6km A30 section in Bad Oeynhausen is still missing (opened in March 2014).
Quote from: michih on September 17, 2015, 04:16:17 PM
Quote from: english si on September 17, 2015, 07:29:33 AM
I've made pull requests for Germany and Austria
Thank you! :clap:
Some notes:
Germany E422 wrong link a422 --> e422
Germany E42 wrong link a042 --> e42
Germany E36 deu.e26 wrong link e26 --> e36
(UK) England A5115 Date missing
What's new? Links do not work:
Austria A12 (Landecker Tunnel) aut.a012lan New Route
Austria A13 (Innsbruck) aut.a013inn New Route
Austria A14 (Bregenz) aut.a014bre New Route
Austria A23 (Inzersdorf) aut.a023inz New Route
Austria A2 (Klagenfurt) aut.002kla Route extended at east end from L77 to B91 wrong link "a" missing; are you sure that this part is A2, source?
The new 1.6km A30 section in Bad Oeynhausen is still missing (opened in March 2014).
I just pulled in and ran an update with changes Si submitted for these last night.
Quote from: Jim on September 18, 2015, 07:38:01 AMI just pulled in and ran an update with changes Si submitted for these last night.
Thanks :). My questions are clarified too.
Quote from: oscar on August 28, 2015, 03:17:15 PM
Quote from: english si on August 28, 2015, 02:45:35 PM
Quote from: NickCPDX on August 28, 2015, 02:30:05 PMI was doing Utah and thought it was ready to go. We'd addressed all the peer review issues AFAIK.
Anyone want to do some double checks?
Also, if he hasn't done so already, Nick should check for any new state routes, or other changes requiring updates to existing route files, after UT was peer-reviewed. A good idea for all the in-dev systems, but especially in a high-growth state like Utah.
One thing to check for, on all in-dev systems: whether there have been U.S. routes changes that affect intersecting state routes, while a draft system was on a long hold. I'm coming across what may be some such changes in my double-check (still underway) of Jim's New Mexico route set. It would be good to make sure we're up-to-date on the existing systems in a state, before activating a new state route system there.
Quote from: oscar on September 19, 2015, 10:33:11 AMOne thing to check for, on all in-dev systems: whether there have been U.S. routes changes that affect intersecting state routes, while a draft system was on a long hold. I'm coming across what may be some such changes in my double-check (still underway) of Jim's New Mexico route set. It would be good to make sure we're up-to-date on the existing systems in a state, before activating a new state route system there.
This is an important point. Before I drafted the usanm set, I updated and otherwise fixed up the existing systems. Of course, that was more than three years ago now with the delays and eventual dormancy of CHM, so I'm not surprised Oscar is finding so many things.
Another important point is that anyone can take on the job of prepping an in-dev system for activation, if the person who drafted the set is unable to do so for whatever reason. I do think any such effort should be "claimed" here in this forum or in our new forum when it comes online to avoid redundant work.
So with the Wahoo bypass now open,
http://fremonttribune.com/news/local/wahoo-bypass-is-scheduled-to-open-tuesday/article_3f3c1f90-8562-5332-9f0d-5d68171d4961.html (http://fremonttribune.com/news/local/wahoo-bypass-is-scheduled-to-open-tuesday/article_3f3c1f90-8562-5332-9f0d-5d68171d4961.html)
does that necessitate a reroute of US 77 and NE 92?
Quote from: SD Mapman on September 20, 2015, 12:16:24 AM
So with the Wahoo bypass now open,
http://fremonttribune.com/news/local/wahoo-bypass-is-scheduled-to-open-tuesday/article_3f3c1f90-8562-5332-9f0d-5d68171d4961.html (http://fremonttribune.com/news/local/wahoo-bypass-is-scheduled-to-open-tuesday/article_3f3c1f90-8562-5332-9f0d-5d68171d4961.html)
does that necessitate a reroute of US 77 and NE 92?
Thanks! I was waiting for confirmation that it was open.
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.
Quote from: Jim on September 20, 2015, 11:01:30 PM
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/ (http://www.dot.nd.gov/travel-info-v2/) (It won't let me save the location, sorry)
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?
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/dotnet2/news/docs/2014releases/20141028-watfordbypasses.pdf)
http://www.dot.nd.gov/divisions/planning/docs/highwayinfo/williston.pdf (http://www.dot.nd.gov/divisions/planning/docs/highwayinfo/williston.pdf)
Quote from: yakra on September 21, 2015, 02:22:53 AM
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. :-)
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.
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
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.
Quote from: Jim on October 15, 2015, 08:47:39 PM
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.
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.
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. :cool:
Quote from: bejacob on October 18, 2015, 01:05:38 PMAny 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. :cool:
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 (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.
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".
Quote from: vdeane on October 18, 2015, 03:42:01 PM
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.
Quote from: Jim on October 18, 2015, 04:20:41 PM
Quote from: vdeane on October 18, 2015, 03:42:01 PM
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.
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...?
Quote from: wphiii on October 20, 2015, 10:39:34 AM
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.
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.
Quote from: Zeffy on October 20, 2015, 08:49:04 PM
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.
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.
Quote from: Jim on October 24, 2015, 08:51:20 AM
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. ;-)
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.
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.
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!
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.
Quote from: Jim on November 11, 2015, 11:03:14 PM
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).
^^ As did I, I wanted green E roads and red A roads and what I got was black E/A roads (except south Wales - but not the north - has blueish clinched A roads until you zoom in, and then they become black)
http://tm.teresco.org/hbtest/mapviewt.php?rg=WLS&u=si404&colors=eure:rgb(0,128,0)rgb:(0,255,0);gbna:rgb(255,0,0)rgb:(128,0,0)
Quote from: english si on November 12, 2015, 03:23:43 AM
^^ As did I, I wanted green E roads and red A roads and what I got was black E/A roads (except south Wales - but not the north - has blueish clinched A roads until you zoom in, and then they become black)
http://tm.teresco.org/hbtest/mapviewt.php?rg=WLS&u=si404&colors=eure:rgb(0,128,0)rgb:(0,255,0);gbna:rgb(255,0,0)rgb:(128,0,0)
You need colons also between the two rgb specifications for each system. That's how I parse them. You can use any CSS-style color specification, so if you prefer the #ff0000 style that should work (though I have not tried). When I added the colons, I see your map in red and green as you intended, but there is still some blue, because of a third system, gbnam, using its default blue coloring, being drawn atop some of the red and green.
Quote from: oscar on November 12, 2015, 12:01:30 AM
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?
Here's the JS code that sets the clinched and unclinched RGB values for the colors as assigned to systems in the systems.csv file.
var colorCodes = new Array();
colorCodes[0] = { name: "blue", unclinched: "rgb(100,100,255)", clinched: "rgb(0,0,255)" };
colorCodes[1] = { name: "brown", unclinched: "rgb(153,152,102)", clinched: "rgb(153,102,0)" };
colorCodes[2] = { name: "red", unclinched: "rgb(255,100,100)", clinched: "rgb(255,0,0)" };
colorCodes[3] = { name: "yellow", unclinched: "rgb(255,255,128)", clinched: "rgb(225,225,0)" };
colorCodes[4] = { name: "teal", unclinched: "rgb(100,200,200)", clinched: "rgb(0,200,200)" };
colorCodes[5] = { name: "green", unclinched: "rgb(100,255,100)", clinched: "rgb(0,255,0)" };
colorCodes[6] = { name: "magenta", unclinched: "rgb(255,100,255)", clinched: "rgb(255,0,255)" };
I think an option to leave unclinched out completely isn't hard, but is best done through a separate mechanism. I could add something like "clinchedonly=1" as an additional query string parameter.
I know that for now adding these ugly and confusing QS parameters is a little awkward. My hope is that by using that mechanism, however, it will be easier for someone to write a front end that generates the maps with all kinds of different options without worrying about how it all is done by the main map-drawing engine.
Re: one of Oscar's other comments. If anyone knows of a set of map tiles that would show only borders and land vs. water without the other clutter that comes from the tiles we have available so far, I think that would be a great option, and might eliminate the need for us to manage our own country/region/water boundaries and generate the old CHM-style maps. Of course, I'm happy to have the project support CHM-style maps also but it won't likely be a priority for me to work on myself.
Quote from: Jim on November 12, 2015, 07:49:16 AM
I think an option to leave unclinched out completely isn't hard, but is best done through a separate mechanism. I could add something like "clinchedonly=1" as an additional query string parameter.
Another possible mechanism here is to allow user-defined line thicknesses and/or opacities as well. Right now both of those are project-wide values, but if it's of interest, I might be able to allow users to, say, make unclinched route segments have a width of 0 or an opacity at or near 0, rendering them invisible. The down side of this approach is that the JS code to draw them all would still be produced and executed, whereas the "clinchedonly=1" would simply ignore them at the PHP level. But maybe customizable thicknesses and opacities are generally useful anyway.
Quote from: oscar on November 12, 2015, 12:01:30 AMI 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.
Quote from: Jim on November 12, 2015, 07:55:41 AMRe: one of Oscar's other comments. If anyone knows of a set of map tiles that would show only borders and land vs. water without the other clutter that comes from the tiles we have available so far, I think that would be a great option, and might eliminate the need for us to manage our own country/region/water boundaries and generate the old CHM-style maps. Of course, I'm happy to have the project support CHM-style maps also but it won't likely be a priority for me to work on myself.
I also prefer having a "simple" map but I think we already have a good one, Google Satellite without labels :).
Is it possible to preselect a map type via the url?
Quote from: michih on November 12, 2015, 12:40:42 PM
I also prefer having a "simple" map but I think we already have a good one, Google Satellite without labels :).
Is it possible to preselect a map type via the url?
No, but that shouldn't be hard. I'll put it on my list.
Thanks. I also tried the colors and I think it's working fine - no bugs.
But I think it's not easy to use because one has to define colors for each system. If I'd like to have all "first class category" roads of all states in a specific color, I have to put all systems to the url...
Quote from: michih on November 12, 2015, 03:26:21 PM
But I think it's not easy to use because one has to define colors for each system. If I'd like to have all "first class category" roads of all states in a specific color, I have to put all systems to the url...
Makes sense. It's not bad when looking at an individual state, province, or European country, but this is not a workable mechanism for, say, changing the colors of all state routes when viewing the entire US.
Quote from: Jim on November 12, 2015, 03:30:01 PM
Quote from: michih on November 12, 2015, 03:26:21 PM
But I think it's not easy to use because one has to define colors for each system. If I'd like to have all "first class category" roads of all states in a specific color, I have to put all systems to the url...
Makes sense. It's not bad when looking at an individual state, province, or European country, but this is not a workable mechanism for, say, changing the colors of all state routes when viewing the entire US.
It is pretty neat, though. I just had the colors in the wrong places.
My example (http://tm.teresco.org/hbtest/mapviewt.php?rg=SD&u=the_spui_ninja&colors=usai:rgb(1,2,3):rgb(62,97,117);usaus:rgb(105,190,40):rgb(105,190,40);usasd:rgb(0,21,50):rgb(0,21,50);usausb:rgb(155,161,162):rgb(155,161,162))
I used "first class category". I think categories already exist. There's tier 1 to 5 (https://github.com/TravelMapping/HighwayData/blob/master/systems.csv)........................................ ;)
Quote from: michih on November 12, 2015, 03:48:18 PM
I used "first class category". I think categories already exist. There's tier 1 to 5 (https://github.com/TravelMapping/HighwayData/blob/master/systems.csv)........................................ ;)
Right - in my post I meant that my current mechanism is unworkable, not that your suggestion would be. I think this would actually be pretty simple the more I think of it.
Quote from: Jim on November 12, 2015, 07:55:41 AM
Re: one of Oscar's other comments. If anyone knows of a set of map tiles that would show only borders and land vs. water without the other clutter that comes from the tiles we have available so far, I think that would be a great option, and might eliminate the need for us to manage our own country/region/water boundaries and generate the old CHM-style maps. Of course, I'm happy to have the project support CHM-style maps also but it won't likely be a priority for me to work on myself.
I've been looking around and haven't found any that eliminate everything but the boundaries, but here's one that's close:
http://maps.skobbler.com/@44.9181393,-86.9238281,5/categorySearch
In "lite" mode everything is lightly shaded (grey or green) and the roads are all white. Looks a lot like Google's terrain maps (without the shaded relief).
Quote from: michih on November 12, 2015, 12:40:42 PM
I also prefer having a "simple" map but I think we already have a good one, Google Satellite without labels :).
That one doesn't work well for me, since most of the time the areas I'm looking at have a lot of forest, which makes it difficult to see unclinched segments.
Also, could the user also have the option of making unclinched segments show up brighter than clinched segments? The new color options are awesome, but regardless of the colors chosen, the clinched segments are always brighter.
The Utah State Highways (system usaut) are now active in Travel Mapping. Thanks to NickCPDX for all his work on this, and to everyone who helped to get them in shape.
Now the race is on for the next system to get ready. Is it usanm? usavt? Maybe even usava, usain, usamt, or usaco? Something in Europe?
I'll run one more update later tonight with any .list updates that come in over the next couple hours.
Quote from: mapcat on November 12, 2015, 06:56:58 PM
Also, could the user also have the option of making unclinched segments show up brighter than clinched segments? The new color options are awesome, but regardless of the colors chosen, the clinched segments are always brighter.
If I were to make the opacity user-configurable, that would do it. Certainly doable
Quote from: Jim on November 12, 2015, 08:16:34 PM
The Utah State Highways (system usaut) are now active in Travel Mapping. Thanks to NickCPDX for all his work on this, and to everyone who helped to get them in shape.
Now the race is on for the next system to get ready. Is it usanm? usavt? Maybe even usava, usain, usamt, or usaco? Something in Europe?
I'll run one more update later tonight with any .list updates that come in over the next couple hours.
I don't think usavt even has a thread here yet (unless I missed it). It would be one I've been looking forward to for a long time though!
Quote from: vdeane on November 12, 2015, 09:19:07 PM
I don't think usavt even has a thread here yet (unless I missed it). It would be one I've been looking forward to for a long time though!
It was discussed at (rather painful) length in a collaborators-only section of the old CHM forum.
I'm not sure further discussion here is needed, unless froggie thinks it useful. usavt seems really, really close to activation.
Quote from: Jim on November 12, 2015, 08:20:25 PM
Quote from: mapcat on November 12, 2015, 06:56:58 PM
Also, could the user also have the option of making unclinched segments show up brighter than clinched segments? The new color options are awesome, but regardless of the colors chosen, the clinched segments are always brighter.
If I were to make the opacity user-configurable, that would do it. Certainly doable
Thanks. Seems that might solve Oscar's request above to make unclinched routes invisible, too.
Quote from: oscar on November 12, 2015, 10:40:51 PM
Quote from: vdeane on November 12, 2015, 09:19:07 PM
I don't think usavt even has a thread here yet (unless I missed it). It would be one I've been looking forward to for a long time though!
It was discussed at (rather painful) length in a collaborators-only section of the old CHM forum.
I'm not sure further discussion here is needed, unless froggie thinks it useful. usavt seems really, really close to activation.
As far as I'm concerned, it's just about ready to go. Though I did turn VT maintenance over to froggie, so it's his turf now. One caveat that I do remember though is that ISTR froggie saying somewhere there's been a proposal to revert VT100HisMor to VT100 proper, and make the bypass VT100Trk, I think. Not sure how far along that process is, if it is happening. So that may be in flux. That, and OSM imagery has improved enough to tweak the location of the VT100/VT100His junction.
I'd like to hear froggie weigh in on this topic.
I'll send him a PM in a bit.
I agree that usavt should be just about ready. The only reason it never made it into CHM was the disagreement about the distinction between state maintained and town maintained portions. I expect everyone still involved in the project is in agreement that the routes as plotted now are the ones that should be included.
Given that I peer-reviewed VT 2 years ago...assuming Eric made the agreed changes before he gave it back to me recently, it should be good to go. I admit that I haven't looked at the temporary TM yet to verify...I'll try to get to that this weekend.
Regarding VT 100 in Morrisville, the change Eric alluded to has not happened yet.
[EDIT:] Found at least one fix that's needed.
Quote from: Jim on November 12, 2015, 06:30:16 PM
Quote from: michih on November 12, 2015, 03:48:18 PM
I used "first class category". I think categories already exist. There's tier 1 to 5 (https://github.com/TravelMapping/HighwayData/blob/master/systems.csv)........................................ ;)
Right - in my post I meant that my current mechanism is unworkable, not that your suggestion would be. I think this would actually be pretty simple the more I think of it.
This was very simple to add. You can now specify tier1:, tier2:, ... in your colors= query string parameter in addition to system names. If you specify both that would apply to the same route, the system name takes precedence. Here's an example URL:
http://tm.teresco.org/hbtest/mapviewt.php?rg=NY&u=terescoj&colors=tier1:rgb%280,0,255%29:rgb%28255,100,100%29;tier4:rgb%2850,50,50%29:rgb%280,0,0%29
Again, the %28 characters are really open parens and %29 close parens.
These will also soon work with the default "mapview.php" instead of just the testing version "mapviewt.php".
Works fine (with "mapview.php") :)
http://tm.teresco.org/hbtest/mapview.php?rg=AUT,BEL,CHE,CZE,DEU,DNK,ESP,FRA,HUN,ITA,LUX,NLD,POL,ROU,SWE,AB,BC,ON,QC,IL,MI&u=michih&colors=tier1:rgb(255,69,0):rgb(124,252,0);tier2:rgb(255,69,0):rgb(124,252,0);tier3:rgb(255,105,180):rgb(50,205,50);tier4:rgb(255,105,180):rgb(50,205,50);tier5:rgb(255,105,180):rgb(50,205,50)
Greens = traveled; Reds = not yet traveled.
Unfortunately, the url is too long for the forum signature which is limited to 300 characters.
Quote from: michih on November 14, 2015, 02:51:27 PMUnfortunately, the url is too long for the forum signature which is limited to 300 characters.
Which reminds me of another intended enhancement: a way to specify regions as groups like "all U.S. states", "all Canadian provinces", or "all countries in Europe".
Quote from: Jim on November 14, 2015, 10:46:58 AM
This was very simple to add. You can now specify tier1:, tier2:, ... in your colors= query string parameter in addition to system names.
Nice! This is much simpler.
QuoteIf you specify both that would apply to the same route, the system name takes precedence.
That is an especially useful feature--thanks for thinking of it. I tried it and it worked perfectly.
A feature I mentioned earlier now has a preliminary implementation. Highway systems now have a third option between "active" and "in-development" called "preview". Systems denoted as preview are those that are intended to be complete but awaiting review and (hopefully) only minor fixes before activation. In the normal logs and maps, they continue to be treated the same as before. However, a second instance of the database is populated as if the preview systems are active rather than in-development, so they show up on maps (and soon perhaps in an alternate per-user log file).
For now, the only place that honors the new option is the draft map overlay viewer. Include preview systems in maps by specifying the alternate DB's name as a query string parameter. For example, to see my NM travels with the usanm "preview" system included, you would use:
http://tm.teresco.org/hbtest/mapview.php?rg=NM&db=TravelMappingDev&u=terescoj (http://tm.teresco.org/hbtest/mapview.php?rg=NM&db=TravelMappingDev&u=terescoj)
Along with many of the other features, I expect and intend that these query string parameters would be generated automatically by some nice front-end web pages some day. For now, it's a good way for those who submit .lists to find mistakes and omissions in the preview systems before they go active, and for highway data managers to see the routes and hopefully also find mistakes before activation.
Important note: updates entries will not be made for changes to systems in preview status, so users should expect things to "break" their list files until those systems are deemed ready to be moved to full active status.
So far, I picked the following as the systems I thought were intended to be substantially complete and worthy of the "preview" status: usavt, usanm, usaco, usava, usawy, usain, usamt. I expect some of the systems in Canada and outside of North America will soon be added to the preview set at the discretion of the highway data developers.
Enjoy! (and please let me know if anything appears to have been broken by this.)
Looks excellent.
Quote from: Jim on November 25, 2015, 11:13:38 PMI expect some of the systems in Canada and outside of North America will soon be added to the preview set at the discretion of the highway data developers.
I've just put the remaining British A road systems as preview ones.
Possibly related, but some of my error log entries have new additional language, for example:
Waypoint label(s) not found in line: TX US59 RivDr TXLp20 [<__main__.Waypoint object at 0x107a10630>]
This entry is for a segment of an active route, with one valid waypoint and the other not yet valid (pending confirmation that the AASHTO-approved reroute of US 59 in Laredo has been carried out).
On the list of "preview" systems, I suggest adding usaak. That draft system is complete, and review has already started with no major issues flagged, which puts it in the same category as usaco, usain, usava, and usawy. canab is another candidate, if yakra agrees.
Quote from: english si on November 26, 2015, 07:20:18 AM
Quote from: Jim on November 25, 2015, 11:13:38 PMI expect some of the systems in Canada and outside of North America will soon be added to the preview set at the discretion of the highway data developers.
I've just put the remaining British A road systems as preview ones.
Thanks. They're now in the TravelMappingDev DB.
Quote from: oscar on November 26, 2015, 09:18:22 AM
Possibly related, but some of my error log entries have new additional language, for example:
Waypoint label(s) not found in line: TX US59 RivDr TXLp20 [<__main__.Waypoint object at 0x107a10630>]
This entry is for a segment of an active route, with one valid waypoint and the other not yet valid (pending confirmation that the AASHTO-approved reroute of US 59 in Laredo has been carried out).
I was in that part of the code when thinking about the problem of zero-length segments. Looks like I broke something. I'll investigate when I can. I think it only affects lines that were invalid.
Quote
On the list of "preview" systems, I suggest adding usaak. That draft system is complete, and review has already started with no major issues flagged, which puts it in the same category as usaco, usain, usava, and usawy. canab is another candidate, if yakra agrees.
I'll put in usaak and launch another "dev" update.
I'll add that at the moment, I've made a "quick and dirty" way of doing this: I just run the site update program twice with different parameters. I know I can do things much more efficiently down the line.
Yay neato! I'll have to add my VT travels straight away.
One suggestion:
Change the logfile output for lines such as
Ignoring line matching highway in inactive system: MT MT78 I-90 PikeAve_E to either acknowledge the system's preview status, or mute them entirely.
I expect some travelers would be heavy users of the Preview feature, and include a lot of lines in their .lists. This could make for a lot of noise in .log files (which many users may have already with inactive/in-dev systems). Maybe muting is the better option?
Quote from: oscar on November 26, 2015, 09:18:22 AM
(pending confirmation that the AASHTO-approved reroute of US 59 in Laredo has been carried out).
Of course, this would be TXLp20_S because of the multiplex. Or maybe US59Bus would get the nod. Or... 8-)
Quote from: oscar on November 26, 2015, 09:18:22 AMcanab is another candidate, if yakra agrees.
All five of mine can go preview. Review has begun; the other four have had issues reported, with some fixed and some explained/discussed. I'll get a pull request in.
Quote from: yakra on November 26, 2015, 02:17:21 PM
One suggestion:
Change the logfile output for lines such as Ignoring line matching highway in inactive system: MT MT78 I-90 PikeAve_E to either acknowledge the system's preview status, or mute them entirely.
I expect some travelers would be heavy users of the Preview feature, and include a lot of lines in their .lists. This could make for a lot of noise in .log files (which many users may have already with inactive/in-dev systems). Maybe muting is the better option?
Post coming soon about two sets of log files (for now).
Once the update running now completes, several more systems will be promoted from "devel" to "preview".
I've also added a second set of log files that will include (among other things) per-user logs/stats with the preview systems considered active:
http://tm.teresco.org/devlogs/ (http://tm.teresco.org/devlogs/)
The original logs with just the active systems considered active remain at
http://tm.teresco.org/logs/ (http://tm.teresco.org/logs/)
At some point, I intend to merge all of this into something easier to deal with, but for now this is the easiest way to get this going.
I know I've already noticed mistakes in my own preliminary .list entries for these preview systems. My hope is that the real win is going to be another tool for those doing peer review to get these preview systems ready to be promoted to full active status.
The URLs for the draft highway browser now also take the db=TravelMappingDev query string parameter, so you can view your travels on an individual route including preview routes. For example, my VT 100:
http://tm.teresco.org/devel/hb.php?r=vt.vt100&db=TravelMappingDev&u=terescoj (http://tm.teresco.org/devel/hb.php?r=vt.vt100&db=TravelMappingDev&u=terescoj)
Great to see the new systems moving towards activation. No one has said anything recently about the next KY state routes set (1000-1499), which appeared to be complete and ready for peer-review in CHM. Has there been any progress on this?
Quote from: mapcat on November 27, 2015, 10:13:24 AM
Great to see the new systems moving towards activation. No one has said anything recently about the next KY state routes set (1000-1499), which appeared to be complete and ready for peer-review in CHM. Has there been any progress on this?
Kentucky was Tim's territory back before CHM went inactive.
Just guessing here, as I don't know what's going on and can't speak for other collaborators... According to the How the work is split (https://www.aaroads.com/forum/index.php?topic=16352.0) thread, no one's officially taken on KY for maintenance purposes (unless someone volunteered in another thread and I missed it). So it's possibly a lack of interest, free time or attention span...
I started peer reviewing it in July 2013. The errors I found (and Jim found some too) and posted in July weren't fixed by September, where I posted a reminder (and they still aren't fixed). This was still when Tim was around, but he was so unbothered by the subsystem that he didn't even make a reply.
Also, if we start having some 4-digit routes in KY clinchable, that opens the issue of having to do the others. I love making route files for TM, but I would despise doing that! Way too many routes, most of which are really short and boring.
Personally, more Canadian systems would be higher on my priority list.
Quote from: yakra on November 27, 2015, 12:30:40 PM
Quote from: mapcat on November 27, 2015, 10:13:24 AM
Great to see the new systems moving towards activation. No one has said anything recently about the next KY state routes set (1000-1499), which appeared to be complete and ready for peer-review in CHM. Has there been any progress on this?
Kentucky was Tim's territory back before CHM went inactive.
Just guessing here, as I don't know what's going on and can't speak for other collaborators... According to the How the work is split (https://www.aaroads.com/forum/index.php?topic=16352.0) thread, no one's officially taken on KY for maintenance purposes (unless someone volunteered in another thread and I missed it). So it's possibly a lack of interest, free time or attention span...
I've occasionally done some minor fixes in KY since I did have the state (Interstates & US Highways) before Tim took it over while doing the state highways. I know there are a few things that do need to be fixed (like some US-60 reroutes).
I suppose the question there would be, are those Kentucky routes part of the primary state route system? It wouldn't make sense to leave routes out just because they're small. If, however, they're secondaries, that would open the door to including every minor secondary in every state (including conceivably Virginia's 600 series routes, NY's reference routes, and maybe even NJ's county routes).
I'd love to see Quebec's provincial routes added. That would probably be next on my wishlist after getting Vermont activated.
Quote from: vdeane on November 27, 2015, 09:23:38 PM
I suppose the question there would be, are those Kentucky routes part of the primary state route system? It wouldn't make sense to leave routes out just because they're small. If, however, they're secondaries, that would open the door to including every minor secondary in every state (including conceivably Virginia's 600 series routes, NY's reference routes, and maybe even NJ's county routes).
All the Kentucky routes are signed the same, except with the usual boring circle stretched into an oval for the 3- and 4-digit routes.
Quote from: vdeane on November 27, 2015, 09:23:38 PM
I'd love to see Quebec's provincial routes added. That would probably be next on my wishlist after getting Vermont activated.
This one could use a lot of help from a French-speaker. Auto-translate only gets you so far, as I've found in dealing with the smaller universe of Quebec Autoroutes.
I have a moderate amount of interest in having Quebec provincial routes added. But the same goes for almost every other North American jurisdiction where we don't already have provincial/state route sets. When I took over updating the Autoroutes, I left the door wide open (in "How the work is split") for someone else to do Quebec provincial routes.
Quote from: oscar on November 27, 2015, 09:43:09 PM
Quote from: vdeane on November 27, 2015, 09:23:38 PM
I suppose the question there would be, are those Kentucky routes part of the primary state route system? It wouldn't make sense to leave routes out just because they're small. If, however, they're secondaries, that would open the door to including every minor secondary in every state (including conceivably Virginia's 600 series routes, NY's reference routes, and maybe even NJ's county routes).
All the Kentucky routes are signed the same, except with the usual boring circle stretched into an oval for the 3- and 4-digit routes.
Quote from: vdeane on November 27, 2015, 09:23:38 PM
I'd love to see Quebec's provincial routes added. That would probably be next on my wishlist after getting Vermont activated.
This one could use a lot of help from a French-speaker. Auto-translate only gets you so far, as I've found in dealing with the smaller universe of Quebec Autoroutes.
I have a moderate amount of interest in having Quebec provincial routes added. But the same goes for almost every other North American jurisdiction where we don't already have provincial/state route sets. When I took over updating the Autoroutes, I left the door wide open (in "How the work is split") for someone else to do Quebec provincial routes.
Ping DrFrankenstein for translations.
New Mexico State Highways (usanm) are now ACTIVE in Travel Mapping. A mere 911 days after I submitted the first complete draft to CHM, 1281 days after I submitted my first batch of routes to CHM, and 1940 days after I claimed the system as my next to develop after the completion of usama. Many, many thanks to Oscar for taking over in the last several weeks to get the system ready to go, and to everyone who reported problems and especially solutions to those problems.
With New Mexico State Highways now active, which preview systems are likely to move to the front of the queue?
I seem to recall a couple other systems were close (VT?). I know it takes a lot of work to get everything ready. I've lost track of which systems are close and thought another update would be good for everyone.
Quote from: bejacob on December 21, 2015, 09:28:38 AM
With New Mexico State Highways now active, which preview systems are likely to move to the front of the queue?
I seem to recall a couple other systems were close (VT?). I know it takes a lot of work to get everything ready. I've lost track of which systems are close and thought another update would be good for everyone.
I think MT and VT are closest. Next up behind them, in no particular order: AK, IN, VA, CO, WY, AB, TX.
Quote from: bejacob on December 21, 2015, 09:28:38 AM
With New Mexico State Highways now active, which preview systems are likely to move to the front of the queue?
I seem to recall a couple other systems were close (VT?). I know it takes a lot of work to get everything ready. I've lost track of which systems are close and thought another update would be good for everyone.
And there's all kinds of stuff in progress in Europe, but I don't know how close those might be.
British A roads beginning with 1, 6, 8, 9 are waiting. Any objections, get them in this year, as I will merge them with the main system on New Years Day if I hear nothing before.
There's some concurrency issues with E roads and in-dev systems that I'll fix (by changing the E roads to match) in the next couple of days.
lvaa (http://tm.teresco.org/devel/hb.php?sys=lvaa&rg=), ltua (http://tm.teresco.org/devel/hb.php?sys=ltua&rg=) and srba (http://tm.teresco.org/devel/hb.php?sys=srba&rg=) need an experienced hand to look over them and check I've not made errors in style. Should take whomever does it not very long. There's 15, 20 and 6 routes respectively with none of them long.
dnkpr, finvt, finkt, fran need peer review, but I believe them done.
If it wouldn't be too hard, would it be possible to add a column for the status of the route system in the highway browser? That way, we could tell what is in development or not from there.
Quote from: english si on December 21, 2015, 12:23:35 PMlvaa (http://tm.teresco.org/devel/hb.php?sys=lvaa&rg=), ltua (http://tm.teresco.org/devel/hb.php?sys=ltua&rg=) and srba (http://tm.teresco.org/devel/hb.php?sys=srba&rg=) need an experienced hand to look over them and check I've not made errors in style. Should take whomever does it not very long. There's 15, 20 and 6 routes respectively with none of them long.
dnkpr, finvt, finkt, fran need peer review, but I believe them done.
I could try to check them but I guess I'm not "experienced" with the style. Sorry.
Quote from: rschen7754 on December 21, 2015, 02:45:48 PM
If it wouldn't be too hard, would it be possible to add a column for the status of the route system in the highway browser? That way, we could tell what is in development or not from there.
Yes, I would like to add this when I fix up the data processing code to be better aware of and more efficient at processing data with the new system status levels.
Quote from: michih on December 21, 2015, 03:44:04 PMI could try to check them but I guess I'm not "experienced" with the style. Sorry.
That's fine, perhaps you would like to check for other kinds of errors (though that could include label issues) on the in-dev European systems?
Perhaps the system status (active/preview/InDev) could be indicted by color coding of the table cells in the HB, to avoid taking up too much on-screen real estate.
Quote from: english si on December 21, 2015, 08:49:24 PM
Quote from: michih on December 21, 2015, 03:44:04 PMI could try to check them but I guess I'm not "experienced" with the style. Sorry.
That's fine, perhaps you would like to check for other kinds of errors (though that could include label issues) on the in-dev European systems?
Specify "other kinds of errors". I could check that you don't miss a route, that you don't miss an interchange and that the waypoint locations are correct.
I checked it for srba and reported a minor issue earlier this year. It's corrected meanwhile and I guess it could go online. It was before the srba thread (https://www.aaroads.com/forum/index.php?topic=16756.0) was started.
I already asked what's required to get new systems online but didn't get any answer.....................
Quote from: michih on November 02, 2015, 11:58:46 AMDo you expect that anyone checks the highway data? Will it only go online if one confirms that data is correct or will it go online anyway after x days?
I still don't know what's exactly required to get dev systems online and who has to do it.
There are already threads for lvaa, ltua and srba. Where should I report issues about dnkpr, finvt, finkt and fran (w/o using github)?
Quote from: michih on December 22, 2015, 05:11:47 AMSpecify "other kinds of errors". I could check that you don't miss a route, that you don't miss an interchange and that the waypoint locations are correct.
That sort of thing, yes.
QuoteI checked it for srba and reported a minor issue earlier this year. It's corrected meanwhile and I guess it could go online. It was before the srba thread (https://www.aaroads.com/forum/index.php?topic=16756.0) was started.
Indeed, that's the sort of thing I need.
QuoteI already asked what's required to get new systems online but didn't get any answer.....................
I'm pretty sure the answer has been given in this thread at least twice, and specific systems' specific issues have been discussed.
QuoteWhere should I report issues about dnkpr, finvt, finkt and fran (w/o using github)?
I've just made threads.
Quote from: yakra on December 21, 2015, 10:05:32 PMPerhaps the system status (active/preview/InDev) could be indicted by color coding of the table cells in the HB, to avoid taking up too much on-screen real estate.
This - perhaps a traffic light red-yellow-green pattern (with green as active)?
Quote from: english si on December 22, 2015, 09:21:29 AM
Quote from: yakra on December 21, 2015, 10:05:32 PMPerhaps the system status (active/preview/InDev) could be indicted by color coding of the table cells in the HB, to avoid taking up too much on-screen real estate.
This - perhaps a traffic light red-yellow-green pattern (with green as active)?
Add blue or purple for active systems being brought up to standards (ie, Oregon)?
Green/yellow/red for active/preview/devel is doable with info already in the database. Having more statuses (such as those systems under improvement) would probably require a change to how updates are run.
Yes, the level field in the systems table indicates which are in any of the three levels. Not hard to add to the HB.
Quote from: Jim on December 22, 2015, 04:18:09 PM
Yes, the level field in the systems table indicates which are in any of the three levels. Not hard to add to the HB.
And thanks to Thing 342, this functionality is now live on TM.
Quote from: Jim on December 22, 2015, 07:32:36 PM
Quote from: Jim on December 22, 2015, 04:18:09 PM
Yes, the level field in the systems table indicates which are in any of the three levels. Not hard to add to the HB.
And thanks to Thing 342, this functionality is now live on TM.
Well, it's live but the DB's corrupted at the moment. I'm running an update (after a failed update) that should get things back up and running within about 15 minutes.
Sorry about the hour plus of TM downtime. I added the continents, countries, and regions tables to the DB and had a series of mistakes that caused the DB to fail to load. Seems to be OK now (with those three new tables available to those looking to enhance the web front end). And now you can check out Thing 342's new color-coded HB tables.
IIRC there was a request to have a mapview layer with shapes only (borders and shoreline) so that one can see the "lines" for easier checking out which segment is not yet clinched. I've recently checked the French N roads and uses mapview (http://tm.teresco.org/hbtest/mapview.php?rg=FRA&u=michih&db=TravelMappingDev) for checking that there are not gaps between different systems of the region et cetera. It's sometimes hard to figure out the lines. Sometimes you only see it after zooming while the layer is still loaded.
I think it would be helpful to have a "white" layer without any map (GM, Mapnik,...) but only the traced routes. Is it possible to add a layer like this? I think it could also be a nice layer for printing because I'm quite sure that a road geek can easily navigate with a map showing road networks only :).
Quote from: michih on January 02, 2016, 05:07:06 AM
IIRC there was a request to have a mapview layer with shapes only (borders and shoreline) so that one can see the "lines" for easier checking out which segment is not yet clinched. I've recently checked the French N roads and uses mapview (http://tm.teresco.org/hbtest/mapview.php?rg=FRA&u=michih&db=TravelMappingDev) for checking that there are not gaps between different systems of the region et cetera. It's sometimes hard to figure out the lines. Sometimes you only see it after zooming while the layer is still loaded.
I think it would be helpful to have a "white" layer without any map (GM, Mapnik,...) but only the traced routes. Is it possible to add a layer like this? I think it could also be a nice layer for printing because I'm quite sure that a road geek can easily navigate with a map showing road networks only :).
I've put an issue into GitHub for this. I'd find something like this, or at least a map layer with nothing but boundaries, to be useful as well. If no such thing is readily available, it's possible we could create it from the boundary data from CHM that was used to generate the CHM-style maps over in that project.
Thanks :). Is there already an issue/reminder for BIng layer?
Quote from: Jim on January 02, 2016, 08:10:12 AM
Quote from: michih on January 02, 2016, 05:07:06 AM
IIRC there was a request to have a mapview layer with shapes only (borders and shoreline) so that one can see the "lines" for easier checking out which segment is not yet clinched. I've recently checked the French N roads and uses mapview (http://tm.teresco.org/hbtest/mapview.php?rg=FRA&u=michih&db=TravelMappingDev) for checking that there are not gaps between different systems of the region et cetera. It's sometimes hard to figure out the lines. Sometimes you only see it after zooming while the layer is still loaded.
I think it would be helpful to have a "white" layer without any map (GM, Mapnik,...) but only the traced routes. Is it possible to add a layer like this? I think it could also be a nice layer for printing because I'm quite sure that a road geek can easily navigate with a map showing road networks only :).
I've put an issue into GitHub for this. I'd find something like this, or at least a map layer with nothing but boundaries, to be useful as well. If no such thing is readily available, it's possible we could create it from the boundary data from CHM that was used to generate the CHM-style maps over in that project.
I'm one of the people who suggested that option, but I'm no longer sure it's useful. Main problem is CHM's shoreline data are sometimes terrible (look at a CHM map for New York City, for example), and many of the land boundaries need to be redrawn too (even in some places in North America, but especially in Europe where some country boundaries have been shifting lately). Using an online map, with its own land and water boundaries, as the base layer means we don't have to bother with all that.
Quote from: michih on January 02, 2016, 08:21:14 AM
Thanks :). Is there already an issue/reminder for BIng layer?
There is now. https://github.com/TravelMapping/Web/issues/19 (https://github.com/TravelMapping/Web/issues/19)
@oscar: I don't like the old CHM map but a simple blank map would be useful... (and maybe easily to be implemented?!)
@jim: Thanks. I've created a github account now (michih was already used, my account is michihdeu). Should I directly create issues there or should we always discuss it in the forum first?
Quote from: michih on January 02, 2016, 08:42:10 AM@jim: Thanks. I've created a github account now (michih was already used, my account is michihdeu). Should I directly create issues there or should we always discuss it in the forum first?
We're still working out best ways, but either works for now. Our new forum is up and will be opened to the public very soon, so that and GitHub will become the mechanisms. I know for sure that we won't require people to sign up for any use GitHub just to submit issues. The advantage of being on GitHub is that you can also easily propose a fix to something, especially if it's a minor issue that won't require much if any discussion.
Quote from: oscar on January 02, 2016, 08:31:49 AM
Quote from: Jim on January 02, 2016, 08:10:12 AM
Quote from: michih on January 02, 2016, 05:07:06 AM
IIRC there was a request to have a mapview layer with shapes only (borders and shoreline) so that one can see the "lines" for easier checking out which segment is not yet clinched. I've recently checked the French N roads and uses mapview (http://tm.teresco.org/hbtest/mapview.php?rg=FRA&u=michih&db=TravelMappingDev) for checking that there are not gaps between different systems of the region et cetera. It's sometimes hard to figure out the lines. Sometimes you only see it after zooming while the layer is still loaded.
EDIT: Looking back at Oscar's response I'm starting to agree with him. We already have an effective web overlay over an existing map (sort of like what the mob-rule County Clinching site has with status over Google Maps.). The white background maps seemed like they were extra work. That being said, I'm not throwing out my work, but let's see what everyone's take on it is. (I may break out this into its own topic when I get home from work today)
I think it would be helpful to have a "white" layer without any map (GM, Mapnik,...) but only the traced routes. Is it possible to add a layer like this? I think it could also be a nice layer for printing because I'm quite sure that a road geek can easily navigate with a map showing road networks only :).
I've put an issue into GitHub for this. I'd find something like this, or at least a map layer with nothing but boundaries, to be useful as well. If no such thing is readily available, it's possible we could create it from the boundary data from CHM that was used to generate the CHM-style maps over in that project.
I'm one of the people who suggested that option, but I'm no longer sure it's useful. Main problem is CHM's shoreline data are sometimes terrible (look at a CHM map for New York City, for example), and many of the land boundaries need to be redrawn too (even in some places in North America, but especially in Europe where some country boundaries have been shifting lately). Using an online map, with its own land and water boundaries, as the base layer means we don't have to bother with all that.
I had started working on this back in July - but because work had me all over the place and working too much that my life got taken from me I couldn't keep up - now the code is out-dated. I put a reply in https://www.aaroads.com/forum/index.php?topic=17184.msg2117290#msg2117290 and opened a github issue regarding this. I have draft code in my branch of Web. Even if caught up to the DB, it works, but doesn't draw clinched highways well.
System usanes, Nebraska State Links and Spurs, is now active in Travel Mapping. Thanks to @yakra who (I believe) developed it, and to those who have reviewed it.
Quote from: Jim on January 07, 2016, 11:59:04 AM
System usanes, Nebraska State Links and Spurs, is now active in Travel Mapping. Thanks to @yakra who (I believe) developed it, and to those who have reviewed it.
I think the highway data update list (http://tm.teresco.org/devel/updates.php) could be improved by adding a link in the "file root" column: http://tm.teresco.org/devel/hb.php?sys=usanes. I think it should be done for all new systems of the list.
Quote from: michih on January 07, 2016, 02:57:31 PM
I think the highway data update list (http://tm.teresco.org/devel/updates.php) could be improved by adding a link in the "file root" column: http://tm.teresco.org/devel/hb.php?sys=usanes. I think it should be done for all new systems of the list.
I'd go a step further and suggest that system status changes should be broken out into a separate table, both in the DB and on the updates page. I'll make a note to myself in GitHub.
Quote from: Jim on January 07, 2016, 09:33:46 PM
Quote from: michih on January 07, 2016, 02:57:31 PM
I think the highway data update list (http://tm.teresco.org/devel/updates.php) could be improved by adding a link in the "file root" column: http://tm.teresco.org/devel/hb.php?sys=usanes. I think it should be done for all new systems of the list.
I'd go a step further and suggest that system status changes should be broken out into a separate table, both in the DB and on the updates page. I'll make a note to myself in GitHub.
And they are. No links to the HB yet, but system-level changes are now in a separate table at the top of the updates page.
There are several new "devel" systems in TM as of today. These are the work of Si, and he can update on the status and plans for those new systems.
And just because they are there, doesn't mean I will treat them as a priority, all it means is that they are there.
My priorities are the systems currently in review that I'm working on.
I'm soon sinking into a new semester, with my heaviest teaching load ever. I intend to continue processing list files and running site updates once every day or two, and bringing in highway data updates as they come in, but there are likely to be times when it's a few days in between. I don't expect much time for real site development until May.
Does it beat my wife's 21 credits (technically 18, but an extra 3 due to being department chair)?
Quote from: froggie on January 14, 2016, 09:30:48 AM
Does it beat my wife's 21 credits (technically 18, but an extra 3 due to being department chair)?
Not quite. 17 plus 3 for sharing some department chair responsibilities. 5 total sections of 3 different courses, but nothing brand new at least. I'll be up for air (and grading catchup) for a week in March during spring break.
Have your TA's do some of the grading :bigass:.
Good luck with your upcoming semester.
Quote from: mvak36 on January 14, 2016, 10:54:17 AM
Have your TA's do some of the grading :bigass:.
Good luck with your upcoming semester.
No TAs here. But the classes are small so it's not horrible.
Si, yakra to fill in? ;)
We can merge in pull requests, but not run the actual updates on Jim's server.
But if Jim were to just blindly update with the new data that we merge in, I suppose that's possible.
Quick note: an update to the standard DB just finished, but I need to leave (and disconnect my computer from the network) before the dev DB update finishes. That will complete when I get home late tonight.
Quote from: yakra on January 15, 2016, 12:21:13 AM
We can merge in pull requests, but not run the actual updates on Jim's server.
But if Jim were to just blindly update with the new data that we merge in, I suppose that's possible.
If we have an experienced project member who is comfortable with running git commands and running scripts from the Unix command line (definitely including Linux and Mac with Python 3.7 installed, probably could be set up on Windows also), I am happy to put some effort into setting things up to allow others to run. Server accounts can be created and permissions set up so multiple people have the ability to run complete site updates.
That said, while I will definitely be busy, I don't anticipate a situation where it will be more than a few days between site updates.
Jim,
I noticed an error with the Wisconsin State Highways. Wisconsin 74 runs from I-41 in Menomonee Falls to WI190 near Sussex, I couldn't find the highway on there.
Thanks,
ShadowHighways
^^ WI 74 has been decommissioned this year.
Quote from: Big John on March 28, 2016, 03:55:31 PM
^^ WI 74 has been decommissioned this year.
Ah, I hadn't realized. Thank you for the heads up.
Thanks,
ShadowHighways
The Travel Mapping site and forum are temporarily down because of a network connectivity problem. I believe I know what's wrong, and I expect to be able to resolve it this morning. I just need to get physical access to it, and then the fix should take just a few minutes.
I haven't seen any posts on here in almost 3 months. Makes me a little nervous. Just wanted to make sure the project was alive and kicking!
Quote from: TAG42481 on August 18, 2016, 12:15:34 PM
I haven't seen any posts on here in almost 3 months. Makes me a little nervous. Just wanted to make sure the project was alive and kicking!
Yep, it's still alive. :) A travel mapping forum was created, so new posts are going there instead of here. Here is the link to the travel mapping forum: http://tm.teresco.org/forum/index.php (http://tm.teresco.org/forum/index.php)
Quote from: 7/8 on August 18, 2016, 12:22:59 PM
Quote from: TAG42481 on August 18, 2016, 12:15:34 PM
I haven't seen any posts on here in almost 3 months. Makes me a little nervous. Just wanted to make sure the project was alive and kicking!
Yep, it's still alive. :) A travel mapping forum was created, so new posts are going there instead of here. Here is the link to the travel mapping forum: http://tm.teresco.org/forum/index.php (http://tm.teresco.org/forum/index.php)
And of course the project itself is headquartered at http://tm.teresco.org/ (http://tm.teresco.org/) now. We've added a ton of highways, greatly enhanced the maps and stats available, and added dozens of users since the discussion moved from here to our own forum. Come join us!
I hadn't realized everything had moved. Fantastic! Glad I finally asked. :-)
It's freakin' awesome.
I want to thank Jim for salvaging this site, and also for getting Indiana State Highways added. It has really motivated me to make more effort in clinching highways.
It wasn't just Jim. Jim may be hosting it, but this was a conglomeration of folks who banded together to get Travel Mapping off the ground.
Quote from: froggie on October 11, 2016, 07:45:18 AM
It wasn't just Jim. Jim may be hosting it, but this was a conglomeration of folks who banded together to get Travel Mapping off the ground.
Yes, I was going to say this same thing. My main contribution has been on the overall design, implementation of data processing side, and some of the web interface. Much of the web front end and virtually all of the huge improvements in quality and greatly expanded quantity of highway systems included are thanks to a larger group of contributors (http://tm.teresco.org/credits.php) (the list at the bottom of that page is incomplete, these are just the people who have put their names forward to include in the list). And not on that list are the many users who send in corrections, updates, and suggestions on the TM forum (http://tm.teresco.org/forum/) who help us improve everything about the project.
Bottom line, I think I can speak for all of us involved in saying that we're glad so many old CHM users and a good number of new users have found TM and are enjoying it.