[GRASS-dev] Dead code

GRASS GIS GRASS GIS developer
1

The following directories contain code but aren't built:

  display/d.colors
  display/d.extract
  display/d.measure
  display/d.what.rast
  display/d.what.vect
  display/d.zoom
  general/g.pnmcat
  general/g.setproj
  imagery/i.class
  imagery/i.ortho.photo/i.ortho.init
  imagery/i.ortho.photo/i.ortho.transform
  imagery/i.points
  imagery/i.vpoints
  raster/r.digit
  raster/r.grow
  raster/r.le
  raster/r.li/r.li.setup
  raster/r.watershed/shed
  vector/v.label.sa
  vector/v.mapcalc

Are there plans to "resurrect" any of these within the foreseeable
future? If not, they should be removed.

Also, raster/wildfire contains just a README and a Makefile, the
actual modules (r.ros, r.spread, r.spreadpath) having been moved up
into the parent raster directory.

The Makefile serves no purpose, and the README (which contains a link
to sample data) won't be seen by end users; its content should
probably be added to the manual pages for the relevant modules.

Finally, I feel that v.in.dwg should be moved to addons.

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

2

On Fri, May 30, 2014 at 1:57 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

The following directories contain code but aren't built:

...
[no idea]
...

        imagery/i.ortho.photo/i.ortho.init
        imagery/i.ortho.photo/i.ortho.transform

i.ortho.photo should remain, I hope to get this updated to G7 at some point.

        imagery/i.points
        imagery/i.vpoints

... maybe no longer needed?

        raster/r.digit

.. a r.digit tool would be nice to have.

        raster/r.grow
        raster/r.le
        raster/r.li/r.li.setup

... all delete candidates.

        raster/r.watershed/shed

... dunno.

        vector/v.label.sa

... merge with v.label?

        vector/v.mapcalc

... dunno.

Are there plans to "resurrect" any of these within the foreseeable
future? If not, they should be removed.

Some yes, some no, see above.

Also, raster/wildfire contains just a README and a Makefile, the
actual modules (r.ros, r.spread, r.spreadpath) having been moved up
into the parent raster directory.

.. sounds like leftover?

The Makefile serves no purpose, and the README (which contains a link
to sample data) won't be seen by end users; its content should
probably be added to the manual pages for the relevant modules.

yes.

Finally, I feel that v.in.dwg should be moved to addons.

yes.

my 0.02 cents

Markus

3

On Fri, May 30, 2014 at 1:57 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

The following directories contain code but aren't built:

        display/d.colors

--> some updates in r62458 but AFAIR the curses support got dropped,
so trash d.colors? Or move to addons?

        display/d.extract

--> likely obsolete. Trash it or move to Addons?

        display/d.measure

--> likely obsolete. Trash it or move to Addons?

        display/d.what.rast
        display/d.what.vect

--> likely obsolete. Replaced with Python scripts in scripts/. Trash
both or move to Addons?

        display/d.zoom

--> likely obsolete. Trash it or move to Addons?

        general/g.pnmcat

--> "Concatenate PNM tiles into a single image, was used by NVIZ". No idea.

        general/g.setproj

--> lacking G_ask_datum_name(). Trash it or move to Addons?

        imagery/i.class

--> likely obsolete. Replaced with g.gui.iclass. Trash it or move to Addons?

        imagery/i.ortho.photo/i.ortho.init
        imagery/i.ortho.photo/i.ortho.transform

--> likely needed. See http://trac.osgeo.org/grass/ticket/2461

        imagery/i.points
        imagery/i.vpoints

--> uses unsupported curses, so trash or move to Addons? ( I think trash)

        raster/r.digit

--> no idea

        raster/r.grow

--> trash

        raster/r.le

--> since it is unmaintained, move to Addons

        raster/r.li/r.li.setup

--> Luca? Can we remove it? Replaced with g.gui.rlisetup

        raster/r.watershed/shed

--> no idea

        vector/v.label.sa

--> lacks find_font_from_freetypecap(). See
http://trac.osgeo.org/grass/ticket/1942 and r34923

        vector/v.mapcalc

--> move to Addons

Also, raster/wildfire contains just a README and a Makefile, the
actual modules (r.ros, r.spread, r.spreadpath) having been moved up
into the parent raster directory.

--> cleaned up now.

Finally, I feel that v.in.dwg should be moved to addons.

