Locus Map - forum

Hi guys, I am glad to introduce our new version of online search system. It consists of two main sections:

1. Suggestions

• Provides 4 main types of suggestions (Historical searches, Categories, Pois and Places)
• Historical searches are available for both logged in and not logged in users and each item can be deleted by trash icon.
• Click on category navigates to Results above map section.
• If user is not satisfied with suggestions and exact term is already typed, pressing search icon on keyboard navigates also to Results above map.

2. Results above map

• Shows items from previously selected category or results by exact term.
• In case of category, results are reloaded automatically by map movement, otherwise Search this area button is available.
• First visible item in result list is highlighted on map.

Regarding implementation - tree of four "segments" are in house built from scratch, and can be somehow "fixed", or "adjusted". These are history, category, point of interest. Category search is based on language specific dictionaries written by some of the Locus community translators. (Thanks again!). These can also be adjusted or even build for new languages - currently EN, DE, CS, PL, IT is supported, other languages just work in the very bare bone sense. For places (towns, cities, villages, admin. boundaries, streets, street numbers), some third party service is used. There is rather slim chance we can "fix" it, unfortunately.

New online search is available from version 4.16.0.2 (http://bit.ly/lmVersionsTest). Thank you in advance for all feedback!

First thoughts about the search. It's a good approach.

1. Preferable for the average user base.
2. The offline db based search screams for the same unification? I'd really love it.
3. Problem. Entered a street name. First few letters typed it was good priorities, closest town street appeared, but after more letters similar streets from more important cities appeared and the street here in close vicinity wasn't listed any more.
4. Some Icons are just too small for this type of dialoue - peaks
5. The Hamburger Menu is every time shaking, if I use another search. Not just one time in order to take notice
6. Screenshot. That screen can be removed. It was some approach of Menion to make offline search easier. But people who use it don't need that. It's somewhat disturbing the ui flow. I always go back as a first step there
7. Results, presentation on map... it's special 😁 Will need more testing first before I comment.

If I pick a category like "Shelter", it displays other categories like peaks, as dots. But I didn't ask for those. Their color permanently changes while moving map.

Oh, I notice a disadvantage: there is no possibility to browse POI categories hierarchically.

When searching for a POI, e.g. a bank, the online search is sorting the results according to my current location, not according to the cursor's position. This makes it impossible to search something in a distant place.

I tried to reproduce the cursor vs GPS location problem. Currently I am in Prague, but my cursor is near Pilsen. See the screenshots. If I search for "Shell", all top results are situated around Pilsen. This is expected and in accordance with the logic: In case that map window is available, use it, otherwise use the fallback to GPS location. 

Hi guys, new version 4.16.0.3 has been released with some fixes and improvements. Thank you for feedback!

@Tapio
2. It is definitely not the end of search rework. 🙂
3. For places third party service is used, so we don't have full control over it.
5. Yes, it was shaking for years, so we disabled animation.
(8.) if you are zoomed enough and all points from the selected category are already displayed, we show also points from another categories. There is the same solution on web.
(9.) Should be discussed next weeks.

Hello Radim,

concerning the cursor vs. GPS Position issue: I found out the "problem" was on my side:

Sometimes the online search shows up two similar "latest search" results (see screenshot). One is with location, one without.

Maybe yesterday I clicked on the wrong one with "Vienna" while my cursor was somewhere 100 km away.

So --> sorry, my fault.

But still there is an other faulty behaviour: When I search for "Supermarkt" in a distant place, I get a supermarket around the cursor position in Austria, then one far away in Germany, then one in Austria, then one in Germany :)

See video: https://1drv.ms/v/s!AredTfs4J1f5gvAIW6FgiDlbWVMfcQ

I'm finding similar - tried online address search for "laundromat" in Ireland but the closest points start 1,000km away in Denmark! A Google Maps search correctly finds a point 1km away.

Quote from: Marek Scholtz on May 09, 2023, 16:36:43(8.) if you are zoomed enough and all points from the selected category are already displayed, we show also points from another categories. There is the same solution on web.

But I didn't ask Locus to show something else... IMO that makes no sense in a search context.
And tapping those points (without without really knowing what they are) makes the search results disappear.

Speaking of "making sense" - sometimes the whole bottom window is just not useful. Of course depends on the results, but maybe you can add something useful, like distance, idk... Screenshot related.

Will you unify the offline LoPoints system as well at some point?

A problem: see screenshot, if I tap on the parking icons on map one by one, then accidentally miss one and tap beside it, the search is gone.

Tried online search, with disappointing experience, when it comes to results.
Reason: the Locus object repository is way too weak.
Do we have to use Google Maps first, then transfer the results to Locus?
Or did I miss a magic configuration option?

When entering street names, some kind of auto completion is needed. If we know street and no. of house it's cumbersome to enter.

Yes it's tragic, search system will be compared with Google Maps 😁

Also I was thinking it's not perfect to add every searched item to the history entries. A more user organised approach is missing.

The search we Locus had so far allowed to select the search engine. There should be no step back from that.
In fact, there should be what the Locus search team built so far PLUS the search engine selection (only active when internet connection exists).
Such combines the strengths of the existing with the new functionality.

I think the new search function is a big improvement. I always grieved about the loss of GooglePlaces search, but with this solution it's quite comfortable to search for bakeries and stuff.

Quote from: TapioBut I didn't ask Locus to show something else... IMO that makes no sense in a search context.
And tapping those points (without without really knowing what they are) makes the search results disappear.

Speaking of "making sense" - sometimes the whole bottom window is just not useful. Of course depends on the results, but maybe you can add something useful, like distance, idk... Screenshot related.

I'm using Search more & more while cycle touring, now not crashing, and agree 110% with @tapio.

First of all the most important point:

New search is a great step forward. It's much, much better than it was in the past.
Looks like Locus search is usable for me. First time since I joined Locus years ago.
Many Thanks.

No pun intended, but am I missing the point here... from Ireland, Killarney (probably any place will do) - main menu > LoPoints(offline) > toilets > many to be found - correct.

Now new Search > Offline places > the nearest is 7km away - stupid, and if there is trailing space character in search text then there are no results!

@Andrew Heard, @luce: There is an important distinction: Places named "supermarkt", "laundromat" and places that actually are a supermarket or a laundry room.
 - As some of you pointed out, Locus "object repository" does not contain laundromat as a place for washing clothes. The notion of points of interest in Locus so far has been: Laundromats are not that important in the hiking/biking context. I am not overly concerned about missing "objects" - points of interest. A few millions of poi can be added quite easily. Why there are still some - we combine results from our service and some third party service, which is inconsistent, sure we know it.
 - What you do in the video: You search for places named like "supermarkt". It is the name which is important here. Not what it really is.
 - Try to type "shop", "super", "gas", "petrol", "diesel", "emergen" (or some similar german words). You will get some suggestions, like Supermarket, Gas station (category, all of them) e.t.c. Click it and then you get "overlay" of all supermarkets (Tesco, Billa, whatever name). Not places that are named "supermarket", but places that are supermarkets.
 - There is no assumption that you don't mean search by a name if you type and hit magnifying glass. If this is not clear, that means an important UX message.
 - It would be not convenient to search for nearby fire pits, shelters e.t.c by name. Usually, there is no name.
 - It would be not convenient to search for "Riffugio Auronzo" by browsing all accommodation.
 - It would be confusing to mix both approaches outlined here IMO

A few suggestions:
I search for Cafe and only places with the name Cafe are offered to me. Here one should make still another category Cafe or the category Restaurant anbieren. Or both make a category Cafe and offer Cafe and Restaurant.

I search for water. Here I am offered the category Drinking water. Here should be offered in addition still the category source.

I am looking for castle, here I am offered Category castle. here it would be nice also Category ruin nice. If I search with Castle, Category Castle and Ruin is offered.
In German there are 2 names "Burg" and "Schloss" in EN this is both catle. The German Category should be renamed here "Burg/Schloss".

even more:
search shelter or only hut.
--> and offer C. mountain hut.
Desire: C. mountain hut, C. shelter, C. wilderness hut.

search cave
--> offer C.cave
wish C. cave, C. mine

In the maps of OAM are also always marked benches. But these come only from a certain zoom.
When hiking, one makes a small break to drink or eat an apple preferably on a bench. A category: bench would be quite nice.
In the search could also picnic area and ... could be offered.

and same/ similar motivation for my "toilet" example

