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