February 2010 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] DEM subfile
by Ronny Klier 26 Feb '10

26 Feb '10

A friend and I spend some time on research the DEM subfile too. While still not knowing the real data encoding, I think we found some additional information about the structure. In general a DEM subfile consists of a common header, a specific header (so far as all subfiles), a block of two data sections per zoom level and a block of descriptions for each zoom level: Header - Common - Specific Zoom level data block - Block 1 -- Data 1 -- Data 2 - Block 2 -- Data 1 -- Data 2 .... Zoom level description block - Description 1 - Description 2 There exist at least to versions of the specific header (0x25 byte - old version? - and 0x29 byte). The headers differ only slightly, the additional bytes are (always?) zero. Offset Length 0x00 0x15 common header 0x15 1 different values (MapSource crashes if second bit is set) 0x16 3 all 0 for 0x29 version, different for 0x25 version 0x19 2 number of zoom levels 0x1B 4 0 0x1F 2 size of single description (seen only 3c00 = 60 byte) 0x21 4 Offset of first description block (0x25) 4 All zero The single description blocks describe the structure and position of Data blocks. Offset Length 0x00 2 Index of description block, starting with 0000. This differs between both versions: While 0x25 version counts in high byte (0001), 0x29 version increments lower byte (0100). Maybe this has different meaning. 0x02 4 Unknown (seems to be always 40000000) 0x06 4 Unknown (seems to be always 40000000) 0x0A 4 Values in latitude dimension (vy) 0x0E 4 Values in longitude dimension (vx) 0x12 2 Unknown (always 0) 0x14 2 Block size in data section 1 (add 1) 0x16 2 Unknown (always 0) 0x18 2 Block count in data section 1 (add 1) 0x1A 4 Unknown value (Last byte not zero) 0x1E 2 Record size in data section 1 0x20 4 Offset of data section 1 0x24 4 Offset of data section 2 0x28 4 western boundary (I know this is unusual but non of the bytes has to be zero and the result still fits) 0x2C 4 northern boundary 0x30 4 Pixel resolution latitude (py) 0x34 4 Pixel resolution longitude (px) 0x38 4 Unknown Using these values the size of data section could be calculated as Block size * Block count * Record size Data section 1 could be read as having Block count blocks. Each of them containing Block size records of Record size. In our opinion the records don't hold offset to data section 2: They are often zero and not continuosly growing, which I would expect them to do. For the two lowest zoom levels the bounding box/size for the covered area could be calculated by (vx * px, vy * py) We don't have any glue what to do with data section 2. But this has to be some picture format, because through removing some layers you will get a lower resolution elevation shading in MapSource. Not knowing much about picture formats, data section 2 (in combination with data section 2) may be a header less GeoTiff or Jpeg (or whatever) Hope there's someone out with good ideas Ronny

2 2

Merging adjacent multipolygons
by Marko Mäkelä 26 Feb '10

26 Feb '10

Hi WanMil, Have you looked at merging adjacent multipolygons? There was some controversy on the Finnish forum <http:// forum.openstreetmap.org/viewforum.php?id=15> but I was not alone with the opinion that lakes should be defined as multipolygons, no matter how complex they are, and that large map objects can or should be split to avoid problems with tools. Ways can have at most 2000 points, for instance, and rendering tools can merge them as needed. Currently, Osmarender is flooding Kuopio, even though I did split Lake Saimaa into rather manageable chunks. I guess I should split it further, if the Osmarender bug cannot be fixed easily. But I do not dare to do it now given the strong opposition from one mapper. I think I devised a reasonable means of identifying artificial cuts between multipolygons, which I also applied to the large multipolygons that I defined, in http://www.openstreetmap.org/browse/changeset/3926233 My artificial cuts are untagged lines that are shared between adjacent multipolygons in role=outer, such as this one between Heposelkä (a section of Lake Saimaa) and the rest of the lake: http://www.openstreetmap.org/browse/way/50841967 Note that the browse window currently shows the main lake as inverted, even though the data appears to be OK in JOSM. Osmarender is having trouble with this small multipolygon too, rendering square-shaped blocks of water where the coastline should be. Best regards, Marko

3 5

Fwd: resolution and zoom levels in style files
by Steve Ratcliffe 26 Feb '10

26 Feb '10

