- mkgmap-dev - The mkgmap lists

How to get a list of all polygon tags used in the style?
by WanMil 03 May '10

03 May '10

In http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q2/008276.html I have noted that there is one shortcome in the multipolygon code. It checks if the mp is tagged with a polygon tag. In that case the tags are copied from the mp otherwise are copied from the element ways. The problem is that the mp code has a (too short) static list of polygon tags (boundary, natural, landuse, land_area, building, waterway). Now my question (to Steve?): How can I get a dynamic list of polygon tags referenced in the style? I need it in the Osm5XmlHandler from where I can give it to the MultiPolygonRelation objects. Have fun! WanMil

1 0

Question about warning
by Carlos Dávila 03 May '10

03 May '10

I'm getting the warning below, but there's no actual way overlapping way 36823507. I know way 4611... is created by mp processing but, why is it overlapping real way?, why doesn't it happen with other multipolygons? 2010/05/02 08:49:24 ADVERTENCIA (RouteNode): 63240001.osm.gz: Similar arcs ((Plaza de Hernán Cortés, http://www.openstreetmap.org/browse/way/4611686018427389076) and (Plaza de Hernán Cortés, http://www.openstreetmap.org/browse/way/36823507)) from http://www.openstreetmap.org/?mlat=39.62629&mlon=-5.41607&zoom=17

4 3

Change mkgmap default options to make mkgmap more userfriendly
by Felix Hartmann 03 May '10

03 May '10

For most people understanding which mkgmap options they should choose, is not easy - as one first needs to have quite thorough understanding. I think in general useful options should be the default - and not stick for ages to old behavior. I'm afraid I make to many mistakes if I change it myself, but I would propose the following default option changes: *changes that only need a default change because one can disable them by setting the value to 0* --reduce-point-density=5.4 --remove-short-arcs=2.8 --location-autofill=1 *option needs to able to be switched off* --generate-sea=extend-sea-sectors,close-gaps=6000 (including this by default, may keep people more aware of coastline nondestruction) *options that would need to be reversed* --supress-dead-end-nodes --adjust-turn-headings --add-pois-to-areas (this seems to be the default behaviour of most renderers now) --ignore-maxspeeds (the current handling sucks, If we would change this to become default, I would be willing to rework the default style to make use of sensible maxspeeds) --route (the default style is routable, hence the default map should be routable too)

5 6

Commit: r1639: Country was only set if is_in:country *and* addr:country were
by svn commit 03 May '10

03 May '10

Version 1639 was commited by steve on 2010-05-03 13:38:23 +0100 (Mon, 03 May 2010) Country was only set if is_in:country *and* addr:country were both set (and then is_in:country is ignored). This makes no sense, so changed so that country is set to is_in:country or failing that addr:country.

1 0

Commit: r1638: Disable dead-end-check for highway=construction.
by svn commit 03 May '10

03 May '10

Version 1638 was commited by marko on 2010-05-03 13:35:55 +0100 (Mon, 03 May 2010) Disable dead-end-check for highway=construction.

1 0

TRE value 4 -- maybe related to intertile routing?
by Felix Hartmann 03 May '10

03 May '10

Where is TRE4 set in mkgmap? I know that TRE values 1-3 are set here: uk/me/parabola/imgfmt/app/trergn/TREHeader.java writer.put3(displayPriority); writer.putInt(0x*110301*); However there is a fourth value which in most Garmin maps is 0xd, whereas we use 0xc. If I use gmaptool to adjust it to any uneven number (like the Garmin default 0xd) then routing does not work at all anymore. But Garmin maps use this value. Therefore I would like to try out what happens if we use mkgmap to directly set the fourth TRE value to different numbers, but I can't find it in the sourcecode.

2 3

Handling of boundary multipolygons
by WanMil 02 May '10

02 May '10

