Messages

Dobrý den - rozhledny v online bodech a nemožnost zobrazit je jako body v okolí: To by se mělo brzy změnit, online search v aplikaci významně předěláváme. Offline body: Aha, díky, to nám uteklo. Radim.

 Hello Tobias. If you copy the profile files as you mentioned, they should work, using the in-build LoRouter offline, which is currently based on version 1.6.x of Brouter. Radim.

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

@lor74cas - this denial of access is due to the access=no and foot=permissive character of a military road. It can be fixed and I make a remark for another round of profiles-fixes. But also this is a good example of a segment, where some kind of warning should be issued anyway. A military road can be closed (at least from OSM point of view) anytime. These warnings are something we started to consider.   

Hello all.
@francisco, thanks for your evaluation of trail grades (How much region specific it is?). If the decision of Locus supporting 4x4 vehicles or dual sport bikes is made, we will use it. There is 4UMaps already available in Locus (small areas can be downloaded for offline use) which displays MTB grades. Why we think this 4x4 routing is tricky: In west Europe where most of Locus users reside the legal 4x4 overlanding is virtually impossible due to many mapped and not mapped restrictions and barriers. So there would be the router which produces routes that we know to be very unreliable. In the other parts of the world such profiles may work.   

Sousoší Panny Marie is fixed (Should update during next run). It was missing completely, There is "Memorial" and "Artwork"

Hi, You will be able to change displayed name to something generic and anonymous.

Hi, Josef. First of all, thank you for the gorgeous pictures!
In terms of editing names and possibly another properties of POIs in the Locus directly: We agree that this feature would be awesome. But, as usually this is not an easy thing to do. Why: Currently all 25M POIs worldwide come from two main open-source datasets. OSM project and Wikipedia. What you ("General Laudon") see, is exactly what some user has written 6 years ago as "name" for the memorial. No doubt any edit should not just change value for Locus, it should improve OSM database quality for everyone.
There are dedicated tools for this (Vespucci editor):/https://play.google.com/store/apps/details?id=de.blau.android&hl=en&gl=US, and OSM notes: /https://wiki.openstreetmap.org. OSM/wiki/Notes . OSM notes can be used from Locus already.
We agree this is not user first approach as all is too slow and complicated.

[Currently]

@lor74cas
Yes, I am aware of this (temporary) limitation. Currently the term in the search bar is only matched against names of points in the local-unspecified language and the language of the client. Other tags are not taken into consideration. (Cannot be taken into consideration directly, as the OSM dataset is not the only possible source of data.) How this search is intended to work (and already works internally, with some minor performance issues):
Let us assume:
- Every point belongs to one or more categories.
- English is the language of client (mobile app or web planner user).
- "wate" is the term in the search bar.

1. A localized fulltext search matches "wate" against names (in local language and in english as specified). As you noticed exactly. Currently, this is the end.
2. Another fulltext search matches "wate" against small dictionaries of synonyms (thesaurus). "wate" could mean: waterfall, watermill, drinking_water, fountain, hot_spring. Why fountain, hot_spring? Because somebody has decided that water and hot_spring are semantically close enough. These little sets of synonyms, language specific,  are configurable on the fly, not stored in a hard manner.
So suggestions are proposed after points that match by their names. Are you searching for drinking_water, waterfall, watermill, fountain perhaps?
3. If we chose one of the suggestion, another search runs (Yes, I actually mean waterfall. Yes, i actually mean all accommodation possibilities combined by typing "room"). This time a localized search matches point by their category, not name. Only category is taken into consideration here, as a source of point can be e.g. Wikipedia, which is not tagged by OSM standards.
Hope this makes some sense, I attach some dictionaries (thesauruses), both specific and more generic to make it more clear.

Hi, thanks for sharing the adjusted profile. Currently we are trying to figure out what the expectation for car routing actually is. More car profiles may be coming. The fact is in central Europe we consider the usage of unpaved roads or tracks for cars problematic at least. (Not so well documented restrictions and gates are one of the reason). I will do some review of the legal state of the "unpaved roads" access. Once more feedback similar to yours comes (Which I expect to be the case for i.e. Scandinavia), we may use your local knowledge. Thanks! 

[@lor74cas]

Hi,
@lor74cas
Elevation data for routing: we have altered brouter internals to use our company maintained dataset, which combines enhanced SRTM source (viewfinderpanorama) and some Lidar sources. However the resolution is 3'' only.

One of the most important things when you are outdoors is water. In the screens you can see that even if there are two fountains nearby, selecting the first search result which should theoretically be the closest sends me more than 50km away.

Thanks for reporting this. The problem here is: Currently the search only uses "names", so only the objects that have the term "water" or similar among their names in two languages ("local" language and "English" in this case) are found. The two nearby fountains are not named at all - "Drinking water" is the overall category of them. More complex search using keywords is needed here. It is already done internally. Sorting: we don't think sorting based on distance entirely is a way to go. More content (Wikipedia, user related) is coming, so "close calls in terms of distance" are resolved based on content.

Hi, regarding more generic qualities of places: there already are "attributes" - icons and short verbal description of features like WLAN access, wheelchair accessibility, smoking ... these are visible in the point detail, if present at all (in well mapped areas there are more of them). Diet is already somehow expressed by icons (veg. is "V", non veg. is "fork and knife"). Anyway being more specific about cuisine would be good, I agree. Probably a feature to do for next version of the database.