Messages

handling Google Maps share button should be fixed

thanks @Marek, and the issue reported many times, of search results from > 10,000km away at the top of the list, when there are closer matches on the map < 10km away?

This is not forgotten, just there is no "fix". There is tons of work to determine relevance of results and: Not everything is under my control. Also the rule that closer "match" is more important is oversimplification as we (not just me) agree. I may do some tweaks but proper solution takes time.

Hello Lupin,
sorry for being late, but this is hard to investigate.
 - Locus router (both offline and online) is not guarantied to give results identical to Brouter project. Why is that: 1.not identical data are used for calculation. (This seems not to be the case here as your profiles work in both Locus router and Brouter). 2.There is constant development on both projects which we sync only sometimes (there may be minor changes in the algorithms e.t.c). We aim to keep online and offline version of Locus router identical.
 - Maybe more appropriate question here is: Is the calculated route wrong? How much error is there regarding your routing profile? Which one is the "right" one?
Would you share your custom profile please?
Radim.

Using online search a little bit and thinking about it a bit more, this is my summary:
- Google data repository is unmatched, beating Locus and any other searches hands down, whatever they try, for years to come
- Locus, for strategic reasons, also with iOS support in mind needs this independent online search
- on Android the Google API search is at no cost to Asamm, as Menion stated
- combining both searches technically seems not feasible, as per Menion's response
- to me, the obvious approach is
-- to have a Locus Search for Android and iOS alike
-- put a Google Search as separate function into the Android version

That would stop any need for tough comparisons and discussions, a d empower users to make their own choice, based on their needs.
Giving USERS a choice may not be a technician's first emotional approach, but is beneficial for all parties in the end.

And above approach would not add complexity to the UI a d user experience.

Hope is the last thing to die ;-)

Cheers
Michael

Hi Michael, just a few notes. Of course I agree Google (and few others big boys too) are rather impossible to match. But the current state of what we have in terms of "data repository", as you put it, is just the first step really. In terms of quantity of data it is easy to add dozens of millions of items by mining the OSM dataset. That is a matter of configuration and will be done. (Not all at once). Accuracy outside well mapped areas is not so great, sadly, as we know. Better search engine is hard but doable of course, that is just a lot of work again - these real world data use cases are not typically solved by technology providers. There is also tons of work making all this machinery to update data and talk to other pieces of machinery. But I don't see an easier way how to put together a consistent, world wide dataset of places and "points of interest" relevant to hike bike context. Of course G will find you the nearest "laundromat" way better than L. But how would you search for the nearest fire pits (worldwide). Of course there are some datasets available but maintaining all this together is a hell we (I) don't want to enter. I am an expert in the osm inconsistencies and weaknesses but IMHO this dataset is really needed here.

@Andrew Heard
- There is some change: The first result in the list one gets when types a term and hits "find", is the nearest one. There will still be map view change as this cannot be done server-side, only in new app version. But drastic changes (thousand miles away zoom&pan) should only happen sometimes, if there is no nearby result. Anyway there is (now) no sort based on distance entirely.   
- "Glitches", or "Timing issue": This indeed looks like some async programming error but it is unfortunately not that simple. The reason is: For < 1% of the questions (queries) one of the engines is not performant enough. (Think too many disk reads as opposed to fast memory reads). Once there is a migration to some other solution, this should be solved.   

GM share - we just probably forgot to test it. 
Zoom level affecting the composition of results, or maybe even search engines low level - this can be quite easily done (simple version) and I agree it is a next logical step.
Which bar is important and which is not: in the world of AI, some improvement over what we have now is IMHO quite possible, but very labourious and from the "data work" point of view also very hard.
Clusters of pois displaying numbers - server side this should be easy, front - end boys will hopefuly cope :-)

More thoughts bubble to the surface after a sleep... a better example, maybe - online search for "bar" (I'm in Dingle, Ireland, so plentiful POI). I don't yet tap the Find button. 1st item is "bar, pub - category" - good. The 2nd item is city of Barcelona - really? Maybe 2000km away. The 3rd item is "McCarthys Bar" 1km away - good. Now on 2nd test of same sequence Barcelona is 1st item.

This time I tap the Find button - "Paudies Bar" is maybe 800m way - good, but 2nd & 3rd list items are places in France with "bar" in their name eg. "19800 Bar, France" - bad, and"McCarthys bar" is lost. I now tap SEARCH THIS AREA - only 1 more local bar icon is shown, whereas there are dozens.

When tested with a phone there are only a few search results, but when tested with a tablet there are many more results.

When compared to LoPoints(offline)  with a Locus map there are 20+ bars within 500m.

1) should it even be necessary to tap Find? Just populate list after a pause in typing?

