Re: [QGIS-Developer] 来自Kurt Stine的邮件

[Paolo Cavallini]

Hi Kurt,

Il 10/03/2018 03:08, Kurt Stine ha scritto:
> I am trying to port QGIS to Windows RT Desktop (Windows on ARM). I have
> everything set up and running, until I get to cmake. Cmake fails to
> build when it reaches spatialite. 
> 
> This is what the cmake error file
> shows: https://hastebin.com/woherijadi.tex
> 
> I have tried manually replacing the spatialite lib with the 4.3 version,
> but the same issue occurs. Any help is welcome and appreciated!

interesting news - would you mind sharing your work? Probably others
would be inerested in installing QGIS in the same environment.
Thanks.

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

[QGIS-Developer] 来自Kurt Stine的邮件

[Kurt Stine]

Hello,


I am trying to port QGIS to Windows RT Desktop (Windows on ARM). I have 
everything set up and running, until I get to cmake. Cmake fails to build when 
it reaches spatialite. 


This is what the cmake error file shows: https://hastebin.com/woherijadi.tex


I have tried manually replacing the spatialite lib with the 4.3 version, but 
the same issue occurs. Any help is welcome and appreciated!


Thanks,
Qiangong2___
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] Compiling Qwt for qgis3/qt5

[Nyall Dawson]

On 9 March 2018 at 22:24, Richard Duivenvoorde  wrote:
> On 09-03-18 12:38, Andrew Brooks wrote:
>> Hi
>>
>> The docs state
>>Qwt >= 5.0 & (< 6.1 with internal QwtPolar)
>> Can you be more explicit about exactly which version of Qwt (and
>> QwtPolar) to use?
>>
>> Most versions of Qwt don't build with Qt-5.
>> QwtPolar doesn't seem to build at all.
>>
>> Any advice regarding building Qwt?  Thanks!
>
> Unless you really need it, you can build without QwtPolar:
> -DWITH_QWTPOLAR=OFF
>
> I'm on Debian sid, then there is
> QWT Version 6.1.3
> and I do build without QWT
>

As far as I'm aware, all the release builds are made without QwtPolar
now. We wanted to strip out this dependency completely, but no-one was
interested in maintaining the part of code where it's used (the GPS
display widget) and doing this work. I don't think anyone's even
noticed yet that this widget isn't present in QGIS 3.0 ;)

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] proj5 and epsg:3857 ?

[Nyall Dawson]

On 9 March 2018 at 19:39, Kristian Evers  wrote:
> All,
>
> Just to follow up on this, since I am the one to blame for this error to show 
> up.

Kristian -- just to add my 2c here, there's absolutely NO-ONE who can
blame you for this mistake, please do not beat yourself up over this!
I'm sure there's not a single developer who hasn't been responsible
for at least one serious bug in release software. It's just the nature
of the job, and even more so when the software involved is such a
complex and esoteric area as that handled by proj.

(Heck... you could easily have bluffed your way around this with some
explanation about temporal datum shifts and the like and claimed that
the proj5 results are "real world accurate" or something, and no-one
would have been able to call you out ;)

Keep up the great work in this critical, yet underappreciated and
under-funded part of our ecosystem. It's very much appreciated and
valued by everyone who knows the work you 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] Simple QGIS KML/KMZ Import

[Carlo A. Bertelli (Charta s.r.l.)]

XML and JSON formats do not adhere to the simple feature model of GDAL/OGR
that is reminiscent of a flat file or a relational table. And GDAL is one
of the base pillars for QGIS.
These are more similar to other storage models, say hierarchical or graphs,
so they enable a complex data structure that requires a pre-flight and asks
for some decisions to correctly represent their structure as a simple
feature or exceed it, delivering a complex relational system (if you can
guess some) or something other.
Maybe that's the new frontier for GDAL more than an opportunity for a
plugin. The same challenge is available for other formats like GPX,
geo/topoJSON, etc.
QGIS may implement much thoroughly the relevant options, but I think this
is work for GDAL.
c

On Fri, Mar 9, 2018 at 6:01 PM, C Hamilton  wrote:

> The challenge with KML imports is that its free form nature makes it
> difficult to conform to a table. I have large KMLs with nested folder
> structures. I find that these large KMLs crash QGIS if I try to import the
> entire thing and then each point gets rendered as a separate layer.
>
> It wouldn't be hard to write a script that just pulls out all the
> placemarks and writes them to a point layer, lines to a line layer, and
> polygons to a polygon layer. What I would loose is the folder structure and
> styling, but I could easily process large KMLs. I could consider a field in
> the layers that would be a string of the nested folders that each point,
> line, polygon were in.
>
> Would this be of interest as a plugin? Is anyone doing this already? There
> doesn't appear to be anything in the plugin repository.
>
> 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
>



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Problems compiling QGIS 3.0: no matching function for call to QgsLayerTreeLayer::connect

[ceholden]

Hi

I encountered this same error trying to compile and package QGIS 3.0 within
the "conda-forge" community channel of the Anaconda Python distribution, but
only when using GCC 4.8 (4.8.5, specifically). Pretty sure I have to stick
with GCC 4.8 for now within this build environment, but I did not encounter
this issue when using GCC 7.2 or 7.3. I switched out to gcc 7.2, keeping all
the other dependencies/etc the same, and can compile and run QGIS without
issue.

I don't know my way around SUSE, but it looks like the "gcc" package for
openSUSE Leap 42.3 is version 4.8
(https://software.opensuse.org/package/gcc). Assuming Hernán is using the
"gcc" package (and not "gcc6" or "gcc7", and thus would be using gcc 4.8.x),
then this could narrow down the issue and help explain why it hasn't come up
elsewhere. I'm unfortunately clueless about the GCC history and not much of
a C++ person, so I'm not sure where to go from here, beyond eventually
upgrading gcc, but would be happy to test patches/compilation options/etc.

Here's a link to a Gist with the output from cmake and the failed make step,
either using Make and Ninja (Ninja shows

Make:
https://gist.github.com/ceholden/b6179d58e17f983ce6f29b32531bb4fa#file-qgis3-0_gcc4-8_make_fail
Ninja:
https://gist.github.com/ceholden/b6179d58e17f983ce6f29b32531bb4fa#file-qgis3-0_gcc4-8_ninja_fail

Best,
Chris



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] proj5 and epsg:3857 ?

[Sebastiaan Couwenberg]

On 03/09/2018 07:04 PM, Richard Duivenvoorde wrote:
> ps README.md still talking about ./configure in "Building on Unix/Linux"
> while apparently it is not there anymore?

It's there after you run autogen.sh.
___
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] proj5 and epsg:3857 ?

[Richard Duivenvoorde]

On 09-03-18 16:30, Even Rouault wrote:
>  
> I don't think the removal of "+nadgrids=@null" is a "universal"
> workaround. It only works when the other SRS has no +towgs84 or
> +nadgrids clause itself, which isn't the case of EPSG:28992. Basically
> if you transform between EPSG:28992 and WebMercator without
> +nadgrids=@null, then no datum shift at all is done, so you have just
> the tranform between the Bessel ellipsoid and the sphere of radius
> 6378137. The proper fix is to get the patched version of proj

Ok, ok :-)

Cloned proj.4, compiled master and working \o/

Thanks,

Richard

ps README.md still talking about ./configure in "Building on Unix/Linux"
while apparently it is not there anymore?

___
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 [1424] Beeline approval notification.

[noreply]

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

[noreply]

Plugin Beeline approval by pcav.
The plugin version "[1424] Beeline 0.2.0" is now approved
Link: http://plugins.qgis.org/plugins/Beeline/
___
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] Issues building from source on Mac - No module named PyQt5

[Timur Girgin]

Well, you might just be right since I could not get some of the packages
working off of brew (due to installation issues, or unavailability). Some
of them were build from source (e.g., SIP), which might be causing the
issue that you are talking about.

And no, I have not been using Remi's formula.

What I am trying to accomplish is to create a QGIS installer for Mac since
there seems to be demand for one, though I have little experience in doing
so.

Thank you for your help

On Fri, Mar 9, 2018 at 11:40 AM, Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> wrote:

> This discussion is going a bit off-topic, but I think the problem could be
> in your Homebrew installation. If someone changes the reference to qt from
> qt4 to qt5 may cause some issue (I call it a mess, but I am biased, I had a
> very bad time with these issue – thanks to Larry did fix them). Maybe you
> will have to uninstall all qt related formulas and reinstall qt 4 and 5.
> I see Remi Desgrange made a formula for the released QGIS 3 here:
> https://github.com/RemiDesgrange/homebrew-qgisrelease
> Are you using it?
> c
>
>
> On Fri, Mar 9, 2018 at 5:22 PM, Timur Girgin 
> wrote:
>
>> Hello Carlo,
>>
>> Would you advice building Qt5 from source then, rather than using brew?
>>
>> Thanks
>>
>> On Fri, Mar 9, 2018 at 11:13 AM, Carlo A. Bertelli (Charta s.r.l.) <
>> carlo.berte...@gmail.com> wrote:
>>
>>> Hello,
>>> I suggest to remind that using Homebrew carries in another issue. The
>>> maintainers decided to force everyone to use Qt5 as Qt4 is deprecated by Qt
>>> developers. Everything that was called qt5-something should become
>>> qt-something, so everyone who uses Qt4 had to make formulas called
>>> qt4-something for every Qt4 dependency.
>>> This was the case even for OsGeo4Mac (https://github.com/OsGeo/home
>>> brew-osgeo4mac/) and Larry Shaffer had to recreate all the needed
>>> dependencies inside this tap. If you have old Qt dependencies inside your
>>> Homebrew, it may happen that qt-something is still qt4-something even if
>>> brew thinks it's qt5... Feeling bewildered? So am I.
>>> c
>>>
>>> On Thu, Mar 8, 2018 at 4:10 PM, Timur Girgin 
>>> wrote:
>>>
 Hello everyone,

 I am having trouble building the QGIS release-3_0 branch on my Mac. I
 finally got it to cmake, however I am getting an error during the make
 process in which it seems that spatialite is using the system's Python(@2)
 executable to find PyQT5 when in reality it should be looking for it in the
 Python@3 executable that has been given during CMAKE. I am guessing
 this is what is causing the issue.

 Please find the error at the bottom of this email. If anyone knows what
 I am doing wrong, would you please let me know?

 Thank you very much!
 Tim

 Here is my CMAKE:

 cmake -D CMAKE_INSTALL_PREFIX=~/Downloads/QGIS-build \
   -D CMAKE_BUILD_TYPE=MINSIZEREL -D ENABLE_TESTS=FALSE \
   -D 
 SPATIALINDEX_LIBRARY=/usr/local/Cellar/spatialindex/1.8.5/lib/libspatialindex.4.dylib
 \
   -D SPATIALINDEX_INCLUDE_DIR=/usr/local/Cellar/spatialindex/1.8.
 5/include/spatialindex/\
   -D QWT_LIBRARY=/usr/local/qwt-6.1.3/lib/libqwt.dylib \
   -D QWT_INCLUDE_DIR=/usr/local/qwt-6.1.3/include \
   -D BISON_EXECUTABLE=/usr/local/Cellar/bison/3.0.4_1/bin/bison \
   -D GEOS_LIBRARY=/usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib \
   -D GEOS_INCLUDE_DIR=/usr/local/Cellar/geos/3.6.2/include \
   -D LIBZIP_LIBRARY=/usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib
 \
   -D LIBZIP_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
   -D LIBZIP_CONF_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
   -D EXPAT_LIBRARY=/usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
 \
   -D EXPAT_INCLUDE_DIR=/usr/local/Cellar/expat/2.2.5/include \
   -D Qt5Core_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Core \
   -D Qt5Gui_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Gui \
   -D Qt5Test_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Test \
   -D Qt5Widgets_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Widgets \
   -D Qt5Concurrent_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Concurrent
 \
   -D Qt5OpenGL_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5OpenGL \
   -D Qt5Xml_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Xml \
   -D Qt5Svg_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Svg \
   -D Qt5Network_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Network \
   -D 
 Qt5PrintSupport_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5PrintSupport
 \
   -D 
 Qt5Positioning_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Positioning
 \
   -D 
 Qt5XmlPatterns_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5XmlPatterns
 \
   -D Qt5WebKit_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5WebView \
   -D 

[QGIS-Developer] Simple QGIS KML/KMZ Import

[C Hamilton]

The challenge with KML imports is that its free form nature makes it
difficult to conform to a table. I have large KMLs with nested folder
structures. I find that these large KMLs crash QGIS if I try to import the
entire thing and then each point gets rendered as a separate layer.

It wouldn't be hard to write a script that just pulls out all the
placemarks and writes them to a point layer, lines to a line layer, and
polygons to a polygon layer. What I would loose is the folder structure and
styling, but I could easily process large KMLs. I could consider a field in
the layers that would be a string of the nested folders that each point,
line, polygon were in.

Would this be of interest as a plugin? Is anyone doing this already? There
doesn't appear to be anything in the plugin repository.

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] issues in QGIS Server 2,18

[Régis Haubourg]

Hi Giovanni,
 GetFeatures  can output GML with a different format.
What is sure is that GeoJSON spec doesn't leave any choice, unless we go
for a proprietary output format allowing another SRS.
I'll keep that in mind when testing OGC compliancy for WFS. We are working
on that currently to evaluate how much work is needed to reach a
certification for WFS.
Regards
Régis

2018-03-09 14:34 GMT+01:00 Giovanni Manghi :

> Hi René-Luc,
>
>
>
> > Le 01/03/2018 à 12:52, Giovanni Manghi a écrit :
> >> Hi all,
> >> now that 2.18 is LTR I guess that many have also updated their QGIS
> >> Server installation to this release. Problem is that I see a few
> >> issues in 2.18 and would like to have gsome feedback from others.
> >>
> >> *) slower: it seems this version is slower compared to 2.14, at least
> >> for some specific request like WFS GetFeatures. See for example:
> >>
> >> https://issues.qgis.org/issues/18249#note-1
> >>
> >> where in the same condition (same server, same postgis datasource of
> >> around ~25000 polygons) 2.18 is about 30 seconds slower than 2.14.
> >
> > This issue is simply due to the transformation of the geometry from the
> > layer CRS to the GeoJSON CRS standard: EPSG:4326
>
> ok thanks, but one doubt: I guess that this change (compared to 2.14)
> was to make qgis server more compliant and this also means that we
> need to accept that for such requests will be always slower than it
> was before? sorry for the dumb question as I'm not much into the ogc
> internals.
>
>
> 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
>
___
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] Issues building from source on Mac - No module named PyQt5

[Carlo A. Bertelli (Charta s.r.l.)]

This discussion is going a bit off-topic, but I think the problem could be
in your Homebrew installation. If someone changes the reference to qt from
qt4 to qt5 may cause some issue (I call it a mess, but I am biased, I had a
very bad time with these issue – thanks to Larry did fix them). Maybe you
will have to uninstall all qt related formulas and reinstall qt 4 and 5.
I see Remi Desgrange made a formula for the released QGIS 3 here:
https://github.com/RemiDesgrange/homebrew-qgisrelease
Are you using it?
c


On Fri, Mar 9, 2018 at 5:22 PM, Timur Girgin  wrote:

> Hello Carlo,
>
> Would you advice building Qt5 from source then, rather than using brew?
>
> Thanks
>
> On Fri, Mar 9, 2018 at 11:13 AM, Carlo A. Bertelli (Charta s.r.l.) <
> carlo.berte...@gmail.com> wrote:
>
>> Hello,
>> I suggest to remind that using Homebrew carries in another issue. The
>> maintainers decided to force everyone to use Qt5 as Qt4 is deprecated by Qt
>> developers. Everything that was called qt5-something should become
>> qt-something, so everyone who uses Qt4 had to make formulas called
>> qt4-something for every Qt4 dependency.
>> This was the case even for OsGeo4Mac (https://github.com/OsGeo/home
>> brew-osgeo4mac/) and Larry Shaffer had to recreate all the needed
>> dependencies inside this tap. If you have old Qt dependencies inside your
>> Homebrew, it may happen that qt-something is still qt4-something even if
>> brew thinks it's qt5... Feeling bewildered? So am I.
>> c
>>
>> On Thu, Mar 8, 2018 at 4:10 PM, Timur Girgin 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I am having trouble building the QGIS release-3_0 branch on my Mac. I
>>> finally got it to cmake, however I am getting an error during the make
>>> process in which it seems that spatialite is using the system's Python(@2)
>>> executable to find PyQT5 when in reality it should be looking for it in the
>>> Python@3 executable that has been given during CMAKE. I am guessing
>>> this is what is causing the issue.
>>>
>>> Please find the error at the bottom of this email. If anyone knows what
>>> I am doing wrong, would you please let me know?
>>>
>>> Thank you very much!
>>> Tim
>>>
>>> Here is my CMAKE:
>>>
>>> cmake -D CMAKE_INSTALL_PREFIX=~/Downloads/QGIS-build \
>>>   -D CMAKE_BUILD_TYPE=MINSIZEREL -D ENABLE_TESTS=FALSE \
>>>   -D 
>>> SPATIALINDEX_LIBRARY=/usr/local/Cellar/spatialindex/1.8.5/lib/libspatialindex.4.dylib
>>> \
>>>   -D SPATIALINDEX_INCLUDE_DIR=/usr/local/Cellar/spatialindex/1.8.
>>> 5/include/spatialindex/\
>>>   -D QWT_LIBRARY=/usr/local/qwt-6.1.3/lib/libqwt.dylib \
>>>   -D QWT_INCLUDE_DIR=/usr/local/qwt-6.1.3/include \
>>>   -D BISON_EXECUTABLE=/usr/local/Cellar/bison/3.0.4_1/bin/bison \
>>>   -D GEOS_LIBRARY=/usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib \
>>>   -D GEOS_INCLUDE_DIR=/usr/local/Cellar/geos/3.6.2/include \
>>>   -D LIBZIP_LIBRARY=/usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib
>>> \
>>>   -D LIBZIP_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>>>   -D LIBZIP_CONF_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>>>   -D EXPAT_LIBRARY=/usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
>>> \
>>>   -D EXPAT_INCLUDE_DIR=/usr/local/Cellar/expat/2.2.5/include \
>>>   -D Qt5Core_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Core \
>>>   -D Qt5Gui_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Gui \
>>>   -D Qt5Test_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Test \
>>>   -D Qt5Widgets_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Widgets \
>>>   -D Qt5Concurrent_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Concurrent
>>> \
>>>   -D Qt5OpenGL_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5OpenGL \
>>>   -D Qt5Xml_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Xml \
>>>   -D Qt5Svg_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Svg \
>>>   -D Qt5Network_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Network \
>>>   -D 
>>> Qt5PrintSupport_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5PrintSupport
>>> \
>>>   -D Qt5Positioning_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Positioning
>>> \
>>>   -D Qt5XmlPatterns_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5XmlPatterns
>>> \
>>>   -D Qt5WebKit_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5WebView \
>>>   -D Qt5UiTools_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5UiTools \
>>>   -D Qt5Sql_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Sql \
>>>   -D 
>>> QCA_INCLUDE_DIR=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.framework/Versions/2.1.3/Headers
>>> \
>>>   -D 
>>> QCA_LIBRARY=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.framework/Versions/2.1.3/qca-qt5
>>> \
>>>   -D LIBTASN1_LIBRARY=/usr/local/Cellar/libtasn1/4.13/lib/libtasn1.6.dylib
>>> \
>>>   -D LIBTASN1_INCLUDE_DIR=/usr/local/Cellar/libtasn1/4.13/include \
>>>   -D QSCINTILLA_INCLUDE_DIR=/usr/local/Cellar/qscintilla2/2.10.2_1/include
>>> \
>>>   -D QSCINTILLA_LIBRARY=/usr/local/Cellar/qscintilla2/2.10.2_1/li
>>> b/libqscintilla2_qt5.13.1.0.dylib \
>>>   -D 

Re: [QGIS-Developer] Issues building from source on Mac - No module named PyQt5

[Timur Girgin]

Hello Carlo,

Would you advice building Qt5 from source then, rather than using brew?

Thanks

On Fri, Mar 9, 2018 at 11:13 AM, Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> wrote:

> Hello,
> I suggest to remind that using Homebrew carries in another issue. The
> maintainers decided to force everyone to use Qt5 as Qt4 is deprecated by Qt
> developers. Everything that was called qt5-something should become
> qt-something, so everyone who uses Qt4 had to make formulas called
> qt4-something for every Qt4 dependency.
> This was the case even for OsGeo4Mac (https://github.com/OsGeo/
> homebrew-osgeo4mac/) and Larry Shaffer had to recreate all the needed
> dependencies inside this tap. If you have old Qt dependencies inside your
> Homebrew, it may happen that qt-something is still qt4-something even if
> brew thinks it's qt5... Feeling bewildered? So am I.
> c
>
> On Thu, Mar 8, 2018 at 4:10 PM, Timur Girgin 
> wrote:
>
>> Hello everyone,
>>
>> I am having trouble building the QGIS release-3_0 branch on my Mac. I
>> finally got it to cmake, however I am getting an error during the make
>> process in which it seems that spatialite is using the system's Python(@2)
>> executable to find PyQT5 when in reality it should be looking for it in the
>> Python@3 executable that has been given during CMAKE. I am guessing this
>> is what is causing the issue.
>>
>> Please find the error at the bottom of this email. If anyone knows what I
>> am doing wrong, would you please let me know?
>>
>> Thank you very much!
>> Tim
>>
>> Here is my CMAKE:
>>
>> cmake -D CMAKE_INSTALL_PREFIX=~/Downloads/QGIS-build \
>>   -D CMAKE_BUILD_TYPE=MINSIZEREL -D ENABLE_TESTS=FALSE \
>>   -D 
>> SPATIALINDEX_LIBRARY=/usr/local/Cellar/spatialindex/1.8.5/lib/libspatialindex.4.dylib
>> \
>>   -D SPATIALINDEX_INCLUDE_DIR=/usr/local/Cellar/spatialindex/1.8.
>> 5/include/spatialindex/\
>>   -D QWT_LIBRARY=/usr/local/qwt-6.1.3/lib/libqwt.dylib \
>>   -D QWT_INCLUDE_DIR=/usr/local/qwt-6.1.3/include \
>>   -D BISON_EXECUTABLE=/usr/local/Cellar/bison/3.0.4_1/bin/bison \
>>   -D GEOS_LIBRARY=/usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib \
>>   -D GEOS_INCLUDE_DIR=/usr/local/Cellar/geos/3.6.2/include \
>>   -D LIBZIP_LIBRARY=/usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib \
>>   -D LIBZIP_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>>   -D LIBZIP_CONF_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>>   -D EXPAT_LIBRARY=/usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
>> \
>>   -D EXPAT_INCLUDE_DIR=/usr/local/Cellar/expat/2.2.5/include \
>>   -D Qt5Core_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Core \
>>   -D Qt5Gui_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Gui \
>>   -D Qt5Test_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Test \
>>   -D Qt5Widgets_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Widgets \
>>   -D Qt5Concurrent_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Concurrent
>> \
>>   -D Qt5OpenGL_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5OpenGL \
>>   -D Qt5Xml_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Xml \
>>   -D Qt5Svg_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Svg \
>>   -D Qt5Network_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Network \
>>   -D 
>> Qt5PrintSupport_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5PrintSupport
>> \
>>   -D Qt5Positioning_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Positioning
>> \
>>   -D Qt5XmlPatterns_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5XmlPatterns
>> \
>>   -D Qt5WebKit_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5WebView \
>>   -D Qt5UiTools_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5UiTools \
>>   -D Qt5Sql_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Sql \
>>   -D 
>> QCA_INCLUDE_DIR=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.framework/Versions/2.1.3/Headers
>> \
>>   -D 
>> QCA_LIBRARY=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.framework/Versions/2.1.3/qca-qt5
>> \
>>   -D LIBTASN1_LIBRARY=/usr/local/Cellar/libtasn1/4.13/lib/libtasn1.6.dylib
>> \
>>   -D LIBTASN1_INCLUDE_DIR=/usr/local/Cellar/libtasn1/4.13/include \
>>   -D QSCINTILLA_INCLUDE_DIR=/usr/local/Cellar/qscintilla2/2.10.2_1/include
>> \
>>   -D QSCINTILLA_LIBRARY=/usr/local/Cellar/qscintilla2/2.10.2_1/li
>> b/libqscintilla2_qt5.13.1.0.dylib \
>>   -D QTKEYCHAIN_INCLUDE_DIR=/usr/local/Cellar/qtkeychain/0.8.0/include \
>>   -D 
>> QTKEYCHAIN_LIBRARY=/usr/local/Cellar/qtkeychain/0.8.0/lib/libqt5keychain.0.8.0.dylib
>> \
>>   -D 
>> SPATIALITE_LIBRARY=/usr/local/Cellar/libspatialite/4.3.0a_6/lib/mod_spatialite.7.dylib
>> \
>>   -D SPATIALITE_INCLUDE_DIR=/usr/local/Cellar/libspatialite/4.3.0a_6/include
>> \
>>   -D SQLITE3_LIBRARY=/usr/local/Cellar/sqlite/3.22.0/lib/libsqlite3.0.dylib
>> \
>>   -D PYTHON_EXECUTABLE=/usr/local/bin/python3 \
>>   -D 
>> PYTHON_INCLUDE_PATH=/usr/local/Frameworks/Python.framework/Versions/3.6/Headers
>> \
>>   -D 
>> PYTHON_LIBRARY=/usr/local/Frameworks/Python.framework/Versions/3.6/Python
>> \
>>   -D WITH_QTWEBKIT=FALSE \
>>   ..
>>
>> 

