Re: [QGIS-Developer] [Qgis-psc] Request for Change of UserAgent
I would really like to understand (i.e. get an explanation) from the OSM admins as to why a user agent that explicitly identifies itself as QGIS like we have now is not enough for them before moving forward. Being a web admin/developer myself, I can hardly find a reason why that's not enough. I'm more curious than anything else, lots of love to the great OSM guys :) Math On Thu, Feb 21, 2019 at 2:51 PM Richard Duivenvoorde wrote: > On 21/02/2019 00.20, Nyall Dawson wrote: > > On Thu, 21 Feb 2019 at 02:30, Richard Duivenvoorde > wrote: > >> > >> Hi Devs, PSC, > >> > >> I had a short talk on IRC to 'Firefishy' the person who runs > >> tile.openstreetmap.org CDN > >> (in bcc, and see: http://irclogs.geoapt.com/qgis/%23qgis.2019-02-20.log > ) > >> > >> In short: he/osm has an issue with QGIS using 'Mozilla/5.0 ' as > >> User-Agent header, but QGIS NOT behaving as a true browser. > > > > Don't we already append "QGIS" to the end of the Mozilla/5.0 string? > > (Firefishy/Grant in bcc) > > Yes we have, but it is for OSM admins still to difficult to distinguish > apparently, AND it makes it more difficult that we say we are a browser > but do not act as one. > > Maybe Jorge's proposal is best: for Nominatim and OSM servers we do > another UserAgent? > > Regards, > > Richard Duivenvoorde > ___ > Qgis-psc mailing list > qgis-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/qgis-psc ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [Qgis-psc] Request for Change of UserAgent
On 21/02/2019 00.20, Nyall Dawson wrote: > On Thu, 21 Feb 2019 at 02:30, Richard Duivenvoorde > wrote: >> >> Hi Devs, PSC, >> >> I had a short talk on IRC to 'Firefishy' the person who runs >> tile.openstreetmap.org CDN >> (in bcc, and see: http://irclogs.geoapt.com/qgis/%23qgis.2019-02-20.log) >> >> In short: he/osm has an issue with QGIS using 'Mozilla/5.0 ' as >> User-Agent header, but QGIS NOT behaving as a true browser. > > Don't we already append "QGIS" to the end of the Mozilla/5.0 string? (Firefishy/Grant in bcc) Yes we have, but it is for OSM admins still to difficult to distinguish apparently, AND it makes it more difficult that we say we are a browser but do not act as one. Maybe Jorge's proposal is best: for Nominatim and OSM servers we do another UserAgent? Regards, Richard Duivenvoorde ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QgsProcessingAlgorithm createInstance
On Thu, 21 Feb 2019 at 07:30, Caio Hamamura wrote: > > QgsProcessingAlgorithm needs to implement this useless method > (createInstance) in my view of point. > > Why do we even need the createInstance method? Couldn’t it be generic: > > def createInstance(self): > return self.__class__() QgsProcessingAlgorithm is a c++ class, which has no concept of metaclasses and so requires subclasses to manually implement this method. But it should be possible to bake this into the PyQGIS bindings alone - see https://github.com/qgis/QGIS/pull/9226 Nyall > > Greetings, > Caio Hamamura > > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [Qgis-psc] Request for Change of UserAgent
On Thu, 21 Feb 2019 at 02:30, Richard Duivenvoorde wrote: > > Hi Devs, PSC, > > I had a short talk on IRC to 'Firefishy' the person who runs > tile.openstreetmap.org CDN > (in bcc, and see: http://irclogs.geoapt.com/qgis/%23qgis.2019-02-20.log) > > In short: he/osm has an issue with QGIS using 'Mozilla/5.0 ' as > User-Agent header, but QGIS NOT behaving as a true browser. Don't we already append "QGIS" to the end of the Mozilla/5.0 string? Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Request for Change of UserAgent
Hi Richard, Each user can change the UserAgent, as ElPaso pointed out (under Advanced settings). But you are suggesting to start distributing QGIS with a different default other than "Mozilla/5.0", right? Which kind of UserAgent you think is a good one? "QGIS "? We can also add another default setting (not difficult to implement) to use a specific UserAgent string when using te OpenStreetMap tile service, and keep the default for all other services. Something like: connections-xyz\OpenStreetMap\useragent=QGIS Regards, Jorge Às 16:30 de 20/02/19, Richard Duivenvoorde escreveu: > Hi Devs, PSC, > > I had a short talk on IRC to 'Firefishy' the person who runs > tile.openstreetmap.org CDN > (in bcc, and see: http://irclogs.geoapt.com/qgis/%23qgis.2019-02-20.log) > > In short: he/osm has an issue with QGIS using 'Mozilla/5.0 ' as > User-Agent header, but QGIS NOT behaving as a true browser. > > He explains that the tricks to create their abuse filters do not work on > QGIS because (for example) we do not honor cookies. > > I asked this earlier: > > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Do-we-have-a-User-Agent-string-for-QGIS-td5360740.html > > But in my opinion now is time to change our default UserAgent. > > In the email thread above people were afraid that certain wms proxies > would block us, but I think we should just try. > > IF we have proxy troubles, we can change the UserAgent per service? For > example change the UserAgent only for OSM related services. > Mmm, is it possible to do that via Python... > > I think that we should honor requests from a colleague-FOSS-service. He > notes that they are exceeding 17000 tile requests per second at peaks... > > Regards, > > Richard Duivenvoorde > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > J. Gustavo -- Jorge Gustavo Rocha Departamento de Informática Universidade do Minho 4710-057 Braga Tel: +351 253604480 Fax: +351 253604471 Móvel: +351 910333888 skype: nabocudnosor ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3
On Thu, 21 Feb 2019 at 00:51, Thomas Baumann wrote: > > Hi Nyall, > > thanks for your feedback. > You are right that some of my examples were not ideal to explain what I > meant, so I try to explain it a bit better this time ;-) Thanks - it's much appreciated! > create a vectorlayer > > Something like: > > https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L24 Ah, that one IS a source of pain. QGIS 3.0 makes it easier with new_empty_memory_layer = QgsMemoryDataProvider.createMemoryLayer( ... ) and new_memory_layer_with_copy_of_features = source_layer.materialize( QgsFeatureRequest().setFilterExpression( ... ) ) You'd still need to follow these up with a call to QgsVectorFileWriter to save as a disk based format. There's some trickiness here because with some disk formats it's not possible to create an empty layer upfront -- e.g. geojson. You have to have some features ready to initially populate that layer with at time of creation. I'd be interested to hear any ideas for "ultimate wishlist" api here? > Example2: For loading layer I meant something like > > https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L7: ... This approach is somewhat of a hack, which is why I wouldn't like to see it as part of any "officially supported" python library. Really, API for doing this belongs in core QGIS API itself (covered by appropriate documentation + unit tests, of course!) > Example3: Iterate through layers: ... > So if there would be a pyqgis-commons library where I would know that I just > have to call a function "get_visible_layers" instead of using [l.layer() for > l in > QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()] I > probably could use this in my next plugin without having to search/google how > to do this. Right - but again, this doesn't belong in a Python specific library. What we need here is a core API addition "visibleLayers": visible_layers = QgsProject.instance().layerTreeRoot().visibleLayers() > Example4: show messages / log messages: > One other example would be the function "display_warning_message_bar" from > the inasafe-utilities where I can show a short message and also provide a > button to show more details about a warning: > https://github.com/inasafe/inasafe/blob/bd00bfeac510722b427544b186bfa10861749e51/safe/utilities/qgis_utilities.py#L132 Once again, I think this could easily be in the c++ API, so that both Python and c++ code could take advantage of it. I don't see anything Python-specific here. > Example5: Settings: > Here I hat something in mind like the qgis-settingsmanager of opengis ( > https://github.com/opengisch/qgissettingmanager ). > I know it is not only a collection of python-/pyqt-functions but a whole > python module but I still it is an example of how functionalities are > provided to make the development of plugins easier. Yes, that one *is* nice. I think Denis originally intended that to be made available in the default PyQGIS library, but I suspect just ran out of time. > So it is always about providing some helper functions that I could also write > by myself but which will save time during development and can help me to do > the things in a consistent way in all of my plugins. Right, but I think it's very important to differentiate here between: 1. API additions which are useful in all contexts (c++ and Python) 2. Python specific API additions, which make use of Python only functionality like decorators, exceptions, and context managers > > >> >> I'm not saying we can't improve the PyQGIS experience, but I don't >> personally see these as good candidates. >> >> I think we have a LOT of work to do with things like: >> - throwing proper exceptions instead of crashing/returning "None" >> values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should >> ideally raise an exception for invalid wkt instead of returning a null >> geometry) >> - providing Python-esque things like __repr__ methods, __len__, [] >> operators (which behave in a python style, e.g. with -1 returning the >> last item), iterators, etc >> - providing more "context managers" (e.g. with : #something ) > > > I don't have such a deep insight in the QGIS-codebase but I guess this would > probably have to be done in the C++-part of QGIS, wouldn't it? Sometimes, or sometimes it's done like this: https://github.com/qgis/QGIS/blob/master/python/core/__init__.py.in > I agree. Even if the PyQGIS-Documentation is now much better than in the past > for me often some short examples like the ones from Thomas Gratier are really > helpful to know how to proceed: > https://webgeodatavore.github.io/pyqgis-samples/ I'd love to see discussion on how we can merge this awesome resource into the new PyQGIS documentation. Together they'd make an awesome resource! Nyall > > So I see three ideas here: > > - provide a collection
[QGIS-Developer] QgsProcessingAlgorithm createInstance
QgsProcessingAlgorithm needs to implement this useless method (createInstance) in my view of point. Why do we even need the createInstance method? Couldn’t it be generic: def createInstance(self): return self.__class__() Greetings, Caio Hamamura ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Request for Change of UserAgent
Hi Richard, Sounds fair to me, you can put the user agent string setting ( /qgis/networkAndProxy/userAgent ) in global_settings.ini, no need to rebuild. https://github.com/qgis/QGIS/blob/master/resources/qgis_global_settings.ini On Wed, Feb 20, 2019 at 5:30 PM Richard Duivenvoorde wrote: > Hi Devs, PSC, > > I had a short talk on IRC to 'Firefishy' the person who runs > tile.openstreetmap.org CDN > (in bcc, and see: http://irclogs.geoapt.com/qgis/%23qgis.2019-02-20.log) > > In short: he/osm has an issue with QGIS using 'Mozilla/5.0 ' as > User-Agent header, but QGIS NOT behaving as a true browser. > > He explains that the tricks to create their abuse filters do not work on > QGIS because (for example) we do not honor cookies. > > I asked this earlier: > > > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Do-we-have-a-User-Agent-string-for-QGIS-td5360740.html > > But in my opinion now is time to change our default UserAgent. > > In the email thread above people were afraid that certain wms proxies > would block us, but I think we should just try. > > IF we have proxy troubles, we can change the UserAgent per service? For > example change the UserAgent only for OSM related services. > Mmm, is it possible to do that via Python... > > I think that we should honor requests from a colleague-FOSS-service. He > notes that they are exceeding 17000 tile requests per second at peaks... > > Regards, > > Richard Duivenvoorde > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alessandro Pasotti w3: www.itopen.it ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Request for Change of UserAgent
Hi Devs, PSC, I had a short talk on IRC to 'Firefishy' the person who runs tile.openstreetmap.org CDN (in bcc, and see: http://irclogs.geoapt.com/qgis/%23qgis.2019-02-20.log) In short: he/osm has an issue with QGIS using 'Mozilla/5.0 ' as User-Agent header, but QGIS NOT behaving as a true browser. He explains that the tricks to create their abuse filters do not work on QGIS because (for example) we do not honor cookies. I asked this earlier: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Do-we-have-a-User-Agent-string-for-QGIS-td5360740.html But in my opinion now is time to change our default UserAgent. In the email thread above people were afraid that certain wms proxies would block us, but I think we should just try. IF we have proxy troubles, we can change the UserAgent per service? For example change the UserAgent only for OSM related services. Mmm, is it possible to do that via Python... I think that we should honor requests from a colleague-FOSS-service. He notes that they are exceeding 17000 tile requests per second at peaks... Regards, Richard Duivenvoorde ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3
Hi Nyall,
thanks for your feedback.
You are right that some of my examples were not ideal to explain what I
meant, so I try to explain it a bit better this time ;-)
Some of the following pyqgis-examples may be outdated as things can be done
easier in qgis3 now but they should just be an example
for some functions that were written by users to make life easier during
the development of QGIS plugins.
Example1: QgsVectorlayer:
Am Mi., 20. Feb. 2019 um 10:29 Uhr schrieb Nyall Dawson <
nyall.daw...@gmail.com>:
>
> This is a single line via the existing API :
>
> vl = QgsVectorLayer( '/home/me/my.shp' , 'my_layer' )
>
> I'm curious to hear how this could be improved?
>
I wrote "load a vectorlayer" but meant "create a vectorlayer"
Something like:
https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L24
Example2: For loading layer I meant something like
https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L7
:
def load_layer(filename, name = None):
'''
Tries to load a layer from the given file
:param filename: the path to the file to load.
:param name: the name to use for adding the layer to the current project.
If not passed or None, it will use the filename basename
'''
name = name or os.path.splitext(os.path.basename(filename))[0]
qgslayer = QgsVectorLayer(filename, name, 'ogr')
if not qgslayer.isValid():
qgslayer = QgsRasterLayer(filename, name)
if not qgslayer.isValid():
raise RuntimeError('Could not load layer: ' + unicode(filename))
return qgslayer
-
Example3: Iterate through layers:
> # all layers
> layers = [l.layer() for l in
> QgsProject.instance().layerTreeRoot().findLayers()]
>
> # visible layers
> visible_layers = [l.layer() for l in
> QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]
>
> Ok, not super-obvious in this case, but still quite concise ;)
>
For the example of visible_layers = [l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()] :
I would probably have needed some minutes to search in one of my plugins if
I have used such a code snippet before or google gis.stackexchange ;-)
Probably I also wouldn't have written such a fancy nice one-liner to get
these layers.
So if there would be a pyqgis-commons library where I would know that I
just have to call a function "get_visible_layers" instead of using
[l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()] I
probably could use this in my next plugin without having to search/google
how to do this.
Example4: show messages / log messages:
>
> > - show a message with different levels (info, warning, critical)
>
> iface.messageBar().pushWarning('blah','some message')
> iface.messageBar().pushInfo('blah','some message')
> iface.messageBar().pushCritical('blah','some message')
>
> > - log messages
> QgsMessageLog.logMessage('my plugin','something', Qgis.Critical)
I had something in mind like the MessageManager of Germán Carrillo:
https://github.com/gacarrillor/AutoFields/blob/master/MessageManager.py
I like the MessageManager because I can easily switch between the
message-modes 'production' or 'debug.
One other example would be the function "display_warning_message_bar" from
the inasafe-utilities where I can show a short message and also provide a
button to show more details about a warning:
https://github.com/inasafe/inasafe/blob/bd00bfeac510722b427544b186bfa10861749e51/safe/utilities/qgis_utilities.py#L132
Example5: Settings:
>
> > - reading setting, writing settings
>
> The QgsSettings class should make this straightforward
>
Here I hat something in mind like the qgis-settingsmanager of opengis (
https://github.com/opengisch/qgissettingmanager ).
I know it is not only a collection of python-/pyqt-functions but a whole
python module but I still it is an example of how functionalities are
provided to make the development of plugins easier.
So it is always about providing some helper functions that I could also
write by myself but which will save time during development and can help me
to do the things in a consistent way in all of my plugins.
> I'm not saying we can't improve the PyQGIS experience, but I don't
> personally see these as good candidates.
>
> I think we have a LOT of work to do with things like:
> - throwing proper exceptions instead of crashing/returning "None"
> values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should
> ideally raise an exception for invalid wkt instead of returning a null
> geometry)
> - providing Python-esque things like __repr__ methods, __len__, []
> operators (which behave in a python style, e.g. with -1 returning the
> last item), iterators, etc
> - providing more "context managers" (e.g. with : #something )
>
I don't have such a deep insight in the QGIS-codebase but I guess this
would probably have to be done in the C++-part of QGIS, wouldn't it?
Re: [QGIS-Developer] Stacktrace for crashes under Windows
Andreas Neumann-4 wrote > Unfortunately, I can't reproduce the same crash on Linux - even with a > slow db connection the crash doesn't appear on Linux. My crash is also only on Windows. Tom - Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon -- Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [629] Networks approval notification.
Plugin Networks approval by pcav. The plugin version "[629] Networks 2.3.0" is now approved Link: http://plugins.qgis.org/plugins/networks/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Problems when connecting to a PostGIS DB using "ssl mode require".
Hi, with Windows 10 / Windows 7, QGIS 3.4.4.3 (OSGeo4W64, code version af723c4942) I have the problem that the window "Enter Credentials" is called again and again during work. The "Log Messages" says: WARNINGConnection to database failed fe_sendauth: no password supplied But I can't find a corresponding message in the PG server log. No entry is made there. This error does not occur with QGIS version 3.4.4.1 (OSGeo4W64, code version f6ddc62fdb) or with Xubuntu 18.04 with 3.4.4+28bionic (code version f6ddc62). Can anyone confirm this bug? Thanks a lot and kind regards Burghardt *** Stadt Wolfsburg Geschäftsbereich IT - 15-3 GIS Rathaus E, Zi. E 313, Porschestraße 47A, D-38440 Wolfsburg Tel +49 5361 28-2531 Fax +49 5361 28-1765 mailto:burghardt.scho...@stadt.wolfsburg.de ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [983] DIVI QGIS Plugin approval notification.
Plugin DIVI QGIS Plugin approval by pcav. The plugin version "[983] DIVI QGIS Plugin 2.0.1" is now approved Link: http://plugins.qgis.org/plugins/DiviPlugin/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Provide a max. legend size in case of map unit sized symbols
I can confirm that there is no issue on print layout. I have been wrong because if there is not yet a map added, it displays the symbols in max size - what is not an issue since one don't need a legend without map. So I'll check out the solution with scale as request parameter and the default size in case there is no scale available. Thanks and regards Dave ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Provide a max. legend size in case of map unit sized symbols
Hi Nyall I think, you're right. If there's no max size defined (enabled) on the GetLegendGraphics, it responds with memory error (so possibly because the size gets infinite because of zero scale). I thought that it has been the issue in the print layout as well, but I'm not sure anymore and I will check again when I'm back in the office. If it's not the issue on print layout - like you say - then I agree on your approach. Where should this default scale be defined in your opinion? Thanks Dave David Signer [da...@opengis.ch](mailto:da...@opengis.ch) [+41 (0)78 766 13 03](tel:+41787661303) [](http://www.opengis.ch) > On Tue, 19 Feb 2019 at 19:03, David Signer wrote: > > > > Hi there > > > > I'm struggling with the following issue > > https://issues.qgis.org/issues/21309 summarized like this: > > When using map units as symbol size and having a max value in mm, this > > value is always taken in the GetLegendGraphics request with QGIS Server, > > what leads to huge symbols there (same in legend of print layout). > > > > I think it's not always needed to adapt the exact size to the legend. > > So I see three approaches: > > - Don't adapt the size to the legend at all > > - Provide a configuration "Maximum size for legend" > > - Provide a max size property for the server (does not solve it for print > > composer) > > > > Where I would prefer the "Maximum size for legend" configuration. > > > > What do you think? > > Isn't the underlying issue here that server generates the legend > without any knowledge of map scale? (And presumably uses a scale of 0 > or some other huge scale, resulting in the symbols taking their > maximum size)? > > If so, then i think the solution is: > > 1. Expose the choice of scale within the GetLegendGraphics call > 2. Allow users to set a "default" legend scale for a particular > project, and use this scale when generating the legend. > > > (same in legend of print layout). > > Can you elaborate? The legend in print layout correctly follows the > scale of the linked map item (and there's unit tests covering this). > > Nyall > > > > > > > Thanks > > Dave > > > > > > > > David Signer > > da...@opengis.ch > > +41 (0)78 766 13 03 > > > > > > > > ___ > > QGIS-Developer mailing list > > QGIS-Developer@lists.osgeo.org > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Stacktrace for crashes under Windows
Hi all, Yes - I also think that my crash is related to an edit widget in form view (relation reference widget). Unfortunately, I can't reproduce the same crash on Linux - even with a slow db connection the crash doesn't appear on Linux. Shortly before the crash, I get the numeric values in the relation reference widgets, instead of the human readable text values I expected. Andreas Am 20.02.19 um 11:57 schrieb Tom Chadwin: Hi Andreas It *might* be more specific even than that. You suspect your crash might be triggered by an edit widget. Mine definitely is. Thanks Tom - Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon -- Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Stacktrace for crashes under Windows
Hi Andreas It *might* be more specific even than that. You suspect your crash might be triggered by an edit widget. Mine definitely is. Thanks Tom - Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon -- Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Stacktrace for crashes under Windows
Hi Tom, Thank you for the reply. Interesting - seems that in certain cases the crash handler is not appearing on Windows! It doesn't seem generally broken - because I get the crash handler dialogue for other crashes - just not for the ones I am interested in ;-( At least - good to know I am not the only one who is affected by this. Strange ... Andreas Am 20.02.19 um 11:14 schrieb Tom Chadwin: Same for me with https://issues.qgis.org/issues/19118. Crashes without the crash handler appearing to give me the trace. Tom - Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon -- Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Stacktrace for crashes under Windows
Same for me with https://issues.qgis.org/issues/19118. Crashes without the crash handler appearing to give me the trace. Tom - Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon -- Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [709] xyToPoint approval notification.
Plugin xyToPoint approval by pcav. The plugin version "[709] xyToPoint 2.0" is now approved Link: http://plugins.qgis.org/plugins/xyToPoint/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3
On Wed, 20 Feb 2019 at 18:38, Thomas Baumann wrote:
>
> Hi qgis-devs,
>
> I recently updated 15 QGIS-plugins to be QGIS3-ready. Most of them were self
> written (in house) plugins but four of them were also plugins from the
> official repository which were written by someone else.
>
> I noticed that there are severals tasks that have many plugins in common like:
> - load a vectorlayer
This is a single line via the existing API :
vl = QgsVectorLayer( '/home/me/my.shp' , 'my_layer' )
I'm curious to hear how this could be improved?
> - add a layer to the layertree
> - iterate through all (visible?) layers of the layertree
# all layers
layers = [l.layer() for l in QgsProject.instance().layerTreeRoot().findLayers()]
# visible layers
visible_layers = [l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]
Ok, not super-obvious in this case, but still quite concise ;)
> - show a message with different levels (info, warning, critical)
iface.messageBar().pushWarning('blah','some message')
iface.messageBar().pushInfo('blah','some message')
iface.messageBar().pushCritical('blah','some message')
> - log messages
QgsMessageLog.logMessage('my plugin','something', Qgis.Critical)
> - reading setting, writing settings
The QgsSettings class should make this straightforward
I'm not saying we can't improve the PyQGIS experience, but I don't
personally see these as good candidates.
I think we have a LOT of work to do with things like:
- throwing proper exceptions instead of crashing/returning "None"
values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should
ideally raise an exception for invalid wkt instead of returning a null
geometry)
- providing Python-esque things like __repr__ methods, __len__, []
operators (which behave in a python style, e.g. with -1 returning the
last item), iterators, etc
- providing more "context managers" (e.g. with : #something )
(Definitely don't take this as a "don't proceed"... there is a VERY
STRONG need to improve the PyQGIS API/Documentation/examples, and this
would be very valuable work!)
Nyall
>
>
>
> Wouldn't it be possible to provide such a collection not only from privat
> persons/projects but from the QGIS-project itself so users could add common
> functions?
> I think the chances would be higher that such a "official" collection would
> be used in the long run and constantly extended.
>
> Apart from the fact that developers could save time while writing their
> plugins this could perhaps also help to improve the overall quality of the
> qgis-plugins as there would probably be several persons who could/would
> countercheck these common functions to make sure they are well written.
>
> regards,
> Thomas
>
> PS: I asked something similar also on gis.stackexchange recently:
>
> https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3
>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Stacktrace for crashes under Windows
Hi, I have a reproducable crash when opening the attribute table in form mode on Windows. Most likely related to some relation reference widget initialization. The same crash doesn't happen on Linux (at least not when the PostgreSQL db is on the same machine). Now - Matthias could have a look at it. However, my problem is, that I can't see the crash dialogue anymore where I can copy the stracktrace. The debugging symbols are installed for my OSGeo4W installations, however, I never see a dialogue where I could copy the stacktrace. Is there some setting that enables display of crash dialogue / stacktrace on Windows? All I get is this dialogue here: Thanks if you have any idea. Andreas ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3
Hi Thomas, Recently more and more is added to QGIS in the `qgis.utils` module, for example the latest addition is the `@alg` decorator for processing algorithms [1]. I really like these efforts and more additions are very welcome! From a workflow perspective, it's good to come up with a QEP or a thread on the mailing list first. Very often those snippets overcome shortcomings of the QGIS API which should rather be fixed on C++ side. Bests Matthias [1] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/134 On 20.02.19 09:38, Thomas Baumann wrote: Hi qgis-devs, I recently updated 15 QGIS-plugins to be QGIS3-ready. Most of them were self written (in house) plugins but four of them were also plugins from the official repository which were written by someone else. I noticed that there are severals tasks that have many plugins in common like: - load a vectorlayer - add a layer to the layertree - iterate through all (visible?) layers of the layertree - show a message with different levels (info, warning, critical) - log messages - reading setting, writing settings - ... It seems a bit ineffective that every developer writes these common task 'from scratch'. There already were some ideas to collect common functions that could be re-used by plugin-developers: -some older functions (GIS2) like https://github.com/NathanW2/parfait https://github.com/qgis/pyqgis_wrappers and something newer like https://github.com/boundlessgeo/lib-qgis-commons https://pypi.org/project/qgiscommons/ One nice example for utilities collected for a (huge) plugin is: https://github.com/inasafe/inasafe/tree/master/safe/utilities Wouldn't it be possible to provide such a collection not only from privat persons/projects but from the QGIS-project itself so users could add common functions? I think the chances would be higher that such a "official" collection would be used in the long run and constantly extended. Apart from the fact that developers could save time while writing their plugins this could perhaps also help to improve the overall quality of the qgis-plugins as there would probably be several persons who could/would countercheck these common functions to make sure they are well written. regards, Thomas PS: I asked something similar also on gis.stackexchange recently: https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3 ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [Qgis-psc] QGIS Voting Member Ballot Results
great :) Luigi Pirelli ** * LinkedIn: https://www.linkedin.com/in/luigipirelli * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli * GitHub: https://github.com/luipir * Mastering QGIS 2nd Edition: * https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition * Hire me: http://goo.gl/BYRQKg ** On Tue, 19 Feb 2019 at 20:42, Marco Bernasocchi wrote: > It is with great pleasure that I'd like to announce our latest community > voting member Hugo Mercier. > > Thanks to everybody for voting and thanks already Hugo for your commitment. > > Here you can find the votes summaries: > > > https://docs.google.com/spreadsheets/d/1ycJPCu9ylVKC9hefBx_BIi5yxrcLlYPwFCUwTvzHikI/edit?usp=sharing > > Cheers > > Marco > > -- > Marco Bernasocchi > > QGIS.org Co-chair > http://berna.io > > ___ > Qgis-psc mailing list > qgis-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/qgis-psc ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Common PyQGIS functions for QGIS 3
Hi qgis-devs, I recently updated 15 QGIS-plugins to be QGIS3-ready. Most of them were self written (in house) plugins but four of them were also plugins from the official repository which were written by someone else. I noticed that there are severals tasks that have many plugins in common like: - load a vectorlayer - add a layer to the layertree - iterate through all (visible?) layers of the layertree - show a message with different levels (info, warning, critical) - log messages - reading setting, writing settings - ... It seems a bit ineffective that every developer writes these common task 'from scratch'. There already were some ideas to collect common functions that could be re-used by plugin-developers: -some older functions (GIS2) like https://github.com/NathanW2/parfait https://github.com/qgis/pyqgis_wrappers and something newer like https://github.com/boundlessgeo/lib-qgis-commons https://pypi.org/project/qgiscommons/ One nice example for utilities collected for a (huge) plugin is: https://github.com/inasafe/inasafe/tree/master/safe/utilities Wouldn't it be possible to provide such a collection not only from privat persons/projects but from the QGIS-project itself so users could add common functions? I think the chances would be higher that such a "official" collection would be used in the long run and constantly extended. Apart from the fact that developers could save time while writing their plugins this could perhaps also help to improve the overall quality of the qgis-plugins as there would probably be several persons who could/would countercheck these common functions to make sure they are well written. regards, Thomas PS: I asked something similar also on gis.stackexchange recently: https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3 ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [412] Qgis2threejs approval notification.
Plugin Qgis2threejs approval by pcav. The plugin version "[412] Qgis2threejs 2.3.1" is now approved Link: http://plugins.qgis.org/plugins/Qgis2threejs/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
