[QGIS-Developer] Plugin [1391] Asistente LADM_COL approval notification.

[noreply]

Plugin Asistente LADM_COL approval by pcav.
The plugin version "[1391] Asistente LADM_COL 0.0.7 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/asistente_ladm_col/
___
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 [1316] Location Lab QGIS Plugin approval notification.

[noreply]

Plugin Location Lab QGIS Plugin approval by pcav.
The plugin version "[1316] Location Lab QGIS Plugin 1.1.0" is now approved
Link: http://plugins.qgis.org/plugins/location_lab/
___
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 Plugins transfer question

[Richard Duivenvoorde]

Please try what I wrote below. As said, I think you can do this yourself.

If not, sent me (as I have admin rights there):
- your login
- the plugin name(s)
- the login of the new maintainer

Regards,

Richard Duivenvoorde


On 06-04-18 16:28, Sebastian Schulz wrote:
> Yes, we are talking about my own plugins, but I mean "transfer" plugin
> from my account to another - in other word change plugin ownership. Is
> it possible?
> 
> Regards,
> Sebastian Schulz
> 
> 2018-03-29 12:44 GMT+02:00 Richard Duivenvoorde  >:
> 
> If I'm right you can change the 'maintainer' in the plugins website (and
> eventually metadata.txt in your plugin).
> 
> Log in, go to your plugins, go to 'Manage' tab and Edit there.
> 
> If you do not see the Manage tab, let us know.
> 
> We are talking about your own plugins isn't it?
> Or is it about transferring owner/maintainership from 'orphaned'
> plugins?
> 
> Regards,
> 
> Richard Duivenvoorde
> 
> 
> On 29-03-18 11:50, Sebastian Schulz wrote:
> > Hello!
> >
> > I've got a question about QGIS Plugins repository. Is it possible to
> > transfer few plugins from one account to another?
> >
> > Regards,
> > Sebastian
> >
> >
> >
> > ___
> > 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 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 Plugins transfer question

[Sebastian Schulz]

Yes, we are talking about my own plugins, but I mean "transfer" plugin from
my account to another - in other word change plugin ownership. Is it
possible?

Regards,
Sebastian Schulz

2018-03-29 12:44 GMT+02:00 Richard Duivenvoorde :

> If I'm right you can change the 'maintainer' in the plugins website (and
> eventually metadata.txt in your plugin).
>
> Log in, go to your plugins, go to 'Manage' tab and Edit there.
>
> If you do not see the Manage tab, let us know.
>
> We are talking about your own plugins isn't it?
> Or is it about transferring owner/maintainership from 'orphaned' plugins?
>
> Regards,
>
> Richard Duivenvoorde
>
>
> On 29-03-18 11:50, Sebastian Schulz wrote:
> > Hello!
> >
> > I've got a question about QGIS Plugins repository. Is it possible to
> > transfer few plugins from one account to another?
> >
> > Regards,
> > Sebastian
> >
> >
> >
> > ___
> > 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] Discussing qgd files

[Régis Haubourg]

Hi,
just a quick followup about qgd file. Paul just merged that PR
https://github.com/qgis/QGIS/pull/6717 and qgd are now only created when
needed.
Thanks Andreas for raising the issue !


2018-03-07 18:45 GMT+01:00 Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com>:

> A disruptive "moreover approach" suggests some reflection about the file
>  database approach.
>
> I see several places where handling metadata in the database could provide
> a better but possibly conflicting solution.
> This happens for instance with styles stored on the database that may
> easily be overwritten by opening a modified project (if you work alone it's
> wonderful, but cooperating is a nightmare), but may happen also with any
> other "intelligent" provision that uses XML and/or persistent storage.
>
> I think this should not prevent a good solution about metadata. A map is
> not made of several layers overlaid with their styles only, it's something
> more and it's not completely satisfactory to reduce this to a project file
> that helps a single user to keep working on it or store the printing styles
> (sorry, I simplify too much, I know). Maybe QGD files are a starting point
> to design a better solution because we are embracing a three level storage
> system: files, light database (SQLite/Spatialite), DBMS (mainly
> PostgreSQL/PostGIS, but even others). This solution could lead us to a
> careful choice or to more flexibility (complexity?).
>
> Maybe this further flexibility is needed. I raise a very peculiar case: we
> work with historical maps and sometimes I georeference maps without being
> certain about my sources, sometimes the source itself is made of parts that
> ask two set of conflicting reference points for the same file. I'm forced
> to make a symlink on the filesystem to have the same file georeferenced in
> two ways. Why the different point sets cannot be stored on database? The
> reference points are points on earth and frequently I need to reuse them
> (what about adjacent tables? Maybe snapping on them could help), why not
> storing them in the database?
>
> QGIS Server is an amazing tool, but why using monolithic and completely
> proprietary XML file while several other applications could benefit from
> more generic metadata stored in the database? That is already done for
> styles which store SLD values besides the Qt ones, but it could be extended
> to other areas.
>
> It's reasonable to blame my "moreover approach", but take what you think
> QGIS could benefit of.
> c
>
> --
> --
> Carlo A. Bertelli
>Charta servizi e sistemi per il territorio e la storia ambientale srl
>   Dipendenze del palazzo Doria,
>   vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
>   tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
>e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
> --
>
>
>
>
> ___
> 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] QgsLocator & common python libs

