logo separator

[mkgmap-dev] Splitter details question

From Chris Miller chris.miller at kbcfp.com on Thu Jan 14 14:23:13 GMT 2010

Hi Marko,

MM> Relations can contain forward references to member relations
MM> (subrelations). The forward references are unavoidable in the
MM> general case, because there may be circular references, for example.
MM> Even small map extracts downloaded by JOSM may contain forward
MM> subrelation references even for tree-like relation hierarchies.

Currently the splitter throws away references between relations. It's on 
my todo list to fix - initially I thought this would be quite tricky to support 
efficiently but I have since realised I can solve it without too much trouble. 
I hadn't realised that forward and even circular references were common though 
so thanks for pointing that out, I'll need to bear that in mind when I add 
support for it. I don't think it'll be too much of a problem to handle given 
there are far fewer relations than there are nodes.

MM> I implemented deferred lookup of subrelations in mkgmap's OSM XML
MM> parser. The parser still throws away forward references to nodes and
MM> ways.

Do you know of any cases where ways or rels have forward references to nodes, 
ie have you seen that happen in the wild? I think the splitter can actually 
handle these sorts of forward references now, as long as the cache is used. 
The split files that are output won't have any forward references. I guess 
this means that "splitting" one of these files to a single output file would 
clean it up so mkgmap could then use it :)

MM> It has been pointed out earlier that JOSM refuses to load the files
MM> from splitter.  Sometimes, it might be useful to load files to JOSM
MM> for troubleshooting.  But JOSM cannot load big files anyway.  Could

Hmm, do you know why it can't load them? Maybe it's an easy fix. I'll add 
it to the todo list to investigate.

MM> there be some filter for "normalizing" the output?  And another
MM> filter for throwing out uninteresting elements or attributes, so
MM> that the tile becomes small enough for JOSM?  Perhaps something like
MM> this already exists?

Nothing like this already exists that I know of but it's something I've thought 
about in the past (with the aim of generating more appropriate tile sizes). 
I guess ideally the splitter could take a filter from mkgmap and split based 
on the filtered data. Unfortunately I suspect it will still be quite difficult 
to throw away nodes that are no longer referenced because the only way(s) 
and/or rel(s) that were referring to those nodes were filtered out.

Chris






More information about the mkgmap-dev mailing list