Re: [Qgis-user] Atlas - generation for one object

[Phil (The Geek) Wyatt]

You can also create that polygon grid layer by using the Vector, Research 
Tools, Vector grid and basing the grid on the bounds of your single object.

 

Cheers - Phil

 

From: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of 
AVICOMARTIN
Sent: Friday, September 23, 2016 1:00 AM
To: qgis-user@lists.osgeo.org
Subject: Re: [Qgis-user] Atlas - generation for one object

 

Yes, there is.
You can define a layer with rectangles that cover your linear object (size and 
position acording to the scale you want) and create atlas using this rectangle 
layer

El 22/09/2016 a las 14:24, Szymon Guza escribió:

Hello,

I want to create an atlas for one object. This object is linear (transmedia - 
fiber cable) and I want to generate its course on several pages in fixed scale 
(because the cable is "too long" to fit on one page).

Is there a possibility to do that?

Szymon






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

 

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

Re: [Qgis-user] Atlas wont export a table when there are too few records

[Nyall Dawson]

On 21 September 2016 at 02:27, James Stott  wrote:
> Hi,
>
> I have a composer and I use the atlas functionality to create PDFs. I have
> point features, and these are contained within different zones. I use atlas
> to create a map of each zone.
>
> The layout is 2 pages, the first page is the map, the 2nd page is a table,
> made up of 5 frames so I have space for around 250 features in the table.
>
> The table displays correctly when I preview the composers in QGIS, but when
> I try to export to PDF, it refuses to export some of the pages with the
> tables on (about 5 out of 20 zones). It seems like the pages it wont export
> are where there is under a certain number of points within the atlas
> feature.

What do you mean by "refuses to export"? Does it show an error? Leaves
the pages out of the export? Or exports blank pages?

Would you be able to share your project + data ?

Nyall



>
> I can get around this if I make the frames smaller in height, but then I
> cant get all the features in the table for some of my zones.
>
> Is anyone else getting this problem? I cant share my actual data, and I dont
> have time at the moment to see if this happens with other random data. I can
> try to recreate next week, but just wondered if anyone else is struggling
> with this problem too.
>
> James
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] build QGIS Server - can QT support be disable?

[Luigi Pirelli]

QT is a framework not only GUI library and qgis server, that use qgis
libs, is heavely based on QT, so you need it!

the simpler solution is to run qgi server in a docker container;

e.g.
https://github.com/kartoza/docker-qgis-server
or
https://github.com/elpaso/qgis-server-docker

regards
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 22 September 2016 at 21:15, Eduardo Kanegae
 wrote:
> hi there,
>
> I'm running a CentOS 6.8, kernel 2.6.32 x86_64 and I'm trying to build
> QGIS Server, based on qgis LTR 2.14.6 sources.
>
> After trying to configure using ccmake, I got the error:
>
> ###
> CMake Error at 
> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108
> (message):
>Could NOT find Qt4: Found unsuitable version "4.6.2", but required is at
>least "4.8.0" (found /usr/bin/qmake-qt4)
>  Call Stack (most recent call first):
>/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:313
> (_FPHSA_FAILURE_MESSAGE)
>/usr/share/cmake/Modules/FindQt4.cmake:1393
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>CMakeLists.txt:277 (FIND_PACKAGE)
> ###
>
> The default yum install gaves me qt4.6.x but I was wondering if is
> there any way to turn off QT support because I won't need any GUI
> functions,
> I just need QGIS Server at this machine. Or am I wrong? Do we need QT4
> or QT5 for building  QGIS Server too, as well in QGIS Desktop cases?
>
> thanks in advance,
>
>
> Eduardo Kanegae
>
> http://www.webmapit.com.br | @webmapit
> https://soundcloud.com/ekanegae
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] build QGIS Server - can QT support be disable?

[Eduardo Kanegae]

hi there,

I'm running a CentOS 6.8, kernel 2.6.32 x86_64 and I'm trying to build
QGIS Server, based on qgis LTR 2.14.6 sources.

After trying to configure using ccmake, I got the error:

###
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108
(message):
   Could NOT find Qt4: Found unsuitable version "4.6.2", but required is at
   least "4.8.0" (found /usr/bin/qmake-qt4)
 Call Stack (most recent call first):
   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:313
(_FPHSA_FAILURE_MESSAGE)
   /usr/share/cmake/Modules/FindQt4.cmake:1393
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
   CMakeLists.txt:277 (FIND_PACKAGE)
