Highway Data Discussion (CHM/TravelMapping)

[Jim]

I still massively prefer the web interface to the shell interface, and prefer the 'for Windows' interface over both.

It doesn't matter to me, as long as we're primarily using the "pull request" mechanism to get things back into the master repository.  Are you willing to help others who would prefer the Windows interface get the procedure down?

[Jim]

For those starting to contribute highway data updates through GitHub: I think it's good if we all "Watch" the HigwhayData repository (by pressing "Watch" near the upper right of https://github.com/TravelMapping/HighwayData) so we'll get notifications of pull requests and the discussions.  Until we have a more specific review process in place, I think it's good if all non-trivial updates get at least a day or two for people to make comments before they get pulled into the master repository.

Also, those not yet (or not intending to get) into GitHub can always email updates to me or someone else who is getting the hang of this process to get it going.  I received a sizeable SD update last night that I'm hoping to create a branch for some time today with the intent of pulling it soon.

[Jim]

So is US 310 supposed to go to Greybull? Or is it just an error?

If it's an error (which I think it is, from my own travels there earlier this summer), it's one carried over from the CHM database. Looks like something else to add to our updates to-do list.

Adding an issue in GitHub.

[Jim]

There's now a pull request in with the SD updates.  Experienced highway data editors, please take a quick look and comment on GitHub if you find problems (or, hopefully, if you don't, so we know it's safe to merge).

[mapcat]

The US 24 update in Indiana appears to not have made it.  http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=in.us024 still shows it on its old routing.

[oscar]

New WY US85BusTor is not in Updates or the database, even though it seems to have been submitted with other Wyoming changes (including to US 85, which route file refers to the Torrington business route).

[SD Mapman]

OK, US 89 in MT switched over to the new exit concurrency format, but it doesn't recognize the old format. Also on that, WY/MT is at the wrong Yellowstone entrance (West instead of north)

New WY US85BusTor is not in Updates or the database, even though it seems to have been submitted with other Wyoming changes (including to US 85, which route file refers to the Torrington business route).

It's on US 26's, too.

[rickmastfan67]

OK, US 89 in MT switched over to the new exit concurrency format, but it doesn't recognize the old format. Also on that, WY/MT is at the wrong Yellowstone entrance (West instead of north)

I'm bringing this up in the pull request that processed it.

I also noticed several other MT US Highways are effected the same way.  This isn't good at all.

[yakra]

I have a first draft of instructions on how to manage highway data changes using GitHub.  I'd like a few people to try it out, ideally by making just one or two small (and not "newsworthy") fixes to highway data in a region you maintain.  I put the instructions themselves in GitHub on a wiki page:

https://github.com/TravelMapping/HighwayData/wiki/Fork-&-Pull-Instructions-for-Highway-Data-Updating

I'm sure there will be a learning curve, and I'm certainly not sure if what I outline here is the best way for us to manage this.  However, I do think having everyone who will be creating and maintaining highway data learn and use enough git and GitHub to manage these processes will make things more efficient once we get rolling.

I got as far as

Now I want to get this branch back to the origin of my fork on GitHub. I first push the branch to GitHub:

My output:

Code Select Expand

yakra@ozzie:~/HighwayData$ git push origin yakra-me26-truncation
error: The requested URL returned error: 403 while accessing https://github.com/yakra/HighwayData.git/info/refs

fatal: HTTP request failed
So that's a no-go. For now at least. 403 Forbidden... What am I doing prong here?
In the meantime, I'll have a go at using the web interface as has been discussed upthread.

[froggie]

I'm working on getting Oregon up to date. There isn't too much, but I've moved US 30 off of I-84 onto Hist US 30 between Troutdale and Cascade Locks as that matches in the field signage. If we decide to do a Hist US route system, US 30 will move back to I-84.

As I noted in the old forum and from my own travels 2 weeks ago, I disagree with this.  I believe US 30 is still on the I-84 mainline.

As for GitHub and file updates, is the preference for us to create a GitHub account and try out Jim's tutorial?  Or can/shall we E-mail .WPT updates to Jim or someone else for uploading?

[Jim]

First version of a datacheck page getting its entries from the DB:

http://www.teresco.org/~terescoj/travelmapping/devel/datacheck.php

Again, it's not pretty but at least the information is in there and we will be able to make it more presentable, searchable, filterable, etc., pretty easily.

To be done: a mechanism to mark entries as false positives.  My current idea is to have another .csv file with entries like

ma.i090;2;3;;VISIBLE_DISTANCE;30.10

which would be matched as errors are encountered, and the falsePositive flag set appropriately.

It's easy enough to have the CSV lines automatically generated by PHP for copying and pasting from the page above, but maybe there's something more efficient.  There's also the issue that many of the 4358 datacheck errors currently detected were already marked as FPs in CHM, and it's silly to do all that work again manually.

[Jim]

As for GitHub and file updates, is the preference for us to create a GitHub account and try out Jim's tutorial?  Or can/shall we E-mail .WPT updates to Jim or someone else for uploading?