@Andrew Heard - offline points and their functionality is not affected at all by this new online search. If it is somehow broken in this version, that is another matter :-(
@freischneider - these configurations are (technically speaking) easily adjusted, it can be done by a well informed native speaker of some language. In fact there will be need to extend these configurations of synonyms to another languages. Sample of such a configuration written by a translator is attached. Solving frequent conflicts: that should be considerably improved once there are some real world data.

How can i see all defined categories and there sub-categories?
When opening the online search a (sub-)set of categories is shown. But when entering a search text new  categories appear.

Quote from: Gerhard57 on May 11, 2023, 09:59:04How can i see all defined categories and there sub-categories?
When opening the online search a (sub-)set of categories is shown. But when entering a search text new  categories appear.

I looked in the offline POI. I think so that are the same.
But if someone does not have them, what then ?
An overview of a menu in the top right would be quite good. Possibly still where you can select which you want to show and which not. Then the map is also clearer.

Hi, in the initial view of search suggestion, there are some most common POI categories which users might want to look for, but they are indeed not all. You can get others by taping their name.

How important is for you to have ability to go through whole list (tree) of them like it is possible for offline POIs now? Do you just need to know how many of them are supported or want to use such list during some real search? Thanks

It's important to note, that this new online search is primarily build for, you guess it, search things. :) That being said, we have plans to review ability to highlight POI categories on the map more permanently in different manner - including highlighting more than one category on the same time, so it allow you to use it for planning more effectively in case you want to use it this way. But that is little bit different story for us.

@Radim & Jan: did I miss a statement re. my proposal to include Google API search again?

Even the combined power of OSM, Wikipedia and Locus Communities will be able to provide comprehensive results, not in decades. Which is not a criticism of the communities approach, which is the only way once you are offline, e.g.. It's about amending above sources with the power of Google Maps - as an option.
And if this should be a financial burden, you can restrict that option to silver or even gold only.

Or is Google search active under the hood already? (I think not, because some searches failed that would deliver in earlier versions.)

Can you pls. advise?

TXs and cheers
Michael

Quote from: Jan Čapek on May 11, 2023, 12:34:17Hi, in the initial view of search suggestion, there are some most common POI categories which users might want to look for, but they are indeed not all. You can get others by taping their name.

How important is for you to have ability to go through whole list (tree) of them like it is possible for offline POIs now? Do you just need to know how many of them are supported or want to use such list during some real search? Thanks

It's important to note, that this new online search is primarily build for, you guess it, search things. :) That being said, we have plans to review ability to highlight POI categories on the map more permanently in different manner - including highlighting more than one category on the same time, so it allow you to use it for planning more effectively in case you want to use it this way. But that is little bit different story for us.

For the search it is not so important which groups there are. This is only important at the beginning to get a feeling for the search, to know what there is everything. But this could also be listed in the help guide.
They plan to highlight certain ones more. I think that's great, because some are quite important. Best something like that should also be in preset. But if one has the selection already I would offer there the possibility: 1. do not show at all 2.normal show 3. highlight show.

woah, that's a rough start..

LM4 beta 4.16.0.2 1st flavour tested, try&cry
LM4 beta 4.16.0.3

as polishing is needed and to save myself I will drop a note only at time
- cursor in search input: I have the keyboard, but the 3 basic android control-buttons are missing
- if I search by category, eg. health, also results of other categories are additionally shown on map
- if I input letters the shown results are located somewhere else, not nearby current map cursor, and also no distance is shown in the list.  As I don't see the results in context of a map (location) it is of limited value
- if the results are shown around the map as icons and I click the map for 1-2 seconds the results are gone. Might be by design, don't know. If I reenter search there is a bin icon next to category though nothing is actively shown
- the result list seems to be a mixture (as noted in #1) with missing visible structure. So I am first busy to get the clou, structure or filter the results, then I can profit of them..this should already be given by a proper design & layout

Quote from: Radim V on May 10, 2023, 21:22:28@Andrew Heard - offline points and their functionality is not affected at all by this new online search. If it is somehow broken in this version, that is another matter :-(

@radim - thanks, but I'm confused between LoPoints(offline) & new search Offline places - a better example maybe - LoPoints search for cafe & 1st two are within 1km of me (both have "cafe" in the name by the way), whereas from Offline places the 1st is 8km away?

And as @freischneider has written, sometimes a "category" is in the list of search results, but sometimes not, and not in the"cafe" example.

Map is on Dortmund, Nordrhein-Westfalen, Germany. GPS off, device located in the area.

I search for "Halde", those are artificial hills, results of former coal mining. There are quite a few in this federal state, they have "Halde" in their osm name, usually.

Now after pressing enter it shows some inappropriate results. In the south of Germany.

https://youtube.com/shorts/fhv1RJWkurw?feature=share

i perform a search and open a poi, go back with the harware back button then repeat searche and open the same poi
locus closes
> second 35 in the screencast

https://www.dropbox.com/s/x92guo3dgw54k1t/search.mp4?dl=0

Thanks for the feedbacks guys. Some comments:

Quote from: michaelbechtold on May 11, 2023, 13:27:05@Radim & Jan: did I miss a statement re. my proposal to include Google API search again?

Well there are lot of reasons to not have our default online search based on Google Search API. Not only because this API is not that great as the search available in actual Google Maps. One of the other reason is also that we need better integrations to data what we work with even outside of search functions (for now and even more for our future plans). Can you send some specific examples of results which you are not happy with?

Quote from: freischneider on May 11, 2023, 14:17:37They plan to highlight certain ones more. I think that's great, because some are quite important. Best something like that should also be in preset. But if one has the selection already I would offer there the possibility: 1. do not show at all 2.normal show 3. highlight show.

I didn't understand that part well I guess. Who you mean by They? :) What do you mean by difference between "normal show" and "highlight show" for POI categories?

Quote from: T-mo on May 11, 2023, 16:57:22- cursor in search input: I have the keyboard, but the 3 basic android control-buttons are missing

Can you please post image of your problem?

Quote from: T-mo on May 11, 2023, 16:57:22- if I search by category, eg. health, also results of other categories are additionally shown on map

That is by design, but we are considering further steps here. POIs are already to some extend content not separable from the background map. The map is designed in mind with POIs presented on top of them. So the question is, do you have issue to distinguish between highligted POIs and normal ones on the map when searching for some particular of selected category?

Quote from: T-mo on May 11, 2023, 16:57:22- if I input letters the shown results are located somewhere else, not nearby current map cursor, and also no distance is shown in the list.  As I don't see the results in context of a map (location) it is of limited value

It's because you don't always search only in the area shown on the screen and app can't know your use-case on the start. Even if there are some results on the visible map, they might be subordinate compared the one 2km away. If you want to filter results only for visible area, there is immediately available button on the map for this purpose. Distance marker from gps position will be later added to the list. To get some context of text results with the map, slide with the list up/down.

Quote from: T-mo on May 11, 2023, 16:57:22if the results are shown around the map as icons and I click the map for 1-2 seconds the results are gone. Might be by design, don't know. If I reenter search there is a bin icon next to category though nothing is actively shown

What is the reason to hold-click on the map during search for you? That bin is for deleting such search from your personal history.

Quote from: T-mo on May 11, 2023, 16:57:22the result list seems to be a mixture (as noted in #1) with missing visible structure. So I am first busy to get the clou, structure or filter the results, then I can profit of them..this should already be given by a proper design & layout

What do you suggest, please? It is expected, that 80% of search will be covered by suggestion module which by design search differently (tries to predict what you really want to search, and so tries to get to desired content with as little efford as possible) than when you fire up search of some particular text string (when you didn't get what you want in suggestions or want to find something with the name you remember but not sure what exactly and want to look it up on the map with others).

Quote from: Andrew Heard on May 11, 2023, 18:04:51thanks, but I'm confused between LoPoints(offline) & new search Offline places - a better example maybe - LoPoints search for cafe & 1st two are within 1km of me (both have "cafe" in the name by the way), whereas from Offline places the 1st is 8km away?

This is really about new online search. With its launch the offline POI search become evem more obsolete and we have already plans to work on this.   

Quote from: Andrew Heard on May 11, 2023, 18:04:51And as @freischneider has written, sometimes a "category" is in the list of search results, but sometimes not, and not in the"cafe" example.

Hmm, would be useful to at least know translated category of some actual POI to be able to know what to input in case you want to highlight similar. Will discuss it.

 

Quote from: Tapio on May 11, 2023, 19:34:27Map is on Dortmund, Nordrhein-Westfalen, Germany. GPS off, device located in the area.

Hmmm, Radim will look into this. New search is language dependant (which is also one of its known weakness), and I got good results around Dormund for "halde" when searching in czech. Something suspicius there!

Quote from: balloni55 on May 12, 2023, 08:44:27locus closes

Seems like some performance issue because of number of content you have enabled on map. Marek will look into this, thanks. 

Currently, all online POIs are displayed on the map.
1. I want certain POI category not to be displayed.
2. I would like to highlight certain POI category (stronger or bigger).
I would like to link the whole thing with Preset.

Quote from: Tapio on May 11, 2023, 19:34:27Map is on Dortmund, Nordrhein-Westfalen, Germany. GPS off, device located in the area.

I search for "Halde", those are artificial hills, results of former coal mining. There are quite a few in this federal state, they have "Halde" in their osm name, usually.

Now after pressing enter it shows some inappropriate results. In the south of Germany.

https://youtube.com/shorts/fhv1RJWkurw?feature=share

There is something wrong going on. I am looking into it.

@Andrew Heard - regarding the "cafe" example - for German language -- and actually all languages except EN, CS, SK -- this all depends entirely on quality of our custom dictionaries (done by a few kind volunteers). Again, some community insight will probably be needed. If a german user types "cafe", no cafe is suggested. Type "Kaffe" or "Bistro", and Cafe (category) is there.
@Tapio - "halde" example: german search (not the "hint" or "suggest" part) has been virtually not working  due to some config error. This has been fixed and "halde" should give you a plenty of results.   

In other words, we suggest to all German speaking testers to test again as search results may or may not behave quite a lot of differently for you now. :) Thanks for pointing us to the problem and we hope you will get better results now.

@Jan:
sure: screencast video (https://drive.google.com/file/d/1FdI4Rv1wlg_O0yuGwXT2reNhGx6t_erb/view)

I really like the smart approach of the search, based on last results, quantity of choosen categories, and whatever, daytime, popular choices, ..
Generally something that needs a lot of testing and adjustments.

If I explicitely search for health, then I explicitly search for health. Sure, there might be a pet shop nearby. Honestly I currently have no idea of an usecase of such extended results without any differentiation.

Relevant area, sure. If I search by category, then around map center.
If different scenarios are necessary, then maybe icons might help to focus search, mapcenter, gps-position (if different), ..

Clicking somewhere else was intuitively to get more map screen space, no bottom point detail, and also by mistake, sometimes i don't hit a POI precisely.

You have choosen small icons to indicate types.
I would also use different spaces and mabe dividers or collapsable areas/categories inside the list. Sure, different opinions, different layouts..
Google search and Google map and some other webservices might be a good source of inspiration for appearance of results and interfaces, often used and strongly optimised.

Quote from: Jan Čapek on May 12, 2023, 20:48:50In other words, we suggest to all German speaking testers to test again as search results may or may not behave quite a lot of differently for you now. :)

First tests give good results now, great.
I noticed it zooms to the first result. This should not be done by Locus. As a user I lose the big picture, I don't know the place of zoom and want to decide, what's having my interest. So maybe first result should not initially be selected?

POI on the map do not open.
1. I search for source
2. category source is offered to me
3. i select C. Source and all POI with source are highlighted and below is a listing of all.
4. i want to open a POI on the map but it does not work.
It only works when I select the POI in the listing. But there I do not know which is the one I want. All have the same name.

It would also be helpful if a small popup appears when I go with the cursor over the POI. This behavior is also active without searching on the map.

Is there a file, table where we can specify which category is offered for a given search word.
I would like to have the search word: Water. I would also like to be offered the C. source. At the moment it is only C. Drinking water.

Also with search: Fountain I would like C. Drinking water and C. Source. At the moment there is no category at all.

@freischneider Here is the exact configuration file that determines what is suggested for typed word (or part of a word). If you do a search for "spo" in this file, you will see what is suggested if you type "spo" in Locus using German language. It is (conceptually) as simple as that. This file was created for us by user Balloni, please take it as a reference. If anyone is interested in improving this file -- also applies to other languages -- that's great, but first: I should properly explain how it all works to editors. (It is important, really, you see it). Also we should set up some collaborative platform for this. Let me know if you want to participate here, please.You cannot view this attachment. 

No hierarchy in the JSON file? If I type "accommodation" for example, should I also expect to see hotel, hostel, motel, camping?

Quote from: Andrew Heard on May 13, 2023, 13:36:06No hierarchy in the JSON file? If I type "accommodation" for example, should I also expect to see hotel, hostel, motel, camping?

Exactly. Hierarchy exists there and is fully supported, but not defined here. "Hotel" is just hotel, "ubernachtung" is accommodation, "Emergency" is more generic, "Hospital" is specific. e.t.c

Quote from: Radim V on May 13, 2023, 11:48:55@freischneider Here is the exact configuration file that determines what is suggested for typed word (or part of a word). If you do a search for "spo" in this file, you will see what is suggested if you type "spo" in Locus using German language. It is (conceptually) as simple as that. This file was created for us by user Balloni, please take it as a reference. If anyone is interested in improving this file -- also applies to other languages -- that's great, but first: I should properly explain how it all works to editors. (It is important, really, you see it). Also we should set up some collaborative platform for this. Let me know if you want to participate here, please.You cannot view this attachment. 

In principle, I am ready to help. I will take the time.
But I am not sure if I know how to work with JSON. I have never heard this before. and I don't want to do anything wrong.
Suggestion:
Open a topic for improving the search.
Make a child topic for each language (or the most important ones).
In the first post mention the people working on the file and how to make suggestions.
Then all people can make suggestions for improvement.
The person who adds the suggestion to the file clicks on the "Say thank you" button. Then other admins (editors of the file) will see that it has already been added.

When i look at the thesaurus_de.json file there is

    "charging_station_bikes" : "Ladestation für Fahrräder, E-Bike, Aufladen",
    "charging_station_cars" : "Ladestation, KFZ, Elektro",

but seaching Ladestation finds only one category "Ladestation für Autos" with another different name??

I am also willing to support, maybe collaborative country-teams might be a solution.

I guess you already have special characters in view, e.g. german umlauts, ö<>oe etc.
tourism is 'Tourimus' and generally the words should also be added separately, like some others already (Essen, Trinken).

Popular searches (fast food, discounters, gas stations, etc.) might help, whatever that might include and it will extend and grow with more and more searches. Sure, advanced and just a filter that might be added anytime somewhere in your lookup-filter-chain. Just a thought.

This is tricky sure, see my vid, searching for 'mc do' needs to  trigger search 'mcdo', whitespaces, and very probably the popular 'Mc Donalds' is meant. Just as stupid example.
'mc dö' might possibly be a search-suggestion as list-item for searches around german locations. Some might be looking for 'Mc Döner', like suggested in the vid, just zillion miles alway.
What if you type 'mill' ? are you searching for categories or specific names, windmill, million..mispelling millitary, and some people also name modern wind turbines a windmill..just for fun. World searches will be versatile :)
I guess also a list for popular typos might be of help, to suggest replacement or even trigger further searchs.

Why not just adding it to https://crowdin.com/project/menion/de#?

Quote from: Tapio on May 14, 2023, 13:03:45Why not just adding it to https://crowdin.com/project/menion/de#?

I didn't want to do that as this is not "translation" and some non-trivial context needs to be explained.

Quote from: Gerhard57 on May 14, 2023, 11:36:09When i look at the thesaurus_de.json file there is

    "charging_station_bikes" : "Ladestation für Fahrräder, E-Bike, Aufladen",
    "charging_station_cars" : "Ladestation, KFZ, Elektro",

but seaching Ladestation finds only one category "Ladestation für Autos" with another different name??

I have given more space to the categories in the stack of results. There will be 2.

Quote from: T-mo on May 14, 2023, 12:38:40I am also willing to support, maybe collaborative country-teams might be a solution.

I guess you already have special characters in view, e.g. german umlauts, ö<>oe etc.
tourism is 'Tourimus' and generally the words should also be added separately, like some others already (Essen, Trinken).

Popular searches (fast food, discounters, gas stations, etc.) might help, whatever that might include and it will extend and grow with more and more searches. Sure, advanced and just a filter that might be added anytime somewhere in your lookup-filter-chain. Just a thought.

This is tricky sure, see my vid, searching for 'mc do' needs to  trigger search 'mcdo', whitespaces, and very probably the popular 'Mc Donalds' is meant. Just as stupid example.
'mc dö' might possibly be a search-suggestion as list-item for searches around german locations. Some might be looking for 'Mc Döner', like suggested in the vid, just zillion miles alway.
What if you type 'mill' ? are you searching for categories or specific names, windmill, million..mispelling millitary, and some people also name modern wind turbines a windmill..just for fun. World searches will be versatile :)
I guess also a list for popular typos might be of help, to suggest replacement or even trigger further searchs.

Special characters - of course, there is "unaccent" procedure. Mc Do - we do not think names of companies are synonyms of categories. This is never done, at least so far. Typos, popular misspellings e.t.c: Yes, especially for short terms guessing what is actually meant can be very, very tricky. Not from technical point of view, but from "how to go about this?" point of view. So I suggest to focus on plain, simple and thoroughly considered configuration. Then the categories suggestion module will be ...not super smart, but definitely good enough.

Sure, the example of brand names was not about categories.
when searching for online adresses and places, LoPoints on the Internet, then you generally don't really know if someone is searching for a POI-name or is thinking about a category or fragments of its description.
But I stop here to not overcomplicate things, focusing on locus-specific scenarios makes sense. No-one expects to cover 'park' like car-parking, park as a place to visit or a misspelled CenterParc of a german :) and the user should still complete his search-text.
well there's already G-maps to cover extended needs.

Quote from: T-mo on May 13, 2023, 00:36:52If I explicitely search for health, then I explicitly search for health. Sure, there might be a pet shop nearby. Honestly I currently have no idea of an usecase of such extended results without any differentiation.

Ah, then it is something else than to what I replied before. You are referring to cumulating child categories under "top level" one like "Health", which are all highlighted in such case, I get it now. Yep, there is some definition of hiearchery of POIs categories, which we might review based on such feedbacks. Thanks

Quote from: T-mo on May 13, 2023, 00:36:52Clicking somewhere else was intuitively to get more map screen space, no bottom point detail, and also by mistake, sometimes i don't hit a POI precisely.

I understand what you mean now I think. Yep, when you are in search screen, you will "lost" it when doing long-press only, however when in POI detail from search, short-press cancels everything. This is by design, as when users are in POI details, most likely higher probability is they already found what they wanted and doesn't need to go back. This of course brings mentioned issue for other cases, where they want to go through more POI details listed in search results. We will think about this.

Quote from: Tapio on May 13, 2023, 08:14:24I noticed it zooms to the first result

In case you don't go directly from suggestions to POI/adress detail, you will always have even your previous map position on screen when opening search results exactly for reasons you mentioned: To not loose idea where nearest results are related to your previous map area. So the map area is calculated to show your your previous position and nerest one now with same safe margins as most general behavior rule to any search case. Before we will as planned split it to more distinct behaviours based on spread of search results.

Quote from: freischneider on May 13, 2023, 10:02:52POI on the map do not open.

That is not correct behaviour - can you please record screen video of this? I can't simulate it.

Quote from: freischneider on May 13, 2023, 10:09:05Also with search: Fountain I would like C. Drinking water and C. Source. At the moment there is no category at all.

As Radim wrote, that thesaurus file is something else than defined hirearchy of POIs.
1) If "fountain" word is used in the german, you should get related fountain category under this search. That is to be added to thesaurus file.   
2) What other categories are related with category fountain are based on defined (somewhere else) category hirearchy. We  welcome  all specific suggestions here, but please keep in mind that they might be highly subjective. I definitely don't think that "drinking water" category should appear under "fountain", as this is not case in real world in many places of earth. 

