0> In article <aanlktike5uqw+5_zyzo1bpk_ugnyutd9l6cj6pw12...@mail.gmail.com>, 0> Chris Browet <URL:mailto:c...@semperpax.com> ("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 <87r5f029gg....@balti.ashgrove>, 0> Toby Speight <URL:mailto:t.m.speight...@cantab.net> ("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=k7sh1uvw...@mail.gmail.com>, 0> Chris Browet <URL:mailto:c...@semperpax.com> ("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. _______________________________________________ Merkaartor mailing list Merkaartor@openstreetmap.org http://lists.openstreetmap.org/listinfo/merkaartor
