Re: [mkgmap-dev] Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?

Hi WanMil, I think it's hard to draw route-icons with line2poi, because the segments have very different length. There are segments with only a few meters and also segments with lots of km. For a satisfying rendering you will need something like route-to-poi, which builds first the complete route

Re: [mkgmap-dev] Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.10.2013 19:12, schrieb WanMil: I will have to think about how to realize constant configurable distances between icons. Maybe someone else has a good idea? Hi WanMil, did you thought about my approach? Here again a little bit more detailed:

Re: [mkgmap-dev] [PATCH v1] finalizer style file

Hi WanMil, just to make sure, I've got it right. way with: a=b c=d e=f actual in lines: a=b c=d {set x=y } x=y ef [0x01 ...] with finalizer: -in lines: x=y e=f [0x01 ..] - in finalizer: a=b c=d type()=way {set x=y} If this is true, also the hole addr-part could be moved to

Re: [mkgmap-dev] Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.10.2013 13:50, schrieb Anna Leuchter: Hi Henning, 1. Option could be: --add-poi-to-routes=100,1000,1 Does this mean that every 100 meters + every 100meters + every 1 meters of the route a mark would be set? So at 1000m there

Re: [mkgmap-dev] Numerical comparison of two tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Bernd, did you tried something like: maxspeed:forward '${maxspeed}' ? Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSdAbRAAoJEPFgsWC7jOeTwkAH/38JgeX1wG//YX3LA3k0edzT

Re: [mkgmap-dev] Numerical comparison of two tags

Am 03.11.2013 13:23, schrieb Steve Ratcliffe: We could use a different notation such as get_tag(maxspeed) since it would be clearer that it could not be quoted. Hi Steve, I would prefer something like get_value(..) or value_of(..) or simply value(..) tag is in OSM a word for key=value, so

Re: [mkgmap-dev] Numerical comparison of two tags

Am 03.11.2013 12:56, schrieb Steve Ratcliffe: The second means that you can write just minspeed $maxspeed and it will be converted automatically to: minspeed=* minspeed $maxspeed Wouldn't it be more logical to convert it to: minspeed=* maxspeed=* minspeed $maxspeed Henning

Re: [mkgmap-dev] Multiple relations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.11.2013 11:48, schrieb demon.box: How can you see the image attached MapSource display tha name of the highway (not the name of the route relation) if there is one or the label Sconosciuto if there isn't. I would delete (I don't want to see

Re: [mkgmap-dev] Drive-on-left

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, but it should be unique in each country. So it should be possible to use a mkgmap:drive_on=left or something similar. Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32)

Re: [mkgmap-dev] o5m plugin for JOSM

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, maybe you should create a ticket for that in the bug-tracker: http://josm.openstreetmap.de/newticket btw: I'm waiting for a very long time for such a plugin :-) Thanks a lot! Henning Am 22.11.2013 09:31, schrieb Gerd Petermann: Hi all,

[mkgmap-dev] IO-problem with actual trunk

Hi, while generating a map of Oman I got the attached error-message (see below 1010). The map is generated out of planet.o5m. Henning 1000 1001 SEVERE (Main): 1001*.o5m: file 1001*.o5m doesn't exist Exiting - if you want to carry on regardless, use the --keep-going option 1002 1003 1004 1005

Re: [mkgmap-dev] IO-problem with actual trunk

Here it is: http://www.aighes.de/data/1010.tar.gz Henning Am 22.11.2013 19:28, schrieb GerdP: Hi Henning, please post a link to the o5m input file. Gerd Henning Scholland wrote Hi, while generating a map of Oman I got the attached error-message (see below 1010). The map

Re: [mkgmap-dev] IO-problem with actual trunk

Am 23.11.2013 09:36, schrieb Gerd Petermann: Hi Henning, okay, maybe it was an error in the update process. I see that e.g. OSM stats also had problems: http://osmstats.altogetherlost.com/index.php?item=nodes Anyway, it is obvious the code in splitter is missing a check, either in the

Re: [mkgmap-dev] Possible solution for deformed polygons

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, if this merging is done after style-processing, then it should be a great improvement without complications. Otherwise only polygons should be merged if all tags are equal. Henning Am 23.11.2013 16:25, schrieb GerdP: Hi Andrzej, for