Re: [QGIS-Developer] Issues building from source on Mac - No module named PyQt5

[Carlo A. Bertelli (Charta s.r.l.)]

Hello,
I suggest to remind that using Homebrew carries in another issue. The
maintainers decided to force everyone to use Qt5 as Qt4 is deprecated by Qt
developers. Everything that was called qt5-something should become
qt-something, so everyone who uses Qt4 had to make formulas called
qt4-something for every Qt4 dependency.
This was the case even for OsGeo4Mac (
https://github.com/OsGeo/homebrew-osgeo4mac/) and Larry Shaffer had to
recreate all the needed dependencies inside this tap. If you have old Qt
dependencies inside your Homebrew, it may happen that qt-something is still
qt4-something even if brew thinks it's qt5... Feeling bewildered? So am I.
c

On Thu, Mar 8, 2018 at 4:10 PM, Timur Girgin  wrote:

> Hello everyone,
>
> I am having trouble building the QGIS release-3_0 branch on my Mac. I
> finally got it to cmake, however I am getting an error during the make
> process in which it seems that spatialite is using the system's Python(@2)
> executable to find PyQT5 when in reality it should be looking for it in the
> Python@3 executable that has been given during CMAKE. I am guessing this
> is what is causing the issue.
>
> Please find the error at the bottom of this email. If anyone knows what I
> am doing wrong, would you please let me know?
>
> Thank you very much!
> Tim
>
> Here is my CMAKE:
>
> cmake -D CMAKE_INSTALL_PREFIX=~/Downloads/QGIS-build \
>   -D CMAKE_BUILD_TYPE=MINSIZEREL -D ENABLE_TESTS=FALSE \
>   -D 
> SPATIALINDEX_LIBRARY=/usr/local/Cellar/spatialindex/1.8.5/lib/libspatialindex.4.dylib
> \
>   -D SPATIALINDEX_INCLUDE_DIR=/usr/local/Cellar/spatialindex/1.8.
> 5/include/spatialindex/\
>   -D QWT_LIBRARY=/usr/local/qwt-6.1.3/lib/libqwt.dylib \
>   -D QWT_INCLUDE_DIR=/usr/local/qwt-6.1.3/include \
>   -D BISON_EXECUTABLE=/usr/local/Cellar/bison/3.0.4_1/bin/bison \
>   -D GEOS_LIBRARY=/usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib \
>   -D GEOS_INCLUDE_DIR=/usr/local/Cellar/geos/3.6.2/include \
>   -D LIBZIP_LIBRARY=/usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib \
>   -D LIBZIP_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>   -D LIBZIP_CONF_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>   -D EXPAT_LIBRARY=/usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
> \
>   -D EXPAT_INCLUDE_DIR=/usr/local/Cellar/expat/2.2.5/include \
>   -D Qt5Core_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Core \
>   -D Qt5Gui_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Gui \
>   -D Qt5Test_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Test \
>   -D Qt5Widgets_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Widgets \
>   -D Qt5Concurrent_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Concurrent
> \
>   -D Qt5OpenGL_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5OpenGL \
>   -D Qt5Xml_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Xml \
>   -D Qt5Svg_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Svg \
>   -D Qt5Network_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Network \
>   -D Qt5PrintSupport_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5PrintSupport
> \
>   -D Qt5Positioning_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Positioning
> \
>   -D Qt5XmlPatterns_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5XmlPatterns
> \
>   -D Qt5WebKit_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5WebView \
>   -D Qt5UiTools_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5UiTools \
>   -D Qt5Sql_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Sql \
>   -D QCA_INCLUDE_DIR=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.
> framework/Versions/2.1.3/Headers \
>   -D QCA_LIBRARY=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.
> framework/Versions/2.1.3/qca-qt5 \
>   -D LIBTASN1_LIBRARY=/usr/local/Cellar/libtasn1/4.13/lib/libtasn1.6.dylib
> \
>   -D LIBTASN1_INCLUDE_DIR=/usr/local/Cellar/libtasn1/4.13/include \
>   -D QSCINTILLA_INCLUDE_DIR=/usr/local/Cellar/qscintilla2/2.10.2_1/include
> \
>   -D QSCINTILLA_LIBRARY=/usr/local/Cellar/qscintilla2/2.10.2_1/
> lib/libqscintilla2_qt5.13.1.0.dylib \
>   -D QTKEYCHAIN_INCLUDE_DIR=/usr/local/Cellar/qtkeychain/0.8.0/include \
>   -D 
> QTKEYCHAIN_LIBRARY=/usr/local/Cellar/qtkeychain/0.8.0/lib/libqt5keychain.0.8.0.dylib
> \
>   -D 
> SPATIALITE_LIBRARY=/usr/local/Cellar/libspatialite/4.3.0a_6/lib/mod_spatialite.7.dylib
> \
>   -D SPATIALITE_INCLUDE_DIR=/usr/local/Cellar/libspatialite/4.3.0a_6/include
> \
>   -D SQLITE3_LIBRARY=/usr/local/Cellar/sqlite/3.22.0/lib/libsqlite3.0.dylib
> \
>   -D PYTHON_EXECUTABLE=/usr/local/bin/python3 \
>   -D 
> PYTHON_INCLUDE_PATH=/usr/local/Frameworks/Python.framework/Versions/3.6/Headers
> \
>   -D PYTHON_LIBRARY=/usr/local/Frameworks/Python.framework/Versions/3.6/Python
> \
>   -D WITH_QTWEBKIT=FALSE \
>   ..
>
> Which outputs:
>
> -- QGIS version: 3.0.0 Girona (3)
> -- Could not find GRASS 7
> -- Found Proj: /Library/Frameworks/PROJ.framework
> -- Found GEOS: /usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib (3.6.2)
> -- Found GDAL: /usr/local/Cellar/gdal2/2.2.3/lib/libgdal.dylib (2.2.3)
> -- Found Expat: 

Re: [QGIS-Developer] proj5 and epsg:3857 ?

[Even Rouault]

On vendredi 9 mars 2018 12:19:09 CET Richard Duivenvoorde wrote:
> Hi All,
> 
> I second that: not blaming anybody here. This happens in the real world.
> 
> My point was that I think as QGIS we can 'hide' this issue by not using
> 5.0.0 'yet' in the osgeo4w package.
> 
> I will happily use/test whatever is available in Debian sid  :-)
> 
> Also tried Kristian's fix.
> 
> For QGIS users: QGIS does not use the epsg file provided by your proj
> install, but a srs.db:
>  {QGISINSTALLDIR}/share/qgis/resources/srs.db
> 
> I edited (using DB browser) and removed the "+nadgrids=@null" clause
> from the epsg:3857 line.
> Checked by looking into the srs chooser of QGIS and seeing that it was
> indeed not visible anymore.
> 
> But it does not seem a 100% hack with me. While more near the 'real'
> place, it is still 150m off?
> 

I don't think the removal of "+nadgrids=@null" is a "universal" workaround. It 
only works 
when the other SRS has no +towgs84 or +nadgrids clause itself, which isn't the 
case of EPSG:
28992. Basically if you transform between EPSG:28992 and WebMercator without 
+nadgrids=@null, then no datum shift at all is done, so you have just the 
tranform between 
the Bessel ellipsoid and the sphere of radius 6378137. The proper fix is to get 
the patched 
version of proj

-- 
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 [597] NNJoin approval notification.

[noreply]

Plugin NNJoin approval by pcav.
The plugin version "[597] NNJoin 3.0.5" is now approved
Link: http://plugins.qgis.org/plugins/NNJoin/
___
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] proj5 and epsg:3857 ?

