[GRASS-dev] Google Summer of Code 2008

GRASS GIS GRASS GIS developer
, ,
1

Hello fellow developers.

Google Summer of Code is going to start again soon, and this year I'd like to start preparation a bit ahead of time :wink: I have been collecting some SoC ideas over the previous year.

So before I dump them all to the wiki I'd like to hear some of your comments.

* displaced symbols.
  Create a module to place map symbols on a map, so that the feature and other overlap information is minimized (NP-Complete problem). The map symbol should be referenced to their original location, by using a reference line.
  * Create new symbol file and add support for it to the GUI and a d.icon command, and to the PS driver.
  * Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.

Uniforming the vector modules:
  * Vector 3D support. Make all vector modules work in 3D space.
  * Add where= and cats= to as many modules as possible, where reasonable (also see ml discussion on this)

* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related)

* wxGui Graphical colour and interval and category selections. This would create a file which could be used in r.reclass, r.colors and friends. Maybe a similar tool for the vector equivalent?

* raster db connections. The raster category value would be a cat in a database. Introduce maybe a new kind of map otherwise identical to an INT map, but the values should be treated as DB cat id's.
  * is this at all feasible?

* Implement new TIN algorithms from
http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)

* Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)

* create an SQL query builder tool to help build sql queries, if enough time add PostGIS queries [cooperation with PostGIS]

* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in another datastructure, like winged edge)

* reimplement v.delauny (also possibly by going via some other data structure)

* R integration [there was some talk on this on the list]

* v.out.odg To create OO draw files (we could maybe collaborate with OO.o on this one, e.g. one mentor form each organisation)

* I've heard many complaints about GRASS lacking a Krigin module. One of these ideas could fix that (maybe both)
  * gstat GUI (would create gstat files, run gstat, and provide a GUI for all file editing tasks)
  * The same except would create an R script.

r.external (from last year) via GDAL

Thoughts? More ideas? Listing an Idea won't require any commitment. I think it is more important to get more ideas, later we will see who can mentor what. (I suspect that we will have sround 2 slots this year for GRASS)

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

2

Some other ideas:

From the GRASS 7.x ideas collection:

- implement file based spatial index (see "Keep topology and spatial index
in file instead of in memory" in Radim's Vector ToDo
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup)
- extend v.overlay to allow all types of overlay operations for all types
of vector (i.e. also points and lines)

More ambitious:
- implement an equivalent of eCognition's object-based classification (in
contrast to pixel-based classification)

Moritz

On Wed, February 20, 2008 17:04, Wolf Bergenheim wrote:

Hello fellow developers.

Google Summer of Code is going to start again soon, and this year I'd
like to start preparation a bit ahead of time :wink: I have been collecting
some SoC ideas over the previous year.

So before I dump them all to the wiki I'd like to hear some of your
comments.

* displaced symbols.
  Create a module to place map symbols on a map, so that the feature and
other overlap information is minimized (NP-Complete problem). The map
symbol should be referenced to their original location, by using a
reference line.
  * Create new symbol file and add support for it to the GUI and a d.icon
command, and to the PS driver.
  * Support native GRASS symbols, png, svg and others. Support specifying
symbol in the database for each feature.

Uniforming the vector modules:
  * Vector 3D support. Make all vector modules work in 3D space.
  * Add where= and cats= to as many modules as possible, where reasonable
(also see ml discussion on this)

* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related)

* wxGui Graphical colour and interval and category selections. This
would create a file which could be used in r.reclass, r.colors and
friends. Maybe a similar tool for the vector equivalent?

* raster db connections. The raster category value would be a cat in a
database. Introduce maybe a new kind of map otherwise identical to an
INT map, but the values should be treated as DB cat id's.
  * is this at all feasible?

* Implement new TIN algorithms from
http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital
elevation model construction from structured topographic data: The DEST
algorithm (see list discussion)

* Expand v.generalize with new methods (e.g merging, exaggeration,
collapse, displacement, point aggregation)

* create an SQL query builder tool to help build sql queries, if enough
time add PostGIS queries [cooperation with PostGIS]

* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in
another datastructure, like winged edge)

* reimplement v.delauny (also possibly by going via some other data
structure)

* R integration [there was some talk on this on the list]

* v.out.odg To create OO draw files (we could maybe collaborate with
OO.o on this one, e.g. one mentor form each organisation)

