Re: [mkgmap-dev] expression test !=
On 28.03.2010 09:05, Torsten Leistikow wrote: Moin, in the Wiki the != test is described as follows: highway!=motorway This will be true when the highway tag exists, but it does NOT have the value motorway. From my understanding this should read like highway!=motorway This will be true when the highway tag exists, but it does NOT have the value motorway, or when there is no highway tag at all. Shall I correct the description in the Wiki or must I correct my understanding of the != test? Yes. That is how it works. Wiki is often outdated or incomplete, or sometimes even wrong... Gruss Torsten ___ 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] Boundary Lines
Torsten Leistikow schrieb: I see in Mapsource many boundary lines which are not existing in the OSM data. See attached screen shot. Are these lines coming from the multipolygon processing? Probably yes. On 17.02. WanMil provided a patch, that allowed the distinction between the original (source) ways of a multipolygon and the artifical (generated) ways from the mkgmap multipolygon processing. But to make use of this patch you must adapt your style file, so it was never commited to the trunk. I don't know how the MP code works, but it should not copy tags like boundary=* to the multipolygon cutting lines. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Generate coastline - can we keep the coastline way?
Toby Speight schrieb: When --generate-coastline=multipolygon fails, I'm left with a map that has no distinction between land and sea. However, if I don't use --generate-coastline, I at least get a line (from my style/lines). Is there any good reason why generating coastline prevents the line rules from being applied to the coastline ways? Hi, I'm a little confused, are you talking about the --generate-sea option? I also noticed the coastline disappearing when using --generate-sea=extend-sea-sectors and would be glad to have it again. ;-) Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Incorrect multipolygon warnings?
Hi, Whilst processing Italy, I've been getting a lot of mp warnings like: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439638 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36433060 I can't see anything wrong with this mp and the JOSM validator does not pick up on anything. Is this an error with mkgmap's MP code or am I missing something? Yes and no. While reading in the data from osm files mkgmap converts all coordinates to the garmin internal format. This reduces the resolution of the coordinates. So the multipolygon code works with other coordinates than OSM. Due to this a polygon might intersect itself although it does not in the original OSM data. Here's another: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439886 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36434237 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Boundary Lines
Chris-Hein Lunkhusen schrieb am 28.03.2010 14:22: I don't know how the MP code works, but it should not copy tags like boundary=* to the multipolygon cutting lines. They should stop putting the boundaries into multipolygons. The problem is, that the boundaries are tagged as areas (thats the meaning of using multipolygons), but they are drawn on the maps as lines around the border of the area. The boundary multipolygons are handled the same way as all multipolygons. If a multipolygon is cut into smaller pieces, all pieces are tagged in the same way as the original multipolygon. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Generate coastline - can we keep the coastline way?
On Sun, Mar 28, 2010 at 02:26:04PM +0200, Chris-Hein Lunkhusen wrote:
I also noticed the coastline disappearing when using
--generate-sea=extend-sea-sectors and would be glad to
have it again. ;-)
Can you fake the coastline by moving the end nodes of your map extract
to the tile borders, like I do:
bzip2 -dc $OSM_BZ2|
perl -e \
'my $del=0;
while(){
$del=1 if (/way id=(4581(437|716|666)|461(1822|076[56]))|22877669/);
s/(node id=28954629.*lat=)60\.51542/$159.414063/;
s/(node id=29193143.*lon=)24\.12826/$119.116211/;
print unless $del;
$del=0 if m|/way|;
}' $OSM
The script deletes some incomplete islands from the Geofabrik finland.osm.bz2
and moves the end nodes of the mainland coastline to the rectangular tile
borders. Before this solution, I tried to glue some coastline to the
Geofabrik extract with osmosis --merge, but that apparently failed for
some reason.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Boundary Lines
On Sun, Mar 28, 2010 at 03:34:58PM +0200, Torsten Leistikow wrote:
Chris-Hein Lunkhusen schrieb am 28.03.2010 14:22:
I don't know how the MP code works, but it should not copy tags
like boundary=* to the multipolygon cutting lines.
They should stop putting the boundaries into multipolygons.
Would it be possible to control the MultiPolygon handler from the
relations style file, something like this:
type=multipolygon boundary!=* { set mkgmap:multipolygon=1 }
Something like this would allow one to create multipolygons for
administrative areas that are not tagged as type=multipolygon.
Examples: highlighting Russia+Kaliningrad, or highlighting the
province around a city differently from the city.
The problem is, that the boundaries are tagged as areas (thats the
meaning of using multipolygons), but they are drawn on the maps as lines
around the border of the area.
Another problem is (as far as I understand) that it is not possible to
distinguish multipolygon cutting lines from original multipolygon role=*
lines. The output of the MultiPolygon handler is really areas, not lines.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Question to --add-pois-to-areas
Hi! How should --add-pois-to-areas work? Here is a Zoo:http://www.openstreetmap.org/?lat=28.40885lon=-16.56398zoom=17layers=B000FTF but it has got neighter icon nor can it be found in the POI search. How is this option expected to work? TIA, Dani P.S: This part is very small so maps are generated very fast: http://download.geofabrik.de/osm/africa/canary_islands.osm.bz2 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Incorrect multipolygon warnings?
WanMil escribió: Hi, Whilst processing Italy, I've been getting a lot of mp warnings like: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439638 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36433060 I can't see anything wrong with this mp and the JOSM validator does not pick up on anything. Is this an error with mkgmap's MP code or am I missing something? Yes and no. While reading in the data from osm files mkgmap converts all coordinates to the garmin internal format. This reduces the resolution of the coordinates. So the multipolygon code works with other coordinates than OSM. Due to this a polygon might intersect itself although it does not in the original OSM data. Here's another: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439886 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36434237 I also have a mp warning in which I can't see any error: 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/2909 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489521 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889739 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276547 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276563 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288870 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288868 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51442603 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276562 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489071 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489520 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489515 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889860 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889776 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889848 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889700 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51334155 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889699 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/2909 does not contain any way tagged with role=outer or empty role If I check relation 2909 in JOSM it does have lots of ways tagged with role outer and they are connected in a closed polygon, apparently in the right order. Do you have any clue? May it be a clockwise/counterclockwise issue? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question to --add-pois-to-areas
Daniela Duerbeck escribió: Hi! How should --add-pois-to-areas work? Here is a Zoo:http://www.openstreetmap.org/?lat=28.40885lon=-16.56398zoom=17layers=B000FTF but it has got neighter icon nor can it be found in the POI search. How is this option expected to work? TIA, Dani P.S: This part is very small so maps are generated very fast: http://download.geofabrik.de/osm/africa/canary_islands.osm.bz2 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev First off all, you may need to add an area=yes tag to the polygon, in order to mkgmap know it's an area. Second, you need a corresponding tourism=zoo line in your points file, otherwise the poi won't be created. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question to --add-pois-to-areas
Carlos Dávila escribió: Daniela Duerbeck escribió: Hi! How should --add-pois-to-areas work? Here is a Zoo:http://www.openstreetmap.org/?lat=28.40885lon=-16.56398zoom=17layers=B000FTF but it has got neighter icon nor can it be found in the POI search. How is this option expected to work? TIA, Dani P.S: This part is very small so maps are generated very fast: http://download.geofabrik.de/osm/africa/canary_islands.osm.bz2 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev First off all, you may need to add an area=yes tag to the polygon, in order to mkgmap know it's an area. Second, you need a corresponding tourism=zoo line in your points file, otherwise the poi won't be created. I've seen we have amenity=zoo in the default points style, but in the wiki zoos are said to be tagged as tourism=zoo. Probably we should add the latter to default style. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question to --add-pois-to-areas
Hi Carlos! I've seen we have amenity=zoo in the default points style, but in the wiki zoos are said to be tagged as tourism=zoo. Probably we should add the latter to default style. It was already inside the points file. Should then also buildings get an area=yes (e.g. here my Aldi-Supermarket: http://www.openstreetmap.org/?lat=48.090925lon=11.507215zoom=18layers=B000FTF) or do we need an additional --add-poi-to-buildings beside add-poi-to-areas? TIA, Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question to --add-pois-to-areas
2010/3/28 Daniela Duerbeck daniela.duerb...@gmx.de: Hi Carlos! I've seen we have amenity=zoo in the default points style, but in the wiki zoos are said to be tagged as tourism=zoo. Probably we should add the latter to default style. It was already inside the points file. Should then also buildings get an area=yes (e.g. here my Aldi-Supermarket: http://www.openstreetmap.org/?lat=48.090925lon=11.507215zoom=18layers=B000FTF) or do we need an additional --add-poi-to-buildings beside add-poi-to-areas? No, area=yes is not needed, because as opposed to a node, when a way gets tagged with building=*, it's clear that it's meant to be an area. You only need area=yes for ways that normally aren't areas, such as highway=residential. -Martin ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Incorrect multipolygon warnings?
Am 28.03.2010 17:24, schrieb Carlos Dávila: WanMil escribió: Hi, Whilst processing Italy, I've been getting a lot of mp warnings like: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439638 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36433060 I can't see anything wrong with this mp and the JOSM validator does not pick up on anything. Is this an error with mkgmap's MP code or am I missing something? Yes and no. While reading in the data from osm files mkgmap converts all coordinates to the garmin internal format. This reduces the resolution of the coordinates. So the multipolygon code works with other coordinates than OSM. Due to this a polygon might intersect itself although it does not in the original OSM data. Here's another: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439886 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36434237 I also have a mp warning in which I can't see any error: 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/2909 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489521 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889739 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276547 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276563 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288870 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288868 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51442603 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276562 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489071 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489520 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489515 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889860 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889776 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889848 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889700 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51334155 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889699 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/2909 does not contain any way tagged with role=outer or empty role If I check relation 2909 in JOSM it does have lots of ways tagged with role outer and they are connected in a closed polygon, apparently in the right order. Do you have any clue? May it be a clockwise/counterclockwise issue? Clockwise/Counterclockwise does not make any difference. Probably this is a tile splitter problem and therefore the multipolygon is not completely cotainted in the tile. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] Do not process boundary relations
At the moment processing of multipolygon boundary relations creates a
lot of unwanted effects (artificial boundaries on tile bounds, lots of
warnings etc.).
The patch excludes the boundary relations from the multipolygon
processing. This can be changed with the new option
--process-boundary-relations.
An additional spin-off is the improved performance and less warnings.
WanMil
Index: resources/help/en/options
===
--- resources/help/en/options (revision 1624)
+++ resources/help/en/options (working copy)
@@ -234,10 +234,17 @@
--ignore-turn-restrictions
When reading OSM files, ignore any restriction relations.
+--process-boundary-relations
+ When reading OSM files, boundary relations are processed. By default
+ they are not processed because most of the boundary relations are
+ incomplete due to splitting of OSM files. When processing these
+ incomplete multipolygons additional artificial boundary lines are
+ created on the tile bounds.
+
--ignore-osm-bounds
When reading OSM files, ignore any bounds elements.
With this option selected generate-sea sometimes works better,
- but routing accross tiles will not work.
+ but routing across tiles will not work.
--preserve-element-order
Process the map elements (nodes, ways, relations) in the order
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
(revision 1624)
+++ src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
(working copy)
@@ -109,6 +109,7 @@
private final boolean makeOppositeCycleways;
private final boolean makeCycleways;
private final boolean ignoreBounds;
+ private final boolean processBoundaryRelations;
private final boolean ignoreTurnRestrictions;
private final boolean linkPOIsToWays;
private final boolean generateSea;
@@ -174,6 +175,7 @@
minimumArcLength = null;
frigRoundabouts = props.getProperty(frig-roundabouts);
ignoreTurnRestrictions =
props.getProperty(ignore-turn-restrictions, false);
+ processBoundaryRelations =
props.getProperty(process-boundary-relations, false);
reportUndefinedNodes =
props.getProperty(report-undefined-nodes, false);
String deleteTagsFileName =
props.getProperty(delete-tags-file);
if(deleteTagsFileName != null)
@@ -600,7 +602,13 @@
long id = currentRelation.getId();
relationMap.put(id, currentRelation);
- currentRelation.processElements();
+ if (processBoundaryRelations == false
+currentRelation instanceof MultiPolygonRelation
+
((MultiPolygonRelation)currentRelation).isBoundaryRelation()) {
+ log.info(Ignore boundary multipolygon
+currentRelation.toBrowseURL());
+ } else {
+ currentRelation.processElements();
+ }
ListMap.EntryString,Relation entries =
deferredRelationMap.remove(id);
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(revision 1624)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(working copy)
@@ -98,6 +98,10 @@
copyTags(other);
}
+ public boolean isBoundaryRelation() {
+ return getTag(boundary) != null;
+ }
+
/**
* Retrieves the mp role of the given element.
*
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Incorrect multipolygon warnings?
WanMil escribió: Am 28.03.2010 17:24, schrieb Carlos Dávila: WanMil escribió: Hi, Whilst processing Italy, I've been getting a lot of mp warnings like: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439638 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36433060 I can't see anything wrong with this mp and the JOSM validator does not pick up on anything. Is this an error with mkgmap's MP code or am I missing something? Yes and no. While reading in the data from osm files mkgmap converts all coordinates to the garmin internal format. This reduces the resolution of the coordinates. So the multipolygon code works with other coordinates than OSM. Due to this a polygon might intersect itself although it does not in the original OSM data. Here's another: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439886 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36434237 I also have a mp warning in which I can't see any error: 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/2909 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489521 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889739 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276547 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276563 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288870 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288868 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51442603 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276562 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489071 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489520 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489515 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889860 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889776 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889848 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889700 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51334155 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889699 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/2909 does not contain any way tagged with role=outer or empty role If I check relation 2909 in JOSM it does have lots of ways tagged with role outer and they are connected in a closed polygon, apparently in the right order. Do you have any clue? May it be a clockwise/counterclockwise issue? Clockwise/Counterclockwise does not make any difference. Probably this is a tile splitter problem and therefore the multipolygon is not completely cotainted in the tile. Not a tile problem, but I've realized this mp is cut by geofabrik (it's in Spain/Portugal border). It is correctly processed when I compile full Iberian Peninsula map (from Europe excerpt), not just Spain or Portugal. Is there any workaround for these cases? (I have a lot more in Spain/France border). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Incorrect multipolygon warnings?
WanMil escribió: Am 28.03.2010 17:24, schrieb Carlos Dávila: WanMil escribió: Hi, Whilst processing Italy, I've been getting a lot of mp warnings like: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439638 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36433060 I can't see anything wrong with this mp and the JOSM validator does not pick up on anything. Is this an error with mkgmap's MP code or am I missing something? Yes and no. While reading in the data from osm files mkgmap converts all coordinates to the garmin internal format. This reduces the resolution of the coordinates. So the multipolygon code works with other coordinates than OSM. Due to this a polygon might intersect itself although it does not in the original OSM data. Here's another: 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: Polygon 4611686018427439886 intersects itself. It is splitted into 2 polygons. 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The polygon is composed of 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: - http://www.openstreetmap.org/browse/way/36434237 I also have a mp warning in which I can't see any error: 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/2909 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489521 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889739 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276547 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276563 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288870 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52288868 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51442603 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/11276562 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489071 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489520 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/52489515 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889860 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889776 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889848 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889700 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/51334155 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: - way: http://www.openstreetmap.org/browse/way/4889699 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/2909 does not contain any way tagged with role=outer or empty role If I check relation 2909 in JOSM it does have lots of ways tagged with role outer and they are connected in a closed polygon, apparently in the right order. Do you have any clue? May it be a clockwise/counterclockwise issue? Clockwise/Counterclockwise does not make any difference. Probably this is a tile splitter problem and therefore the multipolygon is not completely cotainted in the tile. Not a tile problem, but I've realized this mp is cut by geofabrik (it's in Spain/Portugal border). It is correctly processed when I compile full Iberian Peninsula map (from Europe excerpt), not just Spain or Portugal. Is there any workaround for these cases? (I have a lot more in Spain/France border). Unfortunately not. The mp processing performs some simple autoclosing of unclosed polygons. This happens if the polygon can be closed without any self-intersections. WanMil
Re: [mkgmap-dev] [PATCH v1] Do not process boundary relations
WanMil schrieb am 28.03.2010 21:43: The patch excludes the boundary relations from the multipolygon processing. This can be changed with the new option --process-boundary-relations. This might solve the actual problem, but I think it is a dirty hack. When we have the next tag with such a problem, will we add another option switch? Instead we should look for a cleaner solution, where either the mp processing can be better controlled via a style file (e.g. a new style file applicable tags for the mp-processing or perhaps limit the mp-processing to the expressions listed in the polygon file), or where the results of the mp-processings will be marked, so that the original and the artifical polygons can be distinguished in the following processings. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Do not process boundary relations
WanMil schrieb am 28.03.2010 21:43: The patch excludes the boundary relations from the multipolygon processing. This can be changed with the new option --process-boundary-relations. This might solve the actual problem, but I think it is a dirty hack. When we have the next tag with such a problem, will we add another option switch? Instead we should look for a cleaner solution, where either the mp processing can be better controlled via a style file (e.g. a new style file applicable tags for the mp-processing or perhaps limit the mp-processing to the expressions listed in the polygon file), or where the results of the mp-processings will be marked, so that the original and the artifical polygons can be distinguished in the following processings. Gruss Torsten I agree that we should look for a cleaner solution. But at the moment we don't have one. It will take some time until we have a reasonable solution for this. I started with an idea to tag all polygons created by the mp processing. But I think that's too complicated for the style file. Please start a new thread where we can think about how the new tag handling of the mp processing and the connection to the style system should look like. I am happy if more than two of us (I don't have good knowledge of the style system) are talking about fundamental improvements. Just for now I strongly recommend to use this patch until a better solution is ready to use. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Do not process boundary relations
On 28.03.2010 21:43, WanMil wrote: At the moment processing of multipolygon boundary relations creates a lot of unwanted effects (artificial boundaries on tile bounds, lots of warnings etc.). The patch excludes the boundary relations from the multipolygon processing. This can be changed with the new option --process-boundary-relations. An additional spin-off is the improved performance and less warnings. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev For me the patch works very well (I don't know of any reason why I would need to have this behaviour tuneable via style-file, but as often, needs only arise once it is possible). Especially the annoying border artefacts of borders on the geofabrik cuttings are gone However even though I don't really know if it is the same reason. When compiling contourlines, there are also very often straight artefact lines crossing the whole image, maybe the same patch should be used when outputting lines 0x20-0x26 and 0x17??? (these are the contourline regions, and cannot be used for other features) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question to --add-pois-to-areas
Hi Martin! No, area=yes is not needed, because as opposed to a node, when a way gets tagged with building=*, it's clear that it's meant to be an area. You only need area=yes for ways that normally aren't areas, such as highway=residential. But the Aldi is not found when I search for Supermarkets or by Name. TIA, Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question to --add-pois-to-areas
2010/3/29 Daniela Duerbeck daniela.duerb...@gmx.de: Hi Martin! No, area=yes is not needed, because as opposed to a node, when a way gets tagged with building=*, it's clear that it's meant to be an area. You only need area=yes for ways that normally aren't areas, such as highway=residential. But the Aldi is not found when I search for Supermarkets or by Name. OK, I just checked my own garmin map and the Aldi is present and searchable. It was catched by this line in my points-file: shop=supermarket [0x2e02 resolution 20] Looks like some rule catched it before. Do you have a rule for buildings or housenumbers in your points-file? And is it above the supermarket rule? if so, just move it somewhere below - always make sure the more important rules are on top or use continue if you want both to be triggered. -Martin ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
