[mkgmap-dev] [PATCH v1] remove bogus nodes

Sat Nov 28 10:41:57 GMT 2009

Hi Johann,

Sorry for not replying sooner, I have been concentrating on fixing the
bug that Felix unearthed.

> in general i like this idea. Removing superfluos nodes also improves the 
> dp filter, as it can remove more nodes. I would be very pleased, if with 
> this patch it would be possible to store the information of the 
> resolution of the GType in the nodes. Do you think it is possible? This 
> would help me very much with the missing part of the dp filter.

Not 100% sure exactly what you want storing in the nodes. However, in
principle, we can store what we like as long as we don't mind the
space overhead.

> But now I am a little confused with the incHighwayCounter function. I 
> see that it is used in different situations to mark a point as a node, 
> e.g. border nodes, street end nodes or splitting nodes. Would this work 
> after your patch?

Yes, I certainly hope so.

> Also I think the highway count gets counted up while importing, 
> afterwards it is set to zero and then counted up again. Could the first 
> step be ommited?

The highway counts simply track how many ways reference each point.
If a point has a highway count > 1 then it's a candidate for being a
routing node. At the moment, that info is used in the OSM input class
to do the short arc removal. That can only be done when all the
ways/relations/nodes have been read in.

I think that all of the processing from the reading of the XML to
the point where the map objects are added to the map could do with
refactoring to simplify how it works and to remove redundant operations.
However, that's a big job and as what we currently have basically works
pretty well, it will have to wait until someone has enough free time to
work on it. Personally, I would rather spend time working on adding new
features and improving the routing quality.

So yes, to answer your question, almost certainly the highway counting
code could be refactored to only do it once. Mind you, even with very
big tiles the highway counting introduced by this patch in
StyledConverter takes of the order of 1 second to do so it's not a big
overhead.

> Last comment:
> I think, but am not sure, that with this large lists (>10000) a 
> LinkedList<> performs much better than a ArrayList<>. Would need some 
> testing.

I guess that rather depends on how the list is grown when the array
fills up. If it gets doubled in size then it won't need to be
reallocated a lot of times. The downside of the linked list is probably
just that it will take up a lot more space. However, these lists get
thrown away as  soon as the ways have been processed.

If you want to see if linked lists go quicker, please let us know the
results.

Cheers,

Mark