Is the Clinched Highway Mapping site still active?

[oscar]

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?

Not that I know of, though someone might have his eye on that already.

The "in development" systems list for the Highway Browser (which still works) indicates many of the states, etc. where work is in some level of progress, though there are others where work has been done but not posted.

[froggie]

AL & TN state route systems were never begun.

I had informally begun some work on AL a few years ago, but let it lie fallow as I went into 2 years worth of deployments.  AL was never officially begun as yakra noted.

[yakra]

The "in development" systems list for the Highway Browser (which still works) indicates many of the states, etc. where work is in some level of progress, though there are others where work has been done but not posted.

IIRC there was also some unposted work done for GA and VA.
Me, I have the Alberta and Manitoba primary provincial systems roughly 5/6 and 1/2 done respectively. I've also been bad and started some work on Texas.

[Duke87]

Ultimately I think we are going to need some sort of gatekeeping so we don't end up with edit wars, duplicate efforts, and whatnot. I would more or less keep the existing model of having collaborators, but with the following key changes:

- No "we're not accepting any new collaborators right now". Anyone who wants to help and who can be trusted to help competently without stirring drama is welcome to join in.
- All collaborators should be able to upload their own data additions and updates.
- All collaborators should be allowed to claim dibs on one (1) incomplete highway system to work on at a time. In order to claim dibs on another system they must first finish the one they are working on, or upload whatever they have finished and surrender dibs to it. Additionally, a collaborator will surrender their dibs if they go inactive for more than some period of time.
- Decisions about what a system should or shouldn't include when it becomes ambiguous should be made by community consensus, like Wikipedia does. Collaborators and ordinary users should be afforded equal input on such decisions.

[rschen7754]

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?

As I said in a previous post, I have experience with project management.  It's a matter of organization and prioritizing and doing a little bit at a time.  CHM was not built in a day and neither will this new site.  I volunteer my expertise, because as I also said, I'm not an expert in terms of the type of programming that is involved with this.

If whomever does this tries to do it all in one fell swoop, it will fail.

Probably better to break it down into pieces with tangible milestones. i.e.

1) Get the Interstate Highway System working, that's what people care about most. Use the text files.
2) Start building a base of participants, and get some more highway systems back up and running.
3) Start thinking of alternative modes of data entry.

etc.

[CNGL-Leudimin]

And don't forget about European roads! Since I've never been to the US I would have a mileage of zero if the new site sticks only to America.

[english si]

- All collaborators should be allowed to claim dibs on one (1) incomplete highway system to work on at a time. In order to claim dibs on another system they must first finish the one they are working on, or upload whatever they have finished and surrender dibs to it. Additionally, a collaborator will surrender their dibs if they go inactive for more than some period of time.

One? I find the two currently existing constrictive! Does finish it include peer review?

Everything else makes sense.

yakra - bad for starting a third system? I've got about 10 systems fully done beyond the official five I have awaiting peer review and about another 10 part done.

[oscar]

I would more or less keep the existing model of having collaborators, but with the following key changes:

- No "we're not accepting any new collaborators right now". Anyone who wants to help and who can be trusted to help competently without stirring drama is welcome to join in.

What about initially, when the project is still getting on its feet and getting to the stage where it can take on new collaborators?  "Showing the ropes" to new team members means more work for existing team members, so there's something to be said about being selective at the start (such as to focus on filling in any gaps in programming expertise) until the new project's past its launch phase.

Or when the team is fully built out, and starts getting larger than is needed for the work to be done?  At some point, it gets hard to keep everybody on the same page.  Kind of like how over-large corporate boards are notoriously ineffective decision-making bodies (sometimes intentionally, to keep the real decision-making power in the hands of corporate management), with many members there just for show.

I have no doubt that the optimal team size is larger than what CHM has now, but it stops well short of infinity.

[yakra]

If whomever does this tries to do it all in one fell swoop, it will fail.

Probably better to break it down into pieces with tangible milestones. i.e.

1) Get the Interstate Highway System working, that's what people care about most. Use the text files.
2) Start building a base of participants, and get some more highway systems back up and running.
3) Start thinking of alternative modes of data entry.

etc.

I see it a bit differently:

1) Get the DB, new HB and stats working. Once] this framework is in place, it'll be a snap to add back all the existing systems. Interstate, US, European, state, everything. Then, add the more specific features to the site's functionality.
2) Take care of the backlog of updates and fixes to the existing systems that have been piling up since summer.
3) Add in new systems that have been ready to go since then.
4) Build base of participants, more highway systems
5) Start thinking of alternative modes of data entry.

