[PATCH v1] Multipolygon: Allow nested inner polygons
I have found that some multipolygons use nested inner polygons. Example: * A forest (outer) with a lake (inner) that has an island (inner) which is not a forest. (example: http://www.openstreetmap.org/browse/relation/331402) By definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) one has to create two mps. But I see that it is a nice simplification lots of mappers are using. Attached patch handles this situation. The inner and outer roles are now used as follows: * the outmost polygon must have role=outer (or role=<empty>) * all outmost polygons with role=inner are not used (a warning is issued) * all inside polygons with role=inner use their own tagging * all inside polygons with role=outer use the mp tagging if available or their own tagging if the mp is not tagged * all inside polygons with role=<empty> are categorized automatically as outer/inner depending on the nest level * all inside polygons with role=outer without a direct ambient inner polygon are dropped with a warning message (outer in outer polygon) Most of the renderers do not support inner in inner polygons but I think it is a very reasonable extension of the multipolygon handling. This patch also improves the error messages. I haven't seen any more "are not processed due to an unknown reason" messages and I look forward that the community will also not be able to generate any more ... ;-) WanMil
WanMil schrieb:
I have found that some multipolygons use nested inner polygons. Example: * A forest (outer) with a lake (inner) that has an island (inner) which is not a forest. (example: http://www.openstreetmap.org/browse/relation/331402)
But neither mapnik nor osmarender show the inner-inner island (wood), because this construct is not a valid advanced-multipolygon. Chris
WanMil schrieb:
I have found that some multipolygons use nested inner polygons. Example: * A forest (outer) with a lake (inner) that has an island (inner) which is not a forest. (example: http://www.openstreetmap.org/browse/relation/331402)
But neither mapnik nor osmarender show the inner-inner island (wood), because this construct is not a valid advanced-multipolygon.
Chris
The patch supports the complete multipolygon specification. And additionally it is tolerant towards incorrect (but reasonable) multipolygons. So why should mkgmap be restrictive if it doesn't need to? WanMil
WanMil schrieb am 02.03.2010 18:48:
The patch supports the complete multipolygon specification. And additionally it is tolerant towards incorrect (but reasonable) multipolygons. So why should mkgmap be restrictive if it doesn't need to?
Since there is not really a specification for the OSM tagging, mkgmap should not check the data for correctness but try to support as much taggings as possible. So for example in a style file you must also check for typical typing errors, e.g. "centre" vs "center". Gruss Torsten
On Tue, Mar 2, 2010 at 1:12 PM, Torsten Leistikow <de_muur@gmx.de> wrote:
WanMil schrieb am 02.03.2010 18:48:
The patch supports the complete multipolygon specification. And additionally it is tolerant towards incorrect (but reasonable) multipolygons. So why should mkgmap be restrictive if it doesn't need to?
Since there is not really a specification for the OSM tagging, mkgmap should not check the data for correctness but try to support as much taggings as possible. So for example in a style file you must also check for typical typing errors, e.g. "centre" vs "center".
I've listened to that argument for a while and I'm tired of it. Complete anarchy when tagging make writing software to use OSM data incredibly difficult. At some point people are going to have to grow up and come to an agreement on tagging standards and then stick to it. -- Jeff Ollie
On Tue, Mar 2, 2010 at 1:12 PM, Torsten Leistikow<de_muur@gmx.de> wrote:
WanMil schrieb am 02.03.2010 18:48:
The patch supports the complete multipolygon specification. And additionally it is tolerant towards incorrect (but reasonable) multipolygons. So why should mkgmap be restrictive if it doesn't need to?
Since there is not really a specification for the OSM tagging, mkgmap should not check the data for correctness but try to support as much taggings as possible. So for example in a style file you must also check for typical typing errors, e.g. "centre" vs "center".
I've listened to that argument for a while and I'm tired of it. Complete anarchy when tagging make writing software to use OSM data incredibly difficult. At some point people are going to have to grow up and come to an agreement on tagging standards and then stick to it.
Ok, so revert the description of the patch: * The patch detects polygons with role=outer that is inside another polygon with role=outer and issues a warning for that. The inner in inner case is a well known error :-) WanMil
Jeffrey Ollie schrieb am 02.03.2010 21:07:
I've listened to that argument for a while and I'm tired of it.
And I have tried to fight this anarchy and I got tired of it. So I accepted it as a fact and became much more relaxed and satisfied with OSM :-) Gruss Torsten
I have found that some multipolygons use nested inner polygons. Example: * A forest (outer) with a lake (inner) that has an island (inner) which is not a forest. (example: http://www.openstreetmap.org/browse/relation/331402)
By definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) one has to create two mps. But I see that it is a nice simplification lots of mappers are using.
Attached patch handles this situation. The inner and outer roles are now used as follows: * the outmost polygon must have role=outer (or role=<empty>) * all outmost polygons with role=inner are not used (a warning is issued) * all inside polygons with role=inner use their own tagging * all inside polygons with role=outer use the mp tagging if available or their own tagging if the mp is not tagged * all inside polygons with role=<empty> are categorized automatically as outer/inner depending on the nest level * all inside polygons with role=outer without a direct ambient inner polygon are dropped with a warning message (outer in outer polygon)
Most of the renderers do not support inner in inner polygons but I think it is a very reasonable extension of the multipolygon handling.
This patch also improves the error messages. I haven't seen any more "are not processed due to an unknown reason" messages and I look forward that the community will also not be able to generate any more ... ;-)
WanMil
There have been different opinions about this patch. There is one controversal point: Should mkgmap allow nested inner polygons? From my point of view: YES. Because it does not harm in any way. The nested inner polygons I analysed were all reasonable. Ok, they are not 100% compliant to the specification but this is common to lots of others things in (anarchic) OSM. At the moment I see two possible changes: 1. Issue a warning for any nested inner polygon but process it anyhow. 2. Reject nested inner polygons (and issue a warning). What a pity but they are not 100% compliant. Please let me know what's the opinion of mkgmap community and committers because I want the improvements of error messages to be committed. WanMil
There have been different opinions about this patch.
There is one controversal point: Should mkgmap allow nested inner polygons?
From my point of view: YES. Because it does not harm in any way. The nested inner polygons I analysed were all reasonable. Ok, they are not 100% compliant to the specification but this is common to lots of others things in (anarchic) OSM.
At the moment I see two possible changes: 1. Issue a warning for any nested inner polygon but process it anyhow. 2. Reject nested inner polygons (and issue a warning). What a pity but they are not 100% compliant.
Please let me know what's the opinion of mkgmap community and committers because I want the improvements of error messages to be committed.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
If it is not difficult to implement (also for others) then I would propose integration. If however we knew that mapnik could not implement it without major rewrites, then I would not push it forward as long as it is not at least accepted tagging for a larger minority.
I have found that some multipolygons use nested inner polygons. Example: * A forest (outer) with a lake (inner) that has an island (inner) which is not a forest. (example: http://www.openstreetmap.org/browse/relation/331402)
By definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) one has to create two mps. But I see that it is a nice simplification lots of mappers are using.
Attached patch handles this situation. The inner and outer roles are now used as follows: * the outmost polygon must have role=outer (or role=<empty>) * all outmost polygons with role=inner are not used (a warning is issued) * all inside polygons with role=inner use their own tagging * all inside polygons with role=outer use the mp tagging if available or their own tagging if the mp is not tagged * all inside polygons with role=<empty> are categorized automatically as outer/inner depending on the nest level * all inside polygons with role=outer without a direct ambient inner polygon are dropped with a warning message (outer in outer polygon)
Most of the renderers do not support inner in inner polygons but I think it is a very reasonable extension of the multipolygon handling.
This patch also improves the error messages. I haven't seen any more "are not processed due to an unknown reason" messages and I look forward that the community will also not be able to generate any more ... ;-)
WanMil
There have been different opinions about this patch.
There is one controversal point: Should mkgmap allow nested inner polygons?
From my point of view: YES. Because it does not harm in any way. The nested inner polygons I analysed were all reasonable. Ok, they are not 100% compliant to the specification but this is common to lots of others things in (anarchic) OSM.
At the moment I see two possible changes: 1. Issue a warning for any nested inner polygon but process it anyhow. 2. Reject nested inner polygons (and issue a warning). What a pity but they are not 100% compliant.
Please let me know what's the opinion of mkgmap community and committers because I want the improvements of error messages to be committed.
WanMil
The patch improves the handling of roles and warning messages in multipolygon. - A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow WanMil
The patch improves the handling of roles and warning messages in multipolygon.
- A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow
WanMil
I think you made a good choice. Projects like this are lead by the opinions of those who write the code, and I can see you have made big improvements to mkgmap. Garvan
The patch improves the handling of roles and warning messages in multipolygon.
- A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow
WanMil
I think you made a good choice. Projects like this are lead by the opinions of those who write the code, and I can see you have made big improvements to mkgmap.
Garvan
Thanks a lot!! And thanks to all diligent testers who give very valuable feedback! WanMil
The patch improves the handling of roles and warning messages in multipolygon. - A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow WanMil P.S.: This is an updated patch to r1602.
The patch improves the handling of roles and warning messages in multipolygon. - A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow
WanMil
P.S.: This is an updated patch to r1602.
Is anybody out there who has tested this patch? I think it's worth to commit it. WanMil
On 16.03.2010 18:31, WanMil wrote:
The patch improves the handling of roles and warning messages in multipolygon. - A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow
WanMil
P.S.: This is an updated patch to r1602.
Is anybody out there who has tested this patch? I think it's worth to commit it.
Yes I'm using it without glitches.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, On Tue, Mar 16, 2010 at 06:31:20PM +0100, WanMil wrote:
The patch improves the handling of roles and warning messages in multipolygon. - A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow
WanMil
P.S.: This is an updated patch to r1602.
Is anybody out there who has tested this patch? I think it's worth to commit it.
I just tested it, and it works for me. The amount of MultiPolygon warnings for yesterday's dump of Finland dropped from 549 to 544, but the resulting gmapsupp.img is about the same size. By the way, how could I fix this kind of messages: 2010/03/17 07:06:33 WARNING (MultiPolygonRelation): 63240003.osm.gz: Polygon 461 1686018427476479(16P : (4611686018427472578[16P]) carries role inner but lies in side an inner polygon. Potentially its role should be outer. Could the message include the way ID? Marko
Hi WanMil,
On Tue, Mar 16, 2010 at 06:31:20PM +0100, WanMil wrote:
The patch improves the handling of roles and warning messages in multipolygon. - A reasonable warning message for nested outer and nested inner polygons is given - nested inner polygons are processed anyhow
WanMil
P.S.: This is an updated patch to r1602.
Is anybody out there who has tested this patch? I think it's worth to commit it.
I just tested it, and it works for me. The amount of MultiPolygon warnings for yesterday's dump of Finland dropped from 549 to 544, but the resulting gmapsupp.img is about the same size.
By the way, how could I fix this kind of messages:
2010/03/17 07:06:33 WARNING (MultiPolygonRelation): 63240003.osm.gz: Polygon 461 1686018427476479(16P : (4611686018427472578[16P]) carries role inner but lies in side an inner polygon. Potentially its role should be outer.
Could the message include the way ID?
Marko
You don't see it but the message includes the way id:-) It is an artificially generated way (4611686018427472578) from the generate-sea algorithm so there is no "original" OSM way id. WanMil
Hi WanMil,
By the way, how could I fix this kind of messages:
2010/03/17 07:06:33 WARNING (MultiPolygonRelation): 63240003.osm.gz: Polygon 461 1686018427476479(16P : (4611686018427472578[16P]) carries role inner but lies in side an inner polygon. Potentially its role should be outer.
Could the message include the way ID?
Marko
You don't see it but the message includes the way id:-) It is an artificially generated way (4611686018427472578) from the generate-sea algorithm so there is no "original" OSM way id.
I do understand that there is no OSM relation ID for generate-sea, but I do not understand how there could be no way ID. The natural=coastline are genuine OSM ways, aren't they? Why are these messages generated? Generate-sea is not complaining anything, now that my script strips any incomplete islands from the extract and patches the mainland coastline so that it will reach the tile borders. Also the map is looking good. It is not really a big deal. I have been grepping away the generated IDs from the output, in addition to selected IDs that I have analyzed before (splitter or Geofabrik's osmosis problem). Marko
Hi WanMil,
By the way, how could I fix this kind of messages:
2010/03/17 07:06:33 WARNING (MultiPolygonRelation): 63240003.osm.gz: Polygon 461 1686018427476479(16P : (4611686018427472578[16P]) carries role inner but lies in side an inner polygon. Potentially its role should be outer.
Could the message include the way ID?
Marko
You don't see it but the message includes the way id:-) It is an artificially generated way (4611686018427472578) from the generate-sea algorithm so there is no "original" OSM way id.
I do understand that there is no OSM relation ID for generate-sea, but I do not understand how there could be no way ID. The natural=coastline are genuine OSM ways, aren't they?
Yes they are genuine OSM ways. But these ways are assembled by the generate-sea algorithm to polygons which get a new artificial id (the 4611686018427472578). The multipolygon algorithm does not have any knowledge about the source OSM ways and their ids so it is not possible to create a more detailed log message at that point.
Why are these messages generated? Generate-sea is not complaining anything, now that my script strips any incomplete islands from the extract and patches the mainland coastline so that it will reach the tile borders. Also the map is looking good. It is not really a big deal. I have been grepping away the generated IDs from the output, in addition to selected IDs that I have analyzed before (splitter or Geofabrik's osmosis problem).
The messages are generated because the generate-sea algorithm generated two polygons with role=inner and one of these polygons lies inside the other. I don't know if that's a bug of the generate-sea code or if the OSM data has a problem. I have tried a quick patch so that the mp code can output the original way ids if there is a problem. This patch should NOT be committed. It is not tested.... But hopefully it can help you to find the problem you've had. You will get messages like: Polygon 4611686018427482402(128P : (4603087[82P],4603088[46P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. The first id (4611686018427482402) is the artificial id. The ids in the list (4603087, 4603088) are the original OSM ids. WanMil
Hi WanMil,
The messages are generated because the generate-sea algorithm generated two polygons with role=inner and one of these polygons lies inside the other. I don't know if that's a bug of the generate-sea code or if the OSM data has a problem.
I could imagine that there could be two lakes or two islands within each other, without an island or lake in between. Or perhaps there could legitimately be several "rings" of nested islands and lakes, and generate-sea is not prepared for that. I summarized the warnings I get for finland.osm.bz2: sed -e 's/^.* WARNING (\(.*\)):.*/\1/' <mkgmap.log.0 |sort|uniq -c 13 MapBuilder (highway has no region) 68 MultiPolygonRelation 73 RestrictionRelation (ignored unsupported tags or via ways) 887 RoadDef (discarding extra label (already have 4)) 3 RouteNode (dead-end oneways, now suppressed by adding fixme=continue) Now, let us see those MultiPolygonRelation warnings with generated IDs: 2010/03/18 08:59:59 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/384611 contains errors. 2010/03/18 08:59:59 WARNING (MultiPolygonRelation): 63240001.osm.gz: Polygon 4611686018427395994(14P : (51767205[14P]) carries role outer but lies inside an outer polygon. Potentially its role should be inner. This one could be an error in the map data. I do not understand what the relation is about (something about snow coverage), and I am ignoring this one. Last time I checked, there was a L-shaped unclosed line in the relation, but now the error seems different. 2010/03/18 09:06:13 WARNING (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/405789 contains errors. 2010/03/18 09:06:13 WARNING (MultiPolygonRelation): 63240002.osm.gz: Polygon 4611686018427450887(6P : (23545368[6P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. I guess that this is a tile-splitter problem. 2010/03/18 09:06:17 WARNING (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/406008 contains errors. 2010/03/18 09:06:17 WARNING (MultiPolygonRelation): 63240002.osm.gz: Polygon 4611686018427452464(11P : (25662847[10P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. This one should be a Geofabrik problem (near the cutting polygon) 2010/03/18 09:07:13 WARNING (MultiPolygonRelation): 63240003.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/87598 contains errors. 2010/03/18 09:07:13 WARNING (MultiPolygonRelation): 63240003.osm.gz: Polygon 4611686018427459670(5P : (31747976[5P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. Geofabrik problem. 2010/03/18 09:08:53 WARNING (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/88837 contains errors. 2010/03/18 09:08:53 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427482392(1P : (31828356[1P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. Geofabrik problem. 2010/03/18 09:08:53 WARNING (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/253359 contains errors. 2010/03/18 09:08:53 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427483191(10P : (40982083[10P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. Geofabrik problem. 2010/03/18 09:08:53 WARNING (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/287119 contains errors. 2010/03/18 09:08:53 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427483237(18P : (42303932[17P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. 2010/03/18 09:08:53 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427483238(7P : (23446571[6P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. Geofabrik problem. 2010/03/18 09:08:55 WARNING (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/301046 contains errors. 2010/03/18 09:08:55 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427484412(7P : (43036113[6P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. 2010/03/18 09:08:55 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427484414(8P : (43036115[7P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. Geofabrik problem. Do you agree with my guess that these generated IDs must be coming from the multipolygons quoted immediately above them? Then, finally we have a mystery multipolygon where your patch did not seem to help to identify the source: 2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/4611686018427488909 contains errors. 2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427489620(65P : (4614558[65P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. 2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427489967(18P : (42942687[18P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. 2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427489992(28P : (52019072[28P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. This would be in Northern Finland, most likely on the north tip of the Baltic sea, near the Swedish border. Let us see if my guess was right: http://www.openstreetmap.org/browse/way/4614558 http://www.openstreetmap.org/browse/way/42942687 http://www.openstreetmap.org/browse/way/52019072 Right, all the objects are near Tornio/Haparanda, near the Finnish/Swedish border. I fixed it in JOSM. It seems that the natural=coastline has recently been changed to waterway=riverbank, but some islands were forgotten as natural=coastline, and one island was a duplicate polygon. One island is natural=coastline bordered by waterway=riverbank and natural=coastline. I will move the waterway=riverbank a little further to the coast, just around the island. Thanks for your help! Marko
Hi again WanMil, I forgot to mention that a likely reason why I saw fewer of the warnings today was that I extracted the natural=coastline from finland.osm.bz2, loaded it in JOSM and selected the mainland coastline with my http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WaySelectorPlugin and then tagged all mainland puddles that used to be natural=coastline as natural=water. That could have fixed some generate-sea multipolygons. Now there should be only two distinct natural=coastline multipolygons in my map: the Baltic sea and the lake Päijänne, between Lahti and Jyväskylä. Marko
2010/03/18 09:08:55 WARNING (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/301046 contains errors. 2010/03/18 09:08:55 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427484412(7P : (43036113[6P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon. 2010/03/18 09:08:55 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427484414(8P : (43036115[7P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon.
Geofabrik problem.
Do you agree with my guess that these generated IDs must be coming from the multipolygons quoted immediately above them?
Yes that's true. A warning always consists of one line with the mp link and the further lines print out the specific warnings for this mp.
Then, finally we have a mystery multipolygon where your patch did not seem to help to identify the source:
The mystery mp is generated by the generate-sea code and is the final sea multipolygon.
2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/4611686018427488909 contains errors. 2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427489620(65P : (4614558[65P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. 2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427489967(18P : (42942687[18P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. 2010/03/18 09:09:08 WARNING (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427489992(28P : (52019072[28P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer.
This would be in Northern Finland, most likely on the north tip of the Baltic sea, near the Swedish border. Let us see if my guess was right:
http://www.openstreetmap.org/browse/way/4614558 http://www.openstreetmap.org/browse/way/42942687 http://www.openstreetmap.org/browse/way/52019072
Right, all the objects are near Tornio/Haparanda, near the Finnish/Swedish border. I fixed it in JOSM. It seems that the natural=coastline has recently been changed to waterway=riverbank, but some islands were forgotten as natural=coastline, and one island was a duplicate polygon. One island is natural=coastline bordered by waterway=riverbank and natural=coastline. I will move the waterway=riverbank a little further to the coast, just around the island.
Thanks for your help!
Marko
So we have to wait til tomorrow and then you can check if the generate-sea code will generate a full valid sea area without any flodding for finland? Wow, I hope that's working! WanMil
Hi WanMil,
So we have to wait til tomorrow and then you can check if the generate-sea code will generate a full valid sea area without any flodding for finland? Wow, I hope that's working!
I just checked the islands in Tornio/Haparanda, with today's dump, and I did not notice any flooding there. So, the warning was just a "nuisance"; mkgmap guessed right when eliminating the error. Actually, the flooding is already gone since last week when I added a Perl filter that would strip the incomplete natural=coastline islands from the Geofabrik dump and move the endpoints of the mainland natural=coastline to the rectangular area borders. Yes, the sea will look weird, but I think it is good, because then nobody will assume to find any islands outside the Finnish border. Actually, it could be even better to make the sea polygon follow the Finnish territorial waters, because the Geofabrik dump would be missing most islands outside the border. But I guess someone who would navigate with OSM on the Baltic would not produce the map from a country extract. My original plan was to download some coastlines separately and glue those to the Geofabrik dump with osmosis. But apparently it did not work as I expected, because generate-sea kept complaining. So I decided to do the Perl tweaking instead. It is much faster too. :-) Marko
Hi WanMil,
So we have to wait til tomorrow and then you can check if the generate-sea code will generate a full valid sea area
Now the generate-sea originated MultiPolygon warnings are gone. The splitter problems remain, and I have not studied the islands near tile borders. Some weeks ago, before I had converted most natural=coastline lakes to proper multipolygons, I did see some flooding in a lake near a tile border. This is really great progress. Seeing the sea really helps orientation for most Finnish users I would say, given that at least a third of them do live within 30km from the sea or from a major lake. Marko
participants (7)
-
Chris-Hein Lunkhusen -
Felix Hartmann -
Garvan & maew -
Jeffrey Ollie -
Marko Mäkelä -
Torsten Leistikow -
WanMil