On Wed, Feb 3, 2010 at 5:48 AM, Chris Miller
<chris.miller@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