[gdal-dev] Rename and Reorder Layers?

[Nik Sands]

Thanks Even.

I'm mostly working with the SQLite/Spatialite driver so the the SQL query may be a good work around for my first issue.  Thanks for this suggestion.

The second issue sounds more challenging, and I'll have to investigate the VRT file idea, or possibly come up with my own metadata mechanism for managing this.

Cheers,
Nik.


On 17 Jul 2014, at 9:29 pm, Even Rouault <even.rouault at mines-paris.org> wrote:

> Nik,
> 
>> I have two simple questions (not sure if the answers are as simple)...
>> 
>> 1.  Is it possible to rename an OGR layer in place within a writeable data
>> store without first creating a copy of the entire layer?
> 
> There's no provision in the OGR API to do that currently. Although it could be
> nice to have. That would require of course updating the drivers that would
> support that capability, and which are coded currently under the assumption that
> the layer name is immutable.
> For which driver(s) would you be interested to have that capability ?
> 
>> 
>> The only way I've found to do this is to use OGR_DS_CopyLayer() (or similar)
>> and then delete the old layer which is fairly expensive as it has to copy all
>> of the features as well.
> 
> For drivers that are related to SQL databases, issuing an "ALTER TABLE foo
> RENAME TO bar" with ExecuteSQL(), and re-opening the datasource afterwards (OGR
> will not notice the change) should do it.
> 
>> 
>> 2.  Is it possible to change the order of layers within a writeable OGR data
>> store?  (Ie, change the ordering/indexing of layers as they would be
>> retrieved with OGR_DS_GetLayer() ).
> 
> That would be much more involved, not to say impossible. For example, for SQL
> based drivers, the driver list is issued from a request in system tables or
> other tables and there's nothing to control the order of retrieval.
> For filebased drivers, such as a directory of shapefiles, it depends on the
> order of the operating system in which it return the filenames. Nothing you can
> have control on.
> To make it possible reliably would probably involve adding a special OGR
> metadata table with (order_number, layer_name) columns.
> A potential workaround is to use a OGR VRT file as a thin wrapper above your
> "real" datasource. The layers will be ordered in the order they are listed in
> the VRT.
> 
> Best regards,
> 
> Even
> 
> -- 
> Geospatial professional services
> http://even.rouault.free.fr/services.html
>