Hi all, the metadata table is something present in spatialite databases (but is there also on oracle too) that allows to query for extent instead of manually specifying it or recalculating everytime.
i find it pretty useful information, and automatize and speed up extent querying for my layers. Lucio On Wed, Jul 6, 2011 at 12:27 AM, Stella Laurenzo <[email protected]> wrote: > Dane, > As soon as I sent that email, I thought "crap, I meant > to propagate index_table_ through the rest of the file." :) It probably > also makes sense to allow it to be set with a parameter instead of always > auto calculated. > I'll see if Lucio knows what's going on with the metadata bits. I'm not at > all familiar with them. > I'll probably circle back around to this on Thursday. > - stella > > On Tue, Jul 5, 2011 at 5:24 PM, Dane Springmeyer <[email protected]> wrote: >> >> Stella, >> Looks good. Only comment is that hat `index_table_` could be leveraged in >> a few more places to avoid `"idx_" << geometry_table_ << "_" << >> geometry_field_`. Could you take a look at that? >> Also, could you pls create a ticket at mapnik trac on this issue, and >> provide just a bit more detail about the use case/design of attachdb. >> Also, I'm not super aware of the history of the metadata_ option. Its >> clear it is an alternate way for the user to provide an extent. But from my >> perspective its pretty ideal to have an RTREE index, and it might be cleaner >> to remove the metadata_ option and just throw if the user does not either >> provide a manual extent (for speedy creation of the datasource) or if it >> cannot be read from a spatial index. What do you think? >> /cc lucio (aka kunitoki) who it think added the metadata option early on. >> Dane >> On Jul 5, 2011, at 3:59 PM, Stella Laurenzo wrote: >> >> Hi all, >> I've got a sqlite database where some of the tables/indexes are in a >> separate database file. In order to use this, I needed mapnik to run an >> "attach database" command at startup. I generalized the solution slightly >> and implemented this in the attached patch, also referenced here on github: >> >> https://github.com/stellaeof/mapnik2/commit/5654bc3ee7cf46657084890ce02bbbbe1c96b101 >> There are three additions/changes to the sqlite plugin in this commit: >> >> Add an attachdb parameter with syntax >> "dbname@dbfile[,dbname2@dbfile2...]". If attached files are not absolute or >> ":memory:" then they are interpreted relative to the original database file. >> Add an initdb parameter which allows arbitrary sql to be run when a >> connection is established. Any attachments are processed before >> initialization sql. This just seemed like a good idea to add since attachdb >> is just a fancy way to populate the list of initialization sql that this >> adds to as well. It may be useful for people to load extensions or set >> other environment level sqlite options. >> Fix the detection logic for finding a spatial index so that it works >> across databases (sqlite_master checks are per database file - >> select...limit 0 and pragma tableinfo checks are "global" to all attached >> databases). This allows the base table to be in one database file and the >> index in another. >> >> I also wrote and committed a new python test that checks all of this out. >> Let me know what I need to do to get this functionality committed. >> Thanks. >> - stella >> >> <mapnik_sqlite_attachdb_5654bc3ee7cf46657084.diff>_______________________________________________ >> Mapnik-devel mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/mapnik-devel >> > > _______________________________________________ Mapnik-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-devel
