Travel Mapping

Web Design Discussion => General Web Design Discussion => Topic started by: Jim on December 16, 2016, 10:27:28 am

Title: Including map views in highway data updates entries
Post by: Jim on December 16, 2016, 10:27:28 am
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.
Title: Re: Including map views in highway data updates entries
Post by: yakra on December 16, 2016, 03:24:04 pm
Quote from: Jim/jteresco
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?

Quote from: Jim/jteresco
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.

Quote from: mapcat
@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
Title: Re: Including map views in highway data updates entries
Post by: Jim on December 18, 2016, 11:15:32 am
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?
Title: Re: Including map views in highway data updates entries
Post by: mapcat on December 18, 2016, 12:32:26 pm
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).
Title: Re: Including map views in highway data updates entries
Post by: yakra on December 18, 2016, 07:46:34 pm
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?
Title: Re: Including map views in highway data updates entries
Post by: bhemphill on December 18, 2016, 09:07:12 pm
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.
Title: Re: Including map views in highway data updates entries
Post by: mapcat on December 18, 2016, 09:52:47 pm
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.
Title: Re: Including map views in highway data updates entries
Post by: michih on December 19, 2016, 04:38:06 pm
if we're trying to show evidence that the change was needed

Why should we do this?
Title: Re: Including map views in highway data updates entries
Post by: mapcat on December 19, 2016, 11:49:21 pm
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.
Title: Re: Including map views in highway data updates entries
Post by: michih on December 19, 2016, 11:58:52 pm
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.
Title: Re: Including map views in highway data updates entries
Post by: mapcat on December 20, 2016, 12:01:29 am
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?
Title: Re: Including map views in highway data updates entries
Post by: yakra on December 20, 2016, 01:29:27 am
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?
Title: Re: Including map views in highway data updates entries
Post by: michih on December 20, 2016, 01:44:42 am
What sorts of realignments wouldn't deserve images?

True.
Title: Re: Including map views in highway data updates entries
Post by: froggie on December 20, 2016, 10:42:19 am
Quote from: yakra
I would not like to see this required for every realignment/extension/truncation.

Concur.  I really don't see this as necessary.
Title: Re: Including map views in highway data updates entries
Post by: yakra on December 22, 2016, 02:52:04 am
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 (http://cmap.m-plex.com/tools/manual_maintenance.php) (search for "Newsworthy news entries").
Title: Re: Including map views in highway data updates entries
Post by: michih on December 24, 2016, 03:16:27 am
I wanna bring this topic up because we currently have a discussion where images might help: http://tm.teresco.org/forum/index.php?topic=1800.msg4757#msg4757.

My first thought about "showing realignments before/after" on a map was positive because I also had similar problems to understand or to describe changes.

However, I have no simple solution in my mind which could work easily. We would need rules about file format (file size vs. quality, e.g. bmp/jpg/png/tif...), screen resolution, map style, manual highlighting etc. but I think it's hard that every contributor makes screen shots showing the old and the new alignment with the same quality, same look and feel.

For instance, I don't know how this situation (http://tm.teresco.org/forum/index.php?topic=1854) should be shown with a screen shot. This situation must be described with words.

If the description is not clear, the actual solution is asking on the forum. This might work but it's painful for everyone.

I discovered a GitHub feature yesterday. It's not a new feature but I needed it for the first time yesterday (new NLD A12 exit 10 already existed at a location w/o i/c). You can see what has changed in the wpt file (http://tm.teresco.org/forum/index.php?topic=1800.msg4760#msg4760). If you wanna see the old wpts on a map, you can load the corresponding lines to the wp editor, zoom in/out and discover the change on maps etc. But searching the related data on GitHub is not the way how user should figure this out.

We could add one or more "Modification detail" column(s) to updates.csv:

Shows all modifications to the file: https://github.com/TravelMapping/HighwayData/commits/master/hwy_data/NC/usaus/nc.us501.wpt (not required)
Shows the relevant modification to the file: https://github.com/TravelMapping/HighwayData/commit/9d58607f01f1801e0ecd3c0870c45a941a3e023a#diff-e2483097ebfea9179276b2981736684e (red/green what has been changed)
Shows the old version of the file: https://github.com/TravelMapping/HighwayData/blob/0ff7029283fcc1acc2db1fc402bd19b27b34bb85/hwy_data/NC/usaus/nc.us501.wpt (to be loaded to wpt editor)

I think it's not a perfect solution but better than screen shots...


Thoughts? Other ideas?
Title: Re: Including map views in highway data updates entries
Post by: yakra on December 24, 2016, 01:10:54 pm
bits crossposted: http://tm.teresco.org/forum/index.php?topic=1800.msg4763#msg4763

Feeping creaturism.

"Shows the relevant modification to the file" -- unintuitive, as it will often be hidden amongst a bunch of other files changed in the same commit. (Unless we mandate that each commit change only one file, an idea I dislike.)

"Shows all modifications to the file" -- The user will have to find the correct commit to look at the DIFF. Often apparent if the user knows the date the change was made, but sometimes not.

"Shows the old version of the file" -- Either this would require some very clever coding from Jim (or whoever was tasked with implementing it.), or the collaborator making note of the update changes would have to find the SHA for the old version of the file. Some of us aren't that well versed in GitHub, and still submit updates the old-fashioned way, by emailing to Jim or another contributor. Either that's more work that's potentially outside the expertise of a particular contributor, or more work for Jim or whoever.
I think looking at GitHub (and loading stuff into WPTedit) is by its nature more suited to the Power Users -- and those who have the inclination and the know-how can find the appropriate part of GitHub on their own... via "TM on GitHub", their own Browser History, or however. Putting the task of finding the link to a relevant commit on the data contributors, IMO, just adds more busy-work, complication, (and further chances for things to go wrong), for too little gain.

If our pursuit of perfection becomes too relentless, it will soon become a headache of its own.

Quote
If the description is not clear, the actual solution is asking on the forum. This might work but it's painful for everyone.
Or referring to GitHub, as you mentioned, though that's not for everyone. For casual users, yes, asking on the forum is probably the way to go if things are unclear. I think think there's much of a practical way to avoid the process being painful at some point , somewhere. So let it be painful. We just gotta find a way to make the least amount of pain the most tolerable.

--

I think the old CHM conventions, the "mad-libs" of how to phrase updates wording, are overall a very good benchmark to strive for.
They can be found at the bottom of this page (http://cmap.m-plex.com/tools/manual_maintenance.php) (search for "Newsworthy news entries").

A couple excerpts:
Quote
Relocated route (in middle of route):
Pennsylvania US 220: Removed from Main Street and 5th Avenue, and relocated onto a new northern Georgetown bypass, between US 23 and PA 70.
(mentions both ends of the new part, that is, the intersections/places where the old and new alignments meet) and both the old and new routes

Quote
Don't refer to "the new route" or "the new end". Instead, say what the new route is.

Sure, even I'll admit that writing these out can get tedious at times. But proper, descriptive wording in the updates entries can go a long way toward establishing clarify.
Title: Re: Including map views in highway data updates entries
Post by: michih on December 25, 2016, 03:22:46 am
Ok, another idea :)

nc.us501.wpt (actual file; with line index):
Code: [Select]
...
71 CouSt http://www.openstreetmap.org/?lat=36.395085&lon=-78.986270
72 MainSt +NC49 http://www.openstreetmap.org/?lat=36.409756&lon=-78.972183
73 NC49_N http://www.openstreetmap.org/?lat=36.414390&lon=-78.954502
74 BosRd +HalRd http://www.openstreetmap.org/?lat=36.452073&lon=-78.926087
75 NC/VA http://www.openstreetmap.org/?lat=36.541881&lon=-78.901609

nc.us501.001.wpt (new file containing the segment in question plus the unchanged waypoints in front and after; with line index):
Code: [Select]
1 CouSt http://www.openstreetmap.org/?lat=36.395085&lon=-78.986270
2 NC49 http://www.openstreetmap.org/?lat=36.409756&lon=-78.972183
3 WooRd http://www.openstreetmap.org/?lat=36.443292&lon=-78.958536
4 HalRd http://www.openstreetmap.org/?lat=36.452073&lon=-78.926087
5 NC/VA http://www.openstreetmap.org/?lat=36.541881&lon=-78.901609


Updates.csv entry gets a new optional column:

2016-11-14;(USA) North Carolina;US 501;nc.us501;rerouted to new construction north of Roxboro
-->
2016-11-14;(USA) North Carolina;US 501;nc.us501;rerouted to new construction north of Roxboro;nc.us501.001



Updates.php shows it on the site like today:

2016-11-14   (USA) North Carolina   US 501   nc.us501 (http://tm.teresco.org/hb?r=nc.us501)   rerouted to new construction north of Roxboro

It's still the same but opening the HB via updates.php could load nc.us501.wpt and nc.us501.001.wpt. The graph of latter should be displayed in a different color. A 2nd table (or just additional columns in the existing table) could be displayed on the left containing the old waypoints from nc.us501.001. They can directly be positioned in the correct line because nc.us501.001.wpt contains the unchanged waypoints in front and after

Code: [Select]
(36.395085,-78.98627) CouSt 27.27
(36.409756,-78.972183) MainSt 24.24 (36.409756,-78.972183) NC49
(36.41439,-78.954502) NC49_N 21.21 (36.443292,-78.958536) WooRd
(36.452073,-78.926087) BosRd 22.73 (36.452073,-78.926087) HalRd
(36.541881,-78.901609) NC/VA

If there are more or less waypoints now, there could be a gap, e.g. if NC49_N had not exist:

Code: [Select]
(36.395085,-78.98627) CouSt 27.27
(36.409756,-78.972183) MainSt 24.24 (36.409756,-78.972183) NC49
(36.452073,-78.926087) BosRd 22.73 (36.443292,-78.958536) WooRd
(36.452073,-78.926087) HalRd
(36.541881,-78.901609) NC/VA


The user could directly figure out what has been changed and how to change its user list file.

6 graph colors are required (1-3 already exist):

blue: no user selected, actual route
grey: user selected, segment of actual route not traveled
pink: user selected, segment of actual traveled

brown: no user selected, old route
white: user selected, segment of old route not traveled
red: user selected, segment of old traveled




btw: The current updates.csv entry of the NC change is really "bad" and not according to CHM conventions:

Code: [Select]
2016-11-14;(USA) North Carolina;US 501;nc.us501;rerouted to new construction north of Roxboro
Quote
Don't use vague phrases like "the correct location", "onto new construction". Instead, say what the location or highway is.
Title: Re: Including map views in highway data updates entries
Post by: compdude787 on January 06, 2017, 04:01:27 am
Kind of tempted to write this off as too much of a pain in the botty to pursue.

Yeah, I agree; this does seem like way too much work for us all.