###

The default yum install gaves me qt4.6.x but I was wondering if is
there any way to turn off QT support because I won't need any GUI
functions,
I just need QGIS Server at this machine. Or am I wrong? Do we need QT4
or QT5 for building  QGIS Server too, as well in QGIS Desktop cases?

thanks in advance,


Eduardo Kanegae

http://www.webmapit.com.br | @webmapit
https://soundcloud.com/ekanegae
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Raster Interpolation by Attribute

[Nicolas Cadieux]

Hi,
The field needs to be identified as numbers (int, float...) for it to pop up. 
If its text, it will not work.
Nicolas

Envoyé de mon iPad

> Le 22 sept. 2016 à 12:19, azf100 [via OSGeo.org] 
>  a écrit :
> 
> When I use the interpolation plugin, I am able to select Input Vector Layers, 
> but not an Interpolation Attribute. When I click on the dropdown, nothing 
> happens. 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://osgeo-org.1560.x6.nabble.com/Raster-Interpolation-by-Attribute-tp5287324.html
> To start a new topic under Quantum GIS - User, email 
> ml-node+s1560n4125267...@n6.nabble.com 
> To unsubscribe from Quantum GIS - User, click here.
> NAML




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Raster-Interpolation-by-Attribute-tp5287324p5287333.html
Sent from the Quantum GIS - User mailing list archive at Nabble.com.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] EasyCustomLabeling

[Bia]

hi!

anyone has had problems with EasyCustomLabeling with very large files?
OR with memory save layer?

Tks!

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

[Qgis-user] Selected raster is not 8bits formated - QGS 2.16.2

[Hydro Spheric]

After upgrading to QGIS 2.16.2 I get the following error (spelling error not 
mine) when opening a geotiff file:
"Selected raster is not 8bits formated" 
The file opens fine however. 

When adding more rasters the file sometimes does, and sometimes doesn't pop up.
When closing the project the same error pops up for each open raster.

Is this a bug, and if so how can I report it?
Thanks,Bart
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

[QGIS-it-user] Fwd: Re: [Gruppo] Voti per progetti QGIS

[Salvatore Larosa]

> non ha molto senso dare i numeri... usare un sistema di survey/polling
via web
>
> es: https://www.easypolls.net/ o doodle

+1

Saluti,
-SL
___
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-it-user

Re: [Qgis-user] Atlas - generation for one object

[AVICOMARTIN]

Yes, there is.
You can define a layer with rectangles that cover your linear object 
(size and position acording to the scale you want) and create atlas 
using this rectangle layer


El 22/09/2016 a las 14:24, Szymon Guza escribió:

Hello,

I want to create an atlas for one object. This object is linear 
(transmedia - fiber cable) and I want to generate its course on 
several pages in fixed scale (because the cable is "too long" to fit 
on one page).


Is there a possibility to do that?

Szymon


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



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

[Qgis-user] Atlas - generation for one object

[Szymon Guza]

Hello,

I want to create an atlas for one object. This object is linear (transmedia
- fiber cable) and I want to generate its course on several pages in fixed
scale (because the cable is "too long" to fit on one page).

Is there a possibility to do that?

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

Re: [Qgis-user] [Qgis-developer] Discussion on the QGIS grant proposals

[Paolo Cavallini]

Hi Andreas,
thanks again for raising these important points.
My notes (also personal opinion, not to be intended as a PSC position)
below:

Il 22/09/2016 08:14, Neumann, Andreas ha scritto:

> --
> 
> Now comes my personal position/opinion - note that this is not the
> official opinion of the QGIS.ORG board.
> 
> I would personally welcome, if this round of the QGIS grants program
> could focus on the QGIS 3.0 release.

Agreed, a critical point for QGIS future.

> I personally also think that the QGIS grants program, at least at the
> current time, should not pay for development of new features (at least
> not features visible in the GUI for the users). These features can
> be "relatively easy" funded by companies and government organizations
> out there. So our limited QGIS.ORG funds should be rather spent a) to
> community work or b) infrastructure work or c) development work in the
> core of QGIS, such as API modifications, code redesign - stuff that
> isn't really visible to the users, but essential for the success of the
> project.

Agreed, that's one of the reasons we started this program.

