Re: [Qgis-developer] Fwd: [Board] Would you be concerned if the GeoServices REST API became an OGC standard?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 05/05/2013 11:28, Barry Rowlingson ha scritto: On Sat, May 4, 2013 at 1:06 PM, Nathan Woodrow madman...@gmail.com wrote: I'm starting to wonder if anything becoming a OGC is a good thing. What impact would this have on QGIS? For QGIS it would mean you could create a way to read GeoServices REST API-compliant data from servers. The specification would be open and so you could check your implementation against the spec to make sure your code is creating the right requests. However, unless an open-source implementation of the server is available, you won't be able to test it against a real server unless you pay up, or are beholden to the good nature of someone who has paid up. Imagine testing the WMS code in Qgis only by inspecting the URL it creates, and not by whether a WMS server returns the image you were expecting. IMHO, this would put an additional burden (supporting Yet Another standard), being at disadvantage with the proprietary equivalent, without any possible advantage. An arms race among standards in which we (and I believe the GFOSS world at large) would only have to lose. If we agree with this, I believe we should raise our voice with OSGeo. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlGHSaYACgkQ/NedwLUzIr5J1ACgrt9tsUb+w4NMuGsbq+CgXVP7 GU0AoJMe9j9f0a0SV6SoohQHSquIgpuU =+UCu -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SEXTANTE commander
Rather then making it a plugin I would prefer to see it built in like the Python console. You can still leave it in Python but just load it like we do with the Python console by using QgsPythonRunner and calling the module. sounds good to me. Anyway, the code is there, so please you or someone else, feel free to take it and put it whenever it fits better. I will try to improve it a bit and then move it and put it as a built in as you suggested I like the idea of being able to expand it by using simple Python functions. I might be good in the future to have a decorator that has some basic arg validation or things like checking if any of the arguments are callable and returning the result. You could chain methods by handling the callable switch. Sure, there is plenty of room for improvements... I hope that people will have new ideas and we can keep improving it for the current basic version I think we might just need to tweak that combo box a little. It looks a bit strange in the notification area that small. I went the easy way and used a combo box, but I think that actually it would be better to just use a tet box with a completer. Another thing to fi in the UI is that it does not resize when you resize the QGIS window, so it can leave an ugly bar in the middle of the screen... Thanks for your comments! Victor ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Manager - consultation for the best solution
Hi Borys (sorry for the lag - I have been on holiday last week) Not sure how far you got with the implementation, but for the record I would surely choose the solution 2. It is generally a good idea to keep core structures separated from Qt model - ideally the model should be acting just as an adapter to the core data structure. If we decide to change the plugin manager dialog and model, it will not affect the way how other parts of QGIS deal with plugins. Martin On Tue, Apr 30, 2013 at 12:11 PM, Borys Jurgiel li...@borysjurgiel.pl wrote: I need your advice which direction should we take to store plugin metadata in QGIS 2.x. I started to work on Solution 2, but now I think maybe the first is better? It looks much simpler anyway. I'd be happy to see some response asap, as I'm going to implement it until lunch and go further today... :) SOLUTION 1: The QgsPluginManager is created as soon as application starts and it persists all the application life time. Once it's created, it reads installed plugins to the QListView model (like it used to do now), and then Python (if available) uses QgsPluginManager API to add extra metadata (of available plugins) directly to the model. So QgisApp::showPluginManager() only calls exec() of existing QgsPluginManager instance. SOLUTION 2: The QgsPluginManager only exists within QgisApp::showPluginManager() (like now), so I create a new global C++ data structure for all plugin metadata: QgsPluginMetadataRegistry. When application starts, C++ pushes metadata of installed plugins (both C++ and Py) there, then Python (if available) adds an extra metadata for available plugins. Finally, when an user opens the PluginManager, it has an access to the joined metadata. All filtering is done by QSortFilterProxyModel. In addition, this QgsPluginMetadataRegistry class provides transmitting slots- signals for communication from C++ to Python. For example: because the install procedure stays in Python and the Install button is ported to C++, we need a way to connect signal from the C++ button to Python. But in this solution QgsPluginManager is created on user's click, while the Python is already loaded on startup. So first Python (on startup) connects to signal from QgsPluginMetadataRegistry, then the manager (when created) can ping this transmitting slot. I guess it's the simplest way (within solution 2). == Regardless the solution 1 or 2, I'd like to extend QgsPluginMetadata class to make it more multipurpose. Now it's only used internally in QgsPluginRegistry and only contains two fields. I'd add the complete field set (what won't bother QgsPluginRegistry) and use it also as a main metadata item everywhere. Everywhere means: In solution 1 - QgsPluginMetadata as a PLUGIN_DATA_ROLE data in QListView item In solution 2 - QgsPluginMetadata as a base for QgsPluginMetadataRegistry I'd also remove QgsPluginItem class and include its fields into QgsPluginMetadata. So the present state is: 1. QgsPluginRegistry - the registry of loaded plugins. Data are stored in QMapQString, QgsPluginMetadata 2. QgsPluginMetadata - a simple class for the map above. It's only used internally within QgsPluginRegistry. It only contains thee fields: name, library and a pointer to the living plugin object. 3. QgsPluginItem - seems it's obsolete and could be easily merged with QgsPluginMetadata. More details: it's similar to QgsPluginMetadata, just contains another fields and is used in one place only: in QgisApp::showPluginManager() to get data from QgsPluginManager::getSelectedPlugins(). The proposed solution: 1. QgsPluginRegistry - leave it as is 2. QgsPluginMetadataRegistry (only solution 2): parallel to QgsPluginRegistry 3. QgsPluginItem - remove it and include its two fields to QgsPluginMetadata 4. QgsPluginMetadata - make it an universal plugin metadata object == In all cases, all the QgsDetailed... classes are not used anymore, and they only stay for GRASS Plugin. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] crash while setting attributes of a new feature
Hi all, I got a crash when I did this: fields = layer.dataProvider().fields() f = QgsFeature() f.setFields(fields) for field in fields: f[field.name()] = QVariant(1) Using QVariant or not. What did I (again) did wrong Greetings, Denis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] crash while setting attributes of a new feature
hi denis I dont have the new api completely in mind, but maybe this [0] can help you. [0] http://lists.osgeo.org/pipermail/qgis-developer/2013-February/024278.html Marco Bernasocchi (mobile) http://opengis.ch On May 6, 2013 11:27 AM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi all, I got a crash when I did this: fields = layer.dataProvider().fields() f = QgsFeature() f.setFields(fields) for field in fields: f[field.name()] = QVariant(1) Using QVariant or not. What did I (again) did wrong Greetings, Denis __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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] crash while setting attributes of a new feature
Hi Marco, Thanks for your reply. I think this is suposed to work since __setitem__ is defined in the sip file [0] [0] https://github.com/qgis/Quantum-GIS/blob/master/python/core/qgsfeature.sip#L62 On 05/06/2013 11:47 AM, Marco Bernasocchi wrote: hi denis I dont have the new api completely in mind, but maybe this [0] can help you. [0] http://lists.osgeo.org/pipermail/qgis-developer/2013-February/024278.html Marco Bernasocchi (mobile) http://opengis.ch On May 6, 2013 11:27 AM, Denis Rouzaud denis.rouz...@gmail.com mailto:denis.rouz...@gmail.com wrote: Hi all, I got a crash when I did this: fields = layer.dataProvider().fields() f = QgsFeature() f.setFields(fields) for field in fields: f[field.name http://field.name()] = QVariant(1) Using QVariant or not. What did I (again) did wrong Greetings, Denis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Transparency options for background disappeared in Composer items
Hi All, Last week, i could specify if a composer item had a transparent background or not. Today, I only have a color option for background with a alpha band value. I couldn't have it opaque . Does alpha value works? I think alpha tuning must be used by powerusers only. 90 % user don't know about alpha bands. I preferred by far a checkbox and a transparency slider. Why did they disappear? Did I miss something? Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Transparency-options-for-background-disappeared-in-Composer-items-tp5051541.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Transparency options for background disappeared in Composer items
Just a complement. I did get transparency work with alpha band, but it needed a full refresh of composer to start working correctly. Could we simply rename Alpha channel to Alpha channel (transparency) in color picker, so that beginners know where to search for new forms of 1.8 options? Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Transparency-options-for-background-disappeared-in-Composer-items-tp5051541p5051542.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Transparency options for background disappeared in Composer items
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 06/05/2013 12:26, Régis Haubourg ha scritto: Just a complement. I did get transparency work with alpha band, but it needed a full refresh of composer to start working correctly. Could we simply rename Alpha channel to Alpha channel (transparency) in color picker, so that beginners know where to search for new forms of 1.8 options? Maybe better Transparency (Alpha channel). All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlGHh+QACgkQ/NedwLUzIr6EfQCfRxD43P/XqMD2taeXKrjpAgyl ix0AoLAu8Oeu1Qp0a0qaZwk1qofqLWek =G/jf -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] many SVG symbols disappeared
Yes actually I've been doing some work on the SVG library, and removed some of the symbols I though were looking a bit amateur or old-fashioned. But it may be that I've been too drastic, and if anyone feels we should keep them, I'm OK with it too ! 2013/5/5 Tim Sutton li...@linfiniti.com Hi On Sat, May 4, 2013 at 11:28 AM, Giovanni Manghi giovanni.man...@faunalia.pt wrote: Hi all, I just installed the latest master available for Ubuntu and noticed that many classic qgis SVG symbols have disappeared (most of north arrows for example), is this on purpose or is a bug? I think it is a result of me prematurely merging a pull request. I'll take a look. Regards Tim cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- 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] New Manager - consultation for the best solution
Not sure how far you got with the implementation, but for the record I would surely choose the solution 2. It is generally a good idea to keep core structures separated from Qt model - ideally the model should be acting just as an adapter to the core data structure. If we decide to change the plugin manager dialog and model, it will not affect the way how other parts of QGIS deal with plugins. Actually there was a concord (well, only a few folks discussed it) we should keep the metadata inside manager, as there is no use for it outside, so I'm implementing a mixed solution: replacing the messy QgsPluginMetadata and QgsPluginItem classes with one robust QgsPluginMetadata, but wih no external QgsPluginMetadataRegistry. It's not very likely other part of QGIS could be interested in plugin metadata (except Python plugins, but it's already implemented in PyQGIS). I leave all the stuff in the src/app directory, what isn't available by API, so all communication with Python (eg. adding metadata of available plugins) is done by QgsInterface::doSomethingWithManager(). What shhould I do in your approac h? Move QgsPluginMetadata, QgsPluginMetadataRegistry to the src/core directory? Is it worth the effort? I guess it's the only problem for me to adapt your solution. Anyway, I'll work on it from Wednesday, so in first step I'll evaluate time needed for your suggestion. Considering extremely limited time (both: available for me and the delay in QGIS schedule) and the fact I'm not very fast in c++ we will see... In the worst case I can go a mixed way to allow further improvements without backward API breaks. Dnia poniedziałek, 6 maja 2013 o 09:54:04 Martin Dobias napisał(a): Hi Borys (sorry for the lag - I have been on holiday last week) Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Size scale field not working with centroid fill
Hello all, Using Size scale field does not seam to be working with centroid fill, both in 1.8 and master. Is this intended? Does anyone know if there is a feature\bug ticket for it? I could not find one. Alexandre Neto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Size scale field not working with centroid fill
Alexandre, Might be linked to this issue: http://hub.qgis.org/issues/7738 -- centroid fill always use map unit even when set to millimetres. Mathieu On 6 May 2013 18:09, Alexandre Neto senhor.n...@gmail.com wrote: Hello all, Using Size scale field does not seam to be working with centroid fill, both in 1.8 and master. Is this intended? Does anyone know if there is a feature\bug ticket for it? I could not find one. Alexandre Neto ___ 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] Size scale field not working with centroid fill
Hi Mathieu, thanks for your answer. I don't think it's the same problem (although I have noticed it too), as that issue only affect master, whether the issue I'm talking about affect both 1.8 and master, but only in centroid fill (in polygon layers), in point layer it works well. Not sure if it's a bug, a not implemented feature, or simply a not intended one. Alexandre Neto On Mon, May 6, 2013 at 12:15 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote: Alexandre, Might be linked to this issue: http://hub.qgis.org/issues/7738 -- centroid fill always use map unit even when set to millimetres. Mathieu On 6 May 2013 18:09, Alexandre Neto senhor.n...@gmail.com wrote: Hello all, Using Size scale field does not seam to be working with centroid fill, both in 1.8 and master. Is this intended? Does anyone know if there is a feature\bug ticket for it? I could not find one. Alexandre Neto ___ 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] Transparency options for background disappeared in Composer items
Paolo Cavallini wrote Maybe better Transparency (Alpha channel). All the best. Agreed. ticket filed here: http://hub.qgis.org/issues/7771 if someone has some time to take it, that would save me lots of efforts in the hotline period after 1.8 to 2.0 switch. régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Transparency-options-for-background-disappeared-in-Composer-items-tp5051541p5051560.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] many SVG symbols disappeared
Yeah can we have those back. People are free to remove the svgs if they don't like but I wouldn't remove them unless there is technical reason. - Nathan On Mon, May 6, 2013 at 8:51 PM, Olivier Dalang olivier.dal...@gmail.comwrote: Yes actually I've been doing some work on the SVG library, and removed some of the symbols I though were looking a bit amateur or old-fashioned. But it may be that I've been too drastic, and if anyone feels we should keep them, I'm OK with it too ! 2013/5/5 Tim Sutton li...@linfiniti.com Hi On Sat, May 4, 2013 at 11:28 AM, Giovanni Manghi giovanni.man...@faunalia.pt wrote: Hi all, I just installed the latest master available for Ubuntu and noticed that many classic qgis SVG symbols have disappeared (most of north arrows for example), is this on purpose or is a bug? I think it is a result of me prematurely merging a pull request. I'll take a look. Regards Tim cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] many SVG symbols disappeared
I was asking that question on this thread : http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-td5040508.html#a5046486 Maybe I didn't emphasize enough on the deletion of symbols... IMO, the most elegant solution is to keep only the good-looking symbols so we provide a simple and consistent library, and then to provide a link on the website to download the unmodified 1.8 symbol library in case one needs to keep full backwards compatibility (it's quite easy to install : you just have to replace the SVG folder in your installation folder). The whole pull request already breaks backwards compatibility with all other symbols, since by removing their background, the may become unreadable on most of the maps... So if the priority is the keep old projects looking the same rather than having a clean and consistent library, the best is not to change the svg library at all. (just as an illustration, do you really think it's pertinent to keep this in the library ? : https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_layers.pnghttps://www.dropbox.com/s/pgen6dae66xjml2/north-arrow_10_with_map_layers.svg ) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Could ubuntugis PPA be a recommended repository for QGIS 2.0 on Ubuntu ?
Hi, I wonder if ubuntugis PPA could be a recommended and only one repository for QGIS 2.0 on Ubuntu instead of distribution packaged version and package from 'http://qgis.org/debian'. Reasons are following: 1. Currently there are many installation sources for the same Ubuntu platform which is confusing, providing different features and causing the mess when people trying to switch between them. 2. Distribution package in Ubuntu is outdated, I doubt anyone i using it. 3. Package from 'http://qgis.org/debian' is build with outdated dependencies, at least often missing upstream fixes from maintaining releases and when the time is going on they are older and older. 4. UbuntuGIS can provide a solid platform for GIS packages maintained by skilled Debian and Ubuntu devs, can quickly apply fixes from maintaining releases of all dependencies and QGIS itself when provided by upstream. UbuntuGIS can upgrade all packages from time to time to keep version up to date. 5. Using uniform and only one package source can lower maintainig costs either to build and test packages and also when trying to solve bugs. 5. PPAs could depend on each other so one can create separate PPA for 1.x version and separate for version 2.x which will depend on some general PPA providing all build dependencies. 6. Using UbuntuGIS in more massive scale can bring more credit and satisfaction for people who maintain it. What needs to be done ?: 1. Fine tuned Debian 'control' file to prevent conflicting installation of packages after upgrading from distribution packages to UbuntuGIS (this is the case for example in GDAL) 2. More clearly described relation between ubuntugis-stable and ubuntugis-unstable repositories (when the packages move from unstable to stable ...) 3. Maybe creation of more complex PPA architecture for development, staging and production. Looking for you opinions. -- Ivan Mincik ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Could ubuntugis PPA be a recommended repository for QGIS 2.0 on Ubuntu ?
Hi Ivan, On Mon, 06. May 2013 at 14:58:55 +0200, Ivan Mincik wrote: I wonder if ubuntugis PPA could be a recommended and only one repository for QGIS 2.0 on Ubuntu instead of distribution packaged version and package from 'http://qgis.org/debian'. Recommended: ok. Only: why? I don't see the problem with a less intrusive version (ie. qgis on plain ubuntu) and a more intrusive version (ie. qgis on ubuntugis). Switching between the same versions from different repositories might be a problem, but I suppose that doesn't happen often. Maintaining both versions wasn't a big problem in the past, so I don't expect it be come one in future. The packages are only built on release, with the current dependencies at that point - and only updated, when manually when necessary. But that also applies to both repositories. What needs to be done ?: 1. Fine tuned Debian 'control' file to prevent conflicting installation of packages after upgrading from distribution packages to UbuntuGIS (this is the case for example in GDAL) 0. Report those problems. 2. More clearly described relation between ubuntugis-stable and ubuntugis-unstable repositories (when the packages move from unstable to stable ...) Yes, that would be nice to know - I only upload to ubuntugis-unstable ;) Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Could ubuntugis PPA be a recommended repository for QGIS 2.0 on Ubuntu ?
On 05/06/2013 03:50 PM, Jürgen E. Fischer wrote: Hi Ivan, On Mon, 06. May 2013 at 14:58:55 +0200, Ivan Mincik wrote: I wonder if ubuntugis PPA could be a recommended and only one repository for QGIS 2.0 on Ubuntu instead of distribution packaged version and package from 'http://qgis.org/debian'. Recommended: ok. Only: why? I don't see the problem with a less intrusive version (ie. qgis on plain ubuntu) and a more intrusive version (ie. qgis on ubuntugis). Ubuntu distribution packages stick with 1.7 version which is obsolete. Switching between the same versions from different repositories might be a problem, but I suppose that doesn't happen often. Maintaining both versions wasn't a big problem in the past, so I don't expect it be come one in future. Maybe a bug fixing could be easier when you deal for example with lesser GDAL versions. Also when a time goes on distribution libraries goes older and more version dependent workarounds must be provided (for example GDAL 1.10 has better support for PostGIS raster and SpatiaLite) The packages are only built on release, with the current dependencies at that point - and only updated, when manually when necessary. But that also applies to both repositories. PPA build could be less error prone than self made PBuilder. I am often not sure if my pbuilder updated build deps when building packages depending each other. What needs to be done ?: 1. Fine tuned Debian 'control' file to prevent conflicting installation of packages after upgrading from distribution packages to UbuntuGIS (this is the case for example in GDAL) 0. Report those problems. Yes, I am going to fix them in my PPA and send a patch. But I am not sure where reports for PPAs should be submitted. 2. More clearly described relation between ubuntugis-stable and ubuntugis-unstable repositories (when the packages move from unstable to stable ...) Yes, that would be nice to know - I only upload to ubuntugis-unstable ;) What I am missing for PPAs is some kind of wiki where these informations could be placed. Jurgen, thanks for your Debian/Ubuntu packaging. -- Ivan Mincik ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Could ubuntugis PPA be a recommended repository for QGIS 2.0 on Ubuntu ?
On 05/06/2013 07:40 AM, Ivan Mincik wrote: On 05/06/2013 03:50 PM, Jürgen E. Fischer wrote: Hi Ivan, On Mon, 06. May 2013 at 14:58:55 +0200, Ivan Mincik wrote: I wonder if ubuntugis PPA could be a recommended and only one repository for QGIS 2.0 on Ubuntu instead of distribution packaged version and package from 'http://qgis.org/debian'. Recommended: ok. Only: why? I don't see the problem with a less intrusive version (ie. qgis on plain ubuntu) and a more intrusive version (ie. qgis on ubuntugis). Ubuntu distribution packages stick with 1.7 version which is obsolete. That's a function of inheriting official packages from upstream Debian. Get newer versions into Debian and it trickles down. Switching between the same versions from different repositories might be a problem, but I suppose that doesn't happen often. I think new users get confused about which one they really want and the reality is most actually want the Master builds because of features (but that's impractical because of stability). So we should make one of the options the Recommended. For me this has always been ubuntugis-unstable, primarily because the newer gdal builds support the formats people are trying to work with and some of the nastier bugs occur there (if you can't read/write your data everything else is pointless). Maintaining both versions wasn't a big problem in the past, so I don't expect it be come one in future. Maybe a bug fixing could be easier when you deal for example with lesser GDAL versions. Also when a time goes on distribution libraries goes older and more version dependent workarounds must be provided (for example GDAL 1.10 has better support for PostGIS raster and SpatiaLite) The packages are only built on release, with the current dependencies at that point - and only updated, when manually when necessary. But that also applies to both repositories. PPA build could be less error prone than self made PBuilder. I am often not sure if my pbuilder updated build deps when building packages depending each other. What needs to be done ?: 1. Fine tuned Debian 'control' file to prevent conflicting installation of packages after upgrading from distribution packages to UbuntuGIS (this is the case for example in GDAL) 0. Report those problems. Yes, I am going to fix them in my PPA and send a patch. But I am not sure where reports for PPAs should be submitted. http://trac.osgeo.org/ubuntugis/ Unless it's an error in the DebianGIS version which we pull from their git repo. I need to go looking for where to report those besides mailing list and IRC. 2. More clearly described relation between ubuntugis-stable and ubuntugis-unstable repositories (when the packages move from unstable to stable ...) Yes, that would be nice to know - I only upload to ubuntugis-unstable ;) That is the correct place. Sadly the naming convention borrowed from Debian causes nothing but confusion. Testing - where to put stuff when you're not sure if it will work. Unstable - where you put stuff you want people to use. Stable - where we move things to from Unstable when a newer version is staged to go into unstable, so that if you want to stick to the older one you can by switching to stable. Or if you need to get the older version or older deps for some reason (regressions). What I am missing for PPAs is some kind of wiki where these informations could be placed. http://trac.osgeo.org/ubuntugis/ Thanks, Alex ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Could ubuntugis PPA be a recommended repository for QGIS 2.0 on Ubuntu ?
On Mon, May 6, 2013 at 7:57 PM, Alex Mandel tech_...@wildintellect.comwrote: On 05/06/2013 07:40 AM, Ivan Mincik wrote: On 05/06/2013 03:50 PM, Jürgen E. Fischer wrote: Hi Ivan, On Mon, 06. May 2013 at 14:58:55 +0200, Ivan Mincik wrote: I wonder if ubuntugis PPA could be a recommended and only one repository for QGIS 2.0 on Ubuntu instead of distribution packaged version and package from 'http://qgis.org/debian'. Recommended: ok. Only: why? I don't see the problem with a less intrusive version (ie. qgis on plain ubuntu) and a more intrusive version (ie. qgis on ubuntugis). Ubuntu distribution packages stick with 1.7 version which is obsolete. That's a function of inheriting official packages from upstream Debian. Get newer versions into Debian and it trickles down. Yes, I understand. Switching between the same versions from different repositories might be a problem, but I suppose that doesn't happen often. I think new users get confused about which one they really want and the reality is most actually want the Master builds because of features (but that's impractical because of stability). So we should make one of the options the Recommended. For me this has always been ubuntugis-unstable, primarily because the newer gdal builds support the formats people are trying to work with and some of the nastier bugs occur there (if you can't read/write your data everything else is pointless). Maintaining both versions wasn't a big problem in the past, so I don't expect it be come one in future. Maybe a bug fixing could be easier when you deal for example with lesser GDAL versions. Also when a time goes on distribution libraries goes older and more version dependent workarounds must be provided (for example GDAL 1.10 has better support for PostGIS raster and SpatiaLite) The packages are only built on release, with the current dependencies at that point - and only updated, when manually when necessary. But that also applies to both repositories. PPA build could be less error prone than self made PBuilder. I am often not sure if my pbuilder updated build deps when building packages depending each other. What needs to be done ?: 1. Fine tuned Debian 'control' file to prevent conflicting installation of packages after upgrading from distribution packages to UbuntuGIS (this is the case for example in GDAL) 0. Report those problems. Yes, I am going to fix them in my PPA and send a patch. But I am not sure where reports for PPAs should be submitted. http://trac.osgeo.org/**ubuntugis/ http://trac.osgeo.org/ubuntugis/ Unless it's an error in the DebianGIS version which we pull from their git repo. I need to go looking for where to report those besides mailing list and IRC. Thanks for info. 2. More clearly described relation between ubuntugis-stable and ubuntugis-unstable repositories (when the packages move from unstable to stable ...) Yes, that would be nice to know - I only upload to ubuntugis-unstable ;) That is the correct place. Sadly the naming convention borrowed from Debian causes nothing but confusion. Testing - where to put stuff when you're not sure if it will work. Unstable - where you put stuff you want people to use. Stable - where we move things to from Unstable when a newer version is staged to go into unstable, so that if you want to stick to the older one you can by switching to stable. Or if you need to get the older version or older deps for some reason (regressions). Hm, if it is like this, it is really sooo confusing. Is there any possibility to improve this workflow ? What I am missing for PPAs is some kind of wiki where these informations could be placed. http://trac.osgeo.org/**ubuntugis/ http://trac.osgeo.org/ubuntugis/ Thanks, Alex ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] many SVG symbols disappeared
Hi On Mon, May 6, 2013 at 2:31 PM, Olivier Dalang olivier.dal...@gmail.com wrote: I was asking that question on this thread : http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-td5040508.html#a5046486 Maybe I didn't emphasize enough on the deletion of symbols... IMO, the most elegant solution is to keep only the good-looking symbols so we provide a simple and consistent library, and then to provide a link on the website to download the unmodified 1.8 symbol library in case one needs to keep full backwards compatibility (it's quite easy to install : you just have to replace the SVG folder in your installation folder). The whole pull request already breaks backwards compatibility with all other symbols, since by removing their background, the may become unreadable on most of the maps... So if the priority is the keep old projects looking the same rather than having a clean and consistent library, the best is not to change the svg library at all. (just as an illustration, do you really think it's pertinent to keep this in the library ? : https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_layers.png ) Yeah that ain't pretty... Personally I like Oliver's patch and I think we should clean up house for 2.0. Keeping compatibility is useful but most of my project files from 1.8 are already broken to some degree and I would prefer we do all the big changes in 2.0 and then become more conservative in subsequent 2.x releases. 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
Re: [Qgis-developer] [Ubuntu] Could ubuntugis PPA be a recommended repository for QGIS 2.0 on Ubuntu ?
Ivan wrote: Ubuntu distribution packages stick with 1.7 version which is obsolete. Alex: That's a function of inheriting official packages from upstream Debian. which is a function of nobody providing the Debian packages there.. Get newer versions into Debian and it trickles down. which is a function of some of _us_ stepping up to help. the situation with qgis in debian has been the same for years. :-( Unless it's an error in the DebianGIS version which we pull from their git repo. I need to go looking for where to report those besides mailing list and IRC. if you need something sync'd in the DebianGIS side of things, let me know, /or ping the DebianGIS mailing list. Frankie is usually on IRC too. Yes, that would be nice to know - I only upload to ubuntugis-unstable ;) That is the correct place. Sadly the naming convention borrowed from Debian causes nothing but confusion. many of you already know this well, but since there is divergence here I thought to explain the Debian convention anyway for those that don't, Testing - where to put stuff when you're not sure if it will work. in the Debian world that's the experimental branch, not testing. testing is automatically populated from unstable pkgs a fixed amount of time after it has been uploaded, with no (or at least fewer) bugs vs. the last version, and no other dependency conflicts. Unstable - where you put stuff you want people to use. in the Debian world it's simply where new untested packages get uploaded. I would not recommend for a new user to use Debian's unstable branch unless they knew enough to dig themselves out of trouble. (it's called sid [from Toy Story] for a reason, 'cause it breaks stuff) Stable - where we move things to from Unstable when a newer version is staged to go into unstable, so that if you want to stick to the older one you can by switching to stable. Or if you need to get the older version or older deps for some reason (regressions). in the Debian world stable simply the testing branch after some time (often ~6 months) of new version freeze, which then gets blessed with a version number. Similar to Ubuntu LTS release cycles, often ~18 months between versions. The last Debian/stable was released two days ago, and so as of now the unstable branch is finally unfrozen for new packages. It's sad that 1.8.0 is not in it, but there's no magic pool of people to do it for us. thanks, Hamish ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] many SVG symbols disappeared
I am completely on Tims side.. Cleaning up the house for 2.0 is very important - probably we would not get any chance that soon anymore.. So I would also suggest that those old symbols can be provided as a download somewhere for people that would really like to use old symbols (or have to) .. It's just the question where to communicate it to that persons.. kind regards Werner On Mon, May 6, 2013 at 10:55 PM, Tim Sutton li...@linfiniti.com wrote: Hi On Mon, May 6, 2013 at 2:31 PM, Olivier Dalang olivier.dal...@gmail.com wrote: I was asking that question on this thread : http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-td5040508.html#a5046486 Maybe I didn't emphasize enough on the deletion of symbols... IMO, the most elegant solution is to keep only the good-looking symbols so we provide a simple and consistent library, and then to provide a link on the website to download the unmodified 1.8 symbol library in case one needs to keep full backwards compatibility (it's quite easy to install : you just have to replace the SVG folder in your installation folder). The whole pull request already breaks backwards compatibility with all other symbols, since by removing their background, the may become unreadable on most of the maps... So if the priority is the keep old projects looking the same rather than having a clean and consistent library, the best is not to change the svg library at all. (just as an illustration, do you really think it's pertinent to keep this in the library ? : https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_layers.png ) Yeah that ain't pretty... Personally I like Oliver's patch and I think we should clean up house for 2.0. Keeping compatibility is useful but most of my project files from 1.8 are already broken to some degree and I would prefer we do all the big changes in 2.0 and then become more conservative in subsequent 2.x releases. 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS developer opportunity in Washington DB for World Bank-GFDRR
Hi All There is an opportunity for paid work in Washington with the World Bank Global Facility for Disaster Reduction. See original message from World Bank below: - We are starting the search for a QGIS expert to join the core WB-GFDRR team. I'm sharing a draft ToRwe put together and are interested to get your feedback and then your recommendations of any suitable candidates. https://docs.google.com/document/d/1SVBnGPNhugRgz3aPQ4udNI8fS63NKqZuikN1iU72Po8/edit?usp=sharing This role would be about 50% actual programming 50% program / community facilitation. Looking forward to your response. Best, Abby - 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
[Qgis-developer] Creating a pool of maps showcasing QGIS upcoming v2.0 features
Greetings all, As we are fast approaching the day QGIS v2.0 will be release, I thought it might be useful to create a public pool of nice maps showcasing some of the new features that'll be available in v2.0. That should help writing release notes (as visual examples of features will be readily available) as well as being a nice PR effort to attract new users. I believe quite a few of us QGIS users, as well as developers, have by now moved on to using QGIS 1.9 to produce maps. As such, we might already have a pretty good number of already-made maps exemplifying what's coming in v2.0. Anita has already posted a couple of nice blog posts with photos, so did Nyall. It'd be a matter of regrouping the maps under one umbrella. A Flickr group has been set up over here: http://www.flickr.com/groups/2244553@N22/ Nathan and I already uploaded a couple of maps. The concept would be to add maps and a description highlighting the new features (see http://www.flickr.com/photos/60284107@N00/8715653609/in/pool-2244553@N22for example). To upload to the Flickr group, it requires a Flickr account, which shouldn't be too troublesome as one can link its yahoo or gmail account to log in. Is this something you guys would be interested in participating to? Mathieu Pellerin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Creating a pool of maps showcasing QGIS upcoming v2.0 features
I think it's a great idea, hence why I have already added a map of my own :) This could also come in handy for local user groups to do Map Walls by having some images to pick from, full credits given of course. I would ask though that no one upload screens shots of the application itself. Keep screenshots for the manual. This is meant to be just maps that have been created using QGIS. Regards, Nathan On Tue, May 7, 2013 at 2:41 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote: Greetings all, As we are fast approaching the day QGIS v2.0 will be release, I thought it might be useful to create a public pool of nice maps showcasing some of the new features that'll be available in v2.0. That should help writing release notes (as visual examples of features will be readily available) as well as being a nice PR effort to attract new users. I believe quite a few of us QGIS users, as well as developers, have by now moved on to using QGIS 1.9 to produce maps. As such, we might already have a pretty good number of already-made maps exemplifying what's coming in v2.0. Anita has already posted a couple of nice blog posts with photos, so did Nyall. It'd be a matter of regrouping the maps under one umbrella. A Flickr group has been set up over here: http://www.flickr.com/groups/2244553@N22/ Nathan and I already uploaded a couple of maps. The concept would be to add maps and a description highlighting the new features (see http://www.flickr.com/photos/60284107@N00/8715653609/in/pool-2244553@N22for example). To upload to the Flickr group, it requires a Flickr account, which shouldn't be too troublesome as one can link its yahoo or gmail account to log in. Is this something you guys would be interested in participating to? Mathieu Pellerin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Creating a pool of maps showcasing QGIS upcoming v2.0 features
Yep, Nathan's right, let's keep this to rendered maps (via Save image as... or the Composer). There's plenty to show there :) On Tue, May 7, 2013 at 11:46 AM, Nathan Woodrow madman...@gmail.com wrote: I think it's a great idea, hence why I have already added a map of my own :) This could also come in handy for local user groups to do Map Walls by having some images to pick from, full credits given of course. I would ask though that no one upload screens shots of the application itself. Keep screenshots for the manual. This is meant to be just maps that have been created using QGIS. Regards, Nathan On Tue, May 7, 2013 at 2:41 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote: Greetings all, As we are fast approaching the day QGIS v2.0 will be release, I thought it might be useful to create a public pool of nice maps showcasing some of the new features that'll be available in v2.0. That should help writing release notes (as visual examples of features will be readily available) as well as being a nice PR effort to attract new users. I believe quite a few of us QGIS users, as well as developers, have by now moved on to using QGIS 1.9 to produce maps. As such, we might already have a pretty good number of already-made maps exemplifying what's coming in v2.0. Anita has already posted a couple of nice blog posts with photos, so did Nyall. It'd be a matter of regrouping the maps under one umbrella. A Flickr group has been set up over here: http://www.flickr.com/groups/2244553@N22/ Nathan and I already uploaded a couple of maps. The concept would be to add maps and a description highlighting the new features (see http://www.flickr.com/photos/60284107@N00/8715653609/in/pool-2244553@N22for example). To upload to the Flickr group, it requires a Flickr account, which shouldn't be too troublesome as one can link its yahoo or gmail account to log in. Is this something you guys would be interested in participating to? Mathieu Pellerin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Creating a pool of maps showcasing QGIS upcoming v2.0 features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 07/05/2013 06:46, Nathan Woodrow ha scritto: I think it's a great idea, hence why I have already added a map of my own :) Great initiative. Am I right that without logging in, only one map can be seen? All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlGIlysACgkQ/NedwLUzIr7IHQCcDbi16hKpYd0KQXoMAarEMhIM VRgAn3mwLSVPbdr70q9LltzQQ8A+hjCf =1MID -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
