From Silke.Reimer at intevation.de Mon Jan 3 11:19:45 2005 From: Silke.Reimer at intevation.de (Silke Reimer) Date: Mon, 3 Jan 2005 11:19:45 +0100 Subject: a question about my mapviewer program In-Reply-To: <16849.47143.624926.347698@desk.crynwr.com> References: <16848.24146.258982.334379@desk.crynwr.com> <20041227193738.GT1497@intevation.de> <16849.47143.624926.347698@desk.crynwr.com> Message-ID: <20050103101945.GE17871@intevation.de> On Tue, Dec 28, 2004 at 02:46:47PM -0500, Russell Nelson wrote: > Bernhard Reiter writes: > > For the sake of the FreeGIS community, a release certainly is nice > > or is there CVS access? ;) > > I'll do a release soonest. > > > 3) > > The Thuban maintainer are interested in editing layers. > > We even have an experimental drawshape extension, also see > > the road map: http://thuban.intevation.org/roadmap.html > > Excellent. May I suggest that Extensions/drawshape/patch.diff be > applied to HEAD? It looks like a useful patch for any Extension which > needs to use the right mouse button. > > > 1) > > Usually dependencies are handled by packaging system, I have heard > > fedora has a nice one. We made Thuban available on it, so usually > > this is not a hassle for users. On the technological point of view: > > depending on well developed libraries makes your application more robust. > > Yesbut ... those libraries don't come with Fedora by default, and > aren't published on fedora.us. This is right. They are not yet Fedora by default but we are only talking about two packages: proj (which has already status of 'resolved pending' meaning that it will come into Fedora in short time) and python-sqlite which has been package for Fedora and announced on fedora.us (see [1]). Silke [1] https://bugzilla.fedora.us/show_bug.cgi?id=2000 -- Intevation GmbH Georgstrasse 4 49074 Osnabr?ck, Germany http://intevation.de http://intevation.de/~silke FreeGIS.org http://freegis.org/ -------------- 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/20050103/2f9ae44f/attachment.bin From bernhard at intevation.de Mon Jan 3 17:11:30 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 3 Jan 2005 17:11:30 +0100 Subject: a question about my mapviewer program In-Reply-To: <16849.47143.624926.347698@desk.crynwr.com> References: <16848.24146.258982.334379@desk.crynwr.com> <20041227193738.GT1497@intevation.de> <16849.47143.624926.347698@desk.crynwr.com> Message-ID: <20050103161130.GF10243@intevation.de> On Tue, Dec 28, 2004 at 02:46:47PM -0500, Russell Nelson wrote: > Bernhard Reiter writes: > > For the sake of the FreeGIS community, a release certainly is nice > > or is there CVS access? ;) > > I'll do a release soonest. > > > 3) > > The Thuban maintainer are interested in editing layers. > > We even have an experimental drawshape extension, also see > > the road map: http://thuban.intevation.org/roadmap.html > > Excellent. May I suggest that Extensions/drawshape/patch.diff be > applied to HEAD? It looks like a useful patch for any Extension which > needs to use the right mouse button. Bernhard H. had a special reason for not applying it directly, I believe. -------------- 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/20050103/684012de/attachment.bin From bernhard at intevation.de Mon Jan 3 17:17:30 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 3 Jan 2005 17:17:30 +0100 Subject: grid for finite elements In-Reply-To: <16849.46590.696100.983973@desk.crynwr.com> References: <16848.24146.258982.334379@desk.crynwr.com> <41D06679.2080109@noaa.gov> <20041228104414.GB3637@intevation.de> <41D1A32F.5080907@noaa.gov> <16849.46590.696100.983973@desk.crynwr.com> Message-ID: <20050103161730.GG10243@intevation.de> On Tue, Dec 28, 2004 at 02:37:34PM -0500, Russell Nelson wrote: > Chris Barker writes: > > 2) A tool that will let me create and manipulate a finite element grid, > > on top of a raster image and/or a vector map in a custom format. I have > > code that does the triangulation and all, I just need a way to > > manipulate points and display the resulting triangles. > > Hmmm.... You'll need a specialized layer renderer for that, not to > mention an editor. Still, if you're familiar with wxPython, I'd say > it's a no-brainer. Actually I shaw a similiar grid, by triangularisation in the precision farming addition mostly done by Ole Rahn. You can get the code from: http://thuban.intevation.org/download.html#contrib We could not directly integrate it, but still it might inspire you. -------------- 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/20050103/0430de3c/attachment.bin From thuban-bugs at intevation.de Mon Jan 3 17:19:33 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Mon, 3 Jan 2005 17:19:33 +0100 (CET) Subject: [bug #2883] (thuban) Identify/Search: KeyError on unclassified point layers Message-ID: <20050103161933.8B748102BD5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2883 ------------------------------------------------------------------------- Subject: Identify/Search: KeyError on unclassified point layers Thuban Version: CVS as of 2005-01-03 16:00 GMT Performing Identify or Search on unclassified point layers causes a KeyError: Identify: Identify: Traceback (most recent call last): File "Thuban/UI/view.py", line 206, in _do_redraw if self.render_iter.next(): File "Thuban/UI/view.py", line 272, in _render_iterator for cont in renderer.draw_selection_incrementally(layer, shapes): File "Thuban/UI/renderer.py", line 170, in draw_selection_incrementally value = table.ReadValue(shape.ShapeID(), field) File "Thuban/Model/transientdb.py", line 598, in ReadValue row_is_ordinal = row_is_ordinal) File "Thuban/Model/table.py", line 166, in ReadValue return self.dbf.read_attribute(row, self.column_map[col].index) KeyError Search: Traceback (most recent call last): File "Thuban/UI/view.py", line 206, in _do_redraw if self.render_iter.next(): File "Thuban/UI/view.py", line 272, in _render_iterator for cont in renderer.draw_selection_incrementally(layer, shapes): File "Thuban/UI/renderer.py", line 170, in draw_selection_incrementally value = table.ReadValue(shape.ShapeID(), field) File "Thuban/Model/transientdb.py", line 595, in ReadValue row_is_ordinal = row_is_ordinal) File "Thuban/Model/transientdb.py", line 248, in ReadValue return self.ReadRowAsDict(row)[self.column_map[col].name] KeyError -------------------------------------------- Managed by Request Tracker From cvs at intevation.de Mon Jan 3 17:21:19 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 3 Jan 2005 17:21:19 +0100 (CET) Subject: frank: thuban/Thuban/UI renderer.py,1.52,1.53 Message-ID: <20050103162119.EFCD5102BCC@lists.intevation.de> Author: frank Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv2792/Thuban/UI Modified Files: renderer.py Log Message: Thuban/UI/renderer.py (ScreenRendererdraw_selection_incrementally): BugFix 2883: Former implementation only worked on classified point layers: KeyError was raised, now use the default size if field is None. Index: renderer.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/renderer.py,v retrieving revision 1.52 retrieving revision 1.53 diff -u -d -r1.52 -r1.53 --- renderer.py 13 Dec 2004 18:26:11 -0000 1.52 +++ renderer.py 3 Jan 2005 16:21:17 -0000 1.53 @@ -166,7 +166,7 @@ # Get the size of the specific property for this # point - if shapetype == SHAPETYPE_POINT: + if shapetype == SHAPETYPE_POINT and field is not None: value = table.ReadValue(shape.ShapeID(), field) group = lc.FindGroup(value) size = group.GetProperties().GetSize() From cvs at intevation.de Mon Jan 3 17:22:00 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 3 Jan 2005 17:22:00 +0100 (CET) Subject: frank: thuban ChangeLog,1.752,1.753 Message-ID: <20050103162200.49E3B102BCC@lists.intevation.de> Author: frank Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv2819 Modified Files: ChangeLog Log Message: BugFix 2883 Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.752 retrieving revision 1.753 diff -u -d -r1.752 -r1.753 --- ChangeLog 27 Dec 2004 17:00:14 -0000 1.752 +++ ChangeLog 3 Jan 2005 16:21:58 -0000 1.753 @@ -1,3 +1,9 @@ +2005-01-03 Frank Koormann + + * Thuban/UI/renderer.py (ScreenRendererdraw_selection_incrementally): + BugFix 2883: Former implementation only worked on classified point layers: + KeyError was raised, now use the default size if field is None. + 2004-12-27 Bernhard Reiter svgexport 1.0.0cvs: Fixed label export. From bernhard at intevation.de Mon Jan 3 17:22:12 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 3 Jan 2005 17:22:12 +0100 Subject: drawshape "deficiencies" In-Reply-To: <16850.12094.199486.487977@desk.crynwr.com> References: <16850.12094.199486.487977@desk.crynwr.com> Message-ID: <20050103162212.GH10243@intevation.de> On Tue, Dec 28, 2004 at 11:14:54PM -0500, Russell Nelson wrote: > Hmmm.... I see no reason why drawshape couldn't be extended to handle > points and lines. It just needs to understand whether the selected > layer consists of points, lines, or polygons, as opposed to its > current assumption of polygons. Drawshape was a quick hack, but better a quick hack than nothing. ;) > Also (and this is more serious) there needs to be a way to delete the > most recent point. The problem is not giving the user a way to do it. > The problem is giving them a way to do it without forcing them to read > the documentation. For example, we could let Delete remove the most > recent point. How are they going to know that they should resort to > the keyboard? Perhaps we could make a sub-menu off Experimental/Shape > Draw Tool that gives them a mouseable command, but which also tells > them that Delete deletes. Or we could let shift-click delete the most > recent point? Or maybe we need a generalized Edit menu, since we're > adding editing? I think a general editing menu and undockable toolbar it the real solution for this problem, but again a first attempt would be to make deletion possible and then think about the best interface. > What if we had a cursor, which was a little circle > around the selected point(s)? You could use the arrow to go from > point to line segment (circling both points) to point to line > segment. If they clicked when only a point was selected, it would > move the point. If they clicked when a line segment was selected, it > would split the line in half. > > I have no idea of what is the best user interface for an editor. All > suggestions gladly entertained! I think maybe I should prototype it > in mapviewer. I suggest looking at drawing applications like Skencil: www.skencil.org. 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/20050103/a43e46db/attachment.bin From bernhard at intevation.de Mon Jan 3 17:24:21 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 3 Jan 2005 17:24:21 +0100 Subject: speed of raster repainting In-Reply-To: <16852.61767.697338.328880@desk.crynwr.com> References: <16852.61767.697338.328880@desk.crynwr.com> Message-ID: <20050103162421.GI10243@intevation.de> On Fri, Dec 31, 2004 at 01:27:19AM -0500, Russell Nelson wrote: > I notice that raster repainting is fairly slow. The raster needs to > be repainted whenever the layer order is changed or layer visibility > changes. The time seems to be evenly split between ProjectRasterFile(), > and wxImageFromStream(). There is some room for improvement there, I > think. ProjectRasterFile seems to be returning a BMP file, whereas it > could return a wxImage. That would make the raster repaint twice as > fast. Also, it could keep a cache of projected data, so if all the > parameters to ProjectRasterFile are the same, it would return the same > projected data. > > Mapviewer only displays UTM maps, so it doesn't have to deal with > changing the projection. Still, keeping an internal cache of tiles as > pixmaps, ready for drawing, lets me repaint 16 200x200 pixmaps at > least ten times per second. Having a nive cache system is a long standing wish, we did not want to do premature optimisation, this is why we do not have it in there yet. I also believe that caching projected data will help a lot with raster and other data. Did you do any profiling, because that would be evidence that we are slow because of this and saves us one step. :) Also feel free to hack up some optimisation. -------------- 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/20050103/617b80ab/attachment.bin From bernhard at intevation.de Mon Jan 3 17:28:29 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 3 Jan 2005 17:28:29 +0100 Subject: Status: Layer organisation In-Reply-To: <16852.60953.215253.270307@desk.crynwr.com> References: <20040415180842.GF1655@finlandia.infodrom.north.de> <16852.60953.215253.270307@desk.crynwr.com> Message-ID: <20050103162829.GJ10243@intevation.de> On Fri, Dec 31, 2004 at 01:13:45AM -0500, Russell Nelson wrote: > bh at intevation.de (Bernhard Herzog) writes: > > Martin Schulze writes: > > > 2. If 1. we should see why transparency is currently not supported by > > > Thuban > > > > The reason is simple: It's not easy to do with a wxDC. It would be > > possible and probably not even difficult to do a gif-like transparency > > (effecively one bit alpha channel, every pixel is either drawn or not). > > Actually .... There's a step needed prior to this one. If you have > multiple raster layers, Thuban should draw them on top of each other. > Currently, if I load a map which is 1000 x 1000 pixels, and and > another map which is 200 x 200 pixels and overlaps the first, Thuban > only displays one of them. > > There only seems to be code for drawing one background bitmap. True, another long standing wish. https://intevation.de/rt/webrt?serial_num=2301&display=History -------------- 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/20050103/f47ff8af/attachment.bin From Chris.Barker at noaa.gov Mon Jan 3 18:43:19 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon, 03 Jan 2005 09:43:19 -0800 Subject: Status: Layer organisation In-Reply-To: <16852.60953.215253.270307@desk.crynwr.com> References: <20040415180842.GF1655@finlandia.infodrom.north.de> <16852.60953.215253.270307@desk.crynwr.com> Message-ID: <41D98437.5060800@noaa.gov> Russell Nelson wrote: > bh at intevation.de (Bernhard Herzog) writes: > > Martin Schulze writes: > > > 2. If 1. we should see why transparency is currently not supported by > > > Thuban > > > > The reason is simple: It's not easy to do with a wxDC. It would be > > possible and probably not even difficult to do a gif-like transparency > > (effecively one bit alpha channel, every pixel is either drawn or not). Yes, this is a major deficiency of wxDCs. However, I think the wx 2.5 series supports bitmaps with an alpha channel, at least on a platforms that support it natively. I don't think there is such thing as a wxColor with an alpha channel, however, which is what is really needed. Currently, you can do a bitmap with a mask, which provides the above mentioned gif-like behaviour, but it is pretty darn slow. I tried to use it in my FLoatCanvas so that I could cach layers in off-screen bitmaps. It ended up being slower than just re-drawing the objects, at least for my application. This, from the docs, seems to explain why it's slow: """ useMask If true, Blit does a transparent blit using the mask that is associated with the bitmap selected into the source device context. The Windows implementation does the following if MaskBlt cannot be used: -Creates a temporary bitmap and copies the destination area into it. Copies the source area into the temporary bitmap using the specified logical function. -Sets the masked area in the temporary bitmap to BLACK by ANDing the mask bitmap with the temp bitmap with the foreground colour set to WHITE and the bg colour set to BLACK. -Sets the unmasked area in the destination area to BLACK by ANDing the mask bitmap with the destination area with the foreground colour set to BLACK and the background colour set to WHITE. ORs the temporary bitmap with the destination area. -Deletes the temporary bitmap. This sequence of operations ensures that the source's transparent area need not be black, and logical functions are supported. """ Another option would be to use AGG (http://www.antigrain.com/) to do the rendering, and blit the result to the screen. This is being done by at least a couple of Python plotting libraries (Chaco and Matplotlib), and a version is being developed for use with PIL (http://effbot.org/zone/draw-agg.htm). It seems to provide very high quality drawing and full alpha support. Has anyone considered this? By the way, what are the plans for upgrading to wxPython 2.5.* (eventually 2.6)? I have personally converted all my code to the newer versions, and it really is a lot better, particularly on OS-X, where 2.4 is essentially useless. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From nelson at crynwr.com Sat Jan 8 08:10:35 2005 From: nelson at crynwr.com (Russell Nelson) Date: Sat, 8 Jan 2005 02:10:35 -0500 Subject: multiple rasters && mapview Message-ID: <16863.34667.62805.87273@desk.crynwr.com> I'm still tracking down the problem with multiple rasters. The intrinsic problem is that ProjectRasterFile (called from baserenderer.py and implemented in gdalwarp.cpp) always creates a bitmap that fills the viewport. Doesn't matter how big the raster image actually is. Doesn't matter if the actual data in the raster covers only a portion of the image. You can see this for yourself. Load a raster, and a layer that covers more than just the raster. Then zoom to the full extents. The white background of the viewport is entirely overlaid by the raster. The fix is going to have to be in the way ProjectRasterFile gets called. Instead of creating a BMP image, it needs to return a wxImage, clipping mask, and offset. I don't know enough about GDAL to be able to do that yet. I may need help with the Python bindings, but I'll ask for it when I need it. Mapview is now nicely editing line files. I really like the UI, and I'll be putting it into Thuban, once Thuban gets as good as Mapview at displaying rasters. The trouble I'm now running into is that I'm basically re-creating shapfiles. Rather than going that, I need to add line editing to Thuban. That way, everyone benefits. I'm going to have to create an Extension for Terraserver tiles. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bernhard at intevation.de Sat Jan 8 15:12:58 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 8 Jan 2005 15:12:58 +0100 Subject: multiple rasters && mapview In-Reply-To: <16863.34667.62805.87273@desk.crynwr.com> References: <16863.34667.62805.87273@desk.crynwr.com> Message-ID: <20050108141258.GH15519@intevation.de> On Sat, Jan 08, 2005 at 02:10:35AM -0500, Russell Nelson wrote: > I'm still tracking down the problem with multiple rasters. The > intrinsic problem is that ProjectRasterFile (called from > baserenderer.py and implemented in gdalwarp.cpp) always creates a > bitmap that fills the viewport. Doesn't matter how big the raster > image actually is. Doesn't matter if the actual data in the raster > covers only a portion of the image. > > You can see this for yourself. Load a raster, and a layer that covers > more than just the raster. Then zoom to the full extents. The white > background of the viewport is entirely overlaid by the raster. > > The fix is going to have to be in the way ProjectRasterFile gets > called. Instead of creating a BMP image, it needs to return a > wxImage, clipping mask, and offset. Wouldn't this make it depend on wxWidgets a GUI library? (I really don't know.) If possible we probably want to keep that independent. > I don't know enough about GDAL to > be able to do that yet. Could be a workaround to define one color that gets transformed to a clipping mask after projecting out of the BMP? > Mapview is now nicely editing line files. I really like the UI, and > I'll be putting it into Thuban, once Thuban gets as good as Mapview at > displaying rasters. The trouble I'm now running into is that I'm > basically re-creating shapfiles. Rather than going that, I need to > add line editing to Thuban. That way, everyone benefits. > > I'm going to have to create an Extension for Terraserver tiles. Cool. -------------- 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/20050108/9c0fdfc5/attachment.bin From nelson at crynwr.com Sat Jan 8 16:54:10 2005 From: nelson at crynwr.com (Russell Nelson) Date: Sat, 8 Jan 2005 10:54:10 -0500 Subject: multiple rasters && mapview In-Reply-To: <20050108141258.GH15519@intevation.de> References: <16863.34667.62805.87273@desk.crynwr.com> <20050108141258.GH15519@intevation.de> Message-ID: <16864.546.553006.106056@desk.crynwr.com> Bernhard Reiter writes: > > The fix is going to have to be in the way ProjectRasterFile gets > > called. Instead of creating a BMP image, it needs to return a > > wxImage, clipping mask, and offset. > > Wouldn't this make it depend on wxWidgets a GUI library? (I really > don't know.) If possible we probably want to keep that independent. No, it's just another binary file output type. I'm sure that GDAL uses libtiff and libjpeg, and does the right thing if they're not present. > > I don't know enough about GDAL to > > be able to do that yet. > > Could be a workaround to define one color that gets transformed > to a clipping mask after projecting out of the BMP? Loading the BMP takes a substantial amount of time. I hope to avoid that step. With the following two prints in place, a substantial amount of time (1/2 second approximately) occurs between the two prints. In renderer.py: def draw_raster_data(self, data, format = 'BMP'): stream = cStringIO.StringIO(data) print "drd: begin" image = wxImageFromStream(stream, raster_format_map[format]) print "drd: end" bitmap = wxBitmapFromImage(image) self.dc.DrawBitmap(bitmap, 0, 0) Also, there simply MUST be a way to make ProjectRasterFile faster. The amount of time it takes to draw a reasonably complex vector or polygon layer is much, much smaller than the time it takes to render a raster. One of the things that I think would help is a way to communicate the "natural" scale of the map as projected back into Thuban. If you have a UTM raster on a UTM map, and the raster is a 32 meters per pixel, then you want to make sure that the user is given an opportunity to view the map at *exactly* 32 meters per pixel. I think that is best accomplished by making sure that the zoom code has, as one of its steps, the exact scale of the raster, or rasters. I haven't even begun to look into that yet. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From thuban-bugs at intevation.de Sun Jan 9 13:18:45 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Sun, 9 Jan 2005 13:18:45 +0100 (CET) Subject: [bug #2901] (thuban) Duplicate Layer doesn't copy classification field (column) Message-ID: <20050109121845.1DD8D102BFD@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2901 ------------------------------------------------------------------------- Subject: Duplicate Layer doesn't copy classification field (column) Duplicate Layer doesn't copy classification field (column) reference. As a consequnce the duplicated layer has a worthless classification since it is not related to any attribute field. -------------------------------------------- Managed by Request Tracker From cvs at intevation.de Sun Jan 9 13:32:19 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Sun, 9 Jan 2005 13:32:19 +0100 (CET) Subject: frank: thuban/Thuban/UI mainwindow.py,1.135,1.136 Message-ID: <20050109123219.BF83D102BFC@lists.intevation.de> Author: frank Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv12215/Thuban/UI Modified Files: mainwindow.py Log Message: BugFix 2901: Explicitly copy layers ClassificationColumn since it is not part of the layers Classification. Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.135 retrieving revision 1.136 diff -u -d -r1.135 -r1.136 --- mainwindow.py 1 Oct 2004 18:22:32 -0000 1.135 +++ mainwindow.py 9 Jan 2005 12:32:17 -0000 1.136 @@ -653,6 +653,8 @@ layer.ShapeStore(), projection = layer.GetProjection()) new_classification = copy.deepcopy(layer.GetClassification()) + new_layer.SetClassificationColumn( + layer.GetClassificationColumn()) new_layer.SetClassification(new_classification) self.Map().AddLayer(new_layer) From cvs at intevation.de Sun Jan 9 13:32:37 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Sun, 9 Jan 2005 13:32:37 +0100 (CET) Subject: frank: thuban ChangeLog,1.753,1.754 Message-ID: <20050109123237.61506102BFC@lists.intevation.de> Author: frank Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv12243 Modified Files: ChangeLog Log Message: Bugfix 2901 Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.753 retrieving revision 1.754 diff -u -d -r1.753 -r1.754 --- ChangeLog 3 Jan 2005 16:21:58 -0000 1.753 +++ ChangeLog 9 Jan 2005 12:32:35 -0000 1.754 @@ -1,8 +1,14 @@ +2005-01-09 Frank Koormann + + * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): + BugFix 2901: Explicitly copy layers ClassificationColumn since it + is not part of the layers Classification. + 2005-01-03 Frank Koormann - * Thuban/UI/renderer.py (ScreenRendererdraw_selection_incrementally): - BugFix 2883: Former implementation only worked on classified point layers: - KeyError was raised, now use the default size if field is None. + * Thuban/UI/renderer.py (ScreenRendererdraw_selection_incrementally): + BugFix 2883: Former implementation only worked on classified point + layers: KeyError was raised, now use the default size if field is None. 2004-12-27 Bernhard Reiter From nelson at crynwr.com Sun Jan 9 17:03:22 2005 From: nelson at crynwr.com (Russell Nelson) Date: Sun, 9 Jan 2005 11:03:22 -0500 Subject: scaling Message-ID: <16865.21962.258282.700805@desk.crynwr.com> I think that the raster layer should get a chance to adjust the scale when viewport.py's set_view_transform() calculates it. Terraserver tiles come in whatever resolution you want, so long as it's an integer power of two. Since there is, in principle, no reason to treat raster layers specially, I think BaseLayer should have a method for tweaking the scale. For example, Layer.adjust_scale(). If no one objects in principle, I'll prepare a patch for approval. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From cvs at intevation.de Mon Jan 10 18:08:53 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 10 Jan 2005 18:08:53 +0100 (CET) Subject: jan: thuban/Thuban/UI mainwindow.py,1.128,1.128.2.1 Message-ID: <20050110170853.0F1CF10016B@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv6457 Modified Files: Tag: thuban-1-0-branch mainwindow.py Log Message: Backport from HEAD: BugFix for RT #2901: Explicitly copy layers ClassificationColumn since it is not part of the layers Classification. Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.128 retrieving revision 1.128.2.1 diff -u -d -r1.128 -r1.128.2.1 --- mainwindow.py 13 Feb 2004 10:46:44 -0000 1.128 +++ mainwindow.py 10 Jan 2005 17:08:50 -0000 1.128.2.1 @@ -619,6 +619,7 @@ layer.ShapeStore(), projection = layer.GetProjection()) new_classification = copy.deepcopy(layer.GetClassification()) + new_layer.SetClassificationColumn(layer.GetClassificationColumn()) new_layer.SetClassification(new_classification) self.Map().AddLayer(new_layer) From cvs at intevation.de Mon Jan 10 18:09:50 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 10 Jan 2005 18:09:50 +0100 (CET) Subject: jan: thuban ChangeLog,1.624.2.31,1.624.2.32 Message-ID: <20050110170950.CD24410016B@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv6487 Modified Files: Tag: thuban-1-0-branch ChangeLog Log Message: BugFix for RT #2901 Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.624.2.31 retrieving revision 1.624.2.32 diff -u -d -r1.624.2.31 -r1.624.2.32 --- ChangeLog 23 Dec 2004 15:07:56 -0000 1.624.2.31 +++ ChangeLog 10 Jan 2005 17:09:48 -0000 1.624.2.32 @@ -1,3 +1,10 @@ +2005-01-10 Jan-Oliver Wagner + + * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): + Backport from HEAD: + BugFix for RT #2901: Explicitly copy layers ClassificationColumn since it + is not part of the layers Classification. + 2004-12-23 Jan-Oliver Wagner * Thuban/UI/projdialog.py (ProjFrame.load_user_proj): Added a From jan at intevation.de Mon Jan 10 18:28:36 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 10 Jan 2005 18:28:36 +0100 Subject: [Thuban-devel] scaling In-Reply-To: <16865.21962.258282.700805@desk.crynwr.com> References: <16865.21962.258282.700805@desk.crynwr.com> Message-ID: <20050110172836.GB9751@intevation.de> On Sun, Jan 09, 2005 at 11:03:22AM -0500, Russell Nelson wrote: > I think that the raster layer should get a chance to adjust the scale > when viewport.py's set_view_transform() calculates it. Terraserver > tiles come in whatever resolution you want, so long as it's an integer > power of two. Since there is, in principle, no reason to treat raster > layers specially, I think BaseLayer should have a method for tweaking > the scale. For example, Layer.adjust_scale(). this sounds interesting. I wonder how other tools handle this aspect. > If no one objects in principle, I'll prepare a patch for approval. I must admit that I'd need to see the patch to better judge whether it is a good idea to add this to Thuban core. The reason is that I do not yet fully understand the consequences of such a change and playing with it helps me to get a better impression. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From nelson at crynwr.com Tue Jan 11 06:26:45 2005 From: nelson at crynwr.com (Russell Nelson) Date: Tue, 11 Jan 2005 00:26:45 -0500 Subject: [Thuban-devel] scaling In-Reply-To: <20050110172836.GB9751@intevation.de> References: <16865.21962.258282.700805@desk.crynwr.com> <20050110172836.GB9751@intevation.de> Message-ID: <16867.25493.691251.309667@desk.crynwr.com> Jan-Oliver Wagner writes: > I must admit that I'd need to see the patch to better judge whether > it is a good idea to add this to Thuban core. The reason is that > I do not yet fully understand the consequences of such a change > and playing with it helps me to get a better impression. This is the diff I'd like to check in. diff -u -r1.60 layer.py --- Thuban/Model/layer.py 20 Sep 2004 08:13:00 -0000 1.60 +++ Thuban/Model/layer.py 11 Jan 2005 05:21:41 -0000 @@ -71,6 +71,10 @@ self.projection = projection self.changed(LAYER_PROJECTION_CHANGED, self) + def AdjustScale(self, scale): + """Adjust the map's scaling to a preferred scale.""" + return scale + class Layer(BaseLayer): """Represent the information of one geodata file (currently a shapefile) diff -u -r1.18 map.py --- Thuban/Model/map.py 10 Jul 2003 14:53:15 -0000 1.18 +++ Thuban/Model/map.py 11 Jan 2005 05:21:41 -0000 @@ -170,6 +170,13 @@ self.changed(MAP_LAYERS_CHANGED, self) self.changed(MAP_STACKING_CHANGED, self) + def AdjustScale(self, scale): + """Adjust the scale of the map as requested by any layer.""" + + for layer in self.layers: + scale = layer.AdjustScale(scale) + return scale + def BoundingBox(self): """Return the bounding box of the map in Lat/Lon coordinates. diff -u -r1.19 viewport.py --- Thuban/UI/viewport.py 18 Nov 2004 20:17:43 -0000 1.19 +++ Thuban/UI/viewport.py 11 Jan 2005 05:21:44 -0000 @@ -410,7 +410,8 @@ elif scale < min_scale: scale = min_scale - self.scale = scale + # give the layers a chance to pick a better scale. + self.scale = self.map.AdjustScale(scale) # determine new offset to preserve the center self.offset = (wwidth/2 - scale * pcenterx, -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bh at intevation.de Tue Jan 11 17:19:24 2005 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 11 Jan 2005 17:19:24 +0100 Subject: frank: thuban/Thuban/UI mainwindow.py,1.135,1.136 In-Reply-To: <20050109123219.BF83D102BFC@lists.intevation.de> (cvs@intevation.de's message of "Sun, 9 Jan 2005 13:32:19 +0100 (CET)") References: <20050109123219.BF83D102BFC@lists.intevation.de> Message-ID: cvs at intevation.de writes: > --- mainwindow.py 1 Oct 2004 18:22:32 -0000 1.135 > +++ mainwindow.py 9 Jan 2005 12:32:17 -0000 1.136 > @@ -653,6 +653,8 @@ > layer.ShapeStore(), > projection = layer.GetProjection()) > new_classification = copy.deepcopy(layer.GetClassification()) > + new_layer.SetClassificationColumn( > + layer.GetClassificationColumn()) Please don't use tabs for indentation! Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Tue Jan 11 17:52:42 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 11 Jan 2005 17:52:42 +0100 (CET) Subject: frank: thuban/Thuban/UI mainwindow.py,1.136,1.137 Message-ID: <20050111165242.D9896102C24@lists.intevation.de> Author: frank Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv2370/Thuban/UI Modified Files: mainwindow.py Log Message: * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): Fix indention bug. Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.136 retrieving revision 1.137 diff -u -d -r1.136 -r1.137 --- mainwindow.py 9 Jan 2005 12:32:17 -0000 1.136 +++ mainwindow.py 11 Jan 2005 16:52:40 -0000 1.137 @@ -653,8 +653,8 @@ layer.ShapeStore(), projection = layer.GetProjection()) new_classification = copy.deepcopy(layer.GetClassification()) - new_layer.SetClassificationColumn( - layer.GetClassificationColumn()) + new_layer.SetClassificationColumn( + layer.GetClassificationColumn()) new_layer.SetClassification(new_classification) self.Map().AddLayer(new_layer) From cvs at intevation.de Tue Jan 11 17:52:42 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 11 Jan 2005 17:52:42 +0100 (CET) Subject: frank: thuban ChangeLog,1.754,1.755 Message-ID: <20050111165242.E7543102C25@lists.intevation.de> Author: frank Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv2370 Modified Files: ChangeLog Log Message: * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): Fix indention bug. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.754 retrieving revision 1.755 diff -u -d -r1.754 -r1.755 --- ChangeLog 9 Jan 2005 12:32:35 -0000 1.754 +++ ChangeLog 11 Jan 2005 16:52:40 -0000 1.755 @@ -1,7 +1,12 @@ +2005-01-11 Frank Koormann + + * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): + Fix indention bug. + 2005-01-09 Frank Koormann * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): - BugFix 2901: Explicitly copy layers ClassificationColumn since it + BugFix 2901: Explicitly copy layers ClassificationColumn since it is not part of the layers Classification. 2005-01-03 Frank Koormann From frank.koormann at intevation.de Tue Jan 11 17:54:00 2005 From: frank.koormann at intevation.de (Frank Koormann) Date: Tue, 11 Jan 2005 17:54:00 +0100 Subject: frank: thuban/Thuban/UI mainwindow.py,1.135,1.136 In-Reply-To: References: <20050109123219.BF83D102BFC@lists.intevation.de> Message-ID: <20050111165400.GA27703@intevation.de> * Bernhard Herzog [050111 17:19]: > cvs at intevation.de writes: > > > --- mainwindow.py 1 Oct 2004 18:22:32 -0000 1.135 > > +++ mainwindow.py 9 Jan 2005 12:32:17 -0000 1.136 > > @@ -653,6 +653,8 @@ > > layer.ShapeStore(), > > projection = layer.GetProjection()) > > new_classification = copy.deepcopy(layer.GetClassification()) > > + new_layer.SetClassificationColumn( > > + layer.GetClassificationColumn()) > > Please don't use tabs for indentation! > Arrg! Hacked the fix on a not fully pythonized vim. Fixed now. Frank -- Frank Koormann Professional Service around Free Software (http://intevation.net/) FreeGIS Project (http://freegis.org/) From nelson at crynwr.com Tue Jan 11 18:36:25 2005 From: nelson at crynwr.com (Russell Nelson) Date: Tue, 11 Jan 2005 12:36:25 -0500 Subject: very slow development Message-ID: <16868.3737.440900.697135@desk.crynwr.com> This system -- where every patch to be checked-in must first be vetted by ... somebody -- works very poorly for me. I'm all set to write my Terraserver layer, but first I have to have to force the scale to a power of two meters per pixel. To do that, I need the AdjustScale patch. It's the end of the work day in Germany, and it's clear that I'm going to lose another day of development. What can I do differently to speed up development? Should I just code up my layer and throw a huge pile of patches at you? Is that likely to work, or is it more likely to cause a big lumpkin of indigestible patches? -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From joey at infodrom.org Tue Jan 11 19:05:58 2005 From: joey at infodrom.org (Martin Schulze) Date: Tue, 11 Jan 2005 19:05:58 +0100 Subject: very slow development In-Reply-To: <16868.3737.440900.697135@desk.crynwr.com> References: <16868.3737.440900.697135@desk.crynwr.com> Message-ID: <20050111180558.GF927@finlandia.infodrom.north.de> Russell Nelson wrote: > This system -- where every patch to be checked-in must first be vetted > by ... somebody -- works very poorly for me. I'm all set to write my > Terraserver layer, but first I have to have to force the scale to a > power of two meters per pixel. To do that, I need the AdjustScale > patch. It's the end of the work day in Germany, and it's clear that > I'm going to lose another day of development. Why don't you start to work on the terraserver layer. If the AdjustScale patch won't be added in its current representation it can most probably be modified and the terraserver layer can be modified as well to work on top of it. In the long term Thuban has a cleaner codebase when modifications in the core part are reviewed before. > What can I do differently to speed up development? Should I just code > up my layer and throw a huge pile of patches at you? Is that likely > to work, or is it more likely to cause a big lumpkin of indigestible > patches? I'd say work on the layer, and if the AdjustScale won't be accepted as it is now, adjust the layer again (and again (and again (..))) until everything fits. Regards, Joey -- Unix is user friendly ... It's just picky about its friends. From nelson at crynwr.com Tue Jan 11 19:24:16 2005 From: nelson at crynwr.com (Russell Nelson) Date: Tue, 11 Jan 2005 13:24:16 -0500 Subject: very slow development In-Reply-To: <20050111180558.GF927@finlandia.infodrom.north.de> References: <16868.3737.440900.697135@desk.crynwr.com> <20050111180558.GF927@finlandia.infodrom.north.de> Message-ID: <16868.6608.614047.929044@desk.crynwr.com> Martin Schulze writes: > I'd say work on the layer, and if the AdjustScale won't be accepted > as it is now, adjust the layer again (and again (and again (..))) > until everything fits. Okay. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bh at intevation.de Tue Jan 11 19:25:26 2005 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 11 Jan 2005 19:25:26 +0100 Subject: [Thuban-devel] scaling In-Reply-To: <16867.25493.691251.309667@desk.crynwr.com> (Russell Nelson's message of "Tue, 11 Jan 2005 00:26:45 -0500") References: <16865.21962.258282.700805@desk.crynwr.com> <20050110172836.GB9751@intevation.de> <16867.25493.691251.309667@desk.crynwr.com> Message-ID: Russell Nelson writes: > --- Thuban/Model/map.py 10 Jul 2003 14:53:15 -0000 1.18 > +++ Thuban/Model/map.py 11 Jan 2005 05:21:41 -0000 > @@ -170,6 +170,13 @@ > self.changed(MAP_LAYERS_CHANGED, self) > self.changed(MAP_STACKING_CHANGED, self) > > + def AdjustScale(self, scale): > + """Adjust the scale of the map as requested by any layer.""" > + > + for layer in self.layers: > + scale = layer.AdjustScale(scale) > + return scale If multiple layers want to adjust the scale the ones later in the list only see the already adjusted scale. Is that really the right approach? I would have expected that all layers would base their adjustments on the same initial scale. If only one layer returns a different one or if all layers that return a different one return the same one, that one would be taken. How to proceed if the layers that want a different scale don't agree, I don't know. Some test cases that check these different cases would be very useful here. Thinking more about this, I think the AdjustScale method should work differently. It should be more like: def PreferredScale(self, scale): """Return a preferred scale factor near scale The default implementation simply returns None indicating that all scales are acceptable. Derived classes can override this method to return a scale value they would prefer for their data. The new scale value should be near the given scale value. The actual scale used to draw the layer may still not be the preferred scale, though. """ The reason is that that the simple approach outlined above doesn't handle all situations well, even if only one layer returns a different scale. For instance you have two layers, one preferring scale1 and the other scale2. Say the actual scale to be used is scale1. Then you will only get one different scale, so the new scale will be scale2. Then you move the map with the pan tool so the scale should stay the same. The map's AdjustScale method is called with scale2 and now the adjusted scale will be scale1! > --- Thuban/UI/viewport.py 18 Nov 2004 20:17:43 -0000 1.19 > +++ Thuban/UI/viewport.py 11 Jan 2005 05:21:44 -0000 > @@ -410,7 +410,8 @@ > elif scale < min_scale: > scale = min_scale > > - self.scale = scale > + # give the layers a chance to pick a better scale. > + self.scale = self.map.AdjustScale(scale) I think this adjustment should be made before the scale is clamped to the min/max scale. The scale limits are there for a reason. If you zoom in too much, for instance, you can easily get rendering errors. On the whole, I think this scale adjustment needs more thought before it goes into CVS. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bh at intevation.de Tue Jan 11 19:34:09 2005 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 11 Jan 2005 19:34:09 +0100 Subject: multiple rasters && mapview In-Reply-To: <16864.546.553006.106056@desk.crynwr.com> (Russell Nelson's message of "Sat, 8 Jan 2005 10:54:10 -0500") References: <16863.34667.62805.87273@desk.crynwr.com> <20050108141258.GH15519@intevation.de> <16864.546.553006.106056@desk.crynwr.com> Message-ID: > Bernhard Reiter writes: > > Wouldn't this make it depend on wxWidgets a GUI library? (I really > > don't know.) If possible we probably want to keep that independent. So what? Making this faster is more important at the moment and we should be getting plenty of independence from using GDAL in the first place. At least I hope so. I never had much time to look at Thuban's raster code, unfortunately. Russell Nelson writes: > Also, there simply MUST be a way to make ProjectRasterFile faster. I sure hope there is. Trying to get rid of the intermediate BMP file is a good start. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From nelson at crynwr.com Tue Jan 11 19:54:15 2005 From: nelson at crynwr.com (Russell Nelson) Date: Tue, 11 Jan 2005 13:54:15 -0500 Subject: [Thuban-devel] scaling In-Reply-To: References: <16865.21962.258282.700805@desk.crynwr.com> <20050110172836.GB9751@intevation.de> <16867.25493.691251.309667@desk.crynwr.com> Message-ID: <16868.8407.43941.807917@desk.crynwr.com> Bernhard Herzog writes: > If multiple layers want to adjust the scale the ones later in the list > only see the already adjusted scale. Is that really the right approach? Probably not. I think that the basic design of Thuban is correct in that every layer should expect to have to deal with a scale of arbitrary value. It's just that Terraserver has an intrinsic scale of 1, 2, 4, 8, .... meters per pixel, and it only makes sense to work with them if possible. If not possible, then rescaling is necessary. > I would have expected that all layers would base their adjustments on > the same initial scale. If only one layer returns a different one or if > all layers that return a different one return the same one, that one > would be taken. How to proceed if the layers that want a different > scale don't agree, I don't know. Me neither. I'll go ahead and implement something and we'll see how it works! > On the whole, I think this scale adjustment needs more thought before it > goes into CVS. Yup, agreed. I'll run with it in my implemementation and see how it goes. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From nelson at crynwr.com Tue Jan 11 20:02:57 2005 From: nelson at crynwr.com (Russell Nelson) Date: Tue, 11 Jan 2005 14:02:57 -0500 Subject: multiple rasters && mapview In-Reply-To: References: <16863.34667.62805.87273@desk.crynwr.com> <20050108141258.GH15519@intevation.de> <16864.546.553006.106056@desk.crynwr.com> Message-ID: <16868.8929.212169.417868@desk.crynwr.com> Bernhard Herzog writes: > > Bernhard Reiter writes: > > > Wouldn't this make it depend on wxWidgets a GUI library? (I really > > > don't know.) If possible we probably want to keep that independent. > > So what? Making this faster is more important at the moment and we > should be getting plenty of independence from using GDAL in the first > place. What is the speed/memory tradeoff? Right now, GDALwarp is being asked to reproject the raster such that only the visible portion is rendered. If we were instead to tell it to render the entire raster into memory, we could tell wxWindows to draw only the visible portion. That would make panning a LOT faster. Trouble is that it would also increase the memory requirements such that the entire uncompressed raster map must be held in memory. How big are the rasters that thuban users use? How important is fast panning to them? -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From jonathan at jpcoles.com Wed Jan 12 15:26:55 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Wed, 12 Jan 2005 09:26:55 -0500 Subject: multiple rasters && mapview In-Reply-To: <16863.34667.62805.87273@desk.crynwr.com> References: <16863.34667.62805.87273@desk.crynwr.com> Message-ID: <1105540015.7177.22.camel@localhost.localdomain> [i sent this once before but my current address wasn't on the mailing list so it was held. the administrator can ignore that] Am Samstag, den 08.01.2005, 02:10 -0500 schrieb Russell Nelson: > I'm still tracking down the problem with multiple rasters. The > intrinsic problem is that ProjectRasterFile (called from > baserenderer.py and implemented in gdalwarp.cpp) always creates a > bitmap that fills the viewport. > The fix is going to have to be in the way ProjectRasterFile gets > called. Instead of creating a BMP image, it needs to return a > wxImage, clipping mask, and offset. when i first implemented the raster code i discovered that the bounding box of the projected image is different (usually larger) than the bounding box returned from layer.LatLongBoundingBox(). this is because the image may curve outward between the two extreme x points, but the extreme of the outward curve is not recognized as the extend of the bounding box. if you use those values to calculate the parameters to ProjectRasterFile gdal generates an image which does not properly cover the area you want. the quick fix was to have gdal generate an image that covers the whole window. while obviously not ideal, this worked for a first attempt. i hacked up a quick solution (disclaimer: may not work in all instances) that renders as little of the raster layer image as possible. however, as i said before, since the projected bounding box information is incorrect the image is not quite right. if you can figure out how to correctly determine the projected bounding box size, then i think you will be able to a) decrease the rendering time since gdal isn't making an image for the whole window and b) easily allow for multiple raster layers without using masks. try the modifications to renderer.py and baserenderer.py i've listed below and then load the iceland_sample_raster.thuban file to see what i'm talking about. my code base is based on a cvs checkout from last night. good luck, --jonathan p.s. a big hello to everyone at intevation! hope you are all doing well. RCS file: /home/thuban/jail/thubanrepository/thuban/Thuban/UI/baserenderer.py,v retrieving revision 1.13 diff -r1.13 baserenderer.py 372a373 > 481a483,499 > bb = layer.LatLongBoundingBox() > > bb = [[[bb[0], bb[1]], [bb[2], bb[3]],],] > > pmin, pmax = self.projected_points(layer, bb)[0] > > xmin = (pmin[0]-offx)/self.scale > ymin = (offy - pmin[1])/self.scale > xmax = (pmax[0]-offx)/self.scale > ymax = (offy - pmax[1])/self.scale > > width = (xmax - xmin + 1) * self.scale > height = (ymax - ymin + 1) * self.scale > > #print offx, offy, offx*self.scale, offy*self.scale > #print xmin*self.scale, ymin*self.scale > 493c511,512 < self.draw_raster_data(data, "BMP") --- > self.draw_raster_data(pmin[0], pmin[1]-height, data, "BMP") > #self.draw_raster_data(offx*self.scale, offy*self.scale, data, "BMP") 495c514 < def draw_raster_data(self, data, format="BMP"): --- > def draw_raster_data(self, x, y, data, format="BMP"): Index: Thuban/UI/renderer.py =================================================================== RCS file: /home/thuban/jail/thubanrepository/thuban/Thuban/UI/renderer.py,v retrieving revision 1.53 diff -r1.53 renderer.py 40a41,42 > from math import floor > 102c104 < def draw_raster_data(self, data, format = 'BMP'): --- > def draw_raster_data(self, x,y, data, format = 'BMP'): 106c108 < self.dc.DrawBitmap(bitmap, 0, 0) --- > self.dc.DrawBitmap(bitmap, int(floor(x)), int(floor(y))) -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From jonathan at jpcoles.com Wed Jan 12 14:59:49 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Wed, 12 Jan 2005 08:59:49 -0500 Subject: multiple rasters && mapview In-Reply-To: <16863.34667.62805.87273@desk.crynwr.com> References: <16863.34667.62805.87273@desk.crynwr.com> Message-ID: <1105538389.7177.18.camel@localhost.localdomain> Am Samstag, den 08.01.2005, 02:10 -0500 schrieb Russell Nelson: > I'm still tracking down the problem with multiple rasters. The > intrinsic problem is that ProjectRasterFile (called from > baserenderer.py and implemented in gdalwarp.cpp) always creates a > bitmap that fills the viewport. > The fix is going to have to be in the way ProjectRasterFile gets > called. Instead of creating a BMP image, it needs to return a > wxImage, clipping mask, and offset. when i first implemented the raster code i discovered that the bounding box of the projected image is different (usually larger) than the bounding box returned from layer.LatLongBoundingBox(). this is because the image may curve outward between the two extreme x points, but the extreme of the outward curve is not recognized as the extend of the bounding box. if you use those values to calculate the parameters to ProjectRasterFile gdal generates an image which does not properly cover the area you want. the quick fix was to have gdal generate an image that covers the whole window. while obviously not ideal, this worked for a first attempt. i hacked up a quick solution (disclaimer: may not work in all instances) that renders as little of the raster layer image as possible. however, as i said before, since the projected bounding box information is incorrect the image is not quite right. if you can figure out how to correctly determine the projected bounding box size, then i think you will be able to a) decrease the rendering time since gdal isn't making an image for the whole window and b) easily allow for multiple raster layers without using masks. try the modifications to renderer.py and baserenderer.py i've listed below and then load the iceland_sample_raster.thuban file to see what i'm talking about. my code base is based on a cvs checkout from last night. good luck, --jonathan p.s. a big hello to everyone at intevation! hope you are all doing well. RCS file: /home/thuban/jail/thubanrepository/thuban/Thuban/UI/baserenderer.py,v retrieving revision 1.13 diff -r1.13 baserenderer.py 372a373 > 481a483,499 > bb = layer.LatLongBoundingBox() > > bb = [[[bb[0], bb[1]], [bb[2], bb[3]],],] > > pmin, pmax = self.projected_points(layer, bb)[0] > > xmin = (pmin[0]-offx)/self.scale > ymin = (offy - pmin[1])/self.scale > xmax = (pmax[0]-offx)/self.scale > ymax = (offy - pmax[1])/self.scale > > width = (xmax - xmin + 1) * self.scale > height = (ymax - ymin + 1) * self.scale > > #print offx, offy, offx*self.scale, offy*self.scale > #print xmin*self.scale, ymin*self.scale > 493c511,512 < self.draw_raster_data(data, "BMP") --- > self.draw_raster_data(pmin[0], pmin[1]-height, data, "BMP") > #self.draw_raster_data(offx*self.scale, offy*self.scale, data, "BMP") 495c514 < def draw_raster_data(self, data, format="BMP"): --- > def draw_raster_data(self, x, y, data, format="BMP"): Index: Thuban/UI/renderer.py =================================================================== RCS file: /home/thuban/jail/thubanrepository/thuban/Thuban/UI/renderer.py,v retrieving revision 1.53 diff -r1.53 renderer.py 40a41,42 > from math import floor > 102c104 < def draw_raster_data(self, data, format = 'BMP'): --- > def draw_raster_data(self, x,y, data, format = 'BMP'): 106c108 < self.dc.DrawBitmap(bitmap, 0, 0) --- > self.dc.DrawBitmap(bitmap, int(floor(x)), int(floor(y))) -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From cvs at intevation.de Fri Jan 14 16:51:01 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 14 Jan 2005 16:51:01 +0100 (CET) Subject: jan: thuban/Doc/manual thuban-manual-de.xml,1.6,1.7 Message-ID: <20050114155101.477CC102C08@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Doc/manual In directory doto:/tmp/cvs-serv27907 Modified Files: thuban-manual-de.xml Log Message: More translations. Index: thuban-manual-de.xml =================================================================== RCS file: /thubanrepository/thuban/Doc/manual/thuban-manual-de.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- thuban-manual-de.xml 27 Dec 2004 09:05:43 -0000 1.6 +++ thuban-manual-de.xml 14 Jan 2005 15:50:59 -0000 1.7 @@ -616,7 +616,7 @@ Karte Datenbankebene hinzufügen . - Es wird ein Duialog mit zwei Listen geöffnet. + Es wird ein Dialog mit zwei Listen geöffnet. Die linke Liste zeigt alle derzeit offenen Datenbankverbindungen dieser Session an. Eine Liste der verfügbaren Ebenen aus einer Datenbankverbindung wird steht auf der rechten Seite. Aus dieser Liste können Sie eine @@ -764,9 +764,9 @@ -
Object Identification +
Objekt Identifikation - Objects on the map can be identified using the Identify tool + Objekte auf der Karte können identifiziert werden über das Identifikations-Werkzeug @@ -774,12 +774,13 @@ - Identify Tool + Identifikations-Werkzeug . - Clicking on an object selects that object and opens a dialog which - shows all the table attributes for that object. Any current selection - is lost. Objects on the map are typically shapes and this document - will often refer to objects as shapes. + Klickt man auf ein Objekt wird es selektiert und es wird ein + Dialog geöffnet der dann alle Tabellenattribute für das Objekt + anzeigt. Jegliche vorherige Selektion wird gelöscht. + Objekte auf der Karte sind typischerweise Shapes und dieses + Dokument wird sich häufiger auf Objekte als Shapes beziehen.
@@ -803,7 +804,7 @@
-
The Legend +
Die Legende @@ -812,28 +813,31 @@ - Legend + Legende - The Legend provides an overview of the layers in the map. Layers - that appear higher in the legend will appear ``closer'' to the user. - If a layer supports classification (currently, only shape layers - have this feature) then the classification groups will be shown - below each layer. The properties for each group are also displayed - with a small graphic. Polygon layers appear as rectangles, lines - appear as curved lines, and points appear as circles. + Die Legende bietet eine Übersicht über die Ebenen der Karte. + Ebenen die weiter oben in der Legende stehen sind + ``näher'' zum Benutzer. + Falls eine Ebene Klassifizierung unterstützt (derzeit haben + nur Shape-Ebenen haben diese Eigenschaft) so werden die Gruppen + der Klassifikation für jede Ebene dargestellt. + Die Eigenschaften für jede Gruppe werden auch als kleine Grafiken + dargestellt. Polygon-Ebenen werden als Rechtecke dargestellt, + Linoen als Kurven und Punkte als Kreise. - Along the top of the legend is a toolbar which allows quick access - to some of the layer manipulation options under - Map. + Am oberen Rand der Legende ist eine Werkzeugleiste welche einen schnellen + Zugriff auf einige der Komanndos des Menüs + Map + gestattet. - The Move Layer to Top tool + Das Werkzeug @@ -841,14 +845,15 @@ - Move Layer to Top - raises the selected layer to the top of the map. + Auf die oberste Ebene bewegen + bewegt die selektierte Ebene auf der Karte + nach ganz oben. - The Move Layer Up tool + Das Werkzeug @@ -856,14 +861,15 @@ - Move Layer Up - raises the selected layer one level. + Eine Ebene nach oben bewegen + bewegt die selektierte Ebene um einen + Schritt nach oben. - The Move Layer Down tool + Das Werkzeug @@ -871,14 +877,15 @@ - Move Layer Down - lowers the selected layer one level. + Eine Ebene nach unten bewegen + bewegt die selektierte Ebene um einen Schritt + nach unten. - The Move Layer to Bottom tool + Das Werkzeug @@ -886,8 +893,9 @@ - Move Layer to Bottom - lowers the selected layer to the bottom of the map. + Auf die unterste Ebene bewegen + bewegt die selektierte Ebene auf + der Karte nach ganz unten. @@ -1548,14 +1556,14 @@ Ergebnisse aus Verknüpfungen). Die ausgewählten Tabellen werden nach der Bestätigung mit - OK in Tabellenansichten dargestellt.. + OK in Tabellenansichten dargestellt.
-
Join +
Verbinden
- Join Tables + Verbinde Tabellen @@ -1563,50 +1571,54 @@
- The + Der Menüpunkt - Table - Join + Tabelle + Verbinden - item raises a dialog to specify the two tables to be - joined. The join results in a new table named 'Join of "left table" - and "right table"'. + startet einen Dialog für die Angabe der beiden Tabellen die + verbunden werdn sollen. Das Ergebnis der Verbindung ist eine + neue Tabelle mit der Bezeichnung + 'Join of "linke Tabelle" and "rechte Tabelle"'. - The dialog lets you select the two tables to be joined and the two - fields the join has to be performed on. By default, the new - table contains only those records which are matched by the join. + Der Dialog erlaubt es die beiden zu verbindenden Tabellen sowie + die beiden Felder anzugeben über die die Verbindung hergestellt + werden soll. Als Voreinstellung beinhaltet die neue Tabelle + nur die Einträge für die entsprechende Übereinstimmungen + vorlagen. - If you want to preserve the records of the left table you can - perform an outer join. The fields from the right table for records - not matched by the join are filled with None in - this case. + Wollen Sie die Einträge der linken Tabelle erhalten, so können + Sie eine äussere Verbindung erstellen. Die Felder der rechten + Tabelle für Einträge ohne Übereinstimmung werden in diesem + Fall aufgefüllt mit dem Wert None.
-
Attribute Tables +
Attribut-Tabellen - To clearly separate between both types of tables (data and - attribute), Thuban provides functionality regarding the attribute - tables under the Layer menu. + Um klarer zwischen den beiden Tabellen-Typen (Daten und Attribute) zu + unterscheiden, bietet Thuban die Funktionalität für die Attribut-Tabellen + unter dem Menü + Ebene an. -
Show Table +
Zeige Tabelle - Layer - Show Table + Ebene + Zeige Tabelle - opens the attribute table of the currently active layer in a table - view. + öffnet die Attribut-Tabelle für die aktuell aktive Ebene in + einer Tabellenansicht. - In addition to the functionality described above selections - affect also the map display: objects related to selected records - are highlighted. + Eine zusätzliche Funktionalität bei diesen Tabellenansichten + ist, dass bei Selektionen die korrespondierenden Objekte + auf der Karte unmittelbar hervorgehoben werden.
-
Join Table +
Verbinde Tabelle Unlike the join described above, the join does not result in a new table. The attribute table of the currently active layer is the From cvs at intevation.de Fri Jan 14 16:51:39 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 14 Jan 2005 16:51:39 +0100 (CET) Subject: jan: thuban ChangeLog,1.755,1.756 Message-ID: <20050114155139.911AF102C08@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv27939 Modified Files: ChangeLog Log Message: more translation of manual into german. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.755 retrieving revision 1.756 diff -u -d -r1.755 -r1.756 --- ChangeLog 11 Jan 2005 16:52:40 -0000 1.755 +++ ChangeLog 14 Jan 2005 15:51:37 -0000 1.756 @@ -1,3 +1,7 @@ +2005-01-14 Jan-Oliver Wagner + + * Doc/manual/thuban-manual-de.xml: More translations. + 2005-01-11 Frank Koormann * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): From jan at intevation.de Fri Jan 14 17:37:19 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Fri, 14 Jan 2005 17:37:19 +0100 Subject: multiple rasters && mapview In-Reply-To: <1105538389.7177.18.camel@localhost.localdomain> References: <16863.34667.62805.87273@desk.crynwr.com> <1105538389.7177.18.camel@localhost.localdomain> Message-ID: <20050114163719.GA16626@intevation.de> On Wed, Jan 12, 2005 at 08:59:49AM -0500, Jonathan Coles wrote: > Am Samstag, den 08.01.2005, 02:10 -0500 schrieb Russell Nelson: > > I'm still tracking down the problem with multiple rasters. The > > intrinsic problem is that ProjectRasterFile (called from > > baserenderer.py and implemented in gdalwarp.cpp) always creates a > > bitmap that fills the viewport. > > > The fix is going to have to be in the way ProjectRasterFile gets > > called. Instead of creating a BMP image, it needs to return a > > wxImage, clipping mask, and offset. > > when i first implemented the raster code i discovered that the bounding > box of the projected image is different (usually larger) than the > bounding box returned from layer.LatLongBoundingBox(). this is because > the image may curve outward between the two extreme x points, but the > extreme of the outward curve is not recognized as the extend of the > bounding box. if you use those values to calculate the parameters to > ProjectRasterFile gdal generates an image which does not properly cover > the area you want. the quick fix was to have gdal generate an image that > covers the whole window. while obviously not ideal, this worked for a > first attempt. > > i hacked up a quick solution (disclaimer: may not work in all instances) > that renders as little of the raster layer image as possible. however, > as i said before, since the projected bounding box information is > incorrect the image is not quite right. > > if you can figure out how to correctly determine the projected bounding > box size, then i think you will be able to a) decrease the rendering > time since gdal isn't making an image for the whole window and b) easily > allow for multiple raster layers without using masks. > > try the modifications to renderer.py and baserenderer.py i've listed > below and then load the iceland_sample_raster.thuban file to see what > i'm talking about. my code base is based on a cvs checkout from last > night. I've tried your patch and besides the visual effects I observed increased instead of reduced render time. I've used the profiling extension to measure this. In fact, the performance dramtaically goes down the deeper I zoom into the Iceland raster map. > p.s. a big hello to everyone at intevation! hope you are all doing well. Nice to read from you, Jonathan. Good to know you scan the thuban-devel and jump up if we are talking about your code ;-) Things are well but busy at Intevation. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jonathan at jpcoles.com Fri Jan 14 19:39:50 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Fri, 14 Jan 2005 13:39:50 -0500 Subject: multiple rasters && mapview In-Reply-To: <20050114163719.GA16626@intevation.de> References: <16863.34667.62805.87273@desk.crynwr.com> <1105538389.7177.18.camel@localhost.localdomain> <20050114163719.GA16626@intevation.de> Message-ID: <1105727991.7177.48.camel@localhost.localdomain> Am Freitag, den 14.01.2005, 17:37 +0100 schrieb Jan-Oliver Wagner: > I've tried your patch and besides the visual effects I observed > increased instead of reduced render time. I've used the profiling > extension to measure this. > > In fact, the performance dramtaically goes down the deeper I zoom > into the Iceland raster map. yes, you are correct. i located the problem and a new patch (relative to CVS) is listed below. the problem came up because the width and height of the image were not calculated correctly. gdalwarp was trying to generate a *very* large image. this new version should behave a lot better, but i've only tested it with the iceland data and two projections. i don't know if things will be ok with all data and all projections. it seems to me that a lot of time is used just converting the image. from a few print statements and eyeballing the results, the wxImageFromStream() call in draw_raster_data() is what is taking most of the time. very little time is spent in the gdal or actual drawing code. --jonathan RCS file: /home/thuban/jail/thubanrepository/thuban/Thuban/UI/baserenderer.py,v retrieving revision 1.13 diff -r1.13 baserenderer.py 372a373 > 477,480c478,507 < xmin = (0 - offx) / self.scale < ymin = (offy - height) / self.scale < xmax = (width - offx) / self.scale < ymax = (offy - 0) / self.scale --- > #xmin = (0 - offx) / self.scale > #ymin = (offy - height) / self.scale > #xmax = (width - offx) / self.scale > #ymax = (offy - 0) / self.scale > > bb = layer.LatLongBoundingBox() > bb = [[[bb[0], bb[1]], [bb[2], bb[3]],],] > > pmin, pmax = self.projected_points(layer, bb)[0] > > #print "**********" > #print pmin, pmax > #print width, height > > fmin = [max(0, pmin[0]) - offx, offy - min(height, pmin[1])] > fmax = [min(width, pmax[0]) - offx, offy - max(0, pmax[1])] > > xmin = fmin[0]/self.scale > ymin = fmin[1]/self.scale > xmax = fmax[0]/self.scale > ymax = fmax[1]/self.scale > > width = min(width, fmax[0] - fmin[0] + 1) > height = min(height, fmax[1] - fmin[1] + 1) > > #print pmin, pmax > #print xmin, ymin, xmax, ymax > #print width, height > > #print offx, offy #, offx*self.scale, offy*self.scale 493c520 < self.draw_raster_data(data, "BMP") --- > self.draw_raster_data(fmin[0]+offx, offy-fmax[1], data, "BMP") 495c522 < def draw_raster_data(self, data, format="BMP"): --- > def draw_raster_data(self, x, y, data, format="BMP"): -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From bernhard at intevation.de Fri Jan 14 20:09:14 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 14 Jan 2005 20:09:14 +0100 Subject: very slow development In-Reply-To: <16868.6608.614047.929044@desk.crynwr.com> References: <16868.3737.440900.697135@desk.crynwr.com> <20050111180558.GF927@finlandia.infodrom.north.de> <16868.6608.614047.929044@desk.crynwr.com> Message-ID: <20050114190914.GK6661@intevation.de> On Tue, Jan 11, 2005 at 01:24:16PM -0500, Russell Nelson wrote: > Martin Schulze writes: > > I'd say work on the layer, and if the AdjustScale won't be accepted > > as it is now, adjust the layer again (and again (and again (..))) > > until everything fits. > > Okay. If that does not work out with patches, we can use an experimental CVS branch for this, which would make it easier for other developers to look at your code from time to time. As I wrote before, sometimes at Intevation we are very consumed in our projects and on other days we have time for Thuban, so development for us happens in intensive chunks with sometime long pauses. We want your contribution so please suggest whatever you think is good to help your way of development. Bernhard R. -------------- 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/20050114/b602ca96/attachment.bin From jonathan at jpcoles.com Fri Jan 14 21:14:49 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Fri, 14 Jan 2005 15:14:49 -0500 Subject: multiple rasters && mapview In-Reply-To: <16863.34667.62805.87273@desk.crynwr.com> References: <16863.34667.62805.87273@desk.crynwr.com> Message-ID: <1105733689.7177.57.camel@localhost.localdomain> Am Samstag, den 08.01.2005, 02:10 -0500 schrieb Russell Nelson: > The fix is going to have to be in the way ProjectRasterFile gets > called. Instead of creating a BMP image, it needs to return a > wxImage, clipping mask, and offset. I don't know enough about GDAL to > be able to do that yet. I may need help with the Python bindings, but > I'll ask for it when I need it. are you going to be looking into changing ProjectRasterFile to return a wxImage? i've been taking a look at the code and i think i can make the necessary changes. i'll try to give it more work this weekend if i get a chance. i don't think it should be *too* difficult -- i did it once before to get BMP support :) i agree that these changes would improve the speed dramatically. also, with the patch that i've been passing around, things are much better when the original image doesn't cover the whole window. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From nelson at crynwr.com Fri Jan 14 21:22:31 2005 From: nelson at crynwr.com (Russell Nelson) Date: Fri, 14 Jan 2005 15:22:31 -0500 Subject: multiple rasters && mapview In-Reply-To: <1105733689.7177.57.camel@localhost.localdomain> References: <16863.34667.62805.87273@desk.crynwr.com> <1105733689.7177.57.camel@localhost.localdomain> Message-ID: <16872.10759.499691.892103@desk.crynwr.com> Jonathan Coles writes: > are you going to be looking into changing ProjectRasterFile to return a > wxImage? I need more experience with wxWindows, so I'm going to work on the Terra Raster Layer first. It would be great if you could do it. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bernhard at intevation.de Fri Jan 14 22:05:21 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 14 Jan 2005 22:05:21 +0100 Subject: learning more about wxpython In-Reply-To: <16872.10759.499691.892103@desk.crynwr.com> References: <16863.34667.62805.87273@desk.crynwr.com> <1105733689.7177.57.camel@localhost.localdomain> <16872.10759.499691.892103@desk.crynwr.com> Message-ID: <20050114210521.GT6661@intevation.de> On Fri, Jan 14, 2005 at 03:22:31PM -0500, Russell Nelson wrote: > I need more experience with wxWindows, so I'm going to work on the > Terra Raster Layer first. It would be great if you could do it. You probably already know the most important hint when learning more about wxWidgets and wxPython: check out the demo. ;) -------------- 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/20050114/9eee685c/attachment.bin From bh at intevation.de Fri Jan 14 22:13:40 2005 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 14 Jan 2005 22:13:40 +0100 Subject: multiple rasters && mapview In-Reply-To: <1105538389.7177.18.camel@localhost.localdomain> (Jonathan Coles's message of "Wed, 12 Jan 2005 08:59:49 -0500") References: <16863.34667.62805.87273@desk.crynwr.com> <1105538389.7177.18.camel@localhost.localdomain> Message-ID: Jonathan Coles writes: > when i first implemented the raster code i discovered that the bounding > box of the projected image is different (usually larger) than the > bounding box returned from layer.LatLongBoundingBox(). this is because > the image may curve outward between the two extreme x points, but the > extreme of the outward curve is not recognized as the extend of the > bounding box. [...] > if you can figure out how to correctly determine the projected bounding > box size, then i think you will be able to a) decrease the rendering > time since gdal isn't making an image for the whole window and b) easily > allow for multiple raster layers without using masks. It can't be done properly without masks because as you note the boundary of the projected image is not rectangular. It usually has curved edges and even if it were rectangular, it's may not be axis aligned. The only way to draw that properly while only drawing the part of the window actually covered by the projected image is to return an image with an appropriate alpha channel or a mask bitmap in addition the actual image. The strategy I used in Skencil 0.6 is to have one raster image, let's call it C for "canvas") the size of the window. When a raster image is to be rendered, it is rendered into C while also determining which pixels are actually covered by the rendered image. The image may be transformed with an arbitrary affine transformation, so the region covered often isn't a simple axis aligned rectangle, although it's not as complicated as the case Thuban has to handle. The image C is reused for every raster image so that it doesn't have to be allocated over and over again. It should be possible to do something similar in Thuban. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From jonathan at jpcoles.com Tue Jan 18 00:32:21 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Mon, 17 Jan 2005 18:32:21 -0500 Subject: multiple rasters && mapview In-Reply-To: References: <16863.34667.62805.87273@desk.crynwr.com> <1105538389.7177.18.camel@localhost.localdomain> Message-ID: <1106004742.7177.167.camel@localhost.localdomain> Am Freitag, den 14.01.2005, 22:13 +0100 schrieb Bernhard Herzog: > Jonathan Coles writes: > > > when i first implemented the raster code i discovered that the bounding > > box of the projected image is different (usually larger) than the > > bounding box returned from layer.LatLongBoundingBox(). this is because > > the image may curve outward between the two extreme x points, but the > > extreme of the outward curve is not recognized as the extend of the > > bounding box. > [...] > > if you can figure out how to correctly determine the projected bounding > > box size, then i think you will be able to a) decrease the rendering > > time since gdal isn't making an image for the whole window and b) easily > > allow for multiple raster layers without using masks. > > It can't be done properly without masks because as you note the boundary > of the projected image is not rectangular. It usually has curved edges > and even if it were rectangular, it's may not be axis aligned. The only > way to draw that properly while only drawing the part of the window > actually covered by the projected image is to return an image with an > appropriate alpha channel or a mask bitmap in addition the actual image. i think what i had in mind about not needing a mask is different than what you are thinking. what i meant to say was, if you are simplying trying not to have gdal generate a large image that covers the screen, and are content to have a smaller image that may contain patches of "no data" pixels, then it isn't necessary to use a mask, just a better bounding box. i agree with you, however, that a mask (or alpha channel) is necessary to get a "tight" image where there are no "no data" pixels. > The strategy I used in Skencil 0.6 is to have one raster image, let's > call it C for "canvas") the size of the window. When a raster image is > to be rendered, it is rendered into C while also determining which > pixels are actually covered by the rendered image. i'm sending out a email in a few minutes that discusses a solution. gdal warp actually supports "no data" and i can tell DrawBitmap what color to consider the mask color. apply the patches and run the iceland_sample_raster to see what i mean. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From jonathan at jpcoles.com Tue Jan 18 00:33:58 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Mon, 17 Jan 2005 18:33:58 -0500 Subject: multiple rasters && mapview In-Reply-To: <16872.10759.499691.892103@desk.crynwr.com> References: <16863.34667.62805.87273@desk.crynwr.com> <1105733689.7177.57.camel@localhost.localdomain> <16872.10759.499691.892103@desk.crynwr.com> Message-ID: <1106004838.7177.168.camel@localhost.localdomain> Am Freitag, den 14.01.2005, 15:22 -0500 schrieb Russell Nelson: > Jonathan Coles writes: > > are you going to be looking into changing ProjectRasterFile to return a > > wxImage? > > I need more experience with wxWindows, so I'm going to work on the > Terra Raster Layer first. It would be great if you could do it. well, i spent the majority of saturday working on this, and i think i've got a nice solution. quick overview ============== o Faster rendering: - Changed the output format of ProjectRasterFile to an array of RGB values, which eliminates the need for wxImageFromStream. If the format is something else then continue to use wxImageFromStream. - Instead of using the custom gdal driver, use the in-memory driver already provided and do a quick data translation. o NO_DATA support from gdal. parts of a projected image that aren't "real" are colored in a fixed color which can optionally be masked off when the image is draw. o Smaller code size. the changes actually greatly simplified the code, allowing me to remove several support files. o Small memory leak in ProjectRasterFile found and fixed. detailed explanation ==================== it isn't possible to return a wxImage from ProjectRasterFile because a wxImage at the C++ level is very different from the wxImage in python. however, it is possible to return an array of RGB values where the length of the array equals 3*width*height. this may not sound much different from before, but wxImage has a method called SetData which expects an array just like the one i described. calling SetData is a fast operation, unlike wxImageFromStream, which was uncompressing a BMP file. before i could return an array like this, i ripped out the old gdal driver i had written/modified. the driver was the gdal BMP driver that had been changed so instead of writing data to a file it would write it to memory. the modifications had required that i also implement my own version of the file I/O interface to hide a linked list. i discovered a much better way. gdal already has an in-memory driver which writes the data to memory. the only problem is that the organization of the data is not in RGB format. i wrote the function GetImageData that translates the data from the raster band format with color table lookup into a contiguous array of RGB values. doing this meant i could throw away my BMP driver and memory I/O code (files bmpdataset.cpp and cpl_mfile.* can be deleted). i did have to copy over the file memdataset.h from the gdal source since it is not available in the debian development package. i'm attaching the file, which needs to be put in libraries/thuban. you may wonder if it is worth writing a specialized memory driver that stores the data in the proper format as soon as the driver's write function is called. i thought about this and came to the conclusion that the only savings would be a bit of memory because an additional array has to allocated to perform the copy. there would be no real speed difference since the same translation code would have to execute in the write function. whether the translation occurs as the data is written or afterwards makes no difference. if the memory problem really becomes an issue in the future, then this may be the way to go, but for now the trouble of writing and then maintaining such code is not worth it (IMO). after all of these changes, almost all of the time that is being spent in ProjectRasterFile is spent calling GDALSimpleImageWarp(). on tests i ran with the Thuban window very large and the iceland sample at full extent, a call to GDALSimpleImageWarp took, on average, 0.4 seconds. i'm not sure what can be done to improve this, as a call to GDALSimpleImageWarp may be a hard limit. on the python end of things, i kept the changes i made earlier in the week which attempted to use the bounding box of the raster layer, rather than the extents of the whole window. this is known not to be accurate and i agree with bernhard herzog that the best way around this is using a mask (more on this later). a simple 'if' in the code toggles between the two methods. the code has to be modified directly to see the difference. i also changed the calling signature of draw_raster_data to draw_raster_data(self, x, y, data, format="BMP", mask = None). there is a new format called "RAW". i thought about making this the default, since that is what gdal returns, but decided to hold off on that until i get some feedback. in the implementation of draw_raster_data in renderer.py the RAW format is handled by creating and empty image and then calling SetData with the raw image data. this is much faster than calling wxImageFromData with BMP file data. the other formats are still supported, but they still go through the old, slower method of calling wxImageFromData. some of the test cases had to be updated to account for these changes. the mask parameter is documented in the function description, but basically, it allows a few methods of supplying masking information: the simplest of which is to specify a color that isn't to be drawn. not surprisingly, using the mask slows down the call to DrawBitmap. when no using a mask there is almost no slow down in rendering the final image. all the time is spent warping it. it will be possible in the future to add support for alpha blending if that is desired. newer versions of wxWindows supports this and it would be very easy to modify GetImageData to create an array of alpha data to supply to a wxImage. currently, ProjectRasterFile calls GDALSimpleImageWarp. in fact, most of gdalwarp.cpp was taken from the sample application gdalwarpsimple.cpp. it is called "simple" because it only supports 8-bit images and limited warping options. there is a more complex version that supports any datatype and significantly more options. the sample application is called gdalwarp.cpp and comes with the gdal source code. Thuban would, obviously, benefit to use the complex version. if the parameters to and results from a call to ProjectRasterData were cached, as was suggested, this would improve the case when the user is just resizing the window or, in some cases, panning. care would need to be taken in doing so, because if a layer is removed the cached image data should be deleted too. i removed the optimizations in layer drawing that drew the top most raster layer and then only layers above that. i did this with the anticipation of supporting multiple raster layers where the bounding box is not the whole screen or a mask is used. i've only been able to run tests using the iceland sample. i don't have any data with multiple, overlapping raster layers. if anyone does have such data and can send it to me, that would be great. ok, i think that's all for now :) i'm attaching the cvs diff and memdataset.h --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: memdataset.h Type: text/x-chdr Size: 5598 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050117/6827d2ee/memdataset.h -------------- next part -------------- A non-text attachment was scrubbed... Name: cvs.diff Type: text/x-patch Size: 19337 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050117/6827d2ee/cvs.diff From mlennert at club.worldonline.be Tue Jan 18 10:19:24 2005 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue, 18 Jan 2005 10:19:24 +0100 (CET) Subject: [Thuban-list] tests for Daniel Cavelo's classifiers Message-ID: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> [First one didn't come through since I forgot to gzip the patch.] Finally have come back to this: On Wed, October 20, 2004 6:53, Jan-Oliver Wagner said: > On Wed, Oct 20, 2004 at 12:14:43AM +0200, Moritz Lennert wrote: >> Daniel told me that the lack of test keeps his patches for the classifier from being integrated into the CVS. Could someone explain to me what exactly is needed in terms of tests and how I could contribute ? > > I tried to apply his patches some time ago but the did not apply cleanly to current CVS. I was about to analyse what tests are missing. > > So first step would be to apply the patch for HEAD. Attached is a version of the patches that applies cleanly to current (20050118 at ca. 1am) CVS HEAD, plus the necessary additional files that can just be dropped in. This version of the patch also includes two bug fixes, one to the discont algorithm and one general one, dealing with no data situations. > > Next, one should think about what are the most important tests > and add them to the directory test/ > There you can see how the other tests are made - not too difficult in practice but some brain work to have them useful. > test_color.py is a simple one to get the idea. I haven't had time to look into this in great detail (and won't have in the near future), so if someone else has the opportunity to do so, that would be great. (I guess I'll also have to read http://diveintopython.org/unit_testing/index.html in order to completely understand the testing business.) I would really appreciate if this patch could be integrated into cvs as that would make it possible to install with debian apt-get and have everything integrated... Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: class-custom-xtra-files.tar.gz Type: application/gzip Size: 4356 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050118/7c2cc80c/class-custom-xtra-files.tar.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: classification.patch.gz Type: application/gzip Size: 11747 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050118/7c2cc80c/classification.patch.gz From mlennert at club.worldonline.be Tue Jan 18 01:10:54 2005 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue, 18 Jan 2005 01:10:54 +0100 (CET) Subject: [Thuban-list] tests for Daniel Cavelo's classifiers In-Reply-To: <20041020055342.GE4897@intevation.de> References: <32862.83.134.238.100.1098224083.squirrel@vivegnulinux.homelinux.org> <20041020055342.GE4897@intevation.de> Message-ID: <33108.83.134.237.28.1106007054.squirrel@vivegnulinux.homelinux.org> Finally have come back to this: On Wed, October 20, 2004 6:53, Jan-Oliver Wagner said: > On Wed, Oct 20, 2004 at 12:14:43AM +0200, Moritz Lennert wrote: >> Daniel told me that the lack of test keeps his patches for the classifier >> from being integrated into the CVS. Could someone explain to me what >> exactly is needed in terms of tests and how I could contribute ? > > I tried to apply his patches some time ago but the did not apply cleanly > to current CVS. I was about to analyse what tests are missing. > > So first step would be to apply the patch for HEAD. Attached is a version of the patches that applies cleanly to current (20050118 at ca. 1am) CVS HEAD, plus the necessary additional files that can just be dropped in. This version of the patch also includes two bug fixes, one to the discont algorithm and one general one, dealing with no data situations. > > Next, one should think about what are the most important tests > and add them to the directory test/ > There you can see how the other tests are made - not too difficult > in practice but some brain work to have them useful. > test_color.py is a simple one to get the idea. I haven't had time to look into this in great detail (and won't have in the near future), so if someone else has the opportunity to do so, that would be great. (I guess I'll also have to read http://diveintopython.org/unit_testing/index.html in order to completely understand the testing business.) I would really appreciate if this patch could be integrated into cvs as that would make it possible to install with debian apt-get and have everything integrated... Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: classification.patch Type: application/octet-stream Size: 47576 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050118/cef911e9/classification.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: class-custom-xtra-files.tar.gz Type: application/gzip Size: 4356 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050118/cef911e9/class-custom-xtra-files.tar.gz From cvs at intevation.de Tue Jan 18 11:08:18 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 18 Jan 2005 11:08:18 +0100 (CET) Subject: frank: thuban/Extensions/mouseposition - New directory Message-ID: <20050118100818.7313510015A@lists.intevation.de> Author: frank Update of /thubanrepository/thuban/Extensions/mouseposition In directory doto:/tmp/cvs-serv32613/Extensions/mouseposition Log Message: Directory /thubanrepository/thuban/Extensions/mouseposition added to the repository From cvs at intevation.de Tue Jan 18 11:19:04 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 18 Jan 2005 11:19:04 +0100 (CET) Subject: frank: thuban/Extensions/mouseposition __init__.py, NONE, 1.1 mouseposition.py, NONE, 1.1 position.xpm, NONE, 1.1 Message-ID: <20050118101904.A68EB10015A@lists.intevation.de> Author: frank Update of /thubanrepository/thuban/Extensions/mouseposition In directory doto:/tmp/cvs-serv351/Extensions/mouseposition Added Files: __init__.py mouseposition.py position.xpm Log Message: New Extension: mouseposition Tool to collect mouse click positions (map coordinates) in a dialog. * Extensions/mouseposition/__init__.py: New, extension registration * Extensions/mouseposition/mouseposition.py: New, implements the dialog and adds a tool to Thuban mainwindow. * Extensions/mouseposition/position.xpm: New, icon for tool. --- NEW FILE: __init__.py --- # Copyright (C) 2005 by Intevation GmbH # Authors: # Frank Koormann (2005) # # This program is free software under the GPL (>=v2) # Read the file COPYING coming with Thuban for details. # import the actual module import mouseposition # perform the registration of the extension from Thuban import _ from Thuban.UI.extensionregistry import ExtensionDesc, ext_registry ext_registry.add(ExtensionDesc( name = 'mouseposition', version = '1.0.0', authors= [ 'Frank Koormann' ], copyright = '2005 Intevation GmbH', desc = _("On mouse click display the current coordinates\n" \ "in a dialog for easy further processing."))) --- NEW FILE: mouseposition.py --- # Copyright (C) 2005 by Intevation GmbH # Authors: # Frank Koormann (2005) # # This program is free software under the GPL (>=v2) # Read the file COPYING coming with Thuban for details. """ Extend thuban with a locator tool. Collect positions of mouse clicks (in map coordinates) in a text control. The tool was implemented in the need to collect some coordinates for some work (outside Thuban). The status bar display of the coordinates is quite transient (each mouse movement changes it) and cannot be copied. The tool let one simply collect the coordinates needed and copy them in one block later. """ __version__ = '$Revision: 1.1 $' # $Source: /thubanrepository/thuban/Extensions/mouseposition/mouseposition.py,v $ # $Id: mouseposition.py,v 1.1 2005/01/18 10:19:02 frank Exp $ import os, sys import string from wxPython import wx from wxPython.lib.layoutf import Layoutf from Thuban.UI.common import ThubanBeginBusyCursor, ThubanEndBusyCursor from Thuban.UI.command import registry, ToolCommand from Thuban.UI.mainwindow import main_menu, main_toolbar, \ make_check_current_tool from Thuban.UI.viewport import Tool from Thuban.UI.dialogs import NonModalDialog from Thuban import _ import Thuban class DynamicMessageDialog(NonModalDialog): """Similar to the wxScrolledMessageDialog, contents dynamically changeable by calling applications. """ def __init__(self, parent, msg, name, caption, pos = wx.wxDefaultPosition): NonModalDialog.__init__(self, parent, name, caption) x, y = pos if x == -1 and y == -1: self.CenterOnScreen(wx.wxBOTH) text = wx.wxTextCtrl(self, -1, msg, wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxTE_MULTILINE | wx.wxTE_READONLY) ok = wx.wxButton(self, wx.wxID_OK, "OK") text.SetConstraints(Layoutf('t=t5#1;b=t5#2;l=l5#1;r=r5#1', (self,ok))) ok.SetConstraints(Layoutf('b=b5#1;x%w50#1;w!80;h!25', (self,))) wx.EVT_BUTTON(self, wx.wxID_OK, self.OnClose) self.text = text self.SetAutoLayout(1) self.Layout() def getText(self): return self.text.GetValue() def setText(self, text): self.text.SetValue(text) def appendText(self, text): self.text.AppendText(text) class MousePositionTool(Tool): def __init__(self, view, context): Tool.__init__(self, view) self.context = context self.dlg = None def Name(self): return "MousePositionTool" def MouseDown(self, event): map_proj = self.view.Map().GetProjection() pos = self.view.CurrentPosition() if pos is not None: pMsg = "%10.10g, %10.10g\n" % pos name = "extension_mouse_position" dialog = self.context.mainwindow.get_open_dialog(name) if dialog is None: dialog = DynamicMessageDialog(self.context.mainwindow, pMsg, name, _("Mouse Position Tool")) self.context.mainwindow.add_dialog(name, dialog) dialog.Show(True) else: dialog.appendText(pMsg) dialog.Raise() def mouse_position_tool(context): canvas = context.mainwindow.canvas canvas.SelectTool(MousePositionTool(canvas, context)) # locator executed as an tool/extension to Thuban iconfile = os.path.join(os.path.abspath(Thuban.__path__[0]), "..", "Resources", "Bitmaps", "identify") iconfile = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'position') registry.Add(ToolCommand("mouse_position_tool", "Mouse Position Tool", mouse_position_tool, icon = iconfile, helptext = "Collect mouse click coordinates in a dialog", checked = make_check_current_tool("MousePositionTool"))) # Add the command to the toolbar main_toolbar.InsertSeparator() main_toolbar.InsertItem("mouse_position_tool") # find the extensions menu (create it anew if not found) extensions_menu = main_menu.FindOrInsertMenu('extensions', _('E&xtensions')) # finally add the new entry to the extensions menu extensions_menu.InsertItem('mouse_position_tool') --- NEW FILE: position.xpm --- /* XPM */ static char * position_xpm[] = { "24 24 3 1", " c None", ". c #000000", "+ c #949194", " ", " ", " . ", " . .... ", " .+ .+... .. ", " .. .+......... ", " ..+ .+........... ", " ... ..+...........+ ", " ...+ .+............+ ", " .... .............++ ", " ....+.+ ..........+ ", " ......+ +.......++ ", " .....++ ++....+ ", " ......+ ++++ ", " ......+ ", " ....... ", " ...+...+ ", " ..++.... ", " .++.+++.+ ", " + .+ ++ ", " .+ ", " .+ ", " + ", " "}; From cvs at intevation.de Tue Jan 18 11:19:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 18 Jan 2005 11:19:27 +0100 (CET) Subject: frank: thuban ChangeLog,1.756,1.757 Message-ID: <20050118101927.5694110015A@lists.intevation.de> Author: frank Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv389 Modified Files: ChangeLog Log Message: New Extension: mouseposition Tool to collect mouse click positions (map coordinates) in a dialog. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.756 retrieving revision 1.757 diff -u -d -r1.756 -r1.757 --- ChangeLog 14 Jan 2005 15:51:37 -0000 1.756 +++ ChangeLog 18 Jan 2005 10:19:25 -0000 1.757 @@ -1,3 +1,15 @@ +2005-01-18 Frank Koormann + + New Extension: mouseposition + Tool to collect mouse click positions (map coordinates) in a dialog. + + * Extensions/mouseposition/__init__.py: New, extension registration + + * Extensions/mouseposition/mouseposition.py: New, implements the + dialog and adds a tool to Thuban mainwindow. + + * Extensions/mouseposition/position.xpm: New, icon for tool. + 2005-01-14 Jan-Oliver Wagner * Doc/manual/thuban-manual-de.xml: More translations. From Silke.Reimer at intevation.de Tue Jan 18 11:34:50 2005 From: Silke.Reimer at intevation.de (Silke Reimer) Date: Tue, 18 Jan 2005 11:34:50 +0100 Subject: multiple rasters && mapview In-Reply-To: <1106004838.7177.168.camel@localhost.localdomain> References: <16863.34667.62805.87273@desk.crynwr.com> <1105733689.7177.57.camel@localhost.localdomain> <16872.10759.499691.892103@desk.crynwr.com> <1106004838.7177.168.camel@localhost.localdomain> Message-ID: <20050118103450.GB10859@intevation.de> Hi Jonathan, On Mon, Jan 17, 2005 at 06:33:58PM -0500, Jonathan Coles wrote: > Am Freitag, den 14.01.2005, 15:22 -0500 schrieb Russell Nelson: > > Jonathan Coles writes: > > > are you going to be looking into changing ProjectRasterFile to return a > > > wxImage? > > > > I need more experience with wxWindows, so I'm going to work on the > > Terra Raster Layer first. It would be great if you could do it. > > well, i spent the majority of saturday working on this, and i think i've > got a nice solution. > > quick overview > ============== > > o Faster rendering: > - Changed the output format of ProjectRasterFile to an > array of RGB values, which eliminates the need for > wxImageFromStream. If the format is something else > then continue to use wxImageFromStream. > - Instead of using the custom gdal driver, use the in-memory > driver already provided and do a quick data translation. > > o NO_DATA support from gdal. parts of a projected image that > aren't "real" are colored in a fixed color which can > optionally be masked off when the image is draw. > > o Smaller code size. the changes actually greatly simplified > the code, allowing me to remove several support files. > > o Small memory leak in ProjectRasterFile found and fixed. I didn't yet apply your patch to Thuban but it sounds very promising. Thank you for spending the whole Saturday on this issue :-) > i did have to copy over the file memdataset.h from the gdal source since > it is not available in the debian development package. i'm attaching the > file, which needs to be put in libraries/thuban. If it becomes necessary I could put memdataset.h into the libgdal1-dev package since I am maintainer for gdal in debian. So if your patch will be included into Thuban you can count on it. Many greetings, Silke -- Intevation GmbH Georgstrasse 4 49074 Osnabr?ck, Germany http://intevation.de http://intevation.de/~silke FreeGIS.org http://freegis.org/ -------------- 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/20050118/95bf1a8c/attachment.bin From jonathan at jpcoles.com Tue Jan 18 14:12:53 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Tue, 18 Jan 2005 08:12:53 -0500 Subject: multiple rasters && mapview In-Reply-To: <20050118103450.GB10859@intevation.de> References: <16863.34667.62805.87273@desk.crynwr.com> <1105733689.7177.57.camel@localhost.localdomain> <16872.10759.499691.892103@desk.crynwr.com> <1106004838.7177.168.camel@localhost.localdomain> <20050118103450.GB10859@intevation.de> Message-ID: <1106053973.7177.174.camel@localhost.localdomain> Hi Silke, Am Dienstag, den 18.01.2005, 11:34 +0100 schrieb Silke Reimer: > I didn't yet apply your patch to Thuban but it sounds very > promising. Thank you for spending the whole Saturday on this issue > :-) > > > i did have to copy over the file memdataset.h from the gdal source since > > it is not available in the debian development package. i'm attaching the > > file, which needs to be put in libraries/thuban. > > If it becomes necessary I could put memdataset.h into the > libgdal1-dev package since I am maintainer for gdal in debian. So if > your patch will be included into Thuban you can count on it. i went back to see if it was absolutely necessary to include memdataset.h. it turns out that if i call a different method which is exposed in the base class GDALDataset i don't need to include memdataset.h. this is clearly much better since memdataset.h may not appear in all development packages, even if was included in the debian package. i'm attaching another version of the diffs which include the changes. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: cvs.diff Type: text/x-patch Size: 19314 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050118/534b1bea/cvs.diff From nelson at crynwr.com Tue Jan 18 19:29:00 2005 From: nelson at crynwr.com (Russell Nelson) Date: Tue, 18 Jan 2005 13:29:00 -0500 Subject: multiple rasters && mapview In-Reply-To: <1106053973.7177.174.camel@localhost.localdomain> References: <16863.34667.62805.87273@desk.crynwr.com> <1105733689.7177.57.camel@localhost.localdomain> <16872.10759.499691.892103@desk.crynwr.com> <1106004838.7177.168.camel@localhost.localdomain> <20050118103450.GB10859@intevation.de> <1106053973.7177.174.camel@localhost.localdomain> Message-ID: <16877.21868.121170.109792@desk.crynwr.com> Jonathan Coles writes: > i'm attaching another version of the diffs which include the changes. Doesn't work for me. The map is rendered with the wrong colors and flipped top for bottom. I suspect GetImageData is the guilty party. Here's the dataset (137KB): http://russnelson.com/potsdam-railroads.tar.gz On the plus side, it generates wrong results MUCH faster. :-) -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From jonathan at jpcoles.com Tue Jan 18 22:12:11 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Tue, 18 Jan 2005 16:12:11 -0500 Subject: multiple rasters && mapview In-Reply-To: <16877.21868.121170.109792@desk.crynwr.com> References: <16863.34667.62805.87273@desk.crynwr.com> <1105733689.7177.57.camel@localhost.localdomain> <16872.10759.499691.892103@desk.crynwr.com> <1106004838.7177.168.camel@localhost.localdomain> <20050118103450.GB10859@intevation.de> <1106053973.7177.174.camel@localhost.localdomain> <16877.21868.121170.109792@desk.crynwr.com> Message-ID: <1106082731.3336.47.camel@localhost.localdomain> Am Dienstag, den 18.01.2005, 13:29 -0500 schrieb Russell Nelson: > Jonathan Coles writes: > > i'm attaching another version of the diffs which include the changes. > > Doesn't work for me. The map is rendered with the wrong colors and > flipped top for bottom. I suspect GetImageData is the guilty party. > Here's the dataset (137KB): > > http://russnelson.com/potsdam-railroads.tar.gz yes, GetImageData was to blame. it assumed that the image was palette based and that there was only one raster band (i only had iceland_sample_raster.tif to work with). your image is not palette based and has 3 raster bands (one for each of RGB). i've reorganized GetImageData so that it should work with a much wider range of image: those with no palette and 3 bands (assumed to be RGB, although gdal works with others, i need conversion formulas. i can get these later), those with one band and no palette (some greyscale images), and those with one band and a palette. there are a few assumptions that are still made. if the image has more than three bands, like an alpha channel, it will be ignored and you won't get anything. i hope to be able to do something about this, but i just wanted to get this working with your data first. on my machine i can now load your sample data with no problem (had to change the image path in your .thuban file). i've attached a complete cvs diff, although the only file that has changed since my last diff is gdalwarp.cpp. if you find anything else that doesn't work, please send it to me. > > On the plus side, it generates wrong results MUCH faster. :-) > great! --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: cvs.diff Type: text/x-patch Size: 22667 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050118/9f73d608/cvs.diff From thuban-bugs at intevation.de Wed Jan 19 14:32:15 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Wed, 19 Jan 2005 14:32:15 +0100 (CET) Subject: [bug #2909] (thuban) ums_mapserver extension: cannot save mapfile twice Message-ID: <20050119133215.AA747102BD8@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2909 ------------------------------------------------------------------------- Subject: ums_mapserver extension: cannot save mapfile twice Operating System: GNU/Linux, Debian testing/unstable Thuban version: 1.0.1, cvs20050118 wxPython version: 2.4.2.4 Python version: 2.3.4 PySQLite version: 1.0 SQLite version: 2.8.15 GDAL version: 1.2.5 proj version: 4.4.9 Did you compile Thuban yourself? Yes, with dpkg-buildpackage Using the ums_mapserver extension, when I create a map file, then export it and then try to reexport it under the same or a different name I get the following error: An unhandled exception occurred: removeClass(): Child array error. Cannot remove class, invalid index 2 (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "/usr/lib/thuban/Thuban/UI/mainwindow.py", line 284, in invoke_command command.Execute(self.Context()) File "/usr/lib/thuban/Thuban/UI/command.py", line 121, in Execute apply(self.function, (context,) + self.args + args, kw) File "/usr/lib/thuban/Extensions/umn_mapserver/mf_export.py", line 159, in export_mapfile thuban_to_map(context, theMap) File "/usr/lib/thuban/Extensions/umn_mapserver/mf_export.py", line 106, in thuban_to_map tblayer_to_map(tb_map, map) File "/usr/lib/thuban/Extensions/umn_mapserver/mf_export.py", line 74, in tblayer_to_map map.add_thubanlayer(layer) File "/usr/lib/thuban/Extensions/umn_mapserver/mapfile.py", line 1045, in add_thubanlayer new_layer.remove_allclasses() File "/usr/lib/thuban/Extensions/umn_mapserver/mapfile.py", line 709, in remove_allclasses self._mf_layer.removeClass(i) File "/usr/lib/python2.3/site-packages/mapscript.py", line 1232, in removeClass def removeClass(*args): return _mapscript.layerObj_removeClass(*args) MapServerChildError: removeClass(): Child array error. Cannot remove class, invalid index 2 -------------------------------------------- Managed by Request Tracker From thuban-bugs at intevation.de Wed Jan 19 14:39:13 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Wed, 19 Jan 2005 14:39:13 +0100 (CET) Subject: [bug #2910] (thuban) about dialog crashes when changing locale to Message-ID: <20050119133913.B78F1102BE9@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2910 ------------------------------------------------------------------------- Subject: about dialog crashes when changing locale to Operating System: GNU/Linux, Debian testing/unstable Thuban version: 1.0.1, cvs20050118 wxPython version: 2.4.2.4 Python version: 2.3.4 PySQLite version: 1.0 SQLite version: 2.8.15 GDAL version: 1.2.5 proj version: 4.4.9 Did you compile Thuban yourself? Yes, with dpkg-buildpackage Changing the locale to "C" with LC_ALL=C and (optionally) LANG=C and then trying to look at the About... window I get: An unhandled exception occurred: encode() argument 1 must be string, not None (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "/usr/lib/thuban/Thuban/UI/mainwindow.py", line 284, in invoke_command command.Execute(self.Context()) File "/usr/lib/thuban/Thuban/UI/command.py", line 121, in Execute apply(self.function, (context,) + self.args + args, kw) File "/usr/lib/thuban/Thuban/UI/mainwindow.py", line 1004, in call_method apply(getattr(context.mainwindow, methodname), args) File "/usr/lib/thuban/Thuban/UI/mainwindow.py", line 479, in About dlg = About(self) File "/usr/lib/thuban/Thuban/UI/about.py", line 40, in __init__ developers = [ 'Jonathan Coles', File "/usr/lib/thuban/Thuban/UI/about.py", line 172, in unicodeToLocale return unicodeStr.encode(getdefaultlocale()[1]) TypeError: encode() argument 1 must be string, not None -------------------------------------------- Managed by Request Tracker From bernhard at intevation.de Wed Jan 19 22:15:17 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 19 Jan 2005 22:15:17 +0100 Subject: drawshap.diff (was: a question about my mapviewer program) In-Reply-To: <20050103161130.GF10243@intevation.de> References: <16848.24146.258982.334379@desk.crynwr.com> <20041227193738.GT1497@intevation.de> <16849.47143.624926.347698@desk.crynwr.com> <20050103161130.GF10243@intevation.de> Message-ID: <20050119211517.GA8276@intevation.de> On Mon, Jan 03, 2005 at 05:11:30PM +0100, Bernhard Reiter wrote: > On Tue, Dec 28, 2004 at 02:46:47PM -0500, Russell Nelson wrote: > > Excellent. May I suggest that Extensions/drawshape/patch.diff be > > applied to HEAD? It looks like a useful patch for any Extension which > > needs to use the right mouse button. > > Bernhard H. had a special reason for not applying it directly, I believe. Bernhard (H.): Do you remember what it was? -------------- 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/20050119/df714545/attachment.bin From bernhard at intevation.de Thu Jan 20 00:12:20 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 00:12:20 +0100 Subject: missing projection alert In-Reply-To: <16849.49445.322919.107611@desk.crynwr.com> References: <16849.49445.322919.107611@desk.crynwr.com> Message-ID: <20050119231220.GA10228@intevation.de> On Tue, Dec 28, 2004 at 03:25:09PM -0500, Russell Nelson wrote: > I have more confidence that the second patch (mainwindow.py) is > correct. If you have a layer whose LatLonBoundingBox returns values > which are not legitimate latitude or longitudes, the status bar gets a > message asking you to correct the projection. If you load a UTM map, > you'll get this message. Finally could check this patch out. Please commit, it seems fine overall. One one question: Could left=-180 be a valid value? Maybe we should use <= and >= instead of < and > in the comparision. From thuban-bugs at intevation.de Thu Jan 20 02:53:28 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Thu, 20 Jan 2005 02:53:28 +0100 (CET) Subject: [bug #2912] (thuban) An unhandled exception occurred:long int too large to convert to int Message-ID: <20050120015328.76550100179@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2912 ------------------------------------------------------------------------- Subject: An unhandled exception occurred:long int too large to convert to int Operating System: MS Windows Thuban version: 1.0.1 Please enter error description here. Did you compile Thuban yourself? NO If not, which binary package did you install (eg. where did you get it from)? An unhandled exception occurred: long int too large to convert to int (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "C:\bin\Thuban\Thuban\UI\mainwindow.py", line 282, in invoke_command command.Execute(self.Context()) File "C:\bin\Thuban\Thuban\UI\command.py", line 121, in Execute apply(self.function, (context,) + self.args + args, kw) File "C:\bin\Thuban\Thuban\UI\mainwindow.py", line 957, in call_method apply(getattr(context.mainwindow, methodname), args) File "C:\bin\Thuban\Thuban\UI\mainwindow.py", line 871, in ExportMap self.canvas.Export() File "C:\bin\Thuban\Thuban\UI\view.py", line 310, in Export renderer.RenderMap(selected_layer, selected_shapes) File "C:\bin\Thuban\Thuban\UI\renderer.py", line 257, in RenderMap self.render_legend() File "C:\bin\Thuban\Thuban\UI\renderer.py", line 325, in render_legend g.GetProperties(), shapeType) File "C:\bin\Thuban\Thuban\UI\classifier.py", line 1395, in Draw dc.DrawSpline([wxPoint(x, y + h), File "C:\bin\Python23\Lib\site-packages\wxPython\misc.py", line 240, in __init__ self.this = miscc.new_wxPoint(*_args,**_kwargs) OverflowError: long int too large to convert to int -------------------------------------------- Managed by Request Tracker From bh at intevation.de Thu Jan 20 09:42:56 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 20 Jan 2005 09:42:56 +0100 Subject: missing projection alert In-Reply-To: <16849.49445.322919.107611@desk.crynwr.com> (Russell Nelson's message of "Tue, 28 Dec 2004 15:25:09 -0500") References: <16849.49445.322919.107611@desk.crynwr.com> Message-ID: Russell Nelson writes: > Index: Thuban/UI/legend.py > =================================================================== > RCS file: /thubanrepository/thuban/Thuban/UI/legend.py,v > retrieving revision 1.37 > diff -u -r1.37 legend.py > --- Thuban/UI/legend.py 18 Apr 2004 20:37:45 -0000 1.37 > +++ Thuban/UI/legend.py 28 Dec 2004 20:11:45 -0000 > @@ -739,8 +739,18 @@ > dc.SelectObject(bmp) > dc.Clear() > > - if self.canvas.map is not None \ > - and self.canvas.map.projection is not None: > + > + if self.canvas.map is None: It's better to access the map with the Map() method. This was apparently wrong in the original code as well. Likewise, the projection should be fetched with the GetProjection() method. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bernhard at intevation.de Thu Jan 20 09:54:26 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 09:54:26 +0100 Subject: missing projection alert In-Reply-To: <20050119231220.GA10228@intevation.de> References: <16849.49445.322919.107611@desk.crynwr.com> <20050119231220.GA10228@intevation.de> Message-ID: <20050120085426.GB5553@intevation.de> On Thu, Jan 20, 2005 at 12:12:20AM +0100, Bernhard Reiter wrote: > On Tue, Dec 28, 2004 at 03:25:09PM -0500, Russell Nelson wrote: > > I have more confidence that the second patch (mainwindow.py) is > > correct. If you have a layer whose LatLonBoundingBox returns values > > which are not legitimate latitude or longitudes, the status bar gets a > > message asking you to correct the projection. If you load a UTM map, > > you'll get this message. > > Finally could check this patch out. > > Please commit, it seems fine overall. > One one question: > Could left=-180 be a valid value? > Maybe we should use <= and >= instead of < and > in the comparision. The more I think about it, I think it should indeep allow equality. Two more thoughts: As my test layer was your test.jpg called test, I think that added double quotation marks in the string could be a tiny improvements. I did read Select Layer test and ... And I thought, uh that is a nice menu function. ;) Do we actually want to allow working on unprojected layers? It might be that it breaks other assumtions within Thuban for the lat-long boundaries. If we have a clear no here, then we could throw an exception when setting the layer and have other code handle giving out a message. Anyway: Russel feel free to commit. Let me know if you want me do it, if you don't have time. Bernhard R. -------------- 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/20050120/db311dd6/attachment.bin From bernhard at intevation.de Thu Jan 20 09:57:34 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 09:57:34 +0100 Subject: very slow development In-Reply-To: <16868.3737.440900.697135@desk.crynwr.com> References: <16868.3737.440900.697135@desk.crynwr.com> Message-ID: <20050120085734.GC5553@intevation.de> On Tue, Jan 11, 2005 at 12:36:25PM -0500, Russell Nelson wrote: > This system -- where every patch to be checked-in must first be vetted > by ... somebody -- works very poorly for me. Actually this is a transitional phase. If we get a better feeling for your patches, you can do them right away if they are in your part of the code. As for other parts of the code, we all need to do it. ;) 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/20050120/ba8b349f/attachment.bin From bernhard at intevation.de Thu Jan 20 10:04:36 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 10:04:36 +0100 Subject: 089map.zip broken? In-Reply-To: <16835.44022.460828.230550@desk.crynwr.com> References: <16835.44022.460828.230550@desk.crynwr.com> Message-ID: <20050120090436.GD5553@intevation.de> On Fri, Dec 17, 2004 at 11:03:02PM -0500, Russell Nelson wrote: > http://russnelson.com/089map.zip > a pair of files describing a map of my county. Actually I cannot unzip 089map.zip. 249856 5cdddfd2ee0f37f97a4eefe8a0e7918f 089map.zip End-of-central-directory signature not found. -------------- 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/20050120/d48c54b7/attachment.bin From bernhard at intevation.de Thu Jan 20 10:27:55 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 10:27:55 +0100 Subject: Zooming and projection problems (was: Success (sort-of)!) In-Reply-To: <16837.50975.528784.554287@desk.crynwr.com> References: <16837.50975.528784.554287@desk.crynwr.com> Message-ID: <20050120092755.GE5553@intevation.de> On Sun, Dec 19, 2004 at 01:23:27PM -0500, Russell Nelson wrote: > Success!! I got my dataset to display correctly! > > That's good for me in that I can get my task done. However, the > trouble that I had indicates that Thuban is fragile. It doesn't > withstand native users very well. It has, in essence, the same > problem that GRASS has: intolerance of ignorance. After playing a bit with Russel's testdata (089uni00s.zip test.zip) I can only wholeheartedly agree! CVS of today. > Here's what I had to do: > 1) start with a new session (by running Thuban) > 2) set the projection of the session using Map/Projection... > 3) load the raster map, and set its projection using Layer/Projection... > 4) load the shapefile. If you miss 2) then even 3) will not help much and Thuban behaves oddly when zooming around even with 1). Probably more tests and thinking are needed but from a user perspective this is not inuitive. Zooming issues: I can zoom out to get a scalebar of 0..70 km, but after that a zoom out makes the map jump around and does not zoom out further. And I can loose the mapcontent because it gets out of focus. Zooming out should never make a user loose the mapcontent! I can zoom in to a scalebar of 0..600m and not further, okay, this probably is limited to the scaling issuses, still the user is not really informed of this. Probably both are limits of the UTM 18N map projection, but zooming still behaves badly. -------------- 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/20050120/769fcdcd/attachment.bin From cvs at intevation.de Thu Jan 20 11:00:36 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 11:00:36 +0100 (CET) Subject: bernhard: thuban/Thuban/UI about.py,1.18,1.19 Message-ID: <20050120100036.43E60102BD0@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv14098/Thuban/UI Modified Files: about.py Log Message: * Thuban/UiI/about.py: take iso-8859-15 when getdefaultlocale returns None. (Fixes rt#2910.) Index: about.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/about.py,v retrieving revision 1.18 retrieving revision 1.19 diff -u -d -r1.18 -r1.19 --- about.py 17 Dec 2004 18:48:49 -0000 1.18 +++ about.py 20 Jan 2005 10:00:34 -0000 1.19 @@ -169,4 +169,7 @@ # that's not direcly usable (it's missing a "cp" at the beginning). # getdefaultlocale does return a usable encoding name so we use that # instead. - return unicodeStr.encode(getdefaultlocale()[1]) + locale=getdefaultlocale()[1] + if locale is None: + locale = 'iso-8859-15' + return unicodeStr.encode(locale) From cvs at intevation.de Thu Jan 20 11:00:36 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 11:00:36 +0100 (CET) Subject: bernhard: thuban ChangeLog,1.757,1.758 Message-ID: <20050120100036.50DFD102BE5@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv14098 Modified Files: ChangeLog Log Message: * Thuban/UiI/about.py: take iso-8859-15 when getdefaultlocale returns None. (Fixes rt#2910.) Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.757 retrieving revision 1.758 diff -u -d -r1.757 -r1.758 --- ChangeLog 18 Jan 2005 10:19:25 -0000 1.757 +++ ChangeLog 20 Jan 2005 10:00:34 -0000 1.758 @@ -1,3 +1,8 @@ +2005-01-20 Bernhard Reiter + + * Thuban/UiI/about.py: take iso-8859-15 when getdefaultlocale returns + None. (Fixes rt#2910.) + 2005-01-18 Frank Koormann New Extension: mouseposition From bh at intevation.de Thu Jan 20 11:08:51 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 20 Jan 2005 11:08:51 +0100 Subject: bernhard: thuban ChangeLog,1.757,1.758 In-Reply-To: <20050120100036.50DFD102BE5@lists.intevation.de> (cvs@intevation.de's message of "Thu, 20 Jan 2005 11:00:36 +0100 (CET)") References: <20050120100036.50DFD102BE5@lists.intevation.de> Message-ID: cvs at intevation.de writes: > * Thuban/UiI/about.py: take iso-8859-15 when getdefaultlocale returns > None. (Fixes rt#2910.) Are you sure we can rely on latin1 in the "C" locale? -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Thu Jan 20 12:30:54 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 12:30:54 +0100 (CET) Subject: bernhard: thuban ChangeLog,1.758,1.759 Message-ID: <20050120113054.7F687102BDC@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv23472 Modified Files: ChangeLog Log Message: * Thuban/UI/classgen.py (OnRetrieve()): Add a OnRangeText(0) to work around a different in wx Behaviour noticed on MacOSX, thanks to Lorenzo Moretti and Daniel Calvelo for the fix. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.758 retrieving revision 1.759 diff -u -d -r1.758 -r1.759 --- ChangeLog 20 Jan 2005 10:00:34 -0000 1.758 +++ ChangeLog 20 Jan 2005 11:30:52 -0000 1.759 @@ -1,6 +1,12 @@ 2005-01-20 Bernhard Reiter - * Thuban/UiI/about.py: take iso-8859-15 when getdefaultlocale returns + * Thuban/UI/classgen.py (OnRetrieve()): Add a OnRangeText(0) + to work around a different in wx Behaviour noticed on MacOSX, + thanks to Lorenzo Moretti and Daniel Calvelo for the fix. + +2005-01-20 Bernhard Reiter + + * Thuban/UI/about.py: take iso-8859-15 when getdefaultlocale returns None. (Fixes rt#2910.) 2005-01-18 Frank Koormann From cvs at intevation.de Thu Jan 20 12:30:54 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 12:30:54 +0100 (CET) Subject: bernhard: thuban/Thuban/UI classgen.py,1.34,1.35 Message-ID: <20050120113054.84291102BE5@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv23472/Thuban/UI Modified Files: classgen.py Log Message: * Thuban/UI/classgen.py (OnRetrieve()): Add a OnRangeText(0) to work around a different in wx Behaviour noticed on MacOSX, thanks to Lorenzo Moretti and Daniel Calvelo for the fix. Index: classgen.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/classgen.py,v retrieving revision 1.34 retrieving revision 1.35 diff -u -d -r1.34 -r1.35 --- classgen.py 15 Dec 2004 16:42:56 -0000 1.34 +++ classgen.py 20 Jan 2005 11:30:52 -0000 1.35 @@ -904,6 +904,7 @@ try: min, max = table.ValueRange(self.fieldName) self.text_range.SetValue("[" + str(min) + ";" + str(max) + "]") + self.OnRangeText(0) finally: ThubanEndBusyCursor() From bh at intevation.de Thu Jan 20 12:34:29 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 20 Jan 2005 12:34:29 +0100 Subject: bernhard: thuban/Thuban/UI classgen.py,1.34,1.35 In-Reply-To: <20050120113054.84291102BE5@lists.intevation.de> (cvs@intevation.de's message of "Thu, 20 Jan 2005 12:30:54 +0100 (CET)") References: <20050120113054.84291102BE5@lists.intevation.de> Message-ID: cvs at intevation.de writes: > --- classgen.py 15 Dec 2004 16:42:56 -0000 1.34 > +++ classgen.py 20 Jan 2005 11:30:52 -0000 1.35 > @@ -904,6 +904,7 @@ > try: > min, max = table.ValueRange(self.fieldName) > self.text_range.SetValue("[" + str(min) + ";" + str(max) + "]") > + self.OnRangeText(0) Can you add a comment to the sources about this work-around as well? The fix is a bit ugly since on the platform where we don't need the explicit OnRangeText call, OnRangeText ends up being called twice. Also, why 0 as parameter? Strictly speaking it should be the event object, since it's an event handler. We don't have the appropriate event, so None seems more reasonable. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bernhard at intevation.de Thu Jan 20 12:38:49 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 12:38:49 +0100 Subject: bernhard: thuban ChangeLog,1.757,1.758 In-Reply-To: References: <20050120100036.50DFD102BE5@lists.intevation.de> Message-ID: <20050120113849.GE30500@intevation.de> On Thu, Jan 20, 2005 at 11:08:51AM +0100, Bernhard Herzog wrote: > cvs at intevation.de writes: > > > * Thuban/UiI/about.py: take iso-8859-15 when getdefaultlocale returns > > None. (Fixes rt#2910.) > > Are you sure we can rely on latin1 in the "C" locale? No, but about and other code contains latin1 characters, so I don't know of a better solution if None is returned. If you use "ascii" which is the default calling .encode() will use, then it also bombs becaue of the latin1 characters in the about dialog. -------------- 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/20050120/e2a2fe1d/attachment.bin From bh at intevation.de Thu Jan 20 12:42:34 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 20 Jan 2005 12:42:34 +0100 Subject: bernhard: thuban ChangeLog,1.757,1.758 In-Reply-To: <20050120113849.GE30500@intevation.de> (Bernhard Reiter's message of "Thu, 20 Jan 2005 12:38:49 +0100") References: <20050120100036.50DFD102BE5@lists.intevation.de> <20050120113849.GE30500@intevation.de> Message-ID: Bernhard Reiter writes: > If you use "ascii" which is the default calling .encode() will use, > then it also bombs becaue of the latin1 characters in the about dialog. We should use the the "replace" error handler for the encode method. Even if we know the target encoding, we have no guarantee at all that it supports all the characters we need. With "replace" we won't get an exception and the user will see a "?" for characters that couldn't be converted. not ideal, but there's not much we can do about it. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Thu Jan 20 12:45:17 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 12:45:17 +0100 (CET) Subject: bernhard: thuban/Thuban/UI classgen.py,1.35,1.36 Message-ID: <20050120114517.19A16102BDC@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv23751/Thuban/UI Modified Files: classgen.py Log Message: * Thuban/UI/classgen.py (OnRetrieve()): Added a comment that OnRangeText might be called twice and using None as argument. Index: classgen.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/classgen.py,v retrieving revision 1.35 retrieving revision 1.36 diff -u -d -r1.35 -r1.36 --- classgen.py 20 Jan 2005 11:30:52 -0000 1.35 +++ classgen.py 20 Jan 2005 11:45:15 -0000 1.36 @@ -904,7 +904,11 @@ try: min, max = table.ValueRange(self.fieldName) self.text_range.SetValue("[" + str(min) + ";" + str(max) + "]") - self.OnRangeText(0) + # This is a workaround, which will result in OnRangeText + # being called twice on some platforms. + # Testing showed this is needed with current wx 2.4. versions + # on MacOSX to guarantee that it is called at all. + self.OnRangeText(None) finally: ThubanEndBusyCursor() From cvs at intevation.de Thu Jan 20 12:45:17 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 12:45:17 +0100 (CET) Subject: bernhard: thuban ChangeLog,1.759,1.760 Message-ID: <20050120114517.1D5EA102BE5@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv23751 Modified Files: ChangeLog Log Message: * Thuban/UI/classgen.py (OnRetrieve()): Added a comment that OnRangeText might be called twice and using None as argument. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.759 retrieving revision 1.760 diff -u -d -r1.759 -r1.760 --- ChangeLog 20 Jan 2005 11:30:52 -0000 1.759 +++ ChangeLog 20 Jan 2005 11:45:15 -0000 1.760 @@ -1,5 +1,10 @@ 2005-01-20 Bernhard Reiter + * Thuban/UI/classgen.py (OnRetrieve()): Added a comment + that OnRangeText might be called twice and using None as argument. + +2005-01-20 Bernhard Reiter + * Thuban/UI/classgen.py (OnRetrieve()): Add a OnRangeText(0) to work around a different in wx Behaviour noticed on MacOSX, thanks to Lorenzo Moretti and Daniel Calvelo for the fix. From bernhard at intevation.de Thu Jan 20 12:45:46 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 12:45:46 +0100 Subject: bernhard: thuban/Thuban/UI classgen.py,1.34,1.35 In-Reply-To: References: <20050120113054.84291102BE5@lists.intevation.de> Message-ID: <20050120114546.GF30500@intevation.de> On Thu, Jan 20, 2005 at 12:34:29PM +0100, Bernhard Herzog wrote: > cvs at intevation.de writes: > > > --- classgen.py 15 Dec 2004 16:42:56 -0000 1.34 > > +++ classgen.py 20 Jan 2005 11:30:52 -0000 1.35 > > @@ -904,6 +904,7 @@ > > try: > > min, max = table.ValueRange(self.fieldName) > > self.text_range.SetValue("[" + str(min) + ";" + str(max) + "]") > > + self.OnRangeText(0) > > Can you add a comment to the sources about this work-around as well? > The fix is a bit ugly since on the platform where we don't need the > explicit OnRangeText call, OnRangeText ends up being called twice. > > Also, why 0 as parameter? Strictly speaking it should be the event > object, since it's an event handler. We don't have the appropriate > event, so None seems more reasonable. Done, thanks for the hints. -------------- 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/20050120/0c6d448b/attachment.bin From bernhard at intevation.de Thu Jan 20 12:47:25 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 12:47:25 +0100 Subject: bernhard: thuban ChangeLog,1.757,1.758 In-Reply-To: References: <20050120100036.50DFD102BE5@lists.intevation.de> <20050120113849.GE30500@intevation.de> Message-ID: <20050120114725.GG30500@intevation.de> On Thu, Jan 20, 2005 at 12:42:34PM +0100, Bernhard Herzog wrote: > Bernhard Reiter writes: > > > If you use "ascii" which is the default calling .encode() will use, > > then it also bombs becaue of the latin1 characters in the about dialog. > > We should use the the "replace" error handler for the encode method. > Even if we know the target encoding, we have no guarantee at all that it > supports all the characters we need. With "replace" we won't get an > exception and the user will see a "?" for characters that couldn't be > converted. not ideal, but there's not much we can do about it. I thought that also and tried it, but I did get an exception. I might have done it in the wrong way, though. -------------- 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/20050120/040acdfe/attachment.bin From bh at intevation.de Thu Jan 20 12:55:27 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 20 Jan 2005 12:55:27 +0100 Subject: bernhard: thuban ChangeLog,1.757,1.758 In-Reply-To: <20050120114725.GG30500@intevation.de> (Bernhard Reiter's message of "Thu, 20 Jan 2005 12:47:25 +0100") References: <20050120100036.50DFD102BE5@lists.intevation.de> <20050120113849.GE30500@intevation.de> <20050120114725.GG30500@intevation.de> Message-ID: Bernhard Reiter writes: > On Thu, Jan 20, 2005 at 12:42:34PM +0100, Bernhard Herzog wrote: >> We should use the the "replace" error handler for the encode method. [...] > > I thought that also and tried it, but I did get an exception. > I might have done it in the wrong way, though. >>> u'M\xfcller'.encode("ascii", "replace") 'M?ller' Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Thu Jan 20 14:14:16 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 14:14:16 +0100 (CET) Subject: bernhard: thuban ChangeLog,1.760,1.761 Message-ID: <20050120131416.A3664102C05@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv25186 Modified Files: ChangeLog Log Message: * Thuban/UI/about.py (unicodeToLocale()): Improved: Use 'ascii' and then 'replace' for other characters when getdefaultlocale returns None. Thanks to Bernhard H. . Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.760 retrieving revision 1.761 diff -u -d -r1.760 -r1.761 --- ChangeLog 20 Jan 2005 11:45:15 -0000 1.760 +++ ChangeLog 20 Jan 2005 13:14:14 -0000 1.761 @@ -1,5 +1,11 @@ 2005-01-20 Bernhard Reiter + * Thuban/UI/about.py (unicodeToLocale()): Improved: + Use 'ascii' and then 'replace' for other characters + when getdefaultlocale returns None. Thanks to Bernhard H. . + +2005-01-20 Bernhard Reiter + * Thuban/UI/classgen.py (OnRetrieve()): Added a comment that OnRangeText might be called twice and using None as argument. From cvs at intevation.de Thu Jan 20 14:14:16 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 14:14:16 +0100 (CET) Subject: bernhard: thuban/Thuban/UI about.py,1.19,1.20 Message-ID: <20050120131416.A7EE3102C08@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv25186/Thuban/UI Modified Files: about.py Log Message: * Thuban/UI/about.py (unicodeToLocale()): Improved: Use 'ascii' and then 'replace' for other characters when getdefaultlocale returns None. Thanks to Bernhard H. . Index: about.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/about.py,v retrieving revision 1.19 retrieving revision 1.20 diff -u -d -r1.19 -r1.20 --- about.py 20 Jan 2005 10:00:34 -0000 1.19 +++ about.py 20 Jan 2005 13:14:14 -0000 1.20 @@ -171,5 +171,5 @@ # instead. locale=getdefaultlocale()[1] if locale is None: - locale = 'iso-8859-15' - return unicodeStr.encode(locale) + locale = 'ascii' + return unicodeStr.encode(locale,'replace') From nelson at crynwr.com Thu Jan 20 16:55:00 2005 From: nelson at crynwr.com (Russell Nelson) Date: Thu, 20 Jan 2005 10:55:00 -0500 Subject: 089map.zip broken? In-Reply-To: <20050120090436.GD5553@intevation.de> References: <16835.44022.460828.230550@desk.crynwr.com> <20050120090436.GD5553@intevation.de> Message-ID: <16879.54356.590108.619089@desk.crynwr.com> Bernhard Reiter writes: > On Fri, Dec 17, 2004 at 11:03:02PM -0500, Russell Nelson wrote: > > http://russnelson.com/089map.zip > > a pair of files describing a map of my county. > > Actually I cannot unzip 089map.zip. Weird. It tested fine on my desktop, but was bad on my server. I've re-copied it over and it tests fine on my server now. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bernhard at intevation.de Thu Jan 20 17:07:56 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 17:07:56 +0100 Subject: [solved] Re: 089map.zip broken? In-Reply-To: <16879.54356.590108.619089@desk.crynwr.com> References: <16835.44022.460828.230550@desk.crynwr.com> <20050120090436.GD5553@intevation.de> <16879.54356.590108.619089@desk.crynwr.com> Message-ID: <20050120160756.GK1518@intevation.de> On Thu, Jan 20, 2005 at 10:55:00AM -0500, Russell Nelson wrote: > Bernhard Reiter writes: > > On Fri, Dec 17, 2004 at 11:03:02PM -0500, Russell Nelson wrote: > > > http://russnelson.com/089map.zip > > > a pair of files describing a map of my county. > > > > Actually I cannot unzip 089map.zip. > > Weird. It tested fine on my desktop, but was bad on my server. I've > re-copied it over and it tests fine on my server now. Yes, it's fine now. Maybe a binary/text copying problem? -------------- 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/20050120/2bd6bd78/attachment.bin From jonathan at jpcoles.com Thu Jan 20 17:24:16 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Thu, 20 Jan 2005 11:24:16 -0500 Subject: new raster code In-Reply-To: <20050120150051.GG1518@intevation.de> References: <1106232805.3336.59.camel@localhost.localdomain> <20050120150051.GG1518@intevation.de> Message-ID: <1106238256.3336.64.camel@localhost.localdomain> Am Donnerstag, den 20.01.2005, 16:00 +0100 schrieb Bernhard Reiter: > Hi Jonathan, > > as always the problem is that some people here are so busy > that we do not get around doing enough here. :) i understand. > Can you do me a favour and: > * split up patches, if possible > (I understood that removing cpl_mfile.* and bmpdataset.cpp > is indenpendent? No?) done (see attached patch files). you are correct, removing files is a seperate issue. > * diff -u or diff -c them instead > * write a Changelog Entry done. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: test_baserenderer.py.patch Type: text/x-patch Size: 5967 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050120/2f34aa5a/test_baserenderer.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: gdalwarp.cpp.patch Type: text/x-patch Size: 12318 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050120/2f34aa5a/gdalwarp.cpp.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: renderer.py.patch Type: text/x-patch Size: 2297 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050120/2f34aa5a/renderer.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: baserenderer.py.patch Type: text/x-patch Size: 6538 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050120/2f34aa5a/baserenderer.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: ChangeLog.patch Type: text/x-patch Size: 2511 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050120/2f34aa5a/ChangeLog.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.py.patch Type: text/x-patch Size: 950 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050120/2f34aa5a/setup.py.patch From nelson at crynwr.com Thu Jan 20 18:43:58 2005 From: nelson at crynwr.com (Russell Nelson) Date: Thu, 20 Jan 2005 12:43:58 -0500 Subject: "fixing" Projections dialog Message-ID: <16879.60894.666929.765026@desk.crynwr.com> The CVS version of Thuban is, IMHO, currently unusable for the naive user (which was me not too long ago). One of three changes has to happen to fix this: o The Lambert-93 projection must have the accented characters removed. o The Lambert-93 projection must be commented out until accented characters work. o The unicode support must work for projection names. I can only suggest patches for the first two, as I know little about unicode support. OBVIOUSLY the third thing is the right thing to do, but we shouldn't wait for it to happen to make CVS Thuban usable. Which of these patches should I apply? diff -u -r1.9 defaults.proj --- Resources/Projections/defaults.proj 9 Dec 2003 16:17:01 -0000 1.9 +++ Resources/Projections/defaults.proj 20 Jan 2005 17:38:31 -0000 @@ -48,6 +48,7 @@ + OR diff -u -r1.9 defaults.proj --- Resources/Projections/defaults.proj 9 Dec 2003 16:17:01 -0000 1.9 +++ Resources/Projections/defaults.proj 20 Jan 2005 17:38:31 -0000 @@ -48,6 +48,6 @@ - + -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From cvs at intevation.de Thu Jan 20 18:55:25 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 18:55:25 +0100 (CET) Subject: russell: thuban ChangeLog,1.761,1.762 Message-ID: <20050120175525.D4476102BEE@lists.intevation.de> Author: russell Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv32440 Modified Files: ChangeLog Log Message: Warn user about misprojected layers when their lat/lon bounding box exceeds rational lat/lon values. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.761 retrieving revision 1.762 diff -u -d -r1.761 -r1.762 --- ChangeLog 20 Jan 2005 13:14:14 -0000 1.761 +++ ChangeLog 20 Jan 2005 17:55:23 -0000 1.762 @@ -1,3 +1,8 @@ +2005-01-20 Russell Nelson + + * Warn user about misprojected layers when their lat/lon bounding + box exceeds rational lat/lon values. + 2005-01-20 Bernhard Reiter * Thuban/UI/about.py (unicodeToLocale()): Improved: From cvs at intevation.de Thu Jan 20 18:55:25 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 18:55:25 +0100 (CET) Subject: russell: thuban/Thuban/UI mainwindow.py,1.137,1.138 Message-ID: <20050120175525.DAA02102C08@lists.intevation.de> Author: russell Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv32440/Thuban/UI Modified Files: mainwindow.py Log Message: Warn user about misprojected layers when their lat/lon bounding box exceeds rational lat/lon values. Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.137 retrieving revision 1.138 diff -u -d -r1.137 -r1.138 --- mainwindow.py 11 Jan 2005 16:52:40 -0000 1.137 +++ mainwindow.py 20 Jan 2005 17:55:23 -0000 1.138 @@ -340,6 +340,19 @@ text = "(%10.10g, %10.10g)" % pos else: text = "" + map = self.canvas.Map() + for layer in map.layers: + bbox = layer.LatLongBoundingBox() + if bbox: + left, bottom, right, top = bbox + if not (-180 <= left <= 180 and + -180 <= right <= 180 and + -90 <= top <= 90 and + -90 <= bottom <= 90): + text = ("Select '"+layer.title+"' and pick a " + + "projection using Layer/Projection...") + break + self.set_position_text(text) def set_position_text(self, text): From bernhard at intevation.de Thu Jan 20 19:23:47 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 19:23:47 +0100 Subject: "fixing" Projections dialog In-Reply-To: <16879.60894.666929.765026@desk.crynwr.com> References: <16879.60894.666929.765026@desk.crynwr.com> Message-ID: <20050120182347.GI7470@intevation.de> On Thu, Jan 20, 2005 at 12:43:58PM -0500, Russell Nelson wrote: > The CVS version of Thuban is, IMHO, currently unusable for the naive > user (which was me not too long ago). One of three changes has to > happen to fix this: > > o The Lambert-93 projection must have the accented characters removed. Go for that one. > Which of these patches should I apply? The second one removing the accented characters. Thanks! Bernhard R. > > diff -u -r1.9 defaults.proj > --- Resources/Projections/defaults.proj 9 Dec 2003 16:17:01 -0000 1.9 > +++ Resources/Projections/defaults.proj 20 Jan 2005 17:38:31 -0000 > @@ -48,6 +48,7 @@ > > > > + > > > > OR > > > diff -u -r1.9 defaults.proj > --- Resources/Projections/defaults.proj 9 Dec 2003 16:17:01 -0000 1.9 > +++ Resources/Projections/defaults.proj 20 Jan 2005 17:38:31 -0000 > @@ -48,6 +48,6 @@ > > > > - > + > > > > -- > --My blog is at angry-economist.russnelson.com | Freedom means allowing > Crynwr sells support for free software | PGPok | people to do things the > 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are > Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. > > _______________________________________________ > 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/20050120/18c8f662/attachment.bin From cvs at intevation.de Thu Jan 20 19:33:01 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 19:33:01 +0100 (CET) Subject: bernhard: thuban ChangeLog,1.762,1.763 Message-ID: <20050120183301.9E6EF102C05@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv576 Modified Files: ChangeLog Log Message: Small Changelog entry improvement. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.762 retrieving revision 1.763 diff -u -d -r1.762 -r1.763 --- ChangeLog 20 Jan 2005 17:55:23 -0000 1.762 +++ ChangeLog 20 Jan 2005 18:32:59 -0000 1.763 @@ -1,6 +1,7 @@ 2005-01-20 Russell Nelson - * Warn user about misprojected layers when their lat/lon bounding + * Thuban/UI/mainwindow.py(view_position_changed): Warn user about + misprojected layers when their lat/lon bounding box exceeds rational lat/lon values. 2005-01-20 Bernhard Reiter From bh at intevation.de Thu Jan 20 19:33:25 2005 From: bh at intevation.de (Bernhard Herzog) Date: Thu, 20 Jan 2005 19:33:25 +0100 Subject: russell: thuban/Thuban/UI mainwindow.py,1.137,1.138 In-Reply-To: <20050120175525.DAA02102C08@lists.intevation.de> (cvs@intevation.de's message of "Thu, 20 Jan 2005 18:55:25 +0100 (CET)") References: <20050120175525.DAA02102C08@lists.intevation.de> Message-ID: cvs at intevation.de writes: > --- mainwindow.py 11 Jan 2005 16:52:40 -0000 1.137 > +++ mainwindow.py 20 Jan 2005 17:55:23 -0000 1.138 > @@ -340,6 +340,19 @@ > text = "(%10.10g, %10.10g)" % pos > else: > text = "" > + map = self.canvas.Map() > + for layer in map.layers: > + bbox = layer.LatLongBoundingBox() > + if bbox: > + left, bottom, right, top = bbox > + if not (-180 <= left <= 180 and > + -180 <= right <= 180 and > + -90 <= top <= 90 and > + -90 <= bottom <= 90): > + text = ("Select '"+layer.title+"' and pick a " + > + "projection using Layer/Projection...") > + break > + Why is this it in view_position_changed? That method is called for *every* mouse move! AFAICT, this branch is only executed when the mouse leaves the canvas window, so it's not that often, but the view_position_changed does is not the right place to put this code. I don't have a better solution at hand, but the view_position_changed is only there to update the current position. If other information is to be shown in the status bar it should be handled in a different way and by other methods. The status bar widget supports some kind of stack of texts. maybe that can be used to distinguis between short-lived information such as the mouse position and more permanent information such as the hint about the projections. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bernhard at intevation.de Thu Jan 20 19:39:36 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 19:39:36 +0100 Subject: russell: thuban/Thuban/UI mainwindow.py,1.137,1.138 In-Reply-To: References: <20050120175525.DAA02102C08@lists.intevation.de> Message-ID: <20050120183936.GJ7470@intevation.de> On Thu, Jan 20, 2005 at 07:33:25PM +0100, Bernhard Herzog wrote: > but the > view_position_changed does is not the right place to put this code. I > don't have a better solution at hand, but the view_position_changed is > only there to update the current position. Agreed in principle, but... we do not have a better solution at hand. I can reassure you, the situation the user is in is bad, thus I accept a hack in the code before one user gests burned by this. We should add a comment in the code that it is a hack, though. > If other information is to > be shown in the status bar it should be handled in a different way and > by other methods. -------------- 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/20050120/ca88f4c9/attachment.bin From cvs at intevation.de Thu Jan 20 19:47:29 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 19:47:29 +0100 (CET) Subject: bernhard: thuban/Thuban/UI mainwindow.py,1.138,1.139 Message-ID: <20050120184729.0E378102C05@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv795/Thuban/UI Modified Files: mainwindow.py Log Message: * Thuban/UI/mainwindow.py(view_position_changed): Added docstring and comment that the warning code here is a hack. Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.138 retrieving revision 1.139 diff -u -d -r1.138 -r1.139 --- mainwindow.py 20 Jan 2005 17:55:23 -0000 1.138 +++ mainwindow.py 20 Jan 2005 18:47:26 -0000 1.139 @@ -335,11 +335,30 @@ return self.dialogs.get(name) def view_position_changed(self): + """Put current position in status bar after a mouse move.""" pos = self.canvas.CurrentPosition() if pos is not None: text = "(%10.10g, %10.10g)" % pos else: text = "" + # XXX This is a hack until we find a better place for this code. + # (BER 20050120) + # BH wrote (20050120): + # this branch is only executed when the mouse + # leaves the canvas window, so it's not that often [..] + # [Here] not the right place to put this code. + # I don't have a better solution at hand, + # but the view_position_changed is only there to update + # the current position. If other information is to + # be shown in the status bar it should + # be handled in a different way and + # by other methods. + # + # The status bar widget supports some kind of stack of texts. + # maybe that can be used to distinguis + # between short-lived information such as the mouse position + # and more permanent information such as the hint + # about the projections. map = self.canvas.Map() for layer in map.layers: bbox = layer.LatLongBoundingBox() From cvs at intevation.de Thu Jan 20 19:47:29 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 19:47:29 +0100 (CET) Subject: bernhard: thuban ChangeLog,1.763,1.764 Message-ID: <20050120184729.12C4C102C08@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv795 Modified Files: ChangeLog Log Message: * Thuban/UI/mainwindow.py(view_position_changed): Added docstring and comment that the warning code here is a hack. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.763 retrieving revision 1.764 diff -u -d -r1.763 -r1.764 --- ChangeLog 20 Jan 2005 18:32:59 -0000 1.763 +++ ChangeLog 20 Jan 2005 18:47:26 -0000 1.764 @@ -1,3 +1,8 @@ +2005-01-20 Bernhard Reiter + + * Thuban/UI/mainwindow.py(view_position_changed): Added docstring + and comment that the warning code here is a hack. + 2005-01-20 Russell Nelson * Thuban/UI/mainwindow.py(view_position_changed): Warn user about From nelson at crynwr.com Thu Jan 20 20:22:42 2005 From: nelson at crynwr.com (Russell Nelson) Date: Thu, 20 Jan 2005 14:22:42 -0500 Subject: russell: thuban/Thuban/UI mainwindow.py,1.137,1.138 In-Reply-To: References: <20050120175525.DAA02102C08@lists.intevation.de> Message-ID: <16880.1282.289841.754506@desk.crynwr.com> Bernhard Herzog writes: > Why is this it in view_position_changed? That method is called for > *every* mouse move! AFAICT, this branch is only executed when the mouse > leaves the canvas window, so it's not that often, but the > view_position_changed does is not the right place to put this code. I agree. I wanted 1) to have this change in the code, and 2) to have it all in one place. It may very well be that after seeing how it works, somebody figures out what we REALLY want to be telling the user, and where and how and when. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bernhard at intevation.de Thu Jan 20 20:51:12 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 20:51:12 +0100 Subject: new raster code In-Reply-To: <1106238256.3336.64.camel@localhost.localdomain> References: <1106232805.3336.59.camel@localhost.localdomain> <20050120150051.GG1518@intevation.de> <1106238256.3336.64.camel@localhost.localdomain> Message-ID: <20050120195112.GA19836@intevation.de> On Thu, Jan 20, 2005 at 11:24:16AM -0500, Jonathan Coles wrote: > Am Donnerstag, den 20.01.2005, 16:00 +0100 schrieb Bernhard Reiter: > > Can you do me a favour and: > > * split up patches, if possible > > (I understood that removing cpl_mfile.* and bmpdataset.cpp > > is indenpendent? No?) > > done (see attached patch files). you are correct, removing files is a > seperate issue. > > > * diff -u or diff -c them instead > > * write a Changelog Entry > > done. Thanks. I am peeking at it now. First question: Why is the CPLError function commented out here? if ( err ) { - CPLError( CE_Failure, err, "" ); + //CPLError( CE_Failure, err, "%s\n", CPLGetLastErrorMsg() ); return NULL; } -------------- 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/20050120/24c27d57/attachment.bin From nelson at crynwr.com Thu Jan 20 20:52:16 2005 From: nelson at crynwr.com (Russell Nelson) Date: Thu, 20 Jan 2005 14:52:16 -0500 Subject: Zooming and projection problems (was: Success (sort-of)!) In-Reply-To: <20050120092755.GE5553@intevation.de> References: <16837.50975.528784.554287@desk.crynwr.com> <20050120092755.GE5553@intevation.de> Message-ID: <16880.3056.139242.314825@desk.crynwr.com> Bernhard Reiter writes: > > 2) set the projection of the session using Map/Projection... > > 3) load the raster map, and set its projection using Layer/Projection... > > If you miss 2) then even 3) will not help much > and Thuban behaves oddly when zooming around even with 1). This question will mark me as a GIS newbie, but no matter: Is it true that a Map must ALWAYS have a projection? Or is it true that a Map doesn't need a projection if all of the data you load into it has the same projection? I think that in any case, the scalebar should say "Unprojected map. Use Map/Projection to set the projection" if the map's projection is None. It's better than leaving the space empty. Alternately, an unprojected map should have as its base layer "This map has no projection. If you add layers with different projections, Thuban will be unable to reconcile them into one map that makes sense." Hey, maybe that's the best way to do it? When a user creates a New Session (or starts Thuban with no session; same thing), give them a "Map Information" layer. They can delete it, or they can hide it. But as long as it's there, it will emit helpful information like "Yo, stoopid! Dis layer ain't projected!" or "Ya dimbulb, ya just loaded two layers that don't overlap! Maybe deir misprajected?" Or, at least, those would be the error messages in the Noo Yawker translation. > Probably more tests and thinking are needed > but from a user perspective this is not inuitive. Yeah, it's not. At least part of the problem is user naivete, but the software should let them know 1) the effects of what they've done, and 2) how to fix it. Specifically, we need to do something to prevent scale blow-up. This causes ZeroDivision errors that should be entirely preventable. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From nelson at crynwr.com Thu Jan 20 20:54:54 2005 From: nelson at crynwr.com (Russell Nelson) Date: Thu, 20 Jan 2005 14:54:54 -0500 Subject: undo? Message-ID: <16880.3214.456618.679937@desk.crynwr.com> One more wacky idea: Maybe, instead of saving the session as an XML file, it should be saved as a sequence of commands? Thuban would have a command interpreter which would implement changes made to the layers and the map. There would be a command for menu items and any extra data submitted with them, e.g. filenames or projection selections. So when you load something, that's a command, or when you set the projection, that's a command. As you do things, the commands are saved. And .... there's an undo/redo facility which issues the reverse of the commands. So if you botched something accidentally, you could undo that action. Anyway, I'm not proposing a patch for this, just pointing out that it's one way to implement an "undo" facility. Users like undo because it lets them experiment safely. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bernhard at intevation.de Thu Jan 20 21:04:19 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 21:04:19 +0100 Subject: undo! In-Reply-To: <16880.3214.456618.679937@desk.crynwr.com> References: <16880.3214.456618.679937@desk.crynwr.com> Message-ID: <20050120200419.GB19836@intevation.de> Undo certainly is an item on the wish list. You are completely right in that users (which includes us) like it. So we only need to resolve the disagreement about you not providing a patch for undo capabilities. >;-) On Thu, Jan 20, 2005 at 02:54:54PM -0500, Russell Nelson wrote: > One more wacky idea: Maybe, instead of saving the session as an XML > file, it should be saved as a sequence of commands? Thuban would have > a command interpreter which would implement changes made to the layers > and the map. There would be a command for menu items and any extra > data submitted with them, e.g. filenames or projection selections. So > when you load something, that's a command, or when you set the > projection, that's a command. As you do things, the commands are > saved. And .... there's an undo/redo facility which issues the > reverse of the commands. So if you botched something accidentally, > you could undo that action. Anyway, I'm not proposing a patch for > this, just pointing out that it's one way to implement an "undo" > facility. Users like undo because it lets them experiment safely. -------------- 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/20050120/3c48c5f4/attachment.bin From bernhard at intevation.de Thu Jan 20 21:05:01 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 21:05:01 +0100 Subject: new raster code In-Reply-To: <1106238256.3336.64.camel@localhost.localdomain> References: <1106232805.3336.59.camel@localhost.localdomain> <20050120150051.GG1518@intevation.de> <1106238256.3336.64.camel@localhost.localdomain> Message-ID: <20050120200501.GC19836@intevation.de> Got a warning while compiling: building 'Lib.gdalwarp' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include -Ilibraries/thuban/ -I/usr/include/python2.3 -c libraries/thuban/gdalwarp.cpp -o build/temp.linux-ppc-2.3/libraries/thuban/gdalwarp.o libraries/thuban/gdalwarp.cpp: In Funktion ?CPLErr GetImageData(GDALDataset*, unsigned char**, unsigned int*)?: libraries/thuban/gdalwarp.cpp:209: Warnung: unused variable `int nWordSize' -------------- 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/20050120/f1f79d3f/attachment.bin From nelson at crynwr.com Thu Jan 20 21:16:35 2005 From: nelson at crynwr.com (Russell Nelson) Date: Thu, 20 Jan 2005 15:16:35 -0500 Subject: undo! In-Reply-To: <20050120200419.GB19836@intevation.de> References: <16880.3214.456618.679937@desk.crynwr.com> <20050120200419.GB19836@intevation.de> Message-ID: <16880.4515.897811.99275@desk.crynwr.com> Bernhard Reiter writes: > Undo certainly is an item on the wish list. > You are completely right in that users (which includes us) like it. > > So we only need to resolve the disagreement about you not providing > a patch for undo capabilities. >;-) It's probably not impossibly difficult, but I don't know enough about Thuban innards to be able to do it now, or at any foreseeable date in the future. Just to venture a guess, you could do it using a set of wrapper classes around Thuban/Model/*.py, which would inherit the original class, and a new UndoRedo class. The wrapper class would record what had been done, and would know how to undo it. Then you'd need an extra set of methods to 1) explain what had been done, and 2) redo them. Just looking at the history file would be useful anyway, because you could see how a session had been created. Not just its current state, but what steps had been taken to get there. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From bernhard at intevation.de Thu Jan 20 21:25:01 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 21:25:01 +0100 Subject: undo! In-Reply-To: <16880.4515.897811.99275@desk.crynwr.com> References: <16880.3214.456618.679937@desk.crynwr.com> <20050120200419.GB19836@intevation.de> <16880.4515.897811.99275@desk.crynwr.com> Message-ID: <20050120202501.GD19836@intevation.de> On Thu, Jan 20, 2005 at 03:16:35PM -0500, Russell Nelson wrote: > Bernhard Reiter writes: > > Undo certainly is an item on the wish list. > > You are completely right in that users (which includes us) like it. > > > > So we only need to resolve the disagreement about you not providing > > a patch for undo capabilities. >;-) > > It's probably not impossibly difficult, but I don't know enough about > Thuban innards to be able to do it now, or at any foreseeable date in > the future. Just to venture a guess, you could do it using a set of > wrapper classes around Thuban/Model/*.py, which would inherit the > original class, and a new UndoRedo class. The wrapper class would > record what had been done, and would know how to undo it. Then you'd > need an extra set of methods to 1) explain what had been done, and 2) > redo them. Just looking at the history file would be useful anyway, > because you could see how a session had been created. Not just its > current state, but what steps had been taken to get there. I think Bernhard H. would probably like to work on undo capabilities, too. He has quite some experience designing undo within in Skencil. -------------- 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/20050120/3265170f/attachment.bin From cvs at intevation.de Thu Jan 20 21:29:22 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 21:29:22 +0100 (CET) Subject: russell: thuban/Resources/Projections defaults.proj,1.9,1.10 Message-ID: <20050120202922.47936102C05@lists.intevation.de> Author: russell Update of /thubanrepository/thuban/Resources/Projections In directory doto:/tmp/cvs-serv1908/Resources/Projections Modified Files: defaults.proj Log Message: Resources/Projections/defaults.proj: Ruin the speling of the Lambert-93 projection so it doesn't run into the unicode bug. It's the wrong thing to do in the long run, but it's necessary until that bug is fixed. Otherwise the projection dialog segfaults. Index: defaults.proj =================================================================== RCS file: /thubanrepository/thuban/Resources/Projections/defaults.proj,v retrieving revision 1.9 retrieving revision 1.10 diff -u -d -r1.9 -r1.10 --- defaults.proj 9 Dec 2003 16:17:01 -0000 1.9 +++ defaults.proj 20 Jan 2005 20:29:20 -0000 1.10 @@ -48,7 +48,7 @@ - + From cvs at intevation.de Thu Jan 20 21:29:22 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 21:29:22 +0100 (CET) Subject: russell: thuban ChangeLog,1.764,1.765 Message-ID: <20050120202922.4B857102C08@lists.intevation.de> Author: russell Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv1908 Modified Files: ChangeLog Log Message: Resources/Projections/defaults.proj: Ruin the speling of the Lambert-93 projection so it doesn't run into the unicode bug. It's the wrong thing to do in the long run, but it's necessary until that bug is fixed. Otherwise the projection dialog segfaults. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.764 retrieving revision 1.765 diff -u -d -r1.764 -r1.765 --- ChangeLog 20 Jan 2005 18:47:26 -0000 1.764 +++ ChangeLog 20 Jan 2005 20:29:20 -0000 1.765 @@ -1,3 +1,11 @@ +2005-01-20 Russell Nelson + + * Resources/Projections/defaults.proj: Ruin the speling of the + Lambert-93 projection so it doesn't run into the unicode bug. + It's the wrong thing to do in the long run, but it's necessary + until that bug is fixed. Otherwise the projection dialog + segfaults. + 2005-01-20 Bernhard Reiter * Thuban/UI/mainwindow.py(view_position_changed): Added docstring From bernhard at intevation.de Thu Jan 20 21:30:03 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 21:30:03 +0100 Subject: new raster code In-Reply-To: <1106238256.3336.64.camel@localhost.localdomain> References: <1106232805.3336.59.camel@localhost.localdomain> <20050120150051.GG1518@intevation.de> <1106238256.3336.64.camel@localhost.localdomain> Message-ID: <20050120203003.GE19836@intevation.de> The new raster code, applies nicely to CVS, displays and image faster and all test run through positively. However I could make it dump tracebacks in a strange way. Using Russels test data: http://russnelson.com/089uni00s.zip http://russnelson.com/089map.zip http://russnelson.com/test.zip I had a session saved (attached session). If I am opening this everything is fine. Then I add the image from 089map.zip as image layer (not giving it a project yet). Pressing resize to map on the vector layers gives me the first traceback (in attached file). Then after giving it a projects I get other errors on stdout (see second example in the attached file). So I was close saying: It is your code, just submit and squash the bugs... But now it seems like I did find the first bug right away. ;) Bernhard R. -------------- next part -------------- -------------- next part -------------- An unhandled exception occurred: float division (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/mainwindow.py", line 284, in invoke_command command.Execute(self.Context()) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/command.py", line 121, in Execute apply(self.function, (context,) + self.args + args, kw) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/mainwindow.py", line 1036, in call_method apply(getattr(context.mainwindow, methodname), args) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/mainwindow.py", line 941, in FullExtent self.canvas.FitMapToWindow() File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/viewport.py", line 475, in FitMapToWindow self.FitRectToWindow(bbox) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/viewport.py", line 464, in FitRectToWindow self.set_view_transform(scale, (offx, offy)) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/view.py", line 353, in set_view_transform ViewPort.set_view_transform(self, scale, offset) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/viewport.py", line 403, in set_view_transform pcenterx = (wwidth/2 - offset[0]) / scale ZeroDivisionError: float division Traceback (most recent call last): File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/view.py", line 209, in _do_redraw if self.render_iter.next(): File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/view.py", line 258, in _render_iterator for cont in renderer.RenderMapIncrementally(): File "/mobilehome/bernhard/hacking/thuban/root/thuban/test/../Thuban/UI/baserenderer.py", line 197, in render_map_incrementally self.draw_raster_layer(layer) File "/mobilehome/bernhard/hacking/thuban/root/thuban/test/../Thuban/UI/baserenderer.py", line 471, in draw_raster_layer xmin = fmin[0]/self.scale ZeroDivisionError: float division Warning: .VIEW_POSITION: >() Traceback (most recent call last): File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/Lib/connector.py", line 92, in Issue apply(func, args + fargs) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/mainwindow.py", line 339, in view_position_changed pos = self.canvas.CurrentPosition() File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/viewport.py", line 594, in CurrentPosition return self.win_to_proj(x, y) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/viewport.py", line 435, in win_to_proj return ((x - offx) / self.scale, (offy - y) / self.scale) ZeroDivisionError: float division Warning: .VIEW_POSITION: >() Traceback (most recent call last): File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/Lib/connector.py", line 92, in Issue apply(func, args + fargs) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/mainwindow.py", line 339, in view_position_changed pos = self.canvas.CurrentPosition() File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/viewport.py", line 594, in CurrentPosition return self.win_to_proj(x, y) File "/mobilehome/bernhard/hacking/thuban/root/thuban/Thuban/UI/viewport.py", line 435, in win_to_proj return ((x - offx) / self.scale, (offy - y) / self.scale) ZeroDivisionError: float division -------------- 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/20050120/7a63b6ee/attachment.bin From bernhard at intevation.de Thu Jan 20 21:33:26 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 21:33:26 +0100 Subject: russell: thuban/Resources/Projections defaults.proj,1.9,1.10 In-Reply-To: <20050120202922.47936102C05@lists.intevation.de> References: <20050120202922.47936102C05@lists.intevation.de> Message-ID: <20050120203326.GG19836@intevation.de> On Thu, Jan 20, 2005 at 09:29:22PM +0100, cvs at intevation.de wrote: > Author: russell > > Update of /thubanrepository/thuban/Resources/Projections > In directory doto:/tmp/cvs-serv1908/Resources/Projections > > Modified Files: > defaults.proj > Log Message: > Resources/Projections/defaults.proj: Ruin the speling of the > Lambert-93 projection so it doesn't run into the unicode bug. > It's the wrong thing to do in the long run, but it's necessary > until that bug is fixed. Otherwise the projection dialog > segfaults. I think it only seqfaults on utf-8 locale machines due to the underlying wx bug. -------------- 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/20050120/a9cf335f/attachment.bin From cvs at intevation.de Thu Jan 20 21:42:00 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Thu, 20 Jan 2005 21:42:00 +0100 (CET) Subject: russell: thuban ChangeLog,1.765,1.766 Message-ID: <20050120204200.A3E84102C05@lists.intevation.de> Author: russell Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv2069 Modified Files: ChangeLog Log Message: Improve the ChangeLog entry. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.765 retrieving revision 1.766 diff -u -d -r1.765 -r1.766 --- ChangeLog 20 Jan 2005 20:29:20 -0000 1.765 +++ ChangeLog 20 Jan 2005 20:41:58 -0000 1.766 @@ -1,10 +1,11 @@ 2005-01-20 Russell Nelson * Resources/Projections/defaults.proj: Ruin the speling of the - Lambert-93 projection so it doesn't run into the unicode bug. - It's the wrong thing to do in the long run, but it's necessary - until that bug is fixed. Otherwise the projection dialog - segfaults. + Lambert-93 projection so it doesn't run into the wx UTF-8 bug. + It's the wrong thing to do in the long run, but it's necessary for + those users until that bug is fixed. Otherwise the projection + dialog segfaults. Better to annoy some Lambert-93 users with a + spelling mistake than every Fedora Core 3 user of Thuban-CVS. 2005-01-20 Bernhard Reiter From bernhard at intevation.de Thu Jan 20 21:48:36 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Jan 2005 21:48:36 +0100 Subject: [Thuban-list] tests for Daniel Cavelo's classifiers In-Reply-To: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> References: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> Message-ID: <20050120204836.GA20846@intevation.de> Hi Moritz, On Tue, Jan 18, 2005 at 10:19:24AM +0100, Moritz Lennert wrote: > [First one didn't come through since I forgot to gzip the patch.] It did later, only the moderator had to approve it. > Finally have come back to this: First thanks for getting the ball rolling again on that huge patch. > On Wed, October 20, 2004 6:53, Jan-Oliver Wagner said: > > On Wed, Oct 20, 2004 at 12:14:43AM +0200, Moritz Lennert wrote: > >> Daniel told me that the lack of test keeps his patches for the classifier > from being integrated into the CVS. Could someone explain to me what > exactly is needed in terms of tests and how I could contribute ? We hope to have unit tests that shall test a lot of the code path automaticall when being run in cd tests python runtests So we hope that contributors write a few of those tests because you can only do this with detailed knowledge of the code. Ones you get into writing tests, it really is fun, because you can write them before implementing something and then see them succeed. > > So first step would be to apply the patch for HEAD. > > Attached is a version of the patches that applies cleanly to current (20050118 > at ca. 1am) CVS HEAD, plus the necessary additional files that can just be > dropped in. This version of the patch also includes two bug fixes, one to the > discont algorithm and one general one, dealing with no data situations. I take it the fixes are for the new code itself, otherwise you could extract them into smaller patches. BTW: the -N switch to diff should even give you diffs of the new files, which might be easier to packages. > > Next, one should think about what are the most important tests > > and add them to the directory test/ > > There you can see how the other tests are made - not too difficult in > > practice but some brain work to have them useful. > > test_color.py is a simple one to get the idea. > > I haven't had time to look into this in great detail (and won't have in the > near future), so if someone else has the opportunity to do so, that would be > great. (I guess I'll also have to read > http://diveintopython.org/unit_testing/index.html in order to completely > understand the testing business.) No, it is quite easy: Just copy an appropriate test and start adding one function for each method that is new in the patch. > I would really appreciate if this patch could be integrated into cvs as that > would make it possible to install with debian apt-get and have everything > integrated... What we also would like to have would be a Changelog entry. It makes it easer to understand what is going on from an overview point of view. I also noticed that the new files do not have a header. Daniel: Would it be okay for you to assign the copyrights to us? Our idea is to keep them all in one place. Happy hacking, Bernhard R. -------------- 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/20050120/c92fdd1b/attachment.bin From thuban-bugs at intevation.de Thu Jan 20 22:37:29 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Thu, 20 Jan 2005 22:37:29 +0100 (CET) Subject: [bug #2913] (thuban) Thuban 1.0.1 crash on startup Message-ID: <20050120213729.9DB39102C08@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2913 ------------------------------------------------------------------------- Subject: Thuban 1.0.1 crash on startup Operating System: GNU/Linux, Mandrake 10.0 Thuban version: 1.0.1 wxPython version: 2.4.2.4 Python version: other, 2.3.3-2 PySQLite version: 0.5.0 SQLite version: 2.8.6 GDAL version: CVS, post-1.2.5 proj version: CVS, post-4.4.8 Please enter error description here. Thuban crash on startup. Did you compile Thuban yourself? Yes, downloaded tar.gz and extracted spec file from 1.0.0, then rpm to build RPM. thuban [neteler at localhost disstext]$ thuban Eine unbehandelte Ausnahme ist aufgetreten: 'ascii' codec can't encode character u'\xfc' in position 27: ordinal not in range (please report to http://thuban.intevation.org/bugtracker.html) Traceback (most recent call last): File "/usr//bin/thuban", line 23, in ? Thuban.UI.main.main() File "/usr/lib/thuban/Thuban/UI/main.py", line 31, in main app = ThubanApplication(0) File "/usr/lib/python2.3/site-packages/wxPython/wx.py", line 1951, in __init__ _wxStart(self.OnInit) File "/usr/lib/thuban/Thuban/UI/application.py", line 72, in OnInit self.read_startup_files() File "/usr/lib/thuban/Thuban/UI/application.py", line 111, in read_startup_file sys.stderr.write(_("No thubanstart module available\n")) UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 27: e(128) -------------------------------------------- Here the trick: [neteler at localhost neteler]$ touch ~/.thuban/thubanstart.py [neteler at localhost neteler]$ thuban WORKS! I mean, it opens the GUI (see next bug report). Regards Markus Neteler PS: I would like to demonstrate Thuban next week in Munich... Recommendations are welcome. -------------------------------------------- Managed by Request Tracker From thuban-bugs at intevation.de Thu Jan 20 22:47:19 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Thu, 20 Jan 2005 22:47:19 +0100 (CET) Subject: [bug #2914] (thuban) Thuban 1.0.1 crash when loading SHAPE file Message-ID: <20050120214719.C41E4102C08@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2914 ------------------------------------------------------------------------- Subject: Thuban 1.0.1 crash when loading SHAPE file Operating System: GNU/Linux, Mandrake 10.0 Thuban version: 1.0.1 wxPython version: 2.4.2.4 Python version: other, 2.3.3-2 PySQLite version: 0.5.0 SQLite version: 2.8.6 GDAL version: other, post-1.2.5 proj version: 4.4.8, post-4.4.8 Please enter error description here. Did you compile Thuban yourself? Yes, through RPM spec file. System: [neteler at localhost neteler]$ rpm -qa |grep wxPyt wxPythonGTK-devel-2.4.0.6-1 wxPythonGTK-2.4.2.4-2mdk libwxPythonGTK2.4-2.4.2.4-2mdk [neteler at localhost neteler]$ rpm -qa |grep pyth libpython2.3-2.3.3-2mdk libpython2.3-devel-2.3.3-2mdk python-numeric-23.1-2mdk python-base-2.3.3-2mdk python-numeric-devel-22.0-4mdk libpython2.2-devel-2.2.2-6mdk rpm-python-4.2.2-7mdk python-imaging-1.1.4-3mdk libpython2.2-2.2.2-6mdk python-2.3.3-2mdk libuser-python-0.51.7-9.1.100mdk [neteler at localhost neteler]$ rpm -qa |grep pysq pysqlite-0.5.0-1 [neteler at localhost neteler]$ rpm -qa |grep libsq libsqlite0-devel-2.8.6-1mdk libsqlite0-2.8.6-1mdk When loading a SHAPE file (which runs fine in GRASS 6 or QGIS): Segmentation fault example: Loading freegis_worlddata-0.2_simple/geodata/countries_simpl.shp Segmentation fault example GeoTIFF: Traceback (most recent call last): File "/usr/lib/thuban/Thuban/UI/baserenderer.py", line 479, in draw_raster_layer (width, height)) IOError: Attempt to create BMP dataset with an illegal data type (Int16), only Byte supported by the format. Regards Markus Neteler -------------------------------------------- Managed by Request Tracker From jonathan at jpcoles.com Thu Jan 20 23:17:11 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Thu, 20 Jan 2005 17:17:11 -0500 Subject: new raster code In-Reply-To: <20050120203003.GE19836@intevation.de> References: <1106232805.3336.59.camel@localhost.localdomain> <20050120150051.GG1518@intevation.de> <1106238256.3336.64.camel@localhost.localdomain> <20050120203003.GE19836@intevation.de> Message-ID: <1106259431.3336.85.camel@localhost.localdomain> Am Donnerstag, den 20.01.2005, 21:30 +0100 schrieb Bernhard Reiter: > The new raster code, applies nicely to CVS, > displays and image faster and all test run through positively. > > However I could make it dump tracebacks in a strange way. > Using Russels test data: > http://russnelson.com/089uni00s.zip > http://russnelson.com/089map.zip > http://russnelson.com/test.zip > I had a session saved (attached session). > > If I am opening this everything is fine. > Then I add the image from 089map.zip as image layer > (not giving it a project yet). > Pressing resize to map on the vector layers gives > me the first traceback (in attached file). > > Then after giving it a projects I get other errors > on stdout (see second example in the attached file). > > So I was close saying: It is your code, just submit and squash the bugs... > But now it seems like I did find the first bug right away. ;) i was able to reproduce the problem on the current CVS code. this does *not* include my changes, so something else is wrong. i don't think my patches have broken anything that wasn't already broken :) --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From Chris.Barker at noaa.gov Fri Jan 21 01:39:59 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu, 20 Jan 2005 16:39:59 -0800 Subject: bernhard: thuban/Thuban/UI classgen.py,1.35,1.36 In-Reply-To: <20050120114517.19A16102BDC@lists.intevation.de> References: <20050120114517.19A16102BDC@lists.intevation.de> Message-ID: <41F04F5F.8030706@noaa.gov> cvs at intevation.de wrote: > + # Testing showed this is needed with current wx 2.4. versions > + # on MacOSX to guarantee that it is called at all. This brings up a question for me: What is the status of Thuban on OS-X? and What are the plans for updating to wxPython 2.5.* ? These two are intricately connected, because wxPython 2.4.* is really next to worthless on OS-X. thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From jonathan at jpcoles.com Fri Jan 21 02:03:24 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Thu, 20 Jan 2005 20:03:24 -0500 Subject: undo? In-Reply-To: <16880.3214.456618.679937@desk.crynwr.com> References: <16880.3214.456618.679937@desk.crynwr.com> Message-ID: <1106269404.5206.10.camel@localhost.localdomain> Am Donnerstag, den 20.01.2005, 14:54 -0500 schrieb Russell Nelson: > One more wacky idea: Maybe, instead of saving the session as an XML > file, it should be saved as a sequence of commands? Thuban would have > a command interpreter which would implement changes made to the layers > and the map. There would be a command for menu items and any extra > data submitted with them, e.g. filenames or projection selections. So > when you load something, that's a command, or when you set the > projection, that's a command. As you do things, the commands are > saved. And .... there's an undo/redo facility which issues the > reverse of the commands. So if you botched something accidentally, > you could undo that action. Anyway, I'm not proposing a patch for > this, just pointing out that it's one way to implement an "undo" > facility. Users like undo because it lets them experiment safely. i've had some good experiences with developing a system that uses a simple language to operate. i was involved in developing a visualization tool for astronomical data with the CS and astrophysics departments at RIT (GPL'd, of course ;). because of how we designed the system the different modules would talk to each other using a language. the system even allowed for the communication to go over the network so different parts of the system could be on different machines (e.g. one machine that could do fast graphics and rendering). anyway, the point of all that was to say that this is a good idea. not that i'm volunteering to help implement it at the moment :) however, i'm not sure that the whole session file should be a sequence of commands. if it was, the only way to get the final state of the session would be to run through all the commands from the beginning when the session is loaded. if the final state was saved using the current mechanism and *in addition* the commands were saved this could be really cool. the user could load a saved file and then still be able to undo things they had done in a previous session! also, it would further seperate the UI and Model components and allow much fuller tests. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From dcalvelo at minag.gob.pe Fri Jan 21 03:21:52 2005 From: dcalvelo at minag.gob.pe (Daniel Calvelo Aros) Date: Thu, 20 Jan 2005 21:21:52 -0500 Subject: [Thuban-list] tests for Daniel Cavelo's classifiers In-Reply-To: <20050120204836.GA20846@intevation.de> References: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> <20050120204836.GA20846@intevation.de> Message-ID: <20050121021357.M66533@minag.gob.pe> From: Bernhard Reiter > > Daniel: Would it be okay for you to assign the copyrights to us? > Our idea is to keep them all in one place. I thought I added myname to the "Authors:" part of the comment header... Anyway: I hereby transfer my intellectual property rights on the work made so far, in favor of Intevation GmbH. A long time ago you (or maybe Jan) sent me an FSFE form for that, but I can't find it. BTW, are you thinking about transferring all copyrights to FSF or FSFE at some point in time or are you planning on keeping Intevation as copyright holder? Since this is all GPL-covered work, there is no problem wrt further development, derivatives and the like, but it is legally sound to have a unique copyright holder, and it being the FSF(E) might be even more interesting in any litigation case. Daniel. From cvs at intevation.de Fri Jan 21 09:31:18 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 09:31:18 +0100 (CET) Subject: jan: thuban/Thuban/UI mainwindow.py,1.139,1.140 Message-ID: <20050121083118.4585E102BD0@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv12021 Modified Files: mainwindow.py Log Message: (view_position_changed): Made string available for i18n. Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.139 retrieving revision 1.140 diff -u -d -r1.139 -r1.140 --- mainwindow.py 20 Jan 2005 18:47:26 -0000 1.139 +++ mainwindow.py 21 Jan 2005 08:31:16 -0000 1.140 @@ -368,8 +368,8 @@ -180 <= right <= 180 and -90 <= top <= 90 and -90 <= bottom <= 90): - text = ("Select '"+layer.title+"' and pick a " + - "projection using Layer/Projection...") + text = _("Select layer '%s' and pick a projection " + "using Layer/Projection...") % layer.title break self.set_position_text(text) From cvs at intevation.de Fri Jan 21 09:31:45 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 09:31:45 +0100 (CET) Subject: jan: thuban ChangeLog,1.766,1.767 Message-ID: <20050121083145.31F22102BD0@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv12055 Modified Files: ChangeLog Log Message: string fix. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.766 retrieving revision 1.767 diff -u -d -r1.766 -r1.767 --- ChangeLog 20 Jan 2005 20:41:58 -0000 1.766 +++ ChangeLog 21 Jan 2005 08:31:43 -0000 1.767 @@ -1,3 +1,8 @@ +2005-01-21 Jan-Oliver Wagner + + * Thuban/UI/mainwindow.py (view_position_changed): Made string + available for i18n. + 2005-01-20 Russell Nelson * Resources/Projections/defaults.proj: Ruin the speling of the From bernhard at intevation.de Fri Jan 21 13:00:56 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Jan 2005 13:00:56 +0100 Subject: [Thuban-list] tests for Daniel Cavelo's classifiers In-Reply-To: <20050121021357.M66533@minag.gob.pe> References: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> <20050120204836.GA20846@intevation.de> <20050121021357.M66533@minag.gob.pe> Message-ID: <20050121120056.GC21877@intevation.de> On Thu, Jan 20, 2005 at 09:21:52PM -0500, Daniel Calvelo Aros wrote: > From: Bernhard Reiter > > > > Daniel: Would it be okay for you to assign the copyrights to us? > > Our idea is to keep them all in one place. > > I thought I added myname to the "Authors:" part of the comment header... I did see that in one file. The new files in Moritz' set did not include headers at all. > Anyway: > > I hereby transfer my intellectual property rights on the work made so far, in > favor of Intevation GmbH. A long time ago you (or maybe Jan) sent me an FSFE > form for that, but I can't find it. Thanks a lot! > BTW, are you thinking about transferring all copyrights to FSF or FSFE at some > point in time or are you planning on keeping Intevation as copyright holder? This depends on how partical the FLA procedures will be. In principle we would like to transfer it, if this is easy enough. Currently it is not easy enough. > Since this is all GPL-covered work, there is no problem wrt further > development, derivatives and the like, but it is legally sound to have a > unique copyright holder, and it being the FSF(E) might be even more > interesting in any litigation case. Yes! The only thing that could happen to Thuban is a potential move to GNU LGPL for the sake of users that need to connect to proprietary formats or GIS products. So far we did not seem that to be necessary, but that might change in the future. 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/20050121/75ad97dc/attachment.bin From bernhard at intevation.de Fri Jan 21 13:04:02 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Jan 2005 13:04:02 +0100 Subject: MacOSX status and wx 2.5 In-Reply-To: <41F04F5F.8030706@noaa.gov> References: <20050120114517.19A16102BDC@lists.intevation.de> <41F04F5F.8030706@noaa.gov> Message-ID: <20050121120402.GD21877@intevation.de> On Thu, Jan 20, 2005 at 04:39:59PM -0800, Chris Barker wrote: > cvs at intevation.de wrote: > > >+ # Testing showed this is needed with current wx 2.4. > >versions + # on MacOSX to guarantee that it is called at > >all. > > This brings up a question for me: > > What is the status of Thuban on OS-X? I think it is up and running with some bugs. Lorenzo has made nice packages. See thuban-list and http://thuban.intevation.org/download.html#bin_macosx > What are the plans for updating to wxPython 2.5.* ? We like to do it for CVS HEAD, but currently nobody has put in the time. So all help is welcome. > These two are intricately connected, because wxPython 2.4.* is really > next to worthless on OS-X. I cannot say, from what Daniel and Lorenzo write, it Thuban might actually be usable despite some issues with wx 2.4.x. Best, 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/20050121/416865c9/attachment.bin From bernhard at intevation.de Fri Jan 21 13:06:56 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Jan 2005 13:06:56 +0100 Subject: new raster code In-Reply-To: <1106259431.3336.85.camel@localhost.localdomain> References: <1106232805.3336.59.camel@localhost.localdomain> <20050120150051.GG1518@intevation.de> <1106238256.3336.64.camel@localhost.localdomain> <20050120203003.GE19836@intevation.de> <1106259431.3336.85.camel@localhost.localdomain> Message-ID: <20050121120656.GE21877@intevation.de> On Thu, Jan 20, 2005 at 05:17:11PM -0500, Jonathan Coles wrote: > Am Donnerstag, den 20.01.2005, 21:30 +0100 schrieb Bernhard Reiter: > > The new raster code, applies nicely to CVS, > > displays and image faster and all test run through positively. > > > > However I could make it dump tracebacks in a strange way. > > Using Russels test data: > > http://russnelson.com/089uni00s.zip > > http://russnelson.com/089map.zip > > http://russnelson.com/test.zip > > I had a session saved (attached session). > > > > If I am opening this everything is fine. > > Then I add the image from 089map.zip as image layer > > (not giving it a project yet). > > Pressing resize to map on the vector layers gives > > me the first traceback (in attached file). > > > > Then after giving it a projects I get other errors > > on stdout (see second example in the attached file). > > > > So I was close saying: It is your code, just submit and squash the bugs... > > But now it seems like I did find the first bug right away. ;) > > i was able to reproduce the problem on the current CVS code. this does > *not* include my changes, so something else is wrong. i don't think my > patches have broken anything that wasn't already broken :) Okay, then put your changes in. ;) (Shall I do it or do you want to do it yourself when you have send me a new ssh2 key? and your CVS write access is reestablished?) -------------- 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/20050121/6ef7fa87/attachment.bin From bernhard at intevation.de Fri Jan 21 13:08:49 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Jan 2005 13:08:49 +0100 Subject: undo? In-Reply-To: <1106269404.5206.10.camel@localhost.localdomain> References: <16880.3214.456618.679937@desk.crynwr.com> <1106269404.5206.10.camel@localhost.localdomain> Message-ID: <20050121120849.GF21877@intevation.de> On Thu, Jan 20, 2005 at 08:03:24PM -0500, Jonathan Coles wrote: > however, i'm not sure that the whole session file should be a sequence > of commands. if it was, the only way to get the final state of the > session would be to run through all the commands from the beginning when > the session is loaded. if the final state was saved using the current > mechanism and *in addition* the commands were saved this could be really > cool. the user could load a saved file and then still be able to undo > things they had done in a previous session! Yes, the a configurable number of last executed commands should be saved to allow undo even after a save-load operation. First step will be to have this set of undo objects so that we actually can do undos during the run. > also, it would further seperate the UI and Model components and allow > much fuller tests. Can you elaborate how it does this? -------------- 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/20050121/ecfc9d11/attachment.bin From thuban-bugs at intevation.de Fri Jan 21 14:06:34 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Fri, 21 Jan 2005 14:06:34 +0100 (CET) Subject: [bug #2921] (thuban) panning with middle button not working without active tool Message-ID: <20050121130634.00741102BFC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2921 ------------------------------------------------------------------------- Subject: panning with middle button not working without active tool The middle mouse button panning does not work when no tool is activated. Jan would prefer a solution without preselecting a tool during thuban startup, so do I. Also see the discussion: http://intevation.de/pipermail/thuban-devel/2004-December/000788.html -------------------------------------------- Managed by Request Tracker From thuban-bugs at intevation.de Fri Jan 21 14:08:00 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Fri, 21 Jan 2005 14:08:00 +0100 (CET) Subject: [bug #2922] (thuban) move layer projection warning code to a correct place Message-ID: <20050121130800.20755102BFB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2922 ------------------------------------------------------------------------- Subject: move layer projection warning code to a correct place As Bernhard H. keep saying the code for the layer projection warning does not belong to the view update. He is right, this issue it here to not forget this. A better place for the code could be where the legend is constructed. -------------------------------------------- Managed by Request Tracker From cvs at intevation.de Fri Jan 21 14:23:02 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 14:23:02 +0100 (CET) Subject: bernhard: thuban/Resources/Projections defaults.proj,1.9,1.9.2.1 Message-ID: <20050121132302.28D95102C01@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban/Resources/Projections In directory doto:/tmp/cvs-serv18725/Resources/Projections Modified Files: Tag: thuban-1-0-branch defaults.proj Log Message: * Resources/Projections/defaults.proj: Temporary fix from HEAD added: Ruin the spelling of the Lambert-93 projection so it doesn't run into the wx UTF-8 bug. It's the wrong thing to do in the long run, but it's necessary for those users until that bug is fixed. Otherwise the projection dialog segfaults. Better to annoy some Lambert-93 users with a spelling mistake than many Fedora Core 3 users. Index: defaults.proj =================================================================== RCS file: /thubanrepository/thuban/Resources/Projections/defaults.proj,v retrieving revision 1.9 retrieving revision 1.9.2.1 diff -u -d -r1.9 -r1.9.2.1 --- defaults.proj 9 Dec 2003 16:17:01 -0000 1.9 +++ defaults.proj 21 Jan 2005 13:23:00 -0000 1.9.2.1 @@ -48,7 +48,7 @@ - + From cvs at intevation.de Fri Jan 21 14:23:02 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 14:23:02 +0100 (CET) Subject: bernhard: thuban ChangeLog,1.624.2.32,1.624.2.33 Message-ID: <20050121132302.31B83102C02@lists.intevation.de> Author: bernhard Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv18725 Modified Files: Tag: thuban-1-0-branch ChangeLog Log Message: * Resources/Projections/defaults.proj: Temporary fix from HEAD added: Ruin the spelling of the Lambert-93 projection so it doesn't run into the wx UTF-8 bug. It's the wrong thing to do in the long run, but it's necessary for those users until that bug is fixed. Otherwise the projection dialog segfaults. Better to annoy some Lambert-93 users with a spelling mistake than many Fedora Core 3 users. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.624.2.32 retrieving revision 1.624.2.33 diff -u -d -r1.624.2.32 -r1.624.2.33 --- ChangeLog 10 Jan 2005 17:09:48 -0000 1.624.2.32 +++ ChangeLog 21 Jan 2005 13:22:59 -0000 1.624.2.33 @@ -1,3 +1,14 @@ +2005-01-20 Russell Nelson + + * Resources/Projections/defaults.proj: + Temporary fix from HEAD added: + Ruin the spelling of the + Lambert-93 projection so it doesn't run into the wx UTF-8 bug. + It's the wrong thing to do in the long run, but it's necessary for + those users until that bug is fixed. Otherwise the projection + dialog segfaults. Better to annoy some Lambert-93 users with a + spelling mistake than many Fedora Core 3 users. + 2005-01-10 Jan-Oliver Wagner * Thuban/UI/mainwindow.py (MainWindow.DuplicateLayer): From jonathan at jpcoles.com Fri Jan 21 14:55:30 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Fri, 21 Jan 2005 08:55:30 -0500 Subject: [Fwd: Re: new raster code] Message-ID: <1106315730.3712.24.camel@localhost.localdomain> -------- Weitergeleitete Nachricht -------- > Von: Bernhard Reiter > An: Jonathan Coles > Betreff: Re: new raster code > Datum: Thu, 20 Jan 2005 21:35:32 +0100 > Thanks for the answers below, can I forward them to the list? > Or do you want to do it? > > I guess it just makes more sense to answer them on the list so we > have it documented and other people can also comment on your > comments. > > On Thu, Jan 20, 2005 at 02:56:57PM -0500, Jonathan Coles wrote: > > Am Donnerstag, den 20.01.2005, 20:51 +0100 schrieb Bernhard Reiter: > > > Why is the CPLError function commented out here? > > > if ( err ) > > > { > > > - CPLError( CE_Failure, err, "" ); > > > + //CPLError( CE_Failure, err, "%s\n", CPLGetLastErrorMsg() > > > ); > > > return NULL; > > > } > > > > as far as i could tell, it wasn't being printed, and the error message > > is passed up to thuban as an exception message any way. > > > On Thu, Jan 20, 2005 at 03:13:55PM -0500, Jonathan Coles wrote: > > Am Donnerstag, den 20.01.2005, 21:05 +0100 schrieb Bernhard Reiter: > > > Got a warning while compiling: > > > building 'Lib.gdalwarp' extension > > > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall > > > -Wstrict-prototypes -fPIC -I/usr/include -Ilibraries/thuban/ > > > -I/usr/include/python2.3 -c libraries/thuban/gdalwarp.cpp -o > > > build/temp.linux-ppc-2.3/libraries/thuban/gdalwarp.o > > > libraries/thuban/gdalwarp.cpp: In Funktion ?CPLErr > > > GetImageData(GDALDataset*, > > > unsigned char**, unsigned int*)?: > > > libraries/thuban/gdalwarp.cpp:209: Warnung: unused variable `int > > > nWordSize' > > > > it is, indeed, unused. i have already fixed this in revisions since the > > patches i sent you. -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From cvs at intevation.de Fri Jan 21 15:01:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:01:27 +0100 (CET) Subject: jonathan: thuban/Thuban/UI baserenderer.py, 1.13, 1.14 renderer.py, 1.53, 1.54 Message-ID: <20050121140127.D718B102BEC@lists.intevation.de> Author: jonathan Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv21080/Thuban/UI Modified Files: baserenderer.py renderer.py Log Message: Improved rendering raster layers by changing the return format of the ProjectRasterFile function. Index: baserenderer.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/baserenderer.py,v retrieving revision 1.13 retrieving revision 1.14 diff -u -d -r1.13 -r1.14 --- baserenderer.py 22 Nov 2004 11:16:35 -0000 1.13 +++ baserenderer.py 21 Jan 2005 14:01:25 -0000 1.14 @@ -76,6 +76,13 @@ """ del _renderer_extensions[:] +def proj_params_to_str(proj): + "Build a string suitable for GDAL describing the given projection" + str = "" + if proj is not None: + for p in proj.GetAllParameters(): + str += "+" + p + " " + return str # # Base Renderer @@ -177,35 +184,17 @@ that methods especially in derived classes have access to the map if necessary. """ - # Whether the raster layer has already been drawn. See below for - # the optimization this is used for - seenRaster = True - - # - # This is only a good optimization if there is only one - # raster layer and the image covers the entire window (as - # it currently does). We note if there is a raster layer - # and only begin drawing layers once we have drawn it. - # That way we avoid drawing layers that won't be seen. - # - if Thuban.Model.resource.has_gdal_support(): - for layer in self.map.Layers(): - if isinstance(layer, RasterLayer) and layer.Visible(): - seenRaster = False - break for layer in self.map.Layers(): # if honor_visibility is true, only draw visible layers, # otherwise draw all layers if not self.honor_visibility or layer.Visible(): if isinstance(layer, Layer): - if seenRaster: - for i in self.draw_shape_layer_incrementally(layer): - yield True + for i in self.draw_shape_layer_incrementally(layer): + yield True elif isinstance(layer, RasterLayer) \ and Thuban.Model.resource.has_gdal_support(): self.draw_raster_layer(layer) - seenRaster = True yield True else: # look it up in the renderer extensions @@ -370,6 +359,7 @@ scale = self.scale offx, offy = self.offset make_point = self.make_point + for part in points: result.append([]) for x, y in part: @@ -462,50 +452,70 @@ offx, offy = self.offset width, height = self.dc.GetSizeTuple() - in_proj = "" - proj = layer.GetProjection() - if proj is not None: - for p in proj.GetAllParameters(): - in_proj += "+" + p + " " + in_proj = proj_params_to_str(layer.GetProjection()) + out_proj = proj_params_to_str(self.map.GetProjection()) - out_proj = "" - proj = self.map.GetProjection() - if proj is not None: - for p in proj.GetAllParameters(): - out_proj += "+" + p + " " + # True -- warp the image to the size of the whole screen + # False -- only use the bound box of the layer (currently inaccurate) + if True: + pmin = [0,height] + pmax = [width, 0] + else: + bb = layer.LatLongBoundingBox() + bb = [[[bb[0], bb[1]], [bb[2], bb[3]],],] + pmin, pmax = self.projected_points(layer, bb)[0] - xmin = (0 - offx) / self.scale - ymin = (offy - height) / self.scale - xmax = (width - offx) / self.scale - ymax = (offy - 0) / self.scale + fmin = [max(0, pmin[0]) - offx, offy - min(height, pmin[1])] + fmax = [min(width, pmax[0]) - offx, offy - max(0, pmax[1])] + + xmin = fmin[0]/self.scale + ymin = fmin[1]/self.scale + xmax = fmax[0]/self.scale + ymax = fmax[1]/self.scale + + width = int(min(width, round(fmax[0] - fmin[0] + 1))) + height = int(min(height, round(fmax[1] - fmin[1] + 1))) try: - data = ProjectRasterFile(layer.GetImageFilename(), + data = [width, height, + ProjectRasterFile(layer.GetImageFilename(), in_proj, out_proj, (xmin, ymin, xmax, ymax), "", (width, height)) + ] except (IOError, AttributeError, ValueError): # Why does this catch AttributeError and ValueError? # FIXME: The exception should be communicated to the user # better. traceback.print_exc() else: - self.draw_raster_data(data, "BMP") + mask = "#030104" + #mask = None + self.draw_raster_data(fmin[0]+offx, offy-fmax[1], data, "RAW", mask) + data = None - def draw_raster_data(self, data, format="BMP"): - """Draw the raster image in data onto the DC + def draw_raster_data(self, x, y, data, format="BMP", mask = None): + """Draw the raster image in data onto the DC with the top + left corner at (x,y) - The raster image data is a string holding the data in the format - indicated by the format parameter. The image is assumed to be - exactly the size of the dc and to cover it completely. + The raster image data is a list holding the image width, height, + and data in the format indicated by the format parameter. The format parameter is a string with the name of the format. The following format names should be used: - 'BMP' -- Windows Bitmap - 'JPEG' -- Jpeg + 'RAW' -- an array of RGB values (len=3*width*height) + 'BMP' -- Windows Bitmap + 'JPEG' -- JPEG Image - The default format is 'bmp'. + The default format is 'BMP'. + + The mask parameter determines how a mask (if any) is applied + to the image. mask can have the following values: + + o None -- no mask is used + o Any object accepted by wxBitmap.SetMaskColour() + o A one-bit image the same size as the image data This method has to be implemented by derived classes. The implementation in the derived class should try to support at Index: renderer.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/renderer.py,v retrieving revision 1.53 retrieving revision 1.54 diff -u -d -r1.53 -r1.54 --- renderer.py 3 Jan 2005 16:21:17 -0000 1.53 +++ renderer.py 21 Jan 2005 14:01:25 -0000 1.54 @@ -22,7 +22,8 @@ wxTRANSPARENT_PEN, wxTRANSPARENT_BRUSH, \ wxBLACK_PEN, wxBLACK, wxSOLID, wxCROSS_HATCH, wxSWISS, wxNORMAL, \ wxBitmapFromImage, wxImageFromStream, wxBITMAP_TYPE_BMP, \ - wxBITMAP_TYPE_JPEG, wxBITMAP_TYPE_PNG, wxBITMAP_TYPE_TIF, wxBITMAP_TYPE_GIF + wxBITMAP_TYPE_JPEG, wxBITMAP_TYPE_PNG, wxBITMAP_TYPE_TIF, \ + wxBITMAP_TYPE_GIF, wxEmptyImage from wxproj import draw_polygon_shape, draw_polygon_init @@ -38,6 +39,10 @@ from baserenderer import BaseRenderer +from math import floor + +from types import StringType + # Map the strings used for the format parameter of the draw_raster_data # method to the appropriate wxWindows constants @@ -99,11 +104,27 @@ return wxFont(int(round(self.resolution * 10)), wxSWISS, wxNORMAL, wxNORMAL) - def draw_raster_data(self, data, format = 'BMP'): - stream = cStringIO.StringIO(data) - image = wxImageFromStream(stream, raster_format_map[format]) + def draw_raster_data(self, x,y, data, format = 'BMP', mask = None): + if format == 'RAW': + image = wxEmptyImage(data[0], data[1]) + image.SetData(data[2]) + else: + stream = cStringIO.StringIO(data[2]) + image = wxImageFromStream(stream, raster_format_map[format]) + bitmap = wxBitmapFromImage(image) - self.dc.DrawBitmap(bitmap, 0, 0) + + if mask is None: + self.dc.DrawBitmap(bitmap, int(round(x)), int(round(y)), False) + else: + # if we are given a mask object, try to pass it to SetMaskColour, + # otherwise assume it's a mask image + try: + bitmap.SetMaskColour(mask); + self.dc.DrawBitmap(bitmap, int(round(x)), int(round(y)), True) + except (TypeError): + # implement using a mask image + raise NotImplementedError class ScreenRenderer(MapRenderer): From cvs at intevation.de Fri Jan 21 15:01:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:01:27 +0100 (CET) Subject: jonathan: thuban/libraries/thuban gdalwarp.cpp, 1.1, 1.2 bmpdataset.cpp, 1.1, NONE cpl_mfile.cpp, 1.2, NONE cpl_mfile.h, 1.2, NONE Message-ID: <20050121140127.E1419102C00@lists.intevation.de> Author: jonathan Update of /thubanrepository/thuban/libraries/thuban In directory doto:/tmp/cvs-serv21080/libraries/thuban Modified Files: gdalwarp.cpp Removed Files: bmpdataset.cpp cpl_mfile.cpp cpl_mfile.h Log Message: Improved rendering raster layers by changing the return format of the ProjectRasterFile function. Index: gdalwarp.cpp =================================================================== RCS file: /thubanrepository/thuban/libraries/thuban/gdalwarp.cpp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- gdalwarp.cpp 19 Aug 2003 21:32:24 -0000 1.1 +++ gdalwarp.cpp 21 Jan 2005 14:01:25 -0000 1.2 @@ -30,6 +30,10 @@ ****************************************************************************** * * $Log$ + * Revision 1.2 2005/01/21 14:01:25 jonathan + * Improved rendering raster layers by changing the return format of + * the ProjectRasterFile function. + * * Revision 1.1 2003/08/19 21:32:24 jan * These files have been moved here from thuban/extensions/thuban/ * See there in the Attic for the older history. @@ -91,32 +95,23 @@ * */ +#include + +#include "gdal.h" #include "gdal_alg.h" +#include "gdal_priv.h" #include "cpl_string.h" #include "ogr_srs_api.h" -#include "cpl_mfile.h" - -CPL_C_START -void CPL_DLL GDALRegister_THUBANBMP(void); -CPL_C_END - - -/* MFILENAME takes the name of a variable to declare as being the - * "filename", and the address of a MFILEReceiver. - */ -#define MFILENAME(name, ptr) \ -char name[ 8 + 2 * sizeof( void* ) + 1]; \ -{snprintf( name, sizeof(name), "\3\1\4MFILE%0*x", 2*sizeof(void*), (int)(ptr)); \ - memset( ptr, 0, sizeof( ptr ) );} - -#include #define PYTHON_ERR(x) \ {const char *str = CPLGetLastErrorMsg(); \ str != NULL ? PyErr_SetString(x, str) : PyErr_SetString(x, "");} #define LEAVE_NOW(e) { err = e; goto getOut; } +#define NO_DATA_VAL 255 +#define NO_DATA_VAL_STR "255" + CPL_CVSID("$Id$"); static GDALDatasetH @@ -188,11 +183,191 @@ return pszResult; } +/************************************************************************/ +/* GetImageData */ +/* */ +/* Extract the image data from the GDALDataset and pack it into a single*/ +/* array of RGB triples. Use the ColorTable to determine the RGB */ +/* values. We extract the data from the GDALDataset rather than create */ +/* our own driver because the data needs to be translated from */ +/* 4 byte pixel information into 3 byte RGB information. This could be */ +/* done as the data is written to the data set or afterwards, as it is */ +/* done here. Any minor savings from our own driver are outweighed by */ +/* the high development/maintenance costs. */ +/* */ +/* TODO: */ +/* */ +/* o Handle out of memory issues more cleanly than asserting */ +/* o Handle the case where there is no color table (is there a case?) */ +/* */ +/************************************************************************/ + +static CPLErr GetImageData(GDALDataset *ds, + unsigned char **imgbuf, unsigned int *imglen) +{ + CPLErr ret = CE_None; + + GDALColorEntry color; + GDALColorTable *pal = NULL; + + ds->FlushCache(); + + int rasterCount = ds->GetRasterCount(); + int nRasterXSize = ds->GetRasterXSize(); + int nRasterYSize = ds->GetRasterYSize(); + if ( ! (nRasterXSize > 0 && nRasterYSize > 0 )) + return CE_Failure; + + // + // create the new image array for RGBRGB... values + // + *imglen = 3 * nRasterXSize * nRasterYSize; + *imgbuf = new unsigned char[*imglen]; + if ( *imgbuf == NULL ) + return CE_Failure; + + memset(*imgbuf, 170, *imglen); + + // + // if there are three bands assume for now that they are RGB bands + // + if (rasterCount == 3) + { + for (int i=1; i <= rasterCount; i++) + { + int offs = 0; + GDALRasterBand *band = ds->GetRasterBand(i); + + switch (band->GetColorInterpretation()) + { + case GCI_RedBand: offs = 1; break; + case GCI_GreenBand: offs = 2; break; + case GCI_BlueBand: offs = 3; break; + default: offs = i-1; break; + } + + // + // copy the image into the buffer using the proper offset + // so we first copy over all Red values, then all Green + // values, and then all Blue values + // + ret = band->RasterIO(GF_Read, 0, 0, + nRasterXSize, nRasterYSize, + *imgbuf+offs, nRasterXSize, nRasterYSize, + GDT_Byte, 3, 0); + + if (ret == CE_Failure) break; + } + } + else if (rasterCount == 1) + { + // + // one band is either a palette based image, or greyscale + // + + GDALRasterBand *band = ds->GetRasterBand(1); + + switch (band->GetColorInterpretation()) + { + case GCI_PaletteIndex: + + pal = band->GetColorTable(); + // FIXME: what happens if pal is NULL? ignore? + + // test this once to see if conversion is supported. + if (pal && pal->GetColorEntryAsRGB(0, &color)) + { + // + // copy over all the palette indices and then + // loop through the buffer replacing the values + // with the correct RGB triples. + // + ret = band->RasterIO(GF_Read, 0, 0, + nRasterXSize, nRasterYSize, + *imgbuf, nRasterXSize, nRasterYSize, + GDT_Byte, 3, 0); + + if (ret == CE_Failure) break; + + for (unsigned char *data = *imgbuf; + data != (*imgbuf+*imglen); + data += 3) + { + if (*data == NO_DATA_VAL) + { + *(data + 0) = 3; + *(data + 1) = 1; + *(data + 2) = 4; + } + else + { + pal->GetColorEntryAsRGB(*data, &color); + + *(data + 0) = color.c1; + *(data + 1) = color.c2; + *(data + 2) = color.c3; + } + } + } + break; + + case GCI_Undefined: // can we try to make a greyscale image? + case GCI_GrayIndex: + + // + // copy over all the palette indices and then + // loop through the buffer replacing the values + // with the correct RGB triples. + // + ret = band->RasterIO(GF_Read, 0, 0, + nRasterXSize, nRasterYSize, + *imgbuf, nRasterXSize, nRasterYSize, + GDT_Byte, 3, 0); + + if (ret == CE_Failure) break; + + for (unsigned char *data = *imgbuf; + data != (*imgbuf+*imglen); + data += 3) + { + if (*data == NO_DATA_VAL) + { + *(data + 0) = 3; + *(data + 1) = 1; + *(data + 2) = 4; + } + else + { + //pal->GetColorEntry(*data, &color); + + //*(data + 0) = *data; // already correct + *(data + 1) = *data; + *(data + 2) = *data; + } + } + break; + + default: + fprintf(stderr, + "GetImageData: Unsupported color interpretation '%s'\n", + GDALGetColorInterpretationName( + band->GetColorInterpretation())); + break; + } + } + + if (ret != CE_None) + if (imgbuf != NULL) delete imgbuf; + + return ret; +} + static PyObject* ProjectRasterFile(PyObject *, PyObject * args) { - GDALDatasetH hSrcDS, hDstDS; - const char *pszFormat = "GTiff"; + GDALDatasetH hSrcDS = NULL, hDstDS = NULL; + const char *pszFormat = "MEM"; + const char *pszDstFilename = "MEM:::"; char *pszTargetSRS = NULL; char *pszSourceSRS = NULL; const char *pszSrcFilename = NULL; @@ -203,9 +378,10 @@ GDALTransformerFunc pfnTransformer = NULL; char **papszCreateOptions = NULL; int err = 0; + unsigned char *imgbuf = NULL; + unsigned int imglen = 0; - PyObject * returnFileData = NULL; - + PyObject * pyImageData = NULL; PyObject * filename; PyObject * srcImageArgs; PyObject * dstImageArgs; @@ -213,11 +389,6 @@ PyObject * resolution; PyObject * imageRes; - MFILEReceiver receiver; - MFILENAME(pszDstFilename, &receiver); - - //dummycall(); - if (!PyArg_ParseTuple(args, "OOOOOO", &filename, &srcImageArgs, &dstImageArgs, &extents, @@ -242,12 +413,10 @@ nForcePixels = ( int )PyInt_AsLong( PyTuple_GetItem( imageRes, 0 ) ); nForceLines = ( int )PyInt_AsLong( PyTuple_GetItem( imageRes, 1 ) ); - pszFormat = "THUBANBMP"; - bCreateOutput = TRUE; GDALAllRegister(); - GDALRegister_THUBANBMP(); + GDALRegister_MEM(); /* -------------------------------------------------------------------- */ /* Open source dataset. */ @@ -283,7 +452,8 @@ hDstDS = GDALWarpCreateOutput( hSrcDS, pszDstFilename, pszFormat, pszSourceSRS, pszTargetSRS, nOrder, papszCreateOptions ); - papszWarpOptions = CSLSetNameValue( papszWarpOptions, "INIT", "0" ); + papszWarpOptions = CSLSetNameValue( papszWarpOptions, + "INIT", NO_DATA_VAL_STR ); CSLDestroy( papszCreateOptions ); papszCreateOptions = NULL; @@ -322,6 +492,7 @@ pfnTransformer = GDALApproxTransform; } + /* -------------------------------------------------------------------- */ /* Now actually invoke the warper to do the work. */ /* -------------------------------------------------------------------- */ @@ -344,24 +515,28 @@ CPLErrorReset(); err = 0; -getOut: + imglen = 0; + imgbuf = NULL; - GDALClose( hDstDS ); - GDALClose( hSrcDS ); + if ( GetImageData((GDALDataset *)hDstDS, &imgbuf, &imglen) == CE_None) + { + //printf("imglen: %i\n", imglen); - if ( receiver.data != NULL ) + pyImageData = PyString_FromStringAndSize( ( char * )imgbuf, imglen); + + delete imgbuf; + imgbuf = NULL; + } + else { - returnFileData = PyString_FromStringAndSize( ( char * )receiver.data, - receiver.len ); -#if 0 - FILE *fp; - fp = fopen("dummy.bmp", "w+b"); - fwrite(receiver->data, receiver->len, 1, fp); - fclose(fp); - free( receiver->data ); -#endif + PYTHON_ERR( PyExc_StandardError ); } +getOut: + + GDALClose( hDstDS ); + GDALClose( hSrcDS ); + if ( papszWarpOptions ) CSLDestroy( papszWarpOptions ); if ( pszTargetSRS != NULL ) CPLFree(pszTargetSRS); if ( pszSourceSRS != NULL ) CPLFree(pszSourceSRS); @@ -378,15 +553,13 @@ if ( err ) { - CPLError( CE_Failure, err, "" ); + //CPLError( CE_Failure, err, "%s\n", CPLGetLastErrorMsg() ); return NULL; } else { - Py_XINCREF( returnFileData ); - return returnFileData; + return pyImageData; } - } /************************************************************************/ --- bmpdataset.cpp DELETED --- --- cpl_mfile.cpp DELETED --- --- cpl_mfile.h DELETED --- From cvs at intevation.de Fri Jan 21 15:01:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:01:27 +0100 (CET) Subject: jonathan: thuban ChangeLog,1.767,1.768 setup.py,1.46,1.47 Message-ID: <20050121140127.DD0D3102BFB@lists.intevation.de> Author: jonathan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv21080 Modified Files: ChangeLog setup.py Log Message: Improved rendering raster layers by changing the return format of the ProjectRasterFile function. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.767 retrieving revision 1.768 diff -u -d -r1.767 -r1.768 --- ChangeLog 21 Jan 2005 08:31:43 -0000 1.767 +++ ChangeLog 21 Jan 2005 14:01:25 -0000 1.768 @@ -1,3 +1,48 @@ +2005-01-21 Jonathan Coles + + * Thuban/UI/baserenderer.py (proj_params_to_str): New. Takes + a projection and returns a formatted string representing the + parameters to feed to gdalwarp. This function eliminates + redundancy in draw_raster_layer(). + (render_map_incrementally): Removed the optimization which + drew the top most raster layer first and then only those vector- + based layers that are above it. With the support for transparency + this optimization breaks correct behaviour. + (draw_raster_layer): Reorganize code to support possible future + enhancements to raster layer bounding box. The old behaviour has not + changed. Also, change calling parameters to draw_raster_data() + to specify new RAW data format and mask. + (draw_raster_data): Change signature to include an optional + parameter for mask information. Change documentation to mention + support for new parameter and added option for RAW data format. + The data argument is now a list of [width, height, data]. + + * Thuban/UI/renderer.py (draw_raster_data): Add new optional + mask parameter. Add new condition for RAW format, which + significantly reduces rendering time. Add condition for + mask parameter. + + * libraries/thuban/gdalwarp.cpp (GetImageData): New. Creates a + data array of RGB values from the projected image returned from + the gdal warping functions. In the case of palette based images, it + converts the NO_DATA index to the mask color. + (ProjectRasterFile): Removed all custom memory driver references + and replaced it with the standard in-memory dataset provided + by gdal. The return data is no longer a BMP file, but an array + of RGB values, one set triple per pixel. + + * libraries/thuban/bmpdataset.cpp: Removed. Unnecessary. + * libraries/thuban/cpl_mfile.h: Removed. Unnecessary. + * libraries/thuban/cpl_mfile.cpp: Removed. Unnecessary. + + * setup.py (thuban_build_ext.finalize_options): Removed mention + of cpl_mfile.cpp and bmpdataset.cpp files in the list of source + files. These are obsolete with the new version of gdalwarp.cpp + + * test/test_baserenderer.py (draw_raster_data): Updated signature. + (test_raster_no_projection): Changed the test data to be data + in the uncompressed RAW format returned from ProjectRasterFile. + 2005-01-21 Jan-Oliver Wagner * Thuban/UI/mainwindow.py (view_position_changed): Made string Index: setup.py =================================================================== RCS file: /thubanrepository/thuban/setup.py,v retrieving revision 1.46 retrieving revision 1.47 diff -u -d -r1.46 -r1.47 --- setup.py 17 Dec 2004 18:48:49 -0000 1.46 +++ setup.py 21 Jan 2005 14:01:25 -0000 1.47 @@ -1091,9 +1091,7 @@ build_ext.finalize_options(self) if self.with_gdal and include_gdal: self.extensions.append(Extension("Lib.gdalwarp", - [ext_dir + "/thuban/gdalwarp.cpp", - ext_dir + "/thuban/cpl_mfile.cpp", - ext_dir + "/thuban/bmpdataset.cpp"], + [ext_dir + "/thuban/gdalwarp.cpp"], include_dirs = gdal_cs_params[CS_INCDIRS] + [ext_dir + "/thuban/"], define_macros = gdal_cs_params[CS_DEFS], From cvs at intevation.de Fri Jan 21 15:01:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:01:27 +0100 (CET) Subject: jonathan: thuban/test test_baserenderer.py,1.7,1.8 Message-ID: <20050121140127.E6F41102C02@lists.intevation.de> Author: jonathan Update of /thubanrepository/thuban/test In directory doto:/tmp/cvs-serv21080/test Modified Files: test_baserenderer.py Log Message: Improved rendering raster layers by changing the return format of the ProjectRasterFile function. Index: test_baserenderer.py =================================================================== RCS file: /thubanrepository/thuban/test/test_baserenderer.py,v retrieving revision 1.7 retrieving revision 1.8 diff -u -d -r1.7 -r1.8 --- test_baserenderer.py 10 Nov 2003 16:57:43 -0000 1.7 +++ test_baserenderer.py 21 Jan 2005 14:01:25 -0000 1.8 @@ -89,7 +89,7 @@ def label_font(self): return "label font" - def draw_raster_data(self, data, format='BMP'): + def draw_raster_data(self, x, y, data, format='BMP', mask = None): self.raster_data = data self.raster_format = format @@ -287,46 +287,40 @@ # The following commented out code block can be used to generate # the base64 coded reference image data - #hexed = binascii.b2a_base64(renderer.raster_data) + #hexed = binascii.b2a_base64(renderer.raster_data[2]) #while hexed: - # print repr(hexed[:65]) - # hexed = hexed[65:] + #print repr(hexed[:65]) + #hexed = hexed[65:] # The reference data as a base64 coded BMP image raw_data = binascii.a2b_base64( - 'Qk3GBQAAAAAAADYEAAAoAAAAFAAAABQAAAABAAgAAAAAAJABAAAAAAAAAAAAAAABA' - 'AAAAAAAApYOAALGAgAGfjoAHmZyACZ2egAujo4AArICAE66GgACngIA5mZSAJqONg' - 'ACzgIAAoIyABZqZgAO4uYAAtICAAKqAgAScloAAtYCADKepgAS2t4AAooiAALaAgA' - 'CtgIAHsbOAAp2TgACogIAFtbaACqOigAidnoAAuICADKaogACfjoAAr4CAAKSFgAm' - 'fnoAAo4eABrS1gAibnoAHsbKAAp6SgACmg4AGs7SACLCxgAqioIAAoYqAAZ6RgACm' - 'goAKrK6AALmAgAC3gIAApIaABZqagACngYAAo4iAAKmAgAivsYAJoJ6AALCAgACyg' - 'IAAq4CAAKWEgAOclYALpqeAAK6AgACgjYAEm5eAAKKKgAGekIAHmp6ABpmcgAChi4' - 'ALpaaACJyegAClhYAEnJeAAZ+QgAqhoIADnZSAB5mdgACiiYAJnp6ACqGegAqrrYA' - 'GmpuAB5megACkh4ALqqyAA52VgAulpYAAoI6AAZ+PgASbmIALpKWAA7m5gAWbmYAG' - 'mpyAC6SjgAqioYADnZOAA7q6gAianoALqauABpqagAqgnoAEnJWAAp6RgAWbmIACu' - '7uACqGfgAqiooAMqauAAby8gAmusIAMp6qAC6WngAyoqoABvb2AC6SkgAS3uIAJra' - '+AB7KzgAynqIALq62ADKirgAC+voAGsrSABLi4gAG8vYADubqAC6qtgAuprIABvb6' - 'ACLCygAW2t4AKra+AAru8gAS4uYACuruAAry8gAG+voAAEBAAFhkZABAQEAABp6fA' - 'EBACAAAgPwAAPu/AJE9CgBACAAALj1BAEAICAAGPAAAQAgAAAY8+gBACL8AJTxXAA' - 'gIQAAAPEAAAAgIAAY8QABACAgAAGQAAABAAAAALpoAAEBAAAAALgAAAEAABkAGAEA' - 'IQAD2AEAAvwAIAJAu2ABAQEAALmQ5AEBAQAAAnp8AAEAIAAD4+gAAv78An5rDAEBA' - 'QAAuhAcAQEBAAAb8AABAvwAAAGQKAABAAABpLksAQEAIAC4ACwBAAAAAAPkGAAC/Q' - 'AD2APoAvwC/AJ0umgBAQEAAAGRkAABAQAAGnp8AQEAIAPcA/AC/AL8A7D0GAEAIQA' - 'D4hAAAv0AAAAD8QAAAvwgA92T6AL9AvwDsLlcAQEBAAC4AQABAAAgA+EAAAL8IAAA' - '8AAAACAAAAJ8uVgBAQEAAAGQ5AABAQAAAnpcAAEBAAPYAQAC/AAgAnQsGAEAAQAAA' - 'hG0AAEBAAB38PQAIv0AA9mT6AL9AvwAJLmwAZUBAAB0AQAAIAAgAHUAAAAgIAAAAA' - 'AAAAAAAAACzbAAAQEAA//k5AH+/QAAGb5cAQEBAAACy5AAAQAgAAIpAAABACAAAAA' - 'AAAAAAAAkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk' - 'JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ' - 'CQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJC' - 'QkJCQkJCQkJCQkJCQkJCQkJCQkyEi8aQCEJCQkJCQkJCQkJCQkJCTI7OwgILzsyCg' - 'kJCQkJCQkJCQkJCzcJFggvADwGEDc3EhYAMgkJCQkJEjcVJDohGj0LGgYAPT0hCT0' - 'LDyI3CQoBLwAaFgkyEC9AJAE8OgsIMjoABi8kCx4JCQkJCQkeGko8KTcLCxIyNwkJ' - 'CQkWEjwWNUAQPCEAMwgJCQkJCQkSQBcvEkAPAQkyN0AMCQkJCQhBFyEvNy89JCIkM' - 'yItGQwJCQo9RxozIgkyCQoPFxAtDBkgIgkJCQkJCQkJMRoQECJQNi9EIAAgCQkJCQ' - 'kSUA88UAYeBjELICA8HiI=\n') - self.assertEquals(renderer.raster_data, raw_data) - self.assertEquals(renderer.raster_format, "BMP") + 'UmbmUmbmUmbmUmbmUmbmAtYCJooCAtICAq4CJooCArICAuICArICAuYCAs4COn4CO' + 'n4CAq4CAuICFpICUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmAuYCAqICAqoCAqoCFp' + 'ICJooCIo4CCpoCQnoGOn4CDpYCOn4CUmbmUmbmNo6aEpYCLoYCAqICGpICFpICUmb' + 'mAt4CUmbmNo6aAtICArYCAqoCKoYCMoICTnYKOn4CFpICUmbmUmbmUmbmUmbmAp4C' + 'NoICArYCAr4CCpoCAqYCCpoCEpYCHo4CFpICHo4CGpICFpICKoYCTnYKMoICAp4CU' + 'mbmUmbmUmbmUmbmUmbmUmbmAtYCAroCArYCCpoCAtYCAroCAtICAsYCUmbmAt4CAq' + 'YCAroCMoICAs4CAs4CAtYCAt4CAqYCUmbmUmbmUmbmUmbmAtoCAtYCAq4CAtoCBp4' + 'CAroCAqoCAq4CAr4CDpYCGpICAt4CAsICDpYCArICCpoCHo4CAs4CAuICUmbmUmbm' + 'UmbmUmbmUmbmUmbmAuICAqICFpYCAq4CDpoCAqYCFpICAqYCUmbmNo6aAsYCCpoCD' + 'pYCAqICAtoCUmbmAt4CAqoCCpoCAroCHo4CAsYCAq4CAsICAs4CAp4CUmbmAtYCAq' + 'YCIooCHo4CAsICAr4CAqICEpYCAs4CAqICArICDpYCEpYCEpYCAr4CUmbmEpYCAs4' + 'CAtICAs4CAqYCUmbmAtoCAp4CCpoCDpYCAq4CArICAqoCAqYCAqYCAtYCAtoCDpYC' + 'At4CUmbmUmbmUmbmUmbmAt4CAsoCAsoCAp4CAp4CCpoCAsoCAt4CNo6aUmbmUmbmU' + 'mbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmAt4CAtYCCpoCAqICAroCAr4CUmbmUm' + 'bmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmb' + 'mUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbm' + 'UmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmU' + 'mbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUm' + 'bmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmb' + 'mUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbm' + 'UmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmU' + 'mbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUm' + 'bmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmb' + 'mUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbm' + 'UmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbmUmbm\n') + self.assertEquals(renderer.raster_data, [20,20,raw_data]) + self.assertEquals(renderer.raster_format, "RAW") self.assertEquals(dc.calls, [('BeginDrawing',), From cvs at intevation.de Fri Jan 21 15:03:09 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:03:09 +0100 (CET) Subject: jan: thuban/Thuban/UI mainwindow.py,1.128.2.1,1.128.2.2 Message-ID: <20050121140309.0E331102BEC@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv21185 Modified Files: Tag: thuban-1-0-branch mainwindow.py Log Message: (view_position_changed): Backport from HEAD: Warn user about misprojected layers when their lat/lon bounding box exceeds rational lat/lon values. Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.128.2.1 retrieving revision 1.128.2.2 diff -u -d -r1.128.2.1 -r1.128.2.2 --- mainwindow.py 10 Jan 2005 17:08:50 -0000 1.128.2.1 +++ mainwindow.py 21 Jan 2005 14:03:07 -0000 1.128.2.2 @@ -338,6 +338,37 @@ text = "(%10.10g, %10.10g)" % pos else: text = "" + # XXX This is a hack until we find a better place for this code. + # (BER 20050120) + # BH wrote (20050120): + # this branch is only executed when the mouse + # leaves the canvas window, so it's not that often [..] + # [Here] not the right place to put this code. + # I don't have a better solution at hand, + # but the view_position_changed is only there to update + # the current position. If other information is to + # be shown in the status bar it should + # be handled in a different way and + # by other methods. + # + # The status bar widget supports some kind of stack of texts. + # maybe that can be used to distinguis + # between short-lived information such as the mouse position + # and more permanent information such as the hint + # about the projections. + map = self.canvas.Map() + for layer in map.layers: + bbox = layer.LatLongBoundingBox() + if bbox: + left, bottom, right, top = bbox + if not (-180 <= left <= 180 and + -180 <= right <= 180 and + -90 <= top <= 90 and + -90 <= bottom <= 90): + text = _("Select layer '%s' and pick a projection " + "using Layer/Projection...") % layer.title + break + self.set_position_text(text) def set_position_text(self, text): From cvs at intevation.de Fri Jan 21 15:04:03 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:04:03 +0100 (CET) Subject: jan: thuban ChangeLog,1.624.2.33,1.624.2.34 Message-ID: <20050121140403.380D0102BFB@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv21230 Modified Files: Tag: thuban-1-0-branch ChangeLog Log Message: backported missing projection info workaround. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.624.2.33 retrieving revision 1.624.2.34 diff -u -d -r1.624.2.33 -r1.624.2.34 --- ChangeLog 21 Jan 2005 13:22:59 -0000 1.624.2.33 +++ ChangeLog 21 Jan 2005 14:04:01 -0000 1.624.2.34 @@ -1,3 +1,10 @@ +2005-01-21 Jan-Oliver Wagner + + * Thuban/UI/mainwindow.py (view_position_changed): + Backport from HEAD: Warn user about + misprojected layers when their lat/lon bounding + box exceeds rational lat/lon values. + 2005-01-20 Russell Nelson * Resources/Projections/defaults.proj: From cvs at intevation.de Fri Jan 21 15:18:08 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:18:08 +0100 (CET) Subject: jan: thuban/Thuban/UI classgen.py,1.30.2.4,1.30.2.5 Message-ID: <20050121141808.A18CD102BEC@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv21537 Modified Files: Tag: thuban-1-0-branch classgen.py Log Message: (GenQuantilesPanel.OnRetrieve): Backport from HEAD: Add a OnRangeText(0) to work around a different in wx Behaviour noticed on MacOSX, thanks to Lorenzo Moretti and Daniel Calvelo for the fix. Index: classgen.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/classgen.py,v retrieving revision 1.30.2.4 retrieving revision 1.30.2.5 diff -u -d -r1.30.2.4 -r1.30.2.5 --- classgen.py 15 Dec 2004 16:45:30 -0000 1.30.2.4 +++ classgen.py 21 Jan 2005 14:18:06 -0000 1.30.2.5 @@ -904,6 +904,11 @@ try: min, max = table.ValueRange(self.fieldName) self.text_range.SetValue("[" + str(min) + ";" + str(max) + "]") + # This is a workaround, which will result in OnRangeText + # being called twice on some platforms. + # Testing showed this is needed with current wx 2.4. versions + # on MacOSX to guarantee that it is called at all. + self.OnRangeText(None) finally: ThubanEndBusyCursor() From cvs at intevation.de Fri Jan 21 15:18:57 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:18:57 +0100 (CET) Subject: jan: thuban ChangeLog,1.624.2.34,1.624.2.35 Message-ID: <20050121141857.0DB0A102BEC@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv21576 Modified Files: Tag: thuban-1-0-branch ChangeLog Log Message: backport MacOS work around from head. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.624.2.34 retrieving revision 1.624.2.35 diff -u -d -r1.624.2.34 -r1.624.2.35 --- ChangeLog 21 Jan 2005 14:04:01 -0000 1.624.2.34 +++ ChangeLog 21 Jan 2005 14:18:54 -0000 1.624.2.35 @@ -1,5 +1,12 @@ 2005-01-21 Jan-Oliver Wagner + * Thuban/UI/classgen.py (GenQuantilesPanel.OnRetrieve): + Backport from HEAD: + Add a OnRangeText(0) to work around a different in wx Behaviour noticed + on MacOSX, thanks to Lorenzo Moretti and Daniel Calvelo for the fix. + +2005-01-21 Jan-Oliver Wagner + * Thuban/UI/mainwindow.py (view_position_changed): Backport from HEAD: Warn user about misprojected layers when their lat/lon bounding From cvs at intevation.de Fri Jan 21 15:25:27 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 15:25:27 +0100 (CET) Subject: jan: thuban ChangeLog,1.768,1.769 Message-ID: <20050121142527.311EF102BEC@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv21645 Modified Files: ChangeLog Log Message: Various formatting issues resolved, e.g. superflous spaces, but also added class names to method names since some methods have the same name in different classes. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.768 retrieving revision 1.769 diff -u -d -r1.768 -r1.769 --- ChangeLog 21 Jan 2005 14:01:25 -0000 1.768 +++ ChangeLog 21 Jan 2005 14:25:25 -0000 1.769 @@ -1,52 +1,54 @@ 2005-01-21 Jonathan Coles - - * Thuban/UI/baserenderer.py (proj_params_to_str): New. Takes - a projection and returns a formatted string representing the - parameters to feed to gdalwarp. This function eliminates - redundancy in draw_raster_layer(). - (render_map_incrementally): Removed the optimization which - drew the top most raster layer first and then only those vector- - based layers that are above it. With the support for transparency - this optimization breaks correct behaviour. - (draw_raster_layer): Reorganize code to support possible future - enhancements to raster layer bounding box. The old behaviour has not - changed. Also, change calling parameters to draw_raster_data() - to specify new RAW data format and mask. - (draw_raster_data): Change signature to include an optional - parameter for mask information. Change documentation to mention - support for new parameter and added option for RAW data format. - The data argument is now a list of [width, height, data]. - - * Thuban/UI/renderer.py (draw_raster_data): Add new optional - mask parameter. Add new condition for RAW format, which - significantly reduces rendering time. Add condition for - mask parameter. - - * libraries/thuban/gdalwarp.cpp (GetImageData): New. Creates a + + * Thuban/UI/baserenderer.py (proj_params_to_str): New. Takes + a projection and returns a formatted string representing the + parameters to feed to gdalwarp. This function eliminates + redundancy in draw_raster_layer(). + (BaseRenderer.render_map_incrementally): Removed the optimization which + drew the top most raster layer first and then only those vector- + based layers that are above it. With the support for transparency + this optimization breaks correct behaviour. + (BaseRenderer.draw_raster_layer): Reorganize code to support possible + future enhancements to raster layer bounding box. The old behaviour has + not changed. Also, change calling parameters to draw_raster_data() + to specify new RAW data format and mask. + (BaseRenderer.draw_raster_data): Change signature to include an optional + parameter for mask information. Change documentation to mention + support for new parameter and added option for RAW data format. + The data argument is now a list of [width, height, data]. + + * Thuban/UI/renderer.py (MapRenderer.draw_raster_data): Add new optional + mask parameter. Add new condition for RAW format, which + significantly reduces rendering time. Add condition for + mask parameter. + + * libraries/thuban/gdalwarp.cpp (GetImageData): New. Creates a data array of RGB values from the projected image returned from the gdal warping functions. In the case of palette based images, it - converts the NO_DATA index to the mask color. - (ProjectRasterFile): Removed all custom memory driver references - and replaced it with the standard in-memory dataset provided - by gdal. The return data is no longer a BMP file, but an array - of RGB values, one set triple per pixel. + converts the NO_DATA index to the mask color. + (ProjectRasterFile): Removed all custom memory driver references + and replaced it with the standard in-memory dataset provided + by gdal. The return data is no longer a BMP file, but an array + of RGB values, one set triple per pixel. * libraries/thuban/bmpdataset.cpp: Removed. Unnecessary. * libraries/thuban/cpl_mfile.h: Removed. Unnecessary. * libraries/thuban/cpl_mfile.cpp: Removed. Unnecessary. - - * setup.py (thuban_build_ext.finalize_options): Removed mention - of cpl_mfile.cpp and bmpdataset.cpp files in the list of source - files. These are obsolete with the new version of gdalwarp.cpp - - * test/test_baserenderer.py (draw_raster_data): Updated signature. - (test_raster_no_projection): Changed the test data to be data - in the uncompressed RAW format returned from ProjectRasterFile. + + * setup.py (thuban_build_ext.finalize_options): Removed mention + of cpl_mfile.cpp and bmpdataset.cpp files in the list of source + files. These are obsolete with the new version of gdalwarp.cpp + + * test/test_baserenderer.py (SimpleRenderer.draw_raster_data): + Updated signature. + (TestBaseRenderer.test_raster_no_projection): Changed the test + data to be data in the uncompressed RAW format returned from + ProjectRasterFile. 2005-01-21 Jan-Oliver Wagner - * Thuban/UI/mainwindow.py (view_position_changed): Made string - available for i18n. + * Thuban/UI/mainwindow.py (MainWindow.view_position_changed): Made + string available for i18n. 2005-01-20 Russell Nelson @@ -59,32 +61,32 @@ 2005-01-20 Bernhard Reiter - * Thuban/UI/mainwindow.py(view_position_changed): Added docstring - and comment that the warning code here is a hack. + * Thuban/UI/mainwindow.py (MainWindow.view_position_changed): Added + docstring and comment that the warning code here is a hack. 2005-01-20 Russell Nelson - * Thuban/UI/mainwindow.py(view_position_changed): Warn user about - misprojected layers when their lat/lon bounding + * Thuban/UI/mainwindow.py (MainWindow.view_position_changed): Warn + user about misprojected layers when their lat/lon bounding box exceeds rational lat/lon values. 2005-01-20 Bernhard Reiter - * Thuban/UI/about.py (unicodeToLocale()): Improved: + * Thuban/UI/about.py (unicodeToLocale): Improved: Use 'ascii' and then 'replace' for other characters when getdefaultlocale returns None. Thanks to Bernhard H. . - + 2005-01-20 Bernhard Reiter - * Thuban/UI/classgen.py (OnRetrieve()): Added a comment + * Thuban/UI/classgen.py (GenQuantilesPanel.OnRetrieve): Added a comment that OnRangeText might be called twice and using None as argument. - + 2005-01-20 Bernhard Reiter - * Thuban/UI/classgen.py (OnRetrieve()): Add a OnRangeText(0) - to work around a different in wx Behaviour noticed on MacOSX, - thanks to Lorenzo Moretti and Daniel Calvelo for the fix. - + * Thuban/UI/classgen.py (GenQuantilesPanel.OnRetrieve): Add a + OnRangeText(0) to work around a different in wx Behaviour noticed + on MacOSX, thanks to Lorenzo Moretti and Daniel Calvelo for the fix. + 2005-01-20 Bernhard Reiter * Thuban/UI/about.py: take iso-8859-15 when getdefaultlocale returns From jonathan at jpcoles.com Fri Jan 21 16:50:03 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Fri, 21 Jan 2005 10:50:03 -0500 Subject: layer properties dialog Message-ID: <1106322603.3712.40.camel@localhost.localdomain> it was mentioned in RF#2302, the raster layer properties dialog should have more information in it. i've been looking into this because i need to have a place where the user can select which color to use as the masking color (this depends on the colors used in the image, so it should be user changable). one big point that stood right out, was that one dialog box is used for all the kinds of layers. this might make sense with the point, vector, and polygon layers since they all come from shapefiles. however, a raster layer is completely different and should not share the same code. the current setup is extremely fragile and will break from the simplest thing: if someone clicks on 'revert' after changing the name of the raster layer, for example. (yes, i do realize i wrote most of this code). because of the classmapper code, it is very easy to have a different dialog box open depending on what kind of layer it is. currently, it is set to open the Classifer dialog for both general Layers and RasterLayers. if there is no objection to this, i'm going to start writing a new dialog box for raster layers which will show as much information about the layer as there is. i'll also look at creating a generic properties dialog which is extended for other types of layers. that way, all information that every layer has (title, projection, etc.) can be displayed and then anything that is specific to the layer type can come after (classification, mask color selection, etc). --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From jan at intevation.de Fri Jan 21 16:59:41 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Fri, 21 Jan 2005 16:59:41 +0100 Subject: [Thuban-devel] layer properties dialog In-Reply-To: <1106322603.3712.40.camel@localhost.localdomain> References: <1106322603.3712.40.camel@localhost.localdomain> Message-ID: <20050121155941.GC31361@intevation.de> Hi Jonathan, On Fri, Jan 21, 2005 at 10:50:03AM -0500, Jonathan Coles wrote: > it was mentioned in RF#2302, the raster layer properties dialog should > have more information in it. i've been looking into this because i need > to have a place where the user can select which color to use as the > masking color (this depends on the colors used in the image, so it > should be user changable). > > one big point that stood right out, was that one dialog box is used for > all the kinds of layers. this might make sense with the point, vector, > and polygon layers since they all come from shapefiles. however, a > raster layer is completely different and should not share the same code. > the current setup is extremely fragile and will break from the simplest > thing: if someone clicks on 'revert' after changing the name of the > raster layer, for example. (yes, i do realize i wrote most of this > code). > > because of the classmapper code, it is very easy to have a different > dialog box open depending on what kind of layer it is. currently, it is > set to open the Classifer dialog for both general Layers and > RasterLayers. > > if there is no objection to this, i'm going to start writing a new > dialog box for raster layers which will show as much information about > the layer as there is. > > i'll also look at creating a generic properties dialog which is extended > for other types of layers. that way, all information that every layer > has (title, projection, etc.) can be displayed and then anything that is > specific to the layer type can come after (classification, mask color > selection, etc). that'll be just great. Note that Joey implemented already a special dialog for the WMS layers (see the wms extension). He made some changes to the Thuban core so that you can add special dialogs even from an extension. So, it shouldn't be a problem to hook in a raster-specfic dialog. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From nelson at crynwr.com Fri Jan 21 17:04:00 2005 From: nelson at crynwr.com (Russell Nelson) Date: Fri, 21 Jan 2005 11:04:00 -0500 Subject: undo? In-Reply-To: <20050121120849.GF21877@intevation.de> References: <16880.3214.456618.679937@desk.crynwr.com> <1106269404.5206.10.camel@localhost.localdomain> <20050121120849.GF21877@intevation.de> Message-ID: <16881.10224.393734.47369@desk.crynwr.com> Bernhard Reiter writes: > On Thu, Jan 20, 2005 at 08:03:24PM -0500, Jonathan Coles wrote: > > > however, i'm not sure that the whole session file should be a sequence > > of commands. if it was, the only way to get the final state of the > > session would be to run through all the commands from the beginning when > > the session is loaded. Once you have the list of commands that created a session file, then *that* is the canonical representation of the current state of the session. A dump of the current state would simply be serving as a cached copy of the state, and would not be authoritative. Whether the state should be cached or not depends on how long the commands take to execute. If the commands run quickly, keeping a cache to make the sesion load quickly would be a waste. Only after it's implemented could we make that decision. Hmmmm..... Why does it feel like I'm suggesting that Thuban be a reimplementation of GRASS? Maybe the GRASS folks got more things right than it seems? Maybe what GRASS needs is a modern front-end which works like Thuban? I hope that nobody thinks I'm criticizing Thuban -- I don't mean to. I'm just reflecting on the direction my thoughts are taking me. > Yes, the a configurable number of last executed commands should be saved > to allow undo even after a save-load operation. This is a good idea. > > also, it would further seperate the UI and Model components and allow > > much fuller tests. > > Can you elaborate how it does this? UI actions should produce a definite set of commands. Calls into Model components can be scripted using a command rather than having to run the UI. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From joey at infodrom.org Fri Jan 21 17:15:46 2005 From: joey at infodrom.org (Martin Schulze) Date: Fri, 21 Jan 2005 17:15:46 +0100 Subject: [Thuban-devel] layer properties dialog In-Reply-To: <20050121155941.GC31361@intevation.de> References: <1106322603.3712.40.camel@localhost.localdomain> <20050121155941.GC31361@intevation.de> Message-ID: <20050121161546.GN1666@finlandia.infodrom.north.de> Jan-Oliver Wagner wrote: > So, it shouldn't be a problem to hook in a raster-specfic > dialog. Yes, that's what Jonathan said. Very cool to be used not only for WMS! Regards, Joey -- Have you ever noticed that "General Public Licence" contains the word "Pub"? From bh at intevation.de Fri Jan 21 17:44:28 2005 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 21 Jan 2005 17:44:28 +0100 Subject: undo? In-Reply-To: <16881.10224.393734.47369@desk.crynwr.com> (Russell Nelson's message of "Fri, 21 Jan 2005 11:04:00 -0500") References: <16880.3214.456618.679937@desk.crynwr.com> <1106269404.5206.10.camel@localhost.localdomain> <20050121120849.GF21877@intevation.de> <16881.10224.393734.47369@desk.crynwr.com> Message-ID: Russell Nelson writes: > Bernhard Reiter writes: > > On Thu, Jan 20, 2005 at 08:03:24PM -0500, Jonathan Coles wrote: > > > > > however, i'm not sure that the whole session file should be a sequence > > > of commands. if it was, the only way to get the final state of the > > > session would be to run through all the commands from the beginning when > > > the session is loaded. > > Once you have the list of commands that created a session file, What "commands" are we talking about exactly? The menu commands for instance are subject to change between versions to an extent, and what actually do is somewhat implementation defined. Also, extensions can define new commands, yet it would be sad if that would mean you could only load a session if you have certain extensions installed even though those extensions don't really modify what information is stored in the .thuban file. > then *that* is the canonical representation of the current state of the > session. > A dump of the current state would simply be serving as a > cached copy of the state, and would not be authoritative. I think it should be the other way round. The description of the current state of the session is the only really required part of the file. Any description of earlier states, e.g. in the form of commands, should be optional. There are at least two reasons why this should be preferred: efficiency and privacy. Usually you want to load the current state and you're only rarely interested in the earlier states. If you have to reconstruct the session by repeating all the commands starting from an empty session (or some other specific state, doesn't really matter) it's going to be potentially quite inefficient, and over times it gets worse. There's a reason why CVS stores the most recent version of a file as is and diffs for earlier versions. If you store the history of the session in the .thuban file and later give that file to someone else, they can also see all the changes you made. That might give them information you did not want them to have at all. So it should at least be possible not to include the history in the .thuban file. Maybe it should not be in there by default, although that would reduce the benefits of the feature. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From cvs at intevation.de Fri Jan 21 17:58:33 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 17:58:33 +0100 (CET) Subject: bh: thuban/test postgissupport.py,1.13,1.14 Message-ID: <20050121165833.56131102C00@lists.intevation.de> Author: bh Update of /thubanrepository/thuban/test In directory doto:/tmp/cvs-serv24441/test Modified Files: postgissupport.py Log Message: (PostGISDatabase.__init__): Tweak doc-string (find_postgis_sql): Update for postgis-1.0.0-rc1, which uses a different name for the initialization SQL file. Index: postgissupport.py =================================================================== RCS file: /thubanrepository/thuban/test/postgissupport.py,v retrieving revision 1.13 retrieving revision 1.14 diff -u -d -r1.13 -r1.14 --- postgissupport.py 16 Dec 2004 15:18:57 -0000 1.13 +++ postgissupport.py 21 Jan 2005 16:58:31 -0000 1.14 @@ -1,4 +1,4 @@ -# Copyright (C) 2003, 2004 by Intevation GmbH +# Copyright (C) 2003, 2004, 2005 by Intevation GmbH # Authors: # Bernhard Herzog # @@ -396,8 +396,8 @@ server -- The PostgreSQLServer instance containing the database - postgis_sql -- Filename of the postgis.sql file with the - postgis initialization code + postgis_sql -- Filename of the sql file with the postgis + initialization code dbname -- The name of the database @@ -508,10 +508,12 @@ $bindir/../share/postgresql/. Furthermore, different versions of postgis place the file in - slightly different locations. For instance: + slightly different locations or may even use different names. For + instance: postgis 0.7.5 $datadir/contrib/postgis.sql postgis 0.8.1 $datadir/postgis.sql + postgis 1.0.0-rc1 $datadir/lwpostgis.sql To support both versions, we look in both places and return the first one found (looking under contrib first). If the file is not @@ -520,7 +522,8 @@ bindir = run_config_script("pg_config --bindir").strip() datadir = os.path.join(bindir, "..", "share", "postgresql") for filename in [os.path.join(datadir, "contrib", "postgis.sql"), - os.path.join(datadir, "postgis.sql")]: + os.path.join(datadir, "postgis.sql"), + os.path.join(datadir, "lwpostgis.sql")]: if os.path.exists(filename): return filename From cvs at intevation.de Fri Jan 21 17:58:33 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Fri, 21 Jan 2005 17:58:33 +0100 (CET) Subject: bh: thuban ChangeLog,1.769,1.770 Message-ID: <20050121165833.5F844102C01@lists.intevation.de> Author: bh Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv24441 Modified Files: ChangeLog Log Message: (PostGISDatabase.__init__): Tweak doc-string (find_postgis_sql): Update for postgis-1.0.0-rc1, which uses a different name for the initialization SQL file. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.769 retrieving revision 1.770 diff -u -d -r1.769 -r1.770 --- ChangeLog 21 Jan 2005 14:25:25 -0000 1.769 +++ ChangeLog 21 Jan 2005 16:58:31 -0000 1.770 @@ -1,3 +1,10 @@ +2005-01-21 Bernhard Herzog + + * test/postgissupport.py (PostGISDatabase.__init__): Tweak + doc-string + (find_postgis_sql): Update for postgis-1.0.0-rc1, which uses a + different name for the initialization SQL file. + 2005-01-21 Jonathan Coles * Thuban/UI/baserenderer.py (proj_params_to_str): New. Takes From dcalvelo at minag.gob.pe Fri Jan 21 20:46:32 2005 From: dcalvelo at minag.gob.pe (Daniel Calvelo Aros) Date: Fri, 21 Jan 2005 14:46:32 -0500 Subject: MacOSX status and wx 2.5 In-Reply-To: <20050121120402.GD21877@intevation.de> References: <20050120114517.19A16102BDC@lists.intevation.de> <41F04F5F.8030706@noaa.gov> <20050121120402.GD21877@intevation.de> Message-ID: <20050121194129.M65100@minag.gob.pe> From: Bernhard Reiter > On Thu, Jan 20, 2005 at 04:39:59PM -0800, Chris Barker wrote: > > cvs at intevation.de wrote: > > > > >+ # Testing showed this is needed with current wx 2.4. > > >versions + # on MacOSX to guarantee that it is called at > > >all. > > > > This brings up a question for me: > > > > What is the status of Thuban on OS-X? > > I think it is up and running with some bugs. > Lorenzo has made nice packages. > See thuban-list and > http://thuban.intevation.org/download.html#bin_macosx Chris, I highly recommend trying out Lorenzo's package. It IS usable, as long as you don't fiddle with the docking legend. If you undock and redock it, the scrollbar works. Don't resize it, since it doesn't rescale when docking, and don't use the sash. The rest of the system seems stable. I don't have data to reproduce the classification error Lorenzo notes. > > What are the plans for updating to wxPython 2.5.* ? > > We like to do it for CVS HEAD, but currently nobody has put in the time. > So all help is welcome. > > > These two are intricately connected, because wxPython 2.4.* is really > > next to worthless on OS-X. > > I cannot say, from what Daniel and Lorenzo write, > it Thuban might actually be usable despite some issues with wx 2.4.x. Affirmative. From Chris.Barker at noaa.gov Fri Jan 21 21:32:18 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri, 21 Jan 2005 12:32:18 -0800 Subject: MacOSX status and wx 2.5 In-Reply-To: <20050121194129.M65100@minag.gob.pe> References: <20050120114517.19A16102BDC@lists.intevation.de> <41F04F5F.8030706@noaa.gov> <20050121120402.GD21877@intevation.de> <20050121194129.M65100@minag.gob.pe> Message-ID: <41F166D2.9000506@noaa.gov> Daniel Calvelo Aros wrote: > Chris, I highly recommend trying out Lorenzo's package. It IS usable, as long > as you don't fiddle with the docking legend. If you undock and redock it, the > scrollbar works. Don't resize it, since it doesn't rescale when docking, and > don't use the sash. The rest of the system seems stable. I don't have data to > reproduce the classification error Lorenzo notes. This sounds like a classic case of "usable", for some value of usable. But it also sounds kind of bug-ridden, in a way that may well be fixed with newer versions. A LOT of work has been done for OS-X in the 2.5 series. I like a lot of what 2.5.* has to offer on Linux, but on OS-X it is a great leap forward. Early on, I had problems with 2.4.* on OS-X, particularly with buttons in Sizers. 5.5.1 was so much better that I haven't looked back. Besides, I like a lot of the 2.5 features on other platforms anyway. >>>What are the plans for updating to wxPython 2.5.* ? >> >>We like to do it for CVS HEAD, but currently nobody has put in the time. >>So all help is welcome. Would the next step be a version that works on both 2.4.* and 2.5.* ? I'd recommend against that, as 2.5 has some nice additions. However, there may be some value in having a "works on both" version during the transition. By the way, the new wxversion module makes this transition MUCH easier! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From jonathan at jpcoles.com Sat Jan 22 00:09:00 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Fri, 21 Jan 2005 18:09:00 -0500 Subject: bounding boxes Message-ID: <1106348941.3272.9.camel@localhost.localdomain> do all layers have bounding boxes? i would think so, but i just wanted to check. if so, what are people's thoughts on adding BoundingBox and LatLongBoundingBox into BaseLayer? both functions exist in Layer, RasterLayer, and wmsLayer, and it would be nice to be able to assume that all layers have these functions implemented in some way. i'm asking because i'd like to make the bounding boxes standard in the properties dialog. in the same vein, i've added a funtion called Type() in BaseLayer which returns a string representing the type of the layer. For instance, "Unknown", "Image", or whatever kind of shape layer it is. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From thuban-bugs at intevation.de Sat Jan 22 10:18:42 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Sat, 22 Jan 2005 10:18:42 +0100 (CET) Subject: [bug #2928] (thuban) update link to free worlddata to link 0.2 Message-ID: <20050122091842.9991C102BF6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2928 ------------------------------------------------------------------------- Subject: update link to free worlddata to link 0.2 The download pages links to an old version of the free worlddata 0.1, there is a 0.2 available. Also the rpms for the world data are not linked. -------------------------------------------- Managed by Request Tracker From thuban-bugs at intevation.de Sat Jan 22 10:20:34 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Sat, 22 Jan 2005 10:20:34 +0100 (CET) Subject: [bug #2929] (thuban) Better build dependencies Message-ID: <20050122092034.79F9E102BF5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2929 ------------------------------------------------------------------------- Subject: Better build dependencies Somehow the build dependencies on the download page for the sources are not really that helpful nor explicit. -------------------------------------------- Managed by Request Tracker From thuban-bugs at intevation.de Sat Jan 22 15:23:21 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Sat, 22 Jan 2005 15:23:21 +0100 (CET) Subject: [bug #2930] (thuban) tests fail badly when Data with iceland is missing. Message-ID: <20050122142321.DE0C8102BF5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2930 ------------------------------------------------------------------------- Subject: tests fail badly when Data with iceland is missing. Thuban-1.0.1 make cd test python runtests.py you get a huge bunch of errors with lines like: self.this = apply(dbflibc.new_DBFFile,args) IOError: new_DBFFile failed There should be a better test if the data is available. -------------------------------------------- Managed by Request Tracker From bernhard at intevation.de Sat Jan 22 16:25:59 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 22 Jan 2005 16:25:59 +0100 Subject: Experimental Mandrake 10.0 package Message-ID: <20050122152559.GB11811@intevation.de> http://ftp.intevation.de/users/bernhard/thuban/mandrake/ Placed some experimental Mandrake 10.0 i586 packages there. Had no timte to download all the dependencies for gdal, so if someone knows a good gdal package build for Mandrake, let us all know. Bernhard -- 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) From bernhard at intevation.de Sat Jan 22 19:20:32 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 22 Jan 2005 19:20:32 +0100 Subject: Experimental Mandrake 10.0 package In-Reply-To: <20050122152559.GB11811@intevation.de> References: <20050122152559.GB11811@intevation.de> Message-ID: <20050122182032.GB14817@intevation.de> On Sat, Jan 22, 2005 at 04:25:59PM +0100, Bernhard Reiter wrote: > http://ftp.intevation.de/users/bernhard/thuban/mandrake/ > Placed some experimental Mandrake 10.0 i586 packages there. > > Had no timte to download all the dependencies for gdal, > so if someone knows a good gdal package build for Mandrake, > let us all know. Playing around with projections I still can manage to get more encoding to ascii problems. The more I think about it, the more I believe that changing the default encoding in site.py for the python installation might be the better fix for this. 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/20050122/dec354f9/attachment.bin From bh at intevation.de Sat Jan 22 19:25:15 2005 From: bh at intevation.de (Bernhard Herzog) Date: Sat, 22 Jan 2005 19:25:15 +0100 Subject: Experimental Mandrake 10.0 package In-Reply-To: <20050122152559.GB11811@intevation.de> (Bernhard Reiter's message of "Sat, 22 Jan 2005 16:25:59 +0100") References: <20050122152559.GB11811@intevation.de> Message-ID: Bernhard Reiter writes: > http://ftp.intevation.de/users/bernhard/thuban/mandrake/ > Placed some experimental Mandrake 10.0 i586 packages there. Why is there a shapelib RPM? It shouldn't be necessary for Thuban. Thuban contains a copy of part of shapelib. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From thuban-bugs at intevation.de Sat Jan 22 19:28:57 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Sat, 22 Jan 2005 19:28:57 +0100 (CET) Subject: [bug #2931] (thuban) Thuban 1.0.1mdk crashes X-Server with Raster data: signal 11 Message-ID: <20050122182857.01DCD102BF5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2931 ------------------------------------------------------------------------- Subject: Thuban 1.0.1mdk crashes X-Server with Raster data: signal 11 Operating System: GNU/Linux, Mandrake 10.0 Thuban version: 1.0.1, Mdk from Bernhard wxPython version: 2.4.2.4 Python version: other, 2.3.3-2 PySQLite version: other, python-sqlite-1.0.1-1mdk SQLite version: 2.8.6 GDAL version: CVS, current proj version: CVS, current Using the new Thuban-1.0.1-1.mdk100.1.src.rpm, SHAPE files now work but reading GeoTIFF fails: - black map - when using right mouse button, clicking on 'Projection': X-Server RESET! Fatal server error: Caught signal 11. Server aborting Sigh. As being ignorant: does Thuban use my GDAL/PROJ libraries as installed from CVS? Markus -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Sun Jan 23 11:07:13 2005 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sun, 23 Jan 2005 11:07:13 +0100 (CET) Subject: [Thuban-list] tests for Daniel Cavelo's classifiers In-Reply-To: <20050121120056.GC21877@intevation.de> References: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> <20050120204836.GA20846@intevation.de> <20050121021357.M66533@minag.gob.pe> <20050121120056.GC21877@intevation.de> Message-ID: <32779.83.134.238.143.1106474833.squirrel@vivegnulinux.homelinux.org> On Fri, January 21, 2005 13:00, Bernhard Reiter said: > On Thu, Jan 20, 2005 at 09:21:52PM -0500, Daniel Calvelo Aros wrote: >> From: Bernhard Reiter >> > >> > Daniel: Would it be okay for you to assign the copyrights to us? >> > Our idea is to keep them all in one place. >> >> I thought I added myname to the "Authors:" part of the comment header... > > I did see that in one file. > The new files in Moritz' set did not include headers at all. Sorry Daniel, I must have erased them when repackaging the patch. Moritz From mlennert at club.worldonline.be Sun Jan 23 11:13:17 2005 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sun, 23 Jan 2005 11:13:17 +0100 (CET) Subject: [Thuban-list] tests for Daniel Cavelo's classifiers In-Reply-To: <20050120204836.GA20846@intevation.de> References: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> <20050120204836.GA20846@intevation.de> Message-ID: <32792.83.134.238.143.1106475197.squirrel@vivegnulinux.homelinux.org> On Thu, January 20, 2005 21:48, Bernhard Reiter said: > Hi Moritz, > > On Tue, Jan 18, 2005 at 10:19:24AM +0100, Moritz Lennert wrote: >> > So first step would be to apply the patch for HEAD. >> >> Attached is a version of the patches that applies cleanly to current >> (20050118 >> at ca. 1am) CVS HEAD, plus the necessary additional files that can just be >> dropped in. This version of the patch also includes two bug fixes, one to >> the >> discont algorithm and one general one, dealing with no data situations. > > I take it the fixes are for the new code itself, > otherwise you could extract them into smaller patches. > BTW: the -N switch to diff should even give you diffs of the new files, > which might be easier to packages. Yes, the fixes (by Daniel) are for the new code itself. >> > Next, one should think about what are the most important tests >> > and add them to the directory test/ >> > There you can see how the other tests are made - not too difficult in >> > practice but some brain work to have them useful. >> > test_color.py is a simple one to get the idea. >> >> I haven't had time to look into this in great detail (and won't have in the >> near future), so if someone else has the opportunity to do so, that would be >> great. (I guess I'll also have to read >> http://diveintopython.org/unit_testing/index.html in order to completely >> understand the testing business.) > > No, it is quite easy: Just copy an appropriate test and start adding > one function for each method that is new in the patch. The main question I had was: should the tests only test for internal consistency of the code, or should they also check whether the algorithm works correctly, i.e. in this case whether the partition that is proposed actually is correct. The latter would then require quite a series of test cases, or ? > >> I would really appreciate if this patch could be integrated into cvs as that >> would make it possible to install with debian apt-get and have everything >> integrated... > > What we also would like to have would be a Changelog entry. > It makes it easer to understand what is going on from an overview > point of view. Daniel, do you think you could do this. Or would the original mail describing the patch (http://intevation.de/pipermail/thuban-list/2004-February/000348.html) be more or less enough ? Moritz From jan at intevation.de Mon Jan 24 09:21:45 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 24 Jan 2005 09:21:45 +0100 Subject: [Thuban-devel] Re: MacOSX status and wx 2.5 In-Reply-To: <41F166D2.9000506@noaa.gov> References: <20050120114517.19A16102BDC@lists.intevation.de> <41F04F5F.8030706@noaa.gov> <20050121120402.GD21877@intevation.de> <20050121194129.M65100@minag.gob.pe> <41F166D2.9000506@noaa.gov> Message-ID: <20050124082145.GB1272@intevation.de> On Fri, Jan 21, 2005 at 12:32:18PM -0800, Chris Barker wrote: > Would the next step be a version that works on both 2.4.* and 2.5.* ? > I'd recommend against that, as 2.5 has some nice additions. However, > there may be some value in having a "works on both" version during the > transition. I'd prefer to have it work with both, 2.4 and 2.5, for the near future. For dropping 2.4 a requirement should be the availability of 2.6. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan at intevation.de Mon Jan 24 09:30:55 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Mon, 24 Jan 2005 09:30:55 +0100 Subject: [Thuban-devel] bounding boxes In-Reply-To: <1106348941.3272.9.camel@localhost.localdomain> References: <1106348941.3272.9.camel@localhost.localdomain> Message-ID: <20050124083055.GC1272@intevation.de> On Fri, Jan 21, 2005 at 06:09:00PM -0500, Jonathan Coles wrote: > do all layers have bounding boxes? i would think so, but i just wanted > to check. if so, what are people's thoughts on adding BoundingBox and > LatLongBoundingBox into BaseLayer? both functions exist in Layer, > RasterLayer, and wmsLayer, and it would be nice to be able to assume > that all layers have these functions implemented in some way. > > i'm asking because i'd like to make the bounding boxes standard in the > properties dialog. > > in the same vein, i've added a funtion called Type() in BaseLayer which > returns a string representing the type of the layer. For instance, > "Unknown", "Image", or whatever kind of shape layer it is. can you send a patch of these proposed changes? (seems like you have already implemented it for testing :-) Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bernhard at intevation.de Mon Jan 24 09:48:56 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 24 Jan 2005 09:48:56 +0100 Subject: [Thuban-list] tests for Daniel Cavelo's classifiers In-Reply-To: <32792.83.134.238.143.1106475197.squirrel@vivegnulinux.homelinux.org> References: <32812.164.15.134.161.1106039964.squirrel@vivegnulinux.homelinux.org> <20050120204836.GA20846@intevation.de> <32792.83.134.238.143.1106475197.squirrel@vivegnulinux.homelinux.org> Message-ID: <20050124084856.GB12984@intevation.de> On Sun, Jan 23, 2005 at 11:13:17AM +0100, Moritz Lennert wrote: > The main question I had was: should the tests only test for internal > consistency of the code, or should they also check whether the algorithm works > correctly, i.e. in this case whether the partition that is proposed actually > is correct. The latter would then require quite a series of test cases, or ? Consistency of the code is the first step and an integration test would be nice, too. Of course there can always be additional testing, but having one test for each part of the code and then an integration test usually is a very good start. You then need to use common sense on what to do more. -------------- 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/20050124/00f20795/attachment.bin From jpc1870 at cs.rit.edu Sat Jan 22 21:21:31 2005 From: jpc1870 at cs.rit.edu (Jonathan Coles) Date: Sat, 22 Jan 2005 15:21:31 -0500 (EST) Subject: [Thuban-list] New Raster code in CVS In-Reply-To: <20050122181846.GA14817@intevation.de> References: <20050119195042.M58901@minag.gob.pe> <20050120113259.GC30500@intevation.de> <20050120175613.M33094@minag.gob.pe> <20050121145526.GB30778@intevation.de> <20050121165439.GC32748@intevation.de> <1106328723.3712.48.camel@localhost.localdomain> <20050122151535.GA11811@intevation.de> <20050122181846.GA14817@intevation.de> Message-ID: On Sat, 22 Jan 2005, Bernhard Reiter wrote: > On Sat, Jan 22, 2005 at 04:15:35PM +0100, Bernhard Reiter wrote: > > > why do you say that the edges are not sharp? i believe that the code i > > > checked in had masking enabled by default, so only the "good" data > > > should get drawn, which means that the projected edges of the image > > > should be perfect. if i'm mistaken please correct me, and also, if you > > > have it, send me test files. > > You could use gdal_translate to cut the island.tif in pieces. ;) > Works with other images, too. > ah, good idea! i'll try this. --jonathan =========================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com =========================================================================== From bernhard at intevation.de Mon Jan 24 09:50:54 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 24 Jan 2005 09:50:54 +0100 Subject: Experimental Mandrake 10.0 package In-Reply-To: References: <20050122152559.GB11811@intevation.de> Message-ID: <20050124085054.GC12984@intevation.de> On Sat, Jan 22, 2005 at 07:25:15PM +0100, Bernhard Herzog wrote: > Bernhard Reiter writes: > > > http://ftp.intevation.de/users/bernhard/thuban/mandrake/ > > Placed some experimental Mandrake 10.0 i586 packages there. > > Why is there a shapelib RPM? It shouldn't be necessary for Thuban. > Thuban contains a copy of part of shapelib. Strange, it did not build or install the copy properly. Me not being sure about this, in error thought I would need the external development packages and did not inquire correctly. 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/20050124/3e71924a/attachment.bin From bernhard at intevation.de Mon Jan 24 10:06:14 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 24 Jan 2005 10:06:14 +0100 Subject: Experimental Mandrake 10.0 package In-Reply-To: <20050122182032.GB14817@intevation.de> References: <20050122152559.GB11811@intevation.de> <20050122182032.GB14817@intevation.de> Message-ID: <20050124090614.GD12984@intevation.de> On Sat, Jan 22, 2005 at 07:20:32PM +0100, Bernhard Reiter wrote: > On Sat, Jan 22, 2005 at 04:25:59PM +0100, Bernhard Reiter wrote: > > http://ftp.intevation.de/users/bernhard/thuban/mandrake/ > > Placed some experimental Mandrake 10.0 i586 packages there. > > > > Had no timte to download all the dependencies for gdal, > > so if someone knows a good gdal package build for Mandrake, > > let us all know. > > Playing around with projections I still can manage to get more > encoding to ascii problems. The more I think about it, the more > I believe that changing the default encoding in site.py for the > python installation might be the better fix for this. Hmm Debian also has default encoding "ascii" and also the code for setting the default encoding in site.py not-enabled. Here is my Debian testing system: python -c 'import locale ; print locale.getdefaultlocale(), locale.getlocale(), locale.nl_langinfo(locale.CODESET)' ('de_DE', 'iso-8859-15') (None, None) ANSI_X3.4-1968 So the problems are more related to the unicode build of wxPython that Mandrake has. 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/20050124/93580f3b/attachment.bin From bh at intevation.de Mon Jan 24 10:54:51 2005 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 24 Jan 2005 10:54:51 +0100 Subject: Experimental Mandrake 10.0 package In-Reply-To: <20050124085054.GC12984@intevation.de> (Bernhard Reiter's message of "Mon, 24 Jan 2005 09:50:54 +0100") References: <20050122152559.GB11811@intevation.de> <20050124085054.GC12984@intevation.de> Message-ID: Bernhard Reiter writes: > On Sat, Jan 22, 2005 at 07:25:15PM +0100, Bernhard Herzog wrote: [Mandrake RPMs] >> Why is there a shapelib RPM? It shouldn't be necessary for Thuban. >> Thuban contains a copy of part of shapelib. > > Strange, it did not build or install the copy properly. What exactly went wrong? If you've got Lib/shapelibc.so all should be fine. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From bernhard at intevation.de Mon Jan 24 11:18:01 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 24 Jan 2005 11:18:01 +0100 Subject: Experimental Mandrake 10.0 package In-Reply-To: References: <20050122152559.GB11811@intevation.de> <20050124085054.GC12984@intevation.de> Message-ID: <20050124101801.GD24840@intevation.de> On Mon, Jan 24, 2005 at 10:54:51AM +0100, Bernhard Herzog wrote: > Bernhard Reiter writes: > > > On Sat, Jan 22, 2005 at 07:25:15PM +0100, Bernhard Herzog wrote: > [Mandrake RPMs] > >> Why is there a shapelib RPM? It shouldn't be necessary for Thuban. > >> Thuban contains a copy of part of shapelib. > > > > Strange, it did not build or install the copy properly. > > What exactly went wrong? I don't know. :/ > If you've got Lib/shapelibc.so all should be fine. -------------- 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/20050124/ca68f8e0/attachment.bin From cvs at intevation.de Mon Jan 24 12:19:55 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 24 Jan 2005 12:19:55 +0100 (CET) Subject: bh: thuban/Thuban/UI viewport.py, 1.19, 1.20 mainwindow.py, 1.140, 1.141 Message-ID: <20050124111955.5BA33102BCB@lists.intevation.de> Author: bh Update of /thubanrepository/thuban/Thuban/UI In directory doto:/tmp/cvs-serv12794/Thuban/UI Modified Files: viewport.py mainwindow.py Log Message: Rework the status bar updates a bit to make sure the message about the projections is produced at the right times. * Thuban/UI/mainwindow.py (MainWindow.update_status_bar_messages): New class variable with messages that may require a status bar update. (MainWindow.view_position_changed) (MainWindow.update_status_bar): Rename from view_position_changed to update_status_bar. It's meaning has changed now that it may also generate messages about problems with projection settings. (MainWindow.__init__): Use the new update_status_bar_messages class variable to subscribe update_status_bar (MainWindow.set_position_text): Update doc-string. This method has to be renamed at some point. See doc-string and comments. (MainWindow.OnClose): Unsubscribe update_status_bar from all messages in update_status_bar_messages * Thuban/UI/viewport.py (ViewPort.forwarded_map_messages): New class attribute. map messages to be forwarded by the viewport. (ViewPort._subscribe_map, ViewPort._unsubscribe_map): (un)subscribe the messages in forwarded_map_messages Index: viewport.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/viewport.py,v retrieving revision 1.19 retrieving revision 1.20 diff -u -d -r1.19 -r1.20 --- viewport.py 18 Nov 2004 20:17:43 -0000 1.19 +++ viewport.py 24 Jan 2005 11:19:53 -0000 1.20 @@ -1,4 +1,4 @@ -# Copyright (c) 2003-2004 by Intevation GmbH +# Copyright (c) 2003-2005 by Intevation GmbH # Authors: # Bernhard Herzog (2003, 2004) # Jonathan Coles (2003) @@ -20,7 +20,8 @@ from wxproj import point_in_polygon_shape, shape_centroid from Thuban.Model.messages import MAP_PROJECTION_CHANGED, \ - LAYER_PROJECTION_CHANGED, TITLE_CHANGED + LAYER_PROJECTION_CHANGED, TITLE_CHANGED, \ + MAP_LAYERS_ADDED, MAP_LAYERS_REMOVED from Thuban.Model.data import SHAPETYPE_POLYGON, SHAPETYPE_ARC, \ SHAPETYPE_POINT, RAW_SHAPEFILE from Thuban.Model.label import ALIGN_CENTER, ALIGN_TOP, ALIGN_BOTTOM, \ @@ -31,7 +32,7 @@ from selection import Selection from messages import LAYER_SELECTED, SHAPES_SELECTED, VIEW_POSITION, \ - SCALE_CHANGED, MAP_REPLACED + SCALE_CHANGED, MAP_REPLACED import hittest @@ -226,6 +227,13 @@ "HasSelectedShapes": "selection", "SelectedShapes": "selection"} + # Some messages are forwarded from the currently shown map. This is + # simply a list of the channels to forward. The _subscribe_map and + # _unsubscribe_map methods use this to handle the forwarding. + forwarded_map_messages = (LAYER_PROJECTION_CHANGED, TITLE_CHANGED, + MAP_PROJECTION_CHANGED, + MAP_LAYERS_ADDED, MAP_LAYERS_REMOVED) + def __init__(self, size = (400, 300)): self.size = size @@ -311,14 +319,16 @@ self.layer_projection_changed) map.Subscribe(MAP_PROJECTION_CHANGED, self.map_projection_changed) - self.subscribe_forwarding(TITLE_CHANGED, map) + for channel in self.forwarded_map_messages: + self.subscribe_forwarding(channel, map) def _unsubscribe_map(self, map): """ Internal: Unsubscribe from the messages subscribed to in _subscribe_map """ if map is not None: - self.unsubscribe_forwarding(TITLE_CHANGED, map) + for channel in self.forwarded_map_messages: + self.unsubscribe_forwarding(channel, map) map.Unsubscribe(MAP_PROJECTION_CHANGED, self.map_projection_changed) map.Unsubscribe(LAYER_PROJECTION_CHANGED, Index: mainwindow.py =================================================================== RCS file: /thubanrepository/thuban/Thuban/UI/mainwindow.py,v retrieving revision 1.140 retrieving revision 1.141 diff -u -d -r1.140 -r1.141 --- mainwindow.py 21 Jan 2005 08:31:16 -0000 1.140 +++ mainwindow.py 24 Jan 2005 11:19:53 -0000 1.141 @@ -1,4 +1,4 @@ -# Copyright (C) 2001, 2002, 2003, 2004 by Intevation GmbH +# Copyright (C) 2001, 2002, 2003, 2004, 2005 by Intevation GmbH # Authors: # Jan-Oliver Wagner # Bernhard Herzog @@ -23,7 +23,9 @@ import Thuban from Thuban import _ -from Thuban.Model.messages import TITLE_CHANGED +from Thuban.Model.messages import TITLE_CHANGED, LAYER_PROJECTION_CHANGED, \ + MAP_PROJECTION_CHANGED, MAP_LAYERS_ADDED, MAP_LAYERS_REMOVED + from Thuban.Model.session import create_empty_session from Thuban.Model.layer import Layer, RasterLayer from Thuban.Model.postgisdb import PostGISShapeStore, has_postgis_support @@ -75,6 +77,12 @@ "SelectedShapes": "canvas", } + # Messages from the canvas that may require a status bar update. + # The update_status_bar method will be subscribed to these messages. + update_status_bar_messages = (VIEW_POSITION, LAYER_PROJECTION_CHANGED, + MAP_PROJECTION_CHANGED, MAP_LAYERS_ADDED, + MAP_LAYERS_REMOVED) + def __init__(self, parent, ID, title, application, interactor, initial_message = None, size = wxSize(-1, -1)): DockFrame.__init__(self, parent, ID, title, wxDefaultPosition, size) @@ -101,11 +109,13 @@ # Create the map canvas canvas = view.MapCanvas(self, -1) - canvas.Subscribe(VIEW_POSITION, self.view_position_changed) canvas.Subscribe(SHAPES_SELECTED, self.identify_view_on_demand) self.canvas = canvas self.canvas.Subscribe(TITLE_CHANGED, self.title_changed) + for channel in self.update_status_bar_messages: + self.canvas.Subscribe(channel, self.update_status_bar) + self.SetMainWindow(self.canvas) self.SetAutoLayout(True) @@ -334,40 +344,52 @@ def get_open_dialog(self, name): return self.dialogs.get(name) - def view_position_changed(self): - """Put current position in status bar after a mouse move.""" + def update_status_bar(self, *args): + """Handler for a bunch of messages that may require a status bar update + + Currently this handles the canvas' VIEW_POSITION_CHANGED + messages as well as several messages about changes in the map + which may affect whether and how projections are used. + + These messages affect the text in the status bar in the following way: + + When VIEW_POSITION_CHANGED messages are sent and the mouse is + actually in the canvas window, display the current mouse + coordinates as defined by the canvas' CurrentPosition method. + + If there is no current position to show, check whether there is + a potential problem with the map and layer projections and + display a message about it. Otherwise the status bar will + become empty. + + The text is displayed in the status bar using the + set_position_text method. + """ + # Implementation note: We do not really have to know which + # message was sent. We can simply call the canvas' + # CurrentPosition method and if that returns a tuple, it was a + # VIEW_POSITION_CHANGED message and we have to display it. + # Otherwise it was a VIEW_POSITION_CHANGED message where the + # mouse has left the canvas or it was a message about a change + # to the map, in which case we check the projections. + # + # When changing this method, keep in mind that the + # VIEW_POSITION_CHANGED message are sent for every mouse move in + # the canvas window, that is they happen very often, so the path + # taken in that case has to be fast. + text = "" pos = self.canvas.CurrentPosition() if pos is not None: text = "(%10.10g, %10.10g)" % pos else: - text = "" - # XXX This is a hack until we find a better place for this code. - # (BER 20050120) - # BH wrote (20050120): - # this branch is only executed when the mouse - # leaves the canvas window, so it's not that often [..] - # [Here] not the right place to put this code. - # I don't have a better solution at hand, - # but the view_position_changed is only there to update - # the current position. If other information is to - # be shown in the status bar it should - # be handled in a different way and - # by other methods. - # - # The status bar widget supports some kind of stack of texts. - # maybe that can be used to distinguis - # between short-lived information such as the mouse position - # and more permanent information such as the hint - # about the projections. - map = self.canvas.Map() - for layer in map.layers: + for layer in self.canvas.Map().Layers(): bbox = layer.LatLongBoundingBox() if bbox: left, bottom, right, top = bbox if not (-180 <= left <= 180 and - -180 <= right <= 180 and - -90 <= top <= 90 and - -90 <= bottom <= 90): + -180 <= right <= 180 and + -90 <= top <= 90 and + -90 <= bottom <= 90): text = _("Select layer '%s' and pick a projection " "using Layer/Projection...") % layer.title break @@ -375,12 +397,20 @@ self.set_position_text(text) def set_position_text(self, text): - """Set the statusbar text showing the current position. + """Set the statusbar text to that created by update_status_bar By default the text is shown in field 0 of the status bar. Override this method in derived classes to put it into a different field of the statusbar. + + For historical reasons this method is called set_position_text + because at first the text was always either the current position + or the empty string. Now it can contain other messages as well. + The method will be renamed at one point. """ + # Note: If this method is renamed we should perhaps think about + # some backwards compatibility measures for projects like + # GREAT-ER which override this method. self.SetStatusText(text) def OpenOrRaiseDialog(self, name, dialog_class, *args, **kw): @@ -472,7 +502,9 @@ # FIXME: it would be better to tie the unsubscription to # wx's destroy event, but that isn't implemented for wxGTK # yet. - self.canvas.Unsubscribe(VIEW_POSITION, self.view_position_changed) + for channel in self.update_status_bar_messages: + self.canvas.Unsubscribe(channel, self.update_status_bar) + DockFrame.OnClose(self, event) for dlg in self.dialogs.values(): dlg.Destroy() From cvs at intevation.de Mon Jan 24 12:19:55 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Mon, 24 Jan 2005 12:19:55 +0100 (CET) Subject: bh: thuban ChangeLog,1.770,1.771 Message-ID: <20050124111955.64EF6102C07@lists.intevation.de> Author: bh Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv12794 Modified Files: ChangeLog Log Message: Rework the status bar updates a bit to make sure the message about the projections is produced at the right times. * Thuban/UI/mainwindow.py (MainWindow.update_status_bar_messages): New class variable with messages that may require a status bar update. (MainWindow.view_position_changed) (MainWindow.update_status_bar): Rename from view_position_changed to update_status_bar. It's meaning has changed now that it may also generate messages about problems with projection settings. (MainWindow.__init__): Use the new update_status_bar_messages class variable to subscribe update_status_bar (MainWindow.set_position_text): Update doc-string. This method has to be renamed at some point. See doc-string and comments. (MainWindow.OnClose): Unsubscribe update_status_bar from all messages in update_status_bar_messages * Thuban/UI/viewport.py (ViewPort.forwarded_map_messages): New class attribute. map messages to be forwarded by the viewport. (ViewPort._subscribe_map, ViewPort._unsubscribe_map): (un)subscribe the messages in forwarded_map_messages Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.770 retrieving revision 1.771 diff -u -d -r1.770 -r1.771 --- ChangeLog 21 Jan 2005 16:58:31 -0000 1.770 +++ ChangeLog 24 Jan 2005 11:19:53 -0000 1.771 @@ -1,3 +1,27 @@ +2005-01-24 Bernhard Herzog + + Rework the status bar updates a bit to make sure the message about + the projections is produced at the right times. + + * Thuban/UI/mainwindow.py (MainWindow.update_status_bar_messages): + New class variable with messages that may require a status bar + update. + (MainWindow.view_position_changed) + (MainWindow.update_status_bar): Rename from view_position_changed + to update_status_bar. It's meaning has changed now that it may + also generate messages about problems with projection settings. + (MainWindow.__init__): Use the new update_status_bar_messages + class variable to subscribe update_status_bar + (MainWindow.set_position_text): Update doc-string. This method + has to be renamed at some point. See doc-string and comments. + (MainWindow.OnClose): Unsubscribe update_status_bar from all + messages in update_status_bar_messages + + * Thuban/UI/viewport.py (ViewPort.forwarded_map_messages): New + class attribute. map messages to be forwarded by the viewport. + (ViewPort._subscribe_map, ViewPort._unsubscribe_map): (un)subscribe + the messages in forwarded_map_messages + 2005-01-21 Bernhard Herzog * test/postgissupport.py (PostGISDatabase.__init__): Tweak From bh at intevation.de Mon Jan 24 12:28:31 2005 From: bh at intevation.de (Bernhard Herzog) Date: Mon, 24 Jan 2005 12:28:31 +0100 Subject: russell: thuban/Thuban/UI mainwindow.py,1.137,1.138 In-Reply-To: (Bernhard Herzog's message of "Thu, 20 Jan 2005 19:33:25 +0100") References: <20050120175525.DAA02102C08@lists.intevation.de> Message-ID: Bernhard Herzog writes: > I don't have a better solution at hand, but the view_position_changed > is only there to update the current position. If other information is > to be shown in the status bar it should be handled in a different way > and by other methods. I looked at this a bit on Friday and today. It turns out that generating the position message and the projection message in the same method isn't the real problem. The actual problem is that so far the method was only subscribed to the VIEW_POSITION_CHANGED messages. Therefore it was only ever called when the user moves the mouse in the map window or when the mouse leaves that window. Those are not the times when the projection message may have to be displayed. For instance, the user may have to move the mouse into and out of the map window just to see the message. The easiest correct implementation, provided that the message as it stands now is a suitable short term approach to the problem, is to subscribe the method to some more messages and to rename it to reflect its new meaning. See the changes I just committed. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From nelson at crynwr.com Mon Jan 24 15:40:04 2005 From: nelson at crynwr.com (Russell Nelson) Date: Mon, 24 Jan 2005 09:40:04 -0500 Subject: bounding boxes In-Reply-To: <1106348941.3272.9.camel@localhost.localdomain> References: <1106348941.3272.9.camel@localhost.localdomain> Message-ID: <16885.2244.35496.566377@desk.crynwr.com> Jonathan Coles writes: > do all layers have bounding boxes? i would think so, but i just wanted > to check. if so, what are people's thoughts on adding BoundingBox and > LatLongBoundingBox into BaseLayer? both functions exist in Layer, > RasterLayer, and wmsLayer, and it would be nice to be able to assume > that all layers have these functions implemented in some way. The Terra layer won't have a small bounding box. A reasonable bounding box will be as tall as the United States and 3 degrees wide. Depending on the definition of BoundingBox, and the way it's used, I think that the best bounding box the Terra layer could return is None. -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From nelson at crynwr.com Mon Jan 24 15:43:09 2005 From: nelson at crynwr.com (Russell Nelson) Date: Mon, 24 Jan 2005 09:43:09 -0500 Subject: russell: thuban/Thuban/UI mainwindow.py,1.137,1.138 In-Reply-To: References: <20050120175525.DAA02102C08@lists.intevation.de> Message-ID: <16885.2429.620239.562132@desk.crynwr.com> Bernhard Herzog writes: > The easiest correct implementation, provided that the message as it > stands now is a suitable short term approach to the problem, is to > subscribe the method to some more messages and to rename it to reflect > its new meaning. See the changes I just committed. Well done, Bernhard! -- --My blog is at angry-economist.russnelson.com | Freedom means allowing Crynwr sells support for free software | PGPok | people to do things the 521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs. From jonathan at jpcoles.com Mon Jan 24 20:04:21 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Mon, 24 Jan 2005 14:04:21 -0500 Subject: bounding boxes In-Reply-To: <16885.2244.35496.566377@desk.crynwr.com> References: <1106348941.3272.9.camel@localhost.localdomain> <16885.2244.35496.566377@desk.crynwr.com> Message-ID: <1106593461.3331.11.camel@localhost.localdomain> Am Montag, den 24.01.2005, 09:40 -0500 schrieb Russell Nelson: > Jonathan Coles writes: > > do all layers have bounding boxes? i would think so, but i just wanted > > to check. if so, what are people's thoughts on adding BoundingBox and > > LatLongBoundingBox into BaseLayer? both functions exist in Layer, > > RasterLayer, and wmsLayer, and it would be nice to be able to assume > > that all layers have these functions implemented in some way. > > The Terra layer won't have a small bounding box. A reasonable > bounding box will be as tall as the United States and 3 degrees wide. > Depending on the definition of BoundingBox, and the way it's used, I > think that the best bounding box the Terra layer could return is None. one of the places LatLongBoundingBox() is used is when scaling the layer to fit in the window. the return value *can* be None, but real values should be returned if they exist. i think that even given the large size in your example, returning that is better than None. BoundingBox() just returns the "layer's bounding box in the intrinsic coordinate system," to quote the documentation. i would say, any real value is appropriate here. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From jonathan at jpcoles.com Mon Jan 24 20:20:48 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Mon, 24 Jan 2005 14:20:48 -0500 Subject: [Thuban-devel] bounding boxes In-Reply-To: <20050124083055.GC1272@intevation.de> References: <1106348941.3272.9.camel@localhost.localdomain> <20050124083055.GC1272@intevation.de> Message-ID: <1106594448.3331.18.camel@localhost.localdomain> Am Montag, den 24.01.2005, 09:30 +0100 schrieb Jan-Oliver Wagner: > On Fri, Jan 21, 2005 at 06:09:00PM -0500, Jonathan Coles wrote: > > do all layers have bounding boxes? i would think so, but i just wanted > > to check. if so, what are people's thoughts on adding BoundingBox and > > LatLongBoundingBox into BaseLayer? both functions exist in Layer, > > RasterLayer, and wmsLayer, and it would be nice to be able to assume > > that all layers have these functions implemented in some way. > > > > i'm asking because i'd like to make the bounding boxes standard in the > > properties dialog. > > > > in the same vein, i've added a funtion called Type() in BaseLayer which > > returns a string representing the type of the layer. For instance, > > "Unknown", "Image", or whatever kind of shape layer it is. > > can you send a patch of these proposed changes? (seems like > you have already implemented it for testing :-) i haven't actually made the bounding box changes, i've only added the Type() method. i have a series of patches to complete the work for proper masking. i'll send these in a seperate email. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From jonathan at jpcoles.com Tue Jan 25 00:04:45 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Mon, 24 Jan 2005 18:04:45 -0500 Subject: raster layer properties and mask patches Message-ID: <1106607885.6297.4.camel@localhost.localdomain> this weekends activities have resulted in the following changes: o The LayerProperties class is a base class for layer property dialog boxes to inherit from. Some basic information that all layers have is put at the top of the box, and then subclasses are allowed to add to it. This was needed for at least two reasons: 1) The Classifier class was trying to support Layer and RasterLayer, which led to bugs 2) Adding other kinds of property boxes for new layers is now easier and more consistent. o The RasterLayerProperties dialog box displays information specific to raster layers and allows the user to set which color (or index in the case of greyscale or palette-based images) should be used as a mask. This information is used by gdal when projecting the image. gdalwarp.cpp had to modified to accomodate the mask being specified in thuban. o The mask color and whether or not the mask should be used are saved in the .thuban file. o New tests to cover the changes to the model. i've attached all the patches. there may seem to be a lot, but they really only cover the above two items. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: test_load.py.patch Type: text/x-patch Size: 1722 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/test_load.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: test_baserenderer.py.patch Type: text/x-patch Size: 813 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/test_baserenderer.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: gdalwarp.cpp.patch Type: text/x-patch Size: 7633 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/gdalwarp.cpp.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: mainwindow.py.patch Type: text/x-patch Size: 773 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/mainwindow.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: classifier.py.patch Type: text/x-patch Size: 8199 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/classifier.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: baserenderer.py.patch Type: text/x-patch Size: 3199 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/baserenderer.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: save.py.patch Type: text/x-patch Size: 1611 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/save.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: load.py.patch Type: text/x-patch Size: 1325 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/load.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: layer.py.patch Type: text/x-patch Size: 3862 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/layer.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: color.py.patch Type: text/x-patch Size: 1356 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/color.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: test_layer.py.patch Type: text/x-patch Size: 3234 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/test_layer.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: test_color.py.patch Type: text/x-patch Size: 1228 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/test_color.py.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: ChangeLog.patch Type: text/x-patch Size: 3842 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/ChangeLog.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: test_save.py.patch Type: text/x-patch Size: 1240 bytes Desc: not available Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050124/44abe8a0/test_save.py.patch From jan at intevation.de Tue Jan 25 10:20:58 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue, 25 Jan 2005 10:20:58 +0100 Subject: raster layer properties and mask patches In-Reply-To: <1106607885.6297.4.camel@localhost.localdomain> References: <1106607885.6297.4.camel@localhost.localdomain> Message-ID: <20050125092058.GA3155@intevation.de> On Mon, Jan 24, 2005 at 06:04:45PM -0500, Jonathan Coles wrote: > this weekends activities have resulted in the following changes: wow, this is really cool work! > i've attached all the patches. there may seem to be a lot, but they > really only cover the above two items. the patch for baserenderer.py does not apply cleanly. Can you look into this one? Next there seem to be some commented-out source code lines, probably for testing purpose. I started reading the code with color.py and wondered why you have introduced the two functions. Shouldn't it be possible to use the hex method of Color class? Best Jan > _______________________________________________ > Thuban-devel mailing list > Thuban-devel at intevation.de > https://intevation.de/mailman/listinfo/thuban-devel -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From cvs at intevation.de Tue Jan 25 10:31:20 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 25 Jan 2005 10:31:20 +0100 (CET) Subject: jan: thuban/test postgissupport.py,1.7.2.3,1.7.2.4 Message-ID: <20050125093120.834C2102BD5@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/test In directory doto:/tmp/cvs-serv1437 Modified Files: Tag: thuban-1-0-branch postgissupport.py Log Message: Backport from HEAD: (PostGISDatabase.__init__): Tweak doc-string (find_postgis_sql): Update for postgis-1.0.0-rc1, which uses a different name for the initialization SQL file. Index: postgissupport.py =================================================================== RCS file: /thubanrepository/thuban/test/postgissupport.py,v retrieving revision 1.7.2.3 retrieving revision 1.7.2.4 diff -u -d -r1.7.2.3 -r1.7.2.4 --- postgissupport.py 16 Dec 2004 20:34:03 -0000 1.7.2.3 +++ postgissupport.py 25 Jan 2005 09:31:18 -0000 1.7.2.4 @@ -1,4 +1,4 @@ -# Copyright (C) 2003, 2004 by Intevation GmbH +# Copyright (C) 2003, 2004, 2005 by Intevation GmbH # Authors: # Bernhard Herzog # @@ -384,8 +384,8 @@ server -- The PostgreSQLServer instance containing the database - postgis_sql -- Filename of the postgis.sql file with the - postgis initialization code + postgis_sql -- Filename of the sql file with the postgis + initialization code dbname -- The name of the database @@ -478,10 +478,12 @@ $bindir/../share/postgresql/. Furthermore, different versions of postgis place the file in - slightly different locations. For instance: + slightly different locations or may even use different names. For + instance: postgis 0.7.5 $datadir/contrib/postgis.sql postgis 0.8.1 $datadir/postgis.sql + postgis 1.0.0-rc1 $datadir/lwpostgis.sql To support both versions, we look in both places and return the first one found (looking under contrib first). If the file is not @@ -490,7 +492,8 @@ bindir = run_config_script("pg_config --bindir").strip() datadir = os.path.join(bindir, "..", "share", "postgresql") for filename in [os.path.join(datadir, "contrib", "postgis.sql"), - os.path.join(datadir, "postgis.sql")]: + os.path.join(datadir, "postgis.sql"), + os.path.join(datadir, "lwpostgis.sql")]: if os.path.exists(filename): return filename From cvs at intevation.de Tue Jan 25 10:32:01 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 25 Jan 2005 10:32:01 +0100 (CET) Subject: jan: thuban ChangeLog,1.624.2.35,1.624.2.36 Message-ID: <20050125093201.D2C5A102BD5@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv1463 Modified Files: Tag: thuban-1-0-branch ChangeLog Log Message: backport from HEAD: Update for postgis-1.0.0-rc1 Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.624.2.35 retrieving revision 1.624.2.36 diff -u -d -r1.624.2.35 -r1.624.2.36 --- ChangeLog 21 Jan 2005 14:18:54 -0000 1.624.2.35 +++ ChangeLog 25 Jan 2005 09:31:59 -0000 1.624.2.36 @@ -1,3 +1,10 @@ +2005-01-25 Jan-Oliver Wagner + + * test/postgissupport.py: Backport from HEAD: + (PostGISDatabase.__init__): Tweak doc-string + (find_postgis_sql): Update for postgis-1.0.0-rc1, which uses a + different name for the initialization SQL file. + 2005-01-21 Jan-Oliver Wagner * Thuban/UI/classgen.py (GenQuantilesPanel.OnRetrieve): From thuban-bugs at intevation.de Tue Jan 25 12:03:00 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Tue, 25 Jan 2005 12:03:00 +0100 (CET) Subject: [bug #2938] (thuban) Message-ID: <20050125110300.D6814102BD5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2938 ------------------------------------------------------------------------- Subject: area field? -------------------------------------------- Managed by Request Tracker From jonathan at jpcoles.com Tue Jan 25 13:54:13 2005 From: jonathan at jpcoles.com (Jonathan Coles) Date: Tue, 25 Jan 2005 07:54:13 -0500 Subject: raster layer properties and mask patches In-Reply-To: <20050125092058.GA3155@intevation.de> References: <1106607885.6297.4.camel@localhost.localdomain> <20050125092058.GA3155@intevation.de> Message-ID: <1106657653.6297.12.camel@localhost.localdomain> Am Dienstag, den 25.01.2005, 10:20 +0100 schrieb Jan-Oliver Wagner: > On Mon, Jan 24, 2005 at 06:04:45PM -0500, Jonathan Coles wrote: > > this weekends activities have resulted in the following changes: > > wow, this is really cool work! > > > i've attached all the patches. there may seem to be a lot, but they > > really only cover the above two items. > > the patch for baserenderer.py does not apply cleanly. Can you look > into this one? i just did a clean cvs checkout and the patch applied fine. have you made modifications to your local copy? > Next there seem to be some commented-out source code lines, probably > for testing purpose. there are 3 lines of commented code. i think those should stay, if only temporarily, because they have to do with playing with how thuban calculates the region of the raster image to project. other people may want to experiment with it. > I started reading the code with color.py and wondered why you have > introduced the two functions. Shouldn't it be possible to use the hex > method of Color class? from my ChangeLog entry: Although Color.hex() performs the same function, the symmetry with hex2Color is cleaner. It may also be inappropriate to have a hex() method. by inappropriate i mean that the Color object itself shouldn't (arguably) know how to write the hex string. i remember having a discussion with bernhard h. about this 2 years ago. we obviously decided to keep it there. however, like i mention in the log, the symmetry with hex2Color is nice, and perhaps Color.hex(), if we keep it for backward compatibility, should use Color2hex to do the conversion. --jonathan -- ===================================================================== Jonathan Coles http://www.jpcoles.com jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc ===================================================================== From nhueffme at intevation.de Tue Jan 25 15:59:05 2005 From: nhueffme at intevation.de (Nina =?iso-8859-1?q?H=FCffmeyer?=) Date: Tue, 25 Jan 2005 15:59:05 +0100 Subject: Fwd: ogr extension Message-ID: <20050125145905.9A64236CE0@mail.intevation.de> Hi, I am trying to implement ogr support for Thuban as an extension. Now I got the following problem: Thuban knows three types of geometries: points, lines and polygons. In ogr, more types are known, e.g. geometry type wkbUnknown. Enabling Thuban to handle files with these geometry types would affect not only the extension but also the Thuban core (e.g. the Session Tree feature asks for the geometry type and can only handle one of the three types mentioned above). I could change the respective classes or does anybody have a better idea to imlement it without changing the core? Regards, Nina From cvs at intevation.de Tue Jan 25 17:26:32 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Tue, 25 Jan 2005 17:26:32 +0100 (CET) Subject: nhueffme: thuban/Extensions/ogr/sampleFiles - New directory Message-ID: <20050125162632.017C9100179@lists.intevation.de> Author: nhueffme Update of /thubanrepository/thuban/Extensions/ogr/sampleFiles In directory doto:/tmp/cvs-serv9478/Extensions/ogr/sampleFiles Log Message: Directory /thubanrepository/thuban/Extensions/ogr/sampleFiles added to the repository From frank.koormann at intevation.de Tue Jan 25 18:45:48 2005 From: frank.koormann at intevation.de (Frank Koormann) Date: Tue, 25 Jan 2005 18:45:48 +0100 Subject: RFC: ClassGroupPattern Message-ID: <20050125174548.GA9893@intevation.de> Hi, I just hacked in a new classification into Thuban I needed for a specific task: Instead of a single value or a range (valid for numbers) a regexp pattern can be applied (with re.match()). This might be helpful if geo-objects have to be grouped on text fields. So far I only added a new ClassGroup and hacked Thuban/Model/classification.py, Thuban/Model/load.py and the DTD. One needs a handcrafted .thuban session file to make use of the patterns. What do others think about such a classification feature? Do you need this in real life applications? Any suggestions about how this Classification could be generated by "Generate Class"? Best regards, Frank -- Frank Koormann Professional Service around Free Software (http://intevation.net/) FreeGIS Project (http://freegis.org/) From bernhard at intevation.de Tue Jan 25 23:37:21 2005 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Jan 2005 23:37:21 +0100 Subject: Experimental Mandrake 10.0 package In-Reply-To: <20050124085054.GC12984@intevation.de> References: <20050122152559.GB11811@intevation.de> <20050124085054.GC12984@intevation.de> Message-ID: <20050125223721.GA16221@intevation.de> On Mon, Jan 24, 2005 at 09:50:54AM +0100, Bernhard Reiter wrote: > On Sat, Jan 22, 2005 at 07:25:15PM +0100, Bernhard Herzog wrote: > > Bernhard Reiter writes: > > > > > http://ftp.intevation.de/users/bernhard/thuban/mandrake/ > > > Placed some experimental Mandrake 10.0 i586 packages there. > > > > Why is there a shapelib RPM? It shouldn't be necessary for Thuban. > > Thuban contains a copy of part of shapelib. Put up a new version that has no shapelib requirement, that was just a mistake on my side. It is also build with gdal, so if you have gdal installed you can use it. Note that reprojection with gdal so far did not work for me on Mandrake for unknown reason. (My personal guess is problems because of optimising compiler switches.) -------------- 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/20050125/4f0570b6/attachment.bin From thuban-bugs at intevation.de Wed Jan 26 05:54:26 2005 From: thuban-bugs at intevation.de (Request Tracker) Date: Wed, 26 Jan 2005 05:54:26 +0100 (CET) Subject: [bug #2940] (thuban) Err msg and freeze while dragging the left column border in the main app. window Message-ID: <20050126045426.E4752102C04@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2940 ------------------------------------------------------------------------- Subject: Err msg and freeze while dragging the left column border in the main app. window Operating System: MacOS, 10.3.7 Thuban version: 1.0.1 wxPython version: 2.4.2.4 Python version: 2.3.0 PySQLite version: other, 0.51 SQLite version: other, 2.8.15 GDAL version: 1.2.5 proj version: other, 4.4.9 Traceback (most recent call last): File "/Applications/Grass/Thuban 1.0.1.app/Contents/Resources/Python/site-packages/ Thuban/UI/dock.py", line 490, in _OnSashDragged AssertionError Did you compile Thuban yourself? NO If not, which binary package did you install (eg. where did you get it from)? http:// wwwamb.bologna.enea.it/forthuban/Thuban-OSX-Panther-1.0.1-3.dmg -------------------------------------------- Managed by Request Tracker From jan at intevation.de Wed Jan 26 07:11:24 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Wed, 26 Jan 2005 07:11:24 +0100 Subject: RFC: ClassGroupPattern In-Reply-To: <20050125174548.GA9893@intevation.de> References: <20050125174548.GA9893@intevation.de> Message-ID: <20050126061124.GA24465@intevation.de> On Tue, Jan 25, 2005 at 06:45:48PM +0100, Frank Koormann wrote: > I just hacked in a new classification into Thuban I needed for a > specific task: Instead of a single value or a range (valid for numbers) > a regexp pattern can be applied (with re.match()). > This might be helpful if geo-objects have to be grouped on text fields. > So far I only added a new ClassGroup and hacked Thuban/Model/classification.py, > Thuban/Model/load.py and the DTD. One needs a handcrafted .thuban > session file to make use of the patterns. > > What do others think about such a classification feature? Do you need > this in real life applications? Any suggestions about how this Classification > could be generated by "Generate Class"? can you send the patches and the handcrafted file (I guess it is for iceland) ? Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From cvs at intevation.de Wed Jan 26 09:14:57 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 26 Jan 2005 09:14:57 +0100 (CET) Subject: jan: thuban/Doc/manual thuban-manual-de.xml,1.7,1.8 Message-ID: <20050126081457.6051B102BCD@lists.intevation.de> Author: jan Update of /thubanrepository/thuban/Doc/manual In directory doto:/tmp/cvs-serv21068 Modified Files: thuban-manual-de.xml Log Message: More translations. Index: thuban-manual-de.xml =================================================================== RCS file: /thubanrepository/thuban/Doc/manual/thuban-manual-de.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -d -r1.7 -r1.8 --- thuban-manual-de.xml 14 Jan 2005 15:50:59 -0000 1.7 +++ thuban-manual-de.xml 26 Jan 2005 08:14:55 -0000 1.8 @@ -784,9 +784,10 @@
-
Object Labeling +
Objekt mit Label versehen - Objects can be labeled using the Label tool + Objekte können über das Label-Werkzeug mit Labeln versehen + werden @@ -794,13 +795,15 @@ - Label Tool + Label Werkzeug . - Clicking on an object selects that object and opens a dialog which - displays the table attributes for that object. An attribute can - be selected to be the label on the map. The label will be placed - at the center of the shape. Clicking on an object that already has - a label will remove the label. + Klickt man auf ein Objekt, so wird dies selektiert und es wird ein + Dialog geöffnet welcher dessen Attribute darstellt. + Eins der Attribute kann nun als Label für das Objekt auf der Karte + ausgewählt werden. Der Label wird dann mittif auf dem Shape + plaziert. + Klickt man auf ein Objekt welches bereits ein + Label hat, so wird dieser nun entfernt.
@@ -901,7 +904,7 @@ - The Visible tool + Das Sichtbarkeits-Werkzeug @@ -909,15 +912,15 @@ - Visible - shows the selected layer in the map if it was - hidden. + Sichtbar + sorgt dafür, dass eine vorher nicht sichtbare + Ebene nun wieder in der Karte dargestellt wird. - The Invisible tool + Das Unsichtbar-Werkzeug @@ -925,14 +928,15 @@ - Invisible - hides the selected layer in the map. + Unsichtbar + versteckt die aktuell + selektierte Ebene auf der Karte. - The Properties tool + Das Eigenschaften-Werkzeug @@ -940,23 +944,24 @@ - Properties - opens the layer's properties dialog box. - Double-clicking on a layer or a group of a layer will open the - properties dialog for that layer. + Eigenschaften + startet den Eigenschaften-Dialog für die + aktuelle Ebene. + Ein Doppel-Klick auf eine Ebene startet ebenfalls diesen Dialog. - The most used layer related actions are also available from a - popup menu. It is raised when a layer is clicked with the right mouse - button. + Die am häufigsten benötigten Aktionen zu den Ebenen sind + über ein Popup-Menü erreichbar. Es erscheint wenn Sie + mit der Maus über einer Ebene stehen und die rechten + Maustaste betätigen.
- Layer Popup Menu + Popup Menü für Ebenen @@ -965,62 +970,73 @@ - Along the bottom of the legend is the scalebar. The scalebar - will be available if there are any layers and the map has a - projection set. + Am unteren Rand der Legende befindet sich + die Maßstabsanzeige. Sie ist immer dann zu sehen wenn + für die Karte eine Projektion gesetzt ist und mindestens + eine Ebene vorhanden ist.
-
Exporting +
Exportieren - Under Windows, maps can be exported in Enhanced Metafile format + Auf dem Betriebssystem MS Windows können Karten im Enhanced Metafile Format (.wmf) - from + über - Map + Karte Export - for use in reports, presentations, or further - modification. The current map view, legend, and, if available, - scalebar are exported. Under other platforms this option is not - available. Clicking this menu item open a file selection dialog - that lets the user select a location to export the map. + erstellt werden um sie in Reports, + Präsentationen oder weitergehenden Bearbeitungen zu verwenden. + Die aktuelle Kartenansicht, Legende und, falls verfügbar, + Maßstabsanzeige werden dafür exportiert. + Auf anderen Plattformen steht dies nicht zur + Verfügung. + Wählt man diesen Menüpunkt an so wird ein + Dateiauswahldialog für die zu erstellende Exportdatei + geöffnet.
-
Printing +
Drucken - The map can be printed using + Eine Karte wird über - Map - Print - . The current map view, legend, and, if available, - scalebar are printed. A standard printing dialog will open allowing - the user to configure the printer. This dialog will differ depending - on which platform Thuban is running. + Karte + Drucken + ausgedruckt. Die aktuelle Kartenansicht, Legende und, + falls vorhanden, die Maßstabsanzeige werden gedruckt. + Es wird ein Standard-Druckdialog geöffnet der die Konfiguration + des Druckers gestattet. Dieser Druckdialog unterscheidet sich je + nachdem auf welcher Plattform Thuban ausgeführt wird.
- Layer Management + Ebenen Management -
Types of Layers +
Typen von Ebenen - There are three types of layers supported by Thuban: shape layers, - database layers and - image layers. Shape layers consist of vector based shapes with - geo-referenced coordinates. There are three types of supported - shapes: polygons, lines (arc), and points. Database layers are similar - to shape layers but loaded from a database instead of the file system. - Image layers can be any image - file format supported by the Geo-spatial Data Abstraction Library - (GDAL). The images must have geographic - coordinate data either embedded within the file or in a separate - file that is in the same directory as the image file. GeoTIFF files - work very well with Thuban and were designed specifically to be image - layers in GIS programs. + Thuban unterstützt 3 Typen von Ebenen: + Shape-Ebenen, Datenbank-Ebenen und Bild-Ebenen. + Shape-Ebenen bestehen aus vektor-basierten Objekten mit + geo-referenzierten Koordinaten. + Es werden drei Shape-Typen unterstützt: + Polygone, Linien und Punkte. + Datenbank-Ebenen sind den Shape-Ebenen ähnlich und unterscheiden + sich darin, dass die Daten aus einer Datenbank geholt werden + anstatt direkt vom Dateisystem. + Bild-Ebenen können im Prinzip alle von GDAL unterstützten Dateiformate + sein. GDAL ist eine externe Bibliothek und steht für + Geo-spatial Data Abstraction Library. + Das Bild muss Informationen zu seiner geographische Lage und + Ausdenung beinhalten, entweder direkt in die Datei eingebettet + oder als separate Datei im selben Verzeichnis wie die Bild-Datei. + GeoTIFF Dateien funktionieren sehr gut mit Thuban und sind + speziell als Bildebenen für Bild-Ebenen bei Geographischen + Informationssystemen geeignet. All actions in the From cvs at intevation.de Wed Jan 26 09:16:28 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 26 Jan 2005 09:16:28 +0100 (CET) Subject: jan: thuban ChangeLog,1.771,1.772 Message-ID: <20050126081628.391D0102BCD@lists.intevation.de> Author: jan Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv21130 Modified Files: ChangeLog Log Message: more translation on german manual Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.771 retrieving revision 1.772 diff -u -d -r1.771 -r1.772 --- ChangeLog 24 Jan 2005 11:19:53 -0000 1.771 +++ ChangeLog 26 Jan 2005 08:16:26 -0000 1.772 @@ -1,3 +1,7 @@ +2005-01-26 Jan-Oliver Wagner + + * Doc/manual/thuban-manual-de.xml: More translations. + 2005-01-24 Bernhard Herzog Rework the status bar updates a bit to make sure the message about From cvs at intevation.de Wed Jan 26 10:17:04 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 26 Jan 2005 10:17:04 +0100 (CET) Subject: nhueffme: thuban/Extensions/ogr __init__.py, 1.1, 1.2 ogrshapes.py, 1.3, 1.4 ogrstart.py, 1.2, 1.3 Message-ID: <20050126091704.04A55102BE8@lists.intevation.de> Author: nhueffme Update of /thubanrepository/thuban/Extensions/ogr In directory doto:/tmp/cvs-serv21822/Extensions/ogr Modified Files: __init__.py ogrshapes.py ogrstart.py Log Message: Ogr extension works now for shapefiles, GML files and DGN files. Files can be viewed and tables can be shown. For unknown shapetypes the identify mode does not work yet. Index: __init__.py =================================================================== RCS file: /thubanrepository/thuban/Extensions/ogr/__init__.py,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- __init__.py 8 Dec 2004 15:43:10 -0000 1.1 +++ __init__.py 26 Jan 2005 09:17:01 -0000 1.2 @@ -0,0 +1,33 @@ +# Copyright (C) 2004 by Intevation GmbH +# Authors: +# Nina Hueffmeyer +# +# This program is free software under the GPL (>=v2) +# Read the file COPYING coming with the software for details. + +__version__ = "$Revision$" +# $Source$ +# $Id$ + +# import the actual modules +from os import environ +try: + dummy = environ["DISPLAY"] + import OGR + 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 Thuban.UI.extensionregistry import ExtensionDesc, ext_registry + +ext_registry.add(ExtensionDesc( + name = 'OGRstart', + version = '0.9.0', + authors= [ 'Nina Hüffmeyer' ], + copyright = '2004 Intevation GmbH', + desc = _("Open a file supported by ogr."))) Index: ogrshapes.py =================================================================== RCS file: /thubanrepository/thuban/Extensions/ogr/ogrshapes.py,v retrieving revision 1.3 retrieving revision 1.4 diff -u -d -r1.3 -r1.4 --- ogrshapes.py 20 Dec 2004 14:13:57 -0000 1.3 +++ ogrshapes.py 26 Jan 2005 09:17:01 -0000 1.4 @@ -26,6 +26,7 @@ from Thuban.Model.data import SHAPETYPE_POLYGON, SHAPETYPE_ARC, SHAPETYPE_POINT from Thuban.Model.data import RAW_PYTHON, RAW_SHAPEFILE, RAW_WKT +SHAPETYPE_UNKNOWN = "unknown" def has_ogr_support(): """Return whether this Thuban instance supports ogr file formats @@ -39,7 +40,8 @@ # mapping from ogr-lib shapetype and table constants to our constants ogrlib_shapetypes = {ogr.wkbPolygon: SHAPETYPE_POLYGON, ogr.wkbLineString: SHAPETYPE_ARC, - ogr.wkbPoint: SHAPETYPE_POINT} + ogr.wkbPoint: SHAPETYPE_POINT, + ogr.wkbUnknown: SHAPETYPE_UNKNOWN} fieldtype_map = {ogr.OFTString: table.FIELDTYPE_STRING, ogr.OFTInteger: table.FIELDTYPE_INT, @@ -66,16 +68,28 @@ def ShapeID(self): return self.shapeid - # diese Methode funktioniert vielleicht noch nicht für andere Formate - #als shp - #(wenn ein polygon aus mehreren - # Ringen besteht o.ä., hat ein Geometry-Objekt mehr als einen - #GeometryRef().--------- def Points(self): """Return the coordinates of the shape as a list of lists of pairs""" + print "FID: %s" %(self.shapeid) + shape = [] + #spatialFilter = self.ogrlayer.GetSpatialFilter() + +# if spatialFilter is not None: + self.ogrlayer.SetSpatialFilter(None) + # feature = self.ogrlayer.GetFeature(self.shapeid) + # self.ogrlayer.SetSpatialFilter(spatialFilter) + # else: feature = self.ogrlayer.GetFeature(self.shapeid) + + if feature is None: + print "feature is none.........................." + return shape.append([]) geom = feature.GetGeometryRef() - shape = [] + + if geom is None: + print "geom is none................................" + return shape.append([]) + # if geometry object is of type point or line if geom.GetGeometryCount() == 0: points =[] @@ -83,12 +97,13 @@ x = geom.GetX(point) y = geom.GetY(point) points.append((x, y)) + print points return [points] # if geometry object is of type polygon or multipolygon for i in range(geom.GetGeometryCount()): points = [] - geometry = geom.GetGeometryRef(i) - # if geometry object is polygon + geometry = geom.GetGeometryRef(i) + # if geometry object is polygon if geometry.GetGeometryCount() == 0: for point in range(geometry.GetPointCount()): x = geometry.GetX(point) @@ -96,7 +111,7 @@ points.append((x, y)) shape.append(points) # if geometry object is of type multipolygon - else: + else: for j in range(geometry.GetGeometryCount()): points = [] subgeom = geometry.GetGeometryRef(j) @@ -105,6 +120,7 @@ y = subgeom.GetY(point) points.append((x, y)) shape.append(points) + print shape return shape def RawData(self): @@ -128,26 +144,38 @@ # session we need to compare absolute paths and it's usually # safer to always work with absolute paths. - self.filename = os.path.abspath(filename) + self.filename = filename self.layername = layername - self.ogrdatasource = ogr.Open(self.filename) + self.ogrdatasource = ogr.Open(filename) self.ogrlayer = (self.ogrdatasource).GetLayerByName(layername) - self.table = OGRTable(self.ogrdatasource, self.ogrlayer) + + driver = self.ogrdatasource.GetDriver().GetName() + if driver == 'PostgreSQL': + self.id_column = 'gid' + else: + self.id_column = 'fid' + + self.table = OGRTable(self.ogrdatasource, self.ogrlayer, self.id_column) self._open_ogrlayer(layername) def _open_ogrlayer(self, layername): self.numshapes = self.ogrlayer.GetFeatureCount() self.shapetype = self.ogrlayer.GetLayerDefn().GetGeomType() - extent = self.ogrlayer.GetExtent() + extent = self.ogrlayer.GetExtent() if extent: self.bbox = [extent[0], extent[2], extent[1], extent[3]] else: self.bbox = None - self.shapetype = ogrlib_shapetypes[self.shapetype] + if self.shapetype is not ogr.wkbUnknown: + self.shapetype = ogrlib_shapetypes[self.shapetype] + #else: + # this should be ogr.wkbUnknown, but Thuban does not know how + # to handle an unknown shapetype (e.g. Session Tree) + #self.shapetype = ogrlib_shapetypes[ogr.wkbPoint] def OGRLayer(self): """Return the OGRLayer object""" @@ -195,7 +223,10 @@ ogrlayer = self.ogrlayer left, bottom, right, top = bbox - + print "features in bbox: " + print ('Polygon((%s %s, %s %s, %s %s,%s %s, %s %s))' + %(left, bottom, left, top, right, top, + right, bottom, left, bottom)) # create a geometry which can be passed to the layer as spatial filter bboxpolygon = ogr.CreateGeometryFromWkt( ('Polygon((%s %s, %s %s, %s %s,%s %s, %s %s))' @@ -206,8 +237,10 @@ bboxpolygon.AssignSpatialReference(ogrlayer.GetSpatialRef()) ogrlayer.ResetReading() + #ogrlayer.SetSpatialFilterRect(left, bottom, right, top) ogrlayer.SetSpatialFilter(bboxpolygon) numFeatures = ogrlayer.GetFeatureCount() + print numFeatures for feature in range(numFeatures): nextFeature = ogrlayer.GetNextFeature() yield cls(ogrlayer, nextFeature.GetFID()) @@ -216,8 +249,11 @@ def AllShapes(self): """Return an iterable over the shapes in the shape store.""" - for i in xrange(self.NumShapes()): - yield OGRShape(self.ogrlayer, i) + self.ogrlayer.ResetReading() + nextFeature = self.ogrlayer.GetNextFeature() + while nextFeature is not None: + yield OGRShape(self.ogrlayer, nextFeature.GetFID()) + nextFeature = self.ogrlayer.GetNextFeature() def Shape(self, index): """Return the shape with index index""" @@ -241,7 +277,7 @@ """A Table for an ogr file """ - def __init__(self, ds, layer): + def __init__(self, ds, layer, id_column): """Initialize the OGRTable. ds should be an instance of OGRDatasource. @@ -251,10 +287,14 @@ self.datasource = ds self.layer = layer self.tablename = layer.GetName() + self.id_column = id_column # Map column names and indices to column objects. self.column_map = {} + # Map feature ids to ordinals. + self._map_ords_and_ids() + self._fetch_table_information() def _fetch_table_information(self): @@ -275,6 +315,24 @@ self.column_map[col.name] = col self.column_map[col.index] = col + def _map_ords_and_ids(self): + self.ordinals = {} + self.ids = {} + + lay = self.datasource.ExecuteSQL( + "SELECT %s from %s" + %(self.id_column, self.tablename)) + lay.ResetReading() + nextFeature = lay.GetNextFeature() + ord = 0 + while nextFeature is not None: + id = nextFeature.GetFID() + self.ordinals[ord] = id + self.ids[id] = ord + nextFeature = lay.GetNextFeature() + ord = ord + 1 + self.datasource.ReleaseResultSet(lay) + def TableName(self): """Return the name of the table, which is the name of the layer""" return self.tablename @@ -282,7 +340,7 @@ def Title(self): """Return the title of the table. - The title is currently fixed and equal to the tablename + The title is currently """ return self.tablename @@ -316,20 +374,48 @@ def RowIdToOrdinal(self, gid): """Return the row ordinal given its id""" - return self.layer.GetFeature(gid).GetFID() + if gid < 0: + return gid + else: + ord = self.ids[gid] + return ord +# lay = self.datasource.ExecuteSQL( + # "SELECT COUNT(%s) From %s where FID < %s" + # %(self.id_column, self.tablename, gid)) + # ord = lay.GetFeature(0).GetField(0) + # self.datasource.ReleaseResultSet(lay) + # return ord def RowOrdinalToId(self, num): """Return the rowid for given its ordinal""" - return self.layer.GetFeature(num).GetFID() +# lay = self.datasource.ExecuteSQL( + # "SELECT FID From %s" + # %(self.tablename)) + # for i in range(num): + # lay.GetNextFeature() + # id = lay.GetNextFeature().GetField(0) + # self.datasource.ReleaseResultSet(lay) + if num >= 0: + id = self.ordinals[num] + return id + else: + return num def ReadRowAsDict(self, row, row_is_ordinal = 0): """Return a dictionary which contains all the fields.""" + if row_is_ordinal == 1: + rowId = self.RowOrdinalToId(row) + else: + rowId = row layerdef = self.layer.GetLayerDefn() - feature = self.layer.GetFeature(row) + feature = self.layer.GetFeature(rowId) result = {} - for i in range(feature.GetFieldCount()): + for i in range(len(self.columns)): fielddef = layerdef.GetFieldDefn(i) - result[fielddef.GetName()] = feature.GetField(i) + if feature is not None: + result[self.columns[i].name] = feature.GetField(i) + else: + result[fielddef.GetName()] = None return result def ReadValue(self, row, col, row_is_ordinal = 0): @@ -383,8 +469,9 @@ else: right_template = right - query = ("SELECT FID FROM %s WHERE '%s' %s %s ORDER BY FID" - % (self.tablename,left.name, comparison, right_template)) + query = ("SELECT %s FROM %s WHERE '%s' %s %s ORDER BY FID" + % (self.id_column, self.tablename,left.name, comparison, + right_template)) lay = self.datasource.ExecuteSQL(query) result = [] @@ -393,7 +480,8 @@ if feature is None: break result.append(feature.GetField(0)) - self.datasource.ReleaseResultSet(lay) + if lay is not None: + self.datasource.ReleaseResultSet(lay) return result Index: ogrstart.py =================================================================== RCS file: /thubanrepository/thuban/Extensions/ogr/ogrstart.py,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- ogrstart.py 20 Dec 2004 14:13:57 -0000 1.2 +++ ogrstart.py 26 Jan 2005 09:17:01 -0000 1.3 @@ -20,23 +20,22 @@ from Thuban import _ from Thuban.Model.layer import Layer +from Thuban.UI.dbdialog import DBDialog # Import ogr related classes from Extensions.ogr import ogrshapes, ogrdialog +from Extensions.ogr.ogrdialog import ChooseOGRDBTableDialog def open_with_ogr(context): - '''Export data depending on the set properties. - - This is the main export funcation. + '''Open a file supported by ogr. ''' canvas = context.mainwindow.canvas - file = None map = canvas.Map() # Get the file to be opened dlg = wxFileDialog(canvas, _("Select a data file"), ".", "", - _("Shapefiles (*.shp)") + "|*.shp;*.SHP|" + + _("Shape/GML files (*.shp/*.gml)") + "|*.shp;*.gml|" + _("All Files (*.*)") + "|*.*", wxOPEN | wxMULTIPLE) @@ -45,14 +44,16 @@ for filename in filenames: title = os.path.splitext(os.path.basename(filename))[0] has_layers = map.HasLayers() - layername = title + layerDlg = ogrdialog.ChooseLayer(canvas, filename) + if layerDlg.ShowModal() == wxID_OK: + layername = layerDlg.GetLayer() try: session = context.application.Session() store = ogrshapes.OGRShapeStore(session, filename, layername) session.AddShapeStore(store) - except IOError: + except: # the layer couldn't be opened - self.RunMessageBox(("Add Layer"), + context.mainwindow.RunMessageBox(("Add Layer"), ("Can't open the file '%s'.")%filename) else: layer = Layer(title, store) @@ -64,6 +65,55 @@ context.application.SetPath("data",filename) dlg.Destroy() +def select_file_format(context): + ''' Display all available supported formats. + ''' + + canvas = context.mainwindow.canvas + file = None + map = canvas.Map() + + session = context.application.Session() + + dlg = ogrdialog.ChooseFileFormat(canvas, session) + + if dlg.ShowModal() == wxID_OK: + context.mainwindow.RunMessageBox("dialog auf", "dialog auf") + dlg.Destroy() + +def open_db(context): + ''' Open a table in a database as a layer. + ''' + + canvas = context.mainwindow.canvas + map = canvas.Map() + + session = context.application.Session() + dlg = ChooseOGRDBTableDialog(canvas, session) + + if dlg.ShowModal() == wxID_OK: + dbconn, dbtable = dlg.GetTable() + try: + # Choose the correct Interface for the database type + filename = ('PG: host=%s user=%s dbname=%s port=%s' + %(dbconn.host, dbconn.user, dbconn.dbname, dbconn.port)) + + store = ogrshapes.OGRShapeStore(session, filename, dbtable) + session.AddShapeStore(store) + + layer = Layer(dbtable, store) + + has_layers = map.HasLayers() + map.AddLayer(layer) + if not has_layers: + canvas.FitMapToWindow() + except: + # Some error occured while initializing the layer + context.mainwindow.RunMessageBox(_("Add Layer from database"), + _("Can't open the database table '%s'") + % dbtable) + dlg.Destroy() + # Thuban has named commands which can be registered in the central @@ -80,7 +130,16 @@ # find the ogr menu (create it a new if not found) ogr_menu = main_menu.FindOrInsertMenu('ogr', _('OGR')) +registry.Add(Command('select_file_format', 'Select a file format', + select_file_format, + helptext = "Select a file format supported from ogr")) + +registry.Add(Command('open_db', 'Open a layer from a database', + open_db, + helptext = "Open a layer from a database, e.g. PostGIS")) # finally bind the new command with an entry in the extensions menu ogr_menu.InsertItem('open_ogr_files') +ogr_menu.InsertItem('select_file_format') +ogr_menu.InsertItem('open_db') From cvs at intevation.de Wed Jan 26 10:17:03 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 26 Jan 2005 10:17:03 +0100 (CET) Subject: nhueffme: thuban ChangeLog,1.772,1.773 Message-ID: <20050126091703.F3282102BCD@lists.intevation.de> Author: nhueffme Update of /thubanrepository/thuban In directory doto:/tmp/cvs-serv21822 Modified Files: ChangeLog Log Message: Ogr extension works now for shapefiles, GML files and DGN files. Files can be viewed and tables can be shown. For unknown shapetypes the identify mode does not work yet. Index: ChangeLog =================================================================== RCS file: /thubanrepository/thuban/ChangeLog,v retrieving revision 1.772 retrieving revision 1.773 diff -u -d -r1.772 -r1.773 --- ChangeLog 26 Jan 2005 08:16:26 -0000 1.772 +++ ChangeLog 26 Jan 2005 09:17:01 -0000 1.773 @@ -1,3 +1,15 @@ +2005-01-26 Nina Hüffmeyer + + * Extensions/ogr/ogrshapes.py: Added two dictionaries to ShapeStore + which maps the ids and the ordinals. Fixed RowIdToOrdinal(), + RowOrdinalToId() and ReadRowAsDict(). + + * Extensions/ogr/ogrstart.py: Added menu item which opens database + layers for existing database connections. + + * Extensions/ogr/test/test_OGRShapestore.py: Fixed a message string. + + 2005-01-26 Jan-Oliver Wagner * Doc/manual/thuban-manual-de.xml: More translations. From cvs at intevation.de Wed Jan 26 10:17:04 2005 From: cvs at intevation.de (cvs@intevation.de) Date: Wed, 26 Jan 2005 10:17:04 +0100 (CET) Subject: nhueffme: thuban/Extensions/ogr/test test_OGRShapestore.py, 1.2, 1.3 Message-ID: <20050126091704.07774102BF1@lists.intevation.de> Author: nhueffme Update of /thubanrepository/thuban/Extensions/ogr/test In directory doto:/tmp/cvs-serv21822/Extensions/ogr/test Modified Files: test_OGRShapestore.py Log Message: Ogr extension works now for shapefiles, GML files and DGN files. Files can be viewed and tables can be shown. For unknown shapetypes the identify mode does not work yet. Index: test_OGRShapestore.py =================================================================== RCS file: /thubanrepository/thuban/Extensions/ogr/test/test_OGRShapestore.py,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- test_OGRShapestore.py 20 Dec 2004 14:13:57 -0000 1.2 +++ test_OGRShapestore.py 26 Jan 2005 09:17:01 -0000 1.3 @@ -43,7 +43,7 @@ def skip_if_no_ogr(): if ogr is None: - raise support.SkipTest("Can't run ogr tests because ogr counldn't be imported.") + raise support.SkipTest("Can't run ogr tests because ogr couldn't be imported.") class TestOGRShapeStore(unittest.TestCase, support.FloatComparisonMixin): From frank.koormann at intevation.de Wed Jan 26 11:16:13 2005 From: frank.koormann at intevation.de (Frank Koormann) Date: Wed, 26 Jan 2005 11:16:13 +0100 Subject: RFC: ClassGroupPattern In-Reply-To: <20050126061124.GA24465@intevation.de> References: <20050125174548.GA9893@intevation.de> <20050126061124.GA24465@intevation.de> Message-ID: <20050126101613.GA31172@intevation.de> * Jan-Oliver Wagner [050126 07:11]: > On Tue, Jan 25, 2005 at 06:45:48PM +0100, Frank Koormann wrote: > > I just hacked in a new classification into Thuban I needed for a > > specific task: Instead of a single value or a range (valid for numbers) > > a regexp pattern can be applied (with re.match()). > > can you send the patches and the handcrafted file (I guess it is for > iceland) ? No, the Thuban iceland sample layers aren't the ones I usually work with ;) However, I have prepared a sample based on iceland: Group the cultural landmarks by CPTLABEL: A-M and N-Z. Search for "clpattern" in the file. I attached the session file and the patch (now including also Thuban/Model/save.py) Regards, Frank -- Frank Koormann Professional Service around Free Software (http://intevation.net/) FreeGIS Project (http://freegis.org/) -------------- next part -------------- Index: Resources/XML/thuban-1.1.dtd =================================================================== RCS file: /thubanrepository/thuban/Resources/XML/thuban-1.1.dtd,v retrieving revision 1.2 diff -u -3 -p -r1.2 thuban-1.1.dtd --- Resources/XML/thuban-1.1.dtd 3 Oct 2004 20:38:54 -0000 1.2 +++ Resources/XML/thuban-1.1.dtd 26 Jan 2005 09:14:01 -0000 @@ -173,7 +173,7 @@ identify the version of the file format. - + @@ -181,6 +181,7 @@ identify the version of the file format. + @@ -196,6 +197,9 @@ identify the version of the file format. + + +