[mkgmap-dev] There is not enough room in a single garmin map for all the input data

Mon Dec 31 06:34:55 GMT 2012

> A large polygon is split up into many smaller ones.  For a tile with a
> large area of sea there will therefore be many more polygons in the img
> file than you would expect from the number of nodes on the coastline.
> So that is one problem. The polygons fragments will be roughly the
> same size and so it would be possible to calculate and allow for them
> in theory.

Yes, I think it's simply a question of finding a suitable factor to weight the number of nodes. 
I'll look again into this when we have decided how to handle the smoothing problems
below.

> 
> The polygon is sliced into fragments with horizontal and vertical
> lines.  This is the reason for the
> PreserveHorizontalAndVerticalLinesFilter; you mustn't allow the
> straight lines of the polygon fragments to be smoothed in any way, or
> else they won't form the complete polygon any more.  We used to get
> triangular shaped pieces of sea. On the other hand a different
> smoothing algorithm was used in the past and so perhaps the new one
> does not mangle straight lines.

I think the problem is that we describe one line (the coast line) with 
two polygons. An algorithm that smoothes the line must make sure that 
it works the same way for both polygons. I assume that this is achived by
feeding only small fragments to the Douglas Peucker algorithm.
The problem is also described here:
http://www.ian-ko.com/ET_GeoWizards/WhitePapers/gw_smooth_generalize.htm

> 
> [As a separate issue, I don't know if the Douglas Peucker algorithm is
> the most suitable one to smooth polygons and if anyone wants to look
> into that, it would be great]

I thought the same way when I worked on the optimizations last year, but did not 
find anything promising.

> 
> > The base class OsmHandler has a method addCoordToWay(..). In this method
> > the highwayCount is increased always - no matter if it is a way or not.
> > This was introduced by merging the way-closing branch.
> > So Steve should have a look on it. I think that's not intended.
> 
> The fact that highwayCount is incremented always is harmless in itself
> and necessary, since at that point we do not know what is a road and
> what isn't (highwayCount is not a great name, except that it is not
> used for ordinary lines). Obviously we shouldn't be doing any specific
> road processing later on and that needs looking into, certainly
> shouldn't be calling removeShortArcsByWhatever() on anything that
> isn't a road.  That whole area of the code is now quite old and was
> written before we knew how routing worked so we might want to
> rearrange it differently now.

I think highwayCount should be replaced by referenceCount.

Yes, the code in removeShortArcsByMergingNodes() is quite confusing, because it does 
two contrary things:
1) It removes a few points with an algorithm that looks similar to the Douglas Peucker 
2) It preseves other points so that they are not removed by the Douglas Peucker 
filter which is used later.
I understand that we must make sure that we don't remove points from a 
highway that are used as junctions (which is related to the highwayCount > 1) , but 
I don't understand the rest of this. 

> 
> > Osm5XmlHandler.startInNode checks for a tag mkgmap:on-boundary. If that
> > is set the highwayCount is increased. So far so good but this is not
> > performed in the PBF and o5m handler. So maybe this can be removed or
> > must be added to the other handlers too.
> 
> This is to support the case where a splitter-like program creates an
> extract that is exactly trimmed to the boundary and has created its
> own boundary nodes. I don't think that anyone does this. However
> it's not wrong and could be added the other handlers if someone does
> use it.

I think if no program needs that we should remove the code.

Gerd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20121231/d0b09e82/attachment.html 