Closed pfbreton-perso closed 2 weeks ago
It's a bit tricky but it's not that issue in fact: in the browser, when a feature as no name, its datalayer name is displayed instead, but the filtering is more generic and just try to match the feature name (or whatever the key registered as label).
I understand that this is disappointing, but I'm not exactly sure how uMap should behave here:
May be related to https://github.com/umap-project/umap/issues/2058
Thanks for your detailed reply!
I see now - I could reproduce the problem with different gpx files.
To your question, here is my take on your suggestions, if that helps:
make an exception and search on the datalayer name when the feature has no proper name
As a user, this the preferred solution. The way the UI is setup in uMap makes you think that this will actually be the case because it already makes an exception to display a "fake" feature name in the layer details panel.
There is no visual distinction in this panel between "real" names and "fake" feature names. So from a UX stand point you would think that the search/filtering would work on what you see in the list and not on a different representation of the data.
Describe the bug If the data contains characters such as - or _ which is commonly seen in recorded GPX files, the filter seems to fail.
To Reproduce Steps to reproduce the behavior: 1 - go to https://umap.openstreetmap.fr/en/map/rideshare-public_789193#7/46.115/-72.515 2- open the layers window 4- now, add 2023-07 --> the returned records don't match what is actually in the list.
For example, searching for "2024-06-29_07-48_Sat.gpx" does not return anything.
Expected behavior I was expecting to be able to search for strings like:
"2024-06-29_07-48_Sat.gpx" "2024-06-29" "2024-06" "_Sat"
Screenshots in this example, I have 5 items containing the string "2024-07". See before filtering:
after filtering, only two are returned:
Please find a recorded screen capture as well:
Desktop (please complete the following information):
Additional context This map contains uploaded GPX files that I collect through the years from recorded travels. I found this problem when trying to search for a precise trace, typically nammed automatically by OSMAND when saving them ex: "2024-07-01_08-37_Mon.gpx"