* I've heard many complaints about GRASS lacking a Krigin module. One of
these ideas could fix that (maybe both)
  * gstat GUI (would create gstat files, run gstat, and provide a GUI for
all file editing tasks)
  * The same except would create an R script.

r.external (from last year) via GDAL

Thoughts? More ideas? Listing an Idea won't require any commitment. I
think it is more important to get more ideas, later we will see who can
mentor what. (I suspect that we will have sround 2 slots this year for
GRASS)

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

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

3

On Feb 20, 2008, at 2:43 PM, Moritz Lennert wrote:

Some other ideas:

From the GRASS 7.x ideas collection:

- implement file based spatial index (see "Keep topology and spatial index
in file instead of in memory" in Radim's Vector ToDo
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup)

I wanted to suggest this one too (this should also remove the need
for constant rebuilding of spatial index whenever you want to query vector data)
- we should try to find a way how to make this task sound exciting so that there
is an interest to do it - or maybe make it part of some of the vector processing topics
suggested by Wolf.

Another topic that I was thinking about was getting a start for the next generation
visualization tool for GRASS - just a simple demo that can be done
in 3 months to display surface(s) in 2D and smoothly transfer the view into 3D.
Do we have a potential mentor? (I can be the second mentor, but we would
need somebody to mentor the programming part).

Helena

- extend v.overlay to allow all types of overlay operations for all types
of vector (i.e. also points and lines)

More ambitious:
- implement an equivalent of eCognition's object-based classification (in
contrast to pixel-based classification)

Moritz

On Wed, February 20, 2008 17:04, Wolf Bergenheim wrote:

Hello fellow developers.

Google Summer of Code is going to start again soon, and this year I'd
like to start preparation a bit ahead of time :wink: I have been collecting
some SoC ideas over the previous year.

So before I dump them all to the wiki I'd like to hear some of your
comments.

* displaced symbols.
  Create a module to place map symbols on a map, so that the feature and
other overlap information is minimized (NP-Complete problem). The map
symbol should be referenced to their original location, by using a
reference line.
  * Create new symbol file and add support for it to the GUI and a d.icon
command, and to the PS driver.
  * Support native GRASS symbols, png, svg and others. Support specifying
symbol in the database for each feature.

Uniforming the vector modules:
  * Vector 3D support. Make all vector modules work in 3D space.
  * Add where= and cats= to as many modules as possible, where reasonable
(also see ml discussion on this)

* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related)

* wxGui Graphical colour and interval and category selections. This
would create a file which could be used in r.reclass, r.colors and
friends. Maybe a similar tool for the vector equivalent?

* raster db connections. The raster category value would be a cat in a
database. Introduce maybe a new kind of map otherwise identical to an
INT map, but the values should be treated as DB cat id's.
  * is this at all feasible?

* Implement new TIN algorithms from
http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital
elevation model construction from structured topographic data: The DEST
algorithm (see list discussion)

* Expand v.generalize with new methods (e.g merging, exaggeration,
collapse, displacement, point aggregation)

* create an SQL query builder tool to help build sql queries, if enough
time add PostGIS queries [cooperation with PostGIS]

* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in
another datastructure, like winged edge)

* reimplement v.delauny (also possibly by going via some other data
structure)

* R integration [there was some talk on this on the list]

* v.out.odg To create OO draw files (we could maybe collaborate with
OO.o on this one, e.g. one mentor form each organisation)

* I've heard many complaints about GRASS lacking a Krigin module. One of
these ideas could fix that (maybe both)
  * gstat GUI (would create gstat files, run gstat, and provide a GUI for
all file editing tasks)
  * The same except would create an R script.

r.external (from last year) via GDAL

Thoughts? More ideas? Listing an Idea won't require any commitment. I
think it is more important to get more ideas, later we will see who can
mentor what. (I suspect that we will have sround 2 slots this year for
GRASS)

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

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

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

4

Wolf Bergenheim wrote:

Hello fellow developers.

Google Summer of Code is going to start again soon, and this year I'd
like to start preparation a bit ahead of time :wink: I have been
collecting some SoC ideas over the previous year.

So before I dump them all to the wiki I'd like to hear some of your
comments.

* displaced symbols.
   Create a module to place map symbols on a map, so that the
   feature and other overlap information is minimized (NP-Complete
   problem). The map symbol should be referenced to their original
   location, by using a reference line.

