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

[Daniel Calvelo]

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]
> > 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.
> 
> 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 ?

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 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.
> 
> 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 ?

Very good point.

> > 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...
> >
> 
> And it would oblige everyone to use postgis to be able to calculate simple
> 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?

> Moritz

Daniel.

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