render closed waterway polygons?
In my styles, I want to render closed waterway polygons as areas by using the continue statement in my lines: waterway=canal & natural!=water [0x1f resolution 23 continue] polygons file: waterway=canal [0x3c resolution 23] Those closed bodies are rendered ok now, filled with water. If this waterway area consists of two or more separate ways, connected to each other, this is not rendered as water polygon but only as linear elements, which is excellent. Problem arise at the tile borders, where I get unwanted side effects, linear elements of waterways that cross the tiles are automatically closed by mkgmap and therefore rendered as areas (filled up with water), which I do not want. I like to distinguish those artifical polygons in my style file from the really closed waterway polygons. Are those artifcially closed polygons tagged internally by mkgmap somehow, so I can exclude them from my polygon style? Background: In the Netherlands there are tons of areas of water tagged as waterway=* (canal, drain, river). According to the wiki this tagging is wrong (for polygons natural=water should be used, or for bigger rivers, waterway=riverbank). But since Potlatch, Josm and Mapnik automatically render closed waterways as areas, many mappers are making this mistake. (One could argue if maybe the wiki should be revised, why is only waterway=riverbank a polygon and a closed body of waterway=river not?) In Potlatch all natural=water polygons are called "Lake" so many mappers want to 'improve' those areas by tagging them as waterways. I have tried to contact the Potlatch developers about this issue but they dont seem to care to adjust it.
In my styles, I want to render closed waterway polygons as areas by using the continue statement in my lines:
waterway=canal & natural!=water [0x1f resolution 23 continue]
polygons file:
waterway=canal [0x3c resolution 23]
Those closed bodies are rendered ok now, filled with water. If this waterway area consists of two or more separate ways, connected to each other, this is not rendered as water polygon but only as linear elements, which is excellent.
Problem arise at the tile borders, where I get unwanted side effects, linear elements of waterways that cross the tiles are automatically closed by mkgmap and therefore rendered as areas (filled up with water), which I do not want. I like to distinguish those artifical polygons in my style file from the really closed waterway polygons. Are those artifcially closed polygons tagged internally by mkgmap somehow, so I can exclude them from my polygon style?
No. This situation cannot be detected by the style file. At the moment all ways with both endpoints outside the bbox are closed automatically. I have attached a patch that does exactly what you want. All ways are now tagged with two additional tags: mkgmap:wayclosed true/false - signals if a way is closed (first point == last point) mkgmap:autoclosing true/false - true if both end points of the way are outside the bbox and the way is automatically closed if a polygon rule matches. The patch is superfluous if splitter ensures that a closed way is closed in all splitted tiles. WanMil
Background: In the Netherlands there are tons of areas of water tagged as waterway=* (canal, drain, river). According to the wiki this tagging is wrong (for polygons natural=water should be used, or for bigger rivers, waterway=riverbank). But since Potlatch, Josm and Mapnik automatically render closed waterways as areas, many mappers are making this mistake. (One could argue if maybe the wiki should be revised, why is only waterway=riverbank a polygon and a closed body of waterway=river not?)
In Potlatch all natural=water polygons are called "Lake" so many mappers want to 'improve' those areas by tagging them as waterways. I have tried to contact the Potlatch developers about this issue but they dont seem to care to adjust it. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Wanmil! Can you make a patched mkgmap.jar so that I can test this patch?
I have uploaded it to http://files.mkgmap.org.uk/detail/71 Don't know for sure that it works with Java 6. Maybe you have to use Java 7. WanMil
Thanks Wanmil! Can you make a patched mkgmap.jar so that I can test this patch?
Thanks Wanmil, I have Java7 so it wont be a problem. The first tests look good :) So if I understand it right it can be rendered in two ways? In my lines style, add a rule waterway=canal & mkgmap:wayclosed=true {add natural=water} Or Use the continue in the line style after each waterway that needs to be processed and in the polygon style add a rule: waterway=canal & mkgmap:autoclosing=false [0x3c resolution 22] I used the last one and got a few severe styledconverter warnings: Use line rules only for way#
So if I understand it right it can be rendered in two ways?
In my lines style, add a rule waterway=canal & mkgmap:wayclosed=true {add natural=water}
Or
Use the continue in the line style after each waterway that needs to be processed and in the polygon style add a rule:
waterway=canal & mkgmap:autoclosing=false [0x3c resolution 22]
I used the last one and got a few severe styledconverter warnings: Use line rules only for way#
A few more tests: The first method, adding natural=water to waterway=canal & mkgmap:wayclosed=true in my line style didn't work. Only the last method (mkgmap:autoclosing=false in my polygons style) worked. And btw I got not just a few warnings, they were a lot, it looked like those warnings were printed for every single highway (even when I didnt process them, I just tested a map with only water styles)
So if I understand it right it can be rendered in two ways?
In my lines style, add a rule waterway=canal & mkgmap:wayclosed=true {add natural=water}
Or
Use the continue in the line style after each waterway that needs to be processed and in the polygon style add a rule:
waterway=canal & mkgmap:autoclosing=false [0x3c resolution 22]
I used the last one and got a few severe styledconverter warnings: Use line rules only for way#
Yes, the patch prints out the results for *all* ways with log level SEVERE. This should enable you to check manually which rules are used for which way. "Use line rules only..." means that only the lines style file is used for this way. "Use both rules for..." means that the lines plus the polygon style file is used.
A few more tests:
The first method, adding natural=water to waterway=canal & mkgmap:wayclosed=true in my line style didn't work.
Only the last method (mkgmap:autoclosing=false in my polygons style) worked.
And btw I got not just a few warnings, they were a lot, it looked like those warnings were printed for every single highway (even when I didnt process them, I just tested a map with only water styles)
Ok, I should have explained that more in detail. As far as I have understood you want to distinguish in your lines file if a way is closed (use continue statement) or a way is not closed but will automatically be closed by mkgmap (do not use the continue statement). So your line rules will be: waterway=canal & natural!=water & mkgmap:autoclosing!=true [0x1f resolution 23 continue] waterway=canal & natural!=water & mkgmap:autoclosing=true [0x1f resolution 23] WanMil
Wanmil wrote:
Yes, the patch prints out the results for *all* ways with log level SEVERE. This should enable you to check manually which rules are used for which way. "Use line rules only..." means that only the lines style file is used for this way. "Use both rules for..." means that the lines plus the polygon style file is used.
Ok, I have runned the patch on a Benelux extract with only waterways now. In the log file I see only SEVERE (StyledConverter): splitter\map.osm: Use line rules only for WAY: There are no lines saying "Use both rules for..." altough there are some waterways that are converted as polygon. So the interesting ways are seemed to filtered out of these warnings and that is not what you have intended?
So your line rules will be: waterway=canal & natural!=water & mkgmap:autoclosing!=true [0x1f resolution 23 continue] waterway=canal & natural!=water & mkgmap:autoclosing=true [0x1f resolution 23]
Thanks, that seem to work too. The other way worked as well: Lines: waterway=canal & natural!=water [0x1f resolution 23 continue] Polygons: waterway=canal & mkgmap:autoclosing=false & natural!=water [0x3c resolution 23]
Ok, I have runned the patch on a Benelux extract with only waterways now. In the log file I see only SEVERE (StyledConverter): splitter\map.osm: Use line rules only for WAY: There are no lines saying "Use both rules for..." altough there are some waterways that are converted as polygon. So the interesting ways are seemed to filtered out of these warnings and that is not what you have intended?
I see: the message "Use both rules..." is printed out only if the way is not closed and both endpoints are outside the bounding box. So it is quite seldom. Anyhow I wonder why you don't see such a message. The message is generated before the style files are evaluated so your style rules have no influence on if the message is printed or not. Do you think the naming of the extra tags mkgmap:closed and mkgmap:autoclosing is good? Or do you have a better naming which is more intuitive? It's better to change that before committing :-) WanMil
wanmil wrote:
I see: the message "Use both rules..." is printed out only if the way is not closed and both endpoints are outside the bounding box. So it is quite seldom. Anyhow I wonder why you don't see such a message. The message is generated before the style files are evaluated so your style rules have no influence on if the message is printed or not.
Ah ok, I have tested it first only with one big bbox for the whole Benelux so that makes sense. I have now runned the patch on two tiles containing all osm data. It gives tons of line warnings "Use line rules only for WAY" for mkgmap:closed=false; They are way too many warnings to make sense of it, so I don't think those warnings are sensible at all so why print them out? If I skip them there are 30 warnings left with "Use both rules" Most of them are also not relevant (borders, highways) and just a few of them are waterways with mkgmap:closed=false & mkgmap:autoclosing=true which were indeed causing floodings before.
Do you think the naming of the extra tags mkgmap:closed and mkgmap:autoclosing is good? Or do you have a better naming which is more intuitive? It's better to change that before committing :-)
I don't have a better suggestion for those tags. If the description is ok, I think it can be usefull (except for the warnings, but I assume you turn them off when committing it?) Josef wrote:
You should consider that many canal areas have the tag waterway=riverbank, or is this not relevant. This tag is false because there is stagnant water.
They are only handled as polygons which should be rendered ok as long they are closed. This is not relevant in my case, where canal areas like this one was tagged only with waterway=canal: http://www.openstreetmap.org/browse/way/115828742 I added natural=water to it. If I delete the tag waterway=canal, it will be in no matter of time changed by a Potlatch user who thinks that this is not a "lake" ;-) If you render it with mkgmap, this canal would be empty otherwise (unless the new patch will be comitted and the default water rules changed a bit).
Am 26.10.2012 18:52, schrieb Minko:
I added natural=water to it. If I delete the tag waterway=canal, it will be in no matter of time changed by a Potlatch user who thinks that this is not a "lake" ;-) If you render it with mkgmap, this canal would be empty otherwise (unless the new patch will be comitted and the default water rules changed a bit).
IMHO it's logical river -> riverbank and not logical canal - riverbank. He should read the Wiki concerning river and canal: http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dcanal
Am 26.10.2012 17:07, schrieb Minko:
Wanmil wrote:
Yes, the patch prints out the results for *all* ways with log level SEVERE. This should enable you to check manually which rules are used for which way. "Use line rules only..." means that only the lines style file is used for this way. "Use both rules for..." means that the lines plus the polygon style file is used.
Ok, I have runned the patch on a Benelux extract with only waterways now. In the log file I see only SEVERE (StyledConverter): splitter\map.osm: Use line rules only for WAY: There are no lines saying "Use both rules for..." altough there are some waterways that are converted as polygon. So the interesting ways are seemed to filtered out of these warnings and that is not what you have intended?
So your line rules will be: waterway=canal & natural!=water & mkgmap:autoclosing!=true [0x1f resolution 23 continue] waterway=canal & natural!=water & mkgmap:autoclosing=true [0x1f resolution 23]
Thanks, that seem to work too. The other way worked as well:
Lines: waterway=canal & natural!=water [0x1f resolution 23 continue]
Polygons: waterway=canal & mkgmap:autoclosing=false & natural!=water [0x3c resolution 23]
You should consider that many canal areas have the tag waterway=riverbank, or is this not relevant. This tag is false because there is stagnant water.
Hi, WanMil wrote
The patch is superfluous if splitter ensures that a closed way is closed in all splitted tiles.
WanMil
Splitter can do this only if the input file contains the complete way, so I think it is still needed. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/render-closed-waterway-polygons-tp5732836p573... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi
Rule rules; + way.addTag("mkgmap:closed",String.valueOf(way.isClosed())); + way.addTag("mkgmap:autoclosing", "false");
I don't much like the idea of adding two tags to every single way.
+ // the way may be closed automatically because both endpoints are outside the bbox + // set a tag so that these ways can be ignored in the style rules + way.addTag("mkgmap:autoclosing", "true");
It seems to me that setting this is all that is required. It will only affect relatively few ways, and you can test for tag existence rather than having to know/remember if you should test against 'true', 'True', 'yes', '1' or whatever. But apart from that, the main thing is that any rule that uses this will still be guessing -- what if it really was a polygon? Then you will have a missing area of water. I think we can do better though. We can know if the way really is closed even when all its nodes are not included, since the first and last <nd ref="..."> values will be the same for the first and last points in the way. Currently we ignore any node ref in the way for which there is no actual node coordinates during parsing, but we could keep track of the node id's and compare the first and last ones when the way is created. Then a flag could be set on the way, to say that it is definitely closed and you would no longer have to guess. The information that the way is incomplete might be worth saving too. Then 'is_closed()' might be a good candidate for a style function? ..Steve
Steve wrote:
I don't much like the idea of adding two tags to every single way.
+ // the way may be closed automatically because both endpoints are outside the bbox + // set a tag so that these ways can be ignored in the style rules + way.addTag("mkgmap:autoclosing", "true");
It seems to me that setting this is all that is required. It will only affect relatively few ways, and you can test for tag existence rather than having to know/remember if you should test against 'true', 'True', 'yes', '1' or whatever.
I agree Steve, mkgmap:autoclosing=true was indeed the only tag that I needed to render those 'problematic' polygons.
But apart from that, the main thing is that any rule that uses this will still be guessing -- what if it really was a polygon? Then you will have a missing area of water.
In my test case I haven't seen those issues yet. Even this canal which was split in two tiles http://www.openstreetmap.org/browse/way/53011144 was rendered as polygon, maybe because the first node was just within the overlap range (3000) of the other tile? So it would only be broken if it was a rather large polygon. But fortunately most of the items were relatively small polygons.
I think we can do better though. (...) Then 'is_closed()' might be a good candidate for a style function?
Well, if this doesnt take too much calculation time, please go ahead :-)
Hi
In my test case I haven't seen those issues yet. Even this canal which was split in two tiles http://www.openstreetmap.org/browse/way/53011144 was rendered as polygon, maybe because the first node was just within the overlap range (3000) of the other tile? So it would only be broken if it was a rather large polygon. But fortunately most of the items were relatively small polygons.
Yes the start/end point must be outside the overlap to be a problem, so it probably less likely to happen. At least for that tag in that part of the world :) ..Steve
Hi
Well, if this doesnt take too much calculation time, please go ahead :-)
OK here is a first attempt. The parsers are modified to save a flag on the way if it is actually closed. It also aggressively refuses to make anything into a polygon that is not closed. So there should be errors as a result of splitter. But on the other hand there may be more due to OSM data errors. Will have to investigate this and adjust if necessary. Attached is the before and after results of my test and the patch. A precompiled jar is at: http://files.mkgmap.org.uk/download/72/mkgmap.jar ..Steve
Hi
Well, if this doesnt take too much calculation time, please go ahead :-)
OK here is a first attempt.
The parsers are modified to save a flag on the way if it is actually closed. It also aggressively refuses to make anything into a polygon that is not closed.
So there should be errors as a result of splitter. But on the other hand there may be more due to OSM data errors. Will have to investigate this and adjust if necessary.
Attached is the before and after results of my test and the patch.
A precompiled jar is at: http://files.mkgmap.org.uk/download/72/mkgmap.jar
..Steve
Afer a quick code inspection I would say: Looks good! The only thing that must be checked carefully is the new meaning of the isClosed() method. I am quite sure that there are some places at least in the multipolygon code that relies on isClosed() == true => getPoints().get(0).equals(getPoints().get(getPoints().size()-1)) WanMil
Hi
Afer a quick code inspection I would say: Looks good! The only thing that must be checked carefully is the new meaning of the isClosed() method. I am quite sure that there are some places at least in the multipolygon code that relies on isClosed() == true => getPoints().get(0).equals(getPoints().get(getPoints().size()-1))
Yes agreed. The first thing I'm going to do is find out how common it is that isClosed() != isClosedOld(). Perhaps the multi-poly code can make good use of isComplete()? ..Steve
OK here is a first attempt.
There is a major flaw in that patch, as only the Ways that are created from reading the OSM file are dealt with. There are many places where Ways are constructed and these never appear to be closed with that patch. If patched things so that doesn't happen here: http://files.mkgmap.org.uk/download/73/mkgmap.jar With that patch multi-polygons are back! ..Steve
Steve, How do I use this is_closed() in my style files? Can you give an example?
On 27/10/12 21:02, Minko wrote:
Steve, How do I use this is_closed() in my style files? Can you give an example?
My patch attempts to fix the problem without any changes needed to the style file at all. The is_closed() will come later. ..Steve
Hi
Rule rules; + way.addTag("mkgmap:closed",String.valueOf(way.isClosed())); + way.addTag("mkgmap:autoclosing", "false");
I don't much like the idea of adding two tags to every single way.
+ // the way may be closed automatically because both endpoints are outside the bbox + // set a tag so that these ways can be ignored in the style rules + way.addTag("mkgmap:autoclosing", "true");
It seems to me that setting this is all that is required. It will only affect relatively few ways, and you can test for tag existence rather than having to know/remember if you should test against 'true', 'True', 'yes', '1' or whatever.
The two tags needn't be a memory problem just by changing a few other things (I will post a patch within the next days). Anyhow we could decide to set mkgmap:closed=true and mkgmap:autoclosing=true only. I think mkgmap:closed might make sense to have a chance in the lines style to skip an element. I don't have a good example but there are some tags that can be used for lines and polygons.
But apart from that, the main thing is that any rule that uses this will still be guessing -- what if it really was a polygon? Then you will have a missing area of water.
I aggree!
I think we can do better though. We can know if the way really is closed even when all its nodes are not included, since the first and last <nd ref="..."> values will be the same for the first and last points in the way.
Currently we ignore any node ref in the way for which there is no actual node coordinates during parsing, but we could keep track of the node id's and compare the first and last ones when the way is created. Then a flag could be set on the way, to say that it is definitely closed and you would no longer have to guess.
Sounds good. I supposed that splitter removes the node refs for all nodes not contained in the tile. If that's not the case your idea is much better than the patch.
The information that the way is incomplete might be worth saving too.
Then 'is_closed()' might be a good candidate for a style function?
Yes - and is_inpomplete() :-) At the moment I do not make good progress in the style-functions branch. Steve, do you think it's ok to merge the current implementation which requires that a function cannot be used on its own? Otherwise the optimizer removes the function-only-rule.
..Steve
WanMil P.S.: I am happy if you merge the style-include branch! Good work!
The two tags needn't be a memory problem just by changing a few other things (I will post a patch within the next days). Anyhow we could decide to set mkgmap:closed=true and mkgmap:autoclosing=true only. I think mkgmap:closed might make sense to have a chance in the lines style to skip an element. I don't have a good example but there are some tags that can be used for lines and polygons.
Yes true, adding tags will often need no extra memory at all (when both the key and value have a limited set of values and are interned, which they are in this case), and sometimes a lot when the Tags hash map has to be resized. Adding fields as in my patch will always add a fixed amount of memory to each way. I don't know how it all balences out in a typical workload, but I think if you are going to add something to every way its probably best to just reserve the space for it.
Yes - and is_inpomplete() :-) At the moment I do not make good progress in the style-functions branch. Steve, do you think it's ok to merge the current implementation which requires that a function cannot be used on its own? Otherwise the optimizer removes the function-only-rule.
Yes, I think it is fine to merge in new features even if they are incomplete, as long as it doesn't affect the existing functionality.
P.S.: I am happy if you merge the style-include branch! Good work!
OK will do that later today. ..Steve
Am 25.10.2012 15:21, schrieb Minko:
waterway=canal & natural!=water Hi Minko, I think this is bad tagging and should be changed in the data. Correct tagging should be natural=water & water=canal.
In general maybe it would also help to add the way-id to problematic_polygons list. So mkgmap has the hole way and there is no need to autoclose a way. Henning
I understand it is not good tagging but please help me to tell Potlatch they are wrong: https://trac.openstreetmap.org/ticket/4510 If I change it to correct tagging there will be someone else who notice this as "Lake" and again tag it to waterway=canal. There are dozens of mappers who are making this mistake and I'm tired of writing them or correcting them all.
In general maybe it would also help to add the way-id to problematic_polygons list. So mkgmap has the hole way and there is no need to autoclose a way.
That is not the point. The point is that correct waterway=canals which are single lines are being closed too if I render it as polygons. I can think of other forms of lines that could either be polygons or lines. Think of highway=pedestrian or man_made=pier so I think this patch can help.
On 27 Oct 2012, at 09:26, Minko <ligfietser@online.nl> wrote:
I understand it is not good tagging but please help me to tell Potlatch they are wrong: https://trac.openstreetmap.org/ticket/4510
If I change it to correct tagging there will be someone else who notice this as "Lake" and again tag it to waterway=canal. There are dozens of mappers who are making this mistake and I'm tired of writing them or correcting them all.
In general maybe it would also help to add the way-id to problematic_polygons list. So mkgmap has the hole way and there is no need to autoclose a way.
That is not the point. The point is that correct waterway=canals which are single lines are being closed too if I render it as polygons. I can think of other forms of lines that could either be polygons or lines. Think of highway=pedestrian or man_made=pier so I think this patch can help.
Isn't the area=yes tag designed to help differentiate in these cases?
Am 27.10.2012 10:26, schrieb Minko:
That is not the point. The point is that correct waterway=canals which are single lines are being closed too if I render it as polygons. I can think of other forms of lines that could either be polygons or lines. Think of highway=pedestrian or man_made=pier so I think this patch can help.
I think this would be guessing. Of course there are some closed piers or pedestrian-areas (which should be tagged with area=yes) which should be filled like a polygon. But there are also closed ones, which shouldn't be filled. Henning
I don't believe OSM without errors will ever exist. I don't make a map for detecting tagging osm errors, there are other tools to detect tagging errors. It is up to you if you want to make a map which shows every error or a map that tries to make the best of it, guessing or not. Personally I would like to see it will be committed.
Hi Minko, of course I wont tell you how to create your maps. IT was just a hint, that you could also create some additional errors. At all I would prefer a solution like isClosed() as a style-file-function. I think it is more easy to understand. Henning
Hi Henning, Sure, isClosed() would be better, but as workaround this patch could be a solution until isClosed() style-file-function is implemented? Regards, Minko
Hi Attached is my latest version of the patch. I've tried it out on the Netherlands with this style: <<<version>>> 0 <<<lines>>> waterway=canal & natural!=water [0x1f resolution 18 continue] <<<polygons>>> waterway=canal [0x3c resolution 18] Before the patch there are numerous obvious problems where waterways cross the tile boundaries, but I am unable to find a single one with the patch. This patch differs from the first, now the isClosed() routine works exactly the same as before *except* when the way is incomplete, in which case the previously set closed flag is returned. So all generated ways (coastlines, multipolygons etc) should be unaffected, and of course all generated polygons should be complete, unless they were derived from incomplete ways. Pre-built jar at: http://files.mkgmap.org.uk/download/74/mkgmap.jar ..Steve
Sounds great Steve! I will try it on the whole Benelux and with other water features too (drain, river, stream, dam). I have made a poi list of 'problem' areas so I can check the results.
Hi
Attached is my latest version of the patch.
I've tried it out on the Netherlands with this style:
<<<version>>> 0 <<<lines>>> waterway=canal & natural!=water [0x1f resolution 18 continue]
<<<polygons>>> waterway=canal [0x3c resolution 18]
Before the patch there are numerous obvious problems where waterways cross the tile boundaries, but I am unable to find a single one with the patch.
This patch differs from the first, now the isClosed() routine works exactly the same as before *except* when the way is incomplete, in which case the previously set closed flag is returned.
So all generated ways (coastlines, multipolygons etc) should be unaffected, and of course all generated polygons should be complete, unless they were derived from incomplete ways.
Pre-built jar at: http://files.mkgmap.org.uk/download/74/mkgmap.jar
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve, I think the multipolygon code must be changed to work in the same way as unpatched. The problem is the detection which member polygon lies within which other member polygon. See attached picture. The left side shows an mp with two members - one outer and one inner polygon. Due to the splitting process only the nodes within the overlap are known by the mp algorithm. So the mp alg sees the green and red polygon. Nor green neither red contain the other polygon completely. The problem lies in the overlap so the current mp algorithm ignores this and assumes that green contains red - but only if the original green way is not closed. To cut a long story short: Some parts of the mp algorithm must adapt the new meaning of isClosed() and isComplete(). This will improve the algorithm because the isComplete() information was not available before. I will have a look on it. Can you create a branch? That will make it easier for me to add my changes. WanMil
Hi
Attached is my latest version of the patch.
I've tried it out on the Netherlands with this style:
<<<version>>> 0 <<<lines>>> waterway=canal & natural!=water [0x1f resolution 18 continue]
<<<polygons>>> waterway=canal [0x3c resolution 18]
Before the patch there are numerous obvious problems where waterways cross the tile boundaries, but I am unable to find a single one with the patch.
This patch differs from the first, now the isClosed() routine works exactly the same as before *except* when the way is incomplete, in which case the previously set closed flag is returned.
So all generated ways (coastlines, multipolygons etc) should be unaffected, and of course all generated polygons should be complete, unless they were derived from incomplete ways.
Pre-built jar at: http://files.mkgmap.org.uk/download/74/mkgmap.jar
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, Tested it on the whole Benelux and the results look quite good. I have found some glitches with multipolygons however, but I dont know if it is related to the patch or an existing problem. In my style file, I render only waterways. Lines waterway=river & natural!=water [0x18 resolution 16 continue] waterway=canal & natural!=water [0x18 resolution 21 continue] waterway=stream & natural!=water [0x18 resolution 24 continue] waterway=drain & natural!=water [0x18 resolution 24 continue] Polygons (waterway=canal | waterway=river) & natural!=water [0x13 resolution 14] (waterway=drain | waterway=stream) & natural!=water [0x15 resolution 14] (resolution 14 and type 0x13 and 0x15 were chosen because they contrast more to see the difference with the waterlines) One example of a problem is caused where a way is part of a mp relation: http://www.openstreetmap.org/browse/relation/1260069 This part was filled up with water and the area is named "Kyll" after the river. In the actual situation is a administrative district and only a small part is a boundary by the river. In my test map I dont render boundary = administrative, is it a rule in mkgmap that it seeks one of the outer members that is rendered (waterway=river?) and put it on the whole mp?
On 28/10/12 21:43, Minko wrote:
Hi, Tested it on the whole Benelux and the results look quite good.
Great
I have found some glitches with multipolygons however, but I dont know if it is related to the patch or an existing problem.
Right, my fix doesn't target multipolygons at all. I tried lakes in Finland, and I saw multipolygon breakage as expected, although some improvements too. ..Steve
I have found some glitches with multipolygons however, but I dont know if it is related to the patch or an existing problem.
Right, my fix doesn't target multipolygons at all. I tried lakes in Finland, and I saw multipolygon breakage as expected, although some improvements too.
Ah ok, Here is another smaller example: This drain http://www.openstreetmap.org/browse/way/69701523 is part of a landuse=residential mp http://www.openstreetmap.org/browse/relation/1100932 If I render only waterways, not residential areas, it puts a drain around the whole mp. Even if I don't put waterways in my polygon style at all. So this might be a glitch in the mp processing too?
I have found some glitches with multipolygons however, but I dont know if it is related to the patch or an existing problem.
Right, my fix doesn't target multipolygons at all. I tried lakes in Finland, and I saw multipolygon breakage as expected, although some improvements too.
Ah ok,
Here is another smaller example:
This drain http://www.openstreetmap.org/browse/way/69701523 is part of a landuse=residential mp http://www.openstreetmap.org/browse/relation/1100932
If I render only waterways, not residential areas, it puts a drain around the whole mp.
Good catch! This has nothing to do with Steves patch. To save memory mkgmap loads only those tags that are referenced in the style file. You have: mp 1100932: landuse = residential way 69701523: waterway = drain way 69701491: waterway = drain way 68635609: <no tags> way 69701470: <no tags> If you have no rule with landuse but a rule with waterway mkgmap loads the following: mp 1100932: <no tag> way 69701523: waterway = drain way 69701491: waterway = drain way 68635609: <no tags> way 69701470: <no tags> The mp algorithm thinks that the mp is not tagged. So it collects the tags from the outer ways => waterway=drain (outer ways without tags are ignored here. I don't remember why - maybe this should be corrected). So you get a line around your residentail area tagged with waterway=drain. What can we do to avoid such a problem? For multipolygons the loader should not throw away any tag - no matter if it is used or not. Otherwise it is not possible for the mp algorithm to avoid such a problem for sure. The memory penalty should not be so bad because the number of multipolygons is not so big in each tile.
Even if I don't put waterways in my polygon style at all. So this might be a glitch in the mp processing too?
I assume you have rules in your lines file for waterways? WanMil
What can we do to avoid such a problem? Maybe copy tags to polygon only if it's only one outer-way?
Henning
Then we loose a lot of mps which are tagged correctly: All mps with more than one outer way but with its tags on the outer ways. Another option will be to add a special mkgmap tag during file loading when a tag is removed from the mp. This will reduce the (small) memory penalty and will have the same effect. I will post a patch today so we can try to fix that soon. WanMil
Yes Wanmil, If I only had waterways in my lines style, there would be a drain around the residential. And the same for the Kyll area, a river instead of a boundary line (where on OSM there is not a river at all!) So it's a good thing if this could be corrected. If someone is making a waterway map there would be a river where there shouldnt be one! Regards, Minko
Even if I don't put waterways in my polygon style at all. So this might be a glitch in the mp processing too?
I assume you have rules in your lines file for waterways?
On 28/10/12 20:25, WanMil wrote:
So the mp alg sees the green and red polygon. Nor green neither red contain the other polygon completely. The problem lies in the overlap so the current mp algorithm ignores this and assumes that green contains red - but only if the original green way is not closed.
Right I see. I'm not sure that there is a lot more information - isClosed() should always be true for a polygon and isComplete will therefore be false in the same cases that isClosed was false before. In all cases I saw (this was regular polygons), if isClosed is false for something that is meant to be a polygon it doesn't show up on the main Mapnik map - and so it gets fixed!
I will have a look on it. Can you create a branch? That will make it easier for me to add my changes.
OK I shall create a branch and put the changes on it. Cheers, ..Steve
So the mp alg sees the green and red polygon. Nor green neither red contain the other polygon completely. The problem lies in the overlap so the current mp algorithm ignores this and assumes that green contains red - but only if the original green way is not closed.
Right I see. I'm not sure that there is a lot more information - isClosed() should always be true for a polygon and isComplete will therefore be false in the same cases that isClosed was false before.
I found a mini micro improvement but this happens only in very rare cases and only if outer and inner polygons of an mp are touching (which is not allowed). So it needn't be described in detail here :-)
In all cases I saw (this was regular polygons), if isClosed is false for something that is meant to be a polygon it doesn't show up on the main Mapnik map - and so it gets fixed!
I will have a look on it. Can you create a branch? That will make it easier for me to add my changes.
OK I shall create a branch and put the changes on it.
I've added the is_closed() function. Should I also add the is_complete() function? I've also committed the mp changes which was easier than expected. If noone opposes I will merge the branch back to trunk tomorrow. WanMil
Cheers, ..Steve
I've added the is_closed() function. Should I also add the is_complete() function? I've also committed the mp changes which was easier than expected.
If noone opposes I will merge the branch back to trunk tomorrow.
WanMil
Yes, I would like to see the is_closed() function and is_complete() to be merged. As far as I can see mkgmap-way-closing-r2355.jar only has is_closed()?
participants (7)
-
Charlie Ferrero -
GerdP -
Henning Scholland -
Josef Latt -
Minko -
Steve Ratcliffe -
WanMil