For consistency, could the category hirearchy be the same as offline LoPoints?

Quote from: Jan Čapek on May 15, 2023, 09:22:23

Quote from: freischneider on May 13, 2023, 10:02:52POI on the map do not open.

That is not correct behaviour - can you please record screen video of this? I can't simulate it.

I don't think I clicked correctly. It was auto rotate on and I didn't hit it right.
But I noticed that the center for clicking is under the icon. If I click slightly below it, it is activated. If I click slightly above it, it is not activated.
I think it makes sense to put the center in the middle of the icon or to extend the area upwards more than downwards.
Most users will try to click exactly on the icon and not under it.
The real place should be already below the small arrow. But the area to activate should not be.

Quote from: Andrew Heard on May 15, 2023, 16:25:21For consistency, could the category hirearchy be the same as offline LoPoints?

I understand request. But as online search is the new stuff, the answer is, if the offline category hierarchy can be same with online one. :)  And hopefully yes, but this will be confirmed during second development phase, where we will focus to old offline searches.

I'm still quite confused how the new online search works. Again (next town on cycle trip) I look for a laundromat. Google Maps finds nearest 1km away. It works reliably every time. It has "cleaners" in the name, so I return to Locus & type "cleaner" but the nearest match is 1000km+! Please suggest how I would accomplish this simple task with just LM rather than Maps 1st then trying to match addresses. Thanks.