2) should it even be necessary to have a SEARCH THIS AREA button? Wouldn't most common search to be of visible map? When results are empty or scrolled to end of list, maybe the last item is "search wider area"?

3) I think @tapio suggested showing distance to each list item.

4) hover over any Search icon could display a popup or scroll the list otherwise it's not obvious which icon is which.

5) I think it is bad to zoom out (at all) to show icons in the list until one is even tapped, or at least restore original zoom/ position if Back button is pressed.

I hope this is constructive, and not just a rant.

The idea how to find a nearby bar is like this: Type "bar", "pub". Something like "Public service", "Bar, pub" is suggested. These are bars like category of places, whatever name they have. Then if you tap Bar, pub (category), the first item actually suggested, you will see some. No need to use "Find" at all for nearby bars. Not all of bars will pop up necessarily, because in many cases there would be no map, just icons. If you pan or zoom, more bars come and go. If there are many of them, close to each other, only a few are visible. If this does not work in Dingle, then the server must be down or something drastic must be happening.
Problems, or maybe problems:
 - Nobody tells you "zoom in to see them all" (Like Gmaps tells you)
 - Which bar is better, more important, thus visible first or recommended first place?: The Small Bridge or The Dingle Pub? We don't know yet and it is very difficult to answer this for the world wide data.
 - Sometimes only one icon is seen when there is a large cluster of places. Zoom in to see them all.
IMHO this approach makes sense. It has confusing aspects (mostly because we don't know what is important in the real world, and some ordering is virtually random), but it works and is not that pathetic.
The same way this category based search works for waterfalls, shelters, glaciers e.t.c
 1) unless there is some server problem, this is happening.   
A note about ordering: Order by distance exclusively is not used. There is a lot of work to do, but I don't think Barcelona for "Bar" is that irrelevant.

[o]

I am also willing to support, maybe collaborative country-teams might be a solution.

I guess you already have special characters in view, e.g. german umlauts, ö<>oe etc.
tourism is 'Tourimus' and generally the words should also be added separately, like some others already (Essen, Trinken).

Popular searches (fast food, discounters, gas stations, etc.) might help, whatever that might include and it will extend and grow with more and more searches. Sure, advanced and just a filter that might be added anytime somewhere in your lookup-filter-chain. Just a thought.

This is tricky sure, see my vid, searching for 'mc do' needs to  trigger search 'mcdo', whitespaces, and very probably the popular 'Mc Donalds' is meant. Just as stupid example.
'mc dö' might possibly be a search-suggestion as list-item for searches around german locations. Some might be looking for 'Mc Döner', like suggested in the vid, just zillion miles alway.
What if you type 'mill' ? are you searching for categories or specific names, windmill, million..mispelling millitary, and some people also name modern wind turbines a windmill..just for fun. World searches will be versatile
I guess also a list for popular typos might be of help, to suggest replacement or even trigger further searchs.

Special characters - of course, there is "unaccent" procedure. Mc Do - we do not think names of companies are synonyms of categories. This is never done, at least so far. Typos, popular misspellings e.t.c: Yes, especially for short terms guessing what is actually meant can be very, very tricky. Not from technical point of view, but from "how to go about this?" point of view. So I suggest to focus on plain, simple and thoroughly considered configuration. Then the categories suggestion module will be ...not super smart, but definitely good enough.

No hierarchy in the JSON file? If I type "accommodation" for example, should I also expect to see hotel, hostel, motel, camping?

Exactly. Hierarchy exists there and is fully supported, but not defined here. "Hotel" is just hotel, "ubernachtung" is accommodation, "Emergency" is more generic, "Hospital" is specific. e.t.c

@freischneider Here is the exact configuration file that determines what is suggested for typed word (or part of a word). If you do a search for "spo" in this file, you will see what is suggested if you type "spo" in Locus using German language. It is (conceptually) as simple as that. This file was created for us by user Balloni, please take it as a reference. If anyone is interested in improving this file -- also applies to other languages -- that's great, but first: I should properly explain how it all works to editors. (It is important, really, you see it). Also we should set up some collaborative platform for this. Let me know if you want to participate here, please.You cannot view this attachment. 

