Messages

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.

Thanks for the feedbacks guys. Some comments:

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

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.

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?

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

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

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

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

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.

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

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

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?

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.   

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

 

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

locus closes

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

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.

Hi!

Garmin addon for Locus Map is meant to be used with connected phone with the app, so it can't help you with this scenario. If you want to be on your adventures only with your Garmin, you have to rely on its own capabilities, which of course include track recording.

However I doubt you can easily get compass data from it without some processing of directions from track data, but I might be wrong in this. You can export tracks in GPX from their Garmin Connect service once you synchronize your watch with it and import it to your Library in Locus Map.

As for the last question:  in some future we may implement sync of Locus Map Library with Garmin Connect to automatically retrieve tracks from it once they are recorded, but this is not yet confirmed yet, so any promises there.

Well, there are lots of Garmin watch models nowadays. It all depend on your need for advanced fitness metrics, type of the screen, ruggedness, and budget. Basically any will do the job in some form.

Hi, we hope to release first public test versions in the first half of this year. But as Menion mentioned, please don't expect full-blown Locus Map yet. It will be much simpler version for the start. Of course, it will be just the beginning for us though.   

Hi! Well, I fully understand the request, but honestly it is quite low on our priority list for now as it would bring various challenges in the UI which would need to be solved differently and for now we rather spend the time on what we believe even more useful updates. But once the time will be right, we will consider it again!

Hi, this is often requested, but not supported unfortunately. I also can't promise it someday will be as it is really challenging to implementing without too much compromises.