[GRASS-dev] Re: [GRASS-trac] #2: grass-6.2.3 and flex-2.5.34, missing the description.html

GDAL · January 9, 2008, 2:22pm

#2: grass-6.2.3 and flex-2.5.34, missing the description.html
-----------------------+----------------------------------------------------
  Reporter: stumbles | Owner: neteler
      Type: defect | Status: new
  Priority: major | Milestone: 6.3.0
Component: default | Version: unspecified
Resolution: | Keywords:
-----------------------+----------------------------------------------------
Changes (by neteler):

* cc: grass-dev@lists.osgeo.org (added)
* component: Docs => default

Old description:

Using gcc-4.2.2, glibc-2.7 and flex-2.5.34. The make goes fine till it
gets to generating HTML manual pages and fails with;

Following modules are missing the 'description.html' file in src code:
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Thu Dec 27 06:56:30 EST 2007
--
Errors in:
/usr/src/grass-6.2.3/lib/db/sqlp
/usr/src/grass-6.2.3/db/drivers/dbf
/usr/src/grass-6.2.3/db/drivers/postgres
/usr/src/grass-6.2.3/db/drivers/ogr
--
Finished compilation: Thu Dec 27 06:57:17 EST 2007
(In case of errors please change into the directory with error and run
'make')
make: *** [default] Error 1

So I cd to /usr/src/grass-6.2.3/lib/db/sqlp and run make which then
gives;

root@sidney /usr/src/grass-6.2.3/lib/db/sqlp # make
flex lex.l
lex.l:35: bad character: %
lex.l:35: unknown error processing section 1
lex.l:35: unknown error processing section 1
lex.l:35: bad character: 1
lex.l:35: bad character: 2
lex.l:35: bad character: 0
lex.l:35: bad character: 0
make: *** [lex.yy.c] Error 1

The remaining directories /usr/src/grass-6.2.3/db/drivers/dbf,
/usr/src/grass-6.2.3/db/drivers/postgres and
/usr/src/grass-6.2.3/db/drivers/ogr fail on the make because it cannot
find;

/usr/bin/ld: cannot find -lgrass_sqlp
collect2: ld returned 1 exit status
make: *** [/usr/src/grass-6.2.3/dist.i686-pc-linux-gnu/driver/db/dbf]
Error 1

The error shown for /usr/src/grass-6.2.3/lib/db/sqlp looks very similar
to a recent problem I had with teTeX and flex-2.5.34. A small snip of
that particular error looks like;

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I.. -I./.. -O2
-march=athlon64 -pipe -c y_tab.c -o y_tab.o
    flex -l ./pl.l
    ./pl.l:68: bad character: %
    ./pl.l:68: unknown error processing section 1
    ./pl.l:68: unknown error processing section 1
    ./pl.l:68: bad character: 4
    ./pl.l:68: bad character: 0

New description:

Using gcc-4.2.2, glibc-2.7 and flex-2.5.34. The make goes fine till it
gets to generating HTML manual pages and fails with;

Following modules are missing the 'description.html' file in src code:
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Thu Dec 27 06:56:30 EST 2007
--
Errors in:
/usr/src/grass-6.2.3/lib/db/sqlp
/usr/src/grass-6.2.3/db/drivers/dbf
/usr/src/grass-6.2.3/db/drivers/postgres
/usr/src/grass-6.2.3/db/drivers/ogr
--
Finished compilation: Thu Dec 27 06:57:17 EST 2007
(In case of errors please change into the directory with error and run
'make')
make: *** [default] Error 1

So I cd to /usr/src/grass-6.2.3/lib/db/sqlp and run make which then gives;

{{{
root@sidney /usr/src/grass-6.2.3/lib/db/sqlp # make
flex lex.l
lex.l:35: bad character: %
lex.l:35: unknown error processing section 1
lex.l:35: unknown error processing section 1
lex.l:35: bad character: 1
lex.l:35: bad character: 2
lex.l:35: bad character: 0
lex.l:35: bad character: 0
make: *** [lex.yy.c] Error 1
}}}

