August 2012 - mkgmap-dev - The mkgmap lists

Style include files
by Steve Ratcliffe 27 Sep '12

27 Sep '12

Hi In the style-include branch (pre-built jar files available at http://www.mkgmap.org.uk/snapshots/) you can now include files from the same style. The syntax is: include "filename"; You can put this anywhere where you can start a new rule. The contents of the file "filename" are included at that point in the file, just as you would expect. You can (and probably should) put the files in a subdirectory and access it as: include "inc/filename"; A forward slash should be used, even on windows (untested - will fix if it doesn't work). You don't strictly need the quotes around the filename if it is only letters, but its best to always use them since common filename characters such as '.' and '/' will require the quotes anyway. An included file can include another file and this can be arbitrarily nested. The name of the file is always relative to the top of the style and not relative to the location of the file that includes it. So if you have a sub-directory 'inc' with files 'first' and 'second' and 'inc/first' wants to include 'second' then it is written as: include "inc/second"; and not: include "second"; You can't yet include files from other styles, maybe that is not really so useful, what do you think? ..Steve

6 12

Suggestion for more flexibility in locator part of mkgmap
by Clifford Nolan 19 Sep '12

19 Sep '12

Hi Greg, Just to clarify ... the admin_levels for Ireland described here http://wiki.openstreetmap.org/wiki/Ireland/Boundaries#Boundary_Types don't seem to mention things like village boundaries - there's a big gap between admin_level=8 and admin_level=10. In situations like this, maybe the locator could be more flexible and use other kinds of boundaries too. Regards, Cliff

3 7

Problem with huge polygon - vänern sea - sweden
by toc-rox 19 Sep '12

19 Sep '12

Hi all, I'm currently working on a map of sweden. I run into a problem concerning the vänern sea (between Vänersborg and Karlstad). This is an very huge polygon / sea - 10 times larger than the german/swiss Bodensee. Only a small part of the sea will be displayed on the as water: http://gis.19327.n5.nabble.com/file/n5710048/Bildschirmfoto_2012-05-24_um_1… Questions: - Has someone a working splitter / mkgmap configuration for sweden ? - I have set the splitter option "-overlap=10000" - could this be insufficient ? Regards Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-huge-polygon-vanern-sea-sweden-… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 11

Address search for Rostock doesn't work
by toc-rox 18 Sep '12

18 Sep '12

Hi all, the address search for Rostock (germany) doesn't works for me. In BaseCamp I see the correct region "Rostock, Rostock, DEU", but no street can be found there. In my Garmin GPSr (Dakota-20) no city with the name Rostock exists - peculiar. I have build new bounds from scratch, based on the current europe extract from geofabrik. Questions: - Does the address search (for Rostock) works for someone ? - How is it possible to verify the bounds and the street entries ? - What's the general procedure to hunt down address search issues ? Regards Klaus http://gis.19327.n5.nabble.com/file/n5716487/Bildschirmfoto_2012-07-13_um_1… -- View this message in context: http://gis.19327.n5.nabble.com/Address-search-for-Rostock-doesn-t-work-tp57… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4

Style functions
by WanMil 04 Sep '12

04 Sep '12

Hi, I have created the branch style-functions to implement functions like mkgmap::length that can be used in the style system. The mkgmap::length function is the first one that has been implemented. It returns the length of a way in metre. For relations it returns the sum of way length of all members. The function can be used like a tag name: highway=* & access=private & mkgmap::length < 10 { delete highway } Calculations are cached. So the mkgmap::length is calculated not more than once per element. Known bugs: - Rules with a function must always contain a tag rule. Otherwise the optimizer disposes the rule. so the rule mkgmap::length < 10 { delete highway } will never be executed. - The length of relations does not always makes sense. E.g. the length of turn restrictions, multipolygons maybe should be not calculated. Steve: can you have a look on it and give your comment if the implementation looks good to you and what you dislike and what you want to change :-) Can you please also give a hint how I can tell the optimizer that functions should always be treated as an existing tag. Do you think it makes more sense to implement the functions as an additional operator? I am free to change the implementation completely :-) WanMil

