Messages

I agree, as some unnamed inhabitants of the unnamed continent may use Locus this way and some 15 page disclaimer should be used, like what you should not do with a  microwave oven.

I personally insert short comments in similar spirit for some my challenging (on demand) profiles for MTB, that following routes given by that profile may cause heavy fatique, injury or even death of inexperienced users.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

Don't use the microwave when hiking! 

If a tool fails because it was used, where it should not be, it is not the fault of the tool.

If there is a profile for hiking and the ETA is calculated, this is a tool that any inexperienced person can consider suitable. Not everyone who uses Locus is experienced hikers, some of them may be tricked into trusting the ETA and risk getting into trouble. I hope it never happens, but if someone gets hurt or needs to ask for help because they based their hike on the Locus ETA estimate, without any warning in the app, who would legally answer?
I think a warning is needed in the app, to protect developers from possible legal action, but even more so to clarify that ETA is not an exact science, but a rough estimate.

However, I think the ETA estimate is too optimistic, 1500 meters of positive difference in altitude in 2 hours, means 750 meters per hour. The estimate should be at least 3 hours, so there is a 1/3 excess. A mistake of this kind becomes dangerous on long journeys, especially in autumn with the hours of light that are decreasing. So be careful to plan with too much trust in the ETA, even the same planner should warn the user that the ETA is only an estimate and that travel times must be calculated based on their abilities, the type of terrain and weather conditions. This IMHO of a now old hiker.

Good job, I like it.
The imported tracks do not have the timestamp, neither on the track itself in terms of statistics nor the points that compose it.
We need the undo button.

Hello Michael. This option was in the app maybe two years ago ... for about an week. Then Google removed Locus Map from the Google Play and we had to remove this function. Reason? Locus Map does not belong into kind of apps that are able to request exclude from the battery optimization...

Sent from my Pixel 5 using Tapatalk

Hello,
a few months ago I used this app https://play.google.com/store/apps/details?id=com.redbull.wingsforlifeworldrun&gl=IT to participate in a virtual race. At the time of installation it proposes a verification system in order to avoid blocking caused by energy saving, maybe it can be an inspiration to you. The app is relevant to the same scope as Locus.

Little bug.  Going cross-country (using the zig-zag icon) doesn't record any elevation gain.  On the Android, this works as expected.

+1
this is very annoying

Hello,
in the planner did you plan to insert a sort of search tool?
I think it'd be useful in the planner panel or as a icon

Upsidedown

Inviato dal mio SM-A520F utilizzando Tapatalk

...

@lor74cas
Expanding and collapsing waypoints - is it still happening? I can not reproduce it (Chrome, Firefox, Safari)

now it works fine, but meanwhile there was an update of chrome browser on ubuntu lts 20.04

Hello,
once the list of points has been expanded, I can no longer group it again.

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

It makes sense and it might work, but only by seeing it in action would I be able to tell you if it is correct or functional for research purposes.
Is it possible somehow to query locally on the db of the points to see the information relating to the categories? In this way in the areas I know I can check how much information is available and how it is grouped.

Search tool:
From what I see the same problem that I found in the webplanner is also present in the Locus app.
All searches are performed on the basis of the name key, but a lot of information is present in the other keys and therefore these places are not found.
In OSM many nodes do not have the name tag, but have the amenity key valued therefore Locus does not identify these values.
An example above all, of relevant importance for those who are outdoors is the search for a source of water. This public drinking fountain has no name, but is tagged as amenity = drinking_water

Code Select Expand

<osm version = "0.6" generator = "CGImap 0.8.3 (1793695 spike-08.openstreetmap.org)" copyright = "OpenStreetMap and contributors" attribution = "http://www.openstreetmap.org/copyright" license = " http://opendatacommons.org/licenses/odbl/1-0/ ">
<node id = "6312687085" visible = "true" version = "1" changeset = "67715997" timestamp = "2019-03-02T15: 22: 00Z" user = "Cascafico" uid = "361003" lat = "45.9451386" lon = "13.6199964">
<tag k = "access" v = "yes" />
<tag k = "amenity" v = "drinking_water" />
<tag k = "drinking_water" v = "yes" />
<tag k = "indoor" v = "no" />
</node>
</osm>

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.

then waiting for the other keys / attributes present for the objects in osm to be recognized, I will modify the names in osm so that they are also recognized in locus

When a user logs into the portal and synchronizes, the information relating to the units of measure should also be able to be exchanged. In this way, the window for choosing the units of measurement would only be necessary for users who are not logged in.
For example, now in the panel it is not possible to choose whether kj or kcal.

Upsidedown, device vertical

Inviato dal mio SM-A520F utilizzando Tapatalk