On 30/05/08 22:03, Glynn Clements wrote:
Moritz Lennert wrote:
can you replicate this with Spearfish or the NC data set?
Then we could easier test things...
Markus
Hi Markus,
those are the steps to replicate the problem with NC dataset ( all is done
in a new mapset called sqlite):
Moritz Lennert wrote:
those are the steps to replicate the problem with NC dataset ( all is
done
in a new mapset called sqlite):
db.connect driver=sqlite
database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'
g.copy [EMAIL PROTECTED],urbanarea
v.extract -t input=urbanarea
Moritz:
I'm not speaking about replacing any content.
I'm proposing that if you have a column cat in each
table, then the second is renamed to something
like cat2, so that you can have both in the resulting
table.
Glynn:
I think that it would be better to just force the user to
pick
Markus Neteler wrote:
(Hopefully) fixed in 6.4.develbranch and 7.trunk.
Do I understand correctly that the patch ignores the column if the name
already exists ? Wouldn't it be more user-friendly to rename it ?
I don't know about user-friendly, but it would be safer to just
abort
Markus Neteler OSGeo wrote:
Luca,
can you replicate this with Spearfish or the NC data set?
Then we could easier test things...
Markus
Hi Markus,
those are the steps to replicate the problem with NC dataset ( all is done
in a new mapset called sqlite):
db.connect driver=sqlite
On Fri, 30 May 2008 04:17:51 -0700 (PDT)
doktoreas [EMAIL PROTECTED] wrote:
Markus Neteler OSGeo wrote:
Luca,
can you replicate this with Spearfish or the NC data
set?
Then we could easier test things...
Markus
Hi Markus,
those are the steps to replicate the
On Fri, May 30, 2008 at 1:17 PM, doktoreas [EMAIL PROTECTED] wrote:
Markus Neteler OSGeo wrote:
Luca,
can you replicate this with Spearfish or the NC data set?
Then we could easier test things...
Markus
Hi Markus,
those are the steps to replicate the problem with NC dataset ( all is
Markus Neteler OSGeo wrote:
On Fri, May 30, 2008 at 1:17 PM, doktoreas [EMAIL PROTECTED] wrote:
Markus Neteler OSGeo wrote:
Luca,
can you replicate this with Spearfish or the NC data set?
Then we could easier test things...
Markus
Hi Markus,
those are the steps to replicate the
On Fri, 2008-05-30 at 06:32 -0700, doktoreas wrote:
Markus Neteler OSGeo wrote:
On Fri, May 30, 2008 at 1:17 PM, doktoreas [EMAIL PROTECTED] wrote:
Markus Neteler OSGeo wrote:
Luca,
can you replicate this with Spearfish or the NC data set?
Then we could easier test things...
Nikos Alexandris wrote:
Does this mean that the failure of join when using columns with the same
name was a bug?
Thank you,
Nikos
So it seem, but I have just tested the fix and now all is fine.
Luca
--
View this message in context:
On 30/05/08 15:17, Markus Neteler wrote:
On Fri, May 30, 2008 at 1:17 PM, doktoreas [EMAIL PROTECTED] wrote:
Markus Neteler OSGeo wrote:
Luca,
can you replicate this with Spearfish or the NC data set?
Then we could easier test things...
Markus
Hi Markus,
those are the steps to replicate
Moritz Lennert wrote:
can you replicate this with Spearfish or the NC data set?
Then we could easier test things...
Markus
Hi Markus,
those are the steps to replicate the problem with NC dataset ( all is done
in a new mapset called sqlite):
db.connect driver=sqlite
On Fri, May 30, 2008 at 10:03 PM, Glynn Clements
[EMAIL PROTECTED] wrote:
Moritz Lennert wrote:
...
(Hopefully) fixed in 6.4.develbranch and 7.trunk.
Do I understand correctly that the patch ignores the column if the name
already exists ? Wouldn't it be more user-friendly to rename it ?
I
13 matches
Mail list logo