The remaining directories /usr/src/grass-6.2.3/db/drivers/dbf,
/usr/src/grass-6.2.3/db/drivers/postgres and
/usr/src/grass-6.2.3/db/drivers/ogr fail on the make because it cannot
find;

/usr/bin/ld: cannot find -lgrass_sqlp
collect2: ld returned 1 exit status
make: *** [/usr/src/grass-6.2.3/dist.i686-pc-linux-gnu/driver/db/dbf]
Error 1

The error shown for /usr/src/grass-6.2.3/lib/db/sqlp looks very similar to
a recent problem I had with teTeX and flex-2.5.34. A small snip of that
particular error looks like;

{{{
  gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I.. -I./.. -O2
-march=athlon64 -pipe -c y_tab.c -o y_tab.o
     flex -l ./pl.l
     ./pl.l:68: bad character: %
     ./pl.l:68: unknown error processing section 1
     ./pl.l:68: unknown error processing section 1
     ./pl.l:68: bad character: 4
     ./pl.l:68: bad character: 0
}}}

Comment:

developers,

is there any known issue with flex-2.5.34?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2#comment:1>
GRASS-trac <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

Benjamin_Ducke3 · January 10, 2008, 8:51am

Dear all,

following our discussion two days ago, I have started patching
v.in.ascii to support creating only an attribute table w/o
any vector objects/geometries.

It seems the easiest way in terms of not modifying too much of
the original code is to be create a dummy vector map, creating
the table for it and then deleting only the geometries after import,
leaving the table intact.

I have two questions about this:

1. Given that the user want to create a dbase table, where should
the resulting DBF file be placed? In the mapset's dbf directory?

2. Which C API command do I use to delete every element of a
vector map except the attribute table (Apparently, Vect_delete()
always deletes the table, too)?

Thanks,

Benjamin

mlennert · January 10, 2008, 9:17am

On 10/01/08 09:51, Benjamin Ducke wrote:

Dear all,

following our discussion two days ago, I have started patching
v.in.ascii to support creating only an attribute table w/o
any vector objects/geometries.

It seems the easiest way in terms of not modifying too much of
the original code is to be create a dummy vector map, creating
the table for it and then deleting only the geometries after import,
leaving the table intact.

When I looked at it, I had the feeling that the easiest way would be to add a flag which, if set, leaves out the map creation part. This would mean (in in.c)

- conditionalising lines 214-215 and all calls to Vect_delete and Vect_map_add_dblink and other functions using &Map as parameter on the flag not being set
- not use Vect_default_field_info and Fi (lines 300ff), but directly use db_get_connection() and a table_name parameter given by the user (with default being the same name as the file ?).

I have two questions about this:

1. Given that the user want to create a dbase table, where should
the resulting DBF file be placed? In the mapset's dbf directory?

