Add go to coordinate feature to search bar

[nirvn]

GIF time:

This PR adds the capability to type and go to a given coordinate through QField's search bar. Accepted coordinates:

• a pair of longitude and latitude decimals
• a pair of degree minute second coordinates
• a pair of x y project CRS coordinates

The parsing of numbers is locale aware, allowing users to use their language's decimal and thousand separators.

[qfield-fairy]

Uploaded test apks for

• armv7
• x86
• arm64_v8a
• x86_64

[m-kuhn]

🎉 🔍 🎯

[VxTedxV]

Tried on bee farming demo project as shown on the gif but doesn't seem to work as expected : only "Map CRS" is suggested and selecting this one leads to nowhere. Local parsing issue ? Tried with another kind of parsing but it doesn't suggest anything. Also tried on a local project with another CRS (EPSG:2154, Lambert 93) using known coordinates and it still didn't work.

[nirvn]

Can you give the coordinate string you used which didn't parse as WGS84? I suspect you might have used the Google lat lon which would be parsed as lon lat by QField (and incidentally QGIS).

"Leading to nowhere" merely means your project has nothing at the X Y of the Map CRS (very likely in any case :) )

[VxTedxV]

Simple bee demo project, same coordinates as on your gif. Result :

[m-kuhn]

Possibly a locale issue?

[nirvn]

Your android phone is set to which language? France/French?

[m-kuhn]

@nirvn should the "Map CRS" also be filtered by if the numbers fall within the extent of the CRS?

[nirvn]

@m-kuhn , a given CRS' extent (i.e. QgsCoordinateReferenceSystem::bounds() ) is in WGS84m which is no help to us in terms of filtering out Xs and Ys we assume are in the map CRS to begin with. Do you have a better idea?

I think this once again highlights the need for QgsProject to have some extent property.

[m-kuhn]

Are the projected bounds not good enough?

[m-kuhn]

I think this once again highlights the need for QgsProject to have some extent property.

Unless set explicitly by the user we have two problems:

• worldwide background maps
• in the beginning empty/small datasets which are incrementally filled by the user

[nirvn]

The locator correctly register the coordinates as 9.2523 and 46.8072, but fails to add the WGS84 result. Looking at the code, the only way that could happen is if the coordinate transform (from WGS84 to project CRS) fails here: https://github.com/opengisch/QField/pull/1181/files#diff-c95c177df25569bad8ba579f2adcfa02R122

It doesn't fail on my machine, nor on QGIS. I'll try later on my smartphone.

[VxTedxV]

Your android phone is set to which language? France/French?

yes

[m-kuhn]

@VxTedxV fix upcoming in #1191

[VxTedxV]

Tried. WGS84 works on demo project.
Not sure how CRS should be shown in other projects : should recognize the project CRS to search for coordinates ? In my EPSG:2154 CRS (Lambert93) project, if I enter WGS84 coordinates, it works (very slow). If I enter XY coordinates in the project projection, it only suggests "map CRS" (no Lambert93 CRS EPSG:2154) in a weird parsing format :

[nirvn]

