[mkgmap-dev] Tile boundary artefactsFrom WanMil wmgcnfg at web.de on Tue Apr 6 21:16:23 BST 2010
Am 06.04.2010 12:33, schrieb Steve Ratcliffe: > On 05/04/10 18:35, WanMil wrote: >> I started to make very basic checks to get the source of the tile bounds >> problems. >> >> I created the attached bbox1.osm and bbox2.osm. Both contain one >> rectangular polygon identical to the bounds. After compiling it with the >> default style I see in MapSource that the underlying land polygon >> (yellow) does not match to the data (blue) (see land_diff.png). >> >> Any ideas why this happens? Do you have any hints how I could proceed >> and where I should continue my investigations? >> Up to now I tried to decompile the img file with the Display project but >> failed on the RGN files (will need some time to investigate this). > > I looked at bbox2. Both the background and polygon rectangles in the > map RGN are the same size at every level. > > The issue is probably therefore in the overview map. As this has a > very low resolution it is not possible to accurately represent the map > bounds unless the bounds happen to fall on a low resolution > coordinate. If the tile is produced by splitter it should be > correctly aligned, but for randomly produced tiles there is likely to > be some misalignment. > > When the area in the overview map has to be rounded there are a number > of ways of doing it, each of which work in different cases. The last > change in this area was r1532, a change made by Mark for a particular > use case. I think that something a bit more complex is needed, for > example detecting the outside boundaries of a tile set > and rounding outward just on those, leaving the internal boundaries > rounded as they are (they have to fit without overlapping). > > Once we have a proper overview map then its resolution could be > increased and this would make the problem a lot less noticeable even if > nothing else changed. > > ..Steve Now I start to understand the reason for splitter alignments. I also managed to have a look on the rgn file. I compiled both bbox1.osm and bbox2.osm to one gmapsupp.img. I do not fully understand the rgn file but found one difference between the background polygon and the other polygon. The RGN file (see below) in level 2, subdiv 4 uses a start point for the orchard (type 0x4e) and 4 coordinates. The background polygon (type 0x4b) only uses a start point plus 3 coordinates. Is that a desired behaviour? (Sorry if that's a silly question but I am on rookie level regarding the file format) WanMil RGN excerpt: --------- Level 2, Subdiv 4 ---------------------------------------------------- | | | final at ca, (end 4d) | | | line start 9f to ca 0000009f | 000000 | 4e | Type 4e 000000a0 | 000001 | 00 00 00 | Label offset: 0x000000 000000a3 | 000004 | dd fe | Long delta -291 000000a5 | 000006 | 96 fc | Lat delta -874 | | | Start point 55,99993,8,80009 000000a7 | 000008 | 0e | Bitstream length 14 000000a8 | 000009 | a9 | Base a9 000000a9 | 00000a | 00 c0 b4 61 24 00 00 00 | Bitstream (len: 14, 0xe) 000000b1 | 000012 | b4 e4 ba 0d 00 00 | | | | xsame false, xneg false | | | ysame false, yneg false | | | xbase 12, ybase 14 | | | Coord 56,59972,8,80009 2637738/410114 | | | Coord 56,59972,8,99991 2637738/419426 | | | Coord 55,99993,8,99991 2609786/419426 | | | Coord 55,99993,8,80009 2609786/410114 | | | 6 bits left, 0 | | | 000000b7 | 000018 | 4b | Type 4b 000000b8 | 000019 | 00 00 00 | Label offset: 0x000000 000000bb | 00001c | dd fe | Long delta -291 000000bd | 00001e | 96 fc | Lat delta -874 | | | Start point 55,99993,8,80009 000000bf | 000020 | 09 | Bitstream length 9 000000c0 | 000021 | 99 | Base 99 000000c1 | 000022 | 32 12 00 00 c0 b4 75 1b | Bitstream (len: 9, 0x9) 000000c9 | 00002a | 00 | | | | xsame false, xneg false | | | ysame true, yneg false | | | xbase 12, ybase 11 | | | Coord 55,99993,8,99991 2609786/419426 | | | Coord 56,59972,8,99991 2637738/419426 | | | Coord 56,59972,8,80009 2637738/410114 | | | 0 bits left, 0
- Previous message: [mkgmap-dev] Tile boundary artefacts
- Next message: [mkgmap-dev] Commit: r1626: In case multiple ways were joined to a polygon the polygon was tagged with the union set of tags of all joined ways. This algorithm is not compatible to the tag join algorithm described on the multipolygon relation definition (http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Tagging).
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list