> Documentation and PyQT documentation work is already budgeted in our
> annual budget. The money for 2016 hasn't even been spent for both items.
> So I think we should first use the budgeted money for such work. I think
> that user and developer documentation should be an ongoing effort and
> should be supported every year, und budgeted every year as such. We can
> increase the documentation budget positions next year, should it be
> necessary. In reality, it was more a lack of people willing to do the
> work, rather than a lack of funding. So, I am happy to see some
> proposals around documentation and developer documentation - so it seems
> that we have some volunteers. I just suggest that we consider
> documentation work separately and do it anyway - regardless of the
> outcome of the voting on these items.

It makes sense to me.

> Several proposals have a very limited local focus, only useful to one
> single country, or a very limited subset of our users. I suggest that
> such proposals could best be financed by local user groups or interest
> groups. It can't be the purpose of the QGIS grants program to finance
> such projects.

Fully agreed.

One other important point: the reason I originally proposed the grant
programme was to recognize the huge volunteer work several people are
donating to the project, and to help keeping their motivation high.

My suggestion is therefore to prioritize the projects by the people you
feel/know have contributed most to the project until now.

All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [Qgis-developer] Discussion on the QGIS grant proposals

[Nyall Dawson]

>> 2) Implement a flexible properties framework in QGIS
>>
>> This is the kind of under-the-hood API changes and improvements I
>> mentioned above. Stuff that brings our project forward, but under
>> the hood - not visible for the user. This is the basis that later
>> follow-up work can than build upon and benefit from. Stuff that later
>> can also be funded by organizations/companies. Also time critical, to
>> be done as soon as possible. Early in the 3.x life cycle when API
>> changes are still possible.
>
> I also consider this one important, but it may be introduced later on.

Just to clarify (since I'm not sure if it was explicitly noted in the
proposal) - this is more or less a happens-during-api-break or doesn't
happen at all type change. To do it and maintain existing api would
result in 1.5-2x the work required, and a horrible mixed api with many
deprecated methods for the lifecycle of 3.x.

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

Re: [Qgis-user] [Qgis-developer] Discussion on the QGIS grant proposals

[Karl-Magnus Jönsson]

Hi,
As a user and not (yet) a voting member or developer I can just agree with 
Andreas and Vincent. The QGIS grant program, at least now, should focus on QGIS 
3 release, broad under the hood structural changes that moves QGIS into a 
better and more stable platform and not narrow or local features more easily 
funded in other ways.

Regards
Karl-Magnus Jönsson
Kristianstads kommun

-Ursprungligt meddelande-
Från: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] För Vincent Picavet 
(ml)
Skickat: den 22 september 2016 10:10
Till: Neumann, Andreas; QGIS Developers List; QGIS User List
Ämne: Re: [Qgis-user] [Qgis-developer] Discussion on the QGIS grant proposals

Hello,

Thanks Andreas for raising this topic and clearing up facts and giving your 
position.
I agree 100% with what you stated, and I do think this is something which 
should be emphasized much more, if not even constrained.

Some more notes below.

On 22/09/2016 08:14, Neumann, Andreas wrote:
> [..] Now comes my personal position/opinion - note that this is not 
> the official opinion of the QGIS.ORG board.
Same here

> I would personally welcome, if this round of the QGIS grants program 
> could focus on the QGIS 3.0 release.

This is indeed the main challenge for QGIS in the coming months.
Focusing on all aspects of making QGIS3 a real thing should be our top priority 
when confronted to choices.

> I personally also think that the QGIS grants program, at least at the 
> current time, should not pay for development of new features (at least 
> not features visible in the GUI for the users). These features can be 
> "relatively easy" funded by companies and government organizations out 
> there. So our limited QGIS.ORG funds should be rather spent a) to 
> community work or b) infrastructure work or c) development work in the 
> core of QGIS, such as API modifications, code redesign - stuff that 
> isn't really visible to the users, but essential for the success of 
> the project.

From a developer's company point of view, I can only applause to this.
We have numerous demands for new features with paid contract, and the global 
pace of feature development in QGIS is really fast. The very large majority of 
them are funded by clients.
Meanwhile, all tasks like refactoring, code cleaning, bug triaging, 
infrastructure and long term core development efforts are really difficult to 
get funded. Public sector organization generally can't pay for this due to 
public tender bid constraints, and generally end-users do not realize that this 
kind of work is at the same time necessary and time consuming.
In my opinion, the role of QGIS organization, hence the QGIS Grant program, is 
to compensate for this disequilibrium.

