[Qgis-developer] Plugin [183] InaSAFE approval notification.

[noreply]

Plugin InaSAFE approval by ismailsunni.
The plugin version "[183] InaSAFE 4.0.1" is now unapproved
Link: http://plugins.qgis.org/plugins/inasafe/
___
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] Adding default OSM backround maps

[Tim Sutton]

Hi Tom and Mathieu 


Ok good responsesI'll withdraw my suggestion for now

Regards 

Tim Sutton 
Co-founder of Kartoza 
QGIS project chairman 

> On 22 Mar 2017, at 5:11 AM, Mathieu Pellerin  wrote:
> 
> Tim,
> 
> -1 to use OSM-based XYZ tile server that doesn't update its dataset on a 
> regular basis (+/- weekly). While there are nicer styles that OSM's default 
> one, one of the fundamental dynamic of OSM is the ability to update / add 
> spatial data and see those updates reflected on tiles immediately. We should 
> both respect and benefit from that :)
> 
> For e.g., the beautiful style on the link you provided uses a 10-month old 
> OSM dataset. It's a significant data gap.
> 
> Math
> 
> 
>> On Wed, Mar 22, 2017 at 2:29 AM, Tim Sutton  wrote:
>> Hi
>> 
>> Its really great to see this Paolo. I think the OSM requests all sound 
>> reasonable and if we do start representing a high load on their servers we 
>> could consider adding a caching proxy between QGIS clients and OSM tile 
>> server so that we don't hit their servers too hard.
>> 
>> One thing that I would suggest is that we do not use the default tile 
>> renders for OSM - it would be much nicer to provide something 'consumer' 
>> orientated rather than the OSM renders which are great for visualizing a 
>> broad range of OSM feature types but not IMHO very nice looking cartography. 
>> Reaching out to the folks at http://giscience.uni-hd.de to see if we can use 
>> their tile renders might provide a nicer out of the box experience for our 
>> users. Of course we would still acknowledge OSM as the source of the data 
>> and giscience as source of the renders. Here is an example of their render:
>> 
>> http://korona.geog.uni-heidelberg.de
>> 
>> Regards
>> 
>> Tim
>> 
>> 
>> 
>> 
>> 
>>> On 21 Mar 2017, at 4:58 PM, Jorge Gustavo Rocha  wrote:
>>> 
>>> Hi Paolo,
>>> 
>>> I can help on this.
>>> 
>>> 1. The UserAgent is already a configurable feature in QGIS (under
>>> Options/Network). Any user can change it, but we can propose another
>>> default value.
>>> 
>>> 2. The QGIS community is very much aware of OpenStreetMap. If we really
>>> need to make our users more aware, does it make sense to add a new
>>> button to QGIS to report map errors? (context dependent, when the
>>> OpenStreetMap layer is shown) It would have the same functionality of
>>> the notes in OpenStreetMap web interface.
>>> 
>>> 3.1 On the "add layer" dialog, we can show the OpenStreetMap url (which
>>> might change over time) and licenses (for data and tiles) taken from
>>> settings or an (external) resource. We can make this not hard coded, to
>>> be modified easily, without upgrading QGIS. We can also check if the
>>> service is enabled for us, before allow users to add that layer (related
>>> with 4.).
>>> 
>>> 3.2 When the tiles are used in the composer or on the web client, we can
>>> not enforce an attribution string. We might add or suggest it, but users
>>> should be free the create and edit the attributions. It the
>>> responsibility of the user, not a QGIS responsibility.
>>> 
>>> 4. We have to handle when tiles are not loading, either because there
>>> are network problems, server busy, etc. We can customize the user's
>>> feedback regarding the load of the default OpenStreetMap tiles. But we
>>> definitely need to know formally when they shut our access down. This is
>>> related with 3.1 issue. If the access is disabled, we can also disable
>>> adding default OpenStreetMap tiles option.
>>> 
>>> Regards,
>>> 
>>> Jorge Gustavo
>>> 
>>> Às 09:52 de 21-03-2017, Paolo Cavallini escreveu:
 Hi all,
 we have been exploring the possibility of adding default XYZ maps to
 QGIS, so to make life far easier for users.
 The good news is that the OSM board is quite positive about this.
 The not-so-good news is that their (I believe reasonable) requirements
 imply some more development from our side.
 Is anyone interested in taking this?
 Requirements below.
 All the best.
 ===
 
 1. You seem to be using an user agent of "Mozilla/5.0 QGIS/2.18.3". We
 strongly recommend that you don't pretend to be a browser by adding the
 "Mozilla" bit. OpenStreetMap sees increasing traffic from "fake" user
 agents, and it is likely that we will penalise user agents like that at
 some point in the future - meaning tiles will still be served, but
 slower than to "honest" user agents that don't pretend to be a browser
 when they are not. We understand that this is difficult terrain and that
 other data sources might actually *require* that you pretend to be a
 browser - perhaps per-datasource overrides of the user agent are a
 possibility.
 
 2. As you know, OpenStreetMap thrives on contributions by mappers, and
 one of the main reasons we make our tiles freely available is the hope
 of attracting new contributors. It would be 

Re: [Qgis-developer] Adding default OSM backround maps

[Mathieu Pellerin]

Tim,

-1 to use OSM-based XYZ tile server that doesn't update its dataset on a
regular basis (+/- weekly). While there are nicer styles that OSM's default
one, one of the fundamental dynamic of OSM is the ability to update / add
spatial data and see those updates reflected on tiles immediately. We
should both respect and benefit from that :)

For e.g., the beautiful style on the link you provided uses a 10-month old
OSM dataset. It's a significant data gap.

Math


On Wed, Mar 22, 2017 at 2:29 AM, Tim Sutton  wrote:

> Hi
>
> Its really great to see this Paolo. I think the OSM requests all sound
> reasonable and if we do start representing a high load on their servers we
> could consider adding a caching proxy between QGIS clients and OSM tile
> server so that we don't hit their servers too hard.
>
> One thing that I would suggest is that we do not use the default tile
> renders for OSM - it would be much nicer to provide something 'consumer'
> orientated rather than the OSM renders which are great for visualizing a
> broad range of OSM feature types but not IMHO very nice looking
> cartography. Reaching out to the folks at http://giscience.uni-hd.de to
> see if we can use their tile renders might provide a nicer out of the box
> experience for our users. Of course we would still acknowledge OSM as the
> source of the data and giscience as source of the renders. Here is an
> example of their render:
>
> *http://korona.geog.uni-heidelberg.de
> *
>
> Regards
>
> Tim
>
>
>
>
>
> On 21 Mar 2017, at 4:58 PM, Jorge Gustavo Rocha  wrote:
>
> Hi Paolo,
>
> I can help on this.
>
> 1. The UserAgent is already a configurable feature in QGIS (under
> Options/Network). Any user can change it, but we can propose another
> default value.
>
> 2. The QGIS community is very much aware of OpenStreetMap. If we really
> need to make our users more aware, does it make sense to add a new
> button to QGIS to report map errors? (context dependent, when the
> OpenStreetMap layer is shown) It would have the same functionality of
> the notes in OpenStreetMap web interface.
>
> 3.1 On the "add layer" dialog, we can show the OpenStreetMap url (which
> might change over time) and licenses (for data and tiles) taken from
> settings or an (external) resource. We can make this not hard coded, to
> be modified easily, without upgrading QGIS. We can also check if the
> service is enabled for us, before allow users to add that layer (related
> with 4.).
>
> 3.2 When the tiles are used in the composer or on the web client, we can
> not enforce an attribution string. We might add or suggest it, but users
> should be free the create and edit the attributions. It the
> responsibility of the user, not a QGIS responsibility.
>
> 4. We have to handle when tiles are not loading, either because there
> are network problems, server busy, etc. We can customize the user's
> feedback regarding the load of the default OpenStreetMap tiles. But we
> definitely need to know formally when they shut our access down. This is
> related with 3.1 issue. If the access is disabled, we can also disable
> adding default OpenStreetMap tiles option.
>
> Regards,
>
> Jorge Gustavo
>
> Às 09:52 de 21-03-2017, Paolo Cavallini escreveu:
>
> Hi all,
> we have been exploring the possibility of adding default XYZ maps to
> QGIS, so to make life far easier for users.
> The good news is that the OSM board is quite positive about this.
> The not-so-good news is that their (I believe reasonable) requirements
> imply some more development from our side.
> Is anyone interested in taking this?
> Requirements below.
> All the best.
> ===
>
> 1. You seem to be using an user agent of "Mozilla/5.0 QGIS/2.18.3". We
> strongly recommend that you don't pretend to be a browser by adding the
> "Mozilla" bit. OpenStreetMap sees increasing traffic from "fake" user
> agents, and it is likely that we will penalise user agents like that at
> some point in the future - meaning tiles will still be served, but
> slower than to "honest" user agents that don't pretend to be a browser
> when they are not. We understand that this is difficult terrain and that
> other data sources might actually *require* that you pretend to be a
> browser - perhaps per-datasource overrides of the user agent are a
> possibility.
>
> 2. As you know, OpenStreetMap thrives on contributions by mappers, and
> one of the main reasons we make our tiles freely available is the hope
> of attracting new contributors. It would be nice if QGIS could do its
> part to help us here, by making their users aware that OSM is open for
> everyone to contribute. Perhaps a link to
> http://www.openstreetmap.org/fixthemap can be placed somewhere in the
> layer description or something.
>
> 3. Our data is licensed under ODbL 1.0, and our map tiles are CC-BY-SA
> 2.0. The latter could change at any time; the former is
> relatively constant.
>
> The legal consequences of 

Re: [Qgis-developer] Broken sip composer item subclassing in 2.18

[Nyall Dawson]

On 21 March 2017 at 21:12, Tim Sutton  wrote:
> Hi Nyall
>
> It's probably the same issue as described here:
>
> http://osgeo-org.1560.x6.nabble.com/API-Break-in-2-16-for-QgsComposition-td5276424.html
>

Yep - that's it. What a horrible bug. At least it's not our fault...
but still, glad the Qt5 builds are usable!

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] Wiki page/area for 'Building QGIS from scratch'

[gordon]

On 2017-03-21 20:12, Nyall Dawson wrote:

On 22 March 2017 at 08:26,   wrote:


Also, I question further development using WebKit when Qt has moved to
WebEngine.  Wouldn't adopting WebEngine make sense or at least present 
why

it isn't.


As Tom has said, WebEngine isn't a suitable replacement. It's a very,
*very* cut down version of QWebKit which lacks many of the methods we
require.

Until the Qt WebEngine backend is brought up to feature parity with
QWebKit we won't be porting -- it's just not possible to do.

Nyall


Thanks for the clarification.
___
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] Wiki page/area for 'Building QGIS from scratch'

[Nyall Dawson]

On 22 March 2017 at 08:26,   wrote:

> Also, I question further development using WebKit when Qt has moved to
> WebEngine.  Wouldn't adopting WebEngine make sense or at least present why
> it isn't.

As Tom has said, WebEngine isn't a suitable replacement. It's a very,
*very* cut down version of QWebKit which lacks many of the methods we
require.

Until the Qt WebEngine backend is brought up to feature parity with
QWebKit we won't be porting -- it's just not possible to do.

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] Adding default OSM backround maps

[Tom Chadwin]

Hi Tim


Tim Sutton-6 wrote
> One thing that I would suggest is that we do not use the default tile
> renders for OSM - it would be much nicer to provide something 'consumer'
> orientated rather than the OSM renders which are great for visualizing a
> broad range of OSM feature types but not IMHO very nice looking
> cartography. Reaching out to the folks at http://giscience.uni-hd.de
> http://giscience.uni-hd.de/; to see if we can use their tile
> renders might provide a nicer out of the box experience for our users. Of
> course we would still acknowledge OSM as the source of the data and
> giscience as source of the renders. Here is an example of their render:
> 
> http://korona.geog.uni-heidelberg.de
> http://korona.geog.uni-heidelberg.de/;

While I agree with the principal that OSM's default stylesheet is not
suitable as a basemap, there are several issues your proposal raises:

1. Using OSM's tileservers is more likely to be resilient and unchanging
than another provider

2. OSM itself has authority and kudos, which could be good to associate
ourselves with

3. The style is more familiar, and is more likely to meet users'
expectations

4. Using another provider of course means starting new negotiations

5. Using OSM themselves carries the lowest risk (in my opinion) of a
licensing change like the MapQuest one which quite recently affected many,
many published webmaps

In other words, I think we need OSM first and foremost, and can then look to
ask other providers whose styles are likely to prove more useful
cartographically.



Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Adding-default-OSM-backround-maps-tp5313358p5313529.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
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] MMQGIS - Where is the Code Repository & Tracker?

[Tom Chadwin]

The "MM" stands for Michael Minn:

http://michaelminn.com/linux/mmqgis/

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/MMQGIS-Where-is-the-Code-Repository-Tracker-tp5313508p5313528.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
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] Wiki page/area for 'Building QGIS from scratch'

[Tom Chadwin]

There's been quite a lot of discussion on the WebKit/WebEngine issue already
on the list. Bottom line - from memory WebEngine does not yet compare to
WebKit in functionality. I stand to be corrected. 

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Wiki-page-area-for-Building-QGIS-from-scratch-tp5312871p5313527.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
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] Wiki page/area for 'Building QGIS from scratch'

[gordon]

It sounds great, does it work?  I can suggest a reason for building from 
scratch - one can compile to take advantage of multiple cores rather 
than assume everyone likes slow.


I looked at these notes and the first thing I noticed was PyQt5 Version 
5.8.1.  Qt5.8.1 requires a change in Unicode version on Ubuntu 17.04 - 
as I discovered - and it didn't appear that simple to implement.


I don't believe that QGIS built using Qt5.7.1 works with PyQt5 Version 
5.8.1 - see output below, what am I missing?


Also, I question further development using WebKit when Qt has moved to 
WebEngine.  Wouldn't adopting WebEngine make sense or at least present 
why it isn't.


On Ubuntu 17.04, which is based on Qt5.7.1, output from 
`./output/bin/qgis`


`Couldn't load PyQt.
Python support will be disabled. (a really big deal)

Traceback (most recent call last):
  File "", line 1, in
ImportError: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.8' 
not found (required by 
/usr/local/lib/python3.5/dist-packages/PyQt5/QtCore.so)`



On 2017-03-21 16:58, Tim Sutton wrote:

Hi


On 21 Mar 2017, at 9:50 PM, Mark Johnson 
wrote:


Good  - I think it will get outdated quickly and history shows
that such content does not get well maintained. If we had to do
anything along these lines, it could be to have a small chapter
which lists all the QGIS dependencies along with a pointer to the
upstream build instructions for each dependency.


Has anybody actually looked at the pages created as a result of this
discussion, that starts here?

https://github.com/qgis/QGIS-Documentation/wiki#table_of_content


Yes I have - I was trying to propose that it is boiled down to a
simple table on a single page with just:

Dependency | Notes
- |
--[Qt5](https://wiki.qt.io/Building_Qt_5_from_Git) | Qt5 is a
graphical toolkit and collection of utility classes.
etc. | etc.

Regards

Tim


Mark ___
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


—

TIM SUTTON

CO-FOUNDER: Kartoza
PROJECT CHAIR: QGIS.org [1]

Visit http://kartoza.com [2] to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

SKYPE: timlinux
IRC: timlinux on #qgis at freenode.net [3]

Kartoza is a merger between Linfiniti and Afrispatial


Links:
--
[1] http://QGIS.org
[2] http://kartoza.com/
[3] http://freenode.net
___
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] Wiki page/area for 'Building QGIS from scratch'

[John Hawkinson]

Replies to multiple messages inline, elow.

Tim Sutton  wrote on Tue, 21 Mar 2017 at 21:43:07 +0200:

> John have you considered just running QGIS in docker - its probably
> a much easier approach than the method you have embarked upon...

I think your question was directed to Mark Johnson, not to me? But since
you asked, I found the rational raised in this thread to be...stunningly
unconvincing!:

Nathan Woodrow  wrote Sat, 18 Mar 2017 at 22:40:21 +1000:

> The wiki information got outdated very fast,

The reason documentation gets outdated is typically because of a lack
of maintainers (possibly related to lack of visibility), and also an
overly high bar to editing it. A wiki is generally the lowest bar
possible. If the problem is information getting outdated quickly,
moving away from a wiki seems a step in the wrong direction, not the
right one.

> and was also not translatable easily.

I'm not very familiar with translation issues, but my understanding is
they aren't usually strictly format-dependent. (But I should
acknowledge my deep biases as an English speaker.)

> A decision was made a while ago for official documentation should be
> done int the same workflow as the website in order to streamline
> that process

I'm not sure why a streamlined website process ought to have
any bearing on the quality or accessibility of documentation. This
seems a second-class issue.

> and make sure everyone is using the same tools.

I'm also not sure I understand this or why it is important for
documentation; or more important than good documentatoin.


Richard Duivenvoorde  Sat, 18 Mar 2017 at 15:55:34 +0100:

> And can I add the constant hard fight against fake user accounts adding
> wiki spam? (see osgeo wiki).

Yes, this I understand; and this is the constant tension between
lowering the barrier of entry far enough to make it easy for casual
contributors to crowdsource information, and lowering it too far to
make it too easy for spammers. Except it seems like the osgeo wiki
has finally evolved a fairly effective solution (modulo the fact that
it's awful hard to get a mantra and credentials!).

> The workflow we have now is translatable, can be build to pdf's, is
> versioned and is continuously tested/rebuild.

Continuous testing is super-helpful for code. It's nice for
documentation, but not really in the same way. I'd much rather have
good documentation than continuously-tested documentation.

Maybe that's an artificial tradeoff and we can have both.
But I'm not convinced (not that I need to be; again, I'm new here and
so far mostly send long emails.)

--jh...@mit.edu
  John Hawkinson
___
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] MMQGIS - Where is the Code Repository & Tracker?

[C Hamilton]

I was wanting to contact the developer of MMQGIS and found on the
http://plugins.qgis.org/plugins/mmqgis/ page that the link to the Code
repository links back to itself and the Tracker goes to the home page for
documentation. As far as I can tell there is no contact information or the
ability to report bugs or give suggestions. I thought that both of these
were to be a part of the information the plugin provides. At any rate it
would be useful if it were available. I would like to contact the developer.

Thanks,

Calvin
___
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] Wiki page/area for 'Building QGIS from scratch'

[Tim Sutton]

Hi

> On 21 Mar 2017, at 9:50 PM, Mark Johnson  wrote:
> 
> Good  - I think it will get outdated quickly and history shows that such 
> content does not get well maintained. If we had to do anything along these 
> lines, it could be to have a small chapter which lists all the QGIS 
> dependencies along with a pointer to the upstream build instructions for each 
> dependency.
> Has anybody actually looked at the pages created as a result of this 
> discussion, that starts here?
>  
> https://github.com/qgis/QGIS-Documentation/wiki#table_of_content 
> 

Yes I have - I was trying to propose that it is boiled down to a simple table 
on a single page with just:

Dependency | Notes
- | --
[Qt5](https://wiki.qt.io/Building_Qt_5_from_Git) | Qt5 is a graphical toolkit 
and collection of utility classes.
etc. | etc.


Regards

Tim


> 
> Mark
> ___
> 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

—










Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

Kartoza is a merger between Linfiniti and Afrispatial

___
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] [resolved] Qt4 asked when compiling current master

[Pierre_Loicq]

Pierre_Loicq wrote
> Hello,
> 
> I am trying to compile current master on ubuntu 16.04. I have this error:
> 
> [ 99%] Generating ../output/i18n/qgis_bg.qm
> lrelease: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/lrelease': No
> such file or directory
> lrelease: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/lrelease': No
> such file or directory
> i18n/CMakeFiles/translations.dir/build.make:97 : la recette pour la cible
> « output/i18n/qgis_ar.qm » a échouée
> make[2]: *** [output/i18n/qgis_ar.qm] Erreur 1
> make[2]: *** Attente des tâches non terminées
> i18n/CMakeFiles/translations.dir/build.make:101 : la recette pour la cible
> « output/i18n/qgis_bg.qm » a échouée
> make[2]: *** [output/i18n/qgis_bg.qm] Erreur 1
> CMakeFiles/Makefile2:3686 : la recette pour la cible
> « i18n/CMakeFiles/translations.dir/all » a échouée
> make[1]: *** [i18n/CMakeFiles/translations.dir/all] Erreur 2
> make[1]: *** Attente des tâches non terminées
> [ 99%] Built target zzz-db_manager-5-depend
> Makefile:160 : la recette pour la cible « all » a échouée
> make: *** [all] Erreur 2
> 
> I don't know why Qt4 is asked here. ccmake configuration only talks about
> Qt5
> 
> Thank you
> Pierre

