Re: [Qgis-developer] Getting access to atlas record
On 20 June 2014 15:43, Martin Dobias wonder...@gmail.com wrote: 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. I mean column names which are themselves the result of an evaluated expression. For eaxmple, if my table was something like: id, label_with, label1, label2 1000, 1, 'a', 'b' 1001, 2, 'a', 'b' I'd like to be able to label this with an expression like: attribute( feature, 'label' || label_with). If the column name was evaluated as a result of the 'label' || label_with expression, then the returned feature attribute value would be 'a' for feature 1000 and 'b' for feature 1001. (Sorry for the confusing example!). Could this be done using dot notation? 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... That sounds like it might be an easier approach, I'll give it a try! 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
On Fri, Jun 20, 2014 at 1:00 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On 20 June 2014 15:43, Martin Dobias wonder...@gmail.com wrote: 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. I mean column names which are themselves the result of an evaluated expression. For eaxmple, if my table was something like: id, label_with, label1, label2 1000, 1, 'a', 'b' 1001, 2, 'a', 'b' I'd like to be able to label this with an expression like: attribute( feature, 'label' || label_with). If the column name was evaluated as a result of the 'label' || label_with expression, then the returned feature attribute value would be 'a' for feature 1000 and 'b' for feature 1001. (Sorry for the confusing example!). Could this be done using dot notation? No, with dot notation you would need to use a proper field name (could be enclosed in double quotes though) The attribute method could co-exist for these advanced cases - like in Python there is the buildin function getattr(object, name[, default]) for the same purpose. Regards Martin ___ 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
On 23-05-14 22:33, Tim Sutton wrote: Hi all 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/ also note that we are in the middle of pulling the atom feeds from Tim's site and incorporate it in qgis.org: http://qgis.org/en/site/forusers/visualchangelog20.html There are some todo's :-) But after incorporating the image url's and being able to fetch them and do some styling, it hopefully will look as cool as Tim's site :-) Regards, Richard Duivenvoorde ___ 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 Giovanni, Could you give us the link to the issue on the hub ? I really think this is a nasty one. Thanks Michael 2014-06-19 20:33 GMT+02:00 Giovanni Manghi giovanni.man...@faunalia.pt: 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please give us more time for testing and bugfixing
Hi On Thu, Jun 19, 2014 at 1:28 PM, Andreas Neumann a.neum...@carto.net wrote: 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. I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Fwd: Re: Datum Transformation - parameters for mainland Portugal
Original Message Subject: Re: [Qgis-developer] Datum Transformation - parameters for mainland Portugal Date: Fri, 20 Jun 2014 09:35:00 +0200 From: Marco Hugentobler marco.hugentob...@sourcepole.ch To: Pedro Venâncio pedrongvenan...@yahoo.com Hi Pedro Added two ntv2 entries and updated two entries, hope it is correct now. I still feel uncomfortable to delete / update towgs84 entries in the qgis db only. I'm concerned this will get a mess over time if there are lots of updates (and the qgis.db is synchronized during install with the gdal table). If the updates are very important, I'd suggest the Portuguese user group to provide a modified copy of srs.db for people to download. However I came across something quite odd. In the Datum Transformation window, automatically arise some strange transformations (red in the imagehttp://goo.gl/iIWOuw). These transformations give huge errors, and I do not understand what they represent. QGIS reads all possible combinations to get from one datum to the other. Seems to me these towgs84 transformations are all present in the transformation table (though I don't know the geographical crs related to 30004. Is it 4258?) Regarding NTv2 grids (http://goo.gl/jDhxJB) I have another doubt here. On Linux, these files are placed in /usr/share/proj. On Windows, using the OSGeo4W installer, they are placed in ..\OSGeo4W64\share\proj. With QGIS standalone, they are placed at ..\Program Files\QGIS Valmiera\share\proj. There is no possibility of copy the grid files, automatically during the installation? This will make it easier for less experienced users. Maybe it could be done in the packaging (location is system dependent and there is not proj function call to get the right location). Budling ntv2 files with the application is a frequent request. We can discus thiss further after the release. Problems I see are: - too large install package if lots of files are present - requires to check every file license Problem 2 can easily be solved if a volountear steps up for maintaining. Regards, Marco On 18.06.2014 15:13, Pedro Venâncio wrote: Hi all, 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. I already have the SQL queries with the changes that I suggest: delete from tbl_datum_transform where source_crs_code = 4207 or source_crs_code = 4274; insert into tbl_datum_transform (epsg_nr,coord_op_code,source_crs_code, target_crs_code,coord_op_method_code,p1,p2,p3,p4,p5,p6,p7,remarks,preferred,deprecated,area_of_use_code) values (3,100014,4803,4326,9606,-283.088,-70.693,117.445,-1.157,0.059,-0.652,-4.058,'Parâmetros de Transformação de Bursa-Wolf do Datum Lisboa para PT-TM06-ETRS89 (Direção-Geral do Território, 2011)',0,0,1294); insert into tbl_datum_transform (epsg_nr,coord_op_code,source_crs_code, target_crs_code,coord_op_method_code,p1,p2,p3,remarks,preferred,deprecated,area_of_use_code) values (30001,100015,4803,4326,9603,-303.861,-60.693,103.607,'Parâmetros de Transformação de Molodensky do Datum Lisboa para PT-TM06-ETRS89 (Direção-Geral do Território, 2011)',0,0,1294); insert into tbl_datum_transform (epsg_nr,coord_op_code,source_crs_code, target_crs_code,coord_op_method_code,p1,remarks,preferred,deprecated,area_of_use_code) values (30002,100016,4803,4258,9615,'ptLX_e89.gsb','Grelhas no formato NTv2 para a Transformação de Coordenadas do Sistema HGDLx para o Sistema PT-TM06/ETRS89 (José Alberto Gonçalves - FCUP)',1,0,1294); insert into tbl_datum_transform (epsg_nr,coord_op_code,source_crs_code, target_crs_code,coord_op_method_code,p1,remarks,preferred,deprecated,area_of_use_code) values (30003,100017,4803,4258,9615,'DLX_ETRS89_geo.gsb','Grelhas no formato NTv2 para a Transformação de Coordenadas do Sistema HGDLx para o Sistema PT-TM06/ETRS89 (Direção-Geral do Território)',0,0,1294); insert into tbl_datum_transform (epsg_nr,coord_op_code,source_crs_code, target_crs_code,coord_op_method_code,p1,p2,p3,p4,p5,p6,p7,remarks,preferred,deprecated,area_of_use_code) values (30004,100018,4274,4326,9606,-230.994,102.591,25.199,0.633,-0.239,0.900,1.950,'Parâmetros de Transformação de Bursa-Wolf do Datum 73 para PT-TM06-ETRS89 (Direção-Geral do Território, 2011)',0,0,1294); insert into tbl_datum_transform (epsg_nr,coord_op_code,source_crs_code, target_crs_code,coord_op_method_code,p1,p2,p3,remarks,preferred,deprecated,area_of_use_code) values
Re: [Qgis-developer] Qgis master very slow saving project closing with several layers
I think #10379 is related (read the last updates). ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please give us more time for testing and bugfixing
On Fri, Jun 20, 2014 at 9:43 AM, Martin Dobias wonder...@gmail.com wrote: I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). +1. Stability of QGis 2.4 should be a priority of first class. There's no hurry to release it soon, since many people will go in holiday in these days :-) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please give us more time for testing and bugfixing
+1 2014-06-20 10:33 GMT+02:00 Luca Manganelli luc...@gmail.com: On Fri, Jun 20, 2014 at 9:43 AM, Martin Dobias wonder...@gmail.com wrote: I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). +1. Stability of QGis 2.4 should be a priority of first class. There's no hurry to release it soon, since many people will go in holiday in these days :-) ___ 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] Please give us more time for testing and bugfixing
On 20 June 2014 10:33, Luca Manganelli luc...@gmail.com wrote: On Fri, Jun 20, 2014 at 9:43 AM, Martin Dobias wonder...@gmail.com wrote: I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). +1. Stability of QGis 2.4 should be a priority of first class. There's no hurry to release it soon, since many people will go in holiday in these days :-) +1 -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ 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 Micheal Could you give us the link to the issue on the hub ? I really think this is a nasty one. I didn't filed one yet, I'm trying to understand at what point the issue arises when adding layers. Cheers! -- Giovanni Manghi Faunalia.pt Sistemas de Informação Geográfica Open Source Portugal Web: http://www.faunalia.pt Email Jabber: giovanni.man...@faunalia.pt PGP Key available Tel. + 351 96 7058216 -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Server: symbols missing when classified with high ASCII
Hi Paolo, Does the issue still exist ? I take a look at the map application and roads are well rendering. Regards, Le 19/06/2014 12:50, Paolo Cavallini a écrit : 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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Server: symbols missing when classified with high ASCII
Il 20/06/2014 10:51, René-Luc Dhont ha scritto: Does the issue still exist ? I take a look at the map application and roads are well rendering. Yes, the underlying issue is still there. I kind of solved for that application simply using an INT field, and applying labels to it. 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] Please give us more time for testing and bugfixing
+1 giovanni Il 20/giu/2014 10:39 Luca Delucchi lucadel...@gmail.com ha scritto: On 20 June 2014 10:33, Luca Manganelli luc...@gmail.com wrote: On Fri, Jun 20, 2014 at 9:43 AM, Martin Dobias wonder...@gmail.com wrote: I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). +1. Stability of QGis 2.4 should be a priority of first class. There's no hurry to release it soon, since many people will go in holiday in these days :-) +1 -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ 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] Server: symbols missing when classified with high ASCII
Le 20/06/2014 11:07, Paolo Cavallini a écrit : Il 20/06/2014 10:51, René-Luc Dhont ha scritto: Does the issue still exist ? I take a look at the map application and roads are well rendering. Yes, the underlying issue is still there. I kind of solved for that application simply using an INT field, and applying labels to it. All the best. It's probably due to different encoding in desktop (Latin1), server (UTF-8) and data (Latin1) Regards ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please give us more time for testing and bugfixing
+1 Best regards, Pedro Venâncio ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please give us more time for testing and bugfixing
On 20/06/2014 5:43 pm, Martin Dobias wonder...@gmail.com wrote: I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). If Martin thinks we should delay, that's a strong +1 from me. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please give us more time for testing and bugfixing
+1 On 06/20/2014 10:43 AM, Martin Dobias wrote: Hi On Thu, Jun 19, 2014 at 1:28 PM, Andreas Neumann a.neum...@carto.net wrote: 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. I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). Regards Martin -- Kari Salovaara Hanko, Finland Volunteers do not necessarily have the time; they just have the heart. ~ Elizabeth Andrew ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Server: symbols missing when classified with high ASCII
Il 20/06/2014 11:15, René-Luc Dhont ha scritto: It's probably due to different encoding in desktop (Latin1), server (UTF-8) and data (Latin1) good catch, thanks. I think we should handle this more gracefully, however. For the end user this would be very difficult to solve. 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] Server: symbols missing when classified with high ASCII
Le 20/06/2014 12:41, Paolo Cavallini a écrit : Il 20/06/2014 11:15, René-Luc Dhont ha scritto: It's probably due to different encoding in desktop (Latin1), server (UTF-8) and data (Latin1) good catch, thanks. I think we should handle this more gracefully, however. For the end user this would be very difficult to solve. All the best. It's a windows issue ;-) but qgis provides the ability to specify data encoding. Regards, ___ 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
On Thu, Jun 19, 2014 at 5:29 PM, Jürgen E. j...@norbit.de wrote: 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. There was an issue with the credentials - now fixed: http://hub.qgis.org/issues/10655 Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Re: Datum Transformation - parameters for mainland Portugal
Hi Marco. Added two ntv2 entries and updated two entries, hope it is correct now. Great Marco, it is working now with ntv2 grids. Since there is now a duplication, I think you can delete the grids entry with coord_op_code 14 and 17. I still feel uncomfortable to delete / update towgs84 entries in the qgis db only. I'm concerned this will get a mess over time if there are lots of updates (and the qgis.db is synchronized during install with the gdal table). If the updates are very important, I'd suggest the Portuguese user group to provide a modified copy of srs.db for people to download. Yes, this is a possibility. However I came across something quite odd. In the Datum Transformation window, automatically arise some strange transformations (red in the image http://goo.gl/iIWOuw). These transformations give huge errors, and I do not understand what they represent. QGIS reads all possible combinations to get from one datum to the other. Seems to me these towgs84 transformations are all present in the transformation table No, those parameters that have +towgs84=565.04(...) are not associated with any portuguese transformation. These parameters belong to epsg_nr 1571. The only point of contact between this entry and the portuguese entries, is that both uses 4258 (Geographic CRS ETRS89). epsg_nr 1571 uses it as source_crs_code, and some transformations for Portugal (ntv2 grids transformations) uses it as target_crs_code. (though I don't know . Is it 4258?) The biggest mess in my mind is precisely this. Is that, even the possible incorrect match between source and target codes does not make sense, because the geographical crs related to 30004 is 4326 (+towgs84). We only use 4258 for ntv2 grids. So, these options in red in the image should not show up. I think this problem only happens with the portuguese transformations, right Giovanni? Maybe it could be done in the packaging (location is system dependent and there is not proj function call to get the right location). Budling ntv2 files with the application is a frequent request. We can discus thiss further after the release. Problems I see are: - too large install package if lots of files are present - requires to check every file license Problem 2 can easily be solved if a volountear steps up for maintaining. I can check the portuguese grids license. Thank you very much Marco! Best regards, Pedro ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Re: Datum Transformation - parameters for mainland Portugal
Since there is now a duplication, I think you can delete the grids entry with coord_op_code 14 and 17. With which other entries are they duplicated? Seems to me there are no two entries with same source_srs / dest_src / gsb file ? No, those parameters that have +towgs84=565.04(...) are not associated with any portuguese transformation. These parameters belong to epsg_nr 1571. The only point of contact between this entry and the portuguese entries, is that both uses 4258 (Geographic CRS ETRS89). epsg_nr 1571 uses it as source_crs_code, and some transformations for Portugal (ntv2 grids transformations) uses it as target_crs_code. Not sure what you mean. transformation epsg:1571 says there is a transformation between 4258 and 4326 with +towgs84=565.04(...). So this transformation can be used for all projections based on 4258 to transform to wgs84 ellipsoid (and a second transformation is listed to get from wgs84 ellipsoid to the destination datum). Regards, Marco On 20.06.2014 13:13, Pedro Venâncio wrote: Hi Marco. Added two ntv2 entries and updated two entries, hope it is correct now. Great Marco, it is working now with ntv2 grids. Since there is now a duplication, I think you can delete the grids entry with coord_op_code 14 and 17. I still feel uncomfortable to delete / update towgs84 entries in the qgis db only. I'm concerned this will get a mess over time if there are lots of updates (and the qgis.db is synchronized during install with the gdal table). If the updates are very important, I'd suggest the Portuguese user group to provide a modified copy of srs.db for people to download. Yes, this is a possibility. However I came across something quite odd. In the Datum Transformation window, automatically arise some strange transformations (red in the image http://goo.gl/iIWOuw). These transformations give huge errors, and I do not understand what they represent. QGIS reads all possible combinations to get from one datum to the other. Seems to me these towgs84 transformations are all present in the transformation table No, those parameters that have +towgs84=565.04(...) are not associated with any portuguese transformation. These parameters belong to epsg_nr 1571. The only point of contact between this entry and the portuguese entries, is that both uses 4258 (Geographic CRS ETRS89). epsg_nr 1571 uses it as source_crs_code, and some transformations for Portugal (ntv2 grids transformations) uses it as target_crs_code. (though I don't know . Is it 4258?) The biggest mess in my mind is precisely this. Is that, even the possible incorrect match between source and target codes does not make sense, because the geographical crs related to 30004 is 4326 (+towgs84). We only use 4258 for ntv2 grids. So, these options in red in the image should not show up. I think this problem only happens with the portuguese transformations, right Giovanni? Maybe it could be done in the packaging (location is system dependent and there is not proj function call to get the right location). Budling ntv2 files with the application is a frequent request. We can discus thiss further after the release. Problems I see are: - too large install package if lots of files are present - requires to check every file license Problem 2 can easily be solved if a volountear steps up for maintaining. I can check the portuguese grids license. Thank you very much Marco! Best regards, Pedro ___ 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
Re: [Qgis-developer] Qgis master very slow saving project closing with several layers
Hi On Fri, Jun 20, 2014 at 3:49 PM, Giovanni Manghi giovanni.man...@faunalia.pt wrote: Hi Micheal Could you give us the link to the issue on the hub ? I really think this is a nasty one. I didn't filed one yet, I'm trying to understand at what point the issue arises when adding layers. I have tried to create a project with ~120 layers from postgis and both saving project and closing QGIS are quick. Tested on linux/64bit. Maybe there is something specific to your project? Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Re: Datum Transformation - parameters for mainland Portugal
Hi again, - Mensagem original - DE: Pedro Venâncio However I came across something quite odd. In the Datum Transformation window, automatically arise some strange transformations (red in the image http://goo.gl/iIWOuw). These transformations give huge errors, and I do not understand what they represent. QGIS reads all possible combinations to get from one datum to the other. Seems to me these towgs84 transformations are all present in the transformation table No, those parameters that have +towgs84=565.04(...) are not associated with any portuguese transformation. These parameters belong to epsg_nr 1571. The only point of contact between this entry and the portuguese entries, is that both uses 4258 (Geographic CRS ETRS89). epsg_nr 1571 uses it as source_crs_code, and some transformations for Portugal (ntv2 grids transformations) uses it as target_crs_code. (though I don't know . Is it 4258?) The biggest mess in my mind is precisely this. Is that, even the possible incorrect match between source and target codes does not make sense, because the geographical crs related to 30004 is 4326 (+towgs84). We only use 4258 for ntv2 grids. So, these options in red in the image should not show up. I think this problem only happens with the portuguese transformations, right Giovanni? I can now confirm that it is a conflict with epsg_nr 1571, because deleting this record delete from tbl_datum_transform where epsg_nr = 1571; the problem disappears. Best regards, Pedro ___ 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
I have a project with ~100 layers and did not noticed such behavior. Both on Ubuntu and Windows. Cheers, Denis On 20.06.2014 13:45, Martin Dobias wrote: Hi On Fri, Jun 20, 2014 at 3:49 PM, Giovanni Manghi giovanni.man...@faunalia.pt wrote: Hi Micheal Could you give us the link to the issue on the hub ? I really think this is a nasty one. I didn't filed one yet, I'm trying to understand at what point the issue arises when adding layers. I have tried to create a project with ~120 layers from postgis and both saving project and closing QGIS are quick. Tested on linux/64bit. Maybe there is something specific to your project? Martin ___ 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] Please give us more time for testing and bugfixing
Hi Martin, On Fri, 20. Jun 2014 at 14:43:22 +0700, Martin Dobias wrote: I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). So apparently the testing phase works out better this time. Thanks to all the testers. Please keep on testing for the coming week as I going to postpone until next friday. Maybe we should extent the testing phase to six weeks and use only 10 weeks for development for 2.6 (or 10+5 or 9+6 weeks, as we're going to start one week late). 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] Please give us more time for testing and bugfixing
Thanks Jurgen. On Fri, Jun 20, 2014 at 9:55 PM, Jürgen E. j...@norbit.de wrote: Hi Martin, On Fri, 20. Jun 2014 at 14:43:22 +0700, Martin Dobias wrote: I agree with Andreas. Can we postpone the release for a few days? There is still quite steady flow of new bug reports worth addressing. I would suggest max. 7 days (without affecting the schedule of the next release). So apparently the testing phase works out better this time. Thanks to all the testers. Please keep on testing for the coming week as I going to postpone until next friday. Maybe we should extent the testing phase to six weeks and use only 10 weeks for development for 2.6 (or 10+5 or 9+6 weeks, as we're going to start one week late). 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] Qgis master very slow saving project closing with several layers
Hi, Thans for you help, I will try to setup the problematic project and publish it somewhere whenever I find the time. Michael 2014-06-20 13:50 GMT+02:00 Denis Rouzaud denis.rouz...@gmail.com: I have a project with ~100 layers and did not noticed such behavior. Both on Ubuntu and Windows. Cheers, Denis On 20.06.2014 13:45, Martin Dobias wrote: Hi On Fri, Jun 20, 2014 at 3:49 PM, Giovanni Manghi giovanni.man...@faunalia.pt wrote: Hi Micheal Could you give us the link to the issue on the hub ? I really think this is a nasty one. I didn't filed one yet, I'm trying to understand at what point the issue arises when adding layers. I have tried to create a project with ~120 layers from postgis and both saving project and closing QGIS are quick. Tested on linux/64bit. Maybe there is something specific to your project? Martin ___ 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: Re: Datum Transformation - parameters for mainland Portugal
Hi Marco, Since there is now a duplication, I think you can delete the grids entry with coord_op_code 14 and 17. With which other entries are they duplicated? Seems to me there are no two entries with same source_srs / dest_src / gsb file ? coord_op_code 14 uses the same ntv2 grid of 100014 and coord_op_code 17 uses the same ntv2 grid of 100015. The difference is in source_crs_code. The older ones uses 4207, that does not work for Lisbon Datum, because the code of the geographical system used by EPSG:20790 / EPSG:20791 [0] is not EPSG:4207 [1], but EPSG:4803 [2]. So, I think you can delete 14 and 17. [0] http://epsg.io/20790 / http://epsg.io/20791 [1] http://epsg.io/4207 [2] http://epsg.io/4803 No, those parameters that have +towgs84=565.04(...) are not associated with any portuguese transformation. These parameters belong to epsg_nr 1571. The only point of contact between this entry and the portuguese entries, is that both uses 4258 (Geographic CRS ETRS89). epsg_nr 1571 uses it as source_crs_code, and some transformations for Portugal (ntv2 grids transformations) uses it as target_crs_code. Not sure what you mean. transformation epsg:1571 says there is a transformation between 4258 and 4326 with +towgs84=565.04(...). So this transformation can be used for all projections based on 4258 to transform to wgs84 ellipsoid (and a second transformation is listed to get from wgs84 ellipsoid to the destination datum). Yes, but that transformation shows up with the following source - destination: 4803 - 4326; 4274 - 4326; witch does not make sense to me. Deleting epsg_nr 1571, the problem disappears. What do you think might be the cause for this behavior? Thanks Marco! Best regards, Pedro ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Re: Datum Transformation - parameters for mainland Portugal
Am 20.06.2014 13:41, schrieb Marco Hugentobler: No, those parameters that have +towgs84=565.04(...) are not associated with any portuguese transformation. These parameters belong to epsg_nr 1571. The only point of contact between this entry and the portuguese entries, is that both uses 4258 (Geographic CRS ETRS89). epsg_nr 1571 uses it as source_crs_code, and some transformations for Portugal (ntv2 grids transformations) uses it as target_crs_code. tfm 1571 is a bug in the EPSG database. It should be Amersfoort to ETRS89 (1), but somehow the source CRS got wrong. It was deprecated in 2001, and replaced by tfm 1751 (4289 to 4258) under the same name. For some reasons, EPSG still keeps it in its database, marked deprecated. The online version of the database does not show it anymore, so I think QGIS can drop transformations marked deprecated as well. Usually, ETRS89 and WGS84 are concidered identical. There is another tfm 1149 from 4258 to 4326 with all parameters to zero. The transformation table inside QGIS only has those tfm from the EPSG database where the target CRS is 4326 (we want towgs84, right?) So I suggest to set target CRS for all new portuguese CRS to 4326 as well. For the other bug about Lisbon datum with prime meridian Greenwich vs Lisbon, I have to investigate a bit further. Maybe the low accuracy tfm now used applies to both within the range of accurancy. @pedro: I really would encourage you to get this into the EPSG database as soon as possible. Greetings, André Joost ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] diagrams bugs?
Hi all, I have a couple of doubts about diagrams: * their scale dependent visibility does not seems to work * while there is a font button, this seems to only work with text diagrams but not for pie and histogram ones anyone can confirm? cheers -- G -- ___ 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
I can confirm it's not working under windows at least installing from OSGEO4W 32 bit -- View this message in context: http://osgeo-org.1560.x6.nabble.com/edit-widgets-do-not-work-in-current-master-tp5146847p5147085.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
