[GRASS5] TODOs - Wishes for 5.0.3

GRASS GRASS developer
1

Dear developers,

since we have a long list of new developments/improvements in
CVS HEAD, it's time to think about the next release.
Question is what we would like to see in 5.0.3 and
what should go into 5.1/5.2 instead.

What I would like to see in 5.0.3:
- the new PROJ4 related code with datum transformation
- the NVIZ changes (more to come the next days, basically
   related to code cleanup)
- many small things, to be checked with cvs diff to
  the release branch
- r.terraflow, r.simwe, ...?

The individual authors may comment about the status.

Thanks,

Markus

2

Markus Neteler wrote:

Dear developers,

since we have a long list of new developments/improvements in
CVS HEAD, it's time to think about the next release.
Question is what we would like to see in 5.0.3 and
what should go into 5.1/5.2 instead.

What I would like to see in 5.0.3:
- the new PROJ4 related code with datum transformation
- the NVIZ changes (more to come the next days, basically
   related to code cleanup)

The nviz additions are great (especially the legend, north arrow and
labels)
but it needs more testing as I did only very little.
I found that the relative position of the multiple surfaces has shifted
-
this may be due to changes in vector draping ? (allowing draping
slightly above the surface to ensure full visibility - another
extremely valuable addition). So if more people could try-out
the latest nviz in CVS version that would help to make sure that nothing
gets broken for the release..

- many small things, to be checked with cvs diff to
  the release branch
- r.terraflow, r.simwe, ...?

I still need to update the recent Laura's change so that it compiles on
RedHat
and I need to add manual page for simwe. Also I haven't really tested
the latest
version. Maybe these two should wait for 5.0.4

Jaro emailed me s.surf.rst with crossvalidation (he did it really fast)
but again I have not been able to test it so that would be something to
consider
for 5.0.4 as well.

Also I was wondering whether it would be useful to include r.recolor
and d.site.labels from
http://grass.itc.it/outgoing/SJGeo.tar.gz
and r.wavelets into CVS so that it is easier for people to try them out.
I am not sure whether any of these tools are under development for 5.1
(in particular histogram equalized color tables and writing rotated site
labels
may be something that users would appreciate).

Helena

The individual authors may comment about the status.

Thanks,

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

Markus Neteler wrote:

since we have a long list of new developments/improvements in
CVS HEAD, it's time to think about the next release.
Question is what we would like to see in 5.0.3 and
what should go into 5.1/5.2 instead.

What I would like to see in 5.0.3:

- many small things, to be checked with cvs diff to
  the release branch

The relevant script is tools/diff.sh.

- r.terraflow, r.simwe, ...?

I don't think that we should put r.terraflow into 5.0.x. To support
C++ properly requires non-trivial changes to the build system, which
would be best left for 5.1.

Actually, I don't think that we should put r.terraflow anywhere until
someone is willing to make it portable rather than just declaring that
"you must use gcc".

--
Glynn Clements <glynn.clements@virgin.net>

4

Glynn Clements wrote:

Markus Neteler wrote:

> since we have a long list of new developments/improvements in
> CVS HEAD, it's time to think about the next release.
> Question is what we would like to see in 5.0.3 and
> what should go into 5.1/5.2 instead.
>
> What I would like to see in 5.0.3:

> - many small things, to be checked with cvs diff to
> the release branch

The relevant script is tools/diff.sh.

> - r.terraflow, r.simwe, ...?

I don't think that we should put r.terraflow into 5.0.x. To support
C++ properly requires non-trivial changes to the build system, which
would be best left for 5.1.

Actually, I don't think that we should put r.terraflow anywhere until
someone is willing to make it portable rather than just declaring that
"you must use gcc".

I think that r.terraflow is OK in experimental GRASS in
src.contrib/DUKE.
This has some relation to the v.in.dgw discussion as this is another
example of a code that cannot be put into core GRASS release, but that
is needed and should be made available e.g. in src.contrib and users
will
have to compile it separately (SG3d was similar case too).
For an illustration, we did stream extraction for Panama
from 10000x10000 IFSARE-based DEM and we had to kill r.watershed after
17 days,
while r.terraflow did it in 3.5 hours on the same computer.
Laura tried to use her original C-code,
but she had to use the newer C++ version of the code to get that
performance.
She will hopefully add more options to the module and then we can have a
second look at it,
but I am not sure what she will be able to do. At this point I am glad
that we have it.
If anybody wants to look at it and make it portable that would be the
best solution.

Helena

   >

--
Glynn Clements <glynn.clements@virgin.net>

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

Re: [GRASS5] TODOs - Wishes for 5.0.3