BTW the hamburger menu is still quite slow to respond sometimes.

I guess the Locus Search doesn't have access to those? I searched for "Wäscherei",Google Maps has many, but LM (and OAM) doesn't have those, maybe shop:laundry hasn't been included.

After reading the 4.17 News I made some progress, but IMHO it shows improvement is possible. As before, I type "cleaner" BUT now (for 1st time also) tap the Enter/ Find button - now the map zooms out to be 1000km across - grrr, but it now also displays the button SEARCH THIS AREA (so which area was being searched before??), so I carefully zoom back to where I was (REALLY annoying LM), tap the mentioned button, and it now lists the "cleaner" that Google Maps had also suggested just 1km away. I feel this experience can be improved quite a lot but I'll leave it for now, maybe for the developers to reproduce my use-case & frustration.

Go near Barcelona, search for
Restaurant Semproniana
- no match in LM4 4.17
- immediate match in Google maps
The search team asked me for an example, here is my first.
I simply went to my private POIs, picked the first restaurant I found - bang.
I think the UI and mechanics can be as elaborated as you want, if the data source is not comprehensive enough, you lose.
Cheers
Michael

Quote from: michaelbechtold on May 18, 2023, 04:12:36Go near Barcelona, search for
Restaurant Semproniana

note: while 'Semproniana' gets found immediately, 'Restaurant Semproniana' brings the results as described.
Helpful example!

Next one: Hotel Monegal

More thoughts bubble to the surface after a sleep... a better example, maybe - online search for "bar" (I'm in Dingle, Ireland, so plentiful POI). I don't yet tap the Find button. 1st item is "bar, pub - category" - good. The 2nd item is city of Barcelona - really? Maybe 2000km away. The 3rd item is "McCarthys Bar" 1km away - good. Now on 2nd test of same sequence Barcelona is 1st item.

This time I tap the Find button - "Paudies Bar" is maybe 800m way - good, but 2nd & 3rd list items are places in France with "bar" in their name eg. "19800 Bar, France" - bad, and"McCarthys bar" is lost. I now tap SEARCH THIS AREA - only 1 more local bar icon is shown, whereas there are dozens.

When tested with a phone there are only a few search results, but when tested with a tablet there are many more results.

When compared to LoPoints(offline)  with a Locus map there are 20+ bars within 500m.

1) should it even be necessary to tap Find? Just populate list after a pause in typing?

2) should it even be necessary to have a SEARCH THIS AREA button? Wouldn't most common search to be of visible map? When results are empty or scrolled to end of list, maybe the last item is "search wider area"?

3) I think @tapio suggested showing distance to each list item.

4) hover over any Search icon could display a popup or scroll the list otherwise it's not obvious which icon is which.

5) I think it is bad to zoom out (at all) to show icons in the list until one is even tapped, or at least restore original zoom/ position if Back button is pressed.

I hope this is constructive, and not just a rant.

Google Map > POI > share > LM4 > opens LM > online address screen > but nothing actually shared

Quote from: Andrew Heard on May 17, 2023, 17:32:57I'm still quite confused how the new online search works. Again (next town on cycle trip) I look for a laundromat. Google Maps finds nearest 1km away. It works reliably every time. It has "cleaners" in the name, so I return to Locus & type "cleaner" but the nearest match is 1000km+! Please suggest how I would accomplish this simple task with just LM rather than Maps 1st then trying to match addresses. Thanks.

BTW the hamburger menu is still quite slow to respond sometimes.

The reason this is not working as expected is: Laundry rooms are not included in the database. The third party service probably finds some occasional match based on name. But in the primary, structured database that we build - and which enables functions like "show them all nearby, no matter the name" e.t.c - there are none so far. I agree they should be there and most likely, we add them in the next extension step.

