On Jul 6, 2011, at 2:55 AM, kRAkEn/gORe 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.
Ah, sorry did not realize this was a spatialite feature - great to know, we'll keep then :) Lucio - that raises another question I've had for you. My recent work on the sqlite driver has worked to slightly improve the support for using sqlite without spatiallite. Since sqlite supports RTREE indexes natively I allowed the extent to be automatically pulled from the index (if it exists): http://trac.mapnik.org/changeset/2689/trunk/plugins/input/sqlite. Also in that commit I changed the driver to use the native "rowid" for the default primary key instead of the Spatialite PK_UID. Do these seem acceptable to you from the perspective of keeping solid spatialite support? My general thought is that ideally we can support both, nearly automatically. The only thing preventing this is that the user must now manually supply wkb_format="spatialite" to trigger usage of the spatialite geometry (which otherwise fails silently). Ideally we could autodetect a spatialite db, and therefore autodetect the wkb format while throwing if it is not valid. Thoughts? Dane > > 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
