Messages

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

1) First waypoint is not selected - this is intended behavior. You have to intentionally start planning (right click -> start/finish here, select waypoint, add POI to the route) in order to active "routing mode"

@janaton - I find the user experience with BRouter-web much more intuitive - cursor is already a cross, simply click the 1st point & start. To me & I suspect other users, LoRouter-web is more confusing; the casual user asks themselves "why can't I just click this point to start my route?". Have you got 5 people into the room that haven't yet used LoRouter-web & asked them to create a route (most common use-case) and observed how easy/ hard they found the task?

https://www.wired.com/story/its-not-a-bug-its-a-feature/amp



Inviato dal mio SM-A520F utilizzando Tapatalk

Perhaps you can also select other fields there. I would love not to see "Best Interval".

+1

One more point about this screen.
When I click on the track, this sub-screen opens.
When I select a track in the track manager, the full screen opens.
I don't like the full screen because it can't be swiped down (other users too).

But the question is: when you swipe coming from track manager, where do you want to go? Back in the track manager or on the map?
For me it's the track manager, but the swipe gesture with the map at the top suggests the map

I like the way they calculate the ETA, it's something Locus (app and web) needs to improve.

I'm not sure what they're doing there, but nobody, really nobody who regularly hikes or bikes would think in this way. The usual way to think is "300m up/hour, 500m down/hour", something like that. I don't know how many meters I have to go forward while going 1m up? And then measure this with 2 decimal places (1m up is 7.92m forward)
Maybe a nice UI, but please no such nonsense in Locus. Perhaps you can calculate well with these inputs, but your result will be as bad as your input is.

It is certainly a calculation method that not everyone knows, but this does not mean that it should be considered incorrect or unusable. I find it valid and I use it too albeit in a much more crude way with good results.
D distance measured in km (10 km)
A positive gain in meters (100 meters)
V equivalent flat distance in km
P pace on flat (5.30 min@km)
T estimated time
V = D + A / 100 = 10 + 100/100 = 11
T = V / P = 11 * 5.5 = 60.5 = 1h 0m 30sec
The method used on the site is much more refined, I compared it to my routes and times that I know and I find it very precise, it was enough for me to just set the speed on the flat and I already got an estimate time that differs from real time by 5 min over 1h 30min

Find inspiration here. Has streetname info and multiple route select.
https://www.plotaroute.com/makemearoute
Registration is free and you already get 3 free test attempts.
Download as gpx track + waypoints > Select Directions. (Locus compatible)
https://www.plotaroute.com/makemearoute

Verstuurd vanaf mijn Mi A2 Lite met Tapatalk

Thank you for this link!
I like the way they calculate the ETA, it's something Locus (app and web) needs to improve.

ROUND TRIP:
I used to play with the "round trip" feature, but after the first wow effect I decided it was absolutely useless. Who would ever rely on a random rotation function around a point?
It is not possible to define preferences of any kind, be they historical, naturalistic or cultural, so rather than relying on a random function my choice at a crossroads would be that of the road I like best, at least it would be based on my choices.
Unless real utility can be found for this feature, integrating it with the options I wrote above (and all the complications of the case), it should be removed, useful and solid functionality better than things like this that do nothing but generate doubts in users.
Those who use a GPS and map device usually want to rely on certainties, not on a roll of the dice.
But this is just my thought, maybe someone else found it useful, but for now I haven't seen a single post.

Sonny has provided 1" LIDAR based DEMs for most of Europe. And size difference is not some %, but a factor 8. That is costly, because most of the Locus users are from those areas in Europe ...
I think mountain freaks do know Sonny anyway, and know how to put those 1" files in place. Don't they?

Surely an old nerd, mountain enthusiast like me, knows how to do it on his phone, but it's not for everyone. Nor can I do anything about the data in your cloud, or maybe I can ? 
"That is costly, because most of the Locus users are from those areas in Europe ..."
I can also read it this way: if there are many users who will benefit from it, then the cost may be even more justified.
But of course I see things as a user, I understand that as a company you need to evaluate costs and benefits

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

I therefore suggest you to update the data with the more detailed ones at 1 "where available. Your servers will not suffer from a few more gigs of space occupied and a few more seconds of CPU usage, but you will give a more accurate data to everyone.
In my experience of use, 3 "is sufficient for road use (car, bike), but in the mountains 1" is better if, for example, you walk on the edge of a mountain ridge.
After all, the app allows the use of 1 "srtm (for the user it is only a matter of space occupied) on the cloud / web instead we should always have the best option.

[@lor74cas]

@lor74cas
1) Altitude always in metres - thanks for opening this topic. I have already changed this so you can check it in web planner.
2) Profile icon - thanks for the clarification. I added this on my list
3) Srtm files - I am receiving elevation data from the routing server and I don't know what is used internally for the calculation. I have asked @Radim V so probably he can give you more accurate answer
4) Different elevation gain stats - there must be somehting really wrong. I have tried it to reproduce and I was not able to see more than 1 meter difference (rounding issue between browser and backend). Could you share particular example of track where this is happening? Thanks a lot

1) thank you it works
4) BEFORE 1033 POSITIVE GAIN
https://web.locusmap.app/en/?planner=KYOwPgzgbggg9gBwH4F8AaKDSB3OABYARwBEBzAVwDE4BbAOVKgHUIBvSgTwEM6JCAhFFACiEANb8aKMgBkAxgCcYNACYwA+lDzYZYAC7CEAJTA08pDgGFyYAOLqaAVQA2UALJ7SMAGYpLACz0AKXJCWzkIIIADAC8AeRAIGBioywAPACtLMXUYUiYM5zcogE0Yrjwwf2s9Sq0kAEsAXRAMgB1vOQA1fxpbDgzhdRQ8DhAAZRAGgElvf34QdX4ufxgwUgI4SwBumTgmLmcxBpBSAG49g6OT88vD49OL-fubp6uH2+frx7vvz-fXr8Pm8Xj8vsCgYDwVCAWDYZ8ABINCFwJEotFQjFgrGI5GYvHYgm49FEp44smk7ZAA

and after 1133 POSITIVE GAIN
https://web.locusmap.app/en/?shared_track=NGIxYWMwOGItNmQ5Ny00YjM4LThkYjEtNzcxNDBiM2E3MzczOmIyZjVlOGRlLTY1MTQtNDFjZS04MzdiLTA1MGU0ZGNhNmNkMA..

@Menion I know it's not your job, but where can I write to report that your sites are a mess?
it seems that everything is badly connected, there is a main page, one for live tracking, one for the help desk, one for the forum, one for documentation.
There are at least 3 different types of graphics, many pages once opened have no reference to the main site.
With the arrival of the new version 4 it would have been the right time to do some cleaning.

[@lor74cas]

@lor74cas

2) Use metres only for elevation gain/loss - We will consider it. Please, what is the motivation for you (precision, ..)?
3) Logged in but icon still anonymous - I do not understand. Please, could you give me more info: Thx
4) Elevation chart for saved tracks - sure, it is in progress and should be there soon.
5) Hiding top bar - Good idea, we will consider it but for now more important tasks are on the list
6) More accurate altimetetry calculation - this is more related to the routing itselft. Please, ask here: https://forum.locusmap.eu/index.php?topic=7202.0

2) The altitude is always expressed in meters, the height of the mountains for example is in meters the k2 measures 8611 meters I have never seen it described as the 8.6 km high mountain. It is a practice, for hikers, mountaineers, runners, cyclists ...

3) When I am logged in, in my case for example, the image / icon associated with my account on Google appears, the same one you see associated with my profile on this forum.

6) I was just asking, do you "use the 1" srtm files where available"?

• In the stats panel elevation gain/loss is in km, when over the 1000m, please use always meters
• even if correctly logged in, the icon remains anonymous
• the altimetry graph must also be displayed on the tracks opened in cluod, not only on those created with the planner
• top bar with "locus map beta, THE APP, PLANNER ..." is not necessary and steals space, it would be appropriate to hide it like the other panels
• for a more accurate altimetry calculation I hope you use the 1" srtm files where available

There are several things to fix, but overall it's very responsive and easy to use

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.

https://www.openstreetmap.org/#map=14/62.5564/7.7225&layers=Y
no holes

https://www.openstreetmap.org/#map=14/62.5564/7.7225&layers=C
with holes, and I think Locus uses this one

In the image the mystery unveiled.