Is the Clinched Highway Mapping site still active?

[oscar]

This lets the waypoint editor show me a very rough initial outline to which I add the necessary other points and there it is.

"Waypoint editor" is another to-do list item. It's possible to craft route files without one, then use one of Jim's programs to double-check the result. But the waypoint editor we were using lately (internally, access limited to the CHM team) streamlined things by combining those steps.

[Jim]

A lot of the discussion of programming and the like is going over my head. As a practical matter, it seems that if you want to be able to re-use existing .LIST files (something I'd certainly applaud), it means you have to give all the waypoints the exact same names, right? Or else you have to come up with a way of programming in the old names with some sort of "redirect" function so the software would recognize the old and new names? I think going through your own list to replace changed waypoint names would potentially be far more frustrating than simply building a new list!

I see no reason why any existing waypoint names need to be changed, with occasional exceptions where a route has changed since the last updates in August (like a lot of changes in Quebec last autumn), in which case we try to minimize list file breakage such as with "redirects". Especially for route files created by people who give permission for their re-use by a new site, no changes will presumably be the default.

Any fixes or re-plots should continue to avoid changing names of points that are in use by anyone's list file.  This has been a goal of the existing CHM collaborators for a long time.

[Dr Frankenstein]

Thinking out loud here... comments welcome.

I'm in favour of putting the code out on GitHub too.

For managing route contributions, I think that a system similar to what GitHub uses (i.e. pull requests, in which a contributor sends in changes and the project owner(s) either OK them or ask the contributor to revise and resend) could work. This would help keep at least a certain level of standards and avoid most edit wars, and if a contributor is unhappy, then they can start their own fork of the whole thing; both the code and data. Honestly, I keep seeing inconsistencies in OSM and Waze (and now even Google Maps) and it irks me a lot. Even when guidelines are well documented, they get ignored by a large part of the user base, and it's even worse on Waze because there's no requirement to document changesets; in fact, there's no way to document them at all! So a way to enforce those guidelines at least on a per-system basis could be interesting to avoid annoyed roadgeeks. ;D

Heck, we could even put the data on GitHub as well if it's kept in a text (not binary) format (otherwise reviews would be a pain), but Git is not always that easy to grasp for non-programmers.

An idea could be having one or more head maintainer(s) for each system who review contributions. If there's a system that isn't there and you would like to have added, you can apply to create it. I'm all for having things all the way down to numbered municipal roads if people volunteer for that.

Personally, I do keep track of unsigned routes as well, as they usually do have some importance, but they should be treated as separate systems because not everyone does that (i.e. someone who's clinched all signed routes should still have 100% of that system, and if they want to tackle unsigned routes next, it's in a separate system). But then comes the problem of "well-known" unsigned routes such as the New Jersey Turnpike, the Taconic State Parkway, the Queen Elizabeth Way, etc... I suppose that if it does carry a shield of some sort, then it should count as signed.

I think that "global" stats don't make sense (i.e. computing what percentage of the entire highway database you've got), but it would be interesting for users to set goals by selecting which highway systems they want to keep track of globally. I'm not 100% sure of which way I'd implement this conceptually, but this is food for thought.

Rail lines and transit routes are acceptable as far as I'm concerned. If there's opposition, then that can be a fork of the app too, but I think we should leave room for that in the code.

The waypoints system. Sometimes I don't like it, but only sometimes. It does work well for controlled access highways, but in many cases I've driven through part of a long-ish segment on a regular highway and would like to count it, but I don't have an easy-to-manage alternative in mind, so I guess we should keep it at the moment.

[oscar]

For managing route contributions, I think that a system similar to what GitHub uses (i.e. pull requests, in which a contributor sends in changes and the project owner(s) either OK them or ask the contributor to revise and resend) could work. This would help keep at least a certain level of standards and avoid most edit wars, and if a contributor is unhappy, then they can start their own fork of the whole thing; both the code and data. Honestly, I keep seeing inconsistencies in OSM and Waze (and now even Google Maps) and it irks me a lot. Even when guidelines are well documented, they get ignored by a large part of the user base, and it's even worse on Waze because there's no requirement to document changesets; in fact, there's no way to document them!

Heck, we could even put the data on GitHub as well if it's kept in a text (not binary) format (otherwise reviews would be a pain), but Git is not always that easy to grasp for non-programmers.