Quote from: Andrew Heard on May 18, 2023, 12:51:53More thoughts bubble to the surface after a sleep... a better example, maybe - online search for "bar" (I'm in Dingle, Ireland, so plentiful POI). I don't yet tap the Find button. 1st item is "bar, pub - category" - good. The 2nd item is city of Barcelona - really? Maybe 2000km away. The 3rd item is "McCarthys Bar" 1km away - good. Now on 2nd test of same sequence Barcelona is 1st item.

This time I tap the Find button - "Paudies Bar" is maybe 800m way - good, but 2nd & 3rd list items are places in France with "bar" in their name eg. "19800 Bar, France" - bad, and"McCarthys bar" is lost. I now tap SEARCH THIS AREA - only 1 more local bar icon is shown, whereas there are dozens.

When tested with a phone there are only a few search results, but when tested with a tablet there are many more results.

When compared to LoPoints(offline)  with a Locus map there are 20+ bars within 500m.

1) should it even be necessary to tap Find? Just populate list after a pause in typing?

2) should it even be necessary to have a SEARCH THIS AREA button? Wouldn't most common search to be of visible map? When results are empty or scrolled to end of list, maybe the last item is "search wider area"?

3) I think @tapio suggested showing distance to each list item.

4) hover over any Search icon could display a popup or scroll the list otherwise it's not obvious which icon is which.

5) I think it is bad to zoom out (at all) to show icons in the list until one is even tapped, or at least restore original zoom/ position if Back button is pressed.

I hope this is constructive, and not just a rant.

The idea how to find a nearby bar is like this: Type "bar", "pub". Something like "Public service", "Bar, pub" is suggested. These are bars like category of places, whatever name they have. Then if you tap Bar, pub (category), the first item actually suggested, you will see some. No need to use "Find" at all for nearby bars. Not all of bars will pop up necessarily, because in many cases there would be no map, just icons. If you pan or zoom, more bars come and go. If there are many of them, close to each other, only a few are visible. If this does not work in Dingle, then the server must be down or something drastic must be happening.
Problems, or maybe problems:
 - Nobody tells you "zoom in to see them all" (Like Gmaps tells you)
 - Which bar is better, more important, thus visible first or recommended first place?: The Small Bridge or The Dingle Pub? We don't know yet and it is very difficult to answer this for the world wide data.
 - Sometimes only one icon is seen when there is a large cluster of places. Zoom in to see them all.
IMHO this approach makes sense. It has confusing aspects (mostly because we don't know what is important in the real world, and some ordering is virtually random), but it works and is not that pathetic.
The same way this category based search works for waterfalls, shelters, glaciers e.t.c
 1) unless there is some server problem, this is happening.   
A note about ordering: Order by distance exclusively is not used. There is a lot of work to do, but I don't think Barcelona for "Bar" is that irrelevant.

Quote from: Radim V on May 19, 2023, 16:33:30I don't think Barcelona for "Bar" is that irrelevant.

@Radim - maybe the search should consider the current zoom level? Barcelona may be relevant if close by, but not when 2000km, and the map is zoomed out to display, non-existent map/ no offline map even exists. This zoom-out to 2000km happens on most searches which is bad.

Did you check why a share from Google Maps doesn't work? This workaround would help alot.

It's a long was to ...

I definitely agree a properly working share fron Google Maps is a must, if the use if the API Service from GM is discarded.

Re. overcrowding and zooming: Locus will hardly have a proper priority of items to show anytime soon. It cannot, I think, hence no criticism.

But Locus already has a smart system to deal with overcrowding (I recently taught it to Inge, whom I brought to Locus some time ago): it's the grouping. As long as there are numbers, pan and zoom.
Just my 2c.

GM share - we just probably forgot to test it.  :(
Zoom level affecting the composition of results, or maybe even search engines low level - this can be quite easily done (simple version) and I agree it is a next logical step.
Which bar is important and which is not: in the world of AI, some improvement over what we have now is IMHO quite possible, but very labourious and from the "data work" point of view also very hard.
Clusters of pois displaying numbers - server side this should be easy, front - end boys will hopefuly cope :-)

Hello,
The distance shown in the icon does not refer to GPS location or cursor, It seems the distance form screen border in mt.
Is this the correct behavioir?

@search team: https://forum.locusmap.eu/index.php?topic=8460.msg71808;topicseen#msg71808

People are relying on Locus when traveling - DO NOT LET THEM DOWN!

There is not even a way to search in Google Maps and share into Locus (I tried multiple ways, also Plus Code)

QuotePeople are relying on Locus when traveling - DO NOT LET THEM DOWN!

+1 😥

Quote from: michaelbechtold on May 21, 2023, 14:45:36There is not even a way to search in Google Maps and share into Locus (I tried multiple ways, also Plus Code)

Longtap somewhere close to target (create an own red pin), then share to Locus.

Oh yes. Locus should parse and check input in the online search and check for all relevant geopos formats there. That would be user friendly. Then this can truly be a place where users can dump everything in - positions, addresses, search terms...
And of course Locus needs to support the textual Pluscode. ("36XF+JPR, Erkelenz") - because that's the one Google spits out everywhere.

Hi, sorry, this will be slightly longer. ::)  :)

We are really happy to be compared to Google search, but even when we think we made huge step towards, let's be honest there: Google is still beyond our league in terms of search capabilities. :) At least within the cities. But with your help, we will outgrow them soon, we are getting there. ;) To more serious note, we can't use their search API in the way how they are using them on Google Maps - it is simply not the option and we would also loose ability to handle some of our specific requirements! But please keep in mind that this is also big redesign of this functionality on our side and as much as we tried to design it intuitive, it makes some times to get used to it.

Handling POI sharing from Google Maps will be fixed in near occasion, it indeed slipped through our tests. Can't confirm yet, whether we will be able to retrieve also its location or we will again try to find it by name on our search again. Alternatively, you can hold-press anywhere on the map on Google Maps and share specific location which is open properly on Locus Map with exact position.

There are few feedbacks that we can't search for place if you write down its name together with POI category (Restaurant Semproniana). That is fair note, we will think whether we can do something with this in the future. "Bar" or "Restaurant" are not part of the name and we can't do multiple-params searches yet.

@Andrew Heard The suggestions are not the same as text search results! The suggestions are guessing what you want to search even when you didn't tape everything yet or doesn't know whole name. Text search (when clicking to Find) should get you results what you weren't able to get via suggestion module or allow you to search on top of map. It allows you to find for specific place even if its name is part of the name of important placemarks thus suggestion module will not offer it (Barcelona // Barce).

To expect that search (as overall functionality incl. suggestions) should immediately strictly limit results to visible map area is not thinking to other use-cases which such search must handle. (For example, how do you find places which you do not have yet idea where they are at all?) Getting "Barcelona" suggested on Bar is, we believe, really correct as it is major city and there is significant probability that you want to find it when write such letters, thus allowing you to click on it gets you faster to what you might want. That is also why it behaves quite similar even in Google Maps, btw. 

The main reason for "search area" button in text search is to not automatically reload results when you want to explore them, for example when looking for something particular. But even here are reasons to not limit search strictly to viewed area, otherwise some use-cases will not be covered and others users will report wrong/missing results. Your suggestion to limit first and have "show wider area" button on bottom seems to be more limiting for future functionalities than current approach.

BTW your case when you were zoomed out to 1000km+ far to see first result when getting one near you if zooming in again and clicking to search the area is quite extreme case - we will discuss this. Yes, this might happen when "importance" of results of wide-area search will push out of the list the one next you.

We understand it is too intuitive that some results will be shown only when you zoom in due to POI grouping. Will discuss possible solutions to that.

@lor74cas It is correct behavior - this just indicates directions of results outside of your map while you can be anywhere else in the real. We plan to add distances from GPS position to the list of results bellow the map.

thanks for the tip on long-tap in Google Map - that works & is a GREAT "work around". until the latest LM Online Search was released, I've never bothered with online search or even Google Map. The offline POI have been sufficient.

I'm happy to "agree to disagree" whether the initial online search is within the visible map or not. I would rather see list results sorted & displayed by distance (method of sort could be a setting/ personal preference), and in which case Barcelona would never be shown, and the map wouldn't be zoomed out. if we do compare with Google Map then it doesn't zoom out by a huge distance

or even... have the "Barcelona"(s) in the list BUT only change the zoom if & when that item in the list is tapped?

@Jan: appreciate you see the looooong way ahead :-)))

What I do not understand: before the new search system, Locus DID use Google APIs, right? Not exactly maybe as GM itself does, but good enough to leverage the huge dataset Google has.
I do not see any reason that would stop you to feed such a Google API result set as an ADD-ON to your datasets.
Once your and Google datasets are comparable in size, you can drop that API call :-)
OSM alone is definitely not the way to go. When you do some maths like number of OSM objects/country size or /population, you will see that CZ, Germany and very few others stand out. The rest is not exactly desert, but way below practical or reliable.

