August 2009 - mkgmap-dev - The mkgmap lists

Improving mkgmap's Unicode transliteration
by Ævar Arnfjörð Bjarmason 29 Aug '09

29 Aug '09

I'm going to Greece tomorrow and I noticed to my dismay that mkgmap's transliteration tables for the Greek alphabet were totally missing. So I hacked up a small Perl script which uses the Unicode::UCD and the Text::Unidecode modules to fillin the blanks: avar@aoeu:~/src/mkgmap/resources/chars/ascii$ perl re-transliterate.pl < row03.trans > row03.trans.tmp && mv row03.trans.tmp row03.trans The script and a patch to row03.trans which Works For Me are attached. But of course the tool can also be run on the rest of the files to fill in more blanks. And my script can of course be modified a bit further to spit out transliterations for files not yet in mkgmap row* files. I don't know what the row* files were originally based on but there's a lot of prior art for transliterating Unicode and there's no need to redo all this work for mkgmap. The Unicode Consortium has published transliteration tables (which Text::Unidecode is largely based on), it's much easier to use stuff like that rather than doing all the work yourselves. Anyway, off to pack for my flight.

2 2

[PATCH v5] - min arc length fixes
by Mark Burton 29 Aug '09

29 Aug '09

v5 in case people are still using this patch, i have reissued it without the stuff that is now in commit 1152. if you are using this patch and think it should also be committed - please say - it didn't seem conclusive that is was useful when we last discussed it ----------------- v4 I have gone back to the original ordering of doing short arc removal before clipping as the previous version of this patch badly broke polygons As for arcs whose length is less 5m, I am not convinced they are actually a problem as far as routing is concerned as my tests show that mapsource can happily route through zero length arcs that occur at tile boundaries. It would be good if people who have been obliged to use a minimum arc length of > 0 would provide examples of where the routing is broken. i.e. without using this patch, find an example which doesn't route when --remove-short-arcs is specified but will route when --remove-short-arcs=5 is specified. What is still an issue and was discussed a while ago is the problem where routing will fail (or produce a big diversion) when routing out of one tile into another and then back to a destination in the first tile. That never seems to work, short arcs or not. -------------------- v3 This patch is getting serious! To reduce the number of short arcs that are being generated at tile boundaries, this now clips the ways before the short arc removal is done. However, it isn't a perfect solution because some map data is very hard to deal with: a - If a way crosses a tile boundary right in the corner such that both ends are clipped and the resulting sub-way is less than 5m long, it will fail to fix that. A possible workaround could be to introduce extra points to elongate the arc. b - a much more common problem is where a way forks very close to a tile boundary and more than one of the connected ways cross the boundary so you end up with several boundary nodes that should be merged to remove the short arc(s) but they can't be moved as they are boundary nodes! I believe that this could be fixed by not merging the forking node but, instead, moving it away from the boundary such that the ways connected to it that do cross the boundary are not less than 5m long! Alternatively, adding extra points to elongate the forking arcs could be done. With this patch, I processed a 14 tile map of the Netherlands and it produced 21 of these short arc errors (all due to forks close to the tile boundaries). I then tested the routing at 5 of these positions (using mapsource) and only 1 of the 5 showed any sign of breakage, the other 4 all routed happily in all directions. The one that was broken was a junction of three ways and one pair of the ways had no connectivity but the others were ok. On the upside, the patch removed 147 short arcs introduced by the clipping. So more work is required here to fix the corner cases (ha ha) but please test this patch anyway as I expect it to have problems due to the big change it has introduced. As usual, all feedback is appreciated. ---------------- v2 of this patch not only enables remove-short-arcs by default when routing is in use (as previously discussed on ML) but it also fixes some problems in the way splitting code. I would be grateful if people could test this patch because it could possibly cure some routing failures. Cheers, Mark

3 6

Commit: r1156: Misc improvements to extended type attribute processing.
by svn commit 29 Aug '09

29 Aug '09

Version 1156 was commited by markb on 2009-08-29 12:05:20 +0100 (Sat, 29 Aug 2009) Misc improvements to extended type attribute processing. Morse code light type is now specified as a single letter Attributes values that are keywords can now also be specified as an integer value. Lights can also be specified using polish syntax "(c,r,a),(c,r,a)...".

1 0

Commit: r1140: Added support for extended types.
by svn commit 29 Aug '09

29 Aug '09

Version 1140 was commited by markb on 2009-08-19 10:00:27 +0100 (Wed, 19 Aug 2009) Added support for extended types. These are sometimes called '3-byte types' but the upper 8 bits of the type is not encoded in the map objects (just the lower 16 bits) so any non-zero value for the upper byte has the same effect. Further work is needed to encode the extra bytes that specify stuff like depth and colour + all the detail associated with marine lights.

10 38

gui for areas.list ?
by Chris-Hein Lunkhusen 29 Aug '09

29 Aug '09

Hi, Does there exist a tool for visualization (and maybe editing) of the areas.list ? Chris

6 26

Commit: r1155: Avoid NPE when map objects with extended types have no attributes.
by svn commit 28 Aug '09

28 Aug '09

Version 1155 was commited by markb on 2009-08-28 20:56:08 +0100 (Fri, 28 Aug 2009) Avoid NPE when map objects with extended types have no attributes.

1 0

Commit: r1153: Fix error reporting.
by svn commit 28 Aug '09

28 Aug '09

Version 1153 was commited by steve on 2009-08-28 14:11:41 +0100 (Fri, 28 Aug 2009) Fix error reporting. Normal errors that are detected by mkgmap should just be printed but since multithreading was added, all errors dump out a stack trace. Also unwrap any concurrent execution exception, so the actual problem is at the top.

2 1

addr:housenumber weirdness
by Marko Mäkelä 28 Aug '09

28 Aug '09

Today I noticed that the Garmin Edge 705 displays a POI as follows: 12 Apt 4 Virkatie Vantaa 01510 I had defined the node as follows: addr:country=FI addr:city=Vantaa addr:postcode=01510 addr:street=Virkatie addr:housenumber=12-14 The localized format would be as follows: Virkatie 12-14 01510 Vantaa This format is used in much of Europe (Sweden, Norway, Denmark, Germany, France come to my mind). I can live with the English transposition of housenumber/street and city/postcode, but I wonder how Garmin or mkgmap can transform the "-1" in "12-14" into " Apt ". (Another issue is that Garmin hasn't bothered translating the abbreviation of "apartment" into my menu language (Finnish), "as" for "asunto". Luckily they didn't try to translate it as the word "apt".) I changed the node to read addr:street=14, because while the property can be accessed via two driveways (12 and 14), the entrance is at 14. Marko

1 0

Commit: r1154: Transliterate Greek characters.
by svn commit 28 Aug '09

28 Aug '09

Version 1154 was commited by steve on 2009-08-28 15:02:16 +0100 (Fri, 28 Aug 2009) Transliterate Greek characters. - ?\195?\134var Arnfj?\195?\182r?\195?\176 Bjarmason

1 0

make-cycleways
by Valentijn Sessink 28 Aug '09

28 Aug '09

Hi, While looking into the make-cycleway-code, I notice that a simple tag with "cycleway=lane" (or equivalent) would be enough to make a cycleway. However, if there's no access restriction for cyclists, there's no real need to build an extra way here - or is there? Valentijn

2 3