Re: [QGIS-Developer] Bug #21460? | is QGIS non-commercial?

[Benjamin Ducke]

Hi Paolo,

On 08/04/2019 10:30, Paolo Cavallini wrote:
> Hi Cory,
> 
> On 08/04/19 00:57, Cory Albrecht wrote:
>> I was wondering when Bug #21460
>>  was going to get some attention?
>> It's about  QGIS not forming proper PostGIS SQL updates correctly,
>> specifically for null values.
> 
> may I suggest you an interesting read?
> https://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis/

There is a (common) problem with that text
and your reply that is increasingly giving
my headaches when thinking how to advertise
QGIS among colleagues:

Quote (from the URL above):

"unlike the commercial GIS offerings"

This suggests that QGIS is a non-commercial
project.

But a few lines further down we read:

"either organisations who offer commercial QGIS
support"

"if you hire a core QGIS developer to make your
changes"

These are clearly commercial offerings/activities,
and people are being advised to make use of them.

To be clear: I don't think there is anything wrong
with that. But I think that it is misleading to
present QGIS as "non-commercial". It is open
source and non-proprietary, in the sense that no
single individual or institution owns the rights
to it. But commerce is clearly part of QGIS now.

As I see it, there are two "honest" options:

(1) Stop calling QGIS non-commercial and keep
advising people to hire developers for fixing
bugs and implementing features.

(2) Keep calling QGIS a non-commercial project
and stop advising people to hire developers
to fix bugs or develop features for them.

Best,

Ben


> Cheers.
> 
___
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] Geometry no showing on 3.4.1 on Windows 10, but working fine on linux or 2.18

[Benjamin Ducke]

On 22/11/2018 12:19, Alexandre Neto wrote:
> Hi,
> 
> I am having this strange error on Windows, where a layer(shapefile) will
> not show specific geometry in QGIS 3.4. Nevertheless, the same layer
> works fine on QGIS 3.4 on Linux.

I have just observed the same with QGIS 2.18.25.
Actually, I have seen this with both GeoTIFF
and Shapefile data sources. The extent is
correctly read from the data, the attributes and
feature counts are also ok, but no geometries are
visible. This does not happen with QGIS 2.18.24.
And it also does not happen on macOS. It affects
only some Shapefiles, but so far I fail to see
a pattern. What I can say, is that the problem
is not random: If a Shapefile does not display
on a Windows machine with 2.18.25, then it will
be the same with any other Windows machine
running that version of QGIS.

I can also confirm that exporting a Shapefile
(using "Layer->Save As") from 2.18.24 (Windows)
will make it work with 2.18.25. I suspect a
problem with the  GDAL/OGR libs shipped with the
latest Windows binaries.

Best,

Ben

> 
> It also opens fine on windows if one uses QGIS 2.18. Saving the file in
> 2.18 (or on Linux) fixes it for QGIS 3.4 on Windows. Using the geometry
> checker, no errors were found on the geometry.
> 
> Can this be a possble bug on Windows? Or some option that I might have
> activated?
> 
> Here's a link for the data.
> 
> https://www.dropbox.com/s/47grcp7i24gkley/espaco_verde.zip?dl=0
> 
> Thanks,
> 
> Alexandre Neto
> 
> 
> 
> 
> -- 
> Alexandre Neto
> -
> @AlexNetoGeo
> http://sigsemgrilhetas.wordpress.com
> http://gisunchained.wordpress.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
> 



-- 
Dr. Benjamin Ducke
Deutsches Archäologisches Institut (DAI)
Zentrale Berlin, IT-Referat
* Projekt "Stunde Null" *
___
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] Using memory layer in Processing with SAGA and GRASS

[Benjamin Ducke]

Hi,

On 26/04/18 08:53, Nyall Dawson wrote:
> On 26 April 2018 at 16:42, matteo <matteo.ghe...@gmail.com> wrote:
>> Hi Nyall,
>>
>>> No - neither SAGA nor GRASS have any concept of QGIS memory layers.
>>> You need to give them a disk-based file path to save their outputs to.

That's not quite accurate. Even if they did have
such a concept, it would be of no use in this
context.