[Even Rouault]

On vendredi 9 mars 2018 11:38:17 CET Even Rouault wrote:
> Kristian 
> 
> your are certainly not too blame at à personal level. this is the kind of
> this that happen inevitably given a certain amount of changes . i'm
> surprised that the GDAL autotest suite did not catch this but the cause is
> likely that the GDAL c++ class that wraps proj has an optimisation when
> transforming from 3857 to 4326. 

My bad: going from datum=WGS84 to WebMercator wasn't actually affected by 
the bug. Only if you go from datum != WGS84 to WebMercator. And there wasn't 
indeed a test for that later case in GDAL autotest. Now added.

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

Re: [QGIS-Developer] Issues building from source on Mac - No module named PyQt5

[Hernán De Angelis]

Timur,

I am having similar issues in Linux openSUSE Leap 42.3. As far as I
understand there are issues and conflict between versions of PyQT and SIP.
It is not a QGIS problem. It would be nice to sort it out in any case.

/H.

On Thu, Mar 8, 2018 at 4:10 PM, Timur Girgin  wrote:

> Hello everyone,
>
> I am having trouble building the QGIS release-3_0 branch on my Mac. I
> finally got it to cmake, however I am getting an error during the make
> process in which it seems that spatialite is using the system's Python(@2)
> executable to find PyQT5 when in reality it should be looking for it in the
> Python@3 executable that has been given during CMAKE. I am guessing this
> is what is causing the issue.
>
> Please find the error at the bottom of this email. If anyone knows what I
> am doing wrong, would you please let me know?
>
> Thank you very much!
> Tim
>
> Here is my CMAKE:
>
> cmake -D CMAKE_INSTALL_PREFIX=~/Downloads/QGIS-build \
>   -D CMAKE_BUILD_TYPE=MINSIZEREL -D ENABLE_TESTS=FALSE \
>   -D 
> SPATIALINDEX_LIBRARY=/usr/local/Cellar/spatialindex/1.8.5/lib/libspatialindex.4.dylib
> \
>   -D SPATIALINDEX_INCLUDE_DIR=/usr/local/Cellar/spatialindex/1.8.
> 5/include/spatialindex/\
>   -D QWT_LIBRARY=/usr/local/qwt-6.1.3/lib/libqwt.dylib \
>   -D QWT_INCLUDE_DIR=/usr/local/qwt-6.1.3/include \
>   -D BISON_EXECUTABLE=/usr/local/Cellar/bison/3.0.4_1/bin/bison \
>   -D GEOS_LIBRARY=/usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib \
>   -D GEOS_INCLUDE_DIR=/usr/local/Cellar/geos/3.6.2/include \
>   -D LIBZIP_LIBRARY=/usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib \
>   -D LIBZIP_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>   -D LIBZIP_CONF_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>   -D EXPAT_LIBRARY=/usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
> \
>   -D EXPAT_INCLUDE_DIR=/usr/local/Cellar/expat/2.2.5/include \
>   -D Qt5Core_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Core \
>   -D Qt5Gui_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Gui \
>   -D Qt5Test_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Test \
>   -D Qt5Widgets_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Widgets \
>   -D Qt5Concurrent_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Concurrent
> \
>   -D Qt5OpenGL_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5OpenGL \
>   -D Qt5Xml_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Xml \
>   -D Qt5Svg_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Svg \
>   -D Qt5Network_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Network \
>   -D Qt5PrintSupport_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5PrintSupport
> \
>   -D Qt5Positioning_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Positioning
> \
>   -D Qt5XmlPatterns_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5XmlPatterns
> \
>   -D Qt5WebKit_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5WebView \
>   -D Qt5UiTools_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5UiTools \
>   -D Qt5Sql_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Sql \
>   -D QCA_INCLUDE_DIR=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.
> framework/Versions/2.1.3/Headers \
>   -D QCA_LIBRARY=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.
> framework/Versions/2.1.3/qca-qt5 \
>   -D LIBTASN1_LIBRARY=/usr/local/Cellar/libtasn1/4.13/lib/libtasn1.6.dylib
> \
>   -D LIBTASN1_INCLUDE_DIR=/usr/local/Cellar/libtasn1/4.13/include \
>   -D QSCINTILLA_INCLUDE_DIR=/usr/local/Cellar/qscintilla2/2.10.2_1/include
> \
>   -D QSCINTILLA_LIBRARY=/usr/local/Cellar/qscintilla2/2.10.2_1/
> lib/libqscintilla2_qt5.13.1.0.dylib \
>   -D QTKEYCHAIN_INCLUDE_DIR=/usr/local/Cellar/qtkeychain/0.8.0/include \
>   -D 
> QTKEYCHAIN_LIBRARY=/usr/local/Cellar/qtkeychain/0.8.0/lib/libqt5keychain.0.8.0.dylib
> \
>   -D 
> SPATIALITE_LIBRARY=/usr/local/Cellar/libspatialite/4.3.0a_6/lib/mod_spatialite.7.dylib
> \
>   -D SPATIALITE_INCLUDE_DIR=/usr/local/Cellar/libspatialite/4.3.0a_6/include
> \
>   -D SQLITE3_LIBRARY=/usr/local/Cellar/sqlite/3.22.0/lib/libsqlite3.0.dylib
> \
>   -D PYTHON_EXECUTABLE=/usr/local/bin/python3 \
>   -D 
> PYTHON_INCLUDE_PATH=/usr/local/Frameworks/Python.framework/Versions/3.6/Headers
> \
>   -D PYTHON_LIBRARY=/usr/local/Frameworks/Python.framework/Versions/3.6/Python
> \
>   -D WITH_QTWEBKIT=FALSE \
>   ..
>
> Which outputs:
>
> -- QGIS version: 3.0.0 Girona (3)
> -- Could not find GRASS 7
> -- Found Proj: /Library/Frameworks/PROJ.framework
> -- Found GEOS: /usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib (3.6.2)
> -- Found GDAL: /usr/local/Cellar/gdal2/2.2.3/lib/libgdal.dylib (2.2.3)
> -- Found Expat: /usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
> -- Found Spatialindex: /usr/local/Cellar/spatialindex/1.8.5/lib/
> libspatialindex.4.dylib
> -- Found Qwt: /usr/local/qwt-6.1.3/lib/libqwt.dylib (6.1.3)
> -- Found libzip: /usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib
> -- Found Sqlite3: /usr/local/Cellar/sqlite/3.22.0/lib/libsqlite3.0.dylib
> -- Found PostgreSQL: /usr/local/lib/libpq.dylib
> -- Found SpatiaLite: 

Re: [QGIS-Developer] issues in QGIS Server 2,18

[Giovanni Manghi]

Hi all,

>> It will be great to have the possibility to allow nullptr in the map
>> combobox.
>> Nyall, do you have an idea how to enhance QgsComposerItemComboBox
>> introdiuced by
>> https://github.com/qgis/QGIS/commit/1b4bd47076103e931e642c9c2b6a363f14b20a45
>> ?
>> Issue already exists: https://issues.qgis.org/issues/16899
>
> I wouldn't do it this way -- it was the hidden nature of the original
> support for setting no linked map which led to it being broken (also,
> no unit tests -- the combination of a non-obvious reuse of an existing
> widget + no unit tests is basically asking for something to break).
>
> I'd suggest instead adding an explicit checkbox here for "always show
> all layers for server requests" (but better wording!), under a new
> "server settings" group.

seems reasonable to me, and if I can ask... would it be backportable
to 2.18? This change has broken a few web published projects and the
workaround is ugly (manually change the .qgs files or add in the
layout a legend as a png/jpg image).

thanks!

-- 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] pylupdate5 does not understand classes in classes

[Ari Jolma]

On 09.03.2018 14:51, Luigi Pirelli wrote:

I was answering you to prepare a PR... and you just did it
https://github.com/qgis/QGIS/pull/6566
This is the best way to proceed, tnx


No, that PR is not about this issue. I did not create a PR for this 
because I don't know how to fix this. I assume buildvrt.py (and others 
with same issue) should be modified so that the class within the class 
is removed -- or maybe fix pylupdate5 since it is doing a bad job.


Ari



"don't ask what the QGIS dev community can do for you, but what you
can do for all"
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**


On 9 March 2018 at 12:32, Ari Jolma  wrote:

Hi,

