On Tue, Sep 2, 2014 at 2:48 AM, Marko Mäkelä <marko.makela@iki.fi> wrote:

On Mon, Sep 01, 2014 at 09:05:44PM -0300, Nelson A. de Oliveira wrote:

...

Does mkgmap support administrative boundaries defined only by relations? (ie, there isn't any kind of tag in the ways)

This at least used to work. I wrote the "apply" rules for getting names on the boundaries from the relations, separated by "/" or ",". It might have been broken since I wrote the code.

Basically what https://github.com/openstreetmap/mkgmap/blob/master/resources/styles/default... does? Is it necessary to apply other properties, like admin_level?

On Wed, Sep 03, 2014 at 08:52:05PM +0800, Ervin Malicdem wrote:

You need to extract boundary relations data before telling mkgmap to process it.

There are 2 different use cases. One use case is to associate each POI or road (or address index entry) with an administrative area that it is contained in. That is what I would expect the boundary processor to be for. But, this somehow always seemed to work for me (Garmin Edge 705) even without using the boundary processor. The older use case is to generate visible boundary lines in the map. That is what this rule in the 'relations' file of the default style is for: (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } } This combined with these rules in the 'lines' file used to do the trick: boundary=administrative { name '${mkgmap:boundary_name}' } boundary=administrative & admin_level<3 [0x1e resolution 12] boundary=administrative & admin_level<5 [0x1d resolution 19] boundary=administrative & admin_level<7 [0x1c resolution 21] boundary=administrative & admin_level<9 [0x1c resolution 22] boundary=administrative [0x1c resolution 22] boundary=national [0x1e resolution 17] boundary=political [0x1c resolution 19] Near the place I live, there are boundary lines that are boundaries on multiple admin_levels. For example, this section http://www.openstreetmap.org/way/237098468 belongs to 4 boundary relations, and I would expect all 4 names on the line in the Garmin screen, in some order: Vantaa/Sipoo/Helsingin seutukunta/Korson suuralue At some point of time (maybe as a result of WanMil working on the POI-to-area mapping a couple of years ago), I think that this stopped working, and the line only got tagged with only one of the name. With a quick look into a recently generated gmapsupp.img, I did not see any occurrences of "/" that would seem to be for a boundary line. The way 237098468 itself does not carry a name tag, but now I see that it carries the tag admin_level=7. The 'apply' rule in the 'relations' file is only copying the name across, but it does not make any effort to copy the admin_level. Maybe it should? Maybe it should also copy the boundary=administrative tag to the line if it is not already there. This is a tricky situation. I think that the proper thing to do would be is to clone the boundary=administrative member way if it does not carry a boundary=administrative tag. Then, the tag would be added to the cloned way. In that way, you would get both the boundary line and say, a river or a highway that is part of a boundary. An alternative might be to simply add the boundary=administrative tag to the original way, and to use 'continue_with_actions' in the 'lines' file. When it comes to setting the admin_level on the relationship members, it is even more tricky. I guess that one sensible action would be for the 'apply' rule to overwrite the admin_level tag on the member way, if the value on the relation is smaller than the value on the way. In that way, the boundary=administrative way would be tagged with the lowest (most significant) applicable admin_level. Marko