Re: [Qgis-developer] Bye bye SPIT?
Hi, About removing SPIT: Yesterday I imported a large shapefile (which was not even loaded in QGIS) into postgis using the GUI from SPIT; I can't find a way to do so with the DB manager. Mayeul - Mail original - De: Tim Sutton li...@linfiniti.com À: Alexander Bruy alexander.b...@gmail.com Cc: qgis-developer qgis-developer@lists.osgeo.org Envoyé: Mercredi 2 Mai 2012 15:24:50 Objet: Re: [Qgis-developer] Bye bye SPIT? Hi On Wed, May 2, 2012 at 1:30 PM, Alexander Bruy alexander.b...@gmail.com wrote: No objections from me. Good But I also want suggest to remove from fTools Select by Location tool because we have more powerful Spatial Query plugin in core I guess the only downside to that is that SEXTANTE would not be able to use it (it seems to have an ftools integration). Perhaps we should wait till next release, move the Spatial Query tool into analysis and create bindings for it? Regards Tim 2012/5/2 Tim Sutton li...@linfiniti.com: Hi All At the hackfest it was proposed to remove SPIT since it's functionality is present in the DBManager (along with a lot of other nice functionality). Does anyone have objections to me removing it before 1.8 is released? Thanks -- Alexander Bruy -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == 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. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Bye bye SPIT?
oh, yes, you're right - it's PostGIS Manager that requires shp2pgsql, not SPIT. My mistake. Sure, duplication of tools is bad. But removing SPIT would mean removing the *only* (correct?) QGIS GUI tool to load shapefiles into postgis without external dependencies. Do we want to get read of this before putting it in DB manager? Mayeul ___ 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] Re: Working on Symbology Improvement for the GSOC
Hi, Using QGIS 1.9 I've rendered one third of the Alps with 15 different zoom levels as a hobby project (and serve the world at work on QGIS server with a simpler symbology). See links and what I've learned from this below. Here would be my wish-list should we want to compete with open renderers like Mapnik and Osmarender: - Better (point) displacement plugin and/or rules on how to manage overlapping symbols (ignore some symbols). For an example of what is wrong, see here: http://www.outdoormaps.org/simple_map.htm?zoom=15lat=46.10527lon=7.07953layers=B0 - Manage z-index (show bridges above roads above tunnels above...). (I proposed a quite simple implementation.) Here one example where Mapnik gives good results but my (qgis-made) outdoormaps fails: http://www.outdoormaps.org/map.htm?zoom=16lat=45.72481lon=8.62683layers=0FFF It's a road over a railway over a road. Picture below: http://fr.structurae.de/photos/index.cfm?JS=170534 OpenStreetMap statistics show that this (and more tricky) examples are common. - if/else / priority of rules functionality (as it was in 1.7.4 or with other implementation) I have detailed most of those in the thread below: http://comments.gmane.org/gmane.comp.gis.qgis.devel/17094 Other note: For the sample dataset function the user can simply load a simple dataset and experiment with it, then save the styles and apply them in another project. I worked with a sample area on an old machine then applied it to the world (OSM) with success. For average and fast machines, then the postgis indexes do the workas long as you do not zoom out too much so live experimentation with OSM world dataset is possible with QGIS. Mayeul Le lundi 02 avril 2012 à 08:14 +0200, Martin Dobias a écrit : On Sun, Apr 1, 2012 at 11:49 PM, Tim Sutton li...@linfiniti.com wrote: - in the tree, each node should have a small preview icon for that node. So for example if a node is a symbol layer, it would just show that simple line or whatever. If the node is a symbol, it should show the composited result of the symbol layers beneath it. If the node is an aggregate symbol, is should show the composited result of the symbols beneath it. - Assuming a tree that works this way: - Class Symbol - Aggregate symbol - Symbol - Symbol - Symbol Layer - Symbol layer [...] - The gui we had envisaged in Lisbon would provide a tree and to the right of it would be a widget which would update based on the context of the node you are on. I have also recalled the GUI brainstorm from Lisbon hackfest - I have put together a quick mockup to explain what we designed one year ago. The image is attached. Please note that this one dialog should replace the recursive series of symbol selector + symbol properties dialogs. The idea is that there would be just one dialog for setting symbol properties that dynamically updates its content depending on the selection within the symbol tree. I will comment on other ideas/proposals later. Cheers 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] Re: OpenLayers plugin blocks QGIS
Hi, Same problem on Ubuntu 11.10 both with QGIS 1.7.4 (from packages) and 1.9 (compiled by myself). Plugin version: 0.7.1 Same bug even if de-activating all other plugins. Logs when running from command line: Debug: OpenlayersLayer draw Debug: extent: -1866561.0290235436987132,-445776.2978746853768826 : 2072425.8407358757685870,2051521.8292308524250984 Debug: center: 102932.405856, 802872.765678 Debug: size: 1612, 1022 Debug: logicalDpiX: 88 Debug: outputDpi: 88.00 Debug: mapUnitsPerPixel: 2443 Debug: olSize: 1612, 1022 Debug: OpenlayersLayer draw Debug: page file: file:home/user/.qgis/python/plugins/openlayers/html/osm.html Debug: undefined[0]: TypeError: 'null' is not an object I'm not sure the last error is relevant: same message appears for Google layers, which load fine. Mayeul Le jeudi 16 février 2012 à 07:46 -0800, Salvatore Larosa a écrit : Same problem for me on Debian wheezy with QGIS master! SL -- View this message in context: http://osgeo-org.1560.n6.nabble.com/OpenLayers-plugin-blocks-QGIS-tp4370407p4476505.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] Removing old labelling / polygons / WMS tiles
Thanks Andreas! You are right. Still there are 3 different issues with labeling and tiling: -No placement outside the BBOX -Dynamic label placement -Repeated labels Larger area (meta buffer) solves only the first issue, the 2nd and 3rd need work on the WMS side (hence either old labelling or the solution you mentioned). This is explained very well in images here: http://mapproxy.org/docs/latest/labeling.html I still need a few days to finish uploading my 6 GB of QGIS-Mapproxy tiles illustrating this! Stay tuned... Mayeul Le vendredi 09 mars 2012 à 09:17 +0100, Andreas Neumann a écrit : Hi Mayeul, I find it useful that clipped features at the edge of the map always get labeled. I actually demanded such a feature from labeling 2.0 If you want to generate fixed tiles I think the way to go is by clipping a much larger area and then clip out the center. Proxies, such as mapproxy can generate these tiles. That way you get good performance and the advanced labeling of QGIS. If you want fixed labels in QGIS you can generate the centroids by some tool (e.g. Postgis SQL) and set the x and y columns. That way you get guaranteed fixed labels. But I am not a tiling expert - so I may be wrong. Andreas On Thu, 08 Mar 2012 23:22:22 +0100, Mayeul Kauffmann wrote: I also experienced problems with new labelling for polygons. Even when you set new labelling to try only one position, and stay on centroid, labels still move when you pan. They kind of stay on the centroid of the *visible* part of the area. It is annoying when generating tiles with qgis server: you can get duplicated or cut labels. Users have difficulty with this and sometimes the only option is the old labelling. (Cannot find back that wonderful post of a frequent qgis blogger who faced the issue and went back to UMN Mapserver. SUre s/he is reading this) Other example: http://osgeo-org.1560.n6.nabble.com/QGIS-Server-street-names-in-tiles-td4540846.html Blind guess: Maybe the fact that it recalculates centroid of partial polygons at each refresh can cast some light on the performance issue? Mayeul Le mardi 06 mars 2012 à 14:00 +0100, Andreas Neumann a écrit : Hi, Please be more concrete - there are almost 100 different settings and combinations. What is the problem very precise/concrete. What settings did you use, what geometry type - maybe accompanied with screenshots of your settings. In my experience the new labeling works very well and fast. Only area geometries are slow to label. Martin Dobias is currently working on improving/accelerating the labeling of area geometries. Andreas On Tue, 06 Mar 2012 13:13:11 +0100, Paolo Cavallini wrote: Il 05/03/2012 17:06, Andreas Neumann ha scritto: Hi, We discussed this issue backwards and forwards and it would be good to make some progress here. There is really not a lot missing in the new labeling and I don't agree with Paolo that the new labeling is slower than the old labeling. It may have different settings and thus people are comparing apples with oranges. Please test it with an old PC, ora netbooK: in our case it is almost unusable with 300 polygons. Also, some of the bugs are pretty serious. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Removing old labelling / polygons (in 1.9)
I also experienced problems with new labelling for polygons. Even when you set new labelling to try only one position, and stay on centroid, labels still move when you pan. They kind of stay on the centroid of the *visible* part of the area. It is annoying when generating tiles with qgis server: you can get duplicated or cut labels. Users have difficulty with this and sometimes the only option is the old labelling. (Cannot find back that wonderful post of a frequent qgis blogger who faced the issue and went back to UMN Mapserver. SUre s/he is reading this) Other example: http://osgeo-org.1560.n6.nabble.com/QGIS-Server-street-names-in-tiles-td4540846.html Blind guess: Maybe the fact that it recalculates centroid of partial polygons at each refresh can cast some light on the performance issue? Mayeul Le mardi 06 mars 2012 à 14:00 +0100, Andreas Neumann a écrit : Hi, Please be more concrete - there are almost 100 different settings and combinations. What is the problem very precise/concrete. What settings did you use, what geometry type - maybe accompanied with screenshots of your settings. In my experience the new labeling works very well and fast. Only area geometries are slow to label. Martin Dobias is currently working on improving/accelerating the labeling of area geometries. Andreas On Tue, 06 Mar 2012 13:13:11 +0100, Paolo Cavallini wrote: Il 05/03/2012 17:06, Andreas Neumann ha scritto: Hi, We discussed this issue backwards and forwards and it would be good to make some progress here. There is really not a lot missing in the new labeling and I don't agree with Paolo that the new labeling is slower than the old labeling. It may have different settings and thus people are comparing apples with oranges. Please test it with an old PC, ora netbooK: in our case it is almost unusable with 300 polygons. Also, some of the bugs are pretty serious. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Criticism of lack of symbols in QGIS
Hi, This discussion came up already, but just in case this was forgotten: I generated a set of about 1000 svg color icons for QGIS, based on OSM icons. Available here as public domain: http://www.mediafire.com/?jiooxkbmyzgr0 Sample use visible in this video: http://www.youtube.com/watch?v=NBBYtH2svw0t=3m26s (Customizing OSM map with osm2postgresql QGIS ) Hope this helps, Mayeul Le vendredi 03 février 2012 à 23:46 -0800, Alex Mandel a écrit : On 02/03/2012 09:39 PM, Tyler Mitchell wrote: FYI, I +others converted over 100 icons from pdf/font to svg in a 2 hour sprint a few months back. We should add something to pull them into QGIS source for inclusion. Only hold up was that I couldn't get the svg fill stuff worked out. Very cool - are these icons the ones that you can access already via the style manager SVG options? No these icons are converted from public domain US government sets, as of Oct 2011. They have not been incorporated into QGIS yet, but will be shortly. After talking with Nathan and Gary I think we can find a way to pull a copy from the osgeo svn every once in a while, say when building a new release, so maybe they'll be in QGIS 1.7.4 Alternately maybe a plugin should be made to pull them in as an optional thing. Thanks, Alex ___ 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] Rule-based renderer updates
Hi Martin, I've made some tests playing with a few hundred styles, comparing QGIS 1.7.1 and 1.9.0. Overall, I find your commit very good, thanks a lot! Still there are a few regressions IMHO. Discussion below. Rules now form a hierarchical structure: any rule can contain further child rules. When rendering, child rules are applied only when their parent rule matches. This allows users to build a logical trees of rules instead of keeping all rules in a flat list with complex filters. Well, they already did, by using the refine button. Still, the new implementation is MUCH better as you can define a parent rule, many children, then change only one parent (before, you had to modify each single rule). The options use only first rule and use symbol levels have been removed: now all the matching rules and applied and at the same time the rendering order is given by the symbol levels. In my opinion this is the major regression. With 1.7 it was possible to have some if/else logic, and the priority made it somehow work like SLD Mapnik: because in SLD and Mapnik the order of rules matters The beauty of the new hierarchical grouping is to help having simpler rules creation and modification. But removing use only first rule requires to put back AND NOT (previous_rule) criteria to achieve this. This make some use cases more complex and is more computer intensive (the user could put frequent rules on the top to speed up things: subsequent rules are ignored). GUI: rules are shown as a tree. They can be organized easily with drag and drop That's GREAT! Still, apparently the first child rule of a rule need to be created with the refine current rules button before being able to drag and drip children. If you have 5 exiting rules that you want to group under a new parent, you create the parent, create a first child, drag and drop the 5 children, then delete the first child. (Edit: Still sometimes it works... when parent filter is empty?) symbol levels dialog for other renderers is now accessible from a menu from their advanced button That's one click more for some renderers. It's not consistent across renderers: Rendering order... is directly accessible in Rule Based Renderer; Symbol levels is no longer directly accessible. I would suggest to use always Symbol levels. Rendering order... is technically correct but users may confuse it with the rule order, while symbol levels does not have this problem. = Summary and other notes: (+) 1- Truly Hierarchical rules 2- Symbol levels even with several matching rules 3- The ability to change the colour, transparency, output unit and size of several symbols at one time (not 4- Inline editing 5- Drag and drop (=) -The Refine a rule to categories/ranges windows has an AdvancedSymbol levels widget. Why not... -Legend does not reflect hierarchy (-) 1) The priority system and use only first rule option disappeared. 2) The ability to display rules in 3 different ways (a flat way, by grouping them by filter or by scale) has disappeared. Now the GUI is similar to previous grouping by filter. 3) The ability to order the display of the rules by clicking on the column title ( label, rule, scale...) disappeared. This was handy! 4) Impossible to drag a rule A to a rule B to have A be a child of B if B has no child yet. 5) Confusing Rendering order.../Symbol levels 6) Slightly confusing: direct editing of transparency in list allow e.g. 0,5 which corresponds to 50% in the slider version of the symbol properties (by the way the latter would benefit from an edit box). = Suggested priority future improvements IMHO: - Reimplement the (-) above as they are regressions IMO: 1) some optional use only first rule and else behaviour is needed 2) is needed specially for scale. Scale ordering (with 3. ) will make 2) less needed. 3) is more needed than filtering of rules and that 2) 4) minor (but might confuse users) 5) minor but easy to fix - Clone rules - Implement Z-index based on one attribute. Suggested implementation: User says which field has the z index. Lowest z index get rendered below for all rules (using their symbol levels), then next z index, etc. up to highest z-index. Cf. below: For example, when drawing a map of roads with nicely rendered road outlines and varying Z-levels (bridges / tunnels) Z-levels is often stored in one single attribute and is not always related to the other attributes. If you take the main 50 linear feature types, any of them may have values between -5 and +5 in OpenStreetMap, values with -2 and +2 are very common (around 8 features) and +/- 3 are still frequent (14000). http://taginfo.openstreetmap.org/keys/?key=layer#values Hence currently you need around 350 rules for 50 linear feature types and 7 layers. And this without being able to do this: http://osm.org/go/Tt5bBYZU5- (Note that rivers may go below a canal,
Re: [Qgis-developer] rm EPSG:900913?
Hi, Hi would vote to keep it for a while, but I dislike it (it's not an official epsg code, and even the name is incorrect Google Mercator is not a Mercator projection). As a compromise, could we add (deprecated) or even (deprecated, cf. 3857) ? It would also be hidden when you check hide deprecated CRS. Mayeul Le mercredi 18 janvier 2012 à 17:23 +0200, Tim Sutton a écrit : Why don't we keep it around for a while - although its not official it is in wide popular use and there are many tutorials and other materials that reference this id. Regards Tim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] User plugins bug reports server unavailable?
Hi, I just tried to report a few bugs on a user plugin but could not: Clicking new issue goes to: http://hub.qgis.org/projects/qgis-user-plugins/issues/new which says: No tracker is associated to this project. Please check the Project settings. while: http://hub.qgis.org/projects/quantum-gis/issues/new works. Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Web Client - New Features
Hi Larry, I'm new to the list Welcome then and thanks for contributing! That looks great, I'll use this and know others that will! It would be good to have some popular OpenLayers layers included by default, with just the need to uncomment or change one or 2 lines of javascript (for instance, for the 5 base layers of http://www.openstreetmap.org/ ). It would make a handy way to combine e.g. custom QGIS data rendering (such as http://www.youtube.com/watch?v=NBBYtH2svw0 ) with OSM base map, and in some cases may alleviate the need for tile caching the QGIS-rendered layers (with a good base map, you can simplify your overlay). Finally, it offers a solution to a few bugs [1] affecting the QGIS openlayers plugin, and as such is handy even for desktop use. Cheers, Mayeul [1] I'm trying to report them here: http://hub.qgis.org/projects/qgis-user-plugins/issues/new Namely: rezoom automatically at world level in some cases; wait for all tiles to be available to display them. Le jeudi 05 janvier 2012 à 16:51 -0700, Larry Shaffer a écrit : Hi, I'm new to the list, but have been tinkering around with new features for the QGIS Web Client for about a month now. I finally decided to fork the client project at github and am looking for some input on the first new feature I've got working: extra OpenLayers base layers and overlays (with the QGIS Server output sandwiched between). Working with a QGIS Server, MapProxy and OpenLayers workflow, I've gotten the maps rendering in the client faster, decently cached, and with quick label drawing. See the marginally coherent description here: http://dakcarto.github.com/qgis-web-client/ There is no code yet to play with as I am figuring out how to work with git/github (first time with this VCS) and push the work up to my 'extralayers' branch. I'm looking for input on the feature, like whether you think it is a good addition, or whether you see a different approach. I'm mostly looking at adding features that keep the user entry level still around just knowing some javascript, OpenLayers and a smattering of server configuration. I think keeping the logic coding mixed in with GeoExt/Ext, and the configuration easier, is a benefit to adoption of the client by a wider user group. Thank you for any help you can offer, and thanks to those who have previously worked on the client, Larry Shaffer Dakota Cartography Black Hills, South Dakota ___ 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] User plugins bug reports server unavailable?
Hi Richard, Thanks for your very clear answer! I have updated the page http://hub.qgis.org/wiki/quantum-gis/Bugreports with more detailed instructions. (If it is possible, removing the New issue link at http://hub.qgis.org/projects/qgis-user-plugins might help some users, since the link will always trigger an error message. Alternatively, the link could go to a page saying that you have to go to a plugin sub-project first). Cheers, Mayeul Le vendredi 06 janvier 2012 à 19:54 +0100, Richard Duivenvoorde a écrit : On 2012-01-06 15:27, Mayeul Kauffmann wrote: Hi, I just tried to report a few bugs on a user plugin but could not: Clicking new issue goes to: http://hub.qgis.org/projects/qgis-user-plugins/issues/new which says: No tracker is associated to this project. Please check the Project settings. while: http://hub.qgis.org/projects/quantum-gis/issues/new works. Hi Mayeul, qgis-user-plugins is an 'umbrella-project' for plugins: http://hub.qgis.org/projects/qgis-user-plugins Eg I have two plugins hanging under that project: xytools and simplesvg: which both have trackers: http://hub.qgis.org/projects/xytools/issues/new http://hub.qgis.org/projects/simplesvg/issues/new For which plugin do you want to issue bugs? Because, from adding my plugins, I know that you have to tick a certain tickbox to have a tracker and git with your plugin. Maybe the plugin you want to issue for does not have a tracker? Maybe contact the author/owner of the plugin? I think that the umbrella does not have that and that you have to issue you plugin issues to the individual plugin that your bug is for... It is maybe possible to add a tracker to the umbrella-project also, but I do not know what the consensus is for that. I do prefer to have one tracker per plugin: because the actual plugin maintainer is the first person to be responsible for it. But maybe other think different? Richard ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Benchmarking / optimization
Le lundi 28 novembre 2011 à 19:49 +0100, Radim Blazek a écrit : My next plans are: 1) add more projects (more data types and rendering modes) to my benchmark suite Hi, You may try to use http://sourceforge.net/projects/osm2postgresql/ to test with huge OSM datasets. I'm doing this daily on continental extracts (and planning to do this on planet.osm soon). (Do NOT try to import full planet.osm with osm2postgresql_04.sh, next version will be released soon). Rendering when zoomed in a lot is OK, but I would not try to zoom out to much! Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] manual/automatic screenshots
Hi, +1. See older thread: De: Mayeul Kauffmann mayeul.kauffm...@free.fr À: Mars Sjoden aurorageomat...@gmail.com Cc: Andrew Chapman andrew.chap...@donkagen.co.uk, qgis-developer@lists.osgeo.org Sujet: Re: [Qgis-developer] Testing and releases Date: Wed, 08 Jun 2011 22:47:37 +0200 Hi, Some time ago I used xmacro (a Keyboard/mouse macro utility) to create a set of screenshots for a software (GanttProject) in about 15 languages; then it was integrated in OpenOffice documents with relative links. In my experience only the keyboard part was reliable, which requires to have unique and stable keyboard shortcuts for every single menu and dialog box, which is currently very far to be the case (improvements here will also improve usability and user productivity). Interaction in the map canvas is more problematic here. There is also this from the qt manual: http://doc.trolltech.com/4.8-snapshot/gettingstarted-develop.html#testing-qt-applications including this which supports mouse and keyboard simulation: http://doc.trolltech.com/4.8-snapshot/qtestlib-manual.html Mayeul Le mardi 15 novembre 2011 à 11:06 +0100, Paolo Cavallini a écrit : Hi all. I see we are moving away from LaTeX, a move that will bring us more translators, I think. In the occasion, could we think how to make screenshots more automatic? I think we can add a command to rst to automatically generate them during compilation, e.g. qgis --snapshot filename --project filename. Currently this does not allow to open menus etc, but at least some of the screenshots could be made automatic. This could allow to have different manuals for different operating systems, different languages etc. with less effort. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis 1.7 install error
I'm not an install guru, but knowing what is your architecture might help. Myself I'm using non standard install procedure that I described here: http://www.qgis.org/wiki/Talk:Building_QGIS_from_Source It might help. Mayeul Le samedi 01 octobre 2011 à 18:31 +, Jules Kouadio a écrit : Hello. I get this error after the commands mkdir build-master cd build-master ccmake .. make .. Scanning dependencies of target python_module_qgis_analysis [ 93%] Building CXX object python/CMakeFiles/python_module_qgis_analysis.dir/analysis/sipanalysispart0.cpp.o /home/sekedoua/qgis-Quantum-GIS-7bf7110/build-master/python/analysis/sipanalysispart0.cpp: In function ‘void initanalysis()’: /home/sekedoua/qgis-Quantum-GIS-7bf7110/build-master/python/analysis/sipanalysispart0.cpp:161: erreur: ‘SIP_MODULE_NAME’ was not declared in this scope make[2]: *** [python/CMakeFiles/python_module_qgis_analysis.dir/analysis/sipanalysispart0.cpp.o] Erreur 1 make[1]: *** [python/CMakeFiles/python_module_qgis_analysis.dir/all] Erreur 2 make: *** [all] Erreur 2 Please Help me. Thanks. -- -- ___ 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 custom buil to read obfuscated data
@Niccolò: good point. Howevere one could write a non GPL piece of code (the minimum to keep the data undisclosable) and link qgis to it. Is it forbidden by GPL license? I don't think... I think it is. I also believe it might be forbidden by the GPL. I think there might be a way to reconcile ethics, respect for the GPL and the client needs. You would need to obfuscate the source code. For example, you rename fonctions, classes, filenames etc according to an encryption mechanism. The encryption is based on a key chosen by the client. You need to take care of many things, e.g. if: qgsapplication.cpp becomes qslghtygvr15ni189t.cpp then: qgsapplication.h becomes qslghtygvr15ni189t.h Naming conventions which are understood by the framework should be respected as well (I do not know qgis's architecture well enough to be precise here). In one part of the code, you put your mechanism decoding the data. You then release the whole thing as GPL. Obviously, you work on the non-obfuscated code. You need to use or build a software to obfuscate the code (http://en.wikipedia.org/wiki/Obfuscated_code says there are open-source software to do so). Then, for the ethic part: you also share any improvement you do in non-obfuscated format (except maybe the data-decoding part). I wonder though if the major part of the data-decoding part could be generic enough to be shared as (non-obfuscated) GPL code. Then other sensitive projects may reuse it. Is the whole approach ethical? I really don't know. Still, it would be funny to receive a dataset with a notice: to read this geotiff, you must use our version of QuantumGIS, not ArcGIS or Mapinfo! EDIT: not sure the approach above is OK, see http://stackoverflow.com/questions/1086445/obfuscation-and-gpl However GPL encryption software do exist. Maybe the data provider could give the data with a key. Of course it makes the system much weaker. However, the client should be aware that an external compiled piece of code is not much less easy to crack than it is to change an open source software. A final note: I believe in free software and in free geo data. I contribute to QGIS and to OpenStreetMap. I've produced some of OSM icons and released them in public domain. However, piracy exists and I condemn it; some organizations may rightfully search ways to protect themselves against unauthorized used of their data. I prefer companies that share their data, but as long as you contribute yourself to QGIS in other domains, then you would learn something from this work and I would say it's better than if they pay ESRI developers to do the same. Still, if you can find another client/boss which is more open source minded, then I would encourage you to refuse this task. Otherwise, I'll pray for you soul! Hope this helps, Mayeul Probably you're right. http://blog.milkingthegnu.org/2008/04/gpl-for-dummies.html --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.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] DB Manager release
Great! What's the minimal QGIS version required? (I'm stuck with 1.7 until symbol levels with rule-based renderer find their way into the trunk). Mayeul Le jeudi 15 septembre 2011 à 14:18 +0200, Paolo Cavallini a écrit : Hi all. Thanks to the hard work of Giuseppe Sucameli, the supervision of Martin Dobias, and the support of Google for its Summer of Code initiative, DB Manager is now available. DBManager's aim is to merge together some QGis DB plugins, e.g. PGManager, SLManager, RT_Sql_Layer. In this moment it works with both PostgreSQL and SQLite databases and it displays the list of tables, info about the selected table, table data and preview, but also allows to rename/delete tables through its GUI and run query on the selected database, so at this stage it replaces at all SLManager. Thanks to Mauricio De Paulo (mauriciodev), now DB Manager also supports PostGIS Rasters! The last DB Manager version has support to Import Vector Layer feature by drag'n'drop a layer from the QGis browser (or even DB Manager) to a database in the DBManager GUI. The Import Vector Layer feature allows to import/copy any vector layer QGis can load between different datasources, i.e. PostGIS/SpatiaLite databases and OGR files. It's available through the QgsVectorLayerImport class and it has just been merged in master branch. See [1] for an example of use. Faunalia is committed to support the development of this tool, and other DB plugin developers are welcome to join and merge their work, it this makes sense, to reduce confusion for users. Enjoy. [1] http://www.youtube.com/watch?v=bBe7WctSAXI ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Postgis Live historisation
Hi,
I am trying to use Postgis Live historisation from QGIS, following:
http://www.kappasys.ch/pgtools/pghistory/#toc8
I ran into several problems.
Main one is:
After initial import of dataset, the first modification to each single
feature does not add the archive date to it (hence the view does not
filter it). Subsequent modification of a feature which has been modified
at least once are correctly logged and the archive date is correctly
inserted.
Here is what I do:
1. Create data structure with:
shp2pgsql -p -c -I points_test.shp | psql)
2. initialise historisation
SELECT add_history('public'::text, 'points_test'::text,
'public_view'::text, 'points_test_view'::text, true);
3. Load data
shp2pgsql -a points_tests.shp public_view.points_test_view
4. Modify a feature in QGIS
Swapping steps 2 3 give same results.
As a workaround, I was thinking of making a simple update (updating a
field by setting it to its own value) and then deleting unnecessary rows
just after step 3, but I cold not find a way to have the desired effect.
2nd problem is related to date attribute: I have dates as attributes to
my tables. The perl code seems to assume that if it's not a text, it's a
numeric and posgres complains about the trigger trying to insert a
numeric into a date field.
My workaround is to use only text field instead of date fields; I can
live with this.
---
Some other problems are related to documentation.
I had to find out that the following is necessary:
-- DROP TYPE IF EXISTS change_type CASCADE;
CREATE TYPE change_type AS ENUM ('insert', 'update', 'delete');
CREATE SCHEMA public_view AUTHORIZATION
The doc says:
myaccount;add_history('name_schema','name_table','name_schema_view','name_view')
but looking at the code shows that a new (boolean) parameter was addded
at the end.
Finally, last problem: I could not simply load the functions from the
shell with:
psql
-f ~/postgis/insert_timegis_trigger_function.sql
It complained about an error near the end of the script, near
(double quotes with nothing in it?!)
I had to open the query in pgadmin3 to run it.
Thanks for any hint!
Mayeul
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [WEBCLIENT]Specific mailinglist? (was: Mailinglist for QGIS Web-Client)
Le vendredi 26 août 2011 à 23:26 +0200, Tim Sutton a écrit : But seriously, ...tagging subjects like [WEBCLIENT] Help my blah blah blah... is what he had in mind I thinkthough that requires a level of inolvement in list politics that most of our subscribers may not possess I am afraid Regards Tim Hi Yes, tagging the subjects is the easiest to implement, use, and is forgiving.. It would already be great. Disadvantage is that it makes long subjects sometimes, not always though. For instance, this subject would become: [Qgis-developer][WEBCLIENT] Sepecific mailinglist? It is possible to make shorter subjects by modifying the first part of the subject (server side): [Qgis-dev][WEBCLIENT] Specific mailinglist? Or even [QgisDev][WebClient] Specific mailinglist? We already have [Qgis-tr], so why not have shorter tags than [Qgis-developer] ? I suggest CamelCase for readibility, the email client filters are normally case insensitive. For the tags, we need to agree on them to help users create rules. This should be somehow consistent with tagging practices in tracking, wiki, etc. Badly-tagged emails can still be filtered manually by end readers. My genuine question implied something different, one possibility would have been to put tags in the full text for the cases where there is overlap between two subjects. This would avoid very long subjects, but those situations are rare and this would slow down the email filters a lot, so forget it. Marco wrote: You make me sound too smart, and you still didnt give me the target arch of your calculator :) What about doing this for my Kodak EasyShare M420 digicam? Easier task: It already has the zoom in and zoom out buttons ;-) Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsExpression: replacement for QgsSearchString
PostgreSQL is very strict about type conversions, Sqlite is not strict at all and MySQL is somewhere in the middle. I have ended up with these conversion rules: - implicit conversions to desired types - string-number conversions with invalid input return error - arithmetic operators convert to numeric - comparison with numeric type = numeric comparison Apparently my email is too late as this is already merged. Still, IMHO, I would suggest that your rule be as close as possible to the existing rules of one major RDBMS (am I correct in assuming that your implementation is close to MySQL?), or you even better you may use the rule of one existing DB wrapper. You will probably get more consistent/robust results by trying to follow as much as possible an existing standard instead of inventing Yet Another Conversion Standard. There will be use cases that you have not thought about yet. In front of them, the Qgis community would ask how standard x solves this problem? instead of should we use standard x, y or z for this particular case? I am a big fan of postgres. But if you follow (say) MySQL 70 % of the time, postgres 20 % of the time and your own rules the remaining 10%, I would prefer if you try to use 100% MySQL-like rules. My 2 cents. Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Mailinglist for QGIS Web-Client
Le jeudi 25 août 2011 à 22:39 +0200, Marco Bernasocchi a écrit : What about tagging subjects? You mean helping the email clients to automatically filter or classify emails? If this is easy both for email writers and readers, that would be great! Mayeul Marco (android mobile) On Aug 25, 2011 8:51 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi, Myself I would register right away to such a list! However I believe it might be good to have a common list for QGIS Web server and QGIS webclient. (+) QGIS Web server implements non-standard wms capabilities (like the print functionality) and QGIS webclient makes use of them (-) You will loose some readers. There are already many qgis mailing list. If one discussion starts about the desktop print composer and then trolls to the server (or start with server and goes to desktop), then part of the discussion will be on the wrong list. My 2 cents. Mayeul PS: thanks for the web client! Le mercredi 24 août 2011 à 13:13 +0200, Andreas Neumann a écrit : Hi, I wonder if we could establish a mailinglist for QGIS web-client developers? I will be working more actively on the webclient and would like to use it for discussion and announcements, as well as contact with the translators. Most new features require new translations. Should I use the qgis-developer mailinglist or would we setup a separate mailing-list? 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
Re: [Qgis-developer] Mailinglist for QGIS Web-Client
Hi, Myself I would register right away to such a list! However I believe it might be good to have a common list for QGIS Web server and QGIS webclient. (+) QGIS Web server implements non-standard wms capabilities (like the print functionality) and QGIS webclient makes use of them (-) You will loose some readers. There are already many qgis mailing list. If one discussion starts about the desktop print composer and then trolls to the server (or start with server and goes to desktop), then part of the discussion will be on the wrong list. My 2 cents. Mayeul PS: thanks for the web client! Le mercredi 24 août 2011 à 13:13 +0200, Andreas Neumann a écrit : Hi, I wonder if we could establish a mailinglist for QGIS web-client developers? I will be working more actively on the webclient and would like to use it for discussion and announcements, as well as contact with the translators. Most new features require new translations. Should I use the qgis-developer mailinglist or would we setup a separate mailing-list? Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] symbol levels in rule-based rendering
Hi, Thanks for raising this! After months of use of symbol levels in rule-based rendering (SLinRBR), I found the implementation robust. I have several colleagues using regularly my OSM styles. Yesterday I deployed it on an intranet with the webclient, see: http://www.qgis.org/qgiswiki/images/f/fd/Test_qgis_webclient_osm.png http://www.qgis.org/wiki/QGIS_Server_Tutorial#Core_Features So I support applying the SLinRBR patch into the master branch. Still I agree the SLD logic is interesting as well and efforts in this direction are welcome. I still believe it is possible to somehow merge the two: my understanding is that few changes in SLinRBR are needed to make SLinRBR and SLD logic compatible (specifically: improvement of the ElseFilter in current SLinRBR). This is how we could simply define compatibility: a one-to-one relationship between a set of SLinRBR rules and SLD rules. A looser definition could be: given a set of SLinRBR rules, it is possible to find a set of SLD rules that will give the same results for every dataset (and vice versa). An even looser definition would say ... give almost identical results for almost all datasets. In fact, OGC recognizes that SLD rendering is implementation specific (hence same SLD rules may give different results): Whether all features are applied to each rule in sequence or whether all suitable rules are applied to each feature in sequence is implementation-specific, although there may be subtle differences in the appearance of maps resulting from each of the approaches. (source: OGC 05-077r4, Symbology Encoding Implementation Specification). Again from the OGC specification: Note that the above is a description of the semantics of the ElseFilter and not a requirement that systems implement exactly the procedural method described; any semantically equivalent method will suffice. As the Spec. document recall, boolean algebra and set theory show that there are many different ways to express a given condition. It is possible to have very similar results with the following tools on complex OSM datasets: - QGIS (with SLinRBR) - Osmarender - Mapnik - Kosmos There has been discussion in 2008 about using SLD as a way to share rules between the last 3: http://web.archiveorange.com/archive/v/wQWIbLKKl2Drk3qgOFep I do not know the output today but this seems to confirm my feeling that the different logics are somehow compatible. If this is true, all the rest is related to the user interface and the implementation. Hope this helps! All the best, Mayeul Le jeudi 18 août 2011 à 08:45 +0200, Marco Hugentobler a écrit : Hi all After several months, I'd like to open the discussion again and suggest to merge Mayeuls patch into the master branch as well (currently only in 1.7, see also https://github.com/qgis/Quantum-GIS/pull/26) While a rule based renderer following SLD logic would be great in the future , the symbol level patch exists and can be very usefull until a redesigned renderer is there. Any objections? Regards, Marco Am Dienstag, 8. März 2011, 09.03:50 schrieb kimaidou: Hi devs, I agree with Marco and Martin : following the SLD logic would be great. It would help a lot people used to SLD to understand the logic of Qgis styling. I also think we should keep the logic easy to understand while not loosing too much power. Talking about SLD import/export... Using Qgis as a wysiwyg tool to create and share great styles would be awesome. But we must keep in mind SLD specifications do not cover all the features we could imagine/have in Qgis. If we go toward the SLD way (+1 for me), and be able to export/import from/to SLD we would need to have kind of a table of features to compare what can be done in Qgis and not trhough SLD (and the way around). For example, the new labelling engine allows to write labels following lines. As described in the SLD Cookbook (see [1] and [2]) we would need to mimic geoserver vendorOptions tag when exporting from Qgis to SLD. By the way, you must have seen the new SaveAsSLD plugin made by Adrian Weber. He told me he will now focus on supporting new symbology. I am trying to help him and will when I find time. While reading this post, I was thinking it would help a lot if Qgis logic followed the SLD one :) [1] http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#la bel-following-line [2] http://docs.geoserver.org/stable/en/user/_downloads/line_labelfollowingline .sld Kimaidou 2011/3/7 Marco Hugentobler marco.hugentob...@sourcepole.ch Hi Martin I'm also in favour of a rule based renderer that follows closely the logic of SLD. It would be a big plus for QGIS server too. Currently, it's SLD capabilities are built on top of the old renderer, so no overpainting, etc. And yes, with a nice GUI, it will be as user-friendly as the other parts of the symbology. Regards, Marco Am
Re: [Qgis-developer] Rethinking the testing ... (test-driven development)
Hi Just a thought on branch THEN work THEN write tests. It could be instead: branch THEN write tests THEN work. Agile programming encourages test-driven development: you write the tests first, then you code new functionalities. http://en.wikipedia.org/wiki/Test_driven_development While this encourages good practice, I do not know how easy would it be to implement. Anyway, thanks again all for your work! Mayeul Tim Sutton wrote fork branch work write tests request for merge integrate ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] pgversion and QGIS Plugin / emaj (history versioning)
Hi, Followup to recent discussion on pgversion plugin: For versioning (in the sense of history), there is emaj for postgresql: http://pgfoundry.org/projects/emaj/ The manual is well written. Version 0.9 works very well even with postgis data and provides full versioning and rollback (including with tied tables). The only issue is that the id type is not supported by qgis; an easy workaround for a reasonable number of changes is to use a view like this: CREATE OR REPLACE VIEW emaj.test_points_log_view AS (SELECT emaj_id::int4 as id_int4, * from emaj.public_test_points_log); From a philosophical point of view, conflict resolution and history versioning share some ideas: you want to know what the other do. From a functionality point of view, there are some related features: you can stop a commit (pgversion) or roll it back (emaj). As a side note, wikipedia defines versioning in the historical sense (I never encountered the other one), see: http://en.wikipedia.org/wiki/Software_versioning Would be great somehow to somehow merge the two or make them compatible (I have'nt tried), or share some common tables. It also remind me, I believe, a plugin with a slider for versioned data with time-stamp but I cannot find it (was I dreaming?). Thanks and all the best Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Plugin VectorStudio
Hi, I installed the plugin I tried to play with it but could not do anything. Maybe you could describe what it does. If you know how to make a screencast, putting this on, e.g., youtube, is probably the most efficent way. Mayeul Le mercredi 06 juillet 2011 à 14:14 -0300, Pablo Carreira a écrit : Hi, I've uploaded a new plugin called VectorStudio, it provides tools for vectors (geometries) transformations in edit-time. It has an interface that allows the creation of new tools without changing the main code, you can write 'plugins for the plugin'. It's in very early stage and for now is tagged as experimental. I would appreciate comments and suggestions. Regards, Pablo Torres Carreira ___ 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] ESA Summer of Code In Space
Hi, One of the main activity of ESA is earth observation (not Mars observation), so I believe any project focusing on satelite data (imagery or radar) could be sponsored. Mayeul Le mercredi 29 juin 2011 à 12:12 +0100, Barry Rowlingson a écrit : Hi All, the European Space Agency has announced a Summer Of Code project, much like (but independent of) Google's SOC project: http://sophia.estec.esa.int/socis2011/ just thought maybe someone out there has some spacey ideas for Qgis - perhaps a tool to load Martian DEMs from the NASA web site, or an implementation of Martian Coordinate Systems or satellite tracking... The call for proposals isn't that specific (but it does say 'open source' lots). Barry ___ 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-mapserver: user authentication
Hi guys, I'm also interested. Some of my comments below. * user authentification (also needs a secure connection (https)) - could be handled by a python script? * user data storage (can be in a database table (e.g. Postgis, SQLite)) - after the login, QGIS webclient could also store the basic user data, such as name and address. I would prefer storing in the database, as it allows connectivity with other applications and user cases that we cannot even think about. * QGIS server should be made aware about table permissions (roles/groups) and build the GetCapabilities tree accordingly. Here you seem to say: let's use the permissions of the db backend for everything. I find this brilliant: there are plenty of tools to manage those and the this is widely tested (which is important when security matters). The positive side effect is that you can give direct database access to some power users, and you still have to set the rights only once. My understanding is that this cannot work for SQLite (from the manual: the only access permissions that can be applied are the normal file access permissions of the underlying operating system). Second comment on this: Is the above idea about table permissions meant only for vector data, or for PostGIS Raster? (not as widely tested). What follows is: maybe this should be implemented only for a limited number of RDBMS backends. Anyway: Sure, SQLite is much easier for the desktop than Postgres +postgis. Still, if you use https and can buy a certificate, then you have the resources to configure Postgres+postgis. May I ask what do you use for vector backend for QGIS server? Hope this helps, Mayeul Also, I think permissions should be attached either to a) a whole .qgs project (one could use Apache permissions for that) b) or certain layers in a .qgs project How fast do you need that implemented? I think it would be useful to include Pirmin, Marco and Jürgen into the discussion, or whoever else is interested. Maybe something to discuss in a telcon/IRC? Andreas On Tue, 14 Jun 2011 01:12:07 +0100, Giovanni Manghi wrote: Hi all, On Thu, 2011-06-09 at 16:33 +0200, Paolo Cavallini wrote: Hi all. We are interested in an extension of current qgis-mapserver, allowing different users (or groups of) to see different layers (or different projects). Is anyone working on that, or willing to collaborate on a mainstream solution? what we need to develop is quite simple (to explain). Users should be able to register/login in the webclient (users data stored in a geometryless table in the qgis project?), then, depending on what user group the user belong, show certain layers/groups in the TOC of the web client. User data (name, address, etc.) should be stored after the login to allow use them in the print layouts. One way or another we will have to develop something like that, so we would prefer to do it the right way, upstream and in a way that can be useful to as much people as possible. If anyone is interested in collaborate please us know. Cheers -- Giovanni -- ___ 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] Testing and releases
Hi, Some time ago I used xmacro (a Keyboard/mouse macro utility) to create a set of screenshots for a software (GanttProject) in about 15 languages; then it was integrated in OpenOffice documents with relative links. In my experience only the keyboard part was reliable, which requires to have unique and stable keyboard shortcuts for every single menu and dialog box, which is currently very far to be the case (improvements here will also improve usability and user productivity). Interaction in the map canvas is more problematic here. There is also this from the qt manual: http://doc.trolltech.com/4.8-snapshot/gettingstarted-develop.html#testing-qt-applications including this which supports mouse and keyboard simulation: http://doc.trolltech.com/4.8-snapshot/qtestlib-manual.html Mayeul Le mercredi 08 juin 2011 à 11:48 -0700, Mars Sjoden a écrit : I would be interested in participating as dumb user, The 'black box' sounds interesting and a way to organize dumb users for debugging/edu/user docs/ergonomics mars On Wed, Jun 8, 2011 at 11:13 AM, MALIK Julien julien.ma...@c-s.fr wrote: Hello, Do you know about Sikuli ? http://sikuli.org/ I never tested it, but it seems very nice for the black box testing, and can probably handle the automatic screenshot generation. Cheers, Julien Quoting Andrew Chapman andrew.chap...@donkagen.co.uk: I think that there are (at least) two different types of testing that are valuable for a project like QGIS and both play important roles. Different people use different names, but here's my version... 1) White box: This is very much in the hands of the developer and is aimed at proving the functionality of their code - stop the bug before it gets out of your own hands. This type of testing knows how the code should work and typically, among other things, explores the boundary conditions. 2) Black box: This has no special knowledge of how the internals works and tests as a dumb user... that can be relied on to provide the same test coverage every time. One obvious use of this is for regressions testing of the finished build, but I would suggest that with minor enhancements it could be used to help ease some of the user documentation tasks. QGIS supports multiple languages and operating systems, is released regularly but, consequently, it is hard to produce user manuals and tutorials with the most appropriate screen shots, etc. If a black box type of test harness were developed that could be trained (e.g. recording keystrokes and mouse commands with a way to edit them) plus the ability to capture images of screen objects (windows, dialogs, buttons, icons) and save them to named files, this would present further opportunities. The same test (script?) could be run on builds for different operating systems, languages and versions. A standard set of build specific images would be generated and, assuming standard file names and locations, could automatically be imported into the various user documents. There would still need to be some manual text editing, but the labour intensive screenshot processing would be removed. This must be a common requirement across projects, has anyone come across any tools that already exist? Andrew Chapman ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer This message was sent using IMP, the Internet Messaging Program. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: dealing with long primary keys / tests
Hi, Just a short remark , quoting one item of the must needed list posted by Paolo C. yesterday in the user list: automatic testing. In agile programming, you write the tests before implementing new features. Then you track the bugs at the source. Ideally, very few bugs hit the beta-testers (most remaining bugs are due to bugs in the automated tests). The users test what they are good at: they do usability tests only. In the very short term, developing new features is more costly, though. In the long term, everybody wins. Hence I would slightly modify Paolo's list from: - bigfixing - bugfixing ;) - automatic testing - polishing - infrastructure into - automatic testing - bugfixing - polishing - infrastructure (because if you test more, bugfixing becomes easier). Just my 2 cents on things to keep in mind IMHO. Thanks all for the wonderful work!!! Mayeul Le mardi 07 juin 2011 à 08:33 +0200, Andreas Neumann a écrit : Hi Jürgen, I think it is acceptable to apply this to trunk, even with the risk of breaking something major. At some point such bigger changes need to be tested. The current trunk is still young and far away from the release of version 1.8 or whatever the successor will be called. I'd be willing to test. +1 from me to try and apply the patch, given that it still works. Andreas On Mon, 6 Jun 2011 17:24:00 +0200, Jürgen E. Fischer wrote: Hi Andreas, On Mon, 06. Jun 2011 at 16:21:34 +0200, Andreas Neumann wrote: If this patch still works I would vote for applying it to trunk. It is sad that one cannot load data with long id integer primary keys. OSM is certainly an important enough community or data source to justify the application of this patch. Or would it require a lot of additional work besides applying and reviewing the patch? That's the question. IIRC the reason why I didn't apply the patch. Currently we don't have a feature id type so everything that is an int might actually be a feature id - that needs to by changed to 64bit. And that not only for variables and parameters, but also for signals and slots. The former case would be picked up by the compiler, but the latter case won't. So that needs quite an amount of testing. The patch is likely to not apply cleanly anymore, but even if it did - there might be new signals that it doesn't apply to yet. So that probably means we'd apply it, break qgis here and there, test and train to file redmine issues, git some more experience and end up with a fixed qgis that has support for 64bit keys. If that's ok, I'd revisit the issue. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: dealing with long primary keys
Hi, I suggest you try osm2postgresql, which converts bigint into int4 to be compatible with QGIS and works fine so far. To simplify rendering with QGIS, the osm2postgresql script sets up a PostgreSQL database, imports OSM data into it and process those data (including multi-polygons with holes). However, I've seen on the OSM dev list that some threshold for the number of nodes will be reached soon and this might become an issue; if so, I will adapt the script to have a primary key as only nodes with tags are needed for rendering (in the structure created byosm2postgresql, there is a table called nodes_with_tags, aimed at this). See: http://wiki.openstreetmap.org/wiki/Osm2postgresql Hope this helps, Mayeul Le dimanche 05 juin 2011 à 03:02 -0700, wambacher a écrit : there are a lot of openstreetmap-databases in the world and all of them can't be used by qgis. Regards walter ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] release of 1.7 (+1 for beta)
Hi, I agree with Paolo's concerns, and I also believe that ordinary users can benefit from testing the 1.7.0. In addition, they may find a few more blocking bugs... which ultimately may help the community provide an even better version. So +1 for a beta release. Mayeul Le mardi 31 mai 2011 à 10:42 +0200, Werner Macho a écrit : wow +1 for me on that .. a really good idea .. beta + call for funding to solve last bugs .. in that way some companys will probably see that there is a lot of work and time invested in opensource and it would be nice to bring us all ahead by supporting qgis .. we do not have licence issues :) regards Werner On Tue, May 31, 2011 at 10:29 AM, Sandro Santilli s...@keybit.net wrote: On Tue, May 31, 2011 at 06:23:49PM +1000, Nathan Woodrow wrote: I think releasing as a beta would be a good idea, that way we get 1.7 release out but users know it's not fully done. This way it also gives us more time to do bug fixing. I agree with this. A beta would be fine, possibly released with a call for funding targetted at closing up the blockers. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.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
[Qgis-developer] Hey! ticket or mailing list when gdal packaging breacks QGIS?!
Hi guys, I was asked by Giovanni to open a ticket probably because he believed the qgis-developer list was not the right place to discuss this issue, and Jurgen closes it because it's invalid and trac is not the right place to discuss this issue. What is the right place to discuss gdal packaging breacking QGIS on Ubuntu, shortly before release? please open a ticket (if not already). cheers -- Giovanni -- http://trac.osgeo.org/qgis/ticket/3830 Comment: Looks like a problem with GDAL packaging in the [http://trac.osgeo.org/ubuntugis ubuntugis] repository. [jef] I mentioned this first on qgis-developer: no tiff support anymore in Ubuntu 11.04 (Natty) Date: Sun, 15 May 2011 14:18:08 +0200 And several users from qgis-user are waiting for an answer. Thanks! Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: Problem with tiff (cannot open tiff in Ubuntu 11.04)
Hi, I mentioned that Ubuntu users cannot open tiffs anymore, on the dev mailing list 2 days ago [1]. Let's hope someone there knows how to solve this! Mayeul [1] see: http://osgeo-org.1803224.n2.nabble.com/gdal-1-8-0-no-tiff-support-anymore-in-Ubuntu-11-04-Natty-tc6365327.html Le mardi 17 mai 2011 à 15:13 +0100, Hugo a écrit : Hi all, Thanks for your comments. Edward, thanks for you directions but i really need to solve this issue and moreover i really enjoy QGIS/GRASS, and so, i want to keep up with it. The problem now is that i have several projects saved that no longer work with raster files (it really doesn't matter what size they have). When each project starts loading, i can see all the vectorial files being loaded correctly. But as soon as it gets to load any type of raster file QGIS just crashes ans shuts down. Launching QGIS from the terminal has give me the clue to what is wrong: the problem is with my libtiff version. I can see that i have libtiff 4.0 installed but QGIS is looking for libtiff3 (exactly what Giovanni has pointed out). Here is the terminal output: Error: GDAL Error 1: WARNING ! libtiff version mismatch : You're linking against libtiff 3.X but GDAL has been compiled against libtiff = 4.0.0 So my question is how can i fix this? Kind regards, Hugo On Tue, May 17, 2011 at 1:38 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: On Tue, 2011-05-17 at 12:45 +0100, Hugo wrote: Just to give software context i'm on Ubuntu 10.10 64 bits, using Qgis 1.6 and GDAL 1.7. Hi Hugo, here with Ubuntu 10.04 32bit and the ubuntugis repository (qgis 1.6) no problems. I added a bunch of overviews before opening the raster file, in any case no crashes. On the other hand I have problems opening rasters (not only yours) if I upgrade to trunk with the nightly builds repository. But this is probably caused by a mix of libraries from the standard ubuntu repository and the ubuntugis one. Cheers -- Giovanni -- -- Hugo Martins LabNT - ISEGI UNL Campus de Campolide 1070-312 Lisboa N 38°43'56.84, W 9°9'35.74 ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] Re: Problem with big tiff
Hi Alex, Thanks a lot! Yes you point to two of my problems, I had first problem with one of my qgis and another with another qgis: 1) The problem I cannot solve is to compile myself qgis 1.7.0rc knowing that the gdal I have was upgraded to 1.8.0. Could you please tell me if you know how to switch back to get gdal 1.7.0 and compile against it? As I wrote earlier, I detailed the error messages and pointed to my install script in qgis-developer list, here: http://osgeo-org.1803224.n2.nabble.com/gdal-1-8-0-no-tiff-support-anymore-in-Ubuntu-11-04-Natty-tc6365327.html 2) The other problem that I somehow solved: I compiled one version a few weeks ago against gdal 1.7.0; when updating to gdal 1.8.0, I was proposed to remove gdal 1.7.0, I did it, which broke this qgis (I could not find back the right package again; I copied libgdal1.7.0.so.1 from another machine which is still on Ubuntu 10.10, this solves the issue) Thanks a lot for your support! Mayeul Le mardi 17 mai 2011 à 13:47 -0700, Alex Mandel a écrit : That error message seems to have some good clues. Did you recently run ubuntu's update tool? I would open synaptic and go the the libtiff package and see which versions are available to you. I wonder if you self compiled or grabbed a gdal version that wasn't from ubuntu or ubuntugis, so check what options you have for the libgdal package. Note: Ubuntugis just pushed QGIS 1.6 built against GDAL 1.8 if you want to try that. I checked both my 32 and 64 bit 10.04 installs and my libtiff is from lucid-updates and is version 3.9.2-2 which works fine with libgdal 1.8 or 1.7 from ubuntugis. Thanks, Alex On 05/17/2011 07:13 AM, Hugo wrote: Hi all, Thanks for your comments. Edward, thanks for you directions but i really need to solve this issue and moreover i really enjoy QGIS/GRASS, and so, i want to keep up with it. The problem now is that i have several projects saved that no longer work with raster files (it really doesn't matter what size they have). When each project starts loading, i can see all the vectorial files being loaded correctly. But as soon as it gets to load any type of raster file QGIS just crashes ans shuts down. Launching QGIS from the terminal has give me the clue to what is wrong: the problem is with my libtiff version. I can see that i have libtiff 4.0 installed but QGIS is looking for libtiff3 (exactly what Giovanni has pointed out). Here is the terminal output: Error: GDAL Error 1: WARNING ! libtiff version mismatch : You're linking against libtiff 3.X but GDAL has been compiled against libtiff = 4.0.0 So my question is how can i fix this? Kind regards, Hugo On Tue, May 17, 2011 at 1:38 PM, Giovanni Manghi giovanni.man...@gmail.comwrote: On Tue, 2011-05-17 at 12:45 +0100, Hugo wrote: Just to give software context i'm on Ubuntu 10.10 64 bits, using Qgis 1.6 and GDAL 1.7. Hi Hugo, here with Ubuntu 10.04 32bit and the ubuntugis repository (qgis 1.6) no problems. I added a bunch of overviews before opening the raster file, in any case no crashes. On the other hand I have problems opening rasters (not only yours) if I upgrade to trunk with the nightly builds repository. But this is probably caused by a mix of libraries from the standard ubuntu repository and the ubuntugis one. Cheers -- Giovanni -- ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: Problem with tiff (cannot open tiff in Ubuntu 11.04)
Ticket opened here: http://trac.osgeo.org/qgis/ticket/3830 no tiff support in Ubuntu 11.04 with ubuntugis gdal (1.8.0) Mayeul Le mardi 17 mai 2011 à 22:06 +0100, Giovanni Manghi a écrit : On Tue, 2011-05-17 at 22:02 +0200, Mayeul Kauffmann wrote: Hi, I mentioned that Ubuntu users cannot open tiffs anymore, on the dev mailing list 2 days ago [1]. Let's hope someone there knows how to solve this! please open a ticket (if not already). cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] gdal 1.8.0 / no tiff support anymore in Ubuntu 11.04 (Natty)
Hi, libgdal1-dev for Natty provides gdal 1.8.0 which seems not compatible with the code base or some package (does the code links to libtiff 3.X ?) I'm trying to open a geotif from latest Quantum-GIS-3eb0d66 (release-1_7_0 downloaded today at 13h08m43s). It tells me: /path/file.tif is not a valid or recognized data source WARNING ! libtiff version mismatch : You're linking against libtiff 3.X but GDAL has been compiled against libtiff = 4.0.0 The guys from orfeo toolbox seems to have the same issue since about 11th of May, when gdal 1.8 debian package has been pushed to ubuntugis-unstable repository for all ubuntu versions. The consequence being the otb packages cannot open a TIFF any more. See: http://bugs.orfeo-toolbox.org/view.php?id=296 Installed is: libtiff4-dev (3.9.4-5ubuntu6) The only non standard repositories that I use are those 3: deb http://extras.ubuntu.com/ubuntu natty main #Third party developers repository deb http://qgis.org/debian-nightly natty main deb-src http://qgis.org/debian-nightly natty main I installed qgis following the INSTALL guide, and my following home-made script to automate downloading and compile: http://www.qgis.org/wiki/Talk:Building_QGIS_from_Source Other related link (with posts from Andreas Neumann) which mentions the problem of code linking to libtiff 3.x (not sure whether it is relevant): http://osgeo-org.1803224.n2.nabble.com/gdal-dev-mod-python-issue-with-libtiff-td5639239.html Anybody Natty user managed to compile latest release-1_7_0 this weekend after doing an apt-get update upgrade and dist-upgrade? Thanks, Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] OSM viewer plugin / map unit bug in core when lat-long
Hi, In fact the issues 1)a,b,c,d are OK in the latest plugin (sorry). Still there are two main problems left, the roundabout issue plus a bug in base code (see http://trac.osgeo.org/qgis/ticket/3825) 1h. (that I forgot to mention): OSM plugin imports data as lat-long, but while using map unit for the symbology the minimum value authorized by QGIS is 0.01 degree (about 800 meters at longitude 45) which is much too wide for any regional or city map, even for motorways. Working with map units is the best way to have continuous zoom, and this is what I most often do in my styles (hence with metric projection only). So to have nice symbology with the OSM plugin, we need to reproject the data (UTM) or to fix above bug (would be better). I guess changing the map unit maximum resolution should be trivial... but this need to be done in QGIS 1.7.0 as rules-based renderer in main 1.8.0 does not have support for symbol levels. Is there any interest from authorized committers to support/implement this kind of code change in 1.7.0? (Working on the 1g), 2) and 3) steps can be done manually by the final user, but automatizing this would be nice). Thanks for your feedback! Mayeul Le jeudi 12 mai 2011 à 23:44 +0200, Mayeul Kauffmann a écrit : Hi, I would like to ask those interested in OSM viewing with QGIS, to contribute to an improved QGIS viewer of OpenStreetMap data, in form of a python plugin and, if needed, some modification in the trunk. Recently I received several private emails asking me to share my experience and/or files related to viewing OpenStreetMap data in QGIS. One image is worth a thousand words... I have just put 5 improved renderings of OSM data here: http://www.qgis.org/wiki/OpenStreetMap_data_rendered_with_QGIS It uses the rule-based renderer (which just received support of symbol levels in 1.7.0) and osm2postgresql. More details on the method used here: http://www.qgis.org/wiki/Using_OpenStreetMap_data The roadmap could be as follows: 1. Slightly modify the existing plugin as follows: 1a. while opening an .osm file, store the data in a format (let's assume spatialite, but could be other type) that allows long strings (shp/dbf have a 254 characters limitation) 1b. in the spatialite files, store in a single field named tags all the concatenated tags for each feature. Should look like this: access=private, amenity=parking, parking=underground This example is how I manage this node: http://www.openstreetmap.org/browse/node/989971901 (The comma can be replaced by any separator, even a space; comma is for readability for humans). (Optionally here, we can drop the following tags: source, modified_by, edited_with and the like. The shorter, the best performance and the smaller the files). 1c. remove all points that are left with no tags after dropping these tags (those are just vertices or noise) 1d. store the name tag in a name field (for labelling). 1e. do not store roundabouts as polygons but as ways (this is the most common problem generated by the plugin when assuming that closed ways are polygons; this is impossible to have a nice rendering of polygonized roundabouts). 1f. put the required layers in a single group layer 1g. automatically apply a set of .qml files The alternative to the above (1) is to use my osm2postgresql bash script (this requires a linux box; the script installs the server if not done yet; one of its advantages is correct management of polygons with holes and good performance at the country level). 2. Distribute the .qml files I created with the plugin or with QGIS (no idea of what is best) 3. Distribute with the plugin or with QGIS the icons I generated (no idea of what is best). (Optionally: ask [again] SJJB management icon authors to backport svg bug fixes and share related bash scripts) Ideally: for 2 and 3, think of how people would contribute their alternative OSM rendering using the QGIS OSM plugin. I would really appreciate collaboration of at least one python developer for (1-2-3), and [if needed] of a QGIS core developer for (2) and (3). I have very little experience with QGIS python plugins. Since I do this on my spare time only (to prepare my hiking maps), without help this will take ages and I have little personal interest in doing so (it already works on my machine, so...). Also, I could put my .qml on rapidshare, my .svg on openclipart and my bash script to create the svg on the qgis wiki... but I won't, since those solutions add a lot of hassle in data and code management and do not deliver what I would like to contribute to: Fast, easy and beautiful on the fly rule-based rendering of OSM maps Cf. http://trac.osgeo.org/qgis/ticket/3222 I would like to spend time improving the symbology rather than coding the above 1, 2 and 3, hence my question: anybody interested in contributing to an improved QGIS OSM viewer plugin? Thanks for reading, and thanks
[Qgis-developer] OSM viewer / sample styles online
Hi, I've put online a sample .qgs project file with OSM dataset and advanced/multi-scale qml styling (for 1.7.0 only), mainly ways, for Monte Lema (on Italian/Swiss border): http://www.mediafire.com/?jiooxkbmyzgr0 (File: OSM_Lema.zip) The svg are harder to package and I have not updated this online (I must dig for them and do not know what instructions to give for linking them) so nodes will not be displayed well and I do not know what will happen with ways with svg markers. Additionally, some complex polygons were not correctly converted from postgis to sqlite, but I attached what I could. DEM and contour lines are much bigger, so not attached. Hence this is more for you to see the technical organisation than the final rendering, which you can see here: http://www.qgis.org/wiki/OpenStreetMap_data_rendered_with_QGIS Hopefully a slightly modified OSM plugin will make this work in one click! I used osm2postgresql to produce the original dataset. Regards, Mayeul PS: For now, those styles and derived works are (c) Mayeul Kauffmann CC-by-SA (similar to OSM maps and data). If this goes to the trunk, I'll re-release with a more permissive licence if needed. I have already released all the icons I created for this in the public domain. MK Le samedi 14 mai 2011 à 12:02 +0200, Mayeul Kauffmann a écrit : Hi, In fact the issues 1)a,b,c,d are OK in the latest plugin (sorry). Still there are two main problems left, the roundabout issue plus a bug in base code (see http://trac.osgeo.org/qgis/ticket/3825) 1h. (that I forgot to mention): OSM plugin imports data as lat-long, but while using map unit for the symbology the minimum value authorized by QGIS is 0.01 degree (about 800 meters at longitude 45) which is much too wide for any regional or city map, even for motorways. Working with map units is the best way to have continuous zoom, and this is what I most often do in my styles (hence with metric projection only). So to have nice symbology with the OSM plugin, we need to reproject the data (UTM) or to fix above bug (would be better). I guess changing the map unit maximum resolution should be trivial... but this need to be done in QGIS 1.7.0 as rules-based renderer in main 1.8.0 does not have support for symbol levels. Is there any interest from authorized committers to support/implement this kind of code change in 1.7.0? (Working on the 1g), 2) and 3) steps can be done manually by the final user, but automatizing this would be nice). Thanks for your feedback! Mayeul Le jeudi 12 mai 2011 à 23:44 +0200, Mayeul Kauffmann a écrit : Hi, I would like to ask those interested in OSM viewing with QGIS, to contribute to an improved QGIS viewer of OpenStreetMap data, in form of a python plugin and, if needed, some modification in the trunk. Recently I received several private emails asking me to share my experience and/or files related to viewing OpenStreetMap data in QGIS. One image is worth a thousand words... I have just put 5 improved renderings of OSM data here: http://www.qgis.org/wiki/OpenStreetMap_data_rendered_with_QGIS It uses the rule-based renderer (which just received support of symbol levels in 1.7.0) and osm2postgresql. More details on the method used here: http://www.qgis.org/wiki/Using_OpenStreetMap_data The roadmap could be as follows: 1. Slightly modify the existing plugin as follows: 1a. while opening an .osm file, store the data in a format (let's assume spatialite, but could be other type) that allows long strings (shp/dbf have a 254 characters limitation) 1b. in the spatialite files, store in a single field named tags all the concatenated tags for each feature. Should look like this: access=private, amenity=parking, parking=underground This example is how I manage this node: http://www.openstreetmap.org/browse/node/989971901 (The comma can be replaced by any separator, even a space; comma is for readability for humans). (Optionally here, we can drop the following tags: source, modified_by, edited_with and the like. The shorter, the best performance and the smaller the files). 1c. remove all points that are left with no tags after dropping these tags (those are just vertices or noise) 1d. store the name tag in a name field (for labelling). 1e. do not store roundabouts as polygons but as ways (this is the most common problem generated by the plugin when assuming that closed ways are polygons; this is impossible to have a nice rendering of polygonized roundabouts). 1f. put the required layers in a single group layer 1g. automatically apply a set of .qml files The alternative to the above (1) is to use my osm2postgresql bash script (this requires a linux box; the script installs the server if not done yet; one of its advantages is correct management of polygons with holes and good performance at the country level). 2. Distribute the .qml files I
[Qgis-developer] Contributions for improved QGIS OSM viewer plugin
Hi, I would like to ask those interested in OSM viewing with QGIS, to contribute to an improved QGIS viewer of OpenStreetMap data, in form of a python plugin and, if needed, some modification in the trunk. Recently I received several private emails asking me to share my experience and/or files related to viewing OpenStreetMap data in QGIS. One image is worth a thousand words... I have just put 5 improved renderings of OSM data here: http://www.qgis.org/wiki/OpenStreetMap_data_rendered_with_QGIS It uses the rule-based renderer (which just received support of symbol levels in 1.7.0) and osm2postgresql. More details on the method used here: http://www.qgis.org/wiki/Using_OpenStreetMap_data The roadmap could be as follows: 1. Slightly modify the existing plugin as follows: 1a. while opening an .osm file, store the data in a format (let's assume spatialite, but could be other type) that allows long strings (shp/dbf have a 254 characters limitation) 1b. in the spatialite files, store in a single field named tags all the concatenated tags for each feature. Should look like this: access=private, amenity=parking, parking=underground This example is how I manage this node: http://www.openstreetmap.org/browse/node/989971901 (The comma can be replaced by any separator, even a space; comma is for readability for humans). (Optionally here, we can drop the following tags: source, modified_by, edited_with and the like. The shorter, the best performance and the smaller the files). 1c. remove all points that are left with no tags after dropping these tags (those are just vertices or noise) 1d. store the name tag in a name field (for labelling). 1e. do not store roundabouts as polygons but as ways (this is the most common problem generated by the plugin when assuming that closed ways are polygons; this is impossible to have a nice rendering of polygonized roundabouts). 1f. put the required layers in a single group layer 1g. automatically apply a set of .qml files The alternative to the above (1) is to use my osm2postgresql bash script (this requires a linux box; the script installs the server if not done yet; one of its advantages is correct management of polygons with holes and good performance at the country level). 2. Distribute the .qml files I created with the plugin or with QGIS (no idea of what is best) 3. Distribute with the plugin or with QGIS the icons I generated (no idea of what is best). (Optionally: ask [again] SJJB management icon authors to backport svg bug fixes and share related bash scripts) Ideally: for 2 and 3, think of how people would contribute their alternative OSM rendering using the QGIS OSM plugin. I would really appreciate collaboration of at least one python developer for (1-2-3), and [if needed] of a QGIS core developer for (2) and (3). I have very little experience with QGIS python plugins. Since I do this on my spare time only (to prepare my hiking maps), without help this will take ages and I have little personal interest in doing so (it already works on my machine, so...). Also, I could put my .qml on rapidshare, my .svg on openclipart and my bash script to create the svg on the qgis wiki... but I won't, since those solutions add a lot of hassle in data and code management and do not deliver what I would like to contribute to: Fast, easy and beautiful on the fly rule-based rendering of OSM maps Cf. http://trac.osgeo.org/qgis/ticket/3222 I would like to spend time improving the symbology rather than coding the above 1, 2 and 3, hence my question: anybody interested in contributing to an improved QGIS OSM viewer plugin? Thanks for reading, and thanks in advance for any answer! Regards, Mayeul PS: If we can do the above and test it with the QGIS web client, we could do a killer demo at the OSM state of the map conference in Vienna this summer, something like: Create your Customized Slippy Map in 10 Minutes with QGIS. MK ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] How to get a string's english translation with pyhton?
Hi, Just to help those who might help Ricardo: The plugin ProfileFromLine works only in English, not in other languages. The buggy python lines are around here: http://hub.qgis.org/projects/profilefromline/repository/revisions/master/entry/ProfileFromLine.py#L254 if out of extent in strValue or null not in strValue: rasterValue = float(strValue) The bug is described here: http://hub.qgis.org/issues/27#note-2 Mayeul Le dimanche 08 mai 2011 à 23:31 +0100, Ricardo Filipe Soares Garcia da a écrit : Hello list in order to identify pixel values I'm using QgsRasterLayer.identify() This method returns a tuple, with first value being a boolean (by the way, see ticket[1] on trac). The second value is a dictionary with band names as keys and pixel value. I want to check for the pixel value and, in case it is null or out of extents, I want to assign a value to some variable. I am testing the pixel value for the presence of out of extent and null strings. This works OK when the user is using an english locale. When the locale is different, these strings show up translated and my code fails miserably. How can I solve this problem? I'd like to be able to get the english version of the string independently of the locale being used by the user. Thanks [1] - https://trac.osgeo.org/qgis/ticket/3807 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] update pull request
Hi, I do not know either what I good practice, but now that a new commit has been done on the branched 1_7_0 I have now idea how to propagate this in the pull request. I would have created a new personal repository forking the main one and started from zero, but since it is not possible to download a single branch, downloading all takes hours for me, so their might be another commit in the mean time... this way I will never catch up. So for the moment the easy way I found was to post a new patch here: http://trac.osgeo.org/qgis/attachment/ticket/3222/ (@Tim: it now uses relative paths) Patch on freshly branched 1_7_0 https://github.com/qgis/Quantum-GIS/commit/6c835b4cf5cd4a4be687e829bb57e3d51e7345f7 taking into accounts jef's comments at https://github.com/qgis/Quantum-GIS/pull/3 Would it be fine for you to work with this? I wish also to thank you for the hints you already gave me for improving my code. All the best, Mayeul Le vendredi 06 mai 2011 à 23:03 +0200, Mayeul Kauffmann a écrit : Hi Jürgen, Thanks a lot for the detailed answer!! Sorry to have bothered you; I agree standardizing indentation can be useful [in fact, it does not make merging more difficult but easier: if indentation is standardized before each commit, nobody will never ever have to merge indentation]. But it's to late for that in your case anyway, as you've already committed. I would have forked the new 1_7_0 again, applied my patch here, taken into account your comment, run the indentation tool, committed, pushed, and made another pull request. Then I would have deleted my other fork (is this good practice?) I will now work on your comments. Regards, Mayeul ___ 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] update pull request
Hi, Thanks all for your hints. Still, I could not find a way to make those changes on existing branch and on the pull request #3, so I forked again and added a new pull request: https://github.com/qgis/Quantum-GIS/pull/7 In the meantime, there was a new commit in the 1_7_0 branch. (Yes, I know, it is simple to solve this but sorry, no, I'm not smart enough yet...). Sorry for those probably bad practices... Mayeul Le samedi 07 mai 2011 à 15:29 +0200, Sandro Santilli a écrit : On Sat, May 07, 2011 at 12:40:18PM +0200, Mayeul Kauffmann wrote: I would have created a new personal repository forking the main one and started from zero, but since it is not possible to download a single branch, downloading all takes hours for me, so their might be another commit in the mean time... this way I will never catch up. There's no problem importing changes from upstream, git pull merges them in. Optionally the --rebase switch acts like if you created patches for your changes, updated the repository to upstream, and re-applied those patches. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] update pull request
Hi, Thanks a lot Tim for the detailed commands! Will be useful for next time. While searching for documentation, I found several very good diagrams (including the one on the qgis wiki): http://osteele.com/archives/2008/05/commit-policies http://blog.interlinked.org/tutorials/git.html http://www.google.com/search?q=site:book.git-scm.comum=1ie=UTF-8tbm=isch from http://book.git-scm.com/ The most detailed graphic cheat sheet I found is here: http://panela.blog-city.com/update_of_git_supervisual_cheatsheet.htm But on the project page you find an even more detailed svg a python script (I could not make it work, though, even after sudo easy_install pysvg) I have added the first two of those here: http://www.qgis.org/wiki/Using_Git By the way, I also corrected the code formatting for braces in the, er..., editing section of the good formatting example at: http://www.qgis.org/wiki/Developers_Manual#Editing (should we run astyle on code extracts in the wiki? ;-) ) Hope this helps, Mayeul Le samedi 07 mai 2011 à 18:28 +0200, Tim Sutton a écrit : Hi On Sat, May 7, 2011 at 6:03 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi, Thanks all for your hints. Still, I could not find a way to make those changes on existing branch and on the pull request #3, so I forked again and added a new pull request: Ok no need to refork, you can just do (in your local repo): git remote add qgis-upstream git://github.com/qgis/Quantum-GIS.git git fetch qgis-upstream git branch --track release-1_7_0 origin/release-1_7_0 git checkout release-1_7_0 git pull qgis-upstream release-1_7_0 git push origin release-1_7_0 That will pull any changes from qgis repo and push them up to your clone of it. Obviously you need to commit any fixes you made in response to the comments and push those too. Then just issue a new pull request and cancel the old one. I will write up some working practice docs in CODING soon I promise :-) Regards Tim https://github.com/qgis/Quantum-GIS/pull/7 In the meantime, there was a new commit in the 1_7_0 branch. (Yes, I know, it is simple to solve this but sorry, no, I'm not smart enough yet...). Sorry for those probably bad practices... Mayeul Le samedi 07 mai 2011 à 15:29 +0200, Sandro Santilli a écrit : On Sat, May 07, 2011 at 12:40:18PM +0200, Mayeul Kauffmann wrote: I would have created a new personal repository forking the main one and started from zero, but since it is not possible to download a single branch, downloading all takes hours for me, so their might be another commit in the mean time... this way I will never catch up. There's no problem importing changes from upstream, git pull merges them in. Optionally the --rebase switch acts like if you created patches for your changes, updated the repository to upstream, and re-applied those patches. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Hi, I like versioning systems so learning a new one is interesting. The paradoxal point with this github is as follows: (+) One of the idea is to let non-core developers contribute (make commits... in their branch only) in an easy way. I love the github tool that shows you which branch will merge easily with yours... (well, I love it when it's green). That's great. (-) Less experienced developers are not allowed to commit to the trunk because... they are less experienced; that's OK. But in the meantime, IMHO they are required to have a better understanding of git than what is required to commit directly to the main repository. Still, probably the (+) is bigger than the (-). I saw the same doubts in teams migrating from cvs to svn, and none of them wish to go back. Just my 2 cents. Mayeul Le samedi 07 mai 2011 à 11:31 -0500, William Kyngesburye a écrit : Is this git thing on? Questions and confusion. Is there a git guide for dummies? I found http://www.qgis.org/wiki/Using_Git but it seems overly complex. I just want to do like I've done with svn - check out/update, make changes, and commit the changes. 3 steps. Git checkout itself looks complex, let alone committing a change. ...Sorry if I seem a bit resistant. Are users migrated to git? Or do I need to register with github and ask for commit access? How long until 1.7 release? I would like to do the workaround for http://trac.osgeo.org/qgis/ticket/3497 before release, and check over the Mac install/build instructions. On May 2, 2011, at 10:16 AM, Tim Sutton wrote: If you are interested in the git migration, you can test and play around with it here: http://github.com/qgis/Quantum-GIS You can go ahead and fork it and see if everything works ok for you. If we encounter any major issues, we may need to trash and repopulate it so please don't consider it production ready yet. I made detailed notes on the migration for anyone interested here: http://linfiniti.com/2011/05/some-notes-on-the-great-migration-qgis-svn-to-git/ If any git experts notice anything untoward with my procedures please feel free to suggest better working practices. I'll give it a couple of days and if nobody has any major issues, we can start to use that as our canonical repository. Next we will start to work on the trac - redmine migration (and svn commitlog - git commitlog in redmine). If anyone has particular expertise in these (especially the latter), please feel free to volunteer your services. The other directories (code examples etc under svn trunk) I will migrate after the release has gone out. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == 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. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ 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] using indentation scripts
Hi jef and all, I guess it's better to have this discussion here than on a comment of line 351 of src/core/symbology-ng/qgsrendererv2.cpp at https://github.com/qgis/Quantum-GIS/pull/3/files#r26150 Probably it would help other people (Is everybody already always using the indentation scripts? If yes, I should get many answers, if not, please read one of today's commits: If you plan to contribute you should reindent with scripts/prepare-commit.sh (using 'our' astyle)). Jef, you wrote that the reason I could not use the indentation scripts should be fixed in SHA: 86bcdc4bac26a28c1a25 Thanks for the hint! Sorry, but I do not understand from the above what to do. Looking in qgis github for the above code, I arrived here https://github.com/qgis/Quantum-GIS/commits/master I found this, whose code name is similar to the above: https://github.com/qgis/Quantum-GIS/commit/86bcdc4bac26a28c1a25adf0ad088390c3bd16d3 Should I take the CMakeLists.txt from the above, replace mine and start again? Still I found another of your commits that contains much more changes related to astyle: https://github.com/qgis/Quantum-GIS/commit/dcc723c067a795b240247754817c3c21abdffc28 Tim: you said I should use git as this would be easier than sending a new patch file, but now I see that the 1_7_0 branch lacks the correct files to do the indentation. So should I ask a pull request to port the two above-mentioned commits into 1_7_0 ??! Or fork 1_7_0 into my branch, merge the above into my branch (no idea how to do this with git), re-indent the new code, undo the previous merge (so that it does not propagate to 1_7_0), commit this to my branch and request another pull?! I guess the whole point of branching to 1_7_0 just before migrating to git is to have a faster release (let people learn git on master). Currently, the 1_7_0 branch is not ready for indenting scripts with git, should that be mandatory? I do not mind trying, but I need some more guidance here. I tried to modify the prepare-commit.sh script to give it the list of files to re-indent but it failed. Any hint on how to do this? Thanks. Jef, you wrote: our version of astyle is built in scripts/ Yes, I saw this and wrote that it puzzles me. Let me put it differently: from where should I run the script ( my `pwd`) and with which option (I saw the PATH hack) to have it find the astyle.sh which is in the folder. Thanks a lot! Mayeul PS: Better to discuss this here for another reason: the hash code in the from/reply to messages sent by git scared my wife ;-) (well, now I redirect them in another folder for sake of her heart). MK - Mail Original - De: Mayeul Kauffmann mayeul.kauffm...@free.fr À: jef-n reply+p-26150-dcf470ddf5342821ac35239d6bd69865a2dbd...@reply.github.com Cc: qgis-developer qgis-developer@lists.osgeo.org Envoyé: Jeudi 5 Mai 2011 23h49:20 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [Qgis-developer] using indentation scripts Hi Jef, Following your comments on indentation in my patch, I tried to use prepare-commit.sh for more than one hour in vain. When applied after git commit it says nothing has changed (in effect, after commit, my working copy is ahead). So I created a new branch locally to restart from scratch, reapplied my patch, tried the script, in vain again. The best I get is: Unable to determine upstream SVN information from working tree history The only help I could find is a few lines on the following page: http://www.qgis.org/wiki/Developers_Manual#Coding_Style There is a scripts/prepare-commit.sh that looks up the changed files and reindents them using astyle. This should be run before committing. As newer versions of astyle indent differently than the version used to do a complete reindentation of the source, the script uses an old astyle version, that we include in our repository. I had to guess by reading the source code of the script that I needed to install flip (and astyle?), and pass the path to the project as first parameter, but I could not find any documentation on this. Should the script be run form the root folder? Should I install astyle or not? (the comment above on the astyle versions puzzles me). Finally the following command took 10 minutes: cd /hometb/mk/sig/dev/release-1_7_0-4May/Quantum-GIS ./scrips/prepare-commit.sh . before telling me: Unable to determine upstream SVN information from working tree history I tried from several places with relative or absolute path, in vain. So I tried to follow this advice on the same wiki: There is a .indent.pro file in the QGIS src directory that contains the switches to be used when indenting code using the GNU indent program. If you don't use GNU indent, you should emulate these settings. So I installed GNU indent... but could not find the .indent.pro file in the QGIS src directory. What indent options should I use? If I cannot make scrips/prepare-commit.sh work, I do not mind formatting my code manually, but which
Re: [Qgis-developer] using indentation scripts / update pull reques
Hi Jürgen, Thanks a lot for the detailed answer!! Sorry to have bothered you; I agree standardizing indentation can be useful [in fact, it does not make merging more difficult but easier: if indentation is standardized before each commit, nobody will never ever have to merge indentation]. But it's to late for that in your case anyway, as you've already committed. I would have forked the new 1_7_0 again, applied my patch here, taken into account your comment, run the indentation tool, committed, pushed, and made another pull request. Then I would have deleted my other fork (is this good practice?) I will now work on your comments. Regards, Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] using indentation scripts
Hi Jef, Following your comments on indentation in my patch, I tried to use prepare-commit.sh for more than one hour in vain. When applied after git commit it says nothing has changed (in effect, after commit, my working copy is ahead). So I created a new branch locally to restart from scratch, reapplied my patch, tried the script, in vain again. The best I get is: Unable to determine upstream SVN information from working tree history The only help I could find is a few lines on the following page: http://www.qgis.org/wiki/Developers_Manual#Coding_Style There is a scripts/prepare-commit.sh that looks up the changed files and reindents them using astyle. This should be run before committing. As newer versions of astyle indent differently than the version used to do a complete reindentation of the source, the script uses an old astyle version, that we include in our repository. I had to guess by reading the source code of the script that I needed to install flip (and astyle?), and pass the path to the project as first parameter, but I could not find any documentation on this. Should the script be run form the root folder? Should I install astyle or not? (the comment above on the astyle versions puzzles me). Finally the following command took 10 minutes: cd /hometb/mk/sig/dev/release-1_7_0-4May/Quantum-GIS ./scrips/prepare-commit.sh . before telling me: Unable to determine upstream SVN information from working tree history I tried from several places with relative or absolute path, in vain. So I tried to follow this advice on the same wiki: There is a .indent.pro file in the QGIS src directory that contains the switches to be used when indenting code using the GNU indent program. If you don't use GNU indent, you should emulate these settings. So I installed GNU indent... but could not find the .indent.pro file in the QGIS src directory. What indent options should I use? If I cannot make scrips/prepare-commit.sh work, I do not mind formatting my code manually, but which guidelines? The manual only says Tab spacing should be set to 2 spaces and Braces should start on the line following the expression, which I tried to follow. I do not mind to try and emulate these settings, if I know where to look for. Still, thank you jef for you comments on coding style and other hints. Could you please give me some hints on how to solve the above indentation problem? Thanks a lot in advance! Mayeul jef-n wrote at https://github.com/qgis/Quantum-GIS/pull/3/files#r26150 : @@ -348,7 +348,7 @@ QgsFeatureRendererV2* QgsFeatureRendererV2::load( QDomElement element ) QgsFeatureRendererV2* r = m-createRenderer( element ); if ( r ) r-setUsingSymbolLevels( element.attribute( symbollevels, 0 ).toInt() ); - +r-setUsingFirstRule( element.attribute( firstrule, 0 ).toInt() ); use scripts/prepare-commit.sh please and braces here. See also: http://osgeo-org.1803224.n2.nabble.com/indentation-scripts-td3194208.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new ubuntu compile problem
Hi Marco, Myself I migrated to Ubuntu 10.10 and I had the python issue when building r15676 last Saturday but Martin hint (completely remove your build directory) solved the problem for me. My /etc/apt/sources.list contains the following: deb http://qgis.org/debian-nightly natty main deb-src http://qgis.org/debian-nightly natty main Do you use one of the followings? https://launchpad.net/~qgis/+archive/stable http://les-ejk.cz/ubuntu/ # GIS for Ubuntu deb http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu Does are some I tend to use in the past and that are now commented out in my sources.list Hope it helps. Good luck! Mayeul Le lundi 02 mai 2011 à 11:48 +0200, Martin Dobias a écrit : On Mon, May 2, 2011 at 11:40 AM, Marco Bernasocchi ma...@bernawebdesign.ch wrote: I would expect that you have maybe an incompatible version of sip generator and sip python module or something similar. Not sure though about the cause. I look into it tonite. But i guessed a similar cause. Is it correct that trunk needs sip api v 7? No. QGIS does not care about sip api version. That is an internal matter of SIP - it forbids running python modules using incompatible spi api version to protect users from misbehavior (or crashes) due to changes in SIP interals between incompatible sip releases. 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] Bug or problem under Mac, opening a raster tif
Hi, I cannot test on any of these 2 OSes, but just a hint (maybe): In menu Settings/options, CRS tab, there are 3 different options on what to do when a layer has no CRS. I would first check that they are identical on both your platforms. Mayeul Le mercredi 27 avril 2011 à 17:00 +0200, Patrice Vetsel a écrit : Using 1.6 or 1.7 15814. i have some problem with tif raster georeferenced with qgis extension under mac. Trying similar operations under Windows and Mac I noticed a problem. Project are set to WGS84 and fly reprojection activated (windows and mac) When I m adding a raster under georeferencing extension, Windows ask me for assigning a system projection for this raster , not under Mac. Regards Patrice Vetsel___ 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 Processing Framework
Le mercredi 27 avril 2011 à 20:46 +0200, Paolo Cavallini a écrit : Il giorno mer, 27/04/2011 alle 12.00 -0400, Camilo Polymeris ha scritto: Good point. SAGA, as far as I know, does not provide information on which parameters are considered basic and which are advanced. Perhaps a list of parameters considered advanced can be included with the plugin. Not very elegant, because it would be out-of-sync with SAGA, but practical. It is the same approach used in GRASS: in fact, it is better (even if not elegant, I agree) to be able to decide which options should be exposed as default, and which ones as advanced). In fact it would be also good to add a general option user/power user; in the first case only default options will be exposed, in the second the full options. +1 for the concept of a user/power user checkbox. You could call it Always show advanced options which is more neutral (does not make any judgement on the user) and describes exactly what it does. Would be great to have an Advanced options checkbox on each window anyway, to be able to switch their visibility on a case by case basis. In addition, where relevant (functions that use command-line tools or have command-line tools equivalent) and in advanced mode only, it would be great to have the GUI generate the command line corresponding to the options chosen in the GUI; the GUI would show this command line and let the user edit it (or run it as it is). There are many advantages: - the user knows exactly what is going to be executed; advanced QGIS users will be able to use the GUI but benefit from existing help targeted at the command-line users; debugging, sharing questions and ideas in a forum or saving/automating a frequent task is facilitated - you do not have to put very rare options in the GUI (power users can still add the options here when they need it, which should be rare). The idea is to partly bridge the gap between GUI and command line by having the advantages of both (GUI is often easier, command line is generally more powerful). This concept is used successfully in quite a variety of software; just to give a few names: - pgadmin (SQL preview of any schema modification) - vlc (save, convert broadcast functionalities) - R (a few functions of the default Rgui; the Rcommander GUI package)... Just my 2 cents. All the best for this work! Mayeul Again, SAGA provides no tag information. It would have to be generated programatically from library/module name description or provided in a list. Any thoughts on the GUI for that tree? More like SAGA's module tree or more like GIMP's filter menu? I don't think the search/filter/favorites/frequently used part is very hard.. but still, I will keep things simple. I think filtering is often the easiest option. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: [Qgis-user] QGIS Webclient checked in
Answering to my own question: http://www.qgis.org/pt/community/qgis-case-studies/uster-switzerland.html gives a link to a very nice set of live demos: http://gis.uster.ch/ Le samedi 23 avril 2011 à 01:29 +0200, Mayeul Kauffmann a écrit : Hi, Is there somewhere a live demo of QGIS Webclient, a screencast or some screenshots? thanks Mayeul Le vendredi 22 avril 2011 à 15:33 -0500, samuelm...@gmail.com a écrit : Thanks Andreas for this magnificent software, is interesting to see the QGIS's projects in the Web. Regards, Samuel Mesa. P.S:I attached a small contribution from the proposed translation file into Spanish. 2011/4/20 Andreas Neumann a.neum...@carto.net: Hi all, I initially checked in QGIS webclient. You can find the source at http://svn.osgeo.org/qgis/trunk/qgiswebclient/ I have to apologize upfront that I am at holidays until May 3. Until then I cannot answer questions regarding the web client. Pirmin Kalberer knows a bit about the client. If someone wants to translate, you can find the translation file at http://svn.osgeo.org/qgis/trunk/qgiswebclient/js/Translations.js There is a readme file containing some information about installation: http://svn.osgeo.org/qgis/trunk/qgiswebclient/readme.txt Andreas -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ 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] Re: [Qgis-user] QGIS Webclient checked in [translations]
Hi, I am currently working on the French translation. Moving this part of the discussion to the qgis-tr mailing list. Mayeul Le vendredi 22 avril 2011 à 15:33 -0500, samuelm...@gmail.com a écrit : Thanks Andreas for this magnificent software, is interesting to see the QGIS's projects in the Web. Regards, Samuel Mesa. P.S:I attached a small contribution from the proposed translation file into Spanish. 2011/4/20 Andreas Neumann a.neum...@carto.net: Hi all, I initially checked in QGIS webclient. You can find the source at http://svn.osgeo.org/qgis/trunk/qgiswebclient/ I have to apologize upfront that I am at holidays until May 3. Until then I cannot answer questions regarding the web client. Pirmin Kalberer knows a bit about the client. If someone wants to translate, you can find the translation file at http://svn.osgeo.org/qgis/trunk/qgiswebclient/js/Translations.js There is a readme file containing some information about installation: http://svn.osgeo.org/qgis/trunk/qgiswebclient/readme.txt Andreas -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ 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] how to add multipoint
Hi Paolo, Indeed! Not all buttons in the advance editing toolbar are available for all geometry types. With r 15754 and postgis as a backend: You cannot add a point to a multipoint feature (you can only add a new feature). You can move or delete one of its parts . You can copy a multipoint feature and paste it as a new multipoint feature. You cannot add a part to a multiline string (you can only add a new feature). You can move or delete one of its parts. You can copy a multiline feature and paste it as a new multiline feature. You can add and delete parts to multipolygon. (As a minor note, to delete a part of a multipolygon. you have to click on one of its vertice, which *might* be a problem if you have a set of contiguous (parts of) polygons). It is the responsibility of the backend to generate new id's when copy/pasting to avoid duplicates, e.g. with: ALTER TABLE test_multipoints ADD CONSTRAINT test_multipoints_pkey PRIMARY KEY(id); otherwise duplicated id's are created (which does not prevent most functions to work apparently). Hop it helps, Mayeul (PS: Tanti auguri!) Le vendredi 22 avril 2011 à 20:44 +0200, Paolo Cavallini a écrit : Hi all. If I'm not wrong, we can add parts to MULTIPOLYGONs, but not additional points to groups of MULTIPOINTs. If anyone confirms that I understood it correctly, I'll fill a ticket. Thanks. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS connections: take them from PgAdmin3?
Hi, I found the idea appealing and apparently quite simple to implement. On second thought, there are a few issues (nothing blocking, but some work): - If you have 30 databases on 3 local servers (e.g. dev, testing, prod) and only one of those databases has tables with spatial objects, you do not want to list them all in qgis. So you should be given the choice. - This relies on knowing where this pgadmin config file is. I guess it is in ~/pgadmin3 in most GNU/Linux box. Is the pgadmin config file stored in a predictable place in Windows? You should be given the possibility to choose your config file. - In any case this should be optional (you should be able to configure it manually, and you still need to give a password if you are not using a socket or another method of authentification). My 3 cents. Mayeul Le jeudi 21 avril 2011 à 22:26 +0200, Tim Sutton a écrit : Hi Sounds like a good idea Regards Tim On Wed, Apr 20, 2011 at 2:04 PM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. It seems interesting to load the connection settings for PostGIS from those in .pgadmin3 (or syncing them both), so the user should not repeat the config twice. Any major problem with that? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ 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] blocking issues
Hi, Thanks for the link! I started working on this. I will not remove the Must fix tag on my own, but already corrected priorities (incorrectly put as critical when in fact there is no crash nor data loss). I'm working mainly on stuff related to vector (and its symbology, legend and printing). If we prioritise on bug/patches (over enhancement) then we can use this report: http://trac.osgeo.org/qgis/query?status=assignedstatus=newstatus=reopenedmust_fix=Yesorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentmilestone=Version+1.7.0type=bugtype=patch Hope this helps. Mayeul Le samedi 16 avril 2011 à 20:26 +0200, Paolo Cavallini a écrit : Hi all. I think we should take seriously the 80 current blocking issues http://trac.osgeo.org/qgis/query?status=assignedstatus=newstatus=reopenedmust_fix=Yesorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentmilestone=Version+1.7.0report=16 My suggestion is to go through all of them, and either remove the Must fix tag, or postpone release until they are fixed. Opinions? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RuleBase - symbol levels don't persistent
Hi, Have look here: http://trac.osgeo.org/qgis/ticket/3222#comment:18 This is a known bug. I wrote a patch which will be reviewed by wonder. Mayeul Le dimanche 10 avril 2011 à 23:46 +0200, Andrea Peri a écrit : Hi, Using the qgis 1.7 r15690 If I try to set render using Rule Base and symbol level. It seem not saved when close the Layer-Properties windows. I open the windows properties and rule-base windows I add some rules and open the Symbol-levels. It is firstly disables so I check to set enable and set some level. After I click ok - ok and close the propeties-windows. But if I re-open the again I notice the symbol-level is disable again. I'm not sure if this is a bug or a missing functionality. -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ 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] Re: feature freeze: symbol levels in rule-based rendering / OSM
Hi, On top of the patch mentioned below, I made a patch implementing most of wonder's suggestion made at http://trac.osgeo.org/qgis/ticket/2832#comment:9 , namely switching first rule/all rules, enabling symbol levels. I tested it during one week on r15538 and release it against r15676. This gives new rendering possibilities with the rule-based renderer, including easy and beautiful on the fly rule-based rendering of OSM maps, with results similar to mapnik and osmarender. Mayeul Le lundi 21 mars 2011 à 23:06 +0100, Mayeul Kauffmann a écrit : Hi, Tim wrote: Mayeul we will apply this after we branch for release (probably around 1 april). Great! In the meantime, to test the compatibility of the symbol levels patch with commits made since r15217, I just proposed a patch against r15538 adding symbol levels in rule-based renderer (on top of r15217). It is a minimalist patch which adds a quick fix for symbol levels and a Priority column (instead of ID in previous patch) which is necessary to know what is the, er... priority of rules when symbol levels are used (since only first matched rule will be used). It's there: http://trac.osgeo.org/qgis/ticket/3222 patch_on_r15538-rbr_with_symbol_levels.diff I'm testing it and I'll put on trac any issue I might find. Regards, Mayeul Le samedi 19 mars 2011 à 09:40 +0200, Tim Sutton a écrit : Hi On Mon, Mar 14, 2011 at 10:22 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi all As Tim suggested to bring a patch to a developer's attention, I recall here what he suggested (and Marco's positive comment): to apply [my] patch to the release branch and keep trunk untouched. (In fact: it's Marco's patch proposed 7 months ago, see http://trac.osgeo.org/qgis/ticket/2832#comment:3 ) Mayeul we will apply this after we branch for release (probably around 1 april). Please remind me if you see the branch notice go out and you havent seen your patch applied. Regards Tim This does not prevent us to work towards SLD in the long term. Still, for now, all NG renderers (Single symbol, categorized, graduated) have a working Symbol level button, except the rule-based renderer; the patch will give similar behaviour on all renderers. It kills me to write this, but if those few lines of the patch are not applied, IMHO it is better to remove the Symbol levels button from the rule-based renderer (because users will try to use it otherwise). Mayeul On Friday 04 March 2011 at 16:33 +0100, Marco Hugentobler wrote: we could apply your patch to the release branch and keep trunk untouched for Martin to implement it in his preferred way. Martin, Marco that sound ok for you? +1 Marco Am Freitag, 4. März 2011, um 05.42:09 schrieb Tim Sutton: Hi Mayeul On Wed, Mar 2, 2011 at 7:01 PM, mayeul.kauffm...@free.fr wrote: Hi, (This follows this thread: Branch status for merge and release timeline proposal) Thanks for you answer Tim! I found the clarification useful and I appreciate your sense of diplomacy. Here are a few thoughts. You wrote: I agree the items in your list should get attention Just to make sure: most of the list (including links to my patch) was written by users Neumann and Anitagraser. Acknowledged thanks. Among those fixes, we are several developers to believe that symbol levels in rule-based rendering should be fixed, even with a temporary fix. A fix was proposed in August 2010 by mhugent, see: http://trac.osgeo.org/qgis/ticket/2832#comment:8 His patch was applied except for the symbol level lines (about 10 lines of code). I made improvements to this code and my patch was somehow applied, again without the few symbol level lines of code. http://trac.osgeo.org/qgis/ticket/3222#comment:15 I agree with Martin that it would be better to have a final solution than an incomplete one for symbol levels. But since the rule- based rendering is currently in an incomplete state, why put it in the renderer stable release anyway? I believe symbol levels make a huge difference in rendering lines. With them, I have a rendering similar to Osmarender or Mapnik in QGIS which gives QGIS a definitive bonus with respect to many other desktop or server GIS. Ok I had a read through the ticket. Martin is the maintainer of this code so while I share your desire for symbol levels in rule based renderer, I think we should give Martin the space to implement the solution in his way if he has a better approach. I know Martin has a lot of other things on his plate so lets give him some time. If coming up to the release we need to apply a band aid fix (that doesnt break any compatibility) to get 1.7 out with symbol level support, we
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Hi, My preference: option 3 + Marco's suggestion Still, there are more people voting than people going to the hackfest! There were at least 2 messages saying that debugging is not fun (and, no, it is not fun!). And Marco is right about discussing future development directions. For me those taking the time to go to Lisbon should do what they prefer to do, not what the majority of developers prefer. My preference is still option 3 (+ Marco's suggestion), but whatever the decision of participants would be, thanks in advance for the good work and have fun! Mayeul Le jeudi 31 mars 2011 à 09:34 +0200, Marco Hugentobler a écrit : Hi Tim 3 for me too (assuming there is still space to discuss future development directions at the hackfest). Regards, Marco Am Donnerstag, 31. März 2011, um 08.54:11 schrieb Tim Sutton: Hi all There has been some discussion on this list about extending the release schedule for 1.7. The proposals are: 1) Continue with release schedule as is (aiming for mid-april release announcement with branching on 7 April) 2) Extend the release schedule and lift the string freeze until after the hackfest. We would then spend **a day** of the hackfest tidying up QGIS 1.7 and then branch at the end of that day and finalise translation in that branch while we continue to hack new features into trunk for the rest of the hackfest. Planned tag for release would be a week after the hackfest. 3) Extend the release schedule and lift the string freeze until after the hackfest. We would then spend **all** of the hackfest tidying up QGIS 1.7 and then impose a string freeze straight after the hackfest with a planned branch for release a week later. Please cast your vote and have your say. My vote: option 3 Regards Tim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GPL in the Tips (warning: license's bigotry inside)
Hi Jean Roc, I would suggest to change this tip to something widely accepted, for instance: -- Quantum GIS 1.7 is released under the GNU General Public License [version 3, am I correct?? or version 3 or above?]. The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. -- The above sentences (after the first one) are the first three sentences of the Preamble of the GNU GPL v3, here: http://www.gnu.org/licenses/gpl.html This is already translated in many languages here: http://www.gnu.org/licenses/translations.html so this should help have have it translated by QGIS translators. For reference, I copy below the message on QGIS' license posted by Marco 3 weeks ago: De: Marco Hugentobler marco.hugentob...@sourcepole.ch À: qgis-developer@lists.osgeo.org Sujet: [Qgis-developer] GPLv2+ files and GPLv3+ files Date: Thu, 3 Mar 2011 16:52:12 +0100 Hi devs Following up on ticket 3432 (License conflict with GPLv3+ libs), I had a discussion with Volker about it . The conclusion was that there is no conflict, but the only way to distribute QGIS currently is under the terms of the GPLv3. This is because most of the source files are under GPLv2+ (version2 or any later version). However, PAL and the sqlanywhere plugin/provider sources are GPLv3+. In my opinion, GPLv3 shouldn't be a problem for the project. From the GNU page, the major changes seem to be a clause that forbids discriminatory patent deals and one that does not allow sueing DRM hackers. Regards, Marco Le samedi 26 mars 2011 à 20:00 +0100, MORREALE Jean Roc a écrit : Hi, I'm translating the Tips, this sentence caught my eye : The GPL places a restriction that any modifications you make must be made available to the Quantum GIS project This is misleading, you only have to share your modification if you distribute the binaries to somebody else. And even then you only have to give access to the source code to the receivers, you don't have to send your changes directly to the project. For example if an geographic institute called *** made a client based on QGIS supporting its in-house DRM access protocol, it would only have to make the code available when distributing this version outside of the institute. Regards, Jean Roc ___ 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] typo?
In label old generation there is already: Data defined placement Data defined properties Data defined buffer Data defined position in qgis r15554. I do not know where the Date defined position is but I guess this should be Data. Mayeul Le jeudi 24 mars 2011 à 17:59 +0100, Paolo Cavallini a écrit : Hi all. While translating, I found a sting: Date defined position Should this be: Data defined position? All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: feature freeze: symbol levels in rule-based rendering
Hi, Tim wrote: Mayeul we will apply this after we branch for release (probably around 1 april). Great! In the meantime, to test the compatibility of the symbol levels patch with commits made since r15217, I just proposed a patch against r15538 adding symbol levels in rule-based renderer (on top of r15217). It is a minimalist patch which adds a quick fix for symbol levels and a Priority column (instead of ID in previous patch) which is necessary to know what is the, er... priority of rules when symbol levels are used (since only first matched rule will be used). It's there: http://trac.osgeo.org/qgis/ticket/3222 patch_on_r15538-rbr_with_symbol_levels.diff I'm testing it and I'll put on trac any issue I might find. Regards, Mayeul Le samedi 19 mars 2011 à 09:40 +0200, Tim Sutton a écrit : Hi On Mon, Mar 14, 2011 at 10:22 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi all As Tim suggested to bring a patch to a developer's attention, I recall here what he suggested (and Marco's positive comment): to apply [my] patch to the release branch and keep trunk untouched. (In fact: it's Marco's patch proposed 7 months ago, see http://trac.osgeo.org/qgis/ticket/2832#comment:3 ) Mayeul we will apply this after we branch for release (probably around 1 april). Please remind me if you see the branch notice go out and you havent seen your patch applied. Regards Tim This does not prevent us to work towards SLD in the long term. Still, for now, all NG renderers (Single symbol, categorized, graduated) have a working Symbol level button, except the rule-based renderer; the patch will give similar behaviour on all renderers. It kills me to write this, but if those few lines of the patch are not applied, IMHO it is better to remove the Symbol levels button from the rule-based renderer (because users will try to use it otherwise). Mayeul On Friday 04 March 2011 at 16:33 +0100, Marco Hugentobler wrote: we could apply your patch to the release branch and keep trunk untouched for Martin to implement it in his preferred way. Martin, Marco that sound ok for you? +1 Marco Am Freitag, 4. März 2011, um 05.42:09 schrieb Tim Sutton: Hi Mayeul On Wed, Mar 2, 2011 at 7:01 PM, mayeul.kauffm...@free.fr wrote: Hi, (This follows this thread: Branch status for merge and release timeline proposal) Thanks for you answer Tim! I found the clarification useful and I appreciate your sense of diplomacy. Here are a few thoughts. You wrote: I agree the items in your list should get attention Just to make sure: most of the list (including links to my patch) was written by users Neumann and Anitagraser. Acknowledged thanks. Among those fixes, we are several developers to believe that symbol levels in rule-based rendering should be fixed, even with a temporary fix. A fix was proposed in August 2010 by mhugent, see: http://trac.osgeo.org/qgis/ticket/2832#comment:8 His patch was applied except for the symbol level lines (about 10 lines of code). I made improvements to this code and my patch was somehow applied, again without the few symbol level lines of code. http://trac.osgeo.org/qgis/ticket/3222#comment:15 I agree with Martin that it would be better to have a final solution than an incomplete one for symbol levels. But since the rule- based rendering is currently in an incomplete state, why put it in the renderer stable release anyway? I believe symbol levels make a huge difference in rendering lines. With them, I have a rendering similar to Osmarender or Mapnik in QGIS which gives QGIS a definitive bonus with respect to many other desktop or server GIS. Ok I had a read through the ticket. Martin is the maintainer of this code so while I share your desire for symbol levels in rule based renderer, I think we should give Martin the space to implement the solution in his way if he has a better approach. I know Martin has a lot of other things on his plate so lets give him some time. If coming up to the release we need to apply a band aid fix (that doesnt break any compatibility) to get 1.7 out with symbol level support, we could apply your patch to the release branch and keep trunk untouched for Martin to implement it in his preferred way. Martin, Marco that sound ok for you? (for a rendering sample, see: http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png which is compared with the OSM python plugin rendering here: http://www.qgis.org/wiki/Using_OpenStreetMap_data ) Very nice - I also have someone working on building rendering rules for OSM here at Linfiniti and have been reading your notes and the discussions on OSM symbology here on this list with interest. Also, QGIS rule-based rendering is definitely more powerful than what you
Re: [Qgis-developer] Compiling Linux/ubuntu 64 bits
Hi, I compiled QGIS without problem earlier this week without any problem on the exact same architecture (except the window manager): KUbuntu 10.10 64 bits, Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56). Could you share the exact sequence of commands you are doing? It might help. Mayeul Le jeudi 17 mars 2011 à 20:25 -0300, Luiz Motta a écrit : Hi Devs, At now, i compile the QGIS R15530, Linux/Ubuntu 10.10 64 bits I can't use plugins python, i receive this error: Couldn't load PyQGIS. Python support will be disabled. Traceback (most recent call last): File , line 1, in ImportError: /usr/local/share/qgis/python/qgis/core.so: undefined symbol: _ZN14QgsMapRenderer17setDestinationSrsERK28QgsCoordinateReferenceSystem Python version: 2.6.6 (r266:84292, Sep 15 2010, 16:41:53) [GCC 4.4.5] QGIS version: 1.7.0-Trunk 'Trunk', 15530 Python path: ['/usr/local/share/qgis/python', '/home/luiz/.qgis/python', '/home/luiz/.qgis/python/plugins', '/usr/local/share/qgis/python/plugins', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/local/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/python2.6/dist-packages/gst-0.10', '/usr/lib/pymodules/python2.6', '/usr/lib/python2.6/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.6/gtk-2.0'] ___ 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] Status of Release 1.7 and Raster-on-the-Fly
Here are some comments about the second part (which is more a user issue). draw speeds of about 30 seconds I was impressed that QGIS could handle such a large dataset. Any comments? You might gain speed gains doing some or part of the following: - put your dataset in a database (suggested: postgis or spatialite) - simplify your dataset for visualisation at small (overview) scale; try to draw non-simplified data only at detailed (large) scale - if you insist on shapefiles, make sure you created the spatial index (there is one button in QGIS for this) - probably it does not make sense to display all the data at all scale. Depending on semantic needs, optimisation is possible here. In addition, polygons with a very small area can easily be ignored at small scale (they would probably be displayed with a single pixel anyway): pre-compute the scale of each polygon, and create a scale based rule in rule based renderer. (or use a query at the layer level). When you say contour polygon do you mean level curves (elevation data) [hence: might be linestring, not polygons]? Then at small scale you could show only main level curves (every 100 m). Doing this I can browse the Openstreetmap dataset + level curves/contour for a European country (1Gb of data) with a rendering time of less than 1 second. If you have several layers, you may want to try and build the threading branch for even faster rendering (multicore). Mayeul - Mail Original - De: Bob Bruce (CON) bob.br...@gov.mb.ca À: qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org Envoyé: Jeudi 17 Mars 2011 16h53:25 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [Qgis-developer] Status of Release 1.7 and Raster-on-the-Fly I am preparing to do a presentation on QGIS to a GIS users group meeting in Brandon on Friday. What can I say about when 1.7 will come out? Will it have the Raster-on-the-Fly capability that is being tested at the moment? I have been doing some testing with a polygon file of contours have 54614 polygons and it is 770 Mb in size and an getting draw speeds of about 30 seconds on my DELL T3500 system running Windows 7 with 4 Gb of RAM. The contour polygons are at 5m intervals. (I have some screen captures of some of the draws if people want to email me directly for them) This seems like a pretty fast response time and I was impressed that QGIS could handle such a large dataset. Any comments? Bob Bruce **Bob Bruce, FEC, P.Eng. Geomatics Support Engineer **bbr...@gov.mb.ca Manitoba Lands and Geomatics Branch, **work # (204) 945-66361007 Century Street, **FAX # (204) 945-1365Winnipeg, Manitoba, Canada, R3H 0W4 ** **The Manitoba Centre for: ** Cadastral Topographical Mapping, and Remote Sensing ** See us on the Web at: http://www.gov.mb.ca/conservation/geomatics/ ** and: http://www.gov.mb.ca/conservation/geomatics/cada_mapping/index.html ** Check out our digital maps at: http://mli2.gov.mb.ca/ ** and WMS: http://mlidata.gov.mb.ca/wms/request.aspx ___ 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 access control question
Hi David, Barry is right and his answer is much better than what you could get with any client connecting to the data. You can define read-only access for some users and write access to other users both at the database level and at the shared disk level. All the examples you gave (below) are normally managed this way. This is the only safe way to do it: if you create a new client software managing access restriction, you may always face users using other clients to workaround those restrictions. On the contrary, whatever the client you use, nobody will break a well designed database or shared disk security. The only part of the access restrictions that a client as QGIS should take care of is to ask users to provide a correct username/password, and this is implemented. Hope it helps. Mayeul Le mercredi 16 mars 2011 à 16:21 -0500, David Silva Barrera a écrit : For example an Analist just view and calculate areas and stadistics, but a Map-Administrator is responsible for updating new elements on maps, or modifying attributes. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] feature freeze: symbol levels in rule-based rendering
ON and apply all rules -symbol levels OFF and apply first matching rule What do you think? Yes personally I would like to see these options too. Best regards Tim Regards, Mayeul - Mail Original - De: Tim Sutton li...@linfiniti.com À: Mayeul Kauffmann mayeul.kauffm...@free.fr Cc: qgis-developer qgis-developer@lists.osgeo.org Envoyé: Mardi 1 Mars 2011 21h44:05 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Qgis-developer] Branch status for merge and release timeline proposal Hi Mayeul On Tue, Mar 1, 2011 at 3:15 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi, What about open tickets (bug fixes) that are not in branches? What is the timeline for them? We usually try to make sure there are no show stoppers when we release and remaining tickets get carried over to next release. I dont think we will ever be able to be in a situation where there are no open tickets left at the time of a release. Now that New Symbology is the default, I guess the following should be fixed before release, or am I missing something? http://www.qgis.org/wiki/Switching_from_Old_to_New_Symbology_and_Labelin g This is a great list / wiki page. The wait / when to release discussion is one that comes up periodically. I agree the items in your list should get attention - and no doubt more items will be raised when people are using symobology-ng by default. However these are not things I believe we should put a hold on the release for. If there is a general unhappiness about the situation, we can reinstate old symbology by default, but if not, lets put what we have out there for people to test and use, and march on towards 2.0. Regards Tim Thanks for clarification! Mayeul Le mardi 01 mars 2011 à 09:19 +0200, Tim Sutton a écrit : Hi all especially Martin and Pirmin and those actively working on new features I am just wondering how things are looking in terms of merging branches. Is a merge of threaded rendering + 3d globe on the cards for 1.7 assuming we have a code freeze of around March 15? I'd like to get 1.7 out before the hackfest (oops QGIS Meeting) so was thinking along the lines of : - code freeze 15 march - string freeze 21 march - release branching 1 April (yes I know its a cool date to release the code on :-) - release announcements 7 April (or when packages are available Are there any other major features people are working on that should be considered for the release timeline? If the threading + globe branches arent ready we can hold them over till 1.8, though it would be nice to get them out there now to keep all the slathering fans happy! Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == 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. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Easy postgres setup and OSM pre-processing for QGIS [v.0.2]
Hi, I've just released version 0.2 of osm2postgresql. The result is now easier to use with QGIS, thanks to a class field in each table (polygons, ways, nodes_with_tags) on which you can build your symbology. Other features: # Fixes small streams, canals... on riverbanks (nicer rendering with QGIS, and labels from rivers no longer go in the middle of lakes!) # Keeps [almost] ALL tags (in two fields: 'tags' as text and 'tagshstore' as hstore): you may fine-tune your rendering with the 'tags' field using QGIS's rule-based renderer. # Optional: installs a postgres server and configure it; create a database (with postgis and hstore) # Loads OSM data into the database and process it; creates and fixes polygons This is still a work in progress. Hope it helps. Links: http://sourceforge.net/projects/osm2postgresql/ http://www.qgis.org/wiki/Using_OpenStreetMap_data http://wiki.openstreetmap.org/wiki/Osm2postgresql Mayeul Le dimanche 06 mars 2011 à 22:51 +0100, Mayeul Kauffmann a écrit : Hi, To help the use of OSM data in QGIS: I created a bash script to automate the installation and configuration of postgresql, to create a database (with postgis and hstore), to download and run osmosis, load the data into postgres and process them for displaying them on QGIS. The first steps are optional. The script is available at: http://sourceforge.net/projects/osm2postgresql/ The idea came from kimaidou's comment below. It's not yet for linux beginners. It still needs some improvement but with it I can do all the above in one command line. Ultimately I would like to incorporate it somehow into QGIS to have a new OSM viewer. (I discussed this with spatialite's developer but some postgres functions are missing in sqlite.) Mayeul Le lundi 21 février 2011 à 09:17 +0100, kimaidou a écrit : Hi Mayeul and devs, Mayeul, I had a look at your wiki page which describes how to get and use OSM data. I think you should speak a bit more about pre-processed shapefiles, as it is much easier for people with no server/time/skills to open a shapefile in Qgis than setting up a complete OSM postgresql/postgis database. ___ 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] Easy postgres setup and OSM pre-processing for QGIS
Hi, To help the use of OSM data in QGIS: I created a bash script to automate the installation and configuration of postgresql, to create a database (with postgis and hstore), to download and run osmosis, load the data into postgres and process them for displaying them on QGIS. The first steps are optional. The script is available at: http://sourceforge.net/projects/osm2postgresql/ The idea came from kimaidou's comment below. It's not yet for linux beginners. It still needs some improvement but with it I can do all the above in one command line. Ultimately I would like to incorporate it somehow into QGIS to have a new OSM viewer. (I discussed this with spatialite's developer but some postgres functions are missing in sqlite.) Mayeul Le lundi 21 février 2011 à 09:17 +0100, kimaidou a écrit : Hi Mayeul and devs, Mayeul, I had a look at your wiki page which describes how to get and use OSM data. I think you should speak a bit more about pre-processed shapefiles, as it is much easier for people with no server/time/skills to open a shapefile in Qgis than setting up a complete OSM postgresql/postgis database. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] symbol levels in rule-based rendering
Hi again Martin, Thanks for your notes. Below is a proposal for a compromise. I see the long term advantages of converging to something compatible with SLD and you gave good arguments in favor of this approach. Yet, since I find a few advantages in the other approach, I cannot say that I prefer one solution over the other in the long term (I will only be able to tell which I prefer after testing intensively the SLD approach with a GUI). So I've nothing against it as a long term direction, except for one comment (with a proposed fix) and one question: - Comment about: I think GUI for the rule-based renderer could simplify the symbolization of line features with overpainting: first you would create the rules you need for roads and assign symbols with multiple layers. Then you would tell the GUI to take the style containing roads and split it so that rules would be duplicated in new style(s), getting the desired effect. Your suggestion is to create SLD rules in two steps (instead of one), the second step being non-reversible. After the second step, there is no preview anymore of the multiple layers of a given symbol. Imagine you create a rule for a road (with outline), then split the rule, then you are not satisfied with the result and you want to fine-tune the symbol. You would need to do the following: 1. open the style of the inner line 2. Click change... 3. Make the changes 4. Close the style of the inner line 5. Search for the style of the outline (corresponding filter for the same road) and open it 6. Click change... 7. Make the changes 8. Close the style of the outline 9. Click apply. 10. Wait before the map is refreshed. Search for the result directly on the map. 11. Start again from step one since the result is not what you want. It would be very tedious to design multi layer symbols without the symbol preview. In the current symbol layer implementation: the following steps are unnecessary: 4,5,6,8,9,10; and the steps 1 and 4 need to be done only once even if you need ten trials. So, if you have 2 layers for a line and you need 5 trials (that's quite conservative), your proposal requires you to you make 33 mouse clicks more than with the current implementation (5*5 + (5-1)*2). (Only if you can do step 5 in one single click). You could keep your proposal the way it is (SLD view), but have a radio button to switch from the SLD view to another view which would be similar to the current No grouping view (which in fact would be group by filter and scale): for a given scale range, it would group all rules that have a common filter; double-clicking on one row would allow to open a window identical to the Rule properties: you would then modify all the layers in single window, and define the legend as well. The changes will be saved in the different underlying rules (the ones displayed in the SLD view). This way, the different views will reflect the different tasks, while being consistent with the underlying SLD model. What do you think? Question: I'm not sure about how SLD behaves. There are two tasks that the user want to performs: 1. assign the desired symbology (all levels) to a given feature 2. assign the drawing order to all symbol parts Both tasks are separated with the approach I suggested (symbol levels with rules saying if rules later in the list should be tested). So a rule near the bottom (a rarely matched rule then) can end up drawing something *below* all the other layers. My understanding is that SLD cannot do this (or might only if you put many AND NOT conditions in the previous filters?). Question is: Is it possible (and easy) to separate those two tasks with the SLD approach? I think this question is related to what you wrote: However if we were going to apply only first matching rule, the order would be important, but still irrelevant from the rendering order! That's an advantage if it means it separates tasks 1 and 2 mentioned above. --- This discussion is for long term plans as you said. In the short term, if possible, Tim's proposal of committing the patch in the release branch only would be great ;-) This would allow me to share my OSM rendering and let users modify it. You wrote:I have seen some samples from you, they all look great! Thank you! I'm glad you like them. All the best, Mayeul Le dimanche 06 mars 2011 à 11:55 +0100, Martin Dobias a écrit : Hi Mayeul On Sun, Mar 6, 2011 at 2:43 AM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi, Thanks all for sharing your thought on this. I find this discussion very stimulating! Obviously each solution has some advantages and some disadvantages. Here are my comments on Martin's answer. ## Martin wrote: I think we all agree that ultimately we want to have some kind of compatibility with SLD and/or Mapnik I can understand the benefits of technical convergence. Still I do not fully agree
Re: [Qgis-developer] symbol levels in rule-based rendering
Hi, Thanks all for sharing your thought on this. I find this discussion very stimulating! Obviously each solution has some advantages and some disadvantages. Here are my comments on Martin's answer. ## Martin wrote: I think we all agree that ultimately we want to have some kind of compatibility with SLD and/or Mapnik I can understand the benefits of technical convergence. Still I do not fully agree. From my personal point of view, my aim is not to have a software compatible with Mapnik (usable only by expert users?), my aim is to let less advanced users easily define their graphic semiology, to bridge the gap between map makers and map users (one reason is that OSM data is so rich that you can do thousands of different custom maps). That's why I started working on a set of QGIS styles for OSM: I found it too difficult to rewrite quantumnik styles to fit my needs. In more general terms, the QGIS philosophy is somewhat different from Mapnik's. Mapnik is aimed for expert users who do not mind defining thousands of parameters in XML code. If I understood the aims of QGIS correctly, QGIS is also for intermediate users who need to understand how to use the software in a reasonable amount of time, and will use it predominantly with the mouse. Current osm.xml mapnik stylesheet has more than 7000 lines and about 640 filters. There are 35 filters for [highway] = 'secondary' alone; those 35 filters are in 7 different part of the osm.xml stylesheet. I suspect that only developers say that Mapnik and osm.xml files are easy to understand, use and modify. But QGIS should be useful for non-developers as well. Anyway, I believe that there is some compatibility between the symbol levels approach and the mapnik approach. The symbol layers are just a way to organize the superposition of layers (drawing order information is gathered in one place); the mapnik way is linear (order in file defines drawing order), but ultimately (during the actual rendering) both are translated into operations that follow the same logic. Thus it is possible to convert a stylesheet from one system to the other and vice versa. In terms of usability, I think symbol levels win: --- With symbol levels, rules are defined this way: rule 5: [highway] = 'secondary' or [highway] = 'secondary_link' - draw black road outline as layer 1 - draw orange road line as layer 12 --- Mapnik works this way: rule 17: [highway] = 'secondary' or [highway] = 'secondary_link' - draw black road outline rule 18: [...] ... rule 313: [...] ... ... rule 314: [highway] = 'secondary' or [highway] = 'secondary_link' - draw orange road line ... --- There is a 1-to-n relationship between a feature and its symbol layers; this idea is simple and translates directly into the symbol levels system. Mapnik model is redundant: it has to repeat the rule for each symbol layer. (To make a comparison: in a relational database, this would be considered bad practice). My final comment on we want to have some kind of compatibility with SLD and/or Mapnik: If Mapnik were the best ever possible renderer and if it would be possible (and easy!) to achieve every imaginable graphical effect with it, then maybe it would be more efficient to build a quantumnik GUI to modify those stylesheets, and use the Mapnik renderer as the default QGIS renderer, instead of building a new renderer (or trying to modify the existing rule-based renderer to make it resemble mapnik). ## implement the else filter which is hard to achieve right now. My understanding is that a different type (but still useful) of else logic is achieved with apply first matching rule. I described a useful extension to the apply first matching rule logic here: http://trac.osgeo.org/qgis/ticket/3222#comment:16 (see bullet 1. in comment:16: For each rule, let the user say whether (if this rule is matched) it should be the last rule tested) The only downside I see here is that the symbols which are going to be use the effect of overpainting - like the roads with outlines - have to be split to bottom and top layer and applied in two different styles. But I think that is a relatively low price given the advantages. Finally, there are not that many symbols that would need this effect. My experience with OSM data is quite different. I currently have about 70 rules for OSM linear features. More than half of them use 2 to 3 symbol levels with overpainting across features. So for me using overpainting is the rule, not the exception, if you want to have a beautiful rendering. (And it is not limited to road outlines). Here are some additional comments and questions. 1. While designing the architecture, we should work with real cases: pick up a mapping problem (for instance a region with some OSM data) and see what kind
[Qgis-developer] Re: symbol levels in rule-based rendering (+level curves and operators in rules)
Hi, Thanks a lot for the answer, for your comments and for your proposal! If needed, I can try and work on XSLT to convert the styles between the different qml versions that might appear in this process. Here is my answer with respect to your question on level curves: By the way did you figure out the correct syntax for the modulus operator? I was trying to make a simple rule to make every contour % 100m a bit thicker. Eventually I settled for contour in (100,200,300) which is ugly but worked... No, I use external modulo: First I wrote an R script which connects to the .dbf and adds a column with 4 different values values like: |type | --- (NULL) 100 500 1000 Later on I did the same under postgresql. Then in QGIS I defined four rules with different thickness, using scale-based filtering as well. It would be great to know exactly what are the operators that can be used (what is the underlying language?). I found a few simple regexp that I use for instance for altitude range (to display mountain summit points depending on their altitude, even if the metric unit m is included - which is contrary to OSM standard). Mayeul - Mail Original - De: Tim Sutton li...@linfiniti.com À: mayeul kauffmann mayeul.kauffm...@free.fr Cc: qgis-developer qgis-developer@lists.osgeo.org Envoyé: Vendredi 4 Mars 2011 05h42:09 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: symbol levels in rule-based rendering Hi Mayeul On Wed, Mar 2, 2011 at 7:01 PM, mayeul.kauffm...@free.fr wrote: Hi, (This follows this thread: Branch status for merge and release timeline proposal) Thanks for you answer Tim! I found the clarification useful and I appreciate your sense of diplomacy. Here are a few thoughts. You wrote: I agree the items in your list should get attention Just to make sure: most of the list (including links to my patch) was written by users Neumann and Anitagraser. Acknowledged thanks. Among those fixes, we are several developers to believe that symbol levels in rule-based rendering should be fixed, even with a temporary fix. A fix was proposed in August 2010 by mhugent, see: http://trac.osgeo.org/qgis/ticket/2832#comment:8 His patch was applied except for the symbol level lines (about 10 lines of code). I made improvements to this code and my patch was somehow applied, again without the few symbol level lines of code. http://trac.osgeo.org/qgis/ticket/3222#comment:15 I agree with Martin that it would be better to have a final solution than an incomplete one for symbol levels. But since the rule- based rendering is currently in an incomplete state, why put it in the renderer stable release anyway? I believe symbol levels make a huge difference in rendering lines. With them, I have a rendering similar to Osmarender or Mapnik in QGIS which gives QGIS a definitive bonus with respect to many other desktop or server GIS. Ok I had a read through the ticket. Martin is the maintainer of this code so while I share your desire for symbol levels in rule based renderer, I think we should give Martin the space to implement the solution in his way if he has a better approach. I know Martin has a lot of other things on his plate so lets give him some time. If coming up to the release we need to apply a band aid fix (that doesnt break any compatibility) to get 1.7 out with symbol level support, we could apply your patch to the release branch and keep trunk untouched for Martin to implement it in his preferred way. Martin, Marco that sound ok for you? (for a rendering sample, see: http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png which is compared with the OSM python plugin rendering here: http://www.qgis.org/wiki/Using_OpenStreetMap_data ) Very nice - I also have someone working on building rendering rules for OSM here at Linfiniti and have been reading your notes and the discussions on OSM symbology here on this list with interest. Also, QGIS rule-based rendering is definitely more powerful than what you can achieve on ArcGIS with queries and scale-related visibility, but ArcGIS users who need symbol levels will not want QGIS's rule-based rendering. Ideally we should be able to have any combinations of the following: -symbol levels ON or OFF -apply first matching rule or apply all rules (That's 4 combinations) With a few lines take from any of the two patches proposed by mhugent and myself, we can have either: -symbol levels OFF and apply all rules -symbol levels ON and apply first matching rule With the current version (since r15217) we only have: -symbol levels OFF and apply all rules Yup those all sound useful - the idea being that you could create a sequence of symbol layers based on rules offers powerful possibilities. By the way did you figure out the correct syntax for the modulus operator? I was trying to make a simple rule to make every contour % 100m a bit thicker. Eventually I settled
Re: [Qgis-developer] Re: level curves and operators in rules
Hi again, I mentioned regexp in rules. In fact you can use them in place of the modulo operator when you want to test some_number modulo 100 = 0, as it is trivial to test if the last two characters are zeroes. I have not tested this but it should work from 100 to 8900 meters: height like '%[1-8]*[0-9]00' You could also have this I guess for main curves every 200 meters: height like '%[1-8]*[02468]00' * is for optional previous character (not tested when previous character is a regexp) % is for any number of characters [a-c] for range I have tested the following rules and they work fine to display mountains from OSM data according to their height: tags like '%natural=peak%' AND (tags like '%ele=[1-9][0-9]m*%' OR tags like '%ele=[1-4][0-9][0-9]m*%') tags like '%natural=peak%' AND tags like '%ele=[5-9][0-9][0-9]m*%' tags like '%natural=peak%' AND tags like '%ele=1[0-4][0-9][0-9]m*%' tags like '%natural=peak%' AND tags like '%ele=1[5-9][0-9][0-9]m*%' tags like '%natural=peak%' AND tags like '%ele=2[0-9][0-9][0-9]m*%' tags like '%natural=peak%' AND tags like '%ele=3[0-9][0-9][0-9]m*%' tags like '%natural=peak%' AND tags like '%ele=[4-8][0-9][0-9][0-9]m*%' Mayeul - Mail Original - De: mayeul kauffmann mayeul.kauffm...@free.fr À: Tim Sutton li...@linfiniti.com Cc: qgis-developer qgis-developer@lists.osgeo.org Envoyé: Vendredi 4 Mars 2011 10h46:43 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [Qgis-developer] Re: symbol levels in rule-based rendering (+level curves and operators in rules) Hi, Thanks a lot for the answer, for your comments and for your proposal! If needed, I can try and work on XSLT to convert the styles between the different qml versions that might appear in this process. Here is my answer with respect to your question on level curves: By the way did you figure out the correct syntax for the modulus operator? I was trying to make a simple rule to make every contour % 100m a bit thicker. Eventually I settled for contour in (100,200,300) which is ugly but worked... No, I use external modulo: First I wrote an R script which connects to the .dbf and adds a column with 4 different values values like: |type | --- (NULL) 100 500 1000 Later on I did the same under postgresql. Then in QGIS I defined four rules with different thickness, using scale-based filtering as well. It would be great to know exactly what are the operators that can be used (what is the underlying language?). I found a few simple regexp that I use for instance for altitude range (to display mountain summit points depending on their altitude, even if the metric unit m is included - which is contrary to OSM standard). Mayeul - Mail Original - De: Tim Sutton li...@linfiniti.com À: mayeul kauffmann mayeul.kauffm...@free.fr Cc: qgis-developer qgis-developer@lists.osgeo.org Envoyé: Vendredi 4 Mars 2011 05h42:09 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: symbol levels in rule-based rendering Hi Mayeul On Wed, Mar 2, 2011 at 7:01 PM, mayeul.kauffm...@free.fr wrote: Hi, (This follows this thread: Branch status for merge and release timeline proposal) Thanks for you answer Tim! I found the clarification useful and I appreciate your sense of diplomacy. Here are a few thoughts. You wrote: I agree the items in your list should get attention Just to make sure: most of the list (including links to my patch) was written by users Neumann and Anitagraser. Acknowledged thanks. Among those fixes, we are several developers to believe that symbol levels in rule-based rendering should be fixed, even with a temporary fix. A fix was proposed in August 2010 by mhugent, see: http://trac.osgeo.org/qgis/ticket/2832#comment:8 His patch was applied except for the symbol level lines (about 10 lines of code). I made improvements to this code and my patch was somehow applied, again without the few symbol level lines of code. http://trac.osgeo.org/qgis/ticket/3222#comment:15 I agree with Martin that it would be better to have a final solution than an incomplete one for symbol levels. But since the rule- based rendering is currently in an incomplete state, why put it in the renderer stable release anyway? I believe symbol levels make a huge difference in rendering lines. With them, I have a rendering similar to Osmarender or Mapnik in QGIS which gives QGIS a definitive bonus with respect to many other desktop or server GIS. Ok I had a read through the ticket. Martin is the maintainer of this code so while I share your desire for symbol levels in rule based renderer, I think we should give Martin the space to implement the solution in his way if he has a better approach. I know Martin has a lot of other things on his plate so lets give him some time. If coming up to the release we need to apply a band aid fix (that doesnt break any compatibility) to get 1.7 out with symbol level support, we could
[Qgis-developer] symbol levels in rule-based rendering
Hi, (This follows this thread: Branch status for merge and release timeline proposal) Thanks for you answer Tim! I found the clarification useful and I appreciate your sense of diplomacy. Here are a few thoughts. You wrote: I agree the items in your list should get attention Just to make sure: most of the list (including links to my patch) was written by users Neumann and Anitagraser. Among those fixes, we are several developers to believe that symbol levels in rule-based rendering should be fixed, even with a temporary fix. A fix was proposed in August 2010 by mhugent, see: http://trac.osgeo.org/qgis/ticket/2832#comment:8 His patch was applied except for the symbol level lines (about 10 lines of code). I made improvements to this code and my patch was somehow applied, again without the few symbol level lines of code. http://trac.osgeo.org/qgis/ticket/3222#comment:15 I agree with Martin that it would be better to have a final solution than an incomplete one for symbol levels. But since the rule-based rendering is currently in an incomplete state, why put it in the renderer stable release anyway? I believe symbol levels make a huge difference in rendering lines. With them, I have a rendering similar to Osmarender or Mapnik in QGIS which gives QGIS a definitive bonus with respect to many other desktop or server GIS. (for a rendering sample, see: http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png which is compared with the OSM python plugin rendering here: http://www.qgis.org/wiki/Using_OpenStreetMap_data ) Also, QGIS rule-based rendering is definitely more powerful than what you can achieve on ArcGIS with queries and scale-related visibility, but ArcGIS users who need symbol levels will not want QGIS's rule-based rendering. Ideally we should be able to have any combinations of the following: -symbol levels ON or OFF -apply first matching rule or apply all rules (That's 4 combinations) With a few lines take from any of the two patches proposed by mhugent and myself, we can have either: -symbol levels OFF and apply all rules -symbol levels ON and apply first matching rule With the current version (since r15217) we only have: -symbol levels OFF and apply all rules Adding the extra capability provided in the two proposed patches does not prevent working later on having the missing two combinations: -symbol levels ON and apply all rules -symbol levels OFF and apply first matching rule What do you think? Regards, Mayeul - Mail Original - De: Tim Sutton li...@linfiniti.com À: Mayeul Kauffmann mayeul.kauffm...@free.fr Cc: qgis-developer qgis-developer@lists.osgeo.org Envoyé: Mardi 1 Mars 2011 21h44:05 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Qgis-developer] Branch status for merge and release timeline proposal Hi Mayeul On Tue, Mar 1, 2011 at 3:15 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi, What about open tickets (bug fixes) that are not in branches? What is the timeline for them? We usually try to make sure there are no show stoppers when we release and remaining tickets get carried over to next release. I dont think we will ever be able to be in a situation where there are no open tickets left at the time of a release. Now that New Symbology is the default, I guess the following should be fixed before release, or am I missing something? http://www.qgis.org/wiki/Switching_from_Old_to_New_Symbology_and_Labeling This is a great list / wiki page. The wait / when to release discussion is one that comes up periodically. I agree the items in your list should get attention - and no doubt more items will be raised when people are using symobology-ng by default. However these are not things I believe we should put a hold on the release for. If there is a general unhappiness about the situation, we can reinstate old symbology by default, but if not, lets put what we have out there for people to test and use, and march on towards 2.0. Regards Tim Thanks for clarification! Mayeul Le mardi 01 mars 2011 à 09:19 +0200, Tim Sutton a écrit : Hi all especially Martin and Pirmin and those actively working on new features I am just wondering how things are looking in terms of merging branches. Is a merge of threaded rendering + 3d globe on the cards for 1.7 assuming we have a code freeze of around March 15? I'd like to get 1.7 out before the hackfest (oops QGIS Meeting) so was thinking along the lines of : - code freeze 15 march - string freeze 21 march - release branching 1 April (yes I know its a cool date to release the code on :-) - release announcements 7 April (or when packages are available Are there any other major features people are working on that should be considered for the release timeline? If the threading + globe branches arent ready we can hold them over till 1.8, though it would be nice to get them out there now to keep all the slathering fans happy! Regards Tim
Re: [Qgis-developer] icons and styles
Hi, +1 for the style and icon repository! Maybe you will find useful ideas in the way openclipart.org manages collections and packages. One contributor of free icons (SJJB?) sometimes puts several icons in one file, see: http://www.openclipart.org/detail/12368 To generate sets of icons from gray scale icons (with or without boundary) you may want to have a look at the scripts I mentioned here: http://www.qgis.org/wiki/Using_OpenStreetMap_data#Add_new_OSM_icons It may be interesting to separate original svg icons that were designed to be modifiable with scripts and icons meant for end users. The above scripts replace strings in the xml so it's quite easy to understand and use, but I can help you modify it if you need to. For the metadata/information related to an icon, it could be useful to be able to add some information about its usage in QGIS (with wich style set(s) it is used and with which rule). For instance, there are already icons to represent those 2 different cases (with OSM data): tourism=alpine_hut AND heating=fireplace tourism=alpine_hut AND (heating=no OR [heating key does not exists]) Sharing this would allow the visitors to know how a specific icon is used without having to open all projects. It should be possible to extract the rules from the qml files. Just my 2 cents. Mayeul - Mail Original - De: Alex Mandel tech_...@wildintellect.com À: qgis-developer@lists.osgeo.org Envoyé: Mardi 22 Février 2011 10h00:30 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Qgis-developer] icons and styles On 02/22/2011 12:50 AM, Paolo Cavallini wrote: Hi all. I think we should provide an opportunity for uploading sets of icons and styles, on the same infrastructure that we are going to use for plugins. I'd appreciate comments on this. All the best. It's already on the to do list for the django web app. I'm working with the OSGeo Graphics mailing list to try and coordinate efforts on this since they've been thinking about the idea and have an svn folder for it. In particular I've already started on some tools to automate keeping collections of icons in single svg files and using inkscape to split them into individual files for application use, while preserving metadata about the icons in the svg files themselves. My plan at this point is to then use a Django app to catalog the keywords tags from a specific field in the svg xml into a searchable database and then replicate this functionality locally as a plugin (possibly future core item in symbology). Note, as far as I know this will only work for point symbology right now, I do not have a plan for lines or polygon fills yet but that's because they aren't svg based at this time. The whole thing is still in the very early stages so I welcome conversation on the topic and invite others to join OSGeo graphics to really find a multi-app solution for the FOSS GIS community. It will probably be a few months before we get anything up on the website, since there are much higher priorities for the plugin site that still need to be done. Thanks, Alex ___ 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] icons and styles
Tim Sutton wrote: So before anyone writes code, take a google around and see if there is something off-the-shelf we can just repurpose. Hi, It's not django-based but the openclipart.org portal has all what is needed for the svg part. The source code is not directly accessible from the home page, so here is a direct link to the code: https://launchpad.net/openclipart Platform is LAMP. Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Symbology / OSM/ shapefiles
Hi again, kimaidou wrote : Hi Mayeul and devs, Mayel, I had a look at your wiki page which describes how to get and use OSM data. I think you should speak a bit more about pre-processed shapefiles, as it is much easier for people with no server/time/skills to open a shapefile in Qgis than setting up a complete OSM postgresql/postgis database. I agree, the postgis solution currently is to complex to follow for the beginners. But the reason why I am putting this is to show that it is feasible to have this and that it gives good results. In ticket http://trac.osgeo.org/qgis/ticket/3222 I advocate for fast, easy and beautiful OSM maps with qgis: if we can get fast and beautiful maps in the first place, then we can work together to make it easy (the ultimate goal is to make it as easy as with the python plugin or with JOSM). Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Symbology / OSM/ ICONS
Hi, I have added (on the wiki) some comments and a link to the 3liz.com demo and blog about the qgis mapserver rendering based on shapefiles. Mayeul Le lundi 21 février 2011 à 09:17 +0100, kimaidou a écrit : Hi Mayeul and devs, Mayel, I had a look at your wiki page which describes how to get and use OSM data. I think you should speak a bit more about pre-processed shapefiles, as it is much easier for people with no server/time/skills to open a shapefile in Qgis than setting up a complete OSM postgresql/postgis database. I know all the tags are not in the shapefiles, but it is a good start. See the small qgis mapserver rendering with these shapefiles : http://demo.3liz.fr/qgismapserver/ By, the way, I am also looking for icons to render the rich OSM poi database, (http://demo.3liz.fr/osminterest/ ) and asked the creator of the SJJB icons to create some more. I gave him a list 2 days ago, and he told me he would spend some times to work on it in the coming weeks. I will let you know when I get some information. Kimaidou 2011/2/19 Mayeul Kauffmann mayeul.kauffm...@free.fr Thanks for the suggestion Martin! Icons are available here: http://www.mediafire.com/?344x43313q3xx8n They are meant to be used with the tutorial here: http://www.qgis.org/wiki/Using_OpenStreetMap_data I was hoping to find something without restrictions and if possible dedicated to open source material. I could not find it here: http://wiki.osgeo.org/wiki/OSGeo_map_symbol_set There is http://www.openclipart.org (which supports multiple uploads, collections and packages) but I cannot upload a zipped file, hence I cannot reproduce the folder structure required for qgis to find the right files. So I've put the icons I'm using on mediafire: osm_icons4qgis_v1.zip (If I do not login often enough, this might be destroyed). All the icons that either SJJB or myself created are copyright free (CC-0). I do not know the status of the others (mostly, the others are preinstalled with qgis). See http://www.sjjb.co.uk/mapicons/introduction Mayeul Le vendredi 18 février 2011 à 23:40 +0100, Martin Dobias a écrit : There are plenty of web services for easy sharing of files, for example, mediafire.com or megaupload.com 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] OSM icons for QGIS vector rendering
Hi Kimaidou, Hi everybody, Kimaidou: Maybe I already created some of the icons you need. Anyway, I wish to release the ones I created under the license SJJB used (CC-0) and I slightly improved some of his icons. I just added some details on this here: http://www.qgis.org/wiki/Using_OpenStreetMap_data#Add_new_OSM_icons I also put the shell scripts I wrote to generate svg coloured icons on linux (SJJB only generated PNG coloured files). I also uploaded my new raw (gray scale/script-proof) icons ( http://www.mediafire.com/?344x43313q3xx8n ). It would be an honor for me if SJJB accepts to redistribute them with theirs! I also uploaded my qgis styles on trac (ticket 3222): that's 225 rules for points alone, showing 225 icons (I choose the one to focus on based on frequency in OSM data and on icon availability, creating a few new icons, possibly with a local bias: you cannot map a single Italian village without an ice cream shop, so I needed to map this! ... to find the ice cream shops more easily myself of course ;-) To answer your comment about your email sent to SJJB icon creator: I do not know the contact details of the creator of the SJJB icons. But based on the following link, maybe your contact at SJJB might be johnny_automatic: http://www.openclipart.org/search/?query=maps Am I right? Anyway, could you give me his email and/or forward this message to him? Thanks. Hope this helps, Mayeul Le lundi 21 février 2011 à 09:17 +0100, kimaidou a écrit : By, the way, I am also looking for icons to render the rich OSM poi database, (http://demo.3liz.fr/osminterest/ ) and asked the creator of the SJJB icons to create some more. I gave him a list 2 days ago, and he told me he would spend some times to work on it in the coming weeks. I will let you know when I get some information. Kimaidou 2011/2/19 Mayeul Kauffmann mayeul.kauffm...@free.fr Thanks for the suggestion Martin! Icons are available here: http://www.mediafire.com/?344x43313q3xx8n They are meant to be used with the tutorial here: http://www.qgis.org/wiki/Using_OpenStreetMap_data I was hoping to find something without restrictions and if possible dedicated to open source material. I could not find it here: http://wiki.osgeo.org/wiki/OSGeo_map_symbol_set There is http://www.openclipart.org (which supports multiple uploads, collections and packages) but I cannot upload a zipped file, hence I cannot reproduce the folder structure required for qgis to find the right files. So I've put the icons I'm using on mediafire: osm_icons4qgis_v1.zip (If I do not login often enough, this might be destroyed). All the icons that either SJJB or myself created are copyright free (CC-0). I do not know the status of the others (mostly, the others are preinstalled with qgis). See http://www.sjjb.co.uk/mapicons/introduction Mayeul Le vendredi 18 février 2011 à 23:40 +0100, Martin Dobias a écrit : There are plenty of web services for easy sharing of files, for example, mediafire.com or megaupload.com 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] New Symbology / OSM/ ICONS
Thanks for the suggestion Martin! Icons are available here: http://www.mediafire.com/?344x43313q3xx8n They are meant to be used with the tutorial here: http://www.qgis.org/wiki/Using_OpenStreetMap_data I was hoping to find something without restrictions and if possible dedicated to open source material. I could not find it here: http://wiki.osgeo.org/wiki/OSGeo_map_symbol_set There is http://www.openclipart.org (which supports multiple uploads, collections and packages) but I cannot upload a zipped file, hence I cannot reproduce the folder structure required for qgis to find the right files. So I've put the icons I'm using on mediafire: osm_icons4qgis_v1.zip (If I do not login often enough, this might be destroyed). All the icons that either SJJB or myself created are copyright free (CC-0). I do not know the status of the others (mostly, the others are preinstalled with qgis). See http://www.sjjb.co.uk/mapicons/introduction Mayeul Le vendredi 18 février 2011 à 23:40 +0100, Martin Dobias a écrit : There are plenty of web services for easy sharing of files, for example, mediafire.com or megaupload.com Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: New Symbology (discretized data?)
Ramon Andinach wrote:
I'd prefer colormap, for the reason that you give.
seems ok for me.
With categorized and graduated I think that they are clear enough,
but not what I would expect. If you were making a graph I was taught
discrete and continuous to describe these data types, and that is
what I'd expect.
I was taught this as well.
The problem is categorized. Categorized data is data that's been
grouped into subsets (bins). So even the graduated data becomes
categorized.
(Take a set of numbers between 1 and 50 {1,2,11,13,22,24,33,35,44,46},
which I treat as graduated data. I could then categorize them into 5
groups of equal ranges {1,2}{11,13}{22,24}{33,35}{44,46} )
This process is called discretization (the words classification or
categorization are more general). See:
http://en.wikipedia.org/wiki/Discretization_of_continuous_features
Similar words are used in French (discrétisation), Italien
(discretizzazione), German (diskretisierung), Hungarian
(diskretizacija), Polish (dyskretyzacja)...
Hence Discretized data seems a good candidate to me. (données
discrétisées in French, the rest is left as an exercise for the
reader ;-) )
This is the standard way of calling this procedure (in the context of
map creation) in France, Switzerland and Québec. Based on some googling,
it seems that the term is used but not widespread in English. Compare a
search for
discrétisation carte
and one for
discretization map
in google.
To have English results similar to French results, you need to search
for:
discretization map choropleth
With such a search, the term discretization seems to be appropriate
and very precise (still quite technical).
Still... discretized data is the result. When ou choose an entry in
the drop-down menu, the data are not discretized yet!
So another approach could be to name this entry continuous data into
classes or classified continuous data or a variant.
Mayeul
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Symbology : merge borders on nodes for lines / OSM
Hi kimaidou, You wrote: I am trying to use the new symbology to display good looking OpenStreetMap road data. I'm glad to see I'm not the only one working on this. I spent hours designing qgis styles for OSM data and creating a patch. You can work on testing or improving this instead of starting from scratch, see this: http://trac.osgeo.org/qgis/ticket/3222 I am currently writing a tutorial on how to do this, the squeleton of the tutorial is here: http://www.qgis.org/wiki/Using_OpenStreetMap_data I've just added one sample map on the wiki. There is a 2 MB limit for the wiki, just ask me if you want more samples by private mail [French is fine ;-)], I'll send them. Mayeul Le jeudi 17 février 2011 à 12:19 +0100, kimaidou a écrit : Hi devs, I am trying to use the new symbology to display good looking OpenStreetMap road data. I have not figured out how to avoir collisions of borders in the interesections. You can find the style applied here : http://i.picoodle.com/0b4i0occ And the result here : http://i.picoodle.com/0b4i0occ As you can see, the result is not very classy. I would like to achieve this kind of rendering : http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#line-with-border Am I doing something wrong ? Or is the feature not yet available in Qgis 1.6 ? Thanks in advance Kimaidou ___ 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] New Symbology : merge borders on nodes for lines / OSM/ sharing large files?
jr.morre...@enoreth.net wrote: If you can could you try to make a package available with all the style and svg icons for ease of use ? I already have this; the problem is I do not know how to share a zip/tar.gz file of that size (1.6MB svg files only). I asked in this forum but did not received a precise answer (or I did not understand it). Anyone having ideas on sharing this? Thanks jr.morre...@enoreth.net also wrote: This is a great task Thanks for your feedback! , please keep us informed about your progress on these styles. I will Mayeul On Thu, 17 Feb 2011 23:04:06 +0100, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi kimaidou, You wrote: I am trying to use the new symbology to display good looking OpenStreetMap road data. I'm glad to see I'm not the only one working on this. I spent hours designing qgis styles for OSM data and creating a patch. You can work on testing or improving this instead of starting from scratch, see this: http://trac.osgeo.org/qgis/ticket/3222 I am currently writing a tutorial on how to do this, the squeleton of the tutorial is here: http://www.qgis.org/wiki/Using_OpenStreetMap_data I've just added one sample map on the wiki. There is a 2 MB limit for the wiki, just ask me if you want more samples by private mail [French is fine ;-)], I'll send them. Mayeul Le jeudi 17 février 2011 à 12:19 +0100, kimaidou a écrit : Hi devs, I am trying to use the new symbology to display good looking OpenStreetMap road data. I have not figured out how to avoir collisions of borders in the interesections. You can find the style applied here : http://i.picoodle.com/0b4i0occ And the result here : http://i.picoodle.com/0b4i0occ As you can see, the result is not very classy. I would like to achieve this kind of rendering : http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#line-with-border Am I doing something wrong ? Or is the feature not yet available in Qgis 1.6 ? Thanks in advance Kimaidou ___ 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] qgis web
Another simple solution is to call directly qgis command line to generate a png on the fly, using the following options: qgis --snapshot image.png --extent xmin,ymin,xmax,ymax data.shp (for more details type qgis --help or man qgis) [I already gave you that hint on the list one month ago, but for a different question]. Hope it helps, Mayeul Sujet: Re: [Qgis-developer] qgis rendering Date: Fri, 07 Jan 2011 23:29:07 +0100 On 05 January 2011 at 13:18 +0530, Mohammed Rashad wrote : Is there any temporary image generated by qgis when rendering a maplayer either raster or vector? -- Rashad Hi Rashad, I'm not sure, but if you want to generate a raster you can use the File menu Save as image or, from the command line, the --snapshot option Mayeul Le samedi 12 février 2011 à 22:39 +0530, Mohammed Rashad a écrit : How to render a shapefile to an image file so that it can be reused on a web page. Anyone please send a me a minimal code or tell me where and what to modify. I looked src/mapserver folder but I cant get the code for it Atleast please tell me the file to modify to render a vector file(shape) to an image file -- Thanks Regards Rashad ___ 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] A roadmap to QGIS 2.0
Hi, Martin Dobias wrote : One of the important things is how/when to merge the threading branch. I know that just few people tried it, so I didn't get much feedback apart from Marco's and Pirmin's comments. Just my two cents as you seem to lack feedback about the threading branch: IMHO, it is just amazing! When I saw the announcement of the Google summer of code, I was waiting forward to test it. I made a local build some time ago and I was impressed (even on an old dual core AMD Athlon). I am waiting to have the branch merged to test it at work and then probably buy a new machine for home (just for this!); I believe it will largely solve the first (speed) of ticket http://trac.osgeo.org/qgis/ticket/3222 [Fast, easy and beautiful on the fly rule-based rendering of OSM maps]. I am working on improving the easiness and performance of postgis as a qgis backend for osm data here, which I hope together with the multi-threading will allow to have fast on-the fly vector rendering for huge .osm files. (Currently I have fair results for italy.osm but performance with osm data + 25 m level curves still need to be improved). In short, all the best for merging the threading branch; I'll be on the list of testers! In addition, since OSM is a very rich and complex dataset, I believe it is an interesting piece of data to make tests on multi-threading. Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Wiki page: switching from old to new symbology, missing bits
Hi Andreas, I proposed significant additions to the Rule based Renderer in a patch here: http://trac.osgeo.org/qgis/ticket/3222 http://trac.osgeo.org/qgis/attachment/ticket/3222/rule_renderer_patch_on_r15004-symbols_not_merged.diff Applying this patch would solve several issues, including one you mentioned: Needs alias columns for the legend. I just tried to write this on http://www.qgis.org/wiki/ but when I try to create an account, I receive the answer: You do not have permission to create this user account, for the following reason: The action you have requested is limited to users in the group: Administrators. I also have several comments and ideas for the Rule based Renderer, based on tests to create multiscale world map with OSM data. All the best, Mayeul - Mail Original - De: Andreas Neumann a.neum...@carto.net À: qgis-developer@lists.osgeo.org Envoyé: Mardi 18 Janvier 2011 15h58:51 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [Qgis-developer] Wiki page: switching from old to new symbology, missing bits Hi, As Paolo suggested, I started a wiki page for problems/missing bits in the new symbology. Please add your issues, so we can get a rather complete view of what is still missing. http://www.qgis.org/wiki/Switching_from_Old_to_New_Symbology_and_Labeling This is just a start. I will add more issues in the next couple days. Thanks for your help! Andreas -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ 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] Announcing RoadGraph plugin
Hi, I was not able to use the plugin with recent qgis 1.7.0 (r15004) under GNU/Linux Kubuntu 10.10. I tried to copy the downloaded libroadgraphplugin.so in /usr/lib/qgis/plugins/libroadgraphplugin.so The plugin does not appear in the list of plugins to activate. I compiled it from source doing the following: sudo-apt-get install liqgis-dev svn co http://svn.gis-lab.info/road-graph road-graph cd road-graph mkdir build cd build cmake .. make sudo make install # or: # sudo cp ../binary/libroadgraphplugin.so /usr/lib/qgis/plugins/libroadgraphplugin.so Then, qgis crashes immediately after launching it. Even after the following, qgis crashes: sudo rm /usr/lib/qgis/plugins/libroadgraphplugin.so I had to reinstall qgis (in fact to upgrade to dev version 15050) to be able to restart it. Thanks for any hint. Mayeul Le samedi 15 janvier 2011 à 10:53 +0200, Alexander Bruy a écrit : Hi all, MOre information about RoadGraph plugin available in English here http://gis-lab.info/qa/road-graph-eng.html Thanks ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis rendering
Le mercredi 05 janvier 2011 à 13:18 +0530, Mohammed Rashad a écrit : Is there any temporary image generated by qgis when rendering a maplayer either raster or vector? -- Rashad Hi Rashad, I'm not sure, but if you want to generate a raster you can use the File menu Save as image or, from the command line, the --snapshot option Mayeul ___ 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] Re: QGIS.pro, Qt Creator and Android - Qt Creator Integration
I have not seen a way to save the project options explicitly, but I have tested that at least some of the compiling options are saved automatically in a CMakeLists.txt.user file which is automatically created next to CMakeLists.txt. For a discussion on a similar issue: http://stackoverflow.com/questions/3898763/where-does-qtcreator-with-cmake-store-run-and-build-settings-and-how-to-set-via Still maybe part of the following has to be done every time. Here are some steps I've used: If I'm correct, with qtcreator, you have to put the correct cmake parameters *the first time* you configure the project (hence, when you open the CMakeLists.txt and click Run CMake) Here are the options I use myself -DCMAKE_INSTALL_PREFIX=~/bin/myqgisdirectory -DCMAKE_BUILD_TYPE=Debug -DENABLE_TESTS=False -DWITH_MAPSERVER=False The following one is mandatory if you want to control where to install the compiled files (choose a place where you do not need sudo rights to write): -DCMAKE_INSTALL_PREFIX= You can also configure the various build steps. You'll find all of this detailed here: http://blog.urbylog.info/2010/05/plasma-applet-development-walk-through_12.html Mayeul Le jeudi 30 décembre 2010 à 08:45 +0200, Tim Sutton a écrit : Hi Noli I'm not an expert in Qt-Creator (I'm a vim guy!) but the last time I tested it, I didnt see any option to create a .pro file from the CMakeLists.txt based project. In fact that was one of my irritations of trying to use creator - having to re-read in the project from the CMakeLists.txt file every time. But it could be just that I missed something essential in the process. I'm also interested in making an android port at some point... Regards Tim On Thu, Dec 30, 2010 at 6:18 AM, Noli Sicad nsi...@gmail.com wrote: Hi, OK. I managed to install cmake package. But still I don't what should be in the Qgis.pro after I created this project? Anybody can post what should be in entries in Qgis.pro? Noli On 12/30/10, Noli Sicad nsi...@gmail.com wrote: Hi, I am trying to create a Qgis.pro (i.e. QGIS Qt Creator Project) based on this instruction [1]. I am stuck on this step 3. 3. Run cmake in CMake Wizard. You can run it after adding project for this you should navigate to cmake build directory it is qtcreator-build in project root and run ccmake .. like usually); There are a lot of cmake files in the cmake directory, which one should I use? Anyway, anybody has exciting Qgis.pro (Qt Creator project) already and like to share it. I like to try to compile Qgis in Qt - Android lighthouse and see what happen. You watch the video on Android - Qt Creator Integration here - Video. http://code.google.com/p/android-lighthouse/wiki/QtCreatorIntegration Anybody interested in QGIS mobile for Android? Thanks. Noli [1] http://www.osgeo.org/pipermail/qgis-developer/2009-October/007832.html Using QtCreator with QGis is easy. To open QGis in it you should do: 1. In menu File-Open File or Project (Ctrl+O); 2. In open file dialog find CMakeLists.txt in the root of QGIs (/usr/local/src/qgis_trunk/CMakeLists.txt) and open it; 3. Run cmake in CMake Wizard. You can run it after adding project for this you should navigate to cmake build directory it is qtcreator-build in project root and run ccmake .. like usually); 4. After that QtCreator adds the new project with name qgis-1.x.x. 5. If you need to correct cmake options you can do it now (see 3); 6. Compile QGis (Ctrl+B); 7. Switch to tab Projects. In section Build Settings-Build Steps push Details button and add in Additional arguments: install. 8. In section Run Settings push +Add and select in combo box Custom Executable then push Details and add in Executable: /patch/to/qgis/executable (/usr/local/bin/qgis); 9. Start Debugging QGis: F5. ___ 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] Patch for #3369
Le jeudi 30 décembre 2010 à 23:44 +, John Donovan wrote : hope this is the right place to do it. Attaching the patch to the ticket at http://trac.osgeo.org/qgis/ticket/3369 will help as well. Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] symbol levels with rule based rendering
Hi Tim, Thanks for your question. I believe this was already the aim the the rule based renderer which was created some time ago. I have worked with it to try and mimic what mapnik and osmarender are doing with openstreetmap data. As a matter of fact, OSM data is so rich that you can do very different maps for very different types of users; in addition, I cannot think of a richer public dataset, so it is a got dataset to make tests and experiments. Working with data with national datasets (currently Italy.osm planet extract) I came up with a few ideas to improve the current renderer; this would in effect allow every one to have his/her *own* ideal map, easily. I believe this really shows the power of freedom that free software and free data can bring. Thanks again for your comments. Merry christmas! Regards, Mayeul I've pasted my draft code here: http://trac.osgeo.org/qgis/ticket/3222#comment:7 I'm very curious to try out your patch. If I can summarise what you are trying to do in a nutshell, its to make a rule based renderer where each rule that is matched ads one or more symbol layers to the item symbol and adds an accompanying layer level entry. More or less correct? Martin Dobias (who is I think enjoying some time away from the computer over xmas) will be the best one to help you with your questions, but I can say that if my description above is correct, it will be most welcom as it will allow us to create very nice cartography at the end of the day. Regards Tim I'm sure there are several incorrect thinks here. Anyone could help? Thanks and Merry Christmas! Mayeul ___ 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 vote : kCube Developer Poll
Hi, we will try to find something more open friendly for the future - though I dont know if such a thing exists. Yes it does! The R language/statistical software has advanced statistical graphics capacity, cf. e.g.: http://addictedtor.free.fr/graphiques/thumbs.php?sort=votes Here, instead of a pie chart, I would suggest: 1) a bar plot in alphabetical order of categories, and 2) a Pareto plot (bar plot in decreasing order of vote) I would save them in a single png file that would be displayed on the web page. Optionally, to get interactive capacity, I would use the sendplot R package: It allows to get nice customized call tips without using any browser addon (only html and standard ecmascript). To implement this, the easiest I can thing of is (but there are other solutions): Each time there is a new vote: 1- the page managing the vote adds the result of the vote to a plain text file 2- launch an R script (by a system/bash call) The R script will do the following: 3- Read the results of the vote from the plain text file 4- Generates the plot(s), saving it in a png file in a folder of the web server 5- optionally adding interaction (saving relevant javascript file) The steps 1 and 2 can be replaced by a direct call to R (there are R bindings from many web scripting languages). I volunteer to do steps 3 to 5 if you are interested. This requires to have R installed on the web server (it is packaged for most linux distribs). Regards, Mayeul - Mail Original - De: Tim Sutton t...@linfiniti.com À: Tim Sutton t...@linfiniti.com, QGIS Developer Mailing List qgis-developer@lists.osgeo.org, qgis-user qgis-u...@lists.osgeo.org Envoyé: Jeudi 23 Décembre 2010 10h29:20 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Qgis-developer] Please vote : kCube Developer Poll Hi We love closed here :-) Only kidding, sorry I havent realised - we will try to find something more open friendly for the future - though I dont know if such a thing exists. Regards Tim On Tue, Dec 21, 2010 at 9:54 AM, strk s...@keybit.net wrote: On Tue, Dec 21, 2010 at 03:05:06AM +0200, Tim Sutton wrote: Please take a moment to cast your vote for your most desirable option. It's unfortunate I can't see the statistics: http://qgis.org/en/component/apoll/apoll/1-kcube.html The application [1] is an SWF of latest-and-closest version :( [1] http://qgis.org/media/system/swf/open-flash-chart.swf --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Visit http://linfiniti.com to find out about: * QGIS programming services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: [Qgis-user] Problem with kml file
Using Linux grep, you can remove the problematic tags, for instance to remove all lines with TR, do: grep -v TR fluxpyr_221010_1.kml fluxpyr_221010_modif.kml This deletes about two thirds of the lines! You can use sed to have more control. If you want a graphical interface/an easier Windows solution, you can use find and replace in OpenOffice.org writer. (for finer control, use this OOo extension: http://extensions.services.openoffice.org/project/AltSearch) Hope this helps - Mail Original - De: Agustin Lobo alobolis...@gmail.com À: Siki Zoltan s...@agt.bme.hu Cc: qgis-user qgis-u...@lists.osgeo.org, qgis-developer qgis-developer@lists.osgeo.org Envoyé: Jeudi 23 Décembre 2010 13h57:19 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [Qgis-developer] Re: [Qgis-user] Problem with kml file Thanks! Any way I can reformat the file? This file has been given to me, no way I can modify the options of the gps now. Or perhaps there is a way to tell gdal-OGR the file has html format and then write a shapefile? Agus 2010/12/23 Siki Zoltan s...@agt.bme.hu: Dear Augustin, you have html code in the description field of the xml. You sould display them in a browser e.g. FireFox. Or you should change the export configuration of your software/GPS to have plan txt. I've attached a sniplet from your xml in html and an image in my browser. regards, Zoltan On Thu, 23 Dec 2010, Agustin Lobo wrote: Hi! I have a problem with a kmz [1] (unzipped to kml [2]) file that once imported to QGIS has a table plenty of control characters etc [3]. I would appreciate if someone knowing the format could give a look to the kml file and tell me if the file is defective or we have a problem at importing some of them to QGIS, perhaps there are different versions of kml. The files are [1] https://sites.google.com/site/filestemp2/home/fluxpyr_221010_1.kmz [2] https://sites.google.com/site/filestemp2/home/fluxpyr_221010_1.kml [3] https://sites.google.com/site/filestemp2/home/kmlproblem.jpeg Thanks! Agus ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ 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] symbol levels with rule based rendering
Dear list members, I would highly value some advice with some coding problem I facewith rule-based rendering. I am preparing a patch and I have made extensive additions to many parts of the code to support some useful features to render map with complex symbology grammar (see http://trac.osgeo.org/qgis/ticket/3222 for a discussion). Still, I have problems with the symbol levels. I would like to enable symbol levels when several rules are matched. It would be useful when a feature (specially highways) should be represented with a combination of symbols. For instance, a road can be on a bridge, under a tunnel [with transparent tunnel symbol], in construction, bordered with trees, have restricted access, be a one-way road, etc. In many cases, it is possible to simply combine the symbols, e.g. one symbol for the road itself and another one for the bridge around it, and an arrow for one-ways. It would be possible to use only one rule for all highways (except motorways if shown with wider symbol). If we have 30 types of ways and 5 types of additional symbols (bridge, etc), we could then show many tags combinations with only 30+5=35 rules instead of 30*5=150. (Imagine if you add 10 scale-based rules: you got 1500 combinations!!). For the implementation, I modified the symbolForFeature function in src/core/symbology-ng/qgsrulebasedrendererv2.cpp Here is what I'm trying to do: For the first matched rule for a given feature, the code makes a copy of the rule's symbol. If other rules are matched, it merges the layers of the additional matched rule with the symbol(s) of previously matched rule(s). It also merges the information on symbol levels. Tests on rendering on small areas (with features matched by 2 rules) works partially: * the symbols are correctly merged. A new symbol is created and displayed, based on the symbology and levels of the matching rules 8-) * However, it modifies the symbol associated with the first matched rule and shown in the style sheet (if you open the layer properties, you see that the symbol has been permanently modified): the 1st matched rule is now represented by a combination of the 2 original symbols. This change is saved permanently in the Layer Properties. Similarly for symbol levels. 8-( * it crashes very often 8-( I've pasted my draft code here: http://trac.osgeo.org/qgis/ticket/3222#comment:7 I'm sure there are several incorrect thinks here. Anyone could help? Thanks and Merry Christmas! Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] manageR plugin: hot wo load R package sp
My guess is that this is a GDAL/OGR issue. Which version of GDAL do you have on your system? Carson If so, then running the following might help: #in the shell: which gdal-config gdal-config --prefix gdal-config --libs gdal-config --cflags gdal-config --version gdal-config --ogr-enabled gdal-config --formats # in R myPackages-installed.packages() myPackages[myPackages[,1] %in% c(rgdal, sp),] Mayeul ___ 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] Continuous Color style
Hi Luca,
I do not know how to do this in python, but I know how to do it with R.
Since R is GNU/GPL, you can probably take some code from it or use the
same algorithms. Have a look here for some examples:
http://www.r-bloggers.com/color-palettes-in-r/
This R blogger also give a link:
http://research.stowers-institute.org/efg/Report/UsingColorInR.pdf
which is useful even if you do not care about R (see p. 21 sqq on color
models, including Hue-Saturation-Value model, and the references at the
end).
If you are new to R, just type a function name without parenthesis and
type enter. Example session:
topo.colors
function (n, alpha = 1)
{
if ((n - as.integer(n[1L])) 0) {
j - n%/%3
k - n%/%3
i - n - j - k
c(if (i 0) hsv(h = seq.int(from = 43/60, to = 31/60,
length.out = i), alpha = alpha), if (j 0) hsv(h =
seq.int(from = 23/60,
to = 11/60, length.out = j), alpha = alpha), if (k
0) hsv(h = seq.int(from = 10/60, to = 6/60, length.out =
k),
alpha = alpha, s = seq.int(from = 1, to = 0.3, length.out =
k),
v = 1))
}
else character(0L)
}
Hope it helps
Mayeul
Le mercredi 10 novembre 2010 à 00:00 +0100, Luca Delucchi a écrit :
Hi everybody, I'm working on OGR2Layers python plugin, I'd like to
implement also continuous color style, but I didn't understand how can
I assign a style to each features. With also style type like unique
value or graduated I had all the classes of style (symbols class) with
continuous color I had only the first (min value) and the last (max
value), is there some mathematical functions for calculate the
intermediate classes?
Thank's
Luca
___
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
