Re: [QGIS-Developer] MingW64 Windows 64bit Build action failing: a possible workaround

[Sandro Mani via QGIS-Developer]

On 15.09.23 10:35, Andrea Giudiceandrea wrote:

Sandro Mani manisandro at gmail.com
Mon Sep 11 22:22:12 PDT 2023



This should since be fixed in the latest mingw-filesystem. See [1].


Hi Sandro,
the new fixed version is now available used, so I will remove my 
workaround.


Anyway the MingW64 Windows 64bit Build is failing again for: "dnf5: 
command not found".
The command was changed from dnf to dnf5 1 month ago with 
https://github.com/qgis/QGIS/pull/54152/commits/2a4a4b69475f9ae7d00880a6d3434f723a2a52c1 
because of "dnf: command not found".


Reverting back to dnf would fix the issue.

Do you know if it is a temporary issue with dnf5 or should we 
permanently use dnf?



Hi Andrea

I'd revert back to dnf, dnf5 has been postponed for the time being.

Sandro

___
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] MingW64 Windows 64bit Build action failing: a possible workaround

[Sandro Mani via QGIS-Developer]

Hi

This should since be fixed in the latest mingw-filesystem. See [1].

Sandro

[1] 
https://lists.fedoraproject.org/archives/list/mi...@lists.fedoraproject.org/thread/UQXZXB4O4GJZC4TQCDZNMQBA23TWISQQ/


On 10.09.23 06:48, Andrea Giudiceandrea via QGIS-Developer wrote:

Hi devs,
the MingW64 Windows 64bit Build action is continuously failing since a 
couple of days with the following error:


/usr/bin/mingw64-cmake: line 92: fg: no job control

The issue is caused by the %__cmake macro not correctly evaluated and 
misinterpreted.


A possible workaround, which I've tested and which makes the action no 
longer fail and the build succeed, would be to change line 79 of 
/ms-windows/mingw/build.sh from


  mingw$bits-cmake \

to

  rpm --eval "%{mingw64_cmake}" > mingw64-cmake.sh
  sed -i -e 's/%__cmake/cmake/' mingw64-cmake.sh
  chmod +x mingw64-cmake.sh
  ./mingw$bits-cmake.sh \


See 
https://gitlab.gnome.org/TinyTrebuchet/gtk/-/blob/main/.gitlab-ci.yml#L156-158


It's not clear to me what actually triggered the issue, so very likely 
there is a better fix.


Best regards.

Andrea
___
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] MingW builds not enforced on Github actions

[Sandro Mani]

On 28.02.22 21:29, Denis Rouzaud wrote:

Hi all,

Since the MingW builds were all failing lately on Github actions, I 
have removed the requirement for this build for the PRs.


FWIW, should now be fixed. I just did some major packaging work to 
reduce the maintenance burden, and one issue with mingw-python3 slipped 
through. In any case, feel free to just ping me when the builds fail, 
I'm usually pretty responsive... Or is there a way to get notified when 
a pipeline starts failing?


Sandro

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

Re: [QGIS-Developer] QGIS and Fedora: My tips

[Sandro Mani]

Debug sessions of QGIS just "hang"


I noticed this one after upgrading to Fedora 35. Trying to run any
session of QGIS under a debug environment (eg. gdb) just resulted in a
hang at startup.

I tracked this one down to this change:
https://fedoraproject.org/wiki/Changes/DebuginfodByDefault, where
Fedora 35 enables "debuginfod" by default.

debuginfod is supposed to be a helpful thing which downloads debug
info on demand. The "hang" during startup of QGIS debug is actually
just debuginfod trying to download all the debug info for libraries
used by QGIS. BUT... it's an INSANE amount of data it's trying to
download. debuginfod is trying to download debug info for every single
library used by QGIS recursively. Which results in it trying to even
download debug info for webkit, which is so large that I could never
get the download to ever complete!!! Even worse, debuginfod defaults
to auto-deleting all downloaded debug info on a weekly basis so if
you were super-patient and waited for this to download then you'll
just have to go through the same thing again in a week.

Solution: disable debuginfod, by unsetting the DEBUGINFOD_URLS
environment variable. Debug sessions of QGIS will start just like they
always used to.


This one is https://bugzilla.redhat.com/show_bug.cgi?id=2035283 an 
recently solved - gdb will now only download debuginfos if input came 
from a terminal (unless debuginfod is globally disabled obviously, 
either through clearing DEBUGINFOD_URLS or echo "set debuginfod enabled 
off" > ~/.gdbinit).


Sandro


___
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] CI broken (MinGW64)

[Sandro Mani]

On 02.10.21 09:49, Andrea Giudiceandrea wrote:

Will be fixed with this: https://github.com/qgis/QGIS/pull/45303


Hi Sandro,
probably this is related... while, now, the MinGW64 Windows build 
succeeds, QGIS from the MinGW64 build doesn't run properly and the 
Python support results disabled.


Running a recent QGIS (5a572dac) from MinGW64 Windows build artifact, 
the following error is reported at the beginning and QGIS doesn't have 
the Python support:


Couldn't load SIP module.
Python support will be disabled.

Traceback (most recent call last):
  File "", line 1, in
  File 
"C:\Users\giudiceandrea\Downloads\QGIS-Portable_4\lib\python3.10\site-packages\qgis\__init__.py", 
line 78, in

    from qgis.PyQt import QtCore
  File 
"C:\Users\giudiceandrea\Downloads\QGIS-Portable_4\lib\python3.10\site-packages\qgis\PyQt\QtCore.py", 
line 24, in

    from PyQt5.QtCore import *
ModuleNotFoundError: No module named 'PyQt5.sip'


Hi Andrea

This is fixed in mingw-python-qt5-5.15.4-2.fc36, which adds a dependency 
on mingw-python3-PyQt5_sip. So this should be fixed as soon as 
mingw-python-qt5-5.15.4-2.fc36 has propagated to the repos.


Sandro

___
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] CI broken (MinGW64)

[Sandro Mani]

Will be fixed with this: https://github.com/qgis/QGIS/pull/45303

Sandro

On 30.09.21 14:48, Sandro Santilli wrote:

CI broke about 3 hours ago for some reason external to QGIS codebase:
https://github.com/qgis/QGIS/runs/3754353807#step:7:97

 Could not find PyQt5

Anyone with better knowledge of the CI Docker setup to deal with this ?

--strk;
___
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] QtCreator does not start QGIS?

[Sandro Mani]

As for Fedora, F33 and F34 have fixed packages, but I see that the F33 
update was never submitted by the maintainer - I've done so now [1].


Best
Sandro

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-1893aa323f


On 12.11.20 19:17, Alessandro Pasotti wrote:
I switched to QT binaries and sources provided by the QT maintenance 
tool and that's my way to Nirvana.


I self-build PyQt all the others dependencies.

Cheers



On Thu, Nov 12, 2020, 18:51 Richard Duivenvoorde <mailto:rdmaili...@duif.net>> wrote:


Ough, yes, that looks like it (5.15.1)...

Thanks Sandro for checking.

The 'random' qtcreator crashes at startup indeed all show
'sigtraps'...
And I also thought that it has something todo with the
process.start stuff.

I see QProcess in a lot of places, so I do not think I can disable
parts of QGIS compile?

Mmm this is bad (for me & other Testing Debianista's). Hoping
there will be a fixed version (qt) soon..
Other options?
Downgrade Qt?
Compile Qt myself?
Install Fedora on another machine (which Qt is there?)?

Sigh 0o.

    Richard

On 11/12/20 6:00 PM, Sandro Mani wrote:
> Hi Richard
>
> If you are using Qt5.15.{0,1} and are getting random SIGTRAPS,
or the process segfaulting straight after starting through gdb,
this might be [1].
>
> Sandro
>
> [1] https://bugreports.qt.io/browse/QTBUG-86319
<https://bugreports.qt.io/browse/QTBUG-86319>
>
> On 12.11.20 15:45, Richard Duivenvoorde wrote:
>> Still having troubles starting QGIS in debug in QtCreator in my
setup today.
>>
>> See https://duif.net/qc.png <https://duif.net/qc.png>
>>
>> So QGIS (in QtCreator) starts, and during startup it stops and
shows me the dissassembler(?) view. Sometimes I can see something
(like in this screendump: something with libnss ?) sometimes all
is white/empty.
>>
>> Last this I in the log is: "Destroyed while process ("whoami"),
which according to git is recently changed but... does not seem
related to me:
>>
https://github.com/qgis/QGIS/commit/7a38388a8762503b0bdba55065fffea2ff24137a

<https://github.com/qgis/QGIS/commit/7a38388a8762503b0bdba55065fffea2ff24137a>
>>
>> Regards,
>>
>> Richard
>>
>>
>>
>> On 11/11/20 9:16 AM, Richard Duivenvoorde wrote:
>>> Hi,
>>>
>>> Currently in my Qt build I cannot debug QGIS in qtcreator
because it hangs/stops when showing the splash.
>>> After some time the Application Output shows:
>>>
>>> ../../src/core/qgsmessagelog.cpp:29 : (logMessage) [60891ms]
[thread:0x560d9d00] 2020-11-11T08:58:15 [1] HTTP fetch
https://feed.qgis.org/?after=1605081272&lang=en
<https://feed.qgis.org/?after=1605081272&lang=en> failed with
error Operation canceled
>>> ../../src/core/qgsmessagelog.cpp:29 : (logMessage) [0ms]
[thread:0x560d9d00] 2020-11-11T08:58:15 Network[1] Network
request https://feed.qgis.org/?after=1605081272&lang=en
<https://feed.qgis.org/?after=1605081272&lang=en> timed out
>>>
>>> I am connected, and
https://feed.qgis.org/?after=1605081272&lang=en
<https://feed.qgis.org/?after=1605081272&lang=en> is available
from my browser.
>>>
>>> Disabling: 'Show QGIS news feed on welcome page' and 'Check
QGIS version at startup' fix this.
>>>
>>> Others have this issue currently?
>>>
>>> (I hit my head also with this sometimes when in mixed/http
proxied environments
>>> I still think we should use 'opt in' for these 'QGIS phoning
home stuff' instead of 'opt out')
>>>
>>> Regards,
>>>
>>> Richard Duivenvoorde
>>>
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
<mailto:QGIS-Developer@lists.osgeo.org>
>>> List info:
https://lists.osgeo.org/mailman/listinfo/qgis-developer
<https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>>> Unsubscribe:
https://lists.osgeo.org/mailman/listinfo/qgis-developer
<https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
<mailto:QGIS-Developer@lists.osgeo.org>
>> List info:
  

Re: [QGIS-Developer] QtCreator does not start QGIS?

[Sandro Mani]

Hi Richard

If you are using Qt5.15.{0,1} and are getting random SIGTRAPS, or the 
process segfaulting straight after starting through gdb, this might be [1].


Sandro

[1] https://bugreports.qt.io/browse/QTBUG-86319

On 12.11.20 15:45, Richard Duivenvoorde wrote:

Still having troubles starting QGIS in debug in QtCreator in my setup today.

See https://duif.net/qc.png

So QGIS (in QtCreator) starts, and during startup it stops and shows me the 
dissassembler(?) view. Sometimes I can see something (like in this screendump: 
something with libnss ?) sometimes all is white/empty.

Last this I in the log is: "Destroyed while process ("whoami"), which according 
to git is recently changed but... does not seem related to me:
https://github.com/qgis/QGIS/commit/7a38388a8762503b0bdba55065fffea2ff24137a

Regards,

Richard



On 11/11/20 9:16 AM, Richard Duivenvoorde wrote:

Hi,

Currently in my Qt build I cannot debug QGIS in qtcreator because it 
hangs/stops when showing the splash.
After some time the Application Output shows:

../../src/core/qgsmessagelog.cpp:29 : (logMessage) [60891ms] 
[thread:0x560d9d00] 2020-11-11T08:58:15 [1] HTTP fetch 
https://feed.qgis.org/?after=1605081272&lang=en failed with error Operation 
canceled
../../src/core/qgsmessagelog.cpp:29 : (logMessage) [0ms] [thread:0x560d9d00] 
2020-11-11T08:58:15 Network[1] Network request 
https://feed.qgis.org/?after=1605081272&lang=en timed out

I am connected, and https://feed.qgis.org/?after=1605081272&lang=en is 
available from my browser.

Disabling: 'Show QGIS news feed on welcome page' and 'Check QGIS version at 
startup' fix this.

Others have this issue currently?

(I hit my head also with this sometimes when in mixed/http proxied environments
I still think we should use 'opt in' for these 'QGIS phoning home stuff' 
instead of 'opt out')

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 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] Globe Plugin

[Sandro Mani]

On 20.05.20 17:02, Martin Dobias wrote:

Hi

On Wed, May 20, 2020 at 9:23 AM Marco Bernasocchi > wrote:


As one of the grandfathers of the original Globe plugin, I'd say
ditch it - BUT... let's see what Matthias,  Martin and  Sandro
think since they probably are the ones that are most up-to-date on
can now be done with the 3d map canvas and globe

I am personally +1 to remove it:
- native QGIS 3D view has most of the functionality + a lot more to offer
- there have been no real updates besides compilation / code style 
fixes in last ~4 years

- dependencies on OpenSceneGraph and osgEarth have always caused troubles
- we have been on the road to kill any internal c++ plugins in QGIS 
source tree


The only major piece of functionality that's not in the native QGIS 3D 
view is the "earth as a globe" view - so there may be some users that 
may be missing that functionality.


So if we decide to remove the plugin, the question is whether to 
remove it ASAP or wait until QGIS 4.0 or wait until globe support is 
in native QGIS 3D...


No objections to removing on my part.

Best
Sandro

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

Re: [QGIS-Developer] QGIS 3D and Globe plugin

[Sandro Mani]

Hi


On 11.12.2017 00:13, Tisham Dhar wrote:


Just to throw my hat in the ring. I am very excited about the 3D 
pathway QGIS is embarking on and I am happy to support crowdfunding 
and provide code. I have written QT and GL enabled applications in 
openscenegraph for work purposes with OSGB outputs from our 3D city 
models. If anyone can see how to integrate this I would like to add 
OSGB/OpenScenegraph support in the 3D view.


Well just for the record, the QGIS Globe plugin is actually based on 
osgEarth, which is built on OpenSceneGraph. So there it should be fairly 
easy to integrate.


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 20.09.2017 17:39, Even Rouault wrote:


On mercredi 20 septembre 2017 17:32:27 CEST Sandro Mani wrote:

> On 19.09.2017 19:15, Even Rouault wrote:

> > On mardi 19 septembre 2017 18:30:50 CEST Sandro Mani wrote:

> > > On 11.07.2017 14:31, Even Rouault wrote:

> > > > We could potentially imagine to defer the repacking at

> > > >

> > > > leaveUpdateMode() time, actually in the close() method which 
is called


> > > >

> > > > when the reference counter of the update mode drops to zero (*),

> > > >

> > > > instead of doing it at the end of each operation.

> > >

> > > To come back to this, I was looking at moving replack() to 
close(), but


> > >

> > > noticed that syncToDisc() has the logic "for shapefiles, remove 
spatial


> > >

> > > index files and create a new index" which calls close. And 
syncToDisk is


> > >

> > > still called after every change. So should syncToDisk be also 
moved to


> > >

> > > close(), or at least blocked if an updateMode is active?

> >

> > Yes that would probably make sense to block syncToDisk() while in

> > updateMode (so when mUpdateModeStackDepth > 0), but probably only if

> > enterUpdateMode() is called by QgsVectorLayer::startEditing(), and not

> > when called implicitly by doInitialActionsForEdition(), which might be

> > the case if someone directly works at the provider level

> >

> > bool QgsOgrProvider::doInitialActionsForEdition()

> >

> > {

> >

> > if ( !mValid )

> >

> > return false;

> >

> > if ( !mWriteAccess && mWriteAccessPossible && mDynamicWriteAccess )

> >

> > {

> >

> > QgsDebugMsg( "Enter update mode implictly" );

> >

> > if ( !enterUpdateMode() )

> >

> > return false;

> >

> > }

> >

> > return true;

> >

> > }

> >

> > So probably a mImplicitUpdateMode flag should be set above near the

> > QgsDebugMsg(), and the check to decide whether we can defer

> > syncToDisk() would be ( !mImplicitUpdateMode && 
mUpdateModeStackDepth > 0)


>

> Hm but will that flag never be cleared again once set? Since AFAICT a

> there is no leaveUpdateMode matching the enterUpdateMode called by

> doInitialActionsForEdition.

>

> As I understand, the approach to do changes with stable ids would be to

> first enterUpdateMode, then perform the changes, then leaveUpdateMode,

> at which point the changes are synced and the dataset repacked.

Yes

> With the

> mImplicitUpdateMode flag, if anyone worked directly at provider level

> before you come along, deferring syncToDisk would never happen since the

> mImplicitUpdateMode was set and remains set.

Yes my idea was to keep the current behaviour where repack() is done 
frequently, as you cannot know when the dataset should be in a 
consistant state.


But we could also decide to defer syncToDisk() at provider deletion 
(would make the code simpler)


I have no idea of the existing use cases behind and if that would 
break some.


Suppose something like [1] should both allow reliably deferring 
syncToDisk when an updateMode was explicitly entered while keeping the 
current behaviour of immediate syncToDisk for implicit update mode.


Sandro

[1] 
https://github.com/manisandro/QGIS/commit/13f451bdcbb653e9d69e55c79a5ba520d3f1712e
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 19.09.2017 19:15, Even Rouault wrote:


On mardi 19 septembre 2017 18:30:50 CEST Sandro Mani wrote:

> On 11.07.2017 14:31, Even Rouault wrote:

> > We could potentially imagine to defer the repacking at

> > leaveUpdateMode() time, actually in the close() method which is called

> > when the reference counter of the update mode drops to zero (*),

> > instead of doing it at the end of each operation.

>

> To come back to this, I was looking at moving replack() to close(), but

> noticed that syncToDisc() has the logic "for shapefiles, remove spatial

> index files and create a new index" which calls close. And syncToDisk is

> still called after every change. So should syncToDisk be also moved to

> close(), or at least blocked if an updateMode is active?

>

Yes that would probably make sense to block syncToDisk() while in 
updateMode (so when mUpdateModeStackDepth > 0), but probably only if 
enterUpdateMode() is called by QgsVectorLayer::startEditing(), and not 
when called implicitly by doInitialActionsForEdition(), which might be 
the case if someone directly works at the provider level


bool QgsOgrProvider::doInitialActionsForEdition()

{

if ( !mValid )

return false;

if ( !mWriteAccess && mWriteAccessPossible && mDynamicWriteAccess )

{

QgsDebugMsg( "Enter update mode implictly" );

if ( !enterUpdateMode() )

return false;

}

return true;

}

So probably a mImplicitUpdateMode flag should be set above near the 
QgsDebugMsg(), and the check to decide whether we can defer 
syncToDisk() would be ( !mImplicitUpdateMode && mUpdateModeStackDepth > 0)


Hm but will that flag never be cleared again once set? Since AFAICT a 
there is no leaveUpdateMode matching the enterUpdateMode called by 
doInitialActionsForEdition.


As I understand, the approach to do changes with stable ids would be to 
first enterUpdateMode, then perform the changes, then leaveUpdateMode, 
at which point the changes are synced and the dataset repacked. With the 
mImplicitUpdateMode flag, if anyone worked directly at provider level 
before you come along, deferring syncToDisk would never happen since the 
mImplicitUpdateMode was set and remains set.


Sandro
___
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] OGR/GBD: Unrecognized field name OBJECTID