Also, pls. mind what Tapio wrote below. The Google + location format is a must indeed.
And pls put priority to those fixes rather than taking users hostage.

TXs for your understanding.
Cheers
Michael

Maybe you can choose between Google results and OSM results or both. You can put a symbol in front of Google results. On the basis of the distance I see immediately so that the one from G is the same as the one from OSM. and if only one of G is there with this distance, then it was already worth it.

For certain searches I would choose only Category, because water or spring you find bad at G.
With restaurant and cafe it is very important with G search.
Here one could still insert: If I click on the icon of the G result it is opened in Google Maps and I see immediately pictures, rating, etc. And if I click on the text it is displayed on the map.

Hi guys, I have to post a few info here as well  ;)

Google API for search is not technically available to us. Its license for public API prohibits us to use it on our server. It should be also complicated to merge these results into our LoPoints system, but it is another story ...

Google search system was anyway used in the app till now, right? It was because Locus Map used a system directly integrated into the Android and that is free to use for any Android device.

Anyway, we are here creating a united search system on our server, that will be able to use more sources, user history and later also user-based personalization and return the best possible result to the user. This is not possible to do on the device => simply: Google API can't be used because of technical and license limitations. This is the fact, sorry.

Very good background information, Menion, TXs a lot!

Yet, while on your server you must not use Google API, it would be not too hard to merge the local Android Google Search results with those from your server. Data feeds and presentation are two different architecture layers. And merging two feeds is no rocket science.
Once Locus server search is as comprehensive as Google Android API, the latter can be dropped. However, this may take years rather than months, I fear.
Do not get me wrong - I understand your strategy, and if you never start something new, you would never get there. But for the time being I strongly advise to combine the strenghts of both approaches rather than leaving the users with mediocre results (to be friendly) for unknown time.

Just my 2c.
Michael

Understand Michael but this is exactly what we do not want (and most probably can't) do.

The current merge is more robust than it may look and will be even more in the future. It checks for duplicates etc. We also need identical experience on the web and also in the planned iOS version, so it has to be made server-only to achieve this.

Quote from: Jan Čapek on May 22, 2023, 17:59:36@lor74cas It is correct behavior - this just indicates directions of results outside of your map while you can be anywhere else in the real. We plan to add distances from GPS position to the list of results bellow the map.

IMHO It's not what I would have expected.
If the search is done from the center of the map or from the GPS position, it is from that point that I would like the distance to be measured.

Quote from: michaelbechtold on May 22, 2023, 20:19:22What I do not understand: before the new search system, Locus DID use Google APIs, right?

thanks for the background/ insight - hence my confusion over this new scheme. I thought it was better in the past, & now I finally have an answer as to why. It wasn't just my problem.

OK, understand your priorities, Menion.

Then at least the GM share with their plus codes needs to fly seamlessly (not "tap nearby, then ...")
And I have no idea how you will resolve the restricted data set problem.
The nicest and most consistent solution is in trouble, if you cannot trust the results (in the sense "why is so much missing ...").
Good luck for you and team!

Quote from: Andrew Heard on May 22, 2023, 18:47:24or even... have the "Barcelona"(s) in the list BUT only change the zoom if & when that item in the list is tapped?

The app zooms out only to be visible nearest result together with your previous location on map, so even if you have Barcelona in the list the app will not zoom out to it in case there are closer results. So if you get big unexpected zoom outs when fire up text search, we most likely wasn't able to find what you wanted.

Quote from: lor74cas on May 23, 2023, 08:58:55If the search is done from the center of the map or from the GPS position, it is from that point that I would like the distance to be measured.

Search is always "done" from the center of the map. But I agree, it might be confusing when you search when locked on your GPS position and map will automatically move to show you nearest result, thus these distance markers not longer relates to GPS position. Will think about it!

Quote from: michaelbechtold on May 22, 2023, 20:19:22What I do not understand: before the new search system, Locus DID use Google APIs, right?

Ok, I admit that I ignored previous "Google driven" search in my replies more that it is fair, sorry for that. Menion wrote few reasons why we don't want to use it for the future, but the list is even longer including its unreability. But the last thing we want to be your search experience worse than before, so thanks a lot for your feedbacks again. We for sure have some ideas already how to adress some mentioned topics or at least make the issues less of the problem, so keep your fingers crossed!

Quote from: Jan Čapek on May 23, 2023, 11:06:49The app zooms out only to be visible nearest result together with your previous location on map, so even if you have Barcelona in the list the app will not zoom out to it in case there are closer results.

but there were nearer visible results and it did zoom out to 2000km, otherwise I would not have mentioned it. But with the GM long-tap it's no longer an issue.

I suggest to not show only the header of search results and the map, but to also show part of the list, maybe 3 most top items and additionally indicate that this is a scrollable list.
When I slide the header it can only be slided fully to top, no mid position, and I don't see part of the map but the full list, well.

As suggested, see GMaps, heavily optimised and developed over the years. You see the map, you see the results, map height is mostly kept so no disturbing/irritating changes, results list is horizontal and neighbouring results can partly be seen so you understand that there is more, very screenspace friendly, you have categories, 'search this area' is genius to check left and right and trigger new search on demand, but in Locus we now have it automated which also is a new experience, et cetera et cetera. Nothing more to say and worth some inspiration.

As a physicist I honestly don't understand the logic to show results not requested by user's input and specified search but flooding the map, I will need an option to disable this speciality.

@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?

@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.

Also, "search this area" is available for text search, while POI category highlighting is automatically reloaded after map movement.

Quote from: T-mo on May 23, 2023, 22:44:38As a physicist I honestly don't understand the logic to show results not requested by user's input

What do you mean by this? Am I understand right, that you are only referring to category highlighting? In case you search for something specific and don't get suitable results in suggestion module, just hit magnifying glass on your keyboard.

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.

Quote from: lor74cas on May 24, 2023, 12:48:23We thus avoid useless occurrences of results that are too distant both on the map and in the list.

++

Quote from: Jan Čapek on May 24, 2023, 11:43:49@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.

Quote from: Jan Čapek on May 24, 2023, 11:43:49Strange, 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.

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.

@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.

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?

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.

Quote from: lor74cas on May 24, 2023, 12:48:23A 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?

@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.   

Quote from: Jan Čapek on May 25, 2023, 10:52:52But 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

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.

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.

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

Quote from: michaelbechtold on May 28, 2023, 20:22:01Using 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.

@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.

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.

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 ;-(

The latest LM4 beta 4.17.2.3 appears to have gone "backwards" regards to sharing with Google Maps. Has there been a change not in the release notes? Sometimes when I use the workaround of GMap > long tap > share > Locus sometimes now brings up the online search text box with "push pin" as the text. No use at all. Other times the location is unrelated to the desired GMap location. So now no GMap "share" workaround seems viable?

@Radim et.al: don't you think below deserves an answer?

Maybe Google changed their output? However, an easy way for newbs is missing. And Locus should definitely understand latlon and pluscode formats in its new search.

Hi guys,

there were some small changes in handling point sharing from Google Maps to Locus Map. If you encounter problems also in next version, please, let us know.

Quote from: Tapio on July 06, 2023, 14:25:46Maybe Google changed their output? However, an easy way for newbs is missing. And Locus should definitely understand latlon and pluscode formats in its new search.

@Tapio - how to test? I tried sharing a G-Map point with text clipboard > notepad but it just pasted text "red pushpin". I guess the clipboard supports multiple content types simultaneously.

Quote from: Andrew Heard on July 12, 2023, 00:39:17

Quote from: Tapio on July 06, 2023, 14:25:46Maybe Google changed their output? However, an easy way for newbs is missing. And Locus should definitely understand latlon and pluscode formats in its new search.

@Tapio - how to test? I tried sharing a G-Map point with text clipboard > notepad but it just pasted text "red pushpin". I guess the clipboard supports multiple content types simultaneously.

IDK. I am convinced Menion knows how to intercept that "send to" mechanism.

probably been mentioned before, but every time I use online search I feel I'm battling/ pushing uphill; example search for close-by road in Web Planner - first three suggestions are on the other side of the earth; why aren't these suggestions sorted by distance to the users position?

https://web.locusmap.app/en/?lat=-42.836418&lng=147.290826&z=15&map=hikeBikeYou cannot view this attachment.

Quote from: Andrew Heard on July 01, 2023, 09:42:15The latest LM4 beta 4.17.2.3 online search appears to have gone "backwards" regards to sharing with Google Maps....

The latest LM4 beta 4.17.2.4 appears to have gone further "backwards" or at least sideways? My simple use-case, which to be honest is just a hack workaround, because LM4 search is not capable (sorry guys), is

• Google Maps app
• long tap to create red push-pin
• drag-scroll to find the Share option
• tap Share
• tap LM
• now observe, even worse than in 4.17.2.3 LM displays a list of POI over 20,000km away

BUT with correct local address 1km away and no way I can find to re-position to that local address - "so close yet so far" ;-( Funny - at least the list items are sorted by distance ;-(

Google Maps app:
You cannot view this attachment.

LM4 Online Search results after tapping the GMap Share button:
You cannot view this attachment.

BUT I can confirm that a long tap in LM4 will also display the correct address:
You cannot view this attachment.

The Google Maps website shows many results much closer than 20,000km, including the desired one, and which LM would also correctly find:
You cannot view this attachment.

Yes, we can only copy paste lat,lon. And I doubt many users will find the place where to paste it into Locus.

Latest Google Maps. No improvement with Share to LM4. Exactly the same poor behavior.

Quote from: Andrew Heard on July 30, 2023, 07:47:09Latest Google Maps. No improvement with Share to LM4. Exactly the same poor behavior.

But in the other thread they said it's fixed - new version just isn't out yet.

Hi, I posted few notes regarding search and sharing from Google Maps here:
https://forum.locusmap.eu/index.php?topic=8572.msg72919#msg72919

I should have post it here and send link to that topic, but nevermind. :)

Quote from: Andrew Heard on August 09, 2023, 08:02:32@Jan - sorry to sound like a broken record (for those old enough to remember) but why would I (as a user) want to see search results from >1000km at the expense of results I know for sure are closer? Sure, put them at the bottom of the list, but sort by distance surely? MUST?

Because what if you want to find something far away instead? For example New York - there are hundreds of places called like that. The app will never know for sure whether you want to find pub called New York 30km away or New York city in the USA. So it must provide compromise which suits both cases.

But I agree the current state is not optimal. It has to do with two things:
1) It can't find places what you want to find (translations/dictionary issues).
2) We don't yet have enough data in order for "smart" sorting be better than sorting by distance in lots of cases.

Quote from: Jan Čapek on August 09, 2023, 13:37:50Because what if you want to find something far away instead? For example New York - there are hundreds of places called like that. The app will never know for sure whether you want to find pub called New York 30km away or New York city in the USA. So it must provide compromise which suits both cases.

@Jan. We have to agree to disagree. The online search provides results for countries I don't even have maps for. Crazy stuff. Suggestion - add user preference to sort-by distance, or sort-by "LM4 relevance". Maybe add analytics to see what is the preferred use-case, my money is on the former. As @Joeloc said @ https://forum.locusmap.eu/index.php?topic=8572.msg72940#msg72940 my online search workflow has now become GMap > share > LM4 because the results make sense.

Maybe zoom level as an indicator of users scope wish? Zoom level low: User likely wants to find "New York City" in the US. ZL high: wants to find the local "NYC brothel".

Quote from: Tapio on August 10, 2023, 07:54:48Maybe zoom level as an indicator of users scope wish? Zoom level low: User likely wants to find "New York City" in the US. ZL high: wants to find the local "NYC brothel".

This is not practical. So the user must first set the zoom level and can only then search.
It doesn't matter if places are displayed 1000 km away. The important thing is that he can make different sortings. And here the sorting by distance will be in the first place and also belong to the default setting.
If it is sorted by distance, I don't care if there are places with 1000 km distance at the end of the list. It is only important if I sort the distance by GPS or by the center of the map. Here I would set default also map center.

Quote from: freischneider on August 10, 2023, 08:25:31This is not practical. So the user must first set the zoom level and can only then search.

No I'm saying it could use the maps current zoom level (and map position) for its priority decisions. But well, they may already do that.

Quote from: Tapio on August 10, 2023, 16:11:40But well, they may already do that.

Yes, we do. :) This is indeed super complex topic under the hood.