It's working reasonably well so far, given that almost all of us (myself included) started as git/GitHub novices at best.  I'm hoping those who have been working with the Windows version will create and share some instructions.

It's also not the end of the world for those who haven't gotten comfortable enough with GitHub to email updates to someone who is using GitHub (like we used to send to Tim), and one of us can then create a branch, pull request, all that stuff.

[oscar]

Mystery line in my latest log:

Unknown region/highway combo in line: SD I-29BSNor I-29 MilRd

But that route is in the draft highway browser, so it should not be "unknown"

All my other error lines are non-mysterious, including some from the issues we've had lately with some US routes in Montana.

[SD Mapman]

Mystery line in my latest log:

Unknown region/highway combo in line: SD I-29BSNor I-29 MilRd

But that route is in the draft highway browser, so it should not be "unknown"

All my other error lines are non-mysterious, including some from the issues we've had lately with some US routes in Montana.

The updates page and the HB isn't updated, but the logs are. I had to go to GitHub to find the waypoints for the new SD routes. The route from the mystery line doesn't exist and has been removed, BTW.

Also, this must have slipped through the cracks in the big SD update.

But wait, there's more! The Torrington Business route IS in GitHub, but not in the HB or the logs. Weird.

[yakra]

Also, this must have slipped through the cracks in the big SD update.

Aa, sou... That looks like one that was sent in to Tim for inclusion, but after Tim went inactive with Data updates.

[SD Mapman]

Also, should US 34 at the Missouri River be shifted up to the new bridge? (along with all the related shifts)

[yakra]

Jeff has sent Jim "a file for IA US 34 along with some changes to other Iowa routes. He's gone for a few days IIRC so we can wait and see."
I will follow along with the Nebraska side upon Jim's return.

[oscar]

For something completely different, here are two .csv file/route rename changes I suggest, for later no-hurry implementation.

First, the Trans-Canada Highway segment in British Columbia labeled "Queen Charlotte Islands" should be renamed for the islands' native and now-official name "Haida Gwaii" (change became official in 2010, and that's what they're called on the BC official tourist map). It helps that none of our users has traveled that route, AFAIK (it's on my secondary "bucket list" for later this decade), though I'd keep the existing name as an alternate route name to make sure no list files break.

Second, the US 395 segment in California north of Reno NV, currently file-named as "US395Alt" (for Alturas), should become "US395Sus" (for Susanville). The existing filename seems weird and confusing, as if it referred to an Alternate US 395 route. Also, while Alturas is the city right on that part of US 395 with the largest population, Susanville has a much larger population, though US 395 misses the city limits by a few miles (CA 36 connects the city to US 395). As with the Haida Gwaii rename, I'd keep US395Alt and US395_N as alternate route names, so no list files get broken.

UPDATE: Both renames are now in the Travel Mapping draft HB. US395Alt still works as an alternate name, based on the log for my list file.

[rickmastfan67]

Just a simple friendly reminder for all of us contributors.

Don't forget to update/lock/move threads in the old forums that have their fixes finally added to the new database.  That way we can clear up the old threads there before we create the new forums for errors.

[english si]

NB - when I say 'fixed', I mean in my personal offline fork that I'm trying to get into a pull request, but struggling as Github struggles to work out how to do it with a branch that is a few commits behind even when there isn't an edit conflict  .

New WY US85BusTor is not in Updates or the database, even though it seems to have been submitted with other Wyoming changes (including to US 85, which route file refers to the Torrington business route).

Jim fixed it for me. Words that as a Brit make me feel a little creeped out (google it).

Thanks Jim. Oh, wait, that didn't work. Fixing... Fixed.

The US 24 update in Indiana appears to not have made it.  http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=in.us024 still shows it on its old routing.

Fixed.

Also on that, WY/MT is at the wrong Yellowstone entrance (West instead of north)

Fixed.

Just a simple friendly reminder for all of us contributors.

Don't forget to update/lock/move threads in the old forums that have their fixes finally added to the new database.  That way we can clear up the old threads there before we create the new forums for errors.

I gone through the relevant threads and locked ones dealt with and am dealing with the others.

Can we ditch the requirement for the I-79(67) format for concurrent routes. If it's intersecting then that way round makes sense, but if it's a point for exit 67 of I-79 which you are concurrent with it ought to be 67(I-79).

I prefer the consistency of retaining the I-79(67) format.

Consistent with what? Not other system's routes, nor with reality, AFAICS!

Just wanted to mention this, but now all MT US Highways that have multiplexes with Interstates are completely broken (missing '+' to demote label).