Two strings in python/plugins/processing/algs/gdal/buildvrt.py do not
translate because pylupdate5 puts them into wrong context
(ParameterVrtDestination should be in buildvrt).

That's because in buildvrt.py ParameterVrtDestination class is defined
within buildvrt. Perhaps pylupdate5 simply does not support classes in
classes

I suspect this kind of error may be also in other places.

Ari


___
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] pylupdate5 does not understand classes in classes

[Luigi Pirelli]

I was answering you to prepare a PR... and you just did it
https://github.com/qgis/QGIS/pull/6566
This is the best way to proceed, tnx

"don't ask what the QGIS dev community can do for you, but what you
can do for all"
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**


On 9 March 2018 at 12:32, Ari Jolma  wrote:
> Hi,
>
> Two strings in python/plugins/processing/algs/gdal/buildvrt.py do not
> translate because pylupdate5 puts them into wrong context
> (ParameterVrtDestination should be in buildvrt).
>
> That's because in buildvrt.py ParameterVrtDestination class is defined
> within buildvrt. Perhaps pylupdate5 simply does not support classes in
> classes
>
> I suspect this kind of error may be also in other places.
>
> Ari
>
>
> ___
> 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] proj5 and epsg:3857 ?

[Jeff McKenna]

Thanks Kristian.

This experience shows us how today in the world of mapping "services" 
(remote mapping engines like QGIS, MapServer, PostGIS, GRASS GIS,..) 
rely on this unfortunate projection (thanks Google ha), where end-users 
of the services really have no access to the remote server's PROJ 
settings.  It feels like I have been battling this projection for 15 
years now ha.  -jeff




On 2018-03-09 5:39 AM, Kristian Evers wrote:

All,

Just to follow up on this, since I am the one to blame for this error to show 
up.
Both by introducing it in the first place and by releasing 5.0.0 with this as a
known bug. The bug was introduced to fix a range of other potential issues.
Unfortunately the architecture in the old API of PROJ makes it almost impossible
to both treat other transformations correct while also treating the Web Mercator
correctly. The problem is that the Web Mercator is, geodetically speaking, an
abomination of a transformation. It basically defies all logic. This has been 
known
for a long time of course. Unfortunately no tests were set up to catch this 
specific
transformation. I'll make sure to at least add Jeff's test case.

Regarding releasing the library with this bug included. The cause of the problem
was determined very close to the release time (which was announced a month
ahead). We did go through six release candidates. The vote for promotion of RC6
to final release was already started so I decided to release anyway since I did 
not
want to prolong the process even more. I am sure this bug would have been
discovered earlier if all of you QGIS developers would not have been super
busy with QGIS 3.0 and had had some spare time to test the PROJ release
candidates. I am not blaming anyone, it is just a case of bad timing. Not much
we can do about that really. Had I been in your shoes I would not have 
prioritized
testing other software either, that's for sure!

The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg
init-file and the transformation should work as expected. A proper fix will
come in 5.0.1 around April 1st.  I hope you all will continue to use PROJ 5.0.0
in your development builds despite this problem so other bugs can see the
light of day and be fixed in time for 5.0.1.

I completely agree with not requiring 5.0.0 as a dependency for QGIS. Hopefully
5.0.1 is a little better so that can be the recommended PROJ version for QGIS.

I would like to encourage you to take a look at the release schedule [0] for 
the next
couple of years. We are going to change things in order to keep up with current
geodetic developments in countries such as Australia, USA and Iceland.  It will
affect QGIS sooner or later. I am of course happy to provide assistance where
needed.

/Kristian

[0] 
https://github.com/OSGeo/proj.4/milestones?direction=asc=due_date=open

-Oprindelig meddelelse-
Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af 
Jeff McKenna
Sendt: 8. marts 2018 12:50
Til: qgis-developer@lists.osgeo.org
Emne: Re: [QGIS-Developer] proj5 and epsg:3857 ?

Hi Richard,

You can read my report to the PROJ team while I was testing the release
candidates:
http://lists.maptools.org/pipermail/proj/2018-February/008082.html
Sorry, it is a long thread.  I was trying to prevent (this here in QGIS,
for example) from happening, before the release.

-jeff





On 2018-03-07 4:13 PM, Richard Duivenvoorde wrote:

Hi,

Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home
address, and reproject the epsg:28992 coordinate fine to epsg:3857.

But since last week Debian has proj5, and the same plugin (in QGIS
master) now is off by 500 meter.

To reproduce: if you have a QGIS 2.18 with proj4, and the
'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example
the osm xyz layer.
Now do the same in QGIS master with proj5 and you'll see it is not going
to the right/same position.

Another observation: IN 2.18 I can 'reproject' the OSM layer to for
example epsg:4326, and still see (little distorted) map.
But in QGIS3/proj5 I do not see a map anymore.

Anybody else seeing this?

Regards,

Richard Duivenvoorde

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Compiling Qwt for qgis3/qt5

[Richard Duivenvoorde]

On 09-03-18 12:38, Andrew Brooks wrote:
> Hi
> 
> The docs state
>    Qwt >= 5.0 & (< 6.1 with internal QwtPolar)
> Can you be more explicit about exactly which version of Qwt (and
> QwtPolar) to use?
> 
> Most versions of Qwt don't build with Qt-5.
> QwtPolar doesn't seem to build at all.
> 
> Any advice regarding building Qwt?  Thanks!

Unless you really need it, you can build without QwtPolar:
-DWITH_QWTPOLAR=OFF

I'm on Debian sid, then there is
QWT Version 6.1.3
and I do build without QWT

Regards,

Richard Duivenvoorde

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Compiling Qwt for qgis3/qt5

[Andrew Brooks]

Hi

The docs state
   Qwt >= 5.0 & (< 6.1 with internal QwtPolar)
Can you be more explicit about exactly which version of Qwt (and QwtPolar)
to use?

Most versions of Qwt don't build with Qt-5.
QwtPolar doesn't seem to build at all.

Any advice regarding building Qwt?  Thanks!
___
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] proj5 and epsg:3857 ?

[Paolo Cavallini]

Il 09/03/2018 12:27, Sebastiaan Couwenberg ha scritto:

> FWIW, proj (5.0.0-3~exp1) available in Debian experimental contains a
> patch with the cherry-picked commit that fixes this issue. [0]

Thanks Bas!

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

[QGIS-Developer] pylupdate5 does not understand classes in classes

[Ari Jolma]

Hi,

Two strings in python/plugins/processing/algs/gdal/buildvrt.py do not 
translate because pylupdate5 puts them into wrong context 
(ParameterVrtDestination should be in buildvrt).


That's because in buildvrt.py ParameterVrtDestination class is defined 
within buildvrt. Perhaps pylupdate5 simply does not support classes in 
classes


I suspect this kind of error may be also in other places.

Ari


___
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] proj5 and epsg:3857 ?

[Sebastiaan Couwenberg]

On 03/09/2018 12:19 PM, Richard Duivenvoorde wrote:
> I will happily use/test whatever is available in Debian sid  :-)

FWIW, proj (5.0.0-3~exp1) available in Debian experimental contains a
patch with the cherry-picked commit that fixes this issue. [0]

It also contains a patch with the changes from PR #845 [1], but that
introduces a regression causing the shapelib test-suite to fail [1].
I've fixed with another patch included in proj (5.0.0-3~exp2). [2]

[0]
https://github.com/OSGeo/proj.4/commit/f41fad3ac2bff401456f31dd3273e163ea7d09af
[1] https://github.com/OSGeo/proj.4/pull/845
[2] https://github.com/OSGeo/proj.4/pull/845#issuecomment-371785556

Kind Regards,

Bas
___
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] proj5 and epsg:3857 ?

[Tobias Wendorff]

Am Fr, 9.03.2018, 12:19 schrieb Richard Duivenvoorde:
>
> My point was that I think as QGIS we can 'hide' this issue by
> not using 5.0.0 'yet' in the osgeo4w package.

Hehe, proj is hiding itself, since 493 is still shown in "about" ;)

___
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] proj5 and epsg:3857 ?

[Richard Duivenvoorde]

Hi All,

I second that: not blaming anybody here. This happens in the real world.

My point was that I think as QGIS we can 'hide' this issue by not using
5.0.0 'yet' in the osgeo4w package.

I will happily use/test whatever is available in Debian sid  :-)

Also tried Kristian's fix.

