Although I'll be not at the Hackfest and would have to communicate the
postpone to the translators ..
I vote also for 3 ..
Like to see all relevant issues cleaned out..
3
regards
Werner
Am 31.03.2011 09:10, schrieb Radim Blazek:
3
Radim
On Thu, Mar 31, 2011 at 8:54 AM, Tim
Hi Tim
3 for me too (assuming there is still space to discuss future development
directions at the hackfest).
Regards,
Marco
Am Donnerstag, 31. März 2011, um 08.54:11 schrieb Tim Sutton:
Hi all
There has been some discussion on this list about extending the
release schedule for 1.7. The
Hi Tim,
My vote: option 3
Mine too.
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20
Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
--
norBIT
Hi all,
I vote 3. Count me for bug hunting!
3 also for me. I count to help closing invalid tickets and testing new
commits.
cheers
-- Giovanni --
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
I understand your point Paolo, and I can't contribute to C++ coding now, so
I can't support it practically.
But:
- if Camilo can do it, he's welcome. I suppose he's conscious of what it
means, also from a lon term support point of view... With GRASS module we
have the same issues, am I wrong?
On Wed, Mar 9, 2011 at 12:24 PM, Giovanni Manghi
giovanni.man...@gmail.com wrote:
Regardless their CRS, GRASS rasters are always added to qgis with WGS84 CRS.
For me, QGIS sets CRS to raster's CRS but some info seems to be lost
in createFromWkt().
GRASS gives:
Hi devs,
On Thu, Mar 31, 2011 at 8:54 AM, Tim Sutton li...@linfiniti.com wrote:
My vote: option 3
I agree with you, +1 for the option 3.
Cheers.
--
Giuseppe Sucameli
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
On Thu, 31. Mar 2011 at 11:12:42 +0200, Radim Blazek wrote:
On Wed, Mar 9, 2011 at 12:24 PM, Giovanni Manghi
giovanni.man...@gmail.com wrote:
Regardless their CRS, GRASS rasters are always added to qgis with WGS84 CRS.
For me, QGIS sets CRS to raster's CRS but some info seems to be lost
in
3) Extend the release schedule and lift the string freeze until after
the hackfest. We would then spend **all** of the hackfest tidying up
QGIS 1.7 and then impose a string freeze straight after the hackfest
with a planned branch for release a week later.
I'm ok with this chooise
On Thu, Mar 31, 2011 at 11:32 AM, Jürgen E. j...@norbit.de wrote:
That shouldn't be a problem projectionwise.
It found EPSG:4148 because that has the same projection parameters as
EPSG:4326
and the WKT string doesn't have any information about which EPSG is desired.
Otherwise the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/31/2011 11:53 AM, Marco Hugentobler wrote:
Hi devs
An extremely useful thing when using QGIS server in a real project is to have
a standard web client at hand that provides a set of standard tools and
supports the extensions of QGIS
Hi Marco,
On Thu, 31. Mar 2011 at 11:53:52 +0200, Marco Hugentobler wrote:
Andreas Neumann wrote a very nice client with java script based on the GeoExt
framework (http://gis.uster.ch/). He would be available to put it into the
QGIS svn and to maintain it.
Very nice.
For me that would be
Sorry to insist, but I think this is not a good choice. We already had
experiance with several non-core C++ plugins, some of them extremely
useful, and all of them are essentially unavailable to users. On the other
hand, it is probably unfeasible to add a dependency on SAGA.
What I don't
You're right Camilo,
python-saga bindings are available in source, as ready-to-use batch commands
(saga_api_to_python_linux.sh and saga_api_to_python_win.bat):
http://saga-gis.svn.sourceforge.net/viewvc/saga-gis/trunk/saga-gis/src/saga_core/saga_api/)
to compile them through SWIG
It means we have
Hi
On Thu, Mar 31, 2011 at 1:44 PM, Jürgen E. j...@norbit.de wrote:
Hi Marco,
On Thu, 31. Mar 2011 at 11:53:52 +0200, Marco Hugentobler wrote:
Andreas Neumann wrote a very nice client with java script based on the GeoExt
framework (http://gis.uster.ch/). He would be available to put it
Hi,
My preference: option 3 + Marco's suggestion
Still, there are more people voting than people going to the hackfest!
There were at least 2 messages saying that debugging is not fun (and,
no, it is not fun!). And Marco is right about discussing future
development directions. For me those taking
Il giorno gio, 31/03/2011 alle 17.17 +0200, Tim Sutton ha scritto:
+1 From me. As we have discussed offlist, a future development could
be to autogenerate a client project configuration for each QGIS
Mapserver project you publish.
+1; a great addition. One question: does the printing widget
Hi Paolo,
Yes - the printing widget takes the layout from the print composer
layouts in the .qgs project files.
It is a QGIS proprietary extension to the WMS standard - a GetPrint
command where you can specify the layout, scale, map extent, rotation
and grid interval for the graticule.
Cline, Royce L. wrote:
It fails with any color or offset selection. The fact that it hangs
whether I click OK or Cancel in the offset dialog would indicate a problem
exiting this dialog in the GUI.
I am having this problem with QGIS 1.6.0 on Mac Snow Leopard 10.6.7. Has a
ticket been
This is addressed in trunk, although it requires the font and color dialogs to
use qt widgets rather than native dialogs. I believe this is a qt bug,
ultimately.
John
On Mar 31, 2011, at 4:15 PM, jabraham wrote:
Cline, Royce L. wrote:
It fails with any color or offset selection. The
It's currently a part of:
http://trac.osgeo.org/qgis/ticket/3497
I've only partially fixed this (a workaround). There are many color pickers
and I didn't want to either workaround them as problems are found, which would
create a mix of color pickers, or do all of them, which would be a chore
21 matches
Mail list logo