They weren't 'completely broken'. They weren't broken at all (save MT US89's border point). However I've tweaked my change to have the format that I really really don't like as the first label, and all secondary labels hidden on the routes I've changed (it used to not matter?).

-- re-dos of existing route files, to follow new labeling rules, should usually be optional (usually no need to create extra work for ourselves)

Absolutely, which is why I don't see why I have to conform to a new rule that means US routes need to retain silly labelling of certain waypoints, that were added after I changed labels when we agreed to abolish the stupid inconsistency in labelling US Routes.

But I have gone and conformed with this new rule anyway.

-- in any case, any changes to existing files should preserve point labels in use so as not to break route files, by making them alternate labels preceded by a + (how our current route file parser identifies alternate or hidden labels).

It doesn't break them and certainly never used to!

For what it's worth, the current site update program doesn't care if labels other than the first are preceded with a '+' to mark as hidden.

Good, so I didn't break routes like people are saying.

If we'd like to enforce the requirement that any label other than a first (primary) label must have the '+', it's easy enough to add another datacheck that would report those.

I've got lots of them, but it seems that people are thinking that the route is broken if I couldn't be assed to add another character (that never made a difference on the old site), so best make some sort of datacheck so I can 'fix' these 'broken' routes.

Also, when I get my pull request to work, it will contain in dev state route systems of mine (CO, IN, WY) and the Yellowstone routes of a 'usanp' system for people to look at.

[Jim]

NB - when I say 'fixed', I mean in my personal offline fork that I'm trying to get into a pull request, but struggling as Github struggles to work out how to do it with a branch that is a few commits behind even when there isn't an edit conflict  .

For me, this has been the single biggest annoyance as I've learned how to manage GitHub.  The things I've done have required some command-line - maybe others who have managed this process successfully can give some instructions.  Basically, I go to my fork (on the web), compare, create pull request (from the TravelMapping master), pull it.  Pull that down to my local copy, branch, edit, etc. the create pull request from my branch back to TravelMapping master.

I have a friend who's a GitHub expert who probably does this stuff on a daily basis.  Need to ask him the best way to do what we're all looking to do.  There has to be an easier way in these cases where there are no conflicts.  I suspect "rebase" will play a role.

[english si]

I worked out how to do it - and that's make the pull request in-browser, rather than on the Desktop program that means that I'm made 5 commits rather than 300.

I'd already synced TravelMapping/master and si404/master and it was still giving me gyp.

[oscar]

-- re-dos of existing route files, to follow new labeling rules, should usually be optional (usually no need to create extra work for ourselves)

Absolutely, which is why I don't see why I have to conform to a new rule that means US routes need to retain silly labelling of certain waypoints, that were added after I changed labels when we agreed to abolish the stupid inconsistency in labelling US Routes.

But I have gone and conformed with this new rule anyway.

Just to be clear, as previously discussed, we don't really have any "new rules" yet (and, on the subject of labeling exit numbers on concurrent routes, we seem to have some inconsistency on how the "old rule" was applied). Certainly nothing that should affect the more immediate task of catching up with needed updates to existing systems, but nothing that should affect the updating process.

Also, when I get my pull request to work, it will contain in dev state route systems of mine (CO, IN, WY) and the Yellowstone routes of a 'usanp' system for people to look at.

An "usanp" system could usefully include a lot of major National Park/National Park Service-maintained roads besides Yellowstone's (like Natchez Trace Parkway, Skyline Drive, Blue Ridge Parkway), which could be a fruitful discussion for a separate thread.

Parallel systems could be set up for other countries, too. For example, a "cannp" system could resolve the conundrum of how to map Nova Scotia's Cabot Trail, whose omission from Nova Scotia'a mappable systems (provincial trunk route within a national park, with no signed route number) is IMO a glaring gap in our coverage of the province.

I hope, though, that the "US routes" within Yellowstone will remain mappable routes within the usaus system, until they're moved to a new system after it's activated.

[english si]

An "usanp" system could usefully include a lot of major National Park/National Park Service-maintained roads besides Yellowstone's (like Natchez Trace Parkway, Skyline Drive, Blue Ridge Parkway), which could be a fruitful discussion for a separate thread.

Oh, absolutely. Things like the Lincoln Highway have also been suggested (system name of something like "United States Select Scenic and Historic Highways").

Parallel systems could be set up for other countries, too. For example, a "cannp" system could resolve the conundrum of how to map Nova Scotia's Cabot Trail, whose omission from Nova Scotia'a mappable systems (provincial trunk route within a national park, with no signed route number) is IMO a glaring gap in our coverage of the province.

Arguably (like I've just done with major unnumbered/not signed with number A Roads) it could be part of one of the CANNSx systems.

I have, for fun, got Scotland's official National Tourist Routes made up.

I hope, though, that the "US routes" within Yellowstone will remain mappable routes within the usaus system, until they're moved to a new system after it's activated.

They will.

[oscar]

I'm starting to look at Si's new in-dev systems (so far, just to fix my draft list file entries), and already have one comment on CO 2 and CO 22.

We could set up new threads for each in-dev system to facilitate discussion, take in comments, etc. But first, a meta-question:  CHM put discussions of in-dev systems in a collaborators-only area of its forum. Anyone know why it was done that way? We could set up new topics in that area of the CHM forum. But I don't see why we should do that, which could make it harder to get useful input from users who weren't on the CHM collaborator team. OTOH, if we're about to set up our own forum separate from the aaroads forum, we could wait and set up the new threads there instead.