Travel Mapping
Web Design Discussion => General Web Design Discussion => Topic started by: pderocco on October 28, 2023, 01:53:26 am
-
If Travel Mapping had simple passworded accounts, I would think it would be pretty easy to allow a user named xyz to upload a file called xyz.list to a processing directory, from whence the server could automatically process it and make it visible. It would be really nice if we could see the results of our additions within a minute or so. And it would eliminate the need for Jim or anyone to do this manually.
-
https://github.com/TravelMapping/DataProcessing/issues/22
-
Two thoughts related to this:
- As long as the TM server resides on my research server hosted by my employer, I am strictly limiting who has write access to any part of it.
- We can get much of this functionality with automated merges and pulls from GitHub in what I believe would be a much more secure process. It wouldn't give results in a minute, since a site update process takes several minutes, mostly to reload the databases. I am thinking more along the lines of hourly updates. I am still very hesitant on the automated merges of GH pull requests, so this might be accomplished by having several people with ability to merge PRs, and those changes would go into the next automated update.
-
having several people with ability to merge PRs, and those changes would go into the next automated update.
Sounds great!
-
I'm curious: why are everyone's .list files stored in GitHub? I understand why the software is; that's what GitHub is for. But .list files? Why is it necessary to maintain a history of updates? Isn't just storing the latest version of each file all that's necessary? That would eliminate the whole process of pull requests.
-
I'm curious: why are everyone's .list files stored in GitHub? I understand why the software is; that's what GitHub is for. But .list files? Why is it necessary to maintain a history of updates? Isn't just storing the latest version of each file all that's necessary? That would eliminate the whole process of pull requests.
The history isn't essential, though many users, including me, put in meaningful commit messages about changes to our files.
It was chosen because we were already going to use it for the site update software, the web front end code, and the highway data. I saw no reason to use a different solution for user data.
I am open to suggestions about other ways to store them that would work better.
-
I personally was using CVS to maintain a history of my .list file dating back to whenever it was I started with CHM. So I myself am quite thankful for the choice to use GitHub for storing .list fines on TM. YMMV.
-
^ One thing I love about git is the ability to go back thru the history & blame and see when and in what context a given line was added or edited.
It's great for source code, though I bet most people will not make heavy use of it for .list files. Still, it's a tool at our disposal for answering "What else was I doing on that road trip; how did I get there?" type questions.
-
As long as GitHub is used to record old versions of .list files, wouldn't it be useful to have a repo for old versions of .log files too? That would let us look up our past stats.
-
Here it is: https://travelmapping.net/updates/
-
I was talking about user update .log files, which are full of personal mileages and percentages.
-
Yours from 2024-10-01: https://travelmapping.net/updates/2024-10-01@21:33:39/logs/users/pderocco.log
-
I see it now, but it's not in a very useful form, because I have no memory of which days I submitted updates. My point is that, since GitHub has my .list file in the repo, and I can use the normal GitHub or git tools to brows through the past versions of it, my update .log file should also be in there, so I can browse it in the same way.
-
Good point! However, changes to your stats can happen with every update. Due to hwy data changes. you could manually look your list file updates up on Github, and then open the right file in our log archive.
Technically, we do not yet automatically upload data to Github.
In general, we lack interested contributors willing to invest time for coding.
-
I'm definitely interested in a way to track user histories, and I am sure the log files will be helpful to build such a thing. As it stands, we can do Unix diffs, the equivalent of Git change logs, on the text files. But this is not available to regular users directly, and as michih points out, changes in the logs occur not only for your new travels but as highway data is updated and expanded.
-
I'm definitely interested in a way to track user histories, and I am sure the log files will be helpful to build such a thing. As it stands, we can do Unix diffs, the equivalent of Git change logs, on the text files. But this is not available to regular users directly, and as michih points out, changes in the logs occur not only for your new travels but as highway data is updated and expanded.
Here's what I'm most interested in at the moment. Some of the bigshots around here like to tell us they drove another million miles of new road last year. I'd like to be able to check my own stats to see how much I added to my inventory, too. I'll never be in oscar's or mapcat's league, but it's still interesting information, at least to me. I can see how I can do it in several steps, but, since I know how to use git and GitHub, it would be easier just to bring up the appropriate commits without cross-referencing, or even do a git diff. But this means I wouldn't be interested in changes to my stats as a result of changes to the underlying databases, and at least in the US those changes would likely have only a tiny affect on my stats, since the database is pretty much complete.
-
I'd like to be able to check my own stats to see how much I added to my inventory, too.
You just have to open two log files under https://travelmapping.net/updates/
2024-01-01: 67,621.21 miles active+preview
2025-01-01: 77,962.87 miles active+preview
Total 2024: 10,341.66 miles active+preview
Of course, I'd love to see functionality doing the trick on the front end....
-
I'm interested in similar things. I'd like to be able to do things like show tables/charts of clinched routes/distances over time and make animations of a user's travels on maps over time. All possible, but it takes time that is very limited, at least for me to be able to do it.
-
I'm interested in similar things. I'd like to be able to do things like show tables/charts of clinched routes/distances over time and make animations of a user's travels on maps over time. All possible, but it takes time that is very limited, at least for me to be able to do it.
How would that take into account administrative corrections and changes in data? I've been known to adjust what I have marked clinched as I reflect on past travels and even what I count as a clinch (I've waffled on whether to count part of US 31/280 in Birmingham a couple times, for example). And some major changes in data could be a challenge (such as US 301 in Delaware, or the division of France).
-
I'm interested in similar things. I'd like to be able to do things like show tables/charts of clinched routes/distances over time and make animations of a user's travels on maps over time. All possible, but it takes time that is very limited, at least for me to be able to do it.
How would that take into account administrative corrections and changes in data? I've been known to adjust what I have marked clinched as I reflect on past travels and even what I count as a clinch (I've waffled on whether to count part of US 31/280 in Birmingham a couple times, for example). And some major changes in data could be a challenge (such as US 301 in Delaware, or the division of France).
I think we'd need to save the graphs at a certain point. There are related issues:
https://github.com/TravelMapping/DataProcessing/issues/177
https://github.com/TravelMapping/Web/issues/724