[APP] - version 4.1.+ ( 4. 5. 2021 )

[Radim V]

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

[lor74cas]

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

[Viajero Perdido]

Quiet thread lately.  The app is stable, and hopefully the team is enjoying some outdoor time. 

I figured out why the keyboard wasn't popping up when I needed to enter a name for a new waypoint.  It was an interaction with the lock screen, which Locus is set to bypass.  Since the keyboard is a separate app, it needed the phone unlocked, but for some reason wasn't accomplishing that.

My workaround: hit the Home button, which pops up the lock screen long enough for it to recognize my face.  Back to Locus, keyboard is open as expected.  I don't consider this a bug in Locus.

[Menion]

New version 4.1.1.1 published to Google Drive Beta directory yesterday.

Mainly major update in the "Web services library", we hope this will bring/highlight some useful and interesting web maps.

----

@Viajero Perdido
Outdoor time ... this should be nice 

The keyboard problem makes sense, interesting. I have no idea how to bypass this. The app is able to hack security lock screen only for its own process (and also not on all devices), so this most probably does not have any simple solution as I know.

[Andrew Heard]

4.1.1.1_1016_beta @menion - "insert middle point for empty tracks loaded into route planner" - I can't confirm this - test: add start point > add (simple) end point > menu > Route Stats > ">" button > Itinerary > "No waypoints in this track"?

[Menion]

It is about the editing of already saved, usually recorded, or imported routes, that do not have any navigation commands or any old plan stored inside. In this case, such track loaded into route planner will have a single shaping point placed in the middle.
The reason for this is mainly in the case of rounded routes, where simple drag or adding a new via-point caused recompute of the whole route.

[baegas]

Maps cannot be overlaid in beta version 4.1.1.1
And the mapsforge type beta map is not well visible.

[slarti76]

More a question than a report:
I recently noticed that a point I have in the database included Opening Times that were displayed specially, like in Google. That's very nice and useful, but I have no idea how that got there! I cannot edit this data in the Edit Point screen. I don't remember how I created that point, probably from LoPoints, but when I looked at the same point in LoPoint db, there were no Opening Times.
So, how did this data get there, and more importantly: How can I add them myself? Opening Times are what I most often put into the description field, and having them in a standard format that Locus can display accordingly ("Closed now", "Open until 9pm", etc.) would be just fantastic!!!

[Menion]

@baegas
You will have to write me more info ...

@slarti76
hehe, this is really old feature . It was in old times when the app used the so-called "Google Places API". The feature was removed because a) Locus violated Google's terms of use and b) service is now really over-priced.

Online LoPoints now fully support opening times and once we switch offline LoPoints to the new system (not sure if this year), it will be available also offline.
The best how to get this into the app is by editing OpenStreetMap directly!

Editing in the app is doable, but is it really needed? Is there any reason to have opening times for any point in the app and do not have it in the OpenStreetMap data?

[slarti76]

@slarti76
hehe, this is really old feature . It was in old times when the app used the so-called "Google Places API". The feature was removed because a) Locus violated Google's terms of use and b) service is now really over-priced.

I do remember that, but didn't want to bloat my post by mentioning this. But I would have assumed you removed that stuff with the new track screen, so I was surprised it even got an updated look, too

Online LoPoints now fully support opening times and once we switch offline LoPoints to the new system (not sure if this year), it will be available also offline.
The best how to get this into the app is by editing OpenStreetMap directly!

Editing in the app is doable, but is it really needed? Is there any reason to have opening times for any point in the app and do not have it in the OpenStreetMap data?

Well, for one thing, editing OSM data for many is still intimidating. And I'm more talking about points I added to my local database. I mean, on vacation I would see a restaurant that perhaps doesn't even have an OSM entry, so I add it to my database and want to add opening times for future reference (like, tomorrow ). If I first have to add the point to OSM with all data, and then how quickly will it appear in Locus?
If it were a LoPoint-only thing, ok - but right now when you add the point to your local DB, this data is copied, but not editable. Surely this is confusing to any user: There's things shown that is not editable.

And, my other point would be, that you could use the same argument for URL, phone and email fields - you still offer to edit them in Locus directly...

[Menion]

I've got your point. Comparing opening hours to phone/email is not ideal. Phone/email may be simply added to a place where a friend lives, to anything interesting for you. Opening hours belong to any public service that should be in the OSM in all cases. And if it isn't? Add it there.

When it appears? Good question. I think that Radim does updates 3x per week in the online LoPoints database.

Anyway, I really think that contribution to OSM is a top priority. Maybe some easier integration with app like StreetComplete may be useful solution?

[freischneider]

I've got your point. Comparing opening hours to phone/email is not ideal. Phone/email may be simply added to a place where a friend lives, to anything interesting for you. Opening hours belong to any public service that should be in the OSM in all cases. And if it isn't? Add it there.

When it appears? Good question. I think that Radim does updates 3x per week in the online LoPoints database.

Anyway, I really think that contribution to OSM is a top priority. Maybe some easier integration with app like StreetComplete may be useful solution?

There is a better app like StreetCompete. It is OSM go. https://play.google.com/store/apps/details?id=fr.dogeo.osmgo&hl=de&gl=US
Also available as a website: https://osmgo.com/#/main
Editing POIs is much easier there. And it is translated into the national language for some countries.
I could imagine that Locus will work together with the APP in the future.
I go to edit in the LoPOI and the corresponding app opens and calls up the POI.
This will probably require an API in OSMgo? I think there are 2 ways of transmission. Once the OSM ID of the POI? Or the coordinates.
I just don't know how to contact the programmer of OSMGo and what to ask him.
It would be a big step towards better OSM data. Every user can change OSM data very easily. A lot is already given and you just have to select the tags.

[baegas]

@baegas
You will have to write me more info ...

In version 4.1.1, the overlay on the background map works fine.
In this beta version 4.1.1.1, even if any map is loaded on the background map, only the background map is visible and the imported map is not overlaid.
And the specific mapsforge is not visible.
Attached the link to the tested vector map below

https://drive.google.com/file/d/1d4uOy-BYdB3txKrjJT4kyXan9XrraLDu/view?usp=sharing

[slarti76]

Anyway, I really think that contribution to OSM is a top priority. Maybe some easier integration with app like StreetComplete may be useful solution?

That sounds like an idea

[Viajero Perdido]

I really think that contribution to OSM is a top priority.

I'm always happy to hear that. 

A quick "win" would be to add a predefined "Inspect OSM" option to Quick Bookmarks, as discussed recently.

Now that I've discovered the feature - and added the bookmark URL manually - I use it all the time.  My workflow: see something suspicious on the vector map, inspect OSM, decide fix is needed, create point in Locus to remind myself for later editing on big-screen JOSM.  (Sync makes this very convenient.)  But I have no desire to actually edit OSM in Locus.

PS, a very minor inconvenience (bug?):  After editing in JOSM, I move the reminder point to a "done" folder, then hide it.  But "Hide" is disabled after the move, until I tap the point again.  Then I can hide it.