It should use the current db.connect settings (that's what db_get_connection() should give you), and so create any kind of table (dbf or others).

Moritz

Benjamin_Ducke3 · January 10, 2008, 12:52pm

OK, I have it almost working except for one annoyance:

If the table already exists, then --o should allow the user to
overwrite it. Thus, I check for that flag and delete the old
table, if it exists, using:

db_delete_table ( connection.driverName, connection.databaseName,
new->answer );

But even so, the next call to

db_execute_immediate()

complains about the table still being there and creation of the
new table fails.
I suppose that db_delete_table() does not delete the table immediately?
What other function do I have to call to physically get rid of the
table immediately?

Thanks,

Benjamin

Moritz Lennert wrote:

On 10/01/08 09:51, Benjamin Ducke wrote:

Dear all,

following our discussion two days ago, I have started patching
v.in.ascii to support creating only an attribute table w/o
any vector objects/geometries.

It seems the easiest way in terms of not modifying too much of
the original code is to be create a dummy vector map, creating
the table for it and then deleting only the geometries after import,
leaving the table intact.

When I looked at it, I had the feeling that the easiest way would be to
add a flag which, if set, leaves out the map creation part. This would
mean (in in.c)

- conditionalising lines 214-215 and all calls to Vect_delete and
Vect_map_add_dblink and other functions using &Map as parameter on the
flag not being set
- not use Vect_default_field_info and Fi (lines 300ff), but directly use
db_get_connection() and a table_name parameter given by the user (with
default being the same name as the file ?).

I have two questions about this:

1. Given that the user want to create a dbase table, where should
the resulting DBF file be placed? In the mapset's dbf directory?

It should use the current db.connect settings (that's what
db_get_connection() should give you), and so create any kind of table
(dbf or others).

Moritz

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

martinl · January 10, 2008, 1:00pm

Hi,

2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

following our discussion two days ago, I have started patching
v.in.ascii to support creating only an attribute table w/o
any vector objects/geometries.

do you mean to simulate these steps:

echo "1|2|3" | v.in.ascii out=x col="x double precision, y double
precision, t int";
v.db.connect x -d;
g.remove vect=x;
echo "select * from x" | db.select

?

Martin

It seems the easiest way in terms of not modifying too much of
the original code is to be create a dummy vector map, creating
the table for it and then deleting only the geometries after import,
leaving the table intact.

I have two questions about this:

1. Given that the user want to create a dbase table, where should
the resulting DBF file be placed? In the mapset's dbf directory?

2. Which C API command do I use to delete every element of a
vector map except the attribute table (Apparently, Vect_delete()
always deletes the table, too)?

Thanks,

Benjamin
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

Benjamin_Ducke3 · January 10, 2008, 1:33pm

Indeed, disconnecting the DBMS link before
removing the vector map does the same thing ...

I guess, the advantages in patching v.in.ascii to do
this are:

1. Many users who are not very knowledgeable in GRASS
shell scripting and using the DBMS modules (like myself,
obviously) would probably have a better chance of finding what they are
looking for.

2. For very large input tables we'll save some time and mem,
because no coordinate fields checking needs to be done and
creation of the dummy vector map can be skipped.

Disadvantage:

v.in.ascii code gets bloated with more conditionals.

??

Martin Landa wrote:

Hi,

2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

following our discussion two days ago, I have started patching
v.in.ascii to support creating only an attribute table w/o
any vector objects/geometries.

do you mean to simulate these steps:

echo "1|2|3" | v.in.ascii out=x col="x double precision, y double
precision, t int";
v.db.connect x -d;
g.remove vect=x;
echo "select * from x" | db.select

?

Martin

It seems the easiest way in terms of not modifying too much of
the original code is to be create a dummy vector map, creating
the table for it and then deleting only the geometries after import,
leaving the table intact.

I have two questions about this:

1. Given that the user want to create a dbase table, where should
the resulting DBF file be placed? In the mapset's dbf directory?

2. Which C API command do I use to delete every element of a
vector map except the attribute table (Apparently, Vect_delete()
always deletes the table, too)?

Thanks,

Benjamin
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

mlennert · January 10, 2008, 1:40pm

On 10/01/08 14:33, Benjamin Ducke wrote:

Indeed, disconnecting the DBMS link before
removing the vector map does the same thing ...

I guess, the advantages in patching v.in.ascii to do
this are:

1. Many users who are not very knowledgeable in GRASS
shell scripting and using the DBMS modules (like myself,
obviously) would probably have a better chance of finding what they are
looking for.

2. For very large input tables we'll save some time and mem,
because no coordinate fields checking needs to be done and
creation of the dummy vector map can be skipped.

Disadvantage:

v.in.ascii code gets bloated with more conditionals.

+1 for the v.in.ascii approach as I think that will make it easier for users and that if we can easily integrate this kind of functionality into a C-module instead of creating a new script, this will reduce the risk of portability issues that is inherent in shell scripts.

Moritz

mlennert · January 10, 2008, 1:41pm

On 10/01/08 13:52, Benjamin Ducke wrote:

OK, I have it almost working except for one annoyance:

If the table already exists, then --o should allow the user to
overwrite it. Thus, I check for that flag and delete the old
table, if it exists, using:

  db_delete_table ( connection.driverName, connection.databaseName,
                    new->answer );

But even so, the next call to

  db_execute_immediate()

complains about the table still being there and creation of the
new table fails.
I suppose that db_delete_table() does not delete the table immediately?

db_delete_table() sends a "drop table XYZ" sql query to the database
backend, so it should delete the table.

Launching

echo "drop table ggg" | db.execute
followed by
echo "create table ggg (cat int, value double)" | db.execute

works without a problem.

What does db_delete_table return ?

Moritz

Benjamin_Ducke3 · January 10, 2008, 2:10pm

Unfortunately, it returns DB_OK.
There seems to be some caching going on which I don't quite
understand at the moment.
Starting and stopping the db driver in the right sequence seems
to be important.
Anyway, I solved the problem by doing the deletion at an earlier
point in the program.

Everything seems to work OK now. I'll do some tests with more
complex tables, then post a patch.

Benjamin

Moritz Lennert wrote:

On 10/01/08 13:52, Benjamin Ducke wrote:

OK, I have it almost working except for one annoyance:

If the table already exists, then --o should allow the user to
overwrite it. Thus, I check for that flag and delete the old
table, if it exists, using:

  db_delete_table ( connection.driverName, connection.databaseName,
                    new->answer );

But even so, the next call to

  db_execute_immediate()

complains about the table still being there and creation of the
new table fails.
I suppose that db_delete_table() does not delete the table immediately?

db_delete_table() sends a "drop table XYZ" sql query to the database
backend, so it should delete the table.

Launching

echo "drop table ggg" | db.execute
followed by
echo "create table ggg (cat int, value double)" | db.execute

works without a problem.

What does db_delete_table return ?

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

Benjamin_Ducke3 · January 10, 2008, 2:56pm

Alright, here is the patches vor v.in.ascii.

Cheers,

Benjamin

Benjamin Ducke wrote:

Unfortunately, it returns DB_OK.
There seems to be some caching going on which I don't quite
understand at the moment.
Starting and stopping the db driver in the right sequence seems
to be important.
Anyway, I solved the problem by doing the deletion at an earlier
point in the program.

Everything seems to work OK now. I'll do some tests with more
complex tables, then post a patch.

Benjamin

Moritz Lennert wrote:

On 10/01/08 13:52, Benjamin Ducke wrote:

OK, I have it almost working except for one annoyance:

If the table already exists, then --o should allow the user to
overwrite it. Thus, I check for that flag and delete the old
table, if it exists, using:

  db_delete_table ( connection.driverName, connection.databaseName,
                    new->answer );

But even so, the next call to

  db_execute_immediate()

complains about the table still being there and creation of the
new table fails.
I suppose that db_delete_table() does not delete the table immediately?

db_delete_table() sends a "drop table XYZ" sql query to the database
backend, so it should delete the table.

Launching

echo "drop table ggg" | db.execute
followed by
echo "create table ggg (cat int, value double)" | db.execute

works without a problem.

What does db_delete_table return ?

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

(attachments)

description.html.patch (828 Bytes)
in.c.patch (17.6 KB)
local_proto.h.patch (519 Bytes)
points.c.patch (3.7 KB)

martinl · January 10, 2008, 3:10pm

hi,

it is better to create one diff file instead of bunch of them, e.g.

svn diff vector/v.in.ascii > v-in-ascii.diff

sorry for bothering you:-)

