Messages

Stimmt, es ist beim neuen Ordner vorhanden, kann aber danach nicht gewählt werden. Menion sollte es dazupacken.

Neuen Ordner anlegen und Tracks rüberschieben ist aber auch schnell gemacht.

Menion, can you add an expert setting which centers the map to the starting point of a track, when clicking see screenshot? I can only speak for myself, but at any time the starting point is of primary interest for me, track center and overview comes second.

Das Punkte-Problem habe ich inzwischen gelöst, mit Einstellungen unter Punkte und Tracks, "Prüfung auf doppelte POIS während des Imports". Das wirkt sich dann wohl auch auf in der Karte erstellte Punkte aus.

There are no such settings that may increase GPS frequency. There exist external devices, like Garmin GLO and some other, that allows increasing frequency to 10x per second.

Anyway, if the problem you "feel" is really only a movement that is not fluent ... in other apps, they most probably do transition between two locations with map animation. It does not give any extra accuracy or more frequent location > it "only" polishes usability a little.

I was already thinking about it some time ago and decided, that battery is priority no 1.

---

Let's try a quite simple attempt ... next (Beta) version, Expert settings, a new option "Fluent movement". It changes a simple jump between coordinates, to a small 1/4 sec long animation. A one second-long animation does not make sense, because in the end of animation, the location will be almost one second old. So 1/4s is a good compromise and it looks quite good.

---

And usage ... 25% of users use Locus Map for cars & motorcycles. So it is not so simple. We try to focus on hike & bike > This means that when I have to decide something, I optimize the app for the hike & bike rather than for the cars, but ... 

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.

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.

Replace "Unknown Street" display by simple "--" in full transparant top panel.
(Has already been suggested before......)

I had yesterday finally a day on the bike and to be true, I've not noticed any delay when the screen turned on and map had to rotate. It was almost instant.

Anyway, I'll be watching it ...

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

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.

@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 guys,

@freischneider @Graf Geo @Andrew Heard @Tapio @joeloc

thank you for your feedback, that at least red push pin works. Now, we have updated also POI handling to new Google Maps format and hopefully they won't change it in a month. If you encounter silly URL in search window in the next release version, check if you are on latest Google Maps version and if yes, let us know.

I think it is time for a drastic correction of approach here: whatever you do for iOS should not screw the 100000s of users from whom you make your living.
As long as the new search function is not professional, give the Android users back the Google based search.
Equal functionality is not a valid argument against this request, as the iOS version will lack essentials for years to come anyway.
At least give the existing and fully functional Google based search as an option to your (Android) users, PLEASE!

What about then at least adding support for PlusCode? That can be copied from Maps with one tap and surely be parsed by Locus search without ambiguity?!

@slarti76 - thanks, hadn't used +codes before. Still slower (many more taps) than direct "share" of a point from my testing:

• drag POI details down a few times
• tap on "See all"
• tap on +code (very little visual feedback BTW)
• switch back to LM4
• open Search (maybe side panel button)
• paste clipboard (maybe more steps here)

Yeah, agreed, but
a) if we don't have another always-working solution,
b) surely no problem with parsing (well-defined as far as I understand)
c) at least last two steps could be improved if Locus adds a PlusCode support by automatically inserting clipboard content in search field (if it parses as PlusCode).
Heck, Locus could parse the clipboard when opening the search and automatically switch to PlusCode if it parses.

Honestly, I'm a little diappointed how the missing ability to correctly share positions from Google is waved away here. Menion et al should be aware that this is an ability that is absolutely crucial for "normal" users. OSM is nice and well, but let's face it, GMaps will always be more up-to-date. Rarely anyone relies on OSM POIs alone, so we all search stuff in GMaps all the time and want to easily enter the points in Locus. This is not something to just say "hasn't been working for a while, so what?"...

...But sharing of existing GMaps POI doesn't work/ has different behavior to 4.17. Now LM4 Search will display the shared link as text, for example https://maps.app.goo.gl/zmQaPsNkSRVfqtDn6, and display "No search results" rather than moving to that point. When I open this example URL in my web browser, it displays the correct POI.

I guess that is about PlaceIDs and requires API-usage, if possible at all.
This can not be simply decoded or parsed like simple MapURLs with lat-lon. Currently only sharing a nearby set marking seems to be of help.