Subject: [Thuban-list] classification of variable ratios, not only single variables

From: "Moritz Lennert" <[email-masked]>
Date: Fri, 5 Mar 2004 16:42:34 +0100 (CET)

Hello,

I'll just keep going until someone stops me ;-)

How difficult would it be to introduce the possibility of classifying a
map according to the ratio of two variables instead of one variable alone.
As an example: if I have a map whose data table contains population and
surface for each spatial entity, I have to go into the data file (outside
of thuban) and calculate the population density and then I can generate a
map of this density. It would be nice to have the possibility to indicate
two variables, one as nominator and one as denominator and then launch the
classification on this ratio.

Moritz

---

From: "Daniel Calvelo Aros" <[email-masked]>
Date: Sat, 6 Mar 2004 03:21:37 -0500

On Fri, 5 Mar 2004 16:42:34 +0100 (CET), Moritz Lennert wrote
> How difficult would it be to introduce the possibility of 
> classifying a map according to the ratio of two variables instead of 
> one variable alone. As an example: if I have a map whose data table 
> contains population and surface for each spatial entity, I have to 
> go into the data file (outside of thuban) and calculate the 
> population density and then I can generate a map of this density. It 
> would be nice to have the possibility to indicate two variables, one 
> as nominator and one as denominator and then launch the 

It wouldn't be hard. The point is to do it right. 

I mean: the fine way would be to introduce a variable calculator into thuban,
and the possibility to add new (transient) variables into a table. Since we
are using SQLite, the operators are there; there is no need for a full
expression parser.

The odd way (to me) would be to use, like ArcView does, a "Normalize by" extra
variable in the classification dialog. I'd rather have the first, although the
second seems more straightforward for interactive exploration.

Just thinking out loud, but what do you all think of having a *postgis*
calculator, including the GEOS-based extensions, so that we could within
thuban have choropleth maps of, say, the length of rivers that are contained
within state boundaries? That's a lot of extra packages needed, and installing
postgis isn't very straightforward right now...

Thoughts? (I'd be glad to start implementing whatever solution is preferred).

Daniel.

PS. BTW, would people at intevation update thuban .deb to 1.0? What about
packaging postgis+geos for debian? And mapserver? And... (we really need a
debian developer with a strong GIS bias...)

-- Daniel Calvelo Aros
-- Dirección General de Información Agraria
-- Ministerio de Agricultura del Perú
-- (51-1)424-9001

---

From: Stephan Holl <[email-masked]>
Date: Sat, 6 Mar 2004 10:53:17 +0100

Hello Daniel,

At Sat, 6 Mar 2004 03:21:37 -0500 Daniel Calvelo Aros wrote:

> What about
> packaging postgis+geos for debian? And mapserver? And... (we really
> need a debian developer with a strong GIS bias...)

There are unofficial debian-packages for postgis and postgis-geos.
Add this to your /etc/apt/sources.list
	deb http://agrogeomatic.educagri.fr/debian stable main

a first starting point...

Cheers

  Stephan

-- 
Stephan Holl

Check headers for GnuPG Key!
http://www.gdf-hannover.de

 10:50:09 up  1:42,  1 user,  load average: 0.00, 0.00, 0.00

---

From: Jan-Oliver Wagner <[email-masked]>
Date: Sat, 6 Mar 2004 13:19:26 +0100

On Sat, Mar 06, 2004 at 03:21:37AM -0500, Daniel Calvelo Aros wrote:
> PS. BTW, would people at intevation update thuban .deb to 1.0?

already in unstable :-)

Silke: seems you haven't update the thuban/debian CVS files ?

I also updated the download page since gdal now is incorporated and
allows raster layers.

Silke: I think we could replace the src downloads by a explaination
how to get the sourcees from the Debian server?

> debian developer with a strong GIS bias...)

Silke packaged Thuban and gdal. gdal also helped getting GRASS updates
into Debian.

	Jan

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/

Intevation GmbH	              	     http://intevation.de/
FreeGIS	                               http://freegis.org/

---

From: Martin Schulze <[email-masked]>
Date: Sat, 6 Mar 2004 09:45:29 +0100

> debian developer with a strong GIS bias...)

1.0 is in unstable already, the version in testing is a bit older, though.

thuban      testing   1.0rc1-1    alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source
thuban      unstable  1.0.0-1     alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source

update-excuse:

     * thuban (1.0rc1-1 to 1.0.0-1)
          + Maintainer: Silke Reimer
          + Too young, only 4 of 10 days old
          + Not considered

