[GRASS-dev] OGR write access

Markus Metz markus.metz.giswork at googlemail.com
Fri Oct 16 06:32:07 EDT 2009


Hi,

Martin:
> Markus:
>   
>> Then rather implement --u as an option for some modules but not all and not
>> make it global?
>>     
>
> Then we end up with the need to update manually every module which can
> support update mode. Probably we could build a list of modules where
> make sense to have update mode and not (having 'output' parameter).
>   
I think so, too dangerous to make it global. In any case, I don't see a 
way around going through each vector module and see if it could support --u.
>   
>>>> How about a slight modification of Radim's suggestion:
>>>> v.random out=./shapefiles/@OGR,layer=test,format=ESRI_Shapefile
>>>>
>>>> or something similar so that the out option can easily be parsed?
>>>>
>>>>         
>>> yes, anyway it requires adding 'format' modules to the all vector
>>> modules which have 'output' parameter defined
>>>       
>> Hmm, for direct OGR write access, you need to specify the format anyway
>> somewhere? There is already 'format' added to all vector modules which have
>> input defined, can't be too difficult. And as I mentioned before, I think a
>>     
>
> Probably I don't understand, I can't see 'format' parameter only in
> v.out.ogr, v.in.ogr and similar modules. Currently would be possible"
>   
I was referring to grass7 wxGUI e.g. d.vect has a new option element 
called Format with the choices Native and OGR and I suggested to (1) do 
that with e.g. ./shapefiles/@OGR and make that option element a format 
option in the sense of v.[in|out].ogr for output options.
> v.out.ogr input=test dsn=`pwd` type=point -n
> v.external dsn=. layer=test output=test
> v.random out=test n=1000 --u
>
> but probably
>
> v.random map=`pwd`@OGR n=1000 olayer=test format=ESRI_Shapefile
>
> is better approach.
>
>   
>> new output option for output layer could make sense and AFAICT is required
>> for direct OGR write access.
>>     
>
> yes, also olayer would be required. But it would make sense only for
> OGR format, not the native format, am I right?
>   
Thinking about it, there may be problems because some modules may 
produce several output layers in the same output vector map if feature 
cats refer to several layers. No idea how to accommodate that with 
direct OGR write access where each OGR layer needs its own name not 
number. Fetch layer name from input vector, append layer number to map 
name if no layer name available?
> v.extract in=imap layer=1 where="..." out="PG:dbname=db" olayer=omap
> format=PostgreSQL
> v.extract in=imap layer=1 where="..." out=omap format=native
>   
Should work, but preferably use input layer name if available?

Markus M


More information about the grass-dev mailing list