> Documentation and PyQT documentation work is already budgeted in our 
> annual budget. The money for 2016 hasn't even been spent for both 
> items. So I think we should first use the budgeted money for such 
> work. I think that user and developer documentation should be an 
> ongoing effort and should be supported every year, und budgeted every 
> year as such. We can increase the documentation budget positions next 
> year, should it be necessary. In reality, it was more a lack of people 
> willing to do the work, rather than a lack of funding. So, I am happy 
> to see some proposals around documentation and developer documentation 
> - so it seems that we have some volunteers. I just suggest that we 
> consider documentation work separately and do it anyway - regardless 
> of the outcome of the voting on these items.

Documentation is crucial, and I am also fully in favor of having a dedicated 
yearly budget to improve it. It should be stated in the QGIS grant application 
call too.

> Several proposals have a very limited local focus, only useful to one 
> single country, or a very limited subset of our users. I suggest that 
> such proposals could best be financed by local user groups or interest 
> groups. It can't be the purpose of the QGIS grants program to finance 
> such projects.

+1 also

Since I have more or less the same priority list as Andreas, I will also add a 
few comments below.

> ---
> 
> Here is my own personal list of priorities:

In my own priority order :

> ​11)​ Introduce everything necessary for QGIS3 to OSGeo4W
> 
> The majority of our users are on Windows (like it or not). This is the 
> platform that matters most in our user base. The introduction of QGIS 
> 3.0 means porting everything to newer libraries and means a lot of 
> work. This should be one of our main priorities. Jürgen does it works 
> silently in the background many days of work each year that go 
> unnoticed. Jürgen usually only hears complaints if something fails - 
> maybe not so much praise. Having Windows nightly builds and releases 
> early on in the life cycle of QGIS 3.x means that it can be well 
> tested. So - also really important to our project.

This is to me 

Re: [Qgis-user] QField

[Matthias Kuhn]

Hi Andreas,

It's all on the page in the QField docs on the link in my last mail :)

Matthias

On 09/22/2016 10:06 AM, Neumann, Andreas wrote:
> Hi Matthias,
> 
> Oh - thanks for the hint. So probably Reginald is just missing the
> pyramids in the geopackage - to be created, f.e. with gdaladdo.
> 
> Andreas
> 
> On 2016-09-22 09:56, Matthias Kuhn wrote:
> 
>> QField does not (yet) support tiff with jpeg compression.
>>
>> See:
>> http://www.qfield.org/docs/project-management/dataformat.html#raster-data
>>
>> GeoPackage worked quite nice in our experience and can also be built
>> in different resolutions (same page further down).
>>
>> Matthias
>>
>>
>> On 09/22/2016 09:37 AM, Neumann, Andreas wrote:
>>> Hi Reginald,
>>>
>>> You can use the JPEG compression inside Geotiff. Note that this can be
>>> specified separately for both the full resolution and the pyramids. You
>>> can also select the compression factor to decrease the file size in
>>> trade off with quality.
>>>
>>> See
>>> also http://www.gdal.org/frmt_gtiff.html and
>>> http://www.gdal.org/gdaladdo.html for
>>> details.
>>>
>>> I believe that modern QGIS versions have these options exposed in the
>>> GUI, but probably not as default.
>>>
>>> So maybe there is room for potential to get a smaller size Geotiff.
>>>
>>> Greetings,
>>> Andreas
>>>
>>> On 2016-09-22 09:32, Reginald Carlier wrote:
>>>
 Thanks Andreas,

  

 Creating a Geotiff with pyramids did the trick. The only disadvantage
 is that it created a file of about 1.7 GB (the original was 90 MB).

 Now I am ready to test the app J.

  

 Regards,

  

 *Van:*Neumann, Andreas [mailto:a.neum...@carto.net
 ]
 *Verzonden:* woensdag 21 september 2016 16:19
 *Aan:* Reginald Carlier
 *Onderwerp:* Re: [Qgis-user] QField

  

 Hi Reginald,

 Did you create pyramids in the gpkg rasters?

 Generally, Geotiff should be well supported - definitely more tested
 than gpkg rasters. I had a 1GB geotiff on qfield (on SD-Card) and it
 displays fast. I haven't tested vrt files with geotiffs - if it works
 as well?

 Andreas

 On 2016-09-21 15:44, Reginald Carlier wrote:

 Hi Erwan,

  

 You can look in the list of last week where I posted a couple of
 questions about qfield and was pointed to the right website for
 documentation.

 I succeeded to publish a map on my phone but the aereal photo
 which was published as a gpkg file doesn't render. When I use the
 raster.gpkg on my desktop it renders but very slow.

 The gpkg file was created from a 90 MB jp2 file.

  

 Regards,

  

  

  

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

  

  

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

