[mkgmap-dev] Precomp-sea problem solved
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
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 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
Re: [mkgmap-dev] New branch for default typ file
Hi Randolph, is there anything wrong regarding unicode support in mkgmap? If yes, please post a patch or - at least - describe more details. Gerd Von: mkgmap-dev im Auftrag von Randolph J. Herber Gesendet: Samstag, 14. Dezember 2019 18:20 An: Development list for mkgmap; Pinns UK Betreff: Re: [mkgmap-dev] New branch for default typ file Dear Sirs: Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8) as that works in iOS and Unix. Randolph J. Herber On 12/14/2019 9:53 AM, Pinns UK wrote: > Hi Gerd > > The reason for suggesting unicode is that it caters for all languages, > not just those specified by 1252 or 1250 or 1251 > > However, anyone not used to or bothered about codepages, will > benefit from a mapnik.txt where the characters are 1252 compliant. > > I now have all my maps using cp 65001 as Basecamp/ (mapsource?) > automatically selects the appropriate language depending on the > user's Region settings. > > Nick > > > > > On 14/12/2019 15:11, Gerd Petermann wrote: >> Hi all, >> >> when the source for the typ file specifies a codePage which is >> different from the one used on the command line we see a warning >> WARNING: SortCode in TYP txt file different from command line setting >> >> As an unexperienced user I would try to get rid of such a warning, >> maybe causing more trouble than needed. >> A comment in the source says "This is just a warning, not a definite >> problem" >> >> In (1) Nick suggested to use unicode in the typ file, so I wonder in >> what situation this warning is needed? >> >> Gerd >> (1) >> http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html >> >> >> Von: mkgmap-dev im Auftrag >> von Gerd Petermann >> Gesendet: Samstag, 14. Dezember 2019 15:21 >> An: Ticker Berkin; Development list for mkgmap >> Betreff: Re: [mkgmap-dev] New branch for default typ file >> >> Hi Ticker & Joris >> >> I'd also prefer to maintain it as txt file, else I'd prefer to remove >> the file and add a simple hint were to find Joris files. >> >> @Ticker: >> The problem mentioned here is still there. >> http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html >> >> I'll try to code a fix now. >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag >> von Ticker Berkin >> Gesendet: Samstag, 14. Dezember 2019 10:41 >> An: Development list for mkgmap >> Betreff: Re: [mkgmap-dev] New branch for default typ file >> >> Hi Joris & Gerd >> >> Great to see the typ-files now in trunk and all the work in updating >> mapnik.txt to the current default style. Next week I plan to go through >> "20191209 mapnik update.pdf" and comment on it and possible changes to >> the default style. >> >> Some other questions however: >> >> How do you see mapnik.txt now being maintained; will it be as as simple >> .txt file with patches being supplied in the same way as other source >> files, or will it be regenerated from your translation spreadsheet and >> other sources? I'd prefer the simple text file approach, but this might >> allow changes into the file which make it incompatible with the tools >> Joris uses to enhance it. >> >> It is currently in UTF8 format, with an appropriate BOM at the start of >> the file. I don't know how the java input libraries determine the >> conversion rules to internal unicode, but this file should be >> consistent with all the others that contain characters outside the >> simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) >> >> It contains the statement: >>> CodePage=65001 >> This is saying the output should be unicode, but the output should be >> the same as the associated map. >> >> Also the FID should be removed. >> >> Regards >> Ticker >> >> On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote: >>> Hi Joris, >>> >>> the file mapnik.txt says "Based on mkgmap default style version: >>> r4262" >>> Is it the right file? >>> >>> reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | >>> mkgmap:dest_hint=*) >>> I want to look at the DestinationHook. If I got that right it should >>> be OK to have a zero-length road with that type to get the wanted >>> destination hint. In that case we don't have to care about rendering. >>> >>> Gerd >>> >>> >>> Von: Joris Bo >>> Gesendet: Montag, 9. Dezember 2019 20:45 >>> An: Development list for mkgmap; Gerd Petermann >>> Betreff: RE: [mkgmap-dev] New branch for default typ file >>> >>> Hi All, >>> >>> I don't think any changes needed in mkgmap itself. When the draworder >>> of bay is lower then water it will display correctly. >>> See attached new typ-file for correct usage. >>> Even better (but this is a change in default style): don't use >>> natural = bay in polygons but only in points for displaying as name. >>> >>> Today I spent some
Re: [mkgmap-dev] New branch for default typ file
Dear Sirs: Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8) as that works in iOS and Unix. Randolph J. Herber On 12/14/2019 9:53 AM, Pinns UK wrote: Hi Gerd The reason for suggesting unicode is that it caters for all languages, not just those specified by 1252 or 1250 or 1251 However, anyone not used to or bothered about codepages, will benefit from a mapnik.txt where the characters are 1252 compliant. I now have all my maps using cp 65001 as Basecamp/ (mapsource?) automatically selects the appropriate language depending on the user's Region settings. Nick On 14/12/2019 15:11, Gerd Petermann wrote: Hi all, when the source for the typ file specifies a codePage which is different from the one used on the command line we see a warning WARNING: SortCode in TYP txt file different from command line setting As an unexperienced user I would try to get rid of such a warning, maybe causing more trouble than needed. A comment in the source says "This is just a warning, not a definite problem" In (1) Nick suggested to use unicode in the typ file, so I wonder in what situation this warning is needed? Gerd (1) http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Samstag, 14. Dezember 2019 15:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Ticker & Joris I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files. @Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html I'll try to code a fix now. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement: CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map. Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote: Hi Joris, the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file? reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering. Gerd Von: Joris Bo Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file Hi All, I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name. Today I spent some time testing and repairing. The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur. I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly. I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured. I think it’s up to date again but some review and comments are always welcome. See typ-file in attachement, Kind regards, Joris -Oorspronkelijk bericht- Van: mkg
Re: [mkgmap-dev] New branch for default typ file
Hi Gerd The reason for suggesting unicode is that it caters for all languages, not just those specified by 1252 or 1250 or 1251 However, anyone not used to or bothered about codepages, will benefit from a mapnik.txt where the characters are 1252 compliant. I now have all my maps using cp 65001 as Basecamp/ (mapsource?) automatically selects the appropriate language depending on the user's Region settings. Nick On 14/12/2019 15:11, Gerd Petermann wrote: Hi all, when the source for the typ file specifies a codePage which is different from the one used on the command line we see a warning WARNING: SortCode in TYP txt file different from command line setting As an unexperienced user I would try to get rid of such a warning, maybe causing more trouble than needed. A comment in the source says "This is just a warning, not a definite problem" In (1) Nick suggested to use unicode in the typ file, so I wonder in what situation this warning is needed? Gerd (1) http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Samstag, 14. Dezember 2019 15:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Ticker & Joris I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files. @Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html I'll try to code a fix now. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement: CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map. Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote: Hi Joris, the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file? reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering. Gerd Von: Joris Bo Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file Hi All, I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name. Today I spent some time testing and repairing. The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur. I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly. I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured. I think it’s up to date again but some review and comments are always welcome. See typ-file in attachement, Kind regards, Joris -Oorspronkelijk bericht- Van: mkgmap-dev Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann ; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file Hi Gerd Y
Re: [mkgmap-dev] New branch for default typ file
Dear Sirs:
Re UTF-8
Microsoft does this to handle another problem: Microsoft uses many
different character set encodings (i.e., code pages, e.g., CP1252) and
the BOM is used by Microsoft to indicate that the "code page" is UTF-8.
Java was implemented to an older version of the Unicode standard that
prohibited an UTF-8 BOM. The problem is comes from moving back and forth
across that cultural divide. Yes, this is painful.
A solution to the reading issue from the Java side:
https://stackoverflow.com/questions/1835430/byte-order-mark-screws-up-file-reading-in-java
A solution for writing a UTF-8 BOM in Java:
|BufferedWriter out = new BufferedWriter(new OutputStreamWriter(new
FileOutputStream(the File), StandardCharsets.UTF_8))out.write('\ufeff');|
A check for execution in a Windows environment:
String OS = System.getProperty("os.name").toLowerCase();
Boolean isWindows = OS.indexOf("win") >= 0;
Perhaps, on output write the BOM in a Windows environment and use the
BOM optional on input.
http://www.unicode.org/faq/utf_bom.html
Q: What are some of the differences between the UTFs?
A: The following table summarizes some of the properties of each of the
UTFs.
NameUTF-8 UTF-16 UTF-16BEUTF-16LEUTF-32 UTF-32BE
UTF-32LE
Smallest code point
Largest code point 10 10 10 10 10 10 10
Code unit size 8 bits 16 bits 16 bits 16 bits 32 bits 32 bits 32
bits
Byte order N/A big-endian little-endian big-endian
little-endian
Fewest bytes per character 1 2 2 2 4 4
4
Most bytes per character4 4 4 4 4 4
4
In the table indicates that the byte order is determined by a byte
order mark, if present at the beginning of the data stream, otherwise it
is big-endian.
http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf
Table 2-4. The Seven Unicode Encoding Schemes
Encoding Scheme Endian Order BOM Allowed?
UTF-8 N/A yes
The remainder of the table omitted.
https://docs.microsoft.com/en-us/windows/win32/intl/using-byte-order-marks
Using Byte Order Marks
* 05/30/2018
* 2 minutes to read
*
o
o
Always prefix a Unicode plain text file with a byte order mark, which
informs an application receiving the file that the file is byte-ordered.
Available byte order marks are listed in the following table. Because
Unicode plain text is a sequence of 16-bit code values, it is sensitive
to the byte ordering used when the text is written.
Note
A byte order mark is not a control character that selects the byte order
of the text.
Byte order mark Description
EF BB BFUTF-8
FF FE UTF-16, little endian
FE FF UTF-16, big endian
FF FE 00 00 UTF-32, little endian
00 00 FE FF UTF-32, big-endian
On 12/14/2019 3:41 AM, Ticker Berkin wrote:
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.
Some other questions however:
How do you see mapnik.txt now being maintained; will it be as as simple
.txt file with patches being supplied in the same way as other source
files, or will it be regenerated from your translation spreadsheet and
other sources? I'd prefer the simple text file approach, but this might
allow changes into the file which make it incompatible with the tools
Joris uses to enhance it.
It is currently in UTF8 format, with an appropriate BOM at the start of
the file. I don't know how the java input libraries determine the
conversion rules to internal unicode, but this file should be
consistent with all the others that contain characters outside the
simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
It contains the statement:
CodePage=65001
This is saying the output should be unicode, but the output should be
the same as the associated map.
Also the FID should be removed.
Regards
Ticker
On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version:
r4262"
Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
mkgmap:dest_hint=*)
I want to look at the DestinationHook. If I got that right it should
be OK to have a zero-length road with that type to get the wanted
destination hint. In that case we don't have to care about rendering.
Gerd
Von: Joris Bo
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any
[mkgmap-dev] Commit r4396: remove BOM and FID from typ file source
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 ___ 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 all, when the source for the typ file specifies a codePage which is different from the one used on the command line we see a warning WARNING: SortCode in TYP txt file different from command line setting As an unexperienced user I would try to get rid of such a warning, maybe causing more trouble than needed. A comment in the source says "This is just a warning, not a definite problem" In (1) Nick suggested to use unicode in the typ file, so I wonder in what situation this warning is needed? Gerd (1) http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Samstag, 14. Dezember 2019 15:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Ticker & Joris I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files. @Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html I'll try to code a fix now. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement: > CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map. Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote: > Hi Joris, > > the file mapnik.txt says "Based on mkgmap default style version: > r4262" > Is it the right file? > > reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | > mkgmap:dest_hint=*) > I want to look at the DestinationHook. If I got that right it should > be OK to have a zero-length road with that type to get the wanted > destination hint. In that case we don't have to care about rendering. > > Gerd > > > Von: Joris Bo > Gesendet: Montag, 9. Dezember 2019 20:45 > An: Development list for mkgmap; Gerd Petermann > Betreff: RE: [mkgmap-dev] New branch for default typ file > > Hi All, > > I don't think any changes needed in mkgmap itself. When the draworder > of bay is lower then water it will display correctly. > See attached new typ-file for correct usage. > Even better (but this is a change in default style): don't use > natural = bay in polygons but only in points for displaying as name. > > Today I spent some time testing and repairing. > > The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and > also did not have the translations of all the languages anymore. It > also lost draworder of a lot of polygons which made the bay-problem > occur. > > I did a complete recheck of the most recent default-style in: mkgmap > -r4386.zip and changed de typ-file accordingly. > > I downloaded a full europe-latest from geofabrik today, builded it as > a big full europa map with the default style of r4386 and with > mkgmap r4386.jar No errors occured. > > I think it’s up to date again but some review and comments are always > welcome. > > See typ-file in attachement, > > Kind regards, > Joris > > > > > > -Oorspronkelijk bericht- > Van: mkgmap-dev Namens Pinns > UK > Verzonden: maandag 9 december 2019 18:31 > Aan: Gerd Petermann ; > mkgmap-dev@lists.mkgmap.org.uk > Onderwerp: Re: [mkgmap-dev] New branch for default typ file > > Hi Gerd > > Yes, you can do that with a draw level 1 higher than sea. > > Draw orders are defined at the beginning of a (txt) typ file just > before the polygons > > using the following format > > Type=0x type number , draworder > > It is good practice to sort the draworders , as that is how they > appear in a typ file > > [_drawOrder] > Type=0x03,1 > Type=0x28,1 > Type=0x54,1 > Ty
[mkgmap-dev] Commit r4395: Correction typ compile: Ignore codepage from options or command line if typ file specifies codePage in the [_id] section
Version mkgmap-r4395 was committed by gerd on Sat, 14 Dec 2019 Correction typ compile: Ignore codepage from options or command line if typ file specifies codePage in the [_id] section http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4395 ___ 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 Ticker & Joris I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files. @Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html I'll try to code a fix now. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement: > CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map. Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote: > Hi Joris, > > the file mapnik.txt says "Based on mkgmap default style version: > r4262" > Is it the right file? > > reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | > mkgmap:dest_hint=*) > I want to look at the DestinationHook. If I got that right it should > be OK to have a zero-length road with that type to get the wanted > destination hint. In that case we don't have to care about rendering. > > Gerd > > > Von: Joris Bo > Gesendet: Montag, 9. Dezember 2019 20:45 > An: Development list for mkgmap; Gerd Petermann > Betreff: RE: [mkgmap-dev] New branch for default typ file > > Hi All, > > I don't think any changes needed in mkgmap itself. When the draworder > of bay is lower then water it will display correctly. > See attached new typ-file for correct usage. > Even better (but this is a change in default style): don't use > natural = bay in polygons but only in points for displaying as name. > > Today I spent some time testing and repairing. > > The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and > also did not have the translations of all the languages anymore. It > also lost draworder of a lot of polygons which made the bay-problem > occur. > > I did a complete recheck of the most recent default-style in: mkgmap > -r4386.zip and changed de typ-file accordingly. > > I downloaded a full europe-latest from geofabrik today, builded it as > a big full europa map with the default style of r4386 and with > mkgmap r4386.jar No errors occured. > > I think it’s up to date again but some review and comments are always > welcome. > > See typ-file in attachement, > > Kind regards, > Joris > > > > > > -Oorspronkelijk bericht- > Van: mkgmap-dev Namens Pinns > UK > Verzonden: maandag 9 december 2019 18:31 > Aan: Gerd Petermann ; > mkgmap-dev@lists.mkgmap.org.uk > Onderwerp: Re: [mkgmap-dev] New branch for default typ file > > Hi Gerd > > Yes, you can do that with a draw level 1 higher than sea. > > Draw orders are defined at the beginning of a (txt) typ file just > before the polygons > > using the following format > > Type=0x type number , draworder > > It is good practice to sort the draworders , as that is how they > appear in a typ file > > [_drawOrder] > Type=0x03,1 > Type=0x28,1 > Type=0x54,1 > Type=0x01,2 > Type=0x09,2 > Type=0x4E,2 > Type=0x10F1C,2 > etc etc > [end] > I have no idea what the draworder for sea is , but just make it one > higher > > On 09/12/2019 16:41, Gerd Petermann wrote: > > Hi Nick, > > > > I don't want to cut out islands from bay polygons, I thought about > > a proper typ for 0x3d which somehow marks "calmer water" > > and a draw order that puts this above water and below any land type > > polygon. > > Is that possible? > > > > Gerd > > > > > > Von: Pinns UK > > Gesendet: Montag, 9. Dezember 2019 16:17 > > An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk > > Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file > > > > Hi Gerd > > > > Yes, I suppose so > > > > On 09/12/2019 15:14, Gerd Petermann wrote: > > > Hi Nick, > > > > > > my understanding is that you alway
Re: [mkgmap-dev] Suggestions for roadNameConfig.txt
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] Commit r4394: improve Portuguese handling on roadNameConfig.txt
Version mkgmap-r4394 was committed by gerd on Sat, 14 Dec 2019 improve Portuguese handling on roadNameConfig.txt Suggested by Alexandre Folle de Menezes http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4394 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4393: Improvements for options--process-destination and --process-exits
Version mkgmap-r4393 was committed by gerd on Sat, 14 Dec 2019 Improvements for options--process-destination and --process-exits I've noticed that the code tries to avoid distortions but that code was written before WrongAngleFixer. The effect is that the combination of boths sometimes produces even worse distortions like zig-zagging motorways near exits, e.g. near node 75622743. The old code did not add a hint when the corresponding way was less than 10m long. I've changed that limit to 0.3 metres. I've also removed some code duplications. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4393 ___ 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 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 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 mailto:gpetermann_muenc...@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
Re: [mkgmap-dev] New branch for default typ file
Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement: > CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map. Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote: > Hi Joris, > > the file mapnik.txt says "Based on mkgmap default style version: > r4262" > Is it the right file? > > reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | > mkgmap:dest_hint=*) > I want to look at the DestinationHook. If I got that right it should > be OK to have a zero-length road with that type to get the wanted > destination hint. In that case we don't have to care about rendering. > > Gerd > > > Von: Joris Bo > Gesendet: Montag, 9. Dezember 2019 20:45 > An: Development list for mkgmap; Gerd Petermann > Betreff: RE: [mkgmap-dev] New branch for default typ file > > Hi All, > > I don't think any changes needed in mkgmap itself. When the draworder > of bay is lower then water it will display correctly. > See attached new typ-file for correct usage. > Even better (but this is a change in default style): don't use > natural = bay in polygons but only in points for displaying as name. > > Today I spent some time testing and repairing. > > The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and > also did not have the translations of all the languages anymore. It > also lost draworder of a lot of polygons which made the bay-problem > occur. > > I did a complete recheck of the most recent default-style in: mkgmap > -r4386.zip and changed de typ-file accordingly. > > I downloaded a full europe-latest from geofabrik today, builded it as > a big full europa map with the default style of r4386 and with > mkgmap r4386.jar No errors occured. > > I think it’s up to date again but some review and comments are always > welcome. > > See typ-file in attachement, > > Kind regards, > Joris > > > > > > -Oorspronkelijk bericht- > Van: mkgmap-dev Namens Pinns > UK > Verzonden: maandag 9 december 2019 18:31 > Aan: Gerd Petermann ; > mkgmap-dev@lists.mkgmap.org.uk > Onderwerp: Re: [mkgmap-dev] New branch for default typ file > > Hi Gerd > > Yes, you can do that with a draw level 1 higher than sea. > > Draw orders are defined at the beginning of a (txt) typ file just > before the polygons > > using the following format > > Type=0x type number , draworder > > It is good practice to sort the draworders , as that is how they > appear in a typ file > > [_drawOrder] > Type=0x03,1 > Type=0x28,1 > Type=0x54,1 > Type=0x01,2 > Type=0x09,2 > Type=0x4E,2 > Type=0x10F1C,2 > etc etc > [end] > I have no idea what the draworder for sea is , but just make it one > higher > > On 09/12/2019 16:41, Gerd Petermann wrote: > > Hi Nick, > > > > I don't want to cut out islands from bay polygons, I thought about > > a proper typ for 0x3d which somehow marks "calmer water" > > and a draw order that puts this above water and below any land type > > polygon. > > Is that possible? > > > > Gerd > > > > > > Von: Pinns UK > > Gesendet: Montag, 9. Dezember 2019 16:17 > > An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk > > Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file > > > > Hi Gerd > > > > Yes, I suppose so > > > > On 09/12/2019 15:14, Gerd Petermann wrote: > > > Hi Nick, > > > > > > my understanding is that you always have another water polygon, > > > either ocean or natural=water. > > > > > > Gerd > > > > > > > > > Von: Pinns UK > > > Gesendet: Montag, 9. Dezember 2019 16:04 > > > An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk > > > Betreff: Re: AW: [mkgmap-dev] New branch for default typ file > > > > > > Hi Gerd > > > > > > In case of 2) you need 2 polygons for doing each job; one showing > > > 'water' and the other one not > > > > > > Ideally,mkgmap checks if islands are in a 'bay'