Quote from: joeloc on August 09, 2023, 19:14:49To be brutally honest, I wouldn't mind if you completely removed online search from Locus.

Well, you don't need to use it then. :) In reality Locus Map can't rely on other apps to search places nowadays. We are well aware that choosing beforehand where to do search is not up to today standards. That is why we are changing it.

I see that by offline you mean local user content search and by online the one similar to Google. In reality it is more complicated than that. But I am confident it will do exactly what you described as preferred in your post in the end (+ it finds you even the mountain ;)  ). 

But it will take some time so thank you for your patience:
1st stage - online general places (adresses&POIs&..) search (we are here)
2nd stage - offline general places search
3th stage - revamping other local searches

All stages will be combined together in the end, so you will just have to type the string and then do the choosing from the result offerings - presented in the way to suits all scenarios in best possible compromise. Not want to go into the details there now, long way to go. Of course, you will still be able to search just in your tracks for example.

@Andrew Heard @joeloc and others:
We hear you all and thanks so much for your feedbacks. Apparently too often search of local places is rubbish and we will do our best to do something with it.

Until then, we didn't removed old offline address and POI searches. They are still there in its current old-school form. With those the app for sure would not be returning results from countries of which it hasn't downloaded map.

I like what they're trying to do. I think we are too impatient. But this way, good ideas may still come.
My idea:
Right now I have to select search in tracks. But if I want to search in online addresses, I have to change it and start a new search. That is multiple selection in the menu.
Here you could set a default setting where everywhere is searched. If I get too much I can briefly deselect a few search types and then have fewer results. The whole thing also the other way around, add search types.
But with a new search is always first the basic setting that I have set.

Another idea about other search providers (GMaps, Bing...). Who wants to use these does not need to use the online search here (simply deselect the search type). What would be useful, however, is a link to another search provider (app, or website) The link can be set up if you want to use it. When setting up you can still write a note to it.
The icon for this could be placed at the top of the menu. Better would be directly in the search (possibly on the far right).
Of course there is the possibility to place a link to an app in the sidebar. But for some, it is already too full. and simple users do not use it normally. Another area would be the main menu, where I currently also start the search. But at the moment you can only place locus internal functions there and no foreign apps.

Perhaps the topic should be renamed: Online / Offline Search

I do see the complexity in combining all searches together, and I can live with having to select different search "means". But one major bother, that should be not too difficult to change is this:
Everytime the search scope is changed, there's a new, empty input field. Why not prefill with the search term already entered in another search? All the time I start typing into a search field before realizing I have the wrong search - then I change it and have to start from scratch (unless I thought of that and copy-pasted the term, which of course is also a bother).

PS: I just realized that this works between internal point and track search, but that's the only place I found.

Quote from: Jan Čapek on August 10, 2023, 18:07:26...
Until then, we didn't removed old offline address and POI searches. They are still there in its current old-school form. With those the app for sure would not be returning results from countries of which it hasn't downloaded map.

As a Computer Scientist and IT professional since more than 40 years I appreciate that your roadmap is havy lifting. But by the same token I can confirm that you and your search team completely fail re. rule #1: "Do not screw your customers!"
You are "proud" to not have removed offline POI and address search? Well, removing the last straw would have been complete suicide.
Keeping Google based search in its place as it worked for 10 years, alongside your new search, would have been professional. You would get feedback from the geeks who dare the new stuff, while offering propoer search results for all others, while you do your homework for step #2 and #3.
And if there should be pride and emotions in the way of doing that: both do not pay your bills. Be smart instead.
Cheers
Michael (from Radium Hot Springs)

I think Michael's idea is a good one. Keep the old online search and start the new search (beta) in parallel. At the first start of the search (beta) a note so that you should post errors, improvements here in the topic and so that you can still use the old search in case of need.
In the first post here, should be added in bold what they have in mind and how the current timetable is. This can then be adjusted weekly. Then many questions, criticism, etc. would not arise.
I myself use the search very rarely. Nevertheless, I try to help here, because the development of Locus Map is important. In addition, I do not want so that important users (geeks) are annoyed and jump off. because they also often help me with very special applications.

Quote from: freischneider on August 12, 2023, 09:38:59I do not want so that important users (geeks) are annoyed and jump off.

Nobody jumps off or should jump off just because of search. And there's no alternative to LM anyway. People shouldn't forget what we have.
Personally I don't care about the new search too much. For some reason, I don't like the presentation of the new searches results.
Offline POI handling needs improvement, Menion knows that.
I either use Gmaps->Locus or do Nominatim based search, Tasker->Locus.

@michaelbechtold Would you or others please share some examples of searches (exact term together with your map/cursor location and app language) where our new search fails and where old Google (still available in Locus Map Classic) works fine to try to replicate? I am not telling new search is better, but want to be sure we don't miss anything here as I am frankly surprised how unusable you are reporting it is. It is for sure possible we are getting better results on our end because of combination language app, search term language and OSM POI data with their name translations.

