Suggestions to Programmatically Audit .list File

[Hoss6884]

Inevitably, I sometimes come across errors or omissions when updating my list file (i.e. concurrencies I didn't know I had or didn't capture).  I'd like to do a mass audit of my .list file at some point to make sure I'm 100% accurate with segments and waypoint names, but before I invest the time, does anyone have any suggestions on how to do it programmatically?  I'm willing to dust off my coding skills, if necessary.

[michih]

I'm not sure, maybe I got you wrong..... Try to answer paritally...

i.e. concurrencies I didn't know I had or didn't capture

It is not necessary to had these because concurrencies are automatically detected and you are credited for it - if the concurrent routes are of different systems, it counts for all systems.

I'd like to do a mass audit of my .list file at some point to make sure I'm 100% accurate with segments and waypoint names

That you have valid waypoints? Don't you know your user log file: http://travelmapping.net/logs/users/hoss6884.log
Everything looks fine for you. An example with errors.

[Hoss6884]

Thanks for the response.

I’m sorry that I should have been clearer with my original question.  I understand I get credit for concurrencies regardless whether they are included in my file, but I would still like to be able to capture them if I don’t have them listed.  Same if a waypoint name changes - I know I still get credit but would like to have the most updated waypoint listed.

I'm not sure, maybe I got you wrong..... Try to answer paritally...

i.e. concurrencies I didn't know I had or didn't capture

It is not necessary to had these because concurrencies are automatically detected and you are credited for it - if the concurrent routes are of different systems, it counts for all systems.

I'd like to do a mass audit of my .list file at some point to make sure I'm 100% accurate with segments and waypoint names

That you have valid waypoints? Don't you know your user log file: http://travelmapping.net/logs/users/hoss6884.log
Everything looks fine for you. An example with errors.

[michih]

I’m sorry that I should have been clearer with my original question.  I understand I get credit for concurrencies regardless whether they are included in my file, but I would still like to be able to capture them if I don’t have them listed.  Same if a waypoint name changes - I know I still get credit but would like to have the most updated waypoint listed.

Got it I would also be interested in getting rid off alt labels from my user list file. It's all processed during the site update which generates the DB for the production server.

There is  python (standard, used by site update) and cpp (optional) code doing it: https://github.com/TravelMapping/DataProcessing/tree/master/siteupdate

I think that it should be this. Jim has a server and users can get space there. It's possible to clone hwy data, user data and the data processing repo so that you can set up your own instance to run a site update. It's mostly used by hwy data managers to make sure that Jim's site update won't fail with their modifications. I also use it to check that my latest list file changes are correct. And I can compare the log file stats to the one on the site.

You could try to get familar with the site update code and modify it to your purpose. You could output a log file or directly modify your list file or whatever.
Only yakra and Jim are currently familar with the code if you have any (more) detailed question.

[Jim]

This is something that came up quite a while ago in an old thread:

http://forum.travelmapping.net/index.php?topic=1827.msg4443#msg4443

I would like to add this feature when time permits.  Opening a GitHub Issue.

[oscar]

The part that would be most useful for me is detection of list file lines that are completely concurrent with others. In early CHM days, concurrences were not automatically detected, and so we had to enter them in our list files. That bulks up my list file, though I have manually removed many of the duplicate lines during jurisdiction-by-jurisdiction list entry cleanups.

[Jim]

The part that would be most useful for me is detection of list file lines that are completely concurrent with others. In early CHM days, concurrences were not automatically detected, and so we had to enter them in our list files. That bulks up my list file, though I have manually removed many of the duplicate lines during jurisdiction-by-jurisdiction list entry cleanups.

Noted in the GitHub Issue.

[Hoss6884]

Thanks, Jim!  I couldn't see the old thread you linked but read the GitHub issue.

This is something that came up quite a while ago in an old thread:

http://forum.travelmapping.net/index.php?topic=1827.msg4443#msg4443

I would like to add this feature when time permits.  Opening a GitHub Issue.

[yakra]

I understand I get credit for concurrencies regardless whether they are included in my file, but I would still like to be able to capture them if I don’t have them listed.

Is what you want to do get a list of concurrent segments that you didn't explicitly list in your .list file, but got credited for due to concurrency detection?
If you're a Unix or Mac person, you can download concurrencies.log, and from the command line in the directory where you save it, run:
grep 'augment for traveler hoss6884' concurrencies.log

concurrencies.log is mainly for development purposes, so the output won't be very concise, but at least it's something.

[Jim]

I understand I get credit for concurrencies regardless whether they are included in my file, but I would still like to be able to capture them if I don’t have them listed.

Is what you want to do get a list of concurrent segments that you didn't explicitly list in your .list file, but got credited for due to concurrency detection?
If you're a Unix or Mac person, you can download concurrencies.log, and from the command line in the directory where you save it, run:
grep 'augment for traveler hoss6884' concurrencies.log

concurrencies.log is mainly for development purposes, so the output won't be very concise, but at least it's something.

Yes, that would do it.  It can get a little overwhelming for longer concurrencies, though, since it marks every segment individually.