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

Moritz Lennert mlennert at club.worldonline.be
Wed Mar 10 10:04:32 CET 2004

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


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


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


More information about the Thuban-list mailing list

This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)