Hi GRASS-devs,
On Sun, Dec 14, 2008 at 5:40 PM, Tim Sutton <tim@linfiniti.com> wrote:
Hi Marco & Markus
What is the plan regarding which version of GRASS will be packaged with
QGIS 1.0? Last I spoke to you I think you suggested we should ship
6.4rcX - can you specify which GRASS version will be used?
the release candidate becomes pressing now.
Or QGIS 1.0 (Windows, MacOSX) will be shipped with 6.3.0 which I
would pretty much dislike.
Markus
On Sun, Dec 14, 2008 at 9:41 AM, Markus Neteler <neteler@osgeo.org> wrote:
Hi GRASS-devs,
On Sun, Dec 14, 2008 at 5:40 PM, Tim Sutton <tim@linfiniti.com> wrote:
Hi Marco & Markus
What is the plan regarding which version of GRASS will be packaged with
QGIS 1.0? Last I spoke to you I think you suggested we should ship
6.4rcX - can you specify which GRASS version will be used?the release candidate becomes pressing now.
Or QGIS 1.0 (Windows, MacOSX) will be shipped with 6.3.0 which I
would pretty much dislike.Markus
Yes. What needs to happen in order for GRASS 6.4 to make it into QGIS 1.0?
Cheers,
Dylan
On Sun, Dec 14, 2008 at 7:13 PM, Dylan Beaudette
<dylan.beaudette@gmail.com> wrote:
On Sun, Dec 14, 2008 at 9:41 AM, Markus Neteler <neteler@osgeo.org> wrote:
Hi GRASS-devs,
On Sun, Dec 14, 2008 at 5:40 PM, Tim Sutton <tim@linfiniti.com> wrote:
Hi Marco & Markus
What is the plan regarding which version of GRASS will be packaged with
QGIS 1.0? Last I spoke to you I think you suggested we should ship
6.4rcX - can you specify which GRASS version will be used?the release candidate becomes pressing now.
Or QGIS 1.0 (Windows, MacOSX) will be shipped with 6.3.0 which I
would pretty much dislike.Markus
Yes. What needs to happen in order for GRASS 6.4 to make it into QGIS 1.0?
We need at least a release candidate.
This means that we need to create the release branch.
Now 
Markus
Hi,
2008/1/14 Markus Neteler <neteler@osgeo.org>:
[...]
We need at least a release candidate.
This means that we need to create the release branch.
Now
+1
today or in the next few days
see
http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan#RC1
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Sun, Dec 14, 2008 at 10:28 PM, Martin Landa <landa.martin@gmail.com> wrote:
...
today or in the next few days
"Only" 6 blocker/critical bugs are left:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=6.4.0&milestone=6.3.1&type=defect&order=priority
Are they are really critical bugs which block RC1?
Markus
Markus Neteler wrote:
> today or in the next few days
>
> see
> http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan#RC1"Only" 6 blocker/critical bugs are left:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=6.4.0&milestone=6.3.1&type=defect&order=priorityAre they are really critical bugs which block RC1?
Don't count on #58 or #72 being fixed any time soon. The same might
be said for #384, depending upon what's actually causing it.
Is #73 actually a bug, or simply noting that programs which claim to
support "TIFF" invariably only support a (usually unspecified) subset
of the TIFF standard?
In any case, I think that you're going to have to consider anything
relating to wxGUI to not be a blocker if you want a 6.4.0 release
sooner rather than later.
--
Glynn Clements <glynn@gclements.plus.com>
Markus:
http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan#RC1
>
> "Only" 6 blocker/critical bugs are left:
....
> Are they are really critical bugs which block RC1?
Glynn:
Don't count on #58 or #72 being fixed any time soon.
funny, in a mailibf lisr archives search I find that my first post to
grass-dev (and subsequent CVS snadu) mentioned #72 PNG driver off-by-one
issues,
http://article.gmane.org/gmane.comp.gis.grass.devel/154/
Is #73 actually a bug, or simply noting that programs which
claim to support "TIFF" invariably only support a (usually
unspecified) subset of the TIFF standard?
It's really a bug. The heart of it is us not enforcing data type limits.
We are silently allowing the output out of bounds values for cells of
a given data type/size. see raster/r.out.gdal/local_proto.h
the bug report has gotten quite long, so could probably do with a
resummarization of the current situation.
for now just start reading at comment 20; colr/ stuff is "mostly*" done.
http://trac.osgeo.org/grass/ticket/73#comment:20
"nodata must be set to something valid, otherwise the module doesn't know how to write out NULL values when it comes to them. It can't just skip them and nan is not an option for int maps. Thus, as you proposed, in the case where nodata= is out of range for the data type the module should exit with an error."
etc.
* (mostly done: if you pass GDAL createopts to make a bare-bones GeoTIFF
GRASS doesn't know about it and still writes translated color table rule
metadata)
Hamish
Dear friends,
the release candidate becomes pressing now.
Or QGIS 1.0 (Windows, MacOSX) will be shipped with 6.3.0 which I
would pretty much dislike.
Today I started to work on the new MinGW environment for both GRASS and QGIS.
From today I'll abandon GRASS 6.3.0 building, moving my attention to 6.4 and
7.
I decided to split the GRASS builds into:
- Official WinGRASS (itself splitted into: 6.4-RCs, 6.4-dev and 7-dev, both based on trunk)
- GRASS for QGIS
also because of many other dependencies, such as Tcl/Tk and wxWidgets, that are not needed in the QGIS GRASS Plugin.
There are many items in my To-Do list, and the chaotic and confused situation of the current MinGW project could take a lot of time before to fix them all.
This said (sorry for the long preamble), I can imagine the following scenario, based on the fact that the QGIS 1.0 call for packaging is set on 12/20:
A. ship qgis with grass-6.3.0, planning future package upgrades with the 6.4-RCs
B. ship qgis with 6.4-RC1, even if a RC1 branch before 12/20 would not mean that I'll be able to compile a working set (of both QGIS and GRASS 6.4-RC1) in time for the release.
Just my 2 cents
Regards,
MP
> today or in the next few days
I vote for today, as-is.
Hamish
Hi Jürgen,
Did you try to build GRASS for OSGEO4W yet?
No, not yet. I just started my PhD, so I'm "awakening" right now from a long break in GIS developing.
Some time ago I asked Frank to set up a To-Do list on http://trac.osgeo.org/osgeo4w/wiki/pkg-grass (or just a basic list, to be completed by the team, that is Frank, you and me)
This would be very helpful to me to do the job, because I don't have the things clear now on what to do, what is missing, not working... and so on.
Because of the curren dead lines (I mean 1.0 call for packaging set on 12/20) I'll focus my GIS-available-time on the standard MinGW build.
The OSGEO4W job will follow.
Regards,
Marco
Marco Pasetti ha scritto:
No, not yet. I just started my PhD, so I'm "awakening" right now from a
long break in GIS developing.
BTW: w still have problem relative to the inclusion of proprietary
drivers (especially ECW and MsSID). I tried investigating the issue, but
things seem muddled at best. It is unclear whether eg gvSIG has obtained
a licence to redistribute them (they might have done so, perhaps even
paying for it). I think we should avoid legal issues, but on the other
hand I think not having those drivers is a major issue for many users.
Any hints on how to proceed?
All the best.
pc
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *
Hamish wrote:
Glynn:
Is #73 actually a bug, or simply noting that programs which
claim to support "TIFF" invariably only support a (usually
unspecified) subset of the TIFF standard?
It's really a bug. The heart of it is us not enforcing data type limits.
We are silently allowing the output out of bounds values for cells of
a given data type/size. see raster/r.out.gdal/local_proto.h
But it is possible to export GRASS rasters in a way and format that most other applications can read and display, now that colortable export can be disabled. The user can check data type limits in the man page and the range of the raster to be exported and choose an appropriate data type. GRASS can not account for all limitations in all other GIS packages (colortable, compression method...), but it does offer a lot of control over the export format. Enforcing data type limits will make sure (again by the module) that the full range of raster data is actually exported, the lack of it doesn't mean that raster export necessarily results in unusable raster files.
Added my 2 cents,
Markus M
On Mon, Dec 15, 2008 at 4:48 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:
Hamish wrote:
Glynn:
Is #73 actually a bug, or simply noting that programs which
claim to support "TIFF" invariably only support a (usually
unspecified) subset of the TIFF standard?It's really a bug. The heart of it is us not enforcing data type limits.
We are silently allowing the output out of bounds values for cells of
a given data type/size. see raster/r.out.gdal/local_proto.hBut it is possible to export GRASS rasters in a way and format that most
other applications can read and display, now that colortable export can be
disabled. The user can check data type limits in the man page and the range
of the raster to be exported and choose an appropriate data type. GRASS can
not account for all limitations in all other GIS packages (colortable,
compression method...), but it does offer a lot of control over the export
format. Enforcing data type limits will make sure (again by the module) that
the full range of raster data is actually exported, the lack of it doesn't
mean that raster export necessarily results in unusable raster files.Added my 2 cents,
Markus M
I agree with Markus M. on this one.
Dylan