[GRASS-dev] Vector file naming

[Brad Douglas]

On Fri, 2006-09-08 at 04:34 +0100, Glynn Clements wrote:
> Brad Douglas wrote:
> 
> > > > GRASS 6.3.cvs (hamilton2):/usr/src/grass6 > r.to.vect in=elizabeth.los
> > > > out=elizabeth.los feature=area
> > > > Illegal vector map name <elizabeth.los>. Character <.> not allowed.
> > > > ERROR: Map name is not SQL compliant.
> > > > 
> > > > How do file names conflict with SQL92?  I thought SQL92 only applied to
> > > > file contents.  Is this also being used as a workaround for DBF
> > > > limitations?  What I'm getting at is: Why is '.' not allowed?  Doing a
> > > > quick archive search failed to illuminate any light bulbs in the
> > > > immediate vicinity.
> > > 
> > > Hi Brad,
> > > 
> > > AFAIK '.' is reserved for joins. '_' will work. 
> > > 
> > > See
> > > http://grass.itc.it/grass63/manuals/html63_user/sql.html
> > > -> NOTES
> > > 
> > > It would be nice to have the naiming constraints relaxed but
> > > I am not sure if that's really possible.
> > 
> > '_' is also reserved for matching, so that can't be it.
> 
> No, _ is perfectly legal in column and table names. It is used as a
> wildcard by LIKE, but it isn't significant anywhere else.
> 
> > Maybe a better question is: Why doesn't GRASS distinguish between tables
> > and files (database)?
> 
> Because it isn't limited to the DBF driver.

Perhaps this is what I find most frustrating.  DBF is not spatially
aware, so why should I be forced to adhere to unnecessary requirements?

I find it somewhat embarrassing that I can simply move the directory
containing geometry to the name I see fit without negative side effects.

> > I would much prefer to have GRASS automatically
> > substitute '_' for '.' in the table name so I can keep consistent naming
> > conventions across rasters and vectors.
> 
> That could create a problem if you have both map.1 and map_1, as they
> would both have the same name.

In my experience, I find it much less likely to encounter this error
that the former.

> > It's a usability issue and somewhat annoying. :-)
> 
> FWIW, these issues were pointed out when the new vector architecture
> was initially introduced. This isn't an oversight; it was a conscious
> choice.
> 
> > I guess the real question is: How big of a job would this be?  Radim?
> > If it isn't an overwhelming job, I'd like to propose it for 7.x.
> 
> It would appear to be a big enough job that Radim chose not to do it
> when the issues were originally pointed out.

I understand the logic behind the present behavior, but I believe that
logic would be best served if GRASS ceased to use it's own format and
went with a real spatially aware SQL backend (there are several to
choose from and SQLite as middleware makes interfacing a breeze).
Perhaps, this will be the next incarnation of the vector architecture as
spatial databases have matured significantly in recent years.

GRASS is plagued with usability issues like this that will prevent it
from being a viable competitor to commercial alternatives outside of the
research community.

Ok.  This has been discussed to death.  Back to work, everyone. :-)


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785