Re: [mkgmap-dev] Overview map in gmapsupp.img?
Hi all, I followed the discussion, but I am not sure about the results. My understanding so far: If you disable the basemap or if you don't like the basemap in the device you should either add the overview map to the gmapsupp file or use low resolution levels for each tile. I see no reason why we should not add the overview map to the gmapsupp if that is what the user wants and the device is working fine with it. Gerd > Date: Sat, 21 Feb 2015 15:44:45 +0100 > From: po...@poczta.onet.pl > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Overview map in gmapsupp.img? > > Hi Ralf, > > >What is the advantage of using more map tile levels instead of putting > >them into the overview map? > > This is a standard design, supported by mkgmap and Garmin tools. Yours > is not, so you have to do some additional work. Isn't it the reason, for > which you have started this thread? > > Have you tried a search for cities in eTrex? I think you can get double > hits for cities present on overview map. > > -- > Best regards, > Andrzej > ___ > 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] SEVERE log messages from housenumber2 r3471
Hi Gerd, On Mon, Feb 23, Gerd Petermann wrote: > Hi Thorsten, > > I was able to reproduce the "unexpected result" messages, but I found > no "zero length interval" message for Germany, Austria and an older > Czech-republic download from end of 2014. > Maybe that one depends on the style? I can reproduce it with the default style: 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: detected unplausible co mbination of intervals in Viovka 130..75 and 79..79 houses: right [130(26), 12 7(26), 75(26)] right [79(0)] road id(s):127718589, 25464598 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: duplicating number node in road id=127718589, Viovka (n26),N,0,0,B,130,75 [] [130(26), 127(26), 75(26 )] 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: zero length interval ad ded in street id=127718589, Viovka (n26),N,0,0,B,130,75 ==> (n26),N,0,0,N,0,0 + (n27),N,0,0,O,127,75 2015/02/23 08:33:12 SEVERE (ExtNumbers): 71300045.osm.pbf: zero length interval has no numbers in road id=127718589, Viovka 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: detected unplausible combination of intervals in Viovka 127..75 and 79..79 houses: right [127(27), 75(27)] right [79(0)] road id(s):127718589, 25464598 I can upload 71300045.osm.pbf later when I'm in the office. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (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] SEVERE log messages from housenumber2 r3471
Hi Thorsten, I was able to reproduce the "unexpected result" messages, but I found no "zero length interval" message for Germany, Austria and an older Czech-republic download from end of 2014. Maybe that one depends on the style? Gerd > Date: Sat, 21 Feb 2015 18:11:13 +0100 > From: ku...@suse.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] SEVERE log messages from housenumber2 r3471 > > On Sat, Feb 21, GerdP wrote: > > > Hi Thorsten, > > > > I've no time this weekend, will look at it on Monday. > > Which is absolute no problem, enjoy your weekend! > > > I've committed r3474 which reports the road id in the "zero length interval" > > message. > > Ok, I will update to r3474 and test tomorrow. > > Thorsten > > > Gerd > > > > Thorsten Kukuk wrote > > > Hi, > > > > > > with the r3471 (housenumber2), I see some SEVERE log messages > > > from mkgmap: > > > > > > build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:42:33 SEVERE > > > (ExtNumbers): 71200082.osm.pbf: zero length interval has no numbers > > > build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:44:44 SEVERE > > > (ExtNumbers): 71200091.osm.pbf: zero length interval has no numbers > > > build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:52:08 SEVERE > > > (HousenumberGenerator): 71200120.osm.pbf: Hlvkova 1336 > > > http://www.openstreetmap.org/way/237856642 unexpected result in > > > plausibility check, counters: 0 0 > > > > > > build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 07:58:30 SEVERE > > > (ExtNumbers): 71700081.osm.pbf: zero length interval has no numbers > > > build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:02:06 SEVERE > > > (HousenumberGenerator): 71700095.osm.pbf: 's-Gravenweg 332 > > > +http://www.openstreetmap.org/node/2793534692 unexpected result in > > > plausibility check, counters: 0 0 > > > build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:03:21 SEVERE > > > (ExtNumbers): 71700100.osm.pbf: zero length interval has no numbers > > > build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:03:35 SEVERE > > > (HousenumberGenerator): 71700101.osm.pbf: Guldenberg 1 > > > +http://www.openstreetmap.org/node/2773681907 unexpected result in > > > plausibility check, counters: 0 0 > > > > > > Same for Czech Republic, too. > > > > > > Thorsten > > > -- > > > Thorsten Kukuk, Senior Architect SLES & Common Code Base > > > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > > > GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, > > > Graham Norton, HRB 21284 (AG Nürnberg) > > > ___ > > > mkgmap-dev mailing list > > > > > mkgmap-dev@.org > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > -- > > View this message in context: > > http://gis.19327.n5.nabble.com/SEVERE-log-messages-from-housenumber2-r3471-tp5834456p5834469.html > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > -- > Thorsten Kukuk, Senior Architect SLES & Common Code Base > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham > Norton, HRB 21284 (AG Nürnberg) > ___ > 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] Oneway
Many thanks. Dave On Sun, Feb 22, 2015 at 8:47 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > yes, I think you got it. One special case: > mkgmap reverses the order of the points > for a routable way with oneway=-1 tag . > > Gerd > > -- > From: daveswarth...@gmail.com > Date: Sun, 22 Feb 2015 20:19:46 +0700 > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Oneway > > > No, everything is working as it should. I merely wanted to better > understand how decisions are made about displaying the arrows in the > correct direction. It is not obvious from reading TYP files or style > directives how this is done. So if I reword my question again, let's say > you have a dual carriageway. Both lanes have the same oneway=yes tag and > both use the same TYP code. Yet one lane displays the arrows pointing left > to right, while the other lane has them pointing right to left. Either the > Garmin unit or mkgmap has to decide how to draw those arrows. > > From what you are saying, I'm assuming it's the direction the way was > drawn that determines the directionality of those arrows. And furthermore, > it is the Garmin software (and Basecamp) that actually makes the decision > based on information in the IMG file. Is that correct? > > Thanks for taking the time to answer > > > On Sun, Feb 22, 2015 at 6:48 PM, Andrzej Popowski > wrote: > > Hi Dave, > > Garmin format as used in img allows only for equivalent of oneway=1. > Mkgmap have to reverse line direction in case of oneway=-1. So you need > only one pattern in TYP file, with arrows pointing form left to right. > Actually it means arrows pointing from start of a line towards its end. > > I'm trying to guess what is your real question. Do you get arrows pointing > in wrong direction? > > -- > Best regards, > Andrzej > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > ___ 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] the north sea is empty
Am Samstag, 21. Februar 2015, 18:17:35 schrieb Bernd Weigelt:
> not only the north sea, other sea polygons, too
> i use these options to create my maps over a long time
Found the solution, error or what ever
I had no polygon 0x32 in my TYP file, only this line in water_polygons
natural=sea { add mkgmap:skipSizeFilter=true }[0x32 resolution 10]
adding a polygon definition to the TYP does the trick, but i had to add the
draworder '6', too. An empty draworder is bad ;-)
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway
Hi Dave, yes, I think you got it. One special case: mkgmap reverses the order of the points for a routable way with oneway=-1 tag . Gerd From: daveswarth...@gmail.com Date: Sun, 22 Feb 2015 20:19:46 +0700 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Oneway No, everything is working as it should. I merely wanted to better understand how decisions are made about displaying the arrows in the correct direction. It is not obvious from reading TYP files or style directives how this is done. So if I reword my question again, let's say you have a dual carriageway. Both lanes have the same oneway=yes tag and both use the same TYP code. Yet one lane displays the arrows pointing left to right, while the other lane has them pointing right to left. Either the Garmin unit or mkgmap has to decide how to draw those arrows. >From what you are saying, I'm assuming it's the direction the way was drawn >that determines the directionality of those arrows. And furthermore, it is the >Garmin software (and Basecamp) that actually makes the decision based on >information in the IMG file. Is that correct? Thanks for taking the time to answer On Sun, Feb 22, 2015 at 6:48 PM, Andrzej Popowski wrote: Hi Dave, Garmin format as used in img allows only for equivalent of oneway=1. Mkgmap have to reverse line direction in case of oneway=-1. So you need only one pattern in TYP file, with arrows pointing form left to right. Actually it means arrows pointing from start of a line towards its end. I'm trying to guess what is your real question. Do you get arrows pointing in wrong direction? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ 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] Oneway
No, everything is working as it should. I merely wanted to better understand how decisions are made about displaying the arrows in the correct direction. It is not obvious from reading TYP files or style directives how this is done. So if I reword my question again, let's say you have a dual carriageway. Both lanes have the same oneway=yes tag and both use the same TYP code. Yet one lane displays the arrows pointing left to right, while the other lane has them pointing right to left. Either the Garmin unit or mkgmap has to decide how to draw those arrows. >From what you are saying, I'm assuming it's the direction the way was drawn that determines the directionality of those arrows. And furthermore, it is the Garmin software (and Basecamp) that actually makes the decision based on information in the IMG file. Is that correct? Thanks for taking the time to answer On Sun, Feb 22, 2015 at 6:48 PM, Andrzej Popowski wrote: > Hi Dave, > > Garmin format as used in img allows only for equivalent of oneway=1. > Mkgmap have to reverse line direction in case of oneway=-1. So you need > only one pattern in TYP file, with arrows pointing form left to right. > Actually it means arrows pointing from start of a line towards its end. > > I'm trying to guess what is your real question. Do you get arrows pointing > in wrong direction? > > -- > Best regards, > Andrzej > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway
Hi Dave, Garmin format as used in img allows only for equivalent of oneway=1. Mkgmap have to reverse line direction in case of oneway=-1. So you need only one pattern in TYP file, with arrows pointing form left to right. Actually it means arrows pointing from start of a line towards its end. I'm trying to guess what is your real question. Do you get arrows pointing in wrong direction? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] FW: computing power mdx/mdr
From: gpetermann_muenc...@hotmail.com To: ar...@speichenkarte.de Subject: RE: [mkgmap-dev] computing power mdx/mdr Date: Sun, 22 Feb 2015 09:37:54 +0100 Hi Arndt, maybe this excerpt from the options file helps: If both the --gmapsupp and --tdbfile options are given alongside the --index option, then both indexes will be created. Note that this will require roughly twice as much memory. I also assume that the new option --x-split-name-index requires more memory. Gerd Date: Sun, 22 Feb 2015 01:12:25 +0100 From: ar...@speichenkarte.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] computing power mdx/mdr Hello @all my PC is not he best machine. 4GB RAM & Intel CoreDuo 3GHz 64bit Win7. Making maps from Europa is no problem, but at the end of the process, mkgmap failed to build mdx/mdr. For the website www.speichenkarte.de i need germany and a few kilometers more. Size of the files after "splitter" is 2,8 Gb and 213 img-files. mkgmap 3426 is to be able to build this. mkgmap 3472 failed to build mdx/mdr. Also the gmapsupp dosn´t work/no shown. Need 3472 needs more computing power than 3426? Is it possible change mkgmap, to create mdr/mdx and gmapsupp wiss less cumputer power? Best regards Arndt P.S. Sorry for the bad english, hope you understand what i mean :) ___ 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
