[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish 
  Type:  defect   |  Status:  closed 
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  svn-trunk  
Resolution:  fixed|Keywords: 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Comment (by hamish):

 Replying to [comment:16 cmbarton]:
 > Great. I'll look into porting this to 6.5 and 7 soon. It can't be
 > backported because these are out of sync with 6.4, so I'll have to
 > insert them. I just noticed that the my location wizard doesn't
 > launch at all in 7. So I'll need to check on that too.

 I think this was post was intended for #842, not this report which had to
 do with the VAR file.

 but yes, in my tests so far utm+6.4 plain textbox are now working fine. In
 hindsight the spinbox might have just been a mostly a gimic after all.
 typing in two numbers is not much of a burden.

 thanks- the wx location wizard has really become something to be proud of.

 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish 
  Type:  defect   |  Status:  closed 
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  svn-trunk  
Resolution:  fixed|Keywords: 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Comment (by cmbarton):

 Great. I'll look into porting this to 6.5 and 7 soon. It can't be
 backported because these are out of sync with 6.4, so I'll have to insert
 them. I just noticed that the my location wizard doesn't launch at all in
 7. So I'll need to check on that too.

 Michael

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish 
  Type:  defect   |  Status:  closed 
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  svn-trunk  
Resolution:  fixed|Keywords: 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Changes (by hamish):

  * status:  assigned => closed
  * platform:  => Unspecified
  * resolution:  => fixed
  * cpu:  => Unspecified

Comment:

 everything seems to run smoothly enough now. closing bug, noise & all.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish   
  Type:  defect   |  Status:  assigned 
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
--+-
Comment (by neteler):

 Here a related bug:


 {{{
 # Location without dbf/ subdir:
 v.in.sites mysites out=mysites
 Input format: dimension: 2   strings: 0   FP:0
 dbmi: Protocol error
 ERROR: Cannot open database $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
 }}}

-- 
Ticket URL: 
GRASS GIS 
Commonly referred to as GRASS, this is a Geographic Information System (GIS) 
used for geospatial data management and analysis, image processing, 
graphics/maps production, spatial modeling, and visualization. GRASS is 
currently used in academic and commercial settings around the world, as well as 
by many governmental agencies and environmental consulting companies. GRASS is 
official project of the Open Source Geospatial Foundation.___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Michael Barton]

#7: Location wizard: should predefine DB connection for new location
-- 
+-

  Reporter:  neteler  |   Owner:  hamish
  Type:  defect   |  Status:  assigned
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:
-- 
+-

Comment (by hamish):

 Michael:

If we want this to be easily changeable in the future, it should be
dealt with in a central place

 [...]

so that changing it once will switch from a dbf to sqlite default.


 yes, now set by line 9 of include/dbmi.h:
 http://trac.osgeo.org/grass/browser/grass/trunk/include/dbmi.h? 
rev=30545


Thanks. Sounds like this issue is put to rest completely.






(this is how locations are created in the location wizard)


 they needn't be and probably shouldn't be. (unless 'v.in.ogr -c  
locat=',

 but then that's already covered by v.in.ogr)


???

v.in.ogr imports a vector file and creates a new location.

The location wizard creates locations without importing anything. It  
also creates locations in several ways: specifying georeferencing  
information, selecting EPSG code, grabbing georeferencing information  
from a file. AFAICT, g.proj is the appropriate tool to use here.

I'm agnostic about which way is best, except that I don't think that
we should hack it into the location wizard wxPython code.


 It shouldn't need to be in any mapset/location creation code. It  
should be

 dealt with: in a single place, at the time of DB creation, if needed.


Agree.

Michael

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

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish   
  Type:  defect   |  Status:  assigned 
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
--+-
Comment (by hamish):

 Michael:
 > If we want this to be easily changeable in the future, it should be
 > dealt with in a central place
 [...]
 > so that changing it once will switch from a dbf to sqlite default.

 yes, now set by line 9 of include/dbmi.h:
 http://trac.osgeo.org/grass/browser/grass/trunk/include/dbmi.h?rev=30545


 > This has come up periodically over the past year, as lack of a VAR
 > file seems to cause different scattered modules to fail, and is
 > usually puzzling to users as to what is going wrong.

 Name something that still fails and I'll fix it. I don't think there are
 any, but maybe there still is one- I fully accept the need for an audit.

 The main worry I had was for 'v.in.ogr location=' where it will attempt to
 populate a DB table before ever opening the mapset (and so the init.sh
 'db.connect -c' quote-unquote "solution" hasn't had the chance to run).
 But I've just tested that and it correctly creates the VAR file on the fly
 using db_set_default_connection().


 There really shouldn't be a problem with C modules as the vector and db
 libs already had code to automatically create the VAR file as needed
 through the Vect_default_field_info() fn. (further investigation required!
 probably with tools/sql.sh* working backwards from
 db_set_default_connection()).

 {{{
 # a poor test, but ok as a first pass...
 $ cd vector/

 # find C modules which create a DB link:
 $ ADDDB=`grep -rIl Vect_map_add_dblink * | grep -v '/.svn/'`

 # the following will be safe & auto generate VAR as needed:
 $ SAFE=`grep -rIl Vect_default_field_info * | grep -v '/.svn/'`

 # find "A" not in "B" (or B not in A); stuff to investigate:
 $ echo $ADDDB $SAFE | tr ' ' '\n' | sort | uniq -u

 lidar/v.lidar.edgedetection/main.c
 v.db.connect/main.c
 v.transform/trans_digit.c  # ok: default_field() w/o add_dblink()
 }}}

 Ideally the check/create VAR lib fn should be called from the core "create
 new DB" lib fn, if that is not already the case. Thus the db test belongs
 in Vect_map_add_dblink(), Vect_add_dblink(), or Vect_check_dblink(), or
 Vect_write_dblinks() ? By the low-levelness of the last 3 I'd guess put it
 in Vect_map_add_dblink(), *if* Vect_map_add_dblink() is ever called
 without calling Vect_map_add_dblink() first. (and if there is a case like
 that maybe it is a bug?)


 [*] can we rename tools/sql.sh with a more descriptive name?
 sql_lib_tree.sh or something? Is it trivial/hard to adapt that to run for
 SQLite instead of PostgreSQL?



 It WAS a problem from some scripts which created DB tables on their own
 (db.execute, v.db.add*) but AFAIK those are few and have now all been
 fixed for some time. I've now updated those to call 'db.connect -c'.


 > It sounds like this can be fixed 2 ways: change g.proj to create a
 > VAR file when it creates a location

 this is the cart leading the horse and means the VAR creation code must be
 scattered in a bunch of places. Better to funnel the task into one place
 which everything which creates a new table must go past, ie as close as
 possible to when it is actually needed. For the C modules this is
 currently via Vect_default_field_info(), which is for:
  \brief Get default information about link to database for new dblink


 > (this is how locations are created in the location wizard)

 they needn't be and probably shouldn't be. (unless 'v.in.ogr -c locat=',
 but then that's already covered by v.in.ogr)

 > or change modules to gracefully deal with the lack of a VAR file.

 this is the approach which has been taken and AFAIK is fully in place.

 > The ongoing discussion about which of these two ways to fix it has
 > left this unfixed for months.

 No, AFAIK it has been fixed for months already, but hacks were still left
 here and there in the code. Now I've cleaned those up. (r30545, r30546,
 r30547)


 > I'm agnostic about which way is best, except that I don't think that
 > we should hack it into the location wizard wxPython code.

 It shouldn't need to be in any mapset/location creation code. It should be
 dealt with: in a single place, at the time of DB creation, if needed.


 Thus I think it will be safe to again re-disable the 'db.connect -c' call
 in init.sh in SVN/trunk. (due to lingering doubts in 6.3.0 Init.sh is now
 set to create VAR+dbf/ if not there)


 I hope this answers Paul's post of Feb 19 too,


 Hamish

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org

RE: [GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Glynn Clements]

Patton, Eric wrote:

> > see the db.connect help page example for DBF (I usually just cut and
> > paste that to the command line when needed). It accepts variable
> > LOCATION, MAPSET, you don't need to hardcode it. (Be sure to keep the
> > path with $VARIABLES in single quotes!)
> 
> Should each of $GISDABSE, $LOCATION_NAME, and $MAPSET have populated values
> on location startup? These variables always remain blank for each location 
> that
> I try:
> 
> ~ >echo $GISDBASE
> 
> ~ >echo $LOCATION_NAME
> 
> ~ >echo $MAPSET
> 
> ~ >
> 
> are these variables only available from the shell if I export `g.gisenv` or 
> eval `g.gisenv`
> first?

Those are GRASS variables, not environment variables.

The code for the file-based drivers (DBF, SQLite) parses the database
name and replaces any occurences of $MAPSET etc with the value of the
corresponding GRASS variable.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish   
  Type:  defect   |  Status:  assigned 
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
--+-
Comment (by pkelly):

 Here a link to some earlier discussion that didn't make it into the
 request tracker:
 http://www.nabble.com/-GRASS-GIS---7%3A-Location-wizard%3A-should-
 predefine-DB-connection-for-new-location-tt14547177.html#a15543412

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

RE: [GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Hamish]

> Eric:
> >> Thanks for the pointer. I'll hardcode my database paths for now.
> 
> Hamish:
> > see the db.connect help page example for DBF (I usually just cut
> > and paste that to the command line when needed). It accepts
> > variable LOCATION, MAPSET, you don't need to hardcode it. (Be sure
> > to keep the path with $VARIABLES in single quotes!)

