[GRASS-dev] Vector file naming

[Helena Mitasova]

Trevor Wiens wrote:
> On Thu, 07 Sep 2006 12:40:46 +0000
> Brad Douglas wrote:
>
>   
>> On Thu, 2006-09-07 at 13:35 +0200, Markus Neteler wrote:
>>     
>>> On Thu, Sep 07, 2006 at 11:12:18AM +0000, 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.
>>
>> Maybe a better question is: Why doesn't GRASS distinguish between tables
>> and files (database)?  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.  It's a usability issue and
>> somewhat annoying. :-)
>>     
>
> Well...  To my knowledge standard SQL requires a letter as the first
> character of a table name, and after that letters, numbers, or
> underscores are permitted without quotation. If you want to break those
> rules double quotes are required. So the error message is correct.
> Using a period in a table name without double quoting is a violation of
> SQL naming rules. Normally a period is used to related columns to
> tables, aliases etc.
>
> For example
>
> select a.x, b.y
> from schema_one.table_x a, schema_two.table_y b
> where a.q = b.q
>
> Thus it is impossible for SQL to know how to parse this without quotes.
>
>   
>> 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.
>>     
>
> Since we want to improve database support it seems reasonable to
> provide subtle education for GRASS users about SQL sticking with SQL
> naming restrictions. Therefore, it would be more logical to require
> rasters to fit the same naming restrictions as vectors for the 7.x
> line. There will be many users who will hate this idea as they are
> used to using periods in their raster file names, but this would be
> consistent. 
>   
Count me among those who really hate this idea as I have dot in about 
every single raster file name.
And there are a lot of scripts around that use dots in raster names.
It is already a pain to have that restriction in vector data. I am with 
Brad on this one,

Helena
> That said, you are correct that we could implement quoting
> of table names to allow rule breaking naming, but considering the
> difficulties with quotes and bash, this is just a place we don't want
> to go, AFAIC. 
>
> So for 7.x we should do one of two things. One, do nothing, as
> relaxing the naming rules for vectors wouldn't be difficult, but it
> would be unwise and would introduce all new levels frustration for
> users not familiar with SQL. Two, enforce SQL and thus vector naming
> restrictions for rasters for the sake of consistency. 
>
> T
>   


-- 
Helena Mitasova
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmitaso at unity.ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802