Automatic filters on numeric tag values

[Don-vip]

During last SOTM-FR there were several interesting talks about indoor mapping and the applications around it.

It was clear indoor mapping with JOSM has room for improvement. Although there's ​indoorhelper plugin, indoor mappers usually have to define a lot of filters and the task is not easy.

Looking at the existing applications such as ​openLevelUp! I had an idea about an automatic way to use filters, as follows:

The feature is generic and preconfigured for the following numeric tags:

• level (by default)
• layer
• maxspeed
• voltage

This is extensible by plugins, the tags are only analyzed at high zoom levels to reduce the performance penalty, and the color is customizable.

Only one tag at a time, which can be chosen in preferences:

It seems to behave well on the areas I tested (mainly Paris), all feedback welcome :)

[Don-vip]

In 12389/josm:

see #14929 - extract OSDLabel from FilterTableModel

[Don-vip]

In 12388/josm:

see #14929 - change signature of FilterWorker.clearFilterFlags

[Don-vip]

In 12387/josm:

see #14929 - filter dialog: invalidate only edit layer instead of repainting the whole mapview

[Don-vip]

In 12383/josm:

see #14929 - new methods to ease the direct handling of filters

[Don-vip]

In 12360/josm:

see #14929 - filter dialog: invalidate only edit layer instead of repainting the whole mapview

[stoecker]

Some things:

• Why restrict it to numeric values?
• Why handle it in main prefs and not in the filter dialog, where users will search it.
• Why only one tag?

[Don-vip]

In 12400/josm:

see #14929 - Automatic filters on numeric tag values (level, layer, maxspeed, voltage)

[michael2402]

I'd place the layer selection next to the filter-message, best would be inside the filter bubble.

[Don-vip]

Replying to stoecker:

• Why restrict it to numeric values?

The two tags where I find this feature the more useful are numeric (level and layer). And that's understable: with numeric values we can have dozens of different values at a single place, and we need to define as many filters.

• Why handle it in main prefs and not in the filter dialog, where users will search it.

I didn't find an ideal place for the preferences. The idea is to offer the power of filters without the need to use the filter dialog. But you're right it could be useful also to have a direct access from the filter dialog.

• Why only one tag?

The design is simpler this way, and the UI not too loaded (a single line of buttons). If there's demand to have several tags at the same time I can revisit the approach, it should not have any additional performance cost.

[michael2402]

Replying to Don-vip:

The idea is to offer the power of filters without the need to use the filter dialog.

I did some changes to the visibility menu of the layer panel to add the GPX color there (basic draw mode presets for heat map / velocity and nicer buttons coming the next days). I want to keep it light, so I removed the color filter sliders for non-imagery layers.

OSM data layers have no setting at the moment. We could add the quick filter there. I prefer a single dropdown with a none-entry, layouted like the slider and with a nice, newly-to-design level icon next to it. Or alternatively radio buttons to avoid having a dropdown in a dropdown dialog. Then we should not provide filtering for voltage/maxspeed there, since I consider it to be an expert action. And the settings there are typically per-layer.

I see an alternative approach to making it universal for experts: We add an option to each filter to make it selectable in the main panel. The user can select a short description (a few characters) of the filter. We then display those buttons for the filter instead of the level buttons. But this is way too complicated for beginners and I don't know if it makes life for experts much easier than just toggling the filters in the filter dialog.

[Don-vip]

Replying to michael2402:

OSM data layers have no setting at the moment. We could add the quick filter there. I prefer a single dropdown with a none-entry, layouted like the slider and with a nice, newly-to-design level icon next to it.

Good idea!

Then we should not provide filtering for voltage/maxspeed there, since I consider it to be an expert action. And the settings there are typically per-layer.

We can simply display these options in expert mode only.

I see an alternative approach to making it universal for experts: We add an option to each filter to make it selectable in the main panel. The user can select a short description (a few characters) of the filter. We then display those buttons for the filter instead of the level buttons. But this is way too complicated for beginners and I don't know if it makes life for experts much easier than just toggling the filters in the filter dialog.

I'm not sure to fully understand what you have in mind here, but it would be useful to let users define their own automatic filters from the filter dialog.

[bastiK]

Replying to michael2402:

I see an alternative approach to making it universal for experts: We add an option to each filter to make it selectable in the main panel. The user can select a short description (a few characters) of the filter. We then display those buttons for the filter instead of the level buttons. But this is way too complicated for beginners and I don't know if it makes life for experts much easier than just toggling the filters in the filter dialog.

This feels like a natural place, a filter entry with special syntax that gives rise to a GUI-selection on the map: layer={3|2|1|0|-1|-2}.
Only, if it is supposed to make filters easier and more accessible, then this defeats the purpose. Maybe in combination with pre-defined filter-presets or as "behind the scenes" implementation.

[Don-vip]

In 12401/josm:

see #14929 - fix NPE in unit tests

[Don-vip]

In 12403/josm:

see #14929 - findbugs

[Don-vip]

Replying to bastiK:

This feels like a natural place, a filter entry with special syntax that gives rise to a GUI-selection on the map: layer={3|2|1|0|-1|-2}.
Only, if it is supposed to make filters easier and more accessible, then this defeats the purpose. Maybe in combination with pre-defined filter-presets or as "behind the scenes" implementation.

The GUI is meant to be easier and accessible to beginners, but using the filter dialog as backend sounds definitively the way to go. Maybe something with a regex like level=-?[0-9]+.

[michael2402]

Replying to Don-vip:

Replying to bastiK:

This feels like a natural place, a filter entry with special syntax that gives rise to a GUI-selection on the map: layer={3|2|1|0|-1|-2}.
Only, if it is supposed to make filters easier and more accessible, then this defeats the purpose. Maybe in combination with pre-defined filter-presets or as "behind the scenes" implementation.

The GUI is meant to be easier and accessible to beginners, but using the filter dialog as backend sounds definitively the way to go. Maybe something with a regex like level=-?[0-9]+.

I want to see you parsing the regex for all possible values :D.

I thought of a more complex UI to input all possible values, a table something like:

Short	Filter
U	level=-1 | level=-2
0	level=0
1	level=1
2	level=2
3+	level=3 | level=4 | level=5

The first column will be displayed to the user in the map view to switch filters.
We can easily support this for multiple filters at the same time.

[stoecker]

Why define the values at all? We already have knowledge of all possible used values in the current dataset. And the filter only needs to handle currently possible values. I think we only need to define the keys.

[bastiK]

Replying to stoecker:

Why define the values at all? We already have knowledge of all possible used values in the current dataset. And the filter only needs to handle currently possible values. I think we only need to define the keys.

It will be strange if the selection changes with each loaded dataset and we will need more complicated queries than key=value for sure.

[Tordanik]

I'm not sure if this generic approach works for use cases such as indoor mapping. When editing level 3, for example, you do not only want objects with the level=3 tag, but also objects tagged level=2;3 or level=1-4, or even repeat_on=3;4. Other numeric tags will likely have their own specific conventions, e.g. the presence of units for maxspeed.

[Klumbumbus]

little bug:

1. press e.g. turqoise layer=-1 button
2. move mapview away so the turqoise layer=-1 button disappears
3. move mapview back
4. while the filter is still active, the turqoise layer=-1 button is unpressed
5. you need to press the turqoise layer=-1 button twice to disable its filter

(r12403)

[Don-vip]

Replying to Tordanik:

I'm not sure if this generic approach works for use cases such as indoor mapping. When editing level 3, for example, you do not only want objects with the level=3 tag, but also objects tagged level=2;3 or level=1-4, or even repeat_on=3;4. Other numeric tags will likely have their own specific conventions, e.g. the presence of units for maxspeed.

Yes it does, the values are preprocessed. level=2;3 and speed units (mph) are already taken into account, I can add easily the level=1-4 range.

[Don-vip]

In 12407/josm:

see #14929 - add support for numeric ranges + unit test

[Don-vip]

In 12432/josm:

see #14929 - remember button pressed state

[Don-vip]

Initial implementation is done for this release. #14965 created to track further enhancements.

[Klumbumbus]

Replying to Don-vip:

Initial implementation is done for this release.

deactivating an filter still doesn't work properly. After moving mapview away and back you need to press the button twice to disable it. It looks like if there are 3 states of the button: light, dark and even darker.