Online search

[Andrew Heard]

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?

[michaelbechtold]

@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

[freischneider]

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.

[Menion]

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.

[michaelbechtold]

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

[Menion]

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.

[lor74cas]

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

[Andrew Heard]

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

[michaelbechtold]

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!

[Jan Čapek]

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!

[Andrew Heard]

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.

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.

[T-mo]

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.

[Jan Čapek]

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

[lor74cas]

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.

[Andrew Heard]

We thus avoid useless occurrences of results that are too distant both on the map and in the list.

++