2 1

understanding style files
by Chris66 03 Sep '12

03 Sep '12

Hi, short question: when I have these lines with action rules : highway=secondary { name 'bla' } highway=* { name 'blupp' } are *both* lines executed for a secondary or only the first one ? Chris

6 9

[PATCH v1] No address information on some POIs
by WanMil 31 Aug '12

31 Aug '12

I've found a bug that results in some POIs (mainly place POIs) that have no address information (so only the default country and default region). The POIs are automatically created by the add-pois-to-areas parameter and originate from multipolygons. This happens if mkgmap is started at least with the parameters --add-pois-to-areas --index --location-autofill=bounds It is important that the location-autofill parameter contains the value bounds only. In this case the add-pois-to-areas takes the middle points of all multipolygons and create a new POI with tags copied from the mp. But the mp has no address information because the LocationHook ignores all relations and multipolygons. The patch fixes that in the LocationHook. It now adds the mkgmap:admin_levelN tags to all mp. It uses the calculated middle point of the mp to query for the bounds information. WanMil

1 0

Fwd: NUVI 3790 map problems
by maning sambale 31 Aug '12

31 Aug '12

Hi. I got this report from a nuvi 3790 user. According to the user other nuvis are not affected. My mkgmap compiler is a really old r1992. Please see attached shots. Maning Sambale ---------- Forwarded message ---------- From: "Herbert Paul Mariñas" <herbertmarinas(a)gmail.com> Date: Aug 31, 2012 7:47 PM Subject: NUVI 3790 map problems To: <emmanuel.sambale(a)gmail.com> Greetings Mr. Manning I was unable to figure out how to post the screenshot i have on your Ensambale site however i will just try to send it thru your Gmail. Your efforts truly has helped a lot of people specially me, my wife and my colleagues However the last update of the map you had is over lapped by the "green" NUVI 37XX series global map image almost half of it. I am currently using the old 100% vieable image ive got last year however the POI's are kinda old I am now tryig to find a way to extract the POI's from your new map to install it to my old map. Hope you could squezze some of your time and muster your genius way to solve this mapping problem. Again I do salute you sir. This indeed is a heroic act not for individuals like me but for the Country this to can boost our tourism sector.

1 0

mp/hh / km/h m or other units in maxspeed or distance keys
by Felix Hartmann 30 Aug '12

30 Aug '12

Well it's quite a long time, there has been no discussion about this, however it's more and more common to put the unit into the main key. Could mkgmap do a clean up on this? It would be great if mkgmap could do the following: Remove any non numeric keys (and not "." or "," ) and place them into a new key called mkgmap:unit=.... Do this for maxspeed, distance, height, width (propose other keys I may have missed). As I'm sure this would take quite some time, it should be an option, and there should be a style-file called units_removed where you can specify the keys for which mkgmap should do this. Of course an implementation of automatically translating mp/h to km/h and other things would be great to have too, but the above is IMHO first of main importance. The problem is simply that commands like maxspeed>50 or distance<10 don't work otherwise. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

4 8

Dead End Check
by Felix Hartmann 30 Aug '12

30 Aug '12

While wondering how to best clean up all those micromapping footway/service/track/path stuff, and thinking about the mkgmap::length filter, I got the idea, that mkgmap got an dead end check. Is there anywhere a description of how it works? Together with mkgmap:length filtering, it could come very very handy in deciding which ways to delete, and which not. (as in only delete short dead end ways). (even though I would really prefer people to use a tag like micromapping=yes for all those stupid ways, which shouldn't be in a general purpose map). Ways as seen here below in the pic, simply shouldn't be included into general purpose maps (hope the pics are small enough for the mailing list): (above image is ~ 165x60m), so many of theese footways are an astonishing 4m long, all are plain highway=footway without any other tags. And they are all dead end. At least the three 4m ones, I would like to get rid of. Why is this so bad? Well if you make a map without buildings, you'll see the disaster, short ways going nowhere: -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

3 4