Also I was wondering whether it would be useful to include r.recolor
and d.site.labels from
http://grass.itc.it/outgoing/SJGeo.tar.gz
and r.wavelets into CVS so that it is easier for people to try them
out. I am not sure whether any of these tools are under development
for 5.1(in particular histogram equalized color tables and writing
rotated site labels may be something that users would appreciate).

Just a note about d.site.labels,

I've been thinking about an option to limit the significant digits
for the display of attr=double. Having text like "145.000000" everywhere
makes a horrible mess when there are lots of sites. I've been
manually hacking "%.0lf" into do_labels.c. (I use this a lot
for tracking down the cause of errors in s.surf.rst results)

.. which leads me to my next question:

d.site.labels's do_labels.c uses "%lf" for several things, including
categories and dimensions. Moreover, it distinguishes between int, float,
and double category types, which doesn't seem right- maybe I don't fully
understand the "new" sites layout, but I was under the understanding
that categories had to be integers..

The PDF version of the programmer's manual states in section 12.13.1.1
(p.167) that "Categories must be integers."

But in section 12.13.4 (p.171) it defines the Site structure with
RASTER_MAP_TYPE cattype;
CELL ccat;
FCELL fcat;
DCELL dcat;

do_sites.c and an example in the programmer's manual (p.178) both check
against 'cattype' before choosing %d, %f, or %lf ..

So which is it? Are Site structures re-used in raster maps & thus CELL
is the only meaningful category type for Sites? Does 'category' have
multiple meanings in the GRASS code? Does 'Sites' have multiple
meanings? I'm lost.

thanks,
Hamish

6

On Tue, May 27, 2003 at 04:43:52PM -0400, Helena wrote:
[...]

> What I would like to see in 5.0.3:
> - the new PROJ4 related code with datum transformation
> - the NVIZ changes (more to come the next days, basically
> related to code cleanup)

The nviz additions are great (especially the legend, north arrow and
labels) but it needs more testing as I did only very little. I found that
the relative position of the multiple surfaces has shifted - this may be
due to changes in vector draping ? (allowing draping slightly above the
surface to ensure full visibility - another extremely valuable addition).
So if more people could try-out the latest nviz in CVS version that would
help to make sure that nothing gets broken for the release..

There are more changes for NVIZ to arrive from Bob soon.

> - many small things, to be checked with cvs diff to
> the release branch
> - r.terraflow, r.simwe, ...?

I still need to update the recent Laura's change so that it compiles on
RedHat and I need to add manual page for simwe. Also I haven't really
tested the latest version. Maybe these two should wait for 5.0.4

Jaro emailed me s.surf.rst with crossvalidation (he did it really fast)
but again I have not been able to test it so that would be something to
consider for 5.0.4 as well.

The question (for me) is: what is the last release of 5.0.x with
*new features*.
It were better to implement s.surf.rst with crossvalidation as
v.surf.rst with crossvalidation in 5.1 (since v.surf.rst is already
there in 5.1). Otherwise we never go ahead with the new implementation...

Also I was wondering whether it would be useful to include r.recolor
and d.site.labels from
http://grass.itc.it/outgoing/SJGeo.tar.gz
and r.wavelets into CVS so that it is easier for people to try them out. I
am not sure whether any of these tools are under development for 5.1 (in
particular histogram equalized color tables and writing rotated site
labels may be something that users would appreciate).

I feel that nobody is looking into this at time. Volunteers welcome.

Markus

7

The question (for me) is: what is the last release of 5.0.x with
*new features*.
It were better to implement s.surf.rst with crossvalidation as
v.surf.rst with crossvalidation in 5.1 (since v.surf.rst is already
there in 5.1). Otherwise we never go ahead with the new implementation...

you are right, so we will just keep it for us or in experimental until
we get 5.1 running for us.

Helena

> Also I was wondering whether it would be useful to include r.recolor
> and d.site.labels from
> http://grass.itc.it/outgoing/SJGeo.tar.gz
> and r.wavelets into CVS so that it is easier for people to try them out. I
> am not sure whether any of these tools are under development for 5.1 (in
> particular histogram equalized color tables and writing rotated site
> labels may be something that users would appreciate).

I feel that nobody is looking into this at time. Volunteers welcome.

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

8

On Tue, 27 May 2003, Markus Neteler wrote:

What I would like to see in 5.0.3:
- the new PROJ4 related code with datum transformation

We need to tidy up the datum names used in GRASS before doing this. I
don't know where they came from but some are a bit dubious. I would like
to use the Open GIS Consortium Well-known Text values (OGC WKT) for the
long descriptive names for the datums, to make it easier to output the
projection information to other GIS. Here is a summary of the names in
GRASS and what I think the OGC name is:

