Handling of boundary multipolygons
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
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
Why talking so long? Implementation was quite easy so please try this patch and post what you think about this patch. I will post v2 with some more comments in the source code if it should be committed. WanMil
On 17.04.2010 20:00, WanMil wrote:
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
Why talking so long? Implementation was quite easy so please try this patch and post what you think about this patch.
I will post v2 with some more comments in the source code if it should be committed.
WanMil Hallo WanMil Well I do think the patch is working as supposed. However that is not really what I find useful. Now on country boundaries there are sometimes 10 boundaries on top of each other - is this what you want to achieve? I'ld much rather have only the boundary with the highest admin level - and have taken quite a bit of code into the style-file to make sure ONLY the boundary with the lowest admin_level is put inside the map. Your patch makes my style-file useless.
I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve??? BTW - I'ld much rather have a patch that disables sea, if there are more than 500 highway=residential inside the sea polygone, or something similar to detect that nothing is flooding. Just day before yesterdays alp extract from Geofabrik had one tile inside flooded, and there is the dreaded flooding inside Germany as allways (well this one due to geofabrik cutting). Maybe you could write a patch for that problem. I get tons of comments on my website about sea flooding, no matter in how many places I write that this is not solvable and any comment regarding sea flooding will get into the trashbin...
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 17.04.2010 20:00, WanMil wrote:
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
Why talking so long? Implementation was quite easy so please try this patch and post what you think about this patch.
I will post v2 with some more comments in the source code if it should be committed.
WanMil Hallo WanMil Well I do think the patch is working as supposed. However that is not really what I find useful. Now on country boundaries there are sometimes 10 boundaries on top of each other - is this what you want to achieve?
Hi Felix, yes that's exactly what the patch does and should do. Up to now the boundary information is available at many different places. For some boundaries the tags are in the relation. For some the tags are in the relation and some lines are additionally (and iconsistently) tagged with the boundary information. Other relations are not tagged and get their tags from the outer ways. And in all situations some ways contain other tags like highway=residential and so on. From my point of view the situation is quite chaotic. The patch standardizes the above situation in the way that for each boundary a line is created with the boundary tags and these tags are removed from the source lines. So in the end I get distinct lines for each boundary. As you have observed this results in overlapping lines if you have multiple boundaries (which is usual). So far so good. That's a good base to discuss what is really needed by you and other style implementors. My knowledge of the style system is quite basic so I don't know what's useful. But I am quite sure that's not the chaotic situation described above. WanMil
I'ld much rather have only the boundary with the highest admin level - and have taken quite a bit of code into the style-file to make sure ONLY the boundary with the lowest admin_level is put inside the map. Your patch makes my style-file useless.
I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve???
BTW - I'ld much rather have a patch that disables sea, if there are more than 500 highway=residential inside the sea polygone, or something similar to detect that nothing is flooding. Just day before yesterdays alp extract from Geofabrik had one tile inside flooded, and there is the dreaded flooding inside Germany as allways (well this one due to geofabrik cutting). Maybe you could write a patch for that problem. I get tons of comments on my website about sea flooding, no matter in how many places I write that this is not solvable and any comment regarding sea flooding will get into the trashbin...
Hi Felix, yes that's exactly what the patch does and should do. Up to now the boundary information is available at many different places. For some boundaries the tags are in the relation. For some the tags are in the relation and some lines are additionally (and iconsistently) tagged with the boundary information. Other relations are not tagged and get their tags from the outer ways. And in all situations some ways contain other tags like highway=residential and so on. From my point of view the situation is quite chaotic.
The patch standardizes the above situation in the way that for each boundary a line is created with the boundary tags and these tags are removed from the source lines. So in the end I get distinct lines for each boundary. As you have observed this results in overlapping lines if you have multiple boundaries (which is usual).
So far so good. That's a good base to discuss what is really needed by you and other style implementors. My knowledge of the style system is quite basic so I don't know what's useful. But I am quite sure that's not the chaotic situation described above.
WanMil
I have one other idea that might be useful: If the relations are more useful for style writers than the line information the specialized multipolygon code could ensure that the boundary tagging is always and completely in the relation. Boundary information from the lines would be removed. Example: Relation 1: mp: type=multipolyon, boundary=administrative way 1: role=outer, boundary=administrative, admin_level=4, name=ABC region, ... way 2: role=outer, boundary=administrative, admin_level=4, highway=residential, name=ABC region way 3: role=inner, boundary=administrative, admin_level=4, name=ABC region, ... After processing: mp: type=multipolyon, boundary=administrative, admin_level=4, name=ABC region way 1: ... way 2: highway=residential way 3: ... Relation 2: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: role=outer, boundary=administrative, admin_level=5, ... way 2: role=outer, boundary=administrative, admin_level=5, highway=residential, name=Weaverstreet way 3: boundary=administrative, ... After processing: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: ... way 2: highway=residential, name=Weaverstreet way 3: ... So with other words: Style implementors can alway rely on the relation information and need not to filter out boundary information from the lines. WanMil
On 18.04.2010 21:35, WanMil wrote:
Hi Felix, yes that's exactly what the patch does and should do. Up to now the boundary information is available at many different places. For some boundaries the tags are in the relation. For some the tags are in the relation and some lines are additionally (and iconsistently) tagged with the boundary information. Other relations are not tagged and get their tags from the outer ways. And in all situations some ways contain other tags like highway=residential and so on. From my point of view the situation is quite chaotic.
The patch standardizes the above situation in the way that for each boundary a line is created with the boundary tags and these tags are removed from the source lines. So in the end I get distinct lines for each boundary. As you have observed this results in overlapping lines if you have multiple boundaries (which is usual).
So far so good. That's a good base to discuss what is really needed by you and other style implementors. My knowledge of the style system is quite basic so I don't know what's useful. But I am quite sure that's not the chaotic situation described above.
WanMil
I have one other idea that might be useful:
If the relations are more useful for style writers than the line information the specialized multipolygon code could ensure that the boundary tagging is always and completely in the relation. Boundary information from the lines would be removed.
Example: Relation 1: mp: type=multipolyon, boundary=administrative way 1: role=outer, boundary=administrative, admin_level=4, name=ABC region, ... way 2: role=outer, boundary=administrative, admin_level=4, highway=residential, name=ABC region way 3: role=inner, boundary=administrative, admin_level=4, name=ABC region, ...
After processing: mp: type=multipolyon, boundary=administrative, admin_level=4, name=ABC region way 1: ... way 2: highway=residential way 3: ...
Relation 2: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: role=outer, boundary=administrative, admin_level=5, ... way 2: role=outer, boundary=administrative, admin_level=5, highway=residential, name=Weaverstreet way 3: boundary=administrative, ...
After processing: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: ... way 2: highway=residential, name=Weaverstreet way 3: ...
So with other words: Style implementors can alway rely on the relation information and need not to filter out boundary information from the lines.
WanMil
Well IMHO the best would be to have a) the possibility to directly create (routable) lines from the relations style-file file. b) the possibility to have the relations being added to the lines - so you can choose i.e. to only display boundary=administrative & admin_level=4 if boundary=adminstrative & admin_level=2 does not exist. One can do this currently really nicely by not applying directly from the relations file, but by using boundary=administrative & admin_level=4 {set adminboundary4=exist; set adminboundary4name={$name};.......} Then inside the lines file one can put rules like adminboundary2!=exist & adminboundary4=exist {set boundary=administrative; set admin_level=4; set name={$adminboundary4name} } adminboundary2!=exist & adminboundary4!=exist & adminboundary5=exist {set boundary=administrative; set admin_level=5; set name={$adminboundary5name} } ..... What is missing here is that if there are several relations of type admin_level=4 on the same way and you want all of them. Then you will only have one. Therefore for things were one would like to have all displayed (e.g. route=bicycle & network=ncn) - one directly includes them into the map from the relations file. Therefore I propose to use, instead of your patch, the patch by Thilo, and (if consensus) change the relations file in the default style to directly write boundaries from the relations file, and not from the lines file. What I don't understand is why you want to filter out boundary information from the lines, that what we have the rules section for and the continue/continue_with_actions command. So I don't see any benefit in your other idea over implementing the patch by Thilo into the main trunk.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve???
Felix, I had a closer look at the patch and got some questions. As far as I understand the patch it tries to connect all ways of a relation and tags these ways with a special mkgmap:gtype tag which is a summary of all attributes of the relation(?) The convertRelation method tries to connect all ways of a relation. The responsible addWayToListAndChainIfPossible method seems to care about oneway tags if a way is classified as road. I don't know if the handling of two connected ways in following order is correct: Way 1: road, oneway=yes Way 2: no road You will get one way tagged with oneway=yes although the 2nd way is no road. All new assembled ways are put to the waymap, but with a different id. The assembled way copies the original way id from the first way but for the way map a fake id is generated. Although it's working I think that's no good programming style. I am a bit surprised because I think that the patch creates at least one new way for each relation. Doesn't that mean that you have n overlapping ways in case you have n relations on the same way? Probably I don't understand it so could you please explain what happens if one way is contained in multiple relations? WanMil
On 19.04.2010 21:08, WanMil wrote:
I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve???
Felix, I had a closer look at the patch and got some questions.
As far as I understand the patch it tries to connect all ways of a relation and tags these ways with a special mkgmap:gtype tag which is a summary of all attributes of the relation(?)
The convertRelation method tries to connect all ways of a relation. The responsible addWayToListAndChainIfPossible method seems to care about oneway tags if a way is classified as road. I don't know if the handling of two connected ways in following order is correct: Way 1: road, oneway=yes Way 2: no road You will get one way tagged with oneway=yes although the 2nd way is no road.
All new assembled ways are put to the waymap, but with a different id. The assembled way copies the original way id from the first way but for the way map a fake id is generated. Although it's working I think that's no good programming style.
I am a bit surprised because I think that the patch creates at least one new way for each relation. Doesn't that mean that you have n overlapping ways in case you have n relations on the same way? Probably I don't understand it so could you please explain what happens if one way is contained in multiple relations?
WanMil
It's Thilo Hannemann who wrote this patch. I just tried it and like the behaviour better than your patch and thought this patch could solve the same problem your patch is addressing. I have no deep enough understanding of the code to understand whether or not the patch is well written.
On 17.04.2010 20:00, WanMil wrote:
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
Why talking so long? Implementation was quite easy so please try this patch and post what you think about this patch.
I will post v2 with some more comments in the source code if it should be committed.
WanMil Hallo WanMil Well I do think the patch is working as supposed. However that is not really what I find useful. Now on country boundaries there are sometimes 10 boundaries on top of each other - is this what you want to achieve? I'ld much rather have only the boundary with the highest admin level - and have taken quite a bit of code into the style-file to make sure ONLY the boundary with the lowest admin_level is put inside the map. Your patch makes my style-file useless.
I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve???
BTW - I'ld much rather have a patch that disables sea, if there are more than 500 highway=residential inside the sea polygone, or something similar to detect that nothing is flooding. Just day before yesterdays alp extract from Geofabrik had one tile inside flooded, and there is the dreaded flooding inside Germany as allways (well this one due to geofabrik cutting). Maybe you could write a patch for that problem. I get tons of comments on my website about sea flooding, no matter in how many places I write that this is not solvable and any comment regarding sea flooding will get into the trashbin...
Felix, I tried to understand what the patch does. I compiled a map with the default style but the changed code section was never called. So I suppose I am missing some style rules that trigger the patch. Can you send me your style file so that I can try to understand the patch and maybe extract the good parts of it so that we might commit it? WanMil
On 02.05.2010 15:08, WanMil wrote:
On 17.04.2010 20:00, WanMil wrote:
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
Why talking so long? Implementation was quite easy so please try this patch and post what you think about this patch.
I will post v2 with some more comments in the source code if it should be committed.
WanMil Hallo WanMil Well I do think the patch is working as supposed. However that is not really what I find useful. Now on country boundaries there are sometimes 10 boundaries on top of each other - is this what you want to achieve? I'ld much rather have only the boundary with the highest admin level - and have taken quite a bit of code into the style-file to make sure ONLY the boundary with the lowest admin_level is put inside the map. Your patch makes my style-file useless.
I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve???
BTW - I'ld much rather have a patch that disables sea, if there are more than 500 highway=residential inside the sea polygone, or something similar to detect that nothing is flooding. Just day before yesterdays alp extract from Geofabrik had one tile inside flooded, and there is the dreaded flooding inside Germany as allways (well this one due to geofabrik cutting). Maybe you could write a patch for that problem. I get tons of comments on my website about sea flooding, no matter in how many places I write that this is not solvable and any comment regarding sea flooding will get into the trashbin...
Felix, I tried to understand what the patch does. I compiled a map with the default style but the changed code section was never called. So I suppose I am missing some style rules that trigger the patch.
Can you send me your style file so that I can try to understand the patch and maybe extract the good parts of it so that we might commit it?
WanMil You can now directly use [0x?? road_speed=? .... resolution ??] from the relations file. Hence if there are several boundaries on the same line (as relations) you will be able to map them all. Without the patch you first have to "apply" (intermediary) keys. This means you have to put a copy of the boundary rules from the lines file to the relations file, of course if you don't do this, the patch has no effect.
On 02.05.2010 15:08, WanMil wrote:
On 17.04.2010 20:00, WanMil wrote:
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
Why talking so long? Implementation was quite easy so please try this patch and post what you think about this patch.
I will post v2 with some more comments in the source code if it should be committed.
WanMil Hallo WanMil Well I do think the patch is working as supposed. However that is not really what I find useful. Now on country boundaries there are sometimes 10 boundaries on top of each other - is this what you want to achieve? I'ld much rather have only the boundary with the highest admin level - and have taken quite a bit of code into the style-file to make sure ONLY the boundary with the lowest admin_level is put inside the map. Your patch makes my style-file useless.
I don't really understand what this patch is trying to achieve. There is a patch by Thilo Hanneman (I'm attaching it for you) that makes it possible to directly render relations from the relations file, I think that is more useful - or don't I understand something here that you intend to achieve???
BTW - I'ld much rather have a patch that disables sea, if there are more than 500 highway=residential inside the sea polygone, or something similar to detect that nothing is flooding. Just day before yesterdays alp extract from Geofabrik had one tile inside flooded, and there is the dreaded flooding inside Germany as allways (well this one due to geofabrik cutting). Maybe you could write a patch for that problem. I get tons of comments on my website about sea flooding, no matter in how many places I write that this is not solvable and any comment regarding sea flooding will get into the trashbin...
Felix, I tried to understand what the patch does. I compiled a map with the default style but the changed code section was never called. So I suppose I am missing some style rules that trigger the patch.
Can you send me your style file so that I can try to understand the patch and maybe extract the good parts of it so that we might commit it?
WanMil You can now directly use [0x?? road_speed=? .... resolution ??] from the relations file. Hence if there are several boundaries on the same line (as relations) you will be able to map them all. Without the patch you first have to "apply" (intermediary) keys. This means you have to put a copy of the boundary rules from the lines file to the relations file, of course if you don't do this, the patch has no effect.
Can you please send me your style file? (I am not a style guru and it would take some hours until I have set it up correctly)
participants (2)
-
Felix Hartmann -
WanMil