Assuming this is correct, the package will automatically be moved into
testing in 6 days.  However, I wouldn't be surprised if it turns out
to be a dependency problem as well after the quarantaene time.

Regards,

	Joey

-- 
Let's call it an accidental feature.  -- Larry Wall

---

From: Silke Reimer <[email-masked]>
Date: Mon, 8 Mar 2004 10:44:43 +0100

Hallo,

> Silke: seems you haven't update the thuban/debian CVS files ?

Yes. Now it is done. And I will update the thuban download page
today.

> how to get the sourcees from the Debian server?

OK. I will update the page accordingly.

> Silke packaged Thuban and gdal. gdal also helped getting GRASS updates

And I would like to have postgis into debian, too. Giuseppe Sacco
was originally planning to package postgis [1] but I didn't see a
lot of action within the last months. My plan is to investigate it
further as soon as I have a little bit more time.

	Silke

[1] http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg00376.html

-- 
Silke Reimer

---

From: "Moritz Lennert" <[email-masked]>
Date: Mon, 8 Mar 2004 11:04:52 +0100 (CET)

Daniel,

Let's keep the discussion going concerning ratios, now that the Debian
issue seems cleared up.

> are using SQLite, the operators are there; there is no need for a full

Could you elaborate on this ? I am not sure I understand correctly. You
mean that instead of having to include all variables into the table, we
should be able to import (transient) variables from other sources ?

> second seems more straightforward for interactive exploration.

Yes, it is very easy to use. I guess we also have to watch out concerning
the direction of Thuban: it is a viewer not a GIS, or ?

> postgis isn't very straightforward right now...

And it would oblige everyone to use postgis to be able to calculate simple
ratios ? For many usages this seems overkill.

Moritz

---

From: "Daniel Calvelo" <[email-masked]>
Date: Tue, 9 Mar 2004 14:27:13 -0500

On Mon, 8 Mar 2004 11:04:52 +0100 (CET), Moritz Lennert wrote
> Daniel,
> 
> Let's keep the discussion going concerning ratios, now that the 
> Debian issue seems cleared up.

:)

[about introducing ratios in choropleth maps]
> mean that instead of having to include all variables into the table, 
> we should be able to import (transient) variables from other sources ?

I mean that we could have a means of introducing new transient variables
within thuban, and be able to make calculations on them. Thus, ratios are a
simple case of dividing two available variables to make a third, transient,
variable.
 
> the direction of Thuban: it is a viewer not a GIS, or ?

Very good point.

> ratios ? For many usages this seems overkill.

Sure :)

This is related to your previous point. The matter here is not to use postgis
to calculate ratios (I've seen using Oracle remote access to find out lap
years, mind you), which is just the tinyest thing to do with the setting I
mentioned. It's about, as you said before, moving or not from a viewer towards
a GIS.

I think that question should be answered by looking at the current status and
future directions of current free software GIS-related systems. I find two
trends in application (not library) development lately: one is building
user-frienldy interfaces to leverage powerful GIS libraries, the other is to
start from a well interfaced viewer/presenter and move towards GIS
functionality. I currently have explored JUMP, OpenEV, TerraView, QuantumGIS
(and thuban of course) in the latter category. I'd put GMT, GRASS, PostGIS
rather on the former.

Now (freegis.org maintainers please correct me) it seems all of these projects
are headed towards GIS proper. JUMP lacks raster support, but has JTS. QGIS is
flirting with GRASS and PostGIS. OpenEV is slowly adding features. TerraView
only interfaces a small part of the underlying powerful terralib. Refractions,
Inc. states that PostGIS is a step towards a GIS. GRASS is being rewritten to
extend vector capabilities and interfaces.

Where do we want to go? What are distinctive features of thuban (regardless of
technical specifics: cross-platform, Python-based, fully free,...) with
respect to its potential uses? Is it headed towards an embeddable library? Is
it a testbed (e.g. I'm exploring using it for anamorphic cartograms)? Which of
the above projects are we concurrencing?

Making thuban a single-user (desktop) front-end to PostGIS or other features
server may be a long-term goal. We are currently targetting a viewer for
spatial data, but I'm afraid more and more complex things will be getting in
the way and make thuban more and more GISish... The cut doesn't seem very
clear to me.

Thoughts? Will to think of restating or extending the roadmap?

Daniel.

-- Daniel Calvelo Aros

---

From: "Moritz Lennert" <[email-masked]>
Date: Wed, 10 Mar 2004 10:04:32 +0100 (CET)

Daniel Calvelo said:
> On Mon, 8 Mar 2004 11:04:52 +0100 (CET), Moritz wrote:

[snip]

>> > and the possibility to add new (transient) variables into a table.
>> Since
>> > we

Isn't this what ArcView does with its "Normalize by" ? I guess I still
don't understand what you mean completely.

[snip]

> Thoughts? Will to think of restating or extending the roadmap?

I had always seen Thuban as a tool for cartography, which should sooner or
later be interfaced with GIS systems (the roadmap already states access to
the GRASS database as a goal). So, as an example, someone could actually
replace the current tcltkgrass menus of GRASS by an equivalent in Thuban
and thus create "ThuGRASS" ;-), combining the GIS features of GRASS with
the cartography features in Thuban. Add a better integration with Skencil
and you have a complete chain of tools.

This should be possible with other GIS systems. So, I don't think that
Thuban should develop its own GIS features, but rather try to be as open
as possible to allow integration with existing or future free GIS systems.

Moritz

---

From: Bernhard Reiter <[email-masked]>
Date: Wed, 10 Mar 2004 13:53:43 +0100

> > I think that question should be answered by looking at the
> > current status and future directions of current free software
> > GIS-related systems. 

This is an important and interesting question.
I also pounder it from time to time.

> > I find two trends in application (not library) development
> > lately: one is building user-frienldy interfaces to leverage
> > powerful GIS libraries, the other is to start from a well
> > interfaced viewer/presenter and move towards GIS functionality.
> > I currently have explored JUMP, OpenEV, TerraView, QuantumGIS
> > (and thuban of course) in the latter category. I'd put GMT,
> > GRASS, PostGIS rather on the former.

I also see those two trends.
But you can also make orthogonal categories, 
like use of technology and user communities.

> > Now (freegis.org maintainers please correct me) it seems all of
> > these projects are headed towards GIS proper. 

I agree to the thought, but it highly depends on the defintion of GIS.
Using more focussed terms like 
	interactive viewer
	analysis library
	database
	cartography tool
will help the discussion.

> > JUMP lacks raster support, but has JTS.  
> > QGIS is flirting with GRASS and PostGIS.
> > OpenEV is slowly adding features.  TerraView only interfaces a
> > small part of the underlying powerful terralib.  Refractions,
> > Inc. states that PostGIS is a step towards a GIS. GRASS is being
> > rewritten to extend vector capabilities and interfaces.
> >
> > Where do we want to go? What are distinctive features of thuban
> > (regardless of technical specifics: cross-platform,
> > Python-based, fully free,...) with respect to its potential
> > uses? Is it headed towards an embeddable library?

I do not see it heading towards an embeddable library.
The technical specifics shape its potential uses.

Answer to your questions lie in the was Free Software works
in general. I believe it to be centered around a community 
of developers and users. The communication structure is very important.
Also the knowledge each of the participants have.

In Free Software it is natural that people will extend the solution
they know and are accustomed with. Thus each component can possibly
grow in many directions. After a while the function will overlap,
they might be coupled in various , too.

This process constitutes a search for the 
best separation between components and the best solutions
for the developers and users.

> > Is it a testbed 
> > (e.g. I'm exploring using it for anamorphic cartograms)?  

Yes, you can use Thuban as a testbed.

> > Which of the above projects are we concurrencing?

It depends. Expect OpenEV, they are all not crossplatform
and ready to run on a completely Free Software system.

> > Making thuban a single-user (desktop) front-end to PostGIS or other
> > features server may be a long-term goal. 
> > We are currently targetting a viewer for spatial data, 
> > but I'm afraid more and more complex things will be getting in
> > the way and make thuban more and more GISish... 
> > The cut doesn't seem very clear to me.

True, the cut is not clear.
But this seems to be an advantage to Free Software.
Diversity will lead to better solutions for the users.
If users and developers want it, Thuban will have some analysis
features. Certainly some analysis features 
like distance or area calculation are more considered 
cartography then hard GIS.

> > Thoughts? Will to think of restating or extending the roadmap?

We always think about changing the roadmap, 
if we find out more about the world.
This is why we like your thoughts and your contributions.
The roadmap of Thuban will be written by its community.
Intevation is only one part of this community.

> and you have a complete chain of tools.

This is the main goal that motivated us to start Thuban:
Complete the tool chain.

> as possible to allow integration with existing or future free GIS systems.

We will keep Thuban open.

	Bernhard