From bernhard at intevation.de  Fri Nov  5 11:33:39 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 5 Nov 2004 11:33:39 +0100
Subject: [Thuban-devel] Status of sizeable points feature
In-Reply-To: <20041007155304.GA1451@intevation.de>
References: <20041007145606.GA1104@intevation.de>
	<20041007155304.GA1451@intevation.de>
Message-ID: <20041105103339.GF29467@intevation.de>

On Thu, Oct 07, 2004 at 05:53:04PM +0200, Jan-Oliver Wagner wrote:
> On Thu, Oct 07, 2004 at 04:56:06PM +0200, Jan-Oliver Wagner wrote:
> > The things that remain to be done are (any help welcome):

> > - Respect the size when doing hit-testing.

Yes, this really is ugly together with the rendering.

> > - Handle this better in the renderer.  The current implementation is a
> >   horrible kludge that only works in some circumstances.

-------------- 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-devel/attachments/20041105/2d01d8ed/attachment.bin

From jan at intevation.de  Thu Nov 11 21:01:52 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Thu, 11 Nov 2004 21:01:52 +0100
Subject: Proposed change for Extensions import and Extension registry
Message-ID: <20041111200152.GA4351@intevation.de>

Hi,

after some thinking about how the extension are important
and registered I came to the conclusion that it
is better to have the extension registry entry in the
__init__.py file of the extensions' main directory
instead of in one of the files.

Also, in the __init__.py file the actual modules
could be imported. Thus, in ~/.thuban/thubanstart.py
you can write:
import Extensions.gns2shp
instead of
import Extensions.gns2shp.gns2shp

This is even more interesting if you have to
import more than one file like for the umn_mapserver
extension.

The good thing is that this is compatible with already
existing thubanstart.py files. You just don't have the
registry done.

Attached is a patch for gns2shp that illustrates what
I mean.

This is the last issue to complete the registry feature.
And I really want to remove this from my todo list soon.
It can easily be backported to 1.0 btw.

Best

	Jan

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

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



From jan at intevation.de  Thu Nov 11 21:02:44 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Thu, 11 Nov 2004 21:02:44 +0100
Subject: [Thuban-devel] Proposed change for Extensions import and
	Extension registry
In-Reply-To: <20041111200152.GA4351@intevation.de>
References: <20041111200152.GA4351@intevation.de>
Message-ID: <20041111200244.GB4351@intevation.de>

On Thu, Nov 11, 2004 at 09:01:52PM +0100, Jan-Oliver Wagner wrote:
> Attached is a patch for gns2shp that illustrates what
> I mean.

now it is.

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

Intevation GmbH                      http://intevation.de/
FreeGIS                                http://freegis.org/
-------------- next part --------------
Index: Extensions/gns2shp/__init__.py
===================================================================
RCS file: /home/thuban/jail/thubanrepository/thuban/Extensions/gns2shp/__init__.py,v
retrieving revision 1.1
diff -u -3 -p -r1.1 __init__.py
--- Extensions/gns2shp/__init__.py	4 Sep 2003 15:16:44 -0000	1.1
+++ Extensions/gns2shp/__init__.py	11 Nov 2004 19:51:36 -0000
@@ -1,6 +1,21 @@
-# Copyright (c) 2003 by Intevation GmbH
+# Copyright (c) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
-# This program is free software under the GPL (>=v2)
+# This program is free software under the GNU GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
+
+import gns2shp
+
+from Thuban import _
+from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+
+ext_registry.add(ExtensionDesc(
+    name = 'gns2shp',
+    version = '1.0.0',
+    authors= [ 'Jan-Oliver Wagner' ],
+    copyright = '2003, 2004 Intevation GmbH',
+    desc = _("Converts GNS (Geographical Name Service\n" \
+             "of NIMA) to Shapefile format and\n" \
+             "displays the data.")))
+
Index: Extensions/gns2shp/gns2shp.py
===================================================================
RCS file: /home/thuban/jail/thubanrepository/thuban/Extensions/gns2shp/gns2shp.py,v
retrieving revision 1.4
diff -u -3 -p -r1.4 gns2shp.py
--- Extensions/gns2shp/gns2shp.py	28 Sep 2004 19:26:58 -0000	1.4
+++ Extensions/gns2shp/gns2shp.py	11 Nov 2004 19:51:36 -0000
@@ -1,8 +1,8 @@
-# Copyright (C) 2003 by Intevation GmbH
+# Copyright (C) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
-# This program is free software under the GPL (>=v2)
+# This program is free software under the GNU GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
 
 """
@@ -32,21 +32,8 @@ if __name__ != '__main__':
     from Thuban import _
     from Thuban.Model.layer import Layer
 
-from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
-
 import shapelib
 import dbflib
-
-
-ext_registry.add(ExtensionDesc(
-    name = 'gns2shp',
-    version = '1.0.0',
-    authors= [ 'Jan-Oliver Wagner' ],
-    copyright = '2003, 2004 Intevation GmbH',
-    desc = _("Converts GNS (Geographical Name Service\n" \
-             "of NIMA) to Shapefile format and\n" \
-             "displays the data.")))
-
 
 def gns2shp(src_fname, dest_fname):
     """Convert a file from gns textformat into a Shapefile.

From joey at infodrom.org  Fri Nov 12 07:24:06 2004
From: joey at infodrom.org (Martin Schulze)
Date: Fri, 12 Nov 2004 07:24:06 +0100
Subject: Proposed change for Extensions import and Extension registry
In-Reply-To: <20041111200152.GA4351@intevation.de>
References: <20041111200152.GA4351@intevation.de>
Message-ID: <20041112062405.GI7329@finlandia.infodrom.north.de>

Jan-Oliver Wagner wrote:
> after some thinking about how the extension are important
> and registered I came to the conclusion that it
> is better to have the extension registry entry in the
> __init__.py file of the extensions' main directory
> instead of in one of the files.
> 
> Also, in the __init__.py file the actual modules
> could be imported. Thus, in ~/.thuban/thubanstart.py
> you can write:
> import Extensions.gns2shp
> instead of
> import Extensions.gns2shp.gns2shp

Sounds good to me.

Regards,

	Joey

-- 
We all know Linux is great... it does infinite loops in 5 seconds.
        -- Linus Torvalds



From cvs at intevation.de  Mon Nov 15 17:27:43 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Mon, 15 Nov 2004 17:27:43 +0100 (CET)
Subject: bernhard: thuban ChangeLog,1.701,1.702 
Message-ID: <20041115162743.39B36100161@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv31569

Modified Files:
	ChangeLog 
Log Message:
* Extensions/svgexport/: Minor improvements to doc strings.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.701
retrieving revision 1.702
diff -u -d -r1.701 -r1.702
--- ChangeLog	7 Oct 2004 14:44:47 -0000	1.701
+++ ChangeLog	15 Nov 2004 16:27:40 -0000	1.702
@@ -1,3 +1,7 @@
+2004-10-28  Bernhard Reiter <bernhard at intevation.de>
+
+	* Extensions/svgexport/: Minor improvements to doc strings.
+
 2004-10-07  Jan-Oliver Wagner <jan at intevation.de>
 
 	Further elements for sizable point objects now




From cvs at intevation.de  Mon Nov 15 17:27:43 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Mon, 15 Nov 2004 17:27:43 +0100 (CET)
Subject: bernhard: thuban/Extensions/svgexport maplegend.py, 1.1,
	1.2 svgmapwriter.py, 1.5, 1.6 svgsaver.py, 1.3, 1.4 
Message-ID: <20041115162743.3C459102BF9@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban/Extensions/svgexport
In directory doto:/tmp/cvs-serv31569/Extensions/svgexport

Modified Files:
	maplegend.py svgmapwriter.py svgsaver.py 
Log Message:
* Extensions/svgexport/: Minor improvements to doc strings.


Index: maplegend.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/maplegend.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- maplegend.py	19 Feb 2004 13:38:27 -0000	1.1
+++ maplegend.py	15 Nov 2004 16:27:41 -0000	1.2
@@ -119,9 +119,10 @@
 
 
 def write_legend(context):
-    '''The main export funtion - Exports the data depending
-    on the set properties.
-    '''
+    """Export the data depending on the set properties.
+
+    This is the main export function.
+    """
     canvas = context.mainwindow.canvas
     file = None
     map = canvas.Map()

Index: svgmapwriter.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/svgmapwriter.py,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- svgmapwriter.py	27 Sep 2004 09:56:13 -0000	1.5
+++ svgmapwriter.py	15 Nov 2004 16:27:41 -0000	1.6
@@ -8,7 +8,7 @@
 
 
 """
-Classes needed to write a session in SVG format
+Classes needed to write a session in SVG format.
 """
 
 # For compatibility with python 2.2
@@ -52,16 +52,14 @@
 # Some pseudo classes to be compatible with the Baserenderer-class.
 #
 class Point:
-    """A simple Point class."""
+    """Simple Point class to save x,y coordinates."""
     def __init__(self, xp=0, yp=0):
-        """Init the point object."""
         self.x = xp
         self.y = yp
 
 class Trafo:
-    """Class for tranformation properties transfer."""
+    """Class for transformation properties transfer."""
     def __init__(self):
-        """Initialize the class."""
         self.trafos = []
     
     def Append(self, type, coeffs):
@@ -79,9 +77,7 @@
         else: return None
 
 class Pattern:
-    """Pattern object """
     def __init__(self, solid=1):
-        """Init the Pattern object."""
         self.solid = solid
 
 class Pen:
@@ -94,23 +90,18 @@
         self.cap = 'round'
     
     def GetColor(self):
-        """Return the pen's color."""
         return self.color
 
     def GetWidth(self):
-        """Return the pen's width."""
         return self.width
 
     def GetJoin(self):
-        """Return the pen's join type."""
         return self.join
     
     def GetCap(self):
-        """Return the pen's cap type."""
         return self.cap
     
     def GetDashes(self):
-        """Return the pen's dashes."""
         if self.dashes is None or self.dashes is SOLID:
             return []
         else: return self.dashes
@@ -123,11 +114,9 @@
         self.pattern = bpattern
     
     def GetColor(self):
-        """Return the brush color."""
         return self.fill
     
     def GetPattern(self):
-        """Return the Brush pattern object."""
         return self.pattern
 
 class Font:

Index: svgsaver.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/svgsaver.py,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- svgsaver.py	21 Sep 2004 21:30:36 -0000	1.3
+++ svgsaver.py	15 Nov 2004 16:27:41 -0000	1.4
@@ -30,8 +30,9 @@
 
 
 def write_to_svg(context):
