Lucio, Great, thanks for confirming, I agree. I've created a new ticket to track this 'auto' spatialite detection/support:
http://trac.mapnik.org/ticket/798 Dane On Jul 12, 2011, at 12:22 AM, kRAkEn/gORe wrote: > That's is perfectly fine for me. I wonder why i didn't use that already ? > I think however we should support both, as differences are minimal. > I'm just trying to find a way to automagically select the WKB format, > so one doesn't need to specify the wkb_format every time. > > btw i'm using spatialite cause it offers also good tools and libraries > to manipulate/interact with the features in databases. > > cheers > > Lucio > > > On Mon, Jul 11, 2011 at 6:00 PM, Dane Springmeyer <[email protected]> wrote: >> >> 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
