[GRASS5] Re: adapting locations to 5.7, volume nviz updates

GRASS GIS GRASS GIS developer
1

Helena,

(cc grass5)

On Sun, Nov 14, 2004 at 09:41:49PM -0500, Helena wrote:

Markus,

It would be nice to have something like v.migrate (it will reduce the
questions from people
who will write their own scripts that won't work for whatever reason),
especially for larger mapsets or larger files.
I had one problem with conversion that was already discussed but I don't
remember the solution. I did v.in.sites and both files that
I tried had ERROR: Map name is not SQL compliant. Practicaly all of my site
file names have <.> in it, and one of those that I tried even started with
numbers.

To address above problems, I have submitted

- v.convert.all
- v.in.sites.all

to scripts/ in 5.7-CVS which already include file name mangling in case
that a dot is present in the map name.

To import the file, I just changed the name for output, but that would mean
to do all files
manually. Would it be possible to take care of this with v.migrate? (e.g.
replace the dots
in the output name by something else, unless it has
been already solved by some other means.)

Partially done.
TODO: What if a map name starts with a number? Which prefix should I add?

I still don't quite understand how do you want to handle the WIND issue, but
if I understand it correctly, can you and Radim take care of grass57
startup that will add 3rd dim to DEFAULTWIND when grass57 is started on old location?

I think it was just a proposal.
I don't know where to change libgis to add the three lines to WIND.

Currently, if nviz does not find WIND3 it looks for DEFAULTWIND3, so
I will work with Jaro and Tomas to change nviz to read from
WIND and if it does not have the 3d info, it will read DEFAULTWIND
which should have the default 3d info generated by the grass57 startup.

Shouldn't this be added on C level? When opening the file *and* 3d info
missing, to add it?

I am not sure whether we need more discussion on the developers list
regarding
a change in WIND file - in case that this change could generate some
problems it would be good to take care of them now.

Yes, moved to 'grass5'.

So let me know whether this is what you have proposed to do and we will make
the necessary changes in nviz (or if I still did not get it, you may need
to do more explaining).

thank you, I am quite excited about the progress in 5.7 and more people
starting to use it - it looks great,

Helena

Markus

2

Markus Neteler wrote:

I still don't quite understand how do you want to handle the WIND issue, but
if I understand it correctly, can you and Radim take care of grass57 startup that will add 3rd dim to DEFAULTWIND when grass57 is started on old location?

I think it was just a proposal.
I don't know where to change libgis to add the three lines to WIND.

Currently, if nviz does not find WIND3 it looks for DEFAULTWIND3, so
I will work with Jaro and Tomas to change nviz to read from
WIND and if it does not have the 3d info, it will read DEFAULTWIND
which should have the default 3d info generated by the grass57 startup.

Shouldn't this be added on C level? When opening the file *and* 3d info
missing, to add it?

I am not sure whether we need more discussion on the developers list regarding
a change in WIND file - in case that this change could generate some
problems it would be good to take care of them now.

3 dimensions will be default (0,1,1) until set by user.
No changes in modules, only in lib/gis and lib/g3d.
NVIZ can continue to use old functions.

Radim

3

Markus Neteler wrote:

> I still don't quite understand how do you want to handle the WIND issue, but
> if I understand it correctly, can you and Radim take care of grass57
> startup that will add 3rd dim to DEFAULTWIND when grass57 is started on old location?

I think it was just a proposal.
I don't know where to change libgis to add the three lines to WIND.

WIND and cellhd/* files are read and written using the functions in
lib/gis/{rd,wr}_cellhd.c.

If the format is extended, rd_cellhd.c would need to be modified not
to complain about those lines.

Or just extend "struct Cell_head" to include the additional fields and
use that instead of a distinct G3D_Region type (i.e. make G3D_Region
an alias for "struct Cell_head"). G__read_Cell_head() would need to
allow for old WIND files which don't have those fields, either by
reading a WIND3 file or just using top=0.0, bottom=1.0.

--
Glynn Clements <glynn@gclements.plus.com>

4

On Mon, Nov 15, 2004 at 05:54:12PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> > I still don't quite understand how do you want to handle the WIND issue, but
> > if I understand it correctly, can you and Radim take care of grass57
> > startup that will add 3rd dim to DEFAULTWIND when grass57 is started on old location?
>
> I think it was just a proposal.
> I don't know where to change libgis to add the three lines to WIND.

WIND and cellhd/* files are read and written using the functions in
lib/gis/{rd,wr}_cellhd.c.

If the format is extended, rd_cellhd.c would need to be modified not
to complain about those lines.

Or just extend "struct Cell_head" to include the additional fields and
use that instead of a distinct G3D_Region type (i.e. make G3D_Region
an alias for "struct Cell_head"). G__read_Cell_head() would need to
allow for old WIND files which don't have those fields, either by
reading a WIND3 file or just using top=0.0, bottom=1.0.

Helena,

what do you think? Sounds like a "easy going" suggestion to me.
Will you/Jaro implement that?

I would like to get that solved soon to keep GRASS 5.7 user friendly
(to avoid that all users have to use g3.createwind).

Markus