-    '''The main export funtion - Exports the data depending
-    on the set properties.
+    '''Export data depending on the set properties.
+
+    This is the main export funcation.
     '''
     canvas = context.mainwindow.canvas
     file = None




From thuban-bugs at intevation.de  Mon Nov 15 18:21:53 2004
From: thuban-bugs at intevation.de (Request Tracker)
Date: Mon, 15 Nov 2004 18:21:53 +0100 (CET)
Subject: [bug #2692] (thuban) printing leaves out some objects
Message-ID: <20041115172153.A6F47102C0B@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=2692
-------------------------------------------------------------------------

Subject: printing leaves out some objects

As reported by Moritz on Thuban-list:
http://intevation.de/pipermail/thuban-list/2004-November/000508.html
confirmed by Jan.

The drawing stops without reason.

-------------------------------------------- Managed by Request Tracker



From joey at infodrom.org  Mon Nov 15 18:57:31 2004
From: joey at infodrom.org (Martin Schulze)
Date: Mon, 15 Nov 2004 18:57:31 +0100
Subject: Support for bitmap image formats
In-Reply-To: <20040410172407.GD1655@finlandia.infodrom.north.de>
References: <20040410172407.GD1655@finlandia.infodrom.north.de>
Message-ID: <20041115175731.GA1401@finlandia.infodrom.north.de>

Martin Schulze wrote:
> is there a reason the render engine is limited to support only JPEG
> and BMP?  The wxWidgets library seems to support more image formats,
> such as commonly used TIFF, PNG, GIF, or less commonly used PNM, PCX,
> XBM and XPM, just to name some.
> 
> I've just tested whether the engine can handle PNG, TIFF and GIF,
> which worked fine.  I know that's not a proof, but only a
> circumstantial evidence.

Here's further research:

  <http://www.wxwindows.org/feature2.htm> -- wxWidgets 2 Features
  
  XPM is implemented on Unix and Windows; and PNG is implemented on both.
  
  The wxImage class can load JPEG, TIFF, PCX, GIF, PNM and BMP files and
  can also rotate and scale images. wxImage is a platform-independent
  class with emphasis on loading multiple image formats, whereas
  wxBitmap wraps the appropriate platform-dependent bitmap.
  
Hence, it should be fine to enable PNG, TIFF and GIF since they
are supported on both Unix and Windows.

> Attached is a patch that would add these formats.

Regards,

	Joey

-- 
Open source is important from a technical angle.             -- Linus Torvalds
-------------- next part --------------
Index: renderer.py
===================================================================
RCS file: /thubanrepository/thuban/Thuban/UI/renderer.py,v
retrieving revision 1.49
diff -u -r1.49 renderer.py
--- Thuban/UI/renderer.py	11 Nov 2003 18:16:42 -0000	1.49
+++ Thuban/UI/renderer.py	10 Apr 2004 17:15:23 -0000
@@ -20,7 +20,8 @@
 from wxPython.wx import wxPoint, wxRect, wxPen, wxBrush, wxFont, \
     wxTRANSPARENT_PEN, wxTRANSPARENT_BRUSH, \
     wxBLACK_PEN, wxBLACK, wxSOLID, wxCROSS_HATCH, wxSWISS, wxNORMAL, \
-    wxBitmapFromImage, wxImageFromStream, wxBITMAP_TYPE_BMP, wxBITMAP_TYPE_JPEG
+    wxBitmapFromImage, wxImageFromStream, wxBITMAP_TYPE_BMP, \
+    wxBITMAP_TYPE_JPEG, wxBITMAP_TYPE_PNG, wxBITMAP_TYPE_TIF, wxBITMAP_TYPE_GIF
 
 from wxproj import draw_polygon_shape, draw_polygon_init
 
@@ -42,6 +43,9 @@
 raster_format_map = {
     "BMP": wxBITMAP_TYPE_BMP,
     "JPEG": wxBITMAP_TYPE_JPEG,
+    "PNG": wxBITMAP_TYPE_PNG,
+    "TIFF": wxBITMAP_TYPE_TIF,
+    "GIF": wxBITMAP_TYPE_GIF,
     }
 
 class MapRenderer(BaseRenderer):

From joey at infodrom.org  Tue Nov 16 16:40:08 2004
From: joey at infodrom.org (Martin Schulze)
Date: Tue, 16 Nov 2004 16:40:08 +0100
Subject: Support for bitmap image formats
In-Reply-To: <20041115175731.GA1401@finlandia.infodrom.north.de>
References: <20040410172407.GD1655@finlandia.infodrom.north.de>
	<20041115175731.GA1401@finlandia.infodrom.north.de>
Message-ID: <20041116154008.GA5286@finlandia.infodrom.north.de>

Martin Schulze wrote:
> Martin Schulze wrote:
> > is there a reason the render engine is limited to support only JPEG
> > and BMP?  The wxWidgets library seems to support more image formats,
> > such as commonly used TIFF, PNG, GIF, or less commonly used PNM, PCX,
> > XBM and XPM, just to name some.
> > 
> > I've just tested whether the engine can handle PNG, TIFF and GIF,
> > which worked fine.  I know that's not a proof, but only a
> > circumstantial evidence.
> 
> Here's further research:
> 
>   <http://www.wxwindows.org/feature2.htm> -- wxWidgets 2 Features
>   
>   XPM is implemented on Unix and Windows; and PNG is implemented on both.
>   
>   The wxImage class can load JPEG, TIFF, PCX, GIF, PNM and BMP files and
>   can also rotate and scale images. wxImage is a platform-independent
>   class with emphasis on loading multiple image formats, whereas
>   wxBitmap wraps the appropriate platform-dependent bitmap.
>   
> Hence, it should be fine to enable PNG, TIFF and GIF since they
> are supported on both Unix and Windows.

Maybe I should have added that the renderer from Thuban uses
wxImageFromStream and so according to the name wxImage.

Regards,

	Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle



From cvs at intevation.de  Tue Nov 16 22:15:19 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Tue, 16 Nov 2004 22:15:19 +0100 (CET)
Subject: jan: thuban/Extensions/gns2shp gns2shp.py,1.4,1.5 
Message-ID: <20041116211519.81410102C10@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/gns2shp
In directory doto:/tmp/cvs-serv13078

Modified Files:
	gns2shp.py 
Log Message:
Removed registry entry (moved to __init__.py).


Index: gns2shp.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/gns2shp/gns2shp.py,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- gns2shp.py	28 Sep 2004 19:26:58 -0000	1.4
+++ gns2shp.py	16 Nov 2004 21:15:17 -0000	1.5
@@ -1,6 +1,6 @@
-# Copyright (C) 2003 by Intevation GmbH
+# Copyright (C) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -32,21 +32,8 @@
     from Thuban import _
     from Thuban.Model.layer import Layer
 
-from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
-
 import shapelib
 import dbflib
-
-
-ext_registry.add(ExtensionDesc(
-    name = 'gns2shp',
-    version = '1.0.0',
-    authors= [ 'Jan-Oliver Wagner' ],
-    copyright = '2003, 2004 Intevation GmbH',
-    desc = _("Converts GNS (Geographical Name Service\n" \
-             "of NIMA) to Shapefile format and\n" \
-             "displays the data.")))
-
 
 def gns2shp(src_fname, dest_fname):
     """Convert a file from gns textformat into a Shapefile.




From cvs at intevation.de  Tue Nov 16 22:15:51 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Tue, 16 Nov 2004 22:15:51 +0100 (CET)
Subject: jan: thuban/Extensions/gns2shp __init__.py,1.1,1.2 
Message-ID: <20041116211551.1D09A102C10@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/gns2shp
In directory doto:/tmp/cvs-serv13123

Modified Files:
	__init__.py 
Log Message:
Added registry entry and the importing of the actual gns2shp module.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/gns2shp/__init__.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- __init__.py	4 Sep 2003 15:16:44 -0000	1.1
+++ __init__.py	16 Nov 2004 21:15:49 -0000	1.2
@@ -1,6 +1,22 @@
-# Copyright (c) 2003 by Intevation GmbH
+# Copyright (c) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
+
+# import the actual module
+import gns2shp
+
+# perform the registration of the extension
+from Thuban import _
+from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+
+ext_registry.add(ExtensionDesc(
+    name = 'gns2shp',
+    version = '1.0.0',
+    authors= [ 'Jan-Oliver Wagner' ],
+    copyright = '2003, 2004 Intevation GmbH',
+    desc = _("Converts GNS (Geographical Name Service\n" \
+             "of NIMA) to Shapefile format and\n" \
+             "displays the data.")))




From cvs at intevation.de  Tue Nov 16 22:32:58 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Tue, 16 Nov 2004 22:32:58 +0100 (CET)
Subject: jan: thuban/Extensions/profiling profiling.py,1.5,1.6 
Message-ID: <20041116213258.E11F3102C10@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/profiling
In directory doto:/tmp/cvs-serv13637

Modified Files:
	profiling.py 
Log Message:
Removed registry entry (moved to __init__.py).


Index: profiling.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/profiling/profiling.py,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- profiling.py	28 Sep 2004 19:53:52 -0000	1.5
+++ profiling.py	16 Nov 2004 21:32:56 -0000	1.6
@@ -1,6 +1,7 @@
-# Copyright (C) 2003 by Intevation GmbH
+# Copyright (C) 2003, 2004 by Intevation GmbH
 # Authors:
-# Bernhard Herzog <bh at intevation.de>
+# Bernhard Herzog <bh at intevation.de> (2003)
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with the software for details.
@@ -33,15 +34,6 @@
 from Thuban import _
 from Thuban.UI.command import registry, Command
 from Thuban.UI.mainwindow import main_menu
-from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
-
-ext_registry.add(ExtensionDesc(
-    name = 'profiling',
-    version = '1.0.0',
-    authors= [ 'Bernhard Herzog' ],
-    copyright = '2003 Intevation GmbH',
-    desc = _("Provide a profiler and a timer\n"
-             "for screen rendering.")))
 
 #
 # Customization




From cvs at intevation.de  Tue Nov 16 22:33:29 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Tue, 16 Nov 2004 22:33:29 +0100 (CET)
Subject: jan: thuban/Extensions/profiling __init__.py,1.1,1.2 
Message-ID: <20041116213329.8E3D6102C14@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/profiling
In directory doto:/tmp/cvs-serv13660

Modified Files:
	__init__.py 
Log Message:
Added registry entry and the importing of the actual profiling module.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/profiling/__init__.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- __init__.py	31 Oct 2003 16:02:52 -0000	1.1
+++ __init__.py	16 Nov 2004 21:33:27 -0000	1.2
@@ -1,6 +1,22 @@
-# Copyright (c) 2003 by Intevation GmbH
+# Copyright (c) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
+
+# import the actual module
+import profiling
+
+# perform the registration of the extension
+from Thuban import _
+from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+
+ext_registry.add(ExtensionDesc(
+    name = 'profiling',
+    version = '1.0.0',
+    authors= [ 'Bernhard Herzog' ],
+    copyright = '2003, 2004 Intevation GmbH',
+    desc = _("Provide a profiler and a timer\n"
+             "for screen rendering.")))
+




From cvs at intevation.de  Tue Nov 16 22:35:05 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Tue, 16 Nov 2004 22:35:05 +0100 (CET)
Subject: jan: thuban ChangeLog,1.702,1.703 
Message-ID: <20041116213505.F28F9102C10@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv13734

Modified Files:
	ChangeLog 
Log Message:
Changed way of Extension Registry for gns2shp and profiling.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.702
retrieving revision 1.703
diff -u -d -r1.702 -r1.703
--- ChangeLog	15 Nov 2004 16:27:40 -0000	1.702
+++ ChangeLog	16 Nov 2004 21:35:03 -0000	1.703
@@ -1,3 +1,19 @@
+2004-11-16  Jan-Oliver Wagner <jan at intevation.de>
+
+	Changed way of Extension Registry for gns2shp and profiling.
+
+	* Extensions/gns2shp/gns2shp.py: Removed registry entry (moved to
+	__init__.py).
+
+	* Extensions/gns2shp/__init__.py: Added registry entry and the importing
+	of the actual gns2shp module.
+
+	* Extensions/profiling/profiling.py: Removed registry entry (moved to
+	__init__.py).
+
+	* Extensions/profiling/__init__.py: Added registry entry and the importing
+	of the actual profiling module.
+
 2004-10-28  Bernhard Reiter <bernhard at intevation.de>
 
 	* Extensions/svgexport/: Minor improvements to doc strings.




From jan at intevation.de  Tue Nov 16 22:38:14 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Tue, 16 Nov 2004 22:38:14 +0100
Subject: [Thuban-devel] Proposed change for Extensions import and
	Extension registry
In-Reply-To: <20041111200152.GA4351@intevation.de>
References: <20041111200152.GA4351@intevation.de>
Message-ID: <20041116213814.GA6478@intevation.de>

Hi,

I now started to perform this change.
There is another advantage: The __init__.py
can catch exception on importing the actual module and feed this info
into the registry :-)

	Jan

On Thu, Nov 11, 2004 at 09:01:52PM +0100, Jan-Oliver Wagner wrote:
> after some thinking about how the extension are important
> and registered I came to the conclusion that it
> is better to have the extension registry entry in the
> __init__.py file of the extensions' main directory
> instead of in one of the files.
> 
> Also, in the __init__.py file the actual modules
> could be imported. Thus, in ~/.thuban/thubanstart.py
> you can write:
> import Extensions.gns2shp
> instead of
> import Extensions.gns2shp.gns2shp
> 
> This is even more interesting if you have to
> import more than one file like for the umn_mapserver
> extension.
> 
> The good thing is that this is compatible with already
> existing thubanstart.py files. You just don't have the
> registry done.
> 
> Attached is a patch for gns2shp that illustrates what
> I mean.
> 
> This is the last issue to complete the registry feature.
> And I really want to remove this from my todo list soon.
> It can easily be backported to 1.0 btw.

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

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



From cvs at intevation.de  Wed Nov 17 23:02:31 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Wed, 17 Nov 2004 23:02:31 +0100 (CET)
Subject: jan: thuban/Thuban/UI renderer.py,1.49,1.50 
Message-ID: <20041117220231.BFE5610016B@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Thuban/UI
In directory doto:/tmp/cvs-serv9105

Modified Files:
	renderer.py 
Log Message:
(ScreenRenderer.draw_selection_incrementally):
Added consideration of the specific size of point symbols.
The property for each point symbol is retrieved and the size applied
for the rendering method.
Added doc-string.


Index: renderer.py
===================================================================
RCS file: /thubanrepository/thuban/Thuban/UI/renderer.py,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -d -r1.49 -r1.50
--- renderer.py	11 Nov 2003 18:16:42 -0000	1.49
+++ renderer.py	17 Nov 2004 22:02:29 -0000	1.50
@@ -1,8 +1,9 @@
-# Copyright (c) 2001, 2002, 2003 by Intevation GmbH
+# Copyright (c) 2001-2004 by Intevation GmbH
 # Authors:
-# Bernhard Herzog <bh at intevation.de>
-# Jonathan Coles <jonathan at intevation.de>
-# Frank Koormann <frank.koormann at intevation.de>
+# Bernhard Herzog <bh at intevation.de> (2001-2003)
+# Jonathan Coles <jonathan at intevation.de> (2003)
+# Frank Koormann <frank.koormann at intevation.de> (2003)
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -129,16 +130,44 @@
         return self.render_map_incrementally()
 
     def draw_selection_incrementally(self, layer, selected_shapes):
+        """Draw the selected shapes in a emphasized way (i.e.
+        with a special pen and brush.
+        The drawing is performed incrementally, that means every
+        n shapes, the user can have interactions with the map.
+        n is currently fixed to 500.
+
+        layer -- the layer where the shapes belong to.
+        selected_shapes -- a list of the shape-ids representing the
+                           selected shapes for the given layer.
+        """
         pen = wxPen(wxBLACK, 3, wxSOLID)
         brush = wxBrush(wxBLACK, wxCROSS_HATCH)
 
         shapetype = layer.ShapeType()
         useraw, func, param = self.low_level_renderer(layer)
         args = (pen, brush)
+
+        # for point shapes we need to find out the properties
+        # to determine the size. Based on table and field,
+        # we can find out the properties for object - see below.
+        if shapetype == SHAPETYPE_POINT:
+            lc = layer.GetClassification()
+            field = layer.GetClassificationColumn()
+            table = layer.ShapeStore().Table()
+
         count = 0
         for index in selected_shapes:
             count += 1
             shape = layer.Shape(index)
+
+            # Get the size of the specific property for this
+            # point
+            if shapetype == SHAPETYPE_POINT:
+                value = table.ReadValue(shape.ShapeID(), field)
+                group = lc.FindGroup(value)
+                size = group.GetProperties().GetSize()
+                args = (pen, brush, size)
+
             if useraw:
                 data = shape.RawData()
             else:




From cvs at intevation.de  Wed Nov 17 23:08:35 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Wed, 17 Nov 2004 23:08:35 +0100 (CET)
Subject: jan: thuban ChangeLog,1.703,1.704 
Message-ID: <20041117220835.68B3510016B@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv9233

Modified Files:
	ChangeLog 
Log Message:
Another open issue regarding sizeable symbols: correct rendering of
selected symbols.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.703
retrieving revision 1.704
diff -u -d -r1.703 -r1.704
--- ChangeLog	16 Nov 2004 21:35:03 -0000	1.703
+++ ChangeLog	17 Nov 2004 22:08:33 -0000	1.704
@@ -1,3 +1,14 @@
+2004-11-17  Jan-Oliver Wagner <jan at intevation.de>
+
+	Another open issue regarding sizeable symbols: correct rendering of
+	selected symbols.
+
+	* Thuban/UI/renderer.py (ScreenRenderer.draw_selection_incrementally):
+	Added consideration of the specific size of point symbols.
+	The property for each point symbol is retrieved and the size applied
+	for the rendering method.
+	Added doc-string.
+
 2004-11-16  Jan-Oliver Wagner <jan at intevation.de>
 
 	Changed way of Extension Registry for gns2shp and profiling.




From mlennert at club.worldonline.be  Thu Nov 18 11:01:41 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Thu, 18 Nov 2004 11:01:41 +0100 (CET)
Subject: [Thuban-list] svgexport does not export polygon layers
In-Reply-To: <20041115163716.GO26967@intevation.de>
References: <49761.164.15.134.155.1100097741.squirrel@vivegnulinux.homelinux.org>
	<20041115163716.GO26967@intevation.de>
Message-ID: <32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>

Hi Bernard,

On Mon, November 15, 2004 17:37, Bernhard Reiter said:
> Hi Moritz,
>
> On Wed, Nov 10, 2004 at 03:42:21PM +0100, Moritz Lennert wrote:
>
>> Now that I have access to the svg export extension, however, I have
>> problems exporting polygon layers. Line and point layers are no problem.
>> Polygon layers get mentioned in the svg file, but are empty:
>>
>> <g meta="Layer:Secteurs statistiques" >
>> </g>
>> <g meta="Layer:Communes" >
>> </g>
>>
>> Does the svg export tool not support polygon layers ?
>
> It does and it works for me, e.g. on the iceland political layer.
>
> The buglet in there is, that polygons will not be closed,
> but I consider this minor.
>
> But with your data there also seems to be a bug.
> Because you have problems with postscript output also,
> I think it will be in a different part of Thuban.
> (Let's take this to the development list and poke around.)
>

I've tested with the Iceland data and I can confirm that polygons are
exported.

But I have tested with several shapefiles used here in the department and
none of the polygon layer are exported.

I have also imported and cleaned a shapefile in GRASS and rexported it
with v.out.ogr, but it still is not exported to svg.

Moritz



From bernhard at intevation.de  Thu Nov 18 12:19:46 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 18 Nov 2004 12:19:46 +0100
Subject: jan: thuban ChangeLog,1.703,1.704
In-Reply-To: <20041117220835.68B3510016B@lists.intevation.de>
References: <20041117220835.68B3510016B@lists.intevation.de>
Message-ID: <20041118111946.GB7094@intevation.de>

On Wed, Nov 17, 2004 at 11:08:35PM +0100, cvs at intevation.de wrote:
> Author: jan

> Modified Files:
> 	ChangeLog 
> Log Message:
> Another open issue regarding sizeable symbols: correct rendering of
> selected symbols.

So: Did you fix it?
;-) (Upon first reading I was misslead about what you have meant.)
-------------- 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-devel/attachments/20041118/d98e3eda/attachment.bin

From bernhard at intevation.de  Thu Nov 18 12:21:04 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 18 Nov 2004 12:21:04 +0100
Subject: [Thuban-list] svgexport does not export polygon layers
In-Reply-To: <32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>
References: <49761.164.15.134.155.1100097741.squirrel@vivegnulinux.homelinux.org>
	<20041115163716.GO26967@intevation.de>
	<32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>
Message-ID: <20041118112104.GC7094@intevation.de>

Hi Moritz,

On Thu, Nov 18, 2004 at 11:01:41AM +0100, Moritz Lennert wrote:
> On Mon, November 15, 2004 17:37, Bernhard Reiter said:
> > On Wed, Nov 10, 2004 at 03:42:21PM +0100, Moritz Lennert wrote:

> >> Polygon layers get mentioned in the svg file, but are empty:
> >>
> >> <g meta="Layer:Secteurs statistiques" >
> >> </g>
> >> <g meta="Layer:Communes" >
> >> </g>
> >>
> >> Does the svg export tool not support polygon layers ?
> >
> > It does and it works for me, e.g. on the iceland political layer.

> I've tested with the Iceland data and I can confirm that polygons are
> exported.
> 
> But I have tested with several shapefiles used here in the department and
> none of the polygon layer are exported.

> I have also imported and cleaned a shapefile in GRASS and rexported it
> with v.out.ogr, but it still is not exported to svg.

Arg. :(
Can you send me an example data file, so I can reproduce this.
(As small as possible of course.)
-------------- 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-devel/attachments/20041118/64582534/attachment.bin

From jan at intevation.de  Thu Nov 18 12:21:47 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Thu, 18 Nov 2004 12:21:47 +0100
Subject: [Thuban-devel] Re: jan: thuban ChangeLog,1.703,1.704
In-Reply-To: <20041118111946.GB7094@intevation.de>
References: <20041117220835.68B3510016B@lists.intevation.de>
	<20041118111946.GB7094@intevation.de>
Message-ID: <20041118112147.GA16496@intevation.de>

On Thu, Nov 18, 2004 at 12:19:46PM +0100, Bernhard Reiter wrote:
> On Wed, Nov 17, 2004 at 11:08:35PM +0100, cvs at intevation.de wrote:
> > Author: jan
> 
> > Modified Files:
> > 	ChangeLog 
> > Log Message:
> > Another open issue regarding sizeable symbols: correct rendering of
> > selected symbols.
> 
> So: Did you fix it?

yes fixed. Of course.

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

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



From mlennert at club.worldonline.be  Thu Nov 18 12:30:58 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Thu, 18 Nov 2004 12:30:58 +0100 (CET)
Subject: [Thuban-list] svgexport does not export polygon layers
In-Reply-To: <20041118112104.GC7094@intevation.de>
References: <49761.164.15.134.155.1100097741.squirrel@vivegnulinux.homelinux.org>
	<20041115163716.GO26967@intevation.de>
	<32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>
	<20041118112104.GC7094@intevation.de>
Message-ID: <33140.164.15.134.161.1100777458.squirrel@vivegnulinux.homelinux.org>

On Thu, November 18, 2004 12:21, Bernhard Reiter said:
> Hi Moritz,
>
> On Thu, Nov 18, 2004 at 11:01:41AM +0100, Moritz Lennert wrote:
>> On Mon, November 15, 2004 17:37, Bernhard Reiter said:
>> > On Wed, Nov 10, 2004 at 03:42:21PM +0100, Moritz Lennert wrote:
>
>> >> Polygon layers get mentioned in the svg file, but are empty:
>> >>
>> >> <g meta="Layer:Secteurs statistiques" >
>> >> </g>
>> >> <g meta="Layer:Communes" >
>> >> </g>
>> >>
>> >> Does the svg export tool not support polygon layers ?
>> >
>> > It does and it works for me, e.g. on the iceland political layer.
>
>> I've tested with the Iceland data and I can confirm that polygons are
>> exported.
>>
>> But I have tested with several shapefiles used here in the department
>> and
>> none of the polygon layer are exported.
>
>> I have also imported and cleaned a shapefile in GRASS and rexported it
>> with v.out.ogr, but it still is not exported to svg.
>
> Arg. :(
> Can you send me an example data file, so I can reproduce this.
> (As small as possible of course.)

Ok, I found the problem. It is that when a polygon layer has no fill color
(i.e. only boundary lines are visible, the rest of the polygon is
transparent), nothing is exported.

You can reproduce this with the Iceland sample data by setting the fill
color of the political boundaries to transparent.

Moritz



From bernhard at intevation.de  Thu Nov 18 17:19:33 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 18 Nov 2004 17:19:33 +0100
Subject: [Thuban-list] svgexport does not export polygon layers
In-Reply-To: <33140.164.15.134.161.1100777458.squirrel@vivegnulinux.homelinux.org>
References: <49761.164.15.134.155.1100097741.squirrel@vivegnulinux.homelinux.org>
	<20041115163716.GO26967@intevation.de>
	<32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>
	<20041118112104.GC7094@intevation.de>
	<33140.164.15.134.161.1100777458.squirrel@vivegnulinux.homelinux.org>
Message-ID: <20041118161933.GJ16792@intevation.de>

On Thu, Nov 18, 2004 at 12:30:58PM +0100, Moritz Lennert wrote:
> On Thu, November 18, 2004 12:21, Bernhard Reiter said:
> > On Thu, Nov 18, 2004 at 11:01:41AM +0100, Moritz Lennert wrote:
> >> On Mon, November 15, 2004 17:37, Bernhard Reiter said:
> >> > On Wed, Nov 10, 2004 at 03:42:21PM +0100, Moritz Lennert wrote:
> >
> >> >> Polygon layers get mentioned in the svg file, but are empty:
> >> >>
> >> >> <g meta="Layer:Secteurs statistiques" >
> >> >> </g>
> >> >> <g meta="Layer:Communes" >
> >> >> </g>

> Ok, I found the problem. It is that when a polygon layer has no fill color
> (i.e. only boundary lines are visible, the rest of the polygon is
> transparent), nothing is exported.
> 
> You can reproduce this with the Iceland sample data by setting the fill
> color of the political boundaries to transparent.

Cool.
(Care to file a bug report?)
-------------- 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-devel/attachments/20041118/ab332bba/attachment.bin

From thuban-bugs at intevation.de  Thu Nov 18 17:34:00 2004
From: thuban-bugs at intevation.de (Request Tracker)
Date: Thu, 18 Nov 2004 17:34:00 +0100 (CET)
Subject: [bug #2698] (thuban) transparent polygons are not exported to svg
	file
Message-ID: <20041118163400.5068F10016B@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=2698
-------------------------------------------------------------------------

Subject: transparent polygons are not exported to svg file

Operating System: GNU/Linux, debian testing/unstable
Thuban version: CVS, 20041115
wxPython version: other, debian version 2.4.2.6
Python version: other, debian version 2.3.4-13
PySQLite version: other, debian version 0.5.1-3
SQLite version: debian version 2.8.15-2
GDAL version: debian version 1.2.1-1
proj version: debian version 4.4.8-3

Please enter error description here.

When exporting a map to svg, any transparent polygon layer is empty in the resulting svg file. The layer is mentioned in the svg file but no shapes are drawn:

<g meta="Layer:name">
</g>


Did you compile Thuban yourself?

yes via dpkg-buildpackage

-------------------------------------------- Managed by Request Tracker



From mlennert at club.worldonline.be  Thu Nov 18 17:31:39 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Thu, 18 Nov 2004 17:31:39 +0100 (CET)
Subject: [Thuban-list] svgexport does not export polygon layers
In-Reply-To: <20041118161933.GJ16792@intevation.de>
References: <49761.164.15.134.155.1100097741.squirrel@vivegnulinux.homelinux.org>
	<20041115163716.GO26967@intevation.de>
	<32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>
	<20041118112104.GC7094@intevation.de>
	<33140.164.15.134.161.1100777458.squirrel@vivegnulinux.homelinux.org>
	<20041118161933.GJ16792@intevation.de>
Message-ID: <33180.164.15.134.161.1100795499.squirrel@vivegnulinux.homelinux.org>

On Thu, November 18, 2004 17:19, Bernhard Reiter said:
> On Thu, Nov 18, 2004 at 12:30:58PM +0100, Moritz Lennert wrote:
>> On Thu, November 18, 2004 12:21, Bernhard Reiter said:
>> > On Thu, Nov 18, 2004 at 11:01:41AM +0100, Moritz Lennert wrote:
>> >> On Mon, November 15, 2004 17:37, Bernhard Reiter said:
>> >> > On Wed, Nov 10, 2004 at 03:42:21PM +0100, Moritz Lennert wrote:
>> >
>> >> >> Polygon layers get mentioned in the svg file, but are empty:
>> >> >>
>> >> >> <g meta="Layer:Secteurs statistiques" >
>> >> >> </g>
>> >> >> <g meta="Layer:Communes" >
>> >> >> </g>
>
>> Ok, I found the problem. It is that when a polygon layer has no fill
>> color
>> (i.e. only boundary lines are visible, the rest of the polygon is
>> transparent), nothing is exported.
>>
>> You can reproduce this with the Iceland sample data by setting the fill
>> color of the political boundaries to transparent.
>
> Cool.
> (Care to file a bug report?)

done



From cvs at intevation.de  Thu Nov 18 21:17:46 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Thu, 18 Nov 2004 21:17:46 +0100 (CET)
Subject: jan: thuban/Thuban/UI viewport.py,1.18,1.19 
Message-ID: <20041118201746.10040102BCB@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Thuban/UI
In directory doto:/tmp/cvs-serv2214

Modified Files:
	viewport.py 
Log Message:
(ViewPort._hit_point): Added optional parameter
size' defaulting to the previously fixed value 5.
Extended doc-string.
(Viewport._find_shape_in_layer): Resolved FIXME regarding flexibility
for symbols.
Now the size of the largest point symbol is determined to find out
about whether the point has been hit.
This fixes the problem that only clicks inside a fixed distance of
5 where found.


Index: viewport.py
===================================================================
RCS file: /thubanrepository/thuban/Thuban/UI/viewport.py,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -d -r1.18 -r1.19
--- viewport.py	22 Jul 2004 13:07:52 -0000	1.18
+++ viewport.py	18 Nov 2004 20:17:43 -0000	1.19
@@ -1,7 +1,8 @@
-# Copyright (c) 2001, 2002, 2003, 2004 by Intevation GmbH
+# Copyright (c) 2003-2004 by Intevation GmbH
 # Authors:
-# Bernhard Herzog <bh at intevation.de>
-# Frank Koormann <frank at intevation.de>
+# Bernhard Herzog <bh at intevation.de> (2003, 2004)
+# Jonathan Coles <jonathan at intevation.de> (2003)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -11,6 +12,8 @@
 """
 
 __version__ = "$Revision$"
+# $Source$
+# $Id$
 
 from math import hypot
 
@@ -734,14 +737,19 @@
         # around the point. For layers containing points we have to
         # choose a larger size of the box we're testing against so
         # that we take the size of the markers into account
-        # FIXME: Once the markers are more flexible this part has to
-        # become more flexible too, of course
+        # The size of the box is determined by the largest symbol
+        # of the corresponding layer.
+        maxsize = 1
         if layer.ShapeType() == SHAPETYPE_POINT:
-            box = self.unprojected_rect_around_point(px, py, 5)
-        else:
-            box = self.unprojected_rect_around_point(px, py, 1)
+            for group in layer.GetClassification():
+                props = group.GetProperties()
+                if props.GetSize() > maxsize:
+                    maxsize = props.GetSize()
+        box = self.unprojected_rect_around_point(px, py, maxsize)
 
+        # determine the function that does the hit test based on the layer
         hittester = self._get_hit_tester(layer)
+
         for shape in layer.ShapesInRegion(box):
             if field:
                 record = table.ReadRowAsDict(shape.ShapeID())
@@ -749,7 +757,13 @@
                 props = group.GetProperties()
                 filled = props.GetFill() is not Transparent
                 stroked = props.GetLineColor() is not Transparent
-            hit = hittester(layer, shape, filled, stroked, px, py)
+
+            if layer.ShapeType() == SHAPETYPE_POINT:
+                hit = hittester(layer, shape, filled, stroked,
+                                px, py, size = props.GetSize())
+            else:
+                hit = hittester(layer, shape, filled, stroked, px, py)
+
             if hit:
                 return shape.ShapeID()
         return None
@@ -813,14 +827,18 @@
                                    -y * scale + offy))
         return result
 
-    def _hit_point(self, layer, shape, filled, stroked, px, py):
+    def _hit_point(self, layer, shape, filled, stroked, px, py, size = 5):
         """Internal: return whether a click at (px,py) hits the point shape
 
         The filled and stroked parameters determine whether the shape is
         assumed to be filled or stroked respectively.
+
+        size -- defines the size of the point symbol. For the hitting
+                test it is assumed the symbol is a circle of this size
+                (radius).
         """
         x, y = self.projected_points(layer, shape.Points())[0][0]
-        return hypot(px - x, py - y) < 5 and (filled or stroked)
+        return hypot(px - x, py - y) < size and (filled or stroked)
 
     def _hit_arc(self, layer, shape, filled, stroked, px, py):
         """Internal: return whether a click at (px,py) hits the arc shape




From cvs at intevation.de  Thu Nov 18 21:19:06 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Thu, 18 Nov 2004 21:19:06 +0100 (CET)
Subject: jan: thuban ChangeLog,1.704,1.705 
Message-ID: <20041118201906.A6CE9102BCB@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv2244

Modified Files:
	ChangeLog 
Log Message:
Now the hit test considers the size of point symbols.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.704
retrieving revision 1.705
diff -u -d -r1.704 -r1.705
--- ChangeLog	17 Nov 2004 22:08:33 -0000	1.704
+++ ChangeLog	18 Nov 2004 20:19:04 -0000	1.705
@@ -1,6 +1,20 @@
+2004-11-18  Jan-Oliver Wagner <jan at intevation.de>
+
+	Now the hit test considers the size of point symbols.
+
+	* Thuban/UI/viewport.py (ViewPort._hit_point): Added optional parameter
+	'size' defaulting to the previously fixed value 5.
+	Extended doc-string.
+	(Viewport._find_shape_in_layer): Resolved FIXME regarding flexibility
+	for symbols.
+	Now the size of the largest point symbol is determined to find out
+	about whether the point has been hit.
+	This fixes the problem that only clicks inside a fixed distance of
+	5 where found.
+
 2004-11-17  Jan-Oliver Wagner <jan at intevation.de>
 
-	Another open issue regarding sizeable symbols: correct rendering of
+	Another open issue fixed regarding sizeable symbols: correct rendering of
 	selected symbols.
 
 	* Thuban/UI/renderer.py (ScreenRenderer.draw_selection_incrementally):




From jan at intevation.de  Thu Nov 18 21:29:16 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Thu, 18 Nov 2004 21:29:16 +0100
Subject: [Thuban-devel] Status of sizeable points feature
In-Reply-To: <20041105103339.GF29467@intevation.de>
References: <20041007145606.GA1104@intevation.de>
	<20041007155304.GA1451@intevation.de>
	<20041105103339.GF29467@intevation.de>
Message-ID: <20041118202916.GA14509@intevation.de>

On Fri, Nov 05, 2004 at 11:33:39AM +0100, Bernhard Reiter wrote:
> On Thu, Oct 07, 2004 at 05:53:04PM +0200, Jan-Oliver Wagner wrote:
> > On Thu, Oct 07, 2004 at 04:56:06PM +0200, Jan-Oliver Wagner wrote:
> > > The things that remain to be done are (any help welcome):
> 
> > > - Respect the size when doing hit-testing.
> 
> Yes, this really is ugly together with the rendering.

and it is fixed now :-)

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

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



From cvs at intevation.de  Sat Nov 20 13:52:27 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 13:52:27 +0100 (CET)
Subject: jan: thuban/Extensions/svgexport svgsaver.py,1.4,1.5 
Message-ID: <20041120125227.D0A2910015A@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/svgexport
In directory doto:/tmp/cvs-serv3729

Modified Files:
	svgsaver.py 
Log Message:
Moved the menu entry from Extensions
to Experimental menu since this module has yet not reached a stable
status (ie. 1.0).


Index: svgsaver.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/svgsaver.py,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- svgsaver.py	15 Nov 2004 16:27:41 -0000	1.4
+++ svgsaver.py	20 Nov 2004 12:52:25 -0000	1.5
@@ -1,6 +1,9 @@
-# Copyright (c) 2001, 2002, 2003 by Intevation GmbH
+# Copyright (c) 2004 by Intevation GmbH
 # Authors:
-#     Markus Rechtien <markus at intevation.de>
+# Markus Rechtien <markus at intevation.de> (2004)
+# Bernhard Herzog <bh at intevation.de> (2004)
+# Bernhard Reiter <bernhard at intevation.de> (2004)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -96,8 +99,9 @@
 registry.Add(Command('write_to_svg', _('Write SVG Map'), write_to_svg,
                      helptext = _('Export the a map into a SVG file')))
 
-# find the extensions menu (create it anew if not found)
-extensions_menu = main_menu.FindOrInsertMenu('extensions', _('E&xtensions'))
+# find the experimental menu (create it anew if not found)
+experimental_menu = main_menu.FindOrInsertMenu('experimental',
+                                               _('Experimenta&l'))
 
 # finally bind the new command with an entry in the extensions menu
-extensions_menu.InsertItem('write_to_svg')
+experimental_menu.InsertItem('write_to_svg')




From cvs at intevation.de  Sat Nov 20 13:52:52 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 13:52:52 +0100 (CET)
Subject: jan: thuban/Extensions/svgexport __init__.py,1.1,1.2 
Message-ID: <20041120125252.DBD70102BF6@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/svgexport
In directory doto:/tmp/cvs-serv3752

Modified Files:
	__init__.py 
Log Message:
Added registry entry and the importing
of the svgsaver module.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/__init__.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- __init__.py	20 Feb 2004 14:33:11 -0000	1.1
+++ __init__.py	20 Nov 2004 12:52:50 -0000	1.2
@@ -1,6 +1,21 @@
 # Copyright (C) 2004 by Intevation GmbH
 # Authors:
-# Bernhard Herzog <bh at intevation.de>
+# Bernhard Herzog <bh at intevation.de> (2004)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with the software for details.
+
+# import the actual module
+import svgsaver
+
+# perform the registration of the extension
+from Thuban import _
+from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+
+ext_registry.add(ExtensionDesc(
+    name = 'SVGexport',
+    version = '0.9.0',
+    authors= [ 'Markus Rechtien' ],
+    copyright = '2004 Intevation GmbH',
+    desc = _("Export the current map in SVG format.")))




From cvs at intevation.de  Sat Nov 20 13:53:21 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 13:53:21 +0100 (CET)
Subject: jan: thuban/Extensions/bboxdump __init__.py,1.2,1.3 
Message-ID: <20041120125321.50913102BF7@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/bboxdump
In directory doto:/tmp/cvs-serv3766

Modified Files:
	__init__.py 
Log Message:
Added registry entry and the importing
of the actual bboxdump module.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/bboxdump/__init__.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- __init__.py	4 May 2004 17:17:00 -0000	1.2
+++ __init__.py	20 Nov 2004 12:53:19 -0000	1.3
@@ -1,6 +1,22 @@
-# Copyright (c) 2003 by Intevation GmbH
+# Copyright (C) 2004 by Intevation GmbH
 # Authors:
-# Frank Koormann <frank at intevation.de>
+# Frank Koormann <frank at intevation.de> (2004)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
+
+# import the actual module
+import bboxdump
+
+# perform the registration of the extension
+from Thuban import _
+from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+
+ext_registry.add(ExtensionDesc(
+    name = 'bboxdump',
+    version = '1.0.0',
+    authors= [ 'Frank Koormann' ],
+    copyright = '2004 Intevation GmbH',
+    desc = _("Dumps the bounding boxes of all\n" \
+             "shapes of the selected layer.")))




From cvs at intevation.de  Sat Nov 20 13:54:11 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 13:54:11 +0100 (CET)
Subject: jan: thuban/Extensions/bboxdump bboxdump.py,1.4,1.5 
Message-ID: <20041120125411.3F7BC102BFB@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/bboxdump
In directory doto:/tmp/cvs-serv3783

Modified Files:
	bboxdump.py 
Log Message:
Removed registry entry (moved to __init__.py).


Index: bboxdump.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/bboxdump/bboxdump.py,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- bboxdump.py	28 Sep 2004 19:31:05 -0000	1.4
+++ bboxdump.py	20 Nov 2004 12:54:09 -0000	1.5
@@ -1,6 +1,6 @@
-# Copyright (C) 2003-2004 by Intevation GmbH
+# Copyright (C) 2004 by Intevation GmbH
 # Authors:
-# Frank Koormann <frank at intevation.de>
+# Frank Koormann <frank at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -26,19 +26,10 @@
 from Thuban.UI.common import ThubanBeginBusyCursor, ThubanEndBusyCursor
 from Thuban.UI.command import registry, Command
 from Thuban.UI.mainwindow import main_menu, _has_selected_shape_layer
-from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
 from Thuban import _
 
 import shapelib
 import dbflib
-
-ext_registry.add(ExtensionDesc(
-    name = 'bboxdump',
-    version = '1.0.0',
-    authors= [ 'Frank Koormann' ],
-    copyright = '2003-2004 Intevation GmbH',
-    desc = _("Dumps the bounding boxes of all\n" \
-             "shapes of the selected layer.")))
 
 # Widget IDs
 ID_FILENAME = 4001




From cvs at intevation.de  Sat Nov 20 13:54:38 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 13:54:38 +0100 (CET)
Subject: jan: thuban/Extensions/importAPR __init__.py,1.1,1.2 
Message-ID: <20041120125438.94CE0102C01@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/importAPR
In directory doto:/tmp/cvs-serv3798

Modified Files:
	__init__.py 
Log Message:
Added registry entry and the importing
of the actual importAPR module.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/importAPR/__init__.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- __init__.py	22 Sep 2003 10:45:57 -0000	1.1
+++ __init__.py	20 Nov 2004 12:54:36 -0000	1.2
@@ -1,6 +1,21 @@
-# Copyright (c) 2003 by Intevation GmbH
+# Copyright (c) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
+
+# import the actual module
+import importAPR
+
+# perform the registration of the extension
+from Thuban import _
+from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+
+ext_registry.add(ExtensionDesc(
+    name = 'importAPR',
+    version = '0.1.1',
+    authors= [ 'Jan-Oliver Wagner' ],
+    copyright = '2003, 2004 Intevation GmbH',
+    desc = _("Import a ArcView project file (.apr)\n" \
+             "and convert it to Thuban.")))




From cvs at intevation.de  Sat Nov 20 13:55:03 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 13:55:03 +0100 (CET)
Subject: jan: thuban/Extensions/importAPR importAPR.py,1.6,1.7 
Message-ID: <20041120125503.9C4EF102C04@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/importAPR
In directory doto:/tmp/cvs-serv3813

Modified Files:
	importAPR.py 
Log Message:
Removed registry entry (moved to __init__.py).


Index: importAPR.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/importAPR/importAPR.py,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- importAPR.py	3 Oct 2004 22:02:57 -0000	1.6
+++ importAPR.py	20 Nov 2004 12:55:01 -0000	1.7
@@ -1,6 +1,6 @@
 # Copyright (C) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -27,18 +27,9 @@
 from Thuban import _
 from Thuban.Model.layer import Layer
 from Thuban.Model.classification import ClassGroupRange, ClassGroupSingleton
-from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
 
 from odb import ODBBaseObject
 from apr import APR_LClass, APR_TClr, APR_BLnSym, APR_BMkSym, APR_BShSym
-
-ext_registry.add(ExtensionDesc(
-    name = 'importAPR',
-    version = '0.1.1',
-    authors= [ 'Jan-Oliver Wagner' ],
-    copyright = '2003, 2004 Intevation GmbH',
-    desc = _("Import a ArcView project file (.apr)\n" \
-             "and convert it to Thuban.")))
 
 class ODBExtension(Extension):
     def TreeInfo(self):




From cvs at intevation.de  Sat Nov 20 13:55:37 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 13:55:37 +0100 (CET)
Subject: jan: thuban ChangeLog,1.705,1.706 
Message-ID: <20041120125537.9A101102C0A@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv3825

Modified Files:
	ChangeLog 
Log Message:
Changed way of extension registry for importAPR, bboxdump
and added extension registry for svgexport.extension registry for
svgexport.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.705
retrieving revision 1.706
diff -u -d -r1.705 -r1.706
--- ChangeLog	18 Nov 2004 20:19:04 -0000	1.705
+++ ChangeLog	20 Nov 2004 12:55:35 -0000	1.706
@@ -1,3 +1,28 @@
+2004-11-20  Jan-Oliver Wagner <jan at intevation.de>
+
+	Changed way of extension registry for importAPR, bboxdump
+	and added extension registry for svgexport.extension registry for
+	svgexport.
+
+	* Extensions/importAPR/__init__.py: Added registry entry and the importing
+	of the actual importAPR module.
+
+	* Extensions/importAPR/importAPR.py: Removed registry entry (moved to
+	__init__.py).
+
+	* Extensions/bboxdump/__init__.py: Added registry entry and the importing
+	»···of the actual bboxdump module.
+
+	* Extensions/bboxdump/bboxdump.py: Removed registry entry (moved to
+	»···__init__.py).
+
+	* Extensions/svgexport/__init__.py: Added registry entry and the importing
+	of the svgsaver module.
+
+	* Extensions/svgexport/svgsaver.py: Moved the menu entry from Extensions
+	to Experimental menu since this module has yet not reached a stable
+	status (ie. 1.0).
+
 2004-11-18  Jan-Oliver Wagner <jan at intevation.de>
 
 	Now the hit test considers the size of point symbols.




From cvs at intevation.de  Sat Nov 20 22:26:08 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:26:08 +0100 (CET)
Subject: jan: thuban/Extensions/wms __init__.py,1.1,1.2 
Message-ID: <20041120212608.2852D102C0E@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/wms
In directory doto:/tmp/cvs-serv9135

Modified Files:
	__init__.py 
Log Message:
Added registry entry and the importing
of the actual wms module. Included a test for the required PyOGCLib.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/wms/__init__.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- __init__.py	12 Nov 2003 08:14:23 -0000	1.1
+++ __init__.py	20 Nov 2004 21:26:06 -0000	1.2
@@ -1,6 +1,28 @@
-# Copyright (c) 2003 by Intevation GmbH
+# Copyright (c) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
+
+# first try out whether we can import the required module
+# of the PyOGCLib.
+ok = True
+try:
+    import ogclib.WMSClient
+except:
+    print "Problems with PyOGCLib (not installed?)"
+    ok = False
+
+if ok:
+    import wms
+
+    from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+    from Thuban import _
+
+    ext_registry.add(ExtensionDesc(
+        name = 'WMS',
+        version = '0.2.0',
+        authors= [ 'Jan-Oliver Wagner', 'Martin Schulze' ],
+        copyright = '2003, 2004 Intevation GmbH',
+        desc = _("Provide layers via OGC WMS.")))




From cvs at intevation.de  Sat Nov 20 22:26:37 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:26:37 +0100 (CET)
Subject: jan: thuban/Extensions/wms wms.py,1.11,1.12 
Message-ID: <20041120212637.8F26E102C0F@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/wms
In directory doto:/tmp/cvs-serv9159

Modified Files:
	wms.py 
Log Message:
Removed registry entry (moved to __init__.py).


Index: wms.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/wms/wms.py,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- wms.py	1 Oct 2004 17:54:13 -0000	1.11
+++ wms.py	20 Nov 2004 21:26:35 -0000	1.12
@@ -1,6 +1,8 @@
 # Copyright (C) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
+# Bernhard Herzog <bh at intevation.de> (2004)
+# Martin Schulze <joey at infodrom.org> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -31,16 +33,8 @@
 from Thuban.UI.mainwindow import main_menu, layer_properties_dialogs
 from Thuban import _
 import Thuban.UI.baserenderer
-from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
 
 from layer import WMSLayer
-
-ext_registry.add(ExtensionDesc(
-    name = 'WMS',
-    version = '0.1.0',
-    authors= [ 'Jan-Oliver Wagner' ],
-    copyright = '2003, 2004 Intevation GmbH',
-    desc = _("Provide layers via OGC WMS.")))
 
 
 class WMSExtension(Extension):




From cvs at intevation.de  Sat Nov 20 22:27:23 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:27:23 +0100 (CET)
Subject: jan: thuban/Extensions/umn_mapserver __init__.py,1.1,1.2 
Message-ID: <20041120212723.5E304102C10@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/umn_mapserver
In directory doto:/tmp/cvs-serv9173

Modified Files:
	__init__.py 
Log Message:
Added registry entry and the
importing of the actual umn mapserver management modules.
Included a test for the required Python MapScript.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/umn_mapserver/__init__.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- __init__.py	10 Jun 2004 10:36:24 -0000	1.1
+++ __init__.py	20 Nov 2004 21:27:21 -0000	1.2
@@ -1,7 +1,33 @@
 # -*- coding:latin1 -*-
 # Copyright (C) 2004 by Intevation GmbH
 # Authors:
-# Jan Schüngel <jschuengel at intevation.de>
+# Jan Schüngel <jschuengel at intevation.de> (2004)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
+
+# first try out whether we can import the required module
+# of UMN MapServer MapScript.
+ok = True
+try:
+    import mapscript
+except:
+    print "Problems with UMN MapServer MapScript (not installed?)"
+    ok = False
+
+if ok:
+    import mf_import
+    import mf_export
+    import mf_handle
+
+    from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry
+    from Thuban import _
+
+    ext_registry.add(ExtensionDesc(
+        name = 'UMN MapServer Management',
+        version = '1.0.0',
+        authors= [ 'Jan Schüngel' ],
+        copyright = '2004 Intevation GmbH',
+        desc = _("Provide management methods for UMN MapServer\n" \
+                 ".map-files. These can be created/imported/modified.")))




From cvs at intevation.de  Sat Nov 20 22:28:08 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:28:08 +0100 (CET)
Subject: jan: thuban ChangeLog,1.706,1.707 
Message-ID: <20041120212808.C02F1102C11@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv9191

Modified Files:
	ChangeLog 
Log Message:
Changed way of extension registry for wms and added extension
registry for umn_mapserver extension.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.706
retrieving revision 1.707
diff -u -d -r1.706 -r1.707
--- ChangeLog	20 Nov 2004 12:55:35 -0000	1.706
+++ ChangeLog	20 Nov 2004 21:28:06 -0000	1.707
@@ -1,5 +1,19 @@
 2004-11-20  Jan-Oliver Wagner <jan at intevation.de>
 
+	Changed way of extension registry for wms and added extension
+	registry for umn_mapserver extension.
+
+	* Extensions/wms/__init__.py: Added registry entry and the importing
+	of the actual wms module. Included a test for the required PyOGCLib.
+
+	* Extensions/wms/wms.py: Removed registry entry (moved to __init__.py).
+
+	* Extensions/umn_mapserver/__init__.py: Added registry entry and the
+	importing of the actual umn mapserver management modules.
+	Included a test for the required Python MapScript.
+
+2004-11-20  Jan-Oliver Wagner <jan at intevation.de>
+
 	Changed way of extension registry for importAPR, bboxdump
 	and added extension registry for svgexport.extension registry for
 	svgexport.




From jan at intevation.de  Sat Nov 20 22:33:38 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Sat, 20 Nov 2004 22:33:38 +0100
Subject: [Thuban-devel] Re: Revised patch for adding version info for
	Extensions
In-Reply-To: <20040930162512.GC31040@intevation.de>
References: <20040918221128.GB12348@intevation.de>
	<20040925123532.GB6651@intevation.de>
	<20040928200403.GA6764@intevation.de>
	<20040930162512.GC31040@intevation.de>
Message-ID: <20041120213338.GA2445@intevation.de>

On Thu, Sep 30, 2004 at 06:25:12PM +0200, Bernhard Reiter wrote:
> On Tue, Sep 28, 2004 at 10:04:03PM +0200, Jan-Oliver Wagner wrote:
> 
> > Whats' missing is still:
> > - svgexport: Version 1.0.0 I guess?
> 
> There might be a TODO to solve for the legend,
> but I probably work on Skencil first,
> so 
> 	0.9.0
> is not bad until it got more external testers.
> On the other hand 1.0.0 is also okay.
> 
> Do you make the change?
> I would prefer this as you are into that subject. ;)

finally: done (0.9.0). :-)

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

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



From cvs at intevation.de  Sat Nov 20 22:56:13 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:56:13 +0100 (CET)
Subject: jan: thuban/Examples __init__.py,NONE,1.1 
Message-ID: <20041120215613.2247A102C15@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Examples
In directory doto:/tmp/cvs-serv9634

Added Files:
	__init__.py 
Log Message:
Make this directory a package.


--- NEW FILE: __init__.py ---
# Copyright (c) 2004 by Intevation GmbH
# Authors:
# Jan-Oliver Wagner <jan at intevation.de> (2004)
#
# This program is free software under the GPL (>=v2)
# Read the file COPYING coming with Thuban for details.




From cvs at intevation.de  Sat Nov 20 22:56:49 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:56:49 +0100 (CET)
Subject: jan: thuban/Examples/simple_extensions __init__.py,NONE,1.1 
Message-ID: <20041120215649.8DF8E102C16@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Examples/simple_extensions
In directory doto:/tmp/cvs-serv9665

Added Files:
	__init__.py 
Log Message:
Make this directory a package.


--- NEW FILE: __init__.py ---
# Copyright (c) 2004 by Intevation GmbH
# Authors:
# Jan-Oliver Wagner <jan at intevation.de> (2004)
#
# This program is free software under the GPL (>=v2)
# Read the file COPYING coming with Thuban for details.




From cvs at intevation.de  Sat Nov 20 22:57:16 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:57:16 +0100 (CET)
Subject: jan: thuban/Examples/simple_extensions hello_world.py,1.2,1.3 
Message-ID: <20041120215716.DF866102C17@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Examples/simple_extensions
In directory doto:/tmp/cvs-serv9675

Modified Files:
	hello_world.py 
Log Message:
Moved entry from Extensions menu to Examples menu.


Index: hello_world.py
===================================================================
RCS file: /thubanrepository/thuban/Examples/simple_extensions/hello_world.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- hello_world.py	16 May 2004 09:45:05 -0000	1.2
+++ hello_world.py	20 Nov 2004 21:57:14 -0000	1.3
@@ -1,6 +1,6 @@
-# Copyright (C) 2003 by Intevation GmbH
+# Copyright (C) 2003, 2004 by Intevation GmbH
 # Authors:
-# Jan-Oliver Wagner <jan at intevation.de>
+# Jan-Oliver Wagner <jan at intevation.de> (2003, 2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -11,6 +11,8 @@
 """
 
 __version__ = '$Revision$'
+# $Source$
+# $Id$
 
 # use _() already now for all strings that may later be translated
 from Thuban import _
@@ -36,7 +38,7 @@
                      helptext = _('Welcome everyone on this planet')))
 
 # find the extensions menu (create it anew if not found)
-extensions_menu = main_menu.FindOrInsertMenu('extensions', _('E&xtensions'))
+examples_menu = main_menu.FindOrInsertMenu('examples', _('&Examples'))
 
 # finally bind the new command with an entry in the extensions menu
-extensions_menu.InsertItem('hello_world')
+examples_menu.InsertItem('hello_world')




From cvs at intevation.de  Sat Nov 20 22:57:45 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:57:45 +0100 (CET)
Subject: jan: thuban/Examples/simple_extensions simple_command.py,1.2,1.3 
Message-ID: <20041120215745.A4F88102C18@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Examples/simple_extensions
In directory doto:/tmp/cvs-serv9691

Modified Files:
	simple_command.py 
Log Message:
Some more comments, minor changes.


Index: simple_command.py
===================================================================
RCS file: /thubanrepository/thuban/Examples/simple_extensions/simple_command.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- simple_command.py	18 Jul 2002 13:04:06 -0000	1.2
+++ simple_command.py	20 Nov 2004 21:57:43 -0000	1.3
@@ -1,6 +1,7 @@
-# Copyright (C) 2002 by Intevation GmbH
+# Copyright (C) 2002, 2004 by Intevation GmbH
 # Authors:
-# Bernhard Herzog <bh at intevation.de>
+# Bernhard Herzog <bh at intevation.de> (2002)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -10,11 +11,13 @@
 """
 
 __version__ = "$Revision$"
+# $Source$
+# $Id$
 
 # First import some things we need later.
 import os
 from Thuban.UI.command import registry, Command
-import Thuban.UI.mainwindow
+from Thuban.UI.mainwindow import main_menu
 
 # a function implementing a command. Such a function is called with one
 # argument describing the context in which it is invoked. The context is
@@ -40,11 +43,13 @@
 # Thuban.UI.mainwindow. This object has a few methods to add new menus
 # and menu items.
 #
-# InsertMenu creates a new submenu in the menu, parameters are its name
+# FindOrInsertMenu creates a new submenu in the menu, parameters are its name
 # and title which have the same meanings as for a command. The return
 # value is a menu object for the new submenu which has the same methods
 # as main_menu.
-menu = Thuban.UI.mainwindow.main_menu.InsertMenu("examples", "&Examples")
+# If the menu already exist, this previous one will be returned an
+# no new one be created.
+menu = main_menu.FindOrInsertMenu("examples", "&Examples")
 
 # In the new menu we can add new items with InsertItem which takes the
 # name of a command as parameter or with InsertSeparator to add a




From cvs at intevation.de  Sat Nov 20 22:58:20 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:58:20 +0100 (CET)
Subject: jan: thuban/Examples/simple_extensions simple_tool.py,1.5,1.6 
Message-ID: <20041120215820.CE7A0102C19@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Examples/simple_extensions
In directory doto:/tmp/cvs-serv9704

Modified Files:
	simple_tool.py 
Log Message:
Minor changes.


Index: simple_tool.py
===================================================================
RCS file: /thubanrepository/thuban/Examples/simple_extensions/simple_tool.py,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- simple_tool.py	12 Sep 2003 08:32:24 -0000	1.5
+++ simple_tool.py	20 Nov 2004 21:58:18 -0000	1.6
@@ -1,6 +1,7 @@
-# Copyright (C) 2002 by Intevation GmbH
+# Copyright (C) 2002, 2004 by Intevation GmbH
 # Authors:
-# Bernhard Herzog <bh at intevation.de>
+# Bernhard Herzog <bh at intevation.de> (2002)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -10,12 +11,14 @@
 """
 
 __version__ = "$Revision$"
+# $Source$
+# $Id$
 
 # First import some things we need later.
 import os
 from math import hypot
 from Thuban.UI.command import registry, ToolCommand
-import Thuban.UI.mainwindow
+from  Thuban.UI.mainwindow import main_toolbar
 from Thuban.UI.viewport import Tool
 
 
@@ -102,5 +105,5 @@
                          checked = check_simple_tool))
 
 # Add the command to the toolbar
-Thuban.UI.mainwindow.main_toolbar.InsertSeparator()
-Thuban.UI.mainwindow.main_toolbar.InsertItem("simple_tool")
+main_toolbar.InsertSeparator()
+main_toolbar.InsertItem("simple_tool")




From cvs at intevation.de  Sat Nov 20 22:59:01 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 20 Nov 2004 22:59:01 +0100 (CET)
Subject: jan: thuban ChangeLog,1.707,1.708 
Message-ID: <20041120215901.0185D102C23@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv9720

Modified Files:
	ChangeLog 
Log Message:
Some face lifting for the examples.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.707
retrieving revision 1.708
diff -u -d -r1.707 -r1.708
--- ChangeLog	20 Nov 2004 21:28:06 -0000	1.707
+++ ChangeLog	20 Nov 2004 21:58:58 -0000	1.708
@@ -1,5 +1,21 @@
 2004-11-20  Jan-Oliver Wagner <jan at intevation.de>
 
+	Some face lifting for the examples.
+
+	* Examples/__init__.py: Make this directory a package.
+
+	* Examples/simple_extensions/__init__.py: Make this directory a package.
+
+	* Examples/simple_extensions/hello_world.py: Moved entry from Extensions
+	menu to Examples menu.
+
+	* Examples/simple_extensions/simple_command.py: Some more comments,
+	minor changes.
+
+	* Examples/simple_extensions/simple_tool.py: Minor changes.
+
+2004-11-20  Jan-Oliver Wagner <jan at intevation.de>
+
 	Changed way of extension registry for wms and added extension
 	registry for umn_mapserver extension.
 




From bernhard at intevation.de  Mon Nov 22 11:10:34 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Nov 2004 11:10:34 +0100
Subject: [Thuban-devel] Re: Revised patch for adding version info for
	Extensions
In-Reply-To: <20041120213338.GA2445@intevation.de>
References: <20040918221128.GB12348@intevation.de>
	<20040925123532.GB6651@intevation.de>
	<20040928200403.GA6764@intevation.de>
	<20040930162512.GC31040@intevation.de>
	<20041120213338.GA2445@intevation.de>
Message-ID: <20041122101034.GA9475@intevation.de>

On Sat, Nov 20, 2004 at 10:33:38PM +0100, Jan-Oliver Wagner wrote:
> On Thu, Sep 30, 2004 at 06:25:12PM +0200, Bernhard Reiter wrote:
> > On Tue, Sep 28, 2004 at 10:04:03PM +0200, Jan-Oliver Wagner wrote:
> > 
> > > Whats' missing is still:
> > > - svgexport: Version 1.0.0 I guess?

> > 	0.9.0

> > Do you make the change?
> > I would prefer this as you are into that subject. ;)
> 
> finally: done (0.9.0). :-)

Thanks!
Unfortunately one of the two menu entries jumped to Experimental now.
They both should display unter Extensions.

	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-devel/attachments/20041122/8e57286c/attachment.bin

From bernhard at intevation.de  Mon Nov 22 11:12:10 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Nov 2004 11:12:10 +0100
Subject: jan: thuban/Extensions/svgexport svgsaver.py,1.4,1.5
In-Reply-To: <20041120125227.D0A2910015A@lists.intevation.de>
References: <20041120125227.D0A2910015A@lists.intevation.de>
Message-ID: <20041122101210.GB9475@intevation.de>

On Sat, Nov 20, 2004 at 01:52:27PM +0100, cvs at intevation.de wrote:
> Modified Files:
> 	svgsaver.py 
> Log Message:
> Moved the menu entry from Extensions
> to Experimental menu since this module has yet not reached a stable
> status (ie. 1.0).

You only moved one of the two menu entries
and I prefer to have them in Extensions.
-------------- 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-devel/attachments/20041122/f2485eda/attachment.bin

From bernhard at intevation.de  Mon Nov 22 11:14:15 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Nov 2004 11:14:15 +0100
Subject: __init__.py using for Registration
In-Reply-To: <20041120125537.9A101102C0A@lists.intevation.de>
References: <20041120125537.9A101102C0A@lists.intevation.de>
Message-ID: <20041122101415.GC9475@intevation.de>

On Sat, Nov 20, 2004 at 01:55:37PM +0100, cvs at intevation.de wrote:
> Modified Files:
> 	ChangeLog 
> Log Message:
> Changed way of extension registry for importAPR, bboxdump
> and added extension registry for svgexport.extension registry for
> svgexport.

These changes break running tests in the Extensions submodules,
because they always import wxGTK (as far as I can see).
I saw the problem with tests in svgexport (which are running
together will all tests, so all tests are broken now!!)
and with the test in gns2shp.


-------------- 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-devel/attachments/20041122/cb9d3df6/attachment.bin

From cvs at intevation.de  Mon Nov 22 12:16:37 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Mon, 22 Nov 2004 12:16:37 +0100 (CET)
Subject: bernhard: thuban/Thuban/UI baserenderer.py,1.12,1.13 
Message-ID: <20041122111637.999DF102C3A@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban/Thuban/UI
In directory doto:/tmp/cvs-serv8365/UI

Modified Files:
	baserenderer.py 
Log Message:
* Thuban/Model/base.py (UnsetModified):
Fixed some typos in docstring.

* Thuban/UI/baserenderer.py (BaseRenderer.draw_polygon_shape()):
Added hints on the used algorithm for handling holes.


Index: baserenderer.py
===================================================================
RCS file: /thubanrepository/thuban/Thuban/UI/baserenderer.py,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- baserenderer.py	3 Oct 2004 21:45:48 -0000	1.12
+++ baserenderer.py	22 Nov 2004 11:16:35 -0000	1.13
@@ -388,6 +388,8 @@
         value of the shape's Points() method. The coordinates in the
         DC's coordinate system are determined with
         self.projected_points.
+
+        For a description of the algorithm look in wxproj.cpp.
         """
         points = self.projected_points(layer, points)
 
@@ -396,6 +398,7 @@
             for part in points:
                 polygon.extend(part)
 
+            # missing back vertices for correct filling.
             insert_index = len(polygon)
             for part in points[:-1]:
                 polygon.insert(insert_index, part[0])




From cvs at intevation.de  Mon Nov 22 12:16:37 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Mon, 22 Nov 2004 12:16:37 +0100 (CET)
Subject: bernhard: thuban/Thuban/Model base.py,1.7,1.8 
Message-ID: <20041122111637.96C07102C37@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban/Thuban/Model
In directory doto:/tmp/cvs-serv8365/Model

Modified Files:
	base.py 
Log Message:
* Thuban/Model/base.py (UnsetModified):
Fixed some typos in docstring.

* Thuban/UI/baserenderer.py (BaseRenderer.draw_polygon_shape()):
Added hints on the used algorithm for handling holes.


Index: base.py
===================================================================
RCS file: /thubanrepository/thuban/Thuban/Model/base.py,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- base.py	20 Sep 2004 08:13:00 -0000	1.7
+++ base.py	22 Nov 2004 11:16:35 -0000	1.8
@@ -50,7 +50,7 @@
     def UnsetModified(self):
         """Unset the modified flag.
 
-        If the modified flag is changed from set to inset by he call,
+        If the modified flag is changed from set to unset by the call,
         issue a CHANGED message.
 
         The modified flag itself is part of the state of the object so




From cvs at intevation.de  Mon Nov 22 12:17:49 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Mon, 22 Nov 2004 12:17:49 +0100 (CET)
Subject: bernhard: thuban/Extensions/svgexport svgmapwriter.py,1.6,1.7 
Message-ID: <20041122111749.3E054102C3E@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban/Extensions/svgexport
In directory doto:/tmp/cvs-serv8413/Extensions/svgexport

Modified Files:
	svgmapwriter.py 
Log Message:
Fixing #2698 (transparent polygons are not exported to svg file)

	* Extensions/svgexport/svgmapwriter.py:
	Added verbose variable and some logging depending on it.
	(class VirtualDC(XMLWriter)): Minor improvement in the polygon loop, 
	because counting i is not necessary.
	(class Pen, class Brush): Added simple __str__ methods.
	(SVGRenderer.draw_polygone_shape): Fix #2698 (transparent polygons are
	not exported to svg file) Note: holes still unhandled.

	* Extensions/svgexport/test/test_svgmapwriter.py:
	        Made a baseclass TestWithDC for test needed a DC.
		Added tests for bug #2698 (transparent polygons are not
		exported to svg file):
		Testobjectexport.test_transparent_polygon()


Index: svgmapwriter.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/svgmapwriter.py,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- svgmapwriter.py	15 Nov 2004 16:27:41 -0000	1.6
+++ svgmapwriter.py	22 Nov 2004 11:17:47 -0000	1.7
@@ -19,6 +19,11 @@
 # $Source$
 # $Id$
 
+import sys
+
+# Verboseness level for debugging.
+verbose=0
+log=sys.stdout.write
 
 # Regular expressions used with Fontnames
 import re
@@ -88,6 +93,11 @@
         self.dashes = pdashes
         self.join = 'round' 
         self.cap = 'round'
+
+    def __str__(self):
+        return "Pen(%s,%s,%s,%s,%s)" % \
+            (str(self.color), str(self.width), str(self.dashes), 
+             str(self.join), str(self.cap))
     
     def GetColor(self):
         return self.color
@@ -112,10 +122,13 @@
         """Init the brush with the given values."""
         self.fill = bfill
         self.pattern = bpattern
-    
+
+    def __str__(self):
+        return "Brush(" + str(self.fill) + "," + str(self.pattern) + ")"
+
     def GetColor(self):
         return self.fill
-    
+
     def GetPattern(self):
         return self.pattern
 
@@ -200,11 +213,17 @@
         """
         points = self.projected_points(layer, points)
 
-        if brush is not TRANSPARENT_BRUSH:
-            self.dc.SetBrush(brush)
-            self.dc.SetPen(pen)
-            for part in points:
-                self.dc.DrawLines(part)
+        if verbose > 1:
+            log("drawing polygon with brush %s and pen %s\n" % 
+                (str(brush), str(pen)) )
+
+        self.dc.SetBrush(brush)
+        self.dc.SetPen(pen)
+        # FIXME: understand what BaseRenderer.draw_polygon_shape does
+        #        so complicated here and fix it here, too.
+        #        Maybe that is handling of holes?
+        for parts in points:
+            self.dc.DrawPolygon(parts,closed=1)
     
     def draw_point_shape(self, layer, points, pen, brush):
         """Draw a point shape from layer with the given brush and pen
@@ -248,6 +267,8 @@
             # faster since we don't need the attribute information at
             # all.
             field = None
+            if verbose > 0: 
+                log("layer %s has no classification\n" % layer.Title())
 
         # Determine which render function to use.
         useraw, draw_func, draw_func_param = \
@@ -274,11 +295,11 @@
 
             if not group.IsVisible():
                 continue
-            
+
             # Render classification
             shapeType = layer.ShapeType()
             props = group.GetProperties()
-            
+
             # put meta infos into DC
             if field and value:
                 dc.SetMeta({field:value, })
@@ -295,6 +316,7 @@
                 data = shape.RawData()
             else:
                 data = shape.Points()
+            if verbose > 0 : log("Using draw_func %s\n"%(repr(draw_func)))
             draw_func(draw_func_param, data, pen, brush)
             # compatibility
             if 0:
@@ -668,9 +690,9 @@
         for point in polygon:
             if i is 0:
                 data.append('M %s %s ' % (point.x, point.y))
+                i+=1
             else:
                 data.append('L %s %s ' % (point.x, point.y))
-            i+=1
         # FIXME: Determine if path is closed
         if closed:
             data.append('Z')




From cvs at intevation.de  Mon Nov 22 12:17:49 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Mon, 22 Nov 2004 12:17:49 +0100 (CET)
Subject: bernhard: thuban ChangeLog,1.708,1.709 
Message-ID: <20041122111749.39097102C3A@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv8413

Modified Files:
	ChangeLog 
Log Message:
Fixing #2698 (transparent polygons are not exported to svg file)

	* Extensions/svgexport/svgmapwriter.py:
	Added verbose variable and some logging depending on it.
	(class VirtualDC(XMLWriter)): Minor improvement in the polygon loop, 
	because counting i is not necessary.
	(class Pen, class Brush): Added simple __str__ methods.
	(SVGRenderer.draw_polygone_shape): Fix #2698 (transparent polygons are
	not exported to svg file) Note: holes still unhandled.

	* Extensions/svgexport/test/test_svgmapwriter.py:
	        Made a baseclass TestWithDC for test needed a DC.
		Added tests for bug #2698 (transparent polygons are not
		exported to svg file):
		Testobjectexport.test_transparent_polygon()


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.708
retrieving revision 1.709
diff -u -d -r1.708 -r1.709
--- ChangeLog	20 Nov 2004 21:58:58 -0000	1.708
+++ ChangeLog	22 Nov 2004 11:17:47 -0000	1.709
@@ -1,3 +1,25 @@
+2004-11-22  Bernhard Reiter <bernhard at intevation.de>
+
+	* Extensions/svgexport/svgmapwriter.py:
+	Added verbose variable and some logging depending on it.
+	(class VirtualDC(XMLWriter)): Minor improvement in the polygon loop, 
+	because counting i is not necessary.
+	(class Pen, class Brush): Added simple __str__ methods.
+	(SVGRenderer.draw_polygone_shape): Fix #2698 (transparent polygons are
+	not exported to svg file) Note: holes still unhandled.
+
+	* Extensions/svgexport/test/test_svgmapwriter.py:
+	        Made a baseclass TestWithDC for test needed a DC.
+		Added tests for bug #2698 (transparent polygons are not
+		exported to svg file):
+		Testobjectexport.test_transparent_polygon()
+
+	* Thuban/Model/base.py (UnsetModified):
+	Fixed some typos in docstring.
+
+	* Thuban/UI/baserenderer.py (BaseRenderer.draw_polygon_shape()):
+	Added hints on the used algorithm for handling holes.
+
 2004-11-20  Jan-Oliver Wagner <jan at intevation.de>
 
 	Some face lifting for the examples.




From cvs at intevation.de  Mon Nov 22 12:17:49 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Mon, 22 Nov 2004 12:17:49 +0100 (CET)
Subject: bernhard: thuban/Extensions/svgexport/test test_svgmapwriter.py, 1.5,
	1.6 
Message-ID: <20041122111749.42FB5102C3F@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban/Extensions/svgexport/test
In directory doto:/tmp/cvs-serv8413/Extensions/svgexport/test

Modified Files:
	test_svgmapwriter.py 
Log Message:
Fixing #2698 (transparent polygons are not exported to svg file)

	* Extensions/svgexport/svgmapwriter.py:
	Added verbose variable and some logging depending on it.
	(class VirtualDC(XMLWriter)): Minor improvement in the polygon loop, 
	because counting i is not necessary.
	(class Pen, class Brush): Added simple __str__ methods.
	(SVGRenderer.draw_polygone_shape): Fix #2698 (transparent polygons are
	not exported to svg file) Note: holes still unhandled.

	* Extensions/svgexport/test/test_svgmapwriter.py:
	        Made a baseclass TestWithDC for test needed a DC.
		Added tests for bug #2698 (transparent polygons are not
		exported to svg file):
		Testobjectexport.test_transparent_polygon()


Index: test_svgmapwriter.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/test/test_svgmapwriter.py,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- test_svgmapwriter.py	27 Sep 2004 09:56:13 -0000	1.5
+++ test_svgmapwriter.py	22 Nov 2004 11:17:47 -0000	1.6
@@ -34,9 +34,9 @@
      Pen, Brush, SOLID,  Point, Font, TRANSPARENT_PEN, TRANSPARENT_BRUSH, \
      SVGRenderer, SVGMapWriterError
 # Color related classes from the model of thuban
-from Thuban.Model.color import Color, Black
+from Thuban.Model.color import Color, Black, Transparent
 
-from Thuban.Model.data import SHAPETYPE_ARC
+from Thuban.Model.data import SHAPETYPE_ARC, SHAPETYPE_POLYGON
 from Thuban.Model.map import Map
 from Thuban.Model.layer import BaseLayer, Layer
 from Thuban.Model.table import MemoryTable, \
@@ -102,6 +102,21 @@
         dc.DrawPolygon(self.polygon, 0)
         self.assertEquals(xmlsupport.sax_eventlist(data = data), 
                           xmlsupport.sax_eventlist(data = file.getvalue()))
+
+    def test_transparent_polygon(self):
+        '''Test dc drawing a transparent polygon.'''
+        data = ('<path style="stroke-linejoin:round; stroke:#ff00ff; '
+                'stroke-width:3; stroke-linecap:round; fill:none" ' 
+                'meta="Object:test; Label:nothing" d="M 5.6 5.5 '
+                'L 95.4 5.3 L 95.2 95.1 L 5.0 95.0 L 5.0 5.0 "/>')
+        file = StringIO.StringIO()
+        dc = VirtualDC(file)
+        dc.SetPen(self.solid_pen)
+        dc.SetMeta(self.meta)
+        dc.SetBrush(self.trans_brush)
+        dc.DrawPolygon(self.polygon, 0)
+        self.assertEquals(xmlsupport.sax_eventlist(data = data), 
+                          xmlsupport.sax_eventlist(data = file.getvalue()))
     
     def test_rect(self):
         '''Set drawing properties and draw a rectangle'''
@@ -168,7 +183,11 @@
         self.assertEquals(xmlsupport.sax_eventlist(data = data), 
                           xmlsupport.sax_eventlist(data = file.getvalue()))
 
-class TestSVGRendererIDHandling(unittest.TestCase):
+class TestWithDC(unittest.TestCase):
+    """Add dc creation and self.to_destroy list to setUp() and tearDown().
+
+    This is a baseclass for test needing a dc.
+    """
 
     def setUp(self):
         """Create dc for testing and set up self.to_destroy.
@@ -186,6 +205,8 @@
         for obj in self.to_destroy:
             obj.Destroy()
 
+class TestSVGRendererIDHandling(TestWithDC):
+
     def test_make_id_nonintegersetid(self):
         """Test that exception is raised when SetID was called with chars."""
         dc=self.dc
@@ -276,6 +297,42 @@
 
         self.assertRaises(SVGMapWriterError,
                 renderer.RenderMap, None, None)
+
+class Testobjectexport(TestWithDC):
+
+    def test_transparent_polygon(self):
+        """ Create layer with non-filled polygon and test svg rendering."""
+
+        data = ('<clipPath id="mapclip">\n'
+                '    <rect x="0" y="0" width="10" height="10"   />\n'
+                '</clipPath>\n'
+                '<g meta="Object:map"  clip-path="url(#mapclip)" '
+                'clip-rule="evenodd" transform=" scale(100.0)">\n'
+                '    <g meta="Layer:P-Layer" >\n'
+                '        <path style="stroke-linejoin:round; stroke:#000000; '
+                'stroke-width:0.01; stroke-linecap:round; fill:none" '
+                'id="P-Layer_0"'
+                '  d="M 0.0 0.0 L 10.0 -10.0 L 0.0 -10.0 L 0.0 0.0 Z"/>\n'
+                '    </g>\n</g>\n')
+        table = MemoryTable([("type", FIELDTYPE_STRING),
+                             ("value", FIELDTYPE_DOUBLE),
+                             ("code", FIELDTYPE_INT)],
+                            [("UNKNOWN", 0.0, 0)])
+        shapes = [[[(0, 0), (10, 10), (0, 10), (0, 0) ]]]
+        store = SimpleShapeStore(SHAPETYPE_POLYGON, shapes, table)
+
+        map = Map("testpolygonexport")
+        self.to_destroy.append(map)
+        layer=Layer("P-Layer", store, fill=Transparent)
+        map.AddLayer(layer)
+
+        renderer = SVGRenderer(self.dc, map,
+                    scale=1.0, offset=(0,0), region=(0,0,10,10))
+        renderer.RenderMap(None, None)
+        print (data)
+        print (self.dc.file.getvalue())
+        self.assertEquals(data, self.dc.file.getvalue())
+
 
 if __name__ == "__main__":
     support.run_tests()




From bernhard at intevation.de  Mon Nov 22 12:22:10 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Nov 2004 12:22:10 +0100
Subject: [Thuban-list] svgexport does not export polygon layers
In-Reply-To: <33180.164.15.134.161.1100795499.squirrel@vivegnulinux.homelinux.org>
References: <49761.164.15.134.155.1100097741.squirrel@vivegnulinux.homelinux.org>
	<20041115163716.GO26967@intevation.de>
	<32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>
	<20041118112104.GC7094@intevation.de>
	<33140.164.15.134.161.1100777458.squirrel@vivegnulinux.homelinux.org>
	<20041118161933.GJ16792@intevation.de>
	<33180.164.15.134.161.1100795499.squirrel@vivegnulinux.homelinux.org>
Message-ID: <20041122112210.GD9475@intevation.de>

On Thu, Nov 18, 2004 at 05:31:39PM +0100, Moritz Lennert wrote:
> On Thu, November 18, 2004 17:19, Bernhard Reiter said:
> > On Thu, Nov 18, 2004 at 12:30:58PM +0100, Moritz Lennert wrote:
> >> On Thu, November 18, 2004 12:21, Bernhard Reiter said:
> >> > On Thu, Nov 18, 2004 at 11:01:41AM +0100, Moritz Lennert wrote:

> >> Ok, I found the problem. It is that when a polygon layer has no fill
> >> color

> > (Care to file a bug report?)
> 
> done

Just fixed this in CVS.
Let me know if this work for you.

Holes in polygons are still unhandled by SVG export.

Bernhard
ps.: Because of Jan's commits CVS is currently broken, you cannot run tests.
-------------- 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-devel/attachments/20041122/67d24266/attachment.bin

From jan at intevation.de  Mon Nov 22 12:44:27 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Mon, 22 Nov 2004 12:44:27 +0100
Subject: [Thuban-devel] Re: jan: thuban/Extensions/svgexport svgsaver.py,
	1.4, 1.5
In-Reply-To: <20041122101210.GB9475@intevation.de>
References: <20041120125227.D0A2910015A@lists.intevation.de>
	<20041122101210.GB9475@intevation.de>
Message-ID: <20041122114427.GA23081@intevation.de>

On Mon, Nov 22, 2004 at 11:12:10AM +0100, Bernhard Reiter wrote:
> On Sat, Nov 20, 2004 at 01:52:27PM +0100, cvs at intevation.de wrote:
> > Modified Files:
> > 	svgsaver.py 
> > Log Message:
> > Moved the menu entry from Extensions
> > to Experimental menu since this module has yet not reached a stable
> > status (ie. 1.0).
> 
> You only moved one of the two menu entries
> and I prefer to have them in Extensions.

I prepared a patch to put the legend to Experimental too.
I am in favor of clearly distinguishing between stable
and unstable/incomplete extensions.
If you think you reached 1.0, I'll change all
to Extensions immediately ;-)

	Jan

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

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



From bernhard at intevation.de  Mon Nov 22 17:12:15 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Nov 2004 17:12:15 +0100
Subject: [Thuban-devel] Re: jan: thuban/Extensions/svgexport svgsaver.py,
	1.4, 1.5
In-Reply-To: <20041122114427.GA23081@intevation.de>
References: <20041120125227.D0A2910015A@lists.intevation.de>
	<20041122101210.GB9475@intevation.de>
	<20041122114427.GA23081@intevation.de>
Message-ID: <20041122161215.GI5941@intevation.de>

On Mon, Nov 22, 2004 at 12:44:27PM +0100, Jan-Oliver Wagner wrote:
> On Mon, Nov 22, 2004 at 11:12:10AM +0100, Bernhard Reiter wrote:
> > On Sat, Nov 20, 2004 at 01:52:27PM +0100, cvs at intevation.de wrote:
> > > Modified Files:
> > > 	svgsaver.py 
> > > Log Message:
> > > Moved the menu entry from Extensions
> > > to Experimental menu since this module has yet not reached a stable
> > > status (ie. 1.0).
> > 
> > You only moved one of the two menu entries
> > and I prefer to have them in Extensions.
> 
> I prepared a patch to put the legend to Experimental too.
> I am in favor of clearly distinguishing between stable
> and unstable/incomplete extensions.
> If you think you reached 1.0, I'll change all
> to Extensions immediately ;-)

It is not experimental anymore, but also not 1.0.
I think it is best placed as Extension and in 0.9.
-------------- 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-devel/attachments/20041122/fc5e975e/attachment.bin

From bernhard at intevation.de  Wed Nov 24 17:21:31 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 24 Nov 2004 17:21:31 +0100
Subject: CVS fixing: Reverting?
Message-ID: <20041124162131.GC12394@intevation.de>

Hi Jan,

what about reverting the changes you have made until tests work
again in CVS so we get a state we can develop at the other parts.

	Bernhard



From mlennert at club.worldonline.be  Wed Nov 24 19:11:54 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed, 24 Nov 2004 19:11:54 +0100 (CET)
Subject: [Thuban-list] svgexport does not export polygon layers
In-Reply-To: <20041122112210.GD9475@intevation.de>
References: <49761.164.15.134.155.1100097741.squirrel@vivegnulinux.homelinux.org>
	<20041115163716.GO26967@intevation.de>
	<32940.164.15.134.161.1100772101.squirrel@vivegnulinux.homelinux.org>
	<20041118112104.GC7094@intevation.de>
	<33140.164.15.134.161.1100777458.squirrel@vivegnulinux.homelinux.org>
	<20041118161933.GJ16792@intevation.de>
	<33180.164.15.134.161.1100795499.squirrel@vivegnulinux.homelinux.org>
	<20041122112210.GD9475@intevation.de>
Message-ID: <34142.164.15.134.161.1101319914.squirrel@vivegnulinux.homelinux.org>

On Mon, November 22, 2004 12:22, Bernhard Reiter said:
> On Thu, Nov 18, 2004 at 05:31:39PM +0100, Moritz Lennert wrote:
>> On Thu, November 18, 2004 17:19, Bernhard Reiter said:
>> > On Thu, Nov 18, 2004 at 12:30:58PM +0100, Moritz Lennert wrote:
>> >> On Thu, November 18, 2004 12:21, Bernhard Reiter said:
>> >> > On Thu, Nov 18, 2004 at 11:01:41AM +0100, Moritz Lennert wrote:
>
>> >> Ok, I found the problem. It is that when a polygon layer has no fill
>> >> color
>
>> > (Care to file a bug report?)
>>
>> done
>
> Just fixed this in CVS.
> Let me know if this work for you.
>

Yes, it seems to work. Thank you !

Moritz



From jan at intevation.de  Wed Nov 24 22:49:26 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Wed, 24 Nov 2004 22:49:26 +0100
Subject: Base class for Shapes?
Message-ID: <20041124214926.GA30763@intevation.de>

Hi,

on a train travel from Bonn to Osnabr?ck
I worked out an idea about a Base Shape Class.
See the attached patch.

The idea is that we might want to have Shapes/Shapestores
that are kept in memory instead in a file in order
have a opportunity to create/modify them with arbitrary
algorithms implemented in Thuban(or in its extensions).

The idea is taken from a large Thuban Extension on precision
farming developed by Ole Rahn.

This class "Shape" would also be a first step to redruce
the code in that extension. Ongoing steps would be to introduce
a MemoryShapeStore with ability to store it as a Shapefile.

What I want to know is whether this idea is a sensible way to
go or not. Any feedback welcome.

Ah, and: this can even be ported back to 1_0 ;-)

Best

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

Intevation GmbH                      http://intevation.de/
FreeGIS                                http://freegis.org/
-------------- next part --------------
Index: Thuban/Model/data.py
===================================================================
RCS file: /home/thuban/jail/thubanrepository/thuban/Thuban/Model/data.py,v
retrieving revision 1.15
diff -u -3 -p -r1.15 data.py
--- Thuban/Model/data.py	24 Nov 2003 19:23:08 -0000	1.15
+++ Thuban/Model/data.py	24 Nov 2004 21:43:02 -0000
@@ -48,8 +48,114 @@ RAW_SHAPEFILE = "RAW_SHAPEFILE"
 # Raw data in well-known text format
 RAW_WKT = "RAW_WKT"
 
+class Shape:
 
-class ShapefileShape:
+    """Base class (Interface) for representing a single Shape.
+    """
+
+    def __init__(self):
+    	"""Initialize this shape.
+	"""
+	self.shapeid = None
+	self.bbox = None
+	self.points = []
+
+    def ShapeID(self):
+        """Return the unique ID of this shape or None if there is none
+	available.
+        """
+        return self.shapeid
+
+    def setShapeID(self, id):
+        """Set the ID of this shape.
+
+	id -- The unique ID of the shape or None if it hasn't one.
+        """
+        self.shapeid = id
+
+    def BBox(self):
+    	"""Return the bounding box of this shape.
+
+	If it has yet not been computed, this will be done
+	now and the bbox be stored for later use without
+	computation.
+
+	Returns: Bounding box as tuple (minx, miny, maxx, maxy).
+	"""
+	if self.bbox is None:
+            xs = []
+            ys = []
+            for part in self.Points():
+                for x, y in part:
+                    xs.append(x)
+                    ys.append(y)
+            if len(xs): # there must be at least one vertix
+                self.bbox = (min(xs), min(ys), max(xs), max(ys))
+	return self.bbox
+
+    def Points(self):
+        """Return the coordinates of the shape as a list (parts)
+	of lists (sequences) of coordinate pairs.
+        E.g.: [[(x0,y0),(x1,y1),(x2,y2)]]
+
+	Classes inheriting from Shape should overwrite this
+	method.
+	"""
+        return self.points
+
+    def setPoints(self, points):
+        """Set the points for this shape. Also, the bounding box is
+	reset and will be computed anew when used next time.
+
+	points -- a list (parts) of a list (sequences) of coordinate
+	          pairs, e.g.  [ [ (x0,y0),(x1,y1) ] ]
+	"""
+        self.points = points
+	self.bbox = None
+
+    def isInBBox(self, bbox):
+    	"""Test whether the the shape lies completely within the
+	given bounding box.
+
+	bbox -- the bounding box as tuple (minx,miny,max,maxy)
+
+	Returns: True if the shape lies within bbox, else False
+	"""
+        bb_minX, bb_minY, bb_maxX, bb_maxY = bbox
+        minX, minY, maxX, maxY = self.BBox()
+
+        if minX >= bb_minX and maxX <= bb_maxX and \
+	   minY >= bb_minY and maxY <= bb_maxY:
+            return True
+
+        return False
+
+    def __str__(self):
+        return "Shape " + repr(self.shapeid) + ": " + repr(self.points)
+
+#    def intersectsBBox(self, bbox):
+#    	"""Test whether the the shape intersects the given bounding box.
+#	In other words, tests whether at least one point of the shape
+#	lies within the given bounding box.
+#
+#	bbox -- the bounding box as tuple (minx,miny,max,maxy)
+#
+#	Returns: True if at least one point of the shape lies within
+#	         bbox, else False
+#	"""
+#        bb_minX, bb_minY, bb_maxX, bb_maxY = bbox
+#        minX, minY, maxX, maxY = self.BBox()
+#
+#	# test each single point whether it is inside the given bbox
+#        for part in self.Points():
+#            for x, y in part:
+#            if (x >= bb_minX and x <= bb_maxX) and
+#	       (y >= bb_minY and y <= bb_maxY):
+#                return True
+#
+#        return False
+
+class ShapefileShape(Shape):
 
     """Represent one shape of a shapefile"""
 
@@ -60,17 +166,13 @@ class ShapefileShape:
     def compute_bbox(self):
         """
         Return the bounding box of the shape as a tuple (minx,miny,maxx,maxy)
-        """
-        xs = []
-        ys = []
-        for part in self.Points():
-            for x, y in part:
-                xs.append(x)
-                ys.append(y)
-        return (min(xs), min(ys), max(xs), max(ys))
 
-    def ShapeID(self):
-        return self.shapeid
+	This method is deprecated since 2004-11-23.
+	Use BBox() instead.
+        """
+	print "compute_bbox():This method is deprecated since 2004-11-23."
+	print "Use BBox() instead."
+	return self.BBox()
 
     def Points(self):
         """Return the coordinates of the shape as a list of lists of pairs"""
@@ -81,7 +183,9 @@ class ShapefileShape:
         return points
 
     def RawData(self):
-        """Return the shape id to use with the shapefile"""
+        """Return the shape id to use with the shapefile.
+	
+	XXX: What is the difference to ShapeID()?"""
         return self.shapeid
 
     def Shapefile(self):

From cvs at intevation.de  Wed Nov 24 23:21:30 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Wed, 24 Nov 2004 23:21:30 +0100 (CET)
Subject: jan: thuban/Extensions/svgexport/test test_svgmapwriter.py, 1.6,
	1.7 
Message-ID: <20041124222130.4E2A5100164@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/svgexport/test
In directory doto:/tmp/cvs-serv27462

Modified Files:
	test_svgmapwriter.py 
Log Message:
Fixes to have the test run correctly even if the extension is a package.
Also removed the "import Thuban" which makes no sense.


Index: test_svgmapwriter.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/test/test_svgmapwriter.py,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- test_svgmapwriter.py	22 Nov 2004 11:17:47 -0000	1.6
+++ test_svgmapwriter.py	24 Nov 2004 22:21:28 -0000	1.7
@@ -1,7 +1,8 @@
-# Copyright (c) 2001, 2002, 2003, 2004 by Intevation GmbH
+# Copyright (c) 2004 by Intevation GmbH
 # Authors:
-#     Markus Rechtien <markus at intevation.de>
-#     Bernhard Reiter <bernhard at intevation.de>
+# Markus Rechtien <markus at intevation.de> (2004)
+# Bernhard Reiter <bernhard at intevation.de> (2004)
+# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.
@@ -19,18 +20,20 @@
 import StringIO
 import unittest
 
-# If run directly as a script, add Thuban's test directory to the path.
-# Otherwise we assume that the importing code as already done it
+# If run directly as a script, add Thuban's test directory to the path
+# as well as the extensions own directory (i.e. parent).
+# Otherwise we assume that the importing code has already done it.
 if __name__ == "__main__":
     sys.path.append(os.path.join(os.path.abspath(os.path.dirname(sys.argv[0])),
                                  "..", "..", "..", "test"))
+    sys.path.append(os.path.join(os.path.abspath(os.path.dirname(sys.argv[0])),
+                                 ".."))
 from mockgeo import SimpleShapeStore
 import support
 support.initthuban()
-import Thuban
 
 # Now import needed SVG stuff
-from Extensions.svgexport.svgmapwriter import VirtualDC, \
+from svgmapwriter import VirtualDC, \
      Pen, Brush, SOLID,  Point, Font, TRANSPARENT_PEN, TRANSPARENT_BRUSH, \
      SVGRenderer, SVGMapWriterError
 # Color related classes from the model of thuban




From cvs at intevation.de  Wed Nov 24 23:35:59 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Wed, 24 Nov 2004 23:35:59 +0100 (CET)
Subject: jan: thuban/Extensions/svgexport __init__.py,1.2,1.3 
Message-ID: <20041124223559.4B01D100164@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/svgexport
In directory doto:/tmp/cvs-serv27631

Modified Files:
	__init__.py 
Log Message:
Fix to have the extensions' test module also be executed from the
global test routine.
This is done by looking for the absense of the DISPLAY variable.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/__init__.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- __init__.py	20 Nov 2004 12:52:50 -0000	1.2
+++ __init__.py	24 Nov 2004 22:35:57 -0000	1.3
@@ -6,8 +6,17 @@
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with the software for details.
 
-# import the actual module
-import svgsaver
+# import the actual modules
+from os import environ
+try:
+    dummy = environ["DISPLAY"]
+    import svgsaver
+    import maplegend
+except:
+    pass # we don't have a DISPLAY, so don't import the modules
+         # (we probably are in test-mode)
+         # Not sure whether this is the best method to avoid problems
+         # in the global test routine.
 
 # perform the registration of the extension
 from Thuban import _




From cvs at intevation.de  Wed Nov 24 23:52:08 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Wed, 24 Nov 2004 23:52:08 +0100 (CET)
Subject: jan: thuban/Extensions/svgexport maplegend.py,1.2,1.3 
Message-ID: <20041124225208.8BB31100164@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Extensions/svgexport
In directory doto:/tmp/cvs-serv27953

Modified Files:
	maplegend.py 
Log Message:
Moved the menu entry from Extensions
to Experimental menu since this module has yet not reached a stable
status (ie. 1.0).


Index: maplegend.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/maplegend.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- maplegend.py	15 Nov 2004 16:27:41 -0000	1.2
+++ maplegend.py	24 Nov 2004 22:52:06 -0000	1.3
@@ -168,14 +168,13 @@
 # See Thuban/UI/menu.py for the API of the Menu class
 from Thuban.UI.mainwindow import main_menu
 
-# find the extensions menu (create it anew if not found)
-extensions_menu = main_menu.find_menu('extensions')
-if extensions_menu is None:
-    extensions_menu = main_menu.InsertMenu('extensions', _('E&xtensions'))
-    
 # create a new command and register it
 registry.Add(Command('write_legend', _('Write SVG Legend'), write_legend,
                      helptext = _('Write a basic Legend for the map.')))
 
+# find the experimental menu (create it anew if not found)
+experimental_menu = main_menu.FindOrInsertMenu('experimental',
+                                               _('Experimenta&l'))
+
 # finally bind the new command with an entry in the extensions menu
-extensions_menu.InsertItem('write_legend')
+experimental_menu.InsertItem('write_legend')




From cvs at intevation.de  Wed Nov 24 23:52:58 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Wed, 24 Nov 2004 23:52:58 +0100 (CET)
Subject: jan: thuban ChangeLog,1.709,1.710 
Message-ID: <20041124225258.87680100164@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv28055

Modified Files:
	ChangeLog 
Log Message:
Fix broken tests for svg extension and added svg legend
to Experimental menu.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.709
retrieving revision 1.710
diff -u -d -r1.709 -r1.710
--- ChangeLog	22 Nov 2004 11:17:47 -0000	1.709
+++ ChangeLog	24 Nov 2004 22:52:56 -0000	1.710
@@ -1,3 +1,20 @@
+2004-11-24  Jan-Oliver Wagner <jan at intevation.de>
+
+	Fix broken tests for svg extension and added svg legend
+	to Experimental menu.
+
+	* Extensions/svgexport/test/test_svgmapwriter.py: Fix to have
+	the test run correctly even if the extension is a package.
+	Also removed the "import Thuban" which makes no sense.
+
+	* Extensions/svgexport/__init__.py: Fix to have the extensions'
+	test module also be executed from the global test routine.
+	This is done by looking for the absense of the DISPLAY variable.
+
+	* Extensions/svgexport/maplegend.py: Moved the menu entry from Extensions
+	to Experimental menu since this module has yet not reached a stable
+	status (ie. 1.0).
+
 2004-11-22  Bernhard Reiter <bernhard at intevation.de>
 
 	* Extensions/svgexport/svgmapwriter.py:




From jan at intevation.de  Wed Nov 24 23:56:14 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Wed, 24 Nov 2004 23:56:14 +0100
Subject: [Thuban-devel] CVS fixing: Reverting?
In-Reply-To: <20041124162131.GC12394@intevation.de>
References: <20041124162131.GC12394@intevation.de>
Message-ID: <20041124225614.GA31112@intevation.de>

On Wed, Nov 24, 2004 at 05:21:31PM +0100, Bernhard Reiter wrote:
> what about reverting the changes you have made until tests work
> again in CVS so we get a state we can develop at the other parts.

just put enough pressure on me and I'll fix it right away ;-)

Fixed and in CVS. No reverting necessary anymore.

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

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



From jan at intevation.de  Thu Nov 25 00:00:41 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Thu, 25 Nov 2004 00:00:41 +0100
Subject: [Thuban-devel] __init__.py using for Registration
In-Reply-To: <20041122101415.GC9475@intevation.de>
References: <20041120125537.9A101102C0A@lists.intevation.de>
	<20041122101415.GC9475@intevation.de>
Message-ID: <20041124230041.GB31112@intevation.de>

For the archive: this is fxed as of yesterday.

On Mon, Nov 22, 2004 at 11:14:15AM +0100, Bernhard Reiter wrote:
> On Sat, Nov 20, 2004 at 01:55:37PM +0100, cvs at intevation.de wrote:
> > Modified Files:
> > 	ChangeLog 
> > Log Message:
> > Changed way of extension registry for importAPR, bboxdump
> > and added extension registry for svgexport.extension registry for
> > svgexport.
> 
> These changes break running tests in the Extensions submodules,
> because they always import wxGTK (as far as I can see).
> I saw the problem with tests in svgexport (which are running
> together will all tests, so all tests are broken now!!)
> and with the test in gns2shp.

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

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



From dcalvelo at minag.gob.pe  Thu Nov 25 02:29:26 2004
From: dcalvelo at minag.gob.pe (Daniel Calvelo Aros)
Date: Wed, 24 Nov 2004 20:29:26 -0500
Subject: Base class for Shapes?
In-Reply-To: <20041124214926.GA30763@intevation.de>
References: <20041124214926.GA30763@intevation.de>
Message-ID: <20041125012339.M88621@minag.gob.pe>

What I would find excellent to have in memory is a topological
version of the shapestore. I have been trying to implement cartogram
drawing, which involves polygon transformations that must keep e.g. adjacency.
So far I have been quite frustrated by the need to build
the topology anyway. If shape editing is implemented in any timeframe,
topology will be necessary.

Maybe some GRASS "inspiration" might be useful.

-- Daniel Calvelo Aros

PS. And properly implementing Jenks-Caspall classification needs
(a mild, less stringent) topology as well.

---------- Original Message -----------
From: Jan-Oliver Wagner <jan at intevation.de>
To: Thuban Developer Mailing List <thuban-devel at intevation.de>
Sent: Wed, 24 Nov 2004 22:49:26 +0100
Subject: Base class for Shapes?

> Hi,
> 
> on a train travel from Bonn to Osnabr?ck
> I worked out an idea about a Base Shape Class.
> See the attached patch.
> 
> The idea is that we might want to have Shapes/Shapestores
> that are kept in memory instead in a file in order
> have a opportunity to create/modify them with arbitrary
> algorithms implemented in Thuban(or in its extensions).
> 
> The idea is taken from a large Thuban Extension on precision
> farming developed by Ole Rahn.
> 
> This class "Shape" would also be a first step to redruce
> the code in that extension. Ongoing steps would be to introduce
> a MemoryShapeStore with ability to store it as a Shapefile.
> 
> What I want to know is whether this idea is a sensible way to
> go or not. Any feedback welcome.
> 
> Ah, and: this can even be ported back to 1_0 ;-)
> 
> Best
> 
> 	Jan
> -- 
> Jan-Oliver Wagner               http://intevation.de/~jan/
> 
> Intevation GmbH                      http://intevation.de/
> FreeGIS                                http://freegis.org/
------- End of Original Message -------



From jan at intevation.de  Thu Nov 25 09:14:08 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Thu, 25 Nov 2004 09:14:08 +0100
Subject: [Thuban-devel] Re: Base class for Shapes?
In-Reply-To: <20041125012339.M88621@minag.gob.pe>
References: <20041124214926.GA30763@intevation.de>
	<20041125012339.M88621@minag.gob.pe>
Message-ID: <20041125081408.GA31595@intevation.de>

On Wed, Nov 24, 2004 at 08:29:26PM -0500, Daniel Calvelo Aros wrote:
> What I would find excellent to have in memory is a topological
> version of the shapestore. I have been trying to implement cartogram
> drawing, which involves polygon transformations that must keep e.g. adjacency.
> So far I have been quite frustrated by the need to build
> the topology anyway. If shape editing is implemented in any timeframe,
> topology will be necessary.
> 
> Maybe some GRASS "inspiration" might be useful.

having a topological version of the Layer in memory should
actually be indpendent of whether the shapestore is in memory
as well.

I wonder whether there is a library/tool out there that Thuban
could use for toplogy support (GEOS?).

Best

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

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



From dcalvelo at minag.gob.pe  Thu Nov 25 17:51:23 2004
From: dcalvelo at minag.gob.pe (Daniel Calvelo Aros)
Date: Thu, 25 Nov 2004 11:51:23 -0500
Subject: Base class for Shapes?
In-Reply-To: <20041125081408.GA31595@intevation.de>
References: <20041124214926.GA30763@intevation.de>
	<20041125012339.M88621@minag.gob.pe>
	<20041125081408.GA31595@intevation.de>
Message-ID: <20041125163649.M12967@minag.gob.pe>

Mmmh... Ok, right, different problem, different lobbying needs :)

Anyway, it's easier to build shapes from topology than the other way around.

If you need a strong argument for in-memory shapestores, you might consider
them as a cache for physical database access. We do need this kind of cache.
We would need it for WFS support as well. If you ever tried to build a
classification for a 2000-polygon simple feature stored in a remote PostGIS,
you know what I'm talking about.

WRT GEOS, what would you think of "spatially enabling" SQLite? I'm thinking
out loud here, but since you already can have GEOS in PostGIS, most GEOS
functions can be accessed through PostGIS, bar the latency, connection time
etc. If we are trying to have fast access to feature data, implementing RTree
indexing and geometry functions for SQLite and interfacing that with GEOS
would give you high-level topological operators plus SQL access, all
in-memory... That's yet another project, I'm afraid.

-- Daniel Calvelo Aros

---------- Original Message -----------
From: Jan-Oliver Wagner <jan at intevation.de>
To: thuban-devel at intevation.de
Sent: Thu, 25 Nov 2004 09:14:08 +0100
Subject: Re: [Thuban-devel] Re: Base class for Shapes?

> On Wed, Nov 24, 2004 at 08:29:26PM -0500, Daniel Calvelo Aros wrote:
> > What I would find excellent to have in memory is a topological
> > version of the shapestore. I have been trying to implement cartogram
> > drawing, which involves polygon transformations that must keep e.g. adjacency.
> > So far I have been quite frustrated by the need to build
> > the topology anyway. If shape editing is implemented in any timeframe,
> > topology will be necessary.
> > 
> > Maybe some GRASS "inspiration" might be useful.
> 
> having a topological version of the Layer in memory should
> actually be indpendent of whether the shapestore is in memory
> as well.
> 
> I wonder whether there is a library/tool out there that Thuban
> could use for toplogy support (GEOS?).
> 
> Best
> 
> 	Jan
> -- 
> Jan-Oliver Wagner               http://intevation.de/~jan/
> 
> Intevation GmbH                      http://intevation.de/
> FreeGIS                                http://freegis.org/
> 
> _______________________________________________
> Thuban-devel mailing list
> Thuban-devel at intevation.de
> https://intevation.de/mailman/listinfo/thuban-devel
------- End of Original Message -------



From dcalvelo at minag.gob.pe  Thu Nov 25 17:51:34 2004
From: dcalvelo at minag.gob.pe (Daniel Calvelo Aros)
Date: Thu, 25 Nov 2004 11:51:34 -0500
Subject: Base class for Shapes?
In-Reply-To: <20041125081408.GA31595@intevation.de>
References: <20041124214926.GA30763@intevation.de>
	<20041125012339.M88621@minag.gob.pe>
	<20041125081408.GA31595@intevation.de>
Message-ID: <20041125165134.M90071@minag.gob.pe>

Mmmh... Ok, right, different problem, different lobbying needs :)

Anyway, it's easier to build shapes from topology than the other way around.

If you need a strong argument for in-memory shapestores, you might consider
them as a cache for physical database access. We do need this kind of cache.
We would need it for WFS support as well. If you ever tried to build a
classification for a 2000-polygon simple feature stored in a remote PostGIS,
you know what I'm talking about.

WRT GEOS, what would you think of "spatially enabling" SQLite? I'm thinking
out loud here, but since you already can have GEOS in PostGIS, most GEOS
functions can be accessed through PostGIS, bar the latency, connection time
etc. If we are trying to have fast access to feature data, implementing RTree
indexing and geometry functions for SQLite and interfacing that with GEOS
would give you high-level topological operators plus SQL access, all
in-memory... That's yet another project, I'm afraid.

-- Daniel Calvelo Aros

---------- Original Message -----------
From: Jan-Oliver Wagner <jan at intevation.de>
To: thuban-devel at intevation.de
Sent: Thu, 25 Nov 2004 09:14:08 +0100
Subject: Re: [Thuban-devel] Re: Base class for Shapes?

> On Wed, Nov 24, 2004 at 08:29:26PM -0500, Daniel Calvelo Aros wrote:
> > What I would find excellent to have in memory is a topological
> > version of the shapestore. I have been trying to implement cartogram
> > drawing, which involves polygon transformations that must keep e.g. adjacency.
> > So far I have been quite frustrated by the need to build
> > the topology anyway. If shape editing is implemented in any timeframe,
> > topology will be necessary.
> > 
> > Maybe some GRASS "inspiration" might be useful.
> 
> having a topological version of the Layer in memory should
> actually be indpendent of whether the shapestore is in memory
> as well.
> 
> I wonder whether there is a library/tool out there that Thuban
> could use for toplogy support (GEOS?).
> 
> Best
> 
> 	Jan
> -- 
> Jan-Oliver Wagner               http://intevation.de/~jan/
> 
> Intevation GmbH                      http://intevation.de/
> FreeGIS                                http://freegis.org/
> 
> _______________________________________________
> Thuban-devel mailing list
> Thuban-devel at intevation.de
> https://intevation.de/mailman/listinfo/thuban-devel
------- End of Original Message -------



From bh at intevation.de  Thu Nov 25 22:08:44 2004
From: bh at intevation.de (Bernhard Herzog)
Date: Thu, 25 Nov 2004 22:08:44 +0100
Subject: Base class for Shapes?
References: <20041124214926.GA30763@intevation.de>
Message-ID: <s9zoehlk55v.fsf@thetis.intevation.de>

Jan-Oliver Wagner <jan at intevation.de> writes:

> Hi,
>
> on a train travel from Bonn to Osnabr?ck
> I worked out an idea about a Base Shape Class.

If it's there to reduce code duplication OK (The bounding box
computation has been copied several times already).  It should not be a
requirement for shape objects to be derived from that class, though.

> The idea is that we might want to have Shapes/Shapestores
> that are kept in memory instead in a file in order
> have a opportunity to create/modify them with arbitrary
> algorithms implemented in Thuban(or in its extensions).

I haven't looked at Ole's code yet, but in the test suite there's
already a simple shape store that has all the shape data in memory
(SimpleShapeStore in test/mockgeo.py).  It's only there for the tests,
but the MemoryTable started out that way too.

> This class "Shape" would also be a first step to redruce
> the code in that extension. Ongoing steps would be to introduce
> a MemoryShapeStore with ability to store it as a Shapefile.

Writing shapes to a shapefile is orthogonal of memory shape stores.  It
should be possible to write a function that takes any kind of shapestore
and writes its contents to a shapefile (or ideally any writable
shapestore, once we have such a thing in Thuban).

> Ah, and: this can even be ported back to 1_0 ;-)

Why should the shape base class be backported?

> --- Thuban/Model/data.py	24 Nov 2003 19:23:08 -0000	1.15
> +++ Thuban/Model/data.py	24 Nov 2004 21:43:02 -0000
> @@ -48,8 +48,114 @@ RAW_SHAPEFILE = "RAW_SHAPEFILE"
>  # Raw data in well-known text format
>  RAW_WKT = "RAW_WKT"
>  
> +class Shape:
>  
> -class ShapefileShape:
> +    """Base class (Interface) for representing a single Shape.
> +    """

Well, what is it?  A base class or an interface?  It shouldn't be both.
The interface should be independent of a particular base class.  As for
interface, most of the larger python projects (twisted and Zope for
instance) seem to be converging on something like PyProtocols.  The
details vary a bit and we don't need all of it for Thuban, we should go
in that direction as well.  At the very least it will document the
interfaces we use.

That sais, it would be OK to have a class that contains the code that's
currently duplicated in the various shape classes that already exist.
AFAICT, in the shape classes that come with Thuban, i.e. ShapefileShape,
PostGISShape and SimpleShape, there are only two things their
implementations have in common:

  shapeid: In all cases it's passed to __init__, stored in self.shapeid,
           and from there it's returned by the ShapeId() method.

  compute_bbox: The method to compute the bounding from the points.
                It's implementation is exactly the same in all three
                cases.

So if we want a base class for common implementation, these would be the
only things that belong there.


Your base class has several methods that modify the shape. So, one
general design issue that we may need to decide is whether shape objects
are mutable.  I would prefer to keep them immutable.  If they were
mutable, what would changing a shape mean?  If it were a shape read from
a shapefile, for instance, would the shapefile automatically be
modified?

> +    def isInBBox(self, bbox):
> +    	"""Test whether the the shape lies completely within the
> +	given bounding box.

It might be easier to promote bounding boxes to "real" objects.  Then
you could do that kind of bounding box arit

> +
> +	bbox -- the bounding box as tuple (minx,miny,max,maxy)
> +
> +	Returns: True if the shape lies within bbox, else False
> +	"""
> +        bb_minX, bb_minY, bb_maxX, bb_maxY = bbox
> +        minX, minY, maxX, maxY = self.BBox()
> +
> +        if minX >= bb_minX and maxX <= bb_maxX and \
> +	   minY >= bb_minY and maxY <= bb_maxY:
> +            return True
> +
> +        return False
> +
> +    def __str__(self):
> +        return "Shape " + repr(self.shapeid) + ": " + repr(self.points)
> +
> +#    def intersectsBBox(self, bbox):
> +#    	"""Test whether the the shape intersects the given bounding box.
> +#	In other words, tests whether at least one point of the shape
> +#	lies within the given bounding box.
> +#
> +#	bbox -- the bounding box as tuple (minx,miny,max,maxy)
> +#
> +#	Returns: True if at least one point of the shape lies within
> +#	         bbox, else False
> +#	"""
> +#        bb_minX, bb_minY, bb_maxX, bb_maxY = bbox
> +#        minX, minY, maxX, maxY = self.BBox()
> +#
> +#	# test each single point whether it is inside the given bbox
> +#        for part in self.Points():
> +#            for x, y in part:
> +#            if (x >= bb_minX and x <= bb_maxX) and
> +#	       (y >= bb_minY and y <= bb_maxY):
> +#                return True

Did you comment that out and forgot to remove it before posting this?
It's quite buggy :)


>      def RawData(self):
> -        """Return the shape id to use with the shapefile"""
> +        """Return the shape id to use with the shapefile.
> +	
> +	XXX: What is the difference to ShapeID()?"""
>          return self.shapeid

RawData() returns the data for the shape in it's "raw" form.  What that
is depends on the shape store.  For shapefiles it's the id, for the
PostGISShape a string with the WKT representation.  So, it's a
coincidence that RawData() is identical to ShapeID().  The raw form is
used by the low-level renderers, for instance, because it can increase
performance substantially.


   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From bh at intevation.de  Thu Nov 25 22:13:34 2004
From: bh at intevation.de (Bernhard Herzog)
Date: Thu, 25 Nov 2004 22:13:34 +0100
Subject: jan: thuban/Extensions/svgexport __init__.py,1.2,1.3
References: <20041124223559.4B01D100164@lists.intevation.de>
Message-ID: <s9zfz2xk4xt.fsf@thetis.intevation.de>

cvs at intevation.de writes:

> +# import the actual modules
> +from os import environ
> +try:
> +    dummy = environ["DISPLAY"]
> +    import svgsaver
> +    import maplegend
> +except:
> +    pass # we don't have a DISPLAY, so don't import the modules
> +         # (we probably are in test-mode)

That's not the right solution IMO.  No code should check whether it's
running under the test suite or not.  I'm not sure yet what the best
solution is, but as a first step, I'd say that the __init__ module in
the extension packages should not import the GUI parts of the extension
automatically.

  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From jan at intevation.de  Fri Nov 26 09:39:19 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 26 Nov 2004 09:39:19 +0100
Subject: Lots of interesting code in precision farming application
Message-ID: <20041126083919.GA1743@intevation.de>

Hi Thuban developers,

on the Thuban users list I posted a info on
a extrememly interesting contribution to Thuban.
Thanks a lot to Ole Rahn, the main developer!

There are a lot of features in this Precision Farming
application that could/should be ported into Thuban
core or as individual extensions.
All stuff, however, is in german language.
Any takers welcome.

Start here:
http://thuban.intevation.org/download.html#contrib

Best

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

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



From cvs at intevation.de  Fri Nov 26 12:44:34 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Fri, 26 Nov 2004 12:44:34 +0100 (CET)
Subject: bh: thuban/Extensions/svgexport/test test_svgmapwriter.py,1.7,1.8 
Message-ID: <20041126114434.9A613100168@lists.intevation.de>

Author: bh

Update of /thubanrepository/thuban/Extensions/svgexport/test
In directory doto:/tmp/cvs-serv18551/Extensions/svgexport/test

Modified Files:
	test_svgmapwriter.py 
Log Message:
(Testobjectexport.test_transparent_polygon): Commented out some
debug prints


Index: test_svgmapwriter.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/test/test_svgmapwriter.py,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- test_svgmapwriter.py	24 Nov 2004 22:21:28 -0000	1.7
+++ test_svgmapwriter.py	26 Nov 2004 11:44:32 -0000	1.8
@@ -332,8 +332,8 @@
         renderer = SVGRenderer(self.dc, map,
                     scale=1.0, offset=(0,0), region=(0,0,10,10))
         renderer.RenderMap(None, None)
-        print (data)
-        print (self.dc.file.getvalue())
+        #print (data)
+        #print (self.dc.file.getvalue())
         self.assertEquals(data, self.dc.file.getvalue())
 
 




From cvs at intevation.de  Fri Nov 26 12:44:34 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Fri, 26 Nov 2004 12:44:34 +0100 (CET)
Subject: bh: thuban ChangeLog,1.710,1.711 
Message-ID: <20041126114434.A790F102C04@lists.intevation.de>

Author: bh

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv18551

Modified Files:
	ChangeLog 
Log Message:
(Testobjectexport.test_transparent_polygon): Commented out some
debug prints


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.710
retrieving revision 1.711
diff -u -d -r1.710 -r1.711
--- ChangeLog	24 Nov 2004 22:52:56 -0000	1.710
+++ ChangeLog	26 Nov 2004 11:44:32 -0000	1.711
@@ -1,3 +1,9 @@
+2004-11-26  Bernhard Herzog  <bh at intevation.de>
+
+	* Extensions/svgexport/test/test_svgmapwriter.py
+	(Testobjectexport.test_transparent_polygon): Commented out some
+	debug prints
+
 2004-11-24  Jan-Oliver Wagner <jan at intevation.de>
 
 	Fix broken tests for svg extension and added svg legend




From bernhard at intevation.de  Fri Nov 26 16:12:58 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Nov 2004 16:12:58 +0100
Subject: [Thuban-devel] __init__.py using for Registration
In-Reply-To: <20041124230041.GB31112@intevation.de>
References: <20041120125537.9A101102C0A@lists.intevation.de>
	<20041122101415.GC9475@intevation.de>
	<20041124230041.GB31112@intevation.de>
Message-ID: <20041126151258.GF32547@intevation.de>

On Thu, Nov 25, 2004 at 12:00:41AM +0100, Jan-Oliver Wagner wrote:
> For the archive: this is fxed as of yesterday.

Can you run the test of gns2shp?

> On Mon, Nov 22, 2004 at 11:14:15AM +0100, Bernhard Reiter wrote:
> > On Sat, Nov 20, 2004 at 01:55:37PM +0100, cvs at intevation.de wrote:
> > > Modified Files:
> > > 	ChangeLog 
> > > Log Message:
> > > Changed way of extension registry for importAPR, bboxdump
> > > and added extension registry for svgexport.extension registry for
> > > svgexport.
> > 
> > These changes break running tests in the Extensions submodules,
> > because they always import wxGTK (as far as I can see).
> > I saw the problem with tests in svgexport (which are running
> > together will all tests, so all tests are broken now!!)
> > and with the test in gns2shp.
> 
> -- 
> Jan-Oliver Wagner               http://intevation.de/~jan/
> 
> Intevation GmbH                      http://intevation.de/
> FreeGIS                                http://freegis.org/
> 
> _______________________________________________
> Thuban-devel mailing list
> Thuban-devel at intevation.de
> https://intevation.de/mailman/listinfo/thuban-devel

-- 
Gesch?ftsf?hrer, Intevation GmbH                    (intevation.de)
Projekt Freie GIS Software              (freegis.org/index.de.html)
FFII e.V.				                 (ffii.org)
FSF Europa     			      (fsfeurope.org/index.de.html)
-------------- 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-devel/attachments/20041126/dee48b69/attachment.bin

From jan at intevation.de  Fri Nov 26 16:18:30 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 26 Nov 2004 16:18:30 +0100
Subject: [Thuban-devel] __init__.py using for Registration
In-Reply-To: <20041126151258.GF32547@intevation.de>
References: <20041120125537.9A101102C0A@lists.intevation.de>
	<20041122101415.GC9475@intevation.de>
	<20041124230041.GB31112@intevation.de>
	<20041126151258.GF32547@intevation.de>
Message-ID: <20041126151830.GC2769@intevation.de>

On Fri, Nov 26, 2004 at 04:12:58PM +0100, Bernhard Reiter wrote:
> On Thu, Nov 25, 2004 at 12:00:41AM +0100, Jan-Oliver Wagner wrote:
> > For the archive: this is fxed as of yesterday.
> 
> Can you run the test of gns2shp?

no. But that is a different problem, the test is broken already
since before my recent changes.

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

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



From bernhard at intevation.de  Fri Nov 26 16:19:31 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Nov 2004 16:19:31 +0100
Subject: tests, Extensions and __init__
In-Reply-To: <20041124225258.87680100164@lists.intevation.de>
References: <20041124225258.87680100164@lists.intevation.de>
Message-ID: <20041126151931.GG32547@intevation.de>

On Wed, Nov 24, 2004 at 11:52:58PM +0100, cvs at intevation.de wrote:
> Author: jan
> 
> Update of /thubanrepository/thuban
> In directory doto:/tmp/cvs-serv28055
> 
> Modified Files:
> 	ChangeLog 
> Log Message:
> Fix broken tests for svg extension and added svg legend
> to Experimental menu.

The tests itself were not broken
and using DISPLAY as indicate that we are running tests
is an ugly solution.

I think that we need to refrain from  using __init__.py
to make Extensions a package for code clarity reasons.

Most Extensions should have a gui dependent and a gui-independent part.
To keep that seperated, it must be possible to import the
gui-independent modules separately.
Making those directories packages with __init__ prevents this 
as we always include everything
unless we do ugly hacks that depend on some GUI properties.

If that is the case, then I would prefer the clarify 
over the bit of easiness for import commands.

We can later think of a plug-in mechanism that makes loading plugins
easier for the user, like walking throught subdirectories on Extensions
and importing special file names when running as GUI.
Like 	register_me_wx.py
-------------- 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-devel/attachments/20041126/0c51d0cd/attachment.bin

From bernhard at intevation.de  Fri Nov 26 16:20:09 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Nov 2004 16:20:09 +0100
Subject: jan: thuban/Extensions/svgexport __init__.py,1.2,1.3
In-Reply-To: <s9zfz2xk4xt.fsf@thetis.intevation.de>
References: <20041124223559.4B01D100164@lists.intevation.de>
	<s9zfz2xk4xt.fsf@thetis.intevation.de>
Message-ID: <20041126152009.GH32547@intevation.de>

On Thu, Nov 25, 2004 at 10:13:34PM +0100, Bernhard Herzog wrote:
> cvs at intevation.de writes:
> 
> > +# import the actual modules
> > +from os import environ
> > +try:
> > +    dummy = environ["DISPLAY"]
> > +    import svgsaver
> > +    import maplegend
> > +except:
> > +    pass # we don't have a DISPLAY, so don't import the modules
> > +         # (we probably are in test-mode)
> 
> That's not the right solution IMO.  No code should check whether it's
> running under the test suite or not.  I'm not sure yet what the best
> solution is, but as a first step, I'd say that the __init__ module in
> the extension packages should not import the GUI parts of the extension
> automatically.

I agree and wrote down more details in my other email.
-------------- 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-devel/attachments/20041126/115f982d/attachment.bin

From bernhard at intevation.de  Fri Nov 26 16:20:49 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Nov 2004 16:20:49 +0100
Subject: [Thuban-devel] CVS fixing: Reverting?
In-Reply-To: <20041124225614.GA31112@intevation.de>
References: <20041124162131.GC12394@intevation.de>
	<20041124225614.GA31112@intevation.de>
Message-ID: <20041126152049.GI32547@intevation.de>

On Wed, Nov 24, 2004 at 11:56:14PM +0100, Jan-Oliver Wagner wrote:
> On Wed, Nov 24, 2004 at 05:21:31PM +0100, Bernhard Reiter wrote:
> > what about reverting the changes you have made until tests work
> > again in CVS so we get a state we can develop at the other parts.
> 
> just put enough pressure on me and I'll fix it right away ;-)
> 
> Fixed and in CVS. No reverting necessary anymore.

I still opt for reverting as you have used a workaround. ;)
-------------- 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-devel/attachments/20041126/34e08b19/attachment.bin

From bh at intevation.de  Fri Nov 26 16:23:39 2004
From: bh at intevation.de (Bernhard Herzog)
Date: Fri, 26 Nov 2004 16:23:39 +0100
Subject: tests, Extensions and __init__
In-Reply-To: <20041126151931.GG32547@intevation.de> (Bernhard Reiter's
	message of "Fri, 26 Nov 2004 16:19:31 +0100")
References: <20041124225258.87680100164@lists.intevation.de>
	<20041126151931.GG32547@intevation.de>
Message-ID: <s9z653socqs.fsf@salmakis.intevation.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> I think that we need to refrain from  using __init__.py
> to make Extensions a package for code clarity reasons.

The prensence of the __init__.pys is not a problem in and of itself.
The problem is that the code in __init__ imports modules which in turn
import wx.  If the __init__.pys were empty, for instance, we would not
have that problem.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From bernhard at intevation.de  Fri Nov 26 16:24:33 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Nov 2004 16:24:33 +0100
Subject: tests, Extensions and __init__
In-Reply-To: <s9z653socqs.fsf@salmakis.intevation.de>
References: <20041124225258.87680100164@lists.intevation.de>
	<20041126151931.GG32547@intevation.de>
	<s9z653socqs.fsf@salmakis.intevation.de>
Message-ID: <20041126152433.GJ32547@intevation.de>

On Fri, Nov 26, 2004 at 04:23:39PM +0100, Bernhard Herzog wrote:
> Bernhard Reiter <bernhard at intevation.de> writes:
> 
> > I think that we need to refrain from  using __init__.py
> > to make Extensions a package for code clarity reasons.
> 
> The prensence of the __init__.pys is not a problem in and of itself.
> The problem is that the code in __init__ imports modules which in turn
> import wx.  If the __init__.pys were empty, for instance, we would not
> have that problem.

Empty files is what I have meant with "not using" them.


-------------- 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-devel/attachments/20041126/ac664f73/attachment.bin

From bernhard at intevation.de  Fri Nov 26 16:29:21 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Nov 2004 16:29:21 +0100
Subject: Base class for Shapes?
In-Reply-To: <s9zoehlk55v.fsf@thetis.intevation.de>
References: <20041124214926.GA30763@intevation.de>
	<s9zoehlk55v.fsf@thetis.intevation.de>
Message-ID: <20041126152921.GK32547@intevation.de>

On Thu, Nov 25, 2004 at 10:08:44PM +0100, Bernhard Herzog wrote:
> Jan-Oliver Wagner <jan at intevation.de> writes:

> > I worked out an idea about a Base Shape Class.

> > The idea is that we might want to have Shapes/Shapestores
> > that are kept in memory instead in a file in order
> > have a opportunity to create/modify them with arbitrary
> > algorithms implemented in Thuban(or in its extensions).

I agree that we should separate storage of geographic data 
from the accessing object interface.

So does Shape refer to geographic object or shapefiles (one specific
format) here?


> Writing shapes to a shapefile is orthogonal of memory shape stores.  It
> should be possible to write a function that takes any kind of shapestore
> and writes its contents to a shapefile (or ideally any writable
> shapestore, once we have such a thing in Thuban).

> Your base class has several methods that modify the shape. So, one
> general design issue that we may need to decide is whether shape objects
> are mutable.  I would prefer to keep them immutable.  If they were
> mutable, what would changing a shape mean?  If it were a shape read from
> a shapefile, for instance, would the shapefile automatically be
> modified?


We need a concept of changing the data 
and also of buffering data (when the storage is slow).

Most modifications could be buffered until a commit
to a storage is possible. 
In some situations the modifications can be made in their
own new storage (used as a layer).

-------------- 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-devel/attachments/20041126/308e6212/attachment.bin

From bh at intevation.de  Fri Nov 26 16:30:14 2004
From: bh at intevation.de (Bernhard Herzog)
Date: Fri, 26 Nov 2004 16:30:14 +0100
Subject: tests, Extensions and __init__
In-Reply-To: <20041126152433.GJ32547@intevation.de> (Bernhard Reiter's
	message of "Fri, 26 Nov 2004 16:24:33 +0100")
References: <20041124225258.87680100164@lists.intevation.de>
	<20041126151931.GG32547@intevation.de>
	<s9z653socqs.fsf@salmakis.intevation.de>
	<20041126152433.GJ32547@intevation.de>
Message-ID: <s9z1xegocft.fsf@salmakis.intevation.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> On Fri, Nov 26, 2004 at 04:23:39PM +0100, Bernhard Herzog wrote:
>> Bernhard Reiter <bernhard at intevation.de> writes:
>> 
>> > I think that we need to refrain from  using __init__.py
>> > to make Extensions a package for code clarity reasons.
[...]
> Empty files is what I have meant with "not using" them.

Well, the mere presence of the __init__.py turns a directory into a
package, so the way you phrased it implied removing them.  

Hoever, now that I read your post again, are you talking about
Extensions/__init__.py?  The problems we've had came from the
__init__.pys one level deeper.

  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From jan at intevation.de  Fri Nov 26 17:02:20 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 26 Nov 2004 17:02:20 +0100
Subject: [Thuban-devel] Re: jan: thuban/Extensions/svgexport __init__.py,
	1.2, 1.3
In-Reply-To: <s9zfz2xk4xt.fsf@thetis.intevation.de>
References: <20041124223559.4B01D100164@lists.intevation.de>
	<s9zfz2xk4xt.fsf@thetis.intevation.de>
Message-ID: <20041126160220.GE2769@intevation.de>

On Thu, Nov 25, 2004 at 10:13:34PM +0100, Bernhard Herzog wrote:
> cvs at intevation.de writes:
> 
> > +# import the actual modules
> > +from os import environ
> > +try:
> > +    dummy = environ["DISPLAY"]
> > +    import svgsaver
> > +    import maplegend
> > +except:
> > +    pass # we don't have a DISPLAY, so don't import the modules
> > +         # (we probably are in test-mode)
> 
> That's not the right solution IMO.  No code should check whether it's
> running under the test suite or not.

yes. I was unhappy about this too, but this way I was able to have
the test suite run again quickly. Better solution definititly due.

> I'm not sure yet what the best
> solution is, but as a first step, I'd say that the __init__ module in
> the extension packages should not import the GUI parts of the extension
> automatically.

What I want for Thuban is a standard rule to import everything
from a Extension. I don't bother how this is technically done
except that it is simple and a general rule.
"import Extensions.extensionname" fullfilled this, but just
let me know alternatives.

	Jan

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

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



From jan at intevation.de  Fri Nov 26 17:08:25 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 26 Nov 2004 17:08:25 +0100
Subject: [Thuban-devel] CVS fixing: Reverting?
In-Reply-To: <20041126152049.GI32547@intevation.de>
References: <20041124162131.GC12394@intevation.de>
	<20041124225614.GA31112@intevation.de>
	<20041126152049.GI32547@intevation.de>
Message-ID: <20041126160825.GF2769@intevation.de>

On Fri, Nov 26, 2004 at 04:20:49PM +0100, Bernhard Reiter wrote:
> On Wed, Nov 24, 2004 at 11:56:14PM +0100, Jan-Oliver Wagner wrote:
> > On Wed, Nov 24, 2004 at 05:21:31PM +0100, Bernhard Reiter wrote:
> > > what about reverting the changes you have made until tests work
> > > again in CVS so we get a state we can develop at the other parts.
> > 
> > just put enough pressure on me and I'll fix it right away ;-)
> > 
> > Fixed and in CVS. No reverting necessary anymore.
> 
> I still opt for reverting as you have used a workaround. ;)

but my fix made your test work with and without a __init_.py
that import GUI stuff. Isn't that clever enough to call it
a fix and not a workaround? ;-)

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

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



From jan at intevation.de  Fri Nov 26 17:55:20 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 26 Nov 2004 17:55:20 +0100
Subject: [Thuban-devel] Re: Base class for Shapes?
In-Reply-To: <s9zoehlk55v.fsf@thetis.intevation.de>
References: <20041124214926.GA30763@intevation.de>
	<s9zoehlk55v.fsf@thetis.intevation.de>
Message-ID: <20041126165520.GB3139@intevation.de>

On Thu, Nov 25, 2004 at 10:08:44PM +0100, Bernhard Herzog wrote:
> Jan-Oliver Wagner <jan at intevation.de> writes:
> > on a train travel from Bonn to Osnabr?ck
> > I worked out an idea about a Base Shape Class.
> 
> If it's there to reduce code duplication OK (The bounding box
> computation has been copied several times already).  It should not be a
> requirement for shape objects to be derived from that class, though.

I had code reduction in mind.

Why should not all Shape objects share the same base class?

> > The idea is that we might want to have Shapes/Shapestores
> > that are kept in memory instead in a file in order
> > have a opportunity to create/modify them with arbitrary
> > algorithms implemented in Thuban(or in its extensions).
> 
> I haven't looked at Ole's code yet, but in the test suite there's
> already a simple shape store that has all the shape data in memory
> (SimpleShapeStore in test/mockgeo.py).  It's only there for the tests,
> but the MemoryTable started out that way too.

Damn, I didn't find this. Will look into that code before doing
anything else on this topic.

> > This class "Shape" would also be a first step to redruce
> > the code in that extension. Ongoing steps would be to introduce
> > a MemoryShapeStore with ability to store it as a Shapefile.
> 
> Writing shapes to a shapefile is orthogonal of memory shape stores.  It
> should be possible to write a function that takes any kind of shapestore
> and writes its contents to a shapefile (or ideally any writable
> shapestore, once we have such a thing in Thuban).

Correct. I should have written with the ability to modify Shapes easily
and create layers without any Shapefile or Database as connection.

> > Ah, and: this can even be ported back to 1_0 ;-)
> 
> Why should the shape base class be backported?

The PIROL extension is based on 1.0 and there is no 1.2 yet.
So I thought this extension could be made more lean with
such classes ported to 1.0.

> > --- Thuban/Model/data.py	24 Nov 2003 19:23:08 -0000	1.15
> > +++ Thuban/Model/data.py	24 Nov 2004 21:43:02 -0000
> > @@ -48,8 +48,114 @@ RAW_SHAPEFILE = "RAW_SHAPEFILE"
> >  # Raw data in well-known text format
> >  RAW_WKT = "RAW_WKT"
> >  
> > +class Shape:
> >  
> > -class ShapefileShape:
> > +    """Base class (Interface) for representing a single Shape.
> > +    """
> 
> Well, what is it?  A base class or an interface?  It shouldn't be both.
> The interface should be independent of a particular base class.  As for
> interface, most of the larger python projects (twisted and Zope for
> instance) seem to be converging on something like PyProtocols.  The
> details vary a bit and we don't need all of it for Thuban, we should go
> in that direction as well.  At the very least it will document the
> interfaces we use.

I was not sure myself. In general, Interfaces would be nice,
but as along as we keep compatibility with  Python 2.2.1 it is
probably not good to introduce them.
So I was more looking at the base class aspect.

> That sais, it would be OK to have a class that contains the code that's
> currently duplicated in the various shape classes that already exist.
> AFAICT, in the shape classes that come with Thuban, i.e. ShapefileShape,
> PostGISShape and SimpleShape, there are only two things their
> implementations have in common:

>   shapeid: In all cases it's passed to __init__, stored in self.shapeid,
>            and from there it's returned by the ShapeId() method.
> 
>   compute_bbox: The method to compute the bounding from the points.
>                 It's implementation is exactly the same in all three
>                 cases.
> 
> So if we want a base class for common implementation, these would be the
> only things that belong there.

OK.

Aren't there any additional hard requirements all Shape object must have?
What about the RawData for example. Shouldn't there by a default method?

> Your base class has several methods that modify the shape. So, one
> general design issue that we may need to decide is whether shape objects
> are mutable.  I would prefer to keep them immutable.  If they were
> mutable, what would changing a shape mean?  If it were a shape read from
> a shapefile, for instance, would the shapefile automatically be
> modified?

Yes I agree. A base class should be immutable.

> > +    def isInBBox(self, bbox):
> > +    	"""Test whether the the shape lies completely within the
> > +	given bounding box.
> 
> It might be easier to promote bounding boxes to "real" objects.  Then
> you could do that kind of bounding box arit

not sure how to do that "arit".

> > +
> > +	bbox -- the bounding box as tuple (minx,miny,max,maxy)
> > +
> > +	Returns: True if the shape lies within bbox, else False
> > +	"""
> > +        bb_minX, bb_minY, bb_maxX, bb_maxY = bbox
> > +        minX, minY, maxX, maxY = self.BBox()
> > +
> > +        if minX >= bb_minX and maxX <= bb_maxX and \
> > +	   minY >= bb_minY and maxY <= bb_maxY:
> > +            return True
> > +
> > +        return False
> > +
> > +    def __str__(self):
> > +        return "Shape " + repr(self.shapeid) + ": " + repr(self.points)
> > +
> > +#    def intersectsBBox(self, bbox):
> > +#    	"""Test whether the the shape intersects the given bounding box.
> > +#	In other words, tests whether at least one point of the shape
> > +#	lies within the given bounding box.
> > +#
> > +#	bbox -- the bounding box as tuple (minx,miny,max,maxy)
> > +#
> > +#	Returns: True if at least one point of the shape lies within
> > +#	         bbox, else False
> > +#	"""
> > +#        bb_minX, bb_minY, bb_maxX, bb_maxY = bbox
> > +#        minX, minY, maxX, maxY = self.BBox()
> > +#
> > +#	# test each single point whether it is inside the given bbox
> > +#        for part in self.Points():
> > +#            for x, y in part:
> > +#            if (x >= bb_minX and x <= bb_maxX) and
> > +#	       (y >= bb_minY and y <= bb_maxY):
> > +#                return True
> 
> Did you comment that out and forgot to remove it before posting this?
> It's quite buggy :)

yes, that is broken totally and should have been removed before
I made the patch.

> 
> >      def RawData(self):
> > -        """Return the shape id to use with the shapefile"""
> > +        """Return the shape id to use with the shapefile.
> > +	
> > +	XXX: What is the difference to ShapeID()?"""
> >          return self.shapeid
> 
> RawData() returns the data for the shape in it's "raw" form.  What that
> is depends on the shape store.  For shapefiles it's the id, for the
> PostGISShape a string with the WKT representation.  So, it's a
> coincidence that RawData() is identical to ShapeID().  The raw form is
> used by the low-level renderers, for instance, because it can increase
> performance substantially.

This explanation could have helped me if in a default Shape.RawData()
method ;-) Currently we do not have a suitable place in the code to
put this text.

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

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



From jan at intevation.de  Fri Nov 26 17:56:38 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 26 Nov 2004 17:56:38 +0100
Subject: [Thuban-devel] Re: Base class for Shapes?
In-Reply-To: <20041126152921.GK32547@intevation.de>
References: <20041124214926.GA30763@intevation.de>
	<s9zoehlk55v.fsf@thetis.intevation.de>
	<20041126152921.GK32547@intevation.de>
Message-ID: <20041126165638.GC3139@intevation.de>

On Fri, Nov 26, 2004 at 04:29:21PM +0100, Bernhard Reiter wrote:
> On Thu, Nov 25, 2004 at 10:08:44PM +0100, Bernhard Herzog wrote:
> > Jan-Oliver Wagner <jan at intevation.de> writes:
> > > I worked out an idea about a Base Shape Class.
> 
> > > The idea is that we might want to have Shapes/Shapestores
> > > that are kept in memory instead in a file in order
> > > have a opportunity to create/modify them with arbitrary
> > > algorithms implemented in Thuban(or in its extensions).
> 
> I agree that we should separate storage of geographic data 
> from the accessing object interface.
> 
> So does Shape refer to geographic object or shapefiles (one specific
> format) here?

Geographic object.

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

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



From bh at intevation.de  Fri Nov 26 19:31:22 2004
From: bh at intevation.de (Bernhard Herzog)
Date: Fri, 26 Nov 2004 19:31:22 +0100
Subject: [Thuban-devel] Re: Base class for Shapes?
References: <20041124214926.GA30763@intevation.de>
	<s9zoehlk55v.fsf@thetis.intevation.de>
	<20041126165520.GB3139@intevation.de>
Message-ID: <s9zoehkmphh.fsf@salmakis.intevation.de>

Jan-Oliver Wagner <jan at intevation.de> writes:

> On Thu, Nov 25, 2004 at 10:08:44PM +0100, Bernhard Herzog wrote:
>> Jan-Oliver Wagner <jan at intevation.de> writes:
>> > on a train travel from Bonn to Osnabr?ck
>> > I worked out an idea about a Base Shape Class.
>> 
>> If it's there to reduce code duplication OK (The bounding box
>> computation has been copied several times already).  It should not be a
>> requirement for shape objects to be derived from that class, though.
>
> I had code reduction in mind.
>
> Why should not all Shape objects share the same base class?

The question is whether they should have to, not whether they are.  If
the base class doesn't offer any functionality for a specific shape
class it shouldn't have to be derived from the base class.

> I was not sure myself. In general, Interfaces would be nice,
> but as along as we keep compatibility with  Python 2.2.1 it is
> probably not good to introduce them.

The python version we're using has practically nothing to do with
whether we can use some kind of interface mechanism.  All
implementations I have seen are pure Python, basically, without any new
syntax.  Some implementations may work better with new style classes and
perhaps meta-classes, but that's not really a requirement for a simple
implementation.

I even have a simple working (IIRC :-) ) implementation for Thuban lying
around from last year.  That could be dusted off and checked in.  It
would only be good for documentation purposes and some simple test cases
that check whether an object conforms to the interfaces it claims to
support (only tests for the presence of methods at the moment).

> Aren't there any additional hard requirements all Shape object must have?

It has to conform to the shape interface.

> What about the RawData for example. Shouldn't there by a default method?

If the shape store the shape comes does not have a raw format (returned
by the shape stores RawShapeFormat() method) for which the renderer has
a low-level renderer, it doesn't need the RawData method.  The only raw
format for which low-level renderers exist is RAW_SHAPEFILE.

We could probably clarify the situation a bit by specifying that if the
raw format is RAW_PYTHON, then the RawData method will not be called by
Thuban.

Back when I was hacking on the interface stuff the Interface for shapes
was this:

class IShape(Interface):

    def ShapeID(self):
        """Return a unique integer that identifies the shape

        The integer only needs to be unique among the shapes in the same
        shapestore. It can later be used to reload the same shape
        with the shapestore's Shape() method.
        """

    def Points(self):
        """Return the coordinates of the shape as a list of lists of pairs.

        The coordinate system used is that of the shapestore the shape
        was obtained from.
        """

    def RawData(self):
        """Return the raw representation of the shape's coordinates

        The shapestore the shape was read from indicates what the format
        is with its RawShapeFormat method.
        """

    def compute_bbox(self):
        """Return the bounding box of the shape as a tuple

        The returned tuple has the form (minx, miny, maxx, maxy). The
        coordinate system used is that of the shapestore the shape was
        obtained from.
        """


It basically just describes the status quo of last summer.  The RawData
method should probably be optional, and the compute_bbox method should
be renamed.  It was added ad-hoc at some point.  When the
implementations are updated their bounding box methods should at least
do some caching as in your implementation or get the bounding box from
the shapestore which might be better for shapefiles for instance as it's
stored in the shapefiles.

>> It might be easier to promote bounding boxes to "real" objects.  Then
>> you could do that kind of bounding box arit
>
> not sure how to do that "arit".

I think I wanted to delete that unfinished paragraph before posting :).
IIRC, it would have said something along these lines:

It might be easier to promote bounding boxes to "real" objects.  Then
you could do that kind of bounding box arithmetic with the bounding box
objects.  In Skencil I have a C-object for that kind of thing[1].  That
doesn't fit what Thuban needs exactly, but it wouldn't be much work to
adapt it.

> This explanation could have helped me if in a default Shape.RawData()
> method ;-) Currently we do not have a suitable place in the code to
> put this text.

If we had Interfaces we would.

   Bernhard



[1] Skencil's Rect objects: http://www.skencil.org/Doc/devguide-6.html


-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From Chris.Barker at noaa.gov  Fri Nov 26 19:43:36 2004
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Fri, 26 Nov 2004 10:43:36 -0800
Subject: jan: thuban/Extensions/svgexport __init__.py,1.2,1.3
In-Reply-To: <s9zfz2xk4xt.fsf@thetis.intevation.de>
References: <20041124223559.4B01D100164@lists.intevation.de>
	<s9zfz2xk4xt.fsf@thetis.intevation.de>
Message-ID: <41A77958.5060000@noaa.gov>

Hi all,

I'm new this list, but have a little to add.

Bernhard Herzog wrote:
>>+# import the actual modules
>>+from os import environ
>>+try:
>>+    dummy = environ["DISPLAY"]
>>+    import svgsaver
>>+    import maplegend
>>+except:
>>+    pass # we don't have a DISPLAY, so don't import the modules
>>+         # (we probably are in test-mode)
> 
> 
> That's not the right solution IMO.  No code should check whether it's
> running under the test suite or not.  I'm not sure yet what the best
> solution is, but as a first step, I'd say that the __init__ module in
> the extension packages should not import the GUI parts of the extension
> automatically.

I'm clueless as to where this should be done, but I do know that testing 
for the DISPLAY environment variable is a poor way to test if X is 
running. This issue has come up on the wxPython list in the past, I 
created a relatively robust way to check for X. It's a C extension that 
tries to connect to an X-server, and returns an error if it's not 
successful. You might want to use it. Here's a link to my message on 
wxPython-users, with the code. If you have trouble getting it there, 
feel free to ask me for it.

http://aspn.activestate.com/ASPN/Mail/Message/wxPython-users/1925628

-Chris



From bernhard at intevation.de  Fri Nov 26 19:46:16 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Nov 2004 19:46:16 +0100
Subject: tests, Extensions and __init__
In-Reply-To: <s9z1xegocft.fsf@salmakis.intevation.de>
References: <20041124225258.87680100164@lists.intevation.de>
	<20041126151931.GG32547@intevation.de>
	<s9z653socqs.fsf@salmakis.intevation.de>
	<20041126152433.GJ32547@intevation.de>
	<s9z1xegocft.fsf@salmakis.intevation.de>
Message-ID: <20041126184616.GQ7232@intevation.de>

On Fri, Nov 26, 2004 at 04:30:14PM +0100, Bernhard Herzog wrote:
> Bernhard Reiter <bernhard at intevation.de> writes:
> 
> > On Fri, Nov 26, 2004 at 04:23:39PM +0100, Bernhard Herzog wrote:
> >> Bernhard Reiter <bernhard at intevation.de> writes:
> >> 
> >> > I think that we need to refrain from  using __init__.py
> >> > to make Extensions a package for code clarity reasons.
> [...]
> > Empty files is what I have meant with "not using" them.
> 
> Well, the mere presence of the __init__.py turns a directory into a
> package, so the way you phrased it implied removing them.  

I guess I wasn't precise enough on that one...

> Hoever, now that I read your post again, are you talking about
> Extensions/__init__.py?  The problems we've had came from the
> __init__.pys one level deeper.

I know.
A language problem hit me: the plural of extension is extensions,
I probably should have expressed that differently.

-------------- 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-devel/attachments/20041126/a4ba25a5/attachment.bin

From mlennert at club.worldonline.be  Sat Nov 27 10:40:03 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sat, 27 Nov 2004 10:40:03 +0100 (CET)
Subject: Lots of interesting code in precision farming application
In-Reply-To: <20041126083919.GA1743@intevation.de>
References: <20041126083919.GA1743@intevation.de>
Message-ID: <33054.83.134.238.118.1101548403.squirrel@vivegnulinux.homelinux.org>

On Fri, November 26, 2004 9:39, Jan-Oliver Wagner said:
> Hi Thuban developers,
>
> on the Thuban users list I posted a info on
> a extrememly interesting contribution to Thuban.
> Thanks a lot to Ole Rahn, the main developer!
>
> There are a lot of features in this Precision Farming
> application that could/should be ported into Thuban
> core or as individual extensions.
> All stuff, however, is in german language.
> Any takers welcome.

If noone else (with more experience) is planning on doing so, I am willing to
try to extract the csv-import functions as a seperate extension.

If I have seen correctly this entails mostly removing the hard-coded Pirol csv
format in order to allow more generic files.

Moritz





From jan at intevation.de  Sat Nov 27 13:29:50 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Sat, 27 Nov 2004 13:29:50 +0100
Subject: [Thuban-devel] Re: Lots of interesting code in precision
	farming application
In-Reply-To: <33054.83.134.238.118.1101548403.squirrel@vivegnulinux.homelinux.org>
References: <20041126083919.GA1743@intevation.de>
	<33054.83.134.238.118.1101548403.squirrel@vivegnulinux.homelinux.org>
Message-ID: <20041127122950.GB2566@intevation.de>

On Sat, Nov 27, 2004 at 10:40:03AM +0100, Moritz Lennert wrote:
> On Fri, November 26, 2004 9:39, Jan-Oliver Wagner said:
> > on the Thuban users list I posted a info on
> > a extrememly interesting contribution to Thuban.
> > Thanks a lot to Ole Rahn, the main developer!
> >
> > There are a lot of features in this Precision Farming
> > application that could/should be ported into Thuban
> > core or as individual extensions.
> > All stuff, however, is in german language.
> > Any takers welcome.
> 
> If noone else (with more experience) is planning on doing so, I am willing to
> try to extract the csv-import functions as a seperate extension.
> 
> If I have seen correctly this entails mostly removing the hard-coded Pirol csv
> format in order to allow more generic files.

that'll be great. Note that this involves also some work on
MemoryShapestores in case you want to load the data directly into
Thuban.
There is an alternaive of indirectly loading it by first producing s
shapefile formatted file. See gns2shp for an example.

Best

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

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



From cvs at intevation.de  Sat Nov 27 13:54:57 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 13:54:57 +0100 (CET)
Subject: jan: thuban/po hu.po,NONE,1.1 
Message-ID: <20041127125457.D3B8D102BFB@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/po
In directory doto:/tmp/cvs-serv6521

Added Files:
	hu.po 
Log Message:
Hungarian translation. Contributed by Norbert Solymosi.


--- NEW FILE: hu.po ---
# Hungarian Translation for Thuban.
# Copyright (C) 2004 Norbert Solymosi
# This file is distributed under the same license as the Thuban package.
# Norbert Solymosi <Solymosi.Norbert at aotk.szie.hu>, 2004.
#
msgid ""
msgstr ""
"Project-Id-Version: Thuban 1.0.0\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2004-11-27 13:39+0100\n"
"PO-Revision-Date: 2004-11-09 11:31+0100\n"
"Last-Translator: Solymosi Norbert <Solymosi.Norbert at aotk.szie.hu>\n"
"Language-Team: hungarian <Solymosi.Norbert at aotk.szie.hu>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=iso-8859-2\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../Thuban/version.py:180
#, python-format
[...1666 lines suppressed...]

#: ../Thuban/UI/tableview.py:527
msgid "DBF Files (*.dbf)|*.dbf|"
msgstr "DBF-fájlok(*.dbf)|*.dbf|"

#: ../Thuban/UI/tableview.py:528
msgid "CSV Files (*.csv)|*.csv|"
msgstr "CSV-fájlok (*.csv)|*.csv|"

#: ../Thuban/UI/tableview.py:529
msgid "All Files (*.*)|*.*"
msgstr "Minden fájlt (*.*)|*.*"

#: ../Thuban/UI/tree.py:226
msgid "Session"
msgstr "Munkafolyamat"

#: ../Thuban/UI/view.py:289
msgid "Export Map"
msgstr "Térkép exportálása"




From cvs at intevation.de  Sat Nov 27 13:55:39 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 13:55:39 +0100 (CET)
Subject: jan: thuban ChangeLog,1.711,1.712 
Message-ID: <20041127125539.64A53102BFB@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv6546

Modified Files:
	ChangeLog 
Log Message:
added hungarian translation

Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.711
retrieving revision 1.712
diff -u -d -r1.711 -r1.712
--- ChangeLog	26 Nov 2004 11:44:32 -0000	1.711
+++ ChangeLog	27 Nov 2004 12:55:37 -0000	1.712
@@ -1,3 +1,8 @@
+2004-11-27  Jan-Oliver Wagner <jan at intevation.de>
+
+	* po/hu.po: New. Hungarian translation. Contributed
+	by Norbert Solymosi.
+
 2004-11-26  Bernhard Herzog  <bh at intevation.de>
 
 	* Extensions/svgexport/test/test_svgmapwriter.py




From cvs at intevation.de  Sat Nov 27 13:59:53 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 13:59:53 +0100 (CET)
Subject: jan: thuban/po hu.po,NONE,1.1.2.1 
Message-ID: <20041127125953.3C13E102BFB@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/po
In directory doto:/tmp/cvs-serv6591

Added Files:
      Tag: thuban-1-0-branch
	hu.po 
Log Message:
Hungarian translation. Contributed by Norbert Solymosi.


--- NEW FILE: hu.po ---
# Hungarian Translation for Thuban.
# Copyright (C) 2004 Norbert Solymosi
# This file is distributed under the same license as the Thuban package.
# Norbert Solymosi <Solymosi.Norbert at aotk.szie.hu>, 2004.
#
msgid ""
msgstr ""
"Project-Id-Version: Thuban 1.0.0\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2004-11-27 13:56+0100\n"
"PO-Revision-Date: 2004-11-09 11:31+0100\n"
"Last-Translator: Solymosi Norbert <Solymosi.Norbert at aotk.szie.hu>\n"
"Language-Team: hungarian <Solymosi.Norbert at aotk.szie.hu>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=iso-8859-2\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../Thuban/version.py:180
#, python-format
[...1673 lines suppressed...]
#~ msgid "Exit Thuban now"
#~ msgstr "Kilépés a Thubanból most"

#~ msgid "&Top"
#~ msgstr "&Legfelső"

#~ msgid "Put selected layer to the top"
#~ msgstr "Kijelölt réteget a tetejére"

#~ msgid "&Bottom"
#~ msgstr "&Alap"

#~ msgid "Put selected layer to the bottom"
#~ msgstr "Kijelölt réteget a legalulra"

#~ msgid "&Visible"
#~ msgstr "&Látható"

#~ msgid "Toggle visibility of selected layer"
#~ msgstr "A kijelölt réteg láthatóságának kapcsolója?"




From cvs at intevation.de  Sat Nov 27 14:00:33 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 14:00:33 +0100 (CET)
Subject: jan: thuban ChangeLog,1.624.2.9,1.624.2.10 
Message-ID: <20041127130033.79C1C102BFB@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv6625

Modified Files:
      Tag: thuban-1-0-branch
	ChangeLog 
Log Message:
added hungarian translation

Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.624.2.9
retrieving revision 1.624.2.10
diff -u -d -r1.624.2.9 -r1.624.2.10
--- ChangeLog	28 Sep 2004 20:21:53 -0000	1.624.2.9
+++ ChangeLog	27 Nov 2004 13:00:31 -0000	1.624.2.10
@@ -1,3 +1,8 @@
+2004-11-27  Jan-Oliver Wagner <jan at intevation.de>
+
+	* po/hu.po: New. Hungarian translation. Contributed
+	by Norbert Solymosi.
+
 2004-09-28  Jan-Oliver Wagner <jan at intevation.de>
 
 	* Thuban/UI/classgen.py (GenQuantilesPanel.GetList): Fixed




From bh at intevation.de  Sat Nov 27 17:58:24 2004
From: bh at intevation.de (Bernhard Herzog)
Date: Sat, 27 Nov 2004 17:58:24 +0100
Subject: Lots of interesting code in precision farming application
In-Reply-To: <33054.83.134.238.118.1101548403.squirrel@vivegnulinux.homelinux.org>
	(Moritz
	Lennert's message of "Sat, 27 Nov 2004 10:40:03 +0100 (CET)")
References: <20041126083919.GA1743@intevation.de>
	<33054.83.134.238.118.1101548403.squirrel@vivegnulinux.homelinux.org>
Message-ID: <s9zoehj6xfz.fsf@salmakis.intevation.de>

"Moritz Lennert" <mlennert at club.worldonline.be> writes:

> If noone else (with more experience) is planning on doing so, I am willing to
> try to extract the csv-import functions as a seperate extension.

If we add csv import, we should look at the various csv parsers already
written for Python.  Apart from the one in in Ole's code, there are a
few others:

 - cvs.py in the standard library Python 2.3 
   combination of C and Python

 - http://python-dsv.sourceforge.net/ 

   pure python, even has wxPython based import wizard

 - http://www.object-craft.com.au/projects/csv/ 
   written in C

There are probably others.  I haven't really looked at any of them.  I'd
probably prefer the one from the python standard library because that's
the one most likely to be maintained in the future.  TO avoid requiring
python 2.3 we could probably ship a copy with Thuban.

> If I have seen correctly this entails mostly removing the hard-coded
> Pirol csv format in order to allow more generic files.

The ones mentioned are probably more flexible than the PIROL one, though
I haven't really look at that one either yet.

  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From cvs at intevation.de  Sat Nov 27 21:22:40 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 21:22:40 +0100 (CET)
Subject: bernhard: thuban/Extensions/svgexport __init__.py,1.3,1.4 
Message-ID: <20041127202240.28897102BDA@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban/Extensions/svgexport
In directory doto:/tmp/cvs-serv10810/Extensions/svgexport

Modified Files:
	__init__.py 
Log Message:
	* Extensions/svgexport/test/test_svgmapwriter.py:
	Removed Jan from author list as he did not change enough significant
	lines yet.

	* Extensions/svgexport/__init__.py: Added Bernhard as author
	of the Extension.


Index: __init__.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/__init__.py,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- __init__.py	24 Nov 2004 22:35:57 -0000	1.3
+++ __init__.py	27 Nov 2004 20:22:38 -0000	1.4
@@ -25,6 +25,6 @@
 ext_registry.add(ExtensionDesc(
     name = 'SVGexport',
     version = '0.9.0',
-    authors= [ 'Markus Rechtien' ],
+    authors= [ 'Markus Rechtien', 'Bernhard Reiter' ],
     copyright = '2004 Intevation GmbH',
-    desc = _("Export the current map in SVG format.")))
+    desc = _("Export the current map and legend in Thuban-map-SVG format.")))




From cvs at intevation.de  Sat Nov 27 21:22:40 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 21:22:40 +0100 (CET)
Subject: bernhard: thuban ChangeLog,1.712,1.713 
Message-ID: <20041127202240.2B224102BDC@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv10810

Modified Files:
	ChangeLog 
Log Message:
	* Extensions/svgexport/test/test_svgmapwriter.py:
	Removed Jan from author list as he did not change enough significant
	lines yet.

	* Extensions/svgexport/__init__.py: Added Bernhard as author
	of the Extension.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.712
retrieving revision 1.713
diff -u -d -r1.712 -r1.713
--- ChangeLog	27 Nov 2004 12:55:37 -0000	1.712
+++ ChangeLog	27 Nov 2004 20:22:38 -0000	1.713
@@ -1,3 +1,12 @@
+2004-11-27  Bernhard Reiter <bernhard at intevation.de>
+
+	* Extensions/svgexport/test/test_svgmapwriter.py:
+	Removed Jan from author list as he did not change enough significant
+	lines yet.
+
+	* Extensions/svgexport/__init__.py: Added Bernhard as author
+	of the Extension.
+
 2004-11-27  Jan-Oliver Wagner <jan at intevation.de>
 
 	* po/hu.po: New. Hungarian translation. Contributed




From cvs at intevation.de  Sat Nov 27 21:22:40 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 21:22:40 +0100 (CET)
Subject: bernhard: thuban/Extensions/svgexport/test test_svgmapwriter.py, 1.8,
	1.9 
Message-ID: <20041127202240.2CAD6102BEE@lists.intevation.de>

Author: bernhard

Update of /thubanrepository/thuban/Extensions/svgexport/test
In directory doto:/tmp/cvs-serv10810/Extensions/svgexport/test

Modified Files:
	test_svgmapwriter.py 
Log Message:
	* Extensions/svgexport/test/test_svgmapwriter.py:
	Removed Jan from author list as he did not change enough significant
	lines yet.

	* Extensions/svgexport/__init__.py: Added Bernhard as author
	of the Extension.


Index: test_svgmapwriter.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/svgexport/test/test_svgmapwriter.py,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- test_svgmapwriter.py	26 Nov 2004 11:44:32 -0000	1.8
+++ test_svgmapwriter.py	27 Nov 2004 20:22:38 -0000	1.9
@@ -2,7 +2,6 @@
 # Authors:
 # Markus Rechtien <markus at intevation.de> (2004)
 # Bernhard Reiter <bernhard at intevation.de> (2004)
-# Jan-Oliver Wagner <jan at intevation.de> (2004)
 #
 # This program is free software under the GPL (>=v2)
 # Read the file COPYING coming with Thuban for details.




From bernhard at intevation.de  Sat Nov 27 21:27:50 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Sat, 27 Nov 2004 21:27:50 +0100
Subject: jan: thuban/po hu.po,NONE,1.1
In-Reply-To: <20041127125457.D3B8D102BFB@lists.intevation.de>
References: <20041127125457.D3B8D102BFB@lists.intevation.de>
Message-ID: <20041127202750.GA20215@intevation.de>

On Sat, Nov 27, 2004 at 01:54:57PM +0100, cvs at intevation.de wrote:
> Added Files:
> 	hu.po 
> Log Message:
> Hungarian translation. Contributed by Norbert Solymosi.

I think you missed added Norbert to the translator's credits?
-------------- 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-devel/attachments/20041127/5fc3e794/attachment.bin

From cvs at intevation.de  Sat Nov 27 22:30:40 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 22:30:40 +0100 (CET)
Subject: jan: thuban/Thuban/UI about.py,1.11,1.11.2.1 
Message-ID: <20041127213040.AD1B3102BDA@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Thuban/UI
In directory doto:/tmp/cvs-serv11480

Modified Files:
      Tag: thuban-1-0-branch
	about.py 
Log Message:
(About.__init__): Added unicode2Locale use.
Added author for Hungarian translation.
(unicodeToLocale): New. Convert Unicode to Locale encoding.


Index: about.py
===================================================================
RCS file: /thubanrepository/thuban/Thuban/UI/about.py,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -d -r1.11 -r1.11.2.1
--- about.py	3 Feb 2004 19:12:03 -0000	1.11
+++ about.py	27 Nov 2004 21:30:38 -0000	1.11.2.1
@@ -1,4 +1,4 @@
-# Copyright (c) 2001, 2002, 2003 by Intevation GmbH
+# Copyright (c) 2001-2004 by Intevation GmbH
 # Authors:
 # Jonathan Coles <jonathan at intevation.de>
 #
@@ -13,6 +13,8 @@
 
 from wxPython.wx import *
 
+from locale import getlocale
+
 from Thuban import _
 from Thuban.version import versions
 from Thuban.Model.resource import gdal_support_status
@@ -32,9 +34,11 @@
         # characters to get byte strings in latin1.
         lead_developer = 'Bernhard Herzog'
         developers = [ 'Jonathan Coles', 'Frank Koormann',
-                       'Martin M\xfcller', 'Jan-Oliver Wagner' ]
+                       unicodeToLocale(u'Martin M\xfcller'),
+                       'Jan-Oliver Wagner' ]
         translators = [ ( _('French'), 'Daniel Calvelo Aros' ),
-                        ( _('German'), 'Bj\xf6rn Broscheit'),
+                        ( _('German'), unicodeToLocale(u'Bj\xf6rn Broscheit')),
+                        ( _('Hungarian'), 'Norbert Solymosi'),
                         ( _('Italian'), 'Maurizio Napolitano'),
                         ( _('Portuguese (Brazilian)'), 'Eduardo Patto Kanegae'),
                         ( _('Russian'), 'Alex Shevlakov'),
@@ -96,7 +100,7 @@
 
         text_title = wxStaticText(self, -1, 
             _("Thuban is a program for exploring geographic data.\n\n") +
-            "Copyright 2001-2003 Intevation GmbH.\n" +
+            "Copyright 2001-2004 Intevation GmbH.\n" +
             _("Thuban is licensed under the GNU GPL"),
                                   style=wxST_NO_AUTORESIZE|wxALIGN_CENTRE)
 
@@ -126,3 +130,7 @@
         self.EndModal(wxID_CANCEL)
 
 
+def unicodeToLocale(unicodeStr):
+    "Function to convert unicode to the user's locale encoding"
+
+    return unicodeStr.encode(getlocale()[1])




From cvs at intevation.de  Sat Nov 27 22:31:09 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 22:31:09 +0100 (CET)
Subject: jan: thuban ChangeLog,1.624.2.10,1.624.2.11 
Message-ID: <20041127213109.A34CA102BDA@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv11516

Modified Files:
      Tag: thuban-1-0-branch
	ChangeLog 
Log Message:
New translation and backport of encoding unicode/locale.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.624.2.10
retrieving revision 1.624.2.11
diff -u -d -r1.624.2.10 -r1.624.2.11
--- ChangeLog	27 Nov 2004 13:00:31 -0000	1.624.2.10
+++ ChangeLog	27 Nov 2004 21:31:07 -0000	1.624.2.11
@@ -1,5 +1,13 @@
 2004-11-27  Jan-Oliver Wagner <jan at intevation.de>
 
+	New translation and backport of encoding unicode/locale.
+
+	* Thuban/UI/about.py (About.__init__): Added unicode2Locale use.
+	Added author for Hungarian translation.
+	(unicodeToLocale): New. Convert Unicode to Locale encoding.
+
+2004-11-27  Jan-Oliver Wagner <jan at intevation.de>
+
 	* po/hu.po: New. Hungarian translation. Contributed
 	by Norbert Solymosi.
 




From cvs at intevation.de  Sat Nov 27 22:40:03 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 22:40:03 +0100 (CET)
Subject: jan: thuban/Thuban/UI about.py,1.16,1.17 
Message-ID: <20041127214003.2B115102BDA@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban/Thuban/UI
In directory doto:/tmp/cvs-serv11605

Modified Files:
	about.py 
Log Message:
(About.__init__): Added Norbert Solymosi for hungarian translation and
Ole Rahn as contrbutor. Moved Bernhard Reiter from Contributor
to Developer.


Index: about.py
===================================================================
RCS file: /thubanrepository/thuban/Thuban/UI/about.py,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- about.py	28 Sep 2004 19:17:14 -0000	1.16
+++ about.py	27 Nov 2004 21:40:01 -0000	1.17
@@ -37,16 +37,21 @@
         # Note: The source code is in ASCII, so we escape some
         # characters to get byte strings in latin1.
         lead_developer = 'Bernhard Herzog'
-        developers = [ 'Jonathan Coles', 'Frank Koormann',
-                       unicodeToLocale(u'Martin M\xfcller'), 'Jan-Oliver Wagner' ]
+        developers = [ 'Jonathan Coles',
+                       'Frank Koormann',
+                       unicodeToLocale(u'Martin M\xfcller'),
+                       'Bernhard Reiter',
+                       'Jan-Oliver Wagner' ]
         translators = [ ( _('French'), 'Daniel Calvelo Aros' ),
                         ( _('German'), unicodeToLocale(u'Bj\xf6rn Broscheit')),
+                        ( _('Hungarian'), 'Norbert Solymosi'),
                         ( _('Italian'), 'Maurizio Napolitano'),
                         ( _('Portuguese (Brazilian)'), 'Eduardo Patto Kanegae'),
                         ( _('Russian'), 'Alex Shevlakov'),
                         ( _('Spanish'), 'Daniel Calvelo Aros') ]
-        other_contributors = [ 'Jonathan Byron', 'Silke Reimer',
-                               'Bernhard Reiter' ]
+        other_contributors = [ 'Jonathan Byron',
+                               'Ole Rahn',
+                               'Silke Reimer' ]
         dyn_modules = [ ('wxPython', versions['wxPython']),
                         ('Python',   versions['python']),
                         ('PySQLite', versions['pysqlite']),




From cvs at intevation.de  Sat Nov 27 22:44:53 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Sat, 27 Nov 2004 22:44:53 +0100 (CET)
Subject: jan: thuban ChangeLog,1.713,1.714 
Message-ID: <20041127214453.3EC0D102BDA@lists.intevation.de>

Author: jan

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv11675

Modified Files:
	ChangeLog 
Log Message:
More people to give credits.


Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.713
retrieving revision 1.714
diff -u -d -r1.713 -r1.714
--- ChangeLog	27 Nov 2004 20:22:38 -0000	1.713
+++ ChangeLog	27 Nov 2004 21:44:51 -0000	1.714
@@ -1,3 +1,10 @@
+2004-11-27  Jan-Oliver Wagner <jan at intevation.de>
+
+	* Thuban/UI/about.py (About.__init__): Added
+	Norbert Solymosi for hungarian translation and Ole Rahn
+	as contrbutor. Moved Bernhard Reiter from Contributor
+	to Developer.
+
 2004-11-27  Bernhard Reiter <bernhard at intevation.de>
 
 	* Extensions/svgexport/test/test_svgmapwriter.py:




From jan at intevation.de  Sat Nov 27 22:52:22 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Sat, 27 Nov 2004 22:52:22 +0100
Subject: [Thuban-devel] Re: jan: thuban/po hu.po,NONE,1.1
In-Reply-To: <20041127202750.GA20215@intevation.de>
References: <20041127125457.D3B8D102BFB@lists.intevation.de>
	<20041127202750.GA20215@intevation.de>
Message-ID: <20041127215222.GA19137@intevation.de>

On Sat, Nov 27, 2004 at 09:27:50PM +0100, Bernhard Reiter wrote:
> On Sat, Nov 27, 2004 at 01:54:57PM +0100, cvs at intevation.de wrote:
> > Added Files:
> > 	hu.po 
> > Log Message:
> > Hungarian translation. Contributed by Norbert Solymosi.
> 
> I think you missed added Norbert to the translator's credits?

No, I changed the website first and then my little son needed
some attention (it is saturday). The patch was there and is
now commited (even before I read your email).

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

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



From bernhard at intevation.de  Sun Nov 28 01:09:57 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Sun, 28 Nov 2004 01:09:57 +0100
Subject: [Thuban-devel] Re: jan: thuban/po hu.po,NONE,1.1
In-Reply-To: <20041127215222.GA19137@intevation.de>
References: <20041127125457.D3B8D102BFB@lists.intevation.de>
	<20041127202750.GA20215@intevation.de>
	<20041127215222.GA19137@intevation.de>
Message-ID: <20041128000957.GF20215@intevation.de>

On Sat, Nov 27, 2004 at 10:52:22PM +0100, Jan-Oliver Wagner wrote:
> On Sat, Nov 27, 2004 at 09:27:50PM +0100, Bernhard Reiter wrote:
> > On Sat, Nov 27, 2004 at 01:54:57PM +0100, cvs at intevation.de wrote:
> > > Added Files:
> > > 	hu.po 
> > > Log Message:
> > > Hungarian translation. Contributed by Norbert Solymosi.
> > 
> > I think you missed added Norbert to the translator's credits?
> 
> No, I changed the website first and then my little son needed
> some attention (it is saturday). The patch was there and is
> now commited (even before I read your email).

Cool.
I justed wanted to make sure it isn't forgotten,
because I somehow thought the change would come in one commit.
-------------- 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-devel/attachments/20041128/dd11c2ad/attachment.bin

From jan at intevation.de  Mon Nov 29 09:46:55 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Mon, 29 Nov 2004 09:46:55 +0100
Subject: [Thuban-devel] Re: jan: thuban/po hu.po,NONE,1.1
In-Reply-To: <20041128000957.GF20215@intevation.de>
References: <20041127125457.D3B8D102BFB@lists.intevation.de>
	<20041127202750.GA20215@intevation.de>
	<20041127215222.GA19137@intevation.de>
	<20041128000957.GF20215@intevation.de>
Message-ID: <20041129084655.GA5967@intevation.de>

On Sun, Nov 28, 2004 at 01:09:57AM +0100, Bernhard Reiter wrote:
> On Sat, Nov 27, 2004 at 10:52:22PM +0100, Jan-Oliver Wagner wrote:
> > On Sat, Nov 27, 2004 at 09:27:50PM +0100, Bernhard Reiter wrote:
> > > On Sat, Nov 27, 2004 at 01:54:57PM +0100, cvs at intevation.de wrote:
> > > > Added Files:
> > > > 	hu.po 
> > > > Log Message:
> > > > Hungarian translation. Contributed by Norbert Solymosi.
> > > 
> > > I think you missed added Norbert to the translator's credits?
> > 
> > No, I changed the website first and then my little son needed
> > some attention (it is saturday). The patch was there and is
> > now commited (even before I read your email).
> 
> Cool.
> I justed wanted to make sure it isn't forgotten,
> because I somehow thought the change would come in one commit.

yes, I planned to do so. But the utf8tolocale backport came up
and I wanted to test this carefully first. So I cheked in
what I already had.

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

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



From mlennert at club.worldonline.be  Mon Nov 29 11:44:32 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon, 29 Nov 2004 11:44:32 +0100 (CET)
Subject: csv-import (was:Re: [Thuban-devel] Re: Lots of interesting code in 
 precision farming application)
Message-ID: <33003.164.15.134.161.1101725072.squirrel@vivegnulinux.homelinux.org>

Dear Jan and Bernhard,

On Sat, November 27, 2004 13:29, Jan-Oliver Wagner said:
> On Sat, Nov 27, 2004 at 10:40:03AM +0100, Moritz Lennert wrote:
>>
>> If noone else (with more experience) is planning on doing so, I am willing to
>> try to extract the csv-import functions as a seperate extension.
>
> that'll be great. Note that this involves also some work on
> MemoryShapestores in case you want to load the data directly into Thuban.
> There is an alternaive of indirectly loading it by first producing s
shapefile formatted file. See gns2shp for an example.
>

There is a form of MemoryShapestores in Ole's code if I am not mistaken. I
think this is the way to go. Having to create new shapefiles is not very
elegant in my opinion. Thuban should be able to load the new data directly.

But I guess we should agree on one implementation of a MemoryShapestore. This
is up to you developers to decide, as I don't know/understand the code enough
to decide this.



On Sat, November 27, 2004 17:58, Bernhard Herzog said:
> "Moritz Lennert" <mlennert at club.worldonline.be> writes:
>
>> If noone else (with more experience) is planning on doing so, I am willing to
>> try to extract the csv-import functions as a seperate extension.
>
> If we add csv import, we should look at the various csv parsers already
written for Python.  Apart from the one in in Ole's code, there are a few
others:
>
>  - cvs.py in the standard library Python 2.3
>    combination of C and Python
>
>  - http://python-dsv.sourceforge.net/
>
>    pure python, even has wxPython based import wizard
>
>  - http://www.object-craft.com.au/projects/csv/
>    written in C
>
> There are probably others.  I haven't really looked at any of them.  I'd
probably prefer the one from the python standard library because that's the
one most likely to be maintained in the future.  TO avoid requiring python
2.3 we could probably ship a copy with Thuban.

I agree with you that cvs.py looks like the best solution. However, this would
probably mean writing most of the extension from scratch and not taking much
of Ole's code, or ?

>
>> If I have seen correctly this entails mostly removing the hard-coded Pirol
csv format in order to allow more generic files.
>
> The ones mentioned are probably more flexible than the PIROL one, though I
haven't really look at that one either yet.

Yes, I agree. I'll look into them a bit deeper in order to see how to approach
the entire question.

For now, I have just extracted the code and modules necessary in order to have
a very roughly functioning csv-import. You can download it at

http://moritz.homelinux.org/thuban/csvimport.tgz

I changed the code so that the csv file does not have to contain units anymore
(in my eyes this should be handled via the projection properties). At this
stage I have just included all the modules that are necessary because of
series of dependencies. I am sure that much of the code is not necessary for
the csv import.

I also think that ideally the user should not be bothered with having to tell
the module which types the different data elements are in. I will see if some
sort of automatic recognition cannot just be done with python's type()
function.

In the current form of the extension, the csv file must have the following
format:

line 1: column headers
line2: column variable types (one of 'int', 'double' or 'string')
lines3-EOF: data

The separator can be tabulation, comma, semicolon and space.

Moritz




From mlennert at club.worldonline.be  Mon Nov 29 23:15:31 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon, 29 Nov 2004 23:15:31 +0100 (CET)
Subject: csv-import (was:Re: [Thuban-devel] Re: Lots of interesting 
 code in  precision farming application)
In-Reply-To: <33003.164.15.134.161.1101725072.squirrel@vivegnulinux.homelinux.org>
References: <33003.164.15.134.161.1101725072.squirrel@vivegnulinux.homelinux.org>
Message-ID: <33686.83.134.243.86.1101766531.squirrel@vivegnulinux.homelinux.org>

Replying to myself in order to complement what I said:

On Mon, November 29, 2004 11:44, Moritz Lennert said:
> Dear Jan and Bernhard,
>
> On Sat, November 27, 2004 13:29, Jan-Oliver Wagner said:
>> On Sat, Nov 27, 2004 at 10:40:03AM +0100, Moritz Lennert wrote:
>>>
>>> If noone else (with more experience) is planning on doing so, I am willing
>>> to
>>> try to extract the csv-import functions as a seperate extension.
>>
>> that'll be great. Note that this involves also some work on
>> MemoryShapestores in case you want to load the data directly into Thuban.
>> There is an alternaive of indirectly loading it by first producing s
> shapefile formatted file. See gns2shp for an example.
>>
>
> There is a form of MemoryShapestores in Ole's code if I am not mistaken. I
> think this is the way to go. Having to create new shapefiles is not very
> elegant in my opinion. Thuban should be able to load the new data directly.
>
> But I guess we should agree on one implementation of a MemoryShapestore. This
> is up to you developers to decide, as I don't know/understand the code enough
> to decide this.
>



The MemoryShapeStore in Ole's Code is in data_fake.py. To my innocent eyes it
looks quite complete and self-contained (the import from punkt is actually not
needed).

But again: it is up to you to decide on one single implementation. And I would
need this decision in order to continue working on a new csv import extension.

>
>
> On Sat, November 27, 2004 17:58, Bernhard Herzog said:
>> "Moritz Lennert" <mlennert at club.worldonline.be> writes:
>>
>> There are probably others.  I haven't really looked at any of them.  I'd
> probably prefer the one from the python standard library because that's the
> one most likely to be maintained in the future.  TO avoid requiring python
> 2.3 we could probably ship a copy with Thuban.
>
> I agree with you that cvs.py looks like the best solution. However, this would
> probably mean writing most of the extension from scratch and not taking much
> of Ole's code, or ?

I've looked at csv.py in more detail and I like it a lot, especially because
of the apprarently very flexible automatic file format recognition which
should allow reading most csv formats.

I could imagine a first step of just parsing a csv file and writing a new
MemoryShape. This should be quite easy with an existing MemoryShapeStore and
csv.py.

Then in a second step we could write an import wizard for fine-tuning the
import if necessary.

Moritz



From O.Rahn at fh-osnabrueck.de  Tue Nov 30 10:25:02 2004
From: O.Rahn at fh-osnabrueck.de (Ole Rahn)
Date: Tue, 30 Nov 2004 10:25:02 +0100
Subject: csv-import (was:Re: [Thuban-devel] Re: Lots of interesting code in
 precision farming application)
Message-ID: <41AC3C6E.8000105@fh-osnabrueck.de>

Hi Moritz,

as far as I remember, you're right: The CSV Reader should be quite 
independent of the rest of the Precision Farming Extension, BUT the 
MemoryShape isn't ... anymore.

In order to allow deletion of shapes from a MemoryShapeStore, I had to 
alter the MemoryTable (Thuban/Model/table.py). The reason for that is 
the sequential order of attribute data inside this table. If you remove 
random shapes, you have to keep track of which rows were deleted or else 
all data will get deranged...

In order to prevent you from having to search for missing methods there 
are two ways to proceed:
1) I can send you a version of the MemoryShapeStore without deletion 
functions -> no dependency of an altered table.py
2) Here is a diff between a mostly (except for maybe some console 
print-outs) unchanged Thuban 1.0.0 version of table.py and the PIROL one 
- in case you want to use the MemoryShapeStore with its "extended" 
functions... :

Index: table.py
===================================================================
RCS file: /CVS/cvsrepo/thuban/Thuban/Model/table.py,v
retrieving revision 1.4
retrieving revision 1.9
diff -r1.4 -r1.9
14c14
< __version__ = "$Revision: 1.4 $"
---
 > __version__ = "$Revision: 1.9 $"
271a272,295
 >            
 >         self.deletedRows = []
 >        
 >     def removeRow( self, index, row_is_ordinal = 0):
 >         oldIndex = index
 >         if ( not row_is_ordinal ):
 >             index = self.RowIdToOrdinal( index )
 >
 >         #print "removeRow():", index, self.NumRows()
 >         if ( index < self.NumRows() and index > -1):
 >             self.data.remove( self.data[index] )
 >             self.deletedRows.append( oldIndex )
 >             #print "removed:", index
 >             return True
 >            
 >         return False
 >        
 >     def appendRow( self, data, id=-1 ):
 > #        if ( id == -1 ):
 > #            id = self.NumRows()
 >            
 >         self.data.append( data )
 >        
 >        
300a325,333
 >     def _getDeletedBelow( self, gid ):
 >         differenz = 0
 >         for deleted in self.deletedRows:
 >             if ( deleted < gid ):
 >                 #print "-",deleted
 >                 differenz += 1
 >                
 >         return differenz
 >        
307c340,341
<         return gid
---
 >         #print "RowIdToOrdinal():", gid, gid - self._getDeletedBelow(gid)
 >         return gid - self._getDeletedBelow(gid)
315c349
<         return num
---
 >         return num + self._getDeletedBelow(num) +1
325c359,363
<         return self.data[row][self.column_map[col].index]
---
 >         if ( not row_is_ordinal ):
 >             #print "row", row, "col", col, "value", 
self.data[self.RowIdToOrdinal(row)][self.column_map[col].index]
 >             return 
self.data[self.RowIdToOrdinal(row)][self.column_map[col].index]
 >         else:
 >             return self.data[row][self.column_map[col].index]
333c371,375
<         return dict([(col.name, self.data[index][col.index])
---
 >         if ( not row_is_ordinal ):
 >             return dict([(col.name, 
self.data[self.RowIdToOrdinal(index)][col.index])
 >                       for col in self.columns])
 >         else:
 >             return dict([(col.name, self.data[index][col.index])


I hope this helps!
Also, if there is anything I can help you with while trying to decrypt 
our code, let me know. I'll be happy to help.


Best regards

Ole



From mlennert at club.worldonline.be  Tue Nov 30 10:43:10 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue, 30 Nov 2004 10:43:10 +0100 (CET)
Subject: csv-import (was:Re: [Thuban-devel] Re: Lots of interesting 
 code in precision farming application)
In-Reply-To: <41AC3C6E.8000105@fh-osnabrueck.de>
References: <41AC3C6E.8000105@fh-osnabrueck.de>
Message-ID: <33319.164.15.134.161.1101807790.squirrel@vivegnulinux.homelinux.org>

Hi Ole,

On Tue, November 30, 2004 10:25, Ole Rahn said:
> Hi Moritz,
>
> as far as I remember, you're right: The CSV Reader should be quite
> independent of the rest of the Precision Farming Extension, BUT the
> MemoryShape isn't ... anymore.
>
> In order to allow deletion of shapes from a MemoryShapeStore, I had to
> alter the MemoryTable (Thuban/Model/table.py). The reason for that is
> the sequential order of attribute data inside this table. If you remove
> random shapes, you have to keep track of which rows were deleted or else
> all data will get deranged...
>
> In order to prevent you from having to search for missing methods there
> are two ways to proceed:
> 1) I can send you a version of the MemoryShapeStore without deletion
> functions -> no dependency of an altered table.py
> 2) Here is a diff between a mostly (except for maybe some console
> print-outs) unchanged Thuban 1.0.0 version of table.py and the PIROL one
> - in case you want to use the MemoryShapeStore with its "extended"
> functions... :

I don't think that for a csv-import we need the ability to remove shapes, so
the question of whether there are deletion functions or not, should not change
anything for the code used in a csv-import extension. The csv-import code I
have already extracted in order to create a separate "demo"-extension - using
your MemoryShapeStore - seems to work without a problem with an unmodified
cvs-version of Thuban.

So, the question actually is whether Thuban will integrate your
MemoryShapeStore implementation or another one. I'd rather not have to include
an entire MemoryShapeStore in the extension. It would be better to include it
into the core of Thuban and make it usable for extensions. So before coding
the extension, I would need to know the interface to the "official"
MemoryShapeStore.

>
> I hope this helps!
> Also, if there is anything I can help you with while trying to decrypt
> our code, let me know. I'll be happy to help.
>

Thank you !

Moritz



From bernhard at intevation.de  Tue Nov 30 14:19:11 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 30 Nov 2004 14:19:11 +0100
Subject: csv-import
In-Reply-To: <33686.83.134.243.86.1101766531.squirrel@vivegnulinux.homelinux.org>
References: <33003.164.15.134.161.1101725072.squirrel@vivegnulinux.homelinux.org>
	<33686.83.134.243.86.1101766531.squirrel@vivegnulinux.homelinux.org>
Message-ID: <20041130131911.GE5778@intevation.de>

On Mon, Nov 29, 2004 at 11:15:31PM +0100, Moritz Lennert wrote:
> On Mon, November 29, 2004 11:44, Moritz Lennert said:

> > But I guess we should agree on one implementation of a
> > MemoryShapestore. This is up to you developers to decide, as I
> > don't know/understand the code enough to decide this.
> 
> The MemoryShapeStore in Ole's Code is in data_fake.py. To my innocent eyes it
> looks quite complete and self-contained (the import from punkt is actually not
> needed).
> 
> But again: it is up to you to decide on one single implementation.
> And I would need this decision in order to continue working on a
> new csv import extension.

Look at this froma distance it might make sense to separate the issues
to not stop anybody from improving the situation and getting more
experiences.

The problem with a memory only store of geographic objects
probably is the interface and secondly the implementation.
So you could just use any implementation to get started
and later we change it as long as the interface stays the same.

And as I believe it will take us a while to get to a really nice interface
we can use the experiences made by working code for this.


> I've looked at csv.py in more detail and I like it a lot, especially because
> of the apprarently very flexible automatic file format recognition which
> should allow reading most csv formats.
> 
> I could imagine a first step of just parsing a csv file and writing a new
> MemoryShape. This should be quite easy with an existing MemoryShapeStore and
> csv.py.
> 
> Then in a second step we could write an import wizard for fine-tuning the
> import if necessary.

Sounds good to me.
-------------- 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-devel/attachments/20041130/f533d36d/attachment.bin

From mlennert at club.worldonline.be  Tue Nov 30 14:44:40 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue, 30 Nov 2004 14:44:40 +0100 (CET)
Subject: csv-import
In-Reply-To: <20041130131911.GE5778@intevation.de>
References: <33003.164.15.134.161.1101725072.squirrel@vivegnulinux.homelinux.org>
	<33686.83.134.243.86.1101766531.squirrel@vivegnulinux.homelinux.org>
	<20041130131911.GE5778@intevation.de>
Message-ID: <33801.164.15.134.161.1101822280.squirrel@vivegnulinux.homelinux.org>

On Tue, November 30, 2004 14:19, Bernhard Reiter said:
> The problem with a memory only store of geographic objects
> probably is the interface and secondly the implementation.
> So you could just use any implementation to get started
> and later we change it as long as the interface stays the same.
>
> And as I believe it will take us a while to get to a really nice interface
> we can use the experiences made by working code for this.
>

Ok, then I will just use Ole's code for now. Even if the interface changes, it
shouldn't be too much work to adapt one extension to a new interface.

Moritz



From cvs at intevation.de  Tue Nov 30 17:56:52 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Tue, 30 Nov 2004 17:56:52 +0100 (CET)
Subject: joey: thuban/Extensions/wms/test test_ogclib.py,1.7,1.8 
Message-ID: <20041130165652.EB26E102C25@lists.intevation.de>

Author: joey

Update of /thubanrepository/thuban/Extensions/wms/test
In directory doto:/tmp/cvs-serv25244

Modified Files:
	test_ogclib.py 
Log Message:
Improved the test for the internal compare method

Index: test_ogclib.py
===================================================================
RCS file: /thubanrepository/thuban/Extensions/wms/test/test_ogclib.py,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- test_ogclib.py	13 Aug 2004 16:18:46 -0000	1.7
+++ test_ogclib.py	30 Nov 2004 16:56:50 -0000	1.8
@@ -96,20 +96,36 @@
     def test_compareURLs(self):
         """Perform some tests for own compare routine"""
 
+        # Compare same base URL
         result = "http://frida.intevation.org/cgi-bin"
         self.compare_URLs("http://frida.intevation.org/cgi-bin", result)
 
+        # Compare different base URL with same length
+        self.assertRaises(AssertionError, self.compare_URLs, "http://frida.intevation.org/cgi-lib", result)
+
+        # Compare same bse with one argument
         result = "http://frida.intevation.org/cgi-bin?foo=eins"
         self.compare_URLs("http://frida.intevation.org/cgi-bin?foo=eins", result)
 
-        result = "http://frida.intevation.org/cgi-bin?foo=eins&bar=zwei"
-        self.compare_URLs("http://frida.intevation.org/cgi-bin?foo=eins&bar=zwei", result)
+        # Compare same base URL differnt first argument
+        self.assertRaises(AssertionError, self.compare_URLs, "http://frida.intevation.org/cgi-bin?bar=eins", result)
 
+        # Compare same base with two arguments
         result = "http://frida.intevation.org/cgi-bin?foo=eins&bar=zwei"
+        self.compare_URLs("http://frida.intevation.org/cgi-bin?foo=eins&bar=zwei", result)
         self.compare_URLs("http://frida.intevation.org/cgi-bin?bar=zwei&foo=eins", result)
 
+        # Compare same base with different two arguments
+        self.assertRaises(AssertionError, self.compare_URLs, "http://frida.intevation.org/cgi-bin?foo=zwei&bar=eins", result)
+
+        # Compare same base with three arguments
         result = "http://frida.intevation.org/cgi-bin?foo=eins&bar=zwei&baz=jan&quux=tux"
+        self.compare_URLs("http://frida.intevation.org/cgi-bin?foo=eins&bar=zwei&baz=jan&quux=tux", result)
         self.compare_URLs("http://frida.intevation.org/cgi-bin?baz=jan&bar=zwei&quux=tux&foo=eins", result)
+
+        # Compare same base with different three arguments
+        testurl = "http://frida.intevation.org/cgi-bin?baz=jan&foo=zwei&quux=tux&bar=eins"
+        self.assertRaises(AssertionError, self.compare_URLs, testurl, result)
 
 
     def test_CapabilityURL(self):




From cvs at intevation.de  Tue Nov 30 17:59:03 2004
From: cvs at intevation.de (cvs@intevation.de)
Date: Tue, 30 Nov 2004 17:59:03 +0100 (CET)
Subject: joey: thuban ChangeLog,1.714,1.715 
Message-ID: <20041130165903.17CD9102C25@lists.intevation.de>

Author: joey

Update of /thubanrepository/thuban
In directory doto:/tmp/cvs-serv25312

Modified Files:
	ChangeLog 
Log Message:
Improved the test for the internal compare method

Index: ChangeLog
===================================================================
RCS file: /thubanrepository/thuban/ChangeLog,v
retrieving revision 1.714
retrieving revision 1.715
diff -u -d -r1.714 -r1.715
--- ChangeLog	27 Nov 2004 21:44:51 -0000	1.714
+++ ChangeLog	30 Nov 2004 16:59:01 -0000	1.715
@@ -1,3 +1,8 @@
+2004-11-30  Martin Schulze  <joey at infodrom.org>
+
+	* Extensions/wms/test/test_ogclib.py (TestOGCLib.test_compareURLs):
+	Improved the test for the internal compare method
+
 2004-11-27  Jan-Oliver Wagner <jan at intevation.de>
 
 	* Thuban/UI/about.py (About.__init__): Added




From jan at intevation.de  Tue Nov 30 22:42:12 2004
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Tue, 30 Nov 2004 22:42:12 +0100
Subject: [Thuban-devel] Re: Support for bitmap image formats
In-Reply-To: <20041115175731.GA1401@finlandia.infodrom.north.de>
References: <20040410172407.GD1655@finlandia.infodrom.north.de>
	<20041115175731.GA1401@finlandia.infodrom.north.de>
Message-ID: <20041130214212.GC16803@intevation.de>

On Mon, Nov 15, 2004 at 06:57:31PM +0100, Martin Schulze wrote:
> Martin Schulze wrote:
> > is there a reason the render engine is limited to support only JPEG
> > and BMP?  The wxWidgets library seems to support more image formats,
> > such as commonly used TIFF, PNG, GIF, or less commonly used PNM, PCX,
> > XBM and XPM, just to name some.
> > 
> > I've just tested whether the engine can handle PNG, TIFF and GIF,
> > which worked fine.  I know that's not a proof, but only a
> > circumstantial evidence.
> 
> Here's further research:
> 
>   <http://www.wxwindows.org/feature2.htm> -- wxWidgets 2 Features
>   
>   XPM is implemented on Unix and Windows; and PNG is implemented on both.
>   
>   The wxImage class can load JPEG, TIFF, PCX, GIF, PNM and BMP files and
>   can also rotate and scale images. wxImage is a platform-independent
>   class with emphasis on loading multiple image formats, whereas
>   wxBitmap wraps the appropriate platform-dependent bitmap.
>   
> Hence, it should be fine to enable PNG, TIFF and GIF since they
> are supported on both Unix and Windows.

I think the patch is good.
I don't see a reason why not apply it.

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

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