Modify

Opened 2 months ago

Closed 7 weeks ago

Last modified 7 weeks ago

#14929 closed enhancement (fixed)

Automatic filters on numeric tag values

Reported by: Don-vip Owned by: Don-vip
Priority: major Milestone: 17.06
Component: Core Version:
Keywords: sotmfr indoor mapping level layer maxspeed voltage Cc: bastiK, stoecker, Klumbumbus, michael2402

Description (last modified by 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 :)

Attachments (3)

autofilters.png (198.0 KB) - added by Don-vip 2 months ago.
prefs.png (7.5 KB) - added by Don-vip 2 months ago.
05.gif (3.7 MB) - added by Klumbumbus 7 weeks ago.

Change History (30)

Changed 2 months ago by Don-vip

Attachment: autofilters.png added

Changed 2 months ago by Don-vip

Attachment: prefs.png added

comment:1 Changed 2 months ago by Don-vip

Cc: bastiK stoecker Klumbumbus michael2402 added
Description: modified (diff)

comment:2 Changed 2 months ago by Don-vip

In 12389/josm:

see #14929 - extract OSDLabel from FilterTableModel

comment:3 Changed 2 months ago by Don-vip

In 12388/josm:

see #14929 - change signature of FilterWorker.clearFilterFlags

comment:4 Changed 2 months ago by Don-vip

In 12387/josm:

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

comment:5 Changed 2 months ago by Don-vip

In 12383/josm:

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

comment:6 Changed 2 months ago by Don-vip

In 12360/josm:

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

comment:7 Changed 2 months ago by 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?

comment:8 Changed 2 months ago by Don-vip

In 12400/josm:

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

comment:9 Changed 2 months ago by michael2402

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

comment:10 in reply to:  7 ; Changed 2 months ago by 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.

comment:11 in reply to:  10 ; Changed 2 months ago by 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.

comment:12 in reply to:  11 Changed 2 months ago by 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.

comment:13 in reply to:  11 ; Changed 2 months ago by 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.

comment:14 Changed 2 months ago by Don-vip

In 12401/josm:

see #14929 - fix NPE in unit tests

comment:15 Changed 2 months ago by Don-vip

In 12403/josm:

see #14929 - findbugs

comment:16 in reply to:  13 ; Changed 2 months ago by 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]+.

comment:17 in reply to:  16 Changed 2 months ago by 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.

comment:18 Changed 2 months ago by 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.

comment:19 in reply to:  18 Changed 2 months ago by 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.

comment:20 Changed 2 months ago by 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.

comment:21 Changed 2 months ago by 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)

comment:22 in reply to:  20 Changed 2 months ago by 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.

comment:23 Changed 2 months ago by Don-vip

In 12407/josm:

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

comment:24 Changed 8 weeks ago by Don-vip

Owner: changed from team to Don-vip
Status: newassigned

comment:25 Changed 7 weeks ago by Don-vip

In 12432/josm:

see #14929 - remember button pressed state

comment:26 Changed 7 weeks ago by Don-vip

Resolution: fixed
Status: assignedclosed

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

comment:27 in reply to:  26 Changed 7 weeks ago by 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.


Last edited 7 weeks ago by Klumbumbus (previous) (diff)

Changed 7 weeks ago by Klumbumbus

Attachment: 05.gif added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Don-vip.
as The resolution will be set. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.