I am thinking about how to handle boundary multipolygons and want get some feedback and ideas from you. There are two possible ways to use boundary information: 1. Draw the boundaries as lines 2. Draw the boundaries as polygons with different colours for different administrative levels I think the 2nd option cannot be realized (at the moment). I see no way how to define a style that differently colours adjoining polygons with rather identical tags (e.g. boundary=adminstrative, admin_level=2). So let's concentrate on the 1st option. One way may be part of different boundary relations. (admin_level=2 && admin_level=3 && admin_level=4 ....). To be able to process all of them with the style system the way must be duplicated for each relation. The multipolygon handling of boundaries might work as follows: For all ways (role=outer and inner) part of the boundary relation - Clone the original way - Tag the cloned way with the boundary information of the mp - Remove all tags from the original way that are also contained in the mp (with the same value) - Split all closed ways (polygons) in two ways to ensure that only ways are tagged with the boundary information What do you think? If no one really complains I will start implementing this (and expect that it will be accepted when I am ready :-). In case other multipolygon type also require such a processing we might add a config file in future which types are handled in this way. So this is ready to be more generic. WanMil

2 10

Problems with Russian landuse multipolygons
by Marko Mäkelä 02 May '10

02 May '10

Hi WanMil, all, Someone has apparently started to import landuse multipolygons in Russia. I keep getting errors for them. Some multipolygons only have "outer" lines. Here are a few examples: http://www.openstreetmap.org/browse/relation/594151 http://www.openstreetmap.org/browse/relation/594273 http://www.openstreetmap.org/browse/relation/595581 http://www.openstreetmap.org/browse/relation/595858 http://www.openstreetmap.org/browse/relation/597112 http://www.openstreetmap.org/browse/relation/597218 http://www.openstreetmap.org/browse/relation/598234 http://www.openstreetmap.org/browse/relation/598527 These are fully within the Geofabrik extract that I have been using. I recently edited the Geofabrik polygon so that no lake multipolygons or natural=coastline islands are severed. Here is one example that is drawn over an existing island multipolygon: http://www.openstreetmap.org/browse/relation/598998 If you download this multipolygon and some surroundings, you should soon get the idea what is wrong with these imports. If the multipolygon handler cannot be made any more robust, then I would appreciate some option that would ignore certain types of multipolygons. Best regards, Marko

3 3

Re: [mkgmap-dev] Change mkgmap default options to make mkgmap more userfriendly
by Greg Troxel 30 Apr '10

30 Apr '10

so we really need a tag for typical_speed, because you're saying that speed limits and typical speeds are not all that well correlated. This is not really about mkgmap.

2 2

Incorrect capitalisation of first letters of every word during mkgmap style processing
by Charlie Ferrero 29 Apr '10

29 Apr '10

Hi list, I use the following style rules to add more information to the names of mountain peaks: natural=peak & ele ~'[\d\s]*m' {name '${name} (${ele})' | 'Peak (${ele})'} [0x6616 resolution 20] natural=peak & ele ~'[\d\s]*ft' {name '${name} (${ele})'| 'Peak (${ele})'} [0x6616 resolution 20] natural=peak {name '${name} (${ele}m)' | 'Peak (${ele}m)' | '${name}' } [0x6616 resolution 20] This works as I would expect, except where the original tags include a space between the elevation and the "ft" or "m" suffix, eg: natural=peak name=Mount Gizmo ele=1200 m This gets processed by mkgmap into a POI with the name "Mount Gizmo (1200 M)" Similarly, natural=peak name=Mount Gizmo ele=1200 ft Gets turned into "Mount Gizmo (1200 Ft)" The same problem crops up when mkgmap converts a postcode from the addr:postcode tab. You end up with addresses like: Place, Some Street, Some Town, UK Sw4 0jg when it should read Place, Some Street, Some Town, UK SW4 0JG Thus mkgmap is capitalising the first letter of all words in names and addresses and lower-casing the rest, even if they were upper-case to start with. Is there any way of stopping mkgmap from doing this? Indeed, is there a reason for it to do this in the first place. -- Charlie

2 2