usaco (Colorado State Highways)

[si404]

This system is almost ready for activation. Is there anything else that needs doing before then?


Datacheck errors that need looking at:

co.co064 CR89,CR5 VISIBLE_DISTANCE 11.96 co.co064;CR89;CR5;;VISIBLE_DISTANCE;11.96

co.co131 RedMouRd,PinRivBlvd VISIBLE_DISTANCE 11.27 co.co131;RedMouRd;PinRivBlvd;;VISIBLE_DISTANCE;11.27

co.co318 UT/CO,CR10N VISIBLE_DISTANCE 18.90 co.co318;UT/CO;CR10N;;VISIBLE_DISTANCE;18.90

[bejacob]

Is this system ready to move from "preview" to "active"? Seems like there hasn't been any discussion in a while. Just curious about the status.

[Jim]

I'd like to activate this one.  Is there any reason to hold off, other than the lack of specific sources on the credits page?

[si404]

I'd like to activate this one.  Is there any reason to hold off,

Mapcat and yakra have talked about peer reviewing my US state route systems this summer.

other than the lack of specific sources on the credits page?

Does there need to be one?

[Jim]

other than the lack of specific sources on the credits page?

Does there need to be one?

Only if there were any sources used that aren't in the "general" category, like state highway logs or maps, etc., that are specific to Colorado.

[mapcat]

Sorry for the delay. My notes for the routes through 50 are below, but first some general questions.

How accurate should we be at placing the waypoints exactly on an intersection? Many of these are slightly off (meaning over one road but not the other) or further away (not over pavement at all) according to both Google satellite data and OSM. I began compiling lists of these for each route I looked at, but after a while lost interest since there were so many.

How important are implied concurrencies? A few routes (CO7, CO17, CO52) seem to stop and restart after joining another route, per GMSV signage.

Routes should always be plotted west-to-east and south-to-north, correct? CDOT plots some in different directions, and some of the Colorado routes follow CDOT's plot rather than TM convention. Please let me know if there are exceptions to this (besides obvious judgment calls such as diagonal routes).

CDOT source I used: http://dtdapps.coloradodot.info/otis/HighwayData

CO1: CR58 -> CR58_E, US287 -> US287/14
CO2: SmiRd doesn't intersect CO2. 40thAve is the closest intersection to this point, but is it necessary? It's less than half a mile from I-70.
CO5: reverse order
CO7: Does it actually follow US36, or does it exist as 2 separate routes? There's an end sign at Lyons.
        GobCasRd -> PreDr
        Bus7_W (&E) -> CO7Bus_W (&E)?
        SprDr appears to be a private driveway. Is this point needed?