Re: [Qgis-user] [Qgis-developer] Discussion on the QGIS grant proposals

[Vincent Picavet (ml)]

Hello,

Thanks Andreas for raising this topic and clearing up facts and giving
your position.
I agree 100% with what you stated, and I do think this is something
which should be emphasized much more, if not even constrained.

Some more notes below.

On 22/09/2016 08:14, Neumann, Andreas wrote:
> [..] Now comes my personal position/opinion - note that this is not
> the official opinion of the QGIS.ORG board.
Same here

> I would personally welcome, if this round of the QGIS grants program 
> could focus on the QGIS 3.0 release.

This is indeed the main challenge for QGIS in the coming months.
Focusing on all aspects of making QGIS3 a real thing should be our top
priority when confronted to choices.

> I personally also think that the QGIS grants program, at least at
> the current time, should not pay for development of new features (at
> least not features visible in the GUI for the users). These features
> can be "relatively easy" funded by companies and government
> organizations out there. So our limited QGIS.ORG funds should be
> rather spent a) to community work or b) infrastructure work or c)
> development work in the core of QGIS, such as API modifications, code
> redesign - stuff that isn't really visible to the users, but
> essential for the success of the project.

From a developer's company point of view, I can only applause to this.
We have numerous demands for new features with paid contract, and the
global pace of feature development in QGIS is really fast. The very
large majority of them are funded by clients.
Meanwhile, all tasks like refactoring, code cleaning, bug triaging,
infrastructure and long term core development efforts are really
difficult to get funded. Public sector organization generally can't pay
for this due to public tender bid constraints, and generally end-users
do not realize that this kind of work is at the same time necessary and
time consuming.
In my opinion, the role of QGIS organization, hence the QGIS Grant
program, is to compensate for this disequilibrium.

> Documentation and PyQT documentation work is already budgeted in our 
> annual budget. The money for 2016 hasn't even been spent for both
> items. So I think we should first use the budgeted money for such
> work. I think that user and developer documentation should be an
> ongoing effort and should be supported every year, und budgeted every
> year as such. We can increase the documentation budget positions next
> year, should it be necessary. In reality, it was more a lack of
> people willing to do the work, rather than a lack of funding. So, I
> am happy to see some proposals around documentation and developer
> documentation - so it seems that we have some volunteers. I just
> suggest that we consider documentation work separately and do it
> anyway - regardless of the outcome of the voting on these items.

Documentation is crucial, and I am also fully in favor of having a
dedicated yearly budget to improve it. It should be stated in the QGIS
grant application call too.

> Several proposals have a very limited local focus, only useful to
> one single country, or a very limited subset of our users. I suggest
> that such proposals could best be financed by local user groups or
> interest groups. It can't be the purpose of the QGIS grants program
> to finance such projects.

+1 also

Since I have more or less the same priority list as Andreas, I will also
add a few comments below.

> ---
> 
> Here is my own personal list of priorities:

In my own priority order :

> ​11)​ Introduce everything necessary for QGIS3 to OSGeo4W
> 
> The majority of our users are on Windows (like it or not). This is
> the platform that matters most in our user base. The introduction of
> QGIS 3.0 means porting everything to newer libraries and means a lot
> of work. This should be one of our main priorities. Jürgen does it
> works silently in the background many days of work each year that go
> unnoticed. Jürgen usually only hears complaints if something fails -
> maybe not so much praise. Having Windows nightly builds and releases
> early on in the life cycle of QGIS 3.x means that it can be well
> tested. So - also really important to our project.

This is to me the most important item for QGIS3. Jef does a huge work,
something difficult and not the most passionating thing to work on. We
do need to have the platform stable and ready as soon as possible to
have feedback on QGIS 3 very early in the release process.

> ​18)​ QGIS 3 ticket handling and API refactoring
> 
> This is really time critical, and past discussions around QGIS 3.0
> has shown that there is a lack of project management work and
> coordination. I regard this proposal as very useful for the QGIS 3.0
> release.

