[QGIS-Developer] Generic use of QgsLocator and friends?

Mon Oct 9 06:10:11 PDT 2017

On 02-10-17 02:06, Nyall Dawson wrote:
> More implementable suggestions like these would be very welcome :)
> Locator is still very young, and we've got time to tweak the API
> before freeze.

Hi Nyall & other QGIS devs,

(sorry for long email and lot of questions...
tldr; I think qlocator is UBERCOOL!!!! and want to use if for everything)
for a screenie, see:
http://pix.toile-libre.org/upload/original/1507554555.png

I just uploaded a simple Python plugin, initially created to use our
national Geocoder service (PDOK), but for fun also added the Nominatim
(note: end with space, suggest service is not allowed):
http://plugins.qgis.org/plugins/pdoklocator/
and
https://github.com/rduivenvoorde/pdoklocatorplugin
(add http://a.tile.openstreetmap.org/{z}/{x}/{y}.png as xyz layer to
have a nice basemap if you not have it)

I was tempted to add the Google geocoder service too, as that makes it
possible to search for 'kartoza', en you will be sent to the right place
:-)  But I think we first have to take some decisions.

Please install and search for somehwere in The Netherlands ('haarlem',
'2022zj 23') or in the world ('sint maarten'). Note that you need QGIS3
and 'show experimental plugins' checked.

So while doing this a lot of questions popped up, I just share them here
hoping others chime in....

# QUESTION: should we create base (geocoder)classes for the
GeocoderLocator and GeocoderFilter (in cpp or python):
- I created a baseclass for my 2 geocoders, thinking it would be
helpfull to have something like 'mapToResult', but after some initial
tests I think it is maybe only usefull to define some scale presets
(like in current version of this plugin)
- these baseclasses could be python or cpp...

# QUESTION: IF a service does not have a suggest-service (like
Nominatim) adding a space ' ' at the end to force a search
- Nominatim is not supposed to be used as a suggest service (see [0]) in
contrast to the PDOK geocoder), so I decided to do the actual
GET-request as soon as the user added a space in the end to let us know
a searchstring was ended. This is just an idea, if others have better
idea's just let us know

# QUESTION: should we have a (cpp/python?) NetworkAccessManager(factory)
somewhere?
- I took Boundless networkaccessmanager.py to do the HTTP requests. The
advantage of this class is that it mimics http2 lib interface, BUT
actually uses the Qt/QgsNetworking classings...
I think we (as in QGIS) should have such a class in core (be it cpp or
python)

# QUESTION: having different geocoder locators running:
synchron/blocking or asynchron/non-blocking networking?
Because of the fast suggest service of I used the blocking way, but I'm
not sure what the preferred way is here. Also it is not fully clear to
me what to do with running requests (if you type very fast....)

# QUESTION: is a normal plugin the right thing to do?
- in the implementation you actually have to do 2 things:
1) register and deregister the LocatorFilter
2) create and implement the actual QgsLocatorFilter
It is easy to do this as a plugin too (as you can see). I'm ok with
every country implementing its QLocator (do we need a 'term/word' for
it?) and add it as plugin

# QUESTION: should a Filter already have a NetworkAccessManager and an iface
- if implemented as a plugin, you have the iface to actually get a
handle to the mapcanvas etc etc. (you need it so check crs or let themap
zoom/pan) I was wondering if a QgsLocator should not actually be able to
get to the mapcanvas (directly, or via current QgsProject)
Same with an actual NetworkAccessManager...

# QUESTION: why only 3 chars for prefix? (better make this configurable?)
- I think it would be best if a user can decide him/herself to which
locators to use, and thus decide what prefixes to use for them. In my
case I would do: p (for pdok), f (for features), o (for osm/nomanitim)
and g (for google). Others are not so interesting to e...
I think only having the possibility to use 3 character prefixes is not
very usefull?

#    would be cool to be able to have a object-type to scale mapping for
all geocoders, so  you determine for every object type on which z-level
(exact) you want to come... I tried to do that by doing:
    ADDRESS = 750
    STREET = 1500
    ZIP = 3000
    PLACE = 30000
    CITY = 120000
    ISLAND = 250000
    COUNTRY = 4000000
But not sure if this is the best way.

# QUESTION: why short result texts with osm (missing the 'types' of the
object)
- the results (of osm) seem to be cut of rather short?

# QUESTION: should the BaseGeocoderLocator set a point or label? As Option?
- Alesandro's geocoder plugin (for 2.x) put's a point/label in the map.
I was wondering if this should maybe be an (optional) thing in a base
class too? Maybe adding all properties that you receive from the geocoder

# QUESTION: during loading/reloading of the plugin I had a LOT of crashes:
^[QGIS died on signal 11[New LWP 26919]
[New LWP 26920]
[New LWP 26921]
etc
Not sure if this is my install, or has something to do with this plugin,
or the combi of network-threads and application threads...
Please confirm.

Let me now your thoughts/opinions

Ok, that is enough for now, let me know if you reached this sentence :-)

Regards,

Richard Duivenvoorde

[0] https://operations.osmfoundation.org/policies/nominatim/