I am fairly sure about these ones:
wgs84 "World_Geodetic_System_1984" wgs84
wgs72 "World_Geodetic_System_1972" wgs72
nad27 "North_American_Datum_1927" clark66
nad83 "North_American_Datum_1983" grs80
osgb36 "OSGB_1936" airy
tokyo "Tokyo" bessel
sam69 "South_American_Datum_1969" sam69
eur50 "European_Datum_1950" international
agd66 "Australian_Geodetic_Datum_1966" australian
agd84 "Australian_Geodetic_Datum_1984" australian
rome40 "Monte_Mario" international
S-42 "Pulkovo_1942" krassovsky
potsdam "Deutsches_Hauptdreiecksnetz" bessel
carthage "Carthage" clark80

But not these ones
The 4 below seem to all be duplicate entries. Some had separate sets of
parameters (which are now handled by the datumtransform.table file).

a-can "Please use nad27 instead" clark66
aus "Please use agd66 instead" australian
SAD-69 "Please use sam69 instead" sam69
pulkovo "Please use S-42 instead" krassovsky

I decided on using S-42 instead of pulkovo as the abbreviation for the
last one, partly because it included the year and partly because Pulkovo
may be spelt wrongly but maybe it is just an anglicisation of the
placename (as in rome40 instead of roma40). Now I'm not as sure what it
should be called.

I don't know what these ones correspond to---anybody any ideas or should I
delete them?
eur "European" international
eur79 "European 1979 mean" international
grs80 "Geographic Reference System 1980" wgs84
Sasia "South Asia" fschr60m

As far as I was aware grs80 is an ellipsoid and not a datum; it is
implemented as a datum in nad83 in America and etrs89 in Europe.

hermannskogel "Militar_Geographische_Institut" bessel

Hermannskogel seems to be in Austria so this name seemed appropriate but
there is also S_JTSK_Ferro which applies to the Czech Republic and
Slovakia, but are these the same datum?

Below here are ones I have added

ire65 "TM65" modif_airy
ch1903 "CH1903" bessel
ntf87 "Nouvelle_Triangulation_Francaise" plessis
etrs89 "European_Terrestrial_Reference_System_1989" grs80
bel72 "Reseau_National_Belge_1972" international
lis37 "Lisbon_1937" international

And here are some new ones I found reference to at http://crs.ifag.de/ but
don't know what the official name should be. Can anybody help?

rd18 "Rijksdriehoeks Datum 1918 (Netherlands)" bessel
por73 "Portuguese Datum 1973" international
hjors55 "Hjorsey 1955 (Iceland)" international

Another point is that it was very hard to find transformation parameters
for France (I tried to add support for a few European countries but of
course it is not complete). The above website only had one 3-parameter
transformation for the whole of France which couldn't be very accurate.
And there should be more countries there as well but it takes quite a
while to research the parameters and even then I can't test if they are
correct.

Paul

9

On Wednesday 28 May 2003 16:16, Paul Kelly wrote:

Hermannskogel seems to be in Austria so this name seemed appropriate but
there is also S_JTSK_Ferro which applies to the Czech Republic and
Slovakia, but are these the same datum?

I am not very sure what the 'datum' is, just from user point of view:
Acording to http://crs.ifag.de/, 'S-JTSK' is 'Datum identifier' (so it could be datum)
for Czech and Slovak Republic. 'Hermannskogel' seems to be 'Datum anchor point'
used by more 'datums'. If datum record in datum table is something what should help
user to define transformation parameters, then we need two records for
S-JTSK, one for Czech and second for Slovak Republic (different parameters),
S-JTSK_CZ and S-JTSK_SK?
On crs.ifag.de is distinguished only 'CRS identifier': 'CZ_S-JTSK / KROVAK'
and 'SK_S-JTSK / KROVAK'

If you use only 1 record for S-JTSK (but there are no reliable parameters
for the whole territory available, I think), then user have to either define its own
parameters or use wrong (not precise enough) parameters.

Radim

10

Hello Radim

On Wed, 28 May 2003, Radim Blazek wrote:

On Wednesday 28 May 2003 16:16, Paul Kelly wrote:
> Hermannskogel seems to be in Austria so this name seemed appropriate but
> there is also S_JTSK_Ferro which applies to the Czech Republic and
> Slovakia, but are these the same datum?