Resolved ! I used apt-file to know which package I had to install:
qt4-linguist-tools





--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Qt4-asked-when-compiling-current-master-tp5310808p5313502.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
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] Wiki page/area for 'Building QGIS from scratch'

[Mark Johnson]

>
> Good  - I think it will get outdated quickly and history shows that such
> content does not get well maintained. If we had to do anything along these
> lines, it could be to have a small chapter which lists all the QGIS
> dependencies along with a pointer to the upstream build instructions for
> each dependency.

Has anybody actually looked at the pages created as a result of this
discussion, that starts here?

https://github.com/qgis/QGIS-Documentation/wiki#table_of_content

Mark
___
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] RE. Wiki page/area for 'Building QGIS from scratch'

[Tim Sutton]

Hi

> On 21 Mar 2017, at 10:33 AM, Yves Jacolin  wrote:
> 
> Sorry for the noise, reading again the thread, my previous email is not 
> relevant for such issue. I don't think we will add a chapter how to build 
> QGIS 
> from scratch.

Good  - I think it will get outdated quickly and history shows that such 
content does not get well maintained. If we had to do anything along these 
lines, it could be to have a small chapter which lists all the QGIS 
dependencies along with a pointer to the upstream build instructions for each 
dependency. At least that should be more easily maintained and does not 
duplicate effort from upstream projects.

John have you considered just running QGIS in docker - its probably a much 
easier approach than the method you have embarked upon...

Regards

Tim

> 
> Y.
> On samedi 18 mars 2017 15:55:34 CET Richard Duivenvoorde wrote:
>> And can I add the constant hard fight against fake user accounts adding
>> wiki spam? (see osgeo wiki).
>> 
>> The workflow we have now is translatable, can be build to pdf's, is
>> versioned and is continuously tested/rebuild.
>> 
>> Regards,
>> 
>> Richard
>> 
>> On 18-03-17 13:40, Nathan Woodrow wrote:
>>> The wiki information got outdated very fast, and was also not
>>> translatable easily.
>>> A decision was made a while ago for official documentation should be
>>> done int the same workflow
>>> as the website in order to streamline that process and make sure
>>> everyone is using the same tools.
>>> 
>>> - Nathan
>>> 
>>> 
>>> On Sat, Mar 18, 2017 at 10:18 PM, John Hawkinson >> 
>>> > wrote:
>>>I'm new here, so I'll ask the obvious question:
>>> 
>>>Wikis are great because they lower the bar to collaboration. It's
>>>really
>>>easy to make edits and you don't have to worry about them getting
>>>approved
>>>and that's awesome. Really easy workflow, more so than github pull
>>>requests.
>>>New and potential contributors don't get discouraged.
>>> 
>>>What's the reason for putting up barriers to documentation like this?
>>> 
>>>Problems with spam or low quality edits? Can I find a robust
>>>discussion
>>>of the tradeoffs in the list archives?
>>> 
>>>--jh...@mit.edu 
>>> 
>>>  John Hawkinson
>>> 
>>>___
>>>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
> 
> ___
> 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

—










Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

Kartoza is a merger between Linfiniti and Afrispatial

___
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] Adding default OSM backround maps

[Tim Sutton]

Hi

Its really great to see this Paolo. I think the OSM requests all sound 
reasonable and if we do start representing a high load on their servers we 
could consider adding a caching proxy between QGIS clients and OSM tile server 
so that we don't hit their servers too hard.

One thing that I would suggest is that we do not use the default tile renders 
for OSM - it would be much nicer to provide something 'consumer' orientated 
rather than the OSM renders which are great for visualizing a broad range of 
OSM feature types but not IMHO very nice looking cartography. Reaching out to 
the folks at http://giscience.uni-hd.de  to see if 
we can use their tile renders might provide a nicer out of the box experience 
for our users. Of course we would still acknowledge OSM as the source of the 
data and giscience as source of the renders. Here is an example of their render:

http://korona.geog.uni-heidelberg.de 

Regards

Tim





> On 21 Mar 2017, at 4:58 PM, Jorge Gustavo Rocha  wrote:
> 
> Hi Paolo,
> 
> I can help on this.
> 
> 1. The UserAgent is already a configurable feature in QGIS (under
> Options/Network). Any user can change it, but we can propose another
> default value.
> 
> 2. The QGIS community is very much aware of OpenStreetMap. If we really
> need to make our users more aware, does it make sense to add a new
> button to QGIS to report map errors? (context dependent, when the
> OpenStreetMap layer is shown) It would have the same functionality of
> the notes in OpenStreetMap web interface.
> 
> 3.1 On the "add layer" dialog, we can show the OpenStreetMap url (which
> might change over time) and licenses (for data and tiles) taken from
> settings or an (external) resource. We can make this not hard coded, to
> be modified easily, without upgrading QGIS. We can also check if the
> service is enabled for us, before allow users to add that layer (related
> with 4.).
> 
> 3.2 When the tiles are used in the composer or on the web client, we can
> not enforce an attribution string. We might add or suggest it, but users
> should be free the create and edit the attributions. It the
> responsibility of the user, not a QGIS responsibility.
> 
> 4. We have to handle when tiles are not loading, either because there
> are network problems, server busy, etc. We can customize the user's
> feedback regarding the load of the default OpenStreetMap tiles. But we
> definitely need to know formally when they shut our access down. This is
> related with 3.1 issue. If the access is disabled, we can also disable
> adding default OpenStreetMap tiles option.
> 
> Regards,
> 
> Jorge Gustavo
> 
> Às 09:52 de 21-03-2017, Paolo Cavallini escreveu:
>> Hi all,
>> we have been exploring the possibility of adding default XYZ maps to
>> QGIS, so to make life far easier for users.
>> The good news is that the OSM board is quite positive about this.
>> The not-so-good news is that their (I believe reasonable) requirements
>> imply some more development from our side.
>> Is anyone interested in taking this?
>> Requirements below.
>> All the best.
>> ===
>> 
>> 1. You seem to be using an user agent of "Mozilla/5.0 QGIS/2.18.3". We
>> strongly recommend that you don't pretend to be a browser by adding the
>> "Mozilla" bit. OpenStreetMap sees increasing traffic from "fake" user
>> agents, and it is likely that we will penalise user agents like that at
>> some point in the future - meaning tiles will still be served, but
>> slower than to "honest" user agents that don't pretend to be a browser
>> when they are not. We understand that this is difficult terrain and that
>> other data sources might actually *require* that you pretend to be a
>> browser - perhaps per-datasource overrides of the user agent are a
>> possibility.
>> 
>> 2. As you know, OpenStreetMap thrives on contributions by mappers, and
>> one of the main reasons we make our tiles freely available is the hope
>> of attracting new contributors. It would be nice if QGIS could do its
>> part to help us here, by making their users aware that OSM is open for
>> everyone to contribute. Perhaps a link to
>> http://www.openstreetmap.org/fixthemap can be placed somewhere in the
>> layer description or something.
>> 
>> 3. Our data is licensed under ODbL 1.0, and our map tiles are CC-BY-SA
>> 2.0. The latter could change at any time; the former is
>> relatively constant.
>> 
>> The legal consequences of this situation for your users are:
>> 
>> * If they publish an image in which our tiles are visible, they must
>> attribute OpenStreetMap as the source, and specify that the map image is
>> CC-BY-SA 2.0, and specify that the data behind it is ODbL 1.0. All these
>> requirements can be fulfilled in one go by linking to
>> www.openstreetmap.org/copyright but there is no legal requirement to
>> link to that page.
>> 
>> * Everyone is allowed to create derivatives of OpenStreetMap data - for
>> example 

Re: [Qgis-developer] FOSS4G Boston QGIS presentation?

[Tim Sutton]

Hi Larry

> On 21 Mar 2017, at 8:12 PM, Larry Shaffer  wrote:
> 
> Hi Tim, Andreas, et al.,
> 
> Thank you for the quick replies and support. I will submit a "State of QGIS" 
> talk today. Regardless of whether it is accepted, I will probably be in 
> attendance at FOSS4G Boston.


Great!

> 
> Note that I intend this talk to be completely vetted by the community. I will 
> be posting to the dev list with requests for comments, opinions and 
> suggestions on content. While I will be working on this talk at work 
> (assuming it is accepted), it will purely be about and for the community's 
> efforts, with absolutely no content related to my employer, excepting to 
> thank them for supporting my attendance to the event.


Thanks that sounds great.

> 
> I could get someone from work to help with the talk, or be a backup; though, 
> I would definitely prefer someone from the QGIS dev community to help in this 
> regard, ideally someone who does not also work for my employer.


I'd be happy to help compiling your slides / reviewing them etc. I guess Kurt 
Menke might be going along - you might want to touch base with him to hear if 
he is going - he isn't a developer but he is very up to speed with QGIS and the 
QGIS community activities. Hopefully anyone else on the dev list who is going 
will pipe up and pitch in if they can.

> 
> Anyone attending FOSS4G Boston and willing to help out? If so, I need to know 
> today. Thanks.

Regards

Tim

> 
> Regards,
> 
> Larry Shaffer
> Dakota Cartography
> Black Hills, South Dakota
> --
> Boundless Desktop and QGIS Support/Development
> Boundless Spatial - http://boundlessgeo.com 
> lshaf...@boundlessgeo.com 
> On Mon, Mar 20, 2017 at 3:08 PM, Andreas Neumann  > wrote:
> Hi Larry,
> 
> I would also welcome, if you could present on behalf of the project.
> 
> I won't be there - I'd love to come. I like Boston / Cambridge. But I can't 
> join FOSS4G this time.
> 
> Thanks a lot,
> 
> Andreas
> 
> On 20.03.2017 22:05, Tim Sutton wrote:
>> Hi Larry
>> 
>>> On 20 Mar 2017, at 6:33 PM, Larry Shaffer >> > wrote:
>>> 
>>> Hi,
>>> 
>>> Call for presentations ends today (or tomorrow?) for FOSS4G 2017 in Boston.
>>> 
>>> Is someone from the QGIS project already giving, or submitted a proposal 
>>> for, a 'State of QGIS' type of presentation?
>>> 
>>> If not I will be going and am willing to put in a proposal for such a talk, 
>>> highlighting QGIS 3 development and upcoming release (if the community is 
>>> OK with that). If so, I would prefer to co-present with someone from the 
>>> project who will also be attending.
>> 
>> I am not sure who else is going along, but it will be great if you can 
>> present on behalf of the project! Big +1 from me!
>> 
>> Regards
>> 
>> Tim
>> 
>>> 
>>> Regards,
>>> 
>>> Larry Shaffer
>>> Dakota Cartography
>>> Black Hills, South Dakota
>>> --
>>> Boundless Desktop and QGIS Support/Development
>>> Boundless Spatial - http://boundlessgeo.com 
>>> lshaf...@boundlessgeo.com 
>>> ___
>>> 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 
>>> 
>> —
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Tim Sutton
>> 
>> Co-founder: Kartoza
>> Project chair: QGIS.org 
>> 
>> Visit http://kartoza.com  to find out about open source:
>> 
>> Desktop GIS programming services
>> Geospatial web development
>> GIS Training
>> Consulting Services
>> 
>> Skype: timlinux 
>> IRC: timlinux on #qgis at freenode.net 
>> 
>> Kartoza is a merger between Linfiniti and Afrispatial
>> 
>> 
>> 
>> ___
>> 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] FOSS4G Boston QGIS presentation?

[Larry Shaffer]

Hi Tim, Andreas, et al.,

Thank you for the quick replies and support. I will submit a "State of
QGIS" talk today. Regardless of whether it is accepted, I will probably be
in attendance at FOSS4G Boston.

Note that I intend this talk to be completely vetted by the community. I
will be posting to the dev list with requests for comments, opinions and
suggestions on content. While I will be working on this talk at work
(assuming it is accepted), it will purely be about and for the community's
efforts, with absolutely no content related to my employer, excepting to
thank them for supporting my attendance to the event.

I could get someone from work to help with the talk, or be a backup;
though, I would definitely prefer someone from the QGIS dev community to
help in this regard, ideally someone who does not also work for my employer.

Anyone attending FOSS4G Boston and willing to help out? If so, I need to
know today. Thanks.

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
--
Boundless Desktop and QGIS Support/Development
Boundless Spatial - http://boundlessgeo.com
lshaf...@boundlessgeo.com

On Mon, Mar 20, 2017 at 3:08 PM, Andreas Neumann 
wrote:

> Hi Larry,
>
> I would also welcome, if you could present on behalf of the project.
>
> I won't be there - I'd love to come. I like Boston / Cambridge. But I
> can't join FOSS4G this time.
>
> Thanks a lot,
>
> Andreas
>
> On 20.03.2017 22:05, Tim Sutton wrote:
>
> Hi Larry
>
> On 20 Mar 2017, at 6:33 PM, Larry Shaffer  wrote:
>
> Hi,
>
> Call for presentations ends today (or tomorrow?) for FOSS4G 2017 in Boston.
>
> Is someone from the QGIS project already giving, or submitted a proposal
> for, a 'State of QGIS' type of presentation?
>
> If not I will be going and am willing to put in a proposal for such a
> talk, highlighting QGIS 3 development and upcoming release (if the
> community is OK with that). If so, I would prefer to co-present with
> someone from the project who will also be attending.
>
>
> I am not sure who else is going along, but it will be great if you can
> present on behalf of the project! Big +1 from me!
>
> Regards
>
> Tim
>
>
> Regards,
>
> Larry Shaffer
> Dakota Cartography
> Black Hills, South Dakota
> --
> Boundless Desktop and QGIS Support/Development
> Boundless Spatial - http://boundlessgeo.com
> lshaf...@boundlessgeo.com
> ___
> 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
>
>
> —
>
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
> Kartoza is a merger between Linfiniti and Afrispatial
>
>
>
> ___
> Qgis-developer mailing listqgis-develo...@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] Adding default OSM backround maps

[Jorge Gustavo Rocha]

Hi Paolo,

I can help on this.

1. The UserAgent is already a configurable feature in QGIS (under
Options/Network). Any user can change it, but we can propose another
default value.

2. The QGIS community is very much aware of OpenStreetMap. If we really
need to make our users more aware, does it make sense to add a new
button to QGIS to report map errors? (context dependent, when the
OpenStreetMap layer is shown) It would have the same functionality of
the notes in OpenStreetMap web interface.

3.1 On the "add layer" dialog, we can show the OpenStreetMap url (which
might change over time) and licenses (for data and tiles) taken from
settings or an (external) resource. We can make this not hard coded, to
be modified easily, without upgrading QGIS. We can also check if the
service is enabled for us, before allow users to add that layer (related
with 4.).

3.2 When the tiles are used in the composer or on the web client, we can
not enforce an attribution string. We might add or suggest it, but users
should be free the create and edit the attributions. It the
responsibility of the user, not a QGIS responsibility.

4. We have to handle when tiles are not loading, either because there
are network problems, server busy, etc. We can customize the user's
feedback regarding the load of the default OpenStreetMap tiles. But we
definitely need to know formally when they shut our access down. This is
related with 3.1 issue. If the access is disabled, we can also disable
adding default OpenStreetMap tiles option.

Regards,

Jorge Gustavo

Às 09:52 de 21-03-2017, Paolo Cavallini escreveu:
> Hi all,
> we have been exploring the possibility of adding default XYZ maps to
> QGIS, so to make life far easier for users.
> The good news is that the OSM board is quite positive about this.
> The not-so-good news is that their (I believe reasonable) requirements
> imply some more development from our side.
> Is anyone interested in taking this?
> Requirements below.
> All the best.
> ===
> 
> 1. You seem to be using an user agent of "Mozilla/5.0 QGIS/2.18.3". We
> strongly recommend that you don't pretend to be a browser by adding the
> "Mozilla" bit. OpenStreetMap sees increasing traffic from "fake" user
> agents, and it is likely that we will penalise user agents like that at
> some point in the future - meaning tiles will still be served, but
> slower than to "honest" user agents that don't pretend to be a browser
> when they are not. We understand that this is difficult terrain and that
> other data sources might actually *require* that you pretend to be a
> browser - perhaps per-datasource overrides of the user agent are a
> possibility.
> 
> 2. As you know, OpenStreetMap thrives on contributions by mappers, and
> one of the main reasons we make our tiles freely available is the hope
> of attracting new contributors. It would be nice if QGIS could do its
> part to help us here, by making their users aware that OSM is open for
> everyone to contribute. Perhaps a link to
> http://www.openstreetmap.org/fixthemap can be placed somewhere in the
> layer description or something.
> 
> 3. Our data is licensed under ODbL 1.0, and our map tiles are CC-BY-SA
> 2.0. The latter could change at any time; the former is
> relatively constant.
> 
> The legal consequences of this situation for your users are:
> 
> * If they publish an image in which our tiles are visible, they must
> attribute OpenStreetMap as the source, and specify that the map image is
> CC-BY-SA 2.0, and specify that the data behind it is ODbL 1.0. All these
> requirements can be fulfilled in one go by linking to
> www.openstreetmap.org/copyright but there is no legal requirement to
> link to that page.
> 
> * Everyone is allowed to create derivatives of OpenStreetMap data - for
> example by tracing features on the OSM tiles - and freely distribute
> them. Such derived datasets, unless they are "insubstantial"
> (https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline)
> inherit the ODbL license and must, when publicly used, on request be
> made available under ODbL.
> 
> 4. If the load coming from QGIS should be unexpectedly high and impact
> our service performance, there might come a time where we'd have to
> throttle or even switch off this access. You should have some mechanism
> or plan that deals with that to avoid frustration among your user base -
> maybe a mechanism where QGIS installations request updated tile sources
> from a central service so you could notify them of the OSM tiles not
> being available (or being available elsewhere) should the need arise.
> 

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: 

Re: [Qgis-developer] Select by Radius

[Finbar Gillen]

Marco,

I actually noticed that, I made a mistake with how I done this analysis before.

I have set the ‘CRS of the Project from Layer’ and this seems to have given the 
correct answer.

Finbar


From: Marco Lechner [mailto:mlech...@bfs.de]
Sent: 21 March 2017 14:51
To: Finbar Gillen; qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] Select by Radius

You are welcome,

but be careful with creating circles based on different (esp. non metric) 
coordinate reference systems.

Marco


Finbar Gillen > hat am 21. 
März 2017 um 15:04 geschrieben:
Marco,

That worked out great! Thanks for your help.

Regards
Finbar

From: Marco Lechner [mailto:mlech...@bfs.de]
Sent: 21 March 2017 12:26
To: Finbar Gillen; 
qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] Select by Radius

Hi Finbar,

Expresions are using SQL (and usually are the part after the "WHERE". If you 
have a point layer (in a metric KBS) you could use "Select by Expression" from 
Menu -> View -> Select and put in

intersects( $geometry, buffer( geom_from_wkt( 'POINT(410611 5315209)'), 3000))

This selects all onjects of the active layer that are within a 3000m Buffer 
(=circle) around the point 410611 5315209

No python programming needed!

Marco

And by the way: QGIS has a really great documentation:

http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/expression.html
http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/attribute_table.html

Finbar Gillen > hat am 21. 
März 2017 um 12:49 geschrieben:
Hi Marco,

Thanks for the quick response! Would you have an example of python code I would 
put in the expression?

This is an area I will need to upskill on.

Regards
Finbar

From: Marco Lechner [mailto:mlech...@bfs.de]
Sent: 21 March 2017 11:25
To: Finbar Gillen; 
qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Select by Radius

hi Finbar,
you could use select by expression and use geometry functions available in the 
Expresions dialog to create the readius (e.g. buffering the point, created ba 
geometry_from_text). If you need thisvery often, you could create a simple 
model with the preocessing plugin doing what i described.
Marco
Finbar Gillen > hat am 21. 
März 2017 um 12:17 geschrieben:
Hi all,


Another query, I have recently shifted to QGIS from ArcGIS and am looking for 
some help/pointers with the following:

Does QGIS have a method by which I can specify a lat-lon coordinate (or a utm 
x,y coordinates, coordinate system not imp), and get all features that lie 
within a certain radius of this point?

I have used the measure tool to draw a line and expand my radius out to the end 
of the line but looking a more accurate, efficient way of doing it.

Regards,

Finbar



Vhi Group DAC (Vhi) is a holding company for insurance and healthcare services, 
which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC 
and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi Healthcare and Vhi 
Insurance DAC trading as Vhi Insurance are regulated by the Central Bank of 
Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for health insurance in 
Ireland which is underwritten by Vhi Insurance DAC. Vhi Healthcare is tied to 
Zurich Life Assurance plc for Vhi Life Term Insurance which is underwritten by 
Zurich Life Assurance plc. Vhi Healthcare is tied to Collinson Insurance 
Services Limited for MultiTrip Travel Insurance, Backpacker Travel Insurance 
and Vhi Dental Insurance which are underwritten by Great Lakes Reinsurance (UK) 
SE and for Vhi Canada Cover and Vhi International Health Insurance which are 
underwritten by Astrenska Insurance Limited. For more information about the Vhi 
Group please go to: 
https://www.vhi.ie/about-vhi.

Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh seirbhísí 
árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi Healthcare DAC, Vhi 
Insurance DAC, Vhi Health Services DAC agus Vhi Investments DAC. Déanann Banc 
Ceannais na hÉireann rialáil ar Vhi Healthcare DAC, ag trádáil dó mar Vhi 
Healthcare, agus ar Vhi Insurance DAC, ag trádáil dó mar Vhi Insurance. Tá Vhi 
Healthcare ceangailte le Vhi Insurance DAC le haghaidh árachas sláinte in 
Éirinn, rud atá frithgheallta ag Vhi 

Re: [Qgis-developer] Select by Radius

[Marco Lechner]

You are welcome,

but be careful with creating circles based on different (esp. non metric) 
coordinate reference systems.

Marco


> Finbar Gillen  hat am 21. März 2017 um 15:04 
> geschrieben:
> 
> 
> Marco,
> 
>  
> 
> That worked out great! Thanks for your help.
> 
>  
> 
> Regards
> 
> Finbar
> 
>  
> 
> From: Marco Lechner [mailto:mlech...@bfs.de]
> Sent: 21 March 2017 12:26
> To: Finbar Gillen; qgis-developer@lists.osgeo.org
> Subject: RE: [Qgis-developer] Select by Radius
> 
>  
> 
> Hi Finbar,
> 
> Expresions are using SQL (and usually are the part after the "WHERE". 
> If you have a point layer (in a metric KBS) you could use "Select by 
> Expression" from Menu -> View -> Select and put in
> 
> intersects( $geometry, buffer( geom_from_wkt( 'POINT(410611 
> 5315209)'), 3000))
> 
> This selects all onjects of the active layer that are within a 3000m 
> Buffer (=circle) around the point 410611 5315209
> 
> No python programming needed!
> 
> Marco
> 
> And by the way: QGIS has a really great documentation:
> 
> 
> http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/expression.html
>  
> http://scanmail.trustwave.com/?c=6600=0pvR2HQZGUpQrIYiEst1Wq3x0a8I_XAiASvYJpcc1A=33=http%3a%2f%2fdocs%2eqgis%2eorg%2f2%2e14%2fen%2fdocs%2fuser%5fmanual%2fworking%5fwith%5fvector%2fexpression%2ehtml
> 
> http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/attribute_table.html
>  
> http://scanmail.trustwave.com/?c=6600=0pvR2HQZGUpQrIYiEst1Wq3x0a8I_XAiASrfLsca1A=33=http%3a%2f%2fdocs%2eqgis%2eorg%2f2%2e14%2fen%2fdocs%2fuser%5fmanual%2fworking%5fwith%5fvector%2fattribute%5ftable%2ehtml
> 
> 
> 
> Finbar Gillen  hat 
> am 21. März 2017 um 12:49 geschrieben:
> 
> Hi Marco,
> 
>  
> 
> Thanks for the quick response! Would you have an example of python 
> code I would put in the expression?
> 
>  
> 
> This is an area I will need to upskill on.
> 
>  
> 
> Regards
> 
> Finbar
> 
>  
> 
>From: Marco Lechner [mailto:mlech...@bfs.de]
>Sent: 21 March 2017 11:25
>To: Finbar Gillen; qgis-developer@lists.osgeo.org 
> mailto:qgis-developer@lists.osgeo.org
>Subject: Re: [Qgis-developer] Select by Radius
> 
> 
> 
>hi Finbar,
>you could use select by expression and use geometry functions 
> available in the Expresions dialog to create the readius (e.g. buffering the 
> point, created ba geometry_from_text). If you need thisvery often, you could 
> create a simple model with the preocessing plugin doing what i described.
>Marco
> 
> 
>Finbar Gillen  
> hat am 21. März 2017 um 12:17 geschrieben:
> 
>Hi all,
> 
> 
> 
>Another query, I have recently shifted to QGIS from ArcGIS and am 
> looking for some help/pointers with the following:
> 
>Does QGIS have a method by which I can specify a lat-lon 
> coordinate (or a utm x,y coordinates, coordinate system not imp), and get all 
> features that lie within a certain radius of this point?
> 
>I have used the measure tool to draw a line and expand my radius 
> out to the end of the line but looking a more accurate, efficient way of 
> doing it.
> 
>Regards,
> 
>Finbar
> 
> 
> 
> 
> 
> 
>Vhi Group DAC (Vhi) is a holding company for insurance and 
> healthcare services, which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi 
> Health Services DAC and Vhi Investments DAC. Vhi Healthcare DAC trading as 
> Vhi Healthcare and Vhi Insurance DAC trading as Vhi Insurance are regulated 
> by the Central Bank of Ireland. Vhi Healthcare is tied to Vhi Insurance DAC 
> for health insurance in Ireland which is underwritten by Vhi Insurance DAC. 
> Vhi Healthcare is tied to Zurich Life Assurance plc for Vhi Life Term 
> Insurance which is underwritten by Zurich Life Assurance plc. Vhi Healthcare 
> is tied to Collinson Insurance Services Limited for MultiTrip Travel 
> Insurance, Backpacker Travel Insurance and Vhi Dental Insurance which are 
> underwritten by Great Lakes Reinsurance (UK) SE and for Vhi Canada Cover and 
> Vhi International Health Insurance which are underwritten by Astrenska 
> Insurance Limited. For more information about the Vhi Group please go to: 
> https://www.vhi.ie/about-vhi. 
> http://scanmail.trustwave.com/?c=6600=0pvR2HQZGUpQrIYiEst1Wq3x0a8I_XAiASzYeMMd1w=33=https%3a%2f%2fwww%2evhi%2eie%2fabout-vhi
> 
>Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh 
> seirbhísí árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi 
> Healthcare DAC, Vhi Insurance DAC, Vhi 

Re: [Qgis-developer] Select by Radius

[Finbar Gillen]

Marco,

That worked out great! Thanks for your help.

Regards
Finbar

From: Marco Lechner [mailto:mlech...@bfs.de]
Sent: 21 March 2017 12:26
To: Finbar Gillen; qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] Select by Radius

Hi Finbar,

Expresions are using SQL (and usually are the part after the "WHERE". If you 
have a point layer (in a metric KBS) you could use "Select by Expression" from 
Menu -> View -> Select and put in

intersects( $geometry, buffer( geom_from_wkt( 'POINT(410611 5315209)'), 3000))

This selects all onjects of the active layer that are within a 3000m Buffer 
(=circle) around the point 410611 5315209

No python programming needed!

Marco

And by the way: QGIS has a really great documentation:

http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/expression.html
http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/attribute_table.html


Finbar Gillen > hat am 21. 
März 2017 um 12:49 geschrieben:
Hi Marco,

Thanks for the quick response! Would you have an example of python code I would 
put in the expression?

This is an area I will need to upskill on.

Regards
Finbar

From: Marco Lechner [mailto:mlech...@bfs.de]
Sent: 21 March 2017 11:25
To: Finbar Gillen; 
qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Select by Radius

hi Finbar,
you could use select by expression and use geometry functions available in the 
Expresions dialog to create the readius (e.g. buffering the point, created ba 
geometry_from_text). If you need thisvery often, you could create a simple 
model with the preocessing plugin doing what i described.
Marco

Finbar Gillen > hat am 21. 
März 2017 um 12:17 geschrieben:
Hi all,


Another query, I have recently shifted to QGIS from ArcGIS and am looking for 
some help/pointers with the following:

Does QGIS have a method by which I can specify a lat-lon coordinate (or a utm 
x,y coordinates, coordinate system not imp), and get all features that lie 
within a certain radius of this point?

I have used the measure tool to draw a line and expand my radius out to the end 
of the line but looking a more accurate, efficient way of doing it.

Regards,

Finbar



Vhi Group DAC (Vhi) is a holding company for insurance and healthcare services, 
which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC 
and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi Healthcare and Vhi 
Insurance DAC trading as Vhi Insurance are regulated by the Central Bank of 
Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for health insurance in 
Ireland which is underwritten by Vhi Insurance DAC. Vhi Healthcare is tied to 
Zurich Life Assurance plc for Vhi Life Term Insurance which is underwritten by 
Zurich Life Assurance plc. Vhi Healthcare is tied to Collinson Insurance 
Services Limited for MultiTrip Travel Insurance, Backpacker Travel Insurance 
and Vhi Dental Insurance which are underwritten by Great Lakes Reinsurance (UK) 
SE and for Vhi Canada Cover and Vhi International Health Insurance which are 
underwritten by Astrenska Insurance Limited. For more information about the Vhi 
Group please go to: 
https://www.vhi.ie/about-vhi.

Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh seirbhísí 
árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi Healthcare DAC, Vhi 
Insurance DAC, Vhi Health Services DAC agus Vhi Investments DAC. Déanann Banc 
Ceannais na hÉireann rialáil ar Vhi Healthcare DAC, ag trádáil dó mar Vhi 
Healthcare, agus ar Vhi Insurance DAC, ag trádáil dó mar Vhi Insurance. Tá Vhi 
Healthcare ceangailte le Vhi Insurance DAC le haghaidh árachas sláinte in 
Éirinn, rud atá frithgheallta ag Vhi Insurance DAC. Tá Vhi Healthcare 
ceangailte le Zurich Life Assurance plc le haghaidh árachais saoil in Éirinn, 
rud atá frithgheallta ag Zurich Life Assurance plc. Tá Vhi Healthcare 
ceangailte le Collinson Insurance Services Limited le haghaidh Árachas Taistil 
Ilturais agus Turasóirí Mála Droma agus Árachas Fiaclóireachta de chuid Vhi atá 
frithgheallta ag Great Lakes Reinsurance (UK) SE agus le haghaidh Clúdach 
Cheanada de chuid Vhi agus Árachas Sláinte Idirnáisiúnta de chuid Vhi atá 
frithgheallta ag Astrenska Insurance Limited. Chun tuilleadh faisnéise a fháil 
faoi Ghrúpa Vhi, tabhair cuairt ar: 

Re: [Qgis-developer] Select by Radius

[Marco Lechner]

Hi Finbar,

Expresions are using SQL (and usually are the part after the "WHERE". If you 
have a point layer (in a metric KBS) you could use "Select by Expression" from 
Menu -> View -> Select and put in

intersects( $geometry, buffer( geom_from_wkt( 'POINT(410611 5315209)'), 3000))

This selects all onjects of the active layer that are within a 3000m Buffer 
(=circle) around the point 410611 5315209

No python programming needed!

Marco

And by the way: QGIS has a really great documentation:

http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/expression.html
http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/attribute_table.html


> Finbar Gillen  hat am 21. März 2017 um 12:49 
> geschrieben:
> 
> 
> Hi Marco,
> 
>  
> 
> Thanks for the quick response! Would you have an example of python code I 
> would put in the expression?
> 
>  
> 
> This is an area I will need to upskill on.
> 
>  
> 
> Regards
> 
> Finbar
> 
>  
> 
> From: Marco Lechner [mailto:mlech...@bfs.de]
> Sent: 21 March 2017 11:25
> To: Finbar Gillen; qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Select by Radius
> 
>  
> 
> hi Finbar,
> you could use select by expression and use geometry functions 
> available in the Expresions dialog to create the readius (e.g. buffering the 
> point, created ba geometry_from_text). If you need thisvery often, you could 
> create a simple model with the preocessing plugin doing what i described.
> Marco
> 
> 
> 
> Finbar Gillen  hat 
> am 21. März 2017 um 12:17 geschrieben:
> 
> Hi all,
> 
>  
> 
> Another query, I have recently shifted to QGIS from ArcGIS and am 
> looking for some help/pointers with the following:
> 
> Does QGIS have a method by which I can specify a lat-lon coordinate 
> (or a utm x,y coordinates, coordinate system not imp), and get all features 
> that lie within a certain radius of this point?
> 
> I have used the measure tool to draw a line and expand my radius out 
> to the end of the line but looking a more accurate, efficient way of doing it.
> 
> Regards,
> 
> Finbar
> 
>  
> 
> 
>  
> 
> Vhi Group DAC (Vhi) is a holding company for insurance and healthcare 
> services, which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health 
> Services DAC and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi 
> Healthcare and Vhi Insurance DAC trading as Vhi Insurance are regulated by 
> the Central Bank of Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for 
> health insurance in Ireland which is underwritten by Vhi Insurance DAC. Vhi 
> Healthcare is tied to Zurich Life Assurance plc for Vhi Life Term Insurance 
> which is underwritten by Zurich Life Assurance plc. Vhi Healthcare is tied to 
> Collinson Insurance Services Limited for MultiTrip Travel Insurance, 
> Backpacker Travel Insurance and Vhi Dental Insurance which are underwritten 
> by Great Lakes Reinsurance (UK) SE and for Vhi Canada Cover and Vhi 
> International Health Insurance which are underwritten by Astrenska Insurance 
> Limited. For more information about the Vhi Group please go to: 
> https://www.vhi.ie/about-vhi. 
> http://scanmail.trustwave.com/?c=6600=i43R2EsV50gT_vvdEg8Zuzi1taFlje6xQMflOOrSiw=33=https%3a%2f%2fwww%2evhi%2eie%2fabout-vhi
> 
> Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh 
> seirbhísí árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi 
> Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC agus Vhi 
> Investments DAC. Déanann Banc Ceannais na hÉireann rialáil ar Vhi Healthcare 
> DAC, ag trádáil dó mar Vhi Healthcare, agus ar Vhi Insurance DAC, ag trádáil 
> dó mar Vhi Insurance. Tá Vhi Healthcare ceangailte le Vhi Insurance DAC le 
> haghaidh árachas sláinte in Éirinn, rud atá frithgheallta ag Vhi Insurance 
> DAC. Tá Vhi Healthcare ceangailte le Zurich Life Assurance plc le haghaidh 
> árachais saoil in Éirinn, rud atá frithgheallta ag Zurich Life Assurance plc. 
> Tá Vhi Healthcare ceangailte le Collinson Insurance Services Limited le 
> haghaidh Árachas Taistil Ilturais agus Turasóirí Mála Droma agus Árachas 
> Fiaclóireachta de chuid Vhi atá frithgheallta ag Great Lakes Reinsurance (UK) 
> SE agus le haghaidh Clúdach Cheanada de chuid Vhi agus Árachas Sláinte 
> Idirnáisiúnta de chuid Vhi atá frithgheallta ag Astrenska Insurance Limited. 
> Chun tuilleadh faisnéise a fháil faoi Ghrúpa Vhi, tabhair cuairt ar: 
> https://www.vhi.ie/about-vhi. 
> http://scanmail.trustwave.com/?c=6600=i43R2EsV50gT_vvdEg8Zuzi1taFlje6xQMflOOrSiw=33=https%3a%2f%2fwww%2evhi%2eie%2fabout-vhi
> 
> This e-mail and any files transmitted with it contain information 
> which may be confidential and which may also be privileged and is intended 
> solely for the 

Re: [Qgis-developer] ShapeTools XY to Line

[Giovanni Manghi]

Hi!


> Another question I have is whether there are other ArcGIS functions that
> are missing in QGIS that would be good to implement.

amazingly in processing we don't have an easy/obvious (at least for me) way to

* snap points to lines
* cut lines with points
* a tool to perform distance analysis

cheers!

-- G --
___
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] Select by Radius

[Marco Lechner]

hi Finbar,
you could use select by expression and use geometry functions available in the 
Expresions dialog to create the readius (e.g. buffering the point, created ba 
geometry_from_text). If you need thisvery often, you could create a simple 
model with the preocessing plugin doing what i described.
Marco


> Finbar Gillen  hat am 21. März 2017 um 12:17 
> geschrieben:
> 
> 
> Hi all,
> 
>  
> 
> Another query, I have recently shifted to QGIS from ArcGIS and am looking 
> for some help/pointers with the following:
> 
> Does QGIS have a method by which I can specify a lat-lon coordinate (or a 
> utm x,y coordinates, coordinate system not imp), and get all features that 
> lie within a certain radius of this point?
> 
> I have used the measure tool to draw a line and expand my radius out to 
> the end of the line but looking a more accurate, efficient way of doing it.
> 
> Regards,
> 
> Finbar
> 
>  
> 
 

> Vhi Group DAC (Vhi) is a holding company for insurance and healthcare 
> services, which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health 
> Services DAC and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi 
> Healthcare and Vhi Insurance DAC trading as Vhi Insurance are regulated by 
> the Central Bank of Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for 
> health insurance in Ireland which is underwritten by Vhi Insurance DAC. Vhi 
> Healthcare is tied to Zurich Life Assurance plc for Vhi Life Term Insurance 
> which is underwritten by Zurich Life Assurance plc. Vhi Healthcare is tied to 
> Collinson Insurance Services Limited for MultiTrip Travel Insurance, 
> Backpacker Travel Insurance and Vhi Dental Insurance which are underwritten 
> by Great Lakes Reinsurance (UK) SE and for Vhi Canada Cover and Vhi 
> International Health Insurance which are underwritten by Astrenska Insurance 
> Limited. For more information about the Vhi Group please go to: 
> https://www.vhi.ie/about-vhi.
> 
> Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh 
> seirbhísí árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi 
> Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC agus Vhi 
> Investments DAC. Déanann Banc Ceannais na hÉireann rialáil ar Vhi Healthcare 
> DAC, ag trádáil dó mar Vhi Healthcare, agus ar Vhi Insurance DAC, ag trádáil 
> dó mar Vhi Insurance. Tá Vhi Healthcare ceangailte le Vhi Insurance DAC le 
> haghaidh árachas sláinte in Éirinn, rud atá frithgheallta ag Vhi Insurance 
> DAC. Tá Vhi Healthcare ceangailte le Zurich Life Assurance plc le haghaidh 
> árachais saoil in Éirinn, rud atá frithgheallta ag Zurich Life Assurance plc. 
> Tá Vhi Healthcare ceangailte le Collinson Insurance Services Limited le 
> haghaidh Árachas Taistil Ilturais agus Turasóirí Mála Droma agus Árachas 
> Fiaclóireachta de chuid Vhi atá frithgheallta ag Great Lakes Reinsurance (UK) 
> SE agus le haghaidh Clúdach Cheanada de chuid Vhi agus Árachas Sláinte 
> Idirnáisiúnta de chuid Vhi atá frithgheallta ag Astrenska Insurance Limited. 
> Chun tuilleadh faisnéise a fháil faoi Ghrúpa Vhi, tabhair cuairt ar: 
> https://www.vhi.ie/about-vhi.
> 
> This e-mail and any files transmitted with it contain information which 
> may be confidential and which may also be privileged and is intended solely 
> for the use of the individual or entity to whom it is addressed. Unless you 
> are the intended recipient you may not copy or use it, or disclose it to 
> anyone else. Any opinions expressed are that of the individual and not 
> necessarily that of the Vhi Group. If you have received this e-mail in error 
> please notify the sender by return.
> 
> 
> ___
> 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] Select by Radius

[Finbar Gillen]

Hi all,


Another query, I have recently shifted to QGIS from ArcGIS and am looking for 
some help/pointers with the following:

Does QGIS have a method by which I can specify a lat-lon coordinate (or a utm 
x,y coordinates, coordinate system not imp), and get all features that lie 
within a certain radius of this point?

I have used the measure tool to draw a line and expand my radius out to the end 
of the line but looking a more accurate, efficient way of doing it.

Regards,

Finbar

Vhi Group DAC (Vhi) is a holding company for insurance and healthcare services, 
which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC 
and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi Healthcare and Vhi 
Insurance DAC trading as Vhi Insurance are regulated by the Central Bank of 
Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for health insurance in 
Ireland which is underwritten by Vhi Insurance DAC. Vhi Healthcare is tied to 
Zurich Life Assurance plc for Vhi Life Term Insurance which is underwritten by 
Zurich Life Assurance plc. Vhi Healthcare is tied to Collinson Insurance 
Services Limited for MultiTrip Travel Insurance, Backpacker Travel Insurance 
and Vhi Dental Insurance which are underwritten by Great Lakes Reinsurance (UK) 
SE and for Vhi Canada Cover and Vhi International Health Insurance which are 
underwritten by Astrenska Insurance Limited. For more information about the Vhi 
Group please go to: https://www.vhi.ie/about-vhi.

Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh seirbhísí 
árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi Healthcare DAC, Vhi 
Insurance DAC, Vhi Health Services DAC agus Vhi Investments DAC. Déanann Banc 
Ceannais na hÉireann rialáil ar Vhi Healthcare DAC, ag trádáil dó mar Vhi 
Healthcare, agus ar Vhi Insurance DAC, ag trádáil dó mar Vhi Insurance. Tá Vhi 
Healthcare ceangailte le Vhi Insurance DAC le haghaidh árachas sláinte in 
Éirinn, rud atá frithgheallta ag Vhi Insurance DAC. Tá Vhi Healthcare 
ceangailte le Zurich Life Assurance plc le haghaidh árachais saoil in Éirinn, 
rud atá frithgheallta ag Zurich Life Assurance plc. Tá Vhi Healthcare 
ceangailte le Collinson Insurance Services Limited le haghaidh Árachas Taistil 
Ilturais agus Turasóirí Mála Droma agus Árachas Fiaclóireachta de chuid Vhi atá 
frithgheallta ag Great Lakes Reinsurance (UK) SE agus le haghaidh Clúdach 
Cheanada de chuid Vhi agus Árachas Sláinte Idirnáisiúnta de chuid Vhi atá 
frithgheallta ag Astrenska Insurance Limited. Chun tuilleadh faisnéise a fháil 
faoi Ghrúpa Vhi, tabhair cuairt ar: https://www.vhi.ie/about-vhi.

This e-mail and any files transmitted with it contain information which may be 
confidential and which may also be privileged and is intended solely for the 
use of the individual or entity to whom it is addressed. Unless you are the 
intended recipient you may not copy or use it, or disclose it to anyone else. 
Any opinions expressed are that of the individual and not necessarily that of 
the Vhi Group. If you have received this e-mail in error please notify the 
sender by return.


___
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] Broken sip composer item subclassing in 2.18

[Tim Sutton]

Hi Nyall 

It's probably the same issue as described here:

http://osgeo-org.1560.x6.nabble.com/API-Break-in-2-16-for-QgsComposition-td5276424.html

Regards 

Tim Sutton 
Co-founder of Kartoza 
QGIS project chairman 

> On 21 Mar 2017, at 10:56 AM, Nyall Dawson  wrote:
> 
> Hi all,
> 
> I noticed today that composer item subclassing seems broken in 2.18.4 (on 
> linux, untested on other platforms). If I enter something like:
> 
> iface.activeComposers()[0].items()
> 
> I see mostly QgsComposerItem items, rather then the correct subclasses. It's 
> random though, and sometimes the correct item type is returned.
> 
> Is anyone else experiencing this? I'm stumped with this - I can't see any 
> related changes in the code, and the generated cpp looks fine to me.
> 
> 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] QGIS build error

[Yves Jacolin]

building QGIS from scratch I have such error (plenty of this)

https://gist.github.com/yjacolin/c84beac6d4d62fd0be6036651cec5df4

I am using Qt 5.6 is it a problem?

Thanks,

Y.


signature.asc
Description: This is a digitally signed message part.
___
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] Corrections of QgsOgrProvider implementaion of GDAL 2.0