Please separate it from the problem with sharing POI from Google Maps. I think that is clear now and it is separate issue/project for us.

As mentioned before, we think we know well what has to be improved or changed now in order to get better results or be more intuitive. But as we soon to jump on it again, I want to be sure we really have clear picture of all issues.

Quote from: Tapio on August 12, 2023, 10:43:03For some reason, I don't like the presentation of the new searches results.

Would you please elaborate a little?

Quote from: Jan Čapek on August 16, 2023, 16:27:40

Quote from: Tapio on August 12, 2023, 10:43:03For some reason, I don't like the presentation of the new searches results.

Would you please elaborate a little?

a) I mean on map
b) Eg search a category like "parking". A lot of other POI are displayed. Didn't ask for those
c) Tap beside poi, on map - under some circumstances the results stay on map, sometimes they disappear. Need to go into search again.

I recommend to use and test the search as much as possible.
As user experience it doesn't appear as a very sophisticated result though I would love to give a different feedback.
I also suggest -again- to orientate to very evolved solutions like e.g. G-maps with regard to HMI and result presentation. I could tell a lot, but all is said and the rest might be catched by comparison.
It's not about database - which is understood as not being the plan (and hopeless to reach at all), probably might target sth. more basic and komoot'ish.

Nevertheless, just try and add a town-name as basic location description concatenated with another string of an idea to search for..
(if you only use the kiosk name it will be found as shown, being unique enough).

Another example: search for 'Rewe' you will get results, if you search for 'Bochum Rewe' you get no results. This definitely makes no sense.

Regards the latest 4.18.2 online search results & sharing from Google Maps. For me, it's the same experience as reported in previous beta 4.17.2.4 @ https://forum.locusmap.eu/index.php?topic=8436.msg72716#msg72716. Although the release notes mention search improvement (maybe compared to 4.17.0??), so I didn't notice any change.

OLC Search (4.18.2) failure:

HGVV+465, Lünen - not found.
should be
51.592763,7.543109

Quote from: Andrew Heard on August 17, 2023, 00:49:58Regards the latest 4.18.2 online search results & sharing from Google Maps. For me, it's the same experience as reported in previous beta @ https://forum.locusmap.eu/index.php?topic=8436.msg72716#msg72716. Although the release notes mention search improvement, I didn't notice any change.

I still have poor results here as well. Maybe it's because Google Maps doesn't append usable data when sharing. Coordinates would be important here. Maybe Google only gives the name. But also with this should come good results.

@Jan: I gave 2 hiking target examples from BC, Canada many weeks back.

Again that Google Maps sharing. :) Wait please for next release of the app, I believe it will have major impact on your experience in this. Marek and Menion are doing their magic tricks there now. ;) Lets just hope Google don't change the things on their side soon again..

On other hand, all reports of bad experience while using our new online search are welcomed as we are able to separate/sort  them into technical aspects which we are planning to focus on. This give us better ability to determine whether our expected implementations will make significant change for you or not. Thanks.

Quote from: freischneider on August 17, 2023, 08:20:35I still have poor results here as well. Maybe it's because Google Maps doesn't append usable data when sharing. Coordinates would be important here. Maybe Google only gives the name. But also with this should come good results.

@freischneider - but the app that @0709 mentioned https://play.google.com/store/apps/details?id=com.donutpond.sharecoordinates a few weeks ago for sharing between GM & LM works perfect, so it is definitely not a Google Maps issue (IMHO). My Android version is old (V8) & @joeloc mentions issues with current Android. The developer says up to Android 10.

Sharing from G-Maps works perfectly with the new version. I tried it with different types of maps poi.
Thanks

4.18.2.2 - yes sharing GMaps to LM4 working for me too. Excellent. Although not mentioned in release notes?

settings > Navigation > Router (LoRouter) > Profiles setup > (spanner) Active profiles > random crash while list is displayed, happened once, didn't happen for this report ;-(

Nice, but parsing of OLC still lacking ("HGVV+465, Lünen" not working).

I think this is the root cause for this: Autobahn parking fails to share to Locus, Locus finds another parking in the town. Umlaut issue?
👉 https://maps.app.goo.gl/FXxfijJBTn62PGDV7

Seems like the filter-chain is not yet optimised.

I used some city names for simple search tests.
Was going for 'Gütersloh' and looked for the search-as-you-type-results.
'Güters' (while typing) is tricky as 'Güter' is a german word for cargo and goods, and street is 'Straße' in german, also starting with s - so you will get a lot of 'Güterstraße' of different towns, not that uncommon.
At least no city 'Gütersloh' as top-posititioned suggestion.
Google does different, quite experienced with searches, they classify search requests by types and top-position towns or other popular interests.
Similar to 'Dor' when going for Dortmund or Dorsten.

Maybe you prefer some close-range-experience, nevertheless I sometimes found myself in a situation to quickly look for some locations due to very different reasons. Currently I go with Google maps.

IMHO some category- and some priority-evaluation makes sense as part of the filter-chain (sorting of available results).

I like the online search more and more. Especially for LoPois. I search for the category "Parking lot" or "Water point" etc. They are all displayed and highlighted on the map. If I zoom out further, they are updated immediately.
Unfortunately, this is missing when you go to search offline locations (LoPois). Then only a list of POIs is displayed.
Please make the offline area the same as the online area.

Another idea. If there is an online connection, always search online. As soon as there is no longer a connection, automatically switch the search to offline. Now I always have to go to the menu in the search and change it. 

Hi freischneider, thanks for the ideas. Yes, both are planned, we only had to put bigger search upgrades on hold due to other dev priorities, so hopefully we will get back to it in the mid of this year. So sorry it takes so long to continue on this.

I know OSM is quite heterogenous, but it's still too easy to let the online search fail..results while fueling my private jet :D

(correctly it's McDonald's without blank, white space, and with 's, so it's originally due to the underlying OSM-database. But still fun as being a very popular example about how to handle popular typos, misspellings, multiple entries)

I searched for
hotel
Bier
Museum
and get results at 8th position very far away, 1000s of km, france, congo, kenya..
With 'bier' 1st suggestion might be a category like pub, food&drink, Trinkhalle..something with some very basic logic.
#filterchain 8)

@T-mo - I've mentioned this (stupid far away search results) a few times, but fell on deaf ears. Has never made sense to me either ;-(

Quote from: T-mo on March 12, 2024, 23:05:55I searched for
hotel
Bier
Museum
and get results at 8th position very far away, 1000s of km, france, congo, kenya..
With 'bier' 1st suggestion might be a category like pub, food&drink, Trinkhalle..something with some very basic logic.
#filterchain 8)

In my eyes the mixup of different searches in one new "online search" is maybe good for "getting any result", but it is hard as a user to understand that there are "different context of the results" (is it a category? or a POI found somewhere in the Locus World? or is it a result of a dedicated location search of a framework/Internetservice?). This mixup of context is for me one reason why it is so difficult as a user to explain how the current new online search can be improved (most users that complain probably just want it "better" - they don't want to think about context - but the new online search feels "be forced to provide only small junks of context information as a global result"). To make it short: I have trouble finding good results! I started using workarounds for having good results™ like...

1. using Locus Offline POI database navigation in categories with nearby list and map display (good for finding OSM maintained data like museum, toilet, pub - hey, distances to map center works here correctly! - you only have to learn your favourite categories),
2. switching to Wikipedia search in Locus (good for finding sightseeing locations, correct distances),
3. using offline address search in Locus (good for finding addresses in OSM data - exact spelling necessary, choosing north/south of a country is a try&error method),
4. search in google maps and open the location in Locus (good for finding the best results - handling is not the easiest solution because of the media break)

Ideas: If results should include a mixup of different sources, there could be a ranking algorithm that matches "the real needs of the users". If this is not possible or  additionally, it could be more easy to switch fast between the usecases like category search, name of POI search, address search (one that is working like a charm), sightseeing search by Wiki etc.). Single search usecases by those sources as usable symbols for the toolbars would be loveley.

For Android there is still the option to have Google results via API, free of charge (as per Menion, last year's discussion).

But it is a decision by the Asammm search folks to not integrate that. It would be easy to merge those  results or keep this Google search as an additional option in your list, druki.

The earlier argument that Android and iOS should have same features is not valid anyways and a pretty bad excuse. Because the feature set for iOS will be smaller, for many years to come.

A solid search feature incl. Google search API is simply a question of will, not effort or anything else, I think.