Eric:
> Should each of $GISDABSE, $LOCATION_NAME, and $MAPSET have populated
> values on location startup? These variables always remain blank for
> each location that I try:
> 
> ~ >echo $GISDBASE
> ~ >echo $LOCATION_NAME
> ~ >echo $MAPSET
> ~ >
> 
> are these variables only available from the shell if I export
> `g.gisenv` or eval `g.gisenv` first?

If you want to use them as variables from the shell you should use
  eval `g.gisenv`
first. Back in the GRASS 5 days they used to be set all the time but
this caused problems if you had the GUI running and then from the
terminal window you changed e.g. the mapset with g.mapset. The already
launched GUI would not and could not know about the change. So g.gisenv
was created to hold those variables.


But this has nothing (or at least little) to do with the task at hand.
db.connect will parse those variables itself, which is why you have to
enclose them in single quotes when given on the command line- to
prevent the shell from attempting to expand them (into nothing).

so just cut and paste:
 db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'

and it works.


Hamish



  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


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

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Michael Barton]

#7: Location wizard: should predefine DB connection for new location
-- 
+-

  Reporter:  neteler  |   Owner:  hamish
  Type:  defect   |  Status:  assigned
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:
-- 
+-

Comment (by hamish):

 Eric wrote:

I created a new location using today's svn source, and noticed that
db.connect doesn't have its database parameter pre-populated with
$GISDBASE/$LOCATION_NAME/$MAPSET/dbf as it used to; it is now blank.
Possible bug? Would it possible to get the module to at least  
populate

$GISDBASE/$LOCATION_NAME/$MAPSET for this parameter?


 db.connect takes its default driver, database, schema, and group  
settings

 from the $MAPSET/VAR file by way of the db_get_default_*_name() fns.
 (lib/db/dbmi_base/default_name.c)  This is a circular chicken-or-egg
 situation. (the default is to set it back to what it already is,  
which is

 a redundant task)


 Martin:

yes, see
http://trac.osgeo.org/grass/ticket/7

It seems to me that the VAR file should defined for newly created
mapset by default to avoid possible problems.


 that approach deals with the symptoms, but doesn't address the  
underlying

 problem: what to do when the default DB settings are unknown. To be
 robust it needs to be dealt with at module run-time and it needs  
to fail

 in a safe way if the VAR file is somehow damaged.


 A secondary issue is abstracting the default DB settings back to  
one place
 so that when we make the switch to sqlite-as-default, we don't  
have to
 change ad hoc VAR file & dbf/ directory creation code in a dozen  
places.


 - For C code this was already condensed into  
Vect_default_field_info() but

 could be abstracted further*,

 - For shell scripts we can add a new flag to db.connect* to check  
if the

 DB is set, and if not then set it. This would then be called from all
 scripts which create vector tables outside of v.* modules, and  