Re: [mkgmap-dev] IO-problem with actual trunk

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, works as expected. Henning Am 23.11.2013 15:11, schrieb Gerd Petermann: Hi Henning, I was not able to reproduce the problem, but I found a potential error in the o5m write routine: it did not write enough reset bytes. I've changed

Re: [mkgmap-dev] TYP-file can't be written

containing ö,ü,ä and ß. Henning Am 24.11.2013 15:01, schrieb Steve Ratcliffe: On 23/11/13 22:12, Henning Scholland wrote: In the header of my txt-TYP-source I have written CP1252. Converting this to CP1250 and CP1254 is done without problems. So I don't understand, why it's a problem

Re: [mkgmap-dev] IO-problem with actual trunk

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd Here it is: http://www.aighes.de/data/mkgmap.zip Henning Am 24.11.2013 09:02, schrieb Gerd Petermann: Hi Henning, I still don't understand why this change is important for mkgmap, maybe I did not fix the real problem. It would be great

Re: [mkgmap-dev] TYP-file can't be written

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Steve, I don't want to bother you. Is there any news about this? Henning Am 25.11.2013 00:17, schrieb Steve Ratcliffe: Hi Henning in the end of August it worked without any problems. I've just read here that something was changed with

Re: [mkgmap-dev] Address search confused by place=* with name,ref

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marko, for me it sounds like a bug in OSM, which should be fixed. Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSuUlfAAoJEPFgsWC7jOeTijoIAMrkT79PM51nJyrieyykpFNg

Re: [mkgmap-dev] [patch v1] link-pois-to-ways and restrictions

Am 24.12.2013 09:40, schrieb chris66: Am 23.12.2013 15:15, schrieb Gerd Petermann: What do you mean with route restrictions ? sorry, a route restriction is the internal name for it. These route restriction are created for restriction relations like

Re: [mkgmap-dev] Address search confused by place=* with name,ref

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marko, if you find something like Xi:xii Kyttälä, FIN in a name-tag, then this shoulod be wrong for a town. The name of the town would be Kyttälä, or am I wrong? Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32)

Re: [mkgmap-dev] Address search confused by place=* with name,ref

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marko, ok so I misunderstood you. You wrote something of filtering osm.pbf with osmosis and afterwards there were elemets with name Xi:xii Kyttälä, FIN. But as you explained now, mkgmap creates this name. So I agree with you: Your given name

Re: [mkgmap-dev] coastline boundaries

Hi Gerd, I don't know what you discussed with WanMil, but I think it would be better to use mkgmap:coastline=yes in combination with precompiled sea polygons and keep the original way completly untouched (as you did already). In this case no special handling for natural=coastline is

Re: [mkgmap-dev] coastline boundaries

Hi Gerd, processing the precompiled data through style isn't necessary. But I would leave it to the style-dev to take care about rendering natural=coastline also in polygon-file or not. After thinking some minutes more, my approach isn't that better then yours, if you remove the ignore

Re: [mkgmap-dev] Distorted lines

Am 19.02.2014 10:26, schrieb Gerd Petermann: Are you also satisfied with the results? Absolutly! Looks smoother and maps are smaller, win-win-situation. Thanks a lot, Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

[mkgmap-dev] Splitter and multiple input-files

Hi Gerd, I discovered a (small) problem with using two inputfiles with splitter. One input-file is planet.osm, the other one is a srtm-files covering only a few areas. If I split an area, which is not covered by the bbox of my srtm-file, splitter wont write any areas.list and so on. Would it

Re: [mkgmap-dev] Splitter and multiple input-files

Hi Gerd, yes you got it right, as you mean touch as touched by bbox of srtm-file. The srtm-file contains Iceland (NW) and New Zealand (SE). Every poly-file works, which touch this area. Now I tried to split a part of Canada and it failed. To sumerize the log: It split planet as normal and

Re: [mkgmap-dev] high-prec-branch ready for trunk?

Me too. Henning Am 04.03.2014 09:07, schrieb Thorsten Kukuk: On Tue, Mar 04, Gerd Petermann wrote: If I hear no complains I'll merge on March 6. Fine with me, I'm using that branch already for my maps and haven't heard anything negative back yet. Thorsten

