From bwindridge at gmail.com  Mon Oct  2 00:58:01 2006
From: bwindridge at gmail.com (Barry Windridge)
Date: Mon, 2 Oct 2006 09:58:01 +1100
Subject: Fwd: Spatial selection Tools and Table Enhancements
In-Reply-To: <ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<200609270911.31349.bernhard@intevation.de>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
Message-ID: <ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>

---------- Forwarded message ----------
From: Barry Windridge <bwindridge at gmail.com>
Date: Oct 2, 2006 9:56 AM
Subject: Re: Spatial selection Tools and Table Enhancements
To: Bernhard Reiter <bernhard at intevation.de>


Hi Bernhard

> thanks a lot for your contribution!
> This looks like you did a bug chunk of good work!
> Of course this also takes a while to review so bear with us here.
> I also have to think about how to handle your contribution
> in the best way. Two things are on my mind:
>
> a) How to best release it as Free Software.
> Ideally we (means Intevation) would be interested
> in getting a copyright assignment from you (like with any contributor)
> to be able to completely publish Thuban as Free Software and legally
> maintain it. E.g. when we might consider going to GPLV v3 when it comes
> out or to LGPL at some point.
> Is that something you find worth considering?
> Of course we will keep your author name in the files, getting you full credit.
> Currently they do not have a license statement.

My intentions is that the contributions are be freely available and to
be used in Thuban. Is there something formal that I am supposed to do
to achieve this?


> b) How to quality control.
> In the earlier days we were working much more intensively on Thuban.
> During this time we made it a ground rule to have all changes be double
> checked, enhancements thoroughly discussed, tests
> and documentation being written before committing to our repository.
>
> When intensity dropped this turned out to be not feasable, because turnaround
> times were getting quite long. I believe it is more important to take up
> good additions and have less quality control, but show some progress even
> when there are bugs to attract more users and developers.
>
> What do you prefer?
> If we try to be stricter, it will prove your code and Thuban in general,
> but it also will take a lot longer and might be potentially frustrating for
> you.

I have no objections to them going out withoug full quality checking,
however I don't think that they should go out without some checking!

The spatial features I submitted last week were submitted for
comment/checking - I don't think they are ready to go out yet. I am
still lerning about Thuban and even if the code I have submitted,
proves to have no obivious bugs (unlikely!), the code and user
interface needs to be tidied up before it is released.

Can you detail for me how you would see 'early release' working - what
level of checking would code recieve?

I would be interested in hearing about the history of Thuban - why did
you (intervation) start it and why has the intensity of development
been reduced. Where do you want it to go in the future?


> > Select by graphics tools that I have previousely posted have been
> > fixed to handle multi-part shapes.

I should also point out that the select by graphics tools submitted on
the 24 Sept also fixes the problem that the original code had with the
user drawing a polygon that had concave parts.

> Just to be double sure: I understand that this supercedes
> the code you have posted in "Previous/Next Extents Tool" on the 8th,
> because it is included in tools2.zip.

The code for the Previous/Next Extents Tool" should be the same as the
original version. Unitl now, I have not had the facility to keep
changes of individual version on my onw computer - What I submitted on
the 24 is the accumulated changes I have made - plus updating the
files to the latest version of the Thuban head revision.

> > Logic added to make a selection a property of a layer, so that
> > multiple layers can have selections simultaneously.
>
> You have added quite a few enhancements on a per layer basis.
> What are the use cases that you have in mind for this?
> I am wondering if this affect usability of Thuban for users
> that could potentially get confused when they have a selection per layer.

I am used to using GIS software that can maintian selections on
multiple layers. I assumed this was just basic functionality.

Apart from that, you need to be able to maintain selections on at
least two layers to do useful spatial selections using one layer to
select features from another layer. I guess for a simple layer on
layer selection, you could clear the selection used to make the new
selection - but making this the normal behaviou would severely limit
the flexibility of the feature.

Allowing the user to choose how selections are highlighted on
different layers gives the user a mechanism to differentiate
selections made on different layers.

I think that the other changes on a layer basis were only to support
and enhance the ability to make selections on a layer.


> As Didrik has pointed out,
> to make it easier to test your code, a patch against trunk would be best.
> If you work on a checkout of Thuban, svn diff -u will just produce this.

I have just replied to Didrik's email, but I don't think I included
the devel-list in my reply - so it is duplicated below:



> I would also help to have one issue in the patch tracker on wald
> per feature, as it enables to discuss and look as one change at a time.

Until now I have not had a local SVN repository to enable me to keep
track of my own versions - and as far I am aware I the cope I have
submitted previousely has not been added to wald, so I have simple
kept a local version that I have made cummulative changes to - hence
you have got everything when I made a posting.

> You can also use an svn branch if you like.
> Just register on wald, and email me your id so I can upgrade your priviledges.

My Wald login is: barryw


> Best Regards,
> Bernhard
>
> --
> Managing Director - Owner, www.intevation.net       (Free Software Company)
> Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
> www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
>
>
> _______________________________________________
> Thuban-devel mailing list
> Thuban-devel at intevation.de
> https://intevation.de/mailman/listinfo/thuban-devel
>
>
>
>



From bernhard at intevation.de  Mon Oct  2 18:12:27 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 2 Oct 2006 18:12:27 +0200
Subject: Barry on Wald
In-Reply-To: <ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
	<ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
Message-ID: <200610021812.28218.bernhard@intevation.de>

Barry,

On Monday 02 October 2006 00:58, Barry Windridge wrote:
> > I would also help to have one issue in the patch tracker on wald
> > per feature, as it enables to discuss and look as one change at a time.
>
> Until now I have not had a local SVN repository to enable me to keep
> track of my own versions - and as far I am aware I the cope I have
> submitted previousely has not been added to wald, so I have simple
> kept a local version that I have made cummulative changes to - hence
> you have got everything when I made a posting.
>
> > You can also use an svn branch if you like.
> > Just register on wald, and email me your id so I can upgrade your
> > priviledges.
>
> My Wald login is: barryw

