Re: [Qgis-developer] crash on startup
Hi, I'm also experiencing this problem after the last Debian (Wheezy) upgrade. I tried this solution, creating a link, but still giving me this error: pedro@debian-amilo:~$ qgis Warning: loading of qgis translation failed [/usr/share/qgis/i18n//qgis_en_US] Warning: loading of qt translation failed [/usr/share/qt4/translations/qt_en_US] qgis.bin: /tmp/buildd/sip4-4.13.2/siplib/siplib.c:10938: sipEnumType_alloc: Assertiva `(((currentType)->td_flags & 0x0007) == 0x0003)' falhou. Abortado Here is the link that I created: pedro@debian-amilo:~$ ls -lh /usr/lib/x86_64-linux-gnu/libQtWebKit.so lrwxrwxrwx 1 root root 23 Mai 13 00:11 /usr/lib/x86_64-linux-gnu/libQtWebKit.so -> /usr/lib/libQtWebKit.so What am I doing wrong? I've also tried to upgrade the libqtwebkit-dev and libqtwebkit4 with the sid repository, but QGIS continues to crash. Thanks! Best regards, Pedro Venâncio - Original Message - From: Paolo Cavallini -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 12/05/2012 08:25, Werner Macho ha scritto: > I think it should be reportet upstream to debian package maintainer .. > for now you can solve it by setting a link from > /usr/lib/libQtWebKit.so to > /usr/lib/x86_64-linux-gnu/ > > lrssvt pointed out this solution yesterday on IRC Thanks a lot Werner (and lrssvt), that made it. I'm going to report the issue upstream. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] how to create a new geometry from an existing one with python
Hi list I'm trying to code some tools for working with lines layers using python. One such tool is meant to create parallel lines. I am trying to create my new line geometry by first copying the geometry of a previously selected linestring and then translating it according to a specified distance. But I can't seem to find the correct way of copying the geometry. I am on Ubuntu 11.10, using QGIS compiled from master #033d58d, built today. For testing, I'm using layers created with the 'New Memory Layer' plugin, which uses the memory provider. I've tried the following approaches: # python code line_geometry = qgis.utils.iface.mapCanvas().currentLayer().selectedFeatures()[-1].geometry() # approach 1 new_geometry = QgsGeometry(line_geometry) -> Exception: unknown # approach 2 new_geometry = QgsGeometry.fromPolyline(line_geometry.asPolyline()) -> no error is thrown, but nothing happens # approach 3 wkb = line_geometry.asWkb() g.fromWkb(wkb, len(wkb)) -> RuntimeError: underlying C/C++ object has been deleted Thanks for your input! -- ___ ___ __ Ricardo Garcia Silva ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] The WFS Client don't allow multiple SRS
Hi, I'm testing the WFS client and notice it don't understand the multiple srs from getcapabilities. I try to inquiry with the WFS client from a wfs server where there is three available SRS for each layer. I verify this with a call to getcapabilities, that will response this: For every layer available: urn:ogc:def:crs:EPSG::25832 urn:ogc:def:crs:EPSG::3003 urn:ogc:def:crs:EPSG::4326 But in the client WFS the only reported SRS is that in the DefaultSRS tag. Is this a know bug ? -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Threads in sextante
On Sat, May 12, 2012 at 5:41 PM, Giuseppe Sucameli wrote: > Hi, > > On Sat, May 12, 2012 at 8:56 PM, Etienne Tourigny > wrote: >> Any way ftools could be adapted to use the same approach as gdaltools? > > yes, it could. The only problem running non-modal dialogs > are crashes accessing deleted objects like layers removed by > the user. > > The solution implemented in GdalTools is to use the > QgsMapLayerRegistry signals to update the list of layers > and the combos. > >> However - this hack might work - when the characteristic >> '0...10...20...30...40...50...60...70...80...90...100 - done.' output >> is detected (say after '0...10') then the output would be interpreted >> as progress report, which could be used to update the gui every 10% - >> until 100 is read. I have never seen output mixed with progress report >> in gdal utilities, although I may be wrong. > > yes, it could be done. > >>> Stopping/killing the execution thread should be enough. >>> GdalTools asks for confirmation and then does it. >> >> This has to be done manually, externally to qgis though. > > Externally? I mean finding the thread through 'top' (in unixes) and killing it, rather than having a gui to do it (like a Cancel button) > >> Would it be possible to have a "Cancel" button in the dialogs >> that would respond to user input, or respond to the Escape key >> when pressed? > > Yes, why not? > I'm not sure I've understood. I was just wondering if the ui could respond to a click on a Cancel button, or a hit on the escape key - but I guess it could since the operation is done in another (non-blocking) thread. > Also, this could enable several similar operations to be done in parallel - as long as they are not working on the same output files. > [[snip]] >> Am I wrong to think that currently, 2 gdaltools operations could run >> concurrently with the same output file, with all associated problems? > > uhm.. sorry, I've read too fast and I misunderstood your words. > > No, I don't know what happens if two tools wrote on the same output, > though I think GDAL locks the output file until it finished. > > Let's give me a try :) > > BTW, why should two tools work on the same output file? user error - in the case of a more complex workflow with sextante this might happen more often, so it would be good to make sure. regards, Etienne > Cheers. > >> thanks >> Etienne >> >>> >>> Regards. >>> Etienne On Fri, May 11, 2012 at 3:25 AM, Paolo Cavallini wrote: > Il 10/05/2012 23:15, Martin Dobias ha scritto: > >> What should be the benefit of multithreading here? To run algorithms >> outside from main thread so that GUI does not get blocked? > > IMHO this is the main reason; I think the way GDALTools work is fine for > the user. > All the best. > > -- > Paolo Cavallini - Faunalia > www.faunalia.eu > Full contact details at www.faunalia.eu/pc > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>> >>> >>> -- >>> Giuseppe Sucameli > > > > -- > Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Threads in sextante
Hi, On Sat, May 12, 2012 at 8:56 PM, Etienne Tourigny wrote: > Any way ftools could be adapted to use the same approach as gdaltools? yes, it could. The only problem running non-modal dialogs are crashes accessing deleted objects like layers removed by the user. The solution implemented in GdalTools is to use the QgsMapLayerRegistry signals to update the list of layers and the combos. > However - this hack might work - when the characteristic > '0...10...20...30...40...50...60...70...80...90...100 - done.' output > is detected (say after '0...10') then the output would be interpreted > as progress report, which could be used to update the gui every 10% - > until 100 is read. I have never seen output mixed with progress report > in gdal utilities, although I may be wrong. yes, it could be done. >> Stopping/killing the execution thread should be enough. >> GdalTools asks for confirmation and then does it. > > This has to be done manually, externally to qgis though. Externally? > Would it be possible to have a "Cancel" button in the dialogs > that would respond to user input, or respond to the Escape key > when pressed? Yes, why not? I'm not sure I've understood. >>> Also, this could enable several similar operations to be done in >>> parallel - as long as they are not working on the same output files. [[snip]] > Am I wrong to think that currently, 2 gdaltools operations could run > concurrently with the same output file, with all associated problems? uhm.. sorry, I've read too fast and I misunderstood your words. No, I don't know what happens if two tools wrote on the same output, though I think GDAL locks the output file until it finished. Let's give me a try :) BTW, why should two tools work on the same output file? Cheers. > thanks > Etienne > >> >> Regards. >> >>> Etienne >>> >>> On Fri, May 11, 2012 at 3:25 AM, Paolo Cavallini >>> wrote: Il 10/05/2012 23:15, Martin Dobias ha scritto: > What should be the benefit of multithreading here? To run algorithms > outside from main thread so that GUI does not get blocked? IMHO this is the main reason; I think the way GDALTools work is fine for the user. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> ___ >>> Qgis-developer mailing list >>> Qgis-developer@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> >> -- >> Giuseppe Sucameli -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Threads in sextante
Hi Giuseppe! On Sat, May 12, 2012 at 2:12 PM, Giuseppe Sucameli wrote: > Hi Etienne, > > On Sat, May 12, 2012 at 6:47 PM, Etienne Tourigny > wrote: >> I always thought that gdaltools and ftools should be non-blocking >> (unless I am mistaken, they are currently blocking the rest of the >> app), especially if the operation takes a long time. > > GdalTools is non-blocking (uses QProcess to execute commands) > and its dialogs are non-modal, so more operations can run > concurrently and users can open all the gdaltools dialogs they need. I stand corrected then - I guess I was confusing it with ftools, which is blocking and does not spawn a process. Any way ftools could be adapted to use the same approach as gdaltools? >> This might have issues though with >> >> 1) progress report - can this be done by the executing thread? > > That's missing in GdalTools. > > Generally speaking, every time the execution thread emits the > progress signal the main thread (GUI thread) updates the progressbar. > > Focused to GdalTools, it should get progress percent from the > QProcess output but unfortunately a lot of other info goes to > the process output. If it were using the gdal api directly, it could get the progress and report it though QProcess - but that's not possible as gdaltools calls the command-line apps directly. There was some talk on the gdal-dev mailing list about putting the gdal utilities in the api, but this probably won't happen really soon. However - this hack might work - when the characteristic '0...10...20...30...40...50...60...70...80...90...100 - done.' output is detected (say after '0...10') then the output would be interpreted as progress report, which could be used to update the gui every 10% - until 100 is read. I have never seen output mixed with progress report in gdal utilities, although I may be wrong. An example with gdalwarp: $ gdalwarp -s_srs EPSG:4326 -ts 6000 6000 -of GTiff /data/research/work/modis/2000-2010_jun-may/MCD45.ba_qa.cerrado.2000-2001.wgs84.tif /data/tmp/tmp1.tif Creating output file that is 6000P x 6000L. Processing input file /data/research/work/modis/2000-2010_jun-may/MCD45.ba_qa.cerrado.2000-2001.wgs84.tif. Using internal nodata values (eg. 0) for image /data/research/work/modis/2000-2010_jun-may/MCD45.ba_qa.cerrado.2000-2001.wgs84.tif. 0...10...20...30...40...50...60...70...80...90...100 - done. $ > >> 2) what happens when the operation finishes > > The execution thread emits a signal and the main thread > display a message according to the signal (error, finished). > >> Ideally, there should be a way to cancel an operation, if it takes too >> long (e.g. escape key when the operation window has focus) > > Stopping/killing the execution thread should be enough. > GdalTools asks for confirmation and then does it. This has to be done manually, externally to qgis though. Would it be possible to have a "Cancel" button in the dialogs that would respond to user input, or respond to the Escape key when pressed? > >> Also, this could enable several similar operations to be done in >> parallel - as long as they are not working on the same output files. > > That must be taken care from the framework: an operation that needs > as input outputs generated by other operations must be started only > after the required outputs are ready... > ... and the key is to use signals, again. Am I wrong to think that currently, 2 gdaltools operations could run concurrently with the same output file, with all associated problems? You are talking about implementing this sort of thread-safe checks into the sextante framework, right? thanks Etienne > > Regards. > >> Etienne >> >> On Fri, May 11, 2012 at 3:25 AM, Paolo Cavallini >> wrote: >>> Il 10/05/2012 23:15, Martin Dobias ha scritto: >>> What should be the benefit of multithreading here? To run algorithms outside from main thread so that GUI does not get blocked? >>> >>> IMHO this is the main reason; I think the way GDALTools work is fine for >>> the user. >>> All the best. >>> >>> -- >>> Paolo Cavallini - Faunalia >>> www.faunalia.eu >>> Full contact details at www.faunalia.eu/pc >>> ___ >>> Qgis-developer mailing list >>> Qgis-developer@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > -- > Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Threads in sextante
Hi Etienne, On Sat, May 12, 2012 at 6:47 PM, Etienne Tourigny wrote: > I always thought that gdaltools and ftools should be non-blocking > (unless I am mistaken, they are currently blocking the rest of the > app), especially if the operation takes a long time. GdalTools is non-blocking (uses QProcess to execute commands) and its dialogs are non-modal, so more operations can run concurrently and users can open all the gdaltools dialogs they need. > This might have issues though with > > 1) progress report - can this be done by the executing thread? That's missing in GdalTools. Generally speaking, every time the execution thread emits the progress signal the main thread (GUI thread) updates the progressbar. Focused to GdalTools, it should get progress percent from the QProcess output but unfortunately a lot of other info goes to the process output. > 2) what happens when the operation finishes The execution thread emits a signal and the main thread display a message according to the signal (error, finished). > Ideally, there should be a way to cancel an operation, if it takes too > long (e.g. escape key when the operation window has focus) Stopping/killing the execution thread should be enough. GdalTools asks for confirmation and then does it. > Also, this could enable several similar operations to be done in > parallel - as long as they are not working on the same output files. That must be taken care from the framework: an operation that needs as input outputs generated by other operations must be started only after the required outputs are ready... ... and the key is to use signals, again. Regards. > Etienne > > On Fri, May 11, 2012 at 3:25 AM, Paolo Cavallini > wrote: >> Il 10/05/2012 23:15, Martin Dobias ha scritto: >> >>> What should be the benefit of multithreading here? To run algorithms >>> outside from main thread so that GUI does not get blocked? >> >> IMHO this is the main reason; I think the way GDALTools work is fine for the >> user. >> All the best. >> >> -- >> Paolo Cavallini - Faunalia >> www.faunalia.eu >> Full contact details at www.faunalia.eu/pc >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Threads in sextante
I always thought that gdaltools and ftools should be non-blocking (unless I am mistaken, they are currently blocking the rest of the app), especially if the operation takes a long time. This might have issues though with 1) progress report - can this be done by the executing thread? 2) what happens when the operation finishes Ideally, there should be a way to cancel an operation, if it takes too long (e.g. escape key when the operation window has focus) Also, this could enable several similar operations to be done in parallel - as long as they are not working on the same output files. Etienne On Fri, May 11, 2012 at 3:25 AM, Paolo Cavallini wrote: > Il 10/05/2012 23:15, Martin Dobias ha scritto: > >> What should be the benefit of multithreading here? To run algorithms >> outside from main thread so that GUI does not get blocked? > > IMHO this is the main reason; I think the way GDALTools work is fine for the > user. > All the best. > > -- > Paolo Cavallini - Faunalia > www.faunalia.eu > Full contact details at www.faunalia.eu/pc > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] crash on startup
Il giorno sab, 12/05/2012 alle 08.19 +0200, Paolo Cavallini ha scritto: > Of course I have: > > libqtwebkit-dev > libqtwebkit4 > > do I need other packages? > All the best, and thanks. nothing more! Regards, -SL -- Salvatore Larosa linkedIn: http://linkedin.com/in/larosasalvatore twitter: @lrssvt skype: s.larosa IRC: lrssvt ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