Some route contributions are made by non-programmers like me, so GitHub should not be the only way to get route files into the system. But it sounds like your suggestion would insulate non-programmers from having to deal directly with GitHub, which is good.

[NE2]

There's not always a clear distinction between signed and unsigned. SR 7 in south Florida is supposed to be unsigned, but street signs in Broward county say "SR 7" (probably named before it became US 441) and there are a few SR 7 shields posted. North of SR 80 (which is a well-signed carrier route for US 98), SR 7 goes on its own and is signed.

[oscar]

Personally, I do keep track of unsigned routes as well, as they usually do have some importance, but they should be treated as separate systems because not everyone does that (i.e. someone who's clinched all signed routes should still have 100% of that system, and if they want to tackle unsigned routes next, it's in a separate system). But then comes the problem of "well-known" unsigned routes such as the New Jersey Turnpike, the Taconic State Parkway, the Queen Elizabeth Way, etc... I suppose that if it does carry a shield of some sort, then it should count as signed.

The three named highways you mentioned are signed by name, and as such are all in the CHM database, either in a provincial highways route set (the QEW is listed as part of the Ontario Provincial Freeways set, under its signed name rather than its unsigned route number 451), or under a miscellaneous named highways set.

There are other issues with how you handle routes that are assigned route numbers but they're not signed in the field.  Some state DOTs, like for Maryland and Hawaii, assign a route number to every little scrap of pavement they maintain, which results in a large number of unimportant minor routes, most but not all of which have no route markers.  Others like Alaska have very small numbered route networks, but even some of those major routes have little or no route signage (such as AK 10's Cordova segment, which used to be signed, but Alaska DOT&PF gave up in the face of persistent sign vandalism -- there is strong local opposition to long-dormant proposals to connect that segment to the rest of the state highway system). Some such borderline cases are headaches, but I think there's a broad consensus for ignoring unsigned minor routes, to create less work for site maintainers and server.

I think that "global" stats don't make sense (i.e. computing what percentage of the entire highway database you've got), but it would be interesting for users to set goals by selecting which highway systems they want to keep track of globally. I'm not 100% sure of which way I'd implement this conceptually, but this is food for thought.

CHM's user stats home page used to rank users solely by global mileage. It now lists them by default in alphabetical order, but also allows users to switch to one of three other ranking methods (which has the nice feature of having multiple users having a piece of the #1 overall ranking). You can also list in reverse order, such as alphabetically starting with the Zs. There's room to add one or more extra columns, or you can dig deeper to find out who's on top in a particular region or highway system, if you feel competitive but want to focus the comparison on what you specialize in.

[yakra]

If people want the /data folder as-online for work on 1-3 then message me and I can sent it to you, saving the trouble of scraping the site. The mapviews folders are too big to email, but the rest is about 8MB.

I would like a copy.

Which reminds me - would we need to create a new JS .wpt editor?

I archived the one from the site.

Quick question, though: what are the +XNN lines used for?

These are hidden points, just used for keeping the shape of the route, roughly.
Also: A line can have more than one point label. The first label is the one shown on the HB; the rest are hidden, deprecated labels, to maintain compatibility for users with stale .list files, as Jim mentioned. As an example, here's ME I-195:

Code Select Expand

I-95 +0 http://www.openstreetmap.org/?lat=43.527548&lon=-70.452842
1 http://www.openstreetmap.org/?lat=43.523130&lon=-70.445323
2 http://www.openstreetmap.org/?lat=43.511927&lon=-70.432019
ME5 +999 http://www.openstreetmap.org/?lat=43.508130&lon=-70.414639

Before anyone invests much time in generating new .wpt files, I think they should be well aware of the naming conventions, tools, point density guidelines, guidelines for when to insert shaping points, etc.  Of course, a new system might change some of those rules but the existing ones work pretty well, in my opinion, and should be used as a starting point.  Also, make sure you're using public sources (i.e., not Google Maps), and are keeping track of those sources.

Seconded on all points.

I would also like us to be better about making sure points where two roads intersect use exactly the same coordinates, not just kind of sort of close enough.

