Feature: Show user-relevant update entries

[michihdeu]

http://tm.teresco.org/devel/updates.php

It should be possible to reduce the "Updates to Highway Data in Active Systems" table to show only entries which are traveled by the selected user.

http://tm.teresco.org/forum/index.php?topic=1889.msg7034#msg7034

It should be possible, to filter the reduced table as described in #203

[yakra]

select date, root, description from clinchedRoutes as clin right join updates on clin.route = root where traveler = 'yakra';

[michihdeu]

If I get the last post right, the info is already in the db?

There should be two lists like in the log file:

• List of user relevant update entries since project start (or first user appearance?)
• List of user relevant update entries since last user list file update (like reduced list at beginning of user log file)

I'd still love to see all new route entries of all regions where the selected user has travels. A first step could be two full list of all* entries of the regions traveled:

• List of user regions update entries since project start (or first user appearance?)
• List of user regions update entries since last user list file update (including duplicates to previous lists)

[yakra]

If I get the last post right, the info is already in the db?

Yes and no.
Some of the info is; we have less capability than what we're able to put in the log files.
The info that makes it into the DB can't determine whether a route segment was explicitly .listed, or was just added due to multiplex detection.
So, let's say I .list ME US202 ME5_S ME5_N, and me.us202 & me.me005 both have updates entries.
• My .log file would only show the US202 entry, since only US202 was explicitly .listed.
• The DB query above will see that I have travels on both routes (it doesn't know how I got this mileage) and show both updates.

The DB does not contain any info about when a .list has been updated.
We can't do last user list file update or first user appearance, but we can do project start of course.
Almost as good (?), we can do update entries from a user-specified date, such as from a QS param or UI element.

I'd still love to see all new route entries of all regions where the selected user has travels.

Problem is, there are also route added, added route, and however many other ways of describing such, in among the "plain English" updates text. Making a useful filter would be hard, and would probably require a rethink of how updates.csv is done. Adding a new data column is no easy feat with >5300 lines already... But then, maybe you say "a first step" because you already realize this... ;)

A first step could be two full list of all* entries of the regions traveled:

There's another step we need before getting this far -- the region column. Right now, entries like (USA) Texas don't correspond to any other database fields. If we replaced with standard region codes, we could do lookups & JOINs & useful stuff like that. Converting should be doable with a bit of effort. Some spreadsheet and/or shell script magic...

With a little SQL/PHP-fu, we might be able to detect regions in countries with >1 regions, and keep roughly the same appearance on the updates page.
• DEU-BW -> (Germany) Baden-Wurttemberg
• NS -> (Canada) Nova Scotia
Complicatiions:
Most countries where this is done use the country's name field. I see at least 2 exceptions:
• USA is the country's code instead.
• UK = GBR;United Kingdom
Rather than add a new column for how to display a country on the updates page, if we wanted to maintain this formatting, we could just hard-code exceptions for USA & GBR...

[michihdeu]

So, let's say I .list ME US202 ME5_S ME5_N, and me.us202 & me.me005 both have updates entries.
• My .log file would only show the US202 entry, since only US202 was explicitly .listed.
• The DB query above will see that I have travels on both routes (it doesn't know how I got this mileage) and show both updates.

Can we feed the DB from what we enter in the .log file? I mean, it is all user-dependent stuff, not route-dependent...

Problem is, there are also route added, added route, and however many other ways of describing such, in among the "plain English" updates text. Making a useful filter would be hard, and would probably require a rethink of how updates.csv is done.

I made a proposal but it was called overkill

[yakra]

Can we feed the DB from what we enter in the .log file? I mean, it is all user-dependent stuff, not route-dependent...

Yes. In siteupdate, each TravelerList object contains a list of chopped Routes explicitly .listed by the traveler.
This could be tracked as a new boolean field in the existing clinchedRoutes DB table.

[jteresco]

Is there enough value added in trying to get user-specific filtering on the updates page now that log files have notes added about relevant updates?

[yakra]

Still useful IMO. Log files only have the most recent update for each route for the sake of brevity. A Web-based utility would be a good way to get a more complete list.

[michihdeu]

Is there enough value added in trying to get user-specific filtering on the updates page now that log files have notes added about relevant updates?

Yes!

[yakra]

Can we feed the DB from what we enter in the .log file? I mean, it is all user-dependent stuff, not route-dependent...

Yes. In siteupdate, each TravelerList object contains a list of chopped Routes explicitly .listed by the traveler.
This could be tracked as a new boolean field in the existing clinchedRoutes DB table.

Oops. Forgot about this when #502 closed yakra#202.
Easy enough to revert though, and it didn't save very much time.

This could also be implemented as a TMBitset, but it'd take a bit of work to get there.

• Faster
• May or may not save RAM; gotta do the math & try it out.