improve autocompletion (by frequentness, object type, ...)

[sanderd17]

I've given the change from #10687 some time, but I can't get used to it because of the unexpected behaviour sometimes.

F.e., I often draw new higways (mostly driveways and tracks). I do this with the following keys that are kind of programmed in my fingers: ALT+A > "hi" > TAB > "ser" > ENTER. This worked before, and still works in 90% of the cases. However, it also happens that I tag something historic (a mill or memorial f.e.). But when I tag the next highway, I consistently end up with a tag "historic=service".

So I either have to learn to type "hig" for "highway" instead of just "hi", or I have to learn to check every proposal before I hit tab or enter. Both make the process slower. The same happens between "name" and "natural", or "lanes" and "landuse", or sometimes with values, s.a. "track" and "traffic_signals".

As a first improvement to this behaviour, I'd suggest to give a score to every tag, based on how often you use it. Since I use highway more than historic, the highway key would have a bigger score, and be the default one.

A second improvement could be to let the score from above degrade with time. F.e. I might be interested in mapping landuse for a period of time, and then turn my attention to lanes. When the score degrades with time (via a fast formula, f.e. half the existing score every session), the default would change from landuse to lanes after a few sessions.

A different improvement might be to also consider the OSM datatype. When I tag highway=traffic_signals, I always do that on nodes, while highway=track always happens on a way element. So different suggestions could be given to different datatypes. This doesn't always work though, as f.e. lanes and landuse are both mostly tagged on way types.

Thanks for giving this a thought.

[Klumbumbus]

Replying to sanderd17:

the change from #10812

Do you mean r7725?

[sanderd17]

Sorry, I meant #10687 with r7680 and r7681. Those introduced it as the default. (Seems I got the wrong number on my clipboard).

[Klumbumbus]

I don't think that #10687 has much to do with that what you describe. #10687 is only about restart. Autocompletion was changed in r7725.

[skyper]

Second this request for some improvement/options how auto completion works.

[mdk]

Looks similar to #8721.

[bastiK]

Ticket #8721 has been marked as a duplicate of this ticket.

[bastiK]

As Klumbumbus said, the problems you describe are completely unrelated to #10687, r7680 and r7681. What's affecting your workflow is r7725.

Yes, one should make it dependent on the datatype, this would improve the situation somewhat.

To count the frequency of use is also an interesting idea, but I'm not entirely sure at the moment, how this should be done.

One would certainly need to save the usage data across sessions (currently it is discarded when you close JOSM). This may become a little too much for preferences.xml.

Then the question is how to assign a score to a key or tag value? One option would be to record the last 1000 entered tags in order and then count the number of occurrences in this list. (And maybe apply a weight factor.)

[mdk]

Replying to bastiK:

To count the frequency of use is also an interesting idea, but I'm not entirely sure at the moment, how this should be done.

One would certainly need to save the usage data across sessions (currently it is discarded when you close JOSM). This may become a little too much for preferences.xml.

I would be sure, that I only add a few hundred keys the last years. I think a normal mapper will only focus on a few keys.

To be more clear: count only keys, not the values. Count only newly added keys, not modified or deleted keys. So JOSM will learn quiet fast which keys a mapper normally use. When a user adds a new key, I think preferring keys he normally uses instead of keys other mappers are using, will help the actual user a much.

[skyper]

Ticket #6521 has been marked as a duplicate of this ticket.

[skyper]

One most annoying thing is that autocompletion does not stop at key separators like underscore and colon.

[mdk]

In my opinion the actual situation is much better. Autocomplete now “learns” which keys (and values?) are normally used by the mapper. Is it a MRU cache of newly added tags? The details doesn't matter, since it helps me choosing the wanted key in a fast (and predictive) way.

The actual problem for me is, that JOSM forget all these information when I restart. And it's annoying to “train” the mechanism each time new.

Wasn't it be possible to save the “learned” data and reload it at next startup? Perhaps we could only save the last 100 or 1000 entered keys, so that we forget about typos and uncommon tags?

[mdk]

Actualy JOSM persists the list in the properties file (in my case 60 entries). But infact there are only 30, because they are organised as pairs: key1, value1, key2, value2, ...
Autocompletion still uses this list. When you reuse a key=value, it is moved up to the first place. For me this is working and we could close this issue.

Only one thing is not really perfect: If you add 30 tags like different addr:housenumber the list loose all other entries and is "empty" again.