Question regarding duplicated shapes
Hi all, while debugging the shape merger I found many duplicated shapes in Finland, and I am not sure how mkgmap should handle them. Example: http://www.openstreetmap.org/way/105723026 is tagged landuse=farm and is the role=inner member of multipolygon relation http://www.openstreetmap.org/relation/1504949 which has only one role=outer way which also is tagged landuse=farm. Way http://www.openstreetmap.org/way/105719041 is a copy of way 105723026, but with reverse order of points. It is tagged natural=scrub mkgmap r2960 with the default style and --preserve-element-order adds three shapes: one for the outer way with type 0x4e one for way 105719041 with type 0x4f one for way 105723026 with type 0x4e As a result, the natural=scrub is not shown in GPSMapEdit. My shape merger first merges the outer way and the inner way and then adds the natural=scrub later. Now GPSMapEdit shows the area. My understanding is that something goes wrong in the MultiPolygonRelation code. Why is way 105723026 added with type 0x4e? Gerd
On Sun, Jan 12, 2014 at 03:46:30PM +0100, Gerd Petermann wrote:
while debugging the shape merger I found many duplicated shapes in Finland, and I am not sure how mkgmap should handle them.
Oh, the Corine import by "teollisuus" ("industry" in Finnish) is hopeless IMO. :( It is based on very inaccurate data, and the converter is generating duplicate ways and improperly tagged multipolygon relations, like in your example. Instead of defining the area-style tags on the multipolygon relation itself, this import added the tags to all relation members (both role=inner and role=outer). JOSM at least used to display this as intended, IIRC. Whenever I have fixed some multipolygon error in Finland, I have tried to remove the duplicate shapes, and to move the area-style tags to the multipolygon relation. It is sometimes tricky if someone has already tried to edit the imported data.
Example:
http://www.openstreetmap.org/way/105723026
is tagged landuse=farm and is the role=inner member of multipolygon relation http://www.openstreetmap.org/relation/1504949 which has only one role=outer way which also is tagged landuse=farm. Way http://www.openstreetmap.org/way/105719041 is a copy of way 105723026, but with reverse order of points. It is tagged natural=scrub
Yes, this is exactly what I have seen many times. FWIW, I do not think that mkgmap should spend too much effort in supporting this broken and redundant way of mapping multipolygons. The Corine data is very low-resolution, basically useless. Now that we finally got the license stuff sorted out at http://www.openstreetmap.org/copyright the import from the National Land Survey database is "only" a matter of writing and configuring a converter, and manually resolving conflicts with existing data. In this process, the Corine landuse imports will probably be deleted. Best regards, Marko
Hi Marko, thanks for the explanation. So I'll better use other data for testing ;-) Gerd
Date: Sun, 12 Jan 2014 23:55:20 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question regarding duplicated shapes
On Sun, Jan 12, 2014 at 03:46:30PM +0100, Gerd Petermann wrote:
while debugging the shape merger I found many duplicated shapes in Finland, and I am not sure how mkgmap should handle them.
Oh, the Corine import by "teollisuus" ("industry" in Finnish) is hopeless IMO. :( It is based on very inaccurate data, and the converter is generating duplicate ways and improperly tagged multipolygon relations, like in your example.
Instead of defining the area-style tags on the multipolygon relation itself, this import added the tags to all relation members (both role=inner and role=outer). JOSM at least used to display this as intended, IIRC.
Whenever I have fixed some multipolygon error in Finland, I have tried to remove the duplicate shapes, and to move the area-style tags to the multipolygon relation. It is sometimes tricky if someone has already tried to edit the imported data.
Example:
http://www.openstreetmap.org/way/105723026
is tagged landuse=farm and is the role=inner member of multipolygon relation http://www.openstreetmap.org/relation/1504949 which has only one role=outer way which also is tagged landuse=farm. Way http://www.openstreetmap.org/way/105719041 is a copy of way 105723026, but with reverse order of points. It is tagged natural=scrub
Yes, this is exactly what I have seen many times.
FWIW, I do not think that mkgmap should spend too much effort in supporting this broken and redundant way of mapping multipolygons. The Corine data is very low-resolution, basically useless. Now that we finally got the license stuff sorted out at http://www.openstreetmap.org/copyright the import from the National Land Survey database is "only" a matter of writing and configuring a converter, and manually resolving conflicts with existing data. In this process, the Corine landuse imports will probably be deleted.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Gerd Petermann -
Marko Mäkelä