could be
 used in init.sh too. (although if we have done everything  
correctly then

 we won't need to put it in init.sh or any other mapset creation code;
 thus I suggest we keep it out of init.sh)

 [*] now in SVN/trunk as DB_DEFAULT_DRIVER,  
db_set_default_connection(),
 and 'db.connect -c'. (r30545) Init.sh and various scripts are now  
updated

 to use that.


 Eric:

Thanks for the pointer. I'll hardcode my database paths for now.


 see the db.connect help page example for DBF (I usually just cut and
 paste that to the command line when needed). It accepts variable
 LOCATION, MAPSET, you don't need to hardcode it. (Be sure to keep the
 path with $VARIABLES in single quotes!)


 Martin:

anyway if you run some command which calls Vect_default_field_info()
from Vlib, VAR file is created and default driver set up to dbf.

e.g. g.copy vect=


 i.e. any C vector module which goes down that street should do the  
trick.
 The vector lib will set the default database if it goes to find it  
and

 finds it unset.


 Paul:

Also I posted a suggested solution to the dev list a while ago, but
there were no comments.


 could you post a link to that in the bug report?



It seems to me that the VAR file should defined for newly created
mapset by default to avoid possible problems.


For every mapset, or just for each location? If for every mapset,  
should

it be inherited from whatever the setting for PERMANENT is, or just
blindly set to dbf every time a new mapset is created? If it does  
have
to be created for every mapset and inherited from PERMANENT,  
presumably

the state of the DB connection for PERMANENT can't be determined
without using Vectlib functions? But all the mapset/location-handling
functions are in GISlib, and it would really not be a good idea to  
have

GIS dependent on Vectlib functions (I think). So this is really quite
complicated. Perhaps the functions that deal with the default  
database

settings could be moved out of Vectlib and into GISlib.


 whoa, keep it simple. if it is requested and not set, then set it. as
 long as C vector modules are funneled through a single vector lib
 function which checks & sets, and scripts doing low level stuff don't
 make assumptions, we should be ok.

 Michael:
I'm with Marcus and Martin on this. The potential for problems is  
high

if this is not done; the cost to do it is very small. Can we just go
ahead and make this change to g.proj?


 But it's not high. I commented out the auto VAR file creation  
sometime
 before Christmas, and this is the first actual-usage complaint  
I've heard.
 And it's not even a complaint, Eric just noticed that it wasn't  
set and

 was wondering why.

 [now I've made it live again in init.sh, but I still don't really  
think it
 should be there; at least the 'mkdir dbf/' stuff is out of init.sh  
now]


 AFAIK we a

RE: [GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Patton, Eric]

Eric:
 >> Thanks for the pointer. I'll hardcode my database paths for now.

Hamish:
> see the db.connect help page example for DBF (I usually just cut and
> paste that to the command line when needed). It accepts variable
> LOCATION, MAPSET, you don't need to hardcode it. (Be sure to keep the
> path with $VARIABLES in single quotes!)

Should each of $GISDABSE, $LOCATION_NAME, and $MAPSET have populated values
on location startup? These variables always remain blank for each location that
I try:

~ >echo $GISDBASE

~ >echo $LOCATION_NAME

~ >echo $MAPSET

~ >

are these variables only available from the shell if I export `g.gisenv` or 
eval `g.gisenv`
first?

~ Eric.


<>___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

RE: [GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Patton, Eric]

 Eric:
 >> Thanks for the pointer. I'll hardcode my database paths for now.

Hamish:
> see the db.connect help page example for DBF (I usually just cut and
> paste that to the command line when needed). It accepts variable
> LOCATION, MAPSET, you don't need to hardcode it. (Be sure to keep the
> path with $VARIABLES in single quotes!)

Should each of $GISDABSE, $LOCATION_NAME, and $MAPSET have populated values
on location startup? These variables always remain blank for each location that 
I try:

~ >echo $GISDBASE

~ >echo $LOCATION_NAME

~ >echo $MAPSET

~ >

are these variables only available from the shell if I export `g.gisenv` or 
eval `g.gisenv`
first?