Hi, I'm forwarding this mail that ended up at the bounce address rather than going to the list. -------- Original Message -------- Subject: resolution and zoom levels in style files Date: Thu, 25 Feb 2010 03:43:52 +0100 From: Daniela Duerbeck <daniela.duerbeck(a)gmx.de> Reply-To: daniela.duerbeck(a)gmx.de Organisation: GMX To: mkgmap-dev-bounces(a)lists.mkgmap.org.uk Hi All! In the instructions to styles I find that there are 24 zoom levels and 24 is the "most zoomed in". But when I count, I find 27 zoom levels on my Etrex Legend HCx. 27: 5m, 26: 8m, 25: 12m, 24: 20m, 23: 30m, 22: 50m, 21: 80m, 20: 120m, 19: 200m, 18: 300m, 17: 500m, 16: 800m, 15: 1.2km, 14: 2km, 13: 3km, 12: 5km, 11: 8km, 10: 12km, 9: 20km, 8: 30km, 7: 50km, 6: 80km, 5: 120km, 4: 200km, 3: 300km, 2: 500km, 1:800km. Now I would like to know which resolution I should use to make e.g. residential roads appear just at 300 meters. At 500 meters the map gets a bit confusing with all these little streets. At resolution 23 they appear at 120m, with 22 already at 500m. Are there other points to change? Apologies for this beginner's question, but I found no answer. :-( Thanks a lot in advance, Dani

5 4

1point roads with highway shield for POI
by Felix Hartmann 26 Feb '10

26 Feb '10

Sometimes ago I wrote a bit about implementing POI with numbers for cycle node networks. I had thought about it back then already, but did not write about it. It would be great to have the possibility to put a one point road (there has to be some code to make sure it's not munged by the dp-filter) with a highway shield. There would be two use cases: a) cycle node networks. Much better to have a highway shield that shows the number of the cycle node than to have a POI with number graphic (it is not good to trust that a normal label is shown). b) if someone wants to highlight house numbers, this could be used too (of course once many housenumbers are inside osm in the region than this will look strange). c) maybe some other uses. I don't know if this is easily implementable. If it is not difficult it would be great. (a normal POI still has to be created for searchability - so "continue" should be usable nevertheless)

2 2

[PATCH v1] fix for weird turn directions regression
by Mark Burton 26 Feb '10

26 Feb '10

Hopefully fixes the recent regression which caused incorrect turn directions to be issued (most likely to occur when entering roundabouts that have flares). Actually, the bug was there before but it was being masked by some other code that recently got removed so the bug then popped to the surface! Please test. Mark

2 3

[PATCH v1] Reduce number of cuts in multipolygon processing
by WanMil 25 Feb '10

25 Feb '10

The patch reduces the number of cuts that must be performed for each inner polygon. The current code performs one cut for each inner polygon. The patch reduces the number of cuts by selecting cut lines that hit more than one inner polygon at once. This has two advantages: 1. The artefacts on the cut lines in Mapsource are reduced because there are less cut lines. 2. The performance of the mp code for large multipolygons is very much dependend on how many cuts must be performed. Tests in Finland with generate-sea=multipolygon have shown a 75%(!) drop on processing time. In case there are no large multipolygons the performance stays quite the same. WanMil

4 7

Re: [mkgmap-dev] Groundtruth and unzipped osm
by n willink 24 Feb '10

24 Feb '10

Oops have found the answer -- outputfileformat file{0}.osm It helps if you read the manual...

1 0

Groundtruth and unzipped osm
by n willink 24 Feb '10

24 Feb '10

I'm trying to force groundtruth not to generate bz2 files groundtruth ibf2osm --cat 500,50 --ibf area.ibf --outputfileformat file1.osm Without the ' --outputfileformat file1.osm ' I get 2 bz2 files. Unfortunately , using --outputfileformat file1.osm , the first one gets overwritten as file1.osm In other words, it seems --outputfileformat will only create one osm file. I've tried wild cards but to no avail. Is there a way of telling it to 'increment' the files, ie file1.osm,file2.osm ? /Nick

2 1

Commit: r1584: Fixes to the flare road checking.
by svn commit 23 Feb '10

23 Feb '10

Version 1584 was commited by markb on 2010-02-23 22:26:43 +0000 (Tue, 23 Feb 2010) Fixes to the flare road checking. Previously, it would only check flare roads that were connected by a single roundabout arc so it would fail to check those flares whose ends straddled a join in the roundabout. Also, should no longer give a false "flare road direction is wrong" warning when the roundabout connects only to a single flare and no other roads. Still needs more work to cope with the (unusual) situation where a way joins the roundabout between a pair of flair roads. At the moment, those flares won't get checked.

1 0

Use custom icons instead of default Garmin icons for POIs
by Daniela Duerbeck 23 Feb '10

23 Feb '10

Hi! When I add icons in my TYP-files just these show up on the map that are not predefined by Garmin. What must be added in the style to "overwrite" the default icons. Thanks a lot in advance, Dani

1 1