Sort nearmisspoints.log by region

[jteresco]

http://tm.teresco.org/forum/index.php?topic=335.msg6352#msg6352

[jteresco]

Related: allow a way to filter by region for NMPs in the log or the tm-master.nmp file.

[yakra]

Filtering tm-master.nmp by region is now live on site.

As far as nearmisspoints.log goes -- I can't speak to the workflow of others, but I only ever use that when looking for an entry to add to nmpfps.log. I'll already know what I'm looking for after having found it in an .nmp file, so I just search for a relevant text string. So for me personally I don't need nearmisspoints.log to be in any particular order.

Ping @rickmastfan67, your thoughts here?
@si404 @michihdeu @ovoss

[michihdeu]

http://forum.travelmapping.net/index.php?topic=335.msg11120#msg11120

Is it possible to combine all lines within the same "NMP area"? For instance, it would help if line 3, 5, 6 and 7 in the pic would be ordered subsequently and being indicated anyhow that it's the same NMP area. Maybe with another column and an index 1, 2, 3,...? Of course, the index should not be included in the FP entry..... Difficult.... Any suggestion?

[yakra]

http://forum.travelmapping.net/index.php?topic=335.msg11128#msg11128

Re: ordering of tm-master.nmp - I took a quick look and it's probably not too bad. Instead of writing each pair directly to the file when it's detected, I'd just put the pairs of lines into a big old list, sort them however we want them sorted, and then write the file. What sorting criteria makes the most sense?

Giving this some more thought. We're dealing (most directly?) with pairs of text strings, so ordering asciibetically seems the most immediately obvious, but I think that would be a Bad Thing. Suppose we have

me.i395@2 44.786742 -68.794096
me.me015@I-395(2) 44.786741 -68.794096
me.me015@I-395(2) 44.786741 -68.794096
me.us202@I-395(2) 44.786742 -68.794096

Sorting asciibetically, these entries could potentially be separated far apart in the .nmp file by many more entries involving lower-numbered usame routes.

One thing I like about how tm-master.nmp turns out now is how multiple NMP pairs at the same spot, usually involving multiplexes, are all clustered together in the file. If I search for "44.786741 -68.794096" or "44.786741 -68.794096" using Pluma, I'll see every occurrence of that string highlighted. Seeing it within a bunch of NMP pairs all in a row is super convenient.; I'll delete them all once they're fixed or marked as FP. For a good example, see http://yakra.teresco.org/nmp/ok.nmp
I think some kind of ordering by coords would be the way to go.

[yakra]

I have some changes in the pipeline that should result in deterministic ordering in nearmisspoints.log. From there, sorting by region should be easy.

[yakra]

^^ My response was a bit of a brain-fart: this issue is less about tm-master.nmp and more about nearmisspoints.log:

In the forum, @rickmastfan67 wrote:

is there anyway the log file itself can be sorted by region instead of being all over the place? Might make it easier to view while in txt format.

I'd like to keep tm-master.nmp ordered as-is. Its present "sort by quadtree node" method does a good job of clustering together NMPs in the same general area. Plus, nmpbyregion files are sorted by region. ;)

Sorting nearmisspoints.log by region makes sense.
@jteresco wrote:

Re: ordering of tm-master.nmp - I took a quick look and it's probably not too bad. Instead of writing each pair directly to the file when it's detected, I'd just put the pairs of lines into a big old list, sort them however we want them sorted, and then write the file. What sorting criteria makes the most sense?

Doing this with the single lines of nearmisspoints.log seems the simplest solution.
A straight asciibetical sort makes the most sense. That would take core of sorting by region and route, and be pretty readable.
It doesn't require big modifications. Going beyond that and into, say, sorting by CSV route order or waypoint order within routes, and we'd be starting to get more involved...

[yakra]

I think @michihdeu's comment is more in reference to tm-master.nmp and/or the HDX...
OK to close this?

[michihdeu]

sure

[yakra]

Done. Thanks.