Re: [GRASS-user] v.in.db question
On 15/06/12 18:18, Rich Shepard wrote: On Fri, 15 Jun 2012, Moritz Lennert wrote: I just added that feature to trunk (r52078). Seems to work alright, but might lack some failsafe mecanisms. Please test to see if it might have any unforeseen consequences. Moritz, I run 6.5svn and am current at r52080. I'll test the revision if you copy it to the 6.5 trunk, too. Done in r52083, so that you can test it. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.db question
On Fri, 15 Jun 2012, Moritz Lennert wrote: I just added that feature to trunk (r52078). Seems to work alright, but might lack some failsafe mecanisms. Please test to see if it might have any unforeseen consequences. Moritz, I run 6.5svn and am current at r52080. I'll test the revision if you copy it to the 6.5 trunk, too. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.db question
On 06/15/2012 05:52 PM, Moritz Lennert wrote: On 15/06/12 15:56, Micha Silver wrote: What might be even more attractive would be an option to link a GRASS vector to a DB view. This would allow updating of the data tables in the DB, and have the new values accessible from within GRASS. I tried once without success. I don't think that v.db.connect ... layer=2 will work with a database view. Maybe someone on the list with more experience can verify? v.db.connect works very well with views. And I haven't heard anything about it being a problem for layers other than 2. Just remember that if you want to connect another table to a layer, the features in the map have to have category values in that layer, otherwise, there will be no connection between features and attributes in the table. Moritz Thanks, I try again. This mail was received via Mail-SeCure System. -- Micha Silver GIS Consultant, Arava Development Co. http://www.surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.db question
On 15/06/12 15:56, Micha Silver wrote: (Returning the discussion to the maillist) On 06/15/2012 03:58 PM, Rich Shepard wrote: On Fri, 15 Jun 2012, Micha Silver wrote: Now that I think about it, I wonder how hard it would be to add to v.in.db an option to just reuse that same table as the attribute table for the newly created GRASS vector. I had a quick look at the code, and it looks doable (caveat: I'm not a c developer). I just added that feature to trunk (r52078). Seems to work alright, but might lack some failsafe mecanisms. Please test to see if it might have any unforeseen consequences. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.db question
On 15/06/12 15:56, Micha Silver wrote: What might be even more attractive would be an option to link a GRASS vector to a DB view. This would allow updating of the data tables in the DB, and have the new values accessible from within GRASS. I tried once without success. I don't think that v.db.connect ... layer=2 will work with a database view. Maybe someone on the list with more experience can verify? v.db.connect works very well with views. And I haven't heard anything about it being a problem for layers other than 2. Just remember that if you want to connect another table to a layer, the features in the map have to have category values in that layer, otherwise, there will be no connection between features and attributes in the table. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.db question
(Returning the discussion to the maillist) On 06/15/2012 03:58 PM, Rich Shepard wrote: On Fri, 15 Jun 2012, Micha Silver wrote: Now that I think about it, I wonder how hard it would be to add to v.in.db an option to just reuse that same table as the attribute table for the newly created GRASS vector. I had a quick look at the code, and it looks doable (caveat: I'm not a c developer). Do you think this would be a important feature? After all, if you're working on the same database, you can just choose a different name for the new GRASS vector, and it should work... Micha, I think it's a critical feature and should be the default rather than an option. When I recognized what was happening I was left with two choices: create a map/table with a new name and no attributes other than a category number and coordinates, or not create the map from coordinates in the existing table. v.in.db with a new name for the GRASS vector *should* reproduce all columns from the original table into the new GRASS vector's attribute table. How I read the v.in.db manual page (and the table option) lead me to believce the module's purpose is to create a vector map of points based on coordinates in an existing database table. This recognizes there is an existing table and the map would be created from it. The current behavior is use only the coordinates from the existing table and ignore all other attributes. I guess that v.in.db was designed to mirror all the other v.in.* modules. Create both the geometry in GRASS and a new attribute table as per db.connect. What might be even more attractive would be an option to link a GRASS vector to a DB view. This would allow updating of the data tables in the DB, and have the new values accessible from within GRASS. I tried once without success. I don't think that v.db.connect ... layer=2 will work with a database view. Maybe someone on the list with more experience can verify? A kludge would be to create the new map and table with a new name, then use the SQL UPDATE statement to copy the attributes from the existing table to the new one. This would be followed by DROP TABLE , then ALTER TABLE RENAME TO . I think the easiest kludge might be to rename the original table to some temp name *at the start*, then do v.in.db to whatever final name you want for your GRASS vector. -- Micha Rich This mail was received via Mail-SeCure System. -- Micha Silver GIS Consultant, Arava Development Co. http://www.surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.db question
On Thu, 14 Jun 2012, Micha Silver wrote: Is the original table "sites" already in postgres? If so then it indeed already exists ;-) Micha, The table already exists in the postgres database but there's no map of the points in that table. My understanding of v.in.db is this module will create the map from the coordinates in the postgres table. It doesn't. That's why I asked about it. In any case, when I looked closely at the coordinate values in that file they were outside the region; I've no idea where those values originated. So, I started with the lat/lon coordinates of the raw data and just used v.in.ascii to create two new maps/tables (one for chemicals the other for biota). Now I'll re-project those to the project coordinate system. Toda, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.db question
On 06/14/2012 07:08 PM, Rich Shepard wrote: The first example on the v.in.db manual page (version 6.5) has the map output name the same as the input table name. When I try to do this grass throws an error: v.in.db tab=sites x=easting y=northing key=cat out=sites ERROR: Output vector map, table (driver: , database: <>) already exists Is the original table "sites" already in postgres? If so then it indeed already exists ;-) However, the vector map was not in the list before running the module. After running the module, the map 'sites' appears in the list but is empty. What have I missed here? Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user This mail was received via Mail-SeCure System. -- Micha Silver GIS Consultant, Arava Development Co. http://www.surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.db question
The first example on the v.in.db manual page (version 6.5) has the map output name the same as the input table name. When I try to do this grass throws an error: v.in.db tab=sites x=easting y=northing key=cat out=sites ERROR: Output vector map, table (driver: , database: <>) already exists However, the vector map was not in the list before running the module. After running the module, the map 'sites' appears in the list but is empty. What have I missed here? Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ' v.in.db ' question
Bulent Arikan wrote: The file is on my Desktop! which is usually /home//Desktop/ on Linux and usually C\:Documents and Settings\\Desktop\ on Windows Neither of these is the same like $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/, you must set database=, otherwise v.in.db can't find the table. On Apr 22, 2009, at 12:53 AM, Markus Metz wrote: Bulent Arikan wrote: Hi, I am trying to import an OpenOffice dbf into a wgs84 PERMANENT Location. I did this several times in the past with older versions of GRASS. I enter all the necessary information (input table, column names for x, y, z and CAT#). The Connection tab shows "dbf" for the driver name and database name reads " $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ " I get this message: DBMI-DBF driver error: Table 'Iron_II_KNOWN_Sites' doesn't exist Stupid question: is Iron_II_KNOWN_Sites.dbf in " $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ " or in a different folder? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ' v.in.db ' question
Bulent Arikan wrote: Hi, I am trying to import an OpenOffice dbf into a wgs84 PERMANENT Location. I did this several times in the past with older versions of GRASS. I enter all the necessary information (input table, column names for x, y, z and CAT#). The Connection tab shows "dbf" for the driver name and database name reads " $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ " I get this message: DBMI-DBF driver error: Table 'Iron_II_KNOWN_Sites' doesn't exist Stupid question: is Iron_II_KNOWN_Sites.dbf in " $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ " or in a different folder? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ' v.in.db ' question
On Wed, Apr 22, 2009 at 8:46 AM, Hamish wrote: > Bulent Arikan wrote: >> I am trying to import an OpenOffice dbf into a wgs84 >> PERMANENT Location. I did this several times in the past >> with older versions of GRASS. I enter all the necessary >> information (input table, column names for x, y, z and >> CAT#). The Connection tab shows "dbf" for the driver name >> and database name reads " >> $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ " Please also consider db.in.ogr for easy DBF (and other) import: http://grass.osgeo.org/grass64/manuals/html64_user/db.in.ogr.html (ideally in GRASS 6.4.x or 7). >> I get this message: >> >> DBMI-DBF driver error: >> Table 'Iron_II_KNOWN_Sites' doesn't exist >> Missing column in table >> I will greatly appreciate any suggestions. > > maybe it is case sensitive? try key=cat instead of key=CAT. ??? > > [SQL defines column names to be case insensitive, yes?? To my knowledge no. Because e.g. PostgreSQL support upper case column names but you have to quote them. That's the source of the problem here maybe that quoting is needed but cannot be propagated internally or so. Personally I always avoid upper case columns and live happy with that. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ' v.in.db ' question
Bulent Arikan wrote: > I am trying to import an OpenOffice dbf into a wgs84 > PERMANENT Location. I did this several times in the past > with older versions of GRASS. I enter all the necessary > information (input table, column names for x, y, z and > CAT#). The Connection tab shows "dbf" for the driver name > and database name reads " > $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ " > > I get this message: > > DBMI-DBF driver error: > Table 'Iron_II_KNOWN_Sites' doesn't exist > Missing column in table > I will greatly appreciate any suggestions. maybe it is case sensitive? try key=cat instead of key=CAT. ??? [SQL defines column names to be case insensitive, yes?? Did we ever find that in a spec somewhere?] # if you have `dbview` installed, what does this say: dbview -e filename.dbf | head Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] ' v.in.db ' question
Hi, I am trying to import an OpenOffice dbf into a wgs84 PERMANENT Location. I did this several times in the past with older versions of GRASS. I enter all the necessary information (input table, column names for x, y, z and CAT#). The Connection tab shows "dbf" for the driver name and database name reads " $GISDBASE/$LOCATION_NAME/$MAPSET/ dbf/ " I get this message: DBMI-DBF driver error: Table 'Iron_II_KNOWN_Sites' doesn't exist Missing column in table I will greatly appreciate any suggestions. BÜLENT ARIKAN SHESC-ASU___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