CO7Bus (Allenspark) is signed and listed in CDOT's inventory
CO8: BearCreRd -> BearCreBlvd
CO9: It's unclear why some waypoints are county road numbers and others are county road names, even for numbered routes.
        DepSt -> 7thSt or RaiAve (point is not on any intersection so it's hard to tell which road it refers to, but Depot St does not intersect CO9)
        SheTraRd -> GatDr
        DotRd -> WhiPinLn & move slightly
        TosRd does not intersect CO9
        CurCrePass isn't at an intersection or at the pass summit, which apparently is unheralded on CO9.
        ElkMouRd appears to be a private driveway.
CO10: PitLineRd -> PipRd
CO12: BasOsoRd -> BosOsoRd
          What does StoGap represent?
          CR11 does not intersect CO12 at CR11_E
          FR415 -> CR46
          AspAve -> AspRd & move to intersection
          EchoCanRd -> EchoCynRd (or is "Cyn" not recognized as a standard abbreviation here?)
CO13: CDOT says the S end is at 7th St/Airport Rd
          N end should be on road
          CoalMineRd does not intersect CO13 (bridge)
          CR20 is probably CR185
CO14: StoParRd -> StoPraRd or CR27; other named roads could be CR's as well
          CR54 -> CR54G_W
          Add point at CR54G_E (east end of former business loop through Laporte)
          CR55 -> CR65
CO15: reverse order
          CR8 -> CR8S
          CR6 -> CR12S
CO17: Appears to be 2 separate routes; not signed along US285 or US160
          CR-D5 -> CRD.5
          CR-F -> CRF (or is the "-" necessary for CR's that begin with a letter?)
          RusSt -> CRT
          Move S end to state line
CO21: reverse order
CO23: MilAve -> MalAve & move slightly
CO30: 6th/HavSt -> 6thAve_W?
CO35: 53rdPla -> 53rdPl
CO39: S end seems to be CO52 (which ends there rather than continuing on to I-76)
CO40: CDOT agrees with you that CO40 and CO40Bye are separate routes, but GMSV shows signage uniting the two
CO40Aga: CDOT agrees with your route, but GMSV shows signage north to I-70 exit 336
CO44: reverse order
CO45: CDOT shows the N end at Bahama Dr/Capri Cir and the S end at Greenhorn Dr
          22ndSt does not intersect CO45, but 24thSt isn't far away
CO46: the E end should be on the county line
          CR57 -> CraGulRd? I couldn't find any reference to CR57 besides OSM. The Gilpin County GIS doesn't show county road numbers.
CO47: US50 -> US50_E
          WilWhiBlvd -> PeteJimPkwy

I'll review the rest as time permits over the next 2 weeks.

[oscar]

How accurate should we be at placing the waypoints exactly on an intersection? Many of these are slightly off (meaning over one road but not the other) or further away (not over pavement at all) according to both Google satellite data and OSM.

I try to be exact, but OSM often undoes that through minor improvements in its own mapping while I'm working on a route set. That kind of "mapping drift" encourages us to go with "close enough for government work" on waypoint placement.

When I took over usanm, there were a lot of points off by a little, and some off by a lot. I let go the former, as well as intersections with I- and US routes that I didn't touch at all unless the routes absolutely had to be updated.

Routes should always be plotted west-to-east and south-to-north, correct? CDOT plots some in different directions, and some of the Colorado routes follow CDOT's plot rather than TM convention. Please let me know if there are exceptions to this (besides obvious judgment calls such as diagonal routes).

Normally south -> north and west -> east, but if the milemarker order is known to run differently, we'll often follow that instead. But we don't always verify the ordering used by a DOT, which is why I say "often".

Now when the milemarker order changes direction in the middle of a numbered route (like with the west end of AK 1, and the east end of I-A1), that's a judgment call to use the order followed by the majority of the route, which in those instances happens to follow the west -> east convention.

[si404]

Implied concurrencies - if there's an end sign, then sure, that means I'll break it up. Not being signed along other routes - depends (of course, as a Brit, I'm used to it!). CO7 is mapped (though taking a different route in Boulder), but a look at the signs meant I found an 'END' and also no signage along the route parallel to US285 that maps have it marked along, so I broke that. CO17, OTOH, just had signs disappear without any end sign, so I just left it joined.

US287 -> US287/14

I don't do that, as it's very confusing and isn't necessary (showing more than one route is only needed if they are of the same level) - is that US14?

SmiRd doesn't intersect CO2.

MQOpen shows a slip road (and as a GSJ, it is a mandatory point), though Mapnik shows that it's closed. Starred.

(point is not on any intersection so it's hard to tell which road it refers to, but Depot St does not intersect CO9)

The point was clearly close to OSM's point at Depot Rd (though if you zoom in, it becomes 6thSt) - I've moved it to 7thSt anyway.

SheTraRd -> GatDr
DotRd -> WhiPinLn & move slightly

Why use the Google names, when OSM provides perfectly cromulant ones?

What does StoGap represent?

You'd have found out if you looked at the OSM/MQOpen mapping rather than the Goog! 

EchoCanRd -> EchoCynRd (or is "Cyn" not recognized as a standard abbreviation here?)

Why this one and not the others (there's three on this route, there's been several more in lower-numbered routes)? We can use either, and I went with 'Can'. I can change them all, but I'm certainly not going to change just the one.

CoalMineRd does not intersect CO13 (bridge)

Can you really not see slip roads? Oh wait, you're using Google's mapping, not OSM's...

other named roads could be CR's as well

But if they aren't mapped with the number, what's the point in using them. GMSVing every waypoint with a road name to see whether it's a county route seems a waste of time. I know you left this optional, but it seems highly excessive to play 'hunt the county route'.

(or is the "-" necessary for CR's that begin with a letter?)

Yes - I think as it makes clear it's a CR.

S end seems to be CO52 (which ends there rather than continuing on to I-76)

Southbound, CO52 reaches exit 66A, rather than goes down Central Avenue. As there's no CO39 signs at CO52/Central Ave (or south from I-76), there's no reason to continue it southwards. I might change my mind on this later, but I'm keeping it as-is for now.

the E end should be on the county line

Because being 2m off is sooo bad....

I couldn't find any reference to CR57 besides OSM. The Gilpin County GIS doesn't show county road numbers.

And?

WilWhiBlvd -> PeteJimPkwy

and again with the desire to replace perfectly acceptable OSM mapping data 

[mapcat]

US287 -> US287/14

I don't do that, as it's very confusing and isn't necessary (showing more than one route is only needed if they are of the same level) - is that US14?

No, CO14. I've seen it done enough by others that I thought it was standard.

(point is not on any intersection so it's hard to tell which road it refers to, but Depot St does not intersect CO9)

The point was clearly close to OSM's point at Depot Rd (though if you zoom in, it becomes 6thSt) - I've moved it to 7thSt anyway.

Why wouldn't you zoom in?

SheTraRd -> GatDr
DotRd -> WhiPinLn & move slightly

Why use the Google names, when OSM provides perfectly cromulant ones?

Just to be clear, I'm not simply blindly following Google's map data, which is often incorrect or incomplete. I'm using its satellite imagery, which is newer than other satellite imagery in most cases in the US, and street view imagery, which also is dated and seems more reliable than a map built and maintained completely by volunteers.

What does StoGap represent?

You'd have found out if you looked at the OSM/MQOpen mapping rather than the Goog! 

All I could see when I checked those other sources was the name of a community. We're using those as waypoints?

EchoCanRd -> EchoCynRd (or is "Cyn" not recognized as a standard abbreviation here?)

Why this one and not the others (there's three on this route, there's been several more in lower-numbered routes)? We can use either, and I went with 'Can'. I can change them all, but I'm certainly not going to change just the one.

Sorry, I should have been more clear that this was a general question about the use of that abbreviation. Of course the abbreviation should be consistent across all instances.

CoalMineRd does not intersect CO13 (bridge)

Can you really not see slip roads? Oh wait, you're using Google's mapping, not OSM's...

Yes, I saw the slip road--actually more of a separate road than a ramp in this case--but it's nowhere near where you placed the waypoint.

other named roads could be CR's as well

But if they aren't mapped with the number, what's the point in using them. GMSVing every waypoint with a road name to see whether it's a county route seems a waste of time. I know you left this optional, but it seems highly excessive to play 'hunt the county route'.

So is it not necessary, or even helpful, that the waypoint names ought to match what's signed in the field? If not, why not just simplify this even further and assign them all random names?

the E end should be on the county line

Because being 2m off is sooo bad....

2m? Try 2 blocks.

I couldn't find any reference to CR57 besides OSM. The Gilpin County GIS doesn't show county road numbers.

And?

When you've got something tangible like a recent photo of a sign, why ignore it in favor of a name that may or may not be correct?

WilWhiBlvd -> PeteJimPkwy

and again with the desire to replace perfectly acceptable OSM mapping data 

Why are you so impressed with OSM data? Google isn't perfect by any means, but it's really hard for me to accept that a photo of a sign or satellite imagery of a realigned road may be less trustworthy than a map drawn by a bored teenager at 3am.

Sorry that this seemed to touch a nerve. I'm just trying to narrow the gap between my knowledge and the common and best practices employed by the others working on this project. From what I gather from your comments, it seems I've wasted a great deal of time on finding a "correct" name and location for each waypoint. I was not aware of the low priority placed on these, and will work accordingly in the future.

[si404]

No, CO14. I've seen it done enough by others that I thought it was standard.

I was being rhetorical - I know it was CO14, just pointing out the reason why I don't use that format.

Why wouldn't you zoom in?

Because I want to see more than a couple of hundred feet away from the point? It only appeared when I was right zoomed in onto the lowest zoom levels - why would I zoom in that far? It's fixed now anyway.

I'm using its satellite imagery, which is newer than other satellite imagery in most cases in the US, and street view imagery, which also is dated and seems more reliable than a map built and maintained completely by volunteers.

So what you are saying is I need to use data that is copyrighted and leave TM open to lawsuits? 

In terms of threat of lawsuits, Google don't care that much about their map itself, but the satellite/streetview data that costs them lots of money to actually have and keep up-to-date, and they care more about it.

You are saying that I need to change map layers every time I make a point? And enter GMSV everytime there's a conflict between mapping sources? Sounds like busy work!

All I could see when I checked those other sources

OSM/MQOpen is not 'other sources' its the main mapping source we have. We used to use Google (with .ggm files) as our main mapping source, but we did a lengthy conversion to OSM for legal reasons in 2008.

the name of a community. We're using those as waypoints?

Yes, when there's no road name or number.

Yes, I saw the slip road--actually more of a separate road than a ramp in this case--but it's nowhere near where you placed the waypoint.

What I see is a echline style link and another ramp (hence my OP's use of 'ramps'). If it was just an echline, then of course I would have placed it at the link road, but the way I see that junction, according to the mapping, is that the waypoint should go there at the bridge.

So is it not necessary, or even helpful, that the waypoint names ought to match what's signed in the field?

They should also match what's on the map, surely? It should be assumed that, ideally they would be one and the same and most of the time they are. It's an awful lot of busy work to assume that the map needs double-checking. And that's before we go into the copyright issues of creating a derived work from Google (and it's sources that it uses under licence) data and then licensing it differently.

If not, why not just simplify this even further and assign them all random names?

Because there's a massive gulf of difference between random names and names on a mapping source that we can legitimately use. Most of the time, the mapping source is accurate.

2m? Try 2 blocks.

2 blocks??? Is there an ant city there? This is at max zoom!

When you've got something tangible like a recent photo of a sign, why ignore it in favor of a name that may or may not be correct?

Because:
1) it's a whole lot of busy work to go and see whether Schrodinger's label is or is not correct
2) the odd point name from Google data here or there is unlikely to get the lawyers coming, but a policy of using Google's proprietary data to check every point leaves us very vulnerable to being sued.

Obviously, if the photo is from a field check by someone here, then it would be fine to use it.

[mapcat]

Why the hell would Google sue a HOBBYIST site that derives NO MONEY from the use of their imagery?


Assuming they even cared about this site enough to investigate where we got the waypoint names, how could they PROVE that someone who called a waypoint by the name on the street sign rather than the name on OSM got the information from Street View rather than from field-checking it?


Here's the Gilpin-Jefferson county line on CO46:


https://www.google.com/maps/@39.8155783,-105.3965932,3a,25.8y,312.56h,89.05t/data=!3m6!1e1!3m4!1sv2AQ0dBJpD8mI-t5wE5XZA!2e0!7i13312!8i6656!6m1!1e1


Note how close it is to Golden Gate Dr (west of Bear Paw Rd):


https://www.google.com/maps/@39.8158216,-105.3973252,3a,75y,24.18h,73.41t/data=!3m6!1e1!3m4!1sDdsr8CRFXkLi7lbXUJsvBg!2e0!7i13312!8i6656!6m1!1e1

[si404]

Sorry that this seemed to touch a nerve.

The copyright issues are bigger for me, as I'm in a jurisdiction with a lot less lax 'fair use' regulations. Plus having spent several days on usaco only to be told that I need to spend several more days double-checking every point irks me. Add in stuff like the moving of the CO46 end point that a tiny bit off thanks to what oscar calls "mapping drift" and I can become rather irritable (plus I'm already irritable thanks to Downing Street deliberately trying to create a disaster for my country should we not side with them, just so that their insane apocalyptic predictions (based on xenophobia towards both the electorate and the rest of Europe) might just come true).

I'm just trying to narrow the gap between my knowledge and the common and best practices employed by the others working on this project.

A lot of this is in the manual, though, yes, you are just coming into this and don't have the years of consensus and discussions of how to do this in your memory.

From what I gather from your comments, it seems I've wasted a great deal of time on finding a "correct" name and location for each waypoint. I was not aware of the low priority placed on these, and will work accordingly in the future.

It's not a low priority to find a "correct" name and location for the waypoint. It's a low priority to do a lot of busy work assuming that the map is wrong and double-checking that the name and location is right.

[Jim]

Regarding the use of too much Google data, I don't know what made Tim decide several years ago that we needed to get CHM off of that data, but something made him to go the trouble of not using it.  I wish I knew what happened to force the switch away.  As long as the site is on a domain with my name attached to it and running on a server I own, I'd like to err on the side of caution and make sure we're not deriving anything from Google other than the occasional point recentering or renaming.  Ensuring that we only derive our data from sources that are entirely legal for use is also important to the academic side of this project for me, and that connection to my academic project is the only way I can justify putting in as much time as I do on TM.

[mapcat]

Plus having spent several days on usaco only to be told that I need to spend several more days double-checking every point irks me.

Please understand that this is my first attempt at a peer-review. I am not yet familiar with what needs to be flagged and what does not. I didn't tell you you need to do anything; I was just surprised that you weren't concerned with getting the placement of points as exact as I suspected they were supposed to be. This doesn't make you wrong: it just clarifies something for me. The rest of my review should demonstrate a clearer understanding on my part.

A lot of this is in the manual, though, yes, you are just coming into this and don't have the years of consensus and discussions of how to do this in your memory.

I appreciate your recognizing that.

Regarding the use of too much Google data, I don't know what made Tim decide several years ago that we needed to get CHM off of that data, but something made him to go the trouble of not using it.  I wish I knew what happened to force the switch away.  As long as the site is on a domain with my name attached to it and running on a server I own, I'd like to err on the side of caution and make sure we're not deriving anything from Google other than the occasional point recentering or renaming.  Ensuring that we only derive our data from sources that are entirely legal for use is also important to the academic side of this project for me, and that connection to my academic project is the only way I can justify putting in as much time as I do on TM.

This is a very good point that I had not considered. In a roundabout way, Jim is deriving an income from the data we're gathering here, and as much as anyone else here I'd wish to protect him from any controversy regarding this data.

With this in mind, would it be prudent to eliminate anything Google-related from any future TM waypoint editor?

(plus I'm already irritable thanks to Downing Street deliberately trying to create a disaster for my country should we not side with them, just so that their insane apocalyptic predictions (based on xenophobia towards both the electorate and the rest of Europe) might just come true).

I wish you and your country the best as you navigate this. I hope you'll return the favor in a bit less than 5 months when my country faces its own existential crisis.

[si404]

Please understand that this is my first attempt at a peer-review. I am not yet familiar with what needs to be flagged and what does not. I didn't tell you you need to do anything; I was just surprised that you weren't concerned with getting the placement of points as exact as I suspected they were supposed to be. This doesn't make you wrong: it just clarifies something for me. The rest of my review should demonstrate a clearer understanding on my part.

Of course - I lost sight of this when the red mist descended. I was a real grump - don't take it personally. Other stuff (not to mention the awful weather that has thankfully stopped and turned out nice, lightening my mood a lot) had wound me up, and this was merely a small rock that caused an avalanche of annoyance.

I came out far too strong in opposition to you, and for that, I unreservedly apologise.

Most of your review was good stuff, and I've implemented it.