[Sandro Mani]

On 20.09.2017 12:46, Even Rouault wrote:


On mercredi 20 septembre 2017 11:34:50 CEST Sandro Mani wrote:

> On 20.09.2017 08:45, Nyall Dawson wrote:

> > On 20 September 2017 at 10:18, Nyall Dawson 
 wrote:


> >> Hi all,

> >>

> >> I've just been trying to diagnose an issue with loading an existing

> >> 2.18 project in the new 2.18.13 release.

> >>

> >> Seems like something may be broken here with regards to loading OGR

> >> based layers which have a subset filter set.

> >>

> >> These layers trigger the "missing layers" dialog when loading the

> >> project and the layer link cannot be repaired without removing the

> >> filter clause.

> >>

> >> (specifically this is with .gdb layers on Windows - not sure yet if

> >> it's restricted to this combination).

> >>

> >> So just a heads up to test your existing projects before rolling out

> >> the 2.18.13 update.

> >

> > Failing unit test is here: https://github.com/qgis/QGIS/pull/5222,

> > regression bisected to https://github.com/qgis/QGIS/commit/8eaeaaa

> >

> > Sandro can you take a look at this?

>

> Argh.

>

> So the result of the subset query

>

> SELECT OBJECTID as orig_ogc_fid, * FROM "lines" WHERE "text" = 'shape 2'

>

> now is

>

> 305: OGR(1): OGR[3] error 1: Unrecognized field name OBJECTID.

> 305: OGR(1): Data source is invalid (Unrecognized field name OBJECTID.)

>

> but OBJECTID is what was returned by

>

> OGR_L_GetFIDColumn( layer )



Ah, that one is tricky. Let me try to explain the situation

Normally when you do ExecuteSQL(sql_statement, NULL, dialect) with 
dialect==NULL, OGR will forward sql_statement to the underlying SQL 
engine for a SQL compatible DBMS (Postgres, MySQL, SQLite, OCI, 
etc), and if there's no such engine, evaluate it with its own 
OGRSQL builtin engine.


For the FileGDB driver, the ESRI SDK has some SQL evaluation 
capability, but my testing showed that it was too limited to be 
reliable, so by default I fallback to OGRSQL.


You can force the use of the ESRI SQL engine by specifying a dialect 
== "FileGDB". If you do that with the above statement, you'll get


$ ogrinfo sampleFGDB_1.gdb -sql "select OBJECTID as foo, * FROM 
polygonArcsZM1" -dialect FileGDB -q


ERROR 1: Failed at executing 'select OBJECTID as foo, * FROM 
polygonArcsZM1' (An invalid SQL statement was used.)


So no better. Apparently, the ESRI SDK doesn't like selecting a column 
and "*".


So to come back to the bug, the SQL statement is evaluated with the 
OGRSQL engine. So this is a bug in it in the situation where the FID 
column name is an actual non-empty string. OGRSQL only understands 
"FID" as the shortcut for whatever the FID column name, and doesn't 
try to look if a column name matches OGR_L_GetFIDColumn() (when it was 
developped, all drivers that defaulted to OGRSQL had an implementation 
of OGR_L_GetFIDColumn() that returned a "" string). So this is a 
current shortcoming of the OGRSQL engine, that should probably be fixed


In the meantime you have to workaround it on the QGIS side, both for 
the "FileGDB" and "OpenFileGDB" drivers (. In that situation instead 
of using the result of OGR_L_GetFIDColumn() to build your SQL 
statement, hardcode FID.


So your statement will become:

SELECT FID as orig_ogc_fid, * FROM "lines" WHERE "text" = 'shape 2'

Actually when digging a bit more this could affect also the GeoJSON 
driver, but not in all situations. Only if you have a "id" member at 
the same level of "type": "Feature"


So something like

{ "type": "Feature", "id": 168, "properties": {...}, "geometry": {...} "

then id will be used as the FID and returned by OGR_L_GetFIDColumn()

And you'll hit the FileGDB bug

If you have something like

{ "type": "Feature", "properties": { "id": 168,...}, "geometry": {...} "

Then OGR_L_GetFIDColumn() will return "id" but you'll have also a 
regular id field, so "SELECT id as ogrig_ogc_fid, * FROM ..." will 
work then.






My (final!) suggestion is thus to first try:

SELECT {OGR_L_GetFIDColumn() or FID if it is empty} as orig_ogc_fid, * 
FROM


If that returns an error look for CPLGetLastErrorMsg() and if it 
contains OGR_L_GetFIDColumn() in it, retry with


SELECT FID as orig_ogc_fid, * FROM

Not pretty, but should be relatively robust




Thanks for the detailed explanation.

Does it actually hurt to try with FID regardless of the contents of 
CPLGetLastErrorMsg if the previous attempt failed, instead of relying on 
the contents of an error message?


PR is here:
https://github.com/qgis/QGIS/pull/5224


Sandro
___
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] OGR/GBD: Unrecognized field name OBJECTID (was: Re: Warning - possible project corruption in 2.18.13)

[Sandro Mani]

On 20.09.2017 08:45, Nyall Dawson wrote:


On 20 September 2017 at 10:18, Nyall Dawson  wrote:

Hi all,

I've just been trying to diagnose an issue with loading an existing
2.18 project in the new 2.18.13 release.

Seems like something may be broken here with regards to loading OGR
based layers which have a subset filter set.

These layers trigger the "missing layers" dialog when loading the
project and the layer link cannot be repaired without removing the
filter clause.

(specifically this is with .gdb layers on Windows - not sure yet if
it's restricted to this combination).

So just a heads up to test your existing projects before rolling out
the 2.18.13 update.

Failing unit test is here: https://github.com/qgis/QGIS/pull/5222,
regression bisected to https://github.com/qgis/QGIS/commit/8eaeaaa

Sandro can you take a look at this?

Argh.

So the result of the subset query

SELECT OBJECTID as orig_ogc_fid, * FROM "lines" WHERE "text" = 'shape 2'

now is

305: OGR(1): OGR[3] error 1: Unrecognized field name OBJECTID.
305: OGR(1): Data source is invalid (Unrecognized field name OBJECTID.)

but OBJECTID is what was returned by

OGR_L_GetFIDColumn( layer )

Even, any ideas?


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 11.07.2017 14:31, Even Rouault wrote:

We could potentially imagine to defer the repacking at 
leaveUpdateMode() time, actually in the close() method which is called 
when the reference counter of the update mode drops to zero (*), 
instead of doing it at the end of each operation.


To come back to this, I was looking at moving replack() to close(), but 
noticed that syncToDisc() has the logic "for shapefiles, remove spatial 
index files and create a new index" which calls close. And syncToDisk is 
still called after every change. So should syncToDisk be also moved to 
close(), or at least blocked if an updateMode is active?


Thanks
Sandro
___
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] OGR: sqlite with subset query, QgsOgrFeatureIterator::fetchFeature with SpatialFilterRect always returns feature with id 0

[Sandro Mani]

On 03.09.2017 23:50, Even Rouault wrote:


> Ok, so if we only do this for non-select queries, we should be safe?

Yes. I suspect the case where a full SELECT statement is used are 
rare, and people able to do that can tweak the request. It would be 
unreliable to try modifying it.


>

> > > Something like this [1] seems to fix the issue, don't know if 
it's the


> > >

> > > best way forward though?

> >

> > I've left a few comments in the commit

>

> Many thanks. I've pushed a revised version at [1].

I've added a couple suggestions for more robustness, but looks good to me.


Thanks, filed PR: https://github.com/qgis/QGIS/pull/5122

Sandro
___
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] OGR: sqlite with subset query, QgsOgrFeatureIterator::fetchFeature with SpatialFilterRect always returns feature with id 0

[Sandro Mani]

On 02.09.2017 23:34, Even Rouault wrote:


>

> Ok makes sense. Though as far as QGIS goes, is there a case where a

> subset query can result in duplicates?

Could happen. The code currently handles the possibility where 
subsetString() is called with a completely custom SELECT statement, so 
potentially doing crazy things.



Ok, so if we only do this for non-select queries, we should be safe?


>

> Something like this [1] seems to fix the issue, don't know if it's the

> best way forward though?

I've left a few comments in the commit

Many thanks. I've pushed a revised version at [1]. I'm in doubt whether 
it is really worth the hassle to hide the orig_ogr_fid column in the 
fields, together with the firstFieldIsFid it looks like it could make 
things very fragile... As far as I can tell, just the modifications in 
[1] without the extra logic should be pretty robust.


[1] 
https://github.com/manisandro/QGIS/commit/82a56eaa5a48a10a1a656657cefd84b619eae3f2


Sandro
___
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] OGR: sqlite with subset query, QgsOgrFeatureIterator::fetchFeature with SpatialFilterRect always returns feature with id 0

[Sandro Mani]

Hi Even


On 02.09.2017 21:49, Even Rouault wrote:


There's a flow in your reproducer. You run OGR_DS_ExecuteSQL( ds, 
subsetQuery, NULL, NULL ); but do not use the resulting result layer. 
So basically this has no effect on the rest of your code (except a 
memory leak).



