{Spam?} multipolygon with outer polygon within inner polygons
Hi, I'm trying to build a map of The Netherlands and got some problems with rendering the administrative borders correctly. Some parts were related to broken relations between tiles, but the major one was caused by a complex relation of enclaves/exclaves of Baarle in the south of the country. I examined this area more closely and narrowed the problem down to this situation, where I cant render the map correctly with mkgmap: A = one big outer ring (the Dutch municipality of Baarle-Nassau), B1, B2 = some islands inside (Belgium territory, role=inner) C= Within some of those islands there are polygons (Dutch, role=outer) It goes wrong with those outer polygons within the inner polygons. Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg The relation can be found at http://betaplace.emaitie.de/webapps.rel onId=47798 There are no gaps or faults within the relation as far as I can see. I put this question and a few examples of my map also on the forum at http://forum.openstreetmap.org/viewtopic.php?pid=59370 Thanks, Minko
Minko schrieb:
I'm trying to build a map of The Netherlands and got some problems with rendering the administrative borders correctly. Some parts were related to broken relations between tiles, but the major one was caused by a complex relation of enclaves/exclaves of Baarle in the south of the country.
Hi, what I don't understand: Why is the complex MP processing for borders necessary while we are (mostly) only interested in the border _lines_ ? Chris
Hello On 12/02/10 10:24, Minko wrote:
Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg
Thanks for that image as it shows the problem clearly. If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines. I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries. ..Steve
Hello
On 12/02/10 10:24, Minko wrote:
Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg
Thanks for that image as it shows the problem clearly.
If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines.
I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries.
..Steve
Steve, I have two solutions: 1st: We might add a mkgmap option to disable multipolygon processing for boundaries. 2nd: the multipolygon code should not remove the boundary tags from the singular ways. Additionally the polygons created by the multipolygon code could be tagged with mkgmap:mp_boundary=yes. This tag could be evaluated in the style definition so the style could differ between the polygons created by the mp code and the lines not touched by mp code. What do you think? (I am not an expert of the style processing) WanMil
On 12.02.2010 19:26, WanMil wrote:
Hello
On 12/02/10 10:24, Minko wrote:
Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg
Thanks for that image as it shows the problem clearly.
If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines.
I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries.
..Steve
Steve,
I have two solutions:
1st: We might add a mkgmap option to disable multipolygon processing for boundaries.
2nd: the multipolygon code should not remove the boundary tags from the singular ways. Additionally the polygons created by the multipolygon code could be tagged with mkgmap:mp_boundary=yes. This tag could be evaluated in the style definition so the style could differ between the polygons created by the mp code and the lines not touched by mp code.
I think the 2nd solution looks cleaner (or less easy to find out why something goes wrong). I just gripe about tags being lost. I think it should rather be converted to: mkgmap:mp_boundary=${boundary} mkgmap:mp_admin-level=${admin-level} in order not to loose the importance. As I'm not well informed about naming of boundaries, care should be taken not to loose the keys depicting the info how to name a boundary too.
What do you think? (I am not an expert of the style processing)
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I have two solutions:
1st: We might add a mkgmap option to disable multipolygon processing for boundaries.
2nd: the multipolygon code should not remove the boundary tags from the singular ways. Additionally the polygons created by the multipolygon code could be tagged with mkgmap:mp_boundary=yes. This tag could be evaluated in the style definition so the style could differ between the polygons created by the mp code and the lines not touched by mp code.
I think the 2nd solution looks cleaner (or less easy to find out why something goes wrong). I just gripe about tags being lost. I think it should rather be converted to: mkgmap:mp_boundary=${boundary} mkgmap:mp_admin-level=${admin-level}
I think you misunderstood something. Either all ways composing the boundary polygon and additionally the polygons created by the multipolygon code contain ALL tags (boundary=... admin-level=... name=...). But the polygons created by the mp code are additionally tagged with mkgmap:mp_boundary=yes. I don't mind how the tag handling should be. Maybe the style guys tells us what they like most. Nearly everything should be possible. WanMil
in order not to loose the importance. As I'm not well informed about naming of boundaries, care should be taken not to loose the keys depicting the info how to name a boundary too.
What do you think? (I am not an expert of the style processing)
WanMil
Hi WanMil,
2nd: the multipolygon code should not remove the boundary tags from the singular ways. Additionally the polygons created by the multipolygon code could be tagged with mkgmap:mp_boundary=yes. This tag could be evaluated in the style definition so the style could differ between the polygons created by the mp code and the lines not touched by mp code.
This sounds sensible to me. The style could have an additional rule that filters out generated lines. I would set the attribute on all MultiPolygon-generated lines, not just on boundaries. (Someone could want to draw coastlines as lines on a separate map layer, for example, and the generated lines would interfere.) Marko
participants (6)
-
Chris-Hein Lunkhusen -
Felix Hartmann -
Marko Mäkelä -
Minko -
Steve Ratcliffe -
WanMil