- mkgmap-dev - The mkgmap lists

Bay polygons points conversion
by David 20 Dec '19

20 Dec '19

Hi Gerd, I understand what you wrote but, in my case it does not work like that. The natural=bay [0x3d resolution 18] is commented in my polygon style file. The —add-pois-to-areas adds the tag mkgmap:area2poi=true to every polygons. My if statement is based on this tag in my points style. I tried this trick because I thought elements were removed after lines, polygons and points style are applied. My inspiration is based on the fact I am able to create contour lines for forest polygons with the lines style. All my tests are made with Ireland and the bay involved is Clew Bay. David

2 1

Bay polygons points conversion
by David 20 Dec '19

20 Dec '19

The if else is needed in my case because the option « add-pois-to-areas » adds at least one point for each polygon/multipolygon. For example, if a polygon is used to display a named hospital, you will then have also a point with the same name. As explained in the documentation, it makes possible to search the hospital. For Ireland, adding pois to polygons adds at least 3Mb more to the final img file. In Qmapshack, the name of extra POIs is displayed. With the if statement, I do not render bay polygon in polygons style file but I add a corresponding POI in points style file only for bays. This simple trick may need few lines in the documentation. But, I think the problem is that a bay is an inner part of something bigger (like an administrative area is a part of a country). As we do not render counties with a special polygon, bay should not be rendered because they are parts of ocean or sea with no really borders. Last point the style 0x3d chosen for bays is in Garmin Europe map and other Garmin products used for lakes with a size between 77 and 250 km2. 0x3b and 0x45 are known as to be blue like sea polygon and correspond to « unknown ». David

3 3

Bay polygons points conversion
by David 20 Dec '19

20 Dec '19

Hi there, Finally, I found a way to replace bay polygons by points : - use the add-pois-to-areas option - comment/remove the rule for bay in polygons style file - in pounts style file, add an « if then else end » statement to create a point of the kind you want only for elements with tag mkgmap:poi2area=true and put all the existing points rules in the « else » part. There is no need to change anything in mkgmap. David

2 1

yearly summary of mkgmap changes ?
by dave pitney 18 Dec '19

18 Dec '19

Another year of incredible development of mkgmap. Thanks! It would be helpful to have a yearly summary of the major mkgmap changes as there are too many for me to keep track of by following the dev-digest (although this is very helpful). Items such as new options, option changes/updates, code/behaviour changes, depreciated options are things that spring to mind. My concern is that following the dev-digest is following the trees and I may have missed the big picture. In addition, changes/updates that are planned during the next year would be helpful and maybe users could be polled for their top 3, although I have not had much success when polling my users. An option to not compress splitter file output is still top 'o my list. ; The wiki may be a good place for this list rather than buried in the dev-digest. I would offer to help with this but head off to Chile for 3 months of needed hiking, using maps made with mkgmap (of course) and will be without net connection. I am happy to review but leave in 2 weeks. Thanks, -- pitney ----------------- end of message ------------------------

1 0

Precomp-sea (to Ticker)
by David 18 Dec '19

18 Dec '19

Hi, The option « add-pois-to-areas » adds a POI to every polygons. I did not understand well the documentation about how to select which polygons are affected. Wouldn’t it be possible to replace selected polygons by a POI placed at its barycentric point with a rule in a style file ? (We can already use a polygon as a line) Last remark, some bays are described in OSM with a POI and Garmin format defines the corresponding symbol (0x6503). David

2 1

Commit r4397: implement and document new option --is-in-landuse=value[, value...]
by svn commit 18 Dec '19

18 Dec '19

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

6 13

Precomp-sea (to DD8K)
by David 16 Dec '19

16 Dec '19

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

3 2

Precomp-sea problem solved
by David 15 Dec '19

15 Dec '19

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

2 1

Re: [mkgmap-dev] Use of is_in in style
by Gerd Petermann 15 Dec '19

