Here are a few things I needed to fix up with the import of the last known good CHM data into the new system's database. I don't know if they should be a concern.
- CA 44 was in usaca.csv, but no wpt exists. Removed entry.
- A whole bunch of usaky4.csv entries had no corresponding wpt file. Removed entries.
- In order to avoid name conflicts, I removed NM 599 from usansf.csv. I expect usanm is among the systems that will go active almost as soon as we have a usable system, so I'm not too worried about that.
CA 44's wpt should exist, but somehow it fell through the cracks when I first sent the batch to Tim way back when. I might have a copy floating around. I'll research this when I get home.
Quote from: Jim on June 10, 2015, 10:20:28 AM
Here are a few things I needed to fix up with the import of the last known good CHM data into the new system's database. I don't know if they should be a concern.
- CA 44 was in usaca.csv, but no wpt exists. Removed entry.
- A whole bunch of usaky4.csv entries had no corresponding wpt file. Removed entries.
- In order to avoid name conflicts, I removed NM 599 from usansf.csv. I expect usanm is among the systems that will go active almost as soon as we have a usable system, so I'm not too worried about that.
Since usaca.csv is for an in-development system, and that csv file needs a lot of other work, can we wait on this for awhile? I can do some work on this in the short gap between when I get back home from my current trip and when I hit the road again for a month later in Junemonth. But ISTM that our focus for now should be on active systems, and that my efforts for now should be catching up with a lot of updates for active Quebec routes (several Autoroutes, and one related TCH change) plus a few changes on active California and BC routes.
You could remove ak.ak98.wpt from the csv file for the in-development Select Provincial Highways system, to clear the way for putting it back in the in-development Alaska State Highway system, as you're doing for NM 599.
I don't want to rush any in-development system - they're just being read in and added to the DB. If usaca isn't in the kind of shape we should be doing even that, it's easy enough to take it out for the next DB generation run. In very preliminary .list processing code, I'm just reporting a log file warning and otherwise ignoring valid entries that refer to in-development systems.
1) lets get it up and running with the old data as was - who cares if usaca needs a lot more work, etc - having CA1 will help with long routes (being the longest) and having indev systems helps test that mapping.
2) obviously updating active systems should be a priority (I'm currently going through Spain checking E roads routes as I'm bored of proofing and updating the Autovia/Autopista files. It's a lot easier if you reject 'signed as such, but not from the mainline' as old routes) over fixing in dev systems.
CA 1 shouldn't be the longest -- BC 97, TX I-10, CA US 101 and CA I-5 should all be longer (in that order, iirc).
I meant that it is the longest file.
CA CA1 is 49kB / 721.9mi
BC BC97 is 43kB / 1313.6mi
NOR E6 is 42kB / 896.4mi
CA US101 is 41kB / 804.7mi
CA I-5 is 29kB / 806.5mi
TX I-10 is 26kB / 892.9mi
Quote from: english si on June 10, 2015, 03:06:29 PM
I meant that it is the longest file.
CA CA1 is 49kB / 721.9mi
BC BC97 is 43kB / 1313.6mi
NOR E6 is 42kB / 896.4mi
CA US101 is 41kB / 804.7mi
CA I-5 is 29kB / 806.5mi
TX I-10 is 26kB / 892.9mi
Ontario says hi!
ON ON11 is 32.6kB / 1,118.0mi
ON ON17 is 30.2kB / 1,213.8mi (however, this route will shrink a tad in the first update at the new site, but not by much because of ON417 taking over some more of it)
Forgot about ON 11 and 17, whoops! On that note, AB 2 is nothing to sneer at either...
I sent Oscar CA 44's file. It's so old, it's the old .ggm version and I can't find the converter we used...
Here's a list of files 20kB (rounded) and over that were on the original CHM site. Just for 'fun'.
ca.ca001 - 49kB / 721.9mi
bc.bc097 - 43kB / 1313.6mi
nor.e6 - 42kB / 896.4mi
ca.us101 - 41kB / 804.7mi
swe.e45 - 37kB / 1052.5mi
nor.e6kir - 34kB / 706.4mi
on.on011 - 33kB / 1118.0mi
swe.e4 - 32kB / 990.9mi
fin.e75 - 31kB / 803.2mi
on.on017 - 31kB / 1213.8mi
ab.ab002 - 30kB / 807.3mi
esp.e5 - 29kB / 757.9mi
ca.i005 - 29kB / 806.5mi
or.us030 - 29kB / 477.9mi
bc.bc003 - 28kB / 518.5mi
fin.e63 - 28kB / 702.0mi
ky.us060 - 28kB / 486.8mi
tx.us087 - 26kB / 808.4mi
tx.us287 - 26kB / 764.3mi
tx.i010 - 26kB / 892.9mi
fin.e8 - 26kB / 779.9mi
on.tchlak - 26kB / 1030.5mi
ca.ca089 - 26kB / 351.1mi
esp.e15 - 25kB / 816.1mi
tx.us083 - 25kB / 904.4mi
tx.us077 - 24kB / 613.0mi
tur.e80 - 24kB / 1114.8mi
ukr.e50 - 24kB / 994.6mi
esp.e90 - 24kB / 636.8mi
ca.ca099 - 24kB / 434.8mi
tur.e90 - 23kB / 1133.2mi
me.us001 - 23kB / 524.8mi
tx.us067 - 23kB / 761.5mi
tx.us090 - 23kB / 771.5mi
tx.us059 - 23kB / 624.0mi
fl.us001 - 22kB / 552.9mi
ita.e45 - 22kB / 893.7mi
ky.ky0080 - 22kB / 476.1mi
tx.us082 - 22kB / 573.2mi
ukr.e40 - 21kB / 964.7mi
bc.tchyel - 21kB / 665.6mi
ca.ca020 - 21kB / 226.2mi
mb.mb010 - 20kB / 508.5mi
fra.e60 - 20kB / 735.8mi
fra.e15 - 20kB / 778.7mi
fra.e70 - 20kB / 624.2mi
ak.ak001 - 20kB / 545.6mi
tx.i020 - 20kB / 645.3mi
Fun fact: colocation detection of waypoints reveals 2 (lat,lng) pairs that appear in 10 route files.
(41.499667,-81.693617) is at Public Square in Cleveland, and is part of OH US6, OH US20, OH US42, OH US322, OH US422, OH OH3, OH OH8, OH OH14, OH OH43, and OH OH87, all labeled as "PubSqu".
(35.128262,-90.076736) is the Mississippi River bridge on I-55 near Memphis. Since it carries 5 routes plotted by our project (I-55, US 61, US 64, US 70, US 79) across a state line, that end of each highway's Arkansas and Tennessee files contains a point there.
There are also 2 examples each of points that appear 8 times and 9 times.
Apparently the Department of Public Works and Highways (DPWH) in the Philippines released a National Route Numbering System last year. Why did I only find out about this now? :confused:
Anyway, I'd like to add two new systems (national roads and expressways). Other than the following files, what else should I add?
- systems.csv
- _systems/phln.csv
- _systems/phln_con.csv
- _systems/phle.csv
- _systems/phle_con.csv
- phln/*.wpt
- phle/*.wpt
Quote from: sammi on June 14, 2015, 01:16:36 PMOther than the following files, what else should I add?
- systems.csv
- _systems/phln.csv
- _systems/phln_con.csv
- _systems/phle.csv
- _systems/phle_con.csv
- phln/*.wpt
- phle/*.wpt
Not systems.csv - that shouldn't be a free-for-all file.
asiah/phl.ah26.wpt (and files for the spurs of it)?
But I'd hold off for a bit, if I was you - formats are changing, etc.
Quote from: english si on June 14, 2015, 02:51:00 PM
asiah/phl.ah26.wpt (and files for the spurs of it)?
But I'd hold off for a bit, if I was you - formats are changing, etc.
Alright then. I guess for now I'll be compiling waypoints, before actually putting them in the actual data.
Quote from: english si on June 11, 2015, 08:01:29 AM
Here's a list of files 20kB (rounded) and over that were on the original CHM site. Just for 'fun'.
> ca.ca001 - 49kB / 721.9mi
Aah yes, the in-development USACA system. Very dense visible points and shaping points, combined with a very long route, led to CA1 topping off the list. It's what CA89 and CA20 suffer from as well.
> ca.us101 - 41kB / 804.7mi
A long route with dense interchanges on freeway segments. There are a few shaing points and a couple visible points that could be removed, but overall, not bad.
> ab.ab002 - 30kB / 807.3mi
My draft file for the CANAB system is down to 19.2 KB.
446 waypoints: 220 visible, 226 hidden. -> 295 waypoints: 258 visible, 37 hidden.
Average spacing: 1.81 mi -> 2.73 mi
Average visible spacing: 3.69 mi -> Average visible spacing: 3.12 mi
> ca.i005 - 29kB / 806.5mi
A very long freeway with densely spaced interchanges in places. Shaping points are well done; minimal.
> or.us030 - 29kB / 477.9mi
Many of the shaping points, particularly along I-84, can be cut out.
I cut it down to 18.4 K. (http://205.209.84.174/roads/chm/or/or.us030.wpt)
422 waypoints: 219 visible, 203 hidden. -> 276 waypoints: 218 visible, 58 hidden.
Average spacing: 1.14 mi -> 1.73 mi
Average visible spacing: 2.19 mi -> Average visible spacing: 2.19 mi
I actually added a few shaping points (10?) in the eastern part of the state on I-84.
> bc.bc003 - 28kB / 518.5mi
A cursory look shows a lot of shaping points could be cut out. Visible ones as well.
> ky.us060 - 28kB / 486.8mi
> ky.ky0080 - 22kB / 476.1mi
Heh. Tons of state routes here. KY needs 4 digits to number `em all.
> on.tchlak - 26kB / 1030.5mi
A long route that's about where it needs to be WRT shaping.
> ca.ca099 - 24kB / 434.8mi
Not as bad as CA1, 20 or 89. Another case of a long mostly-freeway with dense interchamge spacing tying our hands. Although, many of the shaping points could be eliminated. Also looks like there's opportunity to snip out some visible ones on the surface road, such as in the Yuba City area.
> me.us001 - 23kB / 524.8mi
This has always been rather dense on the visible waypoints. I've trimmed down my local copy: 17.6 K / 524.05 mi
347 waypoints: 310 visible, 37 hidden. -> 272 waypoints: 240 visible, 32 hidden.
Average spacing: 1.52 mi -> 1.93 mi
Average visible spacing: 1.70 mi -> Average visible spacing: 2.19 mi
> mb.mb010 - 20kB / 508.5mi
My draft file for the CANMB system is down to 11.2 KB.
285 waypoints: 93 visible, 192 hidden. -> 172 waypoints: 115 visible, 57 hidden.
Average spacing: 1.79 mi -> 2.94 mi
Average visible spacing: 5.53 mi -> Average visible spacing: 4.41 mi
Quote from: yakra on June 19, 2015, 03:11:11 PM
Quote from: english si on June 11, 2015, 08:01:29 AM
Here's a list of files 20kB (rounded) and over that were on the original CHM site. Just for 'fun'.
> ca.ca001 - 49kB / 721.9mi
Aah yes, the in-development USACA system. Very dense visible points and shaping points, combined with a very long route, led to CA1 topping off the list. It's what CA89 and CA20 suffer from as well.
Awhile ago, I took a stab at slimming down the CA1 route file, before I got interrupted. I agree, lots of room to cut down on the file size, especially cutting down on visible points on straight sections in the Los Angeles metro area.
Quote from: yakra> or.us030 - 29kB / 477.9mi
Many of the shaping points, particularly along I-84, can be cut out.
I cut it down to 18.4 K.
422 waypoints: 219 visible, 203 hidden. -> 276 waypoints: 218 visible, 58 hidden.
Average spacing: 1.14 mi -> 1.73 mi
Average visible spacing: 2.19 mi -> Average visible spacing: 2.19 mi
I actually added a few shaping points (10?) in the eastern part of the state on I-84.
Seems like a good time to ask if we're going to put US 30 on what is signed as Hist US 30 through the gorge or leave it on I-84 and draft up a Hist US 30 route.
Also, I'm very certain that it's pointless to ask if any removed shape points US 30 were also removed from I-84 along the concurrency?
Quote from: Bickendan on June 19, 2015, 05:11:05 PMAlso, I'm very certain that it's pointless to ask if any removed shape points US 30 were also removed from I-84 along the concurrency?
I did not make any edits to I-84. I only loaded US30 into WPTedit and went to town, and put the results on my server
becuz hay guise look at dis. My edit should not be considered canonical. I do (did?) not maintain Oregon. Looks like it was last officially left in Si's hands.
Just curious...what's the rationale for reducing the number of waypoints and/or shaping points for the files? Are large files overtaxing the server in some way, or unnecessarily difficult to maintain?
Quote from: mapcat on June 20, 2015, 11:01:14 AM
Just curious...what's the rationale for reducing the number of waypoints and/or shaping points for the files? Are large files overtaxing the server in some way, or unnecessarily difficult to maintain?
Mainly the former. But trying to keep waypoint density within reason at the outset also makes route file drafting easier. Certainly when I drafted the file for the curvaceous HI 360, I was grateful I didn't have to shape all 600+ hairpin curves in a 30-mile span. I was able to get by with only about two dozen points for that file.
Quote from: oscar on June 20, 2015, 11:27:02 AM
Mainly the former. But trying to keep waypoint density within reason at the outset also makes route file drafting easier. Certainly when I drafted the file for the curvaceous HI 360, I was grateful I didn't have to shape all 600+ hairpin curves in a 30-mile span. I was able to get by with only about two dozen points for that file.
I see. So then there's no motivation to maintain route length integrity within x%? HI 360 is 26.4 miles long in CHM, but a Google Maps trace of the route from end to end comes out at 34.9 miles, or a little more than 32% longer.
Quote from: mapcat on June 20, 2015, 03:00:18 PM
Quote from: oscar on June 20, 2015, 11:27:02 AM
Mainly the former. But trying to keep waypoint density within reason at the outset also makes route file drafting easier. Certainly when I drafted the file for the curvaceous HI 360, I was grateful I didn't have to shape all 600+ hairpin curves in a 30-mile span. I was able to get by with only about two dozen points for that file.
I see. So then there's no motivation to maintain route length integrity within x%? HI 360 is 26.4 miles long in CHM, but a Google Maps trace of the route from end to end comes out at 34.9 miles, or a little more than 32% longer.
I believe the CHM system had a fixed amount by which route lengths were multiplied to get our line segments approach to come close to actual length. One of the things I'd like to see and do in the new project is to have a mechanism by which a route's scale factor (or maybe just especially curvy parts) could have an actual length specified that would override the default approximation.
QuoteI believe the CHM system had a fixed amount by which route lengths were multiplied to get our line segments approach to come close to actual length. One of the things I'd like to see and do in the new project is to have a mechanism by which a route's scale factor (or maybe just especially curvy parts) could have an actual length specified that would override the default approximation.
This would also be useful for transit systems when we get to that point, especially since many have mileages between stations already documented.
Quote from: oscar on June 20, 2015, 11:27:02 AM
Quote from: mapcat on June 20, 2015, 11:01:14 AM
Just curious...what's the rationale for reducing the number of waypoints and/or shaping points for the files? Are large files overtaxing the server in some way, or unnecessarily difficult to maintain?
Mainly the former. But trying to keep waypoint density within reason at the outset also makes route file drafting easier. Certainly when I drafted the file for the curvaceous HI 360, I was grateful I didn't have to shape all 600+ hairpin curves in a 30-mile span. I was able to get by with only about two dozen points for that file.
A route file with too many waypoint marker overlays can be veryu slow to load, display and zoom/pan, depending on a user's system. But more importantly, as Tim pointed out back in 2010:
Quote- Some web scripts in the site necessarily have execution times roughly proportional to the number of points to be searched or plotted. Raising the shaping point count by a factor of 5 while raising the number of supported routes will eventually have a crippling effect.
Multiplex detection comes to mind. (Jim, what's the Big-O of the quad table routine you posted about in another thread?)
I thought I remembered some mention of O(n^2) routines, but a few quick searches thru the CHM forum turn up nothing. Either I remembered incorrectly or am confusing it with another discussion entirely.
I think the quadtree should be in the neighborhood of O(n log n), though that's not the usual log2 found in many tree structures. It was a massive improvement over the original O(n2). Python also had a convenient set and hash table that helped make various parts far more efficient than the naive implementations.
I hope not to need anything in the site update process that's quadratic in the number of points, routes, .list entries, or anything else. The most expensive part is still .list processing but it's not bad. I think it should be able to handle a good number of users with a reasonable update turnaround time.
Quote from: yakra on June 20, 2015, 01:15:07 AMI do (did?) not maintain Oregon. Looks like it was last officially left in Si's hands.
The whole state needs an overhaul - on top of the OTT shaping points issue on many routes, there's lots of points that aren't on the highway.
Plus I keep being given point requests (which I have added, even though I don't need to!) and changes.
I'd love to offload it, rather than having to deal with this demanding region (overhaul, people being on the ball about improving it), but I think I've received a couple of requests from people to maintain it, which creates an issue!
I'll take Oregon back.
OK - here's my up-to-date(ish) files https://dl.dropboxusercontent.com/u/84173946/OR.zip
Thanks, I'll grab it when I get home from work.
A big roadblock to getting both old (CHM veteran) and new people working on improving and expanding the highway data is the conversion to a new format. For the most part, as mentioned before, this is nearly trivial. My intent would be to convert all existing files, get them into their "official" location in GitHub and let people clone and fork and whatever else we decide is the way to manage the changes. The problem is that Tim's wptedit page would still use the old .wpt file format, with the OSM URLs. So the options as I see them:
1) We stick with the old format for now so we can keep using wptedit on Tim's site. We risk it disappearing, and are stuck with a file format that is a bit clunky but would work. But the process described above could happen almost immediately.
2) We copy and modify Tim's wptedit code (it's all available as far as I can tell) to use the new format. It should be nearly trivial to do, but I'm hesitant to take his code without his permission. I'm using some of his JS code in the map displays I developed but I had prior permission to use that code for my academic project, and a lot of it has been changed quite a bit since his last version so I feel like this is OK. In this case, we'd be making only small modifications, using most of his code as is, with no permission of any kind granted as far as I know.
3) Someone writes a brand new highway data file editor. This would take some time, I'm sure.
Quote from: Jim on June 24, 2015, 07:51:10 PM
3) Someone writes a brand new highway data file editor. This would take some time, I'm sure.
What kind of functionality does this need anyway? I'd be up for it.
Quote from: sammi on June 24, 2015, 08:07:19 PM
Quote from: Jim on June 24, 2015, 07:51:10 PM
3) Someone writes a brand new highway data file editor. This would take some time, I'm sure.
What kind of functionality does this need anyway? I'd be up for it.
The existing one's a good starting point:
http://cmap.m-plex.com/tools/wpteditv3/wptedit.html (http://cmap.m-plex.com/tools/wpteditv3/wptedit.html)
Quote from: Jim on June 24, 2015, 08:09:31 PM
Quote from: sammi on June 24, 2015, 08:07:19 PM
Quote from: Jim on June 24, 2015, 07:51:10 PM
3) Someone writes a brand new highway data file editor. This would take some time, I'm sure.
What kind of functionality does this need anyway? I'd be up for it.
The existing one's a good starting point:
I think you should have just PM'ed him the link Jim. We don't want to overload Tim's site with people who don't really have permission to use that.
Quote from: rickmastfan67 on June 24, 2015, 10:09:36 PM
I think you should have just PM'ed him the link Jim. We don't want to overload Tim's site with people who don't really have permission to use that.
Maybe, but it's just a single HTML file with some JS code, and if I'm seeing it right will only hit the server for the initial load. It's all client side after the initial page load.
Quote from: rickmastfan67 on June 24, 2015, 10:09:36 PM
Quote from: Jim on June 24, 2015, 08:09:31 PM
Quote from: sammi on June 24, 2015, 08:07:19 PM
Quote from: Jim on June 24, 2015, 07:51:10 PM
3) Someone writes a brand new highway data file editor. This would take some time, I'm sure.
What kind of functionality does this need anyway? I'd be up for it.
The existing one's a good starting point:
I think you should have just PM'ed him the link Jim. We don't want to overload Tim's site with people who don't really have permission to use that.
Use what? ;)
Quote from: rickmastfan67 on June 24, 2015, 10:09:36 PM
I think you should have just PM'ed him her the link Jim. We don't want to overload Tim's site with people who don't really have permission to use that.
It's not like that modifies any data on the server side though, just whatever the user inputs.
Quote from: Jim on June 24, 2015, 07:51:10 PM
1) We stick with the old format for now so we can keep using wptedit on Tim's site. We risk it disappearing, and are stuck with a file format that is a bit clunky but would work. But the process described above could happen almost immediately.
If a new format would convert what already exists and be at least somewhat close to "write unique point name, insert weblink" then I think it could be explored. I have
zero experience with GitHub though.
Quote2) We copy and modify Tim's wptedit code (it's all available as far as I can tell) to use the new format. It should be nearly trivial to do, but I'm hesitant to take his code without his permission.
I think starting out with it, at least, is reasonable. The worst thing that happens is that he would
communicate with us about something.
Quote from: Jim on June 24, 2015, 07:51:10 PM
... I'm hesitant to take his code without his permission.
There was a phone number posted in the m-plex.com DNS registration info posted the other day. Anyone considered calling it?
Quote from: Jim on June 24, 2015, 07:51:10 PMA big roadblock to getting both old (CHM veteran) and new people working on improving and expanding the highway data is the conversion to a new format. For the most part, as mentioned before, this is nearly trivial. My intent would be to convert all existing files, get them into their "official" location in GitHub and let people clone and fork and whatever else we decide is the way to manage the changes.
Except that would leave all the changes that people have made in the last 10 months behind (plus all the new systems I have that I couldn't add with Tim's "only two systems in dev at a time" and "no more Europe phase 3" rules)...
Quote1) We stick with the old format for now so we can keep using wptedit on Tim's site. We risk it disappearing, and are stuck with a file format that is a bit clunky but would work. But the process described above could happen almost immediately.
this seems the easiest way. What issues are there in keeping the current format other than 'clunkiness'?
The following regions are up for grabs wrt maintanance due to Tim's absence (some of these are me making room for Tim's European systems):
- Arizona
- DC
- Delaware
- Idaho
- Kentucky
- Lousiana
- Maryland
- New Jersey
- Pennsylvania
- Quebec
Quote from: english si on June 25, 2015, 07:37:39 AM
Quote from: Jim on June 24, 2015, 07:51:10 PMA big roadblock to getting both old (CHM veteran) and new people working on improving and expanding the highway data is the conversion to a new format. For the most part, as mentioned before, this is nearly trivial. My intent would be to convert all existing files, get them into their "official" location in GitHub and let people clone and fork and whatever else we decide is the way to manage the changes.
Except that would leave all the changes that people have made in the last 10 months behind (plus all the new systems I have that I couldn't add with Tim's "only two systems in dev at a time" and "no more Europe phase 3" rules)...
True, but we'd easily enough be able to convert those, too.
Quote
Quote1) We stick with the old format for now so we can keep using wptedit on Tim's site. We risk it disappearing, and are stuck with a file format that is a bit clunky but would work. But the process described above could happen almost immediately.
this seems the easiest way. What issues are there in keeping the current format other than 'clunkiness'?
I'd say the main arguments in favor of a new format right now are that it would be simpler and slightly easier to parse (but parsing the current wpt format is not hard), we could add support for comments (which could be added for the old format as well), the URLs are not even a current OSM format, and that if we are going to make a switch, this seems as good a time as we'll ever have to do so. Am I missing anything? I wouldn't mind at all if we just stick with what we have, augmented with comment support.
If nothing else, I'd think upgrading URLs to current format would be a prudent move.
I don't mind taking over Quebec, but I have no experience with creating/maintaining route files on the original CHM (I offered to do the QC provincial routes a few years ago but was denied).
Quote from: froggie on June 25, 2015, 09:24:35 AM
If nothing else, I'd think upgrading URLs to current format would be a prudent move.
Unfortunately, that's just as hard, from the point of view of what to do about a wpt editor, as going to the simplified format we discussed a while back.
Quote from: english si on June 25, 2015, 08:05:11 AM
The following regions are up for grabs wrt maintanance due to Tim's absence (some of these are me making room for Tim's European systems):
- Arizona
- DC
- Delaware
- Idaho
- Kentucky
- Lousiana
- Maryland
- New Jersey
- Pennsylvania
- Quebec
I'll take LA and NJ.
QC:
ISTR that Oscar has kept his eyes on a number of changes that need to be made from the versions currently in the HB, and may have already made the edits to his local files. I'd offer to take QC (because Canada yadda yadda GISplunge), but offer first dibs to Oscar.
Carl, any objections?
Does Oscar have time for all that? :-o
I have a prototype waypoint editor ready! :sombrero:
http://travelmapping.sammdot.ca/wptedit.html
Ok so you can't really edit yet, but now when you click Export it downloads a .wpt file in my proposed new format.
43.726756 -79.330449 WynDr WynfordDr
I'm still trying to get the importing to work. Importing works now too! It's just the actual editing part left to do. <_<
This is what a sample .wpt looks like in the new format:
http://dl.sammdot.ca/on.on409.wpt
Just click Import and copy the contents.
(If it says the length is 0.25 mi / 0.4 km, that's just part of the prototype because I haven't written distance calculations in yet.)
Quote from: SSOWorld on June 25, 2015, 02:50:01 PM
Does Oscar have time for all that? :-o
Maybe, maybe not. I'll let it be his call. FWIW, when the old project went dormant he was already maintaining AK, CA, HI, YT, NT, BC, and SK.
Quote from: sammi on June 25, 2015, 03:35:53 PM
I have a prototype waypoint editor ready! :sombrero:
http://travelmapping.sammdot.ca/wptedit.html
Ok so you can't really edit yet, but now when you click Export it downloads a .wpt file in my proposed new format.
43.726756 -79.330449 WynDr WynfordDr
I'm still trying to get the importing to work. Importing works now too! It's just the actual editing part left to do. <_<
This is what a sample .wpt looks like in the new format:
http://dl.sammdot.ca/on.on409.wpt
Just click Import and copy the contents.
(If it says the length is 0.25 mi / 0.4 km, that's just part of the prototype because I haven't written distance calculations in yet.)
Looking good sammi. However, I'm not seeing any text in the top left where it would list the waypoints. No idea why. Using Firefox 39 Beta.
Quote from: rickmastfan67 on June 25, 2015, 08:54:11 PM
I'm not seeing any text in the top left where it would list the waypoints. No idea why. Using Firefox 39 Beta.
For reference, this is what it looks like on my browser (Chrome 43):
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.sammdot.ca%2F36fad443.png&hash=4ebb8cb0603e1bb5eb8d10cd4222e6f61f29545e)
Can I see a screenshot, so I could figure out what the problem is?
Quote from: sammi on June 25, 2015, 09:54:56 PM
Quote from: rickmastfan67 on June 25, 2015, 08:54:11 PM
I'm not seeing any text in the top left where it would list the waypoints. No idea why. Using Firefox 39 Beta.
For reference, this is what it looks like on my browser (Chrome 43):
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.sammdot.ca%2F36fad443.png&hash=4ebb8cb0603e1bb5eb8d10cd4222e6f61f29545e)
Can I see a screenshot, so I could figure out what the problem is?
Here you go:
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fimg.photobucket.com%2Falbums%2Fv645%2Frickmastfan67%2FCHM%2FTravel_Mapping_Waypoint_Editor_-_2015-06-25_22.13.13.png&hash=ca44efc16dad8f74e518a938b4acdbb4db4ae22e)
I even tried to load it in safe mode and still didn't have any text in the top left load.
Quote from: yakra on June 25, 2015, 01:47:48 PMQC:
ISTR that Oscar has kept his eyes on a number of changes that need to be made from the versions currently in the HB, and may have already made the edits to his local files. I'd offer to take QC (because Canada yadda yadda GISplunge), but offer first dibs to Oscar.
Carl, any objections?
Sure. I'll be sure to raise a flag myself if anything changes in the autoroute system over here.
Quote from: sammi on June 25, 2015, 03:35:53 PMI have a prototype waypoint editor ready! :sombrero:
http://travelmapping.sammdot.ca/wptedit.html
Awesome! I can't test it myself yet because my work computer has IE 9 and Fx 15 (both obsolete), but it's looking great!
Quote from: english si on June 25, 2015, 08:05:11 AM
The following regions are up for grabs wrt maintanance due to Tim's absence (some of these are me making room for Tim's European systems):
- Arizona
- DC
- Delaware
- Idaho
- Kentucky
- Lousiana
- Maryland
- New Jersey
- Pennsylvania
- Quebec
Should Oscar not want them I can volunteer to take on a couple of these. Arizona and New Jersey come to mind but I'll take on a couple more if help is needed.
I'd love to take up Wisconsin, but since it's been claimed and well maintained I won't speak up, thanks Jeff M. :DOn that note - newcomers should be made aware of what the guidelines for placing a route on the map are such as waypoint spacing, source validation, etc.
Quote from: rickmastfan67 on June 25, 2015, 10:14:54 PM
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fimg.photobucket.com%2Falbums%2Fv645%2Frickmastfan67%2FCHM%2FTravel_Mapping_Waypoint_Editor_-_2015-06-25_22.13.13.png&hash=ca44efc16dad8f74e518a938b4acdbb4db4ae22e)
As it turns out I used
Node.innerText, which is a nonstandard feature (that I thought was standard) that doesn't exist in Firefox. I tested it in Firefox 38, so it should work now.
This is excellent. I hope that once sammi's new wpt editor is far enough along, we can convert all "chm_final" data to the new format (with a corresponding mechanism to allow all those who have updated/new wpts on their own systems to be converted easily). I hope many of the long-time CHM route plotters/maintainers will try it out and make suggestions so we have something at least as functional and useful as Tim's old editor.
I think it would be useful to have a list of essential features for the editor to help sammi out with design and implementation. Here are some to start:
- easy adding, removing, renaming, reordering of points, either through the map or by editing the text box
- maintain both visible and hidden waypoints, multiple names for waypoints
- report errors that will flag datacheck problems right in the editor
- "red line" bars or some better mechanism to help see if the actual route stays within the appropriate tolerance of the plotted route's segments
- I'd like to see support added for comments - lines starting with #, which I believe is not a valid label character
Quote from: Jim on June 26, 2015, 10:22:30 AM
maintain both visible and hidden waypoints, multiple names for waypoints
✓
Quote from: Jim on June 26, 2015, 10:22:30 AM
adding
✓ You can use the Add Waypoint button or double-click on the map to add a waypoint. Add Waypoint will add it to the center of the map, double clicking will add it where you clicked.
Quote from: Jim on June 26, 2015, 10:22:30 AM
removing
✓
Quote from: Jim on June 26, 2015, 10:22:30 AM
renaming
✓
, but only partially. Right now it can edit the main label, but none of the other labels.Quote from: Jim on June 26, 2015, 10:22:30 AM
reordering of points
I'm thinking of having a drag-and-drop system to rearrange the points, instead of having to move up and down so many times. I'm not sure yet how I would implement that though. ✓
Quote from: Jim on June 26, 2015, 10:22:30 AM
report errors that will flag datacheck problems right in the editor
I have the list of possible errors that you linked last night. I'll write an error checking thing after I get the label thing down.
Quote from: Jim on June 26, 2015, 10:22:30 AM
"red line" bars or some better mechanism to help see if the actual route stays within the appropriate tolerance of the plotted route's segments
So
that's what that was for.
Quote from: Jim on June 26, 2015, 10:22:30 AM
comments
Does that mean I have to export comments to the output file too?
I see the text listing of waypoint labels, but the map pane is completely blank white. Firefox 20.0.
I think for my part, I'll keep on using Tim's editor. I've downloaded the HTML and JS files. I may end up making some edits to it to work with the new format, and possibly flag some of the possible errors it doesn't report yet.
...If I decide it's worth the trouble.
Which, who knows, I might. While writing an old->new WPT file format converter would be trivial using the C++ code I already have for the listfile mapper, GISplunge, and the like, it's just be a PITA to have to run every completed file thru a converter every time I make an edit.
As for comment support, I'm lukewarm on that. Seems kinda mission creep-y. I like the original (Tim era) idea of keeping the route files (and lists n'at) down to just the necessary bare-bones.
Quote from: yakra on June 26, 2015, 11:54:11 AM
I see the text listing of waypoint labels, but the map pane is completely blank white. Firefox 20.0.
Firefox 20?! :ded: The browser support tables (http://caniuse.com/#search=flex) I'm using don't even have it listed as a version anymore. Also if the map isn't loading then that's an issue with the Google Maps API and not my code.
Works pretty nicely. I did WY77 without too much trouble. I could probably do a whole bunch more.
Quote from: yakra on June 26, 2015, 11:56:09 AM
As for comment support, I'm lukewarm on that. Seems kinda mission creep-y. I like the original (Tim era) idea of keeping the route files (and lists n'at) down to just the necessary bare-bones.
I support "keep it simple" but I do think this is a minor change that is easy to account for in parsing code [ if line.startswith('#') ] and would let us note right in the route files if there was a good reason to do something unusual like points moved a bit to break false concurrencies, labels chosen to avoid collisions with others in the file, etc.
Quote from: sammi on June 26, 2015, 11:00:20 AM
Does that mean I have to export comments to the output file too?
I'd say as long as it just kept them it would be enough for me. But as we've not even agreed that comments are worth the trouble, I'd say don't worry about that just yet. Progress continues to look excellent, by the way!
Should we go to the proposed new format, the following Python code that can do the conversion is being added to the GitHub repository TravelMapping/HighwayData under wptconverter/convert.py
It uses .wpt2 as the new extension for lack of a better idea - I make no suggestion that that's what we should use.
#!/usr/bin/env python3
# Travel Mapping Project, Jim Teresco, 2015
"""Python code to read an old-format .wpt file and
write a new format .wpt2 file.
The old format consists of lines such as
PA/NY +0 http://www.openstreetmap.org/?lat=42.252473&lon=-79.761515
which would convert to
42.252473 79.761515 PA/NY +0
(c) 2015, Jim Teresco
"""
import argparse
# argument parsing
parser = argparse.ArgumentParser(description="Convert wpt to wpt2 file.")
parser.add_argument("fileroot", help="root file name to be converted (fileroot.wpt becomes fileroot.wpt2)")
args = parser.parse_args()
outfile = open(args.fileroot+'.wpt2','wt')
with open(args.fileroot+'.wpt','rt') as infile:
lines = infile.readlines()
for line in lines:
parts = line.split()
url_parts = parts[-1].split('=')
lat_string = url_parts[1].split("&")[0] # chop off "&lon"
lng_string = url_parts[2].split("&")[0] # chop off possible "&zoom"
outfile.write(lat_string + ' ' + lng_string + ' ' + parts[0])
for p in parts[1:-1]:
outfile.write(' ' + p)
outfile.write('\n')
outfile.close()
Quote from: sammi on June 26, 2015, 09:33:09 AM
Quote from: rickmastfan67 on June 25, 2015, 10:14:54 PM
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fimg.photobucket.com%2Falbums%2Fv645%2Frickmastfan67%2FCHM%2FTravel_Mapping_Waypoint_Editor_-_2015-06-25_22.13.13.png&hash=ca44efc16dad8f74e518a938b4acdbb4db4ae22e)
As it turns out I used Node.innerText, which is a nonstandard feature (that I thought was standard) that doesn't exist in Firefox. I tested it in Firefox 38, so it should work now.
Working fine with FF 39. :)
One suggestion thought, I'd make the 'labels' on the left smaller. That way, we can get more labels seen at one time for the longer routes.
Quote from: yakra on June 26, 2015, 11:54:11 AM
I see the text listing of waypoint labels, but the map pane is completely blank white. Firefox 20.0.
Dude! At least download the poratble version to use for the new editor. ;)
Quote from: Jim on June 26, 2015, 04:46:45 PM
Should we go to the proposed new format, the following Python code that can do the conversion is being added to the GitHub repository TravelMapping/HighwayData under wptconverter/convert.py
It uses .wpt2 as the new extension for lack of a better idea - I make no suggestion that that's what we should use.
The new waypoint editor now also supports importing the old CHM format. :) It can be selected as an option when importing waypoint data. (It still only exports to the new format though.) Also, I changed it to use the
.wpt2 extension, so that's pretty much official now.
Quote from: rickmastfan67 on June 26, 2015, 08:27:58 PMDude! At least download the poratble version to use for the new editor. ;)
Not sure what you mean here.
Error checking is now implemented to some extent. Right now it only checks for errors type 1, 2, 3, 5, 6, 7, 10 and 18, because those are the easiest to check for. :) It can also differentiate between possible errors and true errors.
A possible error would be outlined in red, like so:
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.sammdot.ca%2F22909869.png&hash=03c59c76454973075ae5288121bd5bdc5c22050f)
A true error would also be highlighted in red:
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.sammdot.ca%2F26bf2e42.png&hash=f74d242f04cea0ccb79dc7686c6cee479cce3677)
True errors would now also prevent the waypoint data from being exported; possible errors would not.
Quote from: yakra on June 27, 2015, 12:31:45 PM
Quote from: rickmastfan67 on June 26, 2015, 08:27:58 PMDude! At least download the poratble version to use for the new editor. ;)
Not sure what you mean here.
There are portable versions of Firefox.
Quote from: sammi on June 27, 2015, 11:44:42 AMThe new waypoint editor now also supports importing the old CHM format. :) It can be selected as an option when importing waypoint data. (It still only exports to the new format though.) Also, I changed it to use the .wpt2 extension, so that's pretty much official now.
Excellent.
A big issue with the editor (and the browser) at the moment is that it only has Google Maps. OSM data in some form is a must for copyright reasons creating the route (OSM data has a much less restrictive licence than Google data). Other maps are bonuses.
Quote from: english si on June 28, 2015, 10:54:55 AM
A big issue with the editor (and the browser) at the moment is that it only has Google Maps. OSM data in some form is a must for copyright reasons creating the route (OSM data has a much less restrictive licence than Google data). Other maps are bonuses.
Hmm, that was easy. OSM and MapQuest Open (both road and satellite) are now on the map.
I'm somewhat disappointed that MapQuest satellite lacks any sort of large scale data past a few km from the border. :/
(https://www.aaroads.com/forum/proxy.php?request=http%3A%2F%2Fi.sammdot.ca%2F3a5e1635.png&hash=5b994e1c478f31fa98ce9edaf39d12d8e1228beb)
This looks great!
I've been playing around a little with it today, and I did find one issue: if you reorder waypoints and then go back and try to change the label on one of them, sometimes it changes the label for a different waypoint instead. Example:
- Create waypoint 1
- Create waypoint 2
- Create waypoint 4
- Create waypoint 3 (which you accidentally skipped)
- Create waypoint 5
- Reorder waypoints, putting 3 before 4
- Try to change waypoint 3's label to 3A. Result: Waypoint 4's label changes to 3A.
It seems to be getting the instruction "relabel the 4th (by time of creation) waypoint" and interpreting it as "relabel the 4th waypoint in the list". Or vice versa.
Quote from: sammi on June 28, 2015, 11:40:09 AM
I'm somewhat disappointed that MapQuest satellite lacks any sort of large scale data past a few km from the border. :/
That's because it's mostly NAIP imagery, and thus, US only.
Quote from: sammi on June 28, 2015, 11:40:09 AM
Hmm, that was easy. OSM and MapQuest Open (both road and satellite) are now on the map.
Also, with the MapQuest Open maps, you need to include the 'MapQuest' icon, just like they do @ OSM. Also, you need to add direct links to the copyrights like they do on OSM for both. Just wanting to avoid any future e-mails for you saying that the page is against the license by not linking/showing proper copyright images. ;)
Quote from: rickmastfan67 on June 28, 2015, 10:12:27 PMJust wanting to avoid any future e-mails for you saying that the page is against the license by not linking/showing proper copyright images. ;)
This reminds me of another issue we should think about before people start editing and drafting new highway data. I think it's important that we keep the list of sources accurate, and that one or two people should take primary responsibility for that. I know CHM had this information in a spreadsheet, and that should be our starting point if anyone has a copy or a way to get it. I don't see it in the data folder, only in web form at http://cmap.m-plex.com/docs/sources.php (http://cmap.m-plex.com/docs/sources.php).
Quote from: SSOWorld on June 26, 2015, 09:20:23 AM
Quote from: english si on June 25, 2015, 08:05:11 AM
The following regions are up for grabs wrt maintanance due to Tim's absence (some of these are me making room for Tim's European systems):
- Arizona
- DC
- Delaware
- Idaho
- Kentucky
- Lousiana
- Maryland
- New Jersey
- Pennsylvania
- Quebec
Should Oscar not want them I can volunteer to take on a couple of these. Arizona and New Jersey come to mind but I'll take on a couple more if help is needed.
The only one of these I've claimed so far is Quebec (just for maintaining existing systems -- developing a Quebec provincial highways route set wasn't something I was planning on, and would cheerfully yield to someone else), which has immediate maintenance needs since MTQ has been busy expanding its Autoroutes system. Others are maybes, but I can see some of them going to new(er) team members instead.
I wasn't sure where to put this, but this topic seemed to be the right place.
I noticed as I was driving on US 23 just south of Columbus, OH that OH 762 now continues east of US 23, formerly the eastern terminus of the route. I haven't had a chance to drive the new section, but plan to do so within the week. Here are a couple of links I found detailing the newest section.
http://www.circlevilleherald.com/news/extension-of-state-route-causes-change-in-road-names/article_6bf372ad-233a-5a0d-87eb-6f9c33ed688c.html (http://www.circlevilleherald.com/news/extension-of-state-route-causes-change-in-road-names/article_6bf372ad-233a-5a0d-87eb-6f9c33ed688c.html)
http://www.dot.state.oh.us/Divisions/Planning/SPR/Pic-East-West/Documents/Planning%20Documentation/Duvall%20Journal%20Entry.pdf (http://www.dot.state.oh.us/Divisions/Planning/SPR/Pic-East-West/Documents/Planning%20Documentation/Duvall%20Journal%20Entry.pdf)
Perhaps this is already in the queue for updates to the Ohio state highways, but if not, I wanted to pass it along.
We mostly still (for now) post any highway changes to the 'old forums (http://clinched.s2.bizhat.com/index.php)'. This will probably change once we're ready to get the new website up running fully and install a forum there since (IMO) it would be easier in a 'true' forum to keep track of these changes instead of in GitHub.
Anyways, OSM does show the new route extension, while Bing & Google don't even show the new alignment over the new bridge yet.
Quote from: rickmastfan67 on July 12, 2015, 07:43:58 PM
We mostly still (for now) post any highway changes to the 'old forums (http://clinched.s2.bizhat.com/index.php)'. This will probably change once we're ready to get the new website up running fully and install a forum there since (IMO) it would be easier in a 'true' forum to keep track of these changes instead of in GitHub.
Anyways, OSM does show the new route extension, while Bing & Google don't even show the new alignment over the new bridge yet.
I tried signing up for the old forum late last year but never got activated and I wasn't sure if I could post without a registered user name. I'll drive the new route as soon as I can and try to get a few pictures if that is useful. I wasn't sure exactly where to share this info with the new site not yet up and running yet and the old CHM site essentially inactive.
I know we very likely won't use GitHub for end-user reported issues, but to keep track of this one, I've opened a GitHub issue so we don't lose track of it.
I've been spot checking the TM data against the old CHM data and have run into one error I can't figure out.
CHM shows a total mileage in Wisconsin as 11,783.1 mi. TM has it at 11,778.89, a difference of 4.21 miles. CHM rounds data to the nearest 0.1 mi in the tables, and TM rounds to the nearest 0.01, but this shouldn't result in a difference that great; no other states are off by anywhere near that amount.
Comparing individual route systems, the totals are (CHM/TM):
Interstates: 748.9 / 748.96
US highways: 2902.8 / 2902.83
US auxiliary highways: 118.2 / 113.73
MN state highways: 0.5 / 0.49
WI state highways: 8717.9 / 8718.10
Obviously most of the 4.21 mi difference is coming from the US auxiliary highways. And I found one error in that set: in TM, US53BusSol (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=wi.us053bussol&u=mapcat) shows up as the same route as US53BusSup (http://www.teresco.org/~terescoj/travelmapping/hbtest/?r=wi.us053bussup&u=mapcat). However, the difference between the correct mileage (4.5 according to CHM) and the mileage in TM (3.02) is only a mile and a half, not 4 miles.
Given the way data are presented in clinchableroutes.log, I've been unable to detect a missing entry in TM. Maybe CHM has the error; it's hard to say. I even compared the sum of CHM's individual routes from the tables to the total US auxiliary mileage, and although there is a difference (118.2 vs 124.3), it's actually the wrong direction (i.e., even further from TM's total).
Anyone else want to give this a shot?
Si has submitted a bunch of highway data updates I'd like to bring in to start getting things more up-to-date. I think it makes sense to have at least a couple people have a look at any changes like these before they get pulled into the master on GitHub. Would a few of the people with CHM highway data experience be willing to check it out? I think anyone should be able to see and comment upon the pull request in GitHub. It's the "Update test branch 2" pull request in the HighwayData repository in the TravelMapping organization. If you're interested in doing this and can't see and/or comment on the pull request on GitHub let me know so I can try to figure out how to set it up so you can.
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.
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.
Quote from: Jim on August 08, 2015, 10:43:01 PM
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've printed out the instructions, to review more closely when I'm more awake. But they seem to be based on DOS-like command lines (in the "GIT shell" that got installed on my PC when I opened my GitHub account?), rather than the Windows version of GitHub I've been trying to use (which might be the source of all the problems I've been having). I'll have to figure out whether the steps you outline can be done within the Windows environment, or whether I need to get used to a new command-line environment only partially similar to the DOS environment what I abandoned many years (or decades) ago.
If the latter, I'll need to figure out how to move new or revised files edited in a Windows program into where they need to be for a pull request. If at least that part can be done within Windows, so much the better.
I am sure everything can also be done in the Windows program, and some steps right through the web. More likely, the git shell will be easier long term.
oscar, if you figure out how to do this via Windows, let me know. Might be the only way I can do it since I don't have a Linux OS, and don't have the extra space at this time for a virtual Linux OS copy on my HDs.
If nothing else, there seems to be the "Git Shell" for Windows that would let you run the commands. I think the command-line interface is faster once you get the hang of it.
For simple updates, changes should also be able to made right on the GitHub copy (your fork of it, anyway). If I have a chance, I'll pick another fix that needs making in my regions and see if I can do it entirely through the web interface. If so, I'll add that to the instructions on the wiki.
Quote from: Jim on August 09, 2015, 08:06:07 PM
If I have a chance, I'll pick another fix that needs making in my regions and see if I can do it entirely through the web interface. If so, I'll add that to the instructions on the wiki.
Thanks Jim. Hopefully it's straight forward on how to do this it via the web interface.
Quote from: rickmastfan67 on August 09, 2015, 06:57:53 PM
oscar, if you figure out how to do this via Windows, let me know. Might be the only way I can do it since I don't have a Linux OS, and don't have the extra space at this time for a virtual Linux OS copy on my HDs.
I don't use Windows all that frequently, but I think the commands listed can be run in the command prompt. I'm not really familiar with Github's GUI for Windows (however I have used other Git clients in Linux before)
Quote from: rickmastfan67 on August 09, 2015, 08:38:24 PMThanks Jim. Hopefully it's straight forward on how to do this it via the web interface.
It's very straightforward if you are doing a simple change. Becomes a lot more annoying if you are editing a lot of files.
Man oh man. GitHub. Gee whiz...
I entered a username and password to sign up. It wanted a credit card number for billing purposes, which I didn't particularly care for. It wouldn't let me proceed, or so I thought. So I nixed the whole process. Only to later find a confirmation the next time I checked my email. Only, the links therein don't work. Nothing on the email verification page seems to actually do anything. It *could* be a browser upgrade thing, but... GRRR.
I'm 99% sure I've never given GitHub a credit card number. Maybe you wound up somehow at a section of the site for paid project hosting or something like that?
Well, it did give me the option of selecting a free account (no private repositories, only public, IIRC), but still informed me the credit card number was a required field.
So I closed the browser window and abandoned it all. Only to find it seems it went ahead and created the account for me anyway -- only, I'm just stuck at the email verification step.
Ugh. One would think this whole thing could be made a bit more intuitive.
Quote from: yakra on August 10, 2015, 01:06:59 PM
Well, it did give me the option of selecting a free account (no private repositories, only public, IIRC), but still informed me the credit card number was a required field.
So I closed the browser window and abandoned it all. Only to find it seems it went ahead and created the account for me anyway -- only, I'm just stuck at the email verification step.
Ugh. One would think this whole thing could be made a bit more intuitive.
When I created my account to signup and access some OSM related repositories to report bugs, I wasn't asked for a credit card. :/
Quote from: english si on August 10, 2015, 04:52:29 AM
Quote from: rickmastfan67 on August 09, 2015, 08:38:24 PMThanks Jim. Hopefully it's straight forward on how to do this it via the web interface.
It's very straightforward if you are doing a simple change. Becomes a lot more annoying if you are editing a lot of files.
Hmmm, I may just give it a try on a simple fix. All I know I want to do really first is get my last updates that I had sent into Tim into the database. Then I can start doing more 'major' changes to get my data up-to-date in the states I maintain.
Is it really hard to 'delete' a route? I know there is one I need to axe in SC.
EDIT: Ok, looks like the online GUI looks easy enough to use. So, I'll start out with an exit number fix in Georgia on I-16. http://clinched.s2.bizhat.com/viewtopic.php?t=2297&mforum=clinched Don't know if this would count as something that should be mentioned on the 'update' page because of the moving of '1' to I-75 since it's in use @ the first exit (which is really 1A, not 1).
So is US 310 supposed to go to Greybull? Or is it just an error?
(I think this is the right place for these types of things, not sure)
Quote from: Jim on August 10, 2015, 12:50:42 PM
I'm 99% sure I've never given GitHub a credit card number. Maybe you wound up somehow at a section of the site for paid project hosting or something like that?
I also never gave -- and was never asked for -- a CC number when I set up my account. I'm still trying to get the hang of GitHub -- haven't had a chance to use the mini-tutorial Jim assembled over the weekend -- but did manage to copy two of GitHub's repositories to my computer, so it's working for me at least to that extent.
Quote from: SD Mapman on August 11, 2015, 01:19:44 AM
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.
I gave Jim's tutorial a try yesterday, and (while I got a repository on the PC, which was a problem with the 'for Windows' interface I was having) failed to get anything meaningful to happen.
I still massively prefer the web interface to the shell interface, and prefer the 'for Windows' interface over both.
The web interface I can see what I'm doing even if it is clunky to add a ton of files, whereas the shell one I'm a step further removed telling my computer to do what I'd do on the web interface. It's not the outdatedness of the command line operation that bugs me, it's that it's neither quicker nor better and is alien to me.
The 'for Windows' one is just so much more logical than the shell interface - I copy a file (or a folder) over from my Dropbox folder to the Github folder, it shows me clearly what changes I've made and then I can commit and sync with a few button presses. I can edit .wpt and .csv files in the way I have done for years and I don't need to learn all these Linux commands.
But the web one is good enough for general maintenance, so I'm sticking with that.
Quote from: yakra on August 10, 2015, 01:06:59 PM
Well, it did give me the option of selecting a free account (no private repositories, only public, IIRC), but still informed me the credit card number was a required field.
So I closed the browser window and abandoned it all. Only to find it seems it went ahead and created the account for me anyway -- only, I'm just stuck at the email verification step.
Ugh. One would think this whole thing could be made a bit more intuitive.
No need for one - you must have tried to sign up a private repository - which is not free.
Quote from: english si on August 11, 2015, 05:34:56 AM
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?
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.
Quote from: oscar on August 11, 2015, 01:48:42 AM
Quote from: SD Mapman on August 11, 2015, 01:19:44 AM
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.
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).
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.
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).
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)
Quote from: oscar on August 11, 2015, 10:07:52 PM
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.
Quote from: SD Mapman on August 12, 2015, 12:17:07 AM
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.
Quote from: Jim on August 08, 2015, 10:43:01 PM
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
QuoteNow I want to get this branch back to the origin of my fork on GitHub. I first push the branch to GitHub:
My output:
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 failedSo 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.
Quote from: BickendanI'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?
First version of a datacheck page getting its entries from the DB:
http://www.teresco.org/~terescoj/travelmapping/devel/datacheck.php (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.
Quote from: froggie on August 12, 2015, 11:30:01 AM
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.
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.
Quote from: oscar on August 13, 2015, 12:22:41 AM
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 (http://clinched.s2.bizhat.com/clinched-ftopic2250.html) 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.
Quote from: SD Mapman on August 13, 2015, 01:00:28 AMAlso, this (http://clinched.s2.bizhat.com/clinched-ftopic2250.html) 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.
Also, should US 34 at the Missouri River be shifted up to the new bridge? (along with all the related shifts)
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.
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.
Just a simple friendly reminder for all of us contributors.
Don't forget to update/lock/move threads in the old forums (http://clinched.s2.bizhat.com/viewforum.php?f=2&mforum=clinched) 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. ;) :wave:
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 :banghead:.
Quote from: oscar on August 11, 2015, 10:07:52 PM
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.
Quote from: mapcat on August 11, 2015, 09:33:29 PMThe 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.
Quote from: SD Mapman on August 12, 2015, 12:17:07 AMAlso on that, WY/MT is at the wrong Yellowstone entrance (West instead of north)
Fixed.
Quote from: rickmastfan67 on August 18, 2015, 08:32:11 AM
Just a simple friendly reminder for all of us contributors.
Don't forget to update/lock/move threads in the old forums (http://clinched.s2.bizhat.com/viewforum.php?f=2&mforum=clinched) 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. ;) :wave:
I gone through the relevant threads and locked ones dealt with and am dealing with the others.
Quote from: yakra on August 10, 2015, 02:02:14 AM
Quote from: english si on August 07, 2015, 02:13:43 PM
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!
Quote from: rickmastfan67 on August 12, 2015, 01:01:56 AMJust 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?).
Quote from: oscar on August 12, 2015, 04:10:47 AM-- 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.
Quote-- 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!
Quote from: Jim on August 12, 2015, 09:22:46 AMFor 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.
QuoteIf 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.
Quote from: english si on August 20, 2015, 09:29:41 AM
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 :banghead:.
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.
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.
Quote from: english si on August 07, 2015, 02:13:43 PM
Quote from: oscar on August 12, 2015, 04:10:47 AM-- 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.
Quote from: english si on August 07, 2015, 02:13:43 PM
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.
Quote from: oscar on August 20, 2015, 01:36:47 PMAn "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").
Quote from: oscar on August 20, 2015, 01:36:47 PMParallel 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.
QuoteI 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.
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.
Quote from: oscar on August 21, 2015, 12:01:54 PM
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.
Already dealt with three comments on usaco. The old forum, private messages, here - wherever.
A thread here is probably best.
Quote from: oscar on August 21, 2015, 12:01:54 PMBut 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.
When we get a project-specific forum up and running, I'd like to see it all or almost all public. We can always use private messages or other mechanisms if something needs to be discussed that for some reason should not be seen by the end users. The only place I can really think that was a slight positive in the old CHM forum was keeping the point request thread private so we could avoid a flood of point requests from end users for every little turnaround. I suppose it wouldn't hurt to have a private subforum there but I'd prefer it to be used rarely.
Quote from: Jim on August 21, 2015, 01:02:45 PM
We can always use private messages or other mechanisms if something needs to be discussed that for some reason should not be seen by the end users. The only place I can really think that was a slight positive in the old CHM forum was keeping the point request thread private so we could avoid a flood of point requests from end users for every little turnaround. I suppose it wouldn't hurt to have a private subforum there but I'd prefer it to be used rarely.
I'd distinguish between "point requests" and "point suggestions". "Point requests" were basically a "collaborator perk", rejected only if unreasonable, but only collaborators could make them. But CHM also stiff-armed "point suggestions" made in the public part of the forum. I would be more open to such suggestions, if they are something likely to be helpful to other users rather than just a personal favor to the requester, though it would be entirely up to the relevant team member whether to adopt a suggestion.
Now that we have several people well underway using GitHub to submit highway data updates, I'd like to bring up a few things.
1) It would be good if someone can take charge of a sources spreadsheet/CSV. I think we want to start with CHM's list and make sure we keep it up. I think it should just be another .csv in the HighwayData repository like the updates one.
2) The fork/pull model of data updates has worked far better than I hoped from my perspective as the primary person managing those changes. I'm hoping that those contributing highway data updates are finding the process at least tolerable if not always intuitive. This has to be worlds easier than what Tim had to do with everyone sending zip files. That said, it would be nice if some of the typos and other problems could be discovered before I pull them in and try running an update. If you have a computer capable of running Python 3.4 (this is you, most likely) and can get copies of our DataProcessing, HighwayData, and UserData repositories, it shouldn't be too bad. Basically, you would want to point a few paths in the read_data.py program to the right places to find all the data and then run it. If you get errors or warnings, you can fix them and try again. There's also nothing stopping anyone from setting up their own copy of the DB and a web server with a copy of our things in the Web repository and seeing your results as well. But that's not likely of interest to as many people.
3) We can probably move the project to a more permanent web home soon. Assuming we want to use the code I've been working on and using, we'd need a place that has ssh shell access, a modern apache web server with PHP, and a recent mysql database. If I have a chance, I might try setting up a copy of this in my hostmonster account to see if it will work. I know we have a domain name, but I don't think there's anything else yet. I'm perfectly willing to host the new domain on my FreeBSD server, but that leaves me and that server and a pretty small pipe to the Internet all as single points of potential failure.
4) I mentioned datacheck errors recently. I need to track down a problem that's keeping them from loading into the DB now, but once that's done, one of my priorities related to the project (second to processing updates every day or two) is to come up with the mechanism to mark false positives so we can aim for a clean slate for all active systems, and know what needs to be fixed in the in-development systems. One of the big things here is to make sure things already marked in CHM that haven't changed in our data can remain FPs. Once a mechanism is in place, I think it will make sense for someone to be the primary person in charge of maintaining the list of FPs and watching the error list for things that need attention. My semester starts very soon so it will be hard to dedicate much time to it for a while now.
Quote from: Jim on August 21, 2015, 03:52:10 PM
1) It would be good if someone can take charge of a sources spreadsheet/CSV. I think we want to start with CHM's list and make sure we keep it up. I think it should just be another .csv in the HighwayData repository like the updates one.
I should be able to take care of this, especially since I'm almost done updating my jurisdictions. But I first have to take care of my non-roads websites, which are on a webspace my ISP is shutting down in a few weeks, so I need to find a new home for them (perhaps on a webspace I control and isn't affected by the shutdown).
Quote from: Jim on August 21, 2015, 03:52:10 PM
2) The fork/pull model of data updates has worked far better than I hoped from my perspective as the primary person managing those changes. I'm hoping that those contributing highway data updates are finding the process at least tolerable if not always intuitive. This has to be worlds easier than what Tim had to do with everyone sending zip files. That said, it would be nice if some of the typos and other problems could be discovered before I pull them in and try running an update. If you have a computer capable of running Python 3.4 (this is you, most likely) and can get copies of our DataProcessing, HighwayData, and UserData repositories, it shouldn't be too bad. Basically, you would want to point a few paths in the read_data.py program to the right places to find all the data and then run it. If you get errors or warnings, you can fix them and try again. There's also nothing stopping anyone from setting up their own copy of the DB and a web server with a copy of our things in the Web repository and seeing your results as well. But that's not likely of interest to as many people.
That's probably beyond both my technical abilities and my hardware (all my computers are Windows boxes, one of them an ancient one still on Windows Vista). I'll just have to be more careful in assembling my pull requests, and try to keep them bite-sized to minimize the risks of errors in my submissions.
Quote from: english si on August 20, 2015, 02:23:13 PM
Things like the Lincoln Highway have also been suggested (system name of something like "United States Select Scenic and Historic Highways").
The challenge here is "which alignment of it?". At various points in its history any "historic route" will have been realigned, so there is no one single alignment to follow.
Then you have the many cases where modernization of a highway has resulted in segments of what was the old route left as odd and perhaps discontinuous jogs - see for example all the little bits of "Old (Boston) Post Road", "Old Kings Highway", etc. in Connecticut. To what degree, if any, is it appropriate to mark the historic route as following the old alignment(s) that were actually signed as it back in the day versus the modern alignment which was never signed as it but is now the de facto through road along the corridor?
Consider as well that in some cases what was the old route is not driveable. The original routing of US 1 (and also the Boston Post Road) through Stamford CT is still more or less clinchable on foot, but it involves walking through a park and a mall as well as using a bridge which is closed to vehicular traffic. Would we route "CT BosPostRd" along that, or along the newer road which was created in the 1970s?
Quote from: Duke87 on August 22, 2015, 11:44:26 AMConsider as well that in some cases what was the old route is not driveable. The original routing of US 1 (and also the Boston Post Road) through Stamford CT is still more or less clinchable on foot, but it involves walking through a park and a mall as well as using a bridge which is closed to vehicular traffic. Would we route "CT BosPostRd" along that, or along the newer road which was created in the 1970s?
My feeling is this: if it is a historic route, follow the historic route. Of course, this leaves the problem that you raise: at which time period? I know US 66 has a few alignments through Illinois that depend on just when you're talking about. But for something like the Boston Post Road, I'd be prone to "the most historic route" of the historic route. If it's only clinchable by foot, well, that's the alignment. The newer 1970's road is not a "historic route". Yet.
This exact situation of undriveable alignments (potentially with no modern alignment available to boot) also applies to things like the Old Spanish Trail too. So it's hardly a unique situation.
But I suspect this is, as of right now, small potatoes.
If we do historic routes, I think those that are signed somehow make the most sense. Even if there are multiple signed alternatives, no harm in including them all. For example, I recall there being multiple signed Historic US 66 routes through New Mexico, one of which went up through Santa Fe, another more directly to Albuquerque. Nothing would stop us from including all such routings, using the same kinds of mechanisms we use for multiple segment routes in current systems.
I don't think it's worth trying to get old routings that have no official designation or signage. There's going to be too much guesswork, both in trying to map the routes for the project, and for travelers trying to clinch them.
Quote from: Jim on August 22, 2015, 01:39:35 PM
If we do historic routes, I think those that are signed somehow make the most sense. Even if there are multiple signed alternatives, no harm in including them all. For example, I recall there being multiple signed Historic US 66 routes through New Mexico, one of which went up through Santa Fe, another more directly to Albuquerque. Nothing would stop us from including all such routings, using the same kinds of mechanisms we use for multiple segment routes in current systems.
I don't think it's worth trying to get old routings that have no official designation or signage. There's going to be too much guesswork, both in trying to map the routes for the project, and for travelers trying to clinch them.
Indeed. I gather parts of the Lincoln Highway are signed (at least patchily).
Quote from: english si on August 22, 2015, 01:51:39 PM
Indeed. I gather parts of the Lincoln Highway are signed (at least patchily).
Yes, it is in many places. Same with parts of the National Road, plus the multiple routings of US66, US99, etc.
Then you have the Oregon Trail, Santa Fe Trail, Trail of Tears, and so forth, that mostly follow other numbered highways. Would those be part of this system, another, or ignored?
Quote from: mapcat on August 22, 2015, 11:19:47 PM
Quote from: english si on August 22, 2015, 01:51:39 PM
Indeed. I gather parts of the Lincoln Highway are signed (at least patchily).
Yes, it is in many places. Same with parts of the National Road, plus the multiple routings of US66, US99, etc.
Then you have the Oregon Trail, Santa Fe Trail, Trail of Tears, and so forth, that mostly follow other numbered highways. Would those be part of this system, another, or ignored?
Guess it depends on how you define "signed". Boston Post Road has no shields, but many segments of it retain the name "Boston Post Road" on street signs. And in several places there are original 18th century stone mile posts still there by the side of the road, although they're too small and low to the ground to easily spot from a car moving at modern speeds, and at least one has been moved from its original location.
But I suppose unlike things like the Lincoln Highway it is not and never was signed with the intent that people on road trips would be able to follow it by following the signs. Being able to properly follow the original route requires doing some research before setting out to do so.
As mentioned in other places here, it's time to start addressing datacheck errors. This post describes what I've done tonight toward this goal, and asks for one or two volunteers from among our highway data managers to try it out on a small scale before we expand to all data.
I've introduced a new file to the HighwayData repository, datacheckfps.csv, which should contain an entry for each datacheck error that has been verified to be a false positive (FP). At least for now, the definitions of a datacheck error, and what qualifies as an FP, remain the same as CHM. This file is consulted during a site update to flag errors as they are detected. The datacheck page in its current, very basic format (http://www.teresco.org/~terescoj/travelmapping/devel/datacheck.php (http://www.teresco.org/~terescoj/travelmapping/devel/datacheck.php)), shows all datacheck errors, with a column indicating FPs. I've added a new column that prints, for each error, the .csv line that would be added to the datacheckfps.csv file to mark it as an FP (for easy copy and paste). My next project goal, other than continuing to process data and list updates, is to enhance the datacheck page to have 3 tables instead of 1. 1) Errors in active systems that are not flagged as FPs, which should be addressed with high priority, 2) Errors in in-development systems that would need to be addressed or flagged as FPs before activation, and 3) Errors that have been flagged as FPs in any systems. Later, I think it will be useful to include a list of entries in datacheckfps.csv that didn't match any detected error, as these might be indications of new errors introduced.
Anyway, for now, I'd like a few of our highway data managers to take one of your smaller systems and send me, by email, the csv entries for false positives in that system, so I can further test my code that deals with this stuff. Once I'm satisfied that things are working, and maybe with some enhancements to the system to make this process easier, we'll try to get all active systems to show up as clean. I found it useful to compare with entries on the old CHM datacheck page when I processed Massachusetts.
Quote from: Jim on August 24, 2015, 12:59:39 AM
Anyway, for now, I'd like a few of our highway data managers to take one of your smaller systems and send me, by email, the csv entries for false positives in that system, so I can further test my code that deals with this stuff. Once I'm satisfied that things are working, and maybe with some enhancements to the system to make this process easier, we'll try to get all active systems to show up as clean. I found it useful to compare with entries on the old CHM datacheck page when I processed Massachusetts.
Here's one very quick FP from a state I'm in control of currently. I'll check more later and e-mail those instead.
wv.i070;0A;;;EXIT0;Also Jim, is there anyway to have them sorted by 'region' first, and then system, and then route number? Very hard to find routes for one state when they are all over the place.
Quote from: rickmastfan67 on August 24, 2015, 06:31:04 AM
Also Jim, is there anyway to have them sorted by 'region' first, and then system, and then route number? Very hard to find routes for one state when they are all over the place.
Thanks - right now they're just listed by however the DB gives them to me, but I plan to make it easier to navigate, filter, order, later on. Ideally, the list will be nearly empty for active routes after the initial pass for each person's routes. I'm thinking "filter by region" is going to be the easiest and most useful improvement.
I also wonder about how useful the "visible distance too long" errors really are.
Quote from: Jim on August 24, 2015, 08:20:18 AM
I also wonder about how useful the "visible distance too long" errors really are.
Are you checking for "long segment" errors (>20 mi. between waypoints, whether visible or not)? That was to head off technical problems with mapping long interrupted segments, so Tim made us insert shaping points even if not otherwise needed, just to break up the segment. An LS check could be a good fallback for a VD check, and has flagged for me once or twice when my draft route file mistakenly left a long stretch of highway completely unmapped.
I think a VD check is somewhat useful to encourage waypoints every 10 mi. or so (we could tweak the threshold upward) for travelers who turn off or around at places we didn't expect when we drafted the route files. But it can be taken too far, as Tim chided me for taking GPS reads for, and including in my draft Arctic route sets, unnamed and unmapped minor roads such as river accesses just to meet VD requirements. I would favor keeping a VD check, with the understandings that (a) most of them will be crossed off just once as false positives, and (b) we tell new team members not to get desperate about placing waypoints every 10 miles.
QuoteTim chided me for taking GPS reads for, and including in my draft Arctic route sets, unnamed and unmapped minor roads such as river accesses just to meet VD requirements.
i guess I missed that discussion. I added minor ranch access roads in Texas for the same reason.
Quote from: yakra on August 24, 2015, 08:23:46 PM
QuoteTim chided me for taking GPS reads for, and including in my draft Arctic route sets, unnamed and unmapped minor roads such as river accesses just to meet VD requirements.
i guess I missed that discussion. I added minor ranch access roads in Texas for the same reason.
I think that discussion was entirely by e-mail.
Tim's issue was with my inventing names for the access roads I wanted to use, beyond what our waypoint labeling rules allow. Look at the Datacheck entries for Canada's Arctic territories, you'll see a few entries for distances of over 60 miles between visible waypoints, which bothered Tim less than the invented-names points I proposed to reduce those errors.
Yes, same rules apply at this point as CHM. Any visible distance greater than 10 and long segment greater than 20 is flagged.
Hey Jim, I just noticed that there isn't a mention for a version of the 'Exit 0' mention.
WV US-250 (http://cmap.m-plex.com/hb/hwymap.php?r=wv.us250&sys=usaus&rg=all) has a 'Exit #0' mentioned ( I-70(0A) ), but it isn't flagged like the I-70 tag was. Maybe there should be something in your code that could flag any '(0)' or '(0x)' tag as well so it can be double checked too.
Quote from: rickmastfan67 on August 25, 2015, 10:12:51 PM
Hey Jim, I just noticed that there isn't a mention for a version of the 'Exit 0' mention.
WV US-250 (http://cmap.m-plex.com/hb/hwymap.php?r=wv.us250&sys=usaus&rg=all) has a 'Exit #0' mentioned ( I-70(0A) ), but it isn't flagged like the I-70 tag was. Maybe there should be something in your code that could flag any '(0)' or '(0x)' tag as well so it can be double checked too.
Aren't 0x tags less suspicious than a 0 tag? The latter could be a residue from the days when we routinely used 0 and 999 as artificial endpoints in route files (at least for Interstate segments). A 0x tag seems more likely to reflect signage in the field.
Quote from: rickmastfan67 on August 25, 2015, 10:12:51 PM
Hey Jim, I just noticed that there isn't a mention for a version of the 'Exit 0' mention.
WV US-250 (http://cmap.m-plex.com/hb/hwymap.php?r=wv.us250&sys=usaus&rg=all) has a 'Exit #0' mentioned ( I-70(0A) ), but it isn't flagged like the I-70 tag was. Maybe there should be something in your code that could flag any '(0)' or '(0x)' tag as well so it can be double checked too.
Thanks - I opened an issue into Github so I'll remember to address this.
Quote from: oscar on August 25, 2015, 10:24:10 PM
Quote from: rickmastfan67 on August 25, 2015, 10:12:51 PM
Hey Jim, I just noticed that there isn't a mention for a version of the 'Exit 0' mention.
WV US-250 (http://cmap.m-plex.com/hb/hwymap.php?r=wv.us250&sys=usaus&rg=all) has a 'Exit #0' mentioned ( I-70(0A) ), but it isn't flagged like the I-70 tag was. Maybe there should be something in your code that could flag any '(0)' or '(0x)' tag as well so it can be double checked too.
Aren't 0x tags less suspicious than a 0 tag? The latter could be a residue from the days when we routinely used 0 and 999 as artificial endpoints in route files (at least for Interstate segments). A 0x tag seems more likely to reflect signage in the field.
True. Still, if the '0' is getting flagged, so should the '(0)' just in case. I do know that the I-70 example is really posted as '0' in the field, but because of the old '0' & '999' being used for the end points at state lines, we were forced to make it '0A'.
Quote from: oscar on August 24, 2015, 08:52:53 PM
Tim's issue was with my inventing names for the access roads I wanted to use, beyond what our waypoint labeling rules allow. Look at the Datacheck entries for Canada's Arctic territories, you'll see a few entries for distances of over 60 miles between visible waypoints, which bothered Tim less than the invented-names points I proposed to reduce those errors.
In my case, I kinda wibbly-wobblied "Truncated, nearby/distant town name" into "Truncated, nearby/distant
placename". I used placenames included on topo maps. LomaVisRan (http://mapper.acme.com/?ll=30.22889,-103.78750&z=15&t=T), anyone?
The datacheck page now has three tables:
- errors in active systems not flagged as FPs (i.e., the things we need to mark as FPs or fix -- this table should be empty if things are in a good state).
- errors in in-development systems not flagged as FPs (i.e., the things that will need to be marked as FPs or fixed before a system goes active).
- errors in all systems that have been flagged as FPs.
Regarding New Mexico, it looks like the following documents have been updated since I last used similar documents in updating NM's national system routes and drafting NM's state highways:
http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf)
Do we think these are a definitive source about what routes exist and where?
I won't be able to dig through these looking for needed changes in the near term, so it would be great if anyone could at least verify that the highways I have plotted in usanm match those in the first document above, and that termini that are in any way questionable are correct in all routes in the NM region.
I would like this process to be complete before we activate usanm.
We had a report in the old CHM forum about a Truck NY 32 in Glens Falls, and the discussion followed that truck routes are not official from by NYSDOT. (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched)) We have a handful of them in our DB but there are surely more. Thoughts on whether signed truck routes should be included where we know they exist, or leave them all out?
I've never understood why we include truck routes. It's been suggested that there's something remarkable about Truck US-19 in Pittsburgh, but that alone doesn't convince me that the other, unremarkable truck routes are necessary. In PA especially, aren't they posted only in places where the current bridges are structurally deficient? Once those get upgraded, the truck routes will disappear, just like the one in Alliance, Ohio, did after an underpass was modified to allow higher-clearance vehicles.
Quote from: Jim on August 29, 2015, 08:16:17 PM
Regarding New Mexico, it looks like the following documents have been updated since I last used similar documents in updating NM's national system routes and drafting NM's state highways:
http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf)
Do we think these are a definitive source about what routes exist and where?
Just a casual glance, for routes on which I've previously weighed in.
If the lists are authoritative and complete (I have not worked out whether there are routes we know to be in the state system but not in the reports):
-- the on-again off-again NM 497 in Deming looks to be back off again, so we can leave that alone
-- NM 332, mentioned in the NM 11 route file but has no route file of its own, is not a state route
-- NM 300, which we offed after I reported it as unsigned in 2013 (except as a bike route with a different number), is listed in the report, with AADTs reported for years both before and after my report.
Quote from: mapcat on August 29, 2015, 09:08:37 PM
It's been suggested that there's something remarkable about Truck US-19 in Pittsburgh, but that alone doesn't convince me that the other, unremarkable truck routes are necessary.
Well, it's the only known officially approved Truck US Highway by the AASHTO since it's in the logs.
Quote from: Jim on August 29, 2015, 08:52:56 PM
We had a report in the old CHM forum about a Truck NY 32 in Glens Falls, and the discussion followed that truck routes are not official from by NYSDOT. (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched)) We have a handful of them in our DB but there are surely more. Thoughts on whether signed truck routes should be included where we know they exist, or leave them all out?
Makes me wonder about Truck NY 5 as well in Schenectady.
Quote from: rickmastfan67 on August 29, 2015, 10:43:39 PM
Quote from: mapcat on August 29, 2015, 09:08:37 PM
It's been suggested that there's something remarkable about Truck US-19 in Pittsburgh, but that alone doesn't convince me that the other, unremarkable truck routes are necessary.
Well, it's the only known officially approved Truck US Highway by the AASHTO since it's in the logs.
US 9 Truck in Delaware was also approved by AASHTO in 1983...
Mike
Quote from: Rothman on August 30, 2015, 01:08:08 AM
Quote from: Jim on August 29, 2015, 08:52:56 PM
We had a report in the old CHM forum about a Truck NY 32 in Glens Falls, and the discussion followed that truck routes are not official from by NYSDOT. (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched)) We have a handful of them in our DB but there are surely more. Thoughts on whether signed truck routes should be included where we know they exist, or leave them all out?
Makes me wonder about Truck NY 5 as well in Schenectady.
We have that one, and 6 others. We know of at least NY 32 Truck in Glens Falls, but surely there are others we have not discovered.
usany;NY;NY5;Trk;Sch;Schenectady;ny.ny005trksch;
usany;NY;NY9P;Trk;Sar;Saratoga Springs;ny.ny009ptrksar;
usany;NY;NY14;Trk;Gen;Geneva;ny.ny014trkgen;
usany;NY;NY19;Trk;Bro;Brockport;ny.ny019trkbro;
usany;NY;NY29;Trk;Sar;Saratoga Springs;ny.ny029trksar;
usany;NY;NY30;Trk;Sch;Schoharie;ny.ny030trksch;
usany;NY;NY298;Trk;Syr;Syracuse;ny.ny298trksyr;
Some add little or no "clinchable" mileage, as they run along other signed routes for much of their length.
I am not proposing any changes to what we do with US highway truck rounds approved and well signed and shown in the documents we use for references. I am thinking about what we should do with the NY truck routes.
After discovering Truck 32 I went to Mike Fay in Highway Data Services and asked him if he had a list of them; that's when I found out they weren't considered official by Main Office. I think the municipalities come up with them. We don't do pavement sufficiency on them (or traffic counts if they're function class 8, 9, or 19), so I think we can consider them as not being state highways.
Truck 5 and Truck 14 were also my discoveries.
Quote from: vdeane on August 30, 2015, 02:41:49 PM
After discovering Truck 32 I went to Mike Fay in Highway Data Services and asked him if he had a list of them; that's when I found out they weren't considered official by Main Office. I think the municipalities come up with them. We don't do pavement sufficiency on them (or traffic counts if they're function class 8, 9, or 19), so I think we can consider them as not being state highways.
Truck 5 and Truck 14 were also my discoveries.
So, Mike Fay doesn't consider them official and yet we spend the money to sign them...kind of an interesting endeavor to pursue when they aren't official.
Quote from: oscar on August 29, 2015, 09:51:18 PM
Quote from: Jim on August 29, 2015, 08:16:17 PM
Regarding New Mexico, it looks like the following documents have been updated since I last used similar documents in updating NM's national system routes and drafting NM's state highways:
http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf)
Do we think these are a definitive source about what routes exist and where?
Just a casual glance, for routes on which I've previously weighed in.
If the lists are authoritative and complete (I have not worked out whether there are routes we know to be in the state system but not in the reports):
-- the on-again off-again NM 497 in Deming looks to be back off again, so we can leave that alone
-- NM 332, mentioned in the NM 11 route file but has no route file of its own, is not a state route
-- NM 300, which we offed after I reported it as unsigned in 2013 (except as a bike route with a different number), is listed in the report, with AADTs reported for years both before and after my report.
To add on to that, the in-city portion of NM 72 that I reported last year isn't in the logs. That never got added in, though.
It's probably still signed, because New Mexico.
Quote from: vdeane on August 30, 2015, 02:41:49 PM
After discovering Truck 32 I went to Mike Fay in Highway Data Services and asked him if he had a list of them; that's when I found out they weren't considered official by Main Office. I think the municipalities come up with them. We don't do pavement sufficiency on them (or traffic counts if they're function class 8, 9, or 19), so I think we can consider them as not being state highways.
I think the "not considered official by Main Office" is the clincher. No pavement sufficiency checks or traffic counts might not be enough by themselves, since we're including some locally-maintained but state-designated roads (Vermont especially, but also other states) in state route sets.
I'm declaring the current datacheck page and the mechanism to submit false positives to be good enough to have everyone start going through their regions and making reports. I hope this is as simple as looking through the errors for active routes and matching them up to FPs already reported in CHM to start. I wish this could have been automated, but I just didn't have access to the FP list data in a reasonably convenient format to be able to do so.
I expect very few new datacheck errors that need actual fixes in the data for active routes. Let's focus on the active routes to start, then the in-development systems close to activation.
Like the updates.csv file, it will likely cause a lot of edit conflicts if we all edit the file directly and make pull requests. So let's do like that one, and submit your csv entries for the datacheckfps.csv file to me to add to the file. Posting here, posting in a GitHub issue in the HighwayData repository, or sending to me by email are all good ways to get them to me. Later, once the initial rush is done, I'll sort the file alphabetically so we'd each be making changes in different sections. Git would have no problem with merges in that case.
Datacheck doesn't seem to be picking up all of the label references own route error type.
The following OK examples, where the entire label matches the route name, were flagged:
ok.ok077dced;OK77D;;;LABEL_SELFREF;
ok.ok077smar;OK77S;;;LABEL_SELFREF;
ok.ok077sove;OK77S;;;LABEL_SELFREF;
These false positives from the old page at CHM were not:
NB NB772 NB772_E label references own route
NB NB772 NB772_W label references own route
NB NB845 NB845_E label references own route
NB NB845 NB845_W label references own route
ND US52 US52/281Byp label references own route
Quote from: Jim on August 30, 2015, 09:14:56 AM
Quote from: Rothman on August 30, 2015, 01:08:08 AM
Quote from: Jim on August 29, 2015, 08:52:56 PM
We had a report in the old CHM forum about a Truck NY 32 in Glens Falls, and the discussion followed that truck routes are not official from by NYSDOT. (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched (http://clinched.s2.bizhat.com/viewtopic.php?t=2248&mforum=clinched)) We have a handful of them in our DB but there are surely more. Thoughts on whether signed truck routes should be included where we know they exist, or leave them all out?
Makes me wonder about Truck NY 5 as well in Schenectady.
We have that one, and 6 others. We know of at least NY 32 Truck in Glens Falls, but surely there are others we have not discovered.
usany;NY;NY5;Trk;Sch;Schenectady;ny.ny005trksch;
usany;NY;NY9P;Trk;Sar;Saratoga Springs;ny.ny009ptrksar;
usany;NY;NY14;Trk;Gen;Geneva;ny.ny014trkgen;
usany;NY;NY19;Trk;Bro;Brockport;ny.ny019trkbro;
usany;NY;NY29;Trk;Sar;Saratoga Springs;ny.ny029trksar;
usany;NY;NY30;Trk;Sch;Schoharie;ny.ny030trksch;
usany;NY;NY298;Trk;Syr;Syracuse;ny.ny298trksyr;
Some add little or no "clinchable" mileage, as they run along other signed routes for much of their length.
I am not proposing any changes to what we do with US highway truck rounds approved and well signed and shown in the documents we use for references. I am thinking about what we should do with the NY truck routes.
Don't forget about US-20 Truck in Silver Creek, Jim. ;)
http://cmap.m-plex.com/hb/hwymap.php?r=ny.us020trksil&sys=usausb&rg=all
Jim, here's another problem with the datacheck page.
I honestly think it needs to be fixed before a full scale FP cleanup is done.
https://github.com/TravelMapping/DataProcessing/issues/2
I assumed it was the logical duplicate on loop routes, though you have a point.
The most obvious alteration to the page - even before sorting by region - is links on the root field (like the updates page), so people can click and easily see!
Let's wait before putting much effort into FP reporting. I'm looking at the CHM FP list (over 4300 of them) and I think I can programmatically get the majority of them flagged in TravelMapping.
First batch of grabbing CHM datacheck FPs and converting them is complete. There are now about 1800 more visible distance FPs in our database than there were before. Not everything matched up perfectly since our data has diverged some, but it's a big chunk of work no one has to do to look at those 1800. I should be able to do the same for a couple other error types, notably the sharp angle errors. I also will at some point add a list of items in the FP csv list that didn't match any actual error, which might also give some indication of more errors that can be flagged as FPs without much effort (route name changes, label changes or small repositionings). That will help as much down the road as now. So again, hold off on hunting down FPs until I do as much as I can automating the process. I doubt I'll have any time to work on it tomorrow but maybe Sunday.
A couple quick improvements to the datacheck page: each datacheck page entry now has an HB link, and the three (one with all datacheck errors not flagged as FPs in active systems, one with all datacheck errors not flagged as FPs in in-devel systems, and one with datacheck errors that were successfully marked as FPs) and are color-coded: pink for active unflagged, blue for in-devel unflagged, grey for flagged. But continue to hold off dealing with errors until I can import more from CHM automatically.
Sharp angle datacheck FP entries were almost trivial to import from CHM, so they're in. Another 450+ moved from "to do" to "done"!
3167 of the 4471 currently detected errors are now flagged. That's still leaves a lot (1304, in fact) but we're making quick progress here.
I like the color coding. It makes it easy to hold PageUp/PageDown until I'm looking at the table I want.
A thought I had last night: have links at the top of the page to datacheck.php#InDevel and datacheck.php#FP
Next time I can put a little time in, I'm planning to look for those situations where we have a datacheck error that's not quite the same as the FP entry that was converted from CHM. So if a sharp angle or visible distance error is a match except for the angle or distance, I'll report those specially somehow, so they can be given a quick look and hopefully fixed.
Don't worry about duplicates yet - if you sent in new FP reports and there are also now CHM-imported reports. I got rid of all exact duplicates but I'm sure there are a bunch that will be singled out by the check described above.
I knocked off another 300 or so datacheck false positives by taking the list of those imported from CHM which did not match any TravelMapping error exactly, but did match in all except the distance or angle field. If they were off by less than a half mile or a couple degrees, they were fixed to match the current distance or angle. I feel like this is pretty safe. Most of what remain of visible distance and sharp angle errors in active systems are in Europe. I suspect this is because of Si's recent revamp of so many things over there, meaning my import of CHM FPs didn't help much.
As part of this process, the site update program now produces a new log file which contains all FP reports in the TravelMapping datacheckfps.csv file that didn't match any actual error:
http://www.teresco.org/~terescoj/travelmapping/logs/unmatchedfps.log (http://www.teresco.org/~terescoj/travelmapping/logs/unmatchedfps.log)
Hopefully these will be helpful in identifying more FPs, but if they're really not relevant, their entries should be removed from datacheckfps.csv. Low priority work, for sure.
I think this is all I can do automatically with visible distance and sharp angle errors. Please feel free to go back to reporting FPs of those kinds of errors. There's still some thing I can and plan to do with other error types to mark more FPs automatically from CHM's list, so no need to address those just yet.
Duplicate coordinates datacheck errors now include point labels, and I updated the existing FPs for this in our csv file. I hope to be able to use this new feature to be able to knock off another set of FPs from CHM's list.
All "Exit 0" datacheck errors and most "duplicate coordinate" errors have now been marked as FPs thanks to conversion from CHM's list.
All highway data maintainers, please address all remaining duplicate coordinate, duplicate label, sharp angle, and visible distance datacheck errors by reporting as FPs or fixing the highway data. Si, I am sure that most if not all of the visible distance errors in Russia, Kazakhstan, Tajikistan, and some of the other countries currently generating most of the remaining errors in active systems are false positives. Rather than copying and pasting line by line from the tables on the web, I can get you a list of those errors in csv format for you to check out and then paste into the FP list if that's easier. I do think they all need at least a quick look, though, as a quick spot check quickly showed that tjk.e006, for example, looks to have a point out of order generating a few legitimate errors.
Please continue to ignore all datacheck errors of types other than those listed above until I have had a chance to refine my error flagging for those, and then to convert FP reports from the old CHM list where possible.
Quote from: Jim on September 06, 2015, 08:31:42 PM
All "Exit 0" datacheck errors and most "duplicate coordinate" errors have now been marked as FPs thanks to conversion from CHM's list.
Missed two. :)
wv.us040;I-70(0A);;;EXIT0;
wv.us250;I-70(0A);;;EXIT0;
Also, on the 'unmatchedfps.log' file (http://www.teresco.org/~terescoj/travelmapping/logs/unmatchedfps.log), maybe add a line to it to say when it was last modified?
Quote from: rickmastfan67 on September 06, 2015, 09:36:12 PM
Quote from: Jim on September 06, 2015, 08:31:42 PM
All "Exit 0" datacheck errors and most "duplicate coordinate" errors have now been marked as FPs thanks to conversion from CHM's list.
Missed two. :)
wv.us040;I-70(0A);;;EXIT0;
wv.us250;I-70(0A);;;EXIT0;
Also, on the 'unmatchedfps.log' file (http://www.teresco.org/~terescoj/travelmapping/logs/unmatchedfps.log), maybe add a line to it to say when it was last modified?
Strange - those are in the .csv file and I don't see them in the unflagged errors on the page. Are they showing up there for you?
Good suggestion on the log. Until I can do that, note that it's generated at the same time as everything else you see in http://www.teresco.org/~terescoj/travelmapping/logs/ (http://www.teresco.org/~terescoj/travelmapping/logs/).
Quote from: Jim on September 06, 2015, 09:51:25 PM
Quote from: rickmastfan67 on September 06, 2015, 09:36:12 PM
Quote from: Jim on September 06, 2015, 08:31:42 PM
All "Exit 0" datacheck errors and most "duplicate coordinate" errors have now been marked as FPs thanks to conversion from CHM's list.
Missed two. :)
wv.us040;I-70(0A);;;EXIT0;
wv.us250;I-70(0A);;;EXIT0;
Also, on the 'unmatchedfps.log' file (http://www.teresco.org/~terescoj/travelmapping/logs/unmatchedfps.log), maybe add a line to it to say when it was last modified?
Strange - those are in the .csv file and I don't see them in the unflagged errors on the page. Are they showing up there for you?
You're right, they aren't there. Wondering why they would then show up in the unmatchedfps.log file then.
Quote from: rickmastfan67 on September 06, 2015, 09:58:01 PM
You're right, they aren't there. Wondering why they would then show up in the unmatchedfps.log file then.
Sure enough, they're in the log file but also marked as FPs in the database. I'll have to check it out. Thanks.
I-485 isn't a complete loop?
Quote from: Rothman on September 07, 2015, 09:26:16 PM
I-485 isn't a complete loop?
It is, but mapping it in TM is still in the queue, as are all the new and extended Interstates in Texas. In the past week, we added I-41 in Illinois and Wisconsin, and new I-49 mileage in southern Arkansas and northern Louisiana.
Quote from: oscar on September 07, 2015, 09:41:33 PM
Quote from: Rothman on September 07, 2015, 09:26:16 PM
I-485 isn't a complete loop?
It is, but mapping it in TM is still in the queue, as are all the new and extended Interstates in Texas. In the past week, we added I-41 in Illinois and Wisconsin, and new I-49 mileage in southern Arkansas and northern Louisiana.
Thanks! Really looking forward to this project coming together.
Rothman, if you take a look at the 'old' forums (new ones for errors aren't up yet), you can see us still working on and closing threads there when the updated highway is put into TM. :nod:
http://clinched.s2.bizhat.com/index.php?mforum=clinched
Quote from: oscar on September 07, 2015, 09:41:33 PMmapping it in TM is still in the queue, as are all the new and extended Interstates in Texas. In the past week, we added I-41 in Illinois and Wisconsin, and new I-49 mileage in southern Arkansas and northern Louisiana.
Many Texas updates in my local files. I've started poring thru the trail of bread crumbs I've left thru various threads at the old forum, to compile a list of files to submit, and a rundown of the changes for each.
So far, the update will include:
* I-69W, I-169, I-69 inside I-610
* US190 relocation and business route, Copperas Cove
* US271 relocation and business route extension, Mount Pleasant
* other stuff
Mystery errors in my latest list file update:
Unknown region/highway combo in line: TX US259BusKil US259_S TX42_N
Unknown region/highway combo in line: TX US377BusWhi US377_S US377_N
The just-renamed route files are in the HB under the above names, but they're not parsing under their new names.
Quote from: oscar on September 11, 2015, 09:51:24 PM
Mystery errors in my latest list file update:
Unknown region/highway combo in line: TX US259BusKil US259_S TX42_N
Unknown region/highway combo in line: TX US377BusWhi US377_S US377_N
The just-renamed route files are in the HB under the above names, but they're not parsing under their new names.
Looks like the .csv entries were not completely updated (Abbrev field). I'll fix and rerun the update.
Looking at some datacheck error detection improvements, and I definitely have too many labels being flagged with the "US_BANNER" error. CHM has just one:
TN US64 US41A/64BusWin_E uses an incorrect banner with US
I'm inclined to dump that error check altogether. Opinions?
Tonight, improvements to the "label references own route" datacheck tonight, and an import of all of the FP reports of this type of error from CHM. I don't pick up all of the errors CHM did, but I think I'm getting the ones most likely to be problematic. See the unmatchedfps.log file for ones that were reported in CHM as FPs but weren't detected as errors in Travel Mapping, and let me know if you think any of those (and ones like them) really deserve to be detected.
So anyway, I think everything showing up in the datacheck report now are things that should be addressed by fixing the data or reporting as FPs.
Quote from: Jim on September 11, 2015, 10:22:35 PM
Looks like the .csv entries were not completely updated (Abbrev field). I'll fix and rerun the update.
D'OH!
QuoteSee the unmatchedfps.log file for ones that were reported in CHM as FPs but weren't detected as errors in Travel Mapping, and let me know if you think any of those (and ones like them) really deserve to be detected.
md.md222;US1/222;;;LABEL_SELFREF;
I think this kind of error/check is worthwhile to add in. This one is a false positive because it references US222.
Thanks for adding these checks in.
Quote from: Jim on September 11, 2015, 10:28:39 PM
Looking at some datacheck error detection improvements, and I definitely have too many labels being flagged with the "US_BANNER" error. CHM has just one:
TN US64 US41A/64BusWin_E uses an incorrect banner with US
I'm inclined to dump that error check altogether. Opinions?
It might not hurt to get rid of it. It's not checking for an error someone's likely to create by accident while editing route files; it just picks up on labels that don't conform to standards. The bulk of them were probably fixed when Tim created that error check, and that's it.
OTOH, there still is one to be addressed on the CHM datacheck page. Is this because it was newly created, or just because it was missed in the last route of fixing errors?
Since we're correcting route names with errors now, someone might want to address I-94BL (Wilbaux, MT). The name of the town it passes through is Wibaux (no L), so it ought to be mt.i094blwib instead of mt.i094blwil.
Quote from: Jim on August 29, 2015, 08:16:17 PM
Regarding New Mexico, it looks like the following documents have been updated since I last used similar documents in updating NM's national system routes and drafting NM's state highways:
http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/NM_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/US_AADT_Listing.pdf)
http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf (http://dot.state.nm.us/content/dam/nmdot/Data_Management/Interstate_AADT_Listing.pdf)
Do we think these are a definitive source about what routes exist and where?
I'm slowly looking through the NM state route set, in CHM's Highway Browser (easier to navigate than TM's, and I assume the contents are so far the same), to pick out routes in the HB that are not on the state highway list above, and routes with waypoints for intersecting routes that may not be in the state system. This is a running list, which I'll add to as I go along, but there are issues with a few route files apparently referring to state routes that aren't.
Routes in the HB, but not on the state list:NM 598
Routes not in the HB, but on the state list:NM 237
NM 300 -- unsigned in 2013, as previously noted
NM 345 -- a post elsewhere on this forum (https://www.aaroads.com/forum/index.php?topic=6780.msg2092920;topicseen#msg2092920) suggests this route may have been recently decommissioned, but I haven't followed up on that
NM 545
Route files showing intersecting state routes not on the state list:NM 2: 339. 340, 507, 557, 558, 560
NM 11: 332
NM 76: 598
Other notes:NM 16: Some online maps (Google, Bing) indicate route continues southeast on Gallisteo Dam Rd. to its end. State AADT list neither confirms nor disconfirms.
NM 30, NM 68, NM 369, and US 84/285: US 84/285 may have been rerouted through Española (per Google Maps and Bing, but not OSM); if so, would need to adjust north endpoint of NM 30, south end of NM 68, and west end of NM 369. Mapquest also shows rerouting of US 84/285, but suggests that part of all of the old route (Santa Clara Bridge Rd.) is NM 369 or part thereof; not sure I believe that, but something to check out. Complicating things some more: fragments of local news articles (mostly hidden behind paywalls) suggesting talks in recent months between city and state officials about exchanging roadways, but unclear which direction the exchange would go. This is something NMDOT probably could best explain.
NM 38: recenter waypoint NM522 (and corresponding point on NM 522)
NM 55: recenter waypoint NM131 (and corresponding point on NM 131)
NM 68 and other state routes: NM 68 junctions with NM 75, NM 76, NM 240, NM 291, and NM 585 should be recentered (one off by about 0.2 mile)
NM 75 and other state routes: NM 75 junctions with NM 68, NM 76, NM 518, and NM 580 should be recentered
NM 96: recenter waypoint NM112 (and corresponding point on NM 112)
NM 103: OSM and Google Maps suggest route extends about 1 mile east of End waypoint; state log does not confirm or disconfirm
NM 105 and NM 276: OSM indicates NM 105 loops through Rociada, and NM 276 meets NM 105 there. Other online maps disagree. But state log indicates NM 276 does not leave San Miguel County, which supports OSM's routings for both NM 105 and NM 276.
NM 111: recenter waypoint CR447
NM 112: recenter waypoint NM514 (and corresponding point on NM 514)
NM 115: OSM (but not other maps), and state log, suggest route continues past waypoint CR455, south to and beyond Canjilon
NM 119: recenter NM451 waypoint (and corresponding point on NM 119)
NM 120: recenter NM434 waypoint (and corresponding point on NM 434)
NM 122: suggest/request new point at what Bing labels Berryhill Rd. about a mile north of waypoint NM606, and OSM calls Highway 605 (really old NM 605 at best, since you already have an NM 605 point further south on NM 122). This is the last intersection before westbound old US 66 turns into a two-lane road. From my 1965 road atlas, it seems to most closely approximates where we drove the old route on a family move to California in 1964, before switching over to the new I-40 freeway west of Grants.
NM 143: recenter waypoint NM198, and perhaps also flip waypoint order since route is milemarked north to south (from NM 549)
NM 150: ThuRd -> ThuRd_E (not necessary to add waypoint for ThuRd_W)
NM 161: delete waypoint CR12 (point far off route, CR 12 may not intersect NM 161); recenter NM518 waypoint (and corresponding point on NM 518)
NM 198: recenter waypoint NM143, and perhaps also flip waypoint order since route is milemarked north to south; End -> SprCanSP
NM 203: move west endpoint west to county line, per state log
NM 206: US70/NM267 -> US70/267
NM 220: recenter waypoint CRD003 on intersection with Paso Monte Rd.
NM 223: NM50/65 -> NM50/63
NM 227: recenter NM478 (and corresponding point on NM 478)
NM 229/MN 357/new US82 Truck?: OSM (but not other online maps) suggests that there is new US 82 truck route in Artesia (state AADT log shows no US truck or other bannered routes anywhere), if so US82 -> US82/82Trk and NM357 -> US82Trk/357; also, Google Maps and Bing but not OSM suggest south end of NM 229 includes Four Dinkus Road back to US 285, which might explain difference between mileage in the HB and mileage in the state AADT log.
NM 236 and NM 267: OSM and Bing suggest NM 236 extends several blocks southeast from waypoint NM267_E along W. Fir St. to N. Ave. B in Portales, where it meets NM 267, which uses Ave. B over new railroad crossing to connect to US 70 and NM 206; state AADT log unclearly suggests that routing of NM 267
NM 240: recenter CamCul
NM 246: recenter CRB031, CRB020, CRB030
NM 290: recenter SprLn
NM 329: does route also include Mills Ave. between NM 65 and I-25BL? OSM, GM. Bing seem to think so, even though it's not in state AADT log.
NM 348: Part of the route seems to be in Texas, though the state AADT log has the whole route in two New Mexico counties. I'd be inclined to treat this as a minor mis-mapping of the state line and not break the route in two or three parts for supposed state line crossings.
NM 369: recenter CR7
NM 371/NM 5001/new US 64 alignment/new US 64 Business: OSM and other mapping services have US 64 through Farmington moved to a new alignment which used to be NM 5001 (which should be deleted from HB), with NM 371 continuing to the old alignment which is now US 64 Business. So for NM 371 route file, NM 5001-> US64, US64 -> US64Bus; conforming changes needed for US 64 route file, as well as a new one for US64BusFar.
NM 378: recenter both endpoints, and corresponding NM378 point for NM 522
NM 395: state AADT log indicates route is more than twice as long as shown in the HB, but truncated entry in online log does not indicate where to put the south end
NM 412: replace JefRd point (Mapnik doesn't show that road intersecting NM 412) with nearby LoriDr (more consensus among online maps on that intersection).
NM 419: JunRidRd -> CRC55A, and recenter
NM 442: HuRd -> LosHueRd
NM 466: waypoint NM300 refers to unsigned intersecting route not in the HB, though on the state AADT log; delete?
NM 475: PasPri -> LaEnt (this point is useful for people who visited the popular Ten Thousand Waves spa north of this intersection, even if point is not needed for shaping)
NM 502: Waypoint CR84 is nowhere near an intersection, or CR 84 (which appears not to intersect NM 502). Suggest making this a hidden shaping point, or substituting a nearby intersection point.
NM 511: recenter waypoint CR4600
NM 518: missing waypoint for NM 434, to match NM518 waypoint in NM 434 route file -- note that I picked this up by accident, there might be other instances where a waypoint on one route lacks a corresponding point on an intersecting state route
NM 540: Mapnik and other online maps suggest this route has become a loop route, with the northern leg connecting back to NM 39, since the last AADT measurement in the state route log (which reflects only the southern leg).
NM 547 and I-40BLGra: State route log has route starting at Santa Fe Ave. (I-40BL) in Grants. Google Maps and Bing show south end of route at Santa Fe @ 1st St. That would mean adding a waypoint there (with corresponding new point on I-40BLGra), new RooAve_S point, and RooAve -> RooAve_N.
NM 552: recenter SR552Ext (is that another state route, though not shown in route log?) and End
NM 554: recenter CR477
NM 572 and NM 331: state route log indicates route runs twice as long as the HB has it, and extends to meet NM 331 at La Puente. Google Maps, but not Mapnik, sorta agrees. NMDOT online road conditions map also agrees, if you zoom it in just one level before it switches from DeLorme data to Bing at more detailed zoom levels.
NM 602: recenter BMWellRd (far from intersection as shown in Mapnik. but matches Google Map and satellite location), or perhaps delete point or relegate to shaping point.
NM 6563: PeaLn -> PieCanRd
There are many other waypoints that could be recentered, in the unlikely event you think I'm not being fussy enough. I've tried to focus on the more significant ones, especially at junctions between state routes.
Quote from: mapcat on September 12, 2015, 02:17:13 PM
Since we're correcting route names with errors now, someone might want to address I-94BL (Wilbaux, MT). The name of the town it passes through is Wibaux (no L), so it ought to be mt.i094blwib instead of mt.i094blwil.
I'm running an update with this fix, and it will be in GitHub also very soon. Thanks.
Quote from: yakra on September 12, 2015, 11:52:03 AM
Quote from: JimSee the unmatchedfps.log file for ones that were reported in CHM as FPs but weren't detected as errors in Travel Mapping, and let me know if you think any of those (and ones like them) really deserve to be detected.
md.md222;US1/222;;;LABEL_SELFREF;
I think this kind of error/check is worthwhile to add in. This one is a false positive because it references US222.
I refined these checks quite a bit. I picked up everything CHM did and a few others (in cases where a label in a route with a banner intersects its parent refers to that parent as part of a "slashed" label) like:
al.us072altdec;US43/72;;;LABEL_SELFREF;
There were about 20 of those, all of which I marked as FPs. That seemed much easier than sinking more time into refining the "LABEL_SELFREF" checks to avoid flagging them.
Does anyone see anything of major concern in either the datacheck.php page list or in the unmatchedfps.log? I don't mean the errors themselves (of which we still have many to deal with) but things showing up in datacheck that shouldn't or things still in unmatched that should be showing up.
If you see entries in unmatchedfps.log that refer to routes that no longer exist or parts of routes that have since changed, please go ahead and delete the corresponding entries from datacheckfps.csv. I removed several tonight as I was working on improving the LABEL_SELFREF checks. Hopefully before too long, both the datacheck.php page's first table (active routes) and unmatchedfps.log can be empty.
I think it would still be worthwhile to refine the code to avoid flagging examples like the one cited above.
Or for another example, tx.us077bushar;I-69E/77;;;LABEL_SELFREF;
It just doesn't sit right with me to flag these, as they're not really self-references at all, but references to the parent route. And especially in the tx.us077bushar case, a pretty legitimate one.
Of course, if you don't feel it's worth sinking much more time into, I can't fault you for that; it's not really fair for me to shout "Fix this!" and not do anything to that end myself...
Can you point me in the direction of the file containing this code on GitHub, and maybe the relevant lines if it's a huge-ish file? I can always have a look around & see what I can see, and scratch my chin thoughtfully... or let real life get in the way and forget about it completely... ;P
Quote from: yakra on September 15, 2015, 12:50:24 AM
I think it would still be worthwhile to refine the code to avoid flagging examples like the one cited above.
Or for another example, tx.us077bushar;I-69E/77;;;LABEL_SELFREF;
It just doesn't sit right with me to flag these, as they're not really self-references at all, but references to the parent route. And especially in the tx.us077bushar case, a pretty legitimate one.
Of course, if you don't feel it's worth sinking much more time into, I can't fault you for that; it's not really fair for me to shout "Fix this!" and not do anything to that end myself...
Can you point me in the direction of the file containing this code on GitHub, and maybe the relevant lines if it's a huge-ish file? I can always have a look around & see what I can see, and scratch my chin thoughtfully... or let real life get in the way and forget about it completely... ;P
I agree wholeheartedly that the example above shouldn't flag an error, I just ran out of time to tweak the check to avoid flagging it. I'd be very happy to bring in any change that avoided it if you get a chance to take a look and have ideas. The relevant code is at https://github.com/TravelMapping/DataProcessing/blob/master/siteupdate/python-teresco/read_data.py starting around line 850. It's possible (and I hope) that there's a quick fix that I didn't see.
In my now-completed review of the draft NM state routes, I just wanted to flag a few possible changes needed to US routes (US 84/285 reroute in Española, US 64 reroute and new business route in Farmington, US 82 Truck in Artesia), and an Interstate business route (I-40BL Grants), that may require changes to those route files, in addition to related changes to some state routes. Also, several routes that may need to be added or deleted in the NM state route set.
Over in the CHM forum, I've bumped a topic on a short rerouting of US 70 in Lordsburg. However, this one has zero effect on the NM state route set.
Jim, I've finished my review of the draft NM state route files, with detailed notes a few posts upthread. Still some items requiring followup, such as to confirm possible changes to some US routes.
Quote from: oscar on September 23, 2015, 11:00:57 PM
Jim, I've finished my review of the draft NM state route files, with detailed notes a few posts upthread. Still some items requiring followup, such as to confirm possible changes to some US routes.
Excellent, thanks. I'm totally swamped right now, so I won't be making any fixes myself in the next few weeks at least, but would gladly process pull requests for any fixes you or others have time to put together to address at least parts of what we know needs addressing.
Quote from: oscar on September 23, 2015, 11:00:57 PM
NM 329: does route also include Mills Ave. between NM 65 and I-25BL? OSM, GM. Bing seem to think so, even though it's not in state AADT log.
I was out there a few months ago, and drove NM 329 according to GMaps. If it wasn't signed along Mills Ave, I believe I would have made note of it, so I suspect there was some signage along that segment, although I can't be certain.
Quote from: mapcat on September 24, 2015, 10:41:28 AM
Quote from: oscar on September 23, 2015, 11:00:57 PM
NM 329: does route also include Mills Ave. between NM 65 and I-25BL? OSM, GM. Bing seem to think so, even though it's not in state AADT log.
I was out there a few months ago, and drove NM 329 according to GMaps. If it wasn't signed along Mills Ave, I believe I would have made note of it, so I suspect there was some signage along that segment, although I can't be certain.
It's signed from the Business Loop Southbound, per GMSV.
Some poking around GMSV:
In Farmington, GMSV indicates that US 64 has been rerouted south of downtown (with the old routing now a business route), and also that NM 371 has been truncated to end at the new US 64:
https://www.google.com/maps/@36.7193753,-108.1803065,3a,75y,271.35h,92.43t/data=!3m6!1e1!3m4!1sjoCi1qRbnVrpRxjGGkhlpw!2e0!7i13312!8i6656?hl=en
https://www.google.com/maps/@36.7210877,-108.185031,3a,75y,335.1h,72.64t/data=!3m6!1e1!3m4!1s42KU_M85F_Nep51BemNxUQ!2e0!7i13312!8i6656?hl=en
https://www.google.com/maps/@36.7193856,-108.1858387,3a,49.8y,289.27h,83.97t/data=!3m6!1e1!3m4!1s75INh7jcM6ZZvi5v5lyFHA!2e0!7i13312!8i6656?hl=en
https://www.google.com/maps/@36.7317196,-108.23417,3a,41.3y,117.3h,92.49t/data=!3m6!1e1!3m4!1sFFrhyRJlJF5uFSUHYjTbOA!2e0!7i13312!8i6656?hl=en
https://www.google.com/maps/@36.7229462,-108.2218459,3a,47.9y,138h,80.59t/data=!3m6!1e1!3m4!1sp55I-pm5eYALf4mUXMq8PA!2e0!7i13312!8i6656?hl=en
https://www.google.com/maps/@36.7221445,-108.2224157,3a,25.6y,86.76h,85.71t/data=!3m6!1e1!3m4!1smxIvW4GKTs1Vrs0V7ut59w!2e0!7i13312!8i6656?hl=en
In Grants, NM 547 meets the I-40 business loop:
https://www.google.com/maps/@35.1499178,-107.8484915,3a,30y,305.81h,93.63t/data=!3m6!1e1!3m4!1s3ccp6Mrx_J52CPLWwKT_MA!2e0!7i3328!8i1664?hl=en
In Artesia, a few of these along what OSM/Mapnik labels US 82 Truck:
https://www.google.com/maps/@32.8562832,-104.429876,3a,48.2y,15.15h,85.18t/data=!3m6!1e1!3m4!1sYJhvdo6G2z2maVN-P2s5YA!2e0!7i13312!8i6656!6m1!1e1?hl=en
https://www.google.com/maps/@32.8571613,-104.398305,3a,37.5y,271.41h,89.65t/data=!3m6!1e1!3m4!1syOQ22Ro_3XSCa3BLtfFhIw!2e0!7i13312!8i6656?hl=en-US
GMSV does not confirm the possible US route change I'd spotted in Española, though maybe that happened after the last time GMSV sent a camera car through there, so it'll will need to be checked out some other way. As I've noted above, the situation in Española is confusing enough that contacting NMDOT might be the best way to nail it down.
We drove through Farmington yesterday and I can confirm the business/bypass distinction. The signs were a little odd–the "bypass" is still like a regular street and the sign said "Truck Bypass," while the business route indicator appears only as part of the shield for said route (picture an old-style US route shield with "Business" above the horizontal line and "Loop" below it). We took the "bypass" route.
I did not see signage for UT 289 in Cedar City today. Does it officially exist? See https://github.com/TravelMapping/HighwayData/issues/118
Quote from: Jim on October 02, 2015, 09:51:38 PM
I did not see signage for UT 289 in Cedar City today. Does it officially exist? See https://github.com/TravelMapping/HighwayData/issues/118
UDOT says it still exists. http://www.udot.utah.gov/main/uconowner.gf?n=7057009304316097 (http://www.udot.utah.gov/main/uconowner.gf?n=7057009304316097)
Then again, that's from 2008...
Here is a list of all the highways in Utah, for future reference: http://www.udot.utah.gov/main/f?p=100:pg:0:::1:T,V:814, (http://www.udot.utah.gov/main/f?p=100:pg:0:::1:T,V:814,)
Also, TM is missing a lot of the higher-numbered routes in that list. Granted, there are several route numbers reserved for "all the roads and parking lots in x", but some of those are actual roads that go somewhere (UT 310, 312, and 314 come to mind)
Aaaand yet another edit, here's a good resource for checking the Utah State Highways set: https://maps.udot.utah.gov/highway/f?p=184:4 (https://maps.udot.utah.gov/highway/f?p=184:4) (be sure to click show state routes)
This one does include the parking lot highways, so that's kinda neat.
There's a ton of routes that either need to be added or decided firmly not to add them (if that makes any sense).
UT 190 needs troubleshooting too.
So I had a hunch today and looked at the NDDOT Williston Bypass page... and it appears to be done to the point where the truck routes in the HB can be shifted over to the permanent alignment.
http://www.nddotwilliston.com/williston-bypass/ (http://www.nddotwilliston.com/williston-bypass/)
This is all from the Internet.
Hello!
Is this the proper thread to report mistakes on the route list? If so, I would like to add that E22 has a new route in Latvia. A part of it is already added, but a part of it is missing. These are the missing sections.
- https://www.google.lv/maps/dir/56.8458176,24.3908874/56.8586876,24.5650321/@56.8744985,24.3740887,11.5z/data=!4m2!4m1!3e0
- https://www.google.lv/maps/dir/56.6647445,25.4658897/56.6413162,25.4460269/@56.6519841,25.4395341,14.04z
- https://www.google.lv/maps/dir/56.514885,27.7530454/56.3823355,28.0803269/@56.4514505,27.8650632,11.71z
Also, are there any plans to add other main roads (A roads) of Latvia? Some of them are of much higher standart than some of the E roads that are already added. If so I'd be happy to help in this process as I have great knowledge on Latvian highways.
Thanks!
Quote from: mepaulrye on October 08, 2015, 07:13:45 AM
Hello!
Is this the proper thread to report mistakes on the route list?
Hello. It is.
QuoteIf so, I would like to add that E22 has a new route in Latvia. A part of it is already added, but a part of it is missing.
While I found signs on the new P80, I had found no evidence that the links were signed as E22, so kept the old route, which was still signed after the P80 opened.
I've rerouted it on both routes.
QuoteAlso, are there any plans to add other main roads (A roads) of Latvia?
I've added the system to the unactivated routes - you'd be able to view them when the next site update occurs, but not count them in your stats yet.
Thanks for clearing things up. If needed I could try to provide some evidence on the E22 new route. ;-)
Quote from: mepaulrye on October 08, 2015, 10:58:18 AMThanks for clearing things up. If needed I could try to provide some evidence on the E22 new route. ;-)
That would be great, though I've routed the E22 via there anyway, and ditched the A6 route. My (now I read it back) cryptic message about 'both routes' meant the P80 and also the new-build bit of A12 further east, rather than P80 and A6.
Latvia routes online now
http://www.teresco.org/tm/devel/hb.php?sys=&rg=LVA
Quote from: english si on October 09, 2015, 06:21:13 AM
Latvia routes online now
http://www.teresco.org/tm/devel/hb.php?sys=&rg=LVA
It's a small system, so maybe peer review and datacheck cleanup can be done fairly quickly and we can get them active.
Quote from: Jim on October 09, 2015, 07:27:15 AMIt's a small system, so maybe peer review and datacheck cleanup can be done fairly quickly and we can get them active.
Sure, though I'd rather focus peer review efforts on gbna1 - mostly for the selfish reason that most of the stuff I'm newly travelling is in that subsystem. ;) I'm sure others would prefer US state routes.
Of course, this system can be short work - there's only 15 routes. I've spotted a few things that mostly have to do with the age of the files and not having updated some of them.
Also, it would be really useful to be able to turn on in-dev systems in mapview.php mode, so that NMP, broken concurrencies (eg missed shaping points), etc can be easily seen and fixed before activation.
Oh, and MPOpen or Mapnik in our Highway Browser, because Google's data is different and what looks like badly placed points are actually correctly placed wrt the open source data we use to make files.
Quote from: english si on October 08, 2015, 12:25:30 PM
That would be great, though I've routed the E22 via there anyway, and ditched the A6 route. My (now I read it back) cryptic message about 'both routes' meant the P80 and also the new-build bit of A12 further east, rather than P80 and A6.
So here's a project .pdf for A12 from 2008, when half of the new A12E22 route was finished. It states that after full completion of A12's new route (through Nirza), the E22 will be re-routed too. The map is in English, and it pretty much sums up what I wrote. Here is the link http://kartes.lvceli.lv/files/Kohezijas%20projekti_2007_2013/Ludza_Terehova.pdf (http://kartes.lvceli.lv/files/Kohezijas%20projekti_2007_2013/Ludza_Terehova.pdf) . I'll try to find more info on the P5/E22 later.
And thanks for the Latvian A routes, can't wait for them to go active. :cool:
Quote from: english si on October 09, 2015, 07:49:19 AM
Also, it would be really useful to be able to turn on in-dev systems in mapview.php mode, so that NMP, broken concurrencies (eg missed shaping points), etc can be easily seen and fixed before activation.
The way I set things up, it's hard to have in-dev systems included easily, but... I also don't think it's hard at all to set up a second server address operating off a second DB instance, where everything in systems.csv, active or not, is included.
QuoteOh, and MPOpen or Mapnik in our Highway Browser, because Google's data is different and what looks like badly placed points are actually correctly placed wrt the open source data we use to make files.
I added an Issue about this in GitHub to remind me to add that in next time I have a chance to open up the web code. If anyone else wants to add it and submit a pull request that would certainly make it happen more quickly.
Quote from: english si on October 09, 2015, 07:49:19 AM
Oh, and MPOpen or Mapnik in our Highway Browser, because Google's data is different and what looks like badly placed points are actually correctly placed wrt the open source data we use to make files.
Mapnik and MQOpen (and MQOpenSat, which we sometimes have to use for point placement) would be good additions. A lower priority (perhaps save for a new waypoint editor) would be to restore other maps in CHM's highway browser (some broken), including standard Mapquest, Yahoo and Bing, which I sometimes find useful for road names to use in waypoint labels.
I checked the in-development SRBA system (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?sys=srba) and I think it's currently complete.
I would add a waypoint at the end of srb.a001nov:
24 http://www.openstreetmap.org/?lat=44.718441&lon=20.463109
What's required to get the system online?
Noticed something interesting on the NY 25 route: the points at Suffolk CR 58 both say NY58.
Quote from: vdeane on October 18, 2015, 06:01:41 PM
Noticed something interesting on the NY 25 route: the points at Suffolk CR 58 both say NY58.
Thanks for the report. An update is running now with these labels fixed.
Quote from: Jim on October 18, 2015, 06:22:12 PM
Quote from: vdeane on October 18, 2015, 06:01:41 PM
Noticed something interesting on the NY 25 route: the points at Suffolk CR 58 both say NY58.
Thanks for the report. An update is running now with these labels fixed.
The route has been updated, but with duplicate CR58_W points.
I hope what should be CR58_E kept NY58_E as an alternate name, since I and perhaps other users had that waypoint in their list files.
Quote from: oscar on October 18, 2015, 06:47:41 PM
The route has been updated, but with duplicate CR58_W points.
I hope what should be CR58_E kept NY58_E as an alternate name, since I and perhaps other users had that waypoint in their list files.
I should know better than to run a quick fix without paying attention to what I'm doing. The old labels remain as hidden alternates.
Update to update running now.
Quote from: Jim on October 18, 2015, 06:51:47 PM
I should know better than to run a quick fix without paying attention to what I'm doing.
What do you mean US85 multiplexes with ND200? ^_^;
With the new in-development TX systems in the Travel Mapping DB, I think we should work out some steps to follow for peer review of new systems. Does it need to be more formal than 2 or 3 others giving a fairly detailed look over the files? And a GitHub issue or a topic here to post the results?
I like the idea Si had for UK A Roads -- starting an issue on GitHub & saying "post your issues & comments here."
I don't think we need anything more formal. (Unsure what that'd even be.)
I like the idea of a GitHub issue, keeping most of the nuts-n-bolts discussion over there, and not going too spamola on AARoads.
At the same time, I think a topic here could bring us a lot more pairs of eyes, and site enthusiasts who don't necessarily want to set up a GitHub account. Comments here could be copied over to a GitHub issue, as I've seen you do.
Are you thinking of keeping this geared more toward CHM/TM veterans who are well versed in The Manual, Peer Reviewing, etc?
Quote from: yakra on October 22, 2015, 12:26:36 AMI like the idea Si had for UK A Roads -- starting an issue on GitHub & saying "post your issues & comments here."
Only problem is how long do I leave it for, before activating stuff?
Quote from: michih on October 18, 2015, 12:01:47 PM
I checked the in-development SRBA system (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?sys=srba) and I think it's currently complete.
I've made some minor tweaks since then of things I saw, but thanks for taking initiative!
QuoteI would add a waypoint at the end of srb.a001nov:
Done.
QuoteWhat's required to get the system online?
I'd want a CHM collaborator to look over the files, but that's really it, as far as I can see. Note - it's 5 files, all freeways and all pretty short.
Quote from: yakra on October 22, 2015, 12:26:36 AM
I like the idea Si had for UK A Roads -- starting an issue on GitHub & saying "post your issues & comments here."
I don't think we need anything more formal. (Unsure what that'd even be.)
I like the idea of a GitHub issue, keeping most of the nuts-n-bolts discussion over there, and not going too spamola on AARoads.
At the same time, I think a topic here could bring us a lot more pairs of eyes, and site enthusiasts who don't necessarily want to set up a GitHub account. Comments here could be copied over to a GitHub issue, as I've seen you do.
I think a separate topic here often would work best. That's what I plan to do shortly for Alaska State Highways, which will entail some general issues about what routes to include in the system, not just nuts-and-bolts stuff.
Quote from: english si on October 22, 2015, 05:59:26 AM
Quote from: michih on October 18, 2015, 12:01:47 PM
I checked the in-development SRBA system (http://www.teresco.org/~terescoj/travelmapping/devel/hb.php?sys=srba) and I think it's currently complete.
I've made some minor tweaks since then of things I saw, but thanks for taking initiative!
Thanks.
Quote from: english si on October 22, 2015, 05:59:26 AM
Quote from: michih on October 18, 2015, 12:01:47 PM
What's required to get the system online?
I'd want a CHM collaborator to look over the files, but that's really it, as far as I can see. Note - it's 5 files, all freeways and all pretty short.
Is it possible that I could be a collaborator?
I thought all in-development systems are in this list (https://github.com/TravelMapping/HighwayData/blob/master/systems.csv) (all systems at the end of the list with "Yes" notification.) and the region managers are here (https://github.com/TravelMapping/HighwayData/wiki).
Some new Finnish routes recently went online but I don't know where it's announced which new systems are in progress. Is there a list?
Quote from: oscarI think a separate topic here often would work best.
I agree with Oscar, especially since I'm not on GitHub.
I'm not quite sure where to put this one.
US87Bus (Buffalo, WY) or US87BusBuf is goofed up. I was in Buffalo the other day (again, because once really isn't enough) and I'm pretty sure that Business 87 doesn't follow the north bypass. The signs weren't super clear on the ground (though I wasn't paying super close attention). If I'm in the area again (and I will be), I can field check this if it's still unclear.
Feel free to split this off into its own topic as necessary.
Highway here: http://tm.teresco.org/devel/hb.php?r=wy.us087busbuf
Quote from: sipes23 on October 25, 2015, 07:47:20 PMUS87Bus (Buffalo, WY) or US87BusBuf is goofed up. I was in Buffalo the other day (again, because once really isn't enough) and I'm pretty sure that Business 87 doesn't follow the north bypass. The signs weren't super clear on the ground (though I wasn't paying super close attention). If I'm in the area again (and I will be), I can field check this if it's still unclear.
I've created Issue #156 https://github.com/TravelMapping/HighwayData/issues/156 (https://github.com/TravelMapping/HighwayData/issues/156) in the HighwayData repository for this one.
I'm working on getting I-269 ready to go into the site for TN. I'll also help out Froggie and do the short MS section since we don't have a state highway system yet for Mississippi. That way, the border points will be synced.
EDIT: Now done. https://github.com/TravelMapping/HighwayData/pull/158
Since dfilpus isn't an active collaborator anymore, could someone else make a few updates in Ohio? In particular, there are two new routes to add, at least one to delete, and two to adjust. Details are in the CHM forum, but the basics are:
Delete OH 238
Reroute OH38 to follow old 238; former 38 between 238 and Washington C.H. is no longer an ODOT route
Extend OH762 east of US23 along Duvall Rd then north along Ashville Pike, terminating at Airbase Rd
Add OH607 along Monastery Rd between OH60 and OH78 east of McConnellsville
Add OH684 along its former alignment and the northern leg of the former alignment of OH692 between OH143 and OH681 (the route was supposed to be decommissioned, but ODOT added it back after local opposition. Dave deleted it but never got around to restoring it)
Quote from: mapcat on October 27, 2015, 10:03:03 PM
Since dfilpus isn't an active collaborator anymore, could someone else make a few updates in Ohio? In particular, there are two new routes to add, at least one to delete, and two to adjust. Details are in the CHM forum, but the basics are:
Delete OH 238
Reroute OH38 to follow old 238; former 38 between 238 and Washington C.H. is no longer an ODOT route
Extend OH762 east of US23 along Duvall Rd then north along Ashville Pike, terminating at Airbase Rd
Add OH607 along Monastery Rd between OH60 and OH78 east of McConnellsville
Add OH684 along its former alignment and the northern leg of the former alignment of OH692 between OH143 and OH681 (the route was supposed to be decommissioned, but ODOT added it back after local opposition. Dave deleted it but never got around to restoring it)
There is one more.
Delete OH 794. The route is no longer an ODOT route and is now maintained by Clark County. I drove the route in early October and can verify that no state route shield remain.
Doing some 'work' on getting the extension of {401} done for the site.
Only thing is I can't decide on a label for one of the 'interchanges'. It's just an interchange with on-ramps from {3} to {401} in both directions. {401} doesn't have any offramps there.
http://www.openstreetmap.org/?lat=42.238300&lon=-83.003517
I'm tentatively calling it '9'. I would have given consideration to labeling it as 'ON3', however, I need to keep 'ON3' as a hidden point (as well as '0') to prevent breaking people's files at the old end of the {401}, which I'm labeling as '10A'. '10' will be at the overpass for {3}. While it will only be .2 miles apart, I feel it's justified because of the historical end of the {401} being there, plus, it allows anybody who cliched the {401} when it temporarily ended at the recently built {3} roundabout to have a 'proper' point. I even had to add 3 'extra' shaping points that normally wouldn't be justified because of the close proximity of {3} there to prevent any false multiplexes. I'll be doing the same with {3}'s file.
Here's the part I'm adding if anybody wants to check it out in the editor and make any comments before I submit to GitHub sometime tomorrow.
5 http://www.openstreetmap.org/?lat=42.264479&lon=-83.044217
6A http://www.openstreetmap.org/?lat=42.256237&lon=-83.038847
6 http://www.openstreetmap.org/?lat=42.251052&lon=-83.035929
+X002(ON401) http://www.openstreetmap.org/?lat=42.248867&lon=-83.033097
7 http://www.openstreetmap.org/?lat=42.246048&lon=-83.026117
+X003(ON401) http://www.openstreetmap.org/?lat=42.241918&lon=-83.013934
9 http://www.openstreetmap.org/?lat=42.238300&lon=-83.003517
+X004(ON401) http://www.openstreetmap.org/?lat=42.234416&lon=-82.996838
10 http://www.openstreetmap.org/?lat=42.233300&lon=-82.993512
10A +0 +ON3 http://www.openstreetmap.org/?lat=42.233371&lon=-82.988211
13 http://www.openstreetmap.org/?lat=42.244754&lon=-82.968943
14 http://www.openstreetmap.org/?lat=42.247598&lon=-82.958088
21 http://www.openstreetmap.org/?lat=42.240740&lon=-82.873574
I found what may be a concurrency issue near Wilmington, NC. Just west of the city, four route (US17, US74, US76, and NC133) all cross the Brunswick River. If my memory is correct (I drove this route over a year ago) all 4 use the same bridge. Looking at my map for the state http://tm.teresco.org/hbtest/mapview.php?rg=NC&u=bejacob (http://tm.teresco.org/hbtest/mapview.php?rg=NC&u=bejacob) and zooming into the area in question, I see two lines, one red (US highways) and one brown (state highway).
It appears that NC133 has two hidden shaping waypoints that the other routes on this concurrency are missing. It would seem that easiest fix is to remove those two hidden waypoints on NC133. The other option is to add them to the other three routes that share the concurrency.
As it has been a while since I drove this route, it might be helpful for someone to verify the concurrency of the US routes with NC133 before making any changes.
Brian
North Carolina highway changes that need to be updated:
I-74 High Point: Extended west to I-40. Delete I-74 Future High Point.
US 421: Moved to Sanford Bypass. Create US 421 Business Sanford along old route.
US 401: Moved to Rolesville Bypass. Create US 401 Business Rolesville along old route.
NC 24/87: Moved from Bragg Boulevard to Murchinson Road (NC 210) and NC 295.
Quote from: rickmastfan67 on October 29, 2015, 03:08:46 AM
Only thing is I can't decide on a label for one of the 'interchanges'. It's just an interchange with on-ramps from {3} to {401} in both directions. {401} doesn't have any offramps there.
http://www.openstreetmap.org/?lat=42.238300&lon=-83.003517
I'm tentatively calling it '9'.
I agree; I'd probably do the same there.
Quote from: rickmastfan67 on October 29, 2015, 03:08:46 AM
I would have given consideration to labeling it as 'ON3', however, I need to keep 'ON3' as a hidden point (as well as '0') to prevent breaking people's files at the old end of the {401}, which I'm labeling as '10A'. '10' will be at the overpass for {3}. While it will only be .2 miles apart, I feel it's justified because of the historical end of the {401} being there, plus, it allows anybody who cliched the {401} when it temporarily ended at the recently built {3} roundabout to have a 'proper' point.
Agree here too.
Quote from: rickmastfan67 on October 29, 2015, 03:08:46 AM
I even had to add 3 'extra' shaping points that normally wouldn't be justified because of the close proximity of {3} there to prevent any false multiplexes. I'll be doing the same with {3}'s file.
While +X002(ON401) may not be strictly necessary to prevent a false multiplex (centerlines are different at Todd Ln), I would probably have put this point here too. Cuts down on visual confusion on closely zoomed-in maps. ON3 could get away without a shaper here IMO (my 2nd choice would be a visible point at Huron Church Line Rd).
Quote from: bejacob on October 29, 2015, 08:35:01 AM
I found what may be a concurrency issue near Wilmington, NC. Just west of the city, four route (US17, US74, US76, and NC133) all cross the Brunswick River. If my memory is correct (I drove this route over a year ago) all 4 use the same bridge. Looking at my map for the state http://tm.teresco.org/hbtest/mapview.php?rg=NC&u=bejacob (http://tm.teresco.org/hbtest/mapview.php?rg=NC&u=bejacob) and zooming into the area in question, I see two lines, one red (US highways) and one brown (state highway).
It appears that NC133 has two hidden shaping waypoints that the other routes on this concurrency are missing. It would seem that easiest fix is to remove those two hidden waypoints on NC133. The other option is to add them to the other three routes that share the concurrency.
Good catch! I edited the US route files as part of adding NC 140 (among other NC and VA major changes), but forgot that NC 133 (which is indeed still concurrent with the US routes, I drove it last week) would also be affected. I'll fix the NC 133 route file accordingly, so TM will once more detect the concurrency.
EDIT: NC 133 fix is now in the TM database.
Quote from: dfilpus on October 29, 2015, 10:39:19 AM
North Carolina highway changes that need to be updated:
I-74 High Point: Extended west to I-40. Delete I-74 Future High Point.
US 421: Moved to Sanford Bypass. Create US 421 Business Sanford along old route.
US 401: Moved to Rolesville Bypass. Create US 401 Business Rolesville along old route.
NC 24/87: Moved from Bragg Boulevard to Murchinson Road (NC 210) and NC 295.
In addition:
NC 87 Bypass Sanford: Created along the Sanford Bypass from NC 87 to US 1.
NC 44: Extended west from I-795 to US-70.
Quote from: dfilpus on October 30, 2015, 11:52:18 AM
Quote from: dfilpus on October 29, 2015, 10:39:19 AM
North Carolina highway changes that need to be updated:
I-74 High Point: Extended west to I-40. Delete I-74 Future High Point.
US 421: Moved to Sanford Bypass. Create US 421 Business Sanford along old route.
US 401: Moved to Rolesville Bypass. Create US 401 Business Rolesville along old route.
NC 24/87: Moved from Bragg Boulevard to Murchinson Road (NC 210) and NC 295.
In addition:
NC 87 Bypass Sanford: Created along the Sanford Bypass from NC 87 to US 1.
NC 44: Extended west from I-795 to US-70.
Thanks (and good to see you back here). Do you have route files for any of these changes, that you could e-mail to Jim or me to get them through GitHub into the TM database?
Quote from: yakra on October 29, 2015, 03:40:06 PM
ON3 could get away without a shaper here IMO (my 2nd choice would be a visible point at Huron Church Line Rd).
I did add a point there. It was mostly a relocation of the old 'HurChuRd' point that was just to the West.
Heads up for highway data maintainers: I've expanded the updates.csv date field entries to YYYY-MM-DD format. All needed changes to the file itself have been made and other parts of the project that process updates data are updated, and the site is live with the new format in place.
I have an idea for comment and, I hope, implementation in the near future. I propose expanding our current "active" vs. "in development" options for highway systems to be three categories:
1) Active systems: systems that we believe are stable and up-to-date, and for which we intend to do all we can to void breaking .list entries unnecessarily, and will publish updates entries when user-affecting changes are made. This is exactly what we do now for active systems.
2) Systems in review: systems we believe are complete but still might need some fixes before becoming active. For these systems, users are encouraged to start creating .list entries, but no promise is made that changes before activation would not break .lists. I expect there are about a dozen systems that would slide nicely into this category given their current status, such as usaut, usanm, usavt, etc.
3) Systems in development: systems that are incomplete or have other mistakes, omissions, or other issues to be resolved before anyone other than the primary developers of the system should be looking at them. There are a number of systems that would fall into this category for now, like the Asian systems, usanp, usaca, usafl.
The systems.csv file's last column would have entries "active", "review", or "development". All would continue to be processed and would generate datacheck and other errors, but those datachecks would be broken into three tables instead of two. Only errors in the third table, the in-development systems, should be ignored. It would be continue to be the case that there should be no errors listed in the active systems, and one requirement for activation would continue to be that no datacheck errors exist in the system.
The motivation for this further breakdown of inactive systems is to speed the transition from review to activation. I would modify the data processing program and the web tools to be able to generate two instances of the database. One would be the active-only systems that we have now. The second would include all "review" systems. Not only would this be fun for travelers who could then see their maps and stats for more systems even though we haven't activated them yet, but would help the developers of those systems find errors by seeing the maps. One would switch from the standard view to the view with the review systems included by adding a parameter to the URLs. This would be automated once we have a better front end to the whole site.
I doubt that I will do much if anything with this before Thanksgiving or maybe even Christmas, but I don't think it's a huge effort, and I'd be interested in any thoughts on it.
Quote from: Jim on November 04, 2015, 01:47:03 PMNot only would this be fun for travelers who could then see their maps and stats for more systems even though we haven't activated them yet, but would help the developers of those systems find errors by seeing the maps.
I like your idea :nod:. I think the system developers would get more feedback from users who are able to see their maps of review systems.
Quote from: Jim on November 04, 2015, 01:47:03 PM
2) Systems in review: systems we believe are complete but still might need some fixes before becoming active. For these systems, users are encouraged to start creating .list entries, but no promise is made that changes before activation would not break .lists. I expect there are about a dozen systems that would slide nicely into this category given their current status, such as usaut, usanm, usavt, etc.
3) Systems in development: systems that are incomplete or have other mistakes, omissions, or other issues to be resolved before anyone other than the primary developers of the system should be looking at them. There are a number of systems that would fall into this category for now, like the Asian systems, usanp, usaca, usafl.
I agree with where you would place usaca for now (where it will stand once we've implemented the three-category system, can be decided later).
What about usaak? I think "in review" is the right category for that system, for which review comments have already started coming in. If so, I'd like to change the title of that thread accordingly.
I like the idea of being able to tentatively map my travels pre-activation. I usually find, when a new system is activated, gaps in my mapping of the new system because I left out a list file entry or two. I could more easily spot and fix in advance those gaps with a tentative map.
I'm go for the three tier system.
Quote from: michih on November 05, 2015, 02:07:34 PM
I like your idea :nod:. I think the system developers would get more feedback from users who are able to see their maps of review systems.
I was thinking the same thing. Glad to know you're considering it.
I like this idea as well, for two reasons:
1) For users actively paying attention, it makes us able to claim travels in new systems sooner than we otherwise could
2) Sometimes the best way to QC something is to just start using it and see what problems you encounter in real world use. Having users start logging travels in "review" systems would also help spread the workload out by effectively crowdsourcing much of the process of locating mistakes.
Count me as on board too.
I think it would be a good encouragement toward peer reviewing.
I'm game as well.
If you're okay with the extra overhead, it sounds good.
OK, good, lots of positive and neutral reaction and no real negatives pointed out to the three-tier proposal. I'll give it a try when I have a chance. I don't think it's hard but I want to find a time when I can block out a few hours for development and testing before I do much with it.
WV 85 ends at US 119, right? ftp://129.71.206.174/county_maps/Boone_1_of_2.pdf (2014 map). TM shows it ending at WV 17.
Quote from: mapcat on November 06, 2015, 10:05:18 PM
WV 85 ends at US 119, right? ftp://129.71.206.174/county_maps/Boone_1_of_2.pdf (2014 map). TM shows it ending at WV 17.
Will look into this and update accordingly.
Quote from: rickmastfan67 on November 06, 2015, 10:12:40 PM
Quote from: mapcat on November 06, 2015, 10:05:18 PM
WV 85 ends at US 119, right? ftp://129.71.206.174/county_maps/Boone_1_of_2.pdf (2014 map). TM shows it ending at WV 17.
Will look into this and update accordingly.
OSM, Bing, Google, all show WV-85 going to US-119.
We currently have WV-17 & WV-85 ending at their intersection.
StreetView from 2011 shows WV-85 going all the way to US-119. https://goo.gl/maps/7HNf3NjcA8u
PDF you linked to shows a WV-85 shield along the route on the West side of Danville & US-119.
So, WV-85 needs to be extended to US-119. I'll work on fixing this later tonight.
(Submitted (https://github.com/TravelMapping/HighwayData/pull/196))
What's the current consensus on the NY truck route issue? It seems like we're not adding new ones that are discovered but retaining the existing ones.
Quote from: vdeane on November 08, 2015, 02:26:31 PM
What's the current consensus on the NY truck route issue? It seems like we're not adding new ones that are discovered but retaining the existing ones.
Did you post about that elsewhere on AARoads? Or on Github? A quick glance upthread here & I didn't see anything...
Anyway, my two cents:
Was part of the concern how "official" they are, whether they're designated/posted by the state or municipality or what? I know there are a couple truck routes in Kansas posted by the city that are included.
Jim added NY29TrkSar & NY9PTrkSar when I discovered them a few years back. I'm pretty sure those are city-not-state as well.
So maybe, add them when they're found, but not go out of our way to make sure we've found them all...
Quote from: yakra on November 08, 2015, 03:14:50 PM
Quote from: vdeane on November 08, 2015, 02:26:31 PM
What's the current consensus on the NY truck route issue? It seems like we're not adding new ones that are discovered but retaining the existing ones.
Did you post about that elsewhere on AARoads? Or on Github? A quick glance upthread here & I didn't see anything...
Anyway, my two cents:
Was part of the concern how "official" they are, whether they're designated/posted by the state or municipality or what? I know there are a couple truck routes in Kansas posted by the city that are included.
Jim added NY29TrkSar & NY9PTrkSar when I discovered them a few years back. I'm pretty sure those are city-not-state as well.
So maybe, add them when they're found, but not go out of our way to make sure we've found them all...
I recall posted about it somewhere around here, though I don't remember what thread it's buried in. If we're keeping in, we have to add Truck NY 32 in Glens Falls (bypassing the roundabout on a short side street connecting US 9/NY 32 to NY 32) and Truck NY 25 on Eastern Long Island (though the route doesn't appear to be well signed except at the eastern end at the intersection of CR 48 and NY 25). There's also some odd signage in Saratoga Springs regarding the US 9 north to NY 50 south and NY 50 north to US 9 south movements at the southern end of the overlap.
Quote from: yakra on November 08, 2015, 03:14:50 PM
Jim added NY29TrkSar & NY9PTrkSar when I discovered them a few years back. I'm pretty sure those are city-not-state as well.
So maybe, add them when they're found, but not go out of our way to make sure we've found them all...
I would argue that it is user-unfriendly and in bad faith to have a list of such things which is known to be incomplete but which no determined effort is being made to complete it.
Consider this: an individual could very reasonably look at a list or map generated by the project and say "okay, if I want to clinch all the state highways in this region of New York, this is my checklist". To go and start maybe sorta sometimes adding truck routes to the list of NY state highways as they are found is to go to users who have planned clinching trips off the existing data and tell them "hahaha you thought you clinched 100% of the roads here, but now we say you didn't, trololololol".
Given that:
1) there is no exhaustive list of NY truck routes available and the state has no involvement in their creation (i.e. they are "unofficial")
2) they are often signed poorly
3) usany has been an active system for several years and truck routes were not included when it first went active
my vote goes to not including any of them. ESPECIALLY because of item number 3. The decision on whether to include things like this should be made when a system is in development, not after it has gone live - due to concerns outlined above about people using the system data to plan clinching trips. I don't want to yank anyone's completion out from under them due to a change in the standards of what is deemed worthy of inclusion.
I don't have a strong opinion on the inclusion of these signed but unofficial NY truck routes. Perhaps they can be moved to their own system, with the understanding that they will be included if signed but that no guarantee of completeness is being made. A thought: are all of the truck routes we know about that have at least some portion not on other state, US, interstate routes always routed on NY's official but unsigned reference routes?
Quote from: Duke87 on November 08, 2015, 10:17:47 PM
I would argue that it is user-unfriendly and in bad faith to have a list of such things which is known to be incomplete but which no determined effort is being made to complete it.
Aah, but in my scenario said list is not
known to be incomplete! :)
My dismissal is just based on practicality: how far down the rabbit hole should a collaborator go to ensure that every potential truck route is known to either exist or not exist? How many hours of effort to pore into collecting them all, and for what diminishing returns?
For my part, I won't go back and comb through all the New Hampshire State Highways and convert every "FooBarVRd" label to the preferred "FBVilRd" format, when my time is better spent busting out the Nebraska State Links & Spurs, or finishing off the Manitoba Primary Provincial Highways. And similarly, I won't check GMSV and the website of every municipality there for the existence of the odd bannered route that's only recognized at the municipal level.
But if a report from the field comes in of something we've missed, then by all means add it. As we do for other errors & omissions.
WRT trip planning: I don't think this should be of too great importance. If a traveler has not been to a given area yet, their plans would likely include the mainline routes & other routes in the area. If they encounter a new unexpected truck route in the area, they can grab it, or not, as is their wont, and toss a report of it our way. If a traveler has
already been to an area, there's the possibility they'd already know about a truck route there we've not included, and also send us a heads-up. I don't see a route's (non)-inclusion as being a make-or-break factor for making a trip to a given area.
As an aside:
Tim once described a rule of thumb on whether to include a Trk route: Does it make sense as an Alt route? I agree with this criterion. It means that NH16 Truck (Berlin) gets included, but NH107 Truck (Berlin) (as more of a truck route
TO NH107) does not. Thus the US9/NY50 connection vdeane mentioned in Saratoga Springs (which I saw myself in I think 2011) would be out. It's more helpful guidance signage than a proper truck route.
IMO, cases where the truck route connects to the parent at one end and to the route the parent terminates at at the other end make sense as an Alt route. (ME ME228 Trk (Washburn) (http://tm.teresco.org/devel/hb.php?r=me.me228trkwas) is an example.) Bannered routes will sometimes do this. (TX TX44 Bus (Corpus Christi) (http://tm.teresco.org/devel/hb.php?r=tx.tx044buscor) for example.)
Quote from: Jim on November 08, 2015, 10:52:13 PM
I don't have a strong opinion on the inclusion of these signed but unofficial NY truck routes. Perhaps they can be moved to their own system, with the understanding that they will be included if signed but that no guarantee of completeness is being made.
I'm not too hot on the idea of breaking them out into their own system. IMO it's clutter, making too many systems unnecessarily. Also confusing & counterintuitive, when in other cases truck routes, as with other bannered routes, are included in the same set as their respective parent state route systems. Joe Traveler just sees a truck route signed as a truck route out there in the field, and probably doesn't know, understand or care what authority designated/signed the route, whether state or municipal or what.
Quote from: Jim on November 08, 2015, 10:52:13 PM
A thought: are all of the truck routes we know about that have at least some portion not on other state, US, interstate routes always routed on NY's official but unsigned reference routes?
Best thing to do would be to find a counterexample.
The only example (non-I/US/NY) I know of off the top of my head (I'm not going to go to the ends of the earth to exhaustively pore thru the USANY list for others right now) is NY29TrkSar; it follows Weibel Ave between NY29 & NY50. Can anyone confirm whether or not that's a reference route?
Wiebel Ave is not a reference route. Neither is Oakland Ave (Truck NY 32, Glens Falls, not in Travel Mapping).
I checked the location of Truck NY 25 near Greenport. Despite thinking there was another reference further west, I cannot confirm with Google Maps, so I think it's just North Road and Morres Lane (both of which are signed Truck NY 25 from NY 25 itself). If it gets added, I'll admit to counting my street view "clinch" of it; one can see much of it from NY 25 and I'm not driving back out that way just for a small truck route (it's an hour and a half round trip from Riverhead, which is otherwise the furthest east I'd need to go to clinch the remaining touring routes in Suffolk County; had I know about the truck route in advance of my trip out there, I could have looped around when I grabbed NY 25 out to Orient Point, but by the time I found it, I was just trying to beat as much traffic as I could back to my hotel).
Quote from: vdeane on November 09, 2015, 02:49:17 PM
Wiebel Ave is not a reference route. Neither is Oakland Ave (Truck NY 32, Glens Falls, not in Travel Mapping).
Thanks. To me, this lowers the status of these NY truck routes a bit more. I'm thinking more and more that we should remove them.
I vote for canning all truck routes, potential and existing. Besides the good reasons already raised, they're not necessarily permanent. Once the low bridge or sharp turn in the mainline route is remedied, no more truck route.
Quote from: yakra on November 09, 2015, 01:31:11 AM
WRT trip planning: I don't think this should be of too great importance. If a traveler has not been to a given area yet, their plans would likely include the mainline routes & other routes in the area. If they encounter a new unexpected truck route in the area, they can grab it, or not, as is their wont, and toss a report of it our way.
I respectfully disagree. Although I'm not chasing down every state highway in every state, some here seem to be doing exactly that, and it seems unreasonable to expect someone who has carefully planned out a clinch-em-all trip to either (a) follow an unexpected truck route along an unknown path, perhaps adding 30 minutes or more to his or her itinerary, or (b) forgo the new discovery in the interest of saving time, only to need to plan a distant return trip just for that one. Option (a) would also be particularly aggravating to a traveller who, upon reporting the discovery, learns that for some reason it doesn't pass muster and won't be added anyway.
Finding a similar "surprise" new mainline (or business, or alt) route would be far less likely because of the meticulous work done on preparing all new route sets prior to activation. The discussion so far has made it obvious that at least one state lacks a comprehensive list of truck routes; I doubt most others differ.
Quote from: mapcat on November 10, 2015, 12:35:52 AM
I vote for canning all truck routes, potential and existing. Besides the good reasons already raised, they're not necessarily permanent. Once the low bridge or sharp turn in the mainline route is remedied, no more truck route.
What about state-designated truck routes that function more as bypasses? I vote those should stay in at least.
Quote from: mapcat on November 10, 2015, 12:35:52 AM
The discussion so far has made it obvious that at least one state lacks a comprehensive list of truck routes; I doubt most others differ.
South Dakota does.
[2 cents]
not sure why it can't just be left up to whoever maintains the state...CHM and TM are not the arbiters of whether any individual has "completed" a state's system or not. That is up to the users to decide for themselves.
For example, someone may decide they need to travel all of Virginia's unposted state routes that are publicly accessible to clinch the state system, whereas TM will give you 100% credit with just the posted ones...
And while it is true that missing an unknown truck route would cause somebody to have to make a long return trip, that can also happen if a bypass opens after you've been there already...
For me personally I don't care if they are there or not. If they are in I map them if I've been on them.
[/2 cents]
Mike
+1 what Mapmikey just posted, especially the part where it should be up to whomever maintains the state. Generally speaking, whomever maintains a given state is likely to have more of a working knowledge of that state than others, and should know what to include and not to include. We saw this very painfully with the Vermont routes/files on CHM.
Thanks. I'd encourage all highway data contributors to prioritize updates in their regions and getting nearly-ready systems prepped for activation over plotting of new routes and new systems. I don't want us to enforce the "you can only be developing 2 systems at a time" rule CHM had. I know from experience that new development is a lot more satisfying than maintenance and tracking down annoying little problems but as we know all too well, systems get stuck so close to activation and never get that final push.
I second MapMikey & Froggie.
I have no problem with it being a state by state decision whether such things warrant inclusion. I'm all in favor of this, frankly. Once size does not fit all.
What I DO have a problem with is the goalposts getting moved ex post facto. The decision about whether to include such things in a system should be made before it goes live, and then stuck with.
My opinion that truck routes should not be included is specific to NY, largely on this basis. They weren't included when the system first went live, so we should keep it that way for the sake of fairness to users relying on the highway data as a checklist (disclosure: I am one of said users, so I do have some skin in this game).
Quote from: Duke87 on November 10, 2015, 09:52:21 PM
My opinion that truck routes should not be included is specific to NY, largely on this basis. They weren't included when the system first went live, so we should keep it that way for the sake of fairness to users relying on the highway data as a checklist (disclosure: I am one of said users, so I do have some skin in this game).
I think that was because we didn't know of most of them. I recall having to bring it up to Tim's attention about the US-20 Truck route in Silver Creek, NY. That route's been around for pretty much my entire life when I've passed by that town.
Quote from: froggie on November 10, 2015, 10:21:20 AM
+1 what Mapmikey just posted, especially the part where it should be up to whomever maintains the state. Generally speaking, whomever maintains a given state is likely to have more of a working knowledge of that state than others, and should know what to include and not to include.
So, essentially, you're saying that if collaborator Bob chooses to include truck routes in his states, and collaborator Bill chooses to ignore them in his states, that's fine? How do you explain that to a user who, familiar with one of Bob's states, submits a list of truck routes he's found in one of Bill's states, and asks that they be added? To the user, they will be the same; "No thanks, Bill doesn't deal with truck routes" won't seem like a valid explanation.
And what happens when Bob tires of the project, and Bill takes over one of his states? Do the truck routes stay, or do they go?
If a blanket include/ignore for these routes isn't possible, then perhaps we should look to another user option for truck routes specifically, or bannered state routes in general.
Quote from: mapcat on November 11, 2015, 06:30:46 PM
Quote from: froggie on November 10, 2015, 10:21:20 AM
+1 what Mapmikey just posted, especially the part where it should be up to whomever maintains the state. Generally speaking, whomever maintains a given state is likely to have more of a working knowledge of that state than others, and should know what to include and not to include.
So, essentially, you're saying that if collaborator Bob chooses to include truck routes in his states, and collaborator Bill chooses to ignore them in his states, that's fine? How do you explain that to a user who, familiar with one of Bob's states, submits a list of truck routes he's found in one of Bill's states, and asks that they be added? To the user, they will be the same; "No thanks, Bill doesn't deal with truck routes" won't seem like a valid explanation.
And what happens when Bob tires of the project, and Bill takes over one of his states? Do the truck routes stay, or do they go?
All that seems to assume that all truck routes are alike, or that different states have similar policies about truck routes. As has been noted, even within one state (NY), truck routes come in different flavors, with some more "official" (from NYSDOT's standpoint) than others.
As rickmastfan67 noted, there's also imperfect knowledge of what auxiliary routes are out there. We can try to get that nailed down before system activation, but we won't always succeed (especially in some jurisdictions where documentation of such routes is sloppy or hard to find), and will depend on user reports to flag routes we should add. For example, TCH business routes in British Columbia (spotted by Mapmikey) and Saskatchewan (which Alps and I found) were late additions to the Trans-Canada Highway route set.
More broadly, in a volunteer-driven collaborative project like TM you're bound to have some differences in approach, that will affect what gets mapped and how in different states, etc. We can make some efforts to agree on broad guidelines (or continue to use CHM's), for collaborators to apply to the different circumstances of their states or other jurisdictions. But it's unrealistic to expect or even strive for perfect consistency, unless you have one central authority setting and enforcing rules. We tried that once, and it turned out to be unsustainable.
Quote from: oscar on November 11, 2015, 07:33:29 PM
Quote from: mapcat on November 11, 2015, 06:30:46 PM
So, essentially, you're saying that if collaborator Bob chooses to include truck routes in his states, and collaborator Bill chooses to ignore them in his states, that's fine? How do you explain that to a user who, familiar with one of Bob's states, submits a list of truck routes he's found in one of Bill's states, and asks that they be added? To the user, they will be the same; "No thanks, Bill doesn't deal with truck routes" won't seem like a valid explanation.
And what happens when Bob tires of the project, and Bill takes over one of his states? Do the truck routes stay, or do they go?
All that seems to assume that all truck routes are alike, or that different states have similar policies about truck routes. As has been noted, even within one state (NY), truck routes come in different flavors, with some more "official" (from NYSDOT's standpoint) than others.
Indeed, different states have different ways of doing things, and one cannot always broadly apply specific policies in a fair manner. For example, in states that have secondary routes signed with a different shield, they generally are not included in the state system here. But then you have Vermont, where some routes are signed with a different shield to denote local maintenance. The consensus ended up being that they should be included in the primary system for reasons that are difficult to objectively state, but intuitively it makes sense most who are familiar with the routes.
So, with regards to whether a particular state system should include certain bannered routes, I would likewise say this should be determined by community consensus - not by any one individual.
Thinking about it some more, truck routes are striking me as similar to business interstates in some way. It would also be nice to maintain consistency between systems where it makes sense.
Quote from: oscar on September 18, 2015, 02:03:12 AM
In my now-completed review of the draft NM state routes, I just wanted to flag a few possible changes needed to US routes (US 84/285 reroute in Española, US 64 reroute and new business route in Farmington, US 82 Truck in Artesia), and an Interstate business route (I-40BL Grants), that may require changes to those route files, in addition to related changes to some state routes. Also, several routes that may need to be added or deleted in the NM state route set.
Over in the CHM forum, I've bumped a topic on a short rerouting of US 70 in Lordsburg. However, this one has zero effect on the NM state route set.
The rerouting of US 64 and the new business route in Farmington, the NM 547 point addition for I-40BL Grants, and the US 70 reroute in Lordsburg are all in the Travel Mapping HB. I'm satisfied, after reviewing the newest GMSV imagery, that we don't need to change anything in Española. I still need to take another look at the US 82 truck route in Artesia before implementing that change. Also, I-40BL Albuquerque appears to be decommissioned as a business (but not historic) route, which will require some point relabels on several intersecting state routes.
I'm starting on the state route file edits flagged in my long post on page 8 of this topic, which should get the state route set ready for activation. For some, I may need to check in with NMDOT, if I can't get clarity from GMSV.
Got a PM about this, and thought it worth reminding everyone. TM's points in use are not in the DB, but they are in a log file. I think both this file and the old CHM points in use should be consulted when deciding when a point can be renamed without breaking .list files.
http://tm.teresco.org/logs/pointsinuse.log (http://tm.teresco.org/logs/pointsinuse.log)
Once we get a large enough user base, we could probably not worry about the old CHM points in use anymore, but I think it's nice to keep looking there for now. We seem to be picking up a few old CHM users as TM users each week lately.
New log file produced during site updates: a list of .wpt files in our hwy_data hierarchy, other than the boundaries data we are not (yet) using, that did not get processed into the DB as a result of a matching entry in a .csv file for a system in the systems.csv file.
http://tm.teresco.org/logs/unprocessedwpts.log (http://tm.teresco.org/logs/unprocessedwpts.log)
Many are files in partially-developed systems that don't yet have valid .csv files. Some are files that will be added to a .wpt upon activation of a system (where a route already is active in another system). Others are likely old junk that should be cleaned up. Low priority to be sure, but something to take a look at occasionally anyway.
I've thought about this from time to time since the CHM days, how we've got this historical cruft building up.
On the one hand, it's neato for archaeological purposes, having these old WPTs around as a historical record.
OTOH, GitHub has the "Browse commits for this branch", "Browse the repository at this point in the history", etc. options. Which are more complete, more powerful, and probably more appropriate.
I took a look at the unprocessed .wpts log. Some of the entries in my jurisdictions are wpts for deleted routes (some of them deleted years ago in CHM days). Most of them I'll delete later, after I've cleared my NM queue, though some of the California wpts are destined to be folded into other routes (like ca.086s.wpt) and should be preserved for now.
Then, for some reason, the PEI files include TCH files for other provinces. Weird.
Quote from: oscar on November 25, 2015, 12:43:10 AMThen, for some reason, the PEI files include TCH files for other provinces. Weird.
Sounds like the same weirdness that produced this: https://github.com/TravelMapping/HighwayData/issues/169
I've put in a pull request to delete them.
Quote from: yakra on November 25, 2015, 12:31:22 AM
I've thought about this from time to time since the CHM days, how we've got this historical cruft building up.
On the one hand, it's neato for archaeological purposes, having these old WPTs around as a historical record.
OTOH, GitHub has the "Browse commits for this branch", "Browse the repository at this point in the history", etc. options. Which are more complete, more powerful, and probably more appropriate.
Right - we can browse a complete history of our data from the time it was first imported to GitHub. No sense keeping these old files around just for those purposes.
Thanks for the quick initial cleanup - we're down over 200 extraneous files already.
Quote from: Jim on November 25, 2015, 10:02:58 AMRight - we can browse a complete history of our data from the time it was first imported to GitHub. No sense keeping these old files around just for those purposes.
Speaking of which, do we want to bin the chm_final folder?
Quote from: english si on November 25, 2015, 11:02:11 AM
Quote from: Jim on November 25, 2015, 10:02:58 AMRight - we can browse a complete history of our data from the time it was first imported to GitHub. No sense keeping these old files around just for those purposes.
Speaking of which, do we want to bin the chm_final folder?
I'd like to keep it as an easy point of reference, at least for now, with so many CHM users not yet participating in TM.
The datacheck page http://tm.teresco.org/devel/datacheck.php (http://tm.teresco.org/devel/datacheck.php) now breaks datacheck errors into 4 categories: errors in active systems that should be addressed with high priority, errors in preview systems that must be addressed before a system can be activated, errors in devel systems that should be addressed when a system is be prepared for promotion to preview status, and the known false positives (for routes in systems in any development status).
We have a handful of datacheck errors in active systems that should be checked out.
It appears that someone jumped the gun on extending I-69 up to Henderson, KY. I was on the road from Henderson to Madisonville today and it's all still signed as the Pennyrile Pkwy, not I-69, on the route and on trailblazers. No Future I-69 signs either. Exits still use the Pennyrile exit numbers, although new signs are being erected with I-69's numbers, so those will match what's in the HB in the not-too-distant future.
Is there a new standard for elevating future interstates to interstates?
Since there's no separate thread for Oklahoma yet:
US283 and OK44 might need reconfiguring north of Blair. There is a not-so-new diagonal 4-lane route for US283, but the fact that (per GMSV) the old routing is still signed (albeit as TO 283 or TO 44) makes me wonder if there is still some uncertainty about the reroute. GMSV shows the rerouting of US283 as far back as 2008.
https://www.google.com/maps/@34.8128828,-99.334237,3a,75y,335.48h,85.33t/data=!3m6!1e1!3m4!1sjvUa5duM5AnSd7bqGyb_Dw!2e0!7i13312!8i6656
Quote from: mapcat on December 18, 2015, 06:04:57 PM
US283 and OK44 might need reconfiguring north of Blair. There is a not-so-new diagonal 4-lane route for US283, but the fact that (per GMSV) the old routing is still signed (albeit as TO 283 or TO 44) makes me wonder if there is still some uncertainty about the reroute. GMSV shows the rerouting of US283 as far back as 2008.
https://www.google.com/maps/@34.8128828,-99.334237,3a,75y,335.48h,85.33t/data=!3m6!1e1!3m4!1sjvUa5duM5AnSd7bqGyb_Dw!2e0!7i13312!8i6656
Oh, bloody hell.
If Okladot would at any time pull their head out of their bottom, that would be lovely.
The Greer County control section map (http://www.okladot.state.ok.us/Maps/control-section/2012/map_csect_2012-28-greer.pdf) (date unknown, but the URL has a couple "2012"s in it) clearly shows US283 on the east side of the triangle, and OK6 on the diagonal. (US283 on the north side is less clear, and must be inferred.) Meanwhile, the General County Road map (http://www.okladot.state.ok.us/Maps/county/map_co_28-greer.pdf) ("all data current to date of inventory September 2010" / "state system revised to September 2013" / whatever) shows US283 on both the north and east legs -- and OK6 on the east leg. ...Leaving the diagonal as, ostensibly... nothing?
I'm laughing but I'm crying...But regardless, a thru traveler trying to clinch the route is probably going to follow the signs, and finding that our route file doesn't match up would be a nasty surprise. All signage I see on GMSV on the thru route clearly directs travelers to the diagonal. The lone straggler faces travelers coming to the end of OK44 south: GMSV of apparently similar vintage to Mapcat's link (no, I'm not going to leave Lite Mode just to look at the date) shows a junction with US283 south and north -- and an END OK44 sign. The other signage at nearby junctions is pretty unambiguously
TO OK44. So, OK44 should probably end where it already does. At a place signed in the field (?) as US283. But wouldn't be any actual route in our DB if US283 gets moved.
Oohh-
kladot!!@#I'd love it if my head would stop exploding for just a tiny little bit.
If only I could stop repeatedly bashing it into my desk...
-----
While checking out the routes involved here, I noticed that OK6 has been rerouted around the E1340 points, between OK9 & OK55. At least that much is straightforward. ...I hope. :P
I'm having a bit of an issue with one specific route: VA 168. It's "active" as va168fwy, and "preview" as va168. However, in my log I get the following when I try to add them:
QuoteWaypoint label(s) not found in line: VA VA168 NC/VA US60
Unknown region/highway combo in line: VA VA168Fwy NC/VA 15A
Is there some issue with this one route? I can't imagine what I could be doing wrong. Also, it does count the part of VA 168Fwy concurrent with US 17 as clinched for me, if that helps.
Quote from: deathtopumpkins on December 23, 2015, 06:08:21 PM
I'm having a bit of an issue with one specific route: VA 168. It's "active" as va168fwy, and "preview" as va168. However, in my log I get the following when I try to add them:
QuoteWaypoint label(s) not found in line: VA VA168 NC/VA US60
Unknown region/highway combo in line: VA VA168Fwy NC/VA 15A
Is there some issue with this one route? I can't imagine what I could be doing wrong. Also, it does count the part of VA 168Fwy concurrent with US 17 as clinched for me, if that helps.
Same issue with several other routes such as VA 7, VA 28, and VA 262.
Quote from: oscar on December 23, 2015, 06:25:32 PM
Quote from: deathtopumpkins on December 23, 2015, 06:08:21 PM
I'm having a bit of an issue with one specific route: VA 168. It's "active" as va168fwy, and "preview" as va168. However, in my log I get the following when I try to add them:
QuoteWaypoint label(s) not found in line: VA VA168 NC/VA US60
Unknown region/highway combo in line: VA VA168Fwy NC/VA 15A
Is there some issue with this one route? I can't imagine what I could be doing wrong. Also, it does count the part of VA 168Fwy concurrent with US 17 as clinched for me, if that helps.
Same issue with several other routes such as VA 7, VA 28, and VA 262.
Someone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem. This is a problem every time we start developing a new system that has routes already in another system, but only plotted in part in the existing system. If that makes any sense. Anyway, the thing to do is to hold off any changes until the VA routes in the active system are extended to their full length.
Quote from: JimSomeone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem.
I'm presuming this is a temporary fix until the full usava system is brought online?
Quote from: froggie on December 23, 2015, 08:23:48 PM
Quote from: JimSomeone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem.
I'm presuming this is a temporary fix until the full usava system is brought online?
Yes. Eric did this with some Texas routes when those full systems first got into our DB. The usansf routes will go away when usatx and usava activate.
In usansf.csv, there is no
Fwy abbrev for VA168. Thus, the highway name used in a .list file is VA VA168 (hence the 2nd error in deathtopumpkins.log) -- same as the route in the preview usava set. This causes a collision... :\
For the "VA VA168 NC/VA US60" line in deathtopumpkins.list, the "VA VA168" maps to the active route in the usansf set (whether this is due to this route being active and not preview, or the order in which the .csvs are listed and processed, slurped into & read from the DB, etc., I cannot say...). The usansf flavor is the partial route sans the US60 waypoint, hence the 1st error in deathtopumpkins.log.
Maybe add some code to the SiteUpdate script to produce a warning when this happens?
Quote from: Jim on December 23, 2015, 08:26:45 PM
Quote from: froggie on December 23, 2015, 08:23:48 PM
Quote from: JimSomeone (can't remember who) is planning to bring in the extended versions (currently in usava) to the usansf systems to avoid this problem.
I'm presuming this is a temporary fix until the full usava system is brought online?
Yes. Eric did this with some Texas routes when those full systems first got into our DB. The usansf routes will go away when usatx and usava activate.
Yes, it looks like a Texas-style solution is appropriate here.
As far as planning to actually do this goes, I suggested it but fell just short of actually volunteering myself for the task, not wanting to put too much on my plate and spread myself too thin.
(And then I went and took on NY & MA maintenance, 'cuz, you know... I'm nothing if not intellectually consistent...)
Is it any more difficult than (a) copying the "full" versions of the VA 7, VA 28, VA 168, and VA 262 files from your local usava directory to VA's usansf directory, (b) deleting the old va.va007fwy.wpt, etc. files from the local usansf directory, (c) renaming the new "full" files in that directory to the names of the corresponding deleted files, and (d) doing a pull request to get it all added to the GitHub master? No changes needed to .csv files, and no duplicate route files in different places on the master.
If so, that's something I could do tomorrow, since my family does its Christmas festivities tonight.
You'd still need to delete each line in usava.csv & usava_con.csv -- well, not need to, strictly speaking I guess, to avoid route name collisions, but I would still consider it best practice WRT the integrity of the data.
So yes, your approach works.
That said, I just don't like the idea of having the "(Freeway)" in the CSV City/description field, or the "fwy" appended to a Root/filename of a full-length route.
The latter item especially can be confusing for travelers: consider the inclusion of "VA VA168Fwy NC/VA 15A" in deathtopumpkins.list.
I suggest:
Things to do for each:
- Add/copy new file to usansf/
- delete old (va.va007fwy.wpt, etc.) file from usansf
- fix line in usansf.csv
- fix line in usansf_con.csv
- delete line in usava.csv
- delete line in usava_con.csv
While at it, a quick peer review of the extensions of each affected route wouldn't hurt.
Oh what the hell. With only four files (VA7, VA28, VA168, VA262) affected, this isn't as hard to do as my initial hesitation would suggest. I'll have a go at it in the next few hours.
All I did was put my VA route information in a separate text file until the system is activated. That has been how I have avoided issues for now. Obviously I will copy and paste my temporary text file data into my normal .list file when VA is fully activated.
EDIT: Ok I was being skeptical but I will go ahead and put my VA data in my .list file and post here (or in the VA thread) if I notice any issues.
Of course, putting new info into your normal .list file does help us find issues to fix. :)
Quote from: yakra on December 24, 2015, 05:17:37 PM
Of course, putting new info into your normal .list file does help us find issues to fix. :)
So are you saying that putting unactivated data (in this case VA state routes) would still be able to determine errors in my .list file and not affect the other entries?
Quote from: 74/171FAN on December 24, 2015, 08:33:13 PM
Quote from: yakra on December 24, 2015, 05:17:37 PM
Of course, putting new info into your normal .list file does help us find issues to fix. :)
So are you saying that putting unactivated data (in this case VA state routes) would still be able to determine errors in my .list file and not affect the other entries?
You should be able to put anything you want in your .list file. You might trigger warnings, but it would not stop your good lines from being processed properly. And if that ends up not being the case, let me know, because it should be.
Not sure if this is the best place to put this, but here goes.
I have a couple comments on some waypoints for a few Ohio state routes. Possible corrections (hard to say).
OH117 waypoint 46 is labeled OH366/368. It should just be OH366. OH368 ends at the intersection with OH366 a few miles west.
OH366 waypoint 17 is labeled OH117/368. It should be OH117 (see note above on OH117)
Several routes OH273, OH365, OH368, and OH708 all have non-concurrent terminal waypoints called IndLakeSP. It doesn't appear to cause any issues for the system, I just wondered what is the proper protocol for naming labels. In cases like this where routes just end (either at a body of water or where a county road takes over) isn't 'End' an appropriate waypoint label? I'm always in favor of the shorter option (it means I'm less likely to make a typo ;-))
Again, I'm just curious. Having recently driven these routes, it got me thinking about how waypoints are labeled.
Quote from: Jim on December 24, 2015, 09:06:06 PM
You should be able to put anything you want in your .list file. You might trigger warnings, but it would not stop your good lines from being processed properly. And if that ends up not being the case, let me know, because it should be.
If you want something in there that's not intended to be a good line and you don't want to have it trigger warnings or errors in your log file, just start the line with a '#' character and the whole line will be ignored (treated as a comment).
Some of my loose ends in New Mexico are a pair of truck routes (US 380 in Roswell, US 82 in Artesia) that maybe should be added to our data, though I have some doubts about both. Comments are welcome, especially from CHM veterans familiar with some of the arguments we've had then with truck routes.
One thing common to both: there is no record of AASHTO approval for either truck route. NMDOT seems not to bother. It hasn't applied for any AASHTO approval since 2002. Since then, it has rerouted US 64 around Farmington, and established a new US 64 Business on the old alignment.
Also, I couldn't find any official NMDOT route log, or compilation of AADT data, for bannered US routes in the state, or for business Interstates. There are official route lists for state routes, and AADT logs for them and regular Interstates and US routes. But no online resources to confirm the official status from NMDOT's standpoint of Truck US 380 or Truck US 82.
Roswell
There is some of the usual kind of truck route signage (standard reassurance marked, topped with a "truck" or "truck route" banner) we often look for, some of which indicates a US 380 truck route. Here's an example of such signage, on Truck US 70/US 285 in Roswell, the only US truck route we have in our New Mexico data:
https://www.google.com/maps/@33.3939959,-104.5849683,3a,75y,0.52h,70.37t/data=!3m6!1e1!3m4!1sC3Qm-TFe-CM9UQt3_Wlw3g!2e0!7i13312!8i6656
Elsewhere at that intersection are two sign assemblies, indicating a US 380 truck route following Truck US 285 from US 380 southeast to US 285:
Truck US 70 SB at US 70/380
https://www.google.com/maps/@33.3946049,-104.5850536,3a,16.6y,172.18h,89.38t/data=!3m6!1e1!3m4!1sHypavCFkhJhXh27vHA9WEQ!2e0!7i13312!8i6656!6m1!1e1
US 70/380 EB at Truck US 70/285:
https://www.google.com/maps/@33.3941066,-104.5873065,3a,25.1y,96.4h,83.94t/data=!3m6!1e1!3m4!1sXUmb642ult2veKzbunf9GA!2e0!7i13312!8i6656
There are several reasons why I'm reluctant to add a Truck US 380 to the HB:
-- The supposed Truck US 380 is completely concurrent with the southern half of Truck US 285, so adding it to the HB adds no mileage to the system.
-- There is not only no other Truck US 380 signage on Truck US 285, but at the south end there is no signage pointing trucks back toward regular US 380. And the truck route ends at US 285, with no road continuing east to connect back to US 380, nor does NMDOT appear to have any plans to build one.
-- I saw no signage on regular US 380 westbound pointing truck drivers south on US 285 toward Truck US 285/380. Nor is there any signage on US 285 south of Roswell, indicating that the truck bypass is anything other than Truck US 285.
-- There are no truck restrictions on US 380 through downtown Roswell, and indeed my GMSV review showed heavy trucks on US 380 through downtown.
-- The truck detour is rather pointless for US 380 truck traffic, since it takes them far out of their way without completely avoiding downtown Roswell.
Artesia
Artesia has none of the traditional truck route signage that I found in Roswell, along the supposed US 82 truck route as shown in OSM/Mapnik (following 26th St. west of downtown, Richey Ave. north of downtown, and NM 229 returning to US 82 east of downtown).
One additional wrinkle is that the truck route west of US 285 appears not to be state-maintained. 26th Street, AFAIK, was never state-maintained. Richey Ave. west of US 285 used to be part of NM 357, but NMDOT agreed in 2011 to turn that segment to local control. I don't know whether that matters to NMDOT re: designating a bannered US route on a roadway it doesn't maintain, though it appears that the decommissioning of I-40BL Albuquerque followed the transfer of its roadway (Central Ave.) to city maintenance. Then again, I don't know whether NMDOT recognizes the truck route or it's just a local designation, though many of the truck route signs are posted in state right-of-way.
Signage on the supposed US 82 truck route itself
West end of route, on 26th St. at jct US 82:
https://www.google.com/maps/@32.8432734,-104.4298397,3a,20.1y,182.46h,87.66t/data=!3m6!1e1!3m4!1s_TalQfYG-hQLm5YV0ZwWYQ!2e0!7i13312!8i6656
26th St. NB at jct Richey Ave.:
https://www.google.com/maps/@32.8563114,-104.4298761,3a,23.9y,13.89h,89.18t/data=!3m6!1e1!3m4!1sYJhvdo6G2z2maVN-P2s5YA!2e0!7i13312!8i6656
Richey Ave WB at jct 26thSt:
https://www.google.com/maps/@32.8571503,-104.4293036,3a,24.9y,276.76h,83.24t/data=!3m6!1e1!3m4!1sxanTd-Iu-skA2bQkufYkuQ!2e0!7i13312!8i6656
Richey Ave. WB at jct US 285:
https://www.google.com/maps/@32.8571615,-104.3982439,3a,25y,277.11h,83.34t/data=!3m6!1e1!3m4!1szXrzU4ub0DqhRwKK7gpwzg!2e0!7i13312!8i6656
Jct NM 229, from EB NM 357 (Richey Ave. E of US 285):
https://www.google.com/maps/@32.8571894,-104.361984,3a,25.8y,91.97h,79.1t/data=!3m6!1e1!3m4!1sFJFaUpjpVOKG8hijPm1_rQ!2e0!7i13312!8i6656
Jct NM 357, from NB NM 229:
https://www.google.com/maps/@32.8566486,-104.3609853,3a,15y,4.58h,84.89t/data=!3m6!1e1!3m4!1sd3IUfhjyRxX5SISobTOEZw!2e0!7i13312!8i6656
Signage from US 82 and US 285
The truck route appears to be completely unsigned from US 82 EB. WB signage is not much better:
https://www.google.com/maps/@32.8426799,-104.3590606,3a,75y,272.03h,72.6t/data=!3m6!1e1!3m4!1sAgwsBmr-x4a_RTRkNoujtA!2e0!7i13312!8i6656
The only truck route signage I saw anywhere on US 285 is SB at jct Richey Ave.:
.
https://www.google.com/maps/@32.8582625,-104.398986,3a,26.2y,178.36h,80.47t/data=!3m6!1e1!3m4!1sASnK_IOi4KSHOgDWNSWvOw!2e0!7i13312!8i6656
Quote from: Jim on October 09, 2015, 08:52:35 AM
Quote from: english si on October 09, 2015, 07:49:19 AMOh, and MPOpen or Mapnik in our Highway Browser, because Google's data is different and what looks like badly placed points are actually correctly placed wrt the open source data we use to make files.
I added an Issue about this in GitHub to remind me to add that in next time I have a chance to open up the web code. If anyone else wants to add it and submit a pull request that would certainly make it happen more quickly.
It's implemented meanwhile and it's working fine :). Is it a big deal to add
Bing Maps and
Bing Satellite? It would be a great help (for Europe) because it's sometimes more up-to-date than Google. It helps to decide if GM and OSM are different. Currently, I have to use http://wikimapia.org/.
In addition, is it possible to rename the "
Mapnik" call to the more common name "
OSM"?
Quote from: michih on December 28, 2015, 08:11:05 AM
It's implemented meanwhile and it's working fine :). Is it a big deal to add Bing Maps and Bing Satellite? It would be a great help (for Europe) because it's sometimes more up-to-date than Google. It helps to decide if GM and OSM are different. Currently, I have to use http://wikimapia.org/.
Seconded. Both flavors of Bing would be very useful. I had a look at the code round the time OSM was added, but it was much less obvious how to do it than I anticipated, so I just left it alone.
Quote from: michih on December 28, 2015, 08:11:05 AM
In addition, is it possible to rename the "Mapnik" call to the more common name "OSM"?
I downvote this though. I think Mapnik is appropriate as the specific flavor
of OSM data, OpenMQ being another OSM-based flavor.
Quote from: yakra on December 24, 2015, 03:06:06 PM
I suggest:
Things to do for each:
- Add/copy new file to usansf/
- delete old (va.va007fwy.wpt, etc.) file from usansf
- fix line in usansf.csv
- fix line in usansf_con.csv
- delete line in usava.csv
- delete line in usava_con.csv
While at it, a quick peer review of the extensions of each affected route wouldn't hurt.
I've made a branch of the HighwayData repository (https://github.com/TravelMapping/HighwayData/compare/master...yakra:va-usansf) containing these changes.
I'm holding off on making an actual pull request pending some peer review of the extended routes.
Directing further discussion to the Virginia State Highways (in development) thread (https://www.aaroads.com/forum/index.php?topic=16784.msg2116315#msg2116315).
I've made some proposed changes per mapcat's post (https://www.aaroads.com/forum/index.php?topic=15733.msg2113897#msg2113897).
https://github.com/yakra/HighwayData/compare/OK-cleanup
US283:
OK6_A label demoted in favor of OldUS283
OK44 point deleted, resulting in US283 following the diagonal between OldUS283 and...
OK6_B label demoted in favor of OK6_N
OK6_C label demoted in favor of OK6
OK6:
US283_A label demoted in favor of US62/283
US283_B label demoted in favor of OldUS283
US283_C -> US283_N
US283_D label demoted in favor of US283
Removed from N 2020 Rd and E 1340 Rd and relocated onto a divided four-lane diagonal between N 2020 Rd and the closed intersection with Old OK 6.
N2020 added
E1340_W & E1340_E deleted
*OldOK6 added
OK44:
US283 label demoted in favor of OldUS283.
Sure, there's a stable, modern road name there in E1490, but I think given the context that OldUS293 might be less confusing.
It doesn't all feel quite right to me, but I don't think in these circumstances it CAN be quite right.
Thoughts? If no objections, I'll put in a pull request.
Yakra: looks good!
Is there any reason to keep US521ConSum (http://tm.teresco.org/devel/hb.php?r=sc.us521consum) in South Carolina, now that US521's mainline is (poorly) signed along that route?
Quote from: mapcat on January 01, 2016, 09:56:34 AM
Yakra: looks good!
Is there any reason to keep US521ConSum (http://tm.teresco.org/devel/hb.php?r=sc.us521consum) in South Carolina, now that US521's mainline is (poorly) signed along that route?
I knew there was something I forgot to do when I rerouted US-521. Yes, it should be deleted. I'll go submit a pull request in a few minutes to do that.
There seems to be some inconsistency in naming routes around Opp, AL.
In the US84 file, the point it labeled BUS84Opp_W.
US84BusOpp mentions BUS331_N and BUS331_S.
The US331 file uses BUS331Opp.
However, the route in the browser is labeled US331AltOpp, and it has points labeled US84Alt_W and US84Alt_E.
I suspect both the route (file) name for "Alt331" and in it, the labels of US84Alt should be changed to Bus.
Quote from: ntallyn on January 01, 2016, 09:34:33 PM
There seems to be some inconsistency in naming routes around Opp, AL.
In the US84 file, the point it labeled BUS84Opp_W.
US84BusOpp mentions BUS331_N and BUS331_S.
The US331 file uses BUS331Opp.
However, the route in the browser is labeled US331AltOpp, and it has points labeled US84Alt_W and US84Alt_E.
I suspect both the route (file) name for "Alt331" and in it, the labels of US84Alt should be changed to Bus.
I've added a GitHub issue for this, thanks.
US62/68 rerouting in OH/KY.
Old topic from CHM. http://clinched.s2.bizhat.com/clinched-ftopic1764.html&highlight=us62 (http://clinched.s2.bizhat.com/clinched-ftopic1764.html&highlight=us62). The new site is still showing the old routing.
Here's the best I can do finding signage https://www.google.com/maps/@38.6537576,-83.7574047,3a,49.4y,27.44h,90.97t/data=!3m6!1e1!3m4!1sk_LZKfgSDHpVSM4U6M_Feg!2e0!7i13312!8i6656 (https://www.google.com/maps/@38.6537576,-83.7574047,3a,49.4y,27.44h,90.97t/data=!3m6!1e1!3m4!1sk_LZKfgSDHpVSM4U6M_Feg!2e0!7i13312!8i6656). Here is a link that has a few photos http://www.alpsroads.net/roads/oh/bus_62/ (http://www.alpsroads.net/roads/oh/bus_62/).
Having just driving the route, I looked through the HB as I didn't recall seeing any Business routes in Ohio for US62.
Anyway, I suspect someone may wish to explore the issue further for both KY and OH.
In Kentucky, KY16 has been rerouted in Taylor Mill along Pride Pkwy. The bypassed segment of KY16 is now KY3716.
In Missouri, MO364 begins at I-64 now.
Also in Missouri, the western end of I-44BLPac is at Exit 253, not Exit 257.
In North Carolina, US421 bypasses Sanford and the former route is signed as Business 421.
Has anyone mentioned the PA 441 (https://www.aaroads.com/forum/index.php?topic=2410.msg2113572#msg2113572) relocation in Columbia here yet? Basically it follows Front St instead of Locust St and 3rd St through downtown and connects to 3rd St at the north end of the US 30 interchange. From a short field visit on Christmas Eve, it seems that PA 441 is exclusively being posted that way now (coming towards Columbia I saw 3rd St being posted as "TO PA 462", I did not check the borough itself.
In result, PA 441 does not intersect PA 462 anymore so that point will need to be moved (maybe where it used to turn onto Locust St) and the US 30 point should be moved to the north end of the interchange.
Quote from: mapcat on January 05, 2016, 12:33:26 AM
In Kentucky, KY16 has been rerouted in Taylor Mill along Pride Pkwy. The bypassed segment of KY16 is now KY3716.
In Missouri, MO364 begins at I-64 now.
Also in Missouri, the western end of I-44BLPac is at Exit 253, not Exit 257.
In North Carolina, US421 bypasses Sanford and the former route is signed as Business 421.
Quote from: 74/171FAN on January 05, 2016, 06:24:52 AM
Has anyone mentioned the PA 441 (https://www.aaroads.com/forum/index.php?topic=2410.msg2113572#msg2113572) relocation in Columbia here yet? Basically it follows Front St instead of Locust St and 3rd St through downtown and connects to 3rd St at the north end of the US 30 interchange. From a short field visit on Christmas Eve, it seems that PA 441 is exclusively being posted that way now (coming towards Columbia I saw 3rd St being posted as "TO PA 462", I did not check the borough itself.
In result, PA 441 does not intersect PA 462 anymore ... and the US 30 point should be moved to the north end of the interchange.
I've added GitHub issues for these.
Two comments from entering data from a last-minute road trip today:
DE 273: All indications seem to be that it officially ends at the intersection with DE 9 and DE 141, but it seems that it might be posted along DE 9 to 6th St in New Castle (which was the case at one point, the final point heading east for DE 273 is at 6th St and not at the DE 9/DE 141 intersection).
US 13 (PA): This is missing a point at PA 320 (just east of PA 352 which is the better road), PA 320 does have a point at US 13 (and is fully posted in Chester despite its oddities).
Quote from: bejacob on December 26, 2015, 06:42:47 PM
Not sure if this is the best place to put this, but here goes.
I have a couple comments on some waypoints for a few Ohio state routes. Possible corrections (hard to say).
OH117 waypoint 46 is labeled OH366/368. It should just be OH366. OH368 ends at the intersection with OH366 a few miles west.
OH366 waypoint 17 is labeled OH117/368. It should be OH117 (see note above on OH117)
I've changed both in my local files.
QuoteSeveral routes OH273, OH365, OH368, and OH708 all have non-concurrent terminal waypoints called IndLakeSP. It doesn't appear to cause any issues for the system, I just wondered what is the proper protocol for naming labels. In cases like this where routes just end (either at a body of water or where a county road takes over) isn't 'End' an appropriate waypoint label? I'm always in favor of the shorter option (it means I'm less likely to make a typo ;-))
Again, I'm just curious. Having recently driven these routes, it got me thinking about how waypoints are labeled.
The old CHM manual (perhaps due for an update?) puts meaningful names such as park names, city limits, etc ahead of simply "End". However, since the ends of these highways seem not to coincide with current state park boundaries, it seems that the names of the roads continuing from these end points would be more appropriate candidates. I'll hold off on renaming these until others have weighed in.
Quote from: mapcat on January 09, 2016, 06:52:55 PM
Quote from: bejacob on December 26, 2015, 06:42:47 PM
My qSeveral routes OH273, OH365, OH368, and OH708 all have non-concurrent terminal waypoints called IndLakeSP. It doesn't appear to cause any issues for the system, I just wondered what is the proper protocol for naming labels. In cases like this where routes just end (either at a body of water or where a county road takes over) isn't 'End' an appropriate waypoint label? I'm always in favor of the shorter option (it means I'm less likely to make a typo ;-))
Again, I'm just curious. Having recently driven these routes, it got me thinking about how waypoints are labeled.
The old CHM manual (perhaps due for an update?) puts meaningful names such as park names, city limits, etc ahead of simply "End". However, since the ends of these highways seem not to coincide with current state park boundaries, it seems that the names of the roads continuing from these end points would be more appropriate candidates. I'll hold off on renaming these until others have weighed in.
My quick take from the road:
There's a preference for using an intersecting road to name the waypoint, as with two of these routes. If the route ends at a non-intersection point, but the road name or route number changes where the numbered route ends (as appears to be true for another route), using the continuation road name is appropriate, and is something Mapmikey has been doing for Virginia state routes (in part to fend off my suggestion to switch some route endpoints to county line-based waypoint names). IndLakeSP is a legitimate option where all else fails. I've used "End" in similar circumstances, though I prefer to reserve "End" for when I'm desperate, when a route ends at no logical place for no obvious reason. "IndLakeSP" is certainly more meaningful than "End".
As you might gather, there are style differences among team members (such as that I'm madly in love with using parks to place and name waypoints). But none of these options likely will confuse or otherwise aggravate users.
The multiple non-concurrent IndLakeSP points won't confuse the system, so long as there is only one in each route file.
Good feedback from both oscar and mapcat. Both answers satisfy my curiosity. Field research often lead to questions (like when I saw US62Bus and US62Bus signs along the Ohio River and didn't recall seeing any such route in the highway browser).
It's one thing when a waypoint is clearly mislabeled. It's another when the label is long (i.e. IndLakeSP), but correct. Certainly no need to rename without good reason.
Thanks for the replies.
In my travels between DC and Vermont this weekend, found two apparently-new truck PA routes that will require further investigation:
TRUCK PA 625 is south of Reading and utilizes US 222 and the PA 568 exit. I don't recall where it hopped on/off 222 north of there.
TRUCK PA 512 is southwest of Wind Gap and utilizes a short bit of PA 946, Cherry Hill Rd coming off PA 946, and Bushkill Center Rd to connect back to PA 512. I do not know how it gets between Cherry Hill Rd and Bushkill Center Rd.
GMSV will not be helpful in either case as it's not new enough.
Oy gevalt! :D
Quote from: froggie on January 11, 2016, 09:05:39 AM
In my travels between DC and Vermont this weekend, found two apparently-new truck PA routes that will require further investigation:
TRUCK PA 625 is south of Reading and utilizes US 222 and the PA 568 exit. I don't recall where it hopped on/off 222 north of there.
TRUCK PA 512 is southwest of Wind Gap and utilizes a short bit of PA 946, Cherry Hill Rd coming off PA 946, and Bushkill Center Rd to connect back to PA 512. I do not know how it gets between Cherry Hill Rd and Bushkill Center Rd.
GMSV will not be helpful in either case as it's not new enough.
There are a lot of these "ALT TRUCK ROUTES" (at least in District 6-most specifically Chester and Montgomery Counties) that I would have absolutely no idea what their routings were if it were not for whoever updates the PA/US Routes on Wikipedia. There is even a "US 30 BUS ALT TRUCK" route in Downingtown that partially uses the US 30 Bypass.
Quote from: bejacob on January 03, 2016, 10:07:17 AM
US62/68 rerouting in OH/KY.
Old topic from CHM. http://clinched.s2.bizhat.com/clinched-ftopic1764.html&highlight=us62 (http://clinched.s2.bizhat.com/clinched-ftopic1764.html&highlight=us62). The new site is still showing the old routing.
Here's the best I can do finding signage https://www.google.com/maps/@38.6537576,-83.7574047,3a,49.4y,27.44h,90.97t/data=!3m6!1e1!3m4!1sk_LZKfgSDHpVSM4U6M_Feg!2e0!7i13312!8i6656 (https://www.google.com/maps/@38.6537576,-83.7574047,3a,49.4y,27.44h,90.97t/data=!3m6!1e1!3m4!1sk_LZKfgSDHpVSM4U6M_Feg!2e0!7i13312!8i6656). Here is a link that has a few photos http://www.alpsroads.net/roads/oh/bus_62/ (http://www.alpsroads.net/roads/oh/bus_62/).
Having just driving the route, I looked through the HB as I didn't recall seeing any Business routes in Ohio for US62.
Anyway, I suspect someone may wish to explore the issue further for both KY and OH.
I got down there today before the snow and it seems that the Business signs are a mistake.
Traveling east on US 52 (and west on US 62 and south on US 68), at the newer bridge the signs point 68 onto the bridge and 52 and "Business 62" on ahead towards Aberdeen. There is no mention of any other 62, either going forward or across the bridge. "Business 62" continues on along 52 to the older bridge and turns and crosses the river to Maysville, KY. All signage in KY calls the road "US 62" (no business banners can be seen on 62 signs anywhere). I followed it all the way to the US62/US68Bus intersection and saw only bannerless 62 signs. No mention of a Business route appeared on KY 8 or the AA Hwy either.
So I believe that the best course of action is to leave things as they are.
Quote from: mapcat on January 22, 2016, 06:01:08 PM
Quote from: bejacob on January 03, 2016, 10:07:17 AM
US62/68 rerouting in OH/KY.
Old topic from CHM. http://clinched.s2.bizhat.com/clinched-ftopic1764.html&highlight=us62 (http://clinched.s2.bizhat.com/clinched-ftopic1764.html&highlight=us62). The new site is still showing the old routing.
Here's the best I can do finding signage https://www.google.com/maps/@38.6537576,-83.7574047,3a,49.4y,27.44h,90.97t/data=!3m6!1e1!3m4!1sk_LZKfgSDHpVSM4U6M_Feg!2e0!7i13312!8i6656 (https://www.google.com/maps/@38.6537576,-83.7574047,3a,49.4y,27.44h,90.97t/data=!3m6!1e1!3m4!1sk_LZKfgSDHpVSM4U6M_Feg!2e0!7i13312!8i6656). Here is a link that has a few photos http://www.alpsroads.net/roads/oh/bus_62/ (http://www.alpsroads.net/roads/oh/bus_62/).
Having just driving the route, I looked through the HB as I didn't recall seeing any Business routes in Ohio for US62.
Anyway, I suspect someone may wish to explore the issue further for both KY and OH.
I got down there today before the snow and it seems that the Business signs are a mistake.
Traveling east on US 52 (and west on US 62 and south on US 68), at the newer bridge the signs point 68 onto the bridge and 52 and "Business 62" on ahead towards Aberdeen. There is no mention of any other 62, either going forward or across the bridge. "Business 62" continues on along 52 to the older bridge and turns and crosses the river to Maysville, KY. All signage in KY calls the road "US 62" (no business banners can be seen on 62 signs anywhere). I followed it all the way to the US62/US68Bus intersection and saw only bannerless 62 signs. No mention of a Business route appeared on KY 8 or the AA Hwy either.
So I believe that the best course of action is to leave things as they are.
Makes sense. I just shared what I saw because it made me wonder. When I passed through last month, the signs confused me as I didn't recall any business routes in the database. Thanks for checking it out. Routes that stay the same is good as it means no changes our list files. :)
Quote from: 74/171FAN on January 06, 2016, 10:27:04 PM
DE 273: All indications seem to be that it officially ends at the intersection with DE 9 and DE 141, but it seems that it might be posted along DE 9 to 6th St in New Castle (which was the case at one point, the final point heading east for DE 273 is at 6th St and not at the DE 9/DE 141 intersection).
Is the signage you saw newer than GMSV? I saw enough signage in GMSV to convince me to leave as is.
What are your "All indications" / sources of info / etc.?
Quote from: 74/171FAN on January 06, 2016, 10:27:04 PM
US 13 (PA): This is missing a point at PA 320 (just east of PA 352 which is the better road), PA 320 does have a point at US 13 (and is fully posted in Chester despite its oddities).
I've submitted a pull request for this.
Quote from: yakra on January 28, 2016, 10:41:02 AM
Quote from: 74/171FAN on January 06, 2016, 10:27:04 PM
DE 273: All indications seem to be that it officially ends at the intersection with DE 9 and DE 141, but it seems that it might be posted along DE 9 to 6th St in New Castle (which was the case at one point, the final point heading east for DE 273 is at 6th St and not at the DE 9/DE 141 intersection).
Is the signage you saw newer than GMSV? I saw enough signage in GMSV to convince me to leave as is.
What are your "All indications" / sources of info / etc.?
I thought I saw a begin sign posted on DE 273 WB just past DE 141 (and the wikipedia article has its eastern end there). Yes I agree with you on what I saw from street view so I am fine with you leaving it alone for now (the only reason I was even on a road trip that day was due to a power outage at work so I have no chance of field verifying it any time soon).
Quote from: 74/171FAN on January 05, 2016, 06:24:52 AM
Has anyone mentioned the PA 441 (https://www.aaroads.com/forum/index.php?topic=2410.msg2113572#msg2113572) relocation in Columbia here yet? Basically it follows Front St instead of Locust St and 3rd St through downtown and connects to 3rd St at the north end of the US 30 interchange. From a short field visit on Christmas Eve, it seems that PA 441 is exclusively being posted that way now (coming towards Columbia I saw 3rd St being posted as "TO PA 462", I did not check the borough itself.
In result, PA 441 does not intersect PA 462 anymore so that point will need to be moved (maybe where it used to turn onto Locust St) and the US 30 point should be moved to the north end of the interchange.
I did get a chance to field verify this yesterday. I saw that PA 441 is exclusively posted on the bypass and that the only reference to PA 441 from PA 462 is via "TO" signs. I should also mention that there is a ramp from the new PA 441 NB that connects to the existing US 30 EB on-ramp. (it connects to the existing ramp from Cedar St, I obviously have no idea how that could currently be put into OSM until imagery shows it or whatever)
Quote from: 74/171FAN on January 28, 2016, 10:47:27 PM
Quote from: 74/171FAN on January 05, 2016, 06:24:52 AM
Has anyone mentioned the PA 441 (https://www.aaroads.com/forum/index.php?topic=2410.msg2113572#msg2113572) relocation in Columbia here yet? Basically it follows Front St instead of Locust St and 3rd St through downtown and connects to 3rd St at the north end of the US 30 interchange. From a short field visit on Christmas Eve, it seems that PA 441 is exclusively being posted that way now (coming towards Columbia I saw 3rd St being posted as "TO PA 462", I did not check the borough itself.
In result, PA 441 does not intersect PA 462 anymore so that point will need to be moved (maybe where it used to turn onto Locust St) and the US 30 point should be moved to the north end of the interchange.
I did get a chance to field verify this yesterday. I saw that PA 441 is exclusively posted on the bypass and that the only reference to PA 441 from PA 462 is via "TO" signs. I should also mention that there is a ramp from the new PA 441 NB that connects to the existing US 30 EB on-ramp. (it connects to the existing ramp from Cedar St, I obviously have no idea how that could currently be put into OSM until imagery shows it or whatever)
I was the one to originally add it into OSM. I used 2015 NAIP imagery of PA that showed construction far enough along to show that ramp alignment with the rest of the construction for this reroute.
Quote from: 74/171FAN on January 28, 2016, 10:47:27 PM
I thought I saw a begin sign posted on DE 273 WB just past DE 141 (and the wikipedia article has its eastern end there). Yes I agree with you on what I saw from street view so I am fine with you leaving it alone for now (the only reason I was even on a road trip that day was due to a power outage at work so I have no chance of field verifying it any time soon).
I had another look around and found the BEGIN (https://www.google.com/maps/@39.664224,-75.5797291,3a,15y,278.59h,89.2t/data=!3m6!1e1!3m4!1sVA6uZx9gevU3DtQSjDw9DQ!2e0!7i13312!8i6656) sign. Annoyingly, it doesn't line up with the END (https://www.google.com/maps/@39.6642649,-75.5647014,3a,15y,98.24h,86.94t/data=!3m6!1e1!3m4!1sjEo1jFEYWjRIIt24LeYpVw!2e0!7i13312!8i6656) sign. Oh, bother. I wanna walk away from this one whistling casually, and just leave the status quo. Although, the 6thSt_W label is incorrect, and should be relabeled 6thSt.