Re: [mkgmap-dev] New branch for default typ file
Hi Gerd, natural=bay is not a water but a name for an area. It can cover islands too: https://wiki.openstreetmap.org/wiki/Tag:natural=bay IMHO transparent polygon is a good solution. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Alternative Source for osm files
Could this be something related with secure or non secure url ? The download with the opere browser is ready whilst the firefox browser still says, more than 1 hour to load Am 08.12.2019 um 19:17 schrieb Gerd Petermann: Hi Manfred, I've never seen performance problems with geofabrik, but https://extract.bbbike.org/ also provides downloads in osm.pbf format. I have no idea what tools they use, so data at polygon boundaries may not be complete. Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Sonntag, 8. Dezember 2019 18:53 An: Development list for mkgmap Betreff: [mkgmap-dev] Alternative Source for osm files Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. I have the feeling, that the download area from geofabrik is extremely throttled, may be due to the huge traffic from all over the world. And if they are really the only source for the files, than i have to live with. Any solutions ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Alternative Source for osm files
May be it is for me browser dependent. I started this afternoon the download of germany with Firefox, it gives me an average download rate of 160 kb/s. When it has reached nearly 50 percent of data, i started a second download for this region with opera, and guess what, the opera download overruns the one from firefox and will be ready earlier than the other. So i dont know, what is wrong with the firefox download ? Am 08.12.2019 um 19:17 schrieb Gerd Petermann: Hi Manfred, I've never seen performance problems with geofabrik, but https://extract.bbbike.org/ also provides downloads in osm.pbf format. I have no idea what tools they use, so data at polygon boundaries may not be complete. Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Sonntag, 8. Dezember 2019 18:53 An: Development list for mkgmap Betreff: [mkgmap-dev] Alternative Source for osm files Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. I have the feeling, that the download area from geofabrik is extremely throttled, may be due to the huge traffic from all over the world. And if they are really the only source for the files, than i have to live with. Any solutions ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Alternative Source for osm files
On 08/12/2019 17:53, DD8KQ wrote: Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. https://switch2osm.org/serving-tiles/ (which I occasionally add stuff to) also mentions https://protomaps.com/extracts/ I don't know any more about that site other than it "seems to work" - the request to add that site came in as a pull request, so I did a basic check before adding it to the list. If any others should be added please create a pull request that they be added to https://github.com/switch2osm/switch2osm.github.io/blob/master/serving-tiles/index.md . Best Regards, Andy ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Alternative Source for osm files
Hi Manfred, I've never seen performance problems with geofabrik, but https://extract.bbbike.org/ also provides downloads in osm.pbf format. I have no idea what tools they use, so data at polygon boundaries may not be complete. Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Sonntag, 8. Dezember 2019 18:53 An: Development list for mkgmap Betreff: [mkgmap-dev] Alternative Source for osm files Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. I have the feeling, that the download area from geofabrik is extremely throttled, may be due to the huge traffic from all over the world. And if they are really the only source for the files, than i have to live with. Any solutions ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ 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] Alternative Source for osm files
Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. I have the feeling, that the download area from geofabrik is extremely throttled, may be due to the huge traffic from all over the world. And if they are really the only source for the files, than i have to live with. Any solutions ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] space before name
Hi Gerd Enrico asked me for a way to ensure labels are not physically attached to a poi when viewed in Mapsource or Basecamp. Aesthetically it seems not to conform to the way labels are shown on most maps -' ICON label' rather than 'ICONlabel' r Nick On 08/12/2019 09:45, Gerd Petermann wrote: Hi Nick, the option --x-keep-blanks is not limited to POI names, it is about any value label given with mkgmap:label:1 .. mkgmap:label:4. I have no idea what problems you and Enrico are trying to solve, but a solution in the TYP file is probably much better. Gerd Von: Pinns UK Gesendet: Sonntag, 8. Dezember 2019 10:32 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] space before name Hi Gerd In take your point - you wouldn't put spaces in front of place names ; it seems more pleasing to the eye to have names of ,say, pubs detached from the poi . I haven't investigated how it affects searches and personally am not too concerned when it comes to amenities. In a typ file you can put white spaces to the right of a poi with a single pixel on the far right in another colour - not ideal On 08/12/2019 08:49, Gerd Petermann wrote: Hi Nick, my understanding is that there should be absolutely no difference between 1 or 5 or 32 leading spaces with the unpatched version. I did not try how leading spaces are treated when doing address search or POI search with names. In my eyes it is a bad idea to add blanks, I'd prefer to also remove leading and trailing blanks. I just don't know why WanMil removed the corresponding code and I am too lazy to find out ;) Gerd Von: Pinns UK Gesendet: Sonntag, 8. Dezember 2019 09:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] space before name Hi Gerd I'm sorry ; I have no idea what the code refers to but does seem a good idea to have an option where the number of spaces in front of a label are not halved/reduced.Like Enrico, I've had to add about 32 spaces before I could notice any difference - this has been resolved using the mkgmap you prepared for Enrico. hth Nick On 08/12/2019 08:06, Gerd Petermann wrote: Hi Nick, please explain. I still don't fully understand the code in method Label.squashSpaces(). It replaces sequences of so called white space characters by a single blank. A whitespace character "\s" is defined here: https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html When you say "that would be an excellent idea" I wonder if I should better remove the call of Label.squashSpaces() instead of adding a new option. Gerd Von: mkgmap-dev im Auftrag von Pinns UK Gesendet: Sonntag, 8. Dezember 2019 08:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd I think this would be an excellent idea as surrounding icons with transparent spaces in a TYP file does not do the trick - Garmin simply ignores them . Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) - have tested this in a TYP file (it accepts chr$(10) ) r Nick On 08/12/2019 07:10, Gerd Petermann wrote: Hi Enrico, I think about adding a new undocumented option --x-keep-blanks I have not yet understood why we replace duplicated blanks but not all leading and trailing blanks. This was changed in the mergeroads branch with r2827: http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827 Gerd Von: mkgmap-dev im Auftrag von demon_box Gesendet: Sonntag, 8. Dezember 2019 07:23 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd, the new releases of the mkgmap will have this feature embedded? Thanks. --enrico -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ 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 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] New branch for default typ file
Hi typ file experts, please, can anybody post a patch to fix the mapnik.txt regarding 0x3d? I really don't understand the details. Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Freitag, 6. Dezember 2019 16:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd i can remember that some time ago i stumbled also about this fact and i asked the community. I don't remember who gave me the hint but after i've changed the colour into some kind of blue for polygon type 0x3d, it changed to be OK from that time on Am 06.12.2019 um 09:17 schrieb Gerd Petermann: > Hi Ticker, > > I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It > renders as a gray area and may hide the sea below. > I am not sure what the correction is. If possible I would use "transparent" > without any colour, else the same as 0x32. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Ticker Berkin > Gesendet: Donnerstag, 5. Dezember 2019 11:20 > An: mkgmap development > Betreff: Re: [mkgmap-dev] New branch for default typ file > > Hi Gerd > > I think it would be good if the files from > branches/default-typ/resources/typ-files were put into trunk and, in > build.xml, after: > > > this is added: > > > Ticker > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ 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] space before name
Hi Nick, the option --x-keep-blanks is not limited to POI names, it is about any value label given with mkgmap:label:1 .. mkgmap:label:4. I have no idea what problems you and Enrico are trying to solve, but a solution in the TYP file is probably much better. Gerd Von: Pinns UK Gesendet: Sonntag, 8. Dezember 2019 10:32 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] space before name Hi Gerd In take your point - you wouldn't put spaces in front of place names ; it seems more pleasing to the eye to have names of ,say, pubs detached from the poi . I haven't investigated how it affects searches and personally am not too concerned when it comes to amenities. In a typ file you can put white spaces to the right of a poi with a single pixel on the far right in another colour - not ideal On 08/12/2019 08:49, Gerd Petermann wrote: > Hi Nick, > > my understanding is that there should be absolutely no difference between 1 > or 5 or 32 leading spaces with the unpatched version. > I did not try how leading spaces are treated when doing address search or POI > search with names. In my eyes it is a bad idea to add blanks, > I'd prefer to also remove leading and trailing blanks. I just don't know why > WanMil removed the corresponding code and I am too lazy to find out ;) > > Gerd > > > Von: Pinns UK > Gesendet: Sonntag, 8. Dezember 2019 09:17 > An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: AW: [mkgmap-dev] space before name > > Hi Gerd > > I'm sorry ; I have no idea what the code refers to but does seem a good > idea to have an option where the number of > > spaces in front of a label are not halved/reduced.Like Enrico, I've had > to add about 32 spaces before I could notice any difference - this has > been resolved using the mkgmap you prepared for Enrico. > > hth > > Nick > > > On 08/12/2019 08:06, Gerd Petermann wrote: >> Hi Nick, >> >> please explain. I still don't fully understand the code in method >> Label.squashSpaces(). It replaces sequences of so called white space >> characters by a single blank. >> A whitespace character "\s" is defined here: >> https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html >> >> When you say "that would be an excellent idea" I wonder if I should better >> remove the call of Label.squashSpaces() instead of adding a new option. >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag von >> Pinns UK >> Gesendet: Sonntag, 8. Dezember 2019 08:55 >> An: mkgmap-dev@lists.mkgmap.org.uk >> Betreff: Re: [mkgmap-dev] space before name >> >> Hi Gerd >> >> I think this would be an excellent idea as surrounding icons with >> transparent spaces in a TYP file does not do the trick - Garmin simply >> ignores them . >> >> Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) - >> have tested this in a TYP file (it accepts chr$(10) ) >> >> r >> >> Nick >> >> On 08/12/2019 07:10, Gerd Petermann wrote: >>> Hi Enrico, >>> >>> I think about adding a new undocumented option --x-keep-blanks >>> I have not yet understood why we replace duplicated blanks but not all >>> leading and trailing blanks. >>> This was changed in the mergeroads branch with r2827: >>> http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827 >>> >>> Gerd >>> >>> >>> Von: mkgmap-dev im Auftrag von >>> demon_box >>> Gesendet: Sonntag, 8. Dezember 2019 07:23 >>> An: mkgmap-dev@lists.mkgmap.org.uk >>> Betreff: Re: [mkgmap-dev] space before name >>> >>> Hi Gerd, the new releases of the mkgmap will have this feature embedded? >>> Thanks. >>> >>> --enrico >>> >>> >>> >>> >>> -- >>> Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html >>> ___ >>> 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 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] space before name
Hi Gerd In take your point - you wouldn't put spaces in front of place names ; it seems more pleasing to the eye to have names of ,say, pubs detached from the poi . I haven't investigated how it affects searches and personally am not too concerned when it comes to amenities. In a typ file you can put white spaces to the right of a poi with a single pixel on the far right in another colour - not ideal On 08/12/2019 08:49, Gerd Petermann wrote: Hi Nick, my understanding is that there should be absolutely no difference between 1 or 5 or 32 leading spaces with the unpatched version. I did not try how leading spaces are treated when doing address search or POI search with names. In my eyes it is a bad idea to add blanks, I'd prefer to also remove leading and trailing blanks. I just don't know why WanMil removed the corresponding code and I am too lazy to find out ;) Gerd Von: Pinns UK Gesendet: Sonntag, 8. Dezember 2019 09:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] space before name Hi Gerd I'm sorry ; I have no idea what the code refers to but does seem a good idea to have an option where the number of spaces in front of a label are not halved/reduced.Like Enrico, I've had to add about 32 spaces before I could notice any difference - this has been resolved using the mkgmap you prepared for Enrico. hth Nick On 08/12/2019 08:06, Gerd Petermann wrote: Hi Nick, please explain. I still don't fully understand the code in method Label.squashSpaces(). It replaces sequences of so called white space characters by a single blank. A whitespace character "\s" is defined here: https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html When you say "that would be an excellent idea" I wonder if I should better remove the call of Label.squashSpaces() instead of adding a new option. Gerd Von: mkgmap-dev im Auftrag von Pinns UK Gesendet: Sonntag, 8. Dezember 2019 08:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd I think this would be an excellent idea as surrounding icons with transparent spaces in a TYP file does not do the trick - Garmin simply ignores them . Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) - have tested this in a TYP file (it accepts chr$(10) ) r Nick On 08/12/2019 07:10, Gerd Petermann wrote: Hi Enrico, I think about adding a new undocumented option --x-keep-blanks I have not yet understood why we replace duplicated blanks but not all leading and trailing blanks. This was changed in the mergeroads branch with r2827: http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827 Gerd Von: mkgmap-dev im Auftrag von demon_box Gesendet: Sonntag, 8. Dezember 2019 07:23 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd, the new releases of the mkgmap will have this feature embedded? Thanks. --enrico -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ 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 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] Problem with drive-on
Hi all,
the boundary preprocessor that is used to compile the bounds.zip already
contains a check that produces a warning like
"Country name Ohoi RumahDian not in locator config. Country may not be assigned
correctly."
I can change the code to print an error instead which would appear in stderr.
For now, I've only changed the behaviour of the --drive-on detection in r4385.
Maybe it would be better to change the java code which sets mkgmap:admin_level2
so that the value is not filled when it is not a known ISO code
and also the CountryISO filter to return null if the 3 character ISO string is
not known?
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 6. Dezember 2019 16:19
An: Carlos Dávila; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with drive-on
Hi Carlos,
I'll have a look at it. I also think about a change regarding the detect
method. If I got it right it assumes right hand traffic for countires which do
not appear in LocatorConfig.xml. It might better ignore those entries when the
majority of roads is in a known country.
Gerd
Von: mkgmap-dev im Auftrag von Carlos
Dávila
Gesendet: Freitag, 6. Dezember 2019 16:14
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with drive-on
I agree it seems admin_level value is wrong. I've added a comment on
changeset aobut it. A warning as you suggest may be useful to detect
such cases.
El 6/12/19 a las 8:19, Gerd Petermann escribió:
> Hi Carlos,
>
> see https://www.openstreetmap.org/way/303677783 and
> https://www.openstreetmap.org/way/303677781
> I guess the admin_level of those two ways is wrong. There are more ways in
> this area with admin_level=2.
>
> To find them I've added
> highway=* {echotags "c"}
> as last line in the lines file to check what values the roads have in
> mkgmap:admin_level2 and mkgmap:country
>
> Maybe I should add code in the boundary generator to warn when it stores a
> name for mkgmap:admin_level2 which doesn't
> show up in LocatorConfig.xml?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von Gerd
> Petermann
> Gesendet: Donnerstag, 5. Dezember 2019 20:08
> An: Carlos Dávila; mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Problem with drive-on
>
> Hi Carlos,
>
> seems my file was even older. I can reproduce the problem with the bounds
> file created 2019-11-29.
> I'll have a closer look tomorrow.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Carlos Dávila
> Gesendet: Donnerstag, 5. Dezember 2019 19:58
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Problem with drive-on
>
> I have just realized my bounds.zip file is more than one year old (it
> should be automatically updated every week=-O). I'll try with a new one.
>
> El 5/12/19 a las 15:13, Gerd Petermann escribió:
>> Hi Carlos,
>>
>> I just tried to reproduce the problem. I've downloaded the area in your bbox
>> (a bit larger) to file in.osm.pbf
>> and used splitter to cut out your area with
>> java -jar splitter.jar --split-file=areas.list in.osm.pbf
>> Then I used
>> java -jar mkgmap.jar --drive-on=detect --bounds=bounds.zip --route
>> 63240001.osm.pbf
>> I don't see the message.
>>
>> Gerd
>>
>>
>> Von: mkgmap-dev im Auftrag von Gerd
>> Petermann
>> Gesendet: Mittwoch, 4. Dezember 2019 21:16
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Problem with drive-on
>>
>> Hi Carlos,
>>
>> My understanding is that your style (or the bounds file) sets at least two
>> different mkgmap:country values for the tile.
>> Maybe you can post a link to that tile?
>>
>> Gerd
>>
>>
>> Von: mkgmap-dev im Auftrag von
>> Carlos Dávila
>> Gesendet: Mittwoch, 4. Dezember 2019 12:15
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] Problem with drive-on
>>
>> I am preparing an areas.list file to split Oceania, so that each tile
>> contains only roads driven on the same side. I have found a tile where
>> all roads should be driven on left side, as it all lies within
>> Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695)
>> and drive-on-right roads (57)". I have reduced tile size to narrow down
>> the problem. These are its coordinates: -288768,6178816 to
>> -210944,6219776. It includes two islands, right one is detected by
>> mkgmap as right side driven, but it is left driven (to my knowledge).
>> Any idea why this happens?
>>
>>
>>
___
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
___
mkgma
Re: [mkgmap-dev] space before name
Hi Nick, my understanding is that there should be absolutely no difference between 1 or 5 or 32 leading spaces with the unpatched version. I did not try how leading spaces are treated when doing address search or POI search with names. In my eyes it is a bad idea to add blanks, I'd prefer to also remove leading and trailing blanks. I just don't know why WanMil removed the corresponding code and I am too lazy to find out ;) Gerd Von: Pinns UK Gesendet: Sonntag, 8. Dezember 2019 09:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] space before name Hi Gerd I'm sorry ; I have no idea what the code refers to but does seem a good idea to have an option where the number of spaces in front of a label are not halved/reduced.Like Enrico, I've had to add about 32 spaces before I could notice any difference - this has been resolved using the mkgmap you prepared for Enrico. hth Nick On 08/12/2019 08:06, Gerd Petermann wrote: > Hi Nick, > > please explain. I still don't fully understand the code in method > Label.squashSpaces(). It replaces sequences of so called white space > characters by a single blank. > A whitespace character "\s" is defined here: > https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html > > When you say "that would be an excellent idea" I wonder if I should better > remove the call of Label.squashSpaces() instead of adding a new option. > > Gerd > > > Von: mkgmap-dev im Auftrag von Pinns > UK > Gesendet: Sonntag, 8. Dezember 2019 08:55 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] space before name > > Hi Gerd > > I think this would be an excellent idea as surrounding icons with > transparent spaces in a TYP file does not do the trick - Garmin simply > ignores them . > > Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) - > have tested this in a TYP file (it accepts chr$(10) ) > > r > > Nick > > On 08/12/2019 07:10, Gerd Petermann wrote: >> Hi Enrico, >> >> I think about adding a new undocumented option --x-keep-blanks >> I have not yet understood why we replace duplicated blanks but not all >> leading and trailing blanks. >> This was changed in the mergeroads branch with r2827: >> http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827 >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag von >> demon_box >> Gesendet: Sonntag, 8. Dezember 2019 07:23 >> An: mkgmap-dev@lists.mkgmap.org.uk >> Betreff: Re: [mkgmap-dev] space before name >> >> Hi Gerd, the new releases of the mkgmap will have this feature embedded? >> Thanks. >> >> --enrico >> >> >> >> >> -- >> Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html >> ___ >> 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 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] Commit r4386: Implement undocumented option --x-keep-blanks
Version mkgmap-r4386 was committed by gerd on Sun, 08 Dec 2019 Implement undocumented option --x-keep-blanks If given, labels are used as provided by the style rules. Default is that repeated whitespace characters are replaced by a single blank. See also https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4386 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4385: Fix problem with --drive-on:
Version mkgmap-r4385 was committed by gerd on Sun, 08 Dec 2019 Fix problem with --drive-on: If tag mkgmap:country is set to a value that doesn't appear in LocatorConfig.xml count the road as "unknown" driving side instead of assuming that it is a "right-hand" driving side. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4385 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] space before name
Hi Gerd I'm sorry ; I have no idea what the code refers to but does seem a good idea to have an option where the number of spaces in front of a label are not halved/reduced.Like Enrico, I've had to add about 32 spaces before I could notice any difference - this has been resolved using the mkgmap you prepared for Enrico. hth Nick On 08/12/2019 08:06, Gerd Petermann wrote: Hi Nick, please explain. I still don't fully understand the code in method Label.squashSpaces(). It replaces sequences of so called white space characters by a single blank. A whitespace character "\s" is defined here: https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html When you say "that would be an excellent idea" I wonder if I should better remove the call of Label.squashSpaces() instead of adding a new option. Gerd Von: mkgmap-dev im Auftrag von Pinns UK Gesendet: Sonntag, 8. Dezember 2019 08:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd I think this would be an excellent idea as surrounding icons with transparent spaces in a TYP file does not do the trick - Garmin simply ignores them . Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) - have tested this in a TYP file (it accepts chr$(10) ) r Nick On 08/12/2019 07:10, Gerd Petermann wrote: Hi Enrico, I think about adding a new undocumented option --x-keep-blanks I have not yet understood why we replace duplicated blanks but not all leading and trailing blanks. This was changed in the mergeroads branch with r2827: http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827 Gerd Von: mkgmap-dev im Auftrag von demon_box Gesendet: Sonntag, 8. Dezember 2019 07:23 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd, the new releases of the mkgmap will have this feature embedded? Thanks. --enrico -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ 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 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] space before name
Hi Nick, please explain. I still don't fully understand the code in method Label.squashSpaces(). It replaces sequences of so called white space characters by a single blank. A whitespace character "\s" is defined here: https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html When you say "that would be an excellent idea" I wonder if I should better remove the call of Label.squashSpaces() instead of adding a new option. Gerd Von: mkgmap-dev im Auftrag von Pinns UK Gesendet: Sonntag, 8. Dezember 2019 08:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd I think this would be an excellent idea as surrounding icons with transparent spaces in a TYP file does not do the trick - Garmin simply ignores them . Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) - have tested this in a TYP file (it accepts chr$(10) ) r Nick On 08/12/2019 07:10, Gerd Petermann wrote: > Hi Enrico, > > I think about adding a new undocumented option --x-keep-blanks > I have not yet understood why we replace duplicated blanks but not all > leading and trailing blanks. > This was changed in the mergeroads branch with r2827: > http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817&compare[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827 > > Gerd > > > Von: mkgmap-dev im Auftrag von > demon_box > Gesendet: Sonntag, 8. Dezember 2019 07:23 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] space before name > > Hi Gerd, the new releases of the mkgmap will have this feature embedded? > Thanks. > > --enrico > > > > > -- > Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > ___ > 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 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
