Hi Pedro
QGIS imports the towgs84 transformations from GDAL and adds a list of
ntv2 transformations into srs.db.
So I'm going to add/modify the ntv2 transformations (if there are no
objections from other portuguese users). For the towgs84 ones I agree
with Andre that it is better to bring it
Hi all.
The translation of command names and descriptions, and of the help, is
available for
several backends (most notably GRASS). However, at least in my installations,
the
English version is always used. Is this confirmed? If so, I think it should be
changed, as it is confusing for users.
Hi,
I hate to be the one asking for it - but I think we need more time for
testing and bugfixing.
We have a very good release feature wise - but there are still a number
of rather severe or annoying bugs to fix (some of them haven't even been
reported yet).
One month is not enough time for
Hi,
At the Swiss QGIS user meeting yesterday there were some discussions
whether people can cope with the 4 month release schedule and there were
a number of users who said that this way too fast for them. By the time
they could properly test a release, the next release is already there.
Bigger
You are right. The names are taken from the descrition files, and are in
english. No mechanism is implemented for translating them later, but I
guess it shouldn't be difficult if the translate strings are available
already for GRASS ones.
2014-06-19 8:18 GMT+02:00 Paolo Cavallini
On 06/18/2014 11:34 PM, Andreas Neumann wrote:
Hi,
At the Swiss QGIS user meeting yesterday there were some discussions
whether people can cope with the 4 month release schedule and there were
a number of users who said that this way too fast for them. By the time
they could properly test a
Il 19/06/2014 08:38, Victor Olaya ha scritto:
You are right. The names are taken from the descrition files, and are in
english. No
mechanism is implemented for translating them later, but I guess it shouldn't
be
difficult if the translate strings are available already for GRASS ones.
They are both mine,
I'll have a look and see if I need to fix the tests or the code, they
are not expected failures.
While talking about tests: Is somebody still considering / taking care
of github integration? It would be very handy to have this connected to
pull requests.
Best,
Matthias
Hi,
I discovered that if you use QGIS Server along two different project
that share the same layer name.
I.e.:
first project:
roads layer name --- I use the postgis table name roads,
filtered by highways
second project:
roads layer name --- I use the postgis table name roads, with
no
Martin,
Thanks for your answer. Indeed I did not add the layer to the registry in
my foreach loop. I did it at the end (for better performance )
Now it is working, thanks a lot !
Michael
2014-06-19 6:54 GMT+02:00 Martin Dobias wonder...@gmail.com:
Hi Michael
your code works for me. Maybe
Hi Luca,
It is a known issue.
It is not an issue about the layer name, but of layer ids. You have to
make sure that layer ids in all of your projects are unique.
You probably copy/pasted projects and this does not upgrade the layerid.
It is not a problem to have two or more identical layer
Hi all.
On behalf of Lene Fscher, from the University of Copenhagen, I'm inviting QGIS
developers to the spring 2015 hackfest in Danmark.
See below for details.
Thanks Lene!
All the best.
Messaggio Inoltrato
This is an invitation to come to Denmark in May 2015 for Developers
Awesome news! I really enjoyed the time I spend there for their QGIS course
last April, and I cannot think of a better place for a GIS hackfest :-)
2014-06-19 10:14 GMT+02:00 Paolo Cavallini cavall...@faunalia.it:
Hi all.
On behalf of Lene Fscher, from the University of Copenhagen, I'm
Hi,
again +1 with Andreas.
Alex, big corps are real people, trying to do their best to test qgis like
every other community member, and also having to do support, training,
packaging, deploying inside their corp. We often do not have teams of plenty
members on QGIS. Skipping a version for user
Il 19/06/2014 10:32, Régis Haubourg ha scritto:
Alex, big corps are real people, trying to do their best to test qgis
Hi all.
I acknowledge the problem, and I understand well its implications. I think a
proper
solution is not having longer release cycles (we had them before, without major
Hi,
Thank you Giovianni and Marco for fixing this.
I discovered the issue as well but was too busy to act or even report in
the past couple days. I did not have time to investigate the problem.
I can confirm that QGIS server and web client (both master) work fine
together again.
Thanks,
I'm going to learn more towards a longer dev cycle. 4 months open, 2 month
feature freeze.
Of course I'm also pro stable release but there is less need if you have
more time to fix bugs.
- Nathan
On Thu, Jun 19, 2014 at 6:37 PM, Paolo Cavallini cavall...@faunalia.it
wrote:
Il 19/06/2014
I agree with Victor. We had a great time there and the facilities seemed
perfect for a hackfest (in a nature setting surrounded by forest with a
lake nearby).
http://rapidlasso.com/2014/05/23/first-ever-lidar-processing-model-in-qgis/
Great canteen. Potential for evening bonfires. Green fields
Il 19/06/2014 10:51, Nathan Woodrow ha scritto:
I'm going to learn more towards a longer dev cycle. 4 months open, 2 month
feature
freeze.
we had that long ago, and it didn't work well.
Of course I'm also pro stable release but there is less need if you have more
time to
fix bugs.
On Thu, Jun 19, 2014 at 11:00:45AM +0200, Paolo Cavallini wrote:
Il 19/06/2014 10:51, Nathan Woodrow ha scritto:
I'm going to learn more towards a longer dev cycle. 4 months open, 2 month
feature
freeze.
we had that long ago, and it didn't work well.
Of course I'm also pro stable
Hi Andreas,
On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote:
I would propose to try a six month release cycle with two months feature
freeze for testing (see also my previous mail about a request for more time
for testing/bug fixing). Even a yearly release cycle would be fine, if
I'm not sure I really like the just make new releases and avoid bug fixe
releases kind of thinking. There are some places that can't roll out a
whole new release due to possible bugs from major new features, and given
how fast we move this can cause some real issues.
We don't even have to bug
On Thu, Jun 19, 2014 at 07:32:17PM +1000, Nathan Woodrow wrote:
I think the main thing is keeping the bug fix patches small so you don't
affect to much code and is easier to spot where there might be issues.
Agreed. When I spot a bug during development I often first fix it in the
stable
Hi all,
I really think we are going blind here about the bugfix or not bugfix
release ! At present, it depends completely of the package maintainers. For
example:
* Under Windows : no bugfix
* Under Debian : bug-fixed via branch release-2_2
* Ubuntugis-unstable : not bugfxied
* opensuze :
victor
I'm agree about the quality of the copenhagen offer, but remember that we
(spain) loosed again the opportunity to host a hackfest due the fact that
none answered from Girona to the offer do the hackfest there!
:| we should plan to self-organize the hackfest using CENATIC (
Il 19/06/2014 11:50, Gino Pirelli ha scritto:
I'm agree about the quality of the copenhagen offer, but remember that we
(spain)
loosed again the opportunity to host a hackfest due the fact that none
answered from
Girona to the offer do the hackfest there!
No worries, we'll be happy to go
If for a future edition you need help with organizing a hackfest in Spain,
i will be happy to help.
Also, the french QGIS community seems to be rather active, so if anyone
from it wants to do something here, I will be ready to help as much as I
can. Just let me know about what i can do. I think
I just want to clarify one thing about this discussion: we are not speaking
about delaying the 2.4 release, which users are expecting in the next 48
hours, right?
The current state of QGIS master could probably be better, but it's not
worse than 2.2 (of course, that's a perception based on my
Hi
Do you know if it is possible to have some stats in Redmine regarding
the bug counts? Especially:
- chart of number of currently opened bugs for every day past X months
(ideally displaying proportions of priorities)
- chart of number of bugs opened/closed every month/week/day
- stats about bug
Hi Nathan,
On Thu, 19. Jun 2014 at 19:32:17 +1000, Nathan Woodrow wrote:
I'm not sure I really like the just make new releases and avoid bug fixe
releases kind of thinking. There are some places that can't roll out a
whole new release due to possible bugs from major new features, and given
Hello,
Since 2.3 got out, QGIS asks the credentials for the database connection from
time to time (sometimes, instead of credentials box the project simply freezes).
Is there an option to turn this off that I didn’t notice?
I see that no one else has reported this.
Another thing that I had
Hi,
I'd like to add to the discussion that there will be more organizations
investing in bug-fixing in the future. Yesterday, a Swiss canton told me
that they will invest 5000 CHF each year in QA/bugfixing in the future.
I am pretty sure that more organizations will follow.
This means that more
Hi Tudor,
On Thu, 19. Jun 2014 at 13:15:51 +0300, tudor yahoo wrote:
Since 2.3 got out, QGIS asks the credentials for the database connection from
time to time (sometimes, instead of credentials box the project simply
freezes). Is there an option to turn this off that I didn?t notice?
It's
Il 19/06/2014 12:19, Andreas Neumann ha scritto:
I'd like to add to the discussion that there will be more organizations
investing in bug-fixing in the future. Yesterday, a Swiss canton told me
that they will invest 5000 CHF each year in QA/bugfixing in the future.
I am pretty sure that more
6 month dev (including ~1 month freeze) - release - 1 month post
release
freeze - release a bug fix release if needed - move on.
7 months is not good as that would move the schedule into undesireable
areas
(like holidays) over time.
I understand. Then why not go with 4 (1 month
Hey Jurgen,
6 month dev (including ~1 month freeze) - release - 1 month post release
freeze - release a bug fix release if needed - move on.
7 months is not good as that would move the schedule into undesireable
areas
(like holidays) over time.
I understand. We could go with 4 (1 month
We users need bug-free software more than a predictable release date. We
don't need QGIS at an exact specific time. But we cannot accept that
some features are broken that are key to our work
Exactly. There is no point having a release if people can't use it. It
will leave a bad taste,
Good to hear that there are organizations putting money into QA. Thanks
a lot.
I think there are different categories of users, experimental early
adopters and organizations going for stability at the expense of
waiting longer for new features.
To get the best for both, LTS releases may be a
Hi all.
Apparently items whose classification name includes high ASCII (àèé etc.) are
drawn
and shown in the legend, but not on the map:
http://213.136.126.133:8080/www/index.php/view/map/?repository=abidjanproject=abidjan_demo
see e.g. Routes Voies revêtues
Unsure whether it is a server or a
Hi,
I also think 4 months is too frequent (users on gis.stackexchange are still
reporting on 2.0 release!), but think anything longer than 6 months may be
too long.
What about this scenario (building upon Nathan's suggestion)?
1) 4 full months of development on master branch (currently is only
Hi Nathan,
On Thu, 19. Jun 2014 at 20:34:00 +1000, Nathan Woodrow wrote:
Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows
maintainers and they all agree with me - I think they already have don't a
good job to automated it a good deal, but it's still not fully automated
I think that LTS is kind of a really good idea.
At some extent, it's what Sourcepole is doing with its QGIS enterprise.
If we have enough companies paying for such bugfixes QA, that would be
easily feasible, but someone should be in charge of handling this.
Then, the cycle is another
Hi,
I have a very strange problem.
I have a map with a transparent gray-scale raster image and transparent
polygons on top of it.
When I export as PDF the print looks fine. When I print directly to the
printer the raster is not printed at all. I tried with three different
printers to eliminate
On 19/06/2014 11:09 pm, Andreas Neumann a.neum...@carto.net wrote:
Hi,
I have a very strange problem.
I have a map with a transparent gray-scale raster image and transparent
polygons on top of it.
When I export as PDF the print looks fine. When I print directly to the
printer the raster
Hi,
Yes - that is exactly the same behaviour I am experiencing. Vectors are
printing fine, rasters not.
Later I found out that it isn't linked to rotation. Rasters currently
don't print at all in Win64 - regardless of the rotation.
Andreas
Am 19.06.2014 13:12, schrieb Nyall Dawson:
On
Hi Martin,
not sure about charts, but some statistics available on summary
page https://hub.qgis.org/projects/quantum-gis/issues/report
2014-06-19 13:09 GMT+03:00 Martin Dobias wonder...@gmail.com:
Hi
Do you know if it is possible to have some stats in Redmine regarding
the bug counts?
Hi,
With the atlas printing I can get access to the atlas feature id and
atlas feature geometry. This is already very powerful.
Question: is it already possible to get access to any attribute in the
current atlas feature record?
My use case would be the one of linked table. Given the atlas
Hi,
I'm trying to compile QGIS git (after having success with 2.2) on
Debian Squeeze (6.0) which has GCC 4.4.2.
The compilations stops with an make error (see below for error trace).
In summary, GCC 4.4 doesn't like this line from
qgsvectorlayerfeatureiterator.cpp (line 87):
On Thu, Jun 19, 2014 at 10:12 AM, Andreas Neumann a.neum...@carto.net wrote:
Hi Luca,
It is a known issue.
It is not an issue about the layer name, but of layer ids. You have to
make sure that layer ids in all of your projects are unique.
You probably copy/pasted projects and this does not
If I could chime in as a Non-developer. I might be more of a
non-standard user (given with all the things I'm trying to do with
QGIS). I tried to keep up with all the thoughts in this email chain -
The joys of sleeping in the GMT-5 timeszone (or is it +)...anyway..
I look at QGIS has
On Thu, Jun 19, 2014 at 4:29 PM, Randal Hale
rjh...@northrivergeographic.com wrote:
A 5 to 6 month release cycle would be fine for a user (at least for me) if
there were bugfixes in between.
+1 for me, too.
In 2.0 there was a problem with spatialite -
there was no fix until the next release.
On Thu, Jun 19, 2014 at 04:36:47PM +0200, Luca Manganelli wrote:
In Qgis 1.8 there was a blocking bug and thus it would require a
1.8.1, never released, I think, because for the switch from SVN to
GIT. This bug was the impossibility to split a feature stored in a
postgis table, because QGIS
Hi devs,
I have a projet with many layers (about 100). When I open it under QGIS
2.2, I can save it and then close QGIS quite quicky (about 2 or 3 seconds)
When I do so with today QGIS master, it takes 5 minutes to save, then 5
more minutes to close QGIS !
I tried with --noplugins option, with
Hi all,
IMHO, I agree with the idea of having a LTS (maybe once a year) and
intermediate releases for development.
from my working experience, both with public institutions and privates, seems
to be more comfortable not to shift from one version to the other very often;
pretty appreciated is
Hi Randal,
On Thu, 19. Jun 2014 at 10:29:32 -0400, Randal Hale wrote:
* The linux releases only seem to get release once with no bug fixes.
Really that depends on the distro though...but for Ubuntu I think
that is correct.
Depends on the ubuntu version you have - and if there are
Hey - thanks for the explanation.
Like I said - this is just from my perspective - A user who might know
more than the average user or might be completely delusional (I vote for
delusional). Youcan see what impressions I get from things - right or
wrong.
I think whatever makes the most
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 16/06/2014 18:13, Werner Macho ha scritto:
looking closer it seems that one of them is not connected correctly ..
On 06/16/2014 04:59 PM, Paolo Cavallini wrote:
Hi all. IN Vector properties General Layer name there is a
field called
Hi,
On Fri, 23. May 2014 at 22:33:45 +0200, Tim Sutton wrote:
Feature freeze is here and I would like to start compiling the visual
changelog for QGIS 2.4.0 'Chugiak'.
I have set up a new version on
http://changelog.linfiniti.com/qgis/version/2.4.0/
Could I invite contributors and
I would not say it is useless - if you have renamed the layer you
could find the original name (on load) there ..
regards
Werner
On Thu, Jun 19, 2014 at 5:37 PM, Paolo Cavallini cavall...@faunalia.it wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 16/06/2014 18:13, Werner Macho ha
Il 19/06/2014 18:58, Werner Macho ha scritto:
I would not say it is useless - if you have renamed the layer you
could find the original name (on load) there ..
Hi Werner,
sorry, I miss your point. Here the second string is always the same as the
first one.
I must be missing something obvious.
I would like to add something else to the discussion, qgis is adding a lot of
new features and enhancements and don't get me wrong I love them, but it
seems bugs are not squashed at the same pace, I get that adding enhancements
and new features is nice and desirable but I would like one release
*Layer name* could be the name in a postgis table for example, *displayed as*
I would say should work more like an alias, in my opinion Layer name
shouldn't be editable and just be read only as this gives you the name of
the layer in provider, *displayed as* should be editable so people can use
Hello,
Le jeudi 19 juin 2014 11:57:19, Victor Olaya a écrit :
If for a future edition you need help with organizing a hackfest in Spain,
i will be happy to help.
Also, the french QGIS community seems to be rather active, so if anyone
from it wants to do something here, I will be ready to
BTW, I think we should really remove it, better sooner than later. Perhaps
just after 2.4 release?
On 18 giugno 2014 06:36:22 CEST, Nyall Dawson nyall.daw...@gmail.com wrote:
On 18 June 2014 12:24, Stefan Sylla stefansy...@gmx.de wrote:
Basically you can accomplish that by importing your
Hi devs,
I have a projet with many layers (about 100). When I open it under QGIS
2.2, I can save it and then close QGIS quite quicky (about 2 or 3 seconds)
When I do so with today QGIS master, it takes 5 minutes to save, then 5
more minutes to close QGIS !
I also noticed it and about to
it has little use to change the parameters in QGIS only.
the proposed transformations are OK and widely accepted and used in
Portugal. On the other hand it seems there is little interest from the
official authorities to contribute to the upstream projects/libraries,
so to help average Jane/Joe
Am 19.06.2014 20:37, schrieb Giovanni Manghi:
the proposed transformations are OK and widely accepted and used in
Portugal. On the other hand it seems there is little interest from the
official authorities to contribute to the upstream projects/libraries,
so to help average Jane/Joe having
Is there a specific reason why there are entries listed in thumbnail
view http://changelog.linfiniti.com/qgis/version/2.4.0/thumbs/ but not
in list view http://changelog.linfiniti.com/qgis/version/2.4.0/ ?
Best wishes,
Anita
On Thu, Jun 19, 2014 at 6:43 PM, Jürgen E. j...@norbit.de wrote:
Hi,
I want to check with developers before raising an issue, I have a postgis
table with triggers to update fields after updates, I would expect to see
the updated fields to show up after I toggle editing but right now I have to
close the attribute table and reopen it to see the changes
--
View
Hi,
I continue today with this problem. I leave here the complete log to someone
who can give a look: http://goo.gl/oBbb3u
Thank you very much!
Best regards,
Pedro
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
Is there any use case where having the possibility of opening several times
the same attribute table for a layer useful? Right now when opening
attribute table on a layer you can open n attribute tables if you don't
previously close it.
I would think if you already have an opened attribute table
I think the current way it works is correct. There have been times when I
wanted to compare the full table to a selection.
Nathan
On Jun 20, 2014 6:00 AM, AntonioLocandro antoniolocan...@hotmail.com
wrote:
Is there any use case where having the possibility of opening several times
the same
Hi, I have some project (saved with 2.2) with some edit widget
customization (hidden field, value map etc).
When opening the 2.2 project in current master the edit widgets do not work
anymore, i.e fields are visible even though they are set on hidden,
descriptions are not shown in the attributes
Hi Antonio
That would be a feature request for integrating push-notifications from
postgresql to QGIS. I think it could be possible, but it would require
changes on postgres side and QGIS side. At the moment to my knowledge
none of the dataproviders supported by QGIS currently ever sends
Hi Andre and Marco,
These parameters are outdated. The current and official parameters for
Molodensky and Bursa-Wolf transformations are those which are currently in the
Directorate-General of the Territory website [0], and which are those that I
proposed.
In addition, the Datum
Hi Salvatore,
did that just appear right now? The changes to the edit widgets have
been merged a couple of weeks ago already. It would be good to open a
bug report with a demo project.
Best,
Matthias
On Don 19 Jun 2014 22:07:24 CEST, Salvatore Larosa wrote:
Hi, I have some project (saved
OK, that is actually quite handy instead of having to open another QGIS
session.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Attribute-table-opening-several-instances-tp5146844p5146853.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
Hi Matthias,
On Thu, Jun 19, 2014 at 10:49 PM, Matthias Kuhn matthias.k...@gmx.ch
wrote:
Hi Salvatore,
did that just appear right now? The changes to the edit widgets have
been merged a couple of weeks ago already. It would be good to open a
bug report with a demo project.
Sorry I noticed
I continue today with this problem. I leave here the complete log to someone
who
can give a look: http://goo.gl/oBbb3u
Sorry, the link was blocked. Here is the original:
https://dl.dropboxusercontent.com/u/5772257/qgis/log.txt
Thanks!
Best regards,
Pedro
On 19/06/2014 11:56 pm, Andreas Neumann a.neum...@carto.net wrote:
Hi,
Question: is it already possible to get access to any attribute in the
current atlas feature record?
Hi Andreas,
I've been working on this. I nearly had it ready for 2.4, but in the
end I wasn't comfortable pushing it
I have been through and updated all the entries - you should see them
published at: http://changelog.linfiniti.com/qgis/version/2.4.0/
Thanks to all those that contributed. If anyone has additions please go
ahead and add them and I will edit and publish.
Regards
Tim
On Fri, Jun 20, 2014 at
Hi all,
I thought I'd raise an issue which has been on my mind a bit lately,
and I'm not sure how to proceed with fixing it. At the moment there's
a huge lack of consistency in function names in the QGIS expression
engine. Here's some examples:
- Some functions use the naming convention of
Hey Nyall,
I would like to revisit this with you at some stage and maybe explore the
expression context stuff. Having one global variable for all this isn't
going to scale if we ever allow bulk atlas export.
- Nathan
On Fri, Jun 20, 2014 at 1:34 PM, Nyall Dawson nyall.daw...@gmail.com
wrote:
Hi,
Yes. When I initially saw $feature and $numfeatures I thought - oh cool
- I can have access to the feature-record - although - as you said it
wasn't clear which feature this would be refering to. This naming is
really sub-optimal and hopefully we can still correct it.
When was this
Hi Nyall,
Cool that you had a look at this already. It would open up a lot of
possibilities.
Along the same lines I noticed that the table in print composer is not
updated correctly when iterating in the atlas preview mode (don't know
if it works when generating the pdfs).
My usage scenario was
Hi Nyall
On Fri, Jun 20, 2014 at 10:34 AM, Nyall Dawson nyall.daw...@gmail.com wrote:
What I've done is:
- Add an $atlasfeature variable, which returns the current atlas feature
- Add a $currentfeature variable, which returns the current feature
which is being evaluated (unfortunately
On 20 June 2014 15:18, Martin Dobias wonder...@gmail.com wrote:
May I suggest an alternative approach: to introduce dot notation, e.g.
$atlasfeature.area_code - that looks much more like SQL syntax and it
is easier to remember and use. It would require small adjustments to
the parser and
On 20 June 2014 15:07, Andreas Neumann a.neum...@carto.net wrote:
Hi Nyall,
Cool that you had a look at this already. It would open up a lot of
possibilities.
Along the same lines I noticed that the table in print composer is not
updated correctly when iterating in the atlas preview mode
On 20.06.2014 06:19, Nyall Dawson wrote:
Hi all,
I thought I'd raise an issue which has been on my mind a bit lately,
and I'm not sure how to proceed with fixing it. At the moment there's
a huge lack of consistency in function names in the QGIS expression
engine. Here's some examples:
- Some
Hi again
On Fri, Jun 20, 2014 at 11:19 AM, Nyall Dawson nyall.daw...@gmail.com wrote:
Hi all,
I thought I'd raise an issue which has been on my mind a bit lately,
and I'm not sure how to proceed with fixing it. At the moment there's
a huge lack of consistency in function names in the QGIS
On 20 June 2014 15:02, Andreas Neumann a.neum...@carto.net wrote:
Hi,
Yes. When I initially saw $feature and $numfeatures I thought - oh cool
- I can have access to the feature-record - although - as you said it
wasn't clear which feature this would be refering to. This naming is
really
On 20 June 2014 15:31, Denis Rouzaud denis.rouz...@gmail.com wrote:
Regarding clamp, since this was added during developpement phase and nothing
was released since, I would vote for changing it now.
People using master know this might happen. Just send a mail to the list
saying this.
Clamp
On Fri, Jun 20, 2014 at 12:29 PM, Nyall Dawson nyall.daw...@gmail.com wrote:
On 20 June 2014 15:18, Martin Dobias wonder...@gmail.com wrote:
May I suggest an alternative approach: to introduce dot notation, e.g.
$atlasfeature.area_code - that looks much more like SQL syntax and it
is easier
93 matches
Mail list logo