Ah yes indeed!


[...]

The reason is that when issuing a SQL request there's no guarantee 
that it will result in a set of rows with unique identifiers (think of 
a join that could make several rows appear twice), so the FID on the 
result set of ExecuteSQL() are just a sequence starting at 0.


Ok makes sense. Though as far as QGIS goes, is there a case where a 
subset query can result in duplicates?


If you know that your request will result in a result set with real 
FIDs you can use the following trick to get the FID column as a 
regular column (renaming the ogc_fid as something else, since there's 
special logic to ignre "ogc_fid as a regular field. If your FID field 
name is already something else than this default "ogc_fid", then 
you'll already get it as a regular field)


$ ogrinfo poly.sqlite -sql "select ogc_fid as this_is_the_fid, * from 
poly where ogc_fid = 10"


INFO: Open of `poly.sqlite'

using driver `SQLite' successful.

Layer name: SELECT

Geometry: Unknown (any)

[...]

Geometry Column = GEOMETRY

this_is_the_fid: Integer (0.0)

area: Real (0.0)

eas_id: Integer64 (0.0)

prfedea: String (0.0)

OGRFeature(SELECT):0

this_is_the_fid (Integer) = 10

area (Real) = 5268.813

eas_id (Integer64) = 170

prfedea (String) = 35043413

POLYGON ((479750.6875 4764702.0,479658.59375 4764670.0,479640.09375 
4764721.0,479735.90625 4764752.0,479750.6875 4764702.0))


Something like this [1] seems to fix the issue, don't know if it's the 
best way forward though?


Thanks
Sandro

[1] 
https://github.com/manisandro/QGIS/commit/e95eea6dfa3e7ce7d0c0796352fa39943be80031


___
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] OGR: sqlite with subset query, QgsOgrFeatureIterator::fetchFeature with SpatialFilterRect always returns feature with id 0

[Sandro Mani]

Hi

I'm debugging an issue with a sqlite layer, loaded with a subset query, 
where the attribute values in the identify results table don't match the 
ones presented in the feature form (if auto show feature form is enabled).


Upon closer inspection, I noticed that the feature id of the feature 
picked by the feature info tool is always 0 (though it's remaining 
attributes are correct), this leads to the feature form displaying the 
attributes of feature fid=0, hence the mistmatch.


Stepping through the featureRequest performed by the identify tool shows 
that indeed OGR_F_GetFID( fet ) in QgsOgrFeatureIterator::readFeature 
always returns zero.


To isolate the problem, I created a small standalone program which 
replicates what the feature iterator does as a result of the identify 
query (see below), the odd thing is that there it works, and the fid is 
the expected one.


Is there some other global logic implemented in the ogr provider which 
could cause this behaviour?


Thanks
Sandro

--

  const char layerName[] = "S2Q_N_K_BW_F_HAUPT_F";
  const char filePath[] = "test.sqlite";
  const char subsetQuery[] = "SELECT * FROM \"s2q_n_k_bw_f_haupt_f\" 
WHERE \"OBJECTTYPE\"=6901";


  double xmin = 493070.74903165392;
  double xmax = 493071.83368281781;
  double ymin = 5763998.7917103767;
  double ymax = 5763997.707059212;

  // Specific to test.sqlite
  int fieldCount = 41;
  bool firstAttrIsFid = false;
  std::vector fetchAttributes;
  for(int i = 0; i < fieldCount; ++i) {
    fetchAttributes.push_back(i);
  }

  OGRDataSourceH ds = OGROpen( filePath, FALSE, NULL );
  OGRLayerH ogrLayer = OGR_DS_GetLayerByName( ds, layerName );

  OGR_DS_ExecuteSQL( ds, subsetQuery, NULL, NULL );


  if ( OGR_L_TestCapability( ogrLayer, OLCIgnoreFields ) )
  {
    std::vector ignoredFields;
    OGRFeatureDefnH featDefn = OGR_L_GetLayerDefn( ogrLayer );
    for ( int i = ( firstAttrIsFid ? 1 : 0 ); i < fieldCount; i++ )
    {
  if ( std::find(fetchAttributes.begin(), fetchAttributes.end(), i) 
== fetchAttributes.end() )

  {
    // add to ignored fields
    ignoredFields.push_back( OGR_Fld_GetNameRef( 
OGR_FD_GetFieldDefn( featDefn, firstAttrIsFid ? i - 1 : i ) ) );

  }
    }

    ignoredFields.push_back( "OGR_STYLE" ); // not used by QGIS
    ignoredFields.push_back( nullptr );

    OGR_L_SetIgnoredFields( ogrLayer, ignoredFields.data() );
  }

  OGR_L_SetSpatialFilterRect( ogrLayer, xmin, ymin, xmax, ymax );

  OGR_L_SetAttributeFilter( ogrLayer, nullptr );

  OGR_L_ResetReading( ogrLayer );

  OGRFeatureH fet;
  while ( ( fet = OGR_L_GetNextFeature( ogrLayer ) ) ) {
    fprintf(stdout, "FID: %lld\n", OGR_F_GetFID( fet ));
    OGR_F_Destroy( fet );
  }

  OGR_DS_Destroy( ds );

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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 14.07.2017 00:01, Martin Dobias wrote:

Hi Sandro

On Wed, Jul 12, 2017 at 11:15 AM, Sandro Mani  wrote:

The problem is that if one of the changes to be committed is refused by the
provider, you're stuck not being able to commit the entire set of changes.
And, since we are dealing with invalid geometries, it is not that unlikely
that this occurs. Committing directly to the provider ensures that we know
immediately whether a change is valid or not.

Out of curiosity, which providers tend to refuse features? I thought
that most providers will be happy to commit also invalid geometries
given that they do not mind storing them. Are geometries refused only
if they are invalid or are there also other related issues? Maybe it
would help if we did not allow users to commit invalid geometries? (or
only with big red warning that they should expect havoc, possibly end
of the world)
A typical example are attribute collisions when columns are marked as 
unique (and some geometry checker methods fix errors by merging features 
geometries and combining attributes via some scheme, and combining 
attributes does not always end up well).
I can't remember if I also encountered cases where commits were refused 
because of the actual geometry being invalid.


That said, as mentioned elsewhere in the thread, having the edit mode 
inbetween causes headaches because the user can interfere by manually 
changing geometries and the plugin loses track of what's going on.


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 12.07.2017 11:41, Luigi Pirelli wrote:

why not add the feature to a more detailed notification of what is
wrong during commitChanges? Like point out a more detailed report of
the failing feature/attribute/geometry? it would just a new signal and
EditBuffer cache.


Uhm but that would still mean the changeset cannot be committed.

And as a side-note, the edit-buffer inbetween brings a number of 
challenges like:

- The user manually exiting the edit mode while the plugin is working
- The user changing something outside the control of the plugin. The 
plugin is fairly complex in that it updates all other errors based on 
the outcome of a fix - say, if you delete a duplicate node, it may have 
an effect of the vertex id used to describe a "minimal angle" error. 
Updating the errors works well as long as the plugin knows exactly what 
is going on, but if the user starts fiddling inbetween, it gets a real 
proper nightmare to track and handle all changes. Indeed, currently the 
plugin sets the layers to non-editable while it is working so that, 
short of removing the layer from the project, there is not much the user 
can do to interfere with the logic of the plugin.


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 12.07.2017 01:06, Nyall Dawson wrote:

Thanks for the insight, I'll look at that approach.

Sandro

I might have missed this in the earlier conversation, but why not
explore the option suggest of using the layer's edit buffer? I believe
this should automatically handle all the reassignment without any
changes needed (except flipping the direct dataProvider use to the
editBuffer).

Possibly it's nicer for users anyway if the fixes made by the plugin
are buffered and undo-able.
The problem is that if one of the changes to be committed is refused by 
the provider, you're stuck not being able to commit the entire set of 
changes. And, since we are dealing with invalid geometries, it is not 
that unlikely that this occurs. Committing directly to the provider 
ensures that we know immediately whether a change is valid or not.


Sandro

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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 11.07.2017 14:31, Even Rouault wrote:


On mardi 11 juillet 2017 14:00:28 CEST Sandro Mani wrote:

> On 10.07.2017 13:58, Even Rouault wrote:

> > > I did some playing around and came up with some FeatureId 
mapping code


> > >

> > > which is pretty space efficient (basically requiring just

> > >

> > > 3*nDeletedFeatures entries), see below.

> > >

> > >

> > >

> > > The code however assumes that the gaps in the fid-sequence are 
filled by


> > >

> > > decreasing the fids after the gap, which may be pretty specific 
to the


> > >

> > > OGR/Shapefile behaviour.

> >

> > This should clearly be restricted to Shapefiles. Other drivers don't

> > have this compaction logic and will let happily holes in the 
feature ids.


> >

> > > Hence in my view such code should really belong

> > >

> > > into the OGR provider (or perhaps even ogr itself) and not in the

> > >

> > > plugin. Thoughts?

> >

> > Regarding putting that in OGR itself, there's no such API for that

> > right now, and I'm not completely clear of the value to add one

> > (specific use case, for a single driver)

> >

> > Perhaps the QGIS OGR provider would be a better place for now.

>

> So that kinda works, but repacking still causes dreadful performance

> (say after fixing a couple of hundred "minimal area" errors, which

> results in the small features getting deleted, the shapefile is repacked

> after every delete).

>

> So I'd really need a way to freeze repacking, even just for the timespan

> the plugin is busy fixing the errors. Unless there are some better

> ideas, I'll look at adding corresponding methods. A cool name would be

> beginTransaction/endTransaction which is kinda generic and could make

> sense for other providers as well, but unfortunately it collides with

> the existing transaction logic (QgsTransaction) which is about

> multi-layer transaction groups...

As you venture into the OGR provider, you'll see related things :

- there's an internal to the OGR provider startTransaction() / 
commitTransaction() that is used only for SQL based drivers, and in 
the scope of a single operation like addFeatures() / deleteFeatures() /..


- there's a enterUpdateMode() / leaveUpdateMode() pair respectively 
called by QgsVectorLayer::startEditing() / 
QgsVectorLayer::commitChanges(). The purpose of that is to 
respectively re-open a read-only file as read-write, and re-open it 
from read-write back to read-only. This is for scenarios involving 
QGIS with other GIS open at the same time on th same file: if QGIS 
opens it in read-write mode, that prevents the other software from 
opening it (was initially for MapInfo).


We could potentially imagine to defer the repacking at 
leaveUpdateMode() time, actually in the close() method which is called 
when the reference counter of the update mode drops to zero (*), 
instead of doing it at the end of each operation.



Thanks for the insight, I'll look at that approach.

Sandro

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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 10.07.2017 13:58, Even Rouault wrote:


> I did some playing around and came up with some FeatureId mapping code

> which is pretty space efficient (basically requiring just

> 3*nDeletedFeatures entries), see below.

>

> The code however assumes that the gaps in the fid-sequence are filled by

> decreasing the fids after the gap, which may be pretty specific to the

> OGR/Shapefile behaviour.

This should clearly be restricted to Shapefiles. Other drivers don't 
have this compaction logic and will let happily holes in the feature ids.


> Hence in my view such code should really belong

> into the OGR provider (or perhaps even ogr itself) and not in the

> plugin. Thoughts?

Regarding putting that in OGR itself, there's no such API for that 
right now, and I'm not completely clear of the value to add one 
(specific use case, for a single driver)


Perhaps the QGIS OGR provider would be a better place for now.

So that kinda works, but repacking still causes dreadful performance 
(say after fixing a couple of hundred "minimal area" errors, which 
results in the small features getting deleted, the shapefile is repacked 
after every delete).


So I'd really need a way to freeze repacking, even just for the timespan 
the plugin is busy fixing the errors. Unless there are some better 
ideas, I'll look at adding corresponding methods. A cool name would be 
beginTransaction/endTransaction which is kinda generic and could make 
sense for other providers as well, but unfortunately it collides with 
the existing transaction logic (QgsTransaction) which is about 
multi-layer transaction groups...



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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 06.07.2017 11:00, Sandro Mani wrote:



On 06.07.2017 10:57, Even Rouault wrote:


On jeudi 6 juillet 2017 10:45:21 CEST Sandro Mani wrote:

> On 05.07.2017 14:56, Sandro Mani wrote:

> >> That could potentially be done using the current OGR API. Basically

> >> in pseudo code, to execute before executing REPACK

> >>

> >> OGR_L_ResetReading(layer)

> >>

> >> char** ignored_fields = CSLAddString(NULL, "OGR_GEOMETRY" );

> >>

> >> OGR_L_SetIgnoredFields( layer, ignored_fields); // for performance.

> >>

> >> CSLDestroy(ignored_fields);

> >>

> >> OGR_L_SetAttributeFilter( layer, NULL )

> >>

> >> OGR_L_SetSpatialFilter( layer, NULL )

> >>

> >> std::map mapOldIdToNewId;

> >>

> >> GIntBig newId = 0;

> >>

> >> while( feature = OGR_L_GetNextFeature(layer) )

> >>

> >> {

> >>

> >> mapOldIdToNewId[OGR_F_GetFID(feature)] = newId;

> >>

> >> newId ++;

> >>

> >> OGR_F_destroy(feature);

> >>

> >> }

> >>

> >> OGR_L_SetIgnoredFields( layer, NULL );

> >

> > Ok cool, that sounds like a plan - I'll give it a shot.

>

> Hmm so while on the provider side it works well, for the geometry

> checker it is turning out to be pretty hard to deal with the changing

> feature ids (just to cite one example: error fixed by merging geometry

> of feature 10 with that of 11, results in {deleted: 10, updated: 11},

> but after the feature id adjustment this would read {deleted: 10,

> updated: 10}, meaning one would need to keep track that deleted: 10

> refers to the old featureid). Not saying that it isn't doable, but the

> complexitiy of properly handling the feature id changes is non-trivial.

>

> So, other suggestion: any objections if I add a method to

> QgsVectorDataProvider to temporarily freeze repacking? I could also add

> a notification informing the user that the shapefile should not be used

> in other applications while repacking is frozen.

My feeling is that QgsOgrDataProvider is already complicated enough 
with its existing tricks. I'm not sure this temporary freeze 
repacking is a right move (how would you decide when you do it ? and 
I'm pretty sure users will not get it, or will have issues if they 
start an algorithm with an external tool that requires packed shapefiles)


It would be something I would call explicitly while the geometry 
checker is active, I think it is safe to assume that users don't 
expect that they can operate on the shapefile while the geometry 
checker is processing it.  It would not add much complexity to the 
provider, just a flag that repacking is frozen, and a setter to set 
that flag. When the flag is set to false, the shapefile is repacked.


I did some playing around and came up with some FeatureId mapping code 
which is pretty space efficient (basically requiring just 
3*nDeletedFeatures entries), see below.


The code however assumes that the gaps in the fid-sequence are filled by 
decreasing the fids after the gap, which may be pretty specific to the 
OGR/Shapefile behaviour. Hence in my view such code should really belong 
into the OGR provider (or perhaps even ogr itself) and not in the 
plugin. Thoughts?


Sandro

---

#include 
#include 
#include 
#include 

typedef int QgsFeatureId;


class FeatureMapping  {

public:
  QgsFeatureId stableToProvider(QgsFeatureId stableId) const
  {
if(mDeletedStableIds.contains(stableId)){
  return -1;
}
// providerId = stableId - nDeletedBeforeStableId
int nDeletedBeforeStableId = std::lower_bound(mDeletedStableIds.begin(), 
mDeletedStableIds.end(), stableId) - mDeletedStableIds.begin();
return stableId - nDeletedBeforeStableId;
  }

  QgsFeatureId providerToStable(QgsFeatureId providerId) const
  {
int i = 0, n = mProviderToStableOffsetKeys.size(), offset = 0;
while(i < n && mProviderToStableOffsetKeys[i] <= providerId) {
  offset += mProviderToStableOffsetValues[i++];
}
return providerId + offset;
  }