Alternate modes of entry is marked as #5 here, but really, I envision two processes happening in parallel:
* updates and additions to site features / functionality / back-end
* data updates (new systems, changes to existing systems)

One? I find the two currently existing constrictive! Does finish it include peer review?

I also find the current limit of two restrictive. Informally at least, I'd say peer review is not included. I know that you and I at least started a 3rd system while a 1st was only waiting on peer review before activation, and were never called out.

Everything else makes sense.

Agreed. And I want to emphasize:

- Decisions about what a system should or shouldn't include when it becomes ambiguous should be made by community consensus, like Wikipedia does. Collaborators and ordinary users should be afforded equal input on such decisions.

This. If we had such a model in place on the existing project, Vermont would have been included for ages.

yakra - bad for starting a third system? I've got about 10 systems fully done beyond the official five I have awaiting peer review and about another 10 part done.

Well, a 4th system if you count that USAVT was still not activated. Leaving that out (call it peer review?), yes, a 3rd.
Texas of course, would be two or three systems: State Highways one system, and loops & spurs would either be another system or systems #2 & 3.
10 whole systems, huh? Holy cow. Which ones are they?

[english si]

What about initially, when the project is still getting on its feet and getting to the stage where it can take on new collaborators?  "Showing the ropes" to new team members means more work for existing team members, so there's something to be said about being selective at the start (such as to focus on filling in any gaps in programming expertise) until the new project's past its launch phase.

Yes, I'd keep the team fairly small to begin with. Yakra's plan works well, IMO.

yakra - bad for starting a third system? I've got about 10 systems fully done beyond the official five I have awaiting peer review and about another 10 part done.

Well, a 4th system if you count that USAVT was still not activated. Leaving that out (call it peer review?), yes, a 3rd.
Texas of course, would be two or three systems: State Highways one system, and loops & spurs would either be another system or systems #2 & 3.
10 whole systems, huh? Holy cow. Which ones are they?

Complete systems or subsystems (13) - Andorra CG roads, Belgium B Roads, Belgium R Roads, Denmark Primary Routes, Hong Kong Routes, Lithuanian A roads, Latvian A Roads, Singapore Expressways, Colorado State Routes, Indiana State Routes, Wyoming State Routes, Asian Highways (part: Turkey, Georgia, Armenia, Azerbaijan, Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Singapore, Hong Kong), Yellowstone's roads (for the long-proposed usanp system).

Partially complete systems (about 20!), mostly involving more European phase 3 systems (Netherlands N roads, French N roads (which is several systems due to the DOM-TOMs), Moldova M roads, Ukraine M roads, Europe grab bag second tier routes, Finnish Kt roads, Finnish Vt roads, Aaland Vt roads, Aaland Kt roads, Montana secondary state routes, Estonia T roads, Scottish National Tourist Routes, Romania DN roads, Malta roads, Virgin Islands territory routes, Morocco A roads, Algeria A roads, Tunisia A roads, Malaysia E roads)

Most of that comes from having a lot of regions and Europe phase 3 not happening. Some of these were done well over 2 years ago. And a lot of the European ones are small systems with a lot of overlap with the E road network.

[Jim]

I see it a bit differently:

1) Get the DB, new HB and stats working. Once this framework is in place, it'll be a snap to add back all the existing systems. Interstate, US, European, state, everything. Then, add the more specific features to the site's functionality.
2) Take care of the backlog of updates and fixes to the existing systems that have been piling up since summer.
3) Add in new systems that have been ready to go since then.
4) Build base of participants, more highway systems
5) Start thinking of alternative modes of data entry.

Alternate modes of entry is marked as #5 here, but really, I envision two processes happening in parallel:
* updates and additions to site features / functionality / back-end
* data updates (new systems, changes to existing systems)

This is almost exactly what I was intending to reply this evening.  I don't see any need to bring in existing systems piecemeal, other than ones we are not comfortable importing because of lack of permissions.  But I also think the majority of those could be re-created before we'd be in a position to make use of the data in a new system anyway.

[Bickendan]

I'd request that the US Highways that have exit numbers have those tags switched when they get imported.

[rickmastfan67]

I'd request that the US Highways that have exit numbers have those tags switched when they get imported.