Martin

2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

Alright, here is the patches vor v.in.ascii.

Cheers,

Benjamin

Benjamin Ducke wrote:
> Unfortunately, it returns DB_OK.
> There seems to be some caching going on which I don't quite
> understand at the moment.
> Starting and stopping the db driver in the right sequence seems
> to be important.
> Anyway, I solved the problem by doing the deletion at an earlier
> point in the program.
>
> Everything seems to work OK now. I'll do some tests with more
> complex tables, then post a patch.
>
> Benjamin
>
> Moritz Lennert wrote:
>> On 10/01/08 13:52, Benjamin Ducke wrote:
>>> OK, I have it almost working except for one annoyance:
>>>
>>> If the table already exists, then --o should allow the user to
>>> overwrite it. Thus, I check for that flag and delete the old
>>> table, if it exists, using:
>>>
>>> db_delete_table ( connection.driverName, connection.databaseName,
>>> new->answer );
>>>
>>> But even so, the next call to
>>>
>>> db_execute_immediate()
>>>
>>> complains about the table still being there and creation of the
>>> new table fails.
>>> I suppose that db_delete_table() does not delete the table immediately?
>> db_delete_table() sends a "drop table XYZ" sql query to the database
>> backend, so it should delete the table.
>>
>> Launching
>>
>> echo "drop table ggg" | db.execute
>> followed by
>> echo "create table ggg (cat int, value double)" | db.execute
>>
>> works without a problem.
>>
>> What does db_delete_table return ?
>>
>> Moritz
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