Disclaimer : This proposal is by Oslandia
We proposed this item exactly because we observed that we were lacking
project management efforts, and especially regarding the QGIS3 release.
Having time 

Re: [Qgis-user] QField

[Neumann, Andreas]

Hi Matthias, 

Oh - thanks for the hint. So probably Reginald is just missing the
pyramids in the geopackage - to be created, f.e. with gdaladdo. 

Andreas 

On 2016-09-22 09:56, Matthias Kuhn wrote:

> QField does not (yet) support tiff with jpeg compression.
> 
> See:
> http://www.qfield.org/docs/project-management/dataformat.html#raster-data
> 
> GeoPackage worked quite nice in our experience and can also be built in 
> different resolutions (same page further down).
> 
> Matthias
> 
> On 09/22/2016 09:37 AM, Neumann, Andreas wrote: Hi Reginald,
> 
> You can use the JPEG compression inside Geotiff. Note that this can be
> specified separately for both the full resolution and the pyramids. You
> can also select the compression factor to decrease the file size in
> trade off with quality.
> 
> See
> also http://www.gdal.org/frmt_gtiff.html and 
> http://www.gdal.org/gdaladdo.html for
> details.
> 
> I believe that modern QGIS versions have these options exposed in the
> GUI, but probably not as default.
> 
> So maybe there is room for potential to get a smaller size Geotiff.
> 
> Greetings,
> Andreas
> 
> On 2016-09-22 09:32, Reginald Carlier wrote:
> 
> Thanks Andreas,
> 
> Creating a Geotiff with pyramids did the trick. The only disadvantage
> is that it created a file of about 1.7 GB (the original was 90 MB).
> 
> Now I am ready to test the app J.
> 
> Regards,
> 
> *Van:*Neumann, Andreas [mailto:a.neum...@carto.net]
> *Verzonden:* woensdag 21 september 2016 16:19
> *Aan:* Reginald Carlier
> *Onderwerp:* Re: [Qgis-user] QField
> 
> Hi Reginald,
> 
> Did you create pyramids in the gpkg rasters?
> 
> Generally, Geotiff should be well supported - definitely more tested
> than gpkg rasters. I had a 1GB geotiff on qfield (on SD-Card) and it
> displays fast. I haven't tested vrt files with geotiffs - if it works
> as well?
> 
> Andreas
> 
> On 2016-09-21 15:44, Reginald Carlier wrote:
> 
> Hi Erwan,
> 
> You can look in the list of last week where I posted a couple of
> questions about qfield and was pointed to the right website for
> documentation.
> 
> I succeeded to publish a map on my phone but the aereal photo
> which was published as a gpkg file doesn't render. When I use the
> raster.gpkg on my desktop it renders but very slow.
> 
> The gpkg file was created from a 90 MB jp2 file.
> 
> Regards,
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

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

Re: [Qgis-user] QField

[Matthias Kuhn]

QField does not (yet) support tiff with jpeg compression.

See:
http://www.qfield.org/docs/project-management/dataformat.html#raster-data

GeoPackage worked quite nice in our experience and can also be built in 
different resolutions (same page further down).

Matthias