I agree with this except for one case.  When they only have just 'letters' for the exit (like US-422 has in 2 places in PA).  If just letters for the exit, leave as original label.

I would more or less keep the existing model of having collaborators, but with the following key changes:

- No "we're not accepting any new collaborators right now". Anyone who wants to help and who can be trusted to help competently without stirring drama is welcome to join in.

What about initially, when the project is still getting on its feet and getting to the stage where it can take on new collaborators?  "Showing the ropes" to new team members means more work for existing team members, so there's something to be said about being selective at the start (such as to focus on filling in any gaps in programming expertise) until the new project's past its launch phase.

Or when the team is fully built out, and starts getting larger than is needed for the work to be done?  At some point, it gets hard to keep everybody on the same page.  Kind of like how over-large corporate boards are notoriously ineffective decision-making bodies (sometimes intentionally, to keep the real decision-making power in the hands of corporate management), with many members there just for show.

I have no doubt that the optimal team size is larger than what CHM has now, but it stops well short of infinity.

I agree with what another person said about starting with interstates first ... then what about U.S. highways followed by the state highways?  (I'm not forgetting about our non-U.S. friends -- we can address those in parallel).  To me, each state should be assigned to a person (or two at most) who are responsible for all changes in that state at all highway levels.  There should also be a "Board of Collaborators" where at most we have 4-5 people who each oversee a region and the overall direction of the site (I don't want to be one of these people).  What does "oversee" mean in this case?  I'm not sure yet.  But to me, this eliminates having 50 people in charge and also eliminates a one-man show, which is how we got to this current dilemma.

Just a thought.