[Luigi Pirelli]

I strongly agree with Nyall analysis about versioning. We had similar
problems in Boundless when adding new features to already available
modules... there weren't a simple way to load a specific module version,
especially when these different version are available in different python
plugins all listed in the pythonpath.
The simples solution was to version the module from qgiscommon to
qgisocmmon2 and rebuild all in-house plugin at averey update tof
qgisocmmons. Something impossibile with third party plugin, in Boundless
case we had control on deployment and packaging of the product, something
radically different for the standard QGIS.
So I would link the package version to QGIS version avoiding a different
relase math and versioning.

I also agree to avoid ti add snippets that can be solved usign core API.
Btw, for the case of NetworkAccessManager it was introduced to allow
upgrade comnon plugins using QgsNetowkrAccessManager or requests to use the
integrated auth system, something hard to describe into a docstring... btw
I documented it in the PyQGIS coockbook in the auth system paragraphs.

cheers


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 6 April 2018 at 01:55, Nyall Dawson  wrote:

> On 5 April 2018 at 05:06, Richard Duivenvoorde 
> wrote:
>
> > So my main point:
> > - how to give everybody the possibilty to implement a locator class, BUT
> > also share a common base class or use the same QgsNetworkAccessManager
> > moduel?
> >
> > Some options:
> > - we create a separate repo for 'common' python classes, and via git
> > submodules everybody pulls in it's own copy of those classes
> > - we create a common-qgis-python module which would ship with QGIS (with
> > filterbaseclass, QgsNetworkAccessManager, and other ideas from the
> > Boundless commons lib).
>
> My concern with the second approach is (and always has been) that
> these common modules effectively become part of the stable API. We'd
> need to carefully decide on things like:
>
> - how are releases of the module handled? Is it bound to QGIS
> releases, or on its own release schedule?
> - Would the module be versioned (i.e. if it's not tied into QGIS
> releases and packaged accordingly, will the code need to work with any
> QGIS version from 3.0 up?)
>
> We'd also need to very carefully vet all contributions to this module,
> to ensure that they aren't reproducing functionality which is already
> present in the core/gui modules. A lot of the code in common python
> modules I've seen is just re-implementations of widgets and classes
> which are already present in the master codebase, and which should
> always be used instead. If Python syntactical sugar is desired for
> these existing c++ classes then I'd much prefer to see it implemented
> in the core QGIS module, such as is done here:
>
> - https://github.com/qgis/QGIS/blob/master/python/core/__init__.py#L192
> - https://github.com/qgis/QGIS/blob/master/src/core/
> qgsreadwritecontext.h#L84
> (Via https://github.com/qgis/QGIS/blob/master/python/core/__init__.py#L216
> and
> - https://github.com/qgis/QGIS/blob/master/src/core/qgsproject.h#L1316
> (via https://github.com/qgis/QGIS/blob/master/python/core/__init__.py#L240
> )
>
> This is a nice approach to adding standard Python coding patterns into
> the QGIS API, with the benefit that it's already tied into the QGIS
> releases, packaged accordingly, and are all unit tested on Travis.
> Maybe the same approach should be taken for adding the network access
> manager.
>
> Just my 2c!
>
> > PS, wannatry? Download
> > https://github.com/rduivenvoorde/qgislocator/raw/
> master/qgislocator_0.1.1.zip
> > and use Install from ZIP in the plugin manager. Use '2022zj' to search
> > PDOK, or 'eiffel' to search Google. Note that you may need a google key
> > to use their geocoder.
>
> Yep, can't wait to give this a spin :)
>
> 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
> ___
> 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://li

[QGIS-Developer] Plugin [998] Standard Deviational Ellipse approval notification.

[noreply]

Plugin Standard Deviational Ellipse approval by zimbogisgeek.
The plugin version "[998] Standard Deviational Ellipse 3.0.0" is now approved
Link: http://plugins.qgis.org/plugins/SDEllipse/
___
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 [1364] UMEP approval notification.

[noreply]

Plugin UMEP approval by zimbogisgeek.
The plugin version "[1364] UMEP 1.4" is now approved
Link: http://plugins.qgis.org/plugins/UMEP/
___
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] Python-based GDAL utilities are missed from the standalone installer

[Alexander Bruy]

Hi devs,

just noticed that Python-based GDAL utilities (e.g. gdal_merge.py) are
not available in the weekly standalone installer by default. Is this
intentional or just missed dependency to the gdal-python package?

-- 
Alexander Bruy
___
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 [727] OSMDownloader approval notification.

[noreply]

Plugin OSMDownloader approval by pcav.
The plugin version "[727] OSMDownloader 1.0" is now approved
Link: http://plugins.qgis.org/plugins/OSMDownloader/
___
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