Michael, In Mapsource you can adjust the projection angle of each map with Ctrl Alt A if that is what you are looking for. In Basecamp it only works by editing the windows registry parameters (ProjectionAngle in HKEY_CURRENT_USER\Software\Garmin\SharedSettings\Products) or by setting it in Mapsource. Regarding the land background you can choose your own background with --generate-sea=land-tag=key=value (default is natural=land). If you don't specify a label, it says "unknown area" or "land, non urban" If you specify a label but don't fill in anything (i'm using typ viewer) then it displays nothing but a tiny empty text box. You can also try to remove 0x4b from your typ file.

Michael wrote:

This sounds quite promising, I will try it out. Basically I could leave the default unchanged and assign the desired ID to natural=land in the polygons style?

yes, but bare in mind that natural=land is also a common OSM tag. If someone wants to render an island in a lake with natural=land and you render natural=land as background, the island disappears under the lake. On the other hand, the opposite is also possible, when you have an island as natural=land and a lake on this island with natural=water. If you want to put natural=land above natural=water then the lake disappears. This kind of tagging is obsolete, since it is more common now to use multipolygons to avoid those problems, so I think using a background polygon for natural=land should be fine.

Hi Michael,

But I think Minko got it by pointing to the viewing angle in Mapsource.

sure, Minkos explanation is much better. Gerd

Felix Hartmann schrieb:

The actual reason for this problem is, that Mapsource >=6.14 and Basecamp cache the map before/while you view it. Therefore it needs to fix the projections. Hence - the more out of the center of the map you move (south/north), the more distorted it will be. Moving east/west of course doesn't create distortion.

Thank you Felix, now it's clear. I had confused "projection angle" with "viewing angle" (the angle at which a viewer is looking to the map, caused by a tilt of the map). If the projection angle is the latitude for which the correct horizontal width of the map display is calculated, it is clear that areas north of this latitude get stretched, while areas south of it are shown squeezed. Although I am creating a map for Germany, there are some huge but almost empty tiles up to N 60°. One of them covers the whole area between Berlin and Helsinki, others are far out on the Atlantic Ocean, west of Scottland. If Mapsource automatically selects an projection angle in the middle between the points with the max. and the min. latitude, this will result in a projectoion angle of more than 50° for my map and so almost the whole area of Germany appears to be squeezed. Is there an easy way to remove these tiles from the map (I think they only contain ferry lines, pipelines etc.) without using --keep-complete=false for the splitter and without causing artifacts by cutting the contour lines (they are merged to the OSM data before splitting)? Thank you, Michael

GerdP schrieb: Hello Gerd,

Michael Prinzing-3 wrote

...

Although I am creating a map for Germany, there are some huge but almost empty tiles up to N 60°. One of them covers the whole area between Berlin and Helsinki, others are far out on the Atlantic Ocean, west of Scottland. If Mapsource automatically selects an projection angle in the middle between the points with the max. and the min. latitude, this will result in a projectoion angle of more than 50° for my map and so almost the whole area of Germany appears to be squeezed.

Is there an easy way to remove these tiles from the map (I think they only contain ferry lines, pipelines etc.) without using --keep-complete=false for the splitter and without causing artifacts by cutting the contour lines (they are merged to the OSM data before splitting)?

Strange. When I create a map for Germany the tiles are not covering much more. I assume the problem is caused by the SRTM data.

I'll have a deeper look into this, but I cannot imagine the contour data being the cause. I've created the contour data for the rectangle 47.15 5.75 55.15 15.15 This is a lot smaller than the areas covered by the almost empty tiles. Even more, I am splitting the contour lines into parts, none of them consisting of more than 2000 nodes, and then I am using osmosis to cut them to the shape of Germany. I have to use osmosis' parameter completeWays=yes when I am doing this, but even if 1999 out of the max 2000 nodes of a contour line are outside the bounding polygon this should be no more than a few kilometers. It's difficult to find the few data inside the huge and almost empty tiles without coastlines and cities, but at N 54° 42,0' E 13° 51,0' for example there are 3 ferry lines crossing: "Swinoujscie - Trelleborg", "Finnlines" and "Klaipeda - Kiel". All these lines leave the area my map should cover and seem to be included completely.

You can use a polygon file with splitter to make sure that you only get tiles for the wanted area.

Isn't a line starting inside the bounding polygon and ending outside inluded completely if --keep-complete=false is not set? Thank you, Michael

Gerd Petermann schrieb: Hello Gerd,

...

47.15 5.75 55.15 15.15

This is a lot smaller than the areas covered by the almost empty tiles. Even more, I am splitting the contour lines into parts, none of them consisting of more than 2000 nodes, and then I am using osmosis to cut them to the shape of Germany. I have to use osmosis' parameter completeWays=yes when I am doing this, but even if 1999 out of the max 2000 nodes of a contour line are outside the bounding polygon this should be no more than a few kilometers.

It's difficult to find the few data inside the huge and almost empty tiles without coastlines and cities, but at N 54° 42,0' E 13° 51,0' for example there are 3 ferry lines crossing: "Swinoujscie - Trelleborg", "Finnlines" and "Klaipeda - Kiel". All these lines leave the area my map should cover and seem to be included completely.

The question is only the bounding box, because that is used to calculate the tiles. So, maybe osmosis calculates a new bbox on the data in the files.

Yes, the problem was the bounding box, and it has to do with a change in Osmosis. Versions 0.40 and newer do not write a bounding box to the target file of a merge task if at least one source file has no bounding box. Version 0.39 wrote a bounding box to the target file in this case. My contour data does not include a bounding box, so merging the original germany.osm.pbf with my contour data resulted in a file without a bounding box.

In that case you should pass a bbox or polygon to osmosis.

This will of course eliminate the data outside the desired area, but even when using --bounding-box while merging the files with Osmosis 0.40 or newer there is no bounding box written to the target file! I think I will add a bounding box manually to my contour data. Passing a bounding box to the splitter does also work. Thank you, Michael