Re: [mkgmap-dev] Splitter and multiple input-files

Hi Gerd, attached you'll find my splitter-log, the skript and the poly-file. Maybe this helps. Henning Am 04.03.2014 08:16, schrieb Gerd Petermann: Hi Henning, I can't reproduce it with r317. I've tried it like this: Use (an older) planet.o5m and an srtm file covering Bremen and Bremerhafen

Re: [mkgmap-dev] splitter and srtm2osm

Hi Michal, I would recommend to use phyhgtmap instead of srtm2osm. You'll get splitted ways (number of nodes can be specified) and it writes pbf-files, which is more effective. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Infinite loop splitter

Hi Minko, is there a reason for merging the files before splitting? Did you try to just pass all the files to splitter? I'm doing so with osm and srtm-data. Don't know, if this helps in this case, but in general I think it should be much faster. Henning

Re: [mkgmap-dev] options make-all-cycleways and make-cycleways

As I remember correct, the result was: You should use continue or continue_with_actions instead of these cycleway-options. ;) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] conditional includes in style

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, I quote a mail, which I wrote some month ago to the list: while cycling in New Zealand I found out, thats a little bit to easy just taking a style (routing and map-look) and use it in parts of the world, which are very different to

Re: [mkgmap-dev] conditional includes in style

Hi Gerd, maybe it gets a little bit clearer if I gave an example. if ( mkgmap:country=DEU ) { include 'deu_highway_rules'; } or if (mkgmap:country=DEU) { highway=primary { set mkgmap:access=no } highway=... {...} ... } Henning ___

Re: [mkgmap-dev] conditional includes in style

Hi Felix Am 27.03.2014 19:59, schrieb Felix Hartmann: That is also quite nice, my main problem with this approach is - can we by now assume that the mkgmap:country tag is 99.9% available correctly when using precompiled bounds? I haven't heard about any complaints about this. if not

[mkgmap-dev] NPE with r3183 r3185

Hi everybody, since updating to r3183 I get the following NPE. Also Updating to r3185 doesn't solve the issue to me. The NPE doesn't occur in all my maps, but in several ones, mainly in maps with higher density of mapping. Henning java.lang.NullPointerException at

Re: [mkgmap-dev] NPE with r3183 r3185

Hi Gerd, so how I have to change my style to get the same effect as I got before? Henning Am 13.04.2014 17:39, schrieb Gerd Petermann: Hi Henning, yes, these two lines are problematic: type=restriction except ~ '.*bicycle*.' { delete type ; delete restriction } type=restriction:bicycle {

Re: [mkgmap-dev] mkgmap ToDo list

Am 16.04.2014 22:01, schrieb GerdP: Why do you think that it is a bug? Think about oneway=-1 and in style you add oneway-arrows (link mapnik does). In style you will handle -1 special, because arrows should drawn in oposite direction of way. If mkgmap now changes direction of the way, arrows

Re: [mkgmap-dev] barriers on major roads

Hi Gerd, in most cases you will be correct with your assumption. But I cannot say for sure, that there isn't a case outside in reality, for which the tagging on crossing node is correct. So I'm not sure if ignoring would be helpful in every case. Maybe it would be a better thing to generate

Re: [mkgmap-dev] what makes a way a road?

Am 23.04.2014 08:03, schrieb Gerd Petermann: Is this intended? I don't think so. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap ToDo list

Hi @ all, while thinking about creation of simple maps with less features I thought about an better parameter for splitter then just the number of OSM-nodes. Actually splitter writes density-files (but also based on OSM-nodes). You can imagine that the number of OSM-nodes may differ a lot in

Re: [mkgmap-dev] mkgmap ToDo list

Hi Gerd, splitter is able to write a density file, which stores the density of OSM-nodes in the specific area. Afterwards the file is splitted and processed by mkgmap. mkgmap will use only the objects, which are addressed in style-file. Example: In a rectangle of 100x100m are 5 nodes

Re: [mkgmap-dev] mkgmap ToDo list

Hi Gerd, finding a proper max-nodes value wont solve the problem globaly. Eg. then you compare the needed value from europe/north america to the value needed in the rest of the world. Henning Am 25.04.2014 19:35, schrieb Gerd Petermann: Hi Henning, well, I don't know how well the number

Re: [mkgmap-dev] mkgmap ToDo list

Hi Gerd, I would like to have img-tiles which have globally nearly the same filesize, so that they use the space of devices like eTrex 10. With my actual map I use globally the same value for max-nodes. But the size of the img-tiles differ more then factor 2. Eg. a tile in Germany is

Re: [mkgmap-dev] mkgmap ToDo list

Hi Lambertus, are these numbers the result of your script or the basic results of splitter? Henning Am 29.04.2014 20:48, schrieb o...@na1400.info: I don't have the number for Germany, but perhaps the world suffices? The image size distribution of my generic map is: 2MB some 2-3MB 260

Re: [mkgmap-dev] r3239 in performance2 branch

Hi Gerd, below you'll find the compared times, mkgmap needs to compile the map. From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that you are on a good approach. Henning trunk branch Germany 2110335 1830965 -13,24% Turkey 150734 137633 -8,69%

Re: [mkgmap-dev] r3239 in performance2 branch

30.04.2014 19:10, schrieb GerdP: Hi Henning, r3245 should be good now, faster and no known errors. I've also applied the oneway patch. Gerd Henning Scholland wrote Hi Gerd, below you'll find the compared times, mkgmap needs to compile the map. From o5m-tile til img-tiles

Re: [mkgmap-dev] r3251 in performance2 branch

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 02.05.2014 23:21, schrieb Gerd Petermann: Hi all, please test / review the changes in the branch, because I don't plan any further optimizations for now. You should see no different output compared with r3248 in trunk, but around 15% faster

[mkgmap-dev] splitter removes multipolygon-tags

Hi @ all, some users of my map reported to me, that there are several polygons missing. After taking a look into the splitted o5m-files I can confirm, that they can't be rendered because the objects doesn't contain the necessary tags. First I thought, it could be cause because of multiple

Re: [mkgmap-dev] splitter removes multipolygon-tags

Hi Gerd, sorry for delay. I've continued investigation. If I only split the single tile (6211), everything seems to be fine. single tile: http://www.aighes.de/data/mkgmap/6211.o5m http://www.aighes.de/data/mkgmap/splitter_6211.log all ~1500 maptiles at once:

Re: [mkgmap-dev] splitter removes multipolygon-tags

Am 07.05.2014 11:24, schrieb GerdP: I noticed that relation 70724 is missing your file, so we are not talking about removed tags here. Hi Gerd, I'm sorry for this. My first thought was, that splitter transforms MPs to areas. But of course this was stupid. Correct is, that there are missing

Re: [mkgmap-dev] splitter removes multipolygon-tags

Am 08.05.2014 08:38, schrieb Gerd Petermann: Hi Henning, I tried with the areas.list from your homepage. It is not exactly like the one you used to produce the log, but I was able to reproduce the problem. It is caused by overlapping tiles in this area. I am now looking for a correction. Hi

Re: [mkgmap-dev] splitter removes multipolygon-tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, after taking a deeper look into my tile 1211 (also with r327), there are stil mp's missing. Eg. three buildings of Bayreuth University. All three buildings are mapped as mp and also are member in a site relation of the university. After

Re: [mkgmap-dev] splitter removes multipolygon-tags

Thank you Gerd, I will give it a try. Does it work now for as many overlapping tiles as possible? Otherwise it would be helpful to write a warning, that too many tiles are overlapping, which can lead to missing objects. Henning ___ mkgmap-dev

Re: [mkgmap-dev] splitter removes multipolygon-tags

Hi Gerd, ok, so my next step will be to optimize my tiles. Henning Am 10.05.2014 17:27, schrieb GerdP: Hi Henning, I did not try what happens when 5 tiles overlap the same point, but it should work. As I said, you should try to avoid that, as each tile will require the complete reading of the

Re: [mkgmap-dev] splitter removes multipolygon-tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, this is, what I'm thinking about to do, but on the other hand I'm loosing the actual flexibility. I think I will give it a try and will see, how it works. Henning Am 11.05.2014 08:24, schrieb Gerd Petermann: Hi Henning, If you don't

Re: [mkgmap-dev] splitter removes multipolygon-tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, the flexibility is, that I actually can just add new areas to my areas.list and don't have to care about anything. If mkgmap throws out a warning about too many nodes in a tile, I let splitter create a new areas.list for the region and I can

Re: [mkgmap-dev] splitter removes multipolygon-tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, it would be enough, if one tile is only written ones to Disk and only linked via template.args. I think this is the better way for SSD-lifetime and speed. Debugging should also be possible. Henning -BEGIN PGP SIGNATURE- Version:

Re: [mkgmap-dev] splitter removes multipolygon-tags

Hi Gerd, wow, that was quite fast! I called splitter like that: java -Xmx8G -XX:+UseCompressedOops -XX:+UseParallelGC -jar ./bin/splitter.jar --max-threads=6 --stop-after=split --polygon-desc-file=./resources/areas.osm --status-freq=0 --max-nodes=120 ./data/planet.o5m ./data/srtm.o5m As a

Re: [mkgmap-dev] splitter removes multipolygon-tags

Hi Gerd, r333 outputs the files needed. But the resulting poly-files are not quiet useful. Eg. a part of Germany and BeNeLux reaches til the northern part of Scandinavia. Most asian maps are much larger then original files. Henning ___ mkgmap-dev

Re: [mkgmap-dev] splitter removes multipolygon-tags

Hi Gerd, unfortunately no tool, so I will do it manually. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter removes multipolygon-tags

Hi, I've written a little formula in Excel if someone is interested in: =VERKETTEN(RUNDEN(RUNDEN(LINKS(WECHSELN(A1;.;,);FINDEN( ;WECHSELN(A1;.;,)))*(2^24/360/2048);0)*2048*360/(2^24);6); ;RUNDEN(RUNDEN(RECHTS(WECHSELN(A1;.;,);FINDEN(

Re: [mkgmap-dev] splitter removes multipolygon-tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd Am 13.05.2014 22:44, schrieb GerdP: This is an error in splitter, I have to fix that. Maybe you can also change the name of the generated kml-files. name-.areas.kml isn't quite good. At lest the first dot should be removed. But I think

Re: [mkgmap-dev] error handling in splitter

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, I would agree, that if input-data cannot be read or tiles cannot be written, splitter should stop and write an error-message. A special log shouldn't be required if this log will only contain stdout and/or stderr. This can be written to a

[mkgmap-dev] path in template.args-file

Hi, I just realized that the paths in the template.args file is interpreted by mkgmap as relative to template.args file. Is this behaviour intended or shouldn't it be relative to the path, from which mkgmap is called from, as every other path in mkgmap? The template.args-file is pretty old,

Re: [mkgmap-dev] splitter and overlapping tiles in split-file

Hi Gerd, I plan to document in a few sentence, what you should do, if you are having overlapping polys. This could be integrated in mkgmap-guide. But I don't know til then I can finish it, because next weekend I'm starting a short biketrip (just a week) and I wont have time before. Best

Re: [mkgmap-dev] splitter r383

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, go for it! Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTei7jAAoJEKXggIeC16WPvnEIAMR5y2LT4dU8LrfYIpAun97d

Re: [mkgmap-dev] how to replace false tracktype keys in style file?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, what about: \w*[1-5] some alphanumeric characters and then one number between 1 and 5. Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

Re: [mkgmap-dev] help needed

Hi Gerd, as I got it right, in nearly all typical cases the fast algo would be ok because the error is pretty small. So what about calculating always the fast algo and if the calculated distance is larger then X, mkgmap calculates the distance again with the more precise algo. Henning

[mkgmap-dev] Rendering of emergency access points

Hi everybody, today I received an eMail from Niedersächsische Landesforsten (a governmental organisation for forestry in Germany) about actuality of emergency access points. Don't know what they want exactly, but I think I'm not the only one who is rendering these points. So did anyone else

Re: [mkgmap-dev] How to display highway shields with numbers only

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, take a look in Table 4.3 some lines above the shields are explained. There you'll find subst and part. They will help you. Henning Am 09.12.2014 um 03:51 schrieb Mark Bradley: Hi list members, I'm relatively new to mkgmap. I have

Re: [mkgmap-dev] A few thoughts on non-rectangular tiles

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, I would suggest that a common osm-file format would be the easiest way for most of the users (who generating maps out of osm-data and are used to josm). The next question is: Should there only be a non-rectangular border of the hole map or

Re: [mkgmap-dev] mixed index branch merge

Am 16.02.2015 um 14:05 schrieb Gerd Petermann: Hi Steve, I fear I don't understand what problem you see with roads like 'The Avenue' My understanding is that we put the full name into the index, so the road can be found. On the other hand, nobody would expect to find this road by typing

Re: [mkgmap-dev] mixed index branch merge

Hi Gerd, I would prefer kind of such a solution. Maybe if this list is generated after processing mkgmap:country the country could be also used, so having a list for each country. Of course it would be nice to have the list written to a file and also give mkgmap a specific list. Format could be

Re: [mkgmap-dev] POIs without POI-search

Hi Gerd, so test-map:all-elements did the same as POI-tester? Do you know the range of the generated POIs? Or is the range based on style? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] GUI for POI Search TYPES

