On Fri, Nov 5, 2010 at 09:48, Toby Speight <[email protected]>wrote:
> 0> In article < > [email protected]<aanlktike5uqw%[email protected]> > >, > 0> Chris Browet <URL:mailto:[email protected]> ("Chris") wrote: > > Chris> The tests I've been running with Spatialite for the plugin > Chris> incite me of thinking about a *Spatialite backend* for > Chris> Merkaartor, alongside the traditional memory/XML current way. > Chris> The advantages will be a builtin spatial index (hopefully no > Chris> more "indexing...") and the possibility to load and query far > Chris> greater datasets than is possible today. > > > 0> In article <[email protected]>, > 0> Toby Speight <URL:mailto:[email protected]> ("Toby") wrote: > > Toby> Something I've been contemplating for a while is to build a tool for > Toby> helping find duplicate or very close nodes (without continuously > Toby> switching to and from KeepRight). It sounds like I should hold off > this > Toby> until the spatial index code is stabilised? > > > 0> In article <AANLkTinq7BGp_7EitOz6EnQTLOOqZ6y0= > [email protected]>, > 0> Chris Browet <URL:mailto:[email protected]> ("Chris") wrote: > > Chris> Not necessarily. > Chris> > Chris> Using Spatialite as a backend, the usual Node/Way/Relation > Chris> interface will still be there. What would change is the way > Chris> they are saved/restored and their lifecycle (i.e. they could be > Chris> generated "on-demand" from the backend) > > Okay, thanks. > > Although I haven't started anything yet, I'm expecting to need to build > a spatial index of the relevant area in order to find proximate pairs, > so I thought that the Spatialite index might save me re-implementing > code. > > But I probably need to study the code a bit first. > There is already an in-memory rtree spatial index at the layer level, so you're spared the work anyway ;-) - Chris -
_______________________________________________ Merkaartor mailing list [email protected] http://lists.openstreetmap.org/listinfo/merkaartor