On 09/22/2016 09:37 AM, Neumann, Andreas wrote:
> Hi Reginald,
>
> You can use the JPEG compression inside Geotiff. Note that this can be
> specified separately for both the full resolution and the pyramids. You
> can also select the compression factor to decrease the file size in
> trade off with quality.
>
> See
> also http://www.gdal.org/frmt_gtiff.html and 
> http://www.gdal.org/gdaladdo.html for
> details.
>
> I believe that modern QGIS versions have these options exposed in the
> GUI, but probably not as default.
>
> So maybe there is room for potential to get a smaller size Geotiff.
>
> Greetings,
> Andreas
>
> On 2016-09-22 09:32, Reginald Carlier wrote:
>
> > Thanks Andreas,
> >
> >  
> >
> > Creating a Geotiff with pyramids did the trick. The only disadvantage
> > is that it created a file of about 1.7 GB (the original was 90 MB).
> >
> > Now I am ready to test the app J.
> >
> >  
> >
> > Regards,
> >
> >  
> >
> > *Van:*Neumann, Andreas [mailto:a.neum...@carto.net]
> > *Verzonden:* woensdag 21 september 2016 16:19
> > *Aan:* Reginald Carlier
> > *Onderwerp:* Re: [Qgis-user] QField
> >
> >  
> >
> > Hi Reginald,
> >
> > Did you create pyramids in the gpkg rasters?
> >
> > Generally, Geotiff should be well supported - definitely more tested
> > than gpkg rasters. I had a 1GB geotiff on qfield (on SD-Card) and it
> > displays fast. I haven't tested vrt files with geotiffs - if it works
> > as well?
> >
> > Andreas
> >
> > On 2016-09-21 15:44, Reginald Carlier wrote:
> >
> > Hi Erwan,
> >
> >  
> >
> > You can look in the list of last week where I posted a couple of
> > questions about qfield and was pointed to the right website for
> > documentation.
> >
> > I succeeded to publish a map on my phone but the aereal photo
> > which was published as a gpkg file doesn't render. When I use the
> > raster.gpkg on my desktop it renders but very slow.
> >
> > The gpkg file was created from a 90 MB jp2 file.
> >
> >  
> >
> > Regards,
> >
> >  
> >
> >  
> >
> >  
> >
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org 
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
> >
> >  
> >
> >  
> >
>  
>
>  
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
>

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

Re: [Qgis-user] QField

[Neumann, Andreas]

Hi Reginald, 

You can use the JPEG compression inside Geotiff. Note that this can be
specified separately for both the full resolution and the pyramids. You
can also select the compression factor to decrease the file size in
trade off with quality. 

See also http://www.gdal.org/frmt_gtiff.html and
http://www.gdal.org/gdaladdo.html for details. 

I believe that modern QGIS versions have these options exposed in the
GUI, but probably not as default. 

So maybe there is room for potential to get a smaller size Geotiff. 

Greetings,
Andreas 

On 2016-09-22 09:32, Reginald Carlier wrote:

> Thanks Andreas, 
> 
> Creating a Geotiff with pyramids did the trick. The only disadvantage is that 
> it created a file of about 1.7 GB (the original was 90 MB). 
> 
> Now I am ready to test the app J. 
> 
> Regards, 
> 
> VAN: Neumann, Andreas [mailto:a.neum...@carto.net] 
> VERZONDEN: woensdag 21 september 2016 16:19
> AAN: Reginald Carlier
> ONDERWERP: Re: [Qgis-user] QField 
> 
> Hi Reginald, 
> 
> Did you create pyramids in the gpkg rasters? 
> 
> Generally, Geotiff should be well supported - definitely more tested than 
> gpkg rasters. I had a 1GB geotiff on qfield (on SD-Card) and it displays 
> fast. I haven't tested vrt files with geotiffs - if it works as well? 
> 
> Andreas 
> 
> On 2016-09-21 15:44, Reginald Carlier wrote:
> 
>> Hi Erwan, 
>> 
>> You can look in the list of last week where I posted a couple of questions 
>> about qfield and was pointed to the right website for documentation. 
>> 
>> I succeeded to publish a map on my phone but the aereal photo which was 
>> published as a gpkg file doesn't render. When I use the raster.gpkg on my 
>> desktop it renders but very slow. 
>> 
>> The gpkg file was created from a 90 MB jp2 file. 
>> 
>> Regards, 
>> 
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user

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

Re: [Qgis-user] QField

[Reginald Carlier]

Thanks Andreas,

Creating a Geotiff with pyramids did the trick. The only disadvantage is that 
it created a file of about 1.7 GB (the original was 90 MB).
Now I am ready to test the app ☺.

Regards,

Van: Neumann, Andreas [mailto:a.neum...@carto.net]
Verzonden: woensdag 21 september 2016 16:19
Aan: Reginald Carlier
Onderwerp: Re: [Qgis-user] QField


Hi Reginald,

Did you create pyramids in the gpkg rasters?

Generally, Geotiff should be well supported - definitely more tested than gpkg 
rasters. I had a 1GB geotiff on qfield (on SD-Card) and it displays fast. I 
haven't tested vrt files with geotiffs - if it works as well?

Andreas

On 2016-09-21 15:44, Reginald Carlier wrote:
Hi Erwan,

You can look in the list of last week where I posted a couple of questions 
about qfield and was pointed to the right website for documentation.
I succeeded to publish a map on my phone but the aereal photo which was 
published as a gpkg file doesn’t render. When I use the raster.gpkg on my 
desktop it renders but very slow.
The gpkg file was created from a 90 MB jp2 file.

