[Qgis-developer] least surprise, or: which terms should be used?
Hi all. Thanks to Camilo, the analytical framework is now working, and many SAGA modules can be run smoothly from QGIS. See: https://github.com/polymeris/qgis/wiki/Module-Support https://github.com/polymeris/qgis/wiki/Tested-Modules Still several important things to do, but the structure is in place. Now we have to think about human interface. One thing is: which terms should be used? SAGA uses grid, whereas QGIS uses raster. To me, the idea is to have a consistent GUI in QGIS, so better use the QGIS terms not to scare off our users, but this could be confusing for previous SAGA users. I see this as a minor problema, but I may be wrong. Your comments will be appreciated. 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
Re: [Qgis-developer] least surprise, or: which terms should be used?
Hi! Hmm - for german translations grid is - as well as raster - translated as Raster .. so there should be no Problem .. For the english version: What about leaving grid as grid whenever it is used in SAGA-Modules (so you know that you are using a SAGA-Module) and using raster as usual in all other places? Don't know if thats a good idea .. Or write grid/raster when it is used in SAGA-Modules .. just as some suggestions .. regards Werner Am 19.08.2011 08:49, schrieb Paolo Cavallini: Hi all. Thanks to Camilo, the analytical framework is now working, and many SAGA modules can be run smoothly from QGIS. See: https://github.com/polymeris/qgis/wiki/Module-Support https://github.com/polymeris/qgis/wiki/Tested-Modules Still several important things to do, but the structure is in place. Now we have to think about human interface. One thing is: which terms should be used? SAGA uses grid, whereas QGIS uses raster. To me, the idea is to have a consistent GUI in QGIS, so better use the QGIS terms not to scare off our users, but this could be confusing for previous SAGA users. I see this as a minor problema, but I may be wrong. Your comments will be appreciated. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] least surprise, or: which terms should be used?
On Fri, Aug 19, 2011 at 8:49 AM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. Thanks to Camilo, the analytical framework is now working, and many SAGA modules can be run smoothly from QGIS. See: https://github.com/polymeris/qgis/wiki/Module-Support https://github.com/polymeris/qgis/wiki/Tested-Modules Still several important things to do, but the structure is in place. Now we have to think about human interface. One thing is: which terms should be used? SAGA uses grid, whereas QGIS uses raster. To me, the idea is to have a consistent GUI in QGIS, so better use the QGIS terms not to scare off our users, but this could be confusing for previous SAGA users. I see this as a minor problema, but I may be wrong. Also please note that SAGA grid is actualy a raster band in QGIS terminology, since one raster layer could contain several bands. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] least surprise, or: which terms should be used?
If you'll pardon a user intruding (again). I think Werner's point is valid, ie. if you're using the SAGA modules, then presumably you know what is meant in SAGA by grid. But, If you were going to select one, then please use raster. In my work situation, I find myself having to clarify what sort of thing I mean by grid far to frequently to want to introduce a another one. -ramon. On 19/08/2011, at 15:15 , Werner Macho wrote: Hi! Hmm - for german translations grid is - as well as raster - translated as Raster .. so there should be no Problem .. For the english version: What about leaving grid as grid whenever it is used in SAGA-Modules (so you know that you are using a SAGA-Module) and using raster as usual in all other places? Don't know if thats a good idea .. Or write grid/raster when it is used in SAGA-Modules .. just as some suggestions .. regards Werner Am 19.08.2011 08:49, schrieb Paolo Cavallini: Hi all. Thanks to Camilo, the analytical framework is now working, and many SAGA modules can be run smoothly from QGIS. See: https://github.com/polymeris/qgis/wiki/Module-Support https://github.com/polymeris/qgis/wiki/Tested-Modules Still several important things to do, but the structure is in place. Now we have to think about human interface. One thing is: which terms should be used? SAGA uses grid, whereas QGIS uses raster. To me, the idea is to have a consistent GUI in QGIS, so better use the QGIS terms not to scare off our users, but this could be confusing for previous SAGA users. I see this as a minor problema, but I may be wrong. Your comments will be appreciated. All the best. ___ 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] Updating to psycopg2.4.2 ?
Hi, I notice there is avaliable a new psycopg2. http://initd.org/psycopg/articles/2011/06/12/psycopg-242-released/ Should be effort to update the osgeo4w package to this new version ? Some QGIS plugins need psycopg2. I see this new version has some enhancement with PG 9.0 as reported here. http://initd.org/psycopg/articles/2011/05/11/psycopg-241-released/ Andrea. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] least surprise, or: which terms should be used?
Il 19/08/2011 09:15, Werner Macho ha scritto: What about leaving grid as grid whenever it is used in SAGA-Modules (so you know that you are using a SAGA-Module) and using raster as usual in all other places? This is why I'm asking: I think in this way the users will be confused: imagine running an hillshade analysis, once calling the original DEM raster and the other grid. Or write grid/raster when it is used in SAGA-Modules .. This could be cumbersome, as the word is repeated in most modules, sometimes several times each. Thanks for your thoughts. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] least surprise, or: which terms should be used?
Il 19/08/2011 09:20, Martin Dobias ha scritto: Also please note that SAGA grid is actualy a raster band in QGIS terminology, since one raster layer could contain several bands. True, even though: - most analyses will result in single band rasters, so terms will converge - the use of grid is unwarranted in any case - with the same argument, one could use raster band. 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
Re: [Qgis-developer] least surprise, or: which terms should be used?
Il 19/08/2011 09:21, Ramon Andinach ha scritto: I think Werner's point is valid, ie. if you're using the SAGA modules, then presumably you know what is meant in SAGA by grid. But, If you were going to select one, then please use raster. In my work situation, I find myself having to clarify what sort of thing I mean by grid far to frequently to want to introduce a another one. The plugin is meant to add SAGA functions to QGIS, so our main target should be QGIS users, not SAGA ones, I guess. However, life shouldn't be too difficult for anyone. Thanks. -- 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] QGIS Server under Windows
Hi All, especially Jürgen :) Jürgen, could you please review the present state in OsGeo4W and tell whether it is possible to make it working out of the box? What is missing? Maybe just a patch for Apache package? How many people and how much money do you need? :) I don't have any yet, but it would be a good starting point. Could you look at it? More and more users ask me about running the Server under Windows. Recently we gained the howto [1], however I don't know any case where it worked (except the case itself of course) :(( I believe we should be interested in helping small offices/organizations with a Windows server only to introduce the Server and build a QGIS system. Othwerwise, we should remove the Server from Windows builds and clearly state it's designed for Unix family only. The present situation makes an unproffesional impression, that we release something, that maybe works, maybe not... [1] http://www.qgis.org/wiki/QGIS_Server_Tutorial#Windows Server ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Server under Windows
I believe we should be interested in helping small offices/organizations with a Windows server only to introduce the Server and build a QGIS system. Othwerwise, we should remove the Server from Windows builds and clearly state it's designed for Unix family only. The present situation makes an unproffesional impression, that we release something, that maybe works, maybe not... Where did you get this impression that QGIS (Map) server does not work in Windows. QGIS (Map) server works in Windows before it works in Linux and Mac OS X. Have a look at this site (below). It is done in Windows first before Ubuntu and Mac OS X. http://karlinapp.ethz.ch/qgis_wms/configuration/ If you download the QGIS (Map) server manual from the link below. The screenshots in manual done are in Windows. http://karlinapp.ethz.ch/qgis_wms/documentation/index.html Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Server under Windows
Hi Noli The material on karlinapp is older than that on the wiki. Yes, there was a MingW compiled version used for teaching, but it is not current state of the software. It is better to go the osgeo4w way with visual studio compiler and to follow the tutorial on the wiki. Regards, Marco Am Freitag, 19. August 2011, 14.09:09 schrieb Noli Sicad: I believe we should be interested in helping small offices/organizations with a Windows server only to introduce the Server and build a QGIS system. Othwerwise, we should remove the Server from Windows builds and clearly state it's designed for Unix family only. The present situation makes an unproffesional impression, that we release something, that maybe works, maybe not... Where did you get this impression that QGIS (Map) server does not work in Windows. QGIS (Map) server works in Windows before it works in Linux and Mac OS X. Have a look at this site (below). It is done in Windows first before Ubuntu and Mac OS X. http://karlinapp.ethz.ch/qgis_wms/configuration/ If you download the QGIS (Map) server manual from the link below. The screenshots in manual done are in Windows. http://karlinapp.ethz.ch/qgis_wms/documentation/index.html Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions 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] Announcing Metatools plugin
Hi all, we pleased to announce the Metatools plugin for QGIS [1]. Plugin provides convenient interface for creating, editing and viewing metadata. Key features are: - supports vector and raster data - displaying metadata in the HTML format - two editing modes: full metadata tree and filtered necessary fields - templates for organization, license, workflow and data type sections - update or create metadata in batch mode - automatic extraction of some metadata such as extent, number of bands and data type - embedding processing logs into metadata - preview generation More detailed description available in article [2], currently only in Russian (English version coming soon). Source code hosted in GIS-Lab SVN repository [3] Please give it a go and we'd like to have feedback. Don't forget to turn on experimental plugins in your plugin installer. Have fun. [1] http://www.nextgis.ru/en/blog/metatools/ [2] http://gis-lab.info/qa/metatools.html [3] http://svn.gis-lab.info/metatools/trunk -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: QGIS Server under Windows
Hi Borys, On Fri, 19. Aug 2011 at 13:42:14 +0200, Borys Jurgiel wrote: Jürgen, could you please review the present state in OsGeo4W and tell whether it is possible to make it working out of the box? I thought that was the current state. What problems do you have? What is missing? Not sure. More and more users ask me about running the Server under Windows. Recently we gained the howto [1], however I don't know any case where it worked (except the case itself of course) :(( Um, it should work as fcgi - not running it as fcgi leads to the problem that you need to worry about where to put the DLLs. Jürgen [1] http://www.qgis.org/wiki/QGIS_Server_Tutorial#Windows Server -- 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 -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Announcing Metatools plugin
Il 19/08/2011 14:55, Alexander Bruy ha scritto: Key features are: - supports vector and raster data - automatic extraction of some metadata such as extent, number of bands and data type Thanks. I still have problems to extract layer parameters to metadata XML for shp though: Operation can't be completed: `/home/paolo/Desktop/Documenti/Didattica/home/comuni.shp|layerid=0' does not exist in the file system, and is not recognised as a supported dataset name. 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] error on shape file read and write
hi all, anybody interested in little green men (android) bug hunting? actually it is qgis stuff: when I try to create a new shape file the app crashes. here all the infos [0] the files are created but I dont know if they would be usable cheers Marco [0]https://gist.github.com/1156884 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Announcing Metatools plugin
Hi Paolo, fixed in 0.1.11. 2011/8/19 Paolo Cavallini cavall...@faunalia.it: Thanks. I still have problems to extract layer parameters to metadata XML for shp though: Operation can't be completed: `/home/paolo/Desktop/Documenti/Didattica/home/comuni.shp|layerid=0' does not exist in the file system, and is not recognised as a supported dataset name. -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] least surprise, or: which terms should be used?
Now we have to think about human interface. One thing is: which terms should be used? SAGA uses grid, whereas QGIS uses raster. To me, the idea is to have a consistent GUI in QGIS, so better use the QGIS terms not to scare off our users, but this could be confusing for previous SAGA users. I see this as a minor problema, but I may be wrong. Replaced grid and gridd for raster. Of course, the question applies to shapes, vector/vector feature and probably other SAGA terms. Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Announcing an IPython plugin
New (Experimental!) Plugin I just uploaded an alpha version of a plugin that allows an IPython kernel to be integrated into QGIS. This in turn allows external IPython-powered consoles to connect to QGIS and execute commands or inspect data. Version 0.2 of the plugin is now available from PyQGIS and is flagged Experimental: http://spatialserver.net/pyqgis_1.0/contributed/ipython_console.zip I am making the announcement here, because I feel that the current state of the plugin makes it most interesting to developers. I have tested the plugin with QGIS 1.7.0 on OS X 10.6 and Ubuntu 11.4 and it appears to be usable. Bug reports and pull requests are welcomed at GitHub: https://github.com/Sharpie/qgis-ipython What is IPython? = IPython is a __really__ nice shell for performing interactive work in the Python programming language. Some killer features IPython provides compared to the standard Python console are: - Tab completion for object and method names. - Function call tips that provide information about arguments on-the fly. - Easy access to docstrings. - magic commands that allow users to turn complex function calls into simple, customized command lines. Additionally, the v0.11 release completely re-factored the project and brought about many exciting changes: - A distributed two-process system where computational kernels handle the details of executing code and may be controlled by one or more console processes that handle the details of sending user input and formatting kernel output. - A new PyQt-based console with plenty of neat tricks such as Pygments-based highlighting of source code and inline display of Matplotlib graphs. - A high-level framework for performing parallel computing in an interactive fashion. For more information about IPython, see: The IPython website: http://www.ipython.org The manual section on interactive computing: http://ipython.org/ipython-doc/stable/interactive/index.html A talk by Fernando Perez at SciPy 2011 which details many features of v0.11: http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectureForInteractiveAndParallel How Does the Plugin Work? = The IPython plugin requires following dependencies to be installed: - Python 2.6 or 2.7 - IPython v0.11 or v0.12-dev - PyZMQ - Pygments - Matplotlib Unfortunately, Windows users are currently out of luck as QGIS appears to be pinned to the version of Python provided by OSGEO4W which is currently at 2.5.x. The plugin provides one new entry to the Plugins menu called External IPython Console. This launches an external process, based on `ipython-qtconsole`, that communicates with an IPython kernel __running inside of QGIS__. This means that every command entered through the console is actually executed inside of QGIS. The only downside I have noticed to running the console in a process separated from QGIS is that the IPython console window cannot be docked or otherwise integrated into the QGIS GUI. __IMPORTANT NOTE__ One currently has to be careful when closing external Python consoles because they can terminate the IPython kernel running inside of QGIS which has the unfortunate side effect of causing QGIS to quit. The recommended way to shut down an external console is to close the window and select No, just this Console when asked if you would like to quit the Kernel. Choosing Yes, quit everything or running the `exit()` command in the IPython shell will cause QGIS to quit as well. I am working on finding a way around this issue so that it will be more difficult for users to accidentally terminate QGIS when all they wanted to do was close the IPython console. Future Directions = There are plenty of things that need to be cleaned up in order to achieve a smoother user interface such as better error messages and figuring out how to handle situations where the kernel dies and needs to be restarted. There are also many exciting possibilities that could be explored such as using the parallel computing framework to build faster tools for GIS analysis or using the IPython communication protocol make it easier for other programs to communicate with QGIS. If QGIS upgrades to version 2 of the SIP API, another exciting development possibility is to replace the current Python console with an IPython console that does not run in a separate process. I have done some initial work on this front and managed to get a proof-of-concept build that successfully ran the IPython console: https://github.com/Sharpie/Quantum-GIS/tree/ipython-console The biggest challenge in upgrading to version 2 of the SIP API appears to finding areas in the Python code where QString methods are used and replacing them with equivalent Python string methods. The branch above is very much an experiment---many things were simply commented out. -Charlie ___
[Qgis-developer] QgsExpression: replacement for QgsSearchString
Hi everyone recently I have been trying to fix some flaws in search string implementation and it turned out that rather than fixing them one-by-one it will be easier to rewrite that code completely. Search string and associated searching in attribute table was one of my first contributions to QGIS and my first attempt to write a parser and an evaluator. QgsExpression is my second attempt :-) The main reason for the redesign was to bring the evaluation closer to SQL semantics and to clean the code which started to be hard to maintain. QgsExpression is meant to be a replacement for QgsSearchString class. Most of the changes are under the hood: - fixed and simplifed the parser grammar and tree creation - simplified lexer - only one evaluation routine (instead of separate getValue/checkAgainst) - correct handling of NULL values and three-value logic from SQL (true, false, unknown) - fixed error reporting - easily extensible list of functions, saner evaluation of expressions - using QVariant for return values instead of a special type - slightly faster evaluation - a more suitable class name - tests included (!!!) :-) Only few changes are visible for users: - spaces were removed from to int, to real and to string functions because function names must not contain spaces - null values are handled correctly by the functions and operators - errors are reported when conversions between types fail Btw. type conversions (currently supporting null, int, double, string) are implemented in many different ways in databases. I have done some tests on sqlite3, postgresql and mysql and many times there was no consensus what the outcome of an evaluation should be: - 7 '6x' :: mysql=1, sqlite=0, postgresql=error - 7 '6' :: mysql=1, sqlite=0 (!), postgresql=1 - '6x' :: mysql=6 (+warning), sqlite=6, postgresql=error - '3'+'5' :: mysql=8, sqlite=8, postgresql=error - 3/5 :: mysql=0.6, sqlite=0, postgresql=0 - length(123) :: mysql=3, sqlite=3, postgresql=error - 0 or 1 :: mysql=1, sqlite=1, postgresql=error - 0 or 'x' :: mysql=0 (+warning), sqlite=0, postgresql=error 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 The code is here: https://github.com/wonder-sk/Quantum-GIS/tree/expr If there are no objections I will apply the changes to master in few days. Given that I have been simultaneously writing unit tests I am quite confident that there are not too many bugs (unit tests really help!). In that branch I have replaced all the occurrences of search string with expressions. So playing with search in attribute table or doing calculation in field calculator will use the new engine. Martin ___ 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
[Qgis-developer] QGISfor android weekly report #11
it is wit great pleasure that I send you thereports of a super successfull week. Cheers Marco http://www.bernawebdesign.ch/byteblog/2011/08/19/qgis-on-android-has-complete-gui-and-supports-translations/ http://www.bernawebdesign.ch/byteblog/2011/08/19/qgis-data-providers-and-map-canvas/ http://www.opengis.ch ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