~ Eric.




 
<>___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish   
  Type:  defect   |  Status:  assigned 
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
--+-
Comment (by hamish):

 Eric wrote:
 > I created a new location using today's svn source, and noticed that
 > db.connect doesn't have its database parameter pre-populated with
 > $GISDBASE/$LOCATION_NAME/$MAPSET/dbf as it used to; it is now blank.
 > Possible bug? Would it possible to get the module to at least populate
 > $GISDBASE/$LOCATION_NAME/$MAPSET for this parameter?

 db.connect takes its default driver, database, schema, and group settings
 from the $MAPSET/VAR file by way of the db_get_default_*_name() fns.
 (lib/db/dbmi_base/default_name.c)  This is a circular chicken-or-egg
 situation. (the default is to set it back to what it already is, which is
 a redundant task)


 Martin:
 > yes, see
 > http://trac.osgeo.org/grass/ticket/7
 >
 > It seems to me that the VAR file should defined for newly created
 > mapset by default to avoid possible problems.

 that approach deals with the symptoms, but doesn't address the underlying
 problem: what to do when the default DB settings are unknown. To be
 robust it needs to be dealt with at module run-time and it needs to fail
 in a safe way if the VAR file is somehow damaged.


 A secondary issue is abstracting the default DB settings back to one place
 so that when we make the switch to sqlite-as-default, we don't have to
 change ad hoc VAR file & dbf/ directory creation code in a dozen places.

 - For C code this was already condensed into Vect_default_field_info() but
 could be abstracted further*,

 - For shell scripts we can add a new flag to db.connect* to check if the
 DB is set, and if not then set it. This would then be called from all
 scripts which create vector tables outside of v.* modules, and could be
 used in init.sh too. (although if we have done everything correctly then
 we won't need to put it in init.sh or any other mapset creation code;
 thus I suggest we keep it out of init.sh)

 [*] now in SVN/trunk as DB_DEFAULT_DRIVER, db_set_default_connection(),
 and 'db.connect -c'. (r30545) Init.sh and various scripts are now updated
 to use that.


 Eric:
 > Thanks for the pointer. I'll hardcode my database paths for now.

 see the db.connect help page example for DBF (I usually just cut and
 paste that to the command line when needed). It accepts variable
 LOCATION, MAPSET, you don't need to hardcode it. (Be sure to keep the
 path with $VARIABLES in single quotes!)


 Martin:
 > anyway if you run some command which calls Vect_default_field_info()
 > from Vlib, VAR file is created and default driver set up to dbf.
 >
 > e.g. g.copy vect=

 i.e. any C vector module which goes down that street should do the trick.
 The vector lib will set the default database if it goes to find it and
 finds it unset.


 Paul:
 > Also I posted a suggested solution to the dev list a while ago, but
 > there were no comments.

 could you post a link to that in the bug report?


 > > It seems to me that the VAR file should defined for newly created
 > > mapset by default to avoid possible problems.
 >
 > For every mapset, or just for each location? If for every mapset, should
 > it be inherited from whatever the setting for PERMANENT is, or just
 > blindly set to dbf every time a new mapset is created? If it does have
 > to be created for every mapset and inherited from PERMANENT, presumably
 > the state of the DB connection for PERMANENT can't be determined
 > without using Vectlib functions? But all the mapset/location-handling
 > functions are in GISlib, and it would really not be a good idea to have
 > GIS dependent on Vectlib functions (I think). So this is really quite
 > complicated. Perhaps the functions that deal with the default database
 > settings could be moved out of Vectlib and into GISlib.

 whoa, keep it simple. if it is requested and not set, then set it. as
 long as C vector modules are funneled through a single vector lib
 function which checks & sets, and scripts doing low level stuff don't
 make assumptions, we should be ok.

 Michael:
 > I'm with Marcus and Martin on this. The potential for problems is high
 > if this is not done; the cost to do it is very small. Can we just go
 > ahead and make this change to g.proj?

 But it's not high. I commented out the auto VAR file creation sometime
 before Christmas, and this is the first actual-usage complaint I've heard.
 And it's not even a complaint, Eric just noticed that it wasn't set and
 was wondering why.

 [now I've made it live again in init.sh, but I still don't really think it
 should be there; at least the 'mkdir dbf/' stuff is out of i

Re: [GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Paul Kelly]

On Thu, 13 Mar 2008, GRASS GIS wrote:


for 6.3.0 I have re-enabled automatic VAR creation if it doesn't exist.


more soon.


Attached is a patch (completely untested) that illustrates my idea for 
solving the problem. I think there should also be something in 
lib/gis/make_mapset.c (used by g.mapsets) but there are some complications 
there in relation to inheriting the DB settings; see my earlier mail.


PaulIndex: lib/gis/make_loc.c
===
--- lib/gis/make_loc.c	(revision 29515)
+++ lib/gis/make_loc.c	(working copy)
@@ -48,7 +48,7 @@
 FILE *report_file )
 
 {
-char	path[2048];
+char	path[GPATH_MAX];
 int out_stat;
 
 /* Try to create the location directory, under the gisdbase. */
@@ -69,6 +69,19 @@
 G__put_window( wind, "", "DEFAULT_WIND" );
 G__put_window( wind, "", "WIND" );
 
+/* Create database settings file */
+{
+struct Key_Value *dbsettings = G_create_key_value();
+   
+G_set_key_value("DB_DRIVER", "dbf", dbsettings);
+G_set_key_value("DB_DATABASE", "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/", dbsettings);
+G__file_name( path, "", "VAR", "PERMANENT" );
+G_write_key_value_file( path, proj_info, &out_stat );
+if( out_stat != 0 )
+return -1;
+G_free_key_value(dbsettings);
+}
+   
 /* Write out the PROJ_INFO, and PROJ_UNITS if available. */
 if( proj_info != NULL )
 {
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  hamish   
  Type:  defect   |  Status:  assigned 
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
--+-
Changes (by hamish):

  * status:  new => assigned
  * owner:  grass-dev@lists.osgeo.org => hamish
 * cc: grass-dev@lists.osgeo.org (added)
  * milestone:  6.3.0 => 6.4.0

Comment:

 for 6.3.0 I have re-enabled automatic VAR creation if it doesn't exist.


 more soon.

 Hamish

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Michael Barton]

On Feb 18, 2008, at 4:00 AM, GRASS GIS wrote:


#7: Location wizard: should predefine DB connection for new location
-- 
+-

  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.3.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:
-- 
+-

Comment (by neteler):

 Hi,

 any news here? With the upcoming release we'll get tons of
 requests if we don't solve this problem...

 I still don't understand why Hamish insists to do it the
 complicated way.

 Markus

--
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http:// 
grass.osgeo.org/


Markus,

This really needs to be done in g.proj, although I could hack it into  
the location wizard if needed. From what I was following of the  
discussion, there were some *philosophical* reasons for not doing it,  
but the cost for making a var file is essentially nil and the cost of  
not having one potentially high.


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

Re: [GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[Paul Kelly]

Sorry, just noticed there was a call to action by me in that bug report 
which I missed. Anyway, I think the key issue here is whether or not the 
database connection file is considered an essential part of a valid GRASS 
location.
1. If it *is*, then creation of it should be added to the places that 
crate locations: lib/init/mke_mapset.c and lib/gis/make_mapset.c.
2. If it is *not*, then the vector/db library functions that need to 
access it should be updated to either gracefully fail or create default 
settings on finding it absent, and this behaviour should be made 
consistent in all places.


Whatever way it is, I think adding a check to it in Init.sh is an ugly 
hack that just works around the problem rather than fixing it.


BUT: It seems option 1 is already partially implemented!
lib/init/mke_mapset.c (called if you create a new location using 
g.setproj, or the text-based startup) does indeed create the VAR file. So 
it looks to me that the anomaly is that this has been left out of 
lib/gis/make_mapset.c (called if you create a new location using g.proj, 
r.in.gdal or v.in.ogr or the GUI startup).


If we add creation of the VAR file to lib/gis/make_mapset.c, ideally we 
should also do an audit of the vector modules and remove the functionality 
that creates a default VAR file if not present, as it will no longer be 
needed. What do you think of this solution, Hamish?


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

[GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location

[GRASS GIS]

#7: Location wizard: should predefine DB connection for new location
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.3.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
--+-
Comment (by neteler):

 Hi,

 any news here? With the upcoming release we'll get tons of
 requests if we don't solve this problem...

 I still don't understand why Hamish insists to do it the
 complicated way.

 Markus

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev