Is the Clinched Highway Mapping site still active?

[yakra]

How about the option of editing the .list via a form instead of uploading?

[Sub-Urbanite]

Is it really needed though? The County Counting site seems to do relatively fine without much adult supervision.

[oscar]

Is it really needed though? The County Counting site seems to do relatively fine without much adult supervision.

I agree, the county counting site (mob-rule.com) does the things I outlined above with minimal human involvement, except it doesn't process user files so the virus/malware-checking function isn't needed there.

CHM has at least four users with over 4000 lines in their list files, and many others have over a thousand. They should not have to re-enter their data manually via an interactive interface (far more complex than mob-rule.com's, which only has to deal with about 3600 data points). So a CHM successor should retain some file submission capability for the sake of backward compatibility, and also until it is supplemented (my preference) or replaced with a new interactive interface after key existing CHM features are replicated and working smoothly. 

[hbelkins]

Is it really needed though? The County Counting site seems to do relatively fine without much adult supervision.

And it's also clickable.

[sipes23]

Is it really needed though? The County Counting site seems to do relatively fine without much adult supervision.

I agree, the county counting site (mob-rule.com) does the things I outlined above with minimal human involvement, except it doesn't process user files so the virus/malware-checking function isn't needed there.

CHM has at least four users with over 4000 lines in their list files, and many others have over a thousand. They should not have to re-enter their data manually via an interactive interface (far more complex than mob-rule.com's, which only has to deal with about 3600 data points). So a CHM successor should retain some file submission capability for the sake of backward compatibility, even if an interactive interface were added as an option.

Would it be possible to scrape the old .list files from the current CHM site and import them as-is? Then when the new site is open, allow for old users to claim their data with zero reentry. Of course, I have zero idea what programming *that* would take.

[Thing 342]

Is it really needed though? The County Counting site seems to do relatively fine without much adult supervision.

I agree, the county counting site (mob-rule.com) does the things I outlined above with minimal human involvement, except it doesn't process user files so the virus/malware-checking function isn't needed there.

CHM has at least four users with over 4000 lines in their list files, and many others have over a thousand. They should not have to re-enter their data manually via an interactive interface (far more complex than mob-rule.com's, which only has to deal with about 3600 data points). So a CHM successor should retain some file submission capability for the sake of backward compatibility, even if an interactive interface were added as an option.

Would it be possible to scrape the old .list files from the current CHM site and import them as-is? Then when the new site is open, allow for old users to claim their data with zero reentry. Of course, I have zero idea what programming *that* would take.

Not much. The existing .list files are machine parsable.

[Wadsteckel]

Hi Everyone,

I know....should've been here a lot sooner.  For some reason, I thought I was when I wasn't.

Seeing how my life has been in the past year, I can sympathize with Tim and whatever reason he has for having CHM in its current state.  But, with my new career, being able to travel more roads than I could have ever dreamed of doing before, I'm excited to hear that others are planning to try to keep the idea going at a new venue.

Looking forward to see where this journey takes us.

Regards, tonight from Mt. Vernon, IL....
-Ed S

[hbelkins]

Regards, tonight from Mt. Vernon, IL....
-Ed S

How was the Ale-8?

[Duke87]

Before we get too far ahead of ourselves here, let's consider the basics.

1) Rendering maps in Javascript has been done and made to work. Key task: whatever is necessary to make it work for all regions.
2) Calculating stats (mi/km clinched, % clinched) has not been done. Key task: write code that can do this and display the results in a webpage.
3) We don't have a highway browser. Key task: write code that can at least provide a rudimentary highway browser by listing names and coordinates for points and plotting them on a map.
4) We may not be able to use all existing route data. Key task: determine what we can use and recreate what we cannot.
- 4a) Existing data has not been updated in a while. Key task: Fix errors and make necessary updates

Tasks 1, 2, and 3 fall onto people with programming skills. Task 4/4a falls onto anyone who wants to help but cannot program. Anything else is not needed for basic functionality of the service so if it is worked on now it won't be able to be used until after these four things are accomplished.

[rschen7754]

Is it really needed though? The County Counting site seems to do relatively fine without much adult supervision.

Well, all it takes is for one spammer to find the site and add it to their spambot programs... from my experience as a Wikimedia steward, even foreign language Wikipedias in languages you have never heard of get spammed.

[Jim]

Would it be possible to scrape the old .list files from the current CHM site and import them as-is? Then when the new site is open, allow for old users to claim their data with zero reentry. Of course, I have zero idea what programming *that* would take.

Not much. The existing .list files are machine parsable.

Right - it would be pretty much trivial to write something to convert .list files to data in whatever format a new project uses (assuming it does not use .list).

[vdeane]

The thing is, some of us have up to date .list files on our hard drives, but woefully out of date CHM pages.  Some of us also maintained data for systems not yet activated in separate .list files.

[Jim]

The thing is, some of us have up to date .list files on our hard drives, but woefully out of date CHM pages.  Some of us also maintained data for systems not yet activated in separate .list files.

I see no reason those couldn't also be converted, should that become necessary.

[Thing 342]

Before we get too far ahead of ourselves here, let's consider the basics.
...
3) We don't have a highway browser. Key task: write code that can at least provide a rudimentary highway browser by listing names and coordinates for points and plotting them on a map.
...

I was working on a few rudimentary concepts for this earlier, but got stuck on how to store the waypoint data. Can anyone send me a sample of the waypoint data currently provided to CHM for me to look at?

[yakra]

CHM has at least four users with over 4000 lines in their list files, and many others have over a thousand. They should not have to re-enter their data manually via an interactive interface ... So a CHM successor should retain some file submission capability for the sake of backward compatibility, and also until it is supplemented (my preference) or replaced with a new interactive interface after key existing CHM features are replicated and working smoothly.

Using a form to edit the list data, as opposed to uploading, shouldn't be too painful. Copy your existing .list file from a text editor, paste into the form, and blammo!
Count me as another in favor of eventually supplementing list editing with a clickable interface, but not replacing.

Would it be possible to scrape the old .list files from the current CHM site and import them as-is? Then when the new site is open, allow for old users to claim their data with zero reentry. Of course, I have zero idea what programming *that* would take.

Possible, yes. Easy, even. But would we want to? I think it would be wiser to let old users decide for themselves whether they want to participate on any new site.

Before we get too far ahead of ourselves here, let's consider the basics.

1) Rendering maps in Javascript has been done and made to work. Key task: whatever is necessary to make it work for all regions.

It should already work for all regions. The only hangup would be maps straddling 180 degrees longitude. But, how likely is this to show up in any real world situations on the maps? We can likely sweep this under the rug for a good while.

2) Calculating stats (mi/km clinched, % clinched) has not been done. Key task: write code that can do this and display the results in a webpage.

Multiplex detection makes this more complicated than it seems at first glance. But it's nothing insurmountable.

3) We don't have a highway browser. Key task: write code that can at least provide a rudimentary highway browser by listing names and coordinates for points and plotting them on a map.

This should actually be pretty easy to do. At least, making the equivalent of hwymap.php. I made a program back in the day to parse a .WPT file and spit out a hwy browser map page. But, that was with the Google Maps API v.2, which has since been deprecated in favor of v.3. Still though -- piece of cake. View Source is our friend.
The equivalent of selecthwys.php, I've never really given any thought to. This will be dependent on a database of route systems, regions and subregions.

4) We may not be able to use all existing route data. Key task: determine what we can use and recreate what we cannot.

To clarify: are you just thinking in terms of data that may not be OKed by its original creator (most notably, Tim, potentially) for use in a new site?
Or are you also concerned about early route data created from commercial tile maps? Back in 2010, we made the decision to switch to OSM to avoid potentially running afoul of commercial map services' terms of use. But older data, E.G. the U.S. Interstates, were still left in the system as-is, and not remade from scratch using OSM data.