SAGA and GRASS commands run as separate processes,
in their own address spaces. Any reasonably secure
operating system (let's generously include Windows
and macOS in that category), will make sure that
processes cannot simply manipulate each other's
memory.

So QGIS needs to create temporary files to pass
both input and output data to/from GRASS/SAGA.

An alternative would be to refactor all
GRASS/SAGA modules as library objects so that they
could run in the same address space as QGIS.
That would probably also involve creating a new
interface API for use by QGIS (or other "host GIS").

Note that we are talking about C/C++ binaries here.
So one would also need to inspect every single GRASS/SAGA
binary and library for memory leaks (which can currently
be ignored, because memory is freed by the OS as soon as
the GRASS/SAGA commands' process ends).

>>
>> ok, clear now why this was not working
>>
>>
>>> If you use a memory layer as an input to these algs it will also have
>>> to save it out to a disk based format, but this is done automatically
>>> by saving to a file in the temp folder. We could potentially do the
>>> same thing to allow SAGA/GRASS algs to output to a memory layer by
>>> first saving the output to a shp in the temp folder, then loading that
>>> file and copying the features to a memory layer. But it would be
>>> rather inefficient and counter productive - you're still being forced
>>> to loop over the disk-based format, so you're just adding extra
>>> processing for little gain.
>>
>> so within a script (or a Processing plugin) both input layer and output
>> one have to come from a disk saved file.
> 
> Not quite - the input layer doesn't *have* to, because processing will
> automatically save it to a disk file if required.

In the case of SAGA, all this auto-creating files
is not too bad, because SAGA uses simple shapefiles
for vector data.

In the case of GRASS, this is a more complicated matter.
GRASS uses a fully topological vector format and all
input data will go through rigorous topology testing
by default. The more intermediate steps, the higher
the risk that data will get crippled in the process.
Note that GRASS now has an alternative way of linking
to external data instead of importing it:

https://grass.osgeo.org/grass74/manuals/v.external.html

So perhaps it would be a good idea for the QGIS GRASS
provider to offer v.external as an alternative to
v.in.ogr for piping QGIS vector layers into the GRASS
backend (however, read "NOTES" on the page cited above!).

Best,

Ben

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



-- 
Dr. Benjamin Ducke
Deutsches Archäologisches Institut (DAI)
Zentrale Berlin, IT-Referat
* Projekt "Stunde Null" *
___
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] Affine transformation code in Georeferencer -- incomplete?

[Benjamin Ducke]

FYI,

The pure C (+Java bindings) version of the transformation
methods in the QGIS georeferencer is now available here:

https://svn.code.sf.net/p/gvsigce/code/trunk/libraries/libCTL

I realize that this won't be of immediate interest for QGIS
folks, but I would nevertheless like to thank you all for
taking the time to answer my questions on this list.

If anyone here does find my C/Java conversion useful, then
I'd be thankful for any tests/comments.

Cheers,

Ben