Just noting that, as implemented now, having exactly matching points is not strictly necessary, except in the case of multiplexes. That said, IMO I DO think it is good practice, and make sure to do so myself. (It can be useful if, say, a new route comes along that hops off a multiplex with one route and onto the other...)

"Waypoint editor" is another to-do list item. It's possible to craft route files without one, then use one of Jim's programs to double-check the result. But the waypoint editor we were using lately (internally, access limited to the CHM team) streamlined things by combining those steps.

Jim's Viewer used the Google v.2 API, which has been discontinued. Thus the viewer no longer works; I don't believe he's made any updates to the v.3 API. The viewer is a lot less useful with the advent of the JavaScript waypoint editor anyway.
As said above, I've archived the waypoint editor. A quick test has it running off my local files on HD no prob. So, the matter becomes, do we reinvent this wheel this to just avoid using Tim's code? It's not a public-facing part of the site...

As a practical matter, it seems that if you want to be able to re-use existing .LIST files (something I'd certainly applaud), it means you have to give all the waypoints the exact same names, right? Or else you have to come up with a way of programming in the old names with some sort of "redirect" function so the software would recognize the old and new names? I think going through your own list to replace changed waypoint names would potentially be far more frustrating than simply building a new list!

I see no reason why any existing waypoint names need to be changed, with occasional exceptions where a route has changed since the last updates in August (like a lot of changes in Quebec last autumn), in which case we try to minimize list file breakage such as with "redirects". Especially for route files created by people who give permission for their re-use by a new site, no changes will presumably be the default.

Any fixes or re-plots should continue to avoid changing names of points that are in use by anyone's list file.  This has been a goal of the existing CHM collaborators for a long time.

Right. In fact, "redirects" have been in place for some time. Deprecated labels are recognized; "ME I-95 0 999" gets processed as if it were "ME I-95 NH/ME ME/Can. Alternate route names allow .list lines listing the old NC I-74Sea or NC I-74FutEll routes to be mapped to NC I-74Hig.

Heck, we could even put the data on GitHub as well if it's kept in a text (not binary) format (otherwise reviews would be a pain), but Git is not always that easy to grasp for non-programmers.

Data is stored as text. More or less, human-readable. Depending on what kind of human you are.

An idea could be having one or more head maintainer(s) for each system who review contributions. If there's a system that isn't there and you would like to have added, you can apply to create it. I'm all for having things all the way down to numbered municipal roads if people volunteer for that.

Needs further discussion, at least. Head maintainers, applying to create or add systems... may be worthwhile yes. The idea of Numbered municipal roads, however, makes me nervious. Sounds like mission creep, getting into too much unruly clutter...

Personally, I do keep track of unsigned routes as well, as they usually do have some importance, but they should be treated as separate systems because not everyone does that (i.e. someone who's clinched all signed routes should still have 100% of that system, and if they want to tackle unsigned routes next, it's in a separate system). But then comes the problem of "well-known" unsigned routes such as the New Jersey Turnpike, the Taconic State Parkway, the Queen Elizabeth Way, etc... I suppose that if it does carry a shield of some sort, then it should count as signed.

The project as is it now at least, has been limited to signed routes. The goal has been to stay with what's knowable and visible to the average driver (with the exceptions of the Interstates and Autoroutes).

I think that "global" stats don't make sense (i.e. computing what percentage of the entire highway database you've got), but it would be interesting for users to set goals by selecting which highway systems they want to keep track of globally. I'm not 100% sure of which way I'd implement this conceptually, but this is food for thought.

Sounds like something that's already implemented: http://cmap.m-plex.com/stat/system.php?u=si404&sys=eure&du=mi&sort=ra#tr

Rail lines and transit routes are acceptable as far as I'm concerned. If there's opposition, then that can be a fork of the app too, but I think we should leave room for that in the code.

There is room in the code. Really, anything that can be shown in connect-the-dots lines-with-waypoints format can be done. (Hell, we could even flip a switch or two and implement clinching of the international boundaries, coastline, state/provincial lines...) Here again though, I say, mission creep. I think it would dilute things, making a less clearly defined purpose and scope for the site.

[vdeane]

Git isn't too hard to learn, and there are even GUI front-ends for its tasks, though I can see where some would be intimidated by it.

