[mkgmap-dev] Multipolygon problem
Hello all,
I have the following rule in my polygons style:
surface=sand [0x1b resolution 20]
The problem is the following multipolygon:
http://www.openstreetmap.org/browse/relation/1221199
This is a complex multipolygon which, in certain sections, uses the
coastline to define the outer. Parts of the coastline (and therefore
parts of the multipolygon) have the key/tag pair surface=sand
The result is that mkgmap attempts to build a multipolygon for Port
Philip Bay and fill it with sand, which is not ideal:
http://www.cferrero.net/maps/img/1.png
What I can't figure out is how to adjust my polygon style rules to avoid
this happening. Or tell mkgmap not to process multipolygons of type
natural=bay
Neither of the following two variations of the rule makes any difference:
surface=sand natural!=coastline [0x1b resolution 20]
surface=sand type=!multipolygon [0x1b resolution 20]
Nor does
natural=coastline surface=sand {delete surface}
make any difference whether I put it in the lines file or the polygons file
Does anyone have a suggestion on how to fix this?
Thanks!
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index Branch 1764
El 08/01/11 00:10, Felix Hartmann escribió: However on the good side, instead of a popping up crash notice, I get a regular (no error) pop up message: the selected street is not valid in this map product, please select a different street. Using --code-page=1252 is still broke however for Umlauts, as the city is inside the index with an Umlaut, but the address without Umlaut. So you cannot find streets in cities (though for provinces or states Umlauts are fine now) that have an Umlaut, if you enter the city. (city without Umlaut is not accepted, and city with Umlaut will not find the address). Here is a screenshot of the problem. Note Moedling on the address and Mödling in the city field (city moedling cannot be entered, as it does not exist): this is with --latin1 (and yes, --latin1 seems to work much better than cp1252): In my maps I can find cities like Sigüenza and streets like Calle General Yagüe. I use --latin1 and --cp1252. Mapsource is 6.13.7 under wine. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index Branch 1764
On 08.01.2011 09:36, Carlos Dávila wrote: El 08/01/11 00:10, Felix Hartmann escribió: However on the good side, instead of a popping up crash notice, I get a regular (no error) pop up message: the selected street is not valid in this map product, please select a different street. Using --code-page=1252 is still broke however for Umlauts, as the city is inside the index with an Umlaut, but the address without Umlaut. So you cannot find streets in cities (though for provinces or states Umlauts are fine now) that have an Umlaut, if you enter the city. (city without Umlaut is not accepted, and city with Umlaut will not find the address). Here is a screenshot of the problem. Note Moedling on the address and Mödling in the city field (city moedling cannot be entered, as it does not exist): this is with --latin1 (and yes, --latin1 seems to work much better than cp1252): In my maps I can find cities like Sigüenza and streets like Calle General Yagüe. I use --latin1 and --cp1252. Mapsource is 6.13.7 under wine. I can do that too. But i cannot find street ABC in city Sigüenza (if I put Sigüenza as city) - I can find street ABC without entering a city! I can also find street ABC in province ÜÖÄ - only as you see in my screenshot the city in the address index (but not in the city index) is loosing the Umlauts. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
Moin, I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons. But if you change your polygon style from surface=sand [0x1b resolution 20] to surface=sand natural!=coastline [0x1b resolution 20] this shouldn't happen any more. Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely? And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with rule in style
On 07/01/11 22:31, Carlos Dávila wrote:
I want to translate different highway types into others using some
physical tags. I'm testing:
highway=secondary (width7 | shoulder:width0.5) {set highway=primary }
but the shoulder:width condition is not taken into account. What I'm I
doing wrong?
You are doing nothing wrong, its just that only integer values are
recognised. Decimal values like 0.5 are treated as 0.
This should probably be fixed to deal with decimals.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
On 08/01/2011 13:02, Torsten Leistikow wrote: Moin, I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons. But if you change your polygon style from surface=sand [0x1b resolution 20] to surface=sand natural!=coastline [0x1b resolution 20] this shouldn't happen any more. Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely? And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it. Gruss Torsten Hi Torsten, You may be right - it might just be that the polygon rule makes mkgmap create a surface=sand polygon for coastline ways tagged with surface=sand. Unfortunately it is legitimate to tag a way as surface=sand so I cannot correct the OSM data. I need some way of telling mkgmap not to create a surface=sand polygon when it is associated with a coastline. Unfortunately surface=sand natural!=coastline [0x1b resolution 20] does not solve the problem. I think this may be because the natural=coastline tag is being removed during the --generate-sea processing, so it is no longer there when the polygon code starts. The only way I can currently solve it is to remove the surface=sand rule completely, which I don't want to have to do. Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
I am not sure why surface=sand really needs to be on the ways.
But even if surface=sand is on the ways mkgmap shouldn't be creating
polygons from it if the ways aren't closed. As surface=sand can be used for
ways or areas.
I might send a message to the original creator of the ways to ask if they
mind If I remove the surface=sand as it isn't fully accurate anyway.
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: Saturday, 8 January 2011 6:58 PM
To: Development list for mkgmap
Subject: [mkgmap-dev] Multipolygon problem
Hello all,
I have the following rule in my polygons style:
surface=sand [0x1b resolution 20]
The problem is the following multipolygon:
http://www.openstreetmap.org/browse/relation/1221199
This is a complex multipolygon which, in certain sections, uses the
coastline to define the outer. Parts of the coastline (and therefore
parts of the multipolygon) have the key/tag pair surface=sand
The result is that mkgmap attempts to build a multipolygon for Port
Philip Bay and fill it with sand, which is not ideal:
http://www.cferrero.net/maps/img/1.png
What I can't figure out is how to adjust my polygon style rules to avoid
this happening. Or tell mkgmap not to process multipolygons of type
natural=bay
Neither of the following two variations of the rule makes any difference:
surface=sand natural!=coastline [0x1b resolution 20]
surface=sand type=!multipolygon [0x1b resolution 20]
Nor does
natural=coastline surface=sand {delete surface}
make any difference whether I put it in the lines file or the polygons file
Does anyone have a suggestion on how to fix this?
Thanks!
--
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] ArrayIndexOutOfBoundsException in index branch
I compiled a germany map with the index branch and got the following exception: Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 0 at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:41) at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:1) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.mergeSort(Unknown Source) at java.util.Arrays.sort(Unknown Source) at java.util.Collections.sort(Unknown Source) at uk.me.parabola.imgfmt.app.mdr.MdrUtils.sortList(MdrUtils.java:83) at uk.me.parabola.imgfmt.app.mdr.Mdr11.writeSectData(Mdr11.java:51) at uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSection(MDRFile.java:237) at uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:191) at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:175) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:270) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
I have attached that patch to limit polygon creation to closed ways. It's untested and I assume there are some unwanted effects at tile borders. Please check and if you (and others) find it usefull it can be committed. WanMil Moin, I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons. But if you change your polygon style from surface=sand [0x1b resolution 20] to surface=sand natural!=coastline [0x1b resolution 20] this shouldn't happen any more. Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely? And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it. Gruss Torsten ___ 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/osmstyle/StyledConverter.java === --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1773) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -283,7 +283,7 @@ preConvertRules(way); Rule rules; - if (polyline.equals(way.getTag(mkgmap:stylefilter))) + if (polyline.equals(way.getTag(mkgmap:stylefilter)) || way.isClosed() == false) rules = lineRules; else if (polygon.equals(way.getTag(mkgmap:stylefilter))) rules = polygonRules; ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ArrayIndexOutOfBoundsException in index branch
Hi I compiled a germany map with the index branch and got the following exception: Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 0 at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:41) I've found that this happens when there is a character that cannot be represented in the character set. I am about to commit a patch that will replace any such character with a '?' character. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ArrayIndexOutOfBoundsException in index branch
Hi I compiled a germany map with the index branch and got the following exception: Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 0 at uk.me.parabola.imgfmt.app.srt.SrtSortKey.compareTo(SrtSortKey.java:41) I've found that this happens when there is a character that cannot be represented in the character set. I am about to commit a patch that will replace any such character with a '?' character. ..Steve Thanks Steve, I can confirm that the Exception has disappeared. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index Branch 1764
El 08/01/11 09:42, Felix Hartmann escribió: On 08.01.2011 09:36, Carlos Dávila wrote: El 08/01/11 00:10, Felix Hartmann escribió: However on the good side, instead of a popping up crash notice, I get a regular (no error) pop up message: the selected street is not valid in this map product, please select a different street. Using --code-page=1252 is still broke however for Umlauts, as the city is inside the index with an Umlaut, but the address without Umlaut. So you cannot find streets in cities (though for provinces or states Umlauts are fine now) that have an Umlaut, if you enter the city. (city without Umlaut is not accepted, and city with Umlaut will not find the address). Here is a screenshot of the problem. Note Moedling on the address and Mödling in the city field (city moedling cannot be entered, as it does not exist): this is with --latin1 (and yes, --latin1 seems to work much better than cp1252): In my maps I can find cities like Sigüenza and streets like Calle General Yagüe. I use --latin1 and --cp1252. Mapsource is 6.13.7 under wine. I can do that too. But i cannot find street ABC in city Sigüenza (if I put Sigüenza as city) - I can find street ABC without entering a city! I can also find street ABC in province ÜÖÄ - only as you see in my screenshot the city in the address index (but not in the city index) is loosing the Umlauts. In my case neither Sigüenza nor Siguenza seem to be in the address index. If I search for any street that exists in Sigüenza, leaving city field blank, Mapsource finds that street in all other cities, but not in Sig(ü/u)enza. I also noticed index branch maps are missing lots of streets. For example, trunk map shows hundreds of streets called Calle de xxx as you write in the Select street window, while index maps don't find any. If I search for Calle de Pio Xii, trunk map outputs this exact name in several cities, but index map outputs also some Calle de P streets. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] Use a default family index
In case no family id is given the 6829 is used as default.
Any ideas for a better default id? 6829 is just a random number.
This avoids problems when using the maps in MapSource (especially
searching).
WanMil
Index: resources/help/en/options
===
--- resources/help/en/options (revision 1775)
+++ resources/help/en/options (working copy)
@@ -136,6 +136,8 @@
--family-id
This is an integer that identifies a family of products.
+ Range: [1..]
+ Mkgmap default: 6829
--family-name
If you build several maps, this option describes the
Index: src/uk/me/parabola/mkgmap/combiners/NsisBuilder.java
===
--- src/uk/me/parabola/mkgmap/combiners/NsisBuilder.java (revision 1775)
+++ src/uk/me/parabola/mkgmap/combiners/NsisBuilder.java (working copy)
@@ -43,7 +43,7 @@
private String typName;
public void init(CommandArgs args) {
- int familyId = args.get(family-id, 0);
+ int familyId = args.get(family-id, CommandArgs.DEFAULT_FAMILYID);
productId = args.get(product-id, 1);
baseFilename = args.get(overview-mapname, osmmap);
Index: src/uk/me/parabola/mkgmap/combiners/FileInfo.java
===
--- src/uk/me/parabola/mkgmap/combiners/FileInfo.java (revision 1775)
+++ src/uk/me/parabola/mkgmap/combiners/FileInfo.java (working copy)
@@ -341,7 +341,7 @@
}
public int getFamilyId() {
- return args.get(family-id, 0);
+ return args.get(family-id, CommandArgs.DEFAULT_FAMILYID);
}
public int getProductId() {
Index: src/uk/me/parabola/mkgmap/combiners/MdxBuilder.java
===
--- src/uk/me/parabola/mkgmap/combiners/MdxBuilder.java (revision 1775)
+++ src/uk/me/parabola/mkgmap/combiners/MdxBuilder.java (working copy)
@@ -31,7 +31,7 @@
private String outputDir;
public void init(CommandArgs args) {
- int familyId = args.get(family-id, 0);
+ int familyId = args.get(family-id, CommandArgs.DEFAULT_FAMILYID);
int productId = args.get(product-id, 1);
mdxFilename = args.get(overview-mapname, osm) + .mdx;
Index: src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java
===
--- src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java (revision 1775)
+++ src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java (working copy)
@@ -73,7 +73,7 @@
areaName = args.get(area-name, Overview Map);
- int familyId = args.get(family-id, 0);
+ int familyId = args.get(family-id, CommandArgs.DEFAULT_FAMILYID);
int productId = args.get(product-id, 1);
short productVersion = (short)args.get(product-version, 100);
Index: src/uk/me/parabola/mkgmap/CommandArgs.java
===
--- src/uk/me/parabola/mkgmap/CommandArgs.java (revision 1775)
+++ src/uk/me/parabola/mkgmap/CommandArgs.java (working copy)
@@ -5,6 +5,8 @@
import uk.me.parabola.util.EnhancedProperties;
public class CommandArgs {
+ public static final int DEFAULT_FAMILYID = 6829;
+
private final EnhancedProperties currentOptions;
public CommandArgs(EnhancedProperties args) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with rule in style
El 08/01/11 10:47, Steve Ratcliffe escribió:
On 07/01/11 22:31, Carlos Dávila wrote:
I want to translate different highway types into others using some
physical tags. I'm testing:
highway=secondary (width7 | shoulder:width0.5) {set highway=primary }
but the shoulder:width condition is not taken into account. What I'm I
doing wrong?
You are doing nothing wrong, its just that only integer values are
recognised. Decimal values like 0.5 are treated as 0.
This should probably be fixed to deal with decimals.
Would it be too complex to fix it? In Spain highways are tagged
according to administrative criteria [1] and having this option route
calculation could be improved significantly.
[1] http://wiki.openstreetmap.org/wiki/Normalización
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
