- mkgmap-dev - The mkgmap lists

multipolygons: how to flag role=inner role=outer in Style file?
by Minko 27 Feb '10

27 Feb '10

Hi, I have problems rendering this kind of relation: http://www.openstreetmap.org/browse/relation/1525 Many lakes in the Netherlands are automatically tagged (AND import) like this. The lake is a multipolygon, where the outer border is tagged as natural=water (role=outer) and the inner border (for instance an island in this lake) as natural=water (role=inner) too. When I render this, the islands in those lakes are flooded. Of course it would be better not to tag those inner borders at all, or use landuse=* or natural=land Is there a method in the style file to flag ways with role=outer and role=inner from the same multipolygon? What I would like to do is something like this: >From lake A with type=multipolygon and way A1 {natural=water & role=outer} and way A2 {natural=water & role=inner} remove the tag natural=water from way A2 (or retag natural=water to natural=land?) Is this possible? Cheers, Minko

2 1

[PATCH v1] - yet more turn heading adjustment fixes
by Mark Burton 27 Feb '10

27 Feb '10

Hopefully, these changes will fix the bad routing directions we have been seeing recently - please test and report success/failure.

2 1

Help required for style rule
by Mark Burton 27 Feb '10

27 Feb '10

Style gurus, I want to have a rule that matches one way trunk roads. Given that onewayness can be specified with (at least) 3 different tag values (1,yes,true) do I have to have something like the following, or can it be simplified: highway=trunk & (oneway=yes|oneway=true|oneway=1) [...] i.e. does the following mean the same? highway=trunk & oneway [...] Thanks Mark

2 1

Commit: r1586: The patch fixes the copyTags method and adds a null check to the getTagsWithPrefix method (which might have been bigger problem).
by svn commit 27 Feb '10

27 Feb '10

Version 1586 was commited by steve on 2010-02-27 15:01:55 +0000 (Sat, 27 Feb 2010) The patch fixes the copyTags method and adds a null check to the getTagsWithPrefix method (which might have been bigger problem). WanMil

1 0

Method copyTags(..) in Element.java
by WanMil 27 Feb '10

27 Feb '10

Element.java contains the following implementation of copyTags(Element other): /** * Copy the tags of the other element. Only to be used internally * by subclasses. * @param other The other element. All its tags will be copied to this * element. */ public void copyTags(Element other) { if (other.tags != null) tags = other.tags.copy(); } So the copyTags does not add but replace all tags. But only if the other element has tags. This is weird. So I think replaceTags would be a better name and the other.tags==null case should be handled: public void replaceTags(Element other) { if (other.tags == null) tags = null; else tags = other.tags.copy(); } Is this ok or are there any side effects I am not aware of? WanMil

2 2

Commit: r1585: Avoid flooding inland tiles due to bogus coastline segments.
by svn commit 27 Feb '10

27 Feb '10

Version 1585 was commited by markb on 2010-02-27 14:16:37 +0000 (Sat, 27 Feb 2010) Avoid flooding inland tiles due to bogus coastline segments. When using --generate-sea=polygons, bad coastline segments (e.g. anti-lakes) can cause the entire tile to be flooded with sea. This commit suppresses the generation of the sea polygon if the coastline doesn't reach the edge of the tile but ways with "highway" tags (aka roads) do reach the edge of the tile.

1 0

Mysterious icons
by Daniela Duerbeck 27 Feb '10

27 Feb '10

Hi! My new maps show a sandwich for cafe/diner ( http://www.deltadelta.de/nmz/sandwich.png ), chopsticks for cuisine=chinese and a pizza slice for cuisine=italian. But these ar neither original Garmin waypoint icons nor are they defined in the typ file. Where do the come from? Thanks a lot in advance, Dani

1 0

Weird turn instructions
by Carlos Dávila 27 Feb '10

27 Feb '10

At least since version of 12/02/2010 I'm getting some weird turn instructions in places where they worked fine in the past . In this area [1] I get two of these estrange instructions when driving SE from "Avenida Cordel de Merinas" to SW in "Avenida Hernán Cortés". The sequence of instructions (both MapSource and gps) is: 1-Turn right at Avenida de Extremadura (OK) 2-Turn left at Avenida de las Delicias (wrong) 3-Turn right at Avenida de las Delicias (OK) 4-Turn right at Avenida Hernán Cortés (wrong) At 2 there's been no change in the data for a long time. I noticed 4 first time after creating a through_route relation to avoid a "keep left" instruction, but the problem could have been there before. nuvi gives another wrong "turn right" at 3.5 [1] http://www.informationfreeway.org/?lat=39.482090468611915&lon=-6.3719168982…

3 6

Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
by Felix Hartmann 27 Feb '10

27 Feb '10

See screenshot. Happens on both Germany and Alps extract from Geofabrik. I do think that the sea-code is a bit to optimistic whether somewhere is sea or not. Or there is a bug. This happens using: --generate-sea=polygons,extend-sea-sectors,close-gaps=1000 I'll try to see if flooding also happens without "polygons" switch.

3 14

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