Hi Gerd, looks much better now. I've tried it on my Oregon 600. In some cases in the POI search the Oregon found a POI, but doesn't display a name. Is there any explanations for this behavior? Henning ___ mkgmap-dev mailing list

Re: [mkgmap-dev] GUI for POI Search TYPES

Hi Gerd, yes it's pretty much the same. Just one problem. Line 0x01-0x08 starting at same position as point 0x7f00-0x7f07. And between lines and areas the gap is a little bit to big. So I think all the lines should be shifted a column to the right. Otherwise: Very good job! Henning

Re: [mkgmap-dev] Roundabouts causes crashing devices

Hi Minko, I#m not completly sure, but I remember, there were long time ago problems with 2 routable lines on same position. So in my map I changed all routeable lines to transparent and used for showing highways etc. non-routable lines. But maybe this particular problem was solved later.

Re: [mkgmap-dev] splitter r440 released

As you know, I'm using overlapping tiles, but in different gmapsupps. Never had any problems. Is splitter still able to split overlapping tiles? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] splitter r440 released

Should have read your mail better :( I think the test should be implemented in mkgmap while reading the input data tiles. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Copyright & License file reader improvements

Hello, I think similar. No3 seems to be a very bad idea, as code-page is different for different maps. Henning On 28/12/2016 15:18, Gerd Petermann wrote: > Hi Mike, > > Mike Baggaley wrote >> 2: >> Update the documentation to indicate that utf-8 must be used for license >> and copyright file

Re: [mkgmap-dev] Splitter 542 stops working

s error. > I also added a unit test that reproduced the error. > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Henning Scholland <o...@aighes.de> > Gesendet: Donnerstag, 2

Re: [mkgmap-dev] bug?

Hi, I could imagine, -H can also be a code for # (Hash-Tag). If eight matches the regex for 8 I would expect it's changed to 8 and the result would be H8. As Garmin always capitalizes the first letter of each word, it seems eight is interpreted as normal word and -H is transformed to #. Henning

Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data

Hi Gerd, it's a great news. I wanted to try it on my map of China. But unfortunately failed because of missing files in the sea area between Korea and Japan. Maybe it's a good 1st approach to interpret a missing file as an area with 0 elevation. Anyway, thanks for all the research work on DEM!!!

Re: [mkgmap-dev] osmupdate

You need to update wget to latest version as diffs are only served by https and older wget can't use local certificate store. Met the same problem recently... Henning ⁣Sent from BlueMail ​ On 24 May 2018, 14:01, at 14:01, lig fietser wrote: >Since recently I cannot

Re: [mkgmap-dev] osmupdate

Any idea how to solve this? > > > >Van: mkgmap-dev ><mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> >namens Henning Scholland <o...@hscholland.de><mailto:o...@hscholland.de> >Verzonden

Re: [mkgmap-dev] osmupdate

Hi osmupdate is basically a script using wget for downloading and osmconvert for merging. As it's using wget in quiet mode, only chance for debugging download problems is to download the file manual by wget and see the error message. I guess in your case the first file (state.txt of daily,

Re: [mkgmap-dev] mkgmap r4025 implements --x-dem-poly option

Hi Gerd, I got an OutOfMemory exception (see below) while reading zipped 1" SRTM files in Scandinavia. Unzipped it's all fine. Btw. it would be nice to move the 'DEM file calculation for ... took 265 ms'-messages from stdout to logging Information. Henning Exception in thread "main"

Re: [mkgmap-dev] r4033: new dem options are now documented

Hi Gerd, do you think using tif (as Frank pointed out even has better compression ratio) instead of zipped hgt will help regarding the RAM-footprint? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] r4015 in dem-tdb branch implements --x-overview-dem-dist

