Re: [Qgis-developer] Datum Transformation - parameters for mainland Portugal
Hi Pedro QGIS imports the towgs84 transformations from GDAL and adds a list of ntv2 transformations into srs.db. So I'm going to add/modify the ntv2 transformations (if there are no objections from other portuguese users). For the towgs84 ones I agree with Andre that it is better to bring it to gdal/epsg level. Regards, Marco On 18.06.2014 16:59, Andre Joost wrote: Hi Pedro, Am 18.06.2014 15:13, schrieb Pedro Venâncio: I have an update to the parameters that are in Datum Transformation for mainland Portugal. After an analysis of the parameters that are currently inserted in srs.db, I think we should keep only the latest parameters that are provided by the Portuguese Surveying Authority (Directorate-General of the Territory), to avoid confusion among users. So, we should keep only the transformation parameters of Molodensky, Bursa-Wolf, and two grids NTv2 that are in use here in Portugal, one from the Directorate-General of the Territory, and another from the University of Porto. it has little use to change the parameters in QGIS only. All applications that use GDAL/PROJ use the same database of CRS. This is kept in sync with the official EPSG database at http://www.epsg-registry.org/ The EPSG database offers different transformations from local datums to WGS84. One of these is usually bundled to the coordinate system when you use QGIS/GDAL/PROJ. Other software like ARCGIS keeps coordinate systems and datum transformations separated. Latest versions of QGIS allow to use a different datum transformation, but keep in mind that software that stores only EPSG codes (like spatialite) will use nethertheless the default datum transformation. If you feel uncomfortable with the default datum transformation, and you have official sources, you might open a ticket for the CRS databases used in GDAL and PROJ. The parameters should be at least in the EPSG database. QGIS syncs with that database after installation to avoid discrepancies on your own computer. Greetings, André Joost ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Processing: command and help translations
Hi all. The translation of command names and descriptions, and of the help, is available for several backends (most notably GRASS). However, at least in my installations, the English version is always used. Is this confirmed? If so, I think it should be changed, as it is confusing for users. Thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Please give us more time for testing and bugfixing
Hi, I hate to be the one asking for it - but I think we need more time for testing and bugfixing. We have a very good release feature wise - but there are still a number of rather severe or annoying bugs to fix (some of them haven't even been reported yet). One month is not enough time for testing and bugfixing. People are not always in the office, then obviously the bugs can't be immediately fixed. I would propose to have two more weeks for stabilizing things. Yesterday we had the Swiss QGIS user meeting. We had workshops with QGIS master. While the features are great, there were still some issues that need to be addressed. I took notes but did not have the time to do the bug reports. Will do that today. I would hate to have a release with these issues not addressed. Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Four month cycle too fast
Hi, At the Swiss QGIS user meeting yesterday there were some discussions whether people can cope with the 4 month release schedule and there were a number of users who said that this way too fast for them. By the time they could properly test a release, the next release is already there. Bigger organizations (government organizations and bigger companies) have to test a release, package it with IT, test again. They often can't install QGIS themselves (don't have installation privileges) but have to ask IT to do it for them. This is a time-consuming process. I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. PostgreSQL has a yearly release cycle and it works really well I think - both for them as a project and for us as customers. Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Processing: command and help translations
You are right. The names are taken from the descrition files, and are in english. No mechanism is implemented for translating them later, but I guess it shouldn't be difficult if the translate strings are available already for GRASS ones. 2014-06-19 8:18 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. The translation of command names and descriptions, and of the help, is available for several backends (most notably GRASS). However, at least in my installations, the English version is always used. Is this confirmed? If so, I think it should be changed, as it is confusing for users. Thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ 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] Four month cycle too fast
On 06/18/2014 11:34 PM, Andreas Neumann wrote: Hi, At the Swiss QGIS user meeting yesterday there were some discussions whether people can cope with the 4 month release schedule and there were a number of users who said that this way too fast for them. By the time they could properly test a release, the next release is already there. Bigger organizations (government organizations and bigger companies) have to test a release, package it with IT, test again. They often can't install QGIS themselves (don't have installation privileges) but have to ask IT to do it for them. This is a time-consuming process. I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. PostgreSQL has a yearly release cycle and it works really well I think - both for them as a project and for us as customers. Andreas Except Postgis does bugfix releases and doesn't cram as many new features. As discussed in great length in previous threads, it's the pace of new features that makes bugfix releases somewhat inplausible. I'm not saying that 4 months is right, what about alternating stable/experimental like GRASS? So that big orgs only think about every 8 months? Really a big org can decide to skip a release if they want. Every 6 is also possible, the key is timing, right now is a very good time to release to be ready for FOSS4g. Thanks for the feedback, since this the first attempt at the 4 month it's good to get some information from users. Thanks, Alex ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Processing: command and help translations
Il 19/06/2014 08:38, Victor Olaya ha scritto: You are right. The names are taken from the descrition files, and are in english. No mechanism is implemented for translating them later, but I guess it shouldn't be difficult if the translate strings are available already for GRASS ones. Thanks. Please note this is also true for help, already available in many languages for GRASS. This migh be even easier to implement. Ticket opened: http://hub.qgis.org/issues/10636 All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Failing tests
They are both mine, I'll have a look and see if I need to fix the tests or the code, they are not expected failures. While talking about tests: Is somebody still considering / taking care of github integration? It would be very handy to have this connected to pull requests. Best, Matthias On Wed 18 Jun 2014 01:54:52 PM CEST, Nyall Dawson wrote: Hi all, It would be nice if we can get the test suite passing before the upcoming release. As far as I can tell, there's two tests which are currently failing (excluding tests which fail because of platform specific font rendering differences): - qgis_vectorlayercachetest - crashes with a fatal error - qgis_dualviewtest - fails one of its tests Are these expected failures? (Please note - a number of composer tests may fail on some platforms, but all is well. This is caused by differences in font rendering and anti-aliasing between platforms. I've got plans on how to improve this situation for 2.6). 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
[Qgis-developer] QGIS Server: using same layer name in different projects
Hi, I discovered that if you use QGIS Server along two different project that share the same layer name. I.e.: first project: roads layer name --- I use the postgis table name roads, filtered by highways second project: roads layer name --- I use the postgis table name roads, with no filter (all road types) If you first visit with Qgis Web Client the first project, then the second you see only highways. I think that this is due to QGIS Server WMS caching, or am I wrong? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Pyqgis - join a CSV to a vector layer
Martin, Thanks for your answer. Indeed I did not add the layer to the registry in my foreach loop. I did it at the end (for better performance ) Now it is working, thanks a lot ! Michael 2014-06-19 6:54 GMT+02:00 Martin Dobias wonder...@gmail.com: Hi Michael your code works for me. Maybe you have not added the loaded DBF to the QgsMapLayerRegistry before using it for the join? The main layer otherwise does not have a way to resolve the reference to layer from its ID. By the way, it is not necessary to set joinFieldIndex and targetFieldIndex members - they will have no effect. Regards Martin On Thu, Jun 19, 2014 at 12:22 AM, kimaidou kimai...@gmail.com wrote: Hi all. I am trying to join a DBF to a vector layer via python . I can create the QgsVectorJoinInfo() , set the parameters and add it to the layer : https://pastee.org/fv55y When I get vlayer.vectorJoins() , it is filled (3 times, because I made 3 attempts), but when I open the vector layer properties dialog, no join appears in the Join tab. Should I update something after adding the join via addJoin method ? Has anyone a working example ? Thanks in advance Michael ___ 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] QGIS Server: using same layer name in different projects
Hi Luca, It is a known issue. It is not an issue about the layer name, but of layer ids. You have to make sure that layer ids in all of your projects are unique. You probably copy/pasted projects and this does not upgrade the layerid. It is not a problem to have two or more identical layer names, but the layer ids have to be unique. I agree that this is suboptimal and should be resolved in an upcoming version. The layercache should have both the project name and the layerid to form a unique identifier from both attributes. Someone needs to either work on it or found this improvement. Andreas Am 19.06.2014 07:59, schrieb Luca Manganelli: Hi, I discovered that if you use QGIS Server along two different project that share the same layer name. I.e.: first project: roads layer name --- I use the postgis table name roads, filtered by highways second project: roads layer name --- I use the postgis table name roads, with no filter (all road types) If you first visit with Qgis Web Client the first project, then the second you see only highways. I think that this is due to QGIS Server WMS caching, or am I wrong? ___ 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] Fwd: Hackfest/ developers meeting in Spring 2015
Hi all. On behalf of Lene Fscher, from the University of Copenhagen, I'm inviting QGIS developers to the spring 2015 hackfest in Danmark. See below for details. Thanks Lene! All the best. Messaggio Inoltrato This is an invitation to come to Denmark in May 2015 for Developers meeting and Hackfest – or what it is called J University of Copenhagen would like to be host for this event. Our department at the The Forest and Landscape College is situated in Nødebo – 40 km north of Copenhagen. In the week from 18.-22. May 2015 We have room for 34 persons and a hostel nearby is more persons would like to participate. We have a very good canteen which can provide us with food and coffee https://www.facebook.com/SpisehusetSkovskolen We have rooms for working We have an organization for having arrangements like this We have students for testing – they are used to work with QGIS We have “Flækken” the students place for beer and relaxation And place for time off in the forest…. It is easy to get here from Copenhagen. In April 2014, Victor Olaya and Martin Isenburg visited us for a workshop. Please ask Victor for his opinion about our campus could be a place for this event. http://ign.ku.dk/om/skovskolen/ https://www.facebook.com/SkovOgLandkabsingenior Regards *Lene Fischer* Associate Professor *Department of Geosciences and Natural Resource Management* University of Copenhagen l...@ign.ku.dk mailto:l...@ign.ku.dk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Hackfest/ developers meeting in Spring 2015
Awesome news! I really enjoyed the time I spend there for their QGIS course last April, and I cannot think of a better place for a GIS hackfest :-) 2014-06-19 10:14 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. On behalf of Lene Fscher, from the University of Copenhagen, I'm inviting QGIS developers to the spring 2015 hackfest in Danmark. See below for details. Thanks Lene! All the best. Messaggio Inoltrato This is an invitation to come to Denmark in May 2015 for Developers meeting and Hackfest – or what it is called J University of Copenhagen would like to be host for this event. Our department at the The Forest and Landscape College is situated in Nødebo – 40 km north of Copenhagen. In the week from 18.-22. May 2015 We have room for 34 persons and a hostel nearby is more persons would like to participate. We have a very good canteen which can provide us with food and coffee https://www.facebook.com/SpisehusetSkovskolen We have rooms for working We have an organization for having arrangements like this We have students for testing – they are used to work with QGIS We have “Flækken” the students place for beer and relaxation And place for time off in the forest…. It is easy to get here from Copenhagen. In April 2014, Victor Olaya and Martin Isenburg visited us for a workshop. Please ask Victor for his opinion about our campus could be a place for this event. http://ign.ku.dk/om/skovskolen/ https://www.facebook.com/SkovOgLandkabsingenior Regards *Lene Fischer* Associate Professor *Department of Geosciences and Natural Resource Management* University of Copenhagen l...@ign.ku.dk mailto:l...@ign.ku.dk ___ 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] Four month cycle too fast
Hi, again +1 with Andreas. Alex, big corps are real people, trying to do their best to test qgis like every other community member, and also having to do support, training, packaging, deploying inside their corp. We often do not have teams of plenty members on QGIS. Skipping a version for user deployement is an option, but does not change anything in the fact that we have to closely follow every version and test it. If not, we have the load reported on next version. A too fast release cycle leads to the fact that qgis community looses those testers and contributors because they can't follow that.. Not sure we can afford that. 6 months or 8 months, with a longer Release candidate period is a good compromise to me. Also, rc period should not fall during holiday periods. For France, we have august, christmas and sometimes May to avoid. How about others? Maybe access stats of the internet site could give us an global view of those period of unactivity? Cheers, Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Four-month-cycle-too-fast-tp5146648p5146684.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Il 19/06/2014 10:32, Régis Haubourg ha scritto: Alex, big corps are real people, trying to do their best to test qgis Hi all. I acknowledge the problem, and I understand well its implications. I think a proper solution is not having longer release cycles (we had them before, without major improvements over the current situation), but backporting fixes over to a stable version, having more tests and QA. IMHO, this effort should be covered by big corps, who have the power and the interest to do it. I'm available to help organizing this if someone is interested. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [QGIS Mapserver] addDrawingOrder changed logic in 2.4?
Hi, Thank you Giovianni and Marco for fixing this. I discovered the issue as well but was too busy to act or even report in the past couple days. I did not have time to investigate the problem. I can confirm that QGIS server and web client (both master) work fine together again. Thanks, Andreas Am 18.06.2014 15:32, schrieb G. Allegri: This pull request shoud fix it, but please review it in case it would break somethign else https://github.com/qgis/QGIS/pull/1462 2014-06-18 17:02 GMT+02:00 G. Allegri gioha...@gmail.com: Thanks Marco. Done in http://hub.qgis.org/issues/10625 In case the changed logic is only a side effect of the parsing refactoring, the solution seems quite straightforwars, rolling back to differentiating between embedded/not embedded layers. giovanni 2014-06-18 16:52 GMT+02:00 Marco Hugentobler marco.hugentob...@sourcepole.ch: Hi Giovanni Please open a blocker ticket about the layer order and assign it to me. I'll try to look at it before the release. Regards, Marco Von Samsung Galaxy Note gesendet Ursprüngliche Nachricht Von: G. Allegri gioha...@gmail.com Datum: 18.06.2014 16:34 (GMT+01:00) An: qgis-developer qgis-developer@lists.osgeo.org Betreff: [Qgis-developer] [QGIS Mapserver] addDrawingOrder changed logic in 2.4? I'm investingating why QWC is giving me problems with QGIS Server 2.4. I've spot a difference between QGIS 2.2 and the master code which seems to cause problems during the GetProjectSettings response parsing. In previous versions of QGIS Server addDrawingOrder worked for project layers [1] while for embedded layers we had addDrawingOrderEmbeddedGroup [2]. Now we have only addDrawingOrder which seems to work only for embedded projects. The result is that, without emdedded layers, the LayerDrawingOrder element will always be empty. This seems to cause some problems on the QWC side. In fact now QWC works only with GetCapabilities, while it worked both with GetCapabilities and GetProjectSettings before. Is there a reason for this change? giovanni [1] https://github.com/qgis/QGIS/blob/release-2_2/src/mapserver/qgsprojectparser.cpp#L3644 [2] https://github.com/qgis/QGIS/blob/release-2_2/src/mapserver/qgsprojectparser.cpp#L4067 -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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] Four month cycle too fast
I'm going to learn more towards a longer dev cycle. 4 months open, 2 month feature freeze. Of course I'm also pro stable release but there is less need if you have more time to fix bugs. - Nathan On Thu, Jun 19, 2014 at 6:37 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 19/06/2014 10:32, Régis Haubourg ha scritto: Alex, big corps are real people, trying to do their best to test qgis Hi all. I acknowledge the problem, and I understand well its implications. I think a proper solution is not having longer release cycles (we had them before, without major improvements over the current situation), but backporting fixes over to a stable version, having more tests and QA. IMHO, this effort should be covered by big corps, who have the power and the interest to do it. I'm available to help organizing this if someone is interested. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ 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] Fwd: Hackfest/ developers meeting in Spring 2015
I agree with Victor. We had a great time there and the facilities seemed perfect for a hackfest (in a nature setting surrounded by forest with a lake nearby). http://rapidlasso.com/2014/05/23/first-ever-lidar-processing-model-in-qgis/ Great canteen. Potential for evening bonfires. Green fields provide ample opportunities for frisbee tossing or some friendly soccer (my deepest heart-felt condolences to our Spanish friends (-;). I am confident Lene and her team will make a great host ... (-: Cheers, Martin @rapidlasso On Jun 19, 2014 10:31 AM, Victor Olaya vola...@gmail.com wrote: Awesome news! I really enjoyed the time I spend there for their QGIS course last April, and I cannot think of a better place for a GIS hackfest :-) 2014-06-19 10:14 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. On behalf of Lene Fscher, from the University of Copenhagen, I'm inviting QGIS developers to the spring 2015 hackfest in Danmark. See below for details. Thanks Lene! All the best. Messaggio Inoltrato This is an invitation to come to Denmark in May 2015 for Developers meeting and Hackfest - or what it is called J University of Copenhagen would like to be host for this event. Our department at the The Forest and Landscape College is situated in Nødebo - 40 km north of Copenhagen. In the week from 18.-22. May 2015 We have room for 34 persons and a hostel nearby is more persons would like to participate. We have a very good canteen which can provide us with food and coffee https://www.facebook.com/SpisehusetSkovskolen We have rooms for working We have an organization for having arrangements like this We have students for testing - they are used to work with QGIS We have Flækken the students place for beer and relaxation And place for time off in the forest It is easy to get here from Copenhagen. In April 2014, Victor Olaya and Martin Isenburg visited us for a workshop. Please ask Victor for his opinion about our campus could be a place for this event. http://ign.ku.dk/om/skovskolen/ https://www.facebook.com/SkovOgLandkabsingenior Regards *Lene Fischer* Associate Professor *Department of Geosciences and Natural Resource Management* University of Copenhagen l...@ign.ku.dk mailto:l...@ign.ku.dk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Il 19/06/2014 10:51, Nathan Woodrow ha scritto: I'm going to learn more towards a longer dev cycle. 4 months open, 2 month feature freeze. we had that long ago, and it didn't work well. Of course I'm also pro stable release but there is less need if you have more time to fix bugs. late bugs will always be found, regardless of the time frame for testing. the only stable solution is maintaining stable branches with backporting, for which we need additional manpower (= money). All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 11:00:45AM +0200, Paolo Cavallini wrote: Il 19/06/2014 10:51, Nathan Woodrow ha scritto: I'm going to learn more towards a longer dev cycle. 4 months open, 2 month feature freeze. we had that long ago, and it didn't work well. Of course I'm also pro stable release but there is less need if you have more time to fix bugs. late bugs will always be found, regardless of the time frame for testing. Agreed. Bugs are found by users, and users of an official release are a lot lot more than users of a development snapshot. Also, users of a stable release are a usually more than users of new releases. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. 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) Germany 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] Four month cycle too fast
I'm not sure I really like the just make new releases and avoid bug fixe releases kind of thinking. There are some places that can't roll out a whole new release due to possible bugs from major new features, and given how fast we move this can cause some real issues. We don't even have to bug fix until next release just do it for a short (1 month) period after the release, so you're dev cycle is like this: 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. This means any bugs that might come up can be fixed, and we patch then we move on. There is really no need to make 2.x.5 releases, just one would normally be enough. I think the main thing is keeping the bug fix patches small so you don't affect to much code and is easier to spot where there might be issues. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. - Nathan On Jun 19, 2014 7:18 PM, Jürgen E. j...@norbit.de wrote: Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. 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) Germany 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 07:32:17PM +1000, Nathan Woodrow wrote: I think the main thing is keeping the bug fix patches small so you don't affect to much code and is easier to spot where there might be issues. Agreed. When I spot a bug during development I often first fix it in the stable branches and than forward-port to master, to keep the bugfix isolated from the new feature. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi all, I really think we are going blind here about the bugfix or not bugfix release ! At present, it depends completely of the package maintainers. For example: * Under Windows : no bugfix * Under Debian : bug-fixed via branch release-2_2 * Ubuntugis-unstable : not bugfxied * opensuze : bugfixed I think * Mac OX : I do not know etc. NB: I may be wrong for some, please correct me :) And please note I really do not blame any packager. I know time is not a unlimited resource. I really think it is a pity not to have a bug fix release for some users, but to have it for others. I personaly tried the last week to create the build architecture under Windows 7, and almost suceeded (but still have some build errors..). I think once you have the architecture set up, it must not be so manpower demanding to run a bash script under Windows, Ubuntu, etc. and create a bug fix packages (but maybe I am wrong) ? For example, a Windows build is created automatically every week. I think the script can be used once every 4 months (or 6 ) to build the bugfix release, for example for release-2_2. Perhaps we need more documentation on how-to build pacakges for the main Linux distributions, Mac and Windows. It could be great to have a dedicated documentation repository on Github about building QGIS. The INSTALL file is a good start entry, but does not (yet) describe all the possibilities, and has no images, etc. What about having a packagers squad for each main OS, and not rely only on unique volonteers per OS ? I think the manpower is more lacking about documentation, bugfix release announce, communication about it, etc. Michael 2014-06-19 11:36 GMT+02:00 Sandro Santilli s...@keybit.net: On Thu, Jun 19, 2014 at 07:32:17PM +1000, Nathan Woodrow wrote: I think the main thing is keeping the bug fix patches small so you don't affect to much code and is easier to spot where there might be issues. Agreed. When I spot a bug during development I often first fix it in the stable branches and than forward-port to master, to keep the bugfix isolated from the new feature. --strk; ___ 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] Fwd: Hackfest/ developers meeting in Spring 2015
victor I'm agree about the quality of the copenhagen offer, but remember that we (spain) loosed again the opportunity to host a hackfest due the fact that none answered from Girona to the offer do the hackfest there! :| we should plan to self-organize the hackfest using CENATIC ( http://amtega.xunta.es/) or AMTEGA (http://amtega.xunta.es/) support see you Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com) On 19 June 2014 10:31, Victor Olaya vola...@gmail.com wrote: Awesome news! I really enjoyed the time I spend there for their QGIS course last April, and I cannot think of a better place for a GIS hackfest :-) 2014-06-19 10:14 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. On behalf of Lene Fscher, from the University of Copenhagen, I'm inviting QGIS developers to the spring 2015 hackfest in Danmark. See below for details. Thanks Lene! All the best. Messaggio Inoltrato This is an invitation to come to Denmark in May 2015 for Developers meeting and Hackfest – or what it is called J University of Copenhagen would like to be host for this event. Our department at the The Forest and Landscape College is situated in Nødebo – 40 km north of Copenhagen. In the week from 18.-22. May 2015 We have room for 34 persons and a hostel nearby is more persons would like to participate. We have a very good canteen which can provide us with food and coffee https://www.facebook.com/SpisehusetSkovskolen We have rooms for working We have an organization for having arrangements like this We have students for testing – they are used to work with QGIS We have “Flækken” the students place for beer and relaxation And place for time off in the forest…. It is easy to get here from Copenhagen. In April 2014, Victor Olaya and Martin Isenburg visited us for a workshop. Please ask Victor for his opinion about our campus could be a place for this event. http://ign.ku.dk/om/skovskolen/ https://www.facebook.com/SkovOgLandkabsingenior Regards *Lene Fischer* Associate Professor *Department of Geosciences and Natural Resource Management* University of Copenhagen l...@ign.ku.dk mailto:l...@ign.ku.dk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Hackfest/ developers meeting in Spring 2015
Il 19/06/2014 11:50, Gino Pirelli ha scritto: I'm agree about the quality of the copenhagen offer, but remember that we (spain) loosed again the opportunity to host a hackfest due the fact that none answered from Girona to the offer do the hackfest there! No worries, we'll be happy to go next time. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Hackfest/ developers meeting in Spring 2015
If for a future edition you need help with organizing a hackfest in Spain, i will be happy to help. Also, the french QGIS community seems to be rather active, so if anyone from it wants to do something here, I will be ready to help as much as I can. Just let me know about what i can do. I think both options (France, Spain) would be very good as future hackfest locations. Until that happens, let's enjoy Denmark ;-) 2014-06-19 11:50 GMT+02:00 Gino Pirelli lui...@gmail.com: victor I'm agree about the quality of the copenhagen offer, but remember that we (spain) loosed again the opportunity to host a hackfest due the fact that none answered from Girona to the offer do the hackfest there! :| we should plan to self-organize the hackfest using CENATIC ( http://amtega.xunta.es/) or AMTEGA (http://amtega.xunta.es/) support see you Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com) On 19 June 2014 10:31, Victor Olaya vola...@gmail.com wrote: Awesome news! I really enjoyed the time I spend there for their QGIS course last April, and I cannot think of a better place for a GIS hackfest :-) 2014-06-19 10:14 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. On behalf of Lene Fscher, from the University of Copenhagen, I'm inviting QGIS developers to the spring 2015 hackfest in Danmark. See below for details. Thanks Lene! All the best. Messaggio Inoltrato This is an invitation to come to Denmark in May 2015 for Developers meeting and Hackfest – or what it is called J University of Copenhagen would like to be host for this event. Our department at the The Forest and Landscape College is situated in Nødebo – 40 km north of Copenhagen. In the week from 18.-22. May 2015 We have room for 34 persons and a hostel nearby is more persons would like to participate. We have a very good canteen which can provide us with food and coffee https://www.facebook.com/SpisehusetSkovskolen We have rooms for working We have an organization for having arrangements like this We have students for testing – they are used to work with QGIS We have “Flækken” the students place for beer and relaxation And place for time off in the forest…. It is easy to get here from Copenhagen. In April 2014, Victor Olaya and Martin Isenburg visited us for a workshop. Please ask Victor for his opinion about our campus could be a place for this event. http://ign.ku.dk/om/skovskolen/ https://www.facebook.com/SkovOgLandkabsingenior Regards *Lene Fischer* Associate Professor *Department of Geosciences and Natural Resource Management* University of Copenhagen l...@ign.ku.dk mailto:l...@ign.ku.dk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
I just want to clarify one thing about this discussion: we are not speaking about delaying the 2.4 release, which users are expecting in the next 48 hours, right? The current state of QGIS master could probably be better, but it's not worse than 2.2 (of course, that's a perception based on my workflows). So, please :), whether the release cycle needs to to be adjusted, or not, it shouldn't be decided and change within 48 hours of a publicly known release date. As much as bugs are a big issue for end users, being consistent with the user base is also pretty important. Math On Thu, Jun 19, 2014 at 1:34 PM, Andreas Neumann a.neum...@carto.net wrote: Hi, At the Swiss QGIS user meeting yesterday there were some discussions whether people can cope with the 4 month release schedule and there were a number of users who said that this way too fast for them. By the time they could properly test a release, the next release is already there. Bigger organizations (government organizations and bigger companies) have to test a release, package it with IT, test again. They often can't install QGIS themselves (don't have installation privileges) but have to ask IT to do it for them. This is a time-consuming process. I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. PostgreSQL has a yearly release cycle and it works really well I think - both for them as a project and for us as customers. Andreas ___ 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] Redmine statistics
Hi Do you know if it is possible to have some stats in Redmine regarding the bug counts? Especially: - chart of number of currently opened bugs for every day past X months (ideally displaying proportions of priorities) - chart of number of bugs opened/closed every month/week/day - stats about bug reporters - how many of them, how may new ones, which ones are most active That would help us to judge the current status of the release and do some predictions/decisions based on it. I am thinking of either a module in Redmine - or just to have periodic dump of some parts of the database to create such graphs with a script (probably more flexible as that would not limit us to functionality provided by Redmine. Who maintains the Redmine instance nowadays - Alex / Pirmin? Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi Nathan, On Thu, 19. Jun 2014 at 19:32:17 +1000, Nathan Woodrow wrote: I'm not sure I really like the just make new releases and avoid bug fixe releases kind of thinking. There are some places that can't roll out a whole new release due to possible bugs from major new features, and given how fast we move this can cause some real issues. I said compromise. I'm sure that I don't like it. It implies that it's not optimal. But I didn't have a better idea - and apparently I also miss all the new stuff in this discussion - feels like a dejavu. We don't even have to bug fix until next release just do it for a short (1 month) period after the release, so you're dev cycle is like this: That means packaging again and again - and that's what I want to avoid. But I thought about an automated release build when there are new commits in the release branch and a automated bugfix release after a some given period of time without any new commits. That period should be long enough to make it likely that potentially newly introduced issues by the bugfix are spotted and fixed (thereby restarting the period) before its over. And that without further doing except for the backported commit. But I didn't find time to do that yet. 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) 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) Germany 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
[Qgis-developer] QGIS 2.3 credentials problem
Hello, Since 2.3 got out, QGIS asks the credentials for the database connection from time to time (sometimes, instead of credentials box the project simply freezes). Is there an option to turn this off that I didn’t notice? I see that no one else has reported this. Another thing that I had noticed is that when I open the project with 2.3 Master I get asked for credentials at the beginning (normal) and right at the end (not normal). In Dufour I only get asked once — as it should be. I noticed that this happens after 60 seconds of not doing anything. As an ultimate solution I will recreate all the project from scratch but it will take a big chunk of time. All the best, Tudor PS. Windows 64, osgeo4w 32 bit, both 2.2 and master installed ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi, I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. This means that more developers will be able to work on paid bugfixing (e.g. 3-4 devs working each 1-2 weeks for each release). I think that this will help a lot to raise the quality. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Andreas Am 19.06.2014 09:18, schrieb Jürgen E. Fischer: Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. Jürgen ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2.3 credentials problem
Hi Tudor, On Thu, 19. Jun 2014 at 13:15:51 +0300, tudor yahoo wrote: Since 2.3 got out, QGIS asks the credentials for the database connection from time to time (sometimes, instead of credentials box the project simply freezes). Is there an option to turn this off that I didn?t notice? It's probably just the connection that is failing. In that case QGIS shows the connection error message and prompts for credentials. But the error message is not evaluated, so it might not be a authentication problem at all. 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) Germany 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] Four month cycle too fast
Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. I understand. Then why not go with 4 (1 month freeze) 1 month post release freeze. There only adds the extra month on the end to fix anything that might come up after that is bad. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Of course I don't want to create heaps of more work for people but if cutting a release is a hard process then it really creates a sticky point in all this. We need to be able to release as easy as possible. What are the main problems/stoppers with having it fully automated? Do we need resources, VMs for each platform, etc? - Nathan 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) Germany 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hey Jurgen, 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. I understand. We could go with 4 (1 month freeze) 1 month post release freeze. There only adds the extra month on the end to fix anything that might come up after that is bad. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Of course I don't want to create heaps of work for people but if cutting a release is a hard process then it really creates a sticky point in all this. We need to be able to release as easy as possible when ever we need, be that be weekly, monthly, yearly. It really should just be 1) point at branch 2) package. Even if the website lags behind. What are the main problems/stoppers with having it fully automated? Do we need resources, VMs for each platform, etc? - Nathan 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) Germany 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 On Thu, Jun 19, 2014 at 8:11 PM, Jürgen E. j...@norbit.de wrote: Hi Nathan, On Thu, 19. Jun 2014 at 19:32:17 +1000, Nathan Woodrow wrote: I'm not sure I really like the just make new releases and avoid bug fixe releases kind of thinking. There are some places that can't roll out a whole new release due to possible bugs from major new features, and given how fast we move this can cause some real issues. I said compromise. I'm sure that I don't like it. It implies that it's not optimal. But I didn't have a better idea - and apparently I also miss all the new stuff in this discussion - feels like a dejavu. We don't even have to bug fix until next release just do it for a short (1 month) period after the release, so you're dev cycle is like this: That means packaging again and again - and that's what I want to avoid. But I thought about an automated release build when there are new commits in the release branch and a automated bugfix release after a some given period of time without any new commits. That period should be long enough to make it likely that potentially newly introduced issues by the bugfix are spotted and fixed (thereby restarting the period) before its over. And that without further doing except for the backported commit. But I didn't find time to do that yet. 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) 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) Germany 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work Exactly. There is no point having a release if people can't use it. It will leave a bad taste, especially if it's rolled out to organizations. Nothing will ever be perfect but any blockers (provided that they are) need to be fixed before release. There was one the other day where you couldn't add a new column which is pretty major. - Nathan Andreas Am 19.06.2014 09:18, schrieb Jürgen E. Fischer: Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. Jürgen ___ 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] Four month cycle too fast
Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Server: symbols missing when classified with high ASCII
Hi all. Apparently items whose classification name includes high ASCII (àèé etc.) are drawn and shown in the legend, but not on the map: http://213.136.126.133:8080/www/index.php/view/map/?repository=abidjanproject=abidjan_demo see e.g. Routes Voies revêtues Unsure whether it is a server or a client (LizMap) issue. Any hint? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi, I also think 4 months is too frequent (users on gis.stackexchange are still reporting on 2.0 release!), but think anything longer than 6 months may be too long. What about this scenario (building upon Nathan's suggestion)? 1) 4 full months of development on master branch (currently is only 3 months) 2) 1 month of testing RC (during feature freeze) 3) Tag release (e.g. 2.6.0), do NOT create a release branch; then, package and release 4) 1 month (minus previous packaging/release time) of users testing release and devs working on fixes directly to master branch (still in feature freeze) 5) Tag bug fix release (e.g. 2.6.1), create new branch for 'release-2_6'; then, package and do single bugfix release 6) Repeat from 1), with any new fixes backported to 'release-2_6' branch, when resources/funding allow This allows for a decent amount of development time for new features, and a good amount of time for testing (both as a RC and after the public release). The 'stable' branch is not created until the bugfix release, thereby keeping all devs/testers focused on fixes directly to master branch. Essentially, it is a 6-month release cycle with a single bugfix release (if needed) guaranteed to happen 1 month after initial release. The release branch remains open to backported fixes, but packagers should only expect/schedule to do one 'official' followup bugfix release. Any further bugfix releases would be at the packagers discretion. IMO, this may increase dev work on stability, while not detracting from the forward momentum of development and not forcing maintenance of multiple branches, unless sponsors step up to provide such help. It will also show due diligence on the part of the dev team to focus on user-reported bug fixes directly after the public release. Regards, Larry On Thu, Jun 19, 2014 at 4:44 AM, Matthias Kuhn matthias.k...@gmx.ch wrote: Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. ___ 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] Four month cycle too fast
Hi Nathan, On Thu, 19. Jun 2014 at 20:34:00 +1000, Nathan Woodrow wrote: Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Of course I don't want to create heaps of more work for people but if cutting a release is a hard process then it really creates a sticky point in all this. We need to be able to release as easy as possible. You realize that I was just talking about me. I'm doing all of that - and that's also why I became RM - because I did't a lot of the release (namely packaging) anyway. I just don't do OSX and the non-deb linux distributions. And it's also not like a package is a huge amount of work and has tons of manual steps. I already automated it a great deal (otherwise I would probably not stand a chance) - but you still have to manually checkout new branches, wait for builds, wait for the uploads, on multiple platforms and machines - and not of all of that works flawlessly (sometimes this, sometimes that and always something new - you know...) and sometimes something is brought up that the nightly builds didn't show. Same with the nightly builds, most of the time they works nicely, but every now and again there's something going wrong that you didn't predict. Some stuff was improved however - like the disk space issues on our osgeo vm that made building the debian/ubuntu packages a pain (move to a new host). I also finally came to setup a single VM to do the windows (nightly) building (before I had it one two separate machines). But didn't find the time to setup nightly release builds in case of news on the release branch. Neither for osgeo4w nor for a not yet existing debian repository. What are the main problems/stoppers with having it fully automated? Do we need resources, VMs for each platform, etc? See above. Essentially it's just time (some larger chunks and a lot of small ones). 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) Germany 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] Four month cycle too fast
I think that LTS is kind of a really good idea. At some extent, it's what Sourcepole is doing with its QGIS enterprise. If we have enough companies paying for such bugfixes QA, that would be easily feasible, but someone should be in charge of handling this. Then, the cycle is another discussion. It could be either 2 or 3 releases a year, with 1 over 2 or 3 being LTS. But I would definitely investigate the idea of the LTS. Greetings, Denis On 19.06.2014 12:44, Matthias Kuhn wrote: Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. ___ 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] Printing issues with rotated rasters
Hi, I have a very strange problem. I have a map with a transparent gray-scale raster image and transparent polygons on top of it. When I export as PDF the print looks fine. When I print directly to the printer the raster is not printed at all. I tried with three different printers to eliminate the possibility that this is a driver issue. All three printer do not print the raster. --- On the very same machine, with QGIS 2.2 - all of the direct prints are just fine. --- This is on Windows 7 64bit master with the last nightly build. Can others with a Windows 64bit machine please check if direct printing of transparent rasters with transparent polygons on top of it works fine for them? Thanks for checking, Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Printing issues with rotated rasters
On 19/06/2014 11:09 pm, Andreas Neumann a.neum...@carto.net wrote: Hi, I have a very strange problem. I have a map with a transparent gray-scale raster image and transparent polygons on top of it. When I export as PDF the print looks fine. When I print directly to the printer the raster is not printed at all. I tried with three different printers to eliminate the possibility that this is a driver issue. All three printer do not print the raster. Sounds a lot like http://hub.qgis.org/issues/10599 to me. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Printing issues with rotated rasters
Hi, Yes - that is exactly the same behaviour I am experiencing. Vectors are printing fine, rasters not. Later I found out that it isn't linked to rotation. Rasters currently don't print at all in Win64 - regardless of the rotation. Andreas Am 19.06.2014 13:12, schrieb Nyall Dawson: On 19/06/2014 11:09 pm, Andreas Neumann a.neum...@carto.net wrote: Hi, I have a very strange problem. I have a map with a transparent gray-scale raster image and transparent polygons on top of it. When I export as PDF the print looks fine. When I print directly to the printer the raster is not printed at all. I tried with three different printers to eliminate the possibility that this is a driver issue. All three printer do not print the raster. Sounds a lot like http://hub.qgis.org/issues/10599 to me. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Redmine statistics
Hi Martin, not sure about charts, but some statistics available on summary page https://hub.qgis.org/projects/quantum-gis/issues/report 2014-06-19 13:09 GMT+03:00 Martin Dobias wonder...@gmail.com: Hi Do you know if it is possible to have some stats in Redmine regarding the bug counts? Especially: - chart of number of currently opened bugs for every day past X months (ideally displaying proportions of priorities) - chart of number of bugs opened/closed every month/week/day - stats about bug reporters - how many of them, how may new ones, which ones are most active That would help us to judge the current status of the release and do some predictions/decisions based on it. I am thinking of either a module in Redmine - or just to have periodic dump of some parts of the database to create such graphs with a script (probably more flexible as that would not limit us to functionality provided by Redmine. Who maintains the Redmine instance nowadays - Alex / Pirmin? Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Getting access to atlas record
Hi, With the atlas printing I can get access to the atlas feature id and atlas feature geometry. This is already very powerful. Question: is it already possible to get access to any attribute in the current atlas feature record? My use case would be the one of linked table. Given the atlas coverage table has certain names or identifiers and a linked table has the same identifiers. This way I could have simple relations in print composer. The table could be filtered by common keys with the atlas coverage table. Is this already possible in 2.4 and if yes how? If it is not possible I'd like to propose this feature for the next version. Would be really cool to have. Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Compiling QGIS 2.4 with GCC 4.4 (debian squeeze)?
Hi, I'm trying to compile QGIS git (after having success with 2.2) on Debian Squeeze (6.0) which has GCC 4.4.2. The compilations stops with an make error (see below for error trace). In summary, GCC 4.4 doesn't like this line from qgsvectorlayerfeatureiterator.cpp (line 87): QgsVectorLayerFeatureIterator::QgsVectorLayerFeatureIterator( QgsVectorLayerFeatureSource* source, bool ownSource, const QgsFeatureRequest request ) : QgsAbstractFeatureIteratorFromSource( source, ownSource, request ) , mEditGeometrySimplifier( 0 ) in the corresponding header .h file we have: QgsVectorLayerFeatureIterator( QgsVectorLayerFeatureSource* source, bool ownSource, const QgsFeatureRequest request ) : QgsAbstractFeatureIteratorFromSource( source, ownSource, request ) , mEditGeometrySimplifier( 0 ); it seems that the left part ( from : QgsAbstractFeatureFromSource to end) is missing, but adding it returns a preprocessing gcc error. It's possible to fix this? - [ 0%] Building CXX object src/core/CMakeFiles/qgis_core.dir/qgsvectorlayerfeatureiterator.cpp.o /home/trap/qgis-git/QGIS/src/core/qgsvectorlayerfeatureiterator.cpp: In constructor ‘QgsVectorLayerFeatureIterator::QgsVectorLayerFeatureIterator(QgsVectorLayerFeatureSource*, bool, const QgsFeatureRequest)’: /home/trap/qgis-git/QGIS/src/core/qgsvectorlayerfeatureiterator.cpp:87: error: class ‘QgsVectorLayerFeatureIterator’ does not have any field named ‘QgsAbstractFeatureIteratorFromSource’ /home/trap/qgis-git/QGIS/src/core/qgsvectorlayerfeatureiterator.cpp:88: error: no matching function for call to ‘QgsAbstractFeatureIteratorFromSourceQgsVectorLayerFeatureSource::QgsAbstractFeatureIteratorFromSource()’ /home/trap/qgis-git/QGIS/src/core/qgsfeatureiterator.h:113: note: candidates are: QgsAbstractFeatureIteratorFromSource template-parameter-1-1 ::QgsAbstractFeatureIteratorFromSource(T*, bool, const QgsFeatureRequest) [with T = QgsVectorLayerFeatureSource] /home/trap/qgis-git/QGIS/src/core/qgsfeatureiterator.h:111: note: QgsAbstractFeatureIteratorFromSourceQgsVectorLayerFeatureSource::QgsAbstractFeatureIteratorFromSource(const QgsAbstractFeatureIteratorFromSourceQgsVectorLayerFeatureSource) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Server: using same layer name in different projects
On Thu, Jun 19, 2014 at 10:12 AM, Andreas Neumann a.neum...@carto.net wrote: Hi Luca, It is a known issue. It is not an issue about the layer name, but of layer ids. You have to make sure that layer ids in all of your projects are unique. You probably copy/pasted projects and this does not upgrade the layerid. It is not a problem to have two or more identical layer names, but the layer ids have to be unique. I agree that this is suboptimal and should be resolved in an upcoming version. The layercache should have both the project name and the layerid to form a unique identifier from both attributes. Someone needs to either work on it or found this improvement. Thank you, it fixed my problem! :-) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
If I could chime in as a Non-developer. I might be more of a non-standard user (given with all the things I'm trying to do with QGIS). I tried to keep up with all the thoughts in this email chain - The joys of sleeping in the GMT-5 timeszone (or is it +)...anyway.. I look at QGIS has having four operating systems it supports: Linux (debian and ubuntu because I am familiar with those), mac, windows, android: * The linux releases only seem to get release once with no bug fixes. Really that depends on the distro though...but for Ubuntu I think that is correct. * The windows release (using osgeo) is absolutely great - it seems to be getting bugfixes all the time. * I've only installed QGIS on a MAC twice - but from what I can tell it might be getting bugfixes between releases * Android - I have no clue. Of course I have no clue how long it takes to release - I compiled QGIS once and that was an all day thing for me (adding libraries and things). I'm not a developer although I have dreams. A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. In 2.0 there was a problem with spatialite - there was no fix until the next release. It seems (if memory serves me ) there was a fix that rolled out on the OSGEO side in windows at some point. I went against what I normally do and have been running 2.3 for production and it's great (at least from my standpoint). I've tried to respond in with reports and what not. Really I say all of that and I think we (users) are good with whatever as long as you guys are happy with it. It seems like this email stirred up some uneasiness among your guys for release. Any user (in his right mind) isn't sitting there with everything waiting on 2.4 coming out in 48 hours. You guys are the experts - make yourselves happy. Happy developers = better QGIS release. If I could only add one thing - solidify the releases. Make each one mimic the other. Make Linux the same as windows the same as Mac. That's the joy of QGIS - it runs everywhere. Right now I thing the osgeo windows version (because mostly of sid and ecw support) is the best version released. I run xubuntu 14.04 on my main workstation and I think QGIS solid - but QGIS on windows seems to edge that one out just a bit. Maybe it's because most of the world runs on windows and mac and there's a few of use linux users out and about. Anyway - my 2 cents worth. Thank you for the work you are doing. Randy - Randal Hale North River Geographic Systems, Inc http://www.northrivergeographic.com 423.653.3611 tel:423.653.3611 rjh...@northrivergeographic.com mailto:rjh...@northrivergeographic.com twitter:rjhale http://about.me/rjhale On 06/19/2014 08:33 AM, Denis Rouzaud wrote: I think that LTS is kind of a really good idea. At some extent, it's what Sourcepole is doing with its QGIS enterprise. If we have enough companies paying for such bugfixes QA, that would be easily feasible, but someone should be in charge of handling this. Then, the cycle is another discussion. It could be either 2 or 3 releases a year, with 1 over 2 or 3 being LTS. But I would definitely investigate the idea of the LTS. Greetings, Denis On 19.06.2014 12:44, Matthias Kuhn wrote: Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 4:29 PM, Randal Hale rjh...@northrivergeographic.com wrote: A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. +1 for me, too. In 2.0 there was a problem with spatialite - there was no fix until the next release. It seems (if memory serves me ) there was a fix that rolled out on the OSGEO side in windows at some point. In Qgis 1.8 there was a blocking bug and thus it would require a 1.8.1, never released, I think, because for the switch from SVN to GIT. This bug was the impossibility to split a feature stored in a postgis table, because QGIS tried to duplicate the primary key. So we remained to QGIS 1.7.4 and now we are still at 2.0 (but we will migrate to 2.4 if it is all OK). ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 04:36:47PM +0200, Luca Manganelli wrote: In Qgis 1.8 there was a blocking bug and thus it would require a 1.8.1, never released, I think, because for the switch from SVN to GIT. This bug was the impossibility to split a feature stored in a postgis table, because QGIS tried to duplicate the primary key. So we remained to QGIS 1.7.4 and now we are still at 2.0 (but we will migrate to 2.4 if it is all OK). I'm still in love with 1.7.4. No other release got so high in patch-level number :) --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Qgis master very slow saving project closing with several layers
Hi devs, I have a projet with many layers (about 100). When I open it under QGIS 2.2, I can save it and then close QGIS quite quicky (about 2 or 3 seconds) When I do so with today QGIS master, it takes 5 minutes to save, then 5 more minutes to close QGIS ! I tried with --noplugins option, with rendering turned off, and with no layer checked in the legend. Is it a known projet ? You can hardly see it with an average project, but it is very noticeable when you have more than 20 or 30 layers/ Regards Michael ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi all, IMHO, I agree with the idea of having a LTS (maybe once a year) and intermediate releases for development. from my working experience, both with public institutions and privates, seems to be more comfortable not to shift from one version to the other very often; pretty appreciated is having one long lasting stable release. btw: thank you very much for the good job you do every day! Niccolò ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi Randal, On Thu, 19. Jun 2014 at 10:29:32 -0400, Randal Hale wrote: * The linux releases only seem to get release once with no bug fixes. Really that depends on the distro though...but for Ubuntu I think that is correct. Depends on the ubuntu version you have - and if there are packaging related bugs. For instance the trusty package was uninstallable (at least the python support) as trusty (unreleased at the time of the qgis release) moved on and hence the package was referring to package versions that didn't exist anymore. To fix that there was a new build from the release branch to solve that using the current release branch at that point. Other Packages that didn't need to be rebuild, because they were for stable releases weren't. Debian itself also has 2.2 builds that get the backported fixes (and Bas also backports some fixes we didn't backport and maybe stuff we didn't fix at all - I believe). But I Debian will probably stay at 2.2 and skip some upcoming version. * The windows release (using osgeo) is absolutely great - it seems to be getting bugfixes all the time. The qgis 2.2 package wasn't rebuild there either (even when it/I switched from GDAL 1.10.1 to 1.11). If you're referring to the nightly builds, than the ubuntu/debian argument argument above doesn't stick as we also have nightly builds for those - that would also have the latest fixes. as long as you guys are happy with it. It seems like this email stirred up some uneasiness among your guys for release. Any user (in his right mind) isn't sitting there with everything waiting on 2.4 coming out in 48 hours. Only ~20hrs. Friday 12:00 UTC. Right now I thing the osgeo windows version (because mostly of sid and ecw support) is the best version released. 2.2 (or better put GDAL 1.10.1) in OSGeo4W currently doesn't have plugins for MrSid and ECW. The standalone installer was made from the same binaries, but at release time when GDAL 1.10.1 was still default and still has ECW and MrSid out of the box. The nightly build however uses GDAL 1.11 which has those plugins. And 2.4 will be built with current GDAL in OSGeo4W and therefore will also have ECW/MrSid support. A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. That's the point. For the packaging it doesn't matter if you build a new release or an old release with bugfixes (one or a dozen). The effort is essentially the same. It just about building one state for a number of platforms. The release or bugfixes are already done at that point. So a new release every four month w/o bugfix release between release is less effort than a new release every six month with 2 bugfix releases. 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) Germany 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] Four month cycle too fast
Hey - thanks for the explanation. Like I said - this is just from my perspective - A user who might know more than the average user or might be completely delusional (I vote for delusional). Youcan see what impressions I get from things - right or wrong. I think whatever makes the most sense for the developers. The users are more or less along for the ride and all seem very happy with the software. I taught a class on QGIS last week and everyone was sitting there (these are all ESRI users) ecstatic that this previously unknown software exists. Whatever is decided - put it on the website. Just let people know and if it's a 5 month or 4 month or 6 month everyone should be happy - if they aren't ask for donations to speed it up. All of you are packing a tremendous amount of time and effort into this - it's not unnoticed. Again - Thanks for your efforts. Randy On 06/19/2014 12:00 PM, Jürgen E. Fischer wrote: Hi Randal, On Thu, 19. Jun 2014 at 10:29:32 -0400, Randal Hale wrote: * The linux releases only seem to get release once with no bug fixes. Really that depends on the distro though...but for Ubuntu I think that is correct. Depends on the ubuntu version you have - and if there are packaging related bugs. For instance the trusty package was uninstallable (at least the python support) as trusty (unreleased at the time of the qgis release) moved on and hence the package was referring to package versions that didn't exist anymore. To fix that there was a new build from the release branch to solve that using the current release branch at that point. Other Packages that didn't need to be rebuild, because they were for stable releases weren't. Debian itself also has 2.2 builds that get the backported fixes (and Bas also backports some fixes we didn't backport and maybe stuff we didn't fix at all - I believe). But I Debian will probably stay at 2.2 and skip some upcoming version. * The windows release (using osgeo) is absolutely great - it seems to be getting bugfixes all the time. The qgis 2.2 package wasn't rebuild there either (even when it/I switched from GDAL 1.10.1 to 1.11). If you're referring to the nightly builds, than the ubuntu/debian argument argument above doesn't stick as we also have nightly builds for those - that would also have the latest fixes. as long as you guys are happy with it. It seems like this email stirred up some uneasiness among your guys for release. Any user (in his right mind) isn't sitting there with everything waiting on 2.4 coming out in 48 hours. Only ~20hrs. Friday 12:00 UTC. Right now I thing the osgeo windows version (because mostly of sid and ecw support) is the best version released. 2.2 (or better put GDAL 1.10.1) in OSGeo4W currently doesn't have plugins for MrSid and ECW. The standalone installer was made from the same binaries, but at release time when GDAL 1.10.1 was still default and still has ECW and MrSid out of the box. The nightly build however uses GDAL 1.11 which has those plugins. And 2.4 will be built with current GDAL in OSGeo4W and therefore will also have ECW/MrSid support. A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. That's the point. For the packaging it doesn't matter if you build a new release or an old release with bugfixes (one or a dozen). The effort is essentially the same. It just about building one state for a number of platforms. The release or bugfixes are already done at that point. So a new release every four month w/o bugfix release between release is less effort than a new release every six month with 2 bugfix releases. Jürgen -- - Randal Hale North River Geographic Systems, Inc http://www.northrivergeographic.com 423.653.3611 rjh...@northrivergeographic.com twitter:rjhale http://about.me/rjhale ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vectors displayed as
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 16/06/2014 18:13, Werner Macho ha scritto: looking closer it seems that one of them is not connected correctly .. On 06/16/2014 04:59 PM, Paolo Cavallini wrote: Hi all. IN Vector properties General Layer name there is a field called displayed as: what is this useful for? It seems just an echo of the adjoining field Layer name. All the best. Hi all. So, it is confirmed as useless? Should I open a ticket, or maybe even remove it from the GUI soon? All the best. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlOjEdYACgkQ/NedwLUzIr4BNQCgjA3ulCwufMzsXW4g2XtnS07T /hIAoIOVQmWWthoqaQiQ73irWl28WQ6f =rA/I -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please help build a great visual changelog for 2.4
Hi, On Fri, 23. May 2014 at 22:33:45 +0200, Tim Sutton wrote: Feature freeze is here and I would like to start compiling the visual changelog for QGIS 2.4.0 'Chugiak'. I have set up a new version on http://changelog.linfiniti.com/qgis/version/2.4.0/ Could I invite contributors and interested observers to highlight the cool new features that have come into QGIS in this release cycle on the above site. You need to log in to create an account and then start creating 'entries' for the 'version'. Please note that the software on that website is still very much a work in progress rather than a statement of perfection so please bear with the odd glitch you may encounter. For those who have asked before, yes we do intend to support a native QGIS domain for that site in the future, but currently the idea is for us to compile the changelog there and then it will be exported by RSS feed or RST export over to the live QGIS web site. If you can't be bothered to actually use the site above, no problem, just mail me with a paragraph or two describing the new feature, and a nice screenshot (if possible) that shows it off. Please note there is a limit of 1 screenshot per feature (entry). Also don't worry of you are not a native english speaker, I am happy to edit any submissions into the Queen's english. Is there something wrong with the site or did this got completely overlooked? 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) Germany 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] Vectors displayed as
I would not say it is useless - if you have renamed the layer you could find the original name (on load) there .. regards Werner On Thu, Jun 19, 2014 at 5:37 PM, Paolo Cavallini cavall...@faunalia.it wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 16/06/2014 18:13, Werner Macho ha scritto: looking closer it seems that one of them is not connected correctly .. On 06/16/2014 04:59 PM, Paolo Cavallini wrote: Hi all. IN Vector properties General Layer name there is a field called displayed as: what is this useful for? It seems just an echo of the adjoining field Layer name. All the best. Hi all. So, it is confirmed as useless? Should I open a ticket, or maybe even remove it from the GUI soon? All the best. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlOjEdYACgkQ/NedwLUzIr4BNQCgjA3ulCwufMzsXW4g2XtnS07T /hIAoIOVQmWWthoqaQiQ73irWl28WQ6f =rA/I -END PGP SIGNATURE- ___ 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] Vectors displayed as
Il 19/06/2014 18:58, Werner Macho ha scritto: I would not say it is useless - if you have renamed the layer you could find the original name (on load) there .. Hi Werner, sorry, I miss your point. Here the second string is always the same as the first one. I must be missing something obvious. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
I would like to add something else to the discussion, qgis is adding a lot of new features and enhancements and don't get me wrong I love them, but it seems bugs are not squashed at the same pace, I get that adding enhancements and new features is nice and desirable but I would like one release being just fixing bugs no enhancements and a release adding enhancements plus keep squashing bugs -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Four-month-cycle-too-fast-tp5146648p5146817.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vectors displayed as
*Layer name* could be the name in a postgis table for example, *displayed as* I would say should work more like an alias, in my opinion Layer name shouldn't be editable and just be read only as this gives you the name of the layer in provider, *displayed as* should be editable so people can use another name if desired, of course by default it would echo layer name -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Vectors-displayed-as-tp5146137p5146822.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Hackfest/ developers meeting in Spring 2015
Hello, Le jeudi 19 juin 2014 11:57:19, Victor Olaya a écrit : If for a future edition you need help with organizing a hackfest in Spain, i will be happy to help. Also, the french QGIS community seems to be rather active, so if anyone from it wants to do something here, I will be ready to help as much as I can. Just let me know about what i can do. I think both options (France, Spain) would be very good as future hackfest locations. As for hosting a codesprint in France next year (or later), it is clearly doable. We could do it in Lyon again quite easily. Paris could be an option but is expensive and not that convenient for such an event, even if well connected. We could probably easily organize something in Nantes as well, dynamic city with good opensource commitment, 2h from Paris by train. If interested in any of these places, just ask, and the OSGeo-fr team will start to see if something great can be organized. Vincent Until that happens, let's enjoy Denmark ;-) 2014-06-19 11:50 GMT+02:00 Gino Pirelli lui...@gmail.com: victor I'm agree about the quality of the copenhagen offer, but remember that we (spain) loosed again the opportunity to host a hackfest due the fact that none answered from Girona to the offer do the hackfest there! :| we should plan to self-organize the hackfest using CENATIC ( http://amtega.xunta.es/) or AMTEGA (http://amtega.xunta.es/) support see you Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com) On 19 June 2014 10:31, Victor Olaya vola...@gmail.com wrote: Awesome news! I really enjoyed the time I spend there for their QGIS course last April, and I cannot think of a better place for a GIS hackfest :-) 2014-06-19 10:14 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. On behalf of Lene Fscher, from the University of Copenhagen, I'm inviting QGIS developers to the spring 2015 hackfest in Danmark. See below for details. Thanks Lene! All the best. Messaggio Inoltrato This is an invitation to come to Denmark in May 2015 for Developers meeting and Hackfest – or what it is called J University of Copenhagen would like to be host for this event. Our department at the The Forest and Landscape College is situated in Nødebo – 40 km north of Copenhagen. In the week from 18.-22. May 2015 We have room for 34 persons and a hostel nearby is more persons would like to participate. We have a very good canteen which can provide us with food and coffee https://www.facebook.com/SpisehusetSkovskolen We have rooms for working We have an organization for having arrangements like this We have students for testing – they are used to work with QGIS We have “Flækken” the students place for beer and relaxation And place for time off in the forest…. It is easy to get here from Copenhagen. In April 2014, Victor Olaya and Martin Isenburg visited us for a workshop. Please ask Victor for his opinion about our campus could be a place for this event. http://ign.ku.dk/om/skovskolen/ https://www.facebook.com/SkovOgLandkabsingenior Regards *Lene Fischer* Associate Professor *Department of Geosciences and Natural Resource Management* University of Copenhagen l...@ign.ku.dk mailto:l...@ign.ku.dk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Move Point with buffer
BTW, I think we should really remove it, better sooner than later. Perhaps just after 2.4 release? On 18 giugno 2014 06:36:22 CEST, Nyall Dawson nyall.daw...@gmail.com wrote: On 18 June 2014 12:24, Stefan Sylla stefansy...@gmx.de wrote: Basically you can accomplish that by importing your point layer to a Postgis database (using th SPIT plugin in QGIS) Don't use the SPIT plugin - it's old and unmaintained. Use either dbManager or the Import into PostGIS algorithm in processing. I was one of the first to propose the removal of SPIT unfortunately is net yet doable because many have the need to import a lot of layers at once: * db manager doesn't do it, and it is dead slow * the tool in the processing toolbox can work in batch mode but 1) is slow (if compared to SPIT) and does not auto-fill table names when used as btach process. cheers -- G -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qgis master very slow saving project closing with several layers
Hi devs, I have a projet with many layers (about 100). When I open it under QGIS 2.2, I can save it and then close QGIS quite quicky (about 2 or 3 seconds) When I do so with today QGIS master, it takes 5 minutes to save, then 5 more minutes to close QGIS ! I also noticed it and about to write a ticket, indeed a serious issue. cheers! -- g -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Datum Transformation - parameters for mainland Portugal
it has little use to change the parameters in QGIS only. the proposed transformations are OK and widely accepted and used in Portugal. On the other hand it seems there is little interest from the official authorities to contribute to the upstream projects/libraries, so to help average Jane/Joe having those in QGIS will be very useful. cheers -- G -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Datum Transformation - parameters for mainland Portugal
Am 19.06.2014 20:37, schrieb Giovanni Manghi: the proposed transformations are OK and widely accepted and used in Portugal. On the other hand it seems there is little interest from the official authorities to contribute to the upstream projects/libraries, so to help average Jane/Joe having those in QGIS will be very useful. I gave a little overview on available Portuguese datum shifts in the EPSG database here: http://gis.stackexchange.com/questions/45456/how-can-i-see-the-coordinate-transformation-parameters-in-qgis Unfortunately, the transformation with the least accuracy is implemented in GDAL/PROJ. It would not be much work to select one of the others as default. I could open a ticket for that, but I don't have any official reference data to proove the accuracy. The values supplied by Pedro are similar, but they should go the official way into the EPSG database. This does not have to be done by local authorities. The EPSG registry website remarks: Change requests are accepted from any interested party. They should be made by electronic submission of the change request and comment form on the make change request. I suggest to raise the topic on the GDAL or PROJ mailing list before making a change request. But I would not encourage to delete any EPSG code and invent new ones inside QGIS as Pedro suggested. Greetings, André Joost ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please help build a great visual changelog for 2.4
Is there a specific reason why there are entries listed in thumbnail view http://changelog.linfiniti.com/qgis/version/2.4.0/thumbs/ but not in list view http://changelog.linfiniti.com/qgis/version/2.4.0/ ? Best wishes, Anita On Thu, Jun 19, 2014 at 6:43 PM, Jürgen E. j...@norbit.de wrote: Hi, On Fri, 23. May 2014 at 22:33:45 +0200, Tim Sutton wrote: Feature freeze is here and I would like to start compiling the visual changelog for QGIS 2.4.0 'Chugiak'. I have set up a new version on http://changelog.linfiniti.com/qgis/version/2.4.0/ Could I invite contributors and interested observers to highlight the cool new features that have come into QGIS in this release cycle on the above site. You need to log in to create an account and then start creating 'entries' for the 'version'. Please note that the software on that website is still very much a work in progress rather than a statement of perfection so please bear with the odd glitch you may encounter. For those who have asked before, yes we do intend to support a native QGIS domain for that site in the future, but currently the idea is for us to compile the changelog there and then it will be exported by RSS feed or RST export over to the live QGIS web site. If you can't be bothered to actually use the site above, no problem, just mail me with a paragraph or two describing the new feature, and a nice screenshot (if possible) that shows it off. Please note there is a limit of 1 screenshot per feature (entry). Also don't worry of you are not a native english speaker, I am happy to edit any submissions into the Queen's english. Is there something wrong with the site or did this got completely overlooked? 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) Germany 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Attribute table update after trigger in Postgis
I want to check with developers before raising an issue, I have a postgis table with triggers to update fields after updates, I would expect to see the updated fields to show up after I toggle editing but right now I have to close the attribute table and reopen it to see the changes -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Attribute-table-update-after-trigger-in-Postgis-tp5146841.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Error compiling master on Ubuntu 12.04 - qgis_gui
Hi, I continue today with this problem. I leave here the complete log to someone who can give a look: http://goo.gl/oBbb3u Thank you very much! Best regards, Pedro ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Attribute table opening several instances
Is there any use case where having the possibility of opening several times the same attribute table for a layer useful? Right now when opening attribute table on a layer you can open n attribute tables if you don't previously close it. I would think if you already have an opened attribute table for a layer and then clic Open Attribute table it should open a new window unless there is already one open, in that case it should focus the previously opened table respecting any formatting on it -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Attribute-table-opening-several-instances-tp5146844.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Attribute table opening several instances
I think the current way it works is correct. There have been times when I wanted to compare the full table to a selection. Nathan On Jun 20, 2014 6:00 AM, AntonioLocandro antoniolocan...@hotmail.com wrote: Is there any use case where having the possibility of opening several times the same attribute table for a layer useful? Right now when opening attribute table on a layer you can open n attribute tables if you don't previously close it. I would think if you already have an opened attribute table for a layer and then clic Open Attribute table it should open a new window unless there is already one open, in that case it should focus the previously opened table respecting any formatting on it -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Attribute-table-opening-several-instances-tp5146844.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] edit widgets do not work in current master
Hi, I have some project (saved with 2.2) with some edit widget customization (hidden field, value map etc). When opening the 2.2 project in current master the edit widgets do not work anymore, i.e fields are visible even though they are set on hidden, descriptions are not shown in the attributes even though the value map is properly set up Anybody else confirms? Best Regards, -SL -- Salvatore Larosa linkedIn: http://linkedin.com/in/larosasalvatore twitter: @lrssvt skype: s.larosa IRC: lrssvt on freenode ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Attribute table update after trigger in Postgis
Hi Antonio That would be a feature request for integrating push-notifications from postgresql to QGIS. I think it could be possible, but it would require changes on postgres side and QGIS side. At the moment to my knowledge none of the dataproviders supported by QGIS currently ever sends change notifications. Therefore any change in the datasource just appear when the data gets queried again. The attribute table makes use of caching to be responsive. All in all: I think it could be possible, but it's not trivial and should not be treated as bug, but rather a new feature. On Don 19 Jun 2014 21:49:44 CEST, AntonioLocandro wrote: I want to check with developers before raising an issue, I have a postgis table with triggers to update fields after updates, I would expect to see the updated fields to show up after I toggle editing but right now I have to close the attribute table and reopen it to see the changes -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Attribute-table-update-after-trigger-in-Postgis-tp5146841.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Datum Transformation - parameters for mainland Portugal
Hi Andre and Marco, These parameters are outdated. The current and official parameters for Molodensky and Bursa-Wolf transformations are those which are currently in the Directorate-General of the Territory website [0], and which are those that I proposed. In addition, the Datum Transformation, at this moment, does not work for Lisbon Datum, because the code of the geographical system used by EPSG:20790 is not EPSG:4207 [1], but EPSG:4803 [2], as you can see here [3]. No doubt that the ideal would be to have these transformations in proj and gdal, but that should be much more complicated, because these projects should get the information from EPSG database, and almost sure that this update, even if it can be requested by us (portuguese QGIS user group), it will take time. However, doing this update in Datum Transformation, would enable the use of NTv2 grids, and Molodensky and Bursa-Wolf transformations with the latest parameters, very easily (especially if we could place the grids directly in QGIS). I doubt there is another GIS software with this capability! Regarding the possible bug that I spoke in the original post, what do you think? Thank you very much! Best regards, Pedro [0] http://www.dgterritorio.pt/cartografia_e_geodesia/geodesia/transformacao_de_coordenadas/ [1] http://epsg.io/4207 [2] http://epsg.io/4803 [3] http://epsg.io/20790 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] edit widgets do not work in current master
Hi Salvatore, did that just appear right now? The changes to the edit widgets have been merged a couple of weeks ago already. It would be good to open a bug report with a demo project. Best, Matthias On Don 19 Jun 2014 22:07:24 CEST, Salvatore Larosa wrote: Hi, I have some project (saved with 2.2) with some edit widget customization (hidden field, value map etc). When opening the 2.2 project in current master the edit widgets do not work anymore, i.e fields are visible even though they are set on hidden, descriptions are not shown in the attributes even though the value map is properly set up Anybody else confirms? Best Regards, -SL -- Salvatore Larosa linkedIn: http://linkedin.com/in/larosasalvatore twitter: @lrssvt skype: s.larosa IRC: lrssvt on freenode ___ 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] Attribute table opening several instances
OK, that is actually quite handy instead of having to open another QGIS session. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Attribute-table-opening-several-instances-tp5146844p5146853.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] edit widgets do not work in current master
Hi Matthias, On Thu, Jun 19, 2014 at 10:49 PM, Matthias Kuhn matthias.k...@gmx.ch wrote: Hi Salvatore, did that just appear right now? The changes to the edit widgets have been merged a couple of weeks ago already. It would be good to open a bug report with a demo project. Sorry I noticed that just now, I cannot remember the last time that it was working. I am going to file a ticket with a sample project! Best, Matthias On Don 19 Jun 2014 22:07:24 CEST, Salvatore Larosa wrote: Hi, I have some project (saved with 2.2) with some edit widget customization (hidden field, value map etc). When opening the 2.2 project in current master the edit widgets do not work anymore, i.e fields are visible even though they are set on hidden, descriptions are not shown in the attributes even though the value map is properly set up Anybody else confirms? Best Regards, -SL -- Salvatore Larosa linkedIn: http://linkedin.com/in/larosasalvatore twitter: @lrssvt skype: s.larosa IRC: lrssvt on freenode ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Salvatore Larosa linkedIn: http://linkedin.com/in/larosasalvatore twitter: @lrssvt skype: s.larosa IRC: lrssvt on freenode ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Error compiling master on Ubuntu 12.04 - qgis_gui
I continue today with this problem. I leave here the complete log to someone who can give a look: http://goo.gl/oBbb3u Sorry, the link was blocked. Here is the original: https://dl.dropboxusercontent.com/u/5772257/qgis/log.txt Thanks! Best regards, Pedro ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Getting access to atlas record
On 19/06/2014 11:56 pm, Andreas Neumann a.neum...@carto.net wrote: Hi, Question: is it already possible to get access to any attribute in the current atlas feature record? Hi Andreas, I've been working on this. I nearly had it ready for 2.4, but in the end I wasn't comfortable pushing it late in the development cycle. What I've done is: - Add an $atlasfeature variable, which returns the current atlas feature - Add a $currentfeature variable, which returns the current feature which is being evaluated (unfortunately $feature is already used for the current atlas feature NUMBER, which is an issue for a separate email!) - Add an attribute( feature, column ) function, which returns the value stored in the specified column for a given feature This allows you to do an expression like: area_code = attribute($atlasfeature, 'area_code') Or, you can do neat things like label a column using an expression to choose the column name!.. attribute( $currentfeature, label_column ) Hopefully I can push this soon after master is unfrozen. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please help build a great visual changelog for 2.4
I have been through and updated all the entries - you should see them published at: http://changelog.linfiniti.com/qgis/version/2.4.0/ Thanks to all those that contributed. If anyone has additions please go ahead and add them and I will edit and publish. Regards Tim On Fri, Jun 20, 2014 at 3:28 AM, Anita Graser anitagra...@gmx.at wrote: Is there a specific reason why there are entries listed in thumbnail view http://changelog.linfiniti.com/qgis/version/2.4.0/thumbs/ but not in list view http://changelog.linfiniti.com/qgis/version/2.4.0/ ? Best wishes, Anita On Thu, Jun 19, 2014 at 6:43 PM, Jürgen E. j...@norbit.de wrote: Hi, On Fri, 23. May 2014 at 22:33:45 +0200, Tim Sutton wrote: Feature freeze is here and I would like to start compiling the visual changelog for QGIS 2.4.0 'Chugiak'. I have set up a new version on http://changelog.linfiniti.com/qgis/version/2.4.0/ Could I invite contributors and interested observers to highlight the cool new features that have come into QGIS in this release cycle on the above site. You need to log in to create an account and then start creating 'entries' for the 'version'. Please note that the software on that website is still very much a work in progress rather than a statement of perfection so please bear with the odd glitch you may encounter. For those who have asked before, yes we do intend to support a native QGIS domain for that site in the future, but currently the idea is for us to compile the changelog there and then it will be exported by RSS feed or RST export over to the live QGIS web site. If you can't be bothered to actually use the site above, no problem, just mail me with a paragraph or two describing the new feature, and a nice screenshot (if possible) that shows it off. Please note there is a limit of 1 screenshot per feature (entry). Also don't worry of you are not a native english speaker, I am happy to edit any submissions into the Queen's english. Is there something wrong with the site or did this got completely overlooked? 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) Germany 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 ___ 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] Expression engine functions and naming
Hi all, I thought I'd raise an issue which has been on my mind a bit lately, and I'm not sure how to proceed with fixing it. At the moment there's a huge lack of consistency in function names in the QGIS expression engine. Here's some examples: - Some functions use the naming convention of seperating lowercase words with underscores, for example format_number, format_date, color_rgb - Others use all lowercase, no underscore, eg tostring, wordwrap - Still others use camel case, eg geomFromWKT, symDifference Basically, we've got a mix of every naming convention possible. I think there's an urgent need for us to choose a convention and ensure that all newly introduced functions adhere to this. The follow up question is whether or not we can clean up this mess. Can we rename functions in a way that doesn't negatively impact users? Possibly we could have aliases for functions which evaluate ok so that older projects can still work, but which aren't shown the the user in the dialog. There's also some function names formats which really bug me, specifically: - $feature, $numfeatures. Ideally these should be named something more appropriate like $atlas_feature_num and $atlas_feature_count, since they directly relate to atlas variables. From their names it seems more logical that these would return the current feature and number of features in the current layer. - I made a dumb decision when I created the clamp function and put the parameters in the minimum,input,maximum order. In retrospect these should be input,minimum,maximum I'm guessing there's nothing we can do to retrospectively fix these inconsistencies now? Cheers, Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Getting access to atlas record
Hey Nyall, I would like to revisit this with you at some stage and maybe explore the expression context stuff. Having one global variable for all this isn't going to scale if we ever allow bulk atlas export. - Nathan On Fri, Jun 20, 2014 at 1:34 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On 19/06/2014 11:56 pm, Andreas Neumann a.neum...@carto.net wrote: Hi, Question: is it already possible to get access to any attribute in the current atlas feature record? Hi Andreas, I've been working on this. I nearly had it ready for 2.4, but in the end I wasn't comfortable pushing it late in the development cycle. What I've done is: - Add an $atlasfeature variable, which returns the current atlas feature - Add a $currentfeature variable, which returns the current feature which is being evaluated (unfortunately $feature is already used for the current atlas feature NUMBER, which is an issue for a separate email!) - Add an attribute( feature, column ) function, which returns the value stored in the specified column for a given feature This allows you to do an expression like: area_code = attribute($atlasfeature, 'area_code') Or, you can do neat things like label a column using an expression to choose the column name!.. attribute( $currentfeature, label_column ) Hopefully I can push this soon after master is unfrozen. 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] Expression engine functions and naming
Hi, Yes. When I initially saw $feature and $numfeatures I thought - oh cool - I can have access to the feature-record - although - as you said it wasn't clear which feature this would be refering to. This naming is really sub-optimal and hopefully we can still correct it. When was this introduced? In 2.4? If yes, there can hardly be any content using this and I would propose to correct this today before we ship. As to the other cleanup: what you propose: adding aliases in 2.6 and then deprecate the old inconsistent function names in a later version sound like a plan to me. Andreas Am 20.06.2014 04:19, schrieb Nyall Dawson: Hi all, I thought I'd raise an issue which has been on my mind a bit lately, and I'm not sure how to proceed with fixing it. At the moment there's a huge lack of consistency in function names in the QGIS expression engine. Here's some examples: - Some functions use the naming convention of seperating lowercase words with underscores, for example format_number, format_date, color_rgb - Others use all lowercase, no underscore, eg tostring, wordwrap - Still others use camel case, eg geomFromWKT, symDifference Basically, we've got a mix of every naming convention possible. I think there's an urgent need for us to choose a convention and ensure that all newly introduced functions adhere to this. The follow up question is whether or not we can clean up this mess. Can we rename functions in a way that doesn't negatively impact users? Possibly we could have aliases for functions which evaluate ok so that older projects can still work, but which aren't shown the the user in the dialog. There's also some function names formats which really bug me, specifically: - $feature, $numfeatures. Ideally these should be named something more appropriate like $atlas_feature_num and $atlas_feature_count, since they directly relate to atlas variables. From their names it seems more logical that these would return the current feature and number of features in the current layer. - I made a dumb decision when I created the clamp function and put the parameters in the minimum,input,maximum order. In retrospect these should be input,minimum,maximum I'm guessing there's nothing we can do to retrospectively fix these inconsistencies now? Cheers, 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] Getting access to atlas record
Hi Nyall, Cool that you had a look at this already. It would open up a lot of possibilities. Along the same lines I noticed that the table in print composer is not updated correctly when iterating in the atlas preview mode (don't know if it works when generating the pdfs). My usage scenario was that I could filter a linked attribute table based on a spatial query based on the atlas coverage table. E.g. my atlas coverage table was a polygon layer with communities and my other table was a point-layer with school and kindergardens. In the atlas I wanted to filter the table with the schools and kindergardens with the expression within($geometry,$atlasgeometry). The filter works fine, but the table does not update when iterating. I will open a feature request for the access to $atlasfeature and a bug-report for the table update issue. Maybe, if we ever ship a bugfix release, the table update issue could go in there. It would be very nice if this bug were resolved. Again - I really did not have enough time in one month to test all the functionalities (old and new one). Impossible at least for me. Andreas Hi Andreas, I've been working on this. I nearly had it ready for 2.4, but in the end I wasn't comfortable pushing it late in the development cycle. What I've done is: - Add an $atlasfeature variable, which returns the current atlas feature - Add a $currentfeature variable, which returns the current feature which is being evaluated (unfortunately $feature is already used for the current atlas feature NUMBER, which is an issue for a separate email!) - Add an attribute( feature, column ) function, which returns the value stored in the specified column for a given feature This allows you to do an expression like: area_code = attribute($atlasfeature, 'area_code') Or, you can do neat things like label a column using an expression to choose the column name!.. attribute( $currentfeature, label_column ) Hopefully I can push this soon after master is unfrozen. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Getting access to atlas record
Hi Nyall On Fri, Jun 20, 2014 at 10:34 AM, Nyall Dawson nyall.daw...@gmail.com wrote: What I've done is: - Add an $atlasfeature variable, which returns the current atlas feature - Add a $currentfeature variable, which returns the current feature which is being evaluated (unfortunately $feature is already used for the current atlas feature NUMBER, which is an issue for a separate email!) - Add an attribute( feature, column ) function, which returns the value stored in the specified column for a given feature This allows you to do an expression like: area_code = attribute($atlasfeature, 'area_code') May I suggest an alternative approach: to introduce dot notation, e.g. $atlasfeature.area_code - that looks much more like SQL syntax and it is easier to remember and use. It would require small adjustments to the parser and evaluator in order to support nested objects, but I think it would be worth it. I could help with that if needed. Or, you can do neat things like label a column using an expression to choose the column name!.. attribute( $currentfeature, label_column ) This would need some extra care: the expression tells in referencedColumns() call what fields are going to be used. If we support thing like this, we need to ensure that all attributes are fetched. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Getting access to atlas record
On 20 June 2014 15:18, Martin Dobias wonder...@gmail.com wrote: May I suggest an alternative approach: to introduce dot notation, e.g. $atlasfeature.area_code - that looks much more like SQL syntax and it is easier to remember and use. It would require small adjustments to the parser and evaluator in order to support nested objects, but I think it would be worth it. I could help with that if needed. What about evaluating a column name on the fly though? How could this be handled? Maybe both ways should be supported... This would need some extra care: the expression tells in referencedColumns() call what fields are going to be used. If we support thing like this, we need to ensure that all attributes are fetched. That's exactly why I held off on this for 2.4 -- I've had to introduce a usesAllColumns() function to indicate that all columns are required, not just those from the referencedColumns() list. This requires changes to a wide scattering of code throughout QGIS to take advantage of this, and not just rely on referencedColumns to determine the subset to fetch. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Getting access to atlas record
On 20 June 2014 15:07, Andreas Neumann a.neum...@carto.net wrote: Hi Nyall, Cool that you had a look at this already. It would open up a lot of possibilities. Along the same lines I noticed that the table in print composer is not updated correctly when iterating in the atlas preview mode (don't know if it works when generating the pdfs). Thanks Andreas, I'll take a look. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Expression engine functions and naming
On 20.06.2014 06:19, Nyall Dawson wrote: Hi all, I thought I'd raise an issue which has been on my mind a bit lately, and I'm not sure how to proceed with fixing it. At the moment there's a huge lack of consistency in function names in the QGIS expression engine. Here's some examples: - Some functions use the naming convention of seperating lowercase words with underscores, for example format_number, format_date, color_rgb - Others use all lowercase, no underscore, eg tostring, wordwrap - Still others use camel case, eg geomFromWKT, symDifference Basically, we've got a mix of every naming convention possible. I think there's an urgent need for us to choose a convention and ensure that all newly introduced functions adhere to this. The follow up question is whether or not we can clean up this mess. Can we rename functions in a way that doesn't negatively impact users? Possibly we could have aliases for functions which evaluate ok so that older projects can still work, but which aren't shown the the user in the dialog. +1 if possible There's also some function names formats which really bug me, specifically: - $feature, $numfeatures. Ideally these should be named something more appropriate like $atlas_feature_num and $atlas_feature_count, since they directly relate to atlas variables. From their names it seems more logical that these would return the current feature and number of features in the current layer. can't we use the same alias idea for this? - I made a dumb decision when I created the clamp function and put the parameters in the minimum,input,maximum order. In retrospect these should be input,minimum,maximum Regarding clamp, since this was added during developpement phase and nothing was released since, I would vote for changing it now. People using master know this might happen. Just send a mail to the list saying this. Cheers, Denis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Expression engine functions and naming
Hi again On Fri, Jun 20, 2014 at 11:19 AM, Nyall Dawson nyall.daw...@gmail.com wrote: Hi all, I thought I'd raise an issue which has been on my mind a bit lately, and I'm not sure how to proceed with fixing it. At the moment there's a huge lack of consistency in function names in the QGIS expression engine. Here's some examples: - Some functions use the naming convention of seperating lowercase words with underscores, for example format_number, format_date, color_rgb - Others use all lowercase, no underscore, eg tostring, wordwrap - Still others use camel case, eg geomFromWKT, symDifference Basically, we've got a mix of every naming convention possible. I think there's an urgent need for us to choose a convention and ensure that all newly introduced functions adhere to this. The function names are case insensitive, so the problem boils down to with / without underscore. It seems that even in SQL function naming there is not really a common rule which is the preferred option... The follow up question is whether or not we can clean up this mess. Can we rename functions in a way that doesn't negatively impact users? Possibly we could have aliases for functions which evaluate ok so that older projects can still work, but which aren't shown the the user in the dialog. Yeah, we could do that. Later, in QGIS 3 we may remove them completely and provide helpers for loading of older projects to transform the expressions to newer syntax. There's also some function names formats which really bug me, specifically: - $feature, $numfeatures. Ideally these should be named something more appropriate like $atlas_feature_num and $atlas_feature_count, since they directly relate to atlas variables. From their names it seems more logical that these would return the current feature and number of features in the current layer. True. To follow up my previous mail, I would like even more to have object $atlas with nested values, so we would use dot notation e.g. $atlas.feature_count And maybe we should just do more planning when adding new stuff to expressions. Maybe some small RFCs...? - I made a dumb decision when I created the clamp function and put the parameters in the minimum,input,maximum order. In retrospect these should be input,minimum,maximum Actually I like the former syntax - although it seems that most of APIs use the latter... I'm guessing there's nothing we can do to retrospectively fix these inconsistencies now? Not much I guess. This is very similar to API problems, with the difference that expressions affect not only developers, but also users. Regads Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Expression engine functions and naming
On 20 June 2014 15:02, Andreas Neumann a.neum...@carto.net wrote: Hi, Yes. When I initially saw $feature and $numfeatures I thought - oh cool - I can have access to the feature-record - although - as you said it wasn't clear which feature this would be refering to. This naming is really sub-optimal and hopefully we can still correct it. When was this introduced? In 2.4? If yes, there can hardly be any content using this and I would propose to correct this today before we ship. It's been around a long time - since October 2012. I think we're stuck with it for the moment, unless anyone has any novel ways around this? Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Expression engine functions and naming
On 20 June 2014 15:31, Denis Rouzaud denis.rouz...@gmail.com wrote: Regarding clamp, since this was added during developpement phase and nothing was released since, I would vote for changing it now. People using master know this might happen. Just send a mail to the list saying this. Clamp was introduced in 2.2, so we can't modify it now without breaking existing projects. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Getting access to atlas record
On Fri, Jun 20, 2014 at 12:29 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On 20 June 2014 15:18, Martin Dobias wonder...@gmail.com wrote: May I suggest an alternative approach: to introduce dot notation, e.g. $atlasfeature.area_code - that looks much more like SQL syntax and it is easier to remember and use. It would require small adjustments to the parser and evaluator in order to support nested objects, but I think it would be worth it. I could help with that if needed. What about evaluating a column name on the fly though? How could this be handled? Maybe both ways should be supported... Actually the dot syntax would imply on the fly evaluation. When parsing, it is not possible to decide what will be the content of an object. This would be similar to python: the expression x.y means that in object x it should look up x in the dictionary of attributes and return its value. This would need some extra care: the expression tells in referencedColumns() call what fields are going to be used. If we support thing like this, we need to ensure that all attributes are fetched. That's exactly why I held off on this for 2.4 -- I've had to introduce a usesAllColumns() function to indicate that all columns are required, not just those from the referencedColumns() list. This requires changes to a wide scattering of code throughout QGIS to take advantage of this, and not just rely on referencedColumns to determine the subset to fetch. I see. Another option could be to have a special column name that would indicate that all columns are needed - this special name would be understood by QgsFeatureRequest. That would keep the usage of QgsExpression same as before, without having to discriminate between the two cases... Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