I have upgraded you to "Senior Developer", please coordinate 
on the list before doing major things.

Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20061002/d674641b/attachment.bin

From bernhard at intevation.de  Mon Oct  2 18:16:02 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 2 Oct 2006 18:16:02 +0200
Subject: Fwd: Spatial selection Tools and Table Enhancements
In-Reply-To: <ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
	<ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
Message-ID: <200610021816.03525.bernhard@intevation.de>

Barry, I will answer most of your post tomorrow.

First thing to make people test your code is, to make it easy for them.
If you have a branch in Wald's svn or a patch which cleanly applies
to trunk, this is easiest for most other developers.

Next could be inclusion into a development quality release.
Currenlty we as a group aim to get 1.2.0 out with the
feature of wx2.6 support and python 2.4 compatibility.
This will enable a new Thuban package in Debian.

Bernhard

On Monday 02 October 2006 00:58, Barry Windridge wrote:
> ---------- Forwarded message ----------
> From: Barry Windridge <bwindridge at gmail.com>
> Date: Oct 2, 2006 9:56 AM
> Subject: Re: Spatial selection Tools and Table Enhancements
> To: Bernhard Reiter <bernhard at intevation.de>
>
>
> Hi 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/20061002/6605a6fc/attachment.bin

From bernhard at intevation.de  Tue Oct  3 22:53:04 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Oct 2006 22:53:04 +0200
Subject: Contributing code (was: Spatial selection Tools and Table
	Enhancements)
In-Reply-To: <ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
	<ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
Message-ID: <200610032253.09029.bernhard@intevation.de>

On Monday 02 October 2006 00:58, Barry Windridge wrote:
> > a) How to best release it as Free Software.
> > Ideally we (means Intevation) would be interested
> > in getting a copyright assignment from you (like with any contributor)
> > to be able to completely publish Thuban as Free Software and legally
> > maintain it. E.g. when we might consider going to GPLV v3 when it comes
> > out or to LGPL at some point.
> > Is that something you find worth considering?
> > Of course we will keep your author name in the files, getting you full
> > credit. Currently they do not have a license statement.
>
> My intentions is that the contributions are be freely available and to
> be used in Thuban. Is there something formal that I am supposed to do
> to achieve this?

Barry,
I am not sure yet, how we can do this best.
The FSF uses a copyright assignment.
The FSFE has development something 
called a fiduciary licensing agreement (FLA)
which will also hold with European "copyright".

Where are you based?

Currently Intevation holds all "copyrights" on Thuban's code.
A while ago we were considering to transfer the copyright to the FSFE
or a similiar organisation. At that time FSFE was not ready to accept code.
For now it would be easiest to have Intevation keep the copyright,
which we later still could transfer to FSFE or so.

For the time being it would be fine to have a signed email
saying that you transfer the copyright (or exclusive exploitation rights)
of your Thuban contributions
to Intevation for the purpose that we publish it as Free Software.
Intevation will grant you a single usage right back so you can do 
with the code whatever you like.

Didrik, best would be if you could also send such an email.
Would you be willing to?

Regards,
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/20061003/2d7f696c/attachment.bin

From bernhard at intevation.de  Tue Oct  3 23:18:21 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Oct 2006 23:18:21 +0200
Subject: Thuban's history (was: Spatial selection Tools and Table Enhancements)
In-Reply-To: <ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
	<ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
Message-ID: <200610032318.26639.bernhard@intevation.de>

On Monday 02 October 2006 00:58, Barry Windridge wrote:
> I would be interested in hearing about the history of Thuban - why did
> you (intervation) start it and why has the intensity of development
> been reduced. Where do you want it to go in the future?

Thuban was started by Intevation in need for a customer project: 
A scientific tool called GREAT-ER.

Based on our experience as founders of www.freegis.org 
we knew that there was no interactive visualisation tool for geographic data.
In addition we wanted it to be modern, crossplattform, high quality and 
able to run on a complete Free Software stack.
The idea was to leave complicated data processing to heavier GIS,
but provide a responsive frontend to the data and its exploration.
These are unique qualities, way back and still today.

QGIS did not exist when we started Thuban. It was also based on Qt which
was non-free on Windows and aimed to be a full-blown GIS.
Jump and uDig are based on Java which Free Software stack is just now 
approaching a workable state.

We choose a high level dynamic programming language, because the algorithms
are more important for speed and easier designed using such a language.
We kept strict testing rules, like write a test first for new funcationality.
Over 90% of the code instructions are executed when the tests are run.

Development intensity was reduced when the project was sucessfully concluded.
It seems that Thuban was ahead of its time in some areas, like choice of 
programming language. Some of its ideas are not taken up by other groups,
like the GRASS developers. Thuban's community was not growing as big
as it could. Selling native Free Software GIS application 
like Thuban was not easy has customer first discovered the webmapping 
applications. 

Thuban's future is in the hands of the active contributors.
Many technical and design choices are very solid and some even innovative.
The time for native GIS applications will come as it is much easier to write
good interfaces with native widget sets. New concepts like the 
Thuban-Map-SVG are only possible with Free Software.
Personally I would want to see Thuban being available in 
most major distributions and aquiring more features 
of interactive data exploration. One of the next ideas would be
to include an advanced buffering concept to make more remote layers and table 
data acessible.

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/20061003/a3842c20/attachment.bin

From dpinte at itae.be  Wed Oct  4 08:28:01 2006
From: dpinte at itae.be (Didrik Pinte)
Date: Wed, 04 Oct 2006 08:28:01 +0200
Subject: Contributing code (was: Spatial selection Tools and Table
	Enhancements)
In-Reply-To: <200610032253.09029.bernhard@intevation.de>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
	<ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
	<200610032253.09029.bernhard@intevation.de>
Message-ID: <1159943281.22406.21.camel@geru-itae>

Le mardi 03 octobre 2006 ? 22:53 +0200, Bernhard Reiter a ?crit :
> 
> Didrik, best would be if you could also send such an email.
> Would you be willing to?
> 
> Regards,
> Bernhard

For sure ;-)

I, Didrik Pinte, transfer the copyright (or exclusive exploitation
rights) of my Thuban contributions to Intevation for the purpose that
Intevation publish it as Free Software.

Didrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20061004/30015bff/attachment.bin

From bernhard at intevation.de  Wed Oct  4 09:17:30 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Oct 2006 09:17:30 +0200
Subject: Contributing code
In-Reply-To: <1159943281.22406.21.camel@geru-itae>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<200610032253.09029.bernhard@intevation.de>
	<1159943281.22406.21.camel@geru-itae>
Message-ID: <200610040917.31190.bernhard@intevation.de>

On Wednesday 04 October 2006 08:28, Didrik Pinte wrote:
> Le mardi 03 octobre 2006 ? 22:53 +0200, Bernhard Reiter a ?crit :
> > Didrik, best would be if you could also send such an email.
> > Would you be willing to?
> >
> > Regards,
> > Bernhard
>
> For sure ;-)
>
> I, Didrik Pinte, transfer the copyright (or exclusive exploitation
> rights) of my Thuban contributions to Intevation for the purpose that
> Intevation publish it as Free Software.

Thanks!
We are honored by your trust!
-------------- 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/20061004/fecb2f88/attachment.bin

From dpinte at itae.be  Wed Oct  4 16:18:24 2006
From: dpinte at itae.be (Didrik Pinte)
Date: Wed, 04 Oct 2006 16:18:24 +0200
Subject: swig expert
Message-ID: <1159971504.22406.54.camel@geru-itae>

Hi,

I've tried to update dbflib.i in order to support encoding conversion
using PyString_AsDecodedObject. This seems to work pretty fine now and
allow Thuban to work from scratch with any user locale and nearly any
file encoding. 

Because I'm running a Debian/sid system, I had only swig 1.3.29 and no
previous version. So, highly motivated, i've updated the dbflib.i and
shapelib.i files. It builds fine but I have a little problem when
testing the lib.

Is there any swig "expert" here that can help me to find a good solution
to debug it ?

Thanks

Didrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20061004/7bb30c10/attachment.bin

From bernhard at intevation.de  Wed Oct  4 18:31:08 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Oct 2006 18:31:08 +0200
Subject: GetLabelPosFromShape (was: update question)
In-Reply-To: <1159538198.16424.48.camel@geru-itae>
References: <1159460851.16424.9.camel@geru-itae>
	<200609282150.24523.bernhard@intevation.de>
	<1159538198.16424.48.camel@geru-itae>
Message-ID: <200610041831.09041.bernhard@intevation.de>

On Friday 29 September 2006 15:56, Didrik Pinte wrote:
> > > [1] Concerning the modification of the Thuban/UI/viewport.py file, i've
> > > just extracted some code of the LabelShapeAt method in order to be used
> > > by a more general method that will allow the user to label a complete
> > > layer by selecting a field of the associated table. See
> > > http://wald.intevation.org/tracker/index.php?func=detail&aid=121&group_
> > >id=6 &atid=108 The new method GetLabelPosForShape is at the moment in
> > > the viewport.py file but IMHO, it could be moved to the
> > > Thuban/Model/map.py file. What do you think about this ? Is there an
> > > other place that could be more appropriate ?
> >
> > Extracting methods, if you need the functionality from different places
> > in the code is the right idea.
> > (I am currently commenting offline.)
> > Without having seen the method your are extracting I cannot comment
> > on the best place. From looking at LabelShapeAt I believe it works quite
> > closly to windows coordinates which I would consider UI dependent.
> > So what is your idea in moving thi sot Model/map.py?
>
> Here is the explanation (see code below or diff in attachement). The
> piece of code in the old LabelShapeAt method concerning the label
> positioning can be used pretty easily for any shape_index and layer. So,
> i've extracted all this code to a new method called
> GetLabelPosFromShape. This new method return a(x, y, halign, valign)
> tuple when called with a layer and a shape_index.
>
> Because the new GetLabelPosFromShape is not really UI related, I would
> propose to extract it to Model/map.py.

Looking at this a bit, I believe that it is fine to move GetLabelPosFromShape
from UI to Model. Why not using Model/layer.py as the funcation seems to 
deal with data on a layer level? Maybe Model/label.py could also be considered
as it has the related function AddLabel() already.
Given the layer data it works on, I think Model/layer.py would be fine.
What speaks for Model/map.py?

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)



From bernhard at intevation.de  Wed Oct  4 18:41:03 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Oct 2006 18:41:03 +0200
Subject: How to quallity control (was: Spatial selection Tools and Table
	Enhancements)
In-Reply-To: <ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
	<ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
Message-ID: <200610041841.11870.bernhard@intevation.de>

Hi Barry,

On Monday 02 October 2006 00:58, Barry Windridge wrote:
> > b) How to quality control.
> > In the earlier days we were working much more intensively on Thuban.
> > During this time we made it a ground rule to have all changes be double
> > checked, enhancements thoroughly discussed, tests
> > and documentation being written before committing to our repository.
> >
> > When intensity dropped this turned out to be not feasable, because
> > turnaround times were getting quite long. I believe it is more important
> > to take up good additions and have less quality control, but show some
> > progress even when there are bugs to attract more users and developers.
> >
> > What do you prefer?
> > If we try to be stricter, it will prove your code and Thuban in general,
> > but it also will take a lot longer and might be potentially frustrating
> > for you.
>
> I have no objections to them going out withoug full quality checking,
> however I don't think that they should go out without some checking!

I cannot say how much peer review we can organise.
If we say that a minimal peer review should be done, e.g.
you need at least one other Thuban developer to sign off your 
changes, it might delay takeup of contributions significantly.