At a place where I worked, they used Git for the projects, and they had some guidelines to maintain consistency.  The major ones were to name branches based on the issue number (so a fix to a bug labeled issue 578 would be branch issue-578) and to have a single person be responsible for testing and merging the branches together.

I agree that adding many other systems below state level or non-road could lead to clutter, though it brings my thoughts back to something I was thinking about earlier with respect to making the .list files a bit more powerful.  The idea was to allow comments similar to C++ (with text in a line after // or between /* and */ being ignored by the parser) and also optional directives stating which systems to include/exclude.  Of course, existing .list files would continue to process as they do now with this idea.  A sample of the new directives is below.

Code Select Expand


#include interstate, us, state(all), trans-canada, provincial(on, qc), select-named(us)


The goal has been to stay with what's knowable and visible to the average driver (with the exceptions of the Interstates and Autoroutes).

Didn't A-920 get dropped due to being unsigned?

[oscar]

Didn't A-920 get dropped due to being unsigned?

And because we weren't sure it existed even on paper. Since all the (other) A-routes are signed, that leaves Interstates as the only system that explicitly includes unsigned routes.

[Jim]

Before anyone invests much time in generating new .wpt files, I think they should be well aware of the naming conventions, tools, point density guidelines, guidelines for when to insert shaping points, etc.  Of course, a new system might change some of those rules but the existing ones work pretty well, in my opinion, and should be used as a starting point.  Also, make sure you're using public sources (i.e., not Google Maps), and are keeping track of those sources.

Seconded on all points.

If some of the experienced collaborators have any spare time while we wait for the old site to come back to life or a new site to be designed and implemented, I think a great use of that time would be to train up some interested people in how to do this.

I would also like us to be better about making sure points where two roads intersect use exactly the same coordinates, not just kind of sort of close enough.

Just noting that, as implemented now, having exactly matching points is not strictly necessary, except in the case of multiplexes. That said, IMO I DO think it is good practice, and make sure to do so myself. (It can be useful if, say, a new route comes along that hops off a multiplex with one route and onto the other...)

And in some places, there are intentional differences to break what would be false concurrencies otherwise.

"Waypoint editor" is another to-do list item. It's possible to craft route files without one, then use one of Jim's programs to double-check the result. But the waypoint editor we were using lately (internally, access limited to the CHM team) streamlined things by combining those steps.

Jim's Viewer used the Google v.2 API, which has been discontinued. Thus the viewer no longer works; I don't believe he's made any updates to the v.3 API. The viewer is a lot less useful with the advent of the JavaScript waypoint editor anyway.

I'd be happy to implement or help out with a new HB and/or waypoint editor, if we wind up not being able to use or feel comfortable using Tim's code.  Much of what I have here: http://courses.teresco.org/chm/viewer/ is based on Tim's code (with his permission) but it has evolved and continues to evolve. I think I understand everything well enough to implement new and improved versions of the tools we need for this project as time permits.

Finally, in response to the idea of rail or municipal data sets, one of the great things about a project being open is that someone could take a copy of the project and add whatever they want, and the mainline project can bring in or not as those who manage it see fit.

[Dr Frankenstein]

Didn't A-920 get dropped due to being unsigned?

And because we weren't sure it existed even on paper. Since all the (other) A-routes are signed, that leaves Interstates as the only system that explicitly includes unsigned routes.

It doesn't exist except in a (now removed, I believe) dubious Wikipedia claim. It appears as R-201 on signage, reference markers and also in the MTQ's GIS (which includes every scrap of pavement that they maintain or even used to maintain, signed or not; kind of like what MD and HI do as oscar mentioned). No mention of 00920 anywhere, even in the multiplex fields.

[Thing 342]

If people want the /data folder as-online for work on 1-3 then message me and I can sent it to you, saving the trouble of scraping the site. The mapviews folders are too big to email, but the rest is about 8MB.

Mind sending me a copy?

[NE2]

It doesn't exist except in a (now removed, I believe) dubious Wikipedia claim.

I just removed it. I ran the French Wikipoo article through Google Translate and it basically says that it doesn't exist but it could or maybe these other short freeways would also make sense as 920. Yeah.

[english si]

And because we weren't sure it existed even on paper. Since all the (other) A-routes are signed, that leaves Interstates as the only system that explicitly includes unsigned routes.

And International E roads (which also contains unoffical, but signed, routes).

Re matching points - it's hard to keep track of changing them when you peer review (certainly that's where the 99% of NMPs in the British A roads system come from, with the other 1% being to deal with false currencies), especially if there are weird concurrencies that you forgot about and don't appear on mapping as such. However, I hate non-matching points other than the false concurrency thing.

