[Qgis-developer] Changelog updates for 2.2.0
Hi all We have more or less finished writing up the changelog [1] for 2.2. If anyone has further suggestions of things that should go into the changelog, could you please create and account and add them, or just pop me an email. Also some of the entries could use some more detail, please feel free to send me extended notes. @Marco Hugentobler (or anyone else who can answer) can you please provide some background on the datum shift and dxf export features. How does the datum shift dialog get triggered and what do users of the feature need to know. Also for dxf export, is anyone able to provide a screenshot of a QGIS exported project loaded in a CAD app? @Paolo could you provide a definitive list of sponsors for me to add to the top of the changelog for 2.2.0? Before the release we will export the changelog to Restructured Text and it would be great if the docs team can incorporate it into the web site. [1] http://changelog.linfiniti.com/qgis/version/21/ -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Changelog updates for 2.2.0
Tim - What's the cut off date for editing the changelog? There's some additions/fixes to descriptions I'd like to make, but want to take maximum advantage of the pre-feature freeze cut off period before I get around to this... Nyall On 22 January 2014 19:00, Tim Sutton li...@linfiniti.com wrote: Hi all We have more or less finished writing up the changelog [1] for 2.2. If anyone has further suggestions of things that should go into the changelog, could you please create and account and add them, or just pop me an email. Also some of the entries could use some more detail, please feel free to send me extended notes. @Marco Hugentobler (or anyone else who can answer) can you please provide some background on the datum shift and dxf export features. How does the datum shift dialog get triggered and what do users of the feature need to know. Also for dxf export, is anyone able to provide a screenshot of a QGIS exported project loaded in a CAD app? @Paolo could you provide a definitive list of sponsors for me to add to the top of the changelog for 2.2.0? Before the release we will export the changelog to Restructured Text and it would be great if the docs team can incorporate it into the web site. [1] http://changelog.linfiniti.com/qgis/version/21/ -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ 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] Changelog updates for 2.2.0
Hi On Wed, Jan 22, 2014 at 10:13 AM, Nyall Dawson nyall.daw...@gmail.comwrote: Tim - What's the cut off date for editing the changelog? There's some additions/fixes to descriptions I'd like to make, but want to take maximum advantage of the pre-feature freeze cut off period before I get around to this... There is no specific cut off (other than the release date itself) but I would like to personally stop working on it as I have other things on my plate to deal with. Others feel free to add / revise entries as they see fit (with the obvious request that things are kept neat tidy). Regards Tim Nyall On 22 January 2014 19:00, Tim Sutton li...@linfiniti.com wrote: Hi all We have more or less finished writing up the changelog [1] for 2.2. If anyone has further suggestions of things that should go into the changelog, could you please create and account and add them, or just pop me an email. Also some of the entries could use some more detail, please feel free to send me extended notes. @Marco Hugentobler (or anyone else who can answer) can you please provide some background on the datum shift and dxf export features. How does the datum shift dialog get triggered and what do users of the feature need to know. Also for dxf export, is anyone able to provide a screenshot of a QGIS exported project loaded in a CAD app? @Paolo could you provide a definitive list of sponsors for me to add to the top of the changelog for 2.2.0? Before the release we will export the changelog to Restructured Text and it would be great if the docs team can incorporate it into the web site. [1] http://changelog.linfiniti.com/qgis/version/21/ -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] On the fly simplication of point layers
Hi Tim On Tue, Jan 21, 2014 at 3:41 AM, Tim Sutton li...@linfiniti.com wrote: Hi Alex On Mon, Jan 20, 2014 at 10:37 PM, Alex Mandel tech_...@wildintellect.com wrote: On 01/20/2014 12:29 PM, Tim Sutton wrote: Ok I guess you can see where I am going to go with this email :-) Is there any point to allowing users to simplify point layers? Alvaro, can your remove the point rendering tab in layer properties (and I guess check internally that you are not trying to simplify point layers)? Or is there a use case for point simplification that I am not getting? Yeah I am familiar with clustering (and would love to see it as a feature in QGIS), Actually the point displacement renderer already does clustering, though it lacks more options to customize how the clustered symbol would look like. Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] custom application: cannot open shared object file
Hi Denis
I think you just need to set the Run Environment of your project in Qt
Creator - add LD_LIBRARY_PATH or PATH environment variable (depending
on your system) pointing to the directory with QGIS libraries.
Regards
Martin
On Mon, Jan 20, 2014 at 11:32 PM, Denis Rouzaud denis.rouz...@gmail.com wrote:
Hi,
I am trying to create a custom application using QGIS API.
I am using Qt Creator and while running the app I get this error:
error while loading shared libraries: libqgis_core.so.2.1.0: cannot open
shared object file: No such file or directory
Here is the project file:
QT += core gui xml
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = hfp
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp
HEADERS += mainwindow.h
FORMS+= mainwindow.ui
win32:CONFIG(release, debug|release): \
LIBS += -L/$${QGISDIR}/lib/ -lqgis_core -lqgis_gui -lqgis_app
else:win32:CONFIG(debug, debug|release): \
LIBS += -L/$${QGISDIR}/lib/ -lqgis_core -lqgis_gui -lqgis_app
else:unix: \
QGISDIR = /home/denis/opt/qgis/Quantum-GIS \
LIBS += -L/$${QGISDIR}/build/output/lib/ -lqgis_core -lqgis_gui -lqgis_app
INCLUDEPATH += $${QGISDIR}/src \
$${QGISDIR}/src/core \
$${QGISDIR}/src/gui \
$${QGISDIR}/build/ \
DEFINES += GUI_EXPORT= CORE_EXPORT=
What am I missing here?
If you have any general comment regarding this project file, it is very
welcome... first time trying this.
Thanks a lot,
Denis
___
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] Atlas generation and scaling
Hi all - (sorry Martin for sending this question to your private mail first!) I have a question about Atlas generation and scaling: Does the Atlas generator respect scale settings defined under Project properties -- General -- Project scales when you're using the Margin around feature option in Atlas generation -- Scaling settings ? It would be nice to only have decent scale values in the atlas generated maps like 1:12.500, 1:20.000 or whatever instead of 1:11.123,24 Regards Bo Victor Thomsen Aestas-GIS Denmark ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Clustering algorithms from RISE
Hi Sergio On Mon, Jan 20, 2014 at 11:28 PM, Sergio Botero sergio...@gmail.com wrote: As one of the relatively new developers of Clusterpy, I have been looking into the possibility of making Clusterpy (a modified version) part of the Processing code. First I would like to know, do you think that this kind of algorithms area a good fit for the QGIS core? I also would like to know, what would be your proposed process to make this happen? anyone I should contact directly? I think the best thing to do for a start would be to create a Python plugin for QGIS that will use the Processing framework. Then you could upload the plugin to the repository [1], so the potential users will be able to seamlessly download and install it. If there would be a lot of interest from users to have the clustering functionality available in default installation of QGIS, we could discuss the inclusion of the code into QGIS codebase. Regards Martin [1] http://plugins.qgis.org/plugins/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Atlas generation and scaling
On 22 January 2014 20:26, Bo Victor Thomsen bo.victor.thom...@gmail.com wrote: Hi all - (sorry Martin for sending this question to your private mail first!) I have a question about Atlas generation and scaling: Does the Atlas generator respect scale settings defined under Project properties -- General -- Project scales when you're using the Margin around feature option in Atlas generation -- Scaling settings ? It would be nice to only have decent scale values in the atlas generated maps like 1:12.500, 1:20.000 or whatever instead of 1:11.123,24 No, it doesn't respect them currently. Can you please file a feature request for this at http://hub.qgis.org/issues? Cheers, Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] On the fly simplication of point layers
Hi On Wed, Jan 22, 2014 at 11:00 AM, Martin Dobias wonder...@gmail.com wrote: Hi Tim On Tue, Jan 21, 2014 at 3:41 AM, Tim Sutton li...@linfiniti.com wrote: Hi Alex On Mon, Jan 20, 2014 at 10:37 PM, Alex Mandel tech_...@wildintellect.com wrote: On 01/20/2014 12:29 PM, Tim Sutton wrote: Ok I guess you can see where I am going to go with this email :-) Is there any point to allowing users to simplify point layers? Alvaro, can your remove the point rendering tab in layer properties (and I guess check internally that you are not trying to simplify point layers)? Or is there a use case for point simplification that I am not getting? Yeah I am familiar with clustering (and would love to see it as a feature in QGIS), Actually the point displacement renderer already does clustering, though it lacks more options to customize how the clustered symbol would look like. Doesnt it do the reverse? i.e. when more than one point falls in the same place, it shifts them aside so they are all visible. If it can be made to produce a scaled symbol based on the number of underlying points that would be cool.That would also be a good time to change its name to 'Custer or displace' or something. Regards Tim Cheers Martin -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [QGIS-UX] option to disable font vectorization in labels
Hello, Le mardi 21 janvier 2014 21:45:16, Nyall Dawson a écrit : On 22/01/2014 4:56 am, Anita Graser anitagra...@gmx.at wrote: Am 21.01.2014, 10:24 Uhr, schrieb Vincent Mora vincent.m...@oslandia.com - a composer option: you make the choice when you export to svg, in this case you don't see the result until you open the svg Thanks for addressing this issue! For me, the most obvious place to put this option would be in the print composer. Maybe close to the print as raster option? I'm not a huge fan of this option, given that I'd like to keep the composer window as clear of clutter as possible. I think output format specific options like these (and saving svg to layers) should be put into a separate dialog which appears after the save file dialog. Much like how gimp/Photoshop/illustrator etc show a jpg quality dialog after choosing to save a file as jpg. The settings could either be remembered globally or per output filename. -1 for another dialog window. It makes the user have to set another step to export before having a result. If you want to export the same composition work multiple times with different file names you would have to set this every time. If you want QGIS to remember the settings, the user should have set it somewhere specifically. UX simplification is good, magic things happening behind the scene are not. Generally im am more in favor of a configure first, then execute way of working than the opposite. An intermediate solution could be to have an extended save as dialog box, with some options on the side. My ultimate goal (I was going to run this by the ux list) is to move infrequently used settings like resolution, page size/orientation, print as raster, etc and the atlas settings to their own composition properties dialog and then remove the need for the composition and atlas panels. Any thoughts on this? Same, more dialog boxes is a -1 for me, panels are quick and convenient, and give a fast overview of things. An option to hide or reduce them on the side would be preferable imho. Only my personal opinion for what it's worth. Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Reminder: Freeze starts on 2014-01-24 (4 days)
On Mon, Jan 20, 2014 at 10:15 PM, Tim Sutton li...@linfiniti.com wrote: Hi Regarding whether we should keep giving releases names, I think we should (big +1) for the following reasons: -1 for code names, see [1], it is all there what came to my mind: Version 4.0? Ha! Why would I use an easily-recognizable number that gives both a sense of the product history and clear indication of what I'm talking about when I can show off my 1337 status by calling it Ice Cream Sandwich,... * it (under our current scheme) pays homage to the hosts of our hackfests - lets be honest there isn't much reward in hosting it other than seeing your region represented in the release name Cannot it be done in a different way, maybe even more explicitly, for example a bottom bar on splash screen telling place/institution. * its a 'fun' part of our project culture and I would not like to see that we gradually remove everything that is fun and interesting about our project Fun for you, disaster for me. When it comes to code names, I always have to search a table of code names and translate it to a version number. Too old, stupid, ... probably, even such people are using QGIS. * users that I interact with often reference the release by its name, and I think it makes the individual releases more clearly distinguishable I would suggest a Latvian cartographer or place of interest. Then next release we can have a splash of some drunk guys wondering around Brighton on a Saturday night :-P If you insist on mountains/cartographers, please order them at least by height/birth day, that would be very helpful. Radim [1] http://gizmodo.com/5852191/enough-with-the-ridiculous-product-code-names Regards Tim On Mon, Jan 20, 2014 at 9:57 PM, Andreas Neumann a.neum...@carto.net wrote: That's funny! Good catch. Andreas Am 20.01.2014 20:12, schrieb Saber Razmjooei: How about Speed: http://en.wikipedia.org/wiki/John_Speed Goes well with MTR too :) Cheers, Saber -Original Message- From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Andreas Neumann Sent: 20 January 2014 19:07 To: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Reminder: Freeze starts on 2014-01-24 (4 days) Hi, Regarding the name, we could also continue with other famous cartographers - maybe someone from Latvia or England. Andreas Am 20.01.2014 18:48, schrieb Anita Graser: Am 20.01.2014, 15:50 Uhr, schrieb Paolo Cavallini cavall...@faunalia.it: question: do we *really* need a name? I think the good old days of pets planets are gone, we can always have problem choosing a wrong name, and it will be increasingly difficult to find suitable ones. Well, we still have Brighton but I agree that we will probably run out of suitable names with the new faster releases. I could certainly live without release names. Best wishes, Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viruses is taken and it is your responsibility to carry out such checks as you feel appropriate. Saber Razmjooei and Peter Wells trading as Lutra Consulting. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list
Re: [Qgis-developer] On the fly simplication of point layers
Tim, I think that type of simplification should not be activated by default. The risks of users just not knowing what's going on is high. The discarding should be activated via check box when desired. On 21 Jan 2014 12:01, Tim Sutton li...@linfiniti.com wrote: Hi Sent from my mobile On 21 Jan 2014 3:10 AM, Mathieu Pellerin nirvn.a...@gmail.com wrote: Also, that logic can only be applied for fully opaque point symbols. As soon as you have a semi transparent symbol, the repetition of points over a same map pixel does matter and needs to be preserved. Agreed but in that case surely you would just disable simplification? Regards Tim On 21 Jan 2014 07:46, A Huarte ahuart...@yahoo.es wrote: Ok, I will study it If you have time and inclination this would be great (note feature freeze starts in 4 days). A logical starting may be to only return one point per map pixel though I am not sure if you can push that kind of logic over to provider side very easily. Regards Tim De: Tim Sutton li...@linfiniti.com Para: A Huarte ahuart...@yahoo.es CC: qgis-developer qgis-developer@lists.osgeo.org Enviado: Lunes 20 de enero de 2014 22:57 Asunto: Re: [Qgis-developer] On the fly simplication of point layers Hi On Mon, Jan 20, 2014 at 11:47 PM, A Huarte ahuart...@yahoo.es wrote: done: https://github.com/qgis/QGIS/pull/1093 This patch hides the simplification rendering tab for point layers, now it is not supported (internally I am not trying to simplify point layers). Thanks Tim! About if there is a use case for point simplification, I know one, (gvSIG + dielmo open lidar) use it for load extreme big point layers as LiDAR LAS files are. It know the code in java and I think easy migrate to QGIS. Basically, It ignore points by distance in a similar style as the current simplifier classes. Sorry I see my original email was not very clear - I meant if there was a use case for point simplification as *currently implemented in master* - I fully agree that filtering proximal points would be a good performance booster, as would providing a point clustering capability. If you think good for QGIS I think but I can imlement it That would be great! Thanks for your pull request. Regards Tim . Alvaro De: Tim Sutton li...@linfiniti.com Para: qgis-developer qgis-developer@lists.osgeo.org Enviado: Lunes 20 de enero de 2014 21:29 Asunto: [Qgis-developer] On the fly simplication of point layers Ok I guess you can see where I am going to go with this email :-) Is there any point to allowing users to simplify point layers? Alvaro, can your remove the point rendering tab in layer properties (and I guess check internally that you are not trying to simplify point layers)? Or is there a use case for point simplification that I am not getting? Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ 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] Reminder: Freeze starts on 2014-01-24 (4 days)
On 22. 01. 14 11:37, Radim Blazek wrote: On Mon, Jan 20, 2014 at 10:15 PM, Tim Sutton li...@linfiniti.com wrote: Hi Regarding whether we should keep giving releases names, I think we should (big +1) for the following reasons: -1 for code names, see [1], it is all there what came to my mind: Version 4.0? Ha! Why would I use an easily-recognizable number that gives both a sense of the product history and clear indication of what I'm talking about when I can show off my 1337 status by calling it Ice Cream Sandwich,... * it (under our current scheme) pays homage to the hosts of our hackfests - lets be honest there isn't much reward in hosting it other than seeing your region represented in the release name Cannot it be done in a different way, maybe even more explicitly, for example a bottom bar on splash screen telling place/institution. Even though I would keep the names, we'll have troubles anyway: 2 HF a yeat with 3 releases, we won't be able to thank all the places... * its a 'fun' part of our project culture and I would not like to see that we gradually remove everything that is fun and interesting about our project Fun for you, disaster for me. When it comes to code names, I always have to search a table of code names and translate it to a version number. Too old, stupid, ... probably, even such people are using QGIS. * users that I interact with often reference the release by its name, and I think it makes the individual releases more clearly distinguishable I would suggest a Latvian cartographer or place of interest. Then next release we can have a splash of some drunk guys wondering around Brighton on a Saturday night :-P If you insist on mountains/cartographers, please order them at least by height/birth day, that would be very helpful. Radim [1] http://gizmodo.com/5852191/enough-with-the-ridiculous-product-code-names ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] On the fly simplication of point layers
+1 De: Mathieu Pellerin nirvn.a...@gmail.com Para: Tim Sutton li...@linfiniti.com CC: A Huarte ahuart...@yahoo.es; qgis-developer qgis-developer@lists.osgeo.org Enviado: Miércoles 22 de enero de 2014 11:41 Asunto: Re: [Qgis-developer] On the fly simplication of point layers Tim, I think that type of simplification should not be activated by default. The risks of users just not knowing what's going on is high. The discarding should be activated via check box when desired. On 21 Jan 2014 12:01, Tim Sutton li...@linfiniti.com wrote: Hi Sent from my mobile On 21 Jan 2014 3:10 AM, Mathieu Pellerin nirvn.a...@gmail.com wrote: Also, that logic can only be applied for fully opaque point symbols. As soon as you have a semi transparent symbol, the repetition of points over a same map pixel does matter and needs to be preserved. Agreed but in that case surely you would just disable simplification? Regards Tim On 21 Jan 2014 07:46, A Huarte ahuart...@yahoo.es wrote: Ok, I will study it If you have time and inclination this would be great (note feature freeze starts in 4 days). A logical starting may be to only return one point per map pixel though I am not sure if you can push that kind of logic over to provider side very easily. Regards Tim De: Tim Sutton li...@linfiniti.com Para: A Huarte ahuart...@yahoo.es CC: qgis-developer qgis-developer@lists.osgeo.org Enviado: Lunes 20 de enero de 2014 22:57 Asunto: Re: [Qgis-developer] On the fly simplication of point layers Hi On Mon, Jan 20, 2014 at 11:47 PM, A Huarte ahuart...@yahoo.es wrote: done: https://github.com/qgis/QGIS/pull/1093 This patch hides the simplification rendering tab for point layers, now it is not supported (internally I am not trying to simplify point layers). Thanks Tim! About if there is a use case for point simplification, I know one, (gvSIG + dielmo open lidar) use it for load extreme big point layers as LiDAR LAS files are. It know the code in java and I think easy migrate to QGIS. Basically, It ignore points by distance in a similar style as the current simplifier classes. Sorry I see my original email was not very clear - I meant if there was a use case for point simplification as *currently implemented in master* - I fully agree that filtering proximal points would be a good performance booster, as would providing a point clustering capability. If you think good for QGIS I think but I can imlement it That would be great! Thanks for your pull request. Regards Tim . Alvaro De: Tim Sutton li...@linfiniti.com Para: qgis-developer qgis-developer@lists.osgeo.org Enviado: Lunes 20 de enero de 2014 21:29 Asunto: [Qgis-developer] On the fly simplication of point layers Ok I guess you can see where I am going to go with this email :-) Is there any point to allowing users to simplify point layers? Alvaro, can your remove the point rendering tab in layer properties (and I guess check internally that you are not trying to simplify point layers)? Or is there a use case for point simplification that I am not getting? Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ 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] Atlas generation and scaling
Done - as Feature request 9399 Regards Bo Victor Thomsen Den 22-01-2014 10:30, Nyall Dawson skrev: On 22 January 2014 20:26, Bo Victor Thomsen bo.victor.thom...@gmail.com wrote: Hi all - (sorry Martin for sending this question to your private mail first!) I have a question about Atlas generation and scaling: Does the Atlas generator respect scale settings defined under Project properties -- General -- Project scales when you're using the Margin around feature option in Atlas generation -- Scaling settings ? It would be nice to only have decent scale values in the atlas generated maps like 1:12.500, 1:20.000 or whatever instead of 1:11.123,24 No, it doesn't respect them currently. Can you please file a feature request for this at http://hub.qgis.org/issues? Cheers, Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] On the fly simplication of point layers
On Wed, Jan 22, 2014 at 4:33 PM, Tim Sutton li...@linfiniti.com wrote: Actually the point displacement renderer already does clustering, though it lacks more options to customize how the clustered symbol would look like. Doesnt it do the reverse? i.e. when more than one point falls in the same place, it shifts them aside so they are all visible. If it can be made to produce a scaled symbol based on the number of underlying points that would be cool.That would also be a good time to change its name to 'Custer or displace' or something. I think that was what the renderer did originally, but nowadays it also groups points within configured distance. Unfortunately it always tries to draw a circle around the clustered point with original symbols. If we introduced few rendering options, it would be more useful: - draw just the clustered symbol for the whole group - scale the clustered symbol depending on the number of points inside Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Reminder: Freeze starts on 2014-01-24 (4 days)
On Wed, 22. Jan 2014 at 11:42:38 +0100, Denis Rouzaud wrote: On 22. 01. 14 11:37, Radim Blazek wrote: Cannot it be done in a different way, maybe even more explicitly, for example a bottom bar on splash screen telling place/institution. Even though I would keep the names, we'll have troubles anyway: 2 HF a yeat with 3 releases, we won't be able to thank all the places... Huh? 2 HF and 3 releases will help us catch up. Even more: we're not doing Linuxhotel releases and Vienna twice. But I would also be fine if we'd just give it a monotonically increasing version number (like firefox for instance) and be done with it and drop the nameing hassle. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] On the fly simplication of point layers
Hi On Wed, Jan 22, 2014 at 1:23 PM, Martin Dobias wonder...@gmail.com wrote: On Wed, Jan 22, 2014 at 4:33 PM, Tim Sutton li...@linfiniti.com wrote: Actually the point displacement renderer already does clustering, though it lacks more options to customize how the clustered symbol would look like. Doesnt it do the reverse? i.e. when more than one point falls in the same place, it shifts them aside so they are all visible. If it can be made to produce a scaled symbol based on the number of underlying points that would be cool.That would also be a good time to change its name to 'Custer or displace' or something. I think that was what the renderer did originally, but nowadays it also groups points within configured distance. Unfortunately it always tries to draw a circle around the clustered point with original symbols. If we introduced few rendering options, it would be more useful: - draw just the clustered symbol for the whole group - scale the clustered symbol depending on the number of points inside Yeah that should do it! Regards Tim Cheers Martin -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Reminder: Freeze starts on 2014-01-24 (4 days)
On 22. 01. 14 12:25, Jürgen E. Fischer wrote: On Wed, 22. Jan 2014 at 11:42:38 +0100, Denis Rouzaud wrote: On 22. 01. 14 11:37, Radim Blazek wrote: Cannot it be done in a different way, maybe even more explicitly, for example a bottom bar on splash screen telling place/institution. Even though I would keep the names, we'll have troubles anyway: 2 HF a yeat with 3 releases, we won't be able to thank all the places... Huh? 2 HF and 3 releases will help us catch up. Even more: we're not doing Linuxhotel releases and Vienna twice. oopsss, yes. I mixed up because we have a delay right now (Latvia being not the latest). Shall I fill a bug for the operators in my brain? But I would also be fine if we'd just give it a monotonically increasing version number (like firefox for instance) and be done with it and drop the nameing hassle. Jürgen ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [QGIS-UX] option to disable font vectorization in labels
On 22. 01. 14 11:27, Vincent Picavet wrote: Hello, Le mardi 21 janvier 2014 21:45:16, Nyall Dawson a écrit : On 22/01/2014 4:56 am, Anita Graser anitagra...@gmx.at wrote: Am 21.01.2014, 10:24 Uhr, schrieb Vincent Mora vincent.m...@oslandia.com - a composer option: you make the choice when you export to svg, in this case you don't see the result until you open the svg Thanks for addressing this issue! For me, the most obvious place to put this option would be in the print composer. Maybe close to the print as raster option? I'm not a huge fan of this option, given that I'd like to keep the composer window as clear of clutter as possible. I think output format specific options like these (and saving svg to layers) should be put into a separate dialog which appears after the save file dialog. Much like how gimp/Photoshop/illustrator etc show a jpg quality dialog after choosing to save a file as jpg. The settings could either be remembered globally or per output filename. -1 for another dialog window. It makes the user have to set another step to export before having a result. If you want to export the same composition work multiple times with different file names you would have to set this every time. If you want QGIS to remember the settings, the user should have set it somewhere specifically. UX simplification is good, magic things happening behind the scene are not. Generally im am more in favor of a configure first, then execute way of working than the opposite. An intermediate solution could be to have an extended save as dialog box, with some options on the side. +1 for having a cleaner UI. I think it does make sense to separate specific settings in specific dialogs. And, QGIS can remember the settings from one time to another (or am I missing something here?), no need to add a definition somewhere. Then, I don't mind to have either a specific dialog for SVG export or the dialog to be shown after save as. I think people are used to configuration dialogs being shown after choosing a format. My ultimate goal (I was going to run this by the ux list) is to move infrequently used settings like resolution, page size/orientation, print as raster, etc and the atlas settings to their own composition properties dialog and then remove the need for the composition and atlas panels. Any thoughts on this? Same, more dialog boxes is a -1 for me, panels are quick and convenient, and give a fast overview of things. An option to hide or reduce them on the side would be preferable imho. Again, I would also vote in favor of a specific dialog. It's the same on the mainwindow, we don't have a single dock with all the settings at once. I think it's more confusing (and finally less efficient) to have all the settings mixed on the composer dock. Cheers, Denis Only my personal opinion for what it's worth. Vincent ___ 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] Status of the multi-threaded rendering project
Hi everyone As the feature freeze is approaching, I guess this is the right time for an update about the progress of multi-threded rendering. Since the last status update in December I have continued with the implementation, adding support for more data providers, fixing bugs and re-enabling features I disabled during the implementation [1]. The code is in a state where it is quite ready for the merge to master and I am satisfied with the outcome so far. Still, I believe it will be better not to rush into the merge now for 2.2 and then run into problems close to the release (or after!). Don't get me wrong - it works well for me and for the other few brave souls who helped with testing - but given the amount of changes it is likely that some problems will appear sooner or later... git diff statistics say: 315 files changed, 13808 insertions(+), 9321 deletions(-). So, I suggest that we merge the threading branch as soon as the feature freeze will be lifted again, so we will have plenty of time until 2.4 release (4 months) for fixing problems that may appear. To get an idea of what is still missing, here's is my brief to-do list: - merge from master and resolve any conflicts (mainly geometry simplification) - update data providers (so that they work again): - mssql (Nathan has kindly volunteered to get it done) - sqlanywhere (needs to be done by folks who contributed it) - (nice to have) - ability to cancel raster block requests. Otherwise, rendering of raster layers may make the GUI unresponsive until they finish. GDAL currently does not support that either, so this may need also contributing to GDAL, otherwise only native raster providers (wms, wcs, grass) would benefit from that I would appreciate your observations from the testing! Regards Martin [1] https://github.com/wonder-sk/QGIS/commits/threading-revival ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Status of the multi-threaded rendering project
Hi Martin, Thanks for the update. I am trying the threaded version from time to time. Not yet for editing, but for using it as a viewer. I should invest more time into trying it with editing features. I primarily tested SpatiaLite and Postgis, with occasionally some rasters/WMS. I agree that it would probably be best to integrate it into master after 2.2 - given the amount of changes and not enough testing yet. Thanks, Andreas Am 22.01.2014 17:10, schrieb Martin Dobias: Hi everyone As the feature freeze is approaching, I guess this is the right time for an update about the progress of multi-threded rendering. Since the last status update in December I have continued with the implementation, adding support for more data providers, fixing bugs and re-enabling features I disabled during the implementation [1]. The code is in a state where it is quite ready for the merge to master and I am satisfied with the outcome so far. Still, I believe it will be better not to rush into the merge now for 2.2 and then run into problems close to the release (or after!). Don't get me wrong - it works well for me and for the other few brave souls who helped with testing - but given the amount of changes it is likely that some problems will appear sooner or later... git diff statistics say: 315 files changed, 13808 insertions(+), 9321 deletions(-). So, I suggest that we merge the threading branch as soon as the feature freeze will be lifted again, so we will have plenty of time until 2.4 release (4 months) for fixing problems that may appear. To get an idea of what is still missing, here's is my brief to-do list: - merge from master and resolve any conflicts (mainly geometry simplification) - update data providers (so that they work again): - mssql (Nathan has kindly volunteered to get it done) - sqlanywhere (needs to be done by folks who contributed it) - (nice to have) - ability to cancel raster block requests. Otherwise, rendering of raster layers may make the GUI unresponsive until they finish. GDAL currently does not support that either, so this may need also contributing to GDAL, otherwise only native raster providers (wms, wcs, grass) would benefit from that I would appreciate your observations from the testing! Regards Martin [1] https://github.com/wonder-sk/QGIS/commits/threading-revival ___ 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] Clustering algorithms from RISE
Hi Martin, Thank you for your response, I will look into it and start with the Python plugin. Thanks again, Regards Sergio On Jan 22, 2014 4:29 AM, Martin Dobias wonder...@gmail.com wrote: Hi Sergio On Mon, Jan 20, 2014 at 11:28 PM, Sergio Botero sergio...@gmail.com wrote: As one of the relatively new developers of Clusterpy, I have been looking into the possibility of making Clusterpy (a modified version) part of the Processing code. First I would like to know, do you think that this kind of algorithms area a good fit for the QGIS core? I also would like to know, what would be your proposed process to make this happen? anyone I should contact directly? I think the best thing to do for a start would be to create a Python plugin for QGIS that will use the Processing framework. Then you could upload the plugin to the repository [1], so the potential users will be able to seamlessly download and install it. If there would be a lot of interest from users to have the clustering functionality available in default installation of QGIS, we could discuss the inclusion of the code into QGIS codebase. Regards Martin [1] http://plugins.qgis.org/plugins/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Revisiting behavior of composer guides
Following on from a discussion in March last year (http://lists.osgeo.org/pipermail/qgis-developer/2013-March/025064.html), I'd like to re-raise the idea of swapping the behavior of composer guides lines from the current approach (clicking and dragging on the horizontal ruler to create a vertical guide) to the opposite approach (clicking and dragging down the horizontal ruler to create a horizontal guide). My rationale is: - The rulers have changed appearance in 2.2, so this is a good time to change this behavior if we do decide to do so. It's better to address this now while things already look different to users then in a future release. - The alternative behavior is much more standard. A quick test shows me that Illustrator, Inkscape, Publisher, Scribus, Gimp, Photoshop and Indesign all use the drag a horizontal ruler to create a horizontal guide approach. These are all industry-standard applications, and ones which many cartographers/GIS users would be familiar with. What's everyone's thoughts regarding this? Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Revisiting behavior of composer guides
Hi, For me it would be a +1 to change to the common behavior of graphics and DTP software. This is what I already stated in the discussion back then. I understand that you, Nyall, are trying to make QGIS behave more like conventions used in Graphics/DTP software (e.g. shortcuts, selection, navigation, etc.) - so this should be part of the effort I think. Thanks for dealing with this, Andreas Am 23.01.2014 02:30, schrieb Nyall Dawson: Following on from a discussion in March last year (http://lists.osgeo.org/pipermail/qgis-developer/2013-March/025064.html), I'd like to re-raise the idea of swapping the behavior of composer guides lines from the current approach (clicking and dragging on the horizontal ruler to create a vertical guide) to the opposite approach (clicking and dragging down the horizontal ruler to create a horizontal guide). My rationale is: - The rulers have changed appearance in 2.2, so this is a good time to change this behavior if we do decide to do so. It's better to address this now while things already look different to users then in a future release. - The alternative behavior is much more standard. A quick test shows me that Illustrator, Inkscape, Publisher, Scribus, Gimp, Photoshop and Indesign all use the drag a horizontal ruler to create a horizontal guide approach. These are all industry-standard applications, and ones which many cartographers/GIS users would be familiar with. What's everyone's thoughts regarding this? Nyall ___ 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] Visual changelog for QGIS 2.2
I tim, just added entry about WMS Legend... I set also disclaiming about founder of this feature, but I don't know if this is in the entry style... I can erase it to be uniform with other entries. On 30 December 2013 05:41, Tim Sutton li...@linfiniti.com wrote: Hi All Over the last couple of weeks, I have started compiling a list of interesting new features for the visual changelog for QGIS 2.2. Could I invite others to add entries there too. You can either do it directly on the changelog site [1] (you need to create yourself a login first) or send me an email with the following info: * Category of feature * Title for new features * Feature description in markdown or plain text * A screenshot if possible (it is a *visual* changelog) * Your full name for the image credits. Please take a look at the existing entries to ensure that you are not duplicating work. @Nyall maybe it would be nice to get another entry for composer summarising all the other improvements you have made, I know I haven't done the work you have done justice in the list so far. [1] http://changelog.linfiniti.com/qgis/version/21/ Thanks -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ 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
