Re: [mkgmap-dev] Precomp-sea (to DD8K)
Yes, you are right that only to get the area name printed on the map a transparent polygon is just an overkill. But, for me, it will not run to display the name using POI, i don`t know why. So i remember one of the first postings from Gerd regarding this, where he suggested also to make the polygon transparent. And this worked for me in my surrounding. May be, i will do another try to get the POI running Am 15.12.2019 um 16:07 schrieb David: Hi DD8K, Using a transparent polygon just to display a POI is a solution but there might be another one. Is it possible to play with a rule in polygons and points style files and, perhaps, in combination with pois-to-areas-placement ? 0x3d seems to be for large lake (77-250 km2) as for Garmin map Europe. 0x3b and 0x45 are defined as blue-unknown in cgpsmapper doc. Both are the limits of lake types range [0x3c 0x44]. There is also 0x29 blue-unknown between ocean and sea types. For bay, the POI type is 0x6503. David ___ 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] Precomp-sea (to DD8K)
Hi DD8K, Using a transparent polygon just to display a POI is a solution but there might be another one. Is it possible to play with a rule in polygons and points style files and, perhaps, in combination with pois-to-areas-placement ? 0x3d seems to be for large lake (77-250 km2) as for Garmin map Europe. 0x3b and 0x45 are defined as blue-unknown in cgpsmapper doc. Both are the limits of lake types range [0x3c 0x44]. There is also 0x29 blue-unknown between ocean and sea types. For bay, the POI type is 0x6503. David ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...]
is-in-landuse, nice function! with this new option i set acces=no for bicycles when the way is within a cemetary. (& no tag say, that bicycle is ok) There are still a few polys where that could be used. amenity=grave_yard, amenity=hospital, leisure=pitch maybe its better to name the option is-in-polygone:polygone=value Arndt svn commit < s...@mkgmap.org.uk> hat am 15. Dezember 2019 um 10:05 geschrieben: Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019 implement and document new option --is-in-landuse=value[,value...] - svn rename ResidentialHook.java to LanduseHook.java - remove support for undocumented option --residential-hook=false - warn if style uses mkgmap:residential which was replaced by mkgmap:lu:residential http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4397 ___ 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] Suggestions for roadNameConfig.txt
Hi Ticker, reg. your comments in http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029506.html: I think you missed the words "On the PC" in this sentence? - On the PC, when zooming out, the name 'Rue de la Concorde' is only rendered as 'Concorde'. I just verified that this still works (with the unpatched config) but the effect is barely visible with english names. In Mapsource the switch happens when zooming out to a map scale of "500m". I'll try the effects on road search later... Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Sonntag, 15. Dezember 2019 10:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Hi I have suggestions for changes to the English. Patch attached but the relevant lines are: # english # Not good to have prefixes; in UK they are considered as the first part of the street name. #prefix1:en = "East ", "North ", "South ", "West " # Having suffixes makes Find>Address less easy to use on some GPS devices! See posting 21-Feb-2019: # http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029506.html suffix:en = " Arcade", " Avenue", " Circus", " Close", " Court", " Crescent", " Croft", " Drive", " Field", " Fields", " Gardens", " Gate", " Grove", " Hill", " Lane", " Mews", " Parade", " Park", " Passage", " Place", " Rise", " Road", " Square", " Street", " Terrace", " View", " Villas", " Walk", " Way", " Wood", " Yard" Ticker On Sat, 2019-12-14 at 14:03 +, Gerd Petermann wrote: > Hi Alexandre, > > thanks, committed with r4394 > > Gerd > > > Von: mkgmap-dev im Auftrag > von Alexandre Folle de Menezes > Gesendet: Freitag, 13. Dezember 2019 23:53 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Suggestions for roadNameConfig.txt > > Hi, > > I have some suggestions to improve Portuguese handling on > roadNameConfig.txt: > > # portugese > prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco", > "Estrada", > "Rodovia" > prefix2:pt = "da ", "do ", "de ", "das ", "dos ", "d'" > > # Section 2 > > lang:AGO = pt > lang:BRA = pt > lang:GNB = pt > lang:MOZ = pt > > Best regards, > > Alexandre > > ___ > 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] Precomp-sea problem solved
Hi all inspired from the discussion about polygon type 0x3d i made some tests yesterday and modified the polygon to be transparent. The data looks like this : [_polygon] Type=0x3d ;GRMN_TYPE: Water Areas/LAKE_30MI, LARGE_LAKE/Large lake, typically between 30 and 500 sq mi in area/Non NT String1=0x01, String2=0x02,Bucht String3=0x04,Bay String4=0x03,Baai String5=0x09, ExtendedLabels=Y FontStyle=NormalFont CustomColor=No Xpm="32 32 2 1" "! c #FF" " c none" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " ;12345678901234567890123456789012 [end] The advantage of this solution is that the name of all bay areas are written in the map. If you completely omit the polygon 0x3d you will not see the names of these areas (tested on map source with the west coast of ireland) Am 14.12.2019 um 22:15 schrieb David: Hi Gerd, Thank you for you to point me about the 0x3d polygon type used for bay. I removed it from my polygon style file and the result is good. I still cannot be able to compute any route with BaseCamp (MacOs). Strangely, the combo box of transport option is greyed except when I select « direct flight ». To create the map I use the option « route » without any « check-routing-island-len ». Is this option silently on with a default value ? All the best, David ___ 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] Suggestions for roadNameConfig.txt
Hi I have suggestions for changes to the English. Patch attached but the relevant lines are: # english # Not good to have prefixes; in UK they are considered as the first part of the street name. #prefix1:en = "East ", "North ", "South ", "West " # Having suffixes makes Find>Address less easy to use on some GPS devices! See posting 21-Feb-2019: # http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029506.html suffix:en = " Arcade", " Avenue", " Circus", " Close", " Court", " Crescent", " Croft", " Drive", " Field", " Fields", " Gardens", " Gate", " Grove", " Hill", " Lane", " Mews", " Parade", " Park", " Passage", " Place", " Rise", " Road", " Square", " Street", " Terrace", " View", " Villas", " Walk", " Way", " Wood", " Yard" Ticker On Sat, 2019-12-14 at 14:03 +, Gerd Petermann wrote: > Hi Alexandre, > > thanks, committed with r4394 > > Gerd > > > Von: mkgmap-dev im Auftrag > von Alexandre Folle de Menezes > Gesendet: Freitag, 13. Dezember 2019 23:53 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Suggestions for roadNameConfig.txt > > Hi, > > I have some suggestions to improve Portuguese handling on > roadNameConfig.txt: > > # portugese > prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco", > "Estrada", > "Rodovia" > prefix2:pt = "da ", "do ", "de ", "das ", "dos ", "d'" > > # Section 2 > > lang:AGO = pt > lang:BRA = pt > lang:GNB = pt > lang:MOZ = pt > > Best regards, > > Alexandre > > ___ > 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-devIndex: resources/roadNameConfig.txt === --- resources/roadNameConfig.txt (revision 4397) +++ resources/roadNameConfig.txt (working copy) @@ -25,8 +25,11 @@ prefix2:ca = "de las ", "de los ", "de la ", "del ", "de ", "d'" # english -prefix1:en = "East ", "North ", "South ", "West " -suffix:en = " Road", " Street" +# Not good to have prefixes; in UK they are considered as the first part of the street name. +#prefix1:en = "East ", "North ", "South ", "West " +# Having suffixes makes Find>Address less easy to use on some GPS devices! See posting 21-Feb-2019: +# http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029506.html +suffix:en = " Arcade", " Avenue", " Circus", " Close", " Court", " Crescent", " Croft", " Drive", " Field", " Fields", " Gardens", " Gate", " Grove", " Hill", " Lane", " Mews", " Parade", " Park", " Passage", " Place", " Rise", " Road", " Square", " Street", " Terrace", " View", " Villas", " Walk", " Way", " Wood", " Yard" # french prefix1:fr = "Allée", "Avenue", "Boulevard", "Chemin", "Place", "Rue", "Route" ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...]
Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019 implement and document new option --is-in-landuse=value[,value...] - svn rename ResidentialHook.java to LanduseHook.java - remove support for undocumented option --residential-hook=false - warn if style uses mkgmap:residential which was replaced by mkgmap:lu:residential http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4397 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Use of is_in in style
Hi Ticker, thanks for the feedback. We always change both files, one is for the help option in mkgmap, the other for the online help. I don't have a (windows) tool to generate the first using the second. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 14. Dezember 2019 19:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Gerd This looks fine, but shouldn't the option change be to doc/options.txt rather than resources/help/options/en/options? Ticker On Sat, 2019-12-14 at 11:04 +, Gerd Petermann wrote: > Hi all, > > I plan to document new option --is-in-landuse like this: > --is-in-landuse=value[,value...] > Tells mkgmap to calculate a tag for each given landuse area. > Allows to identify eg. buildings within a landuse=residential > or ways > within a landuse=cemetery. If an element is within the given > landuse area, > the information is stored in special tags with prefix > mkmap:lu:. > Example: If you specify --is-in-landuse=cemetery and an > element is within a > landuse=cemetery polygon mkgmap adds the tag > mkgmap:lu:cemetery=x where x is either "yes" or the name of > the cemetery. > The program builds a spatial index for each listed landuse > value to be able to compute > this information before the style rules in lines and points > are applied. > The default for this option is residential. To disable the > processing use > --no-is-in-landuse or an empty list of values. > If the style uses the tag mkgmap:residential which was set by > earlier versions > of mkgmap a warning is printed and the old tag is generated. > > Please suggest improvements. > I really had trouble to decide what to do with old styles using > mkgmap:residential. The patch implements compatibility > combined with a warning message to adapt the style. This allows to > keep the style for a while. > When the change is committed the old undocumented option --x > -residential-hook=false is ignored > with a corresponding warning. > > TODO: document the changes in the style manual. > Gerd > > > Von: Gerd Petermann > Gesendet: Freitag, 13. Dezember 2019 16:20 > An: jan meisters > Betreff: AW: [mkgmap-dev] Use of is_in in style > > Hallo Jan, > > der patch hat den Code nicht dupliziert, sondern > erweitert/verallgemeinert. Der Code ist auch nicht das Problem, > sondern die Kompatibilität mit vorhandenen Styles und die > Dokumentation. Ich kann auch mkgmap:landuse:xxx anstelle von > mkgmap:is-in:xxx generieren. Wichtig ist mir dabei, dass > - alle auf diese Art generierten Tags den gleichen Prefix haben und > - auf keinen Fall andere bereits dokumentierte Tags "überschreiben" > können > Letzteres ist ein eher akademisches Problem, aber stell Dir vor, es > gäbe ein landuse=street und jemand würde dass dann auswerten wollen. > Ohne extra prefix hätten wir dann evtl. einen unsinnigen Inhalt wie > "yes" in dem Tag, der eigentlich einen Straßennamen angibt. > > Wenn ich also aus mkgmap:residential jetzt ein > mkgmap:landuse:residential mache, dann funktionieren alte Styles > nicht mehr. > Ein Kompromiss wäre, alle neuen Tags mit Prefix mkgmap:landuse: zu > versehen und bei residential nur mkgmap: > > Das könnte ich dann auch irgendwie sinnvoll dokumentieren bei den > "mkgmap internal tags" im Style manual. > > Gerd > > > > Von: jan meisters > Gesendet: Freitag, 13. Dezember 2019 16:00 > An: Gerd Petermann > Betreff: Re: [mkgmap-dev] Use of is_in in style > > Hallo Gerd, > > ich bin nicht sicher, ob ich das Problem richtig verstanden habe ;-) > Du hattest, glaube ich, den Code von mkgmap:residential dupliziert, > um damit landuse abfragen zu können. > Aber eigentlich bräuchte man neuen Code für eine neue „Kategorie“ wie > z.Bsp. mkgmap:is-in:, um diese, abgegrenzt von mkgmap:residential, > über landuse hinaus abfragen zu können? > > Würde es denn helfen, wenn man Key und Tag für die neue Option > zusammenfasst, also etwa mkgmap:landuse=cemetery? > Sorry, mehr gibt meine Code-Unkenntnisse nicht her … > > > Ich habe aber inzwischen ein lines-file angepasst, um cemetery und > allotments sinnvoll „downzugraden“, ohne dabei zu viele Informationen > zu zerstören. > Idee war ja, diese oft mit Wegen überfrachteten und manchmal > erratisch getaggten Gebiete von Hervorhebungen für Radfahrer > (vehicle=no, cycle=yes, etc.) auszuschliessen. > Das wurde zwar komplizierter als gedacht, und ist mit Kompromissen > behaftet: Wege, die Gebietsgrenzen kreuzen, sind u.U. auch betroffen. > Leider auch Wege, die die Gebiete nur schneiden. Das ist zwar > unsauberer Zeichnung in OSM geschuldet, aber dennoch blöd. > Dennoch: so, wie es ist, funktioniert es klasse - für mich immerhin. > Missen möchte ich es eigentlich auch nicht mehr. > > Und bislang ist mir noch kein Gedanke g
