I am looking to do a lot of 3D vector data processing with GRASS GIS
in the near future. So I am currently testing GRASS' capabilities
for importing, processing and exporting such data.
I have noticed a number of small lacks and annoyances in a range
of GRASS modules that handle 3D vector data, including v.in.ogr,
v.out.ogr, v.info, v.edit and v.extrude. Over the next days, I will
produce a number of small patches to cure these.
My question is: what code branch should I base my work on?
Is there any chance that modifications to such basic modules
as v.in.ogr will still get applied to 6.4, seeing that we are
already at 6.4? Or would this be something for 6.5?
Cheers,
Ben
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
On Wed, Sep 2, 2009 at 5:35 PM, Benjamin
Ducke<benjamin.ducke@oxfordarch.co.uk> wrote:
I am looking to do a lot of 3D vector data processing with GRASS GIS
in the near future. So I am currently testing GRASS' capabilities
for importing, processing and exporting such data.
I have noticed a number of small lacks and annoyances in a range
of GRASS modules that handle 3D vector data, including v.in.ogr,
v.out.ogr, v.info, v.edit and v.extrude. Over the next days, I will
produce a number of small patches to cure these.
Great to hear!
My question is: what code branch should I base my work on?
Is there any chance that modifications to such basic modules
as v.in.ogr will still get applied to 6.4, seeing that we are
already at 6.4? Or would this be something for 6.5?
please submit to 6.5 *and* 7, otherwise they go out of sync.
If you submit patches as trac tickets, we can mark them there
for 6.4.1 (a bunch is already queuing).
If the patch is a fix, we can even backport to 6.4.svn (6.4.0)
but first it needs to go into 6.5 and 7.
I am wondering - is anybody updating the wxGUI help
(or plans to do so in near future0?
If not, I be happy to do that (submit into grass65?)
but it would definitely need to be reviewed because I am not
a GUI person and I am just learning it - which may a good thing
for the manual development.
Just a few notes -
- can we skip the silk icons? There are too many icons which makes
the help confusing
- It is not clear from the help that e.g. legend is under add overlays: text, legend, barscale
- add raster does not seem to be correctly described (old stuff from tcltk?)
Also, Would it be possible to generate an image or formatted text showing
the GUI tree for the raster, vector and other commands - no matter
how logically you organize the commands there will be users with their
own interpretations struggling to find modules. Currently, I recommend
to type the command into Cmd and hit Enter, but one needs to know the command
for that.
Another question: is there an animation tool in wxpython GUI - something like xganim?
animation under tcltk works but it is a little bit tricky to use
thanks,
Helena
P.S. I haven't abandoned the color table img issue - hopefully I will
get back to it later on (unless somebody else does it meanwhile).
Also, Would it be possible to generate an image or formatted
text showing the GUI tree for the raster, vector and other
commands - no matter how logically you organize the commands
there will be users with their own interpretations struggling
to find modules. Currently, I recommend to type the command
into Cmd and hit Enter, but one needs to know the command
for that.
I started on that, see find_menu_hierarchy() in
tools/module_synopsis.sh
but it needs some final help.
2009/9/4 Helena Mitasova <hmitaso@unity.ncsu.edu>:
I am wondering - is anybody updating the wxGUI help
(or plans to do so in near future0?
I don't know such person.
If not, I be happy to do that (submit into grass65?)
Great, the wxGUI documentation needs to be definitely updated/improved.
but it would definitely need to be reviewed because I am not
a GUI person and I am just learning it - which may a good thing
for the manual development.
- can we skip the silk icons? There are too many icons which makes
the help confusing
Probably it would be enough to show only icons from default iconset
(i.e., grass2). Probably we could create separate manual page -
wxGUI.Iconthemes.html and list there all icons from available
iconthemes (grass, grass2, silk). Make sense to you?
- It is not clear from the help that e.g. legend is under add overlays:
text, legend, barscale
- add raster does not seem to be correctly described (old stuff from tcltk?)
Yes, most of the text has been taken from tcltk GUI manual page.
Also, Would it be possible to generate an image or formatted text showing
the GUI tree for the raster, vector and other commands - no matter
how logically you organize the commands there will be users with their
own interpretations struggling to find modules. Currently, I recommend
to type the command into Cmd and hit Enter, but one needs to know the
command
for that.
Agreed, should not be so much work to implement it (probably could be
reported as wish in trac).
Also, Would it be possible to generate an image or formatted text showing
the GUI tree for the raster, vector and other commands - no matter
how logically you organize the commands there will be users with their
own interpretations struggling to find modules. Currently, I recommend
to type the command into Cmd and hit Enter, but one needs to know the
command
for that.
Agreed, should not be so much work to implement it (probably could be
reported as wish in trac).
Also, Would it be possible to generate an image or formatted text
showing the GUI tree for the raster, vector and other commands - no
matter how logically you organize the commands there will
be users with their own interpretations struggling to find modules.
Martin:
see r38973 - menu item 'Help->Show menu tree'
Great Martin. Looks very good to me but I guess the unfamiliar students
are the true test.
From that code, with slight modification would it possible to export the list of commands to a text file like:
r.in.bin|File > Import from rast > Binary file import
With that I can can then parse it into the module synopsis generating
TeX code.
I made some updates to wxGUI Help (Intro and layer manager),
feel free to modify, fix, continue.
Markus, Martin - would it be possible to make the GRASS65 manual available on-line,
something like this: http://grass.osgeo.org/gdp/manuals.php
so that the students can get the updates without updating entire GRASS?
Also, would it be possible to include the GUI tree online as well?
thank you,
Helena
On Sep 6, 2009, at 1:06 PM, Martin Landa wrote:
Hi,
2009/9/6 Hamish <hamish_b@yahoo.com>:
[...]
From that code, with slight modification would it possible to export the list of commands to a text file like:
r.in.bin|File > Import from rast > Binary file import
With that I can can then parse it into the module synopsis generating
TeX code.
So no idea how to do that... the only option would be to autogenerate
it elsewhere
and copy it onto the server via cronjob.
it can be done e.g. on josef.fsv.cvut.cz (there is already GRASS SVN &
wiki mirror). Just not sure in which form should be the GUI tree
published, see e.g.
It is already online but was just missing from that list.
does it really need to be linked?
IMO we really need to start focusing more on grass7 as the
"real" development branch and backport some useful things to
6.5 but try and put less emphasis on it. Currently development
is getting splintered and falling out of sync, not everything
relevant is being merged away from 6.5, ... I'm just concerned
that it will get worse as grass7 diverges.
> Also, would it be possible to include the GUI tree
> online as well?
I will include it in the module_synopsis.pdf +html once I can
find a few free moments to work on GRASS things.
It is already online but was just missing from that list.
does it really need to be linked?
You mean 6.5 or/and 7?
IMO we really need to start focusing more on grass7 as the
"real" development branch and backport some useful things to
6.5 but try and put less emphasis on it. Currently development
is getting splintered and falling out of sync, not everything
relevant is being merged away from 6.5, ... I'm just concerned
that it will get worse as grass7 diverges.
I think it would be best to only link
- 7 (development)
- 6.4 (stable)
- 6.2 (old stable)
Markus
PS: I find it suprising that the newer manuals on grass.osgeo.org are
impossible to find on Google, apart from grass.itc.it all kinds of (outdated)
mirrors have a higher page ranking than grass.osgeo.org. Well, maybe still
a matter of time?
It is already online but was just missing from that list.
does it really need to be linked?
IMO we really need to start focusing more on grass7 as the
"real" development branch and backport some useful things to
6.5 but try and put less emphasis on it. Currently development
is getting splintered and falling out of sync, not everything
relevant is being merged away from 6.5, ... I'm just concerned
that it will get worse as grass7 diverges.
that is my concern too - but I think rather than focusing on grass7
we should freeze all new development, fix everything that needs to be fixed,
and release GRASS64 final and move on to grass7 after that is done,
with only bug fixes allowed for grass6*
Currently, quite a bit of work is done on grass7 with grass64 release still
pretty far from final release state, so as you say, the development
is getting splintered and it is getting more difficult to do bug fixes in both
(as I have seen recently with v.surf.rst).
just a suggestion - it would be really nice to have a new stable grass release -
as there are still people downloading and installing GRASS6.2
Helena
Also, would it be possible to include the GUI tree
online as well?
I will include it in the module_synopsis.pdf +html once I can
find a few free moments to work on GRASS things.
Il giorno lun, 07/09/2009 alle 12.29 -0400, Helena Mitasova ha scritto:
that is my concern too - but I think rather than focusing on grass7
we should freeze all new development, fix everything that needs to be
fixed,
and release GRASS64 final and move on to grass7 after that is done,
with only bug fixes allowed for grass6*
I cannot agree more: this is very important also for other programs,
most notably QGIS, that now ships with an unstable GRASS version.
Releasing grass64 seems a major issue to me
All the best.
-- http://www.faunalia.it/pc
On Monday 07 September 2009, Helena Mitasova wrote:
On Sep 7, 2009, at 8:30 AM, Hamish wrote:
> Helena wrote:
>>> would it be possible to make the GRASS65 manual available
>>> on-line, something like this:
>>> http://grass.osgeo.org/gdp/manuals.php
>
> Markus wrote:
>> It is already online but was just missing from that list.
>
> does it really need to be linked?
> IMO we really need to start focusing more on grass7 as the
> "real" development branch and backport some useful things to
> 6.5 but try and put less emphasis on it. Currently development
> is getting splintered and falling out of sync, not everything
> relevant is being merged away from 6.5, ... I'm just concerned
> that it will get worse as grass7 diverges.
that is my concern too - but I think rather than focusing on grass7
we should freeze all new development, fix everything that needs to be
fixed,
and release GRASS64 final and move on to grass7 after that is done,
with only bug fixes allowed for grass6*
Currently, quite a bit of work is done on grass7 with grass64 release
still
pretty far from final release state, so as you say, the development
is getting splintered and it is getting more difficult to do bug
fixes in both
(as I have seen recently with v.surf.rst).
just a suggestion - it would be really nice to have a new stable
grass release -
as there are still people downloading and installing GRASS6.2
Helena
Although not a real developer, I tend to agree with Helena's above response.
Cheers,
Dylan
>>> Also, would it be possible to include the GUI tree
>>> online as well?
>
> I will include it in the module_synopsis.pdf +html once I can
> find a few free moments to work on GRASS things.
>
>
> Hamish
I cannot agree more: this is very important also for other programs,
most notably QGIS, that now ships with an unstable GRASS version.
Releasing grass64 seems a major issue to me
probably grass 6.4svn is more stable then other programs released as
stable;-) It's related to the project release management plan. GRASS
seems to be very conservative from this POV. Stable release take some
years to release.
It highlights that some new modules have not been added to the XML, e.g.
v.split. Some in-development, backend, and non-relevant modules rightly
have no menu position.
I'm not sure of that status of some, e.g. r.surf.idw vs. r.surf.idw2.
For the final PDF I'll run a2ps for 2-up, tweak the TeX for bigger logo,
and nicer page breaks, etc. See the current 6.4 PDF version linked below.