[mkgmap-dev] Making splitter and MultiPolygon code play together

Wed Feb 3 18:52:18 GMT 2010

that will be great enhancement, disk space doesn't matter at all.

On Wed, Feb 3, 2010 at 5:48 AM, Chris Miller <chris.miller at kbcfp.com> wrote:

> Hi Marko,
>
> MM> I understand that this would require deferring the writing of the
> MM> nodes
> MM> until the whole input (nodes, ways, and relations) has been
> MM> consumed.
>
> Currently if either or both of the --mixed and --cache parameters are
> supplied
> to the splitter, a complete pass is made over all nodes/ways/rels anyway,
> so during this pass it should be (almost) possible to determine which nodes
> belong to multipolygons and therefore need special handling.
>
> I'm thinking the best thing to do is to make the cache compulsory (which
> in turn would make --mixed redundant) and once the cache is generated and
> all the multipolygons have been found, an additional pass can be made over
> the ways cache file to determine which nodes fall in which multipolygons
> and dealt with accordingly. Without a compulsory cache in place this would
> be very expensive.
>
> The upside to a compulsory cache is that the code doesn't get too messy and
> performance doesn't suffer much, plus there will likely be other benefits
> in the future too. The downside is that a chunk of disk space will always
> be required by the splitter for writing the cache.
>
> Does anyone have any objections to this? If not I'll take a look sometime
> in the next few days. I'll also look at fixing the lack of support in the
> splitter for relations containing other relations.
>
> MM> By the way, I think that you should restrict this inclusion of all
> MM> nodes only to select relation types (only multipolygons come to my
> MM> mind).
>
> OK, I'll do that for starters and see where that gets us. We can always
> enhance
> the logic in the future if need be.
>
> Chris
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20100203/1d0197d5/attachment.html 