Another self restriction would be to insist on doc-strings,
documentation and test cases before accepting a contribution
into a release. I believe that this might be bit too much to ask.

Next point of quality would to deeply discuss the design implications
of each change, but I believe this will be to much for our current workforce
to maintain.

> The spatial features I submitted last week were submitted for
> comment/checking - I don't think they are ready to go out yet. I am
> still lerning about Thuban and even if the code I have submitted,
> proves to have no obivious bugs (unlikely!), the code and user
> interface needs to be tidied up before it is released.
>
> Can you detail for me how you would see 'early release' working - what
> level of checking would code recieve?

We can put it in an experimental branch of Thuban and do snapshot releases
of it whenever somebody things we have reached a stage were more  
users could be interested.

We could make it a requirement to have at least one positive user report
from a beta tester before taking the change up in the stable mainline.

What do you think?
Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20061004/3e67878f/attachment.bin

From bernhard at intevation.de  Wed Oct  4 18:46:14 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Oct 2006 18:46:14 +0200
Subject: Fwd: Spatial selection Tools and Table Enhancements
In-Reply-To: <ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<ebb9a320610011556t2ab86b26jbc656d0817503871@mail.gmail.com>
	<ebb9a320610011558k7168c579s27f90fbf4d14f08f@mail.gmail.com>
Message-ID: <200610041846.15097.bernhard@intevation.de>

On Monday 02 October 2006 00:58, Barry Windridge wrote:
> I should also point out that the select by graphics tools submitted on
> the 24 Sept also fixes the problem that the original code had with the
> user drawing a polygon that had concave parts.

Are you refering to the drawshape extension?
I think we did not add this one to the code because the patch
was suboptimal. We would like to a have a memory shapefile layer
which then can be saved into several formats to properly implement drawing
or editing. I have to search to email list to see what was discussed about 
this already.

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20061004/186c63be/attachment.bin

From bernhard at intevation.de  Wed Oct  4 19:41:51 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Oct 2006 19:41:51 +0200
Subject: Spatial selection Tools and Table Enhancements
In-Reply-To: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
Message-ID: <200610041941.51970.bernhard@intevation.de>

On Sunday 24 September 2006 02:06, Barry Windridge wrote:
> Attached is a zip file containing a number of enhancements to Thuban.
> The enhancements are outlined below (and hopefully reflect changes to
> the head revision on wald).


I took your code for a spin.
Here are my notes how I could make it work (if somebody else want to try it):

20061004
	Trying Barry's tools2.zip contributions.
	Unzip in a directory.
	cp -a trunk/thuban trunk/thuban-barry
	t=trunk/thuban-barry

	cp *.xpm $t/Resources/Bitmaps/
	cp -r BW\ Extensions $t/Extensions/BWExtensions

	# Model
	for f in layer load map save ; do cp $f.py $t/Thuban/Model/ ; done

	# UI
	for f in layerproperties legend mainwindow renderer selection \
 tableview  viewport view ; do cp $f.py $t/Thuban/UI/ ; done 


       # to make it a module
        cp $t/Extensions/__init__.py $t/Extensions/BWExtensions/

 	cat - >>~/.thuban/thubanstart.py << EOF

try:
    import Extensions.BWExtensions.area
    import Extensions.BWExtensions.ruler
    import Extensions.BWExtensions.PrevNextExtent
    import Extensions.BWExtensions.selectByCircle
    import Extensions.BWExtensions.selectByLayer
    import Extensions.BWExtensions.selectByPolygon
    import Extensions.BWExtensions.selectByRectangle
except Exception, x:
    print x
EOF

What I have noticed:
Area tool: When trying to select an area, the canvas goes blank for me,
so I cannot see what I want to select.
Also I cannot end the selection, I needed to click a few times on a different
part to get the map and my control back.



Style:
Using spaces in directory names is suboptimal. This is why I have changed
it to BWExtension. To make it a module an __init__.py was missing.
How did you import all these extensions?

Almost no docstrings.
No tests.


Headers:
Are missing that the files are Free Software.

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)



From bernhard at intevation.de  Wed Oct  4 20:10:43 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Oct 2006 20:10:43 +0200
Subject: Spatial selection Tools and Table Enhancements
In-Reply-To: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
Message-ID: <200610042010.44534.bernhard@intevation.de>

On Sunday 24 September 2006 02:06, Barry Windridge wrote:
> Attached is a zip file containing a number of enhancements to Thuban.

The ruler.py tool is able to measure distances which is a feature
I want for a while. :) 

I believe Frank (Koormann) already did a measurement tool,
but I do not know where he keeps it.
Frank: Is this still residing on your harddisk? ;)

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/20061004/31be4e4d/attachment.bin

From bernhard at intevation.de  Wed Oct  4 20:08:35 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Oct 2006 20:08:35 +0200
Subject: Symbol selection (was: Spatial selection Tools and Table Enhancements)
In-Reply-To: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
Message-ID: <200610042008.41995.bernhard@intevation.de>

On Sunday 24 September 2006 02:06, Barry Windridge wrote:
> d)??????look at logic to allow a choice of symbols for the display of
> points on the map.

I think Jan already had thought about this for a while.
One choice to decide is which format to use for the symbols
or only to use some more symbols which are coded in python.

So far my idea was to use a rather simple format and not something
complicated as the Thuban-MAP-SVG output option allows to use
a full blown vector drawing or layout application to do a final map.

E.g. you can use Skencil to add really nice symbols and we should
not replicate Skencils advances features within Thuban.

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/20061004/056610d2/attachment.bin

From dpinte at itae.be  Thu Oct  5 10:22:12 2006
From: dpinte at itae.be (Didrik Pinte)
Date: Thu, 05 Oct 2006 10:22:12 +0200
Subject: GetLabelPosFromShape (was: update question)
In-Reply-To: <200610041831.09041.bernhard@intevation.de>
References: <1159460851.16424.9.camel@geru-itae>
	<200609282150.24523.bernhard@intevation.de>
	<1159538198.16424.48.camel@geru-itae>
	<200610041831.09041.bernhard@intevation.de>
