Messages

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

For some reason, I don't like the presentation of the new searches results.

Would you please elaborate a little?

Hi, date of adding new devices to the compatibility list is currently unknown, sorry. Unfortunately Garmin "improved" their Connect IQ platform again without prior notice so old and more complex apps like Locus Garmin addon can't be updated anymore and we are analyzing possible next steps. I hope I will know more to the end of August.

But well, they may already do that.

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

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

@Andrew Heard I replied to your question regarding search here:
https://forum.locusmap.eu/index.php?topic=8436.msg72936#msg72936

I only use this as a workaround. The combination of the app that @0709 suggested has really improved this method of sharing greatly.

Yep, it is handy tool, but unfortunately the app isn't compatible with recent Android versions, nor is working offline.

@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