Benjamin_Ducke3 · January 10, 2008, 3:19pm

OK, this seems to be a useful hint, so here it goes again:

Martin Landa wrote:

hi,

it is better to create one diff file instead of bunch of them, e.g.

svn diff vector/v.in.ascii > v-in-ascii.diff

sorry for bothering you:-)

Martin

2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

Alright, here is the patches vor v.in.ascii.

Cheers,

Benjamin

Benjamin Ducke wrote:

Unfortunately, it returns DB_OK.
There seems to be some caching going on which I don't quite
understand at the moment.
Starting and stopping the db driver in the right sequence seems
to be important.
Anyway, I solved the problem by doing the deletion at an earlier
point in the program.

Everything seems to work OK now. I'll do some tests with more
complex tables, then post a patch.

Benjamin

Moritz Lennert wrote:

On 10/01/08 13:52, Benjamin Ducke wrote:

OK, I have it almost working except for one annoyance:

If the table already exists, then --o should allow the user to
overwrite it. Thus, I check for that flag and delete the old
table, if it exists, using:

  db_delete_table ( connection.driverName, connection.databaseName,
                    new->answer );

But even so, the next call to

  db_execute_immediate()

complains about the table still being there and creation of the
new table fails.
I suppose that db_delete_table() does not delete the table immediately?

db_delete_table() sends a "drop table XYZ" sql query to the database
backend, so it should delete the table.

Launching

echo "drop table ggg" | db.execute
followed by
echo "create table ggg (cat int, value double)" | db.execute

works without a problem.

What does db_delete_table return ?

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

(attachments)

v.in.ascii.patch (22.8 KB)

martinl · January 10, 2008, 3:27pm

hi,

the patch is for svn-trunk?

$ patch -p0 < ~/temp/v.in.ascii.patch
patching file v.in.ascii/description.html
patching file v.in.ascii/in.c
Hunk #3 FAILED at 164.
Hunk #4 succeeded at 187 (offset 1 line).
Hunk #6 succeeded at 289 (offset 1 line).
Hunk #8 succeeded at 444 (offset 1 line).
Hunk #10 succeeded at 479 (offset 1 line).
Hunk #12 succeeded at 589 (offset 1 line).
Hunk #14 succeeded at 655 (offset 1 line).
1 out of 15 hunks FAILED -- saving rejects to file v.in.ascii/in.c.rej
patching file v.in.ascii/local_proto.h
patching file v.in.ascii/points.c

Martin

2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

OK, this seems to be a useful hint, so here it goes again:

Martin Landa wrote:
> hi,
>
> it is better to create one diff file instead of bunch of them, e.g.
>
> svn diff vector/v.in.ascii > v-in-ascii.diff
>
> sorry for bothering you:-)
>
> Martin
>
> 2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
>> Alright, here is the patches vor v.in.ascii.
>>
>> Cheers,
>>
>> Benjamin
>>
>> Benjamin Ducke wrote:
>>> Unfortunately, it returns DB_OK.
>>> There seems to be some caching going on which I don't quite
>>> understand at the moment.
>>> Starting and stopping the db driver in the right sequence seems
>>> to be important.
>>> Anyway, I solved the problem by doing the deletion at an earlier
>>> point in the program.
>>>
>>> Everything seems to work OK now. I'll do some tests with more
>>> complex tables, then post a patch.
>>>
>>> Benjamin
>>>
>>> Moritz Lennert wrote:
>>>> On 10/01/08 13:52, Benjamin Ducke wrote:
>>>>> OK, I have it almost working except for one annoyance:
>>>>>
>>>>> If the table already exists, then --o should allow the user to
>>>>> overwrite it. Thus, I check for that flag and delete the old
>>>>> table, if it exists, using:
>>>>>
>>>>> db_delete_table ( connection.driverName, connection.databaseName,
>>>>> new->answer );
>>>>>
>>>>> But even so, the next call to
>>>>>
>>>>> db_execute_immediate()
>>>>>
>>>>> complains about the table still being there and creation of the
>>>>> new table fails.
>>>>> I suppose that db_delete_table() does not delete the table immediately?
>>>> db_delete_table() sends a "drop table XYZ" sql query to the database
>>>> backend, so it should delete the table.
>>>>
>>>> Launching
>>>>
>>>> echo "drop table ggg" | db.execute
>>>> followed by
>>>> echo "create table ggg (cat int, value double)" | db.execute
>>>>
>>>> works without a problem.
>>>>
>>>> What does db_delete_table return ?
>>>>
>>>> Moritz
>>>>
>>>> _______________________________________________
>>>> grass-dev mailing list
>>>> grass-dev@lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>>
>>>>
>> --
>> Benjamin Ducke, M.A.
>> Archäoinformatik
>> (Archaeoinformation Science)
>> Institut für Ur- und Frühgeschichte
>> (Inst. of Prehistoric and Historic Archaeology)
>> Christian-Albrechts-Universität zu Kiel
>> Johanna-Mestorf-Straße 2-6
>> D 24098 Kiel
>> Germany
>>
>> Tel.: ++49 (0)431 880-3378 / -3379
>> Fax : ++49 (0)431 880-7300
>> www.uni-kiel.de/ufg
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>
>

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

Hamish · January 10, 2008, 9:16pm

Martin Landa wrote:

> following our discussion two days ago, I have started patching
> v.in.ascii to support creating only an attribute table w/o
> any vector objects/geometries.

Hi,

I am still away so not really follwing the lists right now, but
checking in spotted this thread.

v.in.ascii is the wrong module for this functionality, it should be in
db.in.ascii or so (but the two sharing code would be nice). ISTR Markus
had created a module like that a few months ago. Was it v.in.ogr with a
DB driver?? I can't quite remember now, just that it exists and is on
my TODO list to investigate if the v.in.garmin & v.in.gpsbabel scripts
should use it.

Hopefully Markus can clarify.

Hamish

____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

mlennert · January 10, 2008, 9:39pm

On 10/01/08 22:16, Hamish wrote:

Martin Landa wrote:

following our discussion two days ago, I have started patching
v.in.ascii to support creating only an attribute table w/o
any vector objects/geometries.

Hi,

I am still away so not really follwing the lists right now, but
checking in spotted this thread.

v.in.ascii is the wrong module for this functionality, it should be in
db.in.ascii or so (but the two sharing code would be nice). ISTR Markus
had created a module like that a few months ago. Was it v.in.ogr with a
DB driver?? I can't quite remember now, just that it exists and is on
my TODO list to investigate if the v.in.garmin & v.in.gpsbabel scripts
should use it.

db.in.ogr

The problem with the ogr csv driver is that it doesn't do any guessing of column types.

I agree that ideally we should have db.in.ascii or a patched ogr csv driver. However the former would mean an extensive amount of code shared between v.in.ascii and db.in.ascii, making it questionable whether these should really be two different modules, and the latter means going into C++ and getting familiar with ogr which might not be an option for those (the one) interested in doing the coding...

But if the code sharing is not deemed a problem, it should be fairly straightforward to create a db.in.ascii from Benjamin's code. And if someone is willing to patch ogr this would probably be the ideal solution.

Moritz

Benjamin_Ducke3 · January 11, 2008, 8:51am

Yes, it was meant for svn-trunk.

I just re-generated it and it works without fuzz on
my fresh SVN checkout (09:45 am CET).
Try the attached version if you like.

I will put work on this feature on hold until there is some
clarification whether these changes are actually wanted ...

However, I'd like to add the ability to read field names
from the ascii input file to v.in.ascii.
Should I add a flag to interpret the first line as
field labels?
Does anyone know what the restrictions on DBF field
names are? Length? Special characters?

Cheers,

Benjamin

Martin Landa wrote:

hi,

the patch is for svn-trunk?