Hi, it would be my expected behaviour if you just delete the OSM data and keep the area still in your map area. Henning ⁣Sent from BlueMail ​ On 23 Dec 2017, 10:12, at 10:12, Ervin Malicdem wrote: >Hi Gerd, > >This is regarding hillshade still being rendered even if the

Re: [mkgmap-dev] r4015 in dem-tdb branch implements --x-overview-dem-dist

Hi Gerd, after thinking a while about overview-dem and it's not really logical to me. Mainly the proposed x-overview-dem-dist=0 isn't really intuitive. I should have thought more better before proposing it. It would be better to have a separate parameter -x-dem-overview=yes/no, where yes is

Re: [mkgmap-dev] Error BeNeLul

Hi Gerd, I got a similar error in East Malaysia/Philippine in that tile: 63240328: 188416,5429248 to 538624,5650432 If you need o5m-file let me know. I used: x-dem=E:\SRTM\hgt\SRTM3v3.0 x-overview-dem-dist=276160 2nd: After you changed the file size limit I ran in some of the problematic tiles

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, basically this describes my idea, just less quick ;-) I will give it a try next weekend. Of course for every map, you need a individual temp-DEM. So I don't seen any issues with poly-cutted-tiles. Henning ___ mkgmap-dev mailing list

Re: [mkgmap-dev] dem-poly and precomp-sea