[NE2]

unoffical, but signed, routes

Unless they were ninjasigned, signage makes them official at some level. If you mean not official at the European level, Interstates and U.S. Routes include some at the federal level (east quarter of I-695 Maryland, US 377 Oklahoma).

[Jim]

Re: the non-matching points for intersections, I have a program that I used to remove all such errors from regions I was responsible for.  There is a manual step, though, since we do want to make sure points that are intentionally distinct remain so.

[SD Mapman]

Before anyone invests much time in generating new .wpt files, I think they should be well aware of the naming conventions, tools, point density guidelines, guidelines for when to insert shaping points, etc.  Of course, a new system might change some of those rules but the existing ones work pretty well, in my opinion, and should be used as a starting point.  Also, make sure you're using public sources (i.e., not Google Maps), and are keeping track of those sources.

Seconded on all points.

If some of the experienced collaborators have any spare time while we wait for the old site to come back to life or a new site to be designed and implemented, I think a great use of that time would be to train up some interested people in how to do this.

I'm interested, so how will that work?

[hbelkins]

I'd be happy to implement or help out with a new HB

Make the new one rich and handsome! 

[rickmastfan67]

Didn't A-920 get dropped due to being unsigned?

And because we weren't sure it existed even on paper. Since all the (other) A-routes are signed, that leaves Interstates as the only system that explicitly includes unsigned routes.

The US highways have a few a well.  Consider the 'unsigned' segment of US-74 on I-75 down to I-24.  It isn't signed, but is well documented on official TDOT maps, and is officially approved per the AASHTO.

Same with the Southern end of US-41 in FL.  FDOT acknowledges it in everything on maps and stuff, just no longer posts it past US-1.

[yakra]

If some of the experienced collaborators have any spare time while we wait for the old site to come back to life or a new site to be designed and implemented, I think a great use of that time would be to train up some interested people in how to do this.

My fear is that once we finally have the site ready to go live, facing a massive deluge of data from all sides to ingest & incorporate. First the data as it exists on the site now, then updates/fixes/changes from the past several months, then a potential flood of new data. It could get pretty crazy. Also, we'd have to properly communicate and keep track of who's-doing-what, so as not to duplicate effort; no sense having Bob and Joe both work on the Manitoba Primary Provincial Highways independently without one another's knowledge. (Especially when I've already got`em half done. )
Are we ready for this? Is it biting off more than we can chew?

[oscar]

The US highways have a few a well.  Consider the 'unsigned' segment of US-74 on I-75 down to I-24.  It isn't signed, but is well documented on official TDOT maps, and is officially approved per the AASHTO.

Same with the Southern end of US-41 in FL.  FDOT acknowledges it in everything on maps and stuff, just no longer posts it past US-1.

But those aren't isolated segments, just continuations of otherwise signed routes.  Different from, say, Maryland I-595 which is unsigned for its entire length.

[NE2]

So how's Alabama/Florida/Tennessee handled? They have routes with signed portions and unsigned 'carrier' portions on U.S. Routes, as well as routes that are entirely unsigned for the same reason.

[rickmastfan67]

So how's Alabama/Florida/Tennessee handled? They have routes with signed portions and unsigned 'carrier' portions on U.S. Routes, as well as routes that are entirely unsigned for the same reason.

Well, for the Florida State routes, I was doing the entire route first if it had any part of it signed.  However, Tim had me change that to only segments that were signed, which needed separate files for routes that had more than 1 individual segment signed (like FL-20).

[yakra]

So how's Alabama/Florida/Tennessee handled? They have routes with signed portions and unsigned 'carrier' portions on U.S. Routes, as well as routes that are entirely unsigned for the same reason.

AL & TN state route systems were never begun. No decision had to be made, so AFAIK it was never looked at.

[SD Mapman]

AL & TN state route systems were never begun. No decision had to be made, so AFAIK it was never looked at.

Did anyone ever start anything on Wyoming?