From info at stoller-dresden.de Wed Jan 8 17:50:51 2003 From: info at stoller-dresden.de (Stoller Ingenieurtechnik GmbH) Date: Wed, 8 Jan 2003 17:50:51 +0100 Subject: [Thuban-list] Newbie: Importing e00 files Message-ID: <022a01c2b736$38535ea0$c800a8c0@AOL> Hi! I am new to GIS but not to programming. Thuban looks interesting. Is there a way to import e00 files? I got them from: http://www.maproom.psu.edu/dcw/ Background: I want to write an application which should have a clickable map of russia. You should see the most important cities and some points added from a database. Or is better to use sketch? Both (thuban and sketch) seem to be developed at intevation. What speaks for, what against using one of them? BTW, Why is there so view traffic on this list? Is thuban used seldom? What are the alternatives? Plattform will be win32 and unix. thomas Please CC to me, I am not on the list. --- Stoller Ingenieurtechnik GmbH Baerensteiner Strasse 27-29, 01277 Dresden Germany Tel.: +49-351-2123930 E-mail: info at stoller-dresden.de Fax: +49-351-2123959 Internet: www.stoller-dresden.de From bernhard at intevation.de Thu Jan 9 18:17:09 2003 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 9 Jan 2003 18:17:09 +0100 Subject: [Thuban-list] Newbie: Importing e00 files In-Reply-To: <022a01c2b736$38535ea0$c800a8c0@AOL> References: <022a01c2b736$38535ea0$c800a8c0@AOL> Message-ID: <20030109171709.GD22556@intevation.de> Hi Stoller, On Wed, Jan 08, 2003 at 05:50:51PM +0100, Stoller Ingenieurtechnik GmbH wrote: > I am new to GIS but not to programming. > Thuban looks interesting. > > Is there a way to import e00 files? Currently Thuban only deals with shapefiles. You would need to convert the e00 files first using other tools. > I got them from: > http://www.maproom.psu.edu/dcw/ > > Background: > I want to write an application which should have > a clickable map of russia. You should see the most > important cities and some points added from a > database. > > Or is better to use sketch? Both (thuban and sketch) seem > to be developed at intevation. What speaks for, what against > using one of them? Sketch is a pretty complete general vector drawing application. E.g. you can use it to finalise maps before printing. Thuban is an interactive geoviewer and focused on this task. Its idea is to browse and edit the data interactively. > BTW, Why is there so view traffic on this list? Is thuban used seldom? There is so few traffic, because Thuban is in its early stages and most users so far communicate with developers at Intevation quite closely not using the list. > What are the alternatives? > Plattform will be win32 and unix. Check out freegis.org, there are plenty. > Please CC to me, I am not on the list. Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-list/attachments/20030109/525ccd13/attachment.bin From jonathan at intevation.de Thu Jan 16 10:46:56 2003 From: jonathan at intevation.de (Jonathan Coles) Date: 16 Jan 2003 10:46:56 +0100 Subject: [Thuban-list] RFC: Layer Classification Message-ID: <1042710416.4254.33.camel@reisen> RFC: Layer Classification ------------------------- Thuban currently has no mechanism for classifying the shapes that compose a layer. It should be possible to define classification properties that partition the shapes so that each partition can be drawn in a different way. For instance, shapes associated with counties can have population properties which are then color coded. There should be a Classification class that encapsulates a classification of a layer's shapes. It would contain the data type that it was associated with (this would come from the table of shape properties), and a list of data values: [[range_low, range_high, [data_values, ...]], ...] When a layer is drawn each shape matches its property value against the ranges (range_low <= value <= range_high, however <= is defined) in the list to find its assigned data values. These values can determine such things as line color, line thickness, and fill color. These data values should not be specifically defined for all types of layers. Polygon layers may have the three values mentioned above, whereas an arc layer may only need the first two. The type of layer that is being drawn will know what values are in the data_values list. There would then have to be an appropriate dialog to allow these values and ranges to be set. Thoughts? --jonathan From jonathan at intevation.de Thu Jan 16 11:16:25 2003 From: jonathan at intevation.de (Jonathan Coles) Date: 16 Jan 2003 11:16:25 +0100 Subject: [Thuban-list] RFC: Layer Rendering Message-ID: <1042712185.4254.63.camel@reisen> RFC: Layer Rendering -------------------- I've noticed that the MapRenderer class contains all the logic to draw the layers and shapes. I think that most of this can and should be moved to another class, either Layer or LayerRenderer. When work on the layer classification begins (see RFC: Layer Classification) there will need to be a lot of type checking to determine what kind of shape is being drawn, what shape property is being used for classification, and so on. A function like layer.render(dc, ...). would clean a lot of this up and just let the system handle what Layer to draw. Which leads into creating several subclasses of Layer for each type. Each subclass would know how to draw itself and what data values are stored in its classification data structure. This allows new types of Layers to be drawn more easily. Ideally, Layers would know how to load and save themselves (although the exact hierarchy for this needs some thought; I wouldn't want to overload the class with too much work). It seems that Layers do know how to load themselves, but a different class is saving them. Putting all this is the same or related class has the advantage of easily adding Layers that are stored in different formats. Perhaps Layer loading could be a plug-in feature (I believe that this is easy to do in Python?). These are just some of my rough thoughts for now. Thoughts? --jonathan From bernhard at intevation.de Thu Jan 16 11:43:17 2003 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 16 Jan 2003 11:43:17 +0100 Subject: [Thuban-list] RFC: Layer Classification In-Reply-To: <1042710416.4254.33.camel@reisen> References: <1042710416.4254.33.camel@reisen> Message-ID: <20030116104317.GB17548@intevation.de> On Thu, Jan 16, 2003 at 10:46:56AM +0100, Jonathan Coles wrote: > There should be a Classification class that encapsulates a > classification of a layer's shapes. It would contain the data type that > it was associated with (this would come from the table of shape > properties), and a list of data values: > > [[range_low, range_high, [data_values, ...]], ...] > > When a layer is drawn each shape matches its property value against the > ranges (range_low <= value <= range_high, however <= is defined) in the > list to find its assigned data values. These values can determine such > things as line color, line thickness, and fill color. > Thoughts? Just that classification might get more complicated later, possible requiring more data and computation. Then just a list of data values or ranges might not be enough. If I got your design idea right then the Classification class will encapsulate this so it should be fine. It makes sense to implement the simple one first, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-list/attachments/20030116/f966c5e4/attachment.bin From warmerdam at pobox.com Thu Jan 16 15:27:37 2003 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu, 16 Jan 2003 09:27:37 -0500 Subject: [Thuban-list] RFC: Layer Classification In-Reply-To: <1042710416.4254.33.camel@reisen> References: <1042710416.4254.33.camel@reisen> Message-ID: <3E26C159.6070009@pobox.com> Jonathan Coles wrote: > RFC: Layer Classification > ------------------------- > > Thuban currently has no mechanism for classifying the shapes that > compose a layer. It should be possible to define classification > properties that partition the shapes so that each partition can be drawn > in a different way. For instance, shapes associated with counties can > have population properties which are then color coded. > > There should be a Classification class that encapsulates a > classification of a layer's shapes. It would contain the data type that > it was associated with (this would come from the table of shape > properties), and a list of data values: > > [[range_low, range_high, [data_values, ...]], ...] > > When a layer is drawn each shape matches its property value against the > ranges (range_low <= value <= range_high, however <= is defined) in the > list to find its assigned data values. These values can determine such > things as line color, line thickness, and fill color. > > These data values should not be specifically defined for all types of > layers. Polygon layers may have the three values mentioned above, > whereas an arc layer may only need the first two. The type of layer that > is being drawn will know what values are in the data_values list. Jonathan, Though not really a Thuban user, I though I would provide a bit of feedback on this. First, for non-ambiguous class membership for data ranges I would suggest the test semantics be "range_low <= value < range_high", or that you make it clear what order the classes are evaluated in so that if some classes have overlapping ranges (even if just at the end points) that you would know what class will be selected. Second, when classifying continuous values it is often convenient to have an aspect of the class (such as color) vary continuously depending on where the data value falls between range_low and range_high. For instance, if rendering point data with temperatures it is often nice to have one class that continuously renders the points between blue and red depending on where they fall in a range. Finally, you might want to introduce a concept of a NULL class. The classification that should be applied to features not falling into another class. Alternatively this might just be specified as a lowest priority class with a very wide data range. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From jan at intevation.de Mon Jan 20 17:44:36 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 20 Jan 2003 17:44:36 +0100 Subject: [Thuban-list] RFC: Layer Rendering In-Reply-To: <1042712185.4254.63.camel@reisen> References: <1042712185.4254.63.camel@reisen> Message-ID: <20030120164436.GA1641@intevation.de> we discussed this IRL. Currently the Layers should neither know how to store itself in a file nor should it do the rendering. Layer currently is a quite stupid class that just holds the necessary information. Storing the infos to a file is kept central in order to have a central point where different file formats (or specific versions of the same format) are be read/written. A single object (like Layer) does not know about the file format in general and thus should not write small portions of it. For the time being, we also keep the rendering in place, but this might eventually change. On Thu, Jan 16, 2003 at 11:16:25AM +0100, Jonathan Coles wrote: > I've noticed that the MapRenderer class contains all the logic to draw > the layers and shapes. I think that most of this can and should be moved > to another class, either Layer or LayerRenderer. When work on the layer > classification begins (see RFC: Layer Classification) there will need to > be a lot of type checking to determine what kind of shape is being > drawn, what shape property is being used for classification, and so on. > A function like layer.render(dc, ...). would clean a lot of this up and > just let the system handle what Layer to draw. > > Which leads into creating several subclasses of Layer for each type. > Each subclass would know how to draw itself and what data values are > stored in its classification data structure. This allows new types of > Layers to be drawn more easily. Ideally, Layers would know how to load > and save themselves (although the exact hierarchy for this needs some > thought; I wouldn't want to overload the class with too much work). It > seems that Layers do know how to load themselves, but a different class > is saving them. Putting all this is the same or related class has the > advantage of easily adding Layers that are stored in different formats. > Perhaps Layer loading could be a plug-in feature (I believe that this is > easy to do in Python?). -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan at intevation.de Mon Jan 20 17:53:17 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 20 Jan 2003 17:53:17 +0100 Subject: [Thuban-list] RFC: Layer Classification In-Reply-To: <3E26C159.6070009@pobox.com> References: <1042710416.4254.33.camel@reisen> <3E26C159.6070009@pobox.com> Message-ID: <20030120165317.GB1641@intevation.de> On Thu, Jan 16, 2003 at 09:27:37AM -0500, Frank Warmerdam wrote: > First, for non-ambiguous class membership for data ranges I would suggest > the test semantics be "range_low <= value < range_high", we'll apply this rule. > Second, when classifying continuous values it is often convenient to > have an aspect of the class (such as color) vary continuously depending > on where the data value falls between range_low and range_high. For > instance, if rendering point data with temperatures it is often nice > to have one class that continuously renders the points between blue and > red depending on where they fall in a range. it seems that there are three types: - discrete (eg 1,2,3 or 'ruin', 'city') - range (eg 0-2.5, 2.5-3.75, 3.75-65.123) - continous (as you described) discrete and range is no problem and will be implemented first. continous is a bit different since it couples a drawing property (color, line thickness, ...) directly to the value. Eg: range 1-15.6 corresponds to color (0,0,0)-(0,0,255) Jonathan, I guess you should keep this third type of classification in mind. Maybe it is not too complicated to implement it. > Finally, you might want to introduce a concept of a NULL class. The > classification that should be applied to features not falling into another > class. Alternatively this might just be specified as a lowest priority > class with a very wide data range. This concept will be implemented. -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From billtate at usermail.com Sat Jan 25 16:45:00 2003 From: billtate at usermail.com (Bill Tate) Date: Sat, 25 Jan 2003 16:45:00 Subject: [Thuban-list] Thuban build error - Message-ID: <200301252148.h0PLmZ4d024133@usermail.com> Anyone encounter this before trying to build 0.1.3 v of Thuban On win2000, python 2.2..1, with wxpython 2.3.2.1 Have VC++ 6.0 but I'm getting the following build error when executing python setup.py build vc++ unable to find an include file projects.h - a search for the file came up empty. ...extensions/thuban/wxproj.cpp(26) : fatal error C1083: Cannot open include file: 'projects.h': No such file or directory Any assistance would be greatly appreciated. regards, bill From jonathan at intevation.de Mon Jan 27 13:21:25 2003 From: jonathan at intevation.de (Jonathan Coles) Date: 27 Jan 2003 13:21:25 +0100 Subject: [Thuban-list] added classification support Message-ID: <1043670085.1843.49.camel@reisen> The following initial updates are now in the cvs repository: layer.py -- classification initialization calls classification.py -- created class to encapsulate a layer classification. Supports specific data points and ranges. load.py -- add support for loading classification information save.py -- add support for saving classification information classifier.py -- initial class for a dialog mainwindow.py -- support for opening the classifier dialog renderer.py -- support for drawing a layer with the classification information iceland_sample_class.thuban -- iceland_sample with classification data test_classification -- tests for the Classification class --jonathan From tkoester at intevation.de Mon Jan 27 14:53:07 2003 From: tkoester at intevation.de (Thomas Koester) Date: Mon, 27 Jan 2003 14:53:07 +0100 Subject: [Thuban-list] added classification support In-Reply-To: <1043670085.1843.49.camel@reisen> References: <1043670085.1843.49.camel@reisen> Message-ID: <20030127135307.GA15329@intevation.de> On Mon, Jan 27, 2003 at 01:21:25PM +0100, Jonathan Coles wrote: > The following initial updates are now in the cvs repository: I installed a current Thuban checkout with python setup.py install --prefix /home/tkoester/Project/greater/install This is the error I get when trying to run it: Traceback (most recent call last): File "./thuban", line 21, in ? import Thuban.UI.main File "/home/tkoester/Project/greater/install/lib/thuban/Thuban/UI/main.py", line 18, in ? from application import ThubanApplication File "/home/tkoester/Project/greater/install/lib/thuban/Thuban/UI/application.py", line 24, in ? from Thuban.Model.load import load_session File "/home/tkoester/Project/greater/install/lib/thuban/Thuban/Model/load.py", line 23, in ? from Thuban.Model.layer import Layer File "/home/tkoester/Project/greater/install/lib/thuban/Thuban/Model/layer.py", line 22, in ? from classification import Classification ImportError: No module named classification Thomas -- Email: tkoester at intevation.de http://intevation.de/~tkoester/ From jan at intevation.de Mon Jan 27 15:01:26 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 27 Jan 2003 15:01:26 +0100 Subject: [Thuban-list] added classification support In-Reply-To: <20030127135307.GA15329@intevation.de> References: <1043670085.1843.49.camel@reisen> <20030127135307.GA15329@intevation.de> Message-ID: <20030127140126.GI1050@intevation.de> On Mon, Jan 27, 2003 at 02:53:07PM +0100, Thomas Koester wrote: >... > File "/home/tkoester/Project/greater/install/lib/thuban/Thuban/Model/layer.py", line 22, in ? > from classification import Classification > ImportError: No module named classification this file should now be in CVS. -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan at intevation.de Mon Jan 27 15:23:36 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 27 Jan 2003 15:23:36 +0100 Subject: [Thuban-list] added classification support In-Reply-To: <1043670085.1843.49.camel@reisen> References: <1043670085.1843.49.camel@reisen> Message-ID: <20030127142336.GK1050@intevation.de> On Mon, Jan 27, 2003 at 01:21:25PM +0100, Jonathan Coles wrote: > The following initial updates are now in the cvs repository: > layer.py -- classification initialization calls >... the sample looks nice. Calling the menu item Classify does not work yet. -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan at intevation.de Mon Jan 27 15:27:10 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 27 Jan 2003 15:27:10 +0100 Subject: [Thuban-list] thuban going for i18n Message-ID: <20030127142710.GL1050@intevation.de> Hi, I just checked in some preparations for support of i18n. All developers: please now use _('...') to specifiy your UI strings. You can import it from Thuban directly. _() currently is just returning its argument, but now the gettext functionality can easily be integrated. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From frank.koormann at intevation.de Mon Jan 27 15:41:02 2003 From: frank.koormann at intevation.de (Frank Koormann) Date: Mon, 27 Jan 2003 15:41:02 +0100 Subject: [Thuban-list] Thuban build error In-Reply-To: <200301252148.h0PLmZ4d024133@usermail.com> References: <200301252148.h0PLmZ4d024133@usermail.com> Message-ID: <20030127144102.GA16804@intevation.de> Bill, * Bill Tate [030125 22:49]: > Anyone encounter this before trying to build 0.1.3 v of Thuban > > On win2000, python 2.2..1, with wxpython 2.3.2.1 > > Have VC++ 6.0 but I'm getting the following build error when executing > python setup.py build > > vc++ unable to find an include file projects.h - a search for the file > came up empty. > > ...extensions/thuban/wxproj.cpp(26) : fatal error C1083: Cannot open include > file: 'projects.h': No such file or directory This is a documentation bug: The docs doesn't state explicitely that you have also to install proj4 to build Thuban. You can find the lib at: http://www.remotesensing.org/proj/ Potentially you have to fix some of the paths in the Thuban setup to build Thuban wth success. Kind regards, Frank -- Frank Koormann Professional Service around Free Software (http://intevation.net/) FreeGIS Project (http://freegis.org/) From eugeneai at icc.ru Wed Jan 22 13:28:54 2003 From: eugeneai at icc.ru (Cherkashin Evgeny) Date: Wed, 22 Jan 2003 20:28:54 +0800 Subject: [Thuban-list] Localizing Thuban, and more... Message-ID: <3E2E8E86.7020806@icc.ru> Hi! I'm head of an scientific project "Constructing an intelligent GIS", project "Angara" (103E, 53N, Irkutsk) which is sponsored of Russian Foundation of Fundamental (Pure) Research. Our aim is to construct programmatical means of development of Decision Support Systems of reginal resources control. A year ago I've decided to construct a new GIS on the base of Python and wxWindows. But due to some organizing problems the project did not started (we developed some scientific aspects of the project). Not so long time ago I've found the Thuban project. Thst's it, I dreamed at nigth. People, wery good work. I decided to develop the project further. My personal itch in the development is as follows: 1. Adaptation of the GIS-viewer to Russian locale. (DONE yestarday partially). 2. Include GDAL-directed access to the GIS. 3. Introduce some spatial data treatenment software, that we have developed (Database Access using XML-specs, City road net reconstruction). 4. After introducing in the Python langage some means of logical inference, the system can do some AI (Automatical model construction of a class of models on the base of data and investigation aim description). 5. I can make an mirror site of the Thuban site. Now I send a patch (durty), which contains the localization and change of the setup.py procedure. The localization allows me to use russian file names and titles. It should be tested by You wether it still works or not. The setup.py was changed (the changes are not intended to be in the distribution directly): 1. To build the wx module on the base of preinstalled development package of the wxPython library. The library is now can be downloaded from www.wxPyhon.org with the library. So, developer are note required to compile wxWindows itself. 2. I placed Proj-4.5 sources in "local" directory. Thanks for Your help to our scientific investigation. You can (should) place also the sign: "The project is partially sponsored by Russian Foundation of Fundamental Research, grants No 01-07-90411, 02-07-06013, 02-05-65054, 02-07-90113, http://www.rfbr.ru" Big warm Gruss aus Sibirien, Ewgenij Tscherkashin (in German transcription) P.S. The diff file is in the attachment. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tunban_recursive_diff.diff Url: http://www.intevation.de/pipermail/thuban-list/attachments/20030122/2920b953/tunban_recursive_diff.diff From jan at intevation.de Tue Jan 28 11:32:51 2003 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 28 Jan 2003 11:32:51 +0100 Subject: [Thuban-list] Localizing Thuban, and more... In-Reply-To: <3E2E8E86.7020806@icc.ru> References: <3E2E8E86.7020806@icc.ru> Message-ID: <20030128103251.GC4326@intevation.de> On Wed, Jan 22, 2003 at 08:28:54PM +0800, Cherkashin Evgeny wrote: > My personal itch in the development is as follows: > 1. Adaptation of the GIS-viewer to Russian locale. (DONE yestarday > partially). Your patch workes around the problem that we did not incorporate real i18n support. I've started better support for i18n yesterday (due to your email :-). Primary aims should be to have gettext support and unicode-clean internal use of strings. All this will take some time of course. > 2. Include GDAL-directed access to the GIS. This would be a great improvement! Please let this mailing list know on your progress, questions etc. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jonathan at intevation.de Tue Jan 28 13:55:23 2003 From: jonathan at intevation.de (Jonathan Coles) Date: 28 Jan 2003 13:55:23 +0100 Subject: [Thuban-list] added classification support In-Reply-To: <20030127142336.GK1050@intevation.de> References: <1043670085.1843.49.camel@reisen> <20030127142336.GK1050@intevation.de> Message-ID: <1043758523.7662.1.camel@reisen> Classify menu item should not crash Thuban now. --jonathan On Mon, 2003-01-27 at 15:23, Jan-Oliver Wagner wrote: > On Mon, Jan 27, 2003 at 01:21:25PM +0100, Jonathan Coles wrote: > > The following initial updates are now in the cvs repository: > > layer.py -- classification initialization calls > >... > > the sample looks nice. Calling the menu item Classify does not > work yet. > > -- > Jan-Oliver Wagner http://intevation.de/~jan/ > > Intevation GmbH http://intevation.de/ > FreeGIS http://freegis.org/ > > _______________________________________________ > Thuban-list mailing list > Thuban-list at intevation.de > https://intevation.de/mailman/listinfo/thuban-list