Regards,



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



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

[Qgis-user] Discussion on the QGIS grant proposals

[Neumann, Andreas]

Dear QGIS users, developers, voting members and user group
representatives, 

As you may have noticed, there is a first round of a QGIS grant program,
fueled by the donations and sponsorship money we received in the past
months. Tim Sutton, chair of the QGIS project, has publicized this
program repeatedly on several channels. 

The good thing is that we got some very good proposals. In total 18
proposals, adding up to a total grant sum of 101 k EUR. You can see all
proposals at
https://drive.google.com/file/d/0B__vDnQXCKiwYTIyWmRSbi1hMWM/view?usp%3Dsharing=D=1474526025402000=AFQjCNFhp43Lkxw3aBCed9-9luJpnR0oWg


Please note that we can only spend 20k EUR in this first round. So there
are tough decisions to make. Note that proposals that can't make it in
the first round, can be kept in a waiting list and may apply again in
the next round of a grants program. If a proposal can't be accepted in
the first round, this doesn't mean it isn't valuable and useful to the
QGIS.ORG project. 

The QGIS PSC will honor the opinion of the voting members, the OSGEO
representative and the user group representatives on how to spend this
limited money wisely. Alltogether a group of currently 27 people (13
qgis user group represenatives, 13 community voting members, 1 OSGEO
representative). This is kind of the "parliament" of the QGIS project
when it comes to such decisions. 

-- 

Now comes my personal position/opinion - note that this is not the
official opinion of the QGIS.ORG board. 

I would personally welcome, if this round of the QGIS grants program
could focus on the QGIS 3.0 release. 

I personally also think that the QGIS grants program, at least at the
current time, should not pay for development of new features (at least
not features visible in the GUI for the users). These features can be
"relatively easy" funded by companies and government organizations out
there. So our limited QGIS.ORG funds should be rather spent a) to
community work or b) infrastructure work or c) development work in the
core of QGIS, such as API modifications, code redesign - stuff that
isn't really visible to the users, but essential for the success of the
project.  

Documentation and PyQT documentation work is already budgeted in our
annual budget. The money for 2016 hasn't even been spent for both items.
So I think we should first use the budgeted money for such work. I think
that user and developer documentation should be an ongoing effort and
should be supported every year, und budgeted every year as such. We can
increase the documentation budget positions next year, should it be
necessary. In reality, it was more a lack of people willing to do the
work, rather than a lack of funding. So, I am happy to see some
proposals around documentation and developer documentation - so it seems
that we have some volunteers. I just suggest that we consider
documentation work separately and do it anyway - regardless of the
outcome of the voting on these items. 

Several proposals have a very limited local focus, only useful to one
single country, or a very limited subset of our users. I suggest that
such proposals could best be financed by local user groups or interest
groups. It can't be the purpose of the QGIS grants program to finance
such projects. 

--- 

Here is my own personal list of priorities: 

​18)​ QGIS 3 ticket handling and API refactoring 

This is really time critical, and past discussions around QGIS 3.0 has
shown that there is a lack of project management work and coordination.
I regard this proposal as very useful for the QGIS 3.0 release. 

​11)​ Introduce everything necessary for QGIS3 to OSGeo4W 

The majority of our users are on Windows (like it or not). This is the
platform that matters most in our user base. The introduction of QGIS
3.0 means porting everything to newer libraries and means a lot of work.
This should be one of our main priorities. Jürgen does it works silently
in the background many days of work each year that go unnoticed. Jürgen
usually only hears complaints if something fails - maybe not so much
praise. Having Windows nightly builds and releases early on in the life
cycle of QGIS 3.x means that it can be well tested. So - also really
important to our project. 

​2)​ Implement a flexible properties framework in QGIS 

This is the kind of under-the-hood API changes and improvements I
mentioned above. Stuff that brings our project forward, but under the
hood - not visible for the user. This is the basis that later follow-up
work can than build upon and benefit from. Stuff that later can also be
funded by organizations/companies. Also time critical, to be done as
soon as possible. Early in the 3.x life cycle when API changes are still
possible. 

​14)​ Project / Map layer registry refactoring 

Similar reasoning like item 2) above. Under the hood, necessary API
improvements. Also time critical, to be