Online search

[T-mo]

@T-mo what search are you referring to? Both in category (POI highlighting) search and text search you should be able to put list and map 50:50 to screen, while only in category search the list is by default collapsed down.

I currently only test category-search as this will be my preferred search with Locus.

@50:50:
you're right, could swear it has been different during my tests.
That is okay. Personally I am not of fan of too much changing map-area-size, result-list vs poi-details, as this is destroying the impression of an information-overlay as layer on top, floating above the map, but a matter of gusto.

@search:
When searching for food&drinks and move around the map I also get symbols for schools, sport pitches, dentist..hitting those additional items I get poi-details without back-to-search-arrow, this is only available with search-related POIs.
Well, all those icons are not of interest too me but still on the map and in dense areas even complicate Poi-selection.
In GMaps I often check the surrounding while searching..in Locus I get a constant map-changing-experience due to autoload. There will be situation where you might need to refind an favoured POI

Some POI have names like a sub-category, 'bar, pub', but I guess these is due to the quality of the OSM-dataset which gets used as base. But as said, I currently test ui and category-search - dataset and quality of results somewhere in future.

[Andrew Heard]

Strange, this shouldn't happen. We will check this. Can you please write what did you exactly search and what was your initial map position before the search?

I had detailed instructions when 1st reported https://forum.locusmap.eu/index.php?topic=8436.msg71742#msg71742 but can no longer reproduce it myself sorry ;-( Maybe it was the previous beta version. I was in Dingle, Ireland. Even now for the "bar" example many more icons are displayed compared to a week ago - is this possible?

A repeat of another suggestion (see screen capture) - when the map is hovered over an online search POI, could there be a popup with details, and/or the list is scrolled to show that item?You cannot view this attachment.

[Andrew Heard]

PS. 4.17.1 location Croagh, Ireland, although I don't think this is relevant. 1st run of new version & 1st online search - tap "bar" in list = map zoomed out ruler = 300km - 1st screen shot. BTW I tap zoom+ to commence zooming back in (after annoyance) & LM4 crashes (although can't reproduce)! 2nd online search - tap "bar" = one POI near the current position is CORRECTLY displayed & map is NOT zoomed - 2nd screen shot. Observe the 3rd screen shot has top panel. So, apart from the crash, this sounds like a timing glitch to me - you said a zoom-out only occurs if no results - it seems in 1st search the asynchronous results didn't arrive in time. And I can now reproduce each scenario approx. 50/50.

[T-mo]

@Andrew Heard:
yes, results with typed 'bar' is very annoying. Results are way off. And sometimes you carefully moved the map to a specific position without having some saved points over there, and want to search around - whoosh, gone.

Seems like the filter-chain is not yet optimised. 1st check against special terms or well known keywords that user might also use, 2nd check around close range distances or screen-border plus extra (district, town, region, whatever), etc., sort of. Might get sophisticated. This might be an iterative process and might require user-interaction, at least if you target perfect results (because you are lacking hardware for detecting brainwaves), to limit results or check multiple subsets. Just a thought.

I secretly visited Google.com, Wikipedia.org and linguee.com, please do not tell.
They put a magnifying glass-symbol NEXT to the searchbar. Maybe it's because you can get there with different devices, e.g. Desktop-PC, maybe not.

[Andrew Heard]

just to be clear(er)
1st LM run with search: massive zoom out
restart & 2nd LM run with search: no zoom out
some timing glitch obtaining online search results?

[Jan Čapek]

I see, there are some confusions in overlapping category highlighting and text search. It is true, that latter is currently unusable to do searches for "bar" etc. as it search only in name of the POI or address, where category name is not usually present. That is why you get that distant results.

Basically the idea is:
1) you want to find some bar - use category highlighting - write "bar" and tap the category in suggestion list.
2) you want to find specific bar and know its name - write down its name without "bar" and hit magnifying glass.
We already have in mind some changes which makes this more intuitive.

@Andrew Heard we found the issue for zooming out during text search - it will be fixed, so the map move will always follow only nearest result.

@T-mo we will try to address issue leading to "loosing" the search when accidentally tap or long-press to something else with some tweaks.

A filter could be introduced to limit searches to a radius of x kilometers.
We thus avoid useless occurrences of results that are too distant both on the map and in the list.

But isn't "search this area" exactly this? Or do you missing it even for category highlighting?

[Radim V]

@Andrew Heard
- There is some change: The first result in the list one gets when types a term and hits "find", is the nearest one. There will still be map view change as this cannot be done server-side, only in new app version. But drastic changes (thousand miles away zoom&pan) should only happen sometimes, if there is no nearby result. Anyway there is (now) no sort based on distance entirely.   
- "Glitches", or "Timing issue": This indeed looks like some async programming error but it is unfortunately not that simple. The reason is: For < 1% of the questions (queries) one of the engines is not performant enough. (Think too many disk reads as opposed to fast memory reads). Once there is a migration to some other solution, this should be solved.   

[lor74cas]

But isn't "search this area" exactly this? Or do you missing it even for category highlighting?

I usually use a zoom that allows me to see a very small area on the screen because I prefer to see the details.
So when I do a search as the area is small I get few results as they depend on the zoom. I would prefer to set up the search with a filter of, for example, a fixed radius of 5 km. So I would always have the list of found items regardless of zoom.
Or
You could show on the map the elements found that obviously fit on the screen, but also list those that don't fit in order of distance.
So if in the list I see what I was looking for that is outside the on-screen map, I can click on it without having to zoom out on the map and be directly centered to that point