@Andrew Heard - regarding the "cafe" example - for German language -- and actually all languages except EN, CS, SK -- this all depends entirely on quality of our custom dictionaries (done by a few kind volunteers). Again, some community insight will probably be needed. If a german user types "cafe", no cafe is suggested. Type "Kaffe" or "Bistro", and Cafe (category) is there.
@Tapio - "halde" example: german search (not the "hint" or "suggest" part) has been virtually not working  due to some config error. This has been fixed and "halde" should give you a plenty of results.   

@Andrew Heard, @luce: There is an important distinction: Places named "supermarkt", "laundromat" and places that actually are a supermarket or a laundry room.
 - As some of you pointed out, Locus "object repository" does not contain laundromat as a place for washing clothes. The notion of points of interest in Locus so far has been: Laundromats are not that important in the hiking/biking context. I am not overly concerned about missing "objects" - points of interest. A few millions of poi can be added quite easily. Why there are still some - we combine results from our service and some third party service, which is inconsistent, sure we know it.
 - What you do in the video: You search for places named like "supermarkt". It is the name which is important here. Not what it really is.
 - Try to type "shop", "super", "gas", "petrol", "diesel", "emergen" (or some similar german words). You will get some suggestions, like Supermarket, Gas station (category, all of them) e.t.c. Click it and then you get "overlay" of all supermarkets (Tesco, Billa, whatever name). Not places that are named "supermarket", but places that are supermarkets.
 - There is no assumption that you don't mean search by a name if you type and hit magnifying glass. If this is not clear, that means an important UX message.
 - It would be not convenient to search for nearby fire pits, shelters e.t.c by name. Usually, there is no name.
 - It would be not convenient to search for "Riffugio Auronzo" by browsing all accommodation.
 - It would be confusing to mix both approaches outlined here IMO

4 months and 3 versions ago I reported this issue with the planners
https://forum.locusmap.eu/index.php?msg=69978
still not solved

Military road
access = no
but ...
foot = permissive
https://www.openstreetmap.org/way/220542005

I "relaxed" the policy towards permissive access in hike and bike routing profiles. Routing is already changed on web, the app will soon follow.
https://link.locusmap.app/r/nsuqvf

Time for routing development is coming, I keep notes on this.

I remember this
https://forum.locusmap.eu/index.php?topic=8235.msg69978#msg69978
2 months and 2 versions ago and still not solved.

I tried the openstreetmap planner and all the possible profiles (Valhalla, OSRM, GraphHopper) they allow passage on the military road while locus does not.

@Radim V

As I agree on "One text field" completely, deciding what is important enough to deserve user attention may be just guesswork. Even if we keep track of history by users, it may be easier if you just tell us e.g. "don't want to search my personal content now".

Fully agree - one text input field only.
However, sometimes there is a reason to restrict scope (latest when you are swamped by the all-in results.
Hence, there should be a expando below the text field, that has all buttons ticked by default, so people CAN restrict at will, in case of need. The buttons may mimick the current list of search sources.
Just my 2c :-)

You will also need to improve search. It should work simultaneously in addresses and points.

I completely agree. Locus search is pure usability horror from last century. A proper search is ONE SINGLE TEXT FIELD that simply searches EVERYTHING at once and shows results as they come in.

Making me decide in advance on where I want to search is just wrong on every level imaginable.

You will also need to improve search. It should work simultaneously in addresses and points.

I completely agree. Locus search is pure usability horror from last century. A proper search is ONE SINGLE TEXT FIELD that simply searches EVERYTHING at once and shows results as they come in.

Making me decide in advance on where I want to search is just wrong on every level imaginable.

Even worse is when I start typing, realize I got the wrong "place" to search in, change it, and the input field is cleared - why's that? Makes no sense and would be easy to fix...

Hi all, thanks for reporting this problem! There is of course no "tram"=no_go. The reason why this is happening is the less common surface=chipseal tag. (I think there is no significant occurrence of this surface in Europe, not even creators of the original brouter considered it). Also handling of defaults used to be less than ideal in the car profiles. Today I reviewed surface handling in all car profiles (Publicly visible are just 2 profiles). After new tiles are produced, the change will eventually make it to the public environment - after testing internally (By us).