Messages

when I tap on the red circle-arrow map icon, two items are listed, tapping the 1st is ignored, tapping the 2nd pans the map to the point. intended?

note, the 2nd search item for "Patisserie" is a record 18,000km away! As mentioned many a time, I'm sure there are far more relevant results.

This composition logic needs rewrite, I agree. The reason why this is happening is something like "We trust the geocoding provider we use in terms of order of results. They know why they ordered results like that." Or there is something I missed. But the most important fact here is this project has seen no development for months and that is the first thing to change.

The current state of "veg_food" in Locus: 1. Places with "vegan" tagging. As mentioned above, that should mean "One full vegan meal at least". 2. Places with diet:vegetarian=only. That means translating is tricky and I make a mental note about that. Basically we wanted to give green V to places that indicate "veggie" people friendliness. But the current state is compromise, of course. We thought Veggie places are different from other minor cuisine distinctions, so they are given extra treatment, being directly search-exposed and being given special icon. (I know, koscher, glutten-free can be seen important by some people too). What we plan to do: POIs have "labels". These are qualities, such as wheelchair accessible, children-friendly e.t.c. Cuisines can be added, so even offline we can see what a restaurant is about.
McDonalds: Believe or not, there is something called McPlant, which is meant to be some veg(an)? burger. Here in Prague they are meant to be served at the airport. I have not been there, but formally: Given the above described logic, some McDonalds are vegan places, at least they say "We serve at least one full vegan meal". For a moment we used some "filter", so McDonalds, KFCs could not be "veggie", whatever they say about themselves but currently this ad-hoc extra logic is not used.

Hi all. I believe some background context would be beneficial to this discussion. When we want to "browse", or "traverse" interactive map content, we deal with a tree-like structure seen on the white picture. So we traverse (in UI) cca 150 nodes. This number will grow over time, but there hardly ever will be 500+ nodes. When we search, using the current approach, we have a name and perhaps some close synonyms attached to every point (node). So no need (ideally) to know what name is used for "brewery". "Beer" works too. And here is the Devil in details in my opinion. These terms (dark picture) are 90% human generated. We have them just for a few languages. Even German can be improved greatly I believe. There are false positives for short terms, but "ho" is hotel, hostel, hospital, hot spring...

Hi Steffen,
Es gibt eine zentrale Idee in deinem Beitrag. Du erwähnst etwas wie ,,weniger komplexe Routenberechnung für Autos, weil hauptsächlich Autobahnen genutzt werden, auf denen es weniger Kreuzungen gibt". Das ist die Idee, die Google Maps verwendet (das weiß ich), und vermutlich viele andere Routing-Engines für Autos auch. BRouter und der von BRouter abgeleitete Router in LM4 (online/offline) verwenden diese Strategie jedoch nicht. Denn BRouter steht für ,,Bicycle Router". Für BRouter sind 100 km gerade Autobahn immer noch eine Serie kleiner Segmente – dieselbe Serie wie ein Wanderweg mit vielen Kreuzungen. BRouter ist von Grund auf langsam. Auch die Komplexität der Routing-Profile spielt hier eine Rolle. Natürlich gibt es eine Lösung für diese langsame Berechnung – die Nutzung von vorab berechneten, kleinen Kacheln, in denen lange Straßenabschnitte vereinfacht sind und Pfade, die für Autos irrelevant sind, weggelassen werden. Aber das wäre zumindest im Moment eine große Änderung für uns.

Hier ist die Idee, die du erfunden hast.
https://en.wikipedia.org/wiki/Contraction_hierarchies

Dobrý den, striktně vzato rozdíly nejsou v použitém algoritmu, ale v tom, jak se pracuje s hodnocením jednotlivých dílčích úseků. Tyhle rozdíly jsou dost velké. Počítá se s povrchem, charakterem cesty a s rozdílem nadmořské výšky (rozdíl je i v hodnocení do kopce/z kopce). Do budoucna se bude brát v potaz i okolí cesty/trailu, ne jen jeho charakter a povrch, takže např. stezka v CHKO bude upřednostněna před (třeba trochu kratší) stezkou skrze třeba vytěžený lom nebo nějaký brownfiled. Touring - preference značených cyklotras, Gravel - polňačky. MTB - je tam posunovátko "dificulty" které nastavuje interně kombinaci vlivů jako převýšení a "šutrovitost", pokud se ví. MTB šoupátko vpravo (technical) předpokládá opravdu technicky ale i fyzicky zdatného jezdce. Tady bych řekl, že je oproti mapám.cz dost rozdíl, v Locusu je "technical" skutečné MTB. Silniční kolo - ano, silnice druhé a třetí třídy (s možností říct, zda chci použít cyklostezky nebo ne). Obecně málokdy je pro nějaký povrch striktní zákaz, spíše je to tak, že např. 100m po šotolině na silničním kole je jako ...2(pro ilustraci) km po asfaltu.

