Including map views in highway data updates entries

[Jim]

A discussion started in GitHub (https://github.com/TravelMapping/HighwayData/pull/991) about possibly having an option to include before and after map views for some highway data updates.  I'll post some thoughts here hopefully soon but maybe others can offer opinions or suggestions on this.

[yakra]

I for one am happy we have relaxed the updates entry rules a bit but we do want the information in there.

The @mapcat comment about the visual being so much more useful makes me think we really want to have some way to show old and new alignments in map form. For some updates, I've found myself at a loss to figure out exactly what I need to do to correct my list file for realignments. I am not proposing a good mechanism for this, but it's something to consider. First thought: before and after screen grabs we can link from the updates entry

Should we shoot for a maximum image resolution?

in cases where this seems useful?

I just want to reemphasize this point. I would not like to see this required for every realignment/extension/truncation.

@jteresco I'd love that...seems like a good idea to work out. How would you suggest storing them/making them available?

I think these should get a directory in the HighwayData repo on GitHub, so they'd be easily available to anyone making their own site with a clone of the data.

File naming suggestion: root_ChangeDate_#[a/b] or root.ChangeDate.#[a/b] (a/b is for after/before), E.G. me.us001altban.20161216.01a.png & me.us001altban.20161216.01b.png

A new column in updates.csv could reference the change number, and updates.php could create links, from that, to the before and after images:
2016-12-16;(USA) Maine;US1 Alternate (Bangor);me.us001altban;Removed from Emacs St and relocated into Vi between Pine St and Elm St;01

If there are two or more unrelated changes to the route requiring separate image pairs, these should be broken up into two updates.csv entries, instead of listed together.
2016-12-16;(USA) Maine;US1 Alternate (Bangor);me.us001altban;Removed from Emacs St and relocated into Vi St between Pine St and Elm St;01
2016-12-16;(USA) Maine;US1 Alternate (Bangor);me.us001altban;Removed from Windows Ave and relocated into Ubuntu Blvd between Apple St and CentOS St;02

[Jim]

I wouldn't want these to be a requirement, but it seems like a nice feature to add in those cases where a short piece of text can't easily describe the change clearly.

I agree the images should live in GitHub, and maybe they can live only there if we can link to them directly.  A nice simple extension to the updates.csv file seems appropriate.  Maybe it can be as simple as if there is an existing file in the repository, a link is automatically created with no changes to csv.  Just leave out the change number from the file names?

[mapcat]

I'm going to add the new I-265 bridge in Kentucky and Indiana tomorrow, assuming it opens on schedule. Since it's not replacing an old bridge, but only connecting two parts of a disconnected highway, I don't think it would benefit from an image.


But say it did: what could/should I use for the basemap when I create the image? OSM shows it because it's in a large city, but the change I made to another Kentucky highway isn't in OSM since it's in a rural area. Google's map hasn't caught up with it yet, either, but Google's satellite image shows the new routing clearly (under construction, but still it makes obvious where the rerouting happened).

[yakra]

Jim: It's just that I can foresee the possibility of two changes requiring images being updated for the same route on the same day.

Mapcat: maybe Bing Satellite, grabbed from WPTEdit? I'm a bit uncomfortable with the idea of using Google... If all else fails, maybe just have the route trace against an OSM background, and that (the route trace) would have to be adequate?

[bhemphill]

Yes, having an image to kind of indicate what is meant would be useful sometimes.  Rerouting updates are generally the least clear in order to keep the update brief.  The ones that at least have a point to go look at to find the vicinity of the change are more helpful at understanding what the update means, although knowing the old routing when there are multiple routes changing does help one to understand which routes do what now and take over the path that you travelled.

Also, it might be good to make the update page be selectable by year.  The 18 month update list is starting to make the page kind of long and many users may not need to go back and look at some of the older updates.  CHM did end up splitting the updates by year for probably a similar reason.

[mapcat]

Mapcat: maybe Bing Satellite, grabbed from WPTEdit? I'm a bit uncomfortable with the idea of using Google... If all else fails, maybe just have the route trace against an OSM background, and that (the route trace) would have to be adequate?

Bing's satellite data is sometimes years out of date. I guess what we need to decide is, what are we trying to show, specifically? If it's just the difference in the route trace, OSM would probably be adequate, but if we're trying to show evidence that the change was needed, or make it easier for the user to decide whether or not to declinch a segment, an out-of-date OSM map may be less helpful. Of course, it usually would still be more effective than words would be.

[michih]

if we're trying to show evidence that the change was needed

Why should we do this?

[mapcat]

if we're trying to show evidence that the change was needed

Why should we do this?

Think of a minor road realignment in between two waypoints. Some users might consider it unimportant, while others might decide that the road moved enough to remove the segment from their .lists.

[michih]

if we're trying to show evidence that the change was needed

Why should we do this?

Think of a minor road realignment in between two waypoints. Some users might consider it unimportant, while others might decide that the road moved enough to remove the segment from their .lists.

That would mean that we had to make images for every realignment. All update entries except new routes or route extensions.

[mapcat]

if we're trying to show evidence that the change was needed

Why should we do this?

Think of a minor road realignment in between two waypoints. Some users might consider it unimportant, while others might decide that the road moved enough to remove the segment from their .lists.

That would mean that we had to make images for every realignment. All update entries except new routes or route extensions.

What sorts of realignments wouldn't deserve images?

[yakra]

The ones that at least have a point to go look at to find the vicinity of the change are more helpful at understanding what the update means

I've continued the CHM tradition of writing things out verbally, E.G. "Removed from Pine St and relocated onto Elm St between Pink Floyd Ave and Led Zeppelin Ave".
The reader is left to translate to WayPtLabelSpeak in his head -- Removed from Pine St and relocated onto Elm St between PinkFloAve and LedZepAve -- before consulting the HB.
Would the actual waypoint labels themselves be more useful/intuitive for you?

[michih]

What sorts of realignments wouldn't deserve images?

True.

[froggie]

I would not like to see this required for every realignment/extension/truncation.

Concur.  I really don't see this as necessary.

[yakra]

Kind of tempted to write this off as too much of a pain in the botty to pursue.
If there's the occasional case where verbal descriptions don't suffice, then... Terribly Sorry?

For reference, Tim's CHM conventions are at the bottom of this page (search for "Newsworthy news entries").