March 2011 - mkgmap-dev - The mkgmap lists

address unknown?
by n Willink 27 Mar '11

27 Mar '11

Is it possible to show addresses on Mapsource etc? I've tried adding addr=housenumber [ 0 x etc ] addr=* [ etc ] address=* [ etc ] to the points file. However,the img file created using mkgmap does not include the typ number I had reserved. ie looking at the POI Types in the TRE all my other types are listed so I know the addr: doesn't seem to work, or does it? Regards Nick -- View this message in context: http://gis.638310.n2.nabble.com/address-unknown-tp6210854p6210854.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4

Commit: r1905: More sensible resolutions for polygons and lines.
by svn commit 26 Mar '11

26 Mar '11

Version 1905 was commited by marko on 2011-03-26 20:39:13 +0000 (Sat, 26 Mar 2011) More sensible resolutions for polygons and lines. Shrink the map size and improve the drawing speed by omitting more map features in wide zoom levels. Based on a patch by and discussion with Felix Hartmann.

1 0

Sensible resolutions - (or patch 5)
by Felix Hartmann 26 Mar '11

26 Mar '11

Even though the drop small polygons patch does improve mkgmap created maps, there are still really bogus resolutions. take kindergarten polygon (or actually most amenity) which shows up before! primary roads. Light rails (17) that in theory show up before primary roads (only in theory because garmin does not display the railway type before resolution 23, so cutting clutter, but still this is a lot of crap and unused data that the default style puts into the map). There loads of other examples. Certainly landuse like forest is more important on a map like a kindergarten, grave_yard or college and so on. It really seams like, everyone just wanted to see his favourite stuff really early, and by continuing this approach the maps get really overloaded without providing any real information on top. Of course a lot of this has been written when OSM had relatively few information, and showing stuff stupidly early made the map look nice and gave the impression of OSM having lots of data which it had not. Nowadays at least in Western and Central Europe - and especially there where people use mkgmap created maps, there is actually lots of information in OSM and the goal has to be to declutter. That's what this patch does. Adding so many polygons early in a raster map would be somehow okay because it is barely noticeable, and there is no penaly in the time to show it on screen, but on a vector map it is simply not good. On top of the resolutions changes I introduced resolutions 21 and 19 for rendering to have smoother addition of information when zooming. Most of the data is in resolutions 24-22 anyhow (each resolution even if showing the same detail, halves the space needed for including it). Overall I think maps should work out the same size as without this patch (even though there are two resolutions added), but draw much faster on GPS/Mapsource/Qlandkarte GT and give a much better tool for orientation. I don't think adding resolution=23 is good, because it increases map size by more or less 25% (whereas 21 only increases total map size by ~5%, 19 by ~1%) I still left most resolutions 1 step of where I would personally put them, so that in countries with less information the style is still working well. Nevertheless in big cities the map is showing much information too early.

6 24

[PATCH v1] Some inner areas are ignored in mulitpolygon processing
by WanMil 26 Mar '11

26 Mar '11

The multipolygon processing makes heavy use of the java.awt.Area class. Calling List<Area> allAreas = .....; List<Area> toRemoveAreas = .....; allAreas.removeAll(toRemoveAreas); sometimes does not remove the areas in toRemoveAreas but some more. The patch does not longer use removeAll but checks for identity before removing an area. (I hope I found all places...) As a result sometimes some inner polygons were not cut out from the outer polygon. WanMil

1 0

Running mkgmap in Eclipse
by Walter Wright 25 Mar '11

25 Mar '11

Hi, this is my first foray into looking at the mkgmap code so please bear with. I'm trying to run mkgmap in an Eclipse workspace and I've downloaded the r1899 source archive as a starting point. I'm getting a load of errors, mostly around a number of crosby* libraries missing. Is there somewhere I can look to find out what I need to do to pull together a working environment? Also, is Eclipse a suitable IDE for this? It's what I've been working with for the last couple of years so it is comfortably familiar at least. Any help appreciated. Walter

7 14

Commit: r1903: Change signature of get() so that it correctly
by svn commit 24 Mar '11

24 Mar '11

Version 1903 was commited by steve on 2011-03-24 21:52:03 +0000 (Thu, 24 Mar 2011) Change signature of get() so that it correctly overrides the method in the superclass.

1 0

broken charset in latest mkgmap
by Michał Rogala 24 Mar '11

24 Mar '11

Hello! I've just downloaded r1894 ( I've used some older release until today - i don't know which one). Recent changes in charsets broke CP1250 - instead of diacritic letters from polish language i get characters like dashes, pound symbols, etc. best regards Michal Rogala

9 18

Address indexing for non-city places
by Clifford Nolan 24 Mar '11

24 Mar '11

I was experimenting with the address search on Garmin Oregon, Nuvi and in Apple Basecamp. It's a very impressive advance. I noticed that when I was searching for a street that was closer to a "locality" than it is to the nearest "village", then the street was indexed as street/locality and failed to find in address search. Other nearby streets that were closer to the village node got tagged as street/village and were found successfully in the search. I suspect the same would be true in other situations - a street closer to a subordinate place node will not be found. Hope that is clear! Perhaps smaller places like localities, hamlets, etc might have a pseudo city tag that points to the nearest city or village. Would that solve the problem? Thanks, Cliff

2 1

Commit: r1902: Create no polygon for man_made=trench unless area=yes.
by svn commit 23 Mar '11

23 Mar '11

Version 1902 was commited by marko on 2011-03-23 21:42:39 +0000 (Wed, 23 Mar 2011) Create no polygon for man_made=trench unless area=yes.

1 0

Address search broken if TWO maps are exported with Mapsource into ONE gmapsupp.img
by Felix Hartmann 23 Mar '11

23 Mar '11

Hello, I somehow misplaced my GPS and cannot find it right now. But I got the report from someone that when exporting both my Italy and my Alps map together to his Vista HCx, address search is not working. (not that both maps overlap, but tiles are different as different splitter run, though I doubt this is important) If however only one map is sent to GPS, address search works for either map. Can anyone confirm this error or cross it out?

1 0