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/ _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
