Name of boundarys
Hi, currently my maps have only the name of one country for the boundary. I wanted to change that so that the names of both countrys are used and added following rules from the default style: relations: (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } } lines: boundary=administrative { name '${mkgmap:boundary_name}' } boundary=administrative & admin_level<3 [0x1e level 5] boundary=administrative & admin_level<5 [0x1d level 4] or alternative in lines: (boundary=administrative & admin_level=2) | boundary=national { name '${mkgmap:boundary_name}' } [0x1e level 5 continue] boundary=administrative & admin_level=4 { name '${mkgmap:boundary_name}' } [0x1d level 4 continue] But for some reasons this rules don't have any affect on the name of the boundarys. I looked at other OSM maps using the same/similar rules, and it looks like they all have the same problem, I don't see it working anywhere. What is wrong with that rules? Similar rules (but without mkgmap:) works fine for other releations like public transport. Thanks, Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Mon, Sep 19, 2011 at 11:08:59AM +0200, Thorsten Kukuk wrote:
I looked at other OSM maps using the same/similar rules, and it looks like they all have the same problem, I don't see it working anywhere.
What is wrong with that rules? Similar rules (but without mkgmap:) works fine for other releations like public transport.
I can confirm that the multiple boundary names no longer work. They did work when I added the rules to the default style. My possibly-badly-educated guess is that it is related to the processing of boundary relations as multipolygons. This should be easy to confirm by adding --ignore-builtin-relations to the mkgmap options. Best regards, Marko
You can take a look on my maps and my style files, I still see multiple names at the boundaries. In the relation file I have this rule (type=boundary | type=multipolygon) & boundary=administrative & admin_level=2 { apply { set boundary2=yes; set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}'; } } In the line style this rule boundary2=yes { name '${mkgmap:boundary2_name}' } [0x1e resolution 16] On my maps you see at the Dutch/German border in the tooltip label "Nederland/Deutschland" Maps: http://openfietsmap.nl (Benelux & Germany) Styles: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts
On Mon, Sep 19, Minko wrote:
You can take a look on my maps and my style files, I still see multiple names at the boundaries.
In the relation file I have this rule
Thanks, that's working fine for me, too. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Mon, Sep 19, 2011 at 09:14:45PM +0200, Thorsten Kukuk wrote:
On Mon, Sep 19, Minko wrote:
You can take a look on my maps and my style files, I still see multiple names at the boundaries.
In the relation file I have this rule
Thanks, that's working fine for me, too.
As you both seem to be based in Germany and Germany has good coverage of boundary=administrative, do you see a need for the multipolygon processing of boundaries? My understanding is that multipolygon processing only makes sense when there are polygon style rules for the multipolygon members. For boundaries, there typically are no polygon rules. If there are, they would be very specific (such as, draw a polygon for a particular area). Marko
On Mon, Sep 19, Marko Mäkelä wrote:
On Mon, Sep 19, 2011 at 09:14:45PM +0200, Thorsten Kukuk wrote:
On Mon, Sep 19, Minko wrote:
You can take a look on my maps and my style files, I still see multiple names at the boundaries.
In the relation file I have this rule
Thanks, that's working fine for me, too.
As you both seem to be based in Germany and Germany has good coverage of boundary=administrative, do you see a need for the multipolygon processing of boundaries?
I'm not really sure if I understand you correct. To draw a boundary, you don't need multipolygon processing of boundaries. But if you want to know the tags like the name of the boundary, you need the informations from the multipolygon. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Mon, Sep 19, 2011 at 09:59:29PM +0200, Thorsten Kukuk wrote:
On Mon, Sep 19, Marko Mäkelä wrote:
As you both seem to be based in Germany and Germany has good coverage of boundary=administrative, do you see a need for the multipolygon processing of boundaries?
I'm not really sure if I understand you correct. To draw a boundary, you don't need multipolygon processing of boundaries. But if you want to know the tags like the name of the boundary, you need the informations from the multipolygon.
The built-in processing of multipolygon relations in mkgmap seems to break the copying of boundary names from the boundary relations to the boundary names in the mkgmap default style. You verified this by confirming that adding --ignore-builtin-relations to the mkgmap options will copy the names of all boundaries to the boundary lines. As far as I understand, the built-in processing of multipolygons should only be useful when generating polygons (areas). The typical use case of boundaries is to draw boundary lines, not to colour the areas limited by the boundaries. Therefore, it would seem to make sense to implement an option for disabling or enabling the built-in multipolygon processing of boundary relations. Best regards, Marko
On Tue, Sep 20, Marko Mäkelä wrote:
On Mon, Sep 19, 2011 at 09:59:29PM +0200, Thorsten Kukuk wrote:
On Mon, Sep 19, Marko Mäkelä wrote:
As you both seem to be based in Germany and Germany has good coverage of boundary=administrative, do you see a need for the multipolygon processing of boundaries?
I'm not really sure if I understand you correct. To draw a boundary, you don't need multipolygon processing of boundaries. But if you want to know the tags like the name of the boundary, you need the informations from the multipolygon.
The built-in processing of multipolygon relations in mkgmap seems to break the copying of boundary names from the boundary relations to the boundary names in the mkgmap default style. You verified this by confirming that adding --ignore-builtin-relations to the mkgmap options will copy the names of all boundaries to the boundary lines.
As far as I understand, the built-in processing of multipolygons should only be useful when generating polygons (areas). The typical use case of boundaries is to draw boundary lines, not to colour the areas limited by the boundaries. Therefore, it would seem to make sense to implement an option for disabling or enabling the built-in multipolygon processing of boundary relations.
Ok, yes, I think that would make sense. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Mon, Sep 19, Marko Mäkelä wrote:
On Mon, Sep 19, 2011 at 11:08:59AM +0200, Thorsten Kukuk wrote:
I looked at other OSM maps using the same/similar rules, and it looks like they all have the same problem, I don't see it working anywhere.
What is wrong with that rules? Similar rules (but without mkgmap:) works fine for other releations like public transport.
I can confirm that the multiple boundary names no longer work. They did work when I added the rules to the default style.
My possibly-badly-educated guess is that it is related to the processing of boundary relations as multipolygons. This should be easy to confirm by adding --ignore-builtin-relations to the mkgmap options.
With --ignore-builtin-relations the rules are working again. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
participants (3)
-
Marko Mäkelä -
Minko -
Thorsten Kukuk