Re: [Qgis-developer] please help me :(
Hi Could you please use a descriptive subject line for your messages (e.g. 'Problem compiling QGIS 1.7 on Ubuntu 12.04') instead of 'Please help me'. On Fri, Jan 10, 2014 at 2:08 AM, otmane yazidi alaoui yazidiotm...@gmail.com wrote: i have this problem [ 0%] Built target svnversion [ 1%] Built target t2tdoc [ 17%] Built target qgis_core [ 24%] Built target ui [ 34%] Built target qgis_gui [ 37%] Built target qgis_analysis [ 63%] Built target qgis [ 66%] Built target translations [ 66%] Built target compile_python_files [ 67%] Built target python_module_qgis_analysis [ 67%] Building CXX object python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart0.cpp.o [ 67%] Building CXX object python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart1.cpp.o /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp: In function ‘PyObject* meth_QgsSymbolV2_renderHints(PyObject*, PyObject*)’: /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp:6719:42: error: passing ‘const QgsSymbolV2’ as ‘this’ argument of ‘int QgsSymbolV2::renderHints()’ discards qualifiers [-fpermissive] /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp: In function ‘PyObject* meth_QgsSymbolV2RenderContext_setSelected(PyObject*, PyObject*)’: /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp:7121:35: error: passing ‘const QgsSymbolV2RenderContext’ as ‘this’ argument of ‘void QgsSymbolV2RenderContext::setSelected(bool)’ discards qualifiers [-fpermissive] make[2]: *** [python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart1.cpp.o] Error 1 make[1]: *** [python/CMakeFiles/python_module_qgis_core.dir/all] Error 2 make: *** [all] Error 2 00:03:40: Le processus /usr/bin/make s'est terminé avec le code 2. Erreur à la compilation du projet qgis1.7.0 (cible : Desktop) Lors de l'exécution de l'étape Make --- Any reason why you are trying to build such an old version of QGIS? Regards Tim -- YAZIDI ALAOUI OTMANE Ingénieur d'état en Géomatique Tel:+212652538743 @ :yazidiotm...@gmail.com http://www.doyoubuzz.com/otmane-yazidi-alaoui // ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Ortho line at specified line distance
Is your code a plugin? Implementing the ortho line is quite easy (as you can see from the code I pointed you to). giovanni 2014/1/10 Ing. Pierluigi De Rosa pierluigi.der...@gfosservices.it Unfortunetely CAD tool is not worth for me. I need to generate ortho segments to line at specified distance into a bigger code. Maybe I need to generate more than thousand segment every time and I cannot to that by hands. Any ideas? thanks Il giorno gio, 09/01/2014 alle 18.34 +0100, G. Allegri ha scritto: Here a short video: http://youtu.be/e0tscGQpywQ 2014/1/9 G. Allegri gioha...@gmail.com Hi Pierluigi, probably CAD Tools plugin is the right tool to do it http://plugins.qgis.org/plugins/cadtools/ https://github.com/geopython/CadTools/blob/master/tools/orthogonaldigitizer.py giovanni 2014/1/9 Ing. Pierluigi De Rosa pierluigi.der...@gfosservices.it Dear all I'm looking for the best way to produce an ortho line to vector line at specified along distance. In past I did the same thing by grass using v.segment and connecting the ortho points nodes. what you suggest as best way to do that? thanks in advance -- Ing. Pierluigi De Rosa (PhD) Studio Associato GFOSSERVICES Via Tilli 58 - 06127 Perugia (PG) tel: 075 7825101 / fax: 075 7823038 cel: 3497558268 web: www.gfosservices.it skype: pierluigi.derosa ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- -- *Ing. Pierluigi De Rosa (PhD)* *Studio Associato GFOSSERVICES* *Via Tilli 58 - 06127 Perugia (PG)* *tel: 075 7825101 / fax: 075 7823038* *cel: 3497558268* *web**: www.gfosservices.it http://www.gfosservices.com/index.php?option=com_contentview=articleid=21Itemid=21lang=it* *skype: pierluigi.derosa * -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus Banner_sito.jpg___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Add areas very slow
Hi all. Talking about speedup of tables: I am noticing that Export/Add geometry column is *extremely* slow for large polygonal layers: any hope to speed it up? All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: 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] [Bug] #8298 - CRS change with recently used CRS makes no effect in the first choice
Hi all, I made a pull request to fixed the issue #8298 http://hub.qgis.org/issues/8298 I implemented the solution to set the default selected CRS in projection selector to the last recent. You can review my code here : https://github.com/qgis/QGIS/pull/1063 Regards, René-Luc D'Hont 3Liz ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Add areas very slow
Il 10/01/2014 10:25, Paolo Cavallini ha scritto: Hi all. Talking about speedup of tables: I am noticing that Export/Add geometry column is *extremely* slow for large polygonal layers: any hope to speed it up? 30k geometries, 45 minutes (!) -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: 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 help me :(
also, why would you build qgis 1.7 which is an old release? On Thu, Jan 9, 2014 at 10:08 PM, otmane yazidi alaoui yazidiotm...@gmail.com wrote: i have this problem [ 0%] Built target svnversion [ 1%] Built target t2tdoc [ 17%] Built target qgis_core [ 24%] Built target ui [ 34%] Built target qgis_gui [ 37%] Built target qgis_analysis [ 63%] Built target qgis [ 66%] Built target translations [ 66%] Built target compile_python_files [ 67%] Built target python_module_qgis_analysis [ 67%] Building CXX object python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart0.cpp.o [ 67%] Building CXX object python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart1.cpp.o /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp: In function ‘PyObject* meth_QgsSymbolV2_renderHints(PyObject*, PyObject*)’: /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp:6719:42: error: passing ‘const QgsSymbolV2’ as ‘this’ argument of ‘int QgsSymbolV2::renderHints()’ discards qualifiers [-fpermissive] /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp: In function ‘PyObject* meth_QgsSymbolV2RenderContext_setSelected(PyObject*, PyObject*)’: /home/alaoui/dev/cpp/qtcreator-build-qgis/python/core/sipcorepart1.cpp:7121:35: error: passing ‘const QgsSymbolV2RenderContext’ as ‘this’ argument of ‘void QgsSymbolV2RenderContext::setSelected(bool)’ discards qualifiers [-fpermissive] make[2]: *** [python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart1.cpp.o] Error 1 make[1]: *** [python/CMakeFiles/python_module_qgis_core.dir/all] Error 2 make: *** [all] Error 2 00:03:40: Le processus /usr/bin/make s'est terminé avec le code 2. Erreur à la compilation du projet qgis1.7.0 (cible : Desktop) Lors de l'exécution de l'étape Make --- -- YAZIDI ALAOUI OTMANE Ingénieur d'état en Géomatique Tel:+212652538743 @ :yazidiotm...@gmail.com http://www.doyoubuzz.com/otmane-yazidi-alaoui // ___ 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] Approximation and geoprocessing
Hi all. I got into an interesting problem, before opening a few tickets I'd like to discuss a line of action. 1. Some sw (namely geomedia) produces shapefiles with very slight differences (same layer, modified and exported several times); I suppose this is due to truncation/approximation in coordinate precision. 2. As a result, the diff between these layers produces a number of virtually 0 width polygons, and some topological errors. 3. This in turn leads to 2 problems: 3.1. subsequent analyses fail because of the errors, and the user has no clue about the reasons 3.2. The microareas are tricky and time consuming to remove (if they are isolated, a possible solution is to select and remove those smaller than an arbitrary threshold, but if they are linked to some real polygons, this will not work). I would therefore suggest a few improvements over the toolchain, i.e.: * add a parameter in analyses, to either snap original data within a threshold before running the analysis, or to clean up the results afterwards * check warn the user of topo errors in source layers, and of possible wrong results; maybe this should be optional, as this will slow down the analysis, and may be useless after first cleanup. Sample data available for those interested. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: 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] Approximation and geoprocessing
Hi, I don't have a solution for the problem. But I can confirm that the whole analysis chain is a bit problematic with all these precision issues. As an example if you test intersections of buildings against parcels (2 different layers) and the building touches the parcel borders you may get very tiny intersects with parcels (only a few square cms) and you wouldn't want to include these intersections in your analysis. So it would be cool if for geometry tests there could be a notion of threshold values. If the area of an intersected polygon is below this value it wouldn't be taken into account during the analysis. These issues are really kind of show-stoppers and almost always require intermediate steps to sort out these edge cases. It would be very handy if the tools could handle this precision/uncertainty problems without having to do a lot of intermediate steps. Andreas Am 10.01.2014 15:01, schrieb Paolo Cavallini: Hi all. I got into an interesting problem, before opening a few tickets I'd like to discuss a line of action. 1. Some sw (namely geomedia) produces shapefiles with very slight differences (same layer, modified and exported several times); I suppose this is due to truncation/approximation in coordinate precision. 2. As a result, the diff between these layers produces a number of virtually 0 width polygons, and some topological errors. 3. This in turn leads to 2 problems: 3.1. subsequent analyses fail because of the errors, and the user has no clue about the reasons 3.2. The microareas are tricky and time consuming to remove (if they are isolated, a possible solution is to select and remove those smaller than an arbitrary threshold, but if they are linked to some real polygons, this will not work). I would therefore suggest a few improvements over the toolchain, i.e.: * add a parameter in analyses, to either snap original data within a threshold before running the analysis, or to clean up the results afterwards * check warn the user of topo errors in source layers, and of possible wrong results; maybe this should be optional, as this will slow down the analysis, and may be useless after first cleanup. Sample data available for those interested. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Multi-threaded Rendering
Hi Martin, I noticed that QGIS crashes (with the multi-threaded rendering) when you turn editing mode on for a layer if this layer exists several times in the legend (i.e. the same layer is loaded several times with different styles or whatever). I observed this at least for postgres. Cheers, Denis On 07. 01. 14 22:23, Andreas Neumann wrote: Hi Martin, I tested it and can confirm that the PostgreSQL pooling works fine and fast now. I see more than 4 Postgis connections though. But maybe these connections are from other plugins using Postgis connections as well. Good to see progress! Thanks, Andreas Am 06.01.2014 13:31, schrieb Martin Dobias: Hi Andreas On Fri, Dec 13, 2013 at 8:31 PM, Andreas Neumann a.neum...@carto.net wrote: Hi Martin, I guess I am also running into the PostgreSQL issue. In general my PostgreSQL based projects with many layers freeze after a very short time, while the SpatiaLite based projects work very nicely. Too many PostgreSQL connections? Can we limit the PostgreSQL connections or can you better re-use existing connections? A quick followup - today I have pushed some changes that introduce a connection pool for PostgreSQL. This should remove the problem with too many connections. It limits the maximum number of concurrent connections from one QGIS instance to four. Also, when the connections are not used for some time, they get closed to save resources (right now it is after one minute). Please test and let me know if things work better now. I will probably also look at pooling of SpatiaLite connections - right now the queries within SQLite are serialized, so within one SpatiaLite database you will not see any performance gain with parallel rendering. Regards 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] Approximation and geoprocessing
Hi, I provided eliminate sliver polygons in the processing framework some months ago (thanks for your help, Victor!). Eliminate is based on a certain field. You would have to calculate the area (or area/perimeter) for all polygons and use that as a threshold in Eliminate sliver polygons. No idea how to calculate that, though. How does the Advanced python field caluclator work? Bernhard Am 10.01.2014 15:18, schrieb Andreas Neumann: Hi, I don't have a solution for the problem. But I can confirm that the whole analysis chain is a bit problematic with all these precision issues. As an example if you test intersections of buildings against parcels (2 different layers) and the building touches the parcel borders you may get very tiny intersects with parcels (only a few square cms) and you wouldn't want to include these intersections in your analysis. So it would be cool if for geometry tests there could be a notion of threshold values. If the area of an intersected polygon is below this value it wouldn't be taken into account during the analysis. These issues are really kind of show-stoppers and almost always require intermediate steps to sort out these edge cases. It would be very handy if the tools could handle this precision/uncertainty problems without having to do a lot of intermediate steps. Andreas Am 10.01.2014 15:01, schrieb Paolo Cavallini: Hi all. I got into an interesting problem, before opening a few tickets I'd like to discuss a line of action. 1. Some sw (namely geomedia) produces shapefiles with very slight differences (same layer, modified and exported several times); I suppose this is due to truncation/approximation in coordinate precision. 2. As a result, the diff between these layers produces a number of virtually 0 width polygons, and some topological errors. 3. This in turn leads to 2 problems: 3.1. subsequent analyses fail because of the errors, and the user has no clue about the reasons 3.2. The microareas are tricky and time consuming to remove (if they are isolated, a possible solution is to select and remove those smaller than an arbitrary threshold, but if they are linked to some real polygons, this will not work). I would therefore suggest a few improvements over the toolchain, i.e.: * add a parameter in analyses, to either snap original data within a threshold before running the analysis, or to clean up the results afterwards * check warn the user of topo errors in source layers, and of possible wrong results; maybe this should be optional, as this will slow down the analysis, and may be useless after first cleanup. Sample data available for those interested. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer __ Information from ESET Mail Security, version of virus signature database 9274 (20140110) __ The message was checked by ESET Mail Security. http://www.eset.com __ Information from ESET Mail Security, version of virus signature database 9274 (20140110) __ The message was checked by ESET Mail Security. http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Approximation and geoprocessing
Hi Bernhard, there is a good article about Advanced Field Calculator [0], but only in Russian (there is a Google Translate in the right sidebar). Hope this helps a bit [0] http://gis-lab.info/qa/fieldpyculator.html 2014/1/10 Bernhard Ströbl bernhard.stro...@jena.de: Hi, I provided eliminate sliver polygons in the processing framework some months ago (thanks for your help, Victor!). Eliminate is based on a certain field. You would have to calculate the area (or area/perimeter) for all polygons and use that as a threshold in Eliminate sliver polygons. No idea how to calculate that, though. How does the Advanced python field caluclator work? Bernhard Am 10.01.2014 15:18, schrieb Andreas Neumann: Hi, I don't have a solution for the problem. But I can confirm that the whole analysis chain is a bit problematic with all these precision issues. As an example if you test intersections of buildings against parcels (2 different layers) and the building touches the parcel borders you may get very tiny intersects with parcels (only a few square cms) and you wouldn't want to include these intersections in your analysis. So it would be cool if for geometry tests there could be a notion of threshold values. If the area of an intersected polygon is below this value it wouldn't be taken into account during the analysis. These issues are really kind of show-stoppers and almost always require intermediate steps to sort out these edge cases. It would be very handy if the tools could handle this precision/uncertainty problems without having to do a lot of intermediate steps. Andreas Am 10.01.2014 15:01, schrieb Paolo Cavallini: Hi all. I got into an interesting problem, before opening a few tickets I'd like to discuss a line of action. 1. Some sw (namely geomedia) produces shapefiles with very slight differences (same layer, modified and exported several times); I suppose this is due to truncation/approximation in coordinate precision. 2. As a result, the diff between these layers produces a number of virtually 0 width polygons, and some topological errors. 3. This in turn leads to 2 problems: 3.1. subsequent analyses fail because of the errors, and the user has no clue about the reasons 3.2. The microareas are tricky and time consuming to remove (if they are isolated, a possible solution is to select and remove those smaller than an arbitrary threshold, but if they are linked to some real polygons, this will not work). I would therefore suggest a few improvements over the toolchain, i.e.: * add a parameter in analyses, to either snap original data within a threshold before running the analysis, or to clean up the results afterwards * check warn the user of topo errors in source layers, and of possible wrong results; maybe this should be optional, as this will slow down the analysis, and may be useless after first cleanup. Sample data available for those interested. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer __ Information from ESET Mail Security, version of virus signature database 9274 (20140110) __ The message was checked by ESET Mail Security. http://www.eset.com __ Information from ESET Mail Security, version of virus signature database 9274 (20140110) __ The message was checked by ESET Mail Security. http://www.eset.com ___ 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
Re: [Qgis-developer] Approximation and geoprocessing
Hi all, If I understood correctly, someone added very recently the support of QgsExpressions in the processing toolbox. This could help I suppose ? Michael 2014/1/10 Alexander Bruy alexander.b...@gmail.com Hi Bernhard, there is a good article about Advanced Field Calculator [0], but only in Russian (there is a Google Translate in the right sidebar). Hope this helps a bit [0] http://gis-lab.info/qa/fieldpyculator.html 2014/1/10 Bernhard Ströbl bernhard.stro...@jena.de: Hi, I provided eliminate sliver polygons in the processing framework some months ago (thanks for your help, Victor!). Eliminate is based on a certain field. You would have to calculate the area (or area/perimeter) for all polygons and use that as a threshold in Eliminate sliver polygons. No idea how to calculate that, though. How does the Advanced python field caluclator work? Bernhard Am 10.01.2014 15:18, schrieb Andreas Neumann: Hi, I don't have a solution for the problem. But I can confirm that the whole analysis chain is a bit problematic with all these precision issues. As an example if you test intersections of buildings against parcels (2 different layers) and the building touches the parcel borders you may get very tiny intersects with parcels (only a few square cms) and you wouldn't want to include these intersections in your analysis. So it would be cool if for geometry tests there could be a notion of threshold values. If the area of an intersected polygon is below this value it wouldn't be taken into account during the analysis. These issues are really kind of show-stoppers and almost always require intermediate steps to sort out these edge cases. It would be very handy if the tools could handle this precision/uncertainty problems without having to do a lot of intermediate steps. Andreas Am 10.01.2014 15:01, schrieb Paolo Cavallini: Hi all. I got into an interesting problem, before opening a few tickets I'd like to discuss a line of action. 1. Some sw (namely geomedia) produces shapefiles with very slight differences (same layer, modified and exported several times); I suppose this is due to truncation/approximation in coordinate precision. 2. As a result, the diff between these layers produces a number of virtually 0 width polygons, and some topological errors. 3. This in turn leads to 2 problems: 3.1. subsequent analyses fail because of the errors, and the user has no clue about the reasons 3.2. The microareas are tricky and time consuming to remove (if they are isolated, a possible solution is to select and remove those smaller than an arbitrary threshold, but if they are linked to some real polygons, this will not work). I would therefore suggest a few improvements over the toolchain, i.e.: * add a parameter in analyses, to either snap original data within a threshold before running the analysis, or to clean up the results afterwards * check warn the user of topo errors in source layers, and of possible wrong results; maybe this should be optional, as this will slow down the analysis, and may be useless after first cleanup. Sample data available for those interested. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer __ Information from ESET Mail Security, version of virus signature database 9274 (20140110) __ The message was checked by ESET Mail Security. http://www.eset.com __ Information from ESET Mail Security, version of virus signature database 9274 (20140110) __ The message was checked by ESET Mail Security. http://www.eset.com ___ 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Font for tests
Hi, I was looking at some of the tests, and realized, that the composerhtml test fails because of some slight font differences. Firebug tells me that the following fonts are used (defined by bootstrap.css): Helvetica Neue,Helvetica,Arial,sans-serif I don't have any of these Helvetica fonts installed and I am not sure about their licensing, but it seems that no package includes them just like that. Does anybody know a font which is just available out of the box on all plattforms to get around such issues? Arial maybe? This option seems much better to me than fixing things with a tolerance param. Have a nice weekend, Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Font for tests
Hi Matthias, On Fri, Jan 10, 2014 at 10:29 AM, Matthias Kuhn matthias.k...@gmx.chwrote: Hi, I was looking at some of the tests, and realized, that the composerhtml test fails because of some slight font differences. Firebug tells me that the following fonts are used (defined by bootstrap.css): Helvetica Neue,Helvetica,Arial,sans-serif I don't have any of these Helvetica fonts installed and I am not sure about their licensing, but it seems that no package includes them just like that. Does anybody know a font which is just available out of the box on all plattforms to get around such issues? Arial maybe? This option seems much better to me than fixing things with a tolerance param. About a year ago, I added a custom built, very lightweight font, FreeSansQGIS, just for tests [0], based off of FreeSans. Usage info is explained in its README [1], notably that the font not be installed on the system. It is intended to be loaded on-the-fly via Qt's font-handling routines, and is already available in the utilities.py module via loadTestFont() [2]. I have also added it to the startup functionality of the QGIS app and server [3], which loads the font if the testdata directory is available, e.g. when running ctest from build directory. Feel free to fix anything wrong with my implementation. Regardless, I have still seen differences in how the same font is drawn by the different systems' window server, so some amount of tolerance (or a set of anomalies) is probably always going to be needed. Though, hopefully that's not a moving target because of the standardized test font. Recently I came across another test font used by the MapServer project, which we might also consider using because it also has bold face [4]. Not sure how it compares to the 'normal' Vera font. However, I think if it is used it should still be renamed to FreeSansQGIS to avoid conflict with installed fonts, and make it easily searchable in the QFontDatabase. [0] https://github.com/qgis/QGIS/tree/master/tests/testdata/font [1] https://github.com/qgis/QGIS/blob/master/tests/testdata/font/FreeSansQGIS-README.txt [2] https://github.com/qgis/QGIS/blob/master/tests/src/python/utilities.py#L218-L228 [3] https://github.com/qgis/QGIS/blob/master/src/app/main.cpp#L739-L746 https://github.com/qgis/QGIS/blob/master/src/mapserver/qgis_map_serv.cpp#L244-L253 [4] https://github.com/mapserver/mapserver/tree/master/tests/vera Regards, Larry Have a nice weekend, Matthias ___ 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] Font for tests
Hi Matthias, On Fri, Jan 10, 2014 at 10:29 AM, Matthias Kuhn matthias.k...@gmx.chwrote: Hi, I was looking at some of the tests, and realized, that the composerhtml test fails because of some slight font differences. We might also consider creating a Web font version of FreeSansQGIS.ttf specifically to load into HTML tests. Firebug tells me that the following fonts are used (defined by bootstrap.css): Helvetica Neue,Helvetica,Arial,sans-serif I don't have any of these Helvetica fonts installed and I am not sure about their licensing, but it seems that no package includes them just like that. Does anybody know a font which is just available out of the box on all plattforms to get around such issues? Arial maybe? This option seems much better to me than fixing things with a tolerance param. Have a nice weekend, Matthias ___ 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] Font for tests
The arial is not available on linux machines. But the liberation Fonts are an Arial with an opensource licensing. http://en.wikipedia.org/wiki/Liberation_fonts We use they usually with MapServer and qgis-server. If interested, follow this link for the download. https://www.redhat.com/promo/fonts/ Regards, A. On 10/01/2014 19:45, Larry Shaffer wrote: Hi Matthias, On Fri, Jan 10, 2014 at 10:29 AM, Matthias Kuhn matthias.k...@gmx.ch mailto:matthias.k...@gmx.ch wrote: Hi, I was looking at some of the tests, and realized, that the composerhtml test fails because of some slight font differences. Firebug tells me that the following fonts are used (defined by bootstrap.css): Helvetica Neue,Helvetica,Arial,sans-serif I don't have any of these Helvetica fonts installed and I am not sure about their licensing, but it seems that no package includes them just like that. Does anybody know a font which is just available out of the box on all plattforms to get around such issues? Arial maybe? This option seems much better to me than fixing things with a tolerance param. About a year ago, I added a custom built, very lightweight font, FreeSansQGIS, just for tests [0], based off of FreeSans. Usage info is explained in its README [1], notably that the font not be installed on the system. It is intended to be loaded on-the-fly via Qt's font-handling routines, and is already available in the utilities.py module via loadTestFont() [2]. I have also added it to the startup functionality of the QGIS app and server [3], which loads the font if the testdata directory is available, e.g. when running ctest from build directory. Feel free to fix anything wrong with my implementation. Regardless, I have still seen differences in how the same font is drawn by the different systems' window server, so some amount of tolerance (or a set of anomalies) is probably always going to be needed. Though, hopefully that's not a moving target because of the standardized test font. Recently I came across another test font used by the MapServer project, which we might also consider using because it also has bold face [4]. Not sure how it compares to the 'normal' Vera font. However, I think if it is used it should still be renamed to FreeSansQGIS to avoid conflict with installed fonts, and make it easily searchable in the QFontDatabase. [0] https://github.com/qgis/QGIS/tree/master/tests/testdata/font [1] https://github.com/qgis/QGIS/blob/master/tests/testdata/font/FreeSansQGIS-README.txt [2] https://github.com/qgis/QGIS/blob/master/tests/src/python/utilities.py#L218-L228 [3] https://github.com/qgis/QGIS/blob/master/src/app/main.cpp#L739-L746 https://github.com/qgis/QGIS/blob/master/src/mapserver/qgis_map_serv.cpp#L244-L253 [4] https://github.com/mapserver/mapserver/tree/master/tests/vera Regards, Larry Have a nice weekend, Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto: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] QGIS Multi-threaded Rendering
Hi Denis I have just tested with one postgis layer being loaded twice. Turning editing mode on/off worked smoothly as expected. Could you please try to track down in what cases it crashes? For example: - does it happen only with postgis layers? - must be the layer loaded multiple times in order to crash? - what if rendering is not turned on when turning on editing mode? Also, a backtrace would be useful... Thanks Martin On Fri, Jan 10, 2014 at 9:34 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi Martin, I noticed that QGIS crashes (with the multi-threaded rendering) when you turn editing mode on for a layer if this layer exists several times in the legend (i.e. the same layer is loaded several times with different styles or whatever). I observed this at least for postgres. Cheers, Denis On 07. 01. 14 22:23, Andreas Neumann wrote: Hi Martin, I tested it and can confirm that the PostgreSQL pooling works fine and fast now. I see more than 4 Postgis connections though. But maybe these connections are from other plugins using Postgis connections as well. Good to see progress! Thanks, Andreas Am 06.01.2014 13:31, schrieb Martin Dobias: Hi Andreas On Fri, Dec 13, 2013 at 8:31 PM, Andreas Neumann a.neum...@carto.net wrote: Hi Martin, I guess I am also running into the PostgreSQL issue. In general my PostgreSQL based projects with many layers freeze after a very short time, while the SpatiaLite based projects work very nicely. Too many PostgreSQL connections? Can we limit the PostgreSQL connections or can you better re-use existing connections? A quick followup - today I have pushed some changes that introduce a connection pool for PostgreSQL. This should remove the problem with too many connections. It limits the maximum number of concurrent connections from one QGIS instance to four. Also, when the connections are not used for some time, they get closed to save resources (right now it is after one minute). Please test and let me know if things work better now. I will probably also look at pooling of SpatiaLite connections - right now the queries within SQLite are serialized, so within one SpatiaLite database you will not see any performance gain with parallel rendering. Regards 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