[freischneider]

When I search for water, a list of POIs is displayed at the bottom. Only the name is present in the list. It would be helpful if behind the name, the distance to the current map center is displayed. Possibly a direction arrow. At the moment I have to click on each result to get this information.

[T-mo]

IMHO the current updated experience is really way better. Results to typed searches are a lot faster, before the blue circle was rotating and nothing happened (I even missed the magnifying glass in my focussed eye-catching area and thought 'what now?')..after a long while those far distant results appeared - now I get immediate results and even good related suggestions like categories.

See images attached, I searched for a franchise, there are several around.
IMHO the auto-results are not very helpful as very similar and hitting the search to get to the map results are different but okayyyy as I see the map and can choose, but there is a Munich entry - well that is 500km away..
I still cannot collapse the keyboard as the 3 buttons are hidden, I have to swipe from top to bring them in and then can collapse keyboard and see all entries.

[michaelbechtold]

Using online search a little bit and thinking about it a bit more, this is my summary:
- Google data repository is unmatched, beating Locus and any other searches hands down, whatever they try, for years to come
- Locus, for strategic reasons, also with iOS support in mind needs this independent online search
- on Android the Google API search is at no cost to Asamm, as Menion stated
- combining both searches technically seems not feasible, as per Menion's response
- to me, the obvious approach is
-- to have a Locus Search for Android and iOS alike
-- put a Google Search as separate function into the Android version

That would stop any need for tough comparisons and discussions, a d empower users to make their own choice, based on their needs.
Giving USERS a choice may not be a technician's first emotional approach, but is beneficial for all parties in the end.

And above approach would not add complexity to the UI a d user experience.

Hope is the last thing to die ;-)

Cheers
Michael

[Radim V]

Using online search a little bit and thinking about it a bit more, this is my summary:
- Google data repository is unmatched, beating Locus and any other searches hands down, whatever they try, for years to come
- Locus, for strategic reasons, also with iOS support in mind needs this independent online search
- on Android the Google API search is at no cost to Asamm, as Menion stated
- combining both searches technically seems not feasible, as per Menion's response
- to me, the obvious approach is
-- to have a Locus Search for Android and iOS alike
-- put a Google Search as separate function into the Android version

That would stop any need for tough comparisons and discussions, a d empower users to make their own choice, based on their needs.
Giving USERS a choice may not be a technician's first emotional approach, but is beneficial for all parties in the end.

And above approach would not add complexity to the UI a d user experience.

Hope is the last thing to die ;-)

Cheers
Michael

Hi Michael, just a few notes. Of course I agree Google (and few others big boys too) are rather impossible to match. But the current state of what we have in terms of "data repository", as you put it, is just the first step really. In terms of quantity of data it is easy to add dozens of millions of items by mining the OSM dataset. That is a matter of configuration and will be done. (Not all at once). Accuracy outside well mapped areas is not so great, sadly, as we know. Better search engine is hard but doable of course, that is just a lot of work again - these real world data use cases are not typically solved by technology providers. There is also tons of work making all this machinery to update data and talk to other pieces of machinery. But I don't see an easier way how to put together a consistent, world wide dataset of places and "points of interest" relevant to hike bike context. Of course G will find you the nearest "laundromat" way better than L. But how would you search for the nearest fire pits (worldwide). Of course there are some datasets available but maintaining all this together is a hell we (I) don't want to enter. I am an expert in the osm inconsistencies and weaknesses but IMHO this dataset is really needed here.

[T-mo]

@Radim V:
I interpret Michael's post as feedback of his current user experience.
Of course a server side database and search- and filter- tool-chain needs it's time to be developed and to mature, and building such an online-search is a bigger project.
Though user-input- and display-framework is a another thing.
I guess Michael prefers the choice within L to also profit of G-API and G-results, app-side. That would be a 2nd block/path behind the scene which might already be available and not active.

[michaelbechtold]

Yes, t-mo, I'm talking about an INCLUSIVE AND.
Yet, not behind the scenes, as this would violate the new Locus search architecture (or at least would complicate things), and on iOS this even might be impossible (I cannot judge here).
This is the reason I propose to follow the path Radim and Menion et.al have described and are going. BUT leave the Google API based search as a separate feature (with its own name), on Android.
As I pointed out earlier, OSM is not anywhere near a reliable or complete model of the world, even for hike/bike aspects, in particular for countries outside CZ/SK/AT/D scope.
BTW: even Bikers appreciate a laundromat from time to time :-)
Again, this is NOT playing one against the other, but COMBINING the strengths of both data sets in a minimal effort way.
Cheers
Michael
PS: there is a difference between Google Maps mobile data hunger and a (Google) API call size in bytes - orders of magnitude. Proven just today, in the middle of Germany.

[Andrew Heard]

Another example of inconsistent online search . Screen caps from the web planner but identical results in LM4.

Search for "Lower Crescent, Belfast, Ireland" - the closest Belfast result in 1.3km away although unrelated to "Lower Crescent". Note I had positioned map to show Lower Crescent only a few metres away. Why not sorted by distance? Also note LM4 displays the distance but not the web planner.
You cannot view this attachment.

BUT the important point, search for "Lower Crs - now the correct results are displayed, but still not at the top of the list given they are the closest, and the "best match".
You cannot view this attachment.

Results displayed as "Crescent" but actually best to search for the abbreviation "Crs".
My Locus online searching experience is often a real hard battle ;-(