Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Radim V

#16
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".
Quote from: michaelbechtold on March 11, 2023, 15:53:21Fully 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 :-)

Quote from: joeloc on March 11, 2023, 15:32:02
Quote from: Žajdlík Josef on March 10, 2023, 10:16:41You 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.
Quote from: slarti76 on March 13, 2023, 09:41:18
Quote from: joeloc on March 11, 2023, 15:32:02
Quote from: Žajdlík Josef on March 10, 2023, 10:16:41You 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...
The following users thanked this post: Andrew Heard
#17
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).   
The following users thanked this post: Andrew Heard, lor74cas
#18
Locus Map / Re: [APP] - version 4.13.+ ( 12/2022 )
December 30, 2022, 10:34:36
@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.   
The following users thanked this post: lor74cas
#19
@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.
The following users thanked this post: Andrew Heard, lor74cas
#20
Web portal & sync / Re: Web planner / portal
April 09, 2021, 08:54:51
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.
The following users thanked this post: lor74cas, janaton
#21
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. 
The following users thanked this post: freischneider
#22
Quote from: tapio on March 03, 2021, 09:59:49
Can the internal profiles be accessed from file system side? Didn't find them. Just curious.
No, internal profiles are hidden from user. Anyway we keep them in sync with above mentioned public repository. You can modify those publicly available profiles to your liking and place them in Locus/router/profiles2. Then in advanced settings the app recognizes them.
The following users thanked this post: Tapio
#23
Hi all,
we have updated the set of routing profiles available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Profiles are of course credited inside.
Now we want to ask for some feedback again: More specifically, In landscape (both flat and mountains) you are familiar with:
-Is the MTB profile in your opinion: Too easy, too hard, or just about right and safe for an average biker?
-There will be not much distinction between walking and hiking in flat landscape but  there should be some distinction in well mapped mountain areas. Do the results suit their activities?
-road cycling: roads too busy?
-any reason you would not use a particular profile for intended activity?
You can try them here:
https://web.locusmap.app/en/
And of course using brouter-web directly.
Thanks!
The following users thanked this post: Tapio