Hi Gerd, I like the idea to have somehow a map polygone limiting or extending the 'background'-map (means DEM, sea, background poly). How about --map-polygon? So if I got it right, this develloping will end in non-rectangle shaped map tiles? Henning On 10.01.2018 16:54, Gerd Petermann wrote: >

Re: [mkgmap-dev] --gmapi not in parameter list

Hi Gerd, I'm using only --overview-mapname=%famid%. For 'standard'-img map file name is also set to 1005000.img Will add also ..number. Thanks for the hint. Henning On 11.01.2018 21:06, Gerd Petermann wrote: > Hi Henning, > > I'll add text to the doc and help. > You you set

[mkgmap-dev] --gmapi not in parameter list

Hi, is there a reason for not listing --gmapi in the documentation (at least on website)? Description can be simply: Outputs map in gmap-format. Btw: In overview map DEM, LBL, RGN and TRE don't follow map-id based file name, but using 6234. In my case it should be 1005. NET and NOD and

Re: [mkgmap-dev] option --show-profiles and DEM

Hi all, I don't see a reason to have this option at all. It should be set automatically to 1 if either contour data or DEM is written. If this data is in the map, you always want to have it and if those are not in the map, you don't need it. Or am I wrong? Henning

Re: [mkgmap-dev] option --show-profiles and DEM

Also without show-profiles=1 MapSource and BaseCamp don't use DEM for elevation of waypoints. Basically it's only used for routing and showing the shades. Henning On 11.01.2018 17:52, lig fietser wrote: > > --show-profiles=1 >     Sets a flag in tdb file which enables profile calculation in

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

Hi Frank, just my opinion: I would keep this separated from mkgmap. I mean, you need once convert the data and that's it and the tools all exist. So I think it's more useful to create a documentation about how to convert the copernicus-files into hgt. Btw. Are these files so much better compared

Re: [mkgmap-dev] HGT - getElevation()

On 10.01.2018 20:33, Andrzej Popowski wrote: > > i would be very defensive with interpolation in the case of > > missing values. > > I got the same feeling. The best way to fill voids is to process whole > HGT. And I believe that DEM providers already have done it, so any > attempt at simple

<    1   2   3   4   5   >