I don't quite understand what you mean by map symbol. Automatic
placement for legends, north arrows, and scale bars? (Seems reasonable,
even if I'm not sure I'd ever use it personally)

Or for 'd.vect type=point icon=symbol_class/symbol_name'? (I don't
think we should be perturbing spatially referenced markers)

* Create new symbol file and add support for it to the GUI and a
   d.icon command, and to the PS driver.

Again, I'm not quite following what this is about.

see d.graph, and "d.stations" + "d.mark" in the wiki addons, and
  http://grass.gdf-hannover.de/wiki/IconSymbols

* Support native GRASS symbols, png, svg and others. Support
specifying symbol in the database for each feature.

see the .eps note at the end of the d.graph help page, and note that
ps.map already supports .eps symbols; AFAIR "svg2eps" may be done from
directly from the command line with inkscape's command line options.

Uniforming the vector modules:
* Vector 3D support. Make all vector modules work in 3D space.
* Add where= and cats= to as many modules as possible, where
reasonable (also see ml discussion on this)

it would be good to write down exactly which modules are involved.
"all" will not be appropriate.

I see this more of a chore than an interesting new project challenge.

* Improved line of sight (Paul Kelly's proposal from last year)

Yes please

* 3D Vector line of sight (related)

example of how/when this would be used?

* wxGui Graphical colour and interval and category selections. This
would create a file which could be used in r.reclass, r.colors and
friends. Maybe a similar tool for the vector equivalent?

how does this releate to the new thematic tools?

* raster db connections. The raster category value would be a cat in
a database. Introduce maybe a new kind of map otherwise identical to
an INT map, but the values should be treated as DB cat id's.
* is this at all feasible?

example of how/when this would be used?

* Implement new TIN algorithms from

In my personal opinion TINs suck and we don't need them. They are
useful for a vector based GIS which lacks support for decent raster
interpolation tools. The ongoing demand for TINs seems to come from
users coming from other (historically vector based) GISs who have not
yet discovered GRASS's vector -> raster interpolation modules.

* Expand v.generalize with new methods (e.g merging, exaggeration,
collapse, displacement, point aggregation)

a big enough project?

* create an SQL query builder tool to help build sql queries, if
enough time add PostGIS queries [cooperation with PostGIS]

interesting.

* rewrite v.buffer / v.parallel

yes please.

* reimplement v.delauny (also possibly by going via some other data
structure)

has it been established that the method is bad? I do not remember
seeing anything which would suggest that problems could not be solved
with some small bug fixing, in which case it would be silly to throw
the whole thing away and start a new module.

* R integration [there was some talk on this on the list]

Roger: thoughts?

* v.out.odg To create OO draw files (we could maybe collaborate with
OO.o on this one, e.g. one mentor form each organisation)

wouldn't it be better to go for something more generic, like improving
the postscript dispaly driver? (probably as part of GRASS 7)

* I've heard many complaints about GRASS lacking a Krigin module. One
of these ideas could fix that (maybe both)
* gstat GUI (would create gstat files, run gstat, and provide a GUI
for all file editing tasks)
  * The same except would create an R script.

this is related to the R integration threads.

r.external (from last year) via GDAL

interesting.

Thoughts? More ideas? Listing an Idea won't require any commitment. I
think it is more important to get more ideas, later we will see who
can mentor what. (I suspect that we will have sround 2 slots this
year for GRASS)

thanks for spearheading this Wolf.

maybe we could trawl through wishes in the bug trackers for more
ideas..

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

5

Wolf:

> * Support native GRASS symbols, png, svg and others. Support
> specifying symbol in the database for each feature.

Hamish:

see the .eps note at the end of the d.graph help page, and note that
ps.map already supports .eps symbols; AFAIR "svg2eps" may be done
directly from the command line with inkscape's command line options.

SVG -> EPS for use with ps.map:
  http://grass.gdf-hannover.de/wiki/IconSymbols#Symbol_families

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

6

On 03/09/2008 03:25 AM, Hamish wrote:

Wolf Bergenheim wrote:

* displaced symbols.
   Create a module to place map symbols on a map, so that the
   feature and other overlap information is minimized (NP-Complete
   problem). The map symbol should be referenced to their original
   location, by using a reference line.

I don't quite understand what you mean by map symbol. Automatic
placement for legends, north arrows, and scale bars? (Seems reasonable,
even if I'm not sure I'd ever use it personally)

Or for 'd.vect type=point icon=symbol_class/symbol_name'? (I don't
think we should be perturbing spatially referenced markers)

I mean icons for point-symbols, the idea of the module would be to have these icons displayed in such a way that they don't overlap, say if you have 5 layers, on for churches, one for schools, one for restaurants, etc, at some point these icons might overlap, if they are too close to each other. Also optionally if you have a map of a city you probably don't want to place the symbol so that it obstructs say an complicated crossing. This is perhaps a bit too much focused on mapping for GRASS, but it was just an idea...

* Create new symbol file and add support for it to the GUI and a
   d.icon command, and to the PS driver.

Again, I'm not quite following what this is about.

Basically the same thing, but support for ps.map, like labels.

see d.graph, and "d.stations" + "d.mark" in the wiki addons, and
  http://grass.gdf-hannover.de/wiki/IconSymbols

Yeah, I just feel it would be nice to be able to support icons in any format, or at least provide tools to convert common icon formats to something that GRASS can use.

* Support native GRASS symbols, png, svg and others. Support
specifying symbol in the database for each feature.

see the .eps note at the end of the d.graph help page, and note that
ps.map already supports .eps symbols; AFAIR "svg2eps" may be done from
directly from the command line with inkscape's command line options.

Also in the GUI display window, or else maybe create a GUI for ps.map :wink:

Uniforming the vector modules:
* Vector 3D support. Make all vector modules work in 3D space.
* Add where= and cats= to as many modules as possible, where
reasonable (also see ml discussion on this)

it would be good to write down exactly which modules are involved.
"all" will not be appropriate.

I see this more of a chore than an interesting new project challenge.

You might see is as a chore, whereas some student might see it as fun. :wink:

The idea with the ideas on the ideas page is to give some sort of indication to the student what we would expect from an application. They are not, and should not be complete SoC applications. It is the responsibility of the Student to work them into an actual SoC application, which is interesting enough to be accepted.

* Improved line of sight (Paul Kelly's proposal from last year)

Yes please

* 3D Vector line of sight (related)

example of how/when this would be used?

We have a city of buildings and want to see where we should put our towers. This is something Markus mentioned to me in passing. Markus perhaps you can elaborate.

* wxGui Graphical colour and interval and category selections. This would create a file which could be used in r.reclass, r.colors and friends. Maybe a similar tool for the vector equivalent?

how does this releate to the new thematic tools?

Perhaps these interval files could be used as well? I'm not too familiar with the new thematic tools... :frowning:

* raster db connections. The raster category value would be a cat in
a database. Introduce maybe a new kind of map otherwise identical to
an INT map, but the values should be treated as DB cat id's.
* is this at all feasible?

example of how/when this would be used?

Say you have a raster map of anything and want to be able to store more then one piece of information for each pixel. So in essence the pixel value would be the key to the table. See ARCGis for more uses :wink:

* Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)

a big enough project?

I think so yes. Last year it was a good project. This year it could be extended with more methods to complete out generalization support.

* create an SQL query builder tool to help build sql queries, if
enough time add PostGIS queries [cooperation with PostGIS]

interesting.

* rewrite v.buffer / v.parallel

yes please.

:smiley: I'd also love to see this be realized.

* reimplement v.delauny (also possibly by going via some other data structure)

has it been established that the method is bad? I do not remember
seeing anything which would suggest that problems could not be solved
with some small bug fixing, in which case it would be silly to throw
the whole thing away and start a new module.

There was some email about it, where someone concluded that it should be rewritten. Search the archives. :wink:

  >> * v.out.odg To create OO draw files (we could maybe collaborate with

OO.o on this one, e.g. one mentor form each organisation)

wouldn't it be better to go for something more generic, like improving
the postscript dispaly driver? (probably as part of GRASS 7)

As you've probably figured out I'd love to see a simpler tool to create maps in GRASS, preferably a snazzy GUI.

* I've heard many complaints about GRASS lacking a Krigin module. One
of these ideas could fix that (maybe both)
* gstat GUI (would create gstat files, run gstat, and provide a GUI
for all file editing tasks)
  * The same except would create an R script.

this is related to the R integration threads.

Yes.

maybe we could trawl through wishes in the bug trackers for more
ideas..

Please do!

Also I'd like to point out that we should start getting out a list of ideas ASAP, the students will start reading our pages on the 17th.

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>