Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Am 13.10.2010 22:09, schrieb WanMil: char...@cferrero.net schrieb am 27.09.2010 15:20: As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area). Gruss Torsten Hi Torsten, I am back and I have thought about your request. It would be possible to implement a patch which keeps the original polygons in case they are tagged differently to the multipolygon. I have also read Charlies answers and before digging in the code I would know if this feature is really needed and useful? Can you estimate how many multipolygons are affected? WanMil Hi, I have posted a patch (Improved tagging of multipolygons) that should fix it. Please test it! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
char...@cferrero.net schrieb am 27.09.2010 15:20: As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area). Gruss Torsten Hi Torsten, I am back and I have thought about your request. It would be possible to implement a patch which keeps the original polygons in case they are tagged differently to the multipolygon. I have also read Charlies answers and before digging in the code I would know if this feature is really needed and useful? Can you estimate how many multipolygons are affected? WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Torsten Leistikow (de_m...@gmx.de) wrote: WanMil schrieb am 24.09.2010 19:29: My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area. You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know. I tried your patch today, and I think it looks quite promising. Implementing such a strict scheme will certainly show some faulty multipolygon (e.g. Aussenalster in Hamburg), but perhaps this will encourage a cleaner tagging of such relations. I think the patch has still one problem: If the tags of the outerpolygon are not used for the multipolygon area, they must still be used as a stand-alone polygon. As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
char...@cferrero.net schrieb am 27.09.2010 15:20: As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area). Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Torsten Leistikow (de_m...@gmx.de) wrote: char...@cferrero.net schrieb am 27.09.2010 15:20: As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area). Gruss Torsten OK, but in practical terms if mkgmap generated a nature reserve polygon, a wood multipolygon and an inner water polygon, wouldn't the visible results be undefined? In other words, you could end up with either: a) Wood multipolygon water polygon hidden underneath a nature reserve polygon, or b) A nature reserve polygon hidden underneath the wood mp and water polygon depending on draw order of the polygons (which afaik you can't control). -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
char...@cferrero.net schrieb am 27.09.2010 16:49: OK, but in practical terms if mkgmap generated a nature reserve polygon, a wood multipolygon and an inner water polygon, wouldn't the visible results be undefined? In other words, you could end up with either: a) Wood multipolygon water polygon hidden underneath a nature reserve polygon, or b) A nature reserve polygon hidden underneath the wood mp and water polygon depending on draw order of the polygons (which afaik you can't control). You can control the draw order of the polygons via the style file. So depending on the targeted use of your map, the result will look differently but clearly defined. In case of the example: My map style would display the wood and the water next to each other. The nature reserve is displayed on top of both, but it is a semi transparent texture. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 19:29: My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area. You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know. I tried your patch today, and I think it looks quite promising. Implementing such a strict scheme will certainly show some faulty multipolygon (e.g. Aussenalster in Hamburg), but perhaps this will encourage a cleaner tagging of such relations. I think the patch has still one problem: If the tags of the outerpolygon are not used for the multipolygon area, they must still be used as a stand-alone polygon. As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
The other relations seem to have water reversed also. For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter. Markus_g For the -Original Message- From: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Markus Sent: Friday, 24 September 2010 4:00 PM To: char...@cferrero.net; 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap Hi Charlie, The only problem I could find for the first relation is the water is reversed. I am about to look at the others http://www.openstreetmap.org/browse/relation/552313 Markus_g -Original Message- From: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Charlie Ferrero Sent: Friday, 24 September 2010 3:42 PM To: Development list for mkgmap Subject: [mkgmap-dev] Trouble getting some multipolygons to render in mkgmap Hi, I'm having trouble getting mkgmap to render (using either the default style or my custom style) some multipolygons which I'm fairly sure are OK. The first is this one: http://www.openstreetmap.org/browse/relation/552313 The inner water way renders fine, but the outer way (leisure=park / barrier=wall) only renders the wall and not the park polygon. It renders fine both in mapnik and in osmarender. Another is the paired set of nested multipolygons at the nearby equestrian club: http://www.openstreetmap.org/browse/relation/414803 and http://www.openstreetmap.org/browse/relation/1184439 These both look fine in mapnik but this time osmarender only shows the inner multipolygon and mkgmap shows neither. And finally: http://www.openstreetmap.org/browse/relation/660096 Which renders fine in mapnik and osmarender, but not mkgmap I'm assuming I somehow tagged these mps wrongly as I created them...can someone point out my error? I'm sure it'll be a doh moment for me. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
On 24/09/2010 10:42, Markus wrote: The other relations seem to have water reversed also. For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter. Markus_g For the Markus, Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it. Also, the multipolygon usage section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: The direction of the ways does not matter -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Not sure if it maters. But in JOSM validator it reversed water:land not on left side. This is why I thought it was correct. Markus_g -Original Message- From: Charlie Ferrero [mailto:char...@cferrero.net] Sent: Friday, 24 September 2010 4:31 PM To: Markus Cc: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap On 24/09/2010 10:42, Markus wrote: The other relations seem to have water reversed also. For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter. Markus_g For the Markus, Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it. Also, the multipolygon usage section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: The direction of the ways does not matter -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Hi Charlie, With the tests I have just done I have found the leisure tag no longer works with multipolygons. Regards, Markus_g -Original Message- From: Charlie Ferrero [mailto:char...@cferrero.net] Sent: Friday, 24 September 2010 4:31 PM To: Markus Cc: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap On 24/09/2010 10:42, Markus wrote: The other relations seem to have water reversed also. For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter. Markus_g For the Markus, Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it. Also, the multipolygon usage section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: The direction of the ways does not matter -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Hi, Markus is right. The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list. Attached patch extends this list by the tags leisure, military, man_made, place, tourism, amenity. I have found them by analyzing the europe OSM dump so this should catch most cases. By the way: the direction of ways is not evaluated. WanMil Hi Charlie, With the tests I have just done I have found the leisure tag no longer works with multipolygons. Regards, Markus_g -Original Message- From: Charlie Ferrero [mailto:char...@cferrero.net] Sent: Friday, 24 September 2010 4:31 PM To: Markus Cc: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap On 24/09/2010 10:42, Markus wrote: The other relations seem to have water reversed also. For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter. Markus_g For the Markus, Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it. Also, the multipolygon usage section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: The direction of the ways does not matter -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java === --- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (revision 1702) +++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (working copy) @@ -70,9 +70,9 @@ * if one of these tags are contained in the multipolygon then the outer * ways use the mp tags instead of their own tags. */ - private static final ListString polygonTags = Arrays.asList(boundary, - natural, landuse, land_area, building, waterway); - + private static final CollectionString polygonTags = new HashSetString(Arrays.asList(boundary, + natural, landuse, land_area, building, waterway, + leisure, military, man_made, place, tourism, amenity)); /** * Create an instance based on an existing relation. We need to do this * because the type of the relation is not known until after all its tags ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35: The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list. My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area. There shouldn't be a list of concerned tags, since any area tags may be used. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the
relevant polygon tags or if the tagging should be taken from the outer
ways. For this purpose a list of known polygon tags is used and up to
now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the
relation OR on the outer polygons. So the outerpoylgons are only to be used,
when there are no tags on the relation.
If the relation itself is tagged and there is a tag on the outerpolygons, this
does logical mean, that the outerpolygon tags apply to the complete area
including the inner-area.
There shouldn't be a list of concerned tags, since any area tags may be used.
I agree.
But the real world does not strictly follow this definition.
Unfortunately very lots of mps are tagged with some non polygon tags and
therefore I introduced the list of well known polygon tags. At least
this was neccessary when I implemented the mp code.
You càn check yourself if it's now the time to remove this polygon list.
I have attached a patch that follows your proposal. Just test it and let
us know.
WanMil
Gruss
Torsten
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (revision 1702)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (working copy)
@@ -67,13 +67,6 @@
private static final double OVERLAP_TOLERANCE_DISTANCE = 2.0d;
/**
- * if one of these tags are contained in the multipolygon then the outer
- * ways use the mp tags instead of their own tags.
- */
- private static final ListString polygonTags = Arrays.asList(boundary,
- natural, landuse, land_area, building, waterway);
-
- /**
* Create an instance based on an existing relation. We need to do this
* because the type of the relation is not known until after all its tags
* are read in.
@@ -771,7 +764,7 @@
// check if the polygon has tags and therefore should be processed
boolean processPolygon = currentPolygon.outer
- || hasPolygonTags(currentPolygon.polygon);
+ || hasTags(currentPolygon.polygon);
if (processPolygon) {
ListWay singularOuterPolygons;
@@ -798,7 +791,7 @@
}
boolean useRelationTags = currentPolygon.outer
- hasPolygonTags(this);
+ hasTags(this);
if (useRelationTags) {
// the multipolygon contains tags that overwhelm the
// tags of the outer polygon
@@ -1374,22 +1367,19 @@
return w;
}
- private boolean hasPolygonTags(JoinedWay way) {
+ private boolean hasTags(JoinedWay way) {
for (Way segment : way.getOriginalWays()) {
- if (hasPolygonTags(segment)) {
+ if (hasTags(segment)) {
return true;
}
}
return false;
}
- private boolean hasPolygonTags(Element element) {
+ private boolean hasTags(Element element) {
for (Map.EntryString, String tagEntry : element.getEntryIteratable()) {
- if (natural.equals(tagEntry.getKey()) coastline.equals(tagEntry.getValue())) {
-// ignore natural=coastline because this is not a real polygon tag
-continue;
- }
- if (polygonTags.contains(tagEntry.getKey())) {
+ if (type.equals(tagEntry.getKey()) == false) {
+// return true if there is more than one tag other than type
return true;
}
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