On 05/05/15 11:41, Benjamin Ducke wrote:
 On 05/05/15 11:20, Olivier Dalang wrote:
 Hi,

 If I'm correct, the QgsLeastSquares::affine() method is used when
 creating a worldfile, and it seems it does not account for rotation (at
 least the generated worldfiles don't).
 
 Ok, that explains a lot.
 

 Not really sure of what you're trying to do,
 
 I am trying to extract the transformation methods
 to plain C. I find that they are nicely designed and
 compact, with GNU Scientific Library (also a plain C
 lib) being the only dependency. I am not aware of any
 other simple C lib for such transformations and I would
 like to make the excellent QGIS implementations of
 Helmert and projective transformations available to
 C and Java (via JNI bindings) programmers. Granted,
 affine transformations are usually easier to find,
 but for the sake of completeness...
 
 but just in case, here's my
 implementation to compute worldfile parameters with rotation too (I had
 no time to port to core yet) : 

 https://gist.github.com/olivierdalang/ba97fc986ade4545068d

 
 Thanks! I will take a look. Maybe this already contains
 all I am searching for.
 
 Cheers,
 
 Ben
 
 Best,

 Olivier




 2015-05-04 10:35 GMT+02:00 Benjamin Ducke bendu...@fastmail.fm
 mailto:bendu...@fastmail.fm:

 Dear Devs --

 I am currently converting the transformation methods
 in the QGIS Georeferencer to plain C.
 So far, I have been able to extract and convert the
 projective and Helmert transformations.

 However, the code for the affine transformation seems
 incomplete.

 Looking here:

 
 https://github.com/qgis/QGIS/trunk/src/plugins/georeferencer/qgsleastsquares.cpp

 I find this method:

 void QgsLeastSquares::affine()

 It computes a 6x6 transformation matrix but stops there.
 In analogy to QgsLeastSquares::helmert(), I _think_
 the next step should be to extract the rotation, scaling,
 translation and shearing vectors using gsl_vector_get().

 It seems to me that QgsLeastSquares::affine() has been
 abandoned code for a while and that the affine transformation
 is now delegated to gdal_warp(?).

 Does anyone here still remember how to extract the affine
 components from the 6x6 matrix? I have done some extensive
 searching on the web but came up empty. Any pointers would
 be greatly appreciated.

 Cheers,

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


 
 
 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Affine transformation code in Georeferencer -- incomplete?

[Benjamin Ducke]

On 05/05/15 11:20, Olivier Dalang wrote:
 Hi,
 
 If I'm correct, the QgsLeastSquares::affine() method is used when
 creating a worldfile, and it seems it does not account for rotation (at
 least the generated worldfiles don't).

Ok, that explains a lot.

 
 Not really sure of what you're trying to do,

I am trying to extract the transformation methods
to plain C. I find that they are nicely designed and
compact, with GNU Scientific Library (also a plain C
lib) being the only dependency. I am not aware of any
other simple C lib for such transformations and I would
like to make the excellent QGIS implementations of
Helmert and projective transformations available to
C and Java (via JNI bindings) programmers. Granted,
affine transformations are usually easier to find,
but for the sake of completeness...

 but just in case, here's my
 implementation to compute worldfile parameters with rotation too (I had
 no time to port to core yet) : 
 
 https://gist.github.com/olivierdalang/ba97fc986ade4545068d
 

Thanks! I will take a look. Maybe this already contains
all I am searching for.

Cheers,

Ben

 Best,
 
 Olivier
 
 
 
 
 2015-05-04 10:35 GMT+02:00 Benjamin Ducke bendu...@fastmail.fm
 mailto:bendu...@fastmail.fm:
 
 Dear Devs --
 
 I am currently converting the transformation methods
 in the QGIS Georeferencer to plain C.
 So far, I have been able to extract and convert the
 projective and Helmert transformations.
 
 However, the code for the affine transformation seems
 incomplete.
 
 Looking here:
 
 
 https://github.com/qgis/QGIS/trunk/src/plugins/georeferencer/qgsleastsquares.cpp
 
 I find this method:
 
 void QgsLeastSquares::affine()
 
 It computes a 6x6 transformation matrix but stops there.
 In analogy to QgsLeastSquares::helmert(), I _think_
 the next step should be to extract the rotation, scaling,
 translation and shearing vectors using gsl_vector_get().
 
 It seems to me that QgsLeastSquares::affine() has been
 abandoned code for a while and that the affine transformation
 is now delegated to gdal_warp(?).
 
 Does anyone here still remember how to extract the affine
 components from the 6x6 matrix? I have done some extensive
 searching on the web but came up empty. Any pointers would
 be greatly appreciated.
 
 Cheers,
 
 Ben
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
 
 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Affine transformation code in Georeferencer -- incomplete?

[Benjamin Ducke]

Dear Devs --

I am currently converting the transformation methods
in the QGIS Georeferencer to plain C.
So far, I have been able to extract and convert the
projective and Helmert transformations.

However, the code for the affine transformation seems
incomplete.

Looking here:

https://github.com/qgis/QGIS/trunk/src/plugins/georeferencer/qgsleastsquares.cpp

I find this method:

void QgsLeastSquares::affine()

It computes a 6x6 transformation matrix but stops there.
In analogy to QgsLeastSquares::helmert(), I _think_
the next step should be to extract the rotation, scaling,
translation and shearing vectors using gsl_vector_get().

It seems to me that QgsLeastSquares::affine() has been
abandoned code for a while and that the affine transformation
is now delegated to gdal_warp(?).

Does anyone here still remember how to extract the affine
components from the 6x6 matrix? I have done some extensive
searching on the web but came up empty. Any pointers would
be greatly appreciated.

Cheers,

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

Re: [Qgis-developer] Using the power of GPU/OpenCL

[Benjamin Ducke]

Hi All,

As was stated before,
the real art about making use of OpenCL is not so
much learning the API, but understanding how
to parallelize your algorithms. One of the big
challenges therefore is that you need to learn
OpenCL and parallel programming in -- well --
parallel!

Essentially, whenever you see a chance to process
data in segments, and don't have to process all of
it in one go, there is a good chance that you
can get major speed-ups out of OpenCL. I would think
that this applies to a lot of raster processing.

Luckily, there is (finally) a thorough
and very understandable text book coming up:

http://www.manning.com/scarpino2/

This has all the information on the topic 
in one place. It's been written with C/C++
coders in mind. I have been part of the review
process for this book, so don't take my recommendation
as unbiased!

OpenCL, btw., is not just for GPUs. It is a parallel
programming framework that also covers (multi-core)
CPUs, so it can fallback on those boring things if
no GPUs are available. In that case your code
might suffer from (minor) API overhead, but it should 
not be necessary to have separate versions of the code.

Cheers,

Ben

- Original Message -
 Hi Andreas
 
 On Fri, Aug 12, 2011 at 11:28 AM, Andreas Neumann
 a.neum...@carto.net wrote:
  Hi,
 
  Now that Martin is including Multithreading Support, I am also
  wondering if
  it would be feasible to also profit from the computing power of GPUs
  and libraries, such as OPENCL. Seems like mobile devices, servers
  and regular
  desktops would benefit. Would the Qgis architecture allow the usage
  of OpenCL?
 
  I am not a dev, but am reading about these new technical options ...
 
 Given that more and more computers come with powerful GPUs it really
 makes sense to explore what are the possibilities for speed
 improvements. In general you can either use a library that implements
 some algorithms on GPU or you can start writing your own GPU code for
 the algorithm (or some parts of it).
 
 The speedup will vary greatly depending on the algorithm. Things like
 3D rendering, image processing, video compression etc. are perfectly
 suited for GPU implementation because one computationally intensive
 routine is used in parallel for millions of independent pixels.
 However many other algorithms will not perform better on GPU. These
 are typically the ones that are not parallel or their bottleneck is
 not in computation - many algorithms have bottlenecks in I/O or they
 need to wait for some resources.
 
 First we would have to identify what is slow and should be optimized.
 Then do some profiling to find out in what parts most of the time is
 spent. If those parts are computationally intensive and parallelizable
 then it is a candidate for GPU implementation. My impression is that
 there are very few places in QGIS where we would gain performance with
 GPU because typically we delegate computation to underlying libraries
 and/or the slowness is caused by I/O. And various pieces of
 functionality are slow just because inefficient or naive algorithms
 are used.
 
 When implementing an algorithm on GPU we still would need to provide
 original implementation if no OpenCL-capable device is found. So this
 adds additional burden on maintainance to ensure that both CPU and GPU
 implementations give equivalent results.
 
 To summarize: yes, it would be possible to use GPU for some tasks, but
 GPU is not a magic wand. Computationally intensive tasks really can be
 improved (even by factors of 100), but many other tasks would not get
 faster.
 
 What are the areas where you think QGIS should be faster?
 
 Martin
 ___ Qgis-developer mailing
 list Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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

Re: [Qgis-developer] QGIS vs gvSIG

[Benjamin Ducke]

Hi Paolo (all) --

- Original Message -

[SNIP]

 I didn't like their development model: AFAICT, there is a commercial
 association of all gvsig devs; this has a strong potential for a
 monopoly.

That's precisely why a number of users and external developers, 
including myself, have now forked off the gvSIG Community Edition (CE).

We are still in the process of building up the web infrastructure,
but the mailing lists are already active and you can read up on
progress in the list archives (the most active one is currently 
the community list):

  http://sourceforge.net/projects/gvsigce/
  http://sourceforge.net/mail/?group_id=343517

Cheers,

Ben

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


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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

Re: [Qgis-developer] QGIS vs gvSIG

[Benjamin Ducke]

OK, folks, let this be the last email to the QGIS list
on this topic! We should really continue the discussion 
on the gvSIG CE community list, which is the right
forum for this.

I am copying this reply to the gvSIG CE list, so we can 
pick up this conversation where we left.

For those who are interested from a general open source
GIS point of view (btw., I strongly believe that the
open source GIS community will benefit more from diversity
than from one project taking the lead over all other),
here's a quick summary:

- gvSIG OADE was created because the official gvSIG
development had stalled for the 1.x branch at version 
1.9 in 2009, a disastrously buggy version, and 
resources were reassigned to 2.0, which until this day 
has failed to materialize.

- gvSIG CE (release 1.0) will be based on the last
release of gvSIG OADE (2010), plus all relevant
patches for gvSIG 1.11/1.12 that have accumulated
in the meantime, plus whatever the gvSIG CE devs
contribute.

- gvSIG CE will be completely open source and follow
the same principles and practices as e.g. QGIS and
GRASS GIS

- There is strong cooperation with SEXTANTE, which
is by now an integral part of gvSIG, and we do our
best to synchronize releases.

- A sync of gvSIG CE with gvSIG 2.0 might happen if
and when a stable release of the 2.x branch gets out
that is up to par with 1.x in terms of user visible
features/advantages.

Best (and apologies to the QGIS people who had
to put up with all this gvSIG talk on their list),

Ben

- Original Message -
 2011/6/23  jr.morre...@enoreth.net 
 
 
 Is this fork going to stay in sync with gvsig's trunk or is it going
 its own seperate path ? I thought that after last year's talks about
 differences between your OA edition and the official (but not public)
 tree the situation would have improved.
 
 What are you referring to with the not public tree?
 Benjamin will answer officially, but the CE edition will try to keep
 the sync with the official trunk. At now the CE trunk contains a gvSIG
 1.9 snapshot (the same of the OADE edition), but will be upgraded soon
 to gvSIG 1.11, which is the latest release.
 A critical moment will be the release of gvSIG 2.0, which will be a
 deep refactoring of the core code structure. When it will happen the
 development and maintanance forces should be split between the 1.1x
 series and the new... I cross my fingers!
 
 giovanni
 
 
 
 
 
 
 
 On Thu, 23 Jun 2011 09:21:25 +0100 (BST), Benjamin Ducke wrote:
 
 
 Hi Paolo (all) --
 
 - Original Message -
 
 [SNIP]
 
 
 
 I didn't like their development model: AFAICT, there is a commercial
 association of all gvsig devs; this has a strong potential for a
 monopoly.
 
 That's precisely why a number of users and external developers,
 including myself, have now forked off the gvSIG Community Edition
 (CE).
 
 We are still in the process of building up the web infrastructure,
 but the mailing lists are already active and you can read up on
 progress in the list archives (the most active one is currently
 the community list):
 
 http://sourceforge.net/ projects/gvsigce/
 http://sourceforge.net/mail/? group_id=343517
 
 Cheers,
 
 Ben
 
 
 
 __ _ Qgis-developer
 mailing list Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/ mailman/listinfo/qgis- developer
 
 
 -- Files attached to this email may be in ISO 26300 format (OASIS
 Open Document Format). If you have difficulty opening them, please
 visit
 http://iso26300.info for more information.
 
 __ _
 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


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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

[Qgis-developer] QGIS project files won't transfer from one PC to another

[Benjamin Ducke]

Dear list --

I have had feedback from some QGIS (1.6) users at work
that a QGIS project saved on one PC fails to
open on another (in fact, it makes QGIS crash).

I have taken a good, long look at the project
file. It contains links to raster images (some
in GIF format), Shapefiles and spatial tables
in a PostGIS DBMS. But none of them look particularly
suspicious. I am baffled by this.

Does anyone here have a bright idea why there 
could be a problem with opening a QGIS project
file that was saved on a different PC (all of
them being Windows XP, and in the same local
network)?

Thanks,

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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