[Even Rouault]

On mardi 21 mars 2017 11:07:18 CET Mark Johnson wrote:
> > That will *not* work for other formats that can have multiple geometry
> > fields, like GML.
> 
> Could you send me such a GML to test this?

Sure you'll find attached such a .gml and the corresponding .xsd

> Have you ever seen or have a GML with a duplicate layer-name?
> 
No, that's not possible given how the GML format work.



-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


multiplegeomfields.gml
Description: application/gml


multiplegeomfields.xsd
Description: XML document
___
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] Corrections of QgsOgrProvider implementaion of GDAL 2.0

[Mark Johnson]

>
> That will *not* work for other formats that can have multiple geometry
> fields, like GML.

Could you send me such a GML to test this?
Have you ever seen or have a GML with a duplicate layer-name?

but it would probably be cleaner to have a dedicated URI parameter for the
> geometry column name.
>
ok

> Anyway at the OGR API level, I reiterate that we must have a separate OGR
> layer name (for GetLayerByname()) and OGR geometry field name (for
> GetGeomFieldIndex())
>
ok



QgsWkbTypes::parseType could be used for ogrWkbGeometryTypeFromName.
___
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] Corrections of QgsOgrProvider implementaion of GDAL 2.0

[Even Rouault]

> To solve the issue of several geometry fields we also need a (optional)
> 
> > parameter with the geometry column name.
> 
> subLayers() will send the layer name in the 'table_name(field_name)' format
> 
> It was only with gdal 1 that GDALDatasetGetLayerByName could not use that
> format.
> That means the 'table_name(field_name)' format can always be used.