  void updateFeatureIdMap(const QList &deletedIds)
  {
for(QgsFeatureId fid : deletedIds) {
  mDeletedStableIds.append(providerToStable(fid));
}
std::sort(mDeletedStableIds.begin(), mDeletedStableIds.end());
int n = mProviderToStableOffsetKeys.size();
for(QgsFeatureId fid : deletedIds) {
  int pos = std::lower_bound(mProviderToStableOffsetKeys.begin(), 
mProviderToStableOffsetKeys.end(), fid) - mProviderToStableOffsetKeys.begin();
  if(pos < n && mProviderToStableOffsetKeys[pos] == fid) {
mProviderToStableOffsetValues[pos] += 1;
  } else {
mProviderToStableOffsetKeys.insert(

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 06.07.2017 11:38, Martin Dobias wrote:

Hi Sandro

On Thu, Jul 6, 2017 at 11:00 AM, Sandro Mani  wrote:

It would be something I would call explicitly while the geometry checker is
active, I think it is safe to assume that users don't expect that they can
operate on the shapefile while the geometry checker is processing it.  It
would not add much complexity to the provider, just a flag that repacking is
frozen, and a setter to set that flag. When the flag is set to false, the
shapefile is repacked.

How about changing the logic in geometry checker? Instead of saving
changes any time user chooses an action, one could just keep a buffer
of changes and then commit everything at once when the user is done
fixing things... That would be also more efficient and it seems like
an easier solution than adding workarounds to data provider interface
for one particular format.
As mentioned before, the problem is that if one of the changes to be 
committed is refused by the provider, you're stuck not being able to 
commit the entire set of changes. And, since we are dealing with invalid 
geometries, it is not that unlikely that this occurs. Committing 
directly to the provider ensures that we know immediately whether a 
change is valid or not.


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 06.07.2017 10:57, Even Rouault wrote:


On jeudi 6 juillet 2017 10:45:21 CEST Sandro Mani wrote:

> On 05.07.2017 14:56, Sandro Mani wrote:

> >> That could potentially be done using the current OGR API. Basically

> >> in pseudo code, to execute before executing REPACK

> >>

> >> OGR_L_ResetReading(layer)

> >>

> >> char** ignored_fields = CSLAddString(NULL, "OGR_GEOMETRY" );

> >>

> >> OGR_L_SetIgnoredFields( layer, ignored_fields); // for performance.

> >>

> >> CSLDestroy(ignored_fields);

> >>

> >> OGR_L_SetAttributeFilter( layer, NULL )

> >>

> >> OGR_L_SetSpatialFilter( layer, NULL )

> >>

> >> std::map mapOldIdToNewId;

> >>

> >> GIntBig newId = 0;

> >>

> >> while( feature = OGR_L_GetNextFeature(layer) )

> >>

> >> {

> >>

> >> mapOldIdToNewId[OGR_F_GetFID(feature)] = newId;

> >>

> >> newId ++;

> >>

> >> OGR_F_destroy(feature);

> >>

> >> }

> >>

> >> OGR_L_SetIgnoredFields( layer, NULL );

> >

> > Ok cool, that sounds like a plan - I'll give it a shot.

>

> Hmm so while on the provider side it works well, for the geometry

> checker it is turning out to be pretty hard to deal with the changing

> feature ids (just to cite one example: error fixed by merging geometry

> of feature 10 with that of 11, results in {deleted: 10, updated: 11},

> but after the feature id adjustment this would read {deleted: 10,

> updated: 10}, meaning one would need to keep track that deleted: 10

> refers to the old featureid). Not saying that it isn't doable, but the

> complexitiy of properly handling the feature id changes is non-trivial.

>

> So, other suggestion: any objections if I add a method to

> QgsVectorDataProvider to temporarily freeze repacking? I could also add

> a notification informing the user that the shapefile should not be used

> in other applications while repacking is frozen.

My feeling is that QgsOgrDataProvider is already complicated enough 
with its existing tricks. I'm not sure this temporary freeze repacking 
is a right move (how would you decide when you do it ? and I'm pretty 
sure users will not get it, or will have issues if they start an 
algorithm with an external tool that requires packed shapefiles)


It would be something I would call explicitly while the geometry checker 
is active, I think it is safe to assume that users don't expect that 
they can operate on the shapefile while the geometry checker is 
processing it.  It would not add much complexity to the provider, just a 
flag that repacking is frozen, and a setter to set that flag. When the 
flag is set to false, the shapefile is repacked.


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 05.07.2017 14:56, Sandro Mani wrote:


That could potentially be done using the current OGR API. Basically 
in pseudo code, to execute before executing REPACK


OGR_L_ResetReading(layer)

char** ignored_fields = CSLAddString(NULL, "OGR_GEOMETRY" );

OGR_L_SetIgnoredFields( layer, ignored_fields); // for performance.

CSLDestroy(ignored_fields);

OGR_L_SetAttributeFilter( layer, NULL )

OGR_L_SetSpatialFilter( layer, NULL )

std::map mapOldIdToNewId;

GIntBig newId = 0;

while( feature = OGR_L_GetNextFeature(layer) )

{

mapOldIdToNewId[OGR_F_GetFID(feature)] = newId;

newId ++;

OGR_F_destroy(feature);

}

OGR_L_SetIgnoredFields( layer, NULL );


Ok cool, that sounds like a plan - I'll give it a shot.

Hmm so while on the provider side it works well, for the geometry 
checker it is turning out to be pretty hard to deal with the changing 
feature ids (just to cite one example: error fixed by merging geometry 
of feature 10 with that of 11, results in {deleted: 10, updated: 11}, 
but after the feature id adjustment this would read {deleted: 10, 
updated: 10}, meaning one would need to keep track that deleted: 10 
refers to the old featureid). Not saying that it isn't doable, but the 
complexitiy of properly handling the feature id changes is non-trivial.


So, other suggestion: any objections if I add a method to 
QgsVectorDataProvider to temporarily freeze repacking? I could also add 
a notification informing the user that the shapefile should not be used 
in other applications while repacking is frozen.


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 05.07.2017 12:18, Even Rouault wrote:


On mercredi 5 juillet 2017 12:04:04 CEST Sandro Mani wrote:

> On 05.07.2017 11:30, Even Rouault wrote:

> > My feeling is that, for good or worse, they are definitely people

> > wanting to have QGIS and "put here the name of your favorite

> > proprietary GIS software" running at the same time, and possibly on

> > the same datasets. This is apparently important in migration scenarios

> > where people aren't ready yet to jump completely to QGIS. That said,

> > this is also tricky to do in a reliable way.

>

> Could ogr expose oldId -> newId information which the qgsogrprovider

> would then emit as a signal when the layer is repacked? I don't mean a

> persistent mapping, but just for the single repack operation.

That could potentially be done using the current OGR API. Basically in 
pseudo code, to execute before executing REPACK


OGR_L_ResetReading(layer)

char** ignored_fields = CSLAddString(NULL, "OGR_GEOMETRY" );

OGR_L_SetIgnoredFields( layer, ignored_fields); // for performance.

CSLDestroy(ignored_fields);

OGR_L_SetAttributeFilter( layer, NULL )

OGR_L_SetSpatialFilter( layer, NULL )

std::map mapOldIdToNewId;

GIntBig newId = 0;

while( feature = OGR_L_GetNextFeature(layer) )

{

mapOldIdToNewId[OGR_F_GetFID(feature)] = newId;

newId ++;

OGR_F_destroy(feature);

}

OGR_L_SetIgnoredFields( layer, NULL );


Ok cool, that sounds like a plan - I'll give it a shot.

Thanks
Sandro

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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 05.07.2017 11:30, Even Rouault wrote:


My feeling is that, for good or worse, they are definitely people 
wanting to have QGIS and "put here the name of your favorite 
proprietary GIS software" running at the same time, and possibly on 
the same datasets. This is apparently important in migration scenarios 
where people aren't ready yet to jump completely to QGIS. That said, 
this is also tricky to do in a reliable way.


Could ogr expose oldId -> newId information which the qgsogrprovider 
would then emit as a signal when the layer is repacked? I don't mean a 
persistent mapping, but just for the single repack operation.


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 05.07.2017 08:51, Giovanni Manghi wrote:


as far as I remember this is not entirely true: if you go on redmine
and look for the (sometimes very long) tickets about this very big
issue at that time (now thankfully), is wasn't necessary to have the
shapefile open in edit mode two applications to leave it in a
"inconsistent" state, if was really just QGIS. After edits and after
saving (and removing it from the project) opening it in another gis
package frequently shown (for example) features that were deleted and
messages about the inconsistent state of the vector.

please do not revert to the previous, wrong, way to do.
I don't think the talk is about reverting, but rather about holding off 
repacking the layer until it is removed from QGIS, meaning that you can 
hit the inconsistent state issues as long as the layer is open in QGIS 
(and the question is whether this particular scenario should be 
supported), but as soon as the layer is removed from QGIS, it is 
repacked and the layer left in a consistent state.


Sandro


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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 04.07.2017 18:46, Even Rouault wrote:

Another solution would be to defere the compaction only at layer 
closing (that's actually the new behaviour of the OGR Shapefile driver 
in recent GDAL versions to force a repack at closing). I'm not sure 
why QGIS currently repacks it every time ?



That would be a nice solution!

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

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

Hi Even

Thanks for the reply. Yes I am indeed testing with shapefiles.

Not sure why I never observed this behaviour previously, but indeed I 
have up to now never observed this myself, nor have received bug reports 
concerned with this kind breakage - and this is a pretty hard to miss 
issue since the plugin will essentially behave randomly.


In any event, so I suppose other than manually introducing a UUID 
attribute to the features and identifying them by a attribute filter 
expression, there is no way to reliably identify a feature over the 
lifetime of the layer being loaded in QGIS?


I'm kinda inclined to think that I'm not the only one relying on feature 
ids to identify features?


Sandro

On 04.07.2017 17:36, Even Rouault wrote:


Sandro,

I guess this might depend on the actual OGR driver used. Somehow I 
assume you use shapefiles here ?


This is probably linked to shapefiles being repacked after the end of 
various operations


such as addFeatures(), changeGeometryValues(), deleteFeatures(), so as 
to avoid issues


with other software that don't like holes in SHP and DBF files.

There have been changes in that area to rebustify shapefile 
recompaction that used


to work not so well on Windows (although most of them were in OGR itself),

but my understanding of

https://github.com/qgis/QGIS/blob/release-2_12/src/providers/ogr/qgsogrprovider.cpp

is that even in 2.12, feature deletion should cause a repack of the 
shapefile, so


I'm not sure why the issue would be new

Even

> Hi

>

> I'm doing work on the geometry checker in QGIS master and noticed that,

> when deleting features from an ogr vector layer, FeatureIds appear to be

> reassigned to fill up the gap in the ids. This is a pretty serious

> blocker for the geometry checker since geometry checker errors are

> identified by the feature id (and other parameters). So if the

> FeatureIds change, the geometry checker errors may suddenly reference

> the wrong feature, causing general mayhem.

>

> Can anyone confirm that indeed FeatureIds are being purposefully

> reassigned, and whether there is a rationale behind this change (I never

> observed this before in QGIS 2.x)? And if so, what other options exist

> to reliably reference a feature over the entire lifetime of the layer

> being loaded in QGIS?

>

> Note that in the geometry checker, I don't use the edit buffer, but

> write each change directly to the data provider. This to avoid that

> situations where, after fixing multiple errors, the final result cannot

> be committed due to a particular geometry still being invalid and the

> provider refusing to accept the change.

>

> Thanks

> Sandro

>

> ___

> 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

--

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] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

Hi

I'm doing work on the geometry checker in QGIS master and noticed that, 
when deleting features from an ogr vector layer, FeatureIds appear to be 
reassigned to fill up the gap in the ids. This is a pretty serious 
blocker for the geometry checker since geometry checker errors are 
identified by the feature id (and other parameters). So if the 
FeatureIds change, the geometry checker errors may suddenly reference 
the wrong feature, causing general mayhem.


Can anyone confirm that indeed FeatureIds are being purposefully 
reassigned, and whether there is a rationale behind this change (I never 
observed this before in QGIS 2.x)? And if so, what other options exist 
to reliably reference a feature over the entire lifetime of the layer 
being loaded in QGIS?


Note that in the geometry checker, I don't use the edit buffer, but 
write each change directly to the data provider. This to avoid that 
situations where, after fixing multiple errors, the final result cannot 
be committed due to a particular geometry still being invalid and the 
provider refusing to accept the change.


Thanks
Sandro

___
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] Abstract GUI base class

[Sandro Mani]

Hi Matthias

Personally I think it's okay to force custom apps to adapt to the app 
library changes, the effort of doing so is way smaller than having to 
port the app abstraction from release to release.


As for where the line is drawn: this proposal would mean one can go as 
far as swap the main QMainWindow with a custom implementation. I don't 
know if it makes sense drawing the line at another level?


As for QQgisInterface re-implementation: I'm not sure I see how one 
could swap out the main window with that approach, besides hiding the 
"classic" app main window constructed in main.cpp and killing of any 
signals that may interact with it - am I missing something?


Best
Sandro



On 06.10.2016 16:02, Matthias Kuhn wrote:

Hi Sandro,

This sounds interesting.
What I wonder mostly is how much of the design and concept should be
imposed on customized apps. This forces either

  * custom apps to adjust to api changes in the app libarary
  * the app library to guarantee api stability

Not having to care for api stability in the app library currently allows
for much flexibility and speed in development.

Something else is where the line between "custom" and "generic" is
drawn. QField (or roam which I don't know very well) are also custom
interfaces. I guess each one of these will draw their line at a
different level. For QField for example, anything that involves things
from the QtWidgets library is out of scope.

Another approach would be to reimplement the QgisInterface instead of
the app. This specifically documents to be meant for 3rd party apps to
be reimplemented.
https://github.com/sourcepole/kadas-albireo/blob/master/src/gui/qgisinterface.h#L58-L62

Could you potentially split this up into multiple levels of
abstractions? Telling plugin developers that they can only use
functionality from the QgisTinyInterface if they want to be compatible
with everyone or use the QgisFullBlastInterface if it should be
fine-tuned for the QGIS classic app?

If it helps to improve the channel from your developments back to
upstream, that will be much appreciated.

All the best
Matthias

On 10/06/2016 02:50 PM, Sandro Mani wrote:

Hi

We are considering porting our abstract GUI class from KADAS Albireo to
QGIS 3.0, basically what was done here [1][2]. Summary is that qgisapp
contains all functionalities which are gui-logic independent and
qgsclassicapp contains the logic tying functionalities to the gui
implementation.

The advantages of this are, besides better code separation (which IMO
qgisapp could benefit from since it's become a bit of a dumping ground),
that it easier for people to write custom guis for QGIS (i.e. very
application specific GUIs exposing only certain functionalities etc)
while sharing the codebase with upstream.

QGIS 3.0 would be a good moment to perform such refactoring. So I'd like
to hear a short feedback whether people would welcome such a change in
principle before moving on to drafting a QEP.

Thanks
Sandro

[1]
https://github.com/sourcepole/kadas-albireo/blob/master/src/app/qgisapp.h
[2]
https://github.com/sourcepole/kadas-albireo/blob/master/src/app/qgsclassicapp.h


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Abstract GUI base class

[Sandro Mani]

Hi

We are considering porting our abstract GUI class from KADAS Albireo to 
QGIS 3.0, basically what was done here [1][2]. Summary is that qgisapp 
contains all functionalities which are gui-logic independent and 
qgsclassicapp contains the logic tying functionalities to the gui 
implementation.


The advantages of this are, besides better code separation (which IMO 
qgisapp could benefit from since it's become a bit of a dumping ground), 
that it easier for people to write custom guis for QGIS (i.e. very 
application specific GUIs exposing only certain functionalities etc) 
while sharing the codebase with upstream.


QGIS 3.0 would be a good moment to perform such refactoring. So I'd like 
to hear a short feedback whether people would welcome such a change in 
principle before moving on to drafting a QEP.


Thanks
Sandro

[1] 
https://github.com/sourcepole/kadas-albireo/blob/master/src/app/qgisapp.h
[2] 
https://github.com/sourcepole/kadas-albireo/blob/master/src/app/qgsclassicapp.h


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Issue with Python on Fedora

[Sandro Mani]

Well in theory one could introduce some heuristics based on /usr/lib64 
existence and /etc/os-release parsing, but I don't think it's worth the 
fuss to cover all possible distro configurations honestly (and I've 
never seen a software package which does this).


Sandro


On 05.10.2016 10:26, Denis Rouzaud wrote:


Perfect, thanks a lot, it works!

Is there a way to integrate this automatically in cmake config? Like 
detecting fedora?


Cheers,

Denis


On 10/05/2016 09:59 AM, Sandro Mani wrote:


Hi Denis

You can adjust the lib install dir when configuring cmake by specifying

|-DQGIS_LIB_SUBDIR=lib64 And yes, on Fedora /usr/lib is for 32bit 
libs, /usr/lib64 for 64bit libs. Sandro |




On 05.10.2016 09:49, Denis Rouzaud wrote:


Hi all,

Thanks a lot to Tudor, Sandro and Richard for your input.

To solve the issue, I had to do
export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH

This seems a bit strange to me, shouldn't /usr/lib be automaticaly used?

Does this means that installation somehow fails to place the lib in 
the proper place? /usr/lib64?


Cheers,

Denis

On 10/04/2016 02:18 PM, Richard Duivenvoorde wrote:

On 04-10-16 10:15, Denis Rouzaud wrote:

Hi all,

I have an issue with Python on Fedora.

After installing from a new clean clone and fresh build dir, if I do

  PYTHONPATH=$PYTHONPATH:/usr/share/qgis/python python -m qgis.PyQt.uic.pyuic

I get

/usr/bin/python: libqgis_core.so.2.17.0: cannot open shared object file:
No such file or directory

Although the lib is indeed in /usr/lib.

Also, if I run qgis from the build output and do
 From qgis.PyQt.uic import pyuic it crashes without any backtrace.

I don't know what to look for.
There are some issues on the hub, but I cannot find the connection with
this one.

Hi Denis,

should you not also set LD_LIBRARY_PATH? It looks like something is not
picking up your fresh lib files?

I compile/install myself in a custom dir, and have to set this both for
running QGIS or to run pyqgis stuff

export LD_LIBRARY_PATH=/home/richard/apps/qgis/master/debug/lib/

I also have another 'set environment' script, that set's the

export QGIS_PREFIX_PATH=/home/richard/apps/qgis/master/debug

maybe try that? Not sure what really is picked up to be honest.

Regards,

Richard Duivenvoorde






___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer




___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer




___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Issue with Python on Fedora

[Sandro Mani]

Hi Denis

You can adjust the lib install dir when configuring cmake by specifying

|-DQGIS_LIB_SUBDIR=lib64 And yes, on Fedora /usr/lib is for 32bit libs, 
/usr/lib64 for 64bit libs. Sandro |




On 05.10.2016 09:49, Denis Rouzaud wrote:


Hi all,

Thanks a lot to Tudor, Sandro and Richard for your input.

To solve the issue, I had to do
export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH

This seems a bit strange to me, shouldn't /usr/lib be automaticaly used?

Does this means that installation somehow fails to place the lib in 
the proper place? /usr/lib64?


Cheers,

Denis

On 10/04/2016 02:18 PM, Richard Duivenvoorde wrote:

On 04-10-16 10:15, Denis Rouzaud wrote:

Hi all,

I have an issue with Python on Fedora.

After installing from a new clean clone and fresh build dir, if I do

  PYTHONPATH=$PYTHONPATH:/usr/share/qgis/python python -m qgis.PyQt.uic.pyuic

I get

/usr/bin/python: libqgis_core.so.2.17.0: cannot open shared object file:
No such file or directory

Although the lib is indeed in /usr/lib.

Also, if I run qgis from the build output and do
 From qgis.PyQt.uic import pyuic it crashes without any backtrace.

I don't know what to look for.
There are some issues on the hub, but I cannot find the connection with
this one.

Hi Denis,

should you not also set LD_LIBRARY_PATH? It looks like something is not
picking up your fresh lib files?

I compile/install myself in a custom dir, and have to set this both for
running QGIS or to run pyqgis stuff

export LD_LIBRARY_PATH=/home/richard/apps/qgis/master/debug/lib/

I also have another 'set environment' script, that set's the

export QGIS_PREFIX_PATH=/home/richard/apps/qgis/master/debug

maybe try that? Not sure what really is picked up to be honest.

Regards,

Richard Duivenvoorde






___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Issue with Python on Fedora

[Sandro Mani]

Hi Denis

If you are on 64bits Fedora, the libs are probably searched for in 
/usr/lib64.


You can run python through strace to check where it is looking for the 
libraries, i.e.


PYTHONPATH=$PYTHONPATH:/usr/share/qgis/python strace python -m 
qgis.PyQt.uic.pyuic


and then just look at which open syscalls are trying to open 
libqgis_core and where.



Hope this helps
Sandro


On 04.10.2016 10:15, Denis Rouzaud wrote:

Hi all,

I have an issue with Python on Fedora.

After installing from a new clean clone and fresh build dir, if I do

 PYTHONPATH=$PYTHONPATH:/usr/share/qgis/python python -m 
qgis.PyQt.uic.pyuic


I get

/usr/bin/python: libqgis_core.so.2.17.0: cannot open shared object 
file: No such file or directory


Although the lib is indeed in /usr/lib.

Also, if I run qgis from the build output and do
From qgis.PyQt.uic import pyuic it crashes without any backtrace.

I don't know what to look for.
There are some issues on the hub, but I cannot find the connection 
with this one.


If anyone has a hint, thanks a lot.

Denis


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of the Globe plugin in QGIS 3 with Qt5

[Sandro Mani]

On 29.09.2016 08:36, Sebastiaan Couwenberg wrote:

On 09/28/2016 02:28 PM, Sandro Mani wrote:

I've had a look recently at adding osgEarth 2.8 support (and produced a
tentative patch [1]), however the rendering is completely broken. I've
not had time to investigate yet, but it looks like osgEarth2.8 puts a
hard minimum requirement on GLSL 3.30, i.e. debug log output:

FRAGMENT glCompileShader "main(fragment)" FAILED
FRAGMENT Shader "main(fragment)" infolog:
0:1(10): error: the compatibility profile is not supported
0:1(10): error: GLSL 3.30 is not supported. Supported versions are:
1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

This makes me uncomfortable: I'm pretty sure many users running somewhat
older distros or older hardware will hit this. So upgrading to osgEarth
2.8 just for the sake of upgrading and braking the globe for many user
is in my view not the best of plans.

To me that just sounds like a normal price for progress.

Not really agreeing on this.



Technically nothing speaks against building osgEarth2.7 against Qt5 (for
clarity: osgEarth 2.7 supports Qt5 alread) and keeping that version
packaged for the forseable future.

Alternatively, distros wanting to upgrade could keep osgEarth 2.7
packaged as osgEarth27 and renaming library names (i.e. libosgEarthXXX
-> libosgEarth27XXX) and the header dirs. Up to this point it would be
fairly easy, the problem comes with osgPlugins - I'm not sure if it is
possible to install multiple versions simultaneously in
/usr/lib64/osgPlugins-3.4.0/ or similar.

Unless someone volunteers to maintain a separate source package for
osgEarth 2.7 in Debian, only a single version will be in Debian (the
latest). Unlike the OpenSceneGraph maintainers I'm not willing to
maintain two co-installable osgEarth versions in a stable release.

Then I suggest you use osgEarth28.patch and deal with the consequences.



Happy to hear other suggestions.

Since the Globe plugin is not very actively developed, and takes a lot
of time before it's adapted to new osgEarth versions, consider it not
appropriate to keep as a core plugin and move it out of the qgis tree.
This is not very fair. Whereas it had a period of being pretty much 
unmaintained, the plugin is now actively maintained. But keep in mind 
that osgEarth is a delicate upstream to deal with: they break things 
without warning and without replacement within "minor" releases (though 
they really should be bumping major digits of the version number...). So 
finding new workarounds etc takes time and effort. So if distros don't 
want to wait for it to be adapted, they are free to simply disable 
building the plugin.


Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of the Globe plugin in QGIS 3 with Qt5

[Sandro Mani]

Hi

I've had a look recently at adding osgEarth 2.8 support (and produced a 
tentative patch [1]), however the rendering is completely broken. I've 
not had time to investigate yet, but it looks like osgEarth2.8 puts a 
hard minimum requirement on GLSL 3.30, i.e. debug log output:


FRAGMENT glCompileShader "main(fragment)" FAILED
FRAGMENT Shader "main(fragment)" infolog:
0:1(10): error: the compatibility profile is not supported
0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 
1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES


This makes me uncomfortable: I'm pretty sure many users running somewhat 
older distros or older hardware will hit this. So upgrading to osgEarth 
2.8 just for the sake of upgrading and braking the globe for many user 
is in my view not the best of plans.


Technically nothing speaks against building osgEarth2.7 against Qt5 (for 
clarity: osgEarth 2.7 supports Qt5 alread) and keeping that version 
packaged for the forseable future.


Alternatively, distros wanting to upgrade could keep osgEarth 2.7 
packaged as osgEarth27 and renaming library names (i.e. libosgEarthXXX 
-> libosgEarth27XXX) and the header dirs. Up to this point it would be 
fairly easy, the problem comes with osgPlugins - I'm not sure if it is 
possible to install multiple versions simultaneously in 
/usr/lib64/osgPlugins-3.4.0/ or similar.


Happy to hear other suggestions.

Best
Sandro

[1] https://smani.fedorapeople.org/osgEarth28.patch


On 28.09.2016 13:40, Sebastiaan Couwenberg wrote:

As discussed in #15536 [0], osgEarth 2.8 has been released and requires
OpenSceneGraph 3.4. The Debian packages for OSG 3.4 have switched to Qt5
as has the Debian packaging for osgEarth 2.8.

Unfortunately the Globe plugin only supports osgEarth 2.7 in QGIS 2.16
(which both still use Qt4). And I've not been able to get an answer from
Pirmin about the plans for the Globe plugin in QGIS 3 which will use Qt5.

Currently most packages that depend on OpenSceneGraph in Debian use the
OpenSceneGraph 3.2 packages, and those will remain available in the next
Debian stable release (stretch). The OpenSceneGraph maintainers have now
also move the OpenSceneGraph 3.4 packages to unstable to have it
available alongside the 3.2 packages in stretch. [1]

Because the QGIS 2.14 LTR packages in Debian lack support for osgEarth
2.7 in the Globe plugin, there is no need to keep the osgEarth package
at version 2.7, it's only used by the upstream QGIS 2.16 packages.

I'm considering moving the osgEarth 2.8 packages from experimental to
unstable for inclusion in stretch, hoping that support for it will be
added as part of the move to Qt5 in QGIS 3. Although based on my
questions in the Redmine issue not being answered and prior experience
with time needed to get support for osgEarth 2.7 in QGIS, I'm not seeing
a bright future for the Globe plugin in QGIS 3 with Qt5 expecting it to
be disabled for a long time until support for osgEarth 2.8 or later is
added.

If there is sufficient demand to keep osgEarth 2.7 in stretch for the
sake of upstream users of the QGIS 2.x packages, I'm willing to keep the
osgEarth 2.8 packages in experimental until stretch is released.
Otherwise I'll move the osgEarth 2.8 packages to unstable for inclusion
in stretch, breaking the Globe plugin in the upstream QGIS 2.16 packages.

Please share your thoughts about the future of the Globe plugin in QGIS
3 with Qt5.

[0] https://hub.qgis.org/issues/15536
[1] https://lists.debian.org/debian-gis/2016/09/msg00022.html

Kind Regards,

Bas



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.16 Globe plugin on Mac

[Sandro Mani]

Is the library being built? I.e. under Linux it is

lib/qgis/plugins/libglobeplugin.so

If yes, look at the debug output of qgis when starting and you should be 
able to see some info about why the plugin is being rejected.


Sandro



On 21.09.2016 16:28, Daven Quinn wrote:

Hi Sandro,

It is not listed anywhere in the plugin manager to be enabled or 
disabled. All other plugins I am accustomed to seeing in that list are 
there (629 in total) but “Globe” is nowhere to be found, unless it 
resides under some non-intuitive name. So, no opportunity to enable 
the plugin in the usual way.


Thanks,
Daven


On September 21, 2016 at 1:16:54 AM, Sandro Mani (manisan...@gmail.com 
<mailto:manisan...@gmail.com>) wrote:



Hi Daven

> doesn’t show up in the plugin directory or menu

Does this mean in the plugins menu or in the list of plugins in the 
plugin manager? If the former, please check the plugin manager an 
make sure the plugin is enabled. With the plugin enabled, a globe 
icon should also appear in the plugin toolbar.


Hope this helps
Sandro



On 21.09.2016 07:49, Daven Quinn wrote:

Hello,

I just completed a source installation of QGIS 2.16.2 on Mac, using 
a modified version of the Homebrew osgeo4mac/qgis–214 formula. I was 
particularly excited to try out the new globe plugin. QGIS builds 
correctly and is usable, but the globe plugin appears to be totally 
disabled, and doesn’t show up in the plugin directory or menu.


I built the formula with globe enabled (the Homebrew |—with-globe| 
option translates to |—DWITH_GLOBE=TRUE 
—DOSG_PLUGIN_PATH=/usr/local/lib/osgPlugins-3.4| compile options. 
I’m running osg 3.4 and osgearth 2.7. Both of these are built using 
homebrew formula, with qt support, and I think they are within the 
range of supported dependencies for the globe plugin.


In the “advanced” settings menu, there is a section for globe plugin 
settings, but I cannot see any other feedback that the plugin is 
installed.


Any insights on what might be disabling the globe plugin, and how I 
could compile QGIS in order to include this? I’ve successfully used 
my install of osgearth to view GIS data described by raw |*.earth| 
files, so I think it’s unlikely to be a dependency issue.


Thanks, Daven



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info:http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.16 Globe plugin on Mac

[Sandro Mani]

Hi Daven

> doesn’t show up in the plugin directory or menu

Does this mean in the plugins menu or in the list of plugins in the 
plugin manager? If the former, please check the plugin manager an make 
sure the plugin is enabled. With the plugin enabled, a globe icon should 
also appear in the plugin toolbar.


Hope this helps
Sandro



On 21.09.2016 07:49, Daven Quinn wrote:

Hello,

I just completed a source installation of QGIS 2.16.2 on Mac, using a 
modified version of the Homebrew osgeo4mac/qgis–214 formula. I was 
particularly excited to try out the new globe plugin. QGIS builds 
correctly and is usable, but the globe plugin appears to be totally 
disabled, and doesn’t show up in the plugin directory or menu.


I built the formula with globe enabled (the Homebrew |—with-globe| 
option translates to |—DWITH_GLOBE=TRUE 
—DOSG_PLUGIN_PATH=/usr/local/lib/osgPlugins-3.4| compile options. I’m 
running osg 3.4 and osgearth 2.7. Both of these are built using 
homebrew formula, with qt support, and I think they are within the 
range of supported dependencies for the globe plugin.


In the “advanced” settings menu, there is a section for globe plugin 
settings, but I cannot see any other feedback that the plugin is 
installed.


Any insights on what might be disabling the globe plugin, and how I 
could compile QGIS in order to include this? I’ve successfully used my 
install of osgearth to view GIS data described by raw |*.earth| files, 
so I think it’s unlikely to be a dependency issue.


Thanks, Daven



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsMapSettings: store layer pointers instead of layer ids?

[Sandro Mani]

On 03.08.2016 15:44, Martin Dobias wrote:

Hi Sandro

On Wed, Aug 3, 2016 at 3:25 PM, Sandro Mani  wrote:

Hi

For a project I need independent QgsMapCanvas instances, in particular a
child view which is unrelated to the main view (including its layertree).
(Easy example: the main view displays a city, and if the user clicks on a
"show building schema" button in the building feature attribute dialog, the
schema of the building is opened in a secondary view. The layers of the
building schema should not appear in the main layer tree however).

Currently this is not possible: while one can set the layers individually
for each QgsMapCanvas, the QgsMapSetting ends up storing the layer ids and
hence they must be stored in the QgsMapLayerRegistry. Items which are stored
in the QgsMapLayerRegistry will always be visible in the application legend
tree.

You can use QgsMapLayerRegistry.instance().addMapLayer(layer, False) -
the layer will get to the registry, but it will not end up in the
layer tree. Doesn't it solve your problem?
Oh, why think small when you can think big... I think I somehow just 
completely missed that :)


Thanks!
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QgsMapSettings: store layer pointers instead of layer ids?

[Sandro Mani]

Hi

For a project I need independent QgsMapCanvas instances, in particular a 
child view which is unrelated to the main view (including its 
layertree). (Easy example: the main view displays a city, and if the 
user clicks on a "show building schema" button in the building feature 
attribute dialog, the schema of the building is opened in a secondary 
view. The layers of the building schema should not appear in the main 
layer tree however).


Currently this is not possible: while one can set the layers 
individually for each QgsMapCanvas, the QgsMapSetting ends up storing 
the layer ids and hence they must be stored in the QgsMapLayerRegistry. 
Items which are stored in the QgsMapLayerRegistry will always be visible 
in the application legend tree.


So I was thinking about whether it would make sense to store the actual 
QgsMapLayer pointers instead of the layerIds in QgsMapSettings, so that 
the whole rendering process is independent of QgsMapLayerRegistry.


I haven't yet investigated extensively how invasive such a change would 
be, but are there some initial opinions?


Thanks
Sandro


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Globe plugin missing on Ubuntu

[Sandro Mani]

On 27.07.2016 15:37, Anita Graser wrote:

Hi,

After updating to 2.16 on Ubuntu, there is no Globe plugin available 
anymore. My package manager only shows Globe for 2.14 even though 
everything else from QGIS 2.16 seems to have installed just fine:


http://gis.stackexchange.com/a/203744/187

Any ideas?
Which package are you using, or did you build yourself? In short, 
osgearth-2.7 is needed or else the globe plugin in QGIS 2.16+ cannot be 
built.


Best
Sandro



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] API Break in 2.16 for QgsComposition

[Sandro Mani]

On 16.07.2016 01:20, Nyall Dawson wrote:

On 15 July 2016 at 03:40, Tim Sutton  wrote:

Hi All

It seems like something broke in QgsComposition (in 2.16 and master) - we have 
some code like this:

logo = self.composition.getComposerItemById('logo')
logo.setPicturePath(self.logo_path)


Which fails saying that QgsCompositionItem has no method setPicturePath. This 
used to work fine in 2.14 - has anyone else encountered this? I know we are 
breaking API post 2.16 but it would be great if this still behaved right - or 
if someone could indicate the preferred way to do this now?

Is this specific to composer items? Or does all sip casting fail? (ie,
try retrieving a symbol layer from a renderer... is it correctly cast
to QgsSimpleFillLayerV2/etc or just left at the generic
QgsSymbolLayerV2?)

I similar issue:

class MyTool(QgsMapTool):
def __init__(self, canvas):
QgsMapTool.__init__(self, canvas)

def canvasReleaseEvent(self, e):
print "Release: %d,%d" % (e.x(), e.y())

iface.mapCanvas().setMapTool(MyTool(self.iface.mapCanvas()))

-> The canvasReleaseEvent of the base class is fired, the overriding 
method is ignored.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] API Break in 2.16 for QgsComposition

[Sandro Mani]

Hi Tim

On 15.07.2016 04:18, Tim Sutton wrote:

Do you know what the 'know good' version is?
The series prior to 4.18, i.e. 4.17 and 4.16 were ok as far as I can 
remember.


Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] API Break in 2.16 for QgsComposition

[Sandro Mani]

Hi

Using Sip-4.18 by any chance? I'm seeing such issues also ever since
upgrading [1], didn't manage to find a solution up to now. (So if this is
indeed the issue, it is not related to QGIS 2.16 but rather to the sip
version.)

Sandro

[1] https://lists.osgeo.org/pipermail/qgis-developer/2016-May/042668.html

On Thu, Jul 14, 2016 at 7:40 PM, Tim Sutton  wrote:

> Hi All
>
> It seems like something broke in QgsComposition (in 2.16 and master) - we
> have some code like this:
>
> logo = self.composition.getComposerItemById('logo')
> logo.setPicturePath(self.logo_path)
>
>
> Which fails saying that QgsCompositionItem has no method setPicturePath.
> This used to work fine in 2.14 - has anyone else encountered this? I know
> we are breaking API post 2.16 but it would be great if this still behaved
> right - or if someone could indicate the preferred way to do this now?
>
> Thanks!
>
> Regards
>
> Tim
>
> —
>
>
>
>
>
>
>
>
> *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: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SIP 4.18 and ConvertToSubClassCode

[Sandro Mani]

Hi Matthias

Ah, forgot to specify: this is with the latest qgis master:

c.composition().getComposerItemById("Text")


Best
Sandro

On 11.05.2016 15:53, Matthias Kuhn wrote:

Hi Sandro,

Just to be sure, did you also try with the non-closed upstream QGIS code?

Matthias

On 05/11/2016 03:33 PM, Sandro Mani wrote:

Hi

Fedora has updated to SIP 4.18, and I'm now seeing some issues with
subclass conversions, in particular

composerView.composition().getComposerItemById("aQgsComposerLabel")

does not anymore return a QgsComposerLabel instance, but rather a
QgsComposerItem instance.

Does anyone familiar with SIP know how to debug this? I've tried
playing around with the ConvertToSubClassCode code in
qgscomposeritem.sip, in particular changing sipClass with sipType
(having read that the former is deprecated [1]), but no improvements.
I actually don't even see that code executing by setting a breakpoint
in sip_corepart0.cpp.

So, any ideas?

Thanks

Sandro



[1] https://riverbankcomputing.com/pipermail/pyqt/2010-June/026759.html

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] SIP 4.18 and ConvertToSubClassCode