Well, all my states (Interstates + US Highways) will be ready to go right away minus some fixes that need to be done to the US highways in SC.  Plus, I was in the middle of fixing up all the TN US Highways before Tim stopped adding new files to the site.  So, I would still need to finish cleaning up those (which shouldn't be too many).

Also, since Tim took over KY from me, we would have to redo all the State Highways.  However, the Interstates and US Highways should be fine as is (minus having to redo the new US-127 Bypass around Albany,KY at minimum), as I overhauled them before Tim started on the State Highways.  If push comes to shove, I still have my copies from before he took over KY that we could put up and then go from there if need be.

[Duke87]

One? I find the two currently existing constrictive! Does finish it include peer review?

I also find the current limit of two restrictive. Informally at least, I'd say peer review is not included. I know that you and I at least started a 3rd system while a 1st was only waiting on peer review before activation, and were never called out.

My line of thinking is that if the new site is more open the number of collaborators will increase dramatically. What I don't want to have happen is people calling dibs on a bunch of things but then not putting much effort into working on any of them, so they don't get done, while in the meantime someone else would eagerly work on them if they were permitted to. Requiring that everyone finish the system they are currently building before they start a new one ensures that everyone gets a shot at something while at the same time also minimizing systems getting locked in limbo and therefore helping things get done more quickly.

With the existing site I have already seen systems stay "in development" seemingly perpetually because the person doing it is short on spare time in which to work on it. With an open collaborator system I can only see this becoming a more frequent problem which will ruin the project if it isn't kept in check. Therefore we need a mechanism to minimize how much anyone can monopolize, and also a mechanism to take it away from them if they aren't making progress and someone else wants to work on it.

Either that, or we need a mechanism for multiple people to be able to work on the same system simultaneously.

I haven't been involved in system building so maybe you know something I don't, but what is the reasoning behind having someone work on multiple systems at a time? Is it simply a question of "I feel like working on something different today", or...?

It's also entirely possible that I'm overestimating how much the group of collaborators will grow and this won't really be an issue.

[oscar]

One? I find the two currently existing constrictive! Does finish it include peer review?

I also find the current limit of two restrictive. Informally at least, I'd say peer review is not included. I know that you and I at least started a 3rd system while a 1st was only waiting on peer review before activation, and were never called out.

My line of thinking is that if the new site is more open the number of collaborators will increase dramatically.

My line of thinking (which is by no means the last word on this) is that the number of collaborators will increase gradually. No more drama, please!

I haven't been involved in system building so maybe you know something I don't, but what is the reasoning behind having someone work on multiple systems at a time? Is it simply a question of "I feel like working on something different today", or...?

There is something to be said for getting the most out of collaborators who already know the routine, and can easily handle developing more than one system at once, at least until new collaborators are brought up to speed and can take on more of the new system development.

With the existing site I have already seen systems stay "in development" seemingly perpetually because the person doing it is short on spare time in which to work on it.

Some of this is logjams at the webmaster level, which a new project hopefully will clear up, with several states, etc. close enough to be brought online quickly once a new site is up and running, or if the old site comes back to life. Some of this is people who've dropped out of the existing project, but their partially-completed systems would be candidates for someone to complete once the team were expanded. Some "miscellaneous" sets under development (such as the "select" Canada systems) might get absorbed into other new sets, either under development or yet to be assigned.

I expect a lot of reshuffling and new assignments to take place. But not right away, there is a ton of other stuff to do first.

[english si]

My line of thinking is that if the new site is more open the number of collaborators will increase dramatically. What I don't want to have happen is people calling dibs on a bunch of things but then not putting much effort into working on any of them, so they don't get done, while in the meantime someone else would eagerly work on them if they were permitted to.

Yep that is a problem.

Requiring that everyone finish the system they are currently building before they start a new one ensures that everyone gets a shot at something while at the same time also minimizing systems getting locked in limbo and therefore helping things get done more quickly.

I see your point, but the limit of two seems fine (provided you don't count peer review). The issue has not been people doing half a system then starting and finishing multiple systems having abandoned the other system.

The issue that people have started a single system and not having time to finish it.

With the existing site I have already seen systems stay "in development" seemingly perpetually because the person doing it is short on spare time in which to work on it.

And the peer review process taking far too long...

and also a mechanism to take it away from them if they aren't making progress and someone else wants to work on it.

This for sure, but not the other one.

Either that, or we need a mechanism for multiple people to be able to work on the same system simultaneously.

That won't work, unless you have a multi-region system you can split into subsystems (Interstates, TCH, E roads, US routes, etc).

I haven't been involved in system building so maybe you know something I don't, but what is the reasoning behind having someone work on multiple systems at a time? Is it simply a question of "I feel like working on something different today", or...?

Partially. Certainly I could have spent some time yesterday sorting out or two of the remaining 4 Russian E roads I have left to do (E22, E30, E38, E40), but I was sick and tired of dealing with the vast emptiness of the former USSR, so sorted out Albania, Macedonia, Kosovo and Bosnia's files instead. If I was creating files (rather than overhauling/updating them) and had the choice of Russian E Roads or nothing then I would have done nothing.

It's a bit like George RR Martin - while he's working on the main ASOIAF series, he gets stuck, or frustrated, or whatever and in those periods, he turns out other material, be it World-building History, a Novella or a Game of Thrones episode's script. Many fans are fed up with him not focusing entirely on the main novels, but the novels aren't delayed by the other stuff - the other stuff probably spurs on his work on the main novels.

My own partially finished systems are mostly beginnings I made from concurrent segments, with a bit more done and then as there was no prospect of publishing and there were other things to do, I left them (the reason I made them was my own personal understanding of that country's road system). Personally, if someone else wants to do them from scratch, I don't have a problem (and I'm very willing to give up regions - I'm certainly aiming to drop US states when their state routes get activated and there's someone suitable to maintain them). And if there is a new site (as this won't happen on the old site reborn) where I can publish them, I could spend an hour on the smaller systems and finish them, or an evening or two on the larger systems (and about a week on the Dutch N roads), and within 6 weeks or so, they are all done (save perhaps Russian AH routes). The backlog will be peer review, as I've found ever since the JS .wpt editor made making files much much quicker and easier!

I expect a lot of reshuffling and new assignments to take place. But not right away, there is a ton of other stuff to do first.

Indeed. My focus is getting existing systems up-to-date.

[vdeane]

I've been curious about what/when the next step might be as well.  CHM is something that's been on my mind, especially since I just clinched a bunch of roads on meets.

[1995hoo]

I have pretty much zero programming skills. The last time I remember writing any sort of program was during my junior year of high school to solve a math problem when I didn't want to sit around writing out all the numbers, so I wrote a short BASIC program and handed it in as "showing my work" (the teacher gave me credit). But if there is something non-programmers could do to help out, I'd consider trying to do so if it's something I'm able to do. I've been keeping my listing up-to-date and, as vdeane says, it was on my mind as I was looking at maps planning a trip for later this year (mentioned on the Road Trips subforum).

[rschen7754]

Have there been recent efforts made to contact Tim?

[yakra]

Not related to any of the last few posts, but some thoughts I've had kicking around for a couple weeks to follow up on my March 6th post...

I think the first version of a new site to go online should have the same data, the same points and labels, as the existing site as it is now.

Why? To avoid breaking .list files.
I have for one (and other collabs, I'm sure) have been dutifully maintaining the highway files for my regions over the past few months while the data on-site remains static. Sometimes this means changing point labels. If the labels weren't in use in someone's .list file at the time, I just changed the label without leaving the old one in as a hidden, deprecated label.

Meanwhile, a bunch of travelers have been updating their list files, based on the old & moldy data still in the HB. Potentially using these deprecated point labels that have been replaced in our local files.
If all our updated highway data and all everyone's updated .list files all hit the new site at about the same time, travelers could find that some of the waypoint labels have suddenly changed out from under them, resulting in errors and broken .list files.

Thus, I think it best that we should get the existing data on site first, then allow some time to get the site populated with people's .list files. Then, we can have the latest bleeding-edge labelsinuse data, in order to tweak our updates that have been waiting in the wings, to beep the breaking of .list files to a minimum.

[Jim]

I think the first version of a new site to go online should have the same data, the same points and labels, as the existing site as it is now.

I hate to see all of the potential fixes and additions to the data have to wait, but I do think it makes a lot of sense to wait for data updates until a at least a skeleton of a new system is live and people can see their travels and stats against the current data.

[english si]

I'd agree with keeping it Aug '14 while testing.

However .list file changes made without seeing the files are guesses as to what the point would be called. If it's a required point, then the guessed label can be informed and is likely correct*. If it's a additional visible point, then (for the same reason we don't take point requests) tough if they haven't got it. Having up to date points in use makes little sense given that people have been updating files since June (when the last processed submission was sent) and have already broken the .list files that they didn't have.

I say add them before the site goes live (eg non-collaborator .list file updates), like a week before, and people could just check the massive list of what the updates (9 months worth and counting...) are before submitting an up-to-date list file after the site launches.

Links to the right Browser file on the updates page would make this much easier and wouldn't be too onerous to sort out some way of automating it via fields in a form that collaborators use to update it

*Though I remember having a debate as to whether we should preempt this, and I used hidden labels so deal with this sort of thing "I took the A22 from the A271 to the A2290 that's ENG A22 A271 A2290", but Tim wanted it that you had to look at the browser and so the points should be labelled "A267/A271" and "A2280/A2290" rather than the "A267 A271 and "A2280 A2290" that I had. I pointed out that it would be easier on users if I just called them "A267" and "A2290" as they are going to have to look at the browser anyway to get what the label was and it didn't matter if they were fully accurate, but it did matter that they were short. I seemingly got away with it on this example because it wasn't the one I used when the debate was occurring and it must have slipped through the peer review net.

[rickmastfan67]

I think the first version of a new site to go online should have the same data, the same points and labels, as the existing site as it is now.

I hate to see all of the potential fixes and additions to the data have to wait, but I do think it makes a lot of sense to wait for data updates until a at least a skeleton of a new system is live and people can see their travels and stats against the current data.

And remember, we have to possibly deal with the states that Tim did all the data having to be removed.  For those states, Interstate/US Highways top priority.  Then redoing the state highways as time allows.

[Bickendan]

I think the first version of a new site to go online should have the same data, the same points and labels, as the existing site as it is now.

I hate to see all of the potential fixes and additions to the data have to wait, but I do think it makes a lot of sense to wait for data updates until a at least a skeleton of a new system is live and people can see their travels and stats against the current data.

And remember, we have to possibly deal with the states that Tim did all the data having to be removed.  For those states, Interstate/US Highways top priority.  Then redoing the state highways as time allows.

Oregon and California are safe in that regard as I had to realign the interstates from the Terraserver imagery to the Gmaps centerlines, though had I had my way when redoing the US highways, they would have gotten their exit numbers.

[english si]

I've got an ever increasing amount (moving west) of Tim's Europe realigned, though as they were done later there's fewer changes when in places that had reasonable OSM coverage 5 years ago than in places where there were guesses, or the older Interstate and US route files.

Also pretty sure that in updating Indiana while improving files, I made enough changes to say it isn't all Tim's work. AZ and NV, however, came to me with state routes done, and so those states would need 'redoing' as a scenario. AZ Loop 303 is about the only file there I've made any important changes to.