4a) Existing data has not been updated in a while. Key task: Fix errors and make necessary updates

For my part, I've kept on top of changes to the regions that I maintain. I believe some other(s) upthread said they've been doing the same. (Si and/or Oscar?)


Regarding storing a user's clinch data in a format other than a .list, or pretty close functional equivalent... We would have to take care to avoid corrupting a user's data to the greatest extent possible in cases of a route being truncated, or relocated at the end or in the middle, especially in cases where new waypoints are added. Nota Bene.

[SD Mapman]

4) We may not be able to use all existing route data. Key task: determine what we can use and recreate what we cannot.
- 4a) Existing data has not been updated in a while. Key task: Fix errors and make necessary updates

I can help with that; that is, if you'd like me to.

[rickmastfan67]

4) We may not be able to use all existing route data. Key task: determine what we can use and recreate what we cannot.

To clarify: are you just thinking in terms of data that may not be OKed by its original creator (most notably, Tim, potentially) for use in a new site?
Or are you also concerned about early route data created from commercial tile maps? Back in 2010, we made the decision to switch to OSM to avoid potentially running afoul of commercial map services' terms of use. But older data, E.G. the U.S. Interstates, were still left in the system as-is, and not remade from scratch using OSM data.

I know I overhauled every Interstate in a state that I was responsible for when I cleaned up US Highways.  So, my states should be a-ok in that part.

I know PA would need to be completely redone since Tim has had full control of that state from the start.

[english si]

4) We may not be able to use all existing route data. Key task: determine what we can use and recreate what we cannot.

To clarify: are you just thinking in terms of data that may not be OKed by its original creator (most notably, Tim, potentially) for use in a new site?
Or are you also concerned about early route data created from commercial tile maps? Back in 2010, we made the decision to switch to OSM to avoid potentially running afoul of commercial map services' terms of use. But older data, E.G. the U.S. Interstates, were still left in the system as-is, and not remade from scratch using OSM data.

4a) Existing data has not been updated in a while. Key task: Fix errors and make necessary updates

For my part, I've kept on top of changes to the regions that I maintain. I believe some other(s) upthread said they've been doing the same. (Si and/or Oscar?)

I have.

And I began to make a start on Tim's European regions, starting with mere updates and overhauling files I had to update for that and pushing on to a total overhaul of all routes whether they needed updates or not. I also did a (fairly minor as it was mostly OK) overhaul of Indiana when I made the state route files. I'd be happy to re-enter Tim's European systems totally if that was what was needed, but I'd much rather have it that we seek his permission as that's going to take a long time for me to remake 81,380.7 miles of data! Given Tim has probably the same amount in North America. And like a gazillion miles of borders (I have Ireland totally redone, did the Isle of Man and Jersey. Drop in the Ocean. Though I'd argue strongly that we don't need Russian/Kazakh subregions, though you would have a couple of big files in Russia like a couple of other routes - US101 in CA and Norway's E6 for instance. I'd also do away with GB ones other than the issues that would cause with .list files and I have border files anyway!) that just makes it more important.

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.

[english si]

I was working on a few rudimentary concepts for this earlier, but got stuck on how to store the waypoint data. Can anyone send me a sample of the waypoint data currently provided to CHM for me to look at?

Here is the Isle of Man's TT Circuit's .wpt file that I made (though as an unsigned route, it won't make it onto the site). It forms a loop.

Code Select Expand

Start http://www.openstreetmap.org/?lat=54.168087&lon=-4.477819
A1/A2 http://www.openstreetmap.org/?lat=54.155687&lon=-4.501305
A5 http://www.openstreetmap.org/?lat=54.155976&lon=-4.501841
A6_E http://www.openstreetmap.org/?lat=54.161366&lon=-4.504952
A6_W http://www.openstreetmap.org/?lat=54.161881&lon=-4.506884
A26 http://www.openstreetmap.org/?lat=54.177105&lon=-4.554455
A23 http://www.openstreetmap.org/?lat=54.183836&lon=-4.565935
A1/A3 http://www.openstreetmap.org/?lat=54.202730&lon=-4.629149
A20 http://www.openstreetmap.org/?lat=54.210373&lon=-4.630373
+X01 http://www.openstreetmap.org/?lat=54.219331&lon=-4.630566
BraRd http://www.openstreetmap.org/?lat=54.260512&lon=-4.581513
+X02 http://www.openstreetmap.org/?lat=54.274146&lon=-4.579496
A4 http://www.openstreetmap.org/?lat=54.280986&lon=-4.588122
+X03 http://www.openstreetmap.org/?lat=54.301326&lon=-4.567909
A10 http://www.openstreetmap.org/?lat=54.309776&lon=-4.541345
A14_N http://www.openstreetmap.org/?lat=54.319452&lon=-4.491863
A17 http://www.openstreetmap.org/?lat=54.323031&lon=-4.472895
B14 http://www.openstreetmap.org/?lat=54.319978&lon=-4.446287
A3/A18 http://www.openstreetmap.org/?lat=54.322168&lon=-4.386742
A2_N http://www.openstreetmap.org/?lat=54.321054&lon=-4.385262
+X04 http://www.openstreetmap.org/?lat=54.312893&lon=-4.385004
+X05 http://www.openstreetmap.org/?lat=54.312893&lon=-4.376206
+X06 http://www.openstreetmap.org/?lat=54.305858&lon=-4.381614
+X07 http://www.openstreetmap.org/?lat=54.278080&lon=-4.443412
A14 http://www.openstreetmap.org/?lat=54.250847&lon=-4.463110
B10 http://www.openstreetmap.org/?lat=54.242660&lon=-4.471972
+X08 http://www.openstreetmap.org/?lat=54.213786&lon=-4.479547
B12 http://www.openstreetmap.org/?lat=54.207436&lon=-4.466522
+X09 http://www.openstreetmap.org/?lat=54.195738&lon=-4.477444
A21 http://www.openstreetmap.org/?lat=54.183108&lon=-4.475470
A2/A18 http://www.openstreetmap.org/?lat=54.171742&lon=-4.467809
Finish http://www.openstreetmap.org/?lat=54.168087&lon=-4.477819

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

[Jim]

I've been considering how the code and data for a new site should be managed, in terms of source code control.  I'm a very regular user of subversion, but I think git provides a better model for this.  If we were to house the project at Github, anyone interested could clone copies of the repository, and a relatively small number of people could commit changes back to the official copy on Github.  I think this model would work especially well for highway data, as anyone could have a copy, make changes, and submit a push request for which could then be pulled into the mainline if appropriate.  People could also essentially file "bug reports" for data that would be tracked and hopefully corrected just like software errors, then they or someone else could propose the actual fix.

I'm interested in learning more about Github anyway (in fact, my software engineering students are currently working through a lab that introduces them to the basics), and would be willing to invest some time in coming up with a proposed model for this, if it seems to others like a reasonable way to proceed.

[Thing 342]

I was working on a few rudimentary concepts for this earlier, but got stuck on how to store the waypoint data. Can anyone send me a sample of the waypoint data currently provided to CHM for me to look at?

Here is the Isle of Man's TT Circuit's .wpt file that I made (though as an unsigned route, it won't make it onto the site). It forms a loop.

Code Select Expand

Start http://www.openstreetmap.org/?lat=54.168087&lon=-4.477819
A1/A2 http://www.openstreetmap.org/?lat=54.155687&lon=-4.501305
A5 http://www.openstreetmap.org/?lat=54.155976&lon=-4.501841
A6_E http://www.openstreetmap.org/?lat=54.161366&lon=-4.504952
A6_W http://www.openstreetmap.org/?lat=54.161881&lon=-4.506884
A26 http://www.openstreetmap.org/?lat=54.177105&lon=-4.554455
A23 http://www.openstreetmap.org/?lat=54.183836&lon=-4.565935
A1/A3 http://www.openstreetmap.org/?lat=54.202730&lon=-4.629149
A20 http://www.openstreetmap.org/?lat=54.210373&lon=-4.630373
+X01 http://www.openstreetmap.org/?lat=54.219331&lon=-4.630566
BraRd http://www.openstreetmap.org/?lat=54.260512&lon=-4.581513
+X02 http://www.openstreetmap.org/?lat=54.274146&lon=-4.579496
A4 http://www.openstreetmap.org/?lat=54.280986&lon=-4.588122
+X03 http://www.openstreetmap.org/?lat=54.301326&lon=-4.567909
A10 http://www.openstreetmap.org/?lat=54.309776&lon=-4.541345
A14_N http://www.openstreetmap.org/?lat=54.319452&lon=-4.491863
A17 http://www.openstreetmap.org/?lat=54.323031&lon=-4.472895
B14 http://www.openstreetmap.org/?lat=54.319978&lon=-4.446287
A3/A18 http://www.openstreetmap.org/?lat=54.322168&lon=-4.386742
A2_N http://www.openstreetmap.org/?lat=54.321054&lon=-4.385262
+X04 http://www.openstreetmap.org/?lat=54.312893&lon=-4.385004
+X05 http://www.openstreetmap.org/?lat=54.312893&lon=-4.376206
+X06 http://www.openstreetmap.org/?lat=54.305858&lon=-4.381614
+X07 http://www.openstreetmap.org/?lat=54.278080&lon=-4.443412
A14 http://www.openstreetmap.org/?lat=54.250847&lon=-4.463110
B10 http://www.openstreetmap.org/?lat=54.242660&lon=-4.471972
+X08 http://www.openstreetmap.org/?lat=54.213786&lon=-4.479547
B12 http://www.openstreetmap.org/?lat=54.207436&lon=-4.466522
+X09 http://www.openstreetmap.org/?lat=54.195738&lon=-4.477444
A21 http://www.openstreetmap.org/?lat=54.183108&lon=-4.475470
A2/A18 http://www.openstreetmap.org/?lat=54.171742&lon=-4.467809
Finish http://www.openstreetmap.org/?lat=54.168087&lon=-4.477819

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

This looks good enough for my purposes. Quick question, though: what are the +XNN lines used for?

[Jim]

Regarding storing a user's clinch data in a format other than a .list, or pretty close functional equivalent... We would have to take care to avoid corrupting a user's data to the greatest extent possible in cases of a route being truncated, or relocated at the end or in the middle, especially in cases where new waypoints are added. Nota Bene.

I'm hoping we'd end up with the .list files remaining the underlying format even if and when a different interface would be provided for editing a user's data.

There is also another behind the scenes thing that this brings up.  A lot of care was taken as routes were merged, truncated, renamed, etc., to allow users with stale .list files to maintain their stats as much as possible.  This will definitely complicate matters but as long we we're aware of it as a new mechanism for ingesting data into the system is designed and implemented, I think it's manageable.

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

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.  When I plot routes, I ensure this is the case by getting the points for all existing plots of intersecting routes and using those as the starting point for the new .wpt file.  This lets the waypoint editor show me a very rough initial outline to which I add the necessary other points and there it is.

[1995hoo]

The thing is, some of us have up to date .list files on our hard drives, but woefully out of date CHM pages.  Some of us also maintained data for systems not yet activated in separate .list files.

To some degree your first sentence is what prompted me to start this thread. I wouldn't call my CHM page "woefully" out of date, but what made me notice the problem was that I submitted updates after our Christmas trip to Florida and they never posted, even after I submitted them two or three times.

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!

[oscar]

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.