For QGIS users: QGIS does not use the epsg file provided by your proj
install, but a srs.db:
 {QGISINSTALLDIR}/share/qgis/resources/srs.db

I edited (using DB browser) and removed the "+nadgrids=@null" clause
from the epsg:3857 line.
Checked by looking into the srs chooser of QGIS and seeing that it was
indeed not visible anymore.

But it does not seem a 100% hack with me. While more near the 'real'
place, it is still 150m off?

Regards and thanks for all the work on Proj: one of the corner stones of
QGIS!!

Richard Duivenvoorde


On 09-03-18 11:38, Even Rouault wrote:
> Kristian 
> 
> your are certainly not too blame at à personal level. this is the kind
> of this that happen inevitably given a certain amount of changes . i'm
> surprised that the GDAL autotest suite did not catch this but the cause
> is likely that the GDAL c++ class that wraps proj has an optimisation
> when transforming from 3857 to 4326. if you transform an array of points
> of the same northing they have the same latitude. this is a common case
> for gdalwarp internal mechanics. thus you need to do trigonometric
> computations just once! so proj is completely short circuited for that
> case. 
> 
> i'll add a test for the reverse transformation that uses proj (could
> receive a similar optimisation but isnt needed when warping unrectified
> imagery with RPC to WebMercator)
> 
> Even 
> ---
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> 
> 
>  Message d'origine 
> De : Kristian Evers 
> Date :09/03/2018 10:39 (GMT+01:00)
> À : qgis-developer@lists.osgeo.org
> Cc :
> Objet : Re: [QGIS-Developer] proj5 and epsg:3857 ?
> 
> All,
> 
> Just to follow up on this, since I am the one to blame for this error to
> show up.
> Both by introducing it in the first place and by releasing 5.0.0 with
> this as a
> known bug. The bug was introduced to fix a range of other potential issues.
> Unfortunately the architecture in the old API of PROJ makes it almost
> impossible
> to both treat other transformations correct while also treating the Web
> Mercator
> correctly. The problem is that the Web Mercator is, geodetically
> speaking, an
> abomination of a transformation. It basically defies all logic. This has
> been known
> for a long time of course. Unfortunately no tests were set up to catch
> this specific
> transformation. I'll make sure to at least add Jeff's test case.
> 
> Regarding releasing the library with this bug included. The cause of the
> problem
> was determined very close to the release time (which was announced a month
> ahead). We did go through six release candidates. The vote for promotion
> of RC6
> to final release was already started so I decided to release anyway
> since I did not
> want to prolong the process even more. I am sure this bug would have been
> discovered earlier if all of you QGIS developers would not have been super
> busy with QGIS 3.0 and had had some spare time to test the PROJ release
> candidates. I am not blaming anyone, it is just a case of bad timing.
> Not much
> we can do about that really. Had I been in your shoes I would not have
> prioritized
> testing other software either, that's for sure!
> 
> The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg
> init-file and the transformation should work as expected. A proper fix will
> come in 5.0.1 around April 1st.  I hope you all will continue to use
> PROJ 5.0.0
> in your development builds despite this problem so other bugs can see the
> light of day and be fixed in time for 5.0.1.
> 
> I completely agree with not requiring 5.0.0 as a dependency for QGIS.
> Hopefully
> 5.0.1 is a little better so that can be the recommended PROJ version for
> QGIS.
> 
> I would like to encourage you to take a look at the release schedule [0]
> for the next
> couple of years. We are going to change things in order to keep up with
> current
> geodetic developments in countries such as Australia, USA and Iceland. 
> It will
> affect QGIS sooner or later. I am of course happy to provide assistance
> where
> needed.
> 
> /Kristian
> 
> [0]
> https://github.com/OSGeo/proj.4/milestones?direction=asc=due_date=open
> 
> -Oprindelig meddelelse-
> Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På
> vegne af Jeff McKenna
> Sendt: 8. marts 2018 12:50
> Til: qgis-developer@lists.osgeo.org
> Emne: Re: [QGIS-Developer] proj5 and epsg:3857 ?
> 
> Hi Richard,
> 
> You can read my report to the PROJ team while I was testing the release
> candidates:
> http://lists.maptools.org/pipermail/proj/2018-February/008082.html
> Sorry, it is a long thread.  I was trying to prevent (this here in QGIS,
> for 

Re: [QGIS-Developer] Separate namespaces for QGIS-LTR and QGIS (3)

[Carlo A. Bertelli (Charta s.r.l.)]

Sorry for rewinding the thread to where it started.
Provided that users can benefit from keeping the last stable release and an
LTR both installed, do you think that this is up to the specific platform
to handle this (OsGeo4W does it already) or a more general solution can be
provided?
The LTR will be on version 2 for several months, so I suggest the libraries
could use a different namespace. Is this an acceptable solution? Are there
alternatives.
c


On Sun, Mar 4, 2018 at 12:13 PM, Nathan Woodrow  wrote:

> Hey Carlo,
>
> I guess we are a bit confused at the moment because the goal of QGIS has
> never really been that at all, at least not post v1.  We have always aimed
> to make it the best it can be for a lot of different workflows.
>
> I'm not sure I would consider anything in QGIS a step backwords at all,
> There has been a crazy, and I mean crazy, amount of dev work to create a
> better product for end users.
>
> - Nathan
>
> On Sun, Mar 4, 2018 at 6:21 PM, Carlo A. Bertelli (Charta s.r.l.) <
> carlo.berte...@gmail.com> wrote:
>
>> No pun intended, when you announced what you were going to do, I used
>> MapInfo as my main GIS and Thuban as a viewer and I hoped very much you
>> were starting something that was went further.
>> Since version 0.11 I was using QGIS as my "main" GIS. What I was saying
>> is that the continuous improvement made all users rely on a dependable
>> QGIS. Departing from a cautious approach to a very fast development pace
>> means users can keep an LTR for day to day working (no advanced needs) and
>> an "evolution" approach for the advanced features. I didn't think that
>> saying "viewer" I diminished the huge effort of these years. The "viewer"
>> approach is still a plus of QGIS and it's not something easy to accomplish
>> if I see the work on Processing and what has been done for GRASS. I think
>> being a "viewer" for GDAL means getting all of the benefits of an evolving
>> project. This has its drawbacks, some processing that is needed at the
>> feature level was available only on layers as a whole. I meant that, the
>> last major version is a further step that asks for more dependability.
>> My apologies for all the developers who felt injured by my words.
>> c
>>
>> On Sun, Mar 4, 2018 at 12:04 AM, Tim Sutton  wrote:
>>
>>> Hi
>>>
>>> On 03 Mar 2018, at 20:43, Jürgen E. Fischer  wrote:
>>>
>>> Hi,
>>>
>>> On Sat, 03. Mar 2018 at 12:43:00 +0100, Carlo A. Bertelli (Charta
>>> s.r.l.) wrote:
>>>
>>> but also abandoned the idea of QGIS as a simple viewer that acquires
>>> editing
>>> abilities by plugins.
>>>
>>>
>>> Was that ever a goal?  If so, I didn't know - but I have been around
>>> only for a
>>> bit more than 10 years ;)
>>>
>>>
>>> Yeah I think the idea of being a full fledged GIS rather than a simple
>>> viewer has been with us for many years already….glad to see it is really
>>> taking hold with 3.0 though :-) Great to have your inputs Carlo.
>>>
>>> Regards
>>>
>>> Tim
>>>
>>>
>>>
>>> Jürgen
>>>
>>> --
>>> Jürgen E. Fischer   norBIT GmbH Tel.
>>> +49-4931-918175-31
>>> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
>>> +49-4931-918175-50
>>> Software Engineer   D-26506 Norden
>>> http://www.norbit.de
>>> QGIS release manager (PSC)  GermanyIRC: jef on
>>> FreeNode
>>> ___
>>> 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*
>>> QGIS Project Steering Committee Chair
>>> t...@qgis.org
>>>
>>
>> --
>> 
>> --
>> Carlo A. Bertelli
>>Charta servizi e sistemi per il territorio e la storia ambientale srl
>>   Dipendenze del palazzo Doria,
>>   vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
>>   tel./fax +39(0)10 2475439  +39 0108566195 <010%20856%206195>
>> mobile:+39 393 1590711 <393%20159%200711>
>>e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
>> 
>> --
>>
>>
>>
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>


-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  

Re: [QGIS-Developer] proj5 and epsg:3857 ?

[Even Rouault]

Kristian 

