[mkgmap-dev] Splitter details question

Thu Jan 14 20:11:44 GMT 2010

Hi Chris,

> 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 know about circular references in practice.  I ran into the forward
references when learning about defining stops in bus route relations.
I learned that in some applications, role=stop members of type=route relations
should be nodes on the ways that constitute the route, while in others it
would be useful to have POIs for passenger wait areas (next to the street)
as members in the relation.  I further understood that the preferred way is
by subrelations, like I did for this short ferry line that you might call
a water bus: http://www.openstreetmap.org/browse/relation/155054
(The passenger wait areas are tagged as highway=bus_stop nodes.)

The route relation has type=site subrelations in role=stop.  Each type=site
subrelation has two nodes, one in role=vehicle and another in role=passengers.
(The latter two role names were not mentioned in the wiki, I made them up.)

I downloaded the area around the above mentioned relation a few times
in JOSM.  Each time, the type=route relation was defined before its
type=site subrelations.

> 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.

Sorry, no.  I don't even know if the OSM XML schema (if one exists; I was
unable to find a copy) allows node, way, relation in an arbitrary order
within the osm element.

> 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.

I have not investigated, but it could be as simple as replacing
version='0.5' with version='0.6' in the osm element.

> 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.

Yes, you would have to store all nodes and flag those that are referenced by
way(s) or rel(s), and not start outputting nodes until all the input has been
consumed.

	Marko