WanMil wrote

How do you avoid that land area is filled with the sea/background color? What you describe is the --generate-sea=polygon variant which can be used in combination with --precomp-sea. But this has the disadvantage that you have a background sea polygon covering the whole tile and land polygons on top of it. So if you click on land you always have sea under the land...

Oh, I forgot to mention that Klaus style does also assign something for natural = land If the style is not the right place to handle the problem, I think I must find an estimate for the number of bytes that are needed to save a polygon so that splitter can weight a node in the precompiled sea files. In simple words: Probably splitter should count these nodes with a factor of 2 or 3. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/There-is-not-enough-room-in-a-single-garmin-m... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Henning Scholland wrote

But wouldn't this lead into other problems? If you split some tiles covering Finland, Sweden and Baltic Sea you will have some tiles without any real data. If I remember correct, this will lead to an boot loop on some devices.

Well, if that is the case I should remove the precomp-sea parm completely. If I use it with norway.osm.pbf, I create tiles that have only one way around sweden: http://www.openstreetmap.org/browse/way/165828682 and you are right, it would be possible to see tiles that just contain a bbox. Due to the precomp-sea parm and and the used style mkgmap creates an img file with 13mb for this. The bounding box for this tile contains many small islands so I guess it is okay that mkgmap creates such a huge file? 63240001.o5m <http://gis.19327.n5.nabble.com/file/n5741986/63240001.o5m> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/There-is-not-enough-room-in-a-single-garmin-m... Sent from the Mkgmap Development mailing list archive at Nabble.com.

WanMil wrote

Can you explain more in detail why there are tiles without any real data? From my point of view that shouldn't happen if the sea-density is added after trimming (which is now the case).

Because I use option --no-trim when splitting as this is what Klaus wants to do. In the mean time I tried to understand why the generate-sea option adds so much data to the output file, and I think I found something that might be wrong or a candidate for improvements: We use a PreserveHorizontalAndVerticalLinesFilter that preserves all nodes which lie on a horizontal or vertical line/shape. Later, the DouglasPeuckerFilter is called to remove obsolte points, but all preserved points are excluded from this processing. Up to now I have no idea why this happens, but it seems not to be a good idea for coastlines. Another strange observation: Although my input file doesn't contain a single way with highway=* I see many coord objects with a highwayCount > 1, which in turn means these coords are preserved by the removeShortArcsByMergingNodes() method. I assume this is explained by the fact that the precompiled sea polygons contain the edges of the grid, so many points share the same coords although they are not on a highway. In short: the name highwayCount is missleading. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/There-is-not-enough-room-in-a-single-garmin-m... Sent from the Mkgmap Development mailing list archive at Nabble.com.

GerdP wrote

...

Another strange observation: Although my input file doesn't contain a single way with highway=* I see many coord objects with a highwayCount > 1, which in turn means these coords are preserved by the removeShortArcsByMergingNodes() method. I assume this is explained by the fact that the precompiled sea polygons contain the edges of the grid, so many points share the same coords although they are not on a highway. In short: the name highwayCount is missleading.

No, it's worse: The sea generator adds one sea polygon and one land polygon, both share all (!) points that are one the coast line. All these points are later preserved in the removeShortArcsByMergingNodes() method. So, the coast line is saved very detailed for each resolution. I am pretty sure this is not intended ?

Gerd

The sea generator of course adds the sea area with multiple polygons and also adds the land area with multiple polygons. They are used only if you have an according rule in the style. I don't see a chance to change anything here. The question is why the highwayCount is > 1. I have searched where the highwayCount is increased. Some places are quite understandable but two are conspicuous: 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. 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. WanMil

I don't fully understand what the removeShortArcsByMergingNodes() should do with coast line data and I don't know why the PreserveHorizontalAndVerticalLinesFilter() is needed. Maybe we can omit these routines for ways that were created by the sea generator.

According to my other post I think the problem is not limited to land/sea polygons but to all neighboured polygons sharing nodes. So I do not want to change something locally in the sea generator when we have a common problem. WanMil

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

Hi, Steve Ratcliffe wrote

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.

Attached is a patch that moves the removeShortArcsByMergingNodes() to StyledConverter, so that it now is only called for ways that are converted to MapRoads. As expected, the generated img files are smaller because less points in ways are preserved. I did a quick test if routing still works (on my Oregon), so maybe this is all that has to be done. I still have the feeling that most of the code in this method is obsolete, but it's hard to say when you cannot test it. Gerd removeShortArcs_v1.patch <http://gis.19327.n5.nabble.com/file/n5742932/removeShortArcs_v1.patch> -- View this message in context: http://gis.19327.n5.nabble.com/There-is-not-enough-room-in-a-single-garmin-m... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Gerd, I don't think, that this would be much better, because then you have to fill land-area with polygons. For Norway this means to fill Sweden and Finland. This wont be much better then filling baltic sea. Henning