[Sandro Mani]

Hi

Fedora has updated to SIP 4.18, and I'm now seeing some issues with 
subclass conversions, in particular


composerView.composition().getComposerItemById("aQgsComposerLabel")

does not anymore return a QgsComposerLabel instance, but rather a 
QgsComposerItem instance.


Does anyone familiar with SIP know how to debug this? I've tried playing 
around with the ConvertToSubClassCode code in qgscomposeritem.sip, in 
particular changing sipClass with sipType (having read that the former 
is deprecated [1]), but no improvements. I actually don't even see that 
code executing by setting a breakpoint in sip_corepart0.cpp.


So, any ideas?

Thanks

Sandro



[1] https://riverbankcomputing.com/pipermail/pyqt/2010-June/026759.html

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Check geometry not fixing errors?

[Sandro Mani]

On 15.01.2016 17:48, Paolo Cavallini wrote:

Il 15/01/2016 17:45, Sandro Mani ha scritto:


Okay, but did you encounter such issues with the geometry checker plugin
specifically? I did a couple of random tests and things seem to work
(except the layer creation issue mentioned previously).

they were not dropped, but I ended up with a layer with more or less the
same errors as in the origin. I may be missing some options though.
If you want we can try debugging it from IRC.
Thanks.
About to leave right now, but if you can just list which layer and which 
checks you picked I should be able to reproduce any issues easily.