Hi all. The problem is: Neither Brouter or the Locus internal router (LoRouter) can work with osm tagging that has arbitrary value. Both routers only see a large SET of known values. This set is possible to extend, but it is still a limited set. For example in access=private, access=permit the values are "private", "permit". These are known values, of course. In maxheight=3.75, "3.75" is not a known value. For this reason, routing aware of tunnel heights e.t.c is not likely to happen soon, unfortunately. Radim, backend dev.

Dobrý den. Případ les u Jedovnic: Je tam skutečně zákaz vstupu kvůli kalamitě. Jak kalamitu dostal Seznam formou "no-go polygonu" do svých map a plánovače? Podle fcb odkazu na mapách (viz obrázek) nejspíš ručně. O spolehlivé, aktualizované databázi všech možných uzavírek nevíme ani pro ČR, natož třeba pro Evropu nebo dokonce svět. (Locus má uživatele po celém světě a věnovat velké redakční úsilí jen v ČR prostě nestačí). Technicky by rozšíření LoRouteru o možnost uzavírek problém nebyl, problém je management těch uzavírek, a to alespoň pro Evropu. Řešením by bylo pečlivé mapování v OSM datasetu, který náš routing využívá. Pak by nic externího nebylo třeba. (To je nejčistší a správné řešení).   

Hello Lupin.
This is a good point.
Current state of .brf files and lookups.dat can be seen here
There are a few additions in the node section (for the exact reason you mentioned), like safety_rope=yes or ladder=yes. However none of the keys you have named specifically are referenced for nodes now. So this is something to consider, but a few overpass_turbo queries should be done before to check the frequency of their usage.
Short note on how tags are used:
- routing as such
- detection of warnings
- time adjustments for walking profiles
Thanks for your point!   

I have tried routing with the LoRouter without my own shaping points. I set a starting point and then had a circular route suggested. The MTB profile was set. Latest beta from 19.01.2024.
The route is very bad. It runs on roads although there is a gravel path in parallel and even an MTB trail with S1 (red-blue).

I have set all shaping points myself in the past to force the path. I thought I would try again to see if the profile got better. But unfortunately it still doesn't suggest any good MTB trails. So I will probably do everything by hand as I have done since then.

Hi, freischneider
Here is a link to the first half of the route from the attached txt file.
https://link.locusmap.app/r/5o6vai
I can see some places where maybe the cycling route does not need to be strictly followed (while riding MTB).
Please show specifically what is wrong here.
The red blue path we see on your screenshot is followed. (Althougt a path is not followed just because somebody mapped its mtb difficulty).

But unless I have a look into map data, this is just my guess. Please specify the location more.

sure: shared track @ web.locusmap.app-planner

Yes, the segment with warning is a secondary road without a (mapped) sidewalk. 

[But]

Hi!

Is it possible to use the route planner on imported tracks, as opposed to only tracks on the base map (e.g., OSM)?

Example: I have a bunch of tracks which represent various (short) sections of a network of off-trail routes that are not present on OSM. How can I plan a route between arbitrary points using these tracks?

Thanks!

Hi. From the computer science point of view this is certainly doable. The only real challenge is reliable detection of segments intersection. (Assuming all segments are accessible in both directions). But: such a work is a lot of work. The result would be a toy for few people imho. As a learning/hobby project this is a good idea/topic. For practical use I would follow what Michal suggested. 

I planned a route with profile 'walk' and get warned about 'heavy traffic'
The route is also not perfect, see top near scale - might probably be due to osm. I walked the route shortly and was able to use each sidewalk of the street.

BTW is there any way to deactivate these new warnings, i don't need them and map is pumped with unneeded signs?

Hi, because the warning for "heavy traffic" is just a short segment of otherwise identical street, it looks like the sidewalk is not mapped correctly. (There is no warning for secondary roads if there is sidewalk). But unless I have a look into map data, this is just my guess. Please specify the location more.

Hello all. There is a fully automated process that updates (changes e.g. names, websites, opening hours), disables or adds new points of interest. No human interaction involved. The logic may be sometimes a bit complex - e.g. "planed" or "demolished" map features are not added or are disabled, some frequent objects (cliffs, trees) have to be named or marked as a landmark, e.t.c. Yesterday some of you mapped in the osm db the wreck as inaccessible tourist attraction, so in a few days (during next update run) the point with red fence in detail (inaccessible place) should pop up in Locus. There will be no wikipedia - an id pointing to wikidata knowledge graph is currently needed for that. If somebody adds this link to osm, wiki will be processed on the 22 this month. There is already related tourist attraction - a propeller from this ship. Propeller Anyway wrecks in general (not tourist attraction tagged) are not considered and it is a good idea to include them. They will be added in the next batched addition.         

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.

Sorry, the profile is there. I see.