I have entered this as TRAC 793 (http://trac.mapnik.org/ticket/793)
- stella On Wed, Jul 6, 2011 at 2:55 AM, kRAkEn/gORe <[email protected]> wrote: > 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
