SearchCompiler: regexp comparison using <tilde>

[simon04]

This increases (mental) interoperability with MapCSS and Overpass QL. Also required for #18164

Example: highway~primary|secondary

[simon04]

In 16260/josm:

fix #19070 - SearchCompiler: regexp comparison using <tilde>

[simon04]

Updated search dialog:

[GerdP]

What about the "regular expression" checkbox in the lower left corner?

[GerdP]

See also #15943

[simon04]

The regular expression mode not only affects key=value queries, but is used for other types as well, see org.openstreetmap.josm.data.osm.search.SearchCompiler#parseFactor()

Since search expressions are also used for user-defined filters, dropping this radio button element sounds like pain to me.

[GerdP]

Replying to simon04:

The regular expression mode not only affects key=value queries, but is used for other types as well, see org.openstreetmap.josm.data.osm.search.SearchCompiler#parseFactor()

I just wondered what happens when you enable the button AND use e.g. highway~trunk.*

Since search expressions are also used for user-defined filters, dropping this radio button element sounds like pain to me.

+1

BTW: The regex search works a bit strange, no matter which version I use.
highway~trunk finds highway=trunk, but not highway=trunk_link
With highway~trunk.* finds both

When I just search for trunk with "standard Search syntax" enabled I also find both, but also other stuff like highway:historic=trunk or name=Strunk

The search for pattern highway~^trunk.* doesn't seem to work. I have to use quotes: highway~"^trunk.*"

[simon04]

Replying to GerdP:

I just wondered what happens when you enable the button AND use e.g. highway~trunk.*

The radio button is not taken into account when using highway~trunk

highway~trunk finds highway=trunk, but not highway=trunk_link
With highway~trunk.* finds both

The patch is performed using matches() (in contrast to find()) – thus the whole string has to be matched against the given regexp. For details see org.openstreetmap.josm.data.osm.search.SearchCompiler.ExactKeyValue#match

[GerdP]

I didn't try to understand the details of the code in SearchCompiler, else I would already have tried to fix #15943.
Looking at your changes in r16260 we probably just have to remove one line?

src/org/openstreetmap/josm/gui/dialogs/SearchDialog.java

@@ -291 +291 @@
                 .addKeyword("-<i>key</i>:<i>valuefragment</i>", null, tr("''valuefragment'' nowhere in ''key''")),
                 GBC.eol());
         hintPanel.add(new SearchKeywordRow(hcbSearchString)
-                .addKeyword("<i>key</i>", null, tr("matches if ''key'' exists"))
                 .addKeyword("<i>key</i>=<i>value</i>", null, tr("''key'' with exactly ''value''"))
                 .addKeyword("<i>key</i>~<i>regexp</i>", null, tr("value of ''key'' matching the regular expression ''regexp''"))
                 .addKeyword("<i>key</i>=*", null, tr("''key'' with any value"))

[simon04]

Replying to GerdP:

I didn't try to understand the details of the code in SearchCompiler, else I would already have tried to fix #15943.

Let's continue the discussion in #15943 (since it's not related to this ticket).

[Klumbumbus]

Milestone renamed

[gaben]

Replying to GerdP:

The search for pattern highway~^trunk.* doesn't seem to work. I have to use quotes: highway~"^trunk.*"

I searched for peaks with elevation in name. The name:"\\.*\\d+ *m" query works but name~"\\.*\\d+ *m" not. According to the help in the search window tilde should work (key~regexp). Is this intended?

JOSM 16392, regex mode enabled.

[simon04]

• You should compare foo=bar to foo~bar – foo:bar is different as it searches for substrings
• For matching an arbitrary string you'd use .* (without escaping)

Thus, name~"\\.*\\d+ *m" not matching name=Peak 3000 m is correct (since \\.* matches an arbitrary number of dots).

Note: name:"\\.*\\d+ *m" matches since it searches for substrings – the substring 3000 m matches

[gaben]

@simon04: Ah got it. That escaping confused me. Thanks for the explanation!