[Qgis-developer] ogr osm provider seems broken
Hi Devs, to me the way qgis handles .osm files seems broken, see: http://hub.qgis.org/issues/1 http://hub.qgis.org/issues/10427 apparently ogr returns -1 on the number of features, but more important the feature interator seems broken Problems: loading an osm file and viewing the attribute table only shows 2 records (while all points are shown on the map). Iterating over the features with python also raises errors. Not sure if we should make this a blocker, because I'm not convinced of the importance of .osm files. Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] scroll area in style page of vector layer properties
Hi all, To fix the issue of the expression widget being too large in categorized/graduated symbology pages, I had to remove the scroll area from the main layout. I don't think it's a problem, and I believe that if a scroll area is needed it should be done in the next level (i.e. in the pages like point displacement, categorized, etc). I made a pull request for this: https://github.com/qgis/QGIS/pull/1428 I just wanted to be sure there was no counter-argument. If not, I will merge this soon. Cheers. Denis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Il 06/06/2014 00:49, Kari Salovaara ha scritto: Conclusions Plugin is useful and thus very acceptable, but - it can be installed only by person who knows what to do, those people who do digitizing are not always programmers (very seldom) - to tell where the actual workhorse is situated is quite clumsy way to use it even the plugin remembers the site (but only in that same session), this should developed to some settings. Now You find it once and write it on paper not to need to find it again etc. otherwise you spend time and possibility to make error?. - these kind of plugins should be marked always as experimental and with this I mean all similar need-to-be-compiled plugins Hi Kari, thanks a lot for your review. I agree, it could be better marking it as experimental for now. Please let me know if someone objects. I think once the plugin is well tested, we'll have to add the exe to the standalone installer for Windows. In the meantime I'm trying to have it on Debian. If someone can do the same for OSX, that would be great. For specific issues, please use the bugtracker. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Editing groups of layers / edit buffer / transactions
Hi devs, Being able to use transactions has a couple of advantages for users of databases: * Databases are prepared for multi user access. A transaction handles concurrent access on DB side. * Immediate feedback if a constraint is violated. With the edit buffer in QGIS, constraints are checked on commit only and updates are partially submitted. * The order of actions is considered (across multiple layers). * Triggers are executed immediately and possible effects on other layers are visible to QGIS. * Feature ID's are stable across commits. The edit buffer on QGIS side has the following jobs (if I'm right): * Buffer changes (insert/delete/update) for a single layer. * Offer undo support. * Broadcast (signal) changes when they occur to the QGIS system. As some of these items are closely related to transactions the edit buffer cannot be used in combination with transactions. So the questions is how it is possible to still support undo in such cases (a system with snapshots would be a possibiliity) and how to signal things (forward actions on client side, when they are sent to the DB / push notifications). On another note, I would be very happy to see support for a layer-independent edit buffer for the relations. The current solution, where a related layer has to be switched to edit mode from an embedded form and when you turn off edit mode from the same place the whole layer is saved, although the context of the button in the UI suggests that only the related features are being committed. Another problem is, that there a PK may be generated only on commit time and creating a foreign key pointing to an uncommitted feature can not be correctly treated, as the layer with the foreign key may be committed before the layer where it points to. This does not need to be done via transactions, but any kind of multi-layer edit buffer - either project wide or on groups of layers - would be highly welcome. I have not yet thought about all this in very detail and there may be still some errors in the concepts outlined in this mail, but I hope some of my thoughts on this topic are valid and constructive. It's an important discussion on the direction to take in order to further enable QGIS as a powerful database frontend. Kind regards, Matthias On 03.06.2014 11:50, Marco Hugentobler wrote: Hi devs In the QGEP project (https://github.com/qgep/QGEP), we are trying to create a waste water application module based on PostgreSQL and QGIS. Other examples of application modules are GIS based solutions for water, electicity, gas, ... So what I'm describing here is valid for a large number of GIS based applications. In an application module, there is usually a complex database schema consisting of many tables, views, triggers, foreign keys, constraints, sql functions. We found, that it is very difficult to do editing with the standard QGIS tools. In QGIS, we have an isolated edit buffer per layer. Once editing is stopped, the edits of a layer are commited to the datasource. For normal edit tasks, this is a great thing. However with many relations between the layers, it is almost impossile to work without triggering a lot of constraint violations in the database. Also adding or removing an object is usually done with sql functions, because it means changes to a lot of tables. In QGEP, we would more like to work within a database transaction and commit / rollback a series of changes at once (after all, a database snapshot can be seen as an edit buffer on database side). A possibility to cope with such a special editing situation is to bypass the edit buffer in QGIS and redirect all the read/write access of the involved database providers through one connection (but only if this mode is activated e.g. by a plugin, normally edit buffer and providers will behave like now). I've submitted a pull request about that topic and there was quite a long discussion about it, but without a clear result. Therefore I'd like to discuss in a broader context (and separated from any implementation issues) the idea of bypassing the edit buffer (in special situations) and using a backend mechanism instead (e.g. db transactions). What are your opinions? Regards, Marco ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Realease and blockers
Hi all. The new QGIS version will be released very soon. There are still 58 blocking issues, growing. Some of them are quite nasty. I urge everybody, and especially those who use QGIS in large organization, saving tons of money previously spent in licences, to quickly invest a fraction of these savings into fixing some of these. With 1 million users, this seems a feasible target. Thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] add rasterlayer to qgsmapcanvas
Sure. The Icons are loading from resoureces.py .
hibo.py:
# Import the PyQt and QGIS libraries
from PyQt4 import QtCore, QtGui
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from qgis.core import *
# Initialize Qt resources from file resources.py
import resources
import sys
import os
# Import the code for the dialog
from Ui_hibo import Ui_hibo
class hibo:
def __init__(self, iface):
# Save reference to the QGIS interface
self.iface = iface
self.gui = Ui_hibo ()
self.gui.setupUi()
def connects(self):
#self.dlg.ui.load_button.clicked.connect(self.loadImage)
pass
def initGui(self):
# Create action that will start plugin configuration
self.action = QAction(QIcon(icon.png), HiBo,
self.iface.mainWindow())
# connect the action to the run method
QObject.connect(self.action, SIGNAL(activated()), self.run)
# Add toolbar button and menu item
self.iface.addToolBarIcon(self.action)
self.iface.addPluginToMenu(HiBo, self.action)
def unload(self):
# Remove the plugin menu item and icon
self.iface.removePluginMenu(HiBo,self.action)
self.iface.removeToolBarIcon(self.action)
# run method that performs all the real work
def run(self):
# show the dialog
self.gui.show()
#print os.getcwd()
result = self.gui.exec_()
# See if OK was pressed
if result == 1:
print test1
ui_hibo.py:
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
import os
from PyQt4 import QtCore, QtGui
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from qgis.core import *
from qgis.gui import *
try:
_fromUtf8 = QtCore.QString.fromUtf8
except AttributeError:
def _fromUtf8(s):
return s
try:
_encoding = QtGui.QApplication.UnicodeUTF8
def _translate(context, text, disambig):
return QtGui.QApplication.translate(context, text, disambig,
_encoding)
except AttributeError:
def _translate(context, text, disambig):
return QtGui.QApplication.translate(context, text, disambig)
class Ui_hibo(QtGui.QDialog):
def __init__(self):
QtGui.QDialog.__init__(self)
self.setupUi()
#self.connect(self.loadRaster, QtCore.SIGNAL('triggered()'),
self.loadRasterImage)
self.connect(self.canvasRaster, QtCore.SIGNAL('renderStarting()'),
self.startRendering)
self.setWindowTitle(self.tr(HiBo))
def setupUi(self):
setup for toolbar
self.toolbarVector = QtGui.QToolBar('vector', self)
self.toolbarRaster = QtGui.QToolBar('raster', self)
self.zoominVector = QtGui.QAction(QtGui.QIcon(zoomin.png),
'zoominVector', self)
self.zoomoutVector = QtGui.QAction(QtGui.QIcon(zoomout.png),
'zoomoutVector', self)
self.moveVector = QtGui.QAction(QtGui.QIcon(move.png),
'moveVector', self)
self.loadVector = QtGui.QAction(QtGui.QIcon(load.png),
'loadVector', self)
self.zoominRaster = QtGui.QAction(QtGui.QIcon(zoomin.png),
'zoominRaster', self)
self.zoomoutRaster = QtGui.QAction(QtGui.QIcon(zoomout.png),
'zoomoutRaster', self)
self.moveRaster = QtGui.QAction(QtGui.QIcon(move.png),
'moveRaster', self)
self.loadRaster = QtGui.QAction(QtGui.QIcon(load.png),
'loadRaster', self)
self.selectRaster= QtGui.QAction(QtGui.QIcon(select.png),
'selectRaster', self)
self.toolbarVector.addAction(self.loadVector)
self.toolbarVector.addAction(self.zoominVector)
self.toolbarVector.addAction(self.zoomoutVector)
self.toolbarVector.addAction(self.moveVector)
self.toolbarRaster.addAction(self.loadRaster)
self.toolbarRaster.addAction(self.zoominRaster)
self.toolbarRaster.addAction(self.zoomoutRaster)
self.toolbarRaster.addAction(self.moveRaster)
self.toolbarRaster.addAction(self.selectRaster)
setup for canvas
self.canvasVector= QgsMapCanvas()
self.canvasVector.setCanvasColor(QtGui.QColor(255,255,255,255))
self.canvasVector.enableAntiAliasing(True)
self.canvasRaster= QgsMapCanvas()
self.canvasRaster.setCanvasColor(QtGui.QColor(255,255,255,255))
self.canvasRaster.enableAntiAliasing(True)
#fileName = QFileDialog.getOpenFileName(None, historical map,
., Image Files (*.png *.jpg *.bmp *.tiff))
fileName = /home/felix/programming/HiBo-plugin/hibo/map.tif
fileInfo = QFileInfo(fileName)
baseName = fileInfo.baseName()
rlayer = QgsRasterLayer(fileName, baseName)
if not rlayer.isValid():
print Layer failed to load!
QgsMapLayerRegistry.instance().addMapLayer(rlayer)
self.canvasRaster.setExtent(rlayer.extent())
self.canvasRaster.setLayerSet( [ QgsMapCanvasLayer(rlayer) ] )
layout
vectorarea = QtGui.QWidget()
rasterarea = QtGui.QWidget()
layoutVector = QtGui.QVBoxLayout()
layoutRaster = QtGui.QVBoxLayout()
vectorarea.setLayout(layoutVector)
Re: [Qgis-developer] Realease and blockers
Hi Paolo, I'm still searching a way to sponsor you, and have good hopes we will find a way. but it won't make it for 2.4. And we will probably be finding a solution only available for my organization. I would have prefered to find a way that other public users in France could repeat, so that we start a massive movement. Any feedback from current european sponsors is more than welcome. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Realease-and-blockers-tp5144366p5144374.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] Realease and blockers
BTW, the very short release cycle is really complicated for us. Deploying prod version and testing new versions periods overshoot here. I'm alone on that topic, and partial time only. Having longer release candidate period, and a 6 months release cycle could help for me. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Realease-and-blockers-tp5144366p5144375.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] Legend refactoring branch merged
One more issue I have found is that the commit below introduces a crash if you add layers from different crs's. timlinux@channel:~/dev/cpp/QGIS$ git bisect good a04ebf9eb012bb7b6f05300e5d3e676e4603553e is the first bad commit commit a04ebf9eb012bb7b6f05300e5d3e676e4603553e Author: Martin Dobias wonder...@gmail.com Date: Thu Jun 5 20:23:34 2014 +0700 Reintroduce datum transforms (were disabled during transition to MTR) :04 04 7c6366ef03b946eab2c6640f455f9f34e32f6210 51562407787ad5eb31f68bc7c4bfb269e4b2bf30 M python :04 04 ada46001fe3dc45e1aaafcbdf0158cc86ac33522 c9b65fb2c3dc0a7516ba68b2bbf4a90193f38a78 M src Sample data here: http://data.inasafe.org/ScenarioDataPackages/BimaTsunami_TestData.zip If you add the raster bil file at the same time the vector layers QGIS will crash. Regards Tim On Fri, Jun 6, 2014 at 11:03 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Fri, Jun 6, 2014 at 10:55 AM, Martin Dobias wonder...@gmail.com wrote: Hi Tim On Fri, Jun 6, 2014 at 10:50 AM, Tim Sutton li...@linfiniti.com wrote: Hi Martin One other glitch I have found is that loading a QML style file in the properties dialog sometimes (always?) does not refresh the legend when you close the dialog. Saving the project, closing and reopening it does cause it to refresh. How old is your git checkout? I have probably fixed that issue yesterday - #10469 had very similar symptoms as you describe. Ah ok I built yesterdam morning early. Compiling now and will come back to you if I still see the issue. Thanks! Tim Regards Martin -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Hi, I kind of agree. I also think the one month testing phase is too short to properly deal with all of the bugs. Maybe a six month release cycle with 4 month development and 2 month testing would be more useful in the future. Furthermore, we would probably need at least one bugfix release. But I know you have discussed this back and forth ... and there is no single solution that fits for everyone. - BTW: I believe our finances would allow to again sponsor 1 week of paid bug fixing from the QGIS funds. Like with the past two releases. Has the PSC discussed this? Andreas Am 06.06.2014 09:36, schrieb Régis Haubourg: BTW, the very short release cycle is really complicated for us. Deploying prod version and testing new versions periods overshoot here. I'm alone on that topic, and partial time only. Having longer release candidate period, and a 6 months release cycle could help for me. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Realease-and-blockers-tp5144366p5144375.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] Realease and blockers
Il 06/06/2014 11:36, Régis Haubourg ha scritto: BTW, the very short release cycle is really complicated for us. Deploying prod version and testing new versions periods overshoot here. I'm alone on that topic, and partial time only. Having longer release candidate period, and a 6 months release cycle could help for me. I understand this. However, you are free to upgrade only if and when you have time for it, e.g. skipping every second version will give you an 8 months time frame. IMHO the fixed release cycle will help people planning in advance (yes, also the investment for bugfixing :) ). All the best, and thanks for your interest. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Il 06/06/2014 11:42, Andreas Neumann ha scritto: But I know you have discussed this back and forth ... and there is no single solution that fits for everyone. yes, that's the point IMHO. BTW: I believe our finances would allow to again sponsor 1 week of paid bug fixing from the QGIS funds. Like with the past two releases. Has the PSC discussed this? not yet. I'd be in favour of this, even though I'd like to see a more direct involvement of power users. all the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
The longer release time isn't for users its for us devs. After the feature freeze is lifted features start going in adding more bugs. So a longer release cycle with 2 months bug fix would allow for more polish. This release was of course a major change adding some big stuff maybe we just expand this one? On Jun 6, 2014 7:47 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 06/06/2014 11:36, Régis Haubourg ha scritto: BTW, the very short release cycle is really complicated for us. Deploying prod version and testing new versions periods overshoot here. I'm alone on that topic, and partial time only. Having longer release candidate period, and a 6 months release cycle could help for me. I understand this. However, you are free to upgrade only if and when you have time for it, e.g. skipping every second version will give you an 8 months time frame. IMHO the fixed release cycle will help people planning in advance (yes, also the investment for bugfixing :) ). All the best, and thanks for your interest. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring branch merged
Hi Tim, this one was fixed this morning in PR #1429 :-) Regards Martin On Fri, Jun 6, 2014 at 4:41 PM, Tim Sutton li...@linfiniti.com wrote: One more issue I have found is that the commit below introduces a crash if you add layers from different crs's. timlinux@channel:~/dev/cpp/QGIS$ git bisect good a04ebf9eb012bb7b6f05300e5d3e676e4603553e is the first bad commit commit a04ebf9eb012bb7b6f05300e5d3e676e4603553e Author: Martin Dobias wonder...@gmail.com Date: Thu Jun 5 20:23:34 2014 +0700 Reintroduce datum transforms (were disabled during transition to MTR) :04 04 7c6366ef03b946eab2c6640f455f9f34e32f6210 51562407787ad5eb31f68bc7c4bfb269e4b2bf30 M python :04 04 ada46001fe3dc45e1aaafcbdf0158cc86ac33522 c9b65fb2c3dc0a7516ba68b2bbf4a90193f38a78 M src Sample data here: http://data.inasafe.org/ScenarioDataPackages/BimaTsunami_TestData.zip If you add the raster bil file at the same time the vector layers QGIS will crash. Regards Tim On Fri, Jun 6, 2014 at 11:03 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Fri, Jun 6, 2014 at 10:55 AM, Martin Dobias wonder...@gmail.com wrote: Hi Tim On Fri, Jun 6, 2014 at 10:50 AM, Tim Sutton li...@linfiniti.com wrote: Hi Martin One other glitch I have found is that loading a QML style file in the properties dialog sometimes (always?) does not refresh the legend when you close the dialog. Saving the project, closing and reopening it does cause it to refresh. How old is your git checkout? I have probably fixed that issue yesterday - #10469 had very similar symptoms as you describe. Ah ok I built yesterdam morning early. Compiling now and will come back to you if I still see the issue. Thanks! Tim Regards Martin -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Hello, Le vendredi 6 juin 2014 11:08:57, Paolo Cavallini a écrit : The new QGIS version will be released very soon. There are still 58 blocking issues, growing. Some of them are quite nasty. I urge everybody, and especially those who use QGIS in large organization, saving tons of money previously spent in licences, to quickly invest a fraction of these savings into fixing some of these. With 1 million users, this seems a feasible target. Could we make a more visible RC release on the website, encouraging testing ? I think that our user are not used yet to our new release cycle. We really should educate them, and lower the barrier to RC testing and bug reporting. As for now, even installing the RCs is complicated, so is bug reporting. What about modifying the RCs so that : * we have a bug report feature in the help menu, allowing to create an osgeo user, search for bug and report if not found ? * we add a splash-screen or a first pop-up window stating clearly that there is a need for bugfixes, and therefore a strong and quick need for funding ? Maybe even adding links to supporting companies as stated on the website, so that users/clients can contact them directly, in addition to the sponsoring informations ? * we add to this popup a big donate now button linking to paypal / flattr or whatever simple system for micro-donation, and a bitcoin address * we propose to optionnally subscribe to a specific qgis-newsletter mailing list, where we can reach our userbase with RC download links, and funding requests (with a privacy protection + no spam statement) This is a bit late for 2.4 of course, but this is IMHO a way to enlarge our tester base, as well as our funders. What we need is not a different release cycle, but more education. Adopting more push-oriented communication methods seams the way to go. My 2 cents, Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
On 06/06/2014 8:20 pm, Vincent Picavet vincent...@oslandia.com wrote: Could we make a more visible RC release on the website, encouraging testing ? I think that our user are not used yet to our new release cycle. We really should educate them, and lower the barrier to RC testing and bug reporting. As for now, even installing the RCs is complicated, so is bug reporting. I don't think the issue is just bug reporting for a RC though. As mentioned, we've already got a very long blocker list, which is still growing. I think a bigger issue is development resources and developer's time availability. At the current rate of bug closing we're very likely to still have a large number of these issues outstanding at the end of the month. I'm in favor of a longer freeze period for next release. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Hello, Le vendredi 6 juin 2014 12:30:23, Nyall Dawson a écrit : On 06/06/2014 8:20 pm, Vincent Picavet vincent...@oslandia.com wrote: Could we make a more visible RC release on the website, encouraging testing ? I think that our user are not used yet to our new release cycle. We really should educate them, and lower the barrier to RC testing and bug reporting. As for now, even installing the RCs is complicated, so is bug reporting. I don't think the issue is just bug reporting for a RC though. As mentioned, we've already got a very long blocker list, which is still growing. I think a bigger issue is development resources and developer's time availability. At the current rate of bug closing we're very likely to still have a large number of these issues outstanding at the end of the month. More bug reports, bug comments and better bug reports is already a lot of developer's time saved. Having more testers (and regular testers) is as important as having developers to fix bugs. My proposal was also more oriented towards getting users involved in all ways, and especially funding at Feature Freeze time. Getting them to download, install and test more thoroughly the RCs, and using this media to incent them to fund the software do contribute to more developers time. I'm in favor of a longer freeze period for next release. I am not sure that more non-paid developer time is a sustainable model. Or it is a matter of going from a FF development model, to a more formal peer- review commitfest model ( like http://rhaas.blogspot.fr/2011/03/commitfests- and-meritocracy.html ). There are many other ways to reduce bugs even before reaching feature freeze, some of them already discussed thoroughly here, I am just trying to find some easy, reachable and efficient means, which can of course be complementary to other means. Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
2014-06-06 13:16 GMT+03:00 Vincent Picavet vincent...@oslandia.com: Could we make a more visible RC release on the website, encouraging testing ? I think that our user are not used yet to our new release cycle. We really should educate them, and lower the barrier to RC testing and bug reporting. As for now, even installing the RCs is complicated, so is bug reporting. We already have a big banner at main page about RC and testing. Seems most users don't visit main page too often to notice it. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Hi On Fri, Jun 6, 2014 at 4:42 PM, Andreas Neumann a.neum...@carto.net wrote: Hi, I kind of agree. I also think the one month testing phase is too short to properly deal with all of the bugs. Maybe a six month release cycle with 4 month development and 2 month testing would be more useful in the future. Furthermore, we would probably need at least one bugfix release. But I know you have discussed this back and forth ... and there is no single solution that fits for everyone. - BTW: I believe our finances would allow to again sponsor 1 week of paid bug fixing from the QGIS funds. Like with the past two releases. Has the PSC discussed this? Not yet but we can table it in our PSC meeting tonight. And yes there is no single release cycle that will keep everyone happy. The other suggestion we had once was to make every third (or other increment) release purely a bug fix release. Those enterprise orientated folks could hold out for those instead of doing incremental upgrades. Regards Tim Andreas Am 06.06.2014 09:36, schrieb Régis Haubourg: BTW, the very short release cycle is really complicated for us. Deploying prod version and testing new versions periods overshoot here. I'm alone on that topic, and partial time only. Having longer release candidate period, and a 6 months release cycle could help for me. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Realease-and-blockers-tp5144366p5144375.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 -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
On 06/06/2014 8:51 pm, Vincent Picavet vincent...@oslandia.com wrote: More bug reports, bug comments and better bug reports is already a lot of developer's time saved. Having more testers (and regular testers) is as important as having developers to fix bugs. Sorry if I didn't word my original reply very well - I didn't mean to imply bug reports aren't important or valued! I'm just unsure how we can clear our current queue in time for release as it stands currently... Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
While testing and reporting is important without a doubt, the currently outstanding issues could be fixed easily by the end of the month as soon as resources are available. The main point is, that we should start improving where there is the biggest effect - and that's paid bugfixing time. There are some extremely capable and effective core devs available for this job as has been proven in the past. That means: go out, tell your neighbours and social media buddies and customers about the RC and testing. But if you want the bugs they report to be fixed, make sure that there's somebody taking care of them. The main problems normally are not the bugs not found while testing, but the ones not fixed before the release. This in turn also means that I don't think a two months bugfixing period will improve a lot. If there's two months with developers spending time on other projects because there's no funding available for bugfixing we haven't won anything. Regards, Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Il 06/06/2014 13:46, Tim Sutton ha scritto: Not yet but we can table it in our PSC meeting tonight. And yes there is no single release cycle that will keep everyone happy. The other suggestion we had once was to make every third (or other increment) release purely a bug fix release. Those enterprise orientated folks could hold out for those instead of doing incremental upgrades. Yet another interesting option, already discussed, is to maintain a stable release, backporting fixes to it. Some work has already gone in that direction, merging and coordinating them would be a major improvements IMHO. I personally think this effort should be funded by one or more of the many big users we increasingly have, and cannot rely on our efforts only. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Il 06/06/2014 13:57, Matthias Kuhn ha scritto: That means: go out, tell your neighbours and social media buddies and customers about the RC and testing. But if you want the bugs they report to be fixed, make sure that there's somebody taking care of them. The main problems normally are not the bugs not found while testing, but the ones not fixed before the release. This in turn also means that I don't think a two months bugfixing period will improve a lot. If there's two months with developers spending time on other projects because there's no funding available for bugfixing we haven't won anything. agreed. please spread this word to users as much as possible, using the MLs, SNs, and any other possible medium. that was the idea behind my post starting this thread. thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Hi, Le vendredi 6 juin 2014 13:34:12, Alexander Bruy a écrit : 2014-06-06 13:16 GMT+03:00 Vincent Picavet vincent...@oslandia.com: Could we make a more visible RC release on the website, encouraging testing ? I think that our user are not used yet to our new release cycle. We really should educate them, and lower the barrier to RC testing and bug reporting. As for now, even installing the RCs is complicated, so is bug reporting. We already have a big banner at main page about RC and testing. Seems most users don't visit main page too often to notice it. I tried with a standard user yesterday, watching him use the site to get qgis, and it was still _very_ complicated for him. He expected to click on a QGIS 2.4 preview download button and the download to begin immediatly, which is far from happening. Instead, the small RC link leads to a page with a lot of links, he had difficulties to find the preview release (not knowing what a release candidate is), hesitating with osgeo4w download, then being redirected once again on the same page, lost in the web page, finally finding a small link to a dull page listing a lot of files (what the hell is a md5sum file ?? what is this 2.3 version ?? where is the preview ?), of which he finally chose a random exe and installed it. Even I was totally lost trying to get the right file. I think we can do much better. Then it is a matter of advertising the preview at large : official call for testing from qgis project on osgeo mailing lists, twitter, linkedin, and if possible on a qgis-news mailing list where we have gathered a lot of user beforehand (with their approval of course). Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Il 06/06/2014 13:17, Hugo Ledoux ha scritto: A windows Installer would be nice, but, Paulo, do you mean that QGIS would add prepair? That would be tricky, since we use CGAL too. But that would be great. The plugin should remember the path of the EXE, it does on all computers we've tested. Report bug on the issue page with details please. Hi. Hugo, would you object in tagging the plugin as experimental for now? Yes, I meant to include prepair (the plugin+the exe+des) in the standalone installer, as well as making it easy to install it in other OSs. Are you willing to help with that? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
I'm not sure just adding it to QGIS like that is the best idea really, it's a bit bolt on. It would be better to port the prepair C++ logic into QGIS itself to use QGIS geometry rather then GDAL. We could then just expose the API and wrap it in Python to expose in Processing. - Nathan On Fri, Jun 6, 2014 at 10:16 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 06/06/2014 13:17, Hugo Ledoux ha scritto: A windows Installer would be nice, but, Paulo, do you mean that QGIS would add prepair? That would be tricky, since we use CGAL too. But that would be great. The plugin should remember the path of the EXE, it does on all computers we've tested. Report bug on the issue page with details please. Hi. Hugo, would you object in tagging the plugin as experimental for now? Yes, I meant to include prepair (the plugin+the exe+des) in the standalone installer, as well as making it easy to install it in other OSs. Are you willing to help with that? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ogr osm provider seems broken
Le vendredi 06 juin 2014 08:55:39, Richard Duivenvoorde a écrit : Hi Devs, to me the way qgis handles .osm files seems broken, see: http://hub.qgis.org/issues/1 http://hub.qgis.org/issues/10427 apparently ogr returns -1 on the number of features, but more important the feature interator seems broken Problems: loading an osm file and viewing the attribute table only shows 2 records (while all points are shown on the map). Iterating over the features with python also raises errors. Not sure if we should make this a blocker, because I'm not convinced of the importance of .osm files. Richard, Jukka pretty much answered rightly the questions in the tickets. The OGR OSM driver is rather tuned to handle multi-gigabyte .osm/.pbf files, and due to the structure of those files, it is impossible to count efficiently the number of features without reading it entirely. Hence -1 returned as the feature count. If you issue an explicit SELECT COUNT(*) FROM, it means that you know what you want, and you're ready to wait for it... And, also related to the structure of the data, the driver is a bit particular in the sense that the iteratation over features with GetNextFeature() might not work if the osm file is of a sufficient size. See the Interleaved reading paragraph of http://www.gdal.org/drv_osm.html. For such cases, it might be interesting to develop a new concept in OGR, a whole dataset feature iterator, that could return features from different layers as soon as they are available. Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
On Fri, Jun 6, 2014 at 1:34 PM, Alexander Bruy alexander.b...@gmail.com wrote: 2014-06-06 13:16 GMT+03:00 Vincent Picavet vincent...@oslandia.com: Could we make a more visible RC release on the website, encouraging testing ? I think that our user are not used yet to our new release cycle. We really should educate them, and lower the barrier to RC testing and bug reporting. As for now, even installing the RCs is complicated, so is bug reporting. We already have a big banner at main page about RC and testing. Seems most users don't visit main page too often to notice it. We've also advertised the release candidates quite heavily on Twitter. I don't think there is much chance to reach those users which we haven't reached so far. Best wishes, Anita ___ 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] Opinion on plugin named prepair (and possible likes)
My colleagues and I are willing to help if there is interest from the community in having prepair included in QGIS. However, I believe, like Nathan, that including the current version is sub-optimal: we’re just calling the binary and pass the WKT of the geometries, and read the WKT returned. Rather slow for big polygons. Hugo On Fri, Jun 6, 2014 at 2:26 PM, qgis-developer-requ...@lists.osgeo.org wrote: Send Qgis-developer mailing list submissions to qgis-developer@lists.osgeo.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.osgeo.org/mailman/listinfo/qgis-developer or, via email, send a message with subject or body 'help' to qgis-developer-requ...@lists.osgeo.org You can reach the person managing the list at qgis-developer-ow...@lists.osgeo.org When replying, please edit your Subject line so it is more specific than Re: Contents of Qgis-developer digest... Today's Topics: 1. Re: Realease and blockers (Tim Sutton) 2. Re: Realease and blockers (Matthias Kuhn) 3. Re: Realease and blockers (Paolo Cavallini) 4. Re: Realease and blockers (Paolo Cavallini) 5. Re: Realease and blockers (Vincent Picavet) 6. Re: Opinion on plugin named prepair (and possible likes) (Paolo Cavallini) 7. Re: Opinion on plugin named prepair (and possible likes) (Nathan Woodrow) 8. Re: ogr osm provider seems broken (Even Rouault) -- Message: 1 Date: Fri, 6 Jun 2014 18:46:38 +0700 From: Tim Sutton li...@linfiniti.com To: Andreas Neumann a.neum...@carto.net Cc: qgis-developer qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Realease and blockers Message-ID: CALCNqkYRTJtCg7fR2JNek8A=j6m_5Sjh1iX=apxudvh+rqx...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi On Fri, Jun 6, 2014 at 4:42 PM, Andreas Neumann a.neum...@carto.net wrote: Hi, I kind of agree. I also think the one month testing phase is too short to properly deal with all of the bugs. Maybe a six month release cycle with 4 month development and 2 month testing would be more useful in the future. Furthermore, we would probably need at least one bugfix release. But I know you have discussed this back and forth ... and there is no single solution that fits for everyone. - BTW: I believe our finances would allow to again sponsor 1 week of paid bug fixing from the QGIS funds. Like with the past two releases. Has the PSC discussed this? Not yet but we can table it in our PSC meeting tonight. And yes there is no single release cycle that will keep everyone happy. The other suggestion we had once was to make every third (or other increment) release purely a bug fix release. Those enterprise orientated folks could hold out for those instead of doing incremental upgrades. Regards Tim Andreas Am 06.06.2014 09:36, schrieb R?gis Haubourg: BTW, the very short release cycle is really complicated for us. Deploying prod version and testing new versions periods overshoot here. I'm alone on that topic, and partial time only. Having longer release candidate period, and a 6 months release cycle could help for me. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Realease-and-blockers-tp5144366p5144375.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 -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140606/ee0cc789/attachment-0001.html -- Message: 2 Date: Fri, 06 Jun 2014 13:57:51 +0200 From: Matthias Kuhn matthias.k...@gmx.ch To: vincent...@oslandia.com, Nyall Dawson nyall.daw...@gmail.com Cc: qgis-user qgis-u...@lists.osgeo.org, qgis-developer qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Realease and blockers Message-ID: 5391acbf.7010...@gmx.ch Content-Type: text/plain; charset=ISO-8859-1 While testing and reporting is important without a doubt, the currently outstanding issues could be fixed easily by the end of the month as soon as resources are available. The main
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Il 06/06/2014 14:45, Hugo Ledoux ha scritto: My colleagues and I are willing to help if there is interest from the community in having prepair included in QGIS. However, I believe, like Nathan, that including the current version is sub-optimal: we’re just calling the binary and pass the WKT of the geometries, and read the WKT returned. Rather slow for big polygons. I also agree with Nathan: would you like to cooperate with QGIS core team, and incorporate your logic, possibly your code, in QGIS itself? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ogr osm provider seems broken
Le vendredi 06 juin 2014 14:48:01, Richard Duivenvoorde a écrit : On 06-06-14 14:26, Even Rouault wrote: Le vendredi 06 juin 2014 08:55:39, Richard Duivenvoorde a écrit : Hi Devs, to me the way qgis handles .osm files seems broken, see: Richard, Jukka pretty much answered rightly the questions in the tickets. The OGR OSM driver is rather tuned to handle multi-gigabyte .osm/.pbf files, and due to the structure of those files, it is impossible to count efficiently the number of features without reading it entirely. Hence -1 returned as the feature count. If you issue an explicit SELECT COUNT(*) FROM, it means that you know what you want, and you're ready to wait for it... And, also related to the structure of the data, the driver is a bit particular in the sense that the iteratation over features with GetNextFeature() might not work if the osm file is of a sufficient size. See the Interleaved reading paragraph of http://www.gdal.org/drv_osm.html. For such cases, it might be interesting to develop a new concept in OGR, a whole dataset feature iterator, that could return features from different layers as soon as they are available. Mmm, ok. Get your point. But then QGIS is broken for this kind of datasources in my opinion. I can only view them on the map? I should at least be able to view the attributes, or run an algorithm on a small dataset like the one attached to the tickets. My point is that QGIS is able to run over the features to show them, and also show the information of the features via the i-tool, I can even classify them... I would think that it would be possible to run over the features in one way or another to either show the attribute table, or do some simple algorithms like buffer. If not... then I think we should at least warn users for this kind of issues. I've not dived in QGIS code to know why it works for some stuff and not for others, but fundamentally the way the driver works requires special handling in the code using the driver. My recommandation would be to use ogr2ogr to convert the osm file into spatialite or postgis and work with the converted files Regards, Richard Duivenvoorde -- Geospatial professional services http://even.rouault.free.fr/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring branch merged
Hi On Fri, Jun 6, 2014 at 5:00 PM, Martin Dobias wonder...@gmail.com wrote: Hi Tim, this one was fixed this morning in PR #1429 :-) Doh! I am always one step behind :-) Thanks! Regards Tim Regards Martin On Fri, Jun 6, 2014 at 4:41 PM, Tim Sutton li...@linfiniti.com wrote: One more issue I have found is that the commit below introduces a crash if you add layers from different crs's. timlinux@channel:~/dev/cpp/QGIS$ git bisect good a04ebf9eb012bb7b6f05300e5d3e676e4603553e is the first bad commit commit a04ebf9eb012bb7b6f05300e5d3e676e4603553e Author: Martin Dobias wonder...@gmail.com Date: Thu Jun 5 20:23:34 2014 +0700 Reintroduce datum transforms (were disabled during transition to MTR) :04 04 7c6366ef03b946eab2c6640f455f9f34e32f6210 51562407787ad5eb31f68bc7c4bfb269e4b2bf30 M python :04 04 ada46001fe3dc45e1aaafcbdf0158cc86ac33522 c9b65fb2c3dc0a7516ba68b2bbf4a90193f38a78 M src Sample data here: http://data.inasafe.org/ScenarioDataPackages/BimaTsunami_TestData.zip If you add the raster bil file at the same time the vector layers QGIS will crash. Regards Tim On Fri, Jun 6, 2014 at 11:03 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Fri, Jun 6, 2014 at 10:55 AM, Martin Dobias wonder...@gmail.com wrote: Hi Tim On Fri, Jun 6, 2014 at 10:50 AM, Tim Sutton li...@linfiniti.com wrote: Hi Martin One other glitch I have found is that loading a QML style file in the properties dialog sometimes (always?) does not refresh the legend when you close the dialog. Saving the project, closing and reopening it does cause it to refresh. How old is your git checkout? I have probably fixed that issue yesterday - #10469 had very similar symptoms as you describe. Ah ok I built yesterdam morning early. Compiling now and will come back to you if I still see the issue. Thanks! Tim Regards Martin -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
I have just written a blog post and added it to Twitter, Google+, Facebook. I have also updated the banners on all those sites to show the RC banner. Blog post is at http://nathanw.net/2014/06/06/help-qgis/ - Nathan On Fri, Jun 6, 2014 at 10:27 PM, Anita Graser anitagra...@gmx.at wrote: On Fri, Jun 6, 2014 at 1:34 PM, Alexander Bruy alexander.b...@gmail.com wrote: 2014-06-06 13:16 GMT+03:00 Vincent Picavet vincent...@oslandia.com: Could we make a more visible RC release on the website, encouraging testing ? I think that our user are not used yet to our new release cycle. We really should educate them, and lower the barrier to RC testing and bug reporting. As for now, even installing the RCs is complicated, so is bug reporting. We already have a big banner at main page about RC and testing. Seems most users don't visit main page too often to notice it. We've also advertised the release candidates quite heavily on Twitter. I don't think there is much chance to reach those users which we haven't reached so far. Best wishes, Anita ___ 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] Opinion on plugin named prepair (and possible likes)
On Fri, Jun 6, 2014 at 3:11 PM, qgis-developer-requ...@lists.osgeo.org wrote: I also agree with Nathan: would you like to cooperate with QGIS core team, and incorporate your logic, possibly your code, in QGIS itself? All the best. Yes we’re willing to do that. It should be stressed out here that we use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR, Boost). ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Hello all, Not sure if this is how it works, but can we propose that the ?small? donations gathered by the Portuguese Users Group (570€) be directed for this bugfixing? Thanks, Alexandre Neto On Fri, Jun 6, 2014 at 12:57 PM, Matthias Kuhn matthias.k...@gmx.ch wrote: While testing and reporting is important without a doubt, the currently outstanding issues could be fixed easily by the end of the month as soon as resources are available. The main point is, that we should start improving where there is the biggest effect - and that's paid bugfixing time. There are some extremely capable and effective core devs available for this job as has been proven in the past. That means: go out, tell your neighbours and social media buddies and customers about the RC and testing. But if you want the bugs they report to be fixed, make sure that there's somebody taking care of them. The main problems normally are not the bugs not found while testing, but the ones not fixed before the release. This in turn also means that I don't think a two months bugfixing period will improve a lot. If there's two months with developers spending time on other projects because there's no funding available for bugfixing we haven't won anything. Regards, Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] GSOC Weekly Report 3: Schematization Plug-in for QGIS
Hi all, *Weekly Report 3* *What was done this week?* - Solved tickets/issues https://github.com/nishithm/schematization/issues?state=open which were created by the mentor on GitHub. It included addition of progress update (in terms of percentage) while running the algorithm and also an option for user to set the threshold for simplification (instead of using a predefined value). - Have added the pre-processing steps of dissolving and converting multiparts to singleparts in the plug-in itself after testing the algorithms using models. These algorithms of processing toolbox are called within the SimplificationAlgorithm https://github.com/nishithm/schematization/blob/master/SimplificationAlgorithm.py#L115 file. *What is the plan for next week?* - In the coming week I'll be trying to add the tests suites for the plug-in which will be helpful for testing the current features as well as for future testing purposes. *Wiki page : *http://hub.qgis.org/wiki/quantum-gis/nishithm *Code repository : *https://github.com/nishithm/schematization Thanks and regards, Nishith Maheshwari Lab for Spatial Informatics IIIT Hyderabad ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Paolo, Please notice that the donations were already sent as several paypal payments. Alexandre Neto On Fri, Jun 6, 2014 at 2:51 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 06/06/2014 15:49, Alexandre Neto ha scritto: Not sure if this is how it works, but can we propose that the ?small? donations gathered by the Portuguese Users Group (570€) be directed for this bugfixing? thant would help, thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Realease and blockers
Il 06/06/2014 15:49, Alexandre Neto ha scritto: Not sure if this is how it works, but can we propose that the ?small? donations gathered by the Portuguese Users Group (570€) be directed for this bugfixing? thant would help, thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring branch merged
Hi On Fri, Jun 6, 2014 at 8:11 PM, Tim Sutton li...@linfiniti.com wrote: Hi On Fri, Jun 6, 2014 at 5:00 PM, Martin Dobias wonder...@gmail.com wrote: Hi Tim, this one was fixed this morning in PR #1429 :-) Doh! I am always one step behind :-) Ok that works fine for me now. And you fixed the double click on the layer thing which was driving me nuts when it was trying to edit the name all the time. I think I have actually run out of issues and the legend is working great for me - thanks for all your hard work! Regards Tim Thanks! Regards Tim Regards Martin On Fri, Jun 6, 2014 at 4:41 PM, Tim Sutton li...@linfiniti.com wrote: One more issue I have found is that the commit below introduces a crash if you add layers from different crs's. timlinux@channel:~/dev/cpp/QGIS$ git bisect good a04ebf9eb012bb7b6f05300e5d3e676e4603553e is the first bad commit commit a04ebf9eb012bb7b6f05300e5d3e676e4603553e Author: Martin Dobias wonder...@gmail.com Date: Thu Jun 5 20:23:34 2014 +0700 Reintroduce datum transforms (were disabled during transition to MTR) :04 04 7c6366ef03b946eab2c6640f455f9f34e32f6210 51562407787ad5eb31f68bc7c4bfb269e4b2bf30 M python :04 04 ada46001fe3dc45e1aaafcbdf0158cc86ac33522 c9b65fb2c3dc0a7516ba68b2bbf4a90193f38a78 M src Sample data here: http://data.inasafe.org/ScenarioDataPackages/BimaTsunami_TestData.zip If you add the raster bil file at the same time the vector layers QGIS will crash. Regards Tim On Fri, Jun 6, 2014 at 11:03 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Fri, Jun 6, 2014 at 10:55 AM, Martin Dobias wonder...@gmail.com wrote: Hi Tim On Fri, Jun 6, 2014 at 10:50 AM, Tim Sutton li...@linfiniti.com wrote: Hi Martin One other glitch I have found is that loading a QML style file in the properties dialog sometimes (always?) does not refresh the legend when you close the dialog. Saving the project, closing and reopening it does cause it to refresh. How old is your git checkout? I have probably fixed that issue yesterday - #10469 had very similar symptoms as you describe. Ah ok I built yesterdam morning early. Compiling now and will come back to you if I still see the issue. Thanks! Tim Regards Martin -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring branch merged
Il 05/06/2014 08:03, Luca Manganelli ha scritto: You can try our server: http://webapps.comune.trento.it/ogc BTW, the server throws an error when layers are added from the browser: Map request error (Title:Eccezione servizio; Error:La richiesta contiene un formato non disponibile dal server. Questo il report restituito dalla sorgente WMS: msWMSLoadGetMapParams(): Image handling error. Unsupported output format (). ; URL: http://webapps.comune.trento.it/ogc?SERVICE=WMSVERSION=1.3.0REQUEST=GetMapBBOX=658906.16767540690489113,5104409.28855266142636538,660377.57158853847067803,5105407.12450302578508854CRS=EPSG:25832WIDTH=519HEIGHT=352LAYERS=ortofoto2009STYLES=FORMAT=TRANSPARENT=TRUE) They work fine when added from the menuAdd WMS. QGIS bug, or server issue? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Adding WMS from Browser (was: Legend refactoring branch merged)
Il 06/06/2014 16:39, Paolo Cavallini ha scritto: Il 05/06/2014 08:03, Luca Manganelli ha scritto: http://webapps.comune.trento.it/ogc BTW, the server throws an error when layers are added from the browser: Map request error (Title:Eccezione servizio; Error:La richiesta contiene un formato non disponibile dal server. Questo il report restituito dalla sorgente WMS: msWMSLoadGetMapParams(): Image handling error. Unsupported output format (). ; URL: http://webapps.comune.trento.it/ogc?SERVICE=WMSVERSION=1.3.0REQUEST=GetMapBBOX=658906.16767540690489113,5104409.28855266142636538,660377.57158853847067803,5105407.12450302578508854CRS=EPSG:25832WIDTH=519HEIGHT=352LAYERS=ortofoto2009STYLES=FORMAT=TRANSPARENT=TRUE) They work fine when added from the menuAdd WMS. QGIS bug, or server issue? seems a server issue, as other WMS are working fine. the different behaviour is however unexpected, and deserves some investigation. all the best- -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Hi Hugo, About a month ago, I created a formula for prepair in the OSGeo4Mac Homebrew tap [0,1]. I would appreciate it if you would review it, and possibly do any pull requests for changes you feel are appropriate. Specifically, what options you used to create the new Mac binary for your plugin, where it is only linked to GDAL's lib (I haven't looked into it yet). On Fri, Jun 6, 2014 at 7:29 AM, Hugo Ledoux h.led...@tudelft.nl wrote: On Fri, Jun 6, 2014 at 3:11 PM, qgis-developer-requ...@lists.osgeo.org wrote: I also agree with Nathan: would you like to cooperate with QGIS core team, and incorporate your logic, possibly your code, in QGIS itself? All the best. Yes we’re willing to do that. It should be stressed out here that we use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR, Boost). Boost is a very large extra dependency, indeed. [0] https://github.com/OSGeo/homebrew-osgeo4mac [1] https://github.com/OSGeo/homebrew-osgeo4mac/blob/master/Formula/prepair.rb Regards, 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] Legend refactoring branch merged
Is missing the image format declaration. This work. I guess the format is mandatory for wms. http://webapps.comune.trento.it/ogc?SERVICE=WMSVERSION=1.3.0REQUEST=GetMapBBOX=658906.16767540690489113,5104409.28855266142636538,660377.57158853847067803,5105407.12450302578508854CRS=EPSG:25832WIDTH=519HEIGHT=352LAYERS=ortofoto2009STYLES=FORMAT=image/pngTRANSPARENT=TRUE 2014-06-06 16:39 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 05/06/2014 08:03, Luca Manganelli ha scritto: You can try our server: http://webapps.comune.trento.it/ogc BTW, the server throws an error when layers are added from the browser: Map request error (Title:Eccezione servizio; Error:La richiesta contiene un formato non disponibile dal server. Questo il report restituito dalla sorgente WMS: msWMSLoadGetMapParams(): Image handling error. Unsupported output format (). ; URL: http://webapps.comune.trento.it/ogc?SERVICE=WMSVERSION=1.3.0REQUEST=GetMapBBOX=658906.16767540690489113,5104409.28855266142636538,660377.57158853847067803,5105407.12450302578508854CRS=EPSG:25832WIDTH=519HEIGHT=352LAYERS=ortofoto2009STYLES=FORMAT=TRANSPARENT=TRUE ) They work fine when added from the menuAdd WMS. QGIS bug, or server issue? All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring branch merged
On Fri, Jun 6, 2014 at 4:39 PM, Paolo Cavallini cavall...@faunalia.it wrote: http://webapps.comune.trento.it/ogc BTW, the server throws an error when layers are added from the browser: Map request error (Title:Eccezione servizio; Error:La richiesta contiene un formato I see that your URL has the parameter FORMAT with null value. If I write FORMAT=png it works... ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Il 06/06/2014 15:29, Hugo Ledoux ha scritto: Yes we’re willing to do that. It should be stressed out here that we use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR, Boost). good news. anyone see the dependencies as a problem? all the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Managinng the CGAL dependency would be useful for (SF)CGAL too. Today it's used only by PostGIS, internally, but maybe its use will extend in the future (hopefully for 3D in QGIS too!). giovanni 2014-06-06 17:51 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 06/06/2014 15:29, Hugo Ledoux ha scritto: Yes we’re willing to do that. It should be stressed out here that we use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR, Boost). good news. anyone see the dependencies as a problem? all the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
SFCGAL is a real hard to compile piece of software. Use it on qgis mean to transformer the qgis in a real hard to compile software . :) Il 06/giu/2014 17:55 G. Allegri gioha...@gmail.com ha scritto: Managinng the CGAL dependency would be useful for (SF)CGAL too. Today it's used only by PostGIS, internally, but maybe its use will extend in the future (hopefully for 3D in QGIS too!). giovanni 2014-06-06 17:51 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 06/06/2014 15:29, Hugo Ledoux ha scritto: Yes we’re willing to do that. It should be stressed out here that we use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR, Boost). good news. anyone see the dependencies as a problem? all the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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] Opinion on plugin named prepair (and possible likes)
Il 06/06/2014 18:24, Andrea Peri ha scritto: SFCGAL is a real hard to compile piece of software. Use it on qgis mean to transformer the qgis in a real hard to compile software . cgal is packaged in all mayor OSs, AFAIK, so no need to compile it. all the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
AFAIK it is noto available in debian stabile. Don't ? Also surely it is not available in RH enterprise. I guess surely it is available in ubuntu and fedora. Il 06/giu/2014 18:26 Paolo Cavallini cavall...@faunalia.it ha scritto: Il 06/06/2014 18:24, Andrea Peri ha scritto: SFCGAL is a real hard to compile piece of software. Use it on qgis mean to transformer the qgis in a real hard to compile software . cgal is packaged in all mayor OSs, AFAIK, so no need to compile it. all the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Il 06/06/2014 18:32, Andrea Peri ha scritto: AFAIK it is noto available in debian stabile. Don't ? I do not think our target for QGIS = 2.4 is Debian stable. Someone correct me if I'm wrong. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Do you guess the sfcgal is available on windows ? Il 06/giu/2014 18:38 Paolo Cavallini cavall...@faunalia.it ha scritto: Il 06/06/2014 18:32, Andrea Peri ha scritto: AFAIK it is noto available in debian stabile. Don't ? I do not think our target for QGIS = 2.4 is Debian stable. Someone correct me if I'm wrong. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Il 06/06/2014 18:41, Andrea Peri ha scritto: Do you guess the sfcgal is available on windows ? prepair needs cgal, not sfcgal all the best -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
I speak of giohappy proposal of sfcgal. Il 06/giu/2014 18:42 Paolo Cavallini cavall...@faunalia.it ha scritto: Il 06/06/2014 18:41, Andrea Peri ha scritto: Do you guess the sfcgal is available on windows ? prepair needs cgal, not sfcgal all the best -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Value Tool disabled when another tool selected
I've noticed the new version of the Value Tool plugin (0.8.4) automatically have the Enable button unchecked when another tool is selected. What is the rationale for this change? I draw polygons on top of raster files to be used during post processing and need the raster values for reference. This change breaks that functionality. I'm running QGIS 2.2 on Ubuntu 14.04. Thanks, Jamie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
CGAL is a prerequisite for SFCGAL. I'm not saying we should worry for having SFCGAL, but analyzing the dependency for prepair is useful for (eventually) having SFCGAL or whatever else based on CGAL. giovanni 2014-06-06 18:45 GMT+02:00 Andrea Peri aperi2...@gmail.com: I speak of giohappy proposal of sfcgal. Il 06/giu/2014 18:42 Paolo Cavallini cavall...@faunalia.it ha scritto: Il 06/06/2014 18:41, Andrea Peri ha scritto: Do you guess the sfcgal is available on windows ? prepair needs cgal, not sfcgal all the best -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Hi, On Fri, Jun 6, 2014 at 10:26 AM, Paolo Cavallini cavall...@faunalia.it wrote: Il 06/06/2014 18:24, Andrea Peri ha scritto: SFCGAL is a real hard to compile piece of software. Use it on qgis mean to transformer the qgis in a real hard to compile software . cgal is packaged in all mayor OSs, AFAIK, so no need to compile it. all the best. Not on Mac. But, there is already a formula in Homebrew, and a new one for SFCGAL [0,1]. My concern, Mac-wise, is the Boost dependency. Here are the minimal Pros/Cons: Pros: * Adds prepair, which is awesome for repairing polygons. * Adds Boost, which will offer a very robust framework to new devs, who are not necessarily adept at Qt developing, for building new core algorithms and features. * Could *double* the number of devs working on project. For example, PDAL and PCL already use Boost, and other 3D/Lidar tools may as well. Cons: * Boost is a very large compile and install. Since the Mac QGIS.app is bundled, the more Boost is used, the more of it needs bundled, possibly making the base install of QGIS on Mac balloon to over 1+ GB. Maintaining a smaller internal src tree may be a good solution. * The more Boost is used within QGIS source (beyond just prepair), then there is more new devs have to learn to become accustomed to the codebase, i.e. C++, Qt, and also Boost. There are probably others; but, adding Boost into the QGIS source mix will be a large change, IMHO. I think it would ultimately be beneficial. [0] https://github.com/Homebrew/homebrew/blob/master/Library/Formula/cgal.rb [1] https://github.com/Homebrew/homebrew/blob/master/Library/Formula/sfcgal.rb Regards, Larry -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Paolo, just to understand better : what do you mena as our target for QGIS ? I don't gind any page in QGIS site say-inf the targets OS . Instead I see the download page will offer: Ubuntu, Debian, Fedora, OpenSuse, RHEL (and various rhel like distro), Mandriva, ArchLinux, and ofcourse MAc, and Windows. I guess this should be bettr explain to avoid mis-understanding. Are you no speak of stables version of all this OSs ? Thx for explain. Andrea. 2014-06-06 18:38 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 06/06/2014 18:32, Andrea Peri ha scritto: AFAIK it is noto available in debian stabile. Don't ? I do not think our target for QGIS = 2.4 is Debian stable. Someone correct me if I'm wrong. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Dear Larry, The prepair Mac binary was made by linking to static versions of CGAL, boost, GMP, GMPXX, MPFI and MPFR, and only linking dynamically to Kyngchaos’ GDAL framework. The idea was that if people use Kyngchaos’ QGIS package, they already have his GDAL framework since it is a requirement. For Homebrew, I think the solution in your formula is the right way to go. Linking statically to the other libraries wouldn’t make sense. All the best, Ken From: Larry Shaffer lar...@dakotacarto.com Date: 6 juni 2014 17:30:53 CEST To: h.led...@tudelft.nl Cc: QGIS Developer List qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes) Hi Hugo, About a month ago, I created a formula for prepair in the OSGeo4Mac Homebrew tap [0,1]. I would appreciate it if you would review it, and possibly do any pull requests for changes you feel are appropriate. Specifically, what options you used to create the new Mac binary for your plugin, where it is only linked to GDAL's lib (I haven't looked into it yet). On Fri, Jun 6, 2014 at 7:29 AM, Hugo Ledoux h.led...@tudelft.nl wrote: On Fri, Jun 6, 2014 at 3:11 PM, qgis-developer-requ...@lists.osgeo.org wrote: I also agree with Nathan: would you like to cooperate with QGIS core team, and incorporate your logic, possibly your code, in QGIS itself? All the best. Yes we’re willing to do that. It should be stressed out here that we use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR, Boost). Boost is a very large extra dependency, indeed. [0] https://github.com/OSGeo/homebrew-osgeo4mac [1] https://github.com/OSGeo/homebrew-osgeo4mac/blob/master/Formula/prepair.rb Regards, 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
Re: [Qgis-developer] Value Tool disabled when another tool selected
I have implemented this to be able to identify on a mouse click instead of whenever you move the mouse (this is an optional behaviour). This requires the tool being a map tool, and you cannot have more than one active map tool. However, when the mouse click option is not enabled, it is NOT used as a map tool therefore it should not be deactivate when another map tool is used. If you uncheck that option (first in the Options dialog) and you still get that behavior it is a bug, and you should file a bug report (I can't reproduce with qgis 2.2). Default is this option turned off, so if you didn't change the option yourself that would be a bug also. Etienne On Fri, Jun 6, 2014 at 1:47 PM, Jamie Adams jaad...@gmail.com wrote: I've noticed the new version of the Value Tool plugin (0.8.4) automatically have the Enable button unchecked when another tool is selected. What is the rationale for this change? I draw polygons on top of raster files to be used during post processing and need the raster values for reference. This change breaks that functionality. I'm running QGIS 2.2 on Ubuntu 14.04. Thanks, Jamie ___ 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] Opinion on plugin named prepair (and possible likes)
Hi Ken, On Fri, Jun 6, 2014 at 12:12 PM, Ken Arroyo Ohori g.a.k.arroyooh...@tudelft.nl wrote: Dear Larry, The prepair Mac binary was made by linking to static versions of CGAL, boost, GMP, GMPXX, MPFI and MPFR, and only linking dynamically to Kyngchaos’ GDAL framework. The idea was that if people use Kyngchaos’ QGIS package, they already have his GDAL framework since it is a requirement. For Homebrew, I think the solution in your formula is the right way to go. Linking statically to the other libraries wouldn’t make sense. The mostly statically built binary would help for Mac bundling based off of OSGeo4Mac within QGIS, where (currently) there is no dependency upon Boost, CGAL, etc. The Kyngchaos.com setup for stable is the standard, but the QGIS Mac nightlies will probably also soon offer ones built strictly off of OSGeo4Mac. I that case, it would be ideal to offer a Homebrew 'bottle' of prepair (~3.5 MB) that would only require the gdal formula. Then, users would not even have to download/install the Boost bottle (~77 MB), let alone compile it. Will look at how to do this, when it comes to that type of bundling. Thanks, Larry All the best, Ken *From:* Larry Shaffer lar...@dakotacarto.com *Date:* 6 juni 2014 17:30:53 CEST *To:* h.led...@tudelft.nl *Cc:* QGIS Developer List qgis-developer@lists.osgeo.org *Subject: Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)* Hi Hugo, About a month ago, I created a formula for prepair in the OSGeo4Mac Homebrew tap [0,1]. I would appreciate it if you would review it, and possibly do any pull requests for changes you feel are appropriate. Specifically, what options you used to create the new Mac binary for your plugin, where it is only linked to GDAL's lib (I haven't looked into it yet). On Fri, Jun 6, 2014 at 7:29 AM, Hugo Ledoux h.led...@tudelft.nl wrote: On Fri, Jun 6, 2014 at 3:11 PM, qgis-developer-requ...@lists.osgeo.org wrote: I also agree with Nathan: would you like to cooperate with QGIS core team, and incorporate your logic, possibly your code, in QGIS itself? All the best. Yes we’re willing to do that. It should be stressed out here that we use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR, Boost). Boost is a very large extra dependency, indeed. [0] https://github.com/OSGeo/homebrew-osgeo4mac [1] https://github.com/OSGeo/homebrew-osgeo4mac/blob/master/Formula/prepair.rb Regards, 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
Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)
Hi Larry, Maybe I’m mistaken here, but doesn’t Homebrew always compile from source? Because if so, I’d think that even the mostly statically linked binary would still need to download and install a Boost bottle (albeit one that creates a static version of the libraries). But in any case, if it helps, I’d be happy to add the functionality to create mostly static versions of prepair to our CMake file, perhaps as a parameter. Ken El 06/06/2014, a las 08:33 p.m., Larry Shaffer lar...@dakotacarto.com escribió: Hi Ken, On Fri, Jun 6, 2014 at 12:12 PM, Ken Arroyo Ohori g.a.k.arroyooh...@tudelft.nl wrote: Dear Larry, The prepair Mac binary was made by linking to static versions of CGAL, boost, GMP, GMPXX, MPFI and MPFR, and only linking dynamically to Kyngchaos’ GDAL framework. The idea was that if people use Kyngchaos’ QGIS package, they already have his GDAL framework since it is a requirement. For Homebrew, I think the solution in your formula is the right way to go. Linking statically to the other libraries wouldn’t make sense. The mostly statically built binary would help for Mac bundling based off of OSGeo4Mac within QGIS, where (currently) there is no dependency upon Boost, CGAL, etc. The Kyngchaos.com setup for stable is the standard, but the QGIS Mac nightlies will probably also soon offer ones built strictly off of OSGeo4Mac. I that case, it would be ideal to offer a Homebrew 'bottle' of prepair (~3.5 MB) that would only require the gdal formula. Then, users would not even have to download/install the Boost bottle (~77 MB), let alone compile it. Will look at how to do this, when it comes to that type of bundling. Thanks, Larry ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Value Tool disabled when another tool selected
Ok, thanks. I filed a bug for this: http://hub.qgis.org/issues/10490 On Fri, Jun 6, 2014 at 11:27 AM, Etienne Tourigny etourigny@gmail.com wrote: I have implemented this to be able to identify on a mouse click instead of whenever you move the mouse (this is an optional behaviour). This requires the tool being a map tool, and you cannot have more than one active map tool. However, when the mouse click option is not enabled, it is NOT used as a map tool therefore it should not be deactivate when another map tool is used. If you uncheck that option (first in the Options dialog) and you still get that behavior it is a bug, and you should file a bug report (I can't reproduce with qgis 2.2). Default is this option turned off, so if you didn't change the option yourself that would be a bug also. Etienne On Fri, Jun 6, 2014 at 1:47 PM, Jamie Adams jaad...@gmail.com wrote: I've noticed the new version of the Value Tool plugin (0.8.4) automatically have the Enable button unchecked when another tool is selected. What is the rationale for this change? I draw polygons on top of raster files to be used during post processing and need the raster values for reference. This change breaks that functionality. I'm running QGIS 2.2 on Ubuntu 14.04. Thanks, Jamie ___ 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] Value Tool disabled when another tool selected
I actually fixed this last month, and forgot to upload a new version. I've been busy finishing my PhD the last few months which explains this! I have just uploaded version 0.8.5 to the plugin repos. Etienne On Fri, Jun 6, 2014 at 5:15 PM, Jamie Adams jaad...@gmail.com wrote: Ok, thanks. I filed a bug for this: http://hub.qgis.org/issues/10490 On Fri, Jun 6, 2014 at 11:27 AM, Etienne Tourigny etourigny@gmail.com wrote: I have implemented this to be able to identify on a mouse click instead of whenever you move the mouse (this is an optional behaviour). This requires the tool being a map tool, and you cannot have more than one active map tool. However, when the mouse click option is not enabled, it is NOT used as a map tool therefore it should not be deactivate when another map tool is used. If you uncheck that option (first in the Options dialog) and you still get that behavior it is a bug, and you should file a bug report (I can't reproduce with qgis 2.2). Default is this option turned off, so if you didn't change the option yourself that would be a bug also. Etienne On Fri, Jun 6, 2014 at 1:47 PM, Jamie Adams jaad...@gmail.com wrote: I've noticed the new version of the Value Tool plugin (0.8.4) automatically have the Enable button unchecked when another tool is selected. What is the rationale for this change? I draw polygons on top of raster files to be used during post processing and need the raster values for reference. This change breaks that functionality. I'm running QGIS 2.2 on Ubuntu 14.04. Thanks, Jamie ___ 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] Value Tool disabled when another tool selected
I just updated - it's now working as expected. Thanks for the quick fix. On Fri, Jun 6, 2014 at 1:39 PM, Etienne Tourigny etourigny@gmail.com wrote: I actually fixed this last month, and forgot to upload a new version. I've been busy finishing my PhD the last few months which explains this! I have just uploaded version 0.8.5 to the plugin repos. Etienne On Fri, Jun 6, 2014 at 5:15 PM, Jamie Adams jaad...@gmail.com wrote: Ok, thanks. I filed a bug for this: http://hub.qgis.org/issues/10490 On Fri, Jun 6, 2014 at 11:27 AM, Etienne Tourigny etourigny@gmail.com wrote: I have implemented this to be able to identify on a mouse click instead of whenever you move the mouse (this is an optional behaviour). This requires the tool being a map tool, and you cannot have more than one active map tool. However, when the mouse click option is not enabled, it is NOT used as a map tool therefore it should not be deactivate when another map tool is used. If you uncheck that option (first in the Options dialog) and you still get that behavior it is a bug, and you should file a bug report (I can't reproduce with qgis 2.2). Default is this option turned off, so if you didn't change the option yourself that would be a bug also. Etienne On Fri, Jun 6, 2014 at 1:47 PM, Jamie Adams jaad...@gmail.com wrote: I've noticed the new version of the Value Tool plugin (0.8.4) automatically have the Enable button unchecked when another tool is selected. What is the rationale for this change? I draw polygons on top of raster files to be used during post processing and need the raster values for reference. This change breaks that functionality. I'm running QGIS 2.2 on Ubuntu 14.04. Thanks, Jamie ___ 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 server is really compliant OGC?
Hi i see the getcapabilities returned from QS is not xsd valid. This deny use it in many usecases rather then getmap. We fund often qgis develop. But i Mike understand why qgis has an invalido xml respinse. Is this a not importante questione for the qgis developer. Also i like understand if resolve this is acceptable or noto. THX ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