@VxTedxV , glad to hear the WGS84 issue has been addressed (thanks for raising it BTW, you've likely helped fix mysterious issues in other parts of QField :) ).

The "weird parsing format" is your French locale 😉 (i.e. thousands separator -> space, decimals separator -> comma).

Regarding the use of "Map CRS" as label vs. the project's CRS friendly string (i.e. Lambert93, EPSG:2154), I've relied on the former as there's rarely enough horizontal space to add much more than that. Your screenshot is a good example of that, using Lambert93 EPSG:2154 would end up with elides, chopping off half of the label here.

IMHO, most users will not really care about the project CRS either because they are merely viewing a project and have little understanding of a "CRS", or because they already know which CRS the project is in.

Would "Project CRS" or "Canvas CRS" be better than "Map CRS"?

[nirvn]

@VxTedxV , oh BTW, when you say it works "very slow", what does that mean?

[VxTedxV]

The "weird parsing format" is your French locale 😉 (i.e. thousands separator -> space, decimals separator -> comma).

OK. If comma is the decimal separator (which is not in my WGS84 test !), what is the one to separate X from Y ?

Regarding the use of "Map CRS" as label vs. the project's CRS friendly string (i.e. Lambert93, EPSG:2154), I've relied on the former as there's rarely enough horizontal space to add much more than that. Your screenshot is a good example of that, using Lambert93 EPSG:2154 would end up with elides, chopping off half of the label here.

IMHO, most users will not really care about the project CRS either because they are merely viewing a project and have little understanding of a "CRS", or because they already know which CRS the project is in.

Would "Project CRS" or "Canvas CRS" be better than "Map CRS"?

I understand the use of a generic label. I think "Project CRS" is closer to QGis but it's OK with "Map CRS"

@VxTedxV , oh BTW, when you say it works "very slow", what does that mean?

On demo project, it's fast.
On my project containing a lot of layers, when typing coordinates, it takes several seconds (60-90) to display a suggestion. Even after making a suggestion the buffering circle still spins a long time (even after opening another project !). It also spins some time after force stopping searching.

[nirvn]

@VxTedxV , ah, that's interesting -- on your large projects, do you have remotely accessed layers (i.e. postgis, oracle, mysql, mssql)?

The problem there would be that the list waits until it goes through all the layers (looking for a matching feature based on display name). I thought those should happen in parallel.

[m-kuhn]

@nirvn can we prioritize a "known-fast" operation such as coordinate go to results?

[nirvn]

@m-kuhn , I thought the locator was emitting results as individual filters were finding those. I'll have a look

[nirvn]

Here, you can actually see the goto locator emits it's results while the spinner is still on waiting for the feature locator to go through features:

[VxTedxV]

@VxTedxV , ah, that's interesting -- on your large projects, do you have remotely accessed layers (i.e. postgis, oracle, mysql, mssql)?

None. If you want me to, I can record a video to see what I experienced (90% of the long video would be looking at the wheel spinning !)

PS : you rock guys with all you do !

[nirvn]

@VxTedxV , so, long story short, locator filters are managed by the OS scheduler. When there are available threads / cores, it'll run in parallel, otherwise sequential. Not sure how much control we have over this.

In any case, you can use the "goto" prefix to only trigger a coordinate search. E.g., typing "goto 12.345,123.123" should make things amazingly fast.

[VxTedxV]

In any case, you can use the "goto" prefix to only trigger a coordinate search. E.g., typing "goto 12.345,123.123" should make things amazingly fast.

should but doesn't 😢 (about 70sec)

[nirvn]

@VxTedxV , what is the brand and model of your phone?

[nirvn]

Also, if you want to curate your project some more, you can remove a bunch of layers from being "searchable" via project properties dialog in QGIS, so searching becomes faster.

[VxTedxV]

@VxTedxV , what is the brand and model of your phone?

Samsung Galaxy Xcover4

[nirvn]

@VxTedxV , if you have a minute, try this APK #1197 (comment) -- should make things faster for you.

[VxTedxV]

Just tested. But not faster :/ I'll make some other tries in the next days...

[nirvn]

@VxTedxV , one more test: with the APK I linked to above, can you test the updated prefix, i.e. 'go 9.1203, 10.2039' (replace lon,lat with whatever you feel good with). Now that the prefix is only two characters, in theory typing 'golon,lat' should avoid triggering feature search altogether.

[VxTedxV]

Yes ! Instant recognition of coordinates with this "go" prefix 🎉

[nirvn]

@VxTedxV , good. As mentioned above, you should probably tweak your project searchable layers settings too regardless of this addressed issue 👍

If you're game, here's something you could do: disable the searchable flag for layers in your large project one by one. You'll likely find one layer that creates this 70sec(?!) delay in getting search results. When you find that layer, let us know, there might be another issue that could be addressed on the QGIS side of things.