table_name(field_name) is only valid as a OGR layer name for the SQLite driver 
and this is a 
legacy behaviour of the GDAL 1 era. That will *not* work for other formats that 
can have 
multiple geometry fields, like GML.

We could potentially use it as a QGIS layername, but it would probably be 
cleaner to have a 
dedicated URI parameter for the geometry column name. Anyway at the OGR API 
level, I 
reiterate that we must have a separate OGR layer name (for GetLayerByname()) 
and OGR 
geometry field name (for GetGeomFieldIndex())

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
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] Adding default OSM backround maps

[Paolo Cavallini]

Hi all,
we have been exploring the possibility of adding default XYZ maps to
QGIS, so to make life far easier for users.
The good news is that the OSM board is quite positive about this.
The not-so-good news is that their (I believe reasonable) requirements
imply some more development from our side.
Is anyone interested in taking this?
Requirements below.
All the best.
===

1. You seem to be using an user agent of "Mozilla/5.0 QGIS/2.18.3". We
strongly recommend that you don't pretend to be a browser by adding the
"Mozilla" bit. OpenStreetMap sees increasing traffic from "fake" user
agents, and it is likely that we will penalise user agents like that at
some point in the future - meaning tiles will still be served, but
slower than to "honest" user agents that don't pretend to be a browser
when they are not. We understand that this is difficult terrain and that
other data sources might actually *require* that you pretend to be a
browser - perhaps per-datasource overrides of the user agent are a
possibility.

2. As you know, OpenStreetMap thrives on contributions by mappers, and
one of the main reasons we make our tiles freely available is the hope
of attracting new contributors. It would be nice if QGIS could do its
part to help us here, by making their users aware that OSM is open for
everyone to contribute. Perhaps a link to
http://www.openstreetmap.org/fixthemap can be placed somewhere in the
layer description or something.

3. Our data is licensed under ODbL 1.0, and our map tiles are CC-BY-SA
2.0. The latter could change at any time; the former is
relatively constant.

The legal consequences of this situation for your users are:

* If they publish an image in which our tiles are visible, they must
attribute OpenStreetMap as the source, and specify that the map image is
CC-BY-SA 2.0, and specify that the data behind it is ODbL 1.0. All these
requirements can be fulfilled in one go by linking to
www.openstreetmap.org/copyright but there is no legal requirement to
link to that page.

* Everyone is allowed to create derivatives of OpenStreetMap data - for
example by tracing features on the OSM tiles - and freely distribute
them. Such derived datasets, unless they are "insubstantial"
(https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline)
inherit the ODbL license and must, when publicly used, on request be
made available under ODbL.

4. If the load coming from QGIS should be unexpectedly high and impact
our service performance, there might come a time where we'd have to
throttle or even switch off this access. You should have some mechanism
or plan that deals with that to avoid frustration among your user base -
maybe a mechanism where QGIS installations request updated tile sources
from a central service so you could notify them of the OSM tiles not
being available (or being available elsewhere) should the need arise.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
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] GSOC project idea

[Sai Harsh Tondomker]

Hi All,
I am Sai Harsh from IIIT-Sri City, I have been using QGIS from past 8
months, I am good at Python and C++ programming apart from this I have
2-year research experience in implementation of algorithmic graph theory.

Here I attach the project write-up, please suggest me whether it's a good
project for GSOC.

Please Clickhere
to
give comment on the write-up,

Awaiting for the response.

Thanks & Regards,
Harsh




On Tue, Mar 21, 2017 at 10:46 AM, Sai Harsh Tondomker  wrote:

> Hi Nyall,
> Thanks for your valuable reply.
> I will try to complete the project write-up(1-2 pages and with some
> additional features) within 2 days.
>
> Thanks & Regards,
> Harsh
>
>
>
>
>    Sent with Mailtrack
> 
>
> On Tue, Mar 21, 2017 at 3:44 AM, Nyall Dawson 
> wrote:
>
>> Hi Sai!
>>
>> Thanks for raising interested in this - we'd love to have more GSOC
>> candidates for the project!
>>
>> Some specific comments inline below:
>>
>> On 21 March 2017 at 06:03, Sai Harsh Tondomker 
>> wrote:>
>> > 1. Without restarting qgis, it will display the newly added plugin.
>> best of my knowledge this feature is not present in qgis.
>>
>> That's already present if plugins are installed using the plugin
>> installer. The master version of the installer also allows
>> installation of offline plugin zips, which will immediately be loaded
>> without restart.
>>
>> > 2.Let us suppose if in a .csv file we have lat, long column, when it's
>> uploaded to qgis it will mark all the places which this lat & long is
>> representing.(If user needs it), it's useful because lat & long are used
>> quite often.
>>
>> That's also already present, using either the delimited text provider
>> or the OGR provider.
>>
>> > 4. Qgis to support Python 3 without breaking python 2.
>>
>> We've made the decision that QGIS 3.0 is when we break API and move to
>> Python 3 only. We won't accept backward compatibility here as it gets
>> very tricky with our various dependencies, especially PyQt. So the
>> master branch is now fully Python 3 and does not support Python 2.
>>
>> > 3. While uploading the .csv file (in which duplicate names exist) to
>> merge with attribute table in qgis, the duplicates can be merge depending
>> on the formula applied, this feature is not present in qgis.
>>
>> This sounds interesting! We could certainly benefit a lot from both
>> greater power available through joins and relations, and also
>> duplicate management is quite poor in QGIS. I'd suggest the second
>> half of this (duplicate management) could be a great project to
>> explore.
>>
>> 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] Drive Time Analysis

[Finbar Gillen]

Hi all,

I am looking to do some drive time isochrones to access accessibility to some 
facilities.

Has anyone done this before using QGIS and have any advice on how to go about 
it?

Any Help is greatly appreciated.

Regards

Finbar Gillen
Vhi Group DAC (Vhi) is a holding company for insurance and healthcare services, 
which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health Services DAC 
and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi Healthcare and Vhi 
Insurance DAC trading as Vhi Insurance are regulated by the Central Bank of 
Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for health insurance in 
Ireland which is underwritten by Vhi Insurance DAC. Vhi Healthcare is tied to 
Zurich Life Assurance plc for Vhi Life Term Insurance which is underwritten by 
Zurich Life Assurance plc. Vhi Healthcare is tied to Collinson Insurance 
Services Limited for MultiTrip Travel Insurance, Backpacker Travel Insurance 
and Vhi Dental Insurance which are underwritten by Great Lakes Reinsurance (UK) 
SE and for Vhi Canada Cover and Vhi International Health Insurance which are 
underwritten by Astrenska Insurance Limited. For more information about the Vhi 
Group please go to: https://www.vhi.ie/about-vhi.

Tá Vhi Group DAC (Vhi) ina chuideachta sealbhaíochta le haghaidh seirbhísí 
árachais agus seirbhísí cúram sláinte, lena n-áirítear Vhi Healthcare DAC, Vhi 
Insurance DAC, Vhi Health Services DAC agus Vhi Investments DAC. Déanann Banc 
Ceannais na hÉireann rialáil ar Vhi Healthcare DAC, ag trádáil dó mar Vhi 
Healthcare, agus ar Vhi Insurance DAC, ag trádáil dó mar Vhi Insurance. Tá Vhi 
Healthcare ceangailte le Vhi Insurance DAC le haghaidh árachas sláinte in 
Éirinn, rud atá frithgheallta ag Vhi Insurance DAC. Tá Vhi Healthcare 
ceangailte le Zurich Life Assurance plc le haghaidh árachais saoil in Éirinn, 
rud atá frithgheallta ag Zurich Life Assurance plc. Tá Vhi Healthcare 
ceangailte le Collinson Insurance Services Limited le haghaidh Árachas Taistil 
Ilturais agus Turasóirí Mála Droma agus Árachas Fiaclóireachta de chuid Vhi atá 
frithgheallta ag Great Lakes Reinsurance (UK) SE agus le haghaidh Clúdach 
Cheanada de chuid Vhi agus Árachas Sláinte Idirnáisiúnta de chuid Vhi atá 
frithgheallta ag Astrenska Insurance Limited. Chun tuilleadh faisnéise a fháil 
faoi Ghrúpa Vhi, tabhair cuairt ar: https://www.vhi.ie/about-vhi.

This e-mail and any files transmitted with it contain information which may be 
confidential and which may also be privileged and is intended solely for the 
use of the individual or entity to whom it is addressed. Unless you are the 
intended recipient you may not copy or use it, or disclose it to anyone else. 
Any opinions expressed are that of the individual and not necessarily that of 
the Vhi Group. If you have received this e-mail in error please notify the 
sender by return.


___
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] RE. Wiki page/area for 'Building QGIS from scratch'

[Yves Jacolin]

Sorry for the noise, reading again the thread, my previous email is not 
relevant for such issue. I don't think we will add a chapter how to build QGIS 
from scratch.

Y.
On samedi 18 mars 2017 15:55:34 CET Richard Duivenvoorde wrote:
> And can I add the constant hard fight against fake user accounts adding
> wiki spam? (see osgeo wiki).
> 
> The workflow we have now is translatable, can be build to pdf's, is
> versioned and is continuously tested/rebuild.
> 
> Regards,
> 
> Richard
> 
> On 18-03-17 13:40, Nathan Woodrow wrote:
> > The wiki information got outdated very fast, and was also not
> > translatable easily.
> > A decision was made a while ago for official documentation should be
> > done int the same workflow
> > as the website in order to streamline that process and make sure
> > everyone is using the same tools.
> > 
> > - Nathan
> > 
> > 
> > On Sat, Mar 18, 2017 at 10:18 PM, John Hawkinson  > 
> > > wrote:
> > I'm new here, so I'll ask the obvious question:
> > 
> > Wikis are great because they lower the bar to collaboration. It's
> > really
> > easy to make edits and you don't have to worry about them getting
> > approved
> > and that's awesome. Really easy workflow, more so than github pull
> > requests.
> > New and potential contributors don't get discouraged.
> > 
> > What's the reason for putting up barriers to documentation like this?
> > 
> > Problems with spam or low quality edits? Can I find a robust
> > discussion
> > of the tradeoffs in the list archives?
> > 
> > --jh...@mit.edu 
> > 
> >   John Hawkinson
> > 
> > ___
> > 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



signature.asc
Description: This is a digitally signed message part.
___
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] RE. Wiki page/area for 'Building QGIS from scratch'

[Yves Jacolin]

Hello,

Could you work like we do for QEP? i.e Write the text in a ticket, ask for 
comment and label it as finished (or to be integrated in the documentation).

I will be happy to do it (assign the ticket to me) if everybody agree with 
this process!

Pros:
* lower the barrier
* easy to comment for a (small) chapter even if this is better and easier in a 
PR for bigger chapter though
* easy also to improve some part of an existing chapter (typos, missing 
informations)

Cons:
* make sure to finalized it :)

Y.
On samedi 18 mars 2017 15:55:34 CET Richard Duivenvoorde wrote:
> And can I add the constant hard fight against fake user accounts adding
> wiki spam? (see osgeo wiki).
> 
> The workflow we have now is translatable, can be build to pdf's, is
> versioned and is continuously tested/rebuild.
> 
> Regards,
> 
> Richard
> 
> On 18-03-17 13:40, Nathan Woodrow wrote:
> > The wiki information got outdated very fast, and was also not
> > translatable easily.
> > A decision was made a while ago for official documentation should be
> > done int the same workflow
> > as the website in order to streamline that process and make sure
> > everyone is using the same tools.
> > 
> > - Nathan
> > 
> > 
> > On Sat, Mar 18, 2017 at 10:18 PM, John Hawkinson  > 
> > > wrote:
> > I'm new here, so I'll ask the obvious question:
> > 
> > Wikis are great because they lower the bar to collaboration. It's
> > really
> > easy to make edits and you don't have to worry about them getting
> > approved
> > and that's awesome. Really easy workflow, more so than github pull
> > requests.
> > New and potential contributors don't get discouraged.
> > 
> > What's the reason for putting up barriers to documentation like this?
> > 
> > Problems with spam or low quality edits? Can I find a robust
> > discussion
> > of the tradeoffs in the list archives?
> > 
> > --jh...@mit.edu 
> > 
> >   John Hawkinson
> > 
> > ___
> > 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



signature.asc
Description: This is a digitally signed message part.
___
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] Corrections of QgsOgrProvider implementaion of GDAL 2.0

[Even Rouault]

On mardi 21 mars 2017 01:04:44 CET Mark Johnson wrote:
> > So if we want to address both we need the layer_id and layer_name. I'd say
> > when you build a OGR URI (mostly in QgisApp::askUserForOGRSublayers()),
> > then look at the uniqueness of the layer names. If there's layer name
> > unicity, then use only the layer name. Otherwise fallback to uniquely the
> > layer_id (and well in that case if the datasource changes at some point,
> > we
> > might have an issue indeed)
> 
> This is already being done in my version.
> 
> Setting the id to -1 could tell the QgsOgrProvider that the layername is
> unique
> - and remove the need of the extra parameter

>From a robustness point of view, I think we should be robust to layerid being 
>absent from the 
URI (and I'd prefer that when we generate URI, we don't set layerId = -1 but 
just remove it) 
since URIs can also been built by users and not only through the UI. We shoud 
also be robust 
to layername from being absent as well, as done currently.

> 
> id >= 0 would tell QgsOgrProvider that the id MUST be used, because there
> are duplicate layernames.
> 

So if both a layerid and layername, you would prever layerid over layername ? 
So the reverse 
of
https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L3494
 ?

Deciding which one is prioritary will always been a matter of arbitrary taste, 
but as there's 
currently a logic, I'd prefer we keep it as much as possible.

> The id and layername will be stored (as it was before) in the URI/Project.

subLayers() should return both layerid (potentially set to -1 if there's no 
issue of unicity) and 
layername as it does currently, but when generating a URI, it should only set 
one of them :
* if subLayers() returned layerId >=0 , use it in the URI
* otherwise use layerName.

> 
> Since at this point it is known that the values are valid
> - no further checks are needed and can be opened directly
> 
> Can we agree on this?
> Anything else still open?

To solve the issue of several geometry fields we also need a (optional) 
parameter with the 
geometry column name.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
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 [1197] Geometry Wrapper approval notification.

[noreply]

Plugin Geometry Wrapper approval by pcav.
The plugin version "[1197] Geometry Wrapper 0.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/GeoWrap/
___
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