your are certainly not too blame at à personal level. this is the kind of this 
that happen inevitably given a certain amount of changes . i'm surprised that 
the GDAL autotest suite did not catch this but the cause is likely that the 
GDAL c++ class that wraps proj has an optimisation when transforming from 3857 
to 4326. if you transform an array of points of the same northing they have the 
same latitude. this is a common case for gdalwarp internal mechanics. thus you 
need to do trigonometric computations just once! so proj is completely short 
circuited for that case. 

i'll add a test for the reverse transformation that uses proj (could receive a 
similar optimisation but isnt needed when warping unrectified imagery with RPC 
to WebMercator)

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

 Message d'origine De : Kristian Evers 
 Date :09/03/2018  10:39  (GMT+01:00) À : 
qgis-developer@lists.osgeo.org Cc :  Objet : Re: 
[QGIS-Developer] proj5 and epsg:3857 ? 
All,

Just to follow up on this, since I am the one to blame for this error to show 
up.
Both by introducing it in the first place and by releasing 5.0.0 with this as a 
known bug. The bug was introduced to fix a range of other potential issues.
Unfortunately the architecture in the old API of PROJ makes it almost impossible
to both treat other transformations correct while also treating the Web Mercator
correctly. The problem is that the Web Mercator is, geodetically speaking, an
abomination of a transformation. It basically defies all logic. This has been 
known
for a long time of course. Unfortunately no tests were set up to catch this 
specific
transformation. I'll make sure to at least add Jeff's test case.

Regarding releasing the library with this bug included. The cause of the problem
was determined very close to the release time (which was announced a month
ahead). We did go through six release candidates. The vote for promotion of RC6
to final release was already started so I decided to release anyway since I did 
not
want to prolong the process even more. I am sure this bug would have been
discovered earlier if all of you QGIS developers would not have been super
busy with QGIS 3.0 and had had some spare time to test the PROJ release
candidates. I am not blaming anyone, it is just a case of bad timing. Not much
we can do about that really. Had I been in your shoes I would not have 
prioritized
testing other software either, that's for sure!

The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg
init-file and the transformation should work as expected. A proper fix will
come in 5.0.1 around April 1st.  I hope you all will continue to use PROJ 5.0.0
in your development builds despite this problem so other bugs can see the
light of day and be fixed in time for 5.0.1.

I completely agree with not requiring 5.0.0 as a dependency for QGIS. Hopefully
5.0.1 is a little better so that can be the recommended PROJ version for QGIS.

I would like to encourage you to take a look at the release schedule [0] for 
the next
couple of years. We are going to change things in order to keep up with current
geodetic developments in countries such as Australia, USA and Iceland.  It will
affect QGIS sooner or later. I am of course happy to provide assistance where
needed.

/Kristian

[0] 
https://github.com/OSGeo/proj.4/milestones?direction=asc=due_date=open

-Oprindelig meddelelse-
Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af 
Jeff McKenna
Sendt: 8. marts 2018 12:50
Til: qgis-developer@lists.osgeo.org
Emne: Re: [QGIS-Developer] proj5 and epsg:3857 ?

Hi Richard,

You can read my report to the PROJ team while I was testing the release 
candidates: 
http://lists.maptools.org/pipermail/proj/2018-February/008082.html 
Sorry, it is a long thread.  I was trying to prevent (this here in QGIS, 
for example) from happening, before the release.

-jeff





On 2018-03-07 4:13 PM, Richard Duivenvoorde wrote:
> Hi,
> 
> Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home
> address, and reproject the epsg:28992 coordinate fine to epsg:3857.
> 
> But since last week Debian has proj5, and the same plugin (in QGIS
> master) now is off by 500 meter.
> 
> To reproduce: if you have a QGIS 2.18 with proj4, and the
> 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example
> the osm xyz layer.
> Now do the same in QGIS master with proj5 and you'll see it is not going
> to the right/same position.
> 
> Another observation: IN 2.18 I can 'reproject' the OSM layer to for
> example epsg:4326, and still see (little distorted) map.
> But in QGIS3/proj5 I do not see a map anymore.
> 
> Anybody else seeing this?
> 
> Regards,
> 
> Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: 

[QGIS-Developer] How to disable authentication disabled in messagebar

[Rashad Kanavath]

Hello,

How can I disable authentication from qgis during build or runtime?
Whe opening settings -> options -> authentication, I have below message

"Authentication system is DISABLED:
QCA's OpenSSL plugin (qca-openssl) is missing.
"
I also have an "critical" message in messagbar every time qgis is
started. It's a bit of annoying.
I don't have strong preference of setting authentication/security on
my qgis installation. So I would prefer to disable this feature in build.

"Messages[2] Authentication System : DISABLED. Resources authenticating via the 
system can not be accessed"

If one doesn't have qca-openssl or whatever is required to enable
authentication then is nice to have no such error messages. In this
case, qgis is trying to activate feature where user does not have
required dependencies. And user is well aware of it during configure
step

I get below message during cmake configure.:
"
-- QtCore/QCA include/lib variables missing or CMake is cross-compiling,
-- skipping QCA OpenSSL plugin C++ check
"

-- 
Take care,
Rashad
___
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] proj5 and epsg:3857 ?

[Kristian Evers]

All,

Just to follow up on this, since I am the one to blame for this error to show 
up.
Both by introducing it in the first place and by releasing 5.0.0 with this as a 
known bug. The bug was introduced to fix a range of other potential issues.
Unfortunately the architecture in the old API of PROJ makes it almost impossible
to both treat other transformations correct while also treating the Web Mercator
correctly. The problem is that the Web Mercator is, geodetically speaking, an
abomination of a transformation. It basically defies all logic. This has been 
known
for a long time of course. Unfortunately no tests were set up to catch this 
specific
transformation. I'll make sure to at least add Jeff's test case.

Regarding releasing the library with this bug included. The cause of the problem
was determined very close to the release time (which was announced a month
ahead). We did go through six release candidates. The vote for promotion of RC6
to final release was already started so I decided to release anyway since I did 
not
want to prolong the process even more. I am sure this bug would have been
discovered earlier if all of you QGIS developers would not have been super
busy with QGIS 3.0 and had had some spare time to test the PROJ release
candidates. I am not blaming anyone, it is just a case of bad timing. Not much
we can do about that really. Had I been in your shoes I would not have 
prioritized
testing other software either, that's for sure!

The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg
init-file and the transformation should work as expected. A proper fix will
come in 5.0.1 around April 1st.  I hope you all will continue to use PROJ 5.0.0
in your development builds despite this problem so other bugs can see the
light of day and be fixed in time for 5.0.1.

I completely agree with not requiring 5.0.0 as a dependency for QGIS. Hopefully
5.0.1 is a little better so that can be the recommended PROJ version for QGIS.

I would like to encourage you to take a look at the release schedule [0] for 
the next
couple of years. We are going to change things in order to keep up with current
geodetic developments in countries such as Australia, USA and Iceland.  It will
affect QGIS sooner or later. I am of course happy to provide assistance where
needed.

/Kristian

[0] 
https://github.com/OSGeo/proj.4/milestones?direction=asc=due_date=open

-Oprindelig meddelelse-
Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af 
Jeff McKenna
Sendt: 8. marts 2018 12:50
Til: qgis-developer@lists.osgeo.org
Emne: Re: [QGIS-Developer] proj5 and epsg:3857 ?

Hi Richard,

You can read my report to the PROJ team while I was testing the release 
candidates: 
http://lists.maptools.org/pipermail/proj/2018-February/008082.html 
Sorry, it is a long thread.  I was trying to prevent (this here in QGIS, 
for example) from happening, before the release.

-jeff





On 2018-03-07 4:13 PM, Richard Duivenvoorde wrote:
> Hi,
> 
> Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home
> address, and reproject the epsg:28992 coordinate fine to epsg:3857.
> 
> But since last week Debian has proj5, and the same plugin (in QGIS
> master) now is off by 500 meter.
> 
> To reproduce: if you have a QGIS 2.18 with proj4, and the
> 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example
> the osm xyz layer.
> Now do the same in QGIS master with proj5 and you'll see it is not going
> to the right/same position.
> 
> Another observation: IN 2.18 I can 'reproject' the OSM layer to for
> example epsg:4326, and still see (little distorted) map.
> But in QGIS3/proj5 I do not see a map anymore.
> 
> Anybody else seeing this?
> 
> Regards,
> 
> Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
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 [1352] Beeline approval notification.

[noreply]

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