Messages

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

Locus on Apple/iOS??? When did I miss that? Definitely can't find it...

See:
https://help.locusmap.eu/topic/32424-locus-map-lite-ios-beta-program-open-for-new-testers

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.

sorry for late reply. 

@mfink Whole Garmin For Locus addon is waiting for some "restart" as the current app can't be updated at all because
Garmin again unexpectedly broke backward compatibility of some important Connect IQ SDK features which Locus Map rely on. So I can't even add support for latest devices now unfortunately.

This prompt is another example of the state of CIQ platform. It never properly worked until I finally this year on latest devices like EPIX. But If it still behaves the same for you, I don't expect it will ever change for Fenix 6 family.


@winice not possible. CIQ is very limited in such areas. 

@joeloc @michaelbechtold

Guys, I think you already forgot that our old search definitely wasn't the same as the one available in Google Maps app/web. You describe it as it was and we ruin it with new search. In fact, that "bike shop" example was completely unusable before as it is now. I understand what could be the ideal state, and believe us, we know the importance of the search capability.

So,
1) The new search what we introduced this year is far from final. Even thanks to your feedbacks, we have clear vision what should be our next steps in order to significantly improve it. But for summer, we had to relocate our limited resources also to other tasks. We plan to get back to it during fall.
2) Yes, it is technically possible to implement Google Search/Maps API (not the one which was in app before), but if we did "just" that, it would bring several MAJOR downsides for us, not mentioning that it would still don't fully replicate search experience as on Google Maps. Some of these are for example limitation of use by only portion of our users, queries limits, inability to search our own/future content and interconnectedness with it, costs, and so on. So we anyway had to start with revamping our own search platform from the ground which will be able to get several search feeds together. What you have in the app now is its first iteration.
3) iOS is definitely not the reason why we choose this path, it is much wider than that. Remember, to find shops in the city around you, Google will always be ahead of us. We are not aiming in exactly same direction as they are. Only after we reach the point when we are unable to do improvement on top of current solution and still be too week in some search use-cases, we will merge it with another search provider to get better results.
4) Smart search MUST be able to return result >1000km far away if it might be relevant. You can already filter results to your map area. I don't consider this to be problem, I believe all issues related to this is rather that search is unable to find places what you expect to find (for example those around you). And this is matter of improving search in general. 
5) There are few main areas to work on now.
- The current implementations of POI category search and search by POIs names are too separated now
- improvements of "search dictionaries" so it will better understand what user want to get
- better data for determining POI significance.
- better work with different languages
These might have significant impact, but they will be tough to conquer, so which us luck.

@Andrew Heard
6) Topic with sharing data from Google Maps is only indirectly relevant with search capabilities. First, it is not "meant" to be used this way - it is implemented primarily for sharing data via emails/messages etc. where receiver ends up on Google Maps again. Note, that not many of other navigation apps registers this command and shows itself in such sharing dialog. Locus Map is, and we are trying to overcome this by parsing provided data and in case we can't determine its location, we throws its name to search.

But Google recently changed something and what previously partially worked now throws unusable URL to search field. Current app version didn't change anything in this and as Marek stated above, he already fixed it again for new upcoming version.

As stated above, our priority is now to get better search relevance on top of data we are working with, which might increase change you find shared location from Google Maps in Locus Map. Indeed parsing name from Google Maps might probably work better even with old Google SDK which we used in the app before. On other hand, we will have hard time to pair the result with data of POI in our DB with this approach. So the final solution to this remains to be seen, I can assure you we are aware of your feedback in this.

Hi, please see here for some update in this regard! 
https://help.locusmap.eu/topic/32424-locus-map-lite-ios-beta-program-open-for-new-testers

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

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

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

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

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

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

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

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

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

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.

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!

What 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!

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.

Hallo,
1) wenn Sie POI von Google Maps an Locus Map weitergeben, erhält die App nicht den leicht lesbaren Ort, sondern den Namen des POI. Also wird schon vorher automatisch eine Suche in Locus Map gestartet, die versucht, den Ort zu finden. Nicht optimal, aber besser als nichts. Leider ist uns dies beim Testen durchgerutscht und es funktioniert nicht mit der neuen Suche, da der Suchbildschirm ohne einen Suchbegriff startet. Wir werden dies bei nächster Gelegenheit beheben.
2) Sie können immer noch auf Google Map auf einen beliebigen Ort auf der Karte drücken und ihn an Locus Map weitergeben, was die genaue Position sehr gut öffnet.

Übersetzt von DeepL.com

@Žajdlík Josef Hi, you mean search input always floating on top of the map or something different? Thank you for your kind words!

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

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.

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

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.

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.

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

POI on the map do not open.

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

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

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.