Martin, Markus,
evoking projection systems' related tickets, I am wondering if this one
should be considered blocker, given epsg:3857 is quite broadly used: https://trac.osgeo.org/grass/ticket/2229
Have a nice sunday !
Vincent.
Le dimanche 21 août 2016 à 14:54 +0200, Martin Landa a écrit :
Dear devs,
2016-07-01 0:42 GMT+02:00 Martin Landa <landa.martin@gmail.com>:
> I am afraid that we have delay, I hope that we will have some time to
> work on GRASS during ISPRS in Prague. What about:
>
> * soft freeze: ~ 15 July
> * hard freeze + RC1: ~ 15 August
> * bug squashing: FOSS4G Bonn
> * RC2: ~ 30 August
> * final: ~ 7 September
I would like to propose slowly to move from SOFT to HARD freeze of
rel72 branch [1]. There is no ticket marked as blocker [2], please
update priority to blocker if you feel that there are tickets which
must be solved before RC1.
On Tue, Aug 30, 2016 at 11:08 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:
- important: please add fixes and your favourite improvements to the
7.2.0-News page (too much for one person to check)
Fixes are added automatically, no ? And they should no go into the "module
changes" sections, or ?
If you mean the list of closed tickets, I would say that that's not enough.
It contains all sorts of stuff (and is [fortunately] very long) and the
ticket title often does not tell you enough (or in a right way) about what
was changed. So a hand-crafted note is better, I think.
As a side note: should we profit of these release announcements to also
list all the new addons checked into the repository since the last release ?
I think this is a great idea. It might be just hard to say what is "since
the last release" (now we work on 6.4, 7.0 and 7.2 series).
On Tue, Aug 30, 2016 at 5:25 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Tue, Aug 30, 2016 at 11:08 AM, Moritz Lennert
- important: please add fixes and your favourite improvements to the
7.2.0-News page (too much for one person to check)
Fixes are added automatically, no ?
Unfortunately not really:
- many bug report titles are hard to understand
- many fixes do not have a bug report
And they should no go into the "module changes" sections, or ?
I believe they should. Because most users will read that part, not the
"scary" #somenumber lines
If you mean the list of closed tickets, I would say that that's not enough.
It contains all sorts of stuff (and is [fortunately] very long) and the
ticket title often does not tell you enough (or in a right way) about what
was changed. So a hand-crafted note is better, I think.
Yes. Also, because it is organized by topic, not by ascending numbers.
As a side note: should we profit of these release announcements to also
list all the new addons checked into the repository since the last release ?
I think this is a great idea. It might be just hard to say what is "since
the last release" (now we work on 6.4, 7.0 and 7.2 series).
On Tue, Aug 30, 2016 at 11:08 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:
As a side note: should we profit of these release announcements to
also list all the new addons checked into the repository since the
last release ?
I think this is a great idea. It might be just hard to say what is
"since the last release" (now we work on 6.4, 7.0 and 7.2 series).
For each release news, we would put in the addons added since the last release of that series.
So, for 7.0.5, we would add the grass6 addons which were uploaded since 7.0.4, and for 7.2 a list of all addons since 7.0. I don't think we have to do this for grass6.
On Wed, Aug 31, 2016 at 2:52 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:
For each release news, we would put in the addons added since the last
release of that series.
So, for 7.0.5, we would add the grass6 addons which were uploaded since
7.0.4, and for 7.2 a list of all addons since 7.0. I don't think we have to
do this for grass6.
Sound ok ?
Yes. Log for the Makefile from each module type directory could be a
starting point:
On Wed, Aug 31, 2016 at 2:52 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:
For each release news, we would put in the addons added since the
last release of that series.
So, for 7.0.5, we would add the grass6 addons which were uploaded
since 7.0.4, and for 7.2 a list of all addons since 7.0. I don't
think we have to do this for grass6.
Sound ok ?
Yes. Log for the Makefile from each module type directory could be a
starting point:
The Windows built train does not use the Makefiles (that's only
happening on Unix based system) but simply compiles everything in the
directory tree.
The Linux compile chain for the addons does use the Makefiles: hence
modules should be added there.
You mean for the binary snapshot ? Users on Linux can still run g.extension on a module even if it does not have an entry in the section Makefile...
Here's a preliminary list of the new ones that are listed with 'g.extension -c', but I'll clean that up tomorrow the latest:
v.tin.to.rast: Converts (rasterize) a TIN map into a raster map
v.maxent.swd: Export raster values at given point locations as text file
in SWD format for input in Maxent
v.in.gbif: importing of GBIF species distribution data
v.in.redlist: importing of IUCN Red List Spatial Data
v.class.mlR: Provides supervised support vector machine classification
v.in.natura2000: importing of Natura 2000 spatial data of protected areas
v.mrmr: Perform Minimum Redundancy Maximum Relevance Feature Selection
on a GRASS Attribute Table
v.in.osm: Imports OpenStreetMap data into GRASS GIS.
v.stream.order: Compute the stream order of stream networks stored in a
vector map at specific outlet vector points
r.mcda.promethee: Multicirtieria decision analysis based on PROMETHEE method
r.stream.variables:
r.category.trim: Export categories and corresponding colors as QGIS
colour file or csv file. Non-existing categories and their colour
definitions will be removed.
r.mregression.series:
r.series.decompose: Program calculates decomposition of time series X
r.out.legend: Create and export image file with legend of a raster map
r.terrain.texture: Pit and peak density
r.tri: Terrain Ruggedness Index
r.vector.ruggedness: Vector Ruggedness Measure
r.euro.ecosystem: Sets colors and categories of European ecosystem
raster data set
r.jpdf: From two series of input raster maps, calculates the joint
probability function and outputs the probabilities of occurrence in the
specified bins.
r.neighborhoodmatrix: Calculates a neighborhood matrix for a raster map
with regions
r.change.info: Landscape change assessment
r.randomforest: Provides supervised random forest classification
i.segment.stats: Calculates statistics describing raster areas
i.ortho.corr: Correct orthophoto taking part of the near orthophotos
using the camera angle map
i.segment.uspo: Unsupervised segmentation parameter optimization
i.gcp: Manages Ground Control Points (GCPs) non-interactively.
i.landsat8.swlst: Practical split-window algorithm estimating Land
Surface Temperature from Landsat 8 OLI/TIRS imagery (Du, Chen; Ren,
Huazhong; Qin, Qiming; Meng, Jinjie; Zhao, Shaohua. 2015)
i.lswt: Compute LSWT from TOA Brightness Temperatures
New addons since 7.0.4 (since May):
v.in.pygbif:
v.strds.stats: Calculates univariate statistics from given space-time
raster datasets based on a vector map
v.sort.points: Sorts a vector point map according to a numeric column
v.what.spoly: Queries vector map with overlaping "spaghetti" polygons
(e.g. Landsat footprints) at given location. Polygons must have not
intersected boundaries.
v.explode: "Explode" polylines, splitting them to separate lines (uses
v.split + v.category)
v.clip: Extracts features of input map which overlay features of clip map.
v.surf.tps:
r.colors.matplotlib: Convert or apply a Matplotlib color table to a
GRASS raster map
r.colors.cubehelix: Create or apply a cubehelix color table to a GRASS
raster map
r.object.geometry: Calculates geometry parameters for raster objects.
r3.what: Queries 3D raster in specified 2D or 3D coordinates.
i.landsat8.qc: Reclass Landsat8 QA band according to acceptable pixel
quality as defined by the user
i.fusion.hpf:
i.image.bathymetry: Satellite Derived Bathymetry (SDB) from
multispectral images
m.printws: Opens a workspace file and creates a map sheet according to
its visible contents.
2016-07-01 0:42 GMT+02:00 Martin Landa <landa.martin@gmail.com>:
* soft freeze: ~ 15 July
* hard freeze + RC1: ~ 15 August
* bug squashing: FOSS4G Bonn
* RC2: ~ 30 August
* final: ~ 7 September
since 7.0.5 is still not out (should happen soon) I would suggest to
postpone also milestone for G72 - hardfreezing + RC1 ~ 25/9. Feel free
to update blockers [1] (currently no tickets marked as blockers and
critical). Thanks, Ma