I mean the name Militar_Geographische_Institut seemed appropriate. [1] Within
GRASS anyway the name is not important as the user can select from a list of
pre-defined transformation parameters or his/her own parameters (see below).
The actual name is not very important at all. The long name is for future
support (well I am working on it now but might put it into GRASS5.1) for
exporting the projection information to other programs. There are some
standards for the datum names based on the European Petroleum Survey Group
(EPSG) but some of them are a bit ambiguous and unclear and there may be
several names for each datum; see
http://gdal.velocet.ca/~warmerda/wktproblems.html

I am not very sure what the 'datum' is, just from user point of view:

No, neither am I :slight_smile: But saying it is an ellipsoid and a set of
transformation parameters will do us for now, I think. Technically it has
a point of origin (or datum anchor point as you describe below) but I
don't see how that is needed for GRASS.

Acording to http://crs.ifag.de/, 'S-JTSK' is 'Datum identifier' (so it could be datum)
for Czech and Slovak Republic. 'Hermannskogel' seems to be 'Datum anchor point'
used by more 'datums'. If datum record in datum table is something what should help
user to define transformation parameters, then we need two records for
S-JTSK, one for Czech and second for Slovak Republic (different parameters),
S-JTSK_CZ and S-JTSK_SK?
On crs.ifag.de is distinguished only 'CRS identifier': 'CZ_S-JTSK / KROVAK'
and 'SK_S-JTSK / KROVAK'

If you use only 1 record for S-JTSK (but there are no reliable parameters
for the whole territory available, I think), then user have to either define its own
parameters or use wrong (not precise enough) parameters.

Just a clarification: The new datum set-up in GRASS makes it possible to
define many different sets of transformation paramters for each datum.
This is done in the datumtransform.table file. E.g. hermannskogel
currently has four sets of 7-parameter transformations, each for Austria,
Czech Republic, Slovakia and Slovenia. Also, these are really just
'suggestions' for the user to pick when setting up his/her location using
g.setproj, and custom parameters can be entered or changed later by editing
the PROJ_INFO file.

It is only if there are no transformation parameters specified (only a
datum name) in the PROJ_INFO file that the default 3-parameter transformation
is looked up from the datum.table and used. This is very unlikely to
happen. In general there should always be specific datum transformation
parameters in the PROJ_INFO file (either 'towgs84:' or 'nadgrids:' line)
and these will be used.

Hope this clarifies things a bit

Paul

[1]. This is how the name is given in the EPSG database. I suspect there
should be an umlaut on the a in Militar which would become Militaer with
the conventional German letters --> ASCII transliteration. And Markus also
suggested it should be Geographisches instead of Geographische which may
be a mistake in the EPSG database. (See Frank's webpage above for the
standard rules for forming these names). It is hard to know if we should
try to produce our own GRASS transformations of the EPSG names (which may
be more correct) or propagate the existing (if unconventional) spellings
in the interests of compatibility.

11

On Wednesday 28 May 2003 17:47, Paul Kelly wrote:

Just a clarification: The new datum set-up in GRASS makes it possible to
define many different sets of transformation paramters for each datum.
This is done in the datumtransform.table file. E.g. hermannskogel
currently has four sets of 7-parameter transformations, each for Austria,
Czech Republic, Slovakia and Slovenia. Also, these are really just
'suggestions' for the user to pick when setting up his/her location using
g.setproj, and custom parameters can be entered or changed later by editing
the PROJ_INFO file.

Sorry, I did not notice this, I am satisfied with datumtransform.table.

Only one wish, could you include also

S-42 "towgs84=26,-121,-78" "Czech Republic, Slovak Republic" " "

from TR8350.2/NIMA, I am not aware of any better source.
Both S-JTSK and S-42 are used in Czech and Slovak Republic.

Radim

12

Hello Michel (and anybody else who would like to test this)

On Tue, 3 Jun 2003, Michel Wurtz wrote:

[...]
> Another point is that it was very hard to find transformation parameters
> for France (I tried to add support for a few European countries but of
> course it is not complete). The above website only had one 3-parameter
> transformation for the whole of France which couldn't be very accurate.

Look at the official french survey site : all parameters and even the algorithms
used are described. You can also load a grid af correction parameters to do
accurate transformation between NTF and GRS80 systems (same style as NAD to NAD ?)

I have had a chance to have a good look at this now and while the grid was
nothing like the nad2nad format, I think I have managed to convert it into
a format (gsb) that can be used by PROJ and GRASS. There was too much for
an e-mail so I put details on a webpage at
http://www.stjohnspoint.co.uk/gis/france.htm and you can download my
version of the gridshift file from there as well.

If we get some feedback and it works, maybe we can include it in the GRASS
distribution the way the USA and Canada files are there now (and perhaps
add Australia and New Zealand as well, which are freely available).
Somebody would need to check any copyright issues though probably.

Paul