Hi, 2009/10/16 Markus Metz <markus.metz.gisw...@googlemail.com>: >>> Not sure if I understand right: updating an existing vector map, be it >>> OGR >>> or native, works for some but not all modules. Some modules first copy >>> all >>> or selected primitives from input to output, then modify output, then >>> write >>> output support files. That could cause duplication of all primitives and >>> a >>> bogus result for some modules like e.g. v.generalize, v.clean, v.select. >>> >> >> I was speaking about empty vector maps. Anyway '--u' could be useful >> also for non-empty vector maps. Then you could use e.g. v.select >> without need to patch maps. E.g. >> >> v.select ain=imap1 bin=imap2 out=omap12 ope=within >> v.select ain=imap3 bin=imap4 out=omap34 ope=contains >> v.patch in=omap12,omap34 out=map >> >> with '--u' flag. >> >> v.select ain=imap1 bin=imap2 out=omap12 ope=within >> v.select ain=imap3 bin=imap4 out=omap12 ope=contains --u > Sounds good! Then the module does not need to check if output is indeed > empty when already existing. Still, I'm not so sure if --u makes sense for > all modules.
It's also not clear how to implement 'update' mode for other GIS elements (raster map, ...). >> Of course you can get bogus (duplicate categories, etc.) with --u, it >> depends on the data you are working with. Generally '--u' should >> implement 'append' mode instead of just overwriting files. Of course >> there are some modules which basically cannot support update mode. >> > > 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). >> >>> >>> 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" 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=`p...@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? 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 > Maybe this is one step ahead, first fully implement direct OGR read access > without the need for v.external? yes, I am working on it. >> and modifying >> Vect_open_new() to pass format parameter, etc. >> > > Yes, in principle similar to Vect_open_old(), needs new Vect_open_new_ogr(). Right. Martin -- Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev