Re: [mkgmap-dev] edge 705 stuck with cities index
2012/2/21 Thorsten Kukuk ku...@suse.de: That's why I use --name-tag-list=name,place_name meanwhile. Hi Thorsten, This worked and do not suffer the freezes when listing the nearest cities. However, these formerly unnamed cities are now duplicates of some cities (I verified this matches the coordinates of the previously unnamed city points). In other words, on the map, some cities have two identical points exactly at the same place. Is there a way to avoid this? The best would be indeed to avoid listing the unnamed cities on the map. Thanks, Eric ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] edge 705 stuck with cities index
Hi Eric, On Wed, Feb 22, Eric Fernandez wrote: 2012/2/21 Thorsten Kukuk ku...@suse.de: That's why I use --name-tag-list=name,place_name meanwhile. Hi Thorsten, This worked and do not suffer the freezes when listing the nearest cities. However, these formerly unnamed cities are now duplicates of some cities (I verified this matches the coordinates of the previously unnamed city points). In other words, on the map, some cities have two identical points exactly at the same place. Is there a way to avoid this? The best would be indeed to avoid listing the unnamed cities on the map. If you change the rule place=city ... to place=city name=* ... You should get only citys with a name. Yuo need to adjust that of course for the other place=* rules, too. But this sounds like a bug in the OSM data. Could you give me some examples, where you have duplicate POIs? Then I can check if this is an OSM data bug or how to better solve this. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] edge 705 stuck with cities index
2012/2/22 Thorsten Kukuk ku...@suse.de: Hi, If you change the rule place=city ... to place=city name=* ... I am using the default style in mkgmap, so isn't that a bug in this default style's rule? Shouldn't it be corrected in mkgmap? But this sounds like a bug in the OSM data. Could you give me some examples, where you have duplicate POIs? Then I can check if this is an OSM data bug or how to better solve this. Thorsten Hi, Here are some examples close to Oxford: Sandford-on-Thames: N 51 42.620' W001 13.721' Bayworth: N 51 42.522' W001 16.668' Sunningwell: N 51 42.065' W001 17.042' Shippon: N 51 40.785' W001 18.439' Wytham: N 51 46.489' W001 18.696' Hope this helps, Eric ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] edge 705 stuck with cities index
2012/2/22 aighes o...@aighes.de: Am 22.02.2012 11:44, schrieb Eric Fernandez: 2012/2/22 Thorsten Kukukku...@suse.de: Hi, If you change the rule place=city ... to place=city name=* ... I am using the default style in mkgmap, so isn't that a bug in this default style's rule? Shouldn't it be corrected in mkgmap? For me it isn't a bug. The information there is a village/town/city/... could be very important. Mainly in not well mapped areas. In a village/ you will find markets, general help, Henning Hi, I understand your point, but the problem here is having unnamed cities created from polygons, which are duplicates of real city/villages. The best way to handle this would be to correct mkgmap to avoid getting these blank duplicates into the map. The intent is not to remove information. Eric ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] feature-request - variable copyright information
Hi, MapSource shows as copyright information the following lines: /Map created with mkgmap-r2220 Map data licenced under Creative Commons Attribution ShareAlike 2.0 OpenStreetMap and contributors Program released under the GPL http://creativecommons.org/licenses/by-sa/2.0/ www.openstreetmap.org/ In near future OSM will change the licence, so I think Garmin-maps could also released with other licences than cc-by-sa. So it would be great to chage these lines to a fix part /Map created with mkgmap-r2220 / /Program released under the GPL / and a variable part for the licence of the map and licence information of the input. this could be done in a txt-file. If there is no txt-file, there should be a default. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
Hi, On Wed, Feb 22, aighes wrote: and a variable part for the licence of the map and licence information of the input. this could be done in a txt-file. If there is no txt-file, there should be a default. Did you ever look at mkgmap --help=options? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] edge 705 stuck with cities index
2012/2/22 Thorsten Kukuk ku...@suse.de: That the name is blank is a bug in your (or the default) style: the polygons all have a name tag: place_name. That's the tag used for a period of time for places in OSM, and we should use that if no name tag is there. The best solution is really to use the option I wrote already here in the thread. The bigger problem is, that the tags for the place node and the place polygon from your examples are even conflicting :( On of the both (polygon or node) needs to be deleted and the other one should be corrected. But since I don't know the area, I cannot say which of the two is the correct one and fix it. Thorsten I just had a look at these places on OSM and indeed, they have both a POI Village (or Hamlet, etc) with the set name (e.g. Cumnor), and around a polygon also called Village with no set name. I assume the blank name comes from this unnamed polygon then. Is this what you mention? So does that violate OSM rules for naming areas/villages? Also, you say the style itself has a bug: so is the bug in the map, in the style, or both? Should all place=XXX entries in points style file be followed with name=*? Or should we use the option --name-tag-list=name,place_name or simply change mkgmap so that it does not add unnamed place_name to the map? Sorry to be daft but this is a bit confusing, considering the possible bug reasons and workarounds. Finally, if the mkgmap default style has a bug, how to report this? Thanks, Eric ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] edge 705 stuck with cities index
On Wed, Feb 22, Eric Fernandez wrote: 2012/2/22 Thorsten Kukuk ku...@suse.de: That the name is blank is a bug in your (or the default) style: the polygons all have a name tag: place_name. That's the tag used for a period of time for places in OSM, and we should use that if no name tag is there. The best solution is really to use the option I wrote already here in the thread. The bigger problem is, that the tags for the place node and the place polygon from your examples are even conflicting :( On of the both (polygon or node) needs to be deleted and the other one should be corrected. But since I don't know the area, I cannot say which of the two is the correct one and fix it. Thorsten I just had a look at these places on OSM and indeed, they have both a POI Village (or Hamlet, etc) with the set name (e.g. Cumnor), and around a polygon also called Village with no set name. Haven't checked Cumnor, but the one I checked have one: place_name They are not without name, we only don't evaluate the alternate tag. I assume the blank name comes from this unnamed polygon then. Is this what you mention? So does that violate OSM rules for naming areas/villages? Please read again what I wrote above: place_name is used, no OSM rules are violated. Also, you say the style itself has a bug: so is the bug in the map, in the style, or both? Should all place=XXX entries in points style file be followed with name=*? Or should we use the option --name-tag-list=name,place_name or simply change mkgmap so that it does not add unnamed place_name to the map? Sorry to be daft but this is a bit confusing, considering the possible bug reasons and workarounds. The bug is that place_name is not used for places. It doesn't matter how you fix it, you can fix it in a lot of different ways. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
On Wed, Feb 22, aighes wrote: Am 22.02.2012 17:53, schrieb Thorsten Kukuk: Or did I misundestood your request? I would like to have this both lines in the copyright-text, shown in MapSource. /Map created with mkgmap-r2220 //Program released under the GPL echo (c) OpenStreetMap and contributors (www.openstreetmap.org). Map data licenced under Creative Commons Attribution ShareAlike 2.0 (http://creativecommons.org/licenses/by-sa/2.0/). Map created with mkgmap-r2220 and data from 2012-02-22 license.txt mkgmap --license-file=license.txt works fine for me. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
Am 22.02.2012 18:35, schrieb Thorsten Kukuk: On Wed, Feb 22, aighes wrote: Am 22.02.2012 17:53, schrieb Thorsten Kukuk: Or did I misundestood your request? I would like to have this both lines in the copyright-text, shown in MapSource. /Map created with mkgmap-r2220 //Program released under the GPL echo (c) OpenStreetMap and contributors (www.openstreetmap.org). Map data licenced under Creative Commons Attribution ShareAlike 2.0 (http://creativecommons.org/licenses/by-sa/2.0/). Map created with mkgmap-r2220 and data from 2012-02-22 license.txt mkgmap --license-file=license.txt Of course it would, but I have to add mkgmap-version manually. It wont be a big thing, but it would be easier if mkgmap would do it, as they would like to have it written. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
On Wed, Feb 22, aighes wrote: Am 22.02.2012 18:35, schrieb Thorsten Kukuk: On Wed, Feb 22, aighes wrote: Am 22.02.2012 17:53, schrieb Thorsten Kukuk: Or did I misundestood your request? I would like to have this both lines in the copyright-text, shown in MapSource. /Map created with mkgmap-r2220 //Program released under the GPL echo (c) OpenStreetMap and contributors (www.openstreetmap.org). Map data licenced under Creative Commons Attribution ShareAlike 2.0 (http://creativecommons.org/licenses/by-sa/2.0/). Map created with mkgmap-r2220 and data from 2012-02-22 license.txt mkgmap --license-file=license.txt Of course it would, but I have to add mkgmap-version manually. It wont be a big thing, but it would be easier if mkgmap would do it, as they would like to have it written. Beside that mkgmap itself reports as version always only svn, I don't think that it is a good idea to have this splitted, into a hardcoded part and a variable one. Would make it very hard to adjust the text for your map if you need to do so. And redirecting the output of mkgmap --version to a file is a really simple task. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch] sequence in marine charts
Am 22.02.2012 05:10, schrieb Thorsten Kukuk:
Hi,
On Tue, Feb 21, Ronny Klier wrote:
I had a look for the occurences of sequence format like 1+(1),1+(3) in
OSM and found it used at least in GB, france and spain. Given this wide
usage, this patch allows , as seperator. Additional (), which mark
phases of eclipse, are handled explicit and not as seperator.
Looks like the patch itself is missing.
Thorsten
Sorry, here it is.
Index: src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java
===
--- src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java (Revision 2221)
+++ src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java (Arbeitskopie)
@@ -439,21 +439,32 @@
if(sequence != null) {
StringBuffer periods = new StringBuffer();
- for(String p : sequence.split([+()])) {
-if (p.isEmpty())
- continue;
-if(periods.length() 0)
- periods.append(,);
-periods.append(Double.parseDouble(p));
+ StringBuffer eclipse = new StringBuffer();
+ for(String p : sequence.split([+,])) {
+if (p.startsWith(() p.endsWith())) {
+ // phases of eclipse are enclosed in (), remove them
+ p = p.substring(1, p.length()-1);
+ if(eclipse.length() 0)
+ eclipse.append(,);
+ eclipse.append(Double.parseDouble(p));
+} else {
+ if(periods.length() 0)
+ periods.append(,);
+ periods.append(Double.parseDouble(p));
+}
}
attributes.put(period, periods.toString());
+ attributes.put(eclipse, eclipse.toString());
}
if(mapObject instanceof Point) {
Light[] lights = parseLights(attributes.get(light));
int[] periods = parsePeriods(attributes.get(period));
-
+ int[] eclipse = parsePeriods(attributes.get(eclipse));
+ if (1 != periods.length periods.length != eclipse.length)
+log.error(number of light and eclipse phases has to be equal);
+
if(type8to15 == 0x0100) { // lights
byte flags0 = 0;
int lightType = lightType();
@@ -486,6 +497,13 @@
}
++nob;
}
+ for(int p : eclipse) {
+ while(p 0x3f) {
+ ++nob;
+ p -= 0x3f;
+ }
+ ++nob;
+ }
flags1 |= 0x01; // further record present?
}
else if(morseLetter != null)
@@ -531,6 +549,8 @@
int period = 0;
for(int p : periods)
period += p;
+for(int p : eclipse)
+ period += p;
if(period 255)
lightType |= 0x40; // 9th bit of period
else if(period 511) {
@@ -599,22 +619,22 @@
extraBytes[i++] = (byte)((lc 5) | lr);
}
if(periods.length 1) {
- extraBytes[i++] = (byte)(0x80 + periods.length / 2);
+ extraBytes[i++] = (byte)(0x80 + periods.length);
// first all lights
- for (int pi = 0; pi periods.length; pi+=2) {
- while(periods[pi] 0x3f) {
+ for (int p : periods) {
+ while(p 0x3f) {
extraBytes[i++] = (byte)0x3f;
- periods[pi] -= 0x3f;
+ p -= 0x3f;
}
- extraBytes[i++] = (byte)periods[pi];
+ extraBytes[i++] = (byte)p;
}
// second all pause
- for (int pi = 1; pi periods.length; pi+=2) {
- while(periods[pi] 0x3f) {
+ for (int p : eclipse) {
+ while(p 0x3f) {
extraBytes[i++] = (byte)0x3f;
- periods[pi] -= 0x3f;
+ p -= 0x3f;
}
- extraBytes[i++] = (byte)periods[pi];
+ extraBytes[i++] = (byte)p;
}
}
else if(morseLetter != null)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
Am 22.02.2012 19:23, schrieb Thorsten Kukuk: And redirecting the output of mkgmap --version to a file is a really simple task. Hi did you tried it? echo java -jar mkgmap.jar --version test.txt doesn't work. Version is only printed to stdout (cmd), not to test.txt. I don't know if it is a Windows-thing or a mkgmap-thing. If this works, everything would be fine. :-) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
On Thu, Feb 23, aighes wrote: Am 22.02.2012 19:23, schrieb Thorsten Kukuk: And redirecting the output of mkgmap --version to a file is a really simple task. Hi did you tried it? echo java -jar mkgmap.jar --version test.txt doesn't work. Version is only printed to stdout (cmd), not to test.txt. I don't know if it is a Windows-thing or a mkgmap-thing. If this works, everything would be fine. :-) Don't know about Windows, but with Linux: java -jar mkgmap.jar --version 2 test.txt No need for the echo. And you need to redirect stderr. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
Hi, sorry, echo was a fault in my email. Doesn't work on windows for me. But I can handle the version manually. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
On Thu, Feb 23, Henning Scholland wrote: Hi, sorry, echo was a fault in my email. Doesn't work on windows for me. But I can handle the version manually. But according to the Microsoft support database, it should: http://support.microsoft.com/kb/110930 Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Holes in the Sea
Hi, I am a step further: After commenting out #natural=coastline [0x15 resolution 16] in my style, all those Polyline errors are away. Most of the holes in the sea are also gone. Only the small hole south of Nice and a big one west of Ireland are still there. I suppose it´s all about memory. The coastline may be too complex to process. Now I ordered some more memory. I hope 8 GB can close those last remaining sea holes. http://wiki.openstreetmap.org/wiki/User:RheinSkipper -Ursprüngliche Nachricht- Von: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev- boun...@lists.mkgmap.org.uk] Im Auftrag von Marko Mäkelä Gesendet: Freitag, 17. Februar 2012 22:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Holes in the Sea On Fri, Feb 17, 2012 at 05:14:53PM +0100, RheinSkipper wrote: Also attached is a screenshot of those terrible holes in the sea. I do not have idea about the max-nodes in the splitter, but the holes are so regular that they should be relatively easy to figure out. Can you determine the tiles corresponding to the holes? Are there any natural=coastline ways in the tiles? If not, mkgmap should assume that the whole tile is land. I would start by checking the hole south of Nizza, as it is smaller. Try to convert the tile.osm.pbf to XML format with Osmosis and then do grep 'natural.*coastline' tile.osm. If there is no match, then my guess should be right. I have had the opposite problem. Someone added an island to a lake with natural=coastline. Previously, the tile had no natural=coastline ways (it was all land). The result was that everything except the small island was converted to water. mkgmap did not produce a warning; technically, it could warn about overlap between natural=water, waterway=riverbank and natural=coastline. If it´s a memory issue, which options can I modify to save memory? As far as I understand, the 'area too small to split' and related messages are due to limitations of the Garmin map format and of Garmin devices. They do not have that much RAM to play with; that is why the map tiles must be relatively small. I hope that this helps. Marko ___ 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] edge 705 stuck with cities index
2012/2/22 aighes o...@aighes.de: Hi, there isn't an error in mkgmap. Your problem is, that thee are 2 osm-objects for one object in reality. You could handle this error different. Eg.: * fix osm-data in osm-db * fix your osm-extract on your pc * change your points-style-file The best would be to fix the error in osm-db. --add-pois-to-area does what it should do. Create for each area a node. There shouldn't be any tests in the code. such tests you can implement in your style-file. Henning Thanks Henning for the information. You say there shouldn't be any test in the code, but we have some already: --report-undefined-nodes or --remove-short-arcs. Logging level provides messages which are useful, and this issue might be worth logging. Cheers, Eric ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