Thanks
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Check geometry not fixing errors?

[Sandro Mani]

On 15.01.2016 17:39, Paolo Cavallini wrote:

Il 15/01/2016 17:34, Sandro Mani ha scritto:


Can you describe the steps to reproduce the case where a geometry ends
up getting thrown away?

this happens quite reliably when using the lwgeom plugin and v.clean,
both through Processing.
thanks.
Okay, but did you encounter such issues with the geometry checker plugin 
specifically? I did a couple of random tests and things seem to work 
(except the layer creation issue mentioned previously).


Thanks
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Check geometry not fixing errors?

[Sandro Mani]

On 15.01.2016 17:16, Paolo Cavallini wrote:

Il 15/01/2016 17:12, Sandro Mani ha scritto:


Some improvements are needed in QgsVectorFileWriter to discard the Z
component resp to allow 3D polygons.

I'll also look at whether there is some bad handling within the geometry
checker code itself.

interesting - thanks Sandro.
better open tickets, to remember and document the process?
all the best.
Can you describe the steps to reproduce the case where a geometry ends 
up getting thrown away?


Thanks
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geometry Checker contra Topology Checker

[Sandro Mani]

On 14.01.2016 13:48, Luigi Pirelli wrote:

Hi

today someone asked me where to invest public development funds
enhancing some topology check instruments (not necessarily QGIS)

they have the doubt about if was better invest in Topology Checher or
Geometry Checker (or something else)

would make sense to invest merging the two plugins, new geometry
engine for Geometry Checker with the UI and use cases of the Topology
Checker?
So from a geometry checker point of view, the big thing it misses 
compared to the topology checker plugin is support for checking multiple 
layers at once.


The UI at the moment is indeed one big block, but the code underneath is 
very modular, and it is pretty easy to make a more "test-set" oriented UI.


Just my two cents

Sandro


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Check geometry not fixing errors?

[Sandro Mani]

On 08.01.2016 19:37, Paolo Cavallini wrote:

Il 08/01/2016 19:02, Paolo Cavallini ha scritto:

Hi all,
I tried several options, but I cannot get rid of the errors in layers from
http://opendata.regione.abruzzo.it/content/ctrn-regione-abruzzo-15000
e.g.
http://opendata.regione.abruzzo.it/opengeodata/Dati_vettoriali/DBTR/CTR_2001-05_5k_SHP/348111.rar
Any hint?

BTW, neither GRASS nor Make Valid (the lwgeom plugin) succeed in fixing
these errors, as they simply throw away the polygons with errors.
Furthermore, lwgeom plugin seems not to be working (returning an empty
output layer) on 2.8, whereas it runs on >=2.12. Feedback would be welcome.
All the best.


Hi Paolo

Looks like these are 3D shapefiles, at least when running the checker 
with "create new layer" I got:


Failed to create the output layer: creation of layer failed (OGR 
error:Geometry type of `3D Polygon' not supported in shapefiles.


Type can be overridden with a layer creation option

of SHPT=POINT/ARC/POLYGON/MULTIPOINT/POINTZ/ARCZ/POLYGONZ/MULTIPOINTZ.

)

Some improvements are needed in QgsVectorFileWriter to discard the Z 
component resp to allow 3D polygons.


I'll also look at whether there is some bad handling within the geometry 
checker code itself.


Best Sandro


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Commit access

[Sandro Mani]

Hi
I have read and I agree with the terms in the QGIS Contributor Guidelines
(http://www.qgis.org/wiki/Contributor_Guidelines). Thank you for inviting me
to the QGIS developers team.

Best regards
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.12 New Geometry Checker Plugin crash

[Sandro Mani]

On 30.10.2015 10:54, m roy wrote:


Il 29/10/2015 11.08, Sandro Mani ha scritto:

On 29.10.2015 09:24, m roy wrote:

If with test suite you mean steps to reproduce the crash:

[...]

100% crash

Thanks for the detailed steps, I've fixed this in my
geom_checker_fixes branch [1] (which I periodically push into master).



Will it be possible to update the plugin or is it mandatory to recompile
QGIS as a whole to test the bug fix?
In short, you'll need to recompile the entire QGIS. But if you then keep 
the sources and build directory, subsequent builds will be incremental, 
hence much quicker.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.12 New Geometry Checker Plugin crash

[Sandro Mani]

On 29.10.2015 09:24, m roy wrote:

If with test suite you mean steps to reproduce the crash:

[...]

100% crash
Thanks for the detailed steps, I've fixed this in my geom_checker_fixes 
branch [1] (which I periodically push into master).



[1] https://github.com/manisandro/QGIS/tree/geom_checker_fixes


[...]

I also got a couple of crashes, but had no opportunity to find a way to
replicate the issue with a minimal test suite. If you can, I can check
it here.
All the best, and thanks.
A backtrace might already be sufficient to pin-point the issue. Clearly, 
the more info, the better.


Thanks
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geometry Checker contra Topology Checker

[Sandro Mani]

On 08.10.2015 16:19, Giovanni Manghi wrote:

We also should move the first one to the analysis library, so that the
routines are accessible by plugins and processing framework Just
another item on the TODO list!

sure, big improvement. better opening a ticket?
Giovanni, could you please add tickets for the missing features of the
new plugin, and one for the removal of previous plugins?
all the best, and thanks.

I must say that I like more the concept of rules in Topology Checker
instead of one big dialog used in Geometry Checker. Both from UI and
programming point of view. It is more flexible and extensible. I am
curious why a new plugin was started instead of improvement of the old
one. I don't think that the Topology Checker should be simply removed
until we have something similar in terms of definition and
implementation of rules.


Hi, I haven't suggested to remove immediately the topology checker,
but just said that the redundancy with the python geometry checker and
now with the new geometry checker is very puzzling for final users, so
one way or another we should get rid of it (the redundancy).

Moreover the new tool can fix geometries, and this is of course a
must. All the mentioned tools have issues: the topology checker with
reprojected layers and false positives in particular but also the new
geometry checker has a few ones, see for example
http://hub.qgis.org/issues/13535

Yep - as mentioned in the original PR, the port to the new geometry core 
is pretty fresh and it didn't get as much testing as our previous 
version based on the old geometry core. So any error reports are 
welcome, I'll look at fixing any outstanding issues.


Thanks
Sandro
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] new dependency on GEOS C++ library

[Sandro Mani]

On 06.10.2015 18:11, Sandro Mani wrote:



On 06.10.2015 18:05, Sandro Santilli wrote:

On Thu, Oct 01, 2015 at 05:41:58PM +0200, Sandro Mani wrote:


I suppose I could replace the incomplete precision reduction
implementation with a hand-rolled snap-to-grid for now and wait for
GEOS 3.6. If there are no objections, I'll move on with this this
weekend.

Were you able to work on the hand-rolled snap-to-grid implementation ?
What would happen by just removing the snapping completely for now ?


I wrote the code on Sunday [1] but didn't manage to find the time to 
actually test it yet. Should find a moment tomorrow, at which point 
I'll do the pull request.


Sorry for the delay.

[1] https://github.com/manisandro/QGIS/tree/geos_snap


Pull request filed: https://github.com/qgis/QGIS/pull/2353
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geometry Checker contra Topology Checker

[Sandro Mani]

On 07.10.2015 09:29, Salvatore Larosa wrote:

Hi Radim,

On Wed, Oct 7, 2015 at 9:25 AM, Radim Blazek  wrote:

I must say that I like more the concept of rules in Topology Checker
instead of one big dialog used in Geometry Checker. Both from UI and
programming point of view. It is more flexible and extensible. I am
curious why a new plugin was started instead of improvement of the old
one. I don't think that the Topology Checker should be simply removed
until we have something similar in terms of definition and
implementation of rules.

+1, something that I thought and that I could not express.

To explain the background - the design was done based on specific 
requirements by a customer. The code was written from scratch to 
properly implement the entire logic of fixing errors and tracking the 
effect of fixing one error on other errors. But from a programming point 
of view the implementation is actually very modular and easily 
extensible. The UI is differently organized, it was felt that it allowed 
the user to more quickly set up the "check session". But as far as I'm 
concerned in it's current form I don't see it as deprecating the current 
topology checker.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geometry Checker contra Topology Checker

[Sandro Mani]

On 06.10.2015 22:28, Salvatore Larosa wrote:

On Tue, Oct 6, 2015 at 8:33 PM, Giovanni Manghi
 wrote:

Hi,


Is it Geometry Checker replacement for Topology Checker? It has more
options but does not support multiple layers. What is the future,
Geometry Checker or Topology Checker or both merged together?


this is the classic example of bad redundancy we would need to remove
in QGIS. Not only we have now the geometry checker and the topology
checker, but there is also a core python tool to check for geometry.
It seems to me that the last two should should eventually be merged in
the first one, considered that they do not offer any tool to fix the
geometries and that they have a few issues (slow, problems with
reprojected layers, false positives, etc.).

Just as additional note, we have two identical entries under the
Vector menu "Geometry Tools".
The cause of this is that fTools creates the "Geometry Tools" vector 
menu entry internally, whereas the C++ plugins use the QgisInterface 
method "addPluginToVectorMenu". I suppose the reason for the fTools 
behaviour is that the QgisInterface method does not allow you to specify 
the icon for the menu entry. And I suppose the reason 
QgisInterface::addPluginToVectorMenu does not allow you to specify the 
icon is because this would lead to potential inconsistent behaviour when 
multiple plugins use the same label text but different icons. So I'm not 
sure how to best solve this.


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geometry Checker contra Topology Checker

[Sandro Mani]

On 06.10.2015 20:33, Giovanni Manghi wrote:

Hi,


Is it Geometry Checker replacement for Topology Checker? It has more
options but does not support multiple layers. What is the future,
Geometry Checker or Topology Checker or both merged together?


this is the classic example of bad redundancy we would need to remove
in QGIS. Not only we have now the geometry checker and the topology
checker, but there is also a core python tool to check for geometry.
It seems to me that the last two should should eventually be merged in
the first one, considered that they do not offer any tool to fix the
geometries and that they have a few issues (slow, problems with
reprojected layers, false positives, etc.).


Hello

Further development of the C++ plugins is not on our radar at this time 
beyond maintenance and fixing possible outstanding issues. It will also 
be next year until it will use the reduced precision mode of GEOS as was 
originally intended. That said, I'm happy to answer any question about 
the architecture of the plugin if anyone wants to extend it to 
eventually be able to replace the python plugins.


Best
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] new dependency on GEOS C++ library

[Sandro Mani]

On 06.10.2015 18:05, Sandro Santilli wrote:

On Thu, Oct 01, 2015 at 05:41:58PM +0200, Sandro Mani wrote:


I suppose I could replace the incomplete precision reduction
implementation with a hand-rolled snap-to-grid for now and wait for
GEOS 3.6. If there are no objections, I'll move on with this this
weekend.

Were you able to work on the hand-rolled snap-to-grid implementation ?
What would happen by just removing the snapping completely for now ?


I wrote the code on Sunday [1] but didn't manage to find the time to 
actually test it yet. Should find a moment tomorrow, at which point I'll 
do the pull request.


Sorry for the delay.

[1] https://github.com/manisandro/QGIS/tree/geos_snap
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] new dependency on GEOS C++ library

[Sandro Mani]

On 01.10.2015 17:26, Sandro Santilli wrote:

So while the discussion on geos-dev started, I'm thinking that
for GEOS you might prefer to have a solution that also works
with older GEOS version ? Note that doing that by keeping the
dependency on the C++ interface might be a puzzle for packagers
because every version of GEOS is intentionally marked as being
binary incompatible with the previous.

Would it make sense to just do the gridding internally (dropping
the geosc++ dep) for now and postpone the proper precision model
implementation to only be available with the newer GEOS release ?

The idea is to ship a 3.6 version of GEOS capable of the PrecisionModel
control before February.

I suppose I could replace the incomplete precision reduction 
implementation with a hand-rolled snap-to-grid for now and wait for GEOS 
3.6. If there are no objections, I'll move on with this this weekend.


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] new dependency on GEOS C++ library

[Sandro Mani]

On 01.10.2015 13:55, Sandro Santilli wrote:

On Thu, Oct 01, 2015 at 01:39:37PM +0200, Sandro Mani wrote:


As resulted from the discussion in the geos ticket: the goal is
having the operations run in reduced precision, not just merely snap
to grid. The discussion revealed however that snap to grid is
basically what ends up being done with the current implementation,
due to a mis-understanding of mine of the geos internals. As
suggested in the geos ticket, I'd like to fix this to work as
initially intended, and keep geosextra in QGIS until a new release
of GEOS comes out which implements needed changes in the C-API.

That's fine by me.
I'm wondering if the easiest way to do it would be something like this:

  GEOSGeometry* GEOSGeometry_setFactory( GEOSGeometryFactory* factory, int 
roundCoordinates );

But note that for such a call, the "factory" parameter would need
to be alive for the whole lifetime of the returned GEOSGeometry
_and_ for any further product from it (operation involving it as an input).

These GeometryFactory links are sticky, that's what makes it hard to
deal with them.



If one sets the reduced precision factories on the geometries, does one 
still need to explicitly reduce those geometries prior to performing the 
analysis operation, or are they reduced implicitly while performing the 
operation?

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] new dependency on GEOS C++ library

[Sandro Mani]

On 01.10.2015 11:47, Sandro Santilli wrote:

I've found that qgis is now dependent on the C++ GEOS API,
due to the new src/core/geosextra.

It seems to me that the "geosextra" code in its current incarnation
only exposes a function to basically round coordinates to a precision
grid, but in no way changes the precision of operations performed by
further GEOS functions on the resulting geometries.

This is discussed in detail in https://trac.osgeo.org/geos/ticket/713

So my question is: if grid-snapping is enough for QGIS use, is adding
a new dependency on GEOS really needed, or isn't there other internal
code for doing coordinates editing work (would seem easy with Qt
standard library?).
As resulted from the discussion in the geos ticket: the goal is having 
the operations run in reduced precision, not just merely snap to grid. 
The discussion revealed however that snap to grid is basically what ends 
up being done with the current implementation, due to a 
mis-understanding of mine of the geos internals. As suggested in the 
geos ticket, I'd like to fix this to work as initially intended, and 
keep geosextra in QGIS until a new release of GEOS comes out which 
implements needed changes in the C-API.


As I've been asked to help with getting the code in place for what
I've understood are good new functionalities I'm here to better
understsand the issue, why the new code is needed and how to best have
it available, considering also that latest GEOS release was published
on August 15, 2015.

See also https://github.com/qgis/qgis/pull/2302

--strk;


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Compile error (geos)

[Sandro Mani]

See also

https://github.com/qgis/QGIS/commit/8cec2c935f5541a865d0bf91140ca5b2d25b17cb#commitcomment-13433347

FindGEOS.cmake changed in that commit, introducing the new variable 
GEOS_CPP_LIBRARY. It looks like a simple reconfigure of an existing 
build directory is insufficient for cmake to pick up that change, and 
people have reported that it is necessary to start from an empty build 
directory for the build to succeed, perhaps removing the CMakeCache 
might also be sufficient. Anyone with enough low-level knowledge of 
cmake to explain why the reconfiguring does not pick up the changes in 
FindGEOS.cmake ...?


Sandro


On 25.09.2015 12:18, Denis Rouzaud wrote:


It's because we're entering feature freeze, nothing special.
-- Sorry --


Le ven. 25 sept. 2015 11:49 AM, Stefan Ziegler 
mailto:stefan.ziegler...@gmail.com>> a 
écrit :


Hi

I cannot compile QGIS master:

[  0%] Built target version
Linking CXX shared library ../../output/lib/libqgis_core.so
CMakeFiles/qgis_core.dir/geosextra/geos_c_extra.cpp.o: In function
`GEOSPrecisionModel_create':
geos_c_extra.cpp:(.text+0x1b): undefined reference to

`geos::geom::PrecisionModel::PrecisionModel(geos::geom::PrecisionModel::Type)'
CMakeFiles/qgis_core.dir/geosextra/geos_c_extra.cpp.o: In function
`GEOSPrecisionModel_createFixed':
geos_c_extra.cpp:(.text+0x63): undefined reference to
`geos::geom::PrecisionModel::PrecisionModel(double)'
CMakeFiles/qgis_core.dir/geosextra/geos_c_extra.cpp.o: In function
`GEOSPrecisionModel_destroy':
geos_c_extra.cpp:(.text+0x9a): undefined reference to
`geos::geom::PrecisionModel::~PrecisionModel()'
CMakeFiles/qgis_core.dir/geosextra/geos_c_extra.cpp.o: In function
`GEOSGeometryPrecisionReducer_reduce':
geos_c_extra.cpp:(.text+0x101): undefined reference to
`geos::precision::GeometryPrecisionReducer::reduce(geos::geom::Geometry
const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [output/lib/libqgis_core.so.2.11.0] Error 1
make[1]: *** [src/core/CMakeFiles/qgis_core.dir/all] Error 2
make: *** [all] Error 2

I installed latest geos from trunk.

regards
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geometry precision model

[Sandro Mani]

On 14.09.2015 10:44, Nyall Dawson wrote:



On 14 Sep 2015 5:47 pm, "Hugo Mercier" > wrote:


>
> - using the C++ GEOS API instead of the C API that exposes precision 
models.

>
> I am not sure yet about what possibility to implement. Is there anything
> that prevent us from using the C++ GEOS API ? Having it in the C API may
> also benefit to other projects (PostGIS) ...
> Or am I totally missing other problems ?
>

Check out pr #2302 - this is being tackled by manisandro currently.

Right, for the geometry checking plugins I've been using the C++ GEOS 
API, but I've wrapped the additional precision related functionality in 
a C API, see


https://github.com/manisandro/QGIS/blob/geometry_plugins/src/core/geosextra/geos_extra/geos_c_extra.cpp
https://github.com/manisandro/QGIS/blob/geometry_plugins/src/core/geosextra/geos_extra/geos_c_extra.h

Such an API was proposed upstream early this year [1], but the 
discussion stalled. So perhaps that discussion could be revived.


Sandro


[1] http://lists.osgeo.org/pipermail/geos-devel/2015-January/007080.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] FOSS4G-EU

[Sandro Mani]

On 10.07.2015 09:20, Paolo Cavallini wrote:

Hi all,
who will be at FOSS4G-EU, next week? I'd be glad of having a QGIS
informal meeting at one of the BoF spaces we have [0].
Anyone interested? Could someone suggest a time and date?
Thanks.

[0] http://wiki.osgeo.org/wiki/FOSS4G_Europe_2015_BirdsOfAFeather

Hi

I'll be there on Wednesday.

@strk
Will you be attending? Would be a nice occasion to have a discussion 
about some GEOS work needed for QGIS, I'm thinking in particular about 
the issue of exposing the PrecisionReducer functionality in the C API 
(as we already discussed to some extent a few months back).


Best,
Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Is the new release schedule a success?

[Sandro Mani]

Hello

Just one curiosity: are unit tests run on all main platforms before 
release? Apparently the nasty OgrConnectionPool issue triggered a 
failure in the test suite on OS X, whereas on Linux it did not. So this 
might be something worth considering for future releases.


Best,
Sandro


On 30.06.2015 22:50, Marco Hugentobler wrote:

Hi

In my opinion, this has nothing to do with the release schedule. It 
has mainly two reasons:


- QGIS is quite a large project. So testing really everything 
(including complex interaction of different modules with GUI) is 
impossible.


- There is a lot of development activity in QGIS. More development = 
more possibility of unexpected side effects.


A longer feature freeze wouldn't help. The thing which does help is 
the 2.8 version.


Regards,
Marco

Am 30.06.2015 um 20:14 schrieb Tom Chadwin:

This post is in no way a criticism of any of the QGIS team and their
monumental efforts or their fabulous product. However, I thought someone
should question how successful the four-monthly release schedule is. 2.8
immediately needed 2.8.1, and there seems to be the chance that 2.10 is
immediately going to need 2.10.1.

Is the predestined release schedule meaning that the devs simply 
cannot test
as much as they need? Alternatively, should the feature freeze be 
extended?


Anyway, keep up the fabulous work, all of you. My organization has never
looked back since migrating to QGIS, and it is only getting better and
better.

Thanks

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Is-the-new-release-schedule-a-success-tp5213659.html
Sent from the Quantum GIS - Developer mailing list archive at 
Nabble.com.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer





___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsVectorLayerCache

[Sandro Mani]

(Forwarding message to list...)

On 15.06.2015 16:52, Sandro Mani wrote:

Hi Matthias

On 15.06.2015 15:34, Matthias Kuhn wrote:

Hi Sandro

On 06/15/2015 02:42 PM, Sandro Mani wrote:

Hello Matthias and List

I have two questions about the QgsVectorLayerCache, which you
(@Matthias) have implemented [1].

1. First the easy one:
https://github.com/qgis/QGIS/blame/master/src/core/qgsvectorlayercache.cpp#L97 



-> I'm not sure what this block of code is supposed to do. As far as I
can see it just performs an empty iteration over all layer features,
but has no effects otherwise. Am I missing something? This block of
code is executed when loading the attribute table. If I comment it, I
can't spot any side effects, except that the loading of the attribute
table is faster.

It's a QgsCachedFeatureWriterIterator which fills the cache when
iterating over it.
It's only being invoked when full caching is requested to avoid
incremental population of the cache with a lot of subsequent requests.
If you have slow round-trips and disable this code the effect should be
noticeable. If it's not, there's something wrong with it.
Uhm ok, I'll need to investigate this together with my AFS provider 
implementation, somehow the result of that code block was that all 
features were fetched from the server twice.



2. Secondly, to the vector layer cache in general.
Some background: I've done an initial implementation of an ArcGIS
Feature Service ("AFS") data provider, and similarly to the WFS
provider, the question of intelligent caching arises, to reduce
round-trips with the server. The WFS provider just caches all features
in memory (if the corresponding option is checked), which is
suboptimal for large datasets.
I've hence been thinking about implementing a local disc-based cache
(say in the form of an SpatiaLite DB), which acts as a local feature
cache. The usefulness of this could however go beyond just WFS and
AFS, to include all non-local data sources. So my idea is to implement
something like a QgsVectorDataProviderProxy which

- overrides getFeatures to return a QgsCacheProxyFeatureIterator: this
iterator first checks whether the Feature is cached, and if not, only
then fetches it from the data provider. If the QgsFeatureRequest
includes an extent, entire pages of features could be loaded from the
disk to memory (up to a specified threshold).

- overrides all add/change/delete methods to ensure that the cache
remains consistent.

Actually I think the most elegant approach would be to have
QgsVectorLayer::mDataProvider be an instance of this
QgsVectorDataProviderProxy. If the data source is local, the calls are
simply forwarded to the actual data provider, otherwise, the above
outlined behavior applies.

So (@Matthias): such an implementation would pretty much overlap with
what you have implemented, but does the work directly at provider
level. What are your thoughts on this? From your experience
implementing [1], do any alarm bells start ringing?

I have thought about this approach as well as it seems to be very nice
to have one shared cache which is able to provide several consumers with
cached data (canvas, attribute table...). Do you think you will be
introducing a size limit?
Speaking of the disk-cache: Yes, I suppose that would make sense, 
perhaps as a configurable option in the user preferences. For memory 
cache, there clearly would be a size limit.


One risk I see is, that if you have different consumers (with a shared
cache), they have different requirements.
For the canvas the requirement is usually to have some spatial index
that keeps track of which regions are cached and if a new request can be
satisfied. It would be even easy/nice to do some look-ahead to pre-load
features or only load part of the canvas if a big region is already
loaded or do tiling.
Right, I'd like to model the cache around an idea of "pages", i.e. 
entire spatial regions which can be swapped in and out of memory 
depending on the current region of interest.


If another consumer then does a second request without a spatial filter
(none or attribute filter instead) it may fetch a lot of features and
pollute your cache with these features. If there's a size limit of the
cache it can then be cleaned of previous features which would still be
more important for drawing then the ones fetched for a different
consumer which may have been requested just once.
Yes I see the problem. First, one would need to investigate how 
expensive such cache trashings are compared to the situation with no 
cache at all. Then I suppose the usual ideas are things like having an 
access time stamp on the page loaded in memory, and if a page needs to 
go, the one last accessed furthest back will get thrown out.


You will also have to take care of multithreading since multiple
iterators can run at the same time.

Definitely.


It's probably also required to spend some thought

Re: [Qgis-developer] Print composer font pickers are broken

[Sandro Mani]

As the author of that commit I'm terribly sorry for the trouble it 
caused, I would have never expected something harmless as setting the 
parent to have such consequences...


Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer