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

[Moritz Lennert]

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

[snip]

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

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

[snip]

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

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