$ patch -p0 < ~/temp/v.in.ascii.patch
patching file v.in.ascii/description.html
patching file v.in.ascii/in.c
Hunk #3 FAILED at 164.
Hunk #4 succeeded at 187 (offset 1 line).
Hunk #6 succeeded at 289 (offset 1 line).
Hunk #8 succeeded at 444 (offset 1 line).
Hunk #10 succeeded at 479 (offset 1 line).
Hunk #12 succeeded at 589 (offset 1 line).
Hunk #14 succeeded at 655 (offset 1 line).
1 out of 15 hunks FAILED -- saving rejects to file v.in.ascii/in.c.rej
patching file v.in.ascii/local_proto.h
patching file v.in.ascii/points.c

Martin

2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

OK, this seems to be a useful hint, so here it goes again:

Martin Landa wrote:

hi,

it is better to create one diff file instead of bunch of them, e.g.

svn diff vector/v.in.ascii > v-in-ascii.diff

sorry for bothering you:-)

Martin

2008/1/10, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

Alright, here is the patches vor v.in.ascii.

Cheers,

Benjamin

Benjamin Ducke wrote:

Unfortunately, it returns DB_OK.
There seems to be some caching going on which I don't quite
understand at the moment.
Starting and stopping the db driver in the right sequence seems
to be important.
Anyway, I solved the problem by doing the deletion at an earlier
point in the program.

Everything seems to work OK now. I'll do some tests with more
complex tables, then post a patch.

Benjamin

Moritz Lennert wrote:

On 10/01/08 13:52, Benjamin Ducke wrote:

OK, I have it almost working except for one annoyance:

If the table already exists, then --o should allow the user to
overwrite it. Thus, I check for that flag and delete the old
table, if it exists, using:

  db_delete_table ( connection.driverName, connection.databaseName,
                    new->answer );

But even so, the next call to

  db_execute_immediate()

complains about the table still being there and creation of the
new table fails.
I suppose that db_delete_table() does not delete the table immediately?

db_delete_table() sends a "drop table XYZ" sql query to the database
backend, so it should delete the table.

Launching

echo "drop table ggg" | db.execute
followed by
echo "create table ggg (cat int, value double)" | db.execute

works without a problem.

What does db_delete_table return ?

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

(attachments)

v.in.ascii.patch (22.8 KB)

mlennert · January 11, 2008, 9:23am

On 11/01/08 09:51, Benjamin Ducke wrote:

Yes, it was meant for svn-trunk.

I just re-generated it and it works without fuzz on
my fresh SVN checkout (09:45 am CET).
Try the attached version if you like.

I will put work on this feature on hold until there is some
clarification whether these changes are actually wanted ...

However, I'd like to add the ability to read field names
from the ascii input file to v.in.ascii.
Should I add a flag to interpret the first line as
field labels?
Does anyone know what the restrictions on DBF field
names are? Length?

8 chars

Special characters?

You should probably avoid anything non-ascii.

Moritz

Hamish · January 11, 2008, 9:09pm

Benjamin Ducke wrote:

However, I'd like to add the ability to read field names
from the ascii input file to v.in.ascii.

that would be nice.

Should I add a flag to interpret the first line as
field labels?

It appears the scanning step may be interesting as a separate little
program, or a scan and exit. ie to prepare a columns= SQL line for you,
which you can check before using.
?
see also v.voronoi and v.delunay source code sharing, although I'm not
sure if that is the best implementation to mimic for a db.in.ascii.

Does anyone know what the restrictions on DBF field
names are? Length? Special characters?

10 chars long, case insensitive, spaces to underscores.
Special chars may be ok but I don't remember ever seeing any, and
considering dBase's age I'd stick to [a-z][0-9] ASCII chars.

Hamish

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

Maciej_Sieczka2 · March 27, 2008, 9:01pm

Moritz Lennert pisze:

On 11/01/08 09:51, Benjamin Ducke wrote:

Does anyone know what the restrictions on DBF field
names are? Length?

8 chars

Add 2:

"DBF column names are limited to 10 characters (DBF API definition)" [1]

Special characters?

You should probably avoid anything non-ascii.

More hints in [1].