this is something I was already thinking some time ago. In the end, I've prepared a little bit "overkill" solution (not for everyone) that may anyway allow very robust filtering.
So in the next big app version, points and tracks filters allow defining filter names over regular expressions.
If you are not familiar with this system, I'll gladly help here in this topic once version will be published, so let me know.
Hi,
this is something I was already thinking some time ago. In the end, I've prepared a little bit "overkill" solution (not for everyone) that may anyway allow very robust filtering.
So in the next big app version, points and tracks filters allow defining filter names over regular expressions.
If you are not familiar with this system, I'll gladly help here in this topic once version will be published, so let me know.
Hi Menion, in v4.8.2 there's a checkbox "Name as regex" so I expected the feature to be functional in that version. I ticked the box and tried with search term "Eing[aä]ng" (a correct pattern for the widespread RegEx-syntax http://www.w3.org/TR/xpath-functions/#regex-syntax) to find both flexions "Eingang" + "Eingänge" of the same basic word – more or less to simulate stemming. Sadly, no results 😕 I guess I must use another RegEx syntax like e.g. pearl, javascript, or scintilla, but neither this topic nor =filter#how_to_filter_points]https://docs.locusmap.eu/doku.php?id=manual:user_guide:points:management&s[]=filter#how_to_filter_points do tell which one. Could you please shed some light onto the syntax of Locus' regular expression engine? A link to the used engine will be best if it offers some documentation, because that also clarifies the feature set (which quantifiers, character classes etc are supported).
Second, any thoughts to extrend regex support from filtering to search, which is also working across all folders?
Best regards, Georg
Hi Menion, in v4.8.2 there's a checkbox "Name as regex" so I expected the feature to be functional in that version. I ticked the box and tried with search term "Eing[aä]ng" (a correct pattern for the widespread RegEx-syntax http://www.w3.org/TR/xpath-functions/#regex-syntax) to find both flexions "Eingang" + "Eingänge" of the same basic word – more or less to simulate stemming. Sadly, no results 😕 I guess I must use another RegEx syntax like e.g. pearl, javascript, or scintilla, but neither this topic nor =filter#how_to_filter_points]https://docs.locusmap.eu/doku.php?id=manual:user_guide:points:management&s[]=filter#how_to_filter_points do tell which one. Could you please shed some light onto the syntax of Locus' regular expression engine? A link to the used engine will be best if it offers some documentation, because that also clarifies the feature set (which quantifiers, character classes etc are supported).
Second, any thoughts to extrend regex support from filtering to search, which is also working across all folders?
I get filtering with RegEx running in Locus 4.10.0 🙂 By try & error I learned the syntax is very close to http://www.w3.org/TR/xpath-functions/#regex-syntax and http://www.w3.org/TR/xmlschema-2/#regexs Not only the original requested filter possibility but even much more sophisticated stuff is possible 👍 Some findings. @Menion, copying them to documentation as "info-box for geeks" probably makes the info easier to find while not irritating average users – what do you think?
group of alternative characters in square brackets: "cr[eê]pe" finds "crêpe" as well as lazy spelling "crepe" in one go, so we're quicker finding this great umami or sweet dish
character groups like backslash d (digits) or s (whitespaces [#x20\t\n\r]): "1h\d\d" finds all points naming a duration of one up to two hours in their name, so "1h15" is found while "2h10" not. @Menion: Is tracks filtering using the same logic and syntax as point filtering? That pattern worked for points but not tracks.
alternative sub-patterns AKA or operator by pipe: "du|des|de l" finds French preposition variations "du" or "des" or "de la" or "de l'<word starting with vovel>"
enforce a space: I want to find only French preposition "des" but not a substring of another, longer word like "normandes". That works by "[ ]des" and "\sdes" (\s equals the whitespaces [#x20\t\n\r]). I tried " des" and " {1}des" without success while they work in XPath, and it's also not exactly the same behavior as in XPath with active x flag because 2nd pattern does produce an error in XPath but not Locus – maybe it's catched under the hood, so it is thrown but just doesn't reach daylight/user.
ignore case: I tried "/cr[eê]pe/i" and "cr[eê]pe, i" to find both "Crepe" and "crepe" in one go, but both did not work, @Menion would be great if you could help here as the the working approaches "cr[eê]pe|Cr[eê]pe" and "[Cc]r[eê]pe" quickly become awkward to read and much more work to type on a mobile beacuse for each single character with uncertain upper/lower case, we must do something (doube the pattern or add a group)
Hopefully the RegEx feature will soon be re-used in search, because search works across folders and also inside descriptions, and in the other direction, the most recent used list of typed search terms becomes re-used in point filtering, because entering the special characters on a mobile with virtual keyboard is not really fun.
I get filtering with RegEx running in Locus 4.10.0 🙂 By try & error I learned the syntax is very close to http://www.w3.org/TR/xpath-functions/#regex-syntax and http://www.w3.org/TR/xmlschema-2/#regexs Not only the original requested filter possibility but even much more sophisticated stuff is possible 👍 Some findings. @Menion, copying them to documentation as "info-box for geeks" probably makes the info easier to find while not irritating average users – what do you think?
group of alternative characters in square brackets: "cr[eê]pe" finds "crêpe" as well as lazy spelling "crepe" in one go, so we're quicker finding this great umami or sweet dish
character groups like backslash d (digits) or s (whitespaces [#x20\t\n\r]): "1h\d\d" finds all points naming a duration of one up to two hours in their name, so "1h15" is found while "2h10" not. @Menion: Is tracks filtering using the same logic and syntax as point filtering? That pattern worked for points but not tracks.
alternative sub-patterns AKA or operator by pipe: "du|des|de l" finds French preposition variations "du" or "des" or "de la" or "de l'<word starting with vovel>"
enforce a space: I want to find only French preposition "des" but not a substring of another, longer word like "normandes". That works by "[ ]des" and "\sdes" (\s equals the whitespaces [#x20\t\n\r]). I tried " des" and " {1}des" without success while they work in XPath, and it's also not exactly the same behavior as in XPath with active x flag because 2nd pattern does produce an error in XPath but not Locus – maybe it's catched under the hood, so it is thrown but just doesn't reach daylight/user.
ignore case: I tried "/cr[eê]pe/i" and "cr[eê]pe, i" to find both "Crepe" and "crepe" in one go, but both did not work, @Menion would be great if you could help here as the the working approaches "cr[eê]pe|Cr[eê]pe" and "[Cc]r[eê]pe" quickly become awkward to read and much more work to type on a mobile beacuse for each single character with uncertain upper/lower case, we must do something (doube the pattern or add a group)
Hopefully the RegEx feature will soon be re-used in search, because search works across folders and also inside descriptions, and in the other direction, the most recent used list of typed search terms becomes re-used in point filtering, because entering the special characters on a mobile with virtual keyboard is not really fun.
thanks you use and test this nice geeky feature :).
Your tips: maybe useful to @Michal Stupka who takes care of our manual?
---
Problems
- the difference in "Track filter" > you are correct. There was a tiny difference I've overlooked. Will be fixed in the next app version.
- not working regexes: I may suggest very nice page I use for testing: https://regex101.com .
- case insensivity > as far as I know, you can't define '/i' parameter for the regex as you do, but I need to do it directly in the code. I think it make sense to ignore case for such searches. So I'll hardcode ' Pattern.CASE_INSENSITIVE' flag to the next version.
---
Regex used also in point/track searches sounds interesting, good idea. I'll definitely think about it.
Jiří M. aka Menion
Hello Georg,
thanks you use and test this nice geeky feature :).
Your tips: maybe useful to @Michal Stupka who takes care of our manual?
---
Problems
- the difference in "Track filter" > you are correct. There was a tiny difference I've overlooked. Will be fixed in the next app version.
- not working regexes: I may suggest very nice page I use for testing: https://regex101.com .
- case insensivity > as far as I know, you can't define '/i' parameter for the regex as you do, but I need to do it directly in the code. I think it make sense to ignore case for such searches. So I'll hardcode ' Pattern.CASE_INSENSITIVE' flag to the next version.
---
Regex used also in point/track searches sounds interesting, good idea. I'll definitely think about it.
v4.11.0 came today to my device and my questions are solved: RegEx work in tracks, and RegEx are case-insensitive making them much more convenient. Thank you, Menion 🙂 BTW, regex101.com looks quite helpful at first glance!
v4.11.0 came today to my device and my questions are solved: RegEx work in tracks, and RegEx are case-insensitive making them much more convenient. Thank you, Menion 🙂 BTW, regex101.com looks quite helpful at first glance!
I like this idea 
Hi,
this is something I was already thinking some time ago. In the end, I've prepared a little bit "overkill" solution (not for everyone) that may anyway allow very robust filtering.
So in the next big app version, points and tracks filters allow defining filter names over regular expressions.
If you are not familiar with this system, I'll gladly help here in this topic once version will be published, so let me know.
Hi,
this is something I was already thinking some time ago. In the end, I've prepared a little bit "overkill" solution (not for everyone) that may anyway allow very robust filtering.
So in the next big app version, points and tracks filters allow defining filter names over regular expressions.
If you are not familiar with this system, I'll gladly help here in this topic once version will be published, so let me know.
Replies have been locked on this page!