On Tue, Mar 8, 2011 at 4:55 AM, William Kyngesburye
wrote:
> Lines 806-826, still some old shortcuts->... stuff here. It won't compile.
Hi William,
r15387 should fix that.
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://l
Hi Carson:
On 07/03/2011 20:38, Paolo Cavallini wrote:
Il giorno lun, 07/03/2011 alle 18.16 +, Carson Farmer ha scritto:
- Export/add geometry columns (this can now be done quite easily from
the field calculator, and my version appears to have issues with
certain vector formats)
I find yo
+1
---
Paolo Cavallini http://faunalia.it/pc
- Reply message -
Da: "Borys Jurgiel"
A:
Oggetto: [Qgis-developer] Raster providers
Data: lun, mar 7, 2011 23:22
Dnia niedziela 06 marca 2011 o 21:18:59 Radim Blazek napisał(a):
> Hi,
> I am ready to merge raster-providers branch to trunk.
Lines 806-826, still some old shortcuts->... stuff here. It won't compile.
-
William Kyngesburye
http://www.kyngchaos.com/
"The beast is actively interested only in now, and, as it is always now and
always shall be, there is an eternity of time for the accomplishment of
objects."
- the w
I think overwriting an existing layer in memory is not a good practice.
Updating existing geometry or attribute data would be great, such as when one
merges two themes, and when the second theme is only contributing matching
attribute. But overwriting should at least not be the default behavior
Dnia poniedziałek 07 marca 2011 o 23:48:46 Carson Farmer napisał(a):
> Ok, I'm getting the overwhelming feeling that people want to be able
> to 'write' to memory layers. I'll try to add this functionality.
Yup!!
> However, I really don't think this should be the 'default' or
> primary/sole o
Hi Marco
On Thu, Mar 3, 2011 at 4:27 PM, Marco Bernasocchi
wrote:
> QgsLegendInterface::groupLayerRelationship() returns this:
> [group0, group1, subGroupOfGroup0]
> BUT
> QgsLegendInterface::groups() returns:
> [group0, subGroupOfGroup0, group1]
>
> notice the difference in the order, is this do
Ok, I'm getting the overwhelming feeling that people want to be able
to 'write' to memory layers. I'll try to add this functionality.
However, I really don't think this should be the 'default' or
primary/sole output type. I think what I'll probably do is simply add
'output options' to the current o
Hi Stefan, All,
coming from webdesign I use Aptana (eclipse derivation) with pydev with
success. Eclipse itself always managed to drive me crazy for some
reasons... I tried as well spe and erich and didn't like the feeling.
Ggeany and gedit with many plugins are very light but Aptana/pydev is
what
Ok, but we have to be careful here... because overwriting a layer that
we are currently working on could lead to problems when the data
provider tries to access features that have been overwritten/erased.
Also, what about the case where we have a line layer that we are
buffering?
Carson
On Mon, M
Yes please to this option (fTools writing to a memory layer)!!
I was thinking of coding for a couple of the fTools functions I used myself.
It would be great to have it in fTools by default :-)
Note: I've uploaded a memory saver plugin that allows memory layers to be
persisted alongside the p
On Mon, Mar 7, 2011 at 10:33 PM, Borys Jurgiel wrote:
> Dnia poniedziałek 07 marca 2011 o 23:31:28 Carson Farmer napisał(a):
>> > Btw. When saving to files, kinda garbage collector would be extremely
>> > usable:)
>>
>> Garbage collector? You mean memory-wise, or temporary file type garbage?
>
> t
Dnia poniedziałek 07 marca 2011 o 23:32:21 Nathan Woodrow napisał(a):
> I would like to see one more option on that list:
>
>- Save to current selected layer
>
> This would write straight back to the current selected layer. I don't
> always want a new layer when doing things like buffers etc
Dnia poniedziałek 07 marca 2011 o 23:31:28 Carson Farmer napisał(a):
> > Btw. When saving to files, kinda garbage collector would be extremely
> > usable:)
>
> Garbage collector? You mean memory-wise, or temporary file type garbage?
temporary files :)
_
I would like to see one more option on that list:
- Save to current selected layer
This would write straight back to the current selected layer. I don't
always want a new layer when doing things like buffers etc.
- Nathan
On Tue, Mar 8, 2011 at 8:29 AM, Borys Jurgiel wrote:
> > > H im
> Btw. When saving to files, kinda garbage collector would be extremely usable:)
Garbage collector? You mean memory-wise, or temporary file type garbage?
--
Carson J. Q. Farmer
ISSP Doctoral Fellow
National Centre for Geocomputation
National University of Ireland, Maynooth,
http://www.carsonfarme
> > H implementing other file formats to the QgsVectorFileWriter is quite
> > easy, while AFAIK writing to the memory layer requires another approach.
> > Maybe we should encapsulate the QgsVectorFileWriter to provide an
> > universal class for the 1.7 API? Just a thought - it's late and my bra
Dnia niedziela 06 marca 2011 o 21:18:59 Radim Blazek napisał(a):
> Hi,
> I am ready to merge raster-providers branch to trunk. Are you ready too?
>
> Radim
Just to let you know, some of us are looking forward :-)
There's less and less time for testing :)
_
>> > One thing I'd really like to do is add the capability to output other
>> > formats besides shapefiles (I'm not a big shapefile fan these days,
>> > field name limitations are a hassle). I might try move over the
>> > geometry and geoprocessing tools first, as they seem to be the most
>> > freq
> Starting with r15381 Field calculator can extract X, Y and perimeter,
> so I think this tool can be removed
Just a thought - x and y in the field calculator require a couple of clicks.
In the ftools you can do it by one click...
> > One thing I'd really like to do is add the capability to outp
Hi Carson
On Mon, 7 Mar 2011 18:16:23 +
Carson Farmer wrote:
> - Export/add geometry columns (this can now be done quite easily from
> the field calculator, and my version appears to have issues with
> certain vector formats)
Starting with r15381 Field calculator can extract X, Y and perimet
Hi Radim
Great! +1 for merging from me too.
Regards,
Marco
Am Sonntag, 6. März 2011, 21.18:59 schrieb Radim Blazek:
> Hi,
> I am ready to merge raster-providers branch to trunk. Are you ready too?
>
> Radim
> ___
> Qgis-developer mailing list
> Qgis-d
Hi Martin,
Marco was quicker, but here is my answer as well...
Am Montag, 7. März 2011, um 16.26:19 schrieb Martin Dobias:
> Hi Marco
>
> On Mon, Mar 7, 2011 at 4:11 PM, Marco Hugentobler
>
> wrote:
> > Hi
> >
> >> An alternative option is that we just freeze our 'stable' releases at
> >> 1.6
Hi Martin
I'm also in favour of a rule based renderer that follows closely the logic of
SLD. It would be a big plus for QGIS server too. Currently, it's SLD
capabilities are built on top of the old renderer, so no overpainting, etc.
And yes, with a nice GUI, it will be as user-friendly as the o
> Yes, but your join by location feature is exceptional and needs to remain. I
> don't know of any alternative to that.
agreed
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Hi Martin
> I thought I will do it the other way round: to create a new branch
> from trunk (e.g. threading_branch2) and merge the commits from
> threading_branch there. Looks easier to port those few dozens of
> commits rather than porting nearly 2000(!) commits from trunk back to
> the branch.
Hi Carson,
On Mar 7, 2011, at 11:17 AM, Carson Farmer wrote:
>>> - Join attributes (this was never really meant as a 'solution', but
>>> rather a temporary 'hack' to allow for table joints, but it is slow
>>> and combersome, and requires the creation of a new field, whereas the
>>> new join capab
> I find your solution more intuitive for newbies, and I would like to
> keep it, at least for now. Can calculator extract x and y from points?
No it can't, and perimeter calculation seems to be an issue as well.
Ok, well then I might change this to be a wrapper around the field
calculator, that wa
> the field calculator misses to compute the perimeter of the polygons.
> Once it will do it you can retire "Export/add geometry columns" ;)
Ok, I'll have a look at that tonight then
Carson
--
Carson J. Q. Farmer
ISSP Doctoral Fellow
National Centre for Geocomputation
National University of Irel
Dnia poniedziałek 07 marca 2011 o 19:28:09 Giovanni Manghi napisał(a):
> Hi Carson,
>
> > - Export/add geometry columns (this can now be done quite easily from
> > the field calculator, and my version appears to have issues with
> > certain vector formats)
>
> the field calculator misses to compu
> Can calculator extract x and y from points?
right, the calculator also misses this feature.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Il giorno lun, 07/03/2011 alle 18.16 +, Carson Farmer ha scritto:
> - Export/add geometry columns (this can now be done quite easily from
> the field calculator, and my version appears to have issues with
> certain vector formats)
I find your solution more intuitive for newbies, and I would l
Hi Carson,
> - Export/add geometry columns (this can now be done quite easily from
> the field calculator, and my version appears to have issues with
> certain vector formats)
the field calculator misses to compute the perimeter of the polygons.
Once it will do it you can retire "Export/add geom
Hi Devs,
One of my favorite outcomes from developing fTools, is actually when
one or two fTools functions become redundant due to new features in
base QGIS. The reason isn't because that means one less tool for me to
worry about, but rather because it means things are progressing... and
with QGIS
Hi Marco
On Mon, Mar 7, 2011 at 4:11 PM, Marco Hugentobler
wrote:
> Hi
>
>> An alternative option is that we just freeze our 'stable' releases at
>> 1.6 (or maybe a last 1.7 release with no threading) and jump right on
>> to doing 1.9.x releases in the run up to September. However I would
>> rath
Hi
> An alternative option is that we just freeze our 'stable' releases at
> 1.6 (or maybe a last 1.7 release with no threading) and jump right on
> to doing 1.9.x releases in the run up to September. However I would
> rather put the things we are developing into mainstream releases since
> (I kn
Hi
On Mon, Mar 7, 2011 at 3:49 PM, Martin Dobias wrote:
> On Mon, Mar 7, 2011 at 2:37 PM, Paolo Cavallini wrote:
>> Il giorno lun, 07/03/2011 alle 15.18 +0200, Tim Sutton ha scritto:
>>
>>> to doing 1.9.x releases in the run up to September. However I would
>>> rather put the things we are dev
Hi
On Mon, Mar 7, 2011 at 3:50 PM, Giovanni Manghi
wrote:
> Hi,
>
> On Fri, 2011-03-04 at 19:02 +0200, Tim Sutton wrote:
>> Hi
>> Agreed Ill remove it - now is the time to start cleaning house on the
>> way to 2.0...
>
>
> people find also weird that the north arrow, barscale and copyright are
>
On Mon, Mar 7, 2011 at 2:24 PM, Tim Sutton wrote:
> Hi
>
> +1 from meit was really fun building that whole mainwindow by
> handin a masochistic kind of waylets not perpetuate the 'fun'
> if we don't need to...
One more thing: I would also suggest removing status bar tips from the
acti
Hi,
On Fri, 2011-03-04 at 19:02 +0200, Tim Sutton wrote:
> Hi
> Agreed Ill remove it - now is the time to start cleaning house on the
> way to 2.0...
people find also weird that the north arrow, barscale and copyright are
available as plugins... can they e part of this "house cleaning" and
pass
On Mon, Mar 7, 2011 at 2:37 PM, Paolo Cavallini wrote:
> Il giorno lun, 07/03/2011 alle 15.18 +0200, Tim Sutton ha scritto:
>
>> to doing 1.9.x releases in the run up to September. However I would
>> rather put the things we are developing into mainstream releases since
>> (I know some people hate
Hi Tim!
On Mon, Mar 7, 2011 at 2:18 PM, Tim Sutton wrote:
>
> Is it not possible to reimplement the old methods as thin wrappers
> around the new QgsFeatureIterator class and at the same time mark them
> in doxygen as deprecated? Sorry I havent looked in the code itself so
> it may be a dumb ques
Il giorno lun, 07/03/2011 alle 15.18 +0200, Tim Sutton ha scritto:
> to doing 1.9.x releases in the run up to September. However I would
> rather put the things we are developing into mainstream releases since
> (I know some people hate this idea) our users are also our testers.
Agreed, even if i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Other possibility would be to merge just stuff that is safe to merge
> (various optimizations and refactorings) and keep back the threading
> until we can break backward compatibility.
>
> Comments?
Thanks for information, great that You solved GI
Hi
+1 from meit was really fun building that whole mainwindow by
handin a masochistic kind of waylets not perpetuate the 'fun'
if we don't need to...
Regards
Tim
On Mon, Mar 7, 2011 at 12:57 PM, Nathan Woodrow wrote:
> When I first started working on qgis I wondered why all that co
Hi Martin
On Mon, Mar 7, 2011 at 12:34 PM, Martin Dobias wrote:
> On Mon, Mar 7, 2011 at 11:20 AM, Ivan Mincik wrote:
>> Martin, have You found some good solution for threading problems in
>> Python (threading branch) ?
>
> Yes, I have fixed that few weeks ago.
>
> But the problems I am facing n
On Sun, 2011-03-06 at 11:01 -0800, Bob and Deb wrote:
> I know that the Value Tool is a 3rd party plugin, but it would be nice
> if the raster-provider could work with it. All of my rasters are
> reported as being "out of extent".
The value tool plugin is so useful (and fundamental) when doing ra
seems like qt (the commercial part) is now sold to a finnish company
named digia. I don't know anything about digia, but it is probably good
that Nokia let go of qt instead of letting it slowly die ...
http://blog.qt.nokia.com/
not much mention about the open source part of qt.
Andreas
--
--
When I first started working on qgis I wondered why all that code was there
and not in the ui file.
+1 for moving it all to the ui file. Would make things a lot nicer and
cleaner to edit.
On Mon, Mar 7, 2011 at 8:41 PM, Martin Dobias wrote:
> Hi devs
>
> recently I wondered why we still have t
Hi devs
recently I wondered why we still have the whole QGIS app gui
construction (actions, menus, toolbars) in the QgisApp class. I
remember that in the early Qt4 days this was necessary since there was
no support in Qt Designer to create menus/toolbars. But nowadays it is
perfectly possible, so
On Mon, Mar 7, 2011 at 11:20 AM, Ivan Mincik wrote:
> Martin, have You found some good solution for threading problems in
> Python (threading branch) ?
Yes, I have fixed that few weeks ago.
But the problems I am facing now are related to compatibility - I was
unable to reach 100% compatibility w
Martin, have You found some good solution for threading problems in
Python (threading branch) ?
Ivan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
2011/3/6 Germán Carrillo :
> Hi all,
> I have added some functionalities to the plugin [1], now it:
> * Has PostGIS rasters (WKTRaster) support (Based on WKTRaster QGIS plugin.)
> * Has a layer list widget displaying a number of layer properties.
> On the other hand, the antialiasing feature has be
Hi
By the way I just wanted to add that the process of registering a
plugin from within QGIS can easily be achieved just by popping up a
QWebView control with url pointed to the appropriate page. I am using
this same technique for a 'first run' wizard I am working on that will
allow the user to re
W dniu 06.03.2011 10:53, Tim Sutton pisze:
Hi
On Sun, Mar 6, 2011 at 9:08 AM, Paolo Cavallini wrote:
Il giorno sab, 05/03/2011 alle 23.39 +0200, Tim Sutton ha scritto:
just pick something :-) Now I've become kind of partial to the splash
screen in trunk. It includes many people from the devel
Il giorno lun, 07/03/2011 alle 09.14 +0100, Alessandro Pasotti ha
scritto:
> Can we use this time (before the hackfest) to talk about and reach a
> decision about this further improvements of the plugins website ?
If we do not reach a firm conclusion about this before, I think the HF
is our best
2011/3/5 Paolo Cavallini
> Il giorno sab, 05/03/2011 alle 10.17 +0100, Alessandro Pasotti ha
> scritto:
>
> > I cannot see dramatic advantages of an uploading function from within
> > QGIS. BTW this could be quite easily done with a RPC call (RPC4Django
> > handles this quite well).
>
> I agree t
57 matches
Mail list logo
