[GRASS5] Changes between 5.0.0 release and current release branch

Glynn_Clements · November 27, 2002, 4:17pm

There follows a summary of the changes which have been committed to
the release branch since the 5.0.0 release.

All appear to be either trivial fixes, non-trivial but critical fixes,
or documentation changes. Although I'm not quite sure about the
v.out.shape change.

A (larger) list of changes to the head which haven't been committed to
the release branch will follow.

----------------------------------------------------------------------

Makefile.in
Update "srcdist" target to include base directory

configure
configure.in
Add check for keypad() function in curses library
Change FreeType header check

documents/grasshist.html
Update

html/database.html
html/display.html
html/drivers.html
html/env_vars.html
html/export.html
html/general.html
html/grid3d.html
html/imagery.html
html/import.html
html/index.html
html/misc.html
html/models.html
html/paint.html
html/photo.html
html/projections.html
html/ps.html
html/raster.html
html/scripts.html
html/searchhtml.html
html/sites.html
html/tips_and_tricks.html
html/vector.html
Remove font tags
Misc. HTML clean-up

html/html/d.3d.html
Add box=

html/html/g.rename.html
Add -o

html/html/photo.camera.html
Update

html/html/r.covar.html
Change example matrix

html/html/r.stats.html
Remove -z

html/html/r.to.pg.html [ADDED]
Added

html/spearfish_directorytree.html [ADDED]
Added

html/terminology.html
  Add link to Spearfish data set
  Fix typo
  Remove font tags
  Misc. HTML clean-up

src/CMD/generic/make.mid
mk/mid.mk
mk/mid.mk.shlib
Change libedit -> libgedit (MacOSX name conflict)

src.contrib/GMSL/NVIZ2.2/scripts/widgets.tcl
Prevent divide-by-zero
Expose private commands (Tk 8.4 fix)

src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/dataoct.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/main.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/oct.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/user1.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/user2.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/user3.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/user4.c
Obtain malloc() prototype from stdlib.h, not malloc.h

src.contrib/SCS/vector/v.report/cmd/perimeter.c [REMOVED]
src.contrib/SCS/vector/v.report/cmd/Gmakefile
src.contrib/SCS/vector/v.report/cmd/do_v_stats.c
Move perimiter calculation into do_v_stats.c

src/display/d.zoom/cmd/set.c
Rename round() -> round_to() (ANSI C9X name conflict)

src/display/devices/PNGdriver/Gmakefile
Add PNG driver to monitorcap even if the executable doesn't
need to be rebuilt

src/imagery/i.pca/cmd/main.c
Rename round() -> round_c() (ANSI C9X name conflict)

src/include/config.h.in
Add HAVE_KEYPAD

src/libes/gis/get_row.c
Change G_get_map_row() to honour the mask

src/libes/gis/lzw.c [REMOVED]
Removed

src/libes/vask/V_exit.c
src/libes/vask/V_init.c
Only call keypad() if HAVE_KEYPAD is defined

src/libes/vect32/georef/vars.c [REMOVED]
src/libes/vect32/georef/Gmakefile
src/libes/vect32/georef/geo_file.c
Move variable definitions into geo_file.c (MacOSX linker fix)

src/mapdev/v.extract/cmd/main.c
Disable -n switch

src/mapdev/v.out.shape/extract.c
src/mapdev/v.out.shape/main.c
???

src/raster/r.mapcalc3/evaluate.c
src/raster/r.mapcalc3/expression.c
src/raster/r.mapcalc3/map.c
src/raster/r.mapcalc3/mapcalc.h
src/raster/r.mapcalc3/mapcalc.l
src/raster/r.mapcalc3/mapcalc.y
src/raster/r.mapcalc3/xnot.c
  Fix handling of qualified map names
  Improve handling of undefined variable, function or map names
  Allow input to be terminated by "end" or "exit" as well as EOF
  Fix arity of not() function

src/raster/r.param.scale/interface.c
html/html/r.param.scale.html
Change default c_tol value
Document sense of direction of maximum gradient

src/raster/r.sun/main.c
Remove reference to <malloc.h>
Fix spelling of Key_Value

src/raster/r.support/cmd/support.c
  Remove unused variables
  Look for map in current mapset (no qualified map names)
  Use G_fatal_error()

src/raster/r.tiff/r.out.tiff.c
Add warning when writing FP maps

src/scripts/contrib/grassmirrorsmap/grass.sites.mirror
Fix URL for Taiwan

src/scripts/contrib/r.univar/r.univar
Add "(excluding NULL cells)" to message

src/scripts/contrib/v.cutregion.sh/v.cutregion.sh
Change ORGANIZATION field
Note creator

src/scripts/contrib/v.line2area/v.area2line
src/scripts/contrib/v.line2area/v.line2area
Use -o switch when calling g.rename

src/tcltkgrass/module/i.grey.scale [REMOVED]
src/tcltkgrass/main/menu.tcl
Remove references to i.grey.scale

src/tcltkgrass/module/d.zoom
Fix option names

src/tcltkgrass/module/r.stats
Update flags: add -pnNCri, remove -mz

----------------------------------------------------------------------

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

Eric_G_Miller · November 28, 2002, 2:29am

On Wed, Nov 27, 2002 at 04:17:35PM +0000, Glynn Clements wrote:

There follows a summary of the changes which have been committed to
the release branch since the 5.0.0 release.

All appear to be either trivial fixes, non-trivial but critical fixes,
or documentation changes. Although I'm not quite sure about the
v.out.shape change.

* Fixes Segmentation Violation when exporting areas.

* Fixes interior boundary winding (shapefiles have exteriors clockwise,
   interiors counterclockwise) for areas with holes. AFAIK,
   Vect_get_area_points and Vect_get_isle_points always return clockwise
   polygons. So isle point orders are reversed. Isles will come up
   twice, once as interior and once as exterior. (If my understanding of
   these API's is incorrect, someone please let me know.)

* Only labelled areas are exported unless the -A flag is given. This
makes possible the differentiation between area holes and area
islands. With the -A flag, all areas are exported.

--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler

Radim_Blazek · November 28, 2002, 8:26am

On Thursday 28 November 2002 03:29 am, Eric G. Miller wrote:

* Fixes interior boundary winding (shapefiles have exteriors clockwise,
   interiors counterclockwise) for areas with holes. AFAIK,
   Vect_get_area_points and Vect_get_isle_points always return clockwise
   polygons. So isle point orders are reversed. Isles will come up
   twice, once as interior and once as exterior. (If my understanding of
   these API's is incorrect, someone please let me know.)

I thought that direction for areas/isles is the same in grass as in shapefile
and Vect_get_isle_points returns counterclockwise vertices:

struct P_isle {
plus_t *lines; /* Boundary Lines (Negative means N2 to N1
counter-clockwise) */
}

int Vect_get_isle_points () {
      if (Isle->lines[i] < 0) {
          start = Points.n_points - 1; inc = -1 ; end = 1;
      } else {
          end = Points.n_points - 2; inc = 1 ; start = 0;
      }
}

It is strange if shapefiles with reverted order of isles are correct.
Did you check it in ArcExplorer or other ESRI SW (AE runs on Linux)?

Radim

Eric_G_Miller · November 28, 2002, 10:05am

On Thu, Nov 28, 2002 at 09:26:39AM +0100, Radim Blazek wrote:

On Thursday 28 November 2002 03:29 am, Eric G. Miller wrote:
> * Fixes interior boundary winding (shapefiles have exteriors clockwise,
> interiors counterclockwise) for areas with holes. AFAIK,
> Vect_get_area_points and Vect_get_isle_points always return clockwise
> polygons. So isle point orders are reversed. Isles will come up
> twice, once as interior and once as exterior. (If my understanding of
> these API's is incorrect, someone please let me know.)

I thought that direction for areas/isles is the same in grass as in shapefile
and Vect_get_isle_points returns counterclockwise vertices:

struct P_isle {
  plus_t *lines; /* Boundary Lines (Negative means N2 to N1
                      counter-clockwise) */
}

int Vect_get_isle_points () {
      if (Isle->lines[i] < 0) {
          start = Points.n_points - 1; inc = -1 ; end = 1;
      } else {
          end = Points.n_points - 2; inc = 1 ; start = 0;
      }
}

It is strange if shapefiles with reverted order of isles are correct.
Did you check it in ArcExplorer or other ESRI SW (AE runs on Linux)?

I checked w/ ArcGIS 8.1 against screen dump of the drawn map as GRASS
areas and they rendered the same (vs. earlier version with direction
reversal for "isles"). And areas were the ones I wanted. If I remember
correctly, other folks checked as well and reported success.

The above snippet is identical in Vect_get_area_points. They are
reversing edges that natively are in the opposite order of the flow
around the polygon. I guess we'd have to hunt around the build code to
see how the edges are ordered to build areas and isles. I still think
both "areas" and "isles" are built in clockwise order...

--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler

David_D_Gray · November 28, 2002, 3:50pm

Eric G. Miller wrote:

On Thu, Nov 28, 2002 at 09:26:39AM +0100, Radim Blazek wrote:

On Thursday 28 November 2002 03:29 am, Eric G. Miller wrote:

* Fixes interior boundary winding (shapefiles have exteriors clockwise,
  interiors counterclockwise) for areas with holes. AFAIK,
  Vect_get_area_points and Vect_get_isle_points always return clockwise
  polygons. So isle point orders are reversed. Isles will come up
  twice, once as interior and once as exterior. (If my understanding of
  these API's is incorrect, someone please let me know.)

I thought that direction for areas/isles is the same in grass as in shapefile
and Vect_get_isle_points returns counterclockwise vertices:

struct P_isle {
plus_t *lines; /* Boundary Lines (Negative means N2 to N1
                     counter-clockwise) */
}

int Vect_get_isle_points () {
     if (Isle->lines[i] < 0) {
         start = Points.n_points - 1; inc = -1 ; end = 1;
     } else {
         end = Points.n_points - 2; inc = 1 ; start = 0;
     }
}

It is strange if shapefiles with reverted order of isles are correct.
Did you check it in ArcExplorer or other ESRI SW (AE runs on Linux)?

I checked w/ ArcGIS 8.1 against screen dump of the drawn map as GRASS
areas and they rendered the same (vs. earlier version with direction
reversal for "isles"). And areas were the ones I wanted. If I remember
correctly, other folks checked as well and reported success.

The above snippet is identical in Vect_get_area_points. They are
reversing edges that natively are in the opposite order of the flow
around the polygon. I guess we'd have to hunt around the build code to
see how the edges are ordered to build areas and isles. I still think
both "areas" and "isles" are built in clockwise order...

Hi Eric

The code for v.in.shape as it is now requires the points to be ordered in the 'correct' order, ie. clockwise for outer ring and anti-clockwise for islands. If, as sometimes happens with AV 3.x at least, an outer ring say is ordered the wrong way, the shape is not imported, but a warning is given, eg:

++++++++++++++++++++++++++++++++++++++++++++++++++++++

POLYGON (SHAPE) NUMBER 131

   Polygon contains 0 outer rings and a total of 0 holes.
   The structure is in an inconsistent state with 1 dangling holes.
   Area point is not provided.
   No height co-ordinates are supplied for the vertices.

++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Counts are wrong because the operation is not completed]

But, shapes exported with the pre-changes v.out.shape are re-imported OK with v.in.shape, so the islands in the shape file must circulate the right way. That would suggest they are in the right order in the dig_plus file also. I'll check this with the new module.

The polygon control code (v.in.shape/polygon.c) should be modified to not depend on rings' direction of circulation. This is in v.in.shape now and is to be more general for 5.1 (eg. interface to OGR). That was a low priority and I wasn't going to deal with it for stable, but now I think I'll move it up the queue a bit.

David

Eric_G_Miller · November 28, 2002, 10:57pm

On Thu, Nov 28, 2002 at 03:50:20PM +0000, David D Gray wrote:

But, shapes exported with the pre-changes v.out.shape are re-imported OK
with v.in.shape, so the islands in the shape file must circulate the
right way. That would suggest they are in the right order in the
dig_plus file also. I'll check this with the new module.

Okay, you and Radim are apparently correct, so I'll revert the
direction.

--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler

Glynn_Clements · February 16, 2003, 9:33pm

I've done another round of merging; attached is the list of
outstanding differences.

The list is split into several sections. The first section is the
changes which don't fall into any of the specific sections; the
subsequent sections correspond to: datum conversion, MinGW,
tcltkgrass/startup I18N, and PostgreSQL.

The changes in the first section are those for which I'm
"unconvinced"; i.e. they might make it in, either as-is or in a
modified form, depending upon comments. The changes in the other
sections are those which I specifically don't intend to apply.

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

(attachments)

grass-diff.txt (6.16 KB)

Eric_G_Miller · February 17, 2003, 12:23am

On Sun, Feb 16, 2003 at 09:33:17PM +0000, Glynn Clements wrote:
[snip]

The changes in the first section are those for which I'm
"unconvinced"; i.e. they might make it in, either as-is or in a
modified form, depending upon comments. The changes in the other
sections are those which I specifically don't intend to apply.

Note: the geo.h/geo_init.c changes below don't substantively change
functionality, but they do change API. I also believe the code is
somewhat cleaner. For instance, why should global variables used only
by m.proj[2] be *defined* in geo.h and therefore polluting all of libgis?

================================================================================

src/display/d.sites/cmd/draw_point.c
G_adjust_easting()

This fixes a drawing problem for data sets crossing the dateline
(+/-180). It's trivial and should have always been there.

src/general/g.setproj/get_num.c
src/general/g.setproj/local_proto.h
src/general/g.setproj/main.c
??? (Eric)

Mostly minor clean up and reflect changes in geo.h and geo_init.c
Must go in if they do, must not if they don't. Also added some
missing #include's.

src/include/geo.h
??? (Eric)

Syncs with geo_init.c - Move code *definitions* to geo_init.c,
remove unnecessary globals, add function prototypes for geo_init.c.

src/libes/gis/geo_init.c
??? (Eric)

Syncs with geo.h - Make table const, remove global variables, try
to improve documentation, namespace clean-up, make UNITS const and
initialized at compile time.

src/libes/gis/state83
3200: x_0: 0.6e+06 -> 0.60960122e+06

Fixes incorrect false easting, should go in (verified the value per
North Carolina law).

src/libes/proj/pj_datums.c
src/libes/proj/pj_ellps.c
Add missing underscores

Fixes lookup failures (me/paul). Should go in with other
projection/datum changes.

src/misc/m.proj/geo_func.c
src/misc/m.proj/local_proto.h
src/misc/m.proj/main.c
src/misc/m.proj/process.c
???

Sync geo.h/geo_init.c ... but obsolete anyway and should be removed?

================================================================================

html/html/m.proj2.html
src/misc/m.proj2/TODO
src/misc/m.proj2/geo_func.c
src/misc/m.proj2/input.c
src/misc/m.proj2/local_proto.h
src/misc/m.proj2/main.c
src/misc/m.proj2/process.c
Datum conversion
???

Syncs with geo.h/geo_init.c changes, also several bug fixes (me)
Then, datum transformations/man page (paul).

================================================================================

--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse

neteler · February 17, 2003, 1:03pm

On Sun, Feb 16, 2003 at 09:33:17PM +0000, Glynn Clements wrote:

html/html/d.legend.html
src/tcltkgrass/module/d.legend
-o, maxfontsize=

here Hamish Bowman may comment
Being the author of '-o, maxfontsize=' I can confirm that this was
a workaround only. Now Hamish has polished the code.

html/index.html
html/searchhtml.html
index2.html -> index.html

Yes. index2.html doesn't exist any more.

+ src.nonGPL/
Removed from release branch

Yes, that's better.

+ src.contrib/GMSL/r.simwe/
Added

No. It may go into the release branch when it is stabilized in
HEAD. Helena and Jaro continue to work on it.

src/general/init/grass.src
Trap signals

It was mostly disliked (although it helped for me :-).
In my opinion it doesn't harm even if it isn't the 100% solution.

src/imagery/i.ortho.photo/photo.rectify/write.c
Error messages

Was disliked, so no.

src/mapdev/v.in.dgn/Gmakefile
src/mapdev/v.in.dgn/README
src/mapdev/v.in.dgn/main.c
???

Yes. It's not in the compile list, so it doesn't cause problems.

src/scripts/contrib/d.rast.leg/d.rast.leg
???

Hamish?

src/scripts/contrib/r.univar/r.univar
???

No, the update should only be used with a flag (to be added to the
r.univar).

Markus

Glynn_Clements · February 17, 2003, 8:01pm

[In general, if HEAD and the release branch differ, and both are
broken, then leaving it alone at least provides a reminder that
something needs to be fixed.]

Markus Neteler wrote:

> html/html/d.legend.html
> src/tcltkgrass/module/d.legend
> -o, maxfontsize=

here Hamish Bowman may comment
Being the author of '-o, maxfontsize=' I can confirm that this was
a workaround only. Now Hamish has polished the code.

d.legend itself understands:

map= color= type= lines= thin= labelnum= at= range=
-v -c -n -s -m -f

but the set of options/flags which are documented in the HTML file and
are supported by supported by the tcltkgrass module are:

map= color= lines= thin= labelnum=
-v -c -s -m

IOW, those files need to be changed, but the version in HEAD isn't
correct.

Hamish said:

I'll get around to fixing these soon ..

At least the existing versions don't mention options which don't
actually exist in the program (-o, maxfontsize=).

> html/index.html
> html/searchhtml.html
> index2.html -> index.html

Yes. index2.html doesn't exist any more.

Neither does "../../index.html", which is the actual URL which is
contained in those files:

-<A HREF="../../index2.html">
+<A HREF="../../index.html">

html/index.html is installed as /usr/local/grass5/documents/index.html
(assuming the default prefix). The link "../../index.html" thus refers
to /usr/local/index.html, which probably won't exist (and if it did,
probably wouldn't be related to GRASS).

If this is meant to refer to the root of the GRASS website, it should
probably be:

or even just:

IOW, those files need to be changed, but the version in HEAD isn't
correct.

> src/general/init/grass.src
> Trap signals

It was mostly disliked (although it helped for me :-).
In my opinion it doesn't harm even if it isn't the 100% solution.

Same reasoning as before; either this should actually be fixed or it
should be acknowledged that it needs fixing.

> src/mapdev/v.in.dgn/Gmakefile
> src/mapdev/v.in.dgn/README
> src/mapdev/v.in.dgn/main.c
> ???

Yes. It's not in the compile list, so it doesn't cause problems.

Radim said:

Requires dgnlib which is not located by configure -> no.

> src/scripts/contrib/d.rast.leg/d.rast.leg
> ???

Hamish?

Hamish said:

  actually, probably not. It's broken for non-FP rasters right now due
  to the -o flag (which never made it out of HEAD) becoming -n, but it
  seems to have some related logic problems as well.

  I wasn't aware this script existed until now, but will see what I can
  whip up.

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

H_B · February 18, 2003, 1:54pm

> > html/html/d.legend.html
> > src/tcltkgrass/module/d.legend

Hamish said:

I'll get around to fixing these soon ..

And now I have. New versions of both are in CVS/HEAD now.

Unfortunately, I've just noticed what seems to be an inconsistency in the
d.legend at= option: it treats 0,0 as the lower left corner and 100,100
is the upper right corner of the monitor. As this is different from
d.frame and d.mapgraph, I guess I got the +y-axis convention
backwards (?).
Additionally, the d.frame at= option differs in implementation from
mine (at=bottom,top,left,right vs at=x1,y1,x2,y2). For consistency's sake
I guess I should change that as well.

I've got a lightly tested patch that fixes these things; but for this
release would you all rather have it 'correct' now or well tested with a
warning in the man page that these two things will change soon (which is
how it stands currently) ?

> > src/scripts/contrib/d.rast.leg/d.rast.leg
> > ???
>
> Hamish?

I've updated it in CVS so it now mostly works again, at least back to the
functionality it had on the 5.0.0 release. It still doesn't work
all that well though, so I don't see the point in including it at this
point. I may have a go at it at some later point.

regards,
Hamish

Glynn_Clements · February 18, 2003, 3:31pm

H Bowman wrote:

Unfortunately, I've just noticed what seems to be an inconsistency in the
d.legend at= option: it treats 0,0 as the lower left corner and 100,100
is the upper right corner of the monitor. As this is different from
d.frame and d.mapgraph, I guess I got the +y-axis convention
backwards (?).
Additionally, the d.frame at= option differs in implementation from
mine (at=bottom,top,left,right vs at=x1,y1,x2,y2). For consistency's sake
I guess I should change that as well.

I've got a lightly tested patch that fixes these things; but for this
release would you all rather have it 'correct' now or well tested with a
warning in the man page that these two things will change soon (which is
how it stands currently) ?

If you're going to change the behaviour of an existing option, it's
best to do it ASAP, before anyone gets used to the existing behaviour.

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

H_B · February 19, 2003, 3:26am

> Unfortunately, I've just noticed what seems to be an inconsistency in the
> d.legend at= option

If you're going to change the behaviour of an existing option, it's
best to do it ASAP, before anyone gets used to the existing behaviour.

Done. I've just updated the following in CVS/HEAD:
src/display/d.leg.thin/main.c
src/tcltkgrass/module/d.legend
html/html/d.legend.html

All these should be fine & up to date now.

Hamish