May 2010 - mkgmap-dev - The mkgmap lists

TRE value 4 -- maybe related to intertile routing?
by Felix Hartmann 03 May '10

03 May '10

Where is TRE4 set in mkgmap? I know that TRE values 1-3 are set here: uk/me/parabola/imgfmt/app/trergn/TREHeader.java writer.put3(displayPriority); writer.putInt(0x*110301*); However there is a fourth value which in most Garmin maps is 0xd, whereas we use 0xc. If I use gmaptool to adjust it to any uneven number (like the Garmin default 0xd) then routing does not work at all anymore. But Garmin maps use this value. Therefore I would like to try out what happens if we use mkgmap to directly set the fourth TRE value to different numbers, but I can't find it in the sourcecode.

2 3

Handling of boundary multipolygons
by WanMil 02 May '10

02 May '10

I am thinking about how to handle boundary multipolygons and want get some feedback and ideas from you. There are two possible ways to use boundary information: 1. Draw the boundaries as lines 2. Draw the boundaries as polygons with different colours for different administrative levels I think the 2nd option cannot be realized (at the moment). I see no way how to define a style that differently colours adjoining polygons with rather identical tags (e.g. boundary=adminstrative, admin_level=2). So let's concentrate on the 1st option. One way may be part of different boundary relations. (admin_level=2 && admin_level=3 && admin_level=4 ....). To be able to process all of them with the style system the way must be duplicated for each relation. The multipolygon handling of boundaries might work as follows: For all ways (role=outer and inner) part of the boundary relation - Clone the original way - Tag the cloned way with the boundary information of the mp - Remove all tags from the original way that are also contained in the mp (with the same value) - Split all closed ways (polygons) in two ways to ensure that only ways are tagged with the boundary information What do you think? If no one really complains I will start implementing this (and expect that it will be accepted when I am ready :-). In case other multipolygon type also require such a processing we might add a config file in future which types are handled in this way. So this is ready to be more generic. WanMil

2 10

Problems with Russian landuse multipolygons
by Marko Mäkelä 02 May '10

02 May '10

Hi WanMil, all, Someone has apparently started to import landuse multipolygons in Russia. I keep getting errors for them. Some multipolygons only have "outer" lines. Here are a few examples: http://www.openstreetmap.org/browse/relation/594151 http://www.openstreetmap.org/browse/relation/594273 http://www.openstreetmap.org/browse/relation/595581 http://www.openstreetmap.org/browse/relation/595858 http://www.openstreetmap.org/browse/relation/597112 http://www.openstreetmap.org/browse/relation/597218 http://www.openstreetmap.org/browse/relation/598234 http://www.openstreetmap.org/browse/relation/598527 These are fully within the Geofabrik extract that I have been using. I recently edited the Geofabrik polygon so that no lake multipolygons or natural=coastline islands are severed. Here is one example that is drawn over an existing island multipolygon: http://www.openstreetmap.org/browse/relation/598998 If you download this multipolygon and some surroundings, you should soon get the idea what is wrong with these imports. If the multipolygon handler cannot be made any more robust, then I would appreciate some option that would ignore certain types of multipolygons. Best regards, Marko

3 3