search

TravelMapping / Web

Web-facing tool/page development
8 stars 26 forks source link

Feature: Show user-relevant update entries #204

Open michihdeu opened 7 years ago

michihdeu commented 7 years ago

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 https://github.com/TravelMapping/Web/issues/203

yakra commented 7 years ago

For example, http://tm.teresco.org/devel/updates.php?u=yakra or http://tm.teresco.org/devel/updates.php?u=terescoj etc. could show updates for the routes in yakra.list or terescoj.list.

At risk of going down a bit of a rabbit-hole, AltRouteNames should probably be included. If I list travels on KS KS17, then show updates for KS KS14. If I list travels on MS I-22FutTup, then show updates for MS I-22. If I list travels on NS NS4Bib, then show updates for NS NS4NGl.

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

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

There should be two lists like in the 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:

yakra commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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.