--> yes, move to Addons

More opinions?

Markus

4

On 29 October 2014 00:18, Markus Neteler <neteler@osgeo.org> wrote:

        imagery/i.class

--> likely obsolete. Replaced with g.gui.iclass. Trash it or move to Addons?

trash

        imagery/i.ortho.photo/i.ortho.init
        imagery/i.ortho.photo/i.ortho.transform

--> likely needed. See http://trac.osgeo.org/grass/ticket/2461

+1000

        raster/r.le

--> since it is unmaintained, move to Addons

is it different from r.li?

        raster/r.li/r.li.setup

--> Luca? Can we remove it? Replaced with g.gui.rlisetup

I'm going to remove it

More opinions?

Markus

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

5

Hi,

2014-10-29 0:18 GMT+01:00 Markus Neteler <neteler@osgeo.org>:

[...]

        general/g.setproj

--> lacking G_ask_datum_name(). Trash it or move to Addons?

isn't it replaced by `g.proj -c` ?

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://www.gismentors.eu/mentors/landa

6

2014-10-29 0:18 GMT+01:00 Markus Neteler <neteler@osgeo.org>:

        imagery/i.class

--> likely obsolete. Replaced with g.gui.iclass. Trash it or move to Addons?

it's same code as in G6, so removed in r62464-5.

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://www.gismentors.eu/mentors/landa

7

Markus Neteler wrote:

> The following directories contain code but aren't built:
>
> display/d.colors

--> some updates in r62458 but AFAIR the curses support got dropped,
so trash d.colors? Or move to addons?

> display/d.extract
--> likely obsolete. Trash it or move to Addons?

> display/d.measure
--> likely obsolete. Trash it or move to Addons?

> display/d.what.rast
> display/d.what.vect
--> likely obsolete. Replaced with Python scripts in scripts/. Trash
both or move to Addons?

> display/d.zoom
--> likely obsolete. Trash it or move to Addons?

Trash. I can't see these being resurrected in anything like their
existing form. Any replacements would presumably be in Python/wx.

> general/g.pnmcat
--> "Concatenate PNM tiles into a single image, was used by NVIZ". No idea.

Presumably the wxPython replacement doesn't need it, so remove.

> general/g.setproj
--> lacking G_ask_datum_name(). Trash it or move to Addons?

Are the replacements sufficient? g.setproj had a lot of logic for
dealing with the relationships between various parameters. Has that
been incorporated into the GUI? Is it unnecessary? Or does everyone
just use EPSG codes now?

> imagery/i.class
--> likely obsolete. Replaced with g.gui.iclass. Trash it or move to Addons?

It looks like Martin has already answered that one.

> imagery/i.points
> imagery/i.vpoints
--> uses unsupported curses, so trash or move to Addons? ( I think trash)

Trash. Anything that uses curses and R_get_location_with_* as a GUI is
never going to work with 7.x, and any replacement will likely be
written in Python.

> raster/r.digit
--> no idea

Same issue as d.* and i.* modules above. Trash.

> vector/v.label.sa
--> lacks find_font_from_freetypecap().

That could probably be fixed easily enough. But it probably shouldn't
be dealing with FreeType directly. I'd suggest using the display API,
specifically D_get_text_box() rather than trying to calculate a
skyline.

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

8

On Thu, Oct 30, 2014 at 8:40 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

...

I have collected the comments here:

http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup

> general/g.setproj
--> lacking G_ask_datum_name(). Trash it or move to Addons?

Are the replacements sufficient? g.setproj had a lot of logic for
dealing with the relationships between various parameters. Has that
been incorporated into the GUI? Is it unnecessary? Or does everyone
just use EPSG codes now?

No, EPSG codes do not represent all. Especially since we still need to
update the CSV files included in lib/proj/ which are pretty dated now.
See README.txt therein for a better approach.

> imagery/i.class
--> likely obsolete. Replaced with g.gui.iclass. Trash it or move to Addons?

It looks like Martin has already answered that one.

It is yet lacking the cleanup of documentation references:
find . -type f | grep -v 'svn/pristine' | grep -v 'locale' | xargs
grep "i\.class"

To add to the discussion of removing potentially obsolete code:
Additionally I have added to the Wiki page:

* r.bitpattern: Remove r.bitpattern since r.mapcalc does it more nicely now - ?
* raster/r.in.arc and raster/r.out.arc (use r.in.gdal/r.out.gdal) - ?
* raster/r.in.tiff and raster/r.out.tiff (use r.in.gdal/r.out.gdal) - ?

IMPORTANT: we need to update accordingly
http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Removedmodules

Markus

9

Hi,

2014-10-30 10:49 GMT+01:00 Markus Neteler <neteler@osgeo.org>:

It is yet lacking the cleanup of documentation references:
find . -type f | grep -v 'svn/pristine' | grep -v 'locale' | xargs
grep "i\.class"

done in 62487.

IMPORTANT: we need to update accordingly
http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Removedmodules

done [1].

Martin

[1] http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures?action=diff&version=254&old_version=253

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

10

On Thu, Oct 30, 2014 at 10:49 AM, Markus Neteler wrote:

On Thu, Oct 30, 2014 at 8:40 AM, Glynn Clements wrote:

Are the replacements sufficient? g.setproj had a lot of logic for
dealing with the relationships between various parameters. Has that
been incorporated into the GUI? Is it unnecessary? Or does everyone
just use EPSG codes now?

No, EPSG codes do not represent all. Especially since we still need to
update the CSV files included in lib/proj/ which are pretty dated now.
See README.txt therein for a better approach.

If the connection is available why not retrieve these information
directly from the web?
something like:

{{{
In [1]: import urllib2

In [2]: def get_epsg_wkt(epsg):
   ...: response =
urllib2.urlopen('http://epsg.io/\{epsg\}\.wkt&#39;\.format\(epsg=epsg\)\)
   ...: return response.read()
   ...:

In [3]: print(get_epsg_wkt(3003))
PROJCS["Monte Mario / Italy zone 1",GEOGCS["Monte
Mario",DATUM["Monte_Mario",SPHEROID["International
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6265"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4265"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",1500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","3003"]]
}}}

11

On Thu, Oct 30, 2014 at 11:38 AM, Pietro <peter.zamb@gmail.com> wrote:

On Thu, Oct 30, 2014 at 10:49 AM, Markus Neteler wrote:

On Thu, Oct 30, 2014 at 8:40 AM, Glynn Clements wrote:

Are the replacements sufficient? g.setproj had a lot of logic for
dealing with the relationships between various parameters. Has that
been incorporated into the GUI? Is it unnecessary? Or does everyone
just use EPSG codes now?

No, EPSG codes do not represent all. Especially since we still need to
update the CSV files included in lib/proj/ which are pretty dated now.
See README.txt therein for a better approach.

If the connection is available

... internet connection is not necessarily available.

why not retrieve these information directly from the web?
something like:

{{{
In [1]: import urllib2

In [2]: def get_epsg_wkt(epsg):
   ...: response =
urllib2.urlopen('http://epsg.io/\{epsg\}\.wkt&#39;\.format\(epsg=epsg\)\)
   ...: return response.read()
   ...:

In [3]: print(get_epsg_wkt(3003))
PROJCS["Monte Mario / Italy zone 1",GEOGCS["Monte
Mario",DATUM["Monte_Mario",SPHEROID["International
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6265"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4265"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",1500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","3003"]]
}}}

This delivers only one of several TOWGS84 parameters.
In the location manager is a selection dialog with respect to the
actual EPSG code and the datums stored in

lib/gis/datum.table
lib/gis/datumtransform.table

Markus

12

Markus Neteler wrote:

> If the connection is available

... internet connection is not necessarily available.

And even if it is, not everyone wants to send a log of their actions
to a third party.

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

13

Hi,

please express your opinion on the remaining issues:

http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup

? unclear: Trash or move to addons?

* display/d.colors - ?
* display/d.extract - ?
* display/d.measure - ?
* general/g.setproj - partially replaced by `g.proj -c` but contains
still useful logic
* r.bitpattern: Remove r.bitpattern since r.mapcalc+i.modis.qa does it
more nicely now - ?
* raster/r.in.arc and raster/r.out.arc (use r.in.gdal/r.out.gdal) - ?
* raster/r.in.tiff and raster/r.out.tiff (use r.in.gdal/r.out.gdal) - ?
* raster/r.grow - ?
* raster/r.le - ?
* raster/r.watershed/shed - ?
* vector/v.mapcalc - ?
* selected r.stream modules: r.stream.channel, r.stream.distance,
r.stream.order, r.stream.segment, r.stream.slope, r.stream.snap,
r.stream.stats: move back to Addons

I would like to go ahead...

thanks,
Markus

14

On Fri, Oct 31, 2014 at 12:01 PM, Markus Neteler <neteler@osgeo.org> wrote:

Hi,

please express your opinion on the remaining issues:

http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup

? unclear: Trash or move to addons?

* display/d.colors - ?
* display/d.extract - ?
* display/d.measure - ?

trash all of them. d.measure and d.colors are replaced in gui, d.extract is
missing in gui but this code is useless anyway

Anna

* general/g.setproj - partially replaced by `g.proj -c` but contains

still useful logic
* r.bitpattern: Remove r.bitpattern since r.mapcalc+i.modis.qa does it
more nicely now - ?
* raster/r.in.arc and raster/r.out.arc (use r.in.gdal/r.out.gdal) - ?
* raster/r.in.tiff and raster/r.out.tiff (use r.in.gdal/r.out.gdal) - ?

* raster/r.grow - ?

* raster/r.le - ?
* raster/r.watershed/shed - ?
* vector/v.mapcalc - ?
* selected r.stream modules: r.stream.channel, r.stream.distance,
r.stream.order, r.stream.segment, r.stream.slope, r.stream.snap,
r.stream.stats: move back to Addons

I would like to go ahead...

thanks,
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

15

On Fri, Oct 31, 2014 at 12:01 PM, Markus Neteler <neteler@osgeo.org> wrote:

* raster/r.grow - ?

I'm for move to addons [1]. Do you have suggestions for the name? The
difference is that it supports negative "grow" besides the standard one.

[1] http://trac.osgeo.org/grass/ticket/2368#comment:4

16

On Fri, Oct 31, 2014 at 10:15 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Fri, Oct 31, 2014 at 12:01 PM, Markus Neteler <neteler@osgeo.org> wrote:

Hi,

please express your opinion on the remaining issues:

http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup

? unclear: Trash or move to addons?

* display/d.colors - ?
* display/d.extract - ?
* display/d.measure - ?

trash all of them. d.measure and d.colors are replaced in gui, d.extract is
missing in gui but this code is useless anyway

ok: d.colors, d.measure, d.what.rast, d.what.vect, d.zoom removed in r62508.

Will backport that then to relbr7.

Markus

17

Hi,

selected r.stream modules: r.stream.channel, r.stream.distance,
r.stream.order, r.stream.segment, r.stream.slope, r.stream.snap,
r.stream.stats: moved back from relbranch7 to Addons (r62511 and
r62512).

Future fixes in trunk may be backported to Addons at this point.

Markus

18

On Fri, Oct 31, 2014 at 10:17 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Oct 31, 2014 at 12:01 PM, Markus Neteler <neteler@osgeo.org> wrote:

* raster/r.grow - ?

I'm for move to addons [1]. Do you have suggestions for the name? The
difference is that it supports negative "grow" besides the standard one.

There is this open ticket
https://trac.osgeo.org/grass/ticket/2368

Markus

[1] http://trac.osgeo.org/grass/ticket/2368#comment:4

19

On Fri, Oct 31, 2014 at 5:01 PM, Markus Neteler <neteler@osgeo.org> wrote:

Hi,

please express your opinion on the remaining issues:

http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup

Update: cleanup of unused r.digit in r62515.

Yet open:

- r.bitpattern: Remove r.bitpattern since r.mapcalc+i.modis.qa does it
more nicely now - ?
- raster/r.in.arc and raster/r.out.arc (use r.in.gdal/r.out.gdal) - ?
- raster/r.in.tiff and raster/r.out.tiff (use r.in.gdal/r.out.gdal) - ?
- raster/r.grow - https://trac.osgeo.org/grass/ticket/2368 - ?
- raster/r.le (sufficiently superseded by r.li?) - ?
- raster/r.watershed/shed (last change 5 years ago!) - ?

Markus

20

Hi,

On 1 November 2014 11:15, Markus Neteler <neteler@osgeo.org> wrote:

Yet open:

- raster/r.in.arc and raster/r.out.arc (use r.in.gdal/r.out.gdal) - ?
- raster/r.in.tiff and raster/r.out.tiff (use r.in.gdal/r.out.gdal) - ?

- raster/r.le (sufficiently superseded by r.li?) - ?

these three could be removed from my point of view!

Markus

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org