15 Dec '19

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 <gpetermann_muenchen(a)hotmail.com> 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 <jan_m23(a)gmx.net> 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 gekommen, auch andere Keys wie z.Bsp. leisure oder amenity nutzen zu können. Andere mögen das aber wollen - also verstehe ich Dich, wenn Du das vor der Dokumentation sauber ausgearbeitet haben möchtest. Wirst Du —x-is-in denn vorher schon in der bestehenden Form in den releases belassen? Mich würds freuen. Schöne Grüße! Jan Am 10.12.2019 um 11:24 schrieb Gerd Petermann <gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>: Hi Jan, thanks for the quick feedback. I am not yet sure about the prefix for those calculated tags. Maybe I change it from mkgmap: to mkgmap:is-in: so that I can document this prefix in the style manual. A separate name space is probably better. Problem is the existing mkgmap:residential which would then be mkgmap:is-in:residential. Existing styles would no longer work. I'll think about this, any suggestions are welcomed... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan meisters <jan_m23(a)gmx.net<mailto:jan_m23@gmx.net>> Gesendet: Dienstag, 10. Dezember 2019 11:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Gerd, thanks a lot! I tried the binary with the new option and it works exactly as I want it. To the .args-file I added x-is-in-landuse=residential,cemetery,industrial and to the beginning of lines highway=* & mkgmap:cemetery=* {set highway=path} Result is, as expected, the unified representation of lines inside the asked landuse. Other landuse-tags seem to work as well, I also played with allotments successfully: —x-is-in-landuse=residential,cemetery,allotments,industrial So, even with this „rough“ approach only for landuse, it´s a huge step ahead. Hopefully the option will remain in later releases. Unfortunately, me either am not able to dig into code to generalize the function. Jan Am 09.12.2019 um 17:28 schrieb Gerd Petermann <gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>>: Hi Jan, sorry, I compiled the binary before removing some debug code. Here is a clean one: http://files.mkgmap.org.uk/download/459/mkgmap.jar Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 16:31 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Jan, attached source could replace ResidentialHook. It implements new option --x-is-in-landuse so that one can use e.g. --x-is-in-landuse=residential,cemetery,industrial Without any option it works like the old ResidentialHook. For each given value, mkgmap checks if an element is inside a landuse with that value, if so, it adds the corresponding tag like mkgmap:residential or mkgmap:industrial This is all done before the style rules are executed, so all calculations are done for all elements. With a bit more work I can also add other polygon tags like natural=* or place=* but it would probably slow down mkgmap and require a lot more heap. A binary compiled with this is source is here: http://files.mkgmap.org.uk/download/458/mkgmap.jar Please try if it works for you. I'd prefer to have a general style function like is_in which could be used with is_in(landuse=cemetery) or is_in(natural=wood) but I have no idea how to implement the syntax parser etc. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 14:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Jan, the result of the is_in discussion was the ResidentialHook which computes the special tag mkgmap:residential. It would be possible to duplicate the code to calculate also a tag for landuse=cemetary. Not sure if that makes sense? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan_m23(a)gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net> <jan_m23(a)gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net>> Gesendet: Montag, 9. Dezember 2019 13:15 An: mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Use of is_in in style Can mkgmap use is_in to filter out objects inside specific (multi)polygons? In my case I´d like to unify ways inside cemeteries/grave-yards, e.g. highway=* & is_in:landuse=cemetery {set highway=path} Check-styles isn´t complaining of the syntax, but the rule has no effect. Similar has been discussed here, but without particular answer: http://gis.19327.n8.nabble.com/is-in-filter-td5890564.html#a5890836 Thanks _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <LanduseHook.java>_______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 2

Commit r4396: remove BOM and FID from typ file source
by svn commit 14 Dec '19

14 Dec '19

Version mkgmap-r4396 was committed by gerd on Sat, 14 Dec 2019 remove BOM and FID from typ file source http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4396

1 0