Hi Eric see embedded Ticker On Thu, 2020-03-26 at 05:46 -0700, AnkEric wrote:
Hi Ticker,
/> Is there a change that you'd like to see in the next version?/
No, thanks. Please consider: I'm only a private user. Therefore my RFC's or suggestions are only relevant if other users might benefit as well.
My conclusion (FWIW): Use "mapnik_fix.txt", update with Comments (restore lost information), rename to "mapnik.txt" and save in mkgmap repository. Next version: verify "mkgmap.txt" to be compliant, compatible with TYPViewer. Yes, this would be a change I'd like to see in the next version!
But first: verify if ([_polygon] type=0x3d, Bay) is okay for mkgmap if TYPViewer changes are applied.
Bay needs to be transparent. Changing the characters use to represent the pixels works around the TYPViewer problem.
Anke does not know what (natural=bay) is, where to find it (it's not in the Netherlands)
my old NL map had this: 51.34878873825073/3.7353515625 [name=Slufter Kwade Hoek, natural=bay] and these two named bays still exist https://www.openstreetmap.org/relation/3123125 https://www.openstreetmap.org/relation/1305743
and how to verify if it's up to mkgmap standards. A [natural=bay] is on top of the water?
A bay area will often include islands, so it must not hide these and the islands shouldn't be cut-out from the bay with a multipolygon relation. The reason for the polygon is for naming the area so the default style should be changed so the rule only triggers if named.
Similarly to [leisure=marina]? And should be rendered by name only?
this is not in the default style at the moment, but could be added (even if unnamed - it is a visible feature)
OT? Yes and No, since the "bay" took me an hour of billable work yesterday.
?
Moreover, Anke is wondering why [natural=bay] is explicitly rendered by mkgmap-default and (wetland=swamp) is not rendered by mkgmap-default.
wetland=swamp should only occur in conjunction with natural=wetland, which is handled by the mkgmap-default. Many of the decisions about what is handled by mkgmap-default are based on the standard TYPs supported by a typical Garmin device
Disappointing to say the least. Or why (natural=wetland & name=*) and (natural=wetland & name!=*) are rendered differently?
mkgmap-default doesn't do this
Hiding "wetland" as "meadow" if wetland is having a name?
I don't understand what you mean. I don't see anything in mkgmap -default that relates to this
/> This is fine for your usage, but not for changing the file in the mkgmap repository./
IMO, mkgmap - as a Global Application, having Global Users - needs a very good reason for not being compliant. In this context being not compliant to TYPViewer. "Change typfile (easy using TYPViewer) is your first option if you don't like the OSM-Map" is a suggestion I have made very often to dissatisfied users.
It might be easy, but it changes the file in ways that may cause incorrect behaviour, and in a typical file that hasn't been maintained by TYPViewer, it might change every section. Another tool my behave in a similar manner and feel free re-write the file in a different way; then it would quickly become impossible to know what is significant for any required changes.
Also for me: If I should want to change mkgmap.txt it's most simple by updating mkgmap.txt by TYPViewer, without having to Resolve the one (!) remaining "Error" or "Syntax difference" ([_polygon] type=0x3d) first.
The line that caused the TYPViewer input error has been changed in mkgmap. The other line that exposes a problem in TYPViewer should be be applied soon. It is difficult to predict the problems that other .typ manipulation tools might have.
/> The problem with using TYPViewer to change the file is that it has made lots of arbitary/irrelevant textual changes, lost information about the source encoding, added information about the destination encoding, removed the comments, etc/
Fact or fable?
Look at the saved .txt file
Yes, TYPViewer did "remove the comments" (if "mkgmap.txt" is converted to "<TYPViewer>.txt", but why would a user want to do this?).
Because they want to use TYPViewer to make changed to the mkgmap resources/typ-files/*.txt
If comments are added to mkgmap.txt, a User can see the comments. Once a User or mkgmap will update "mkgmap.txt" to "mkgmap.typ" this information is lost, but also not required for Compiling the Map.
This is obvious
All Compilers will always remove all comments in SourceCode.
Which compiler removes comments from the source code? Almost all won't copy the comments into the object format.
TYPViewer will generate a TXT file from the Compiled version (if requested), therefore Comments are removed, except for TYPViewer's own Comments. And since this - IMO - is the only drawback for TYPViewer: have we ever suggested this as a RFC to sherco40@ntymail.com ? Sherco has updated TYPViewer in my interest in the past.
Do this if you want to. I use a text editor to maintain the .txt file and mkgmap to convert it and build it into the map.
mkgmap.txt:
[_id] /;ProductCode=1 set from --product-id ;FID=8094 set from --family-id ;CodePage=65001 set from --code-page/
If I Change this into the next lines, TYPViewer will respect that, therefore no "lost information about the source encoding": [_id] ProductCode=1 FID=8094 CodePage=65001
It loses the BOM and encoding comment at the beginning of the file.
If I don't Set encoding (in "mapnik.txt"), I can set it inside TYPViewer:
<http://gis.19327.n8.nabble.com/file/t344065/TYPViewer_Encoding.png>
Encoding: TXT file mapnik is: "utf-8 BOM, Unix (Lf)" /; -*- coding: UTF-8 -*- NB: first 3 bytes/char in file is UTF-8 encoded ByteOrderMark (BOM)/ TXT file TYPViewer is: "utf-8, Win (CrLf)"
TYPViewer actually uses this information when you open a file with the standard "Open .TXT file" and gets its internal representation correct.
*Fact checking:* Compare "mkgmap.txt" and "mkgmap_fix.txt " and look for "arbitrary/irrelevant textual changes". To do so, Professionally I use UltraEdit and UltraCompare. Privately I use EditPad Lite (free for personal use) and WinMerge (free software). Both highly recommended for OSM, mkgmap.
<http://gis.19327.n8.nabble.com/file/t344065/TypeFiles_Compared_mkgma p_TYPViewer.png>
This reports 869 differences when the only required changes were changing a comma and some indentation. It would take a while looking at this diff be sure of this.
1. TYPViewer will remove Comments: ;Author: Jorisbo@hotmail.com ; ;Based on mkgmap default style version: r4293...4288 ; Etc.
2. TYPViewer will add more Comments: ;=========== POLYGONES : PRIORITE DANS L'AFFICHAGE ====== Unfortunately in French language, which is - imo - as "unwanted" as Dutch or German language, not to mention Chinese.
3. TYPViewer sets Case: "type" > "Type", "subtype" > "SubType"
4. TYPViewer will Sort [_drawOrder] (but will not change [_drawOrder]): Type=0x04b,1 Type=0x03d,1 Type=0x002,2 to: Type=0x03b,1 Type=0x04d,1 Type=0x002,2
It will change 0xNN to 0x0NN
5. TYPViewer will change Transparant: "." > " "
6. TYPViewer will sort and renumber Language: Mapnik: String=Village String1=0x01,Résidentiel String2=0x02,Wohngebiet String4=0x03,Bebouwing TYPViewer: String1=0x00,Village String2=0x01,Résidentiel String3=0x02,Wohngebiet String4=0x03,Bebouwing
Thanks to TYPViewer sorting and renumbering Language Strings, it immediately stood out (looking at TYPViewer TXT file) translations are incomplete in mapnik.txt. Complete is: String1 - String8 (8 languages). Incomplete is: String1 - String7 (one language missing) String1 - String4 (four languages missing).
There are a lot of missing translations / many other languages.
Examples of missing languages:
[_polygon] Type=0x05 ;GRMN_TYPE: Large Manmade Areas/PARKING_LOT/Parking lot area/Non NT String1=0x00,Parking Lot String2=0x01,Parking String3=0x02,Parkplatz String4=0x04,Car Park String5=0x03,Parkeerterrein String6=0x15,Parking String7=0x10,Estacionamento String8=0x05,Parcheggio ExtendedLabels=Y
[_polygon] Type=0x07 ;GRMN_TYPE: Large Manmade Areas/AIRPORT/Airport area/Non NT String1=0x00,Airport String2=0x01,Aéroport String3=0x02,Flughafen String4=0x03,Vliegveld String5=0x15,Lotnisko String6=0x10,Aeroporto String7=0x05,Aerodromo ExtendedLabels=Y
[_polygon] Type=0x12 ;GRMN_TYPE: // String1=0x00,Retail String2=0x01,Aire String3=0x02,Raststätte String4=0x03,Snelweg rustplaats ExtendedLabels=Y
Some might not have been given because the default is adequate.
Eric (Eric & Anke, AnkEric)
-- 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