Message-ID: <1160036532.11697.23.camel@geru-itae>

Le mercredi 04 octobre 2006 ? 18:31 +0200, Bernhard Reiter a ?crit :
> 
> Looking at this a bit, I believe that it is fine to move GetLabelPosFromShape
> from UI to Model. Why not using Model/layer.py as the funcation seems to 
> deal with data on a layer level? Maybe Model/label.py could also be considered
> as it has the related function AddLabel() already.
> Given the layer data it works on, I think Model/layer.py would be fine.
> What speaks for Model/map.py?

I believe that you got it right concerning Model/layer.py. Nothing
speaks for Model/map.py. I suggested it without having a deep look at
all the modules of the Model package. Regarding the content, this is the
best place to add it.

If this is ok for everybody, i'll patch the code this week-end to
integrate the new method.

Didrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20061005/11cc61b5/attachment.bin

From frank.koormann at intevation.de  Thu Oct  5 11:57:21 2006
From: frank.koormann at intevation.de (Frank Koormann)
Date: Thu, 5 Oct 2006 11:57:21 +0200
Subject: Spatial selection Tools and Table Enhancements
In-Reply-To: <200610042010.44534.bernhard@intevation.de>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<200610042010.44534.bernhard@intevation.de>
Message-ID: <20061005095721.GA20947@intevation.de>

* Bernhard Reiter <bernhard at intevation.de> [061005 10:03]:
> On Sunday 24 September 2006 02:06, Barry Windridge wrote:
> > Attached is a zip file containing a number of enhancements to Thuban.
> 
> The ruler.py tool is able to measure distances which is a feature
> I want for a while. :) 
> 
> I believe Frank (Koormann) already did a measurement tool,

No, I didn't

Frank

-- 
Frank Koormann                             <frank.koormann at intevation.de>
 Professional Service around Free Software       (http://intevation.net/)
 PostGIS Support     (http://intevation.de/services/gis/postgis.en.html)



From bernhard at intevation.de  Fri Oct  6 17:08:47 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Oct 2006 17:08:47 +0200
Subject: GetLabelPosFromShape (was: update question)
In-Reply-To: <1160036532.11697.23.camel@geru-itae>
References: <1159460851.16424.9.camel@geru-itae>
	<200610041831.09041.bernhard@intevation.de>
	<1160036532.11697.23.camel@geru-itae>
Message-ID: <200610061708.51630.bernhard@intevation.de>

On Thursday 05 October 2006 10:22, Didrik Pinte wrote:
> If this is ok for everybody, i'll patch the code this week-end to
> integrate the new method.

Go for it. :)

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20061006/d85580be/attachment.bin

From bernhard at intevation.de  Fri Oct  6 17:11:56 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Oct 2006 17:11:56 +0200
Subject: swig expert
In-Reply-To: <1159971504.22406.54.camel@geru-itae>
References: <1159971504.22406.54.camel@geru-itae>
Message-ID: <200610061711.57660.bernhard@intevation.de>

On Wednesday 04 October 2006 16:18, Didrik Pinte wrote:
> I've tried to update dbflib.i in order to support encoding conversion
> using PyString_AsDecodedObject. This seems to work pretty fine now and
> allow Thuban to work from scratch with any user locale and nearly any
> file encoding.
>
> Because I'm running a Debian/sid system, I had only swig 1.3.29 and no
> previous version. So, highly motivated, i've updated the dbflib.i and
> shapelib.i files. It builds fine but I have a little problem when
> testing the lib.

Can you describe your problems in more detail?
Best is to also add a patch, so if somebody wants to look into it,
it can be done right away.

> Is there any swig "expert" here that can help me to find a good solution
> to debug it ?

The result of swig usually is just C and Python so there is no magic in 
debugging it. 
Lately we thought that doing a python-wrapper for shapelib without swig 
is better, because there is so much fine tuning when you use swig for each
language that you do not win much in using swig.

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/20061006/e3a9eff0/attachment.bin

From bernhard at intevation.de  Fri Oct  6 17:13:04 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Oct 2006 17:13:04 +0200
Subject: Measure tool (was: Spatial selection Tools and Table Enhancements)
In-Reply-To: <20061005095721.GA20947@intevation.de>
References: <ebb9a320609231706k40917e85qb4a9fbbb0c71cfd6@mail.gmail.com>
	<200610042010.44534.bernhard@intevation.de>
	<20061005095721.GA20947@intevation.de>
Message-ID: <200610061713.05540.bernhard@intevation.de>

On Thursday 05 October 2006 11:57, Frank Koormann wrote:
> * Bernhard Reiter <bernhard at intevation.de> [061005 10:03]:
> > On Sunday 24 September 2006 02:06, Barry Windridge wrote:
> > > Attached is a zip file containing a number of enhancements to Thuban.
> >
> > The ruler.py tool is able to measure distances which is a feature
> > I want for a while. :)
> >
> > I believe Frank (Koormann) already did a measurement tool,
>
> No, I didn't

Then my memory fools me, I darkly remembered I had seen such a tool.
Sorry for the noise.
-------------- 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/20061006/6d48c49c/attachment.bin

From dpinte at itae.be  Fri Oct  6 18:06:22 2006
From: dpinte at itae.be (Didrik Pinte)
Date: Fri, 06 Oct 2006 18:06:22 +0200
Subject: swig expert
In-Reply-To: <200610061711.57660.bernhard@intevation.de>
References: <1159971504.22406.54.camel@geru-itae>
	<200610061711.57660.bernhard@intevation.de>
Message-ID: <1160150783.3360.25.camel@geru-itae>

Le vendredi 06 octobre 2006 ? 17:11 +0200, Bernhard Reiter a ?crit :
> On Wednesday 04 October 2006 16:18, Didrik Pinte wrote:
> > I've tried to update dbflib.i in order to support encoding conversion
> > using PyString_AsDecodedObject. This seems to work pretty fine now and
> > allow Thuban to work from scratch with any user locale and nearly any
> > file encoding.
> >
> > Because I'm running a Debian/sid system, I had only swig 1.3.29 and no
> > previous version. So, highly motivated, i've updated the dbflib.i and
> > shapelib.i files. It builds fine but I have a little problem when
> > testing the lib.
> 
> Can you describe your problems in more detail?
> Best is to also add a patch, so if somebody wants to look into it,
> it can be done right away.

Ok. The patch is here
http://wald.intevation.org/tracker/index.php?func=detail&aid=191&group_id=6&atid=107

Here are the two problems :

[1] this new version does not seem to be happy with unicode objects in
place of str objects. When calling shapefile.ShapeFile(filename) from
Thuban, the library complains about the type of the argument :

--------------------------------------------------------------------------
An unhandled exception occurred:
in method 'new_ShapeFile', argument 1 of type 'char *'
(please report to http://thuban.intevation.org/bugtracker.html)

Traceback (most recent call last):
  File
"/home/did/projets/python/thuban/current/thuban/Thuban/UI/mainwindow.py", line 297, in invoke_command
    command.Execute(self.Context())
  File
"/home/did/projets/python/thuban/current/thuban/test/../Thuban/UI/command.py", line 121, in Execute
    apply(self.function, (context,) + self.args + args, kw)
  File
"/home/did/projets/python/thuban/current/thuban/Thuban/UI/mainwindow.py", line 1072, in call_method
    apply(getattr(context.mainwindow, methodname), args)
  File
"/home/did/projets/python/thuban/current/thuban/Thuban/UI/mainwindow.py", line 573, in AddLayer
    store = self.application.Session().OpenShapefile(filename)
  File
"/home/did/projets/python/thuban/current/thuban/test/../Thuban/Model/session.py", line 296, in OpenShapefile
    store = ShapefileStore(self, filename)
  File
"/home/did/projets/python/thuban/current/thuban/test/../Thuban/Model/data.py", line 204, in __init__
    self._open_shapefile()
  File
"/home/did/projets/python/thuban/current/thuban/test/../Thuban/Model/data.py", line 207, in _open_shapefile
    self.shapefile = shapelib.ShapeFile(self.FileName())
  File
"/home/did/projets/python/thuban/current/thuban/Thuban/../Lib/shapelib.py", line 73, in __init__
    this = _shapelib.new_ShapeFile(*args)
TypeError: in method 'new_ShapeFile', argument 1 of type 'char *'
--------------------------------------------------------------------------

I've investigated the problem and found a workaround. In the
Lib/shapelib.py, changing the args tuple at line 73 so that it contains
only str objects and no more unicode ones solve the problem ... That's a
bit strange. I've reported the problem on the swig-user mailing list but
have received no answer at the moment.

[2] The second problem is really strange :

When calling the original libraries/pyshapelib/pytest.py, everything
works fine BUT if you do the following, you get an error :

Original code :
--------------------------------------------------------------------
make_shapefile("testfile")
read_shapefile("testfile")
--------------------------------------------------------------------

Modified code causing the bug :
--------------------------------------------------------------------
make_shapefile("testfile")
import os
os.path.exists("testfile.shp")
read_shapefile("testfile")
--------------------------------------------------------------------
Output : 

([10.0, 10.0, 0.0, 0.0], [20.0, 20.0, 0.0, 0.0])
[[(10.0, 10.0), (10.0, 20.0), (20.0, 20.0), (10.0, 10.0)]]
([0.0, 0.0, 0.0, 0.0], [40.0, 40.0, 0.0, 0.0])
[[(0.0, 0.0), (0.0, 40.0), (40.0, 40.0), (40.0, 0.0), (0.0, 0.0)],
[(10.0, 10.0), (20.0, 10.0), (20.0, 20.0), (10.0, 20.0), (10.0, 10.0)]]
Traceback (most recent call last):
  File "pytest.py", line 88, in ?
    os.path.exists("testfile.shp")
  File "/usr/lib/python2.4/posixpath.py", line 171, in exists
    st = os.stat(path)
TypeError: shapefile already closed

It is like if the handle was closed but still kept some kind of
reference on the previously opened shapefile.

> > Is there any swig "expert" here that can help me to find a good solution
> > to debug it ?
> 
> The result of swig usually is just C and Python so there is no magic in 
> debugging it. 
> Lately we thought that doing a python-wrapper for shapelib without swig 
> is better, because there is so much fine tuning when you use swig for each
> language that you do not win much in using swig.

Any suggestion for a swig-replacement ? Boost.Python ?

Didrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20061006/bbd9e33d/attachment.bin

From thuban-patches at wald.intevation.org  Fri Oct  6 18:05:23 2006
From: thuban-patches at wald.intevation.org (thuban-patches@wald.intevation.org)
Date: Fri,  6 Oct 2006 18:05:23 +0200 (CEST)
Subject: =?UTF-8?B?W3RodWJhbi1QYXRjaGVzXVsxOTFdIHB5c2hhcGVsaWIgdXBkYXRlIHRvIHN3aWcgMS4zLjI5IGFuZCB1bmljb2RlIHN1cHBvcnQ=?=
Message-ID: <20061006160523.B6D7D18017EB@pyrosoma.intevation.org>

Patches item #191, was opened at 2006-10-06 18:05
You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=107&aid=191&group_id=6
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

Status: Open
Priority: 3
Submitted By: Didrik Pinte (dpinte)
Assigned to: Nobody (None)
Summary: pyshapelib update to swig 1.3.29 and unicode support 
Version: None
Category: None


Initial Comment:
Here is the buggy patch.

Here are the two problems : 

[1] this new version does not seem to be happy with unicode objects in place of str objects. When calling shapefile.ShapeFile(filename) from Thuban, the library complains about the type of the argument :

--------------------------------------------------------------------------
An unhandled exception occurred:
in method 'new_ShapeFile', argument 1 of type 'char *'
(please report to http://thuban.intevation.org/bugtracker.html)

Traceback (most recent call last):
  File "/home/did/projets/python/thuban/current/thuban/Thuban/UI/mainwindow.py", line 297, in invoke_command
    command.Execute(self.Context())
  File "/home/did/projets/python/thuban/current/thuban/test/../Thuban/UI/command.py", line 121, in Execute
    apply(self.function, (context,) + self.args + args, kw)
  File "/home/did/projets/python/thuban/current/thuban/Thuban/UI/mainwindow.py", line 1072, in call_method
    apply(getattr(context.mainwindow, methodname), args)
  File "/home/did/projets/python/thuban/current/thuban/Thuban/UI/mainwindow.py", line 573, in AddLayer
    store = self.application.Session().OpenShapefile(filename)
  File "/home/did/projets/python/thuban/current/thuban/test/../Thuban/Model/session.py", line 296, in OpenShapefile
    store = ShapefileStore(self, filename)
  File "/home/did/projets/python/thuban/current/thuban/test/../Thuban/Model/data.py", line 204, in __init__
    self._open_shapefile()
  File "/home/did/projets/python/thuban/current/thuban/test/../Thuban/Model/data.py", line 207, in _open_shapefile
    self.shapefile = shapelib.ShapeFile(self.FileName())
  File "/home/did/projets/python/thuban/current/thuban/Thuban/../Lib/shapelib.py", line 73, in __init__
    this = _shapelib.new_ShapeFile(*args)
TypeError: in method 'new_ShapeFile', argument 1 of type 'char *'
--------------------------------------------------------------------------

I've investigated the problem and found a workaround. In the Lib/shapelib.py, changing the args tuple at line 73 so that it contains only str objects and no more unicode ones solve the problem ... That's a bit strange. I've reported the problem on the swig-user mailing list but have received no answer at the moment.

[2] The second problem is really strange :

When calling the original libraries/pyshapelib/pytest.py, everything works fine BUT if you do the following, you get an error :

Original code :
--------------------------------------------------------------------
make_shapefile("testfile")
read_shapefile("testfile")
--------------------------------------------------------------------

Modified code causing the bug :
--------------------------------------------------------------------
make_shapefile("testfile")
import os
os.path.exists("testfile.shp")
read_shapefile("testfile")
--------------------------------------------------------------------
Output : 

([10.0, 10.0, 0.0, 0.0], [20.0, 20.0, 0.0, 0.0])
[[(10.0, 10.0), (10.0, 20.0), (20.0, 20.0), (10.0, 10.0)]]
([0.0, 0.0, 0.0, 0.0], [40.0, 40.0, 0.0, 0.0])
[[(0.0, 0.0), (0.0, 40.0), (40.0, 40.0), (40.0, 0.0), (0.0, 0.0)], [(10.0, 10.0), (20.0, 10.0), (20.0, 20.0), (10.0, 20.0), (10.0, 10.0)]]
Traceback (most recent call last):
  File "pytest.py", line 88, in ?
    os.path.exists("testfile.shp")
  File "/usr/lib/python2.4/posixpath.py", line 171, in exists
    st = os.stat(path)
TypeError: shapefile already closed

It is like if the handle was closed but still kept some kind of reference on the previously opened shapefile.


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=107&aid=191&group_id=6



From bernhard at intevation.de  Sat Oct 14 23:06:38 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Sat, 14 Oct 2006 23:06:38 +0200
Subject: swig expert
In-Reply-To: <1160150783.3360.25.camel@geru-itae>
References: <1159971504.22406.54.camel@geru-itae>
	<200610061711.57660.bernhard@intevation.de>
	<1160150783.3360.25.camel@geru-itae>
Message-ID: <200610142306.39401.bernhard@intevation.de>

On Friday 06 October 2006 18:06, Didrik Pinte wrote:
> > Lately we thought that doing a python-wrapper for shapelib without swig
> > is better, because there is so much fine tuning when you use swig for
> > each language that you do not win much in using swig.
>
> Any suggestion for a swig-replacement ? Boost.Python ?

I think Bernhard (Herzog) would just use C and Python to wrap the libraries
like described in the Python documentation.

Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20061014/c12da650/attachment.bin

From bernhard at intevation.de  Sat Oct 14 23:15:41 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Sat, 14 Oct 2006 23:15:41 +0200
Subject: os.path.exists() strangeness with pytest.py (Re: swig expert)
In-Reply-To: <1160150783.3360.25.camel@geru-itae>
References: <1159971504.22406.54.camel@geru-itae>
	<200610061711.57660.bernhard@intevation.de>
	<1160150783.3360.25.camel@geru-itae>
Message-ID: <200610142315.42573.bernhard@intevation.de>

On Friday 06 October 2006 18:06, Didrik Pinte wrote:
> [2] The second problem is really strange :
>
> When calling the original libraries/pyshapelib/pytest.py, everything
> works fine BUT if you do the following, you get an error :
>
> Original code :
> --------------------------------------------------------------------
> make_shapefile("testfile")
> read_shapefile("testfile")
> --------------------------------------------------------------------
>
> Modified code causing the bug :
> --------------------------------------------------------------------
> make_shapefile("testfile")
> import os
> os.path.exists("testfile.shp")
> read_shapefile("testfile")
> --------------------------------------------------------------------
> Output :
>
> ([10.0, 10.0, 0.0, 0.0], [20.0, 20.0, 0.0, 0.0])
> [[(10.0, 10.0), (10.0, 20.0), (20.0, 20.0), (10.0, 10.0)]]
> ([0.0, 0.0, 0.0, 0.0], [40.0, 40.0, 0.0, 0.0])
> [[(0.0, 0.0), (0.0, 40.0), (40.0, 40.0), (40.0, 0.0), (0.0, 0.0)],
> [(10.0, 10.0), (20.0, 10.0), (20.0, 20.0), (10.0, 20.0), (10.0, 10.0)]]
> Traceback (most recent call last):
> ? File "pytest.py", line 88, in ?
> ? ? os.path.exists("testfile.shp")
> ? File "/usr/lib/python2.4/posixpath.py", line 171, in exists
> ? ? st = os.stat(path)
> TypeError: shapefile already closed
>
> It is like if the handle was closed but still kept some kind of
> reference on the previously opened shapefile.

This is strange. 
There should not be a connection between os.path.exists() 
and the other code. One thing that could cause this would be
earlier memory corruption. I wonder if there is a way to automatically
check for problems like this in Python modules.

Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20061014/b1e703fc/attachment.bin

From bernhard at intevation.de  Mon Oct 16 01:37:19 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 16 Oct 2006 01:37:19 +0200
Subject: Fixed LC_NUMERIC problem with RasterLayer
Message-ID: <200610160137.22579.bernhard@intevation.de>

I think I have finally fixed the problem with raster projections
and decimalcomma locales today.

https://wald.intevation.org/tracker/index.php?func=detail&aid=120&group_id=6&atid=105

Now we only need to report the bugs upstream and also show
our solution for the dbflib.

Bernhard
-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)



From thuban-bugs at wald.intevation.org  Mon Oct 16 01:34:19 2006
From: thuban-bugs at wald.intevation.org (thuban-bugs@wald.intevation.org)
Date: Mon, 16 Oct 2006 01:34:19 +0200 (CEST)
Subject: =?UTF-8?B?W3RodWJhbi1CdWdzXVsxOTddIE9HUiByb2J1c3QgYWdhaW5zdCBMQ19OVU1FUklDIHdpdGggZGVjaW1hbGNvbW1hPw==?=
Message-ID: <20061015233419.B3CCE18017DC@pyrosoma.intevation.org>

Bugs item #197, was opened at 2006-10-16 01:34
You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=105&aid=197&group_id=6
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

Status: Open
Priority: 3
Submitted By: Bernhard Reiter (bernhard)
Assigned to: Nobody (None)
Summary: OGR robust against LC_NUMERIC with decimalcomma? 
Resolution: None
Version: None
Category: None


Initial Comment:
Current version of GDAL, shapelib and proj have problems when they
are called with an LC_NUMERIC that uses comma as decimalseperator.
See
https://wald.intevation.org/tracker/index.php?func=detail&aid=120&group_id=6&atid=105

It is likely that the new OGR module has the same problem.
This needs checking.



----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=105&aid=197&group_id=6



From thuban-bugs at wald.intevation.org  Tue Oct 17 15:33:52 2006
From: thuban-bugs at wald.intevation.org (thuban-bugs@wald.intevation.org)
Date: Tue, 17 Oct 2006 15:33:52 +0200 (CEST)
Subject: =?UTF-8?B?W3RodWJhbi1CdWdzXVsxOThdIFBvc3RHSVM6IFRodWJhbiBkb2Vzbid0IHN1cHBvcnQgUG9zdGdyZVNRTCBzY2hlbWE=?=
Message-ID: <20061017133352.C0999180012F@pyrosoma.intevation.org>

Bugs item #198, was opened at 2006-10-17 15:33
You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=105&aid=198&group_id=6
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

Status: Open
Priority: 3
Submitted By: Frank Koormann (frank)
Assigned to: Nobody (None)
Summary: PostGIS: Thuban doesn't support PostgreSQL schema 
Resolution: None
Version: None
Category: None


Initial Comment:
Thuban expects the data always in the default schema (public) and does not support the PostgreSQL schema concept.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=105&aid=198&group_id=6



From thuban-bugs at wald.intevation.org  Mon Oct 23 11:18:57 2006
From: thuban-bugs at wald.intevation.org (thuban-bugs@wald.intevation.org)
Date: Mon, 23 Oct 2006 11:18:57 +0200 (CEST)
Subject: =?UTF-8?B?W3RodWJhbi1CdWdzXVsyMDZdIHd4cHJvai5jcHAgY2FsbHMgdG8gc3FydCBtZXRob2QgaXMgYnVnZ3kgd2l0aCBtc3ZjKysgdG9vbGtpdCAyMDAz?=
Message-ID: <20061023091857.748C318017E9@pyrosoma.intevation.org>

Bugs item #206, was opened at 2006-10-23 11:18
You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=105&aid=206&group_id=6
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

Status: Open
Priority: 3
Submitted By: Didrik Pinte (dpinte)
Assigned to: Nobody (None)
Summary: wxproj.cpp calls to sqrt method is buggy with msvc++ toolkit 2003 
Resolution: None
Version: None
Category: None


Initial Comment:
While compiling thuban with MS VC++ Toolkit 2003 with the revision 2712, I get the following error :

libraries\thuban\wxproj.cpp(459) : error C2668: 'sqrt' : ambiguous call to overl
oaded function
        C:\Program Files\Microsoft Visual C++ Toolkit 2003\include\math.h(626):
could be 'long double sqrt(long double)'
        C:\Program Files\Microsoft Visual C++ Toolkit 2003\include\math.h(578):
or       'float sqrt(float)'
        C:\Program Files\Microsoft Visual C++ Toolkit 2003\include\math.h(200):
or       'double sqrt(double)'
        while trying to match the argument list '(long)'
error: command '"C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin\cl.exe"'
 failed with exit status 2

The corresponding line of code is the following : 

    len = (long)sqrt(vx * vx + vy * vy);

The Gnu C library does define only sqrt values with double input. Casting the inputs to double solve the problem on with this win32 compiler. This won't break the code for other architectures.

So here is the patch ;-)

    len = (long)sqrt( (double)vx * vx + vy * vy );


Does anybody has another good suggestion about this ? Or can we consider it has solved with my wonderful patch ?

Didrik

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=105&aid=206&group_id=6