Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract
Please, consider the following: 1) In some languages, adjectives follow the noun, e.g., the Romance languages; in others, the adjectives precede the noun, e.g., the Teutonic languages. 2) The writing order varies: left-to-right, right-to-left, top-to bottom, etc. 3) There are languages with moderately strict adjective order, e.g., English, with determiner, quantity, opinion, size, age, shape, color, and origin/material. 4) There are languages where some of the adjectives are in the verb, e.g., the Athabaskan languages. Therefore "one size fits all" trimming is not going to work. On 02-Dec-21 11:02, Gerd Petermann wrote: Hi Felix, I think the code removes only suffixes to avoid messing real road names consisting of multiple words. Why do you add e.g. M0. as prefix? What does it mean? Or is it a ref? Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] What is this error actually telling me.
How do I tell which tile. I quoted the entire error message. On 23-Jul-21 17:29, Gerd Petermann wrote: Do you get this error message for the overview map or for a single tile? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] What is this error actually telling me.
SEVERE (global): The RGN section of the map or tile is too big. The maximum size is 16777215 bytes. Try splitting the map into smaller tiles or reducing the amount of information included in the map. With last year's versions, this worked. What is the fix? I osmosis combined the pbf files from geofabrik.de for north, central, and south America using osmosis, which appeared to have worked without problems. The pbfs were down loaded in the last two weeks. There were some roundabout errors from splitter. I get the error message above from mkgmap. E:\OSMMaps>type combineAmericas.bat files\osmosis\bin\osmosis.bat ^ --read-pbf data\central-america-latest.osm.pbf ^ --read-pbf data\south-america-latest.osm.pbf ^ --merge ^ --read-pbf data\north-america-latest.osm.pbf ^ --merge ^ --write-pbf data\americas.osm.pbf E:\OSMMaps>type splitterAmericasUC.bat java -Xmx6G -jar files\splitter\splitter.jar ^ --description="AmericasUC" ^ --geonames-file=files\cities1000.zip ^ --keep-complete=true ^ --mapid=99970001 ^ --max-areas= ^ --max-nodes=100 ^ --max-threads=7 ^ --output=pbf ^ --output-dir=AmericasUC ^ --precomp-sea=files\sea.zip ^ --resolution=13 ^ --status-freq=30 ^ --wanted-admin-level=10 ^ --write-kml=AmericasUC\split.kml ^ data\americas.osm.pbf E:\OSMMaps>type mkgmapAmericasUC.bat java -Xmx6G -jar files\mkgmap\mkgmap.jar ^ --output-dir="AmericasUC"\map ^ --nsis ^ --tdbfile ^ --overview-mapname=9997 ^ --mapname=99970001 ^ --family-id=9997 ^ --description="AmericasUC" ^ --series-name="AmericasUC" ^ --family-name="AmericasUC" ^ --gmapi ^ --gmapsupp ^ --draw-priority=1 ^ --latin1 ^ --index ^ --housenumbers ^ --bounds=files\bounds.zip ^ --precomp-sea=files\sea.zip ^ --location-autofill=is_in,nearest ^ --name-tag-list=name:en,int_name,name ^ --add-pois-to-lines ^ --add-pois-to-areas ^ --pois-to-areas-placement ^ --preserve-element-order ^ --road-name-pois ^ --remove-ovm-work-files ^ --route ^ --remove-short-arcs ^ --adjust-turn-headings ^ --process-destination ^ --process-exits ^ --reduce-point-density=3 ^ --reduce-point-density-polygon=4 ^ --merge-lines ^ --drive-on=detect,right ^ --report-roundabout-issues ^ --max-jobs=7 ^ --verbose ^ --order-by-decreasing-area ^ --style-file=style2 ^ --check-styles ^ -c AmericasUC\template.args ^ typ\Symbols.typ E:\OSMMaps> ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters
2 megameter is a short trip (about 1250 miles)? I made this trip three times in this last year. This is almost exclusively Interstate usage (think German Autobahn). On 05-May-21 03:32, Felix Hartmann wrote: Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters
Huh, that statement is wrong. Garmin uses OSM and they acknowledge that fact. I own five Garmin receivers for car navigation and use Garmin maps in the new ones and mkgmap generated maps in the older ones. I do not use Google Maps in my phones for navigation at all. On 05-May-21 02:42, Felix Hartmann wrote: But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] remainder of logging changes
Java generally can be installed readily in Linux. Here is a Ubuntu example: $ java Command 'java' not found, but can be installed with: sudo apt install default-jre sudo apt install openjdk-11-jre-headless sudo apt install openjdk-8-jre-headless Randolph J. Herber On 13-Apr-21 04:35, Gerd Petermann wrote: Hi all, forgot to mention that "java.exe" probably doesn't exist on a unix based system, and also the path "dist\\mkgmap.jar" probably will not work. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Montag, 12. April 2021 17:56 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] remainder of logging changes Hi Gerd, Please find attached a patch with the remainder of the logging changes (apart from CommandArgs). There are changes to the main program so that the dates and times are only output if mkgmap is processing one or more files. The patch includes an update to the unit test. Note that this now takes a little longer to run, because of having to create new processes to run some of the tests. BTW, were you expecting a change to diagnosticmessages.patch, or is it OK as it stands? (I've attached a copy in case it got lost amongst all the others.) Cheers, Mike ___ 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] TYP file. Descriptions and translations
Dear Sirs:
Again I offer a set of translations via Google translate, which, of
course, means that they need be edited by native language users.
Nonetheless, I expect that they would be a useful basis from which to start.
These languages already have been done (the codes before the arrows are
the language codes that I had assigned arbitrarily):
{"1d" -> "Albanian", "29" -> "Arabic", "09" -> "Basque",
"2a" -> "Belarussian", "1e" -> "Bosnian", "23" -> "Brazilian",
"22" -> "Bulgarian", "0a" -> "Catalan", "13" -> "Croatian",
"12" -> "Czech", "0e" -> "Danish", "03" -> "Dutch",
"04" -> "English", "06" -> "Finnish", "01" -> "French",
"0d" -> "Gaelic", "0b" -> "Galician", "02" -> "German",
"17" -> "Greek", "14" -> "Hungarian", "2e" -> "Irish",
"05" -> "Italian", "25" -> "Japanese", "24" -> "Korean",
"1a" -> "Latvian", "1b" -> "Latvian", "21" -> "Macedonian",
"2c" -> "Moldavian", "2d" -> "Montenegrin", "0f" -> "Norwegian",
"15" -> "Polish", "10" -> "Portuguese", "1c" -> "Romanian",
"19" -> "Russian", "1f" -> "Serbian", "26" -> "Simplified Chinese",
"11" -> "Slovak", "18" -> "Slovenian", "08" -> "Spanish",
"07" -> "Swedish", "28" -> "Thai", "27" -> "Traditional Chinese",
"16" -> "Turkish", "2b" -> "Ukrainian", "0c" -> "Welsh"}
For example, I already know that the Portuguese translation is a mixture
of dialects, including Brazilian and Iberian peninsula.
Sincerely,
Randolph J. Herber
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Split gmapsupp.img
The 4GB limit is a result of the fact that Garmin devices use FAT16B without LFS (only the very oldest) and FAT32 (all the rest) filesystems. Garmin devices do not support exFAT; though, devices with rewritable firmware could be made to support exFAT. The reason that FAT file systems are used are they are freely available and work on Linux, Windows and Apple operating systems. Please, see: https://en.wikipedia.org/wiki/File_Allocation_Table https://physics.nist.gov/cuu/Units/binary.html https://en.wikipedia.org/wiki/ExFAT There are several sizes of concern: cluster size, maximum file size, maximum number of files, and maximum file system size. Each of these sizes are powers of two or powers of 2 less one. Because of the powers of 2, SI binary prefixes will be used. Remember only one file can be stored in a cluster and a file may have more than one cluster. The space at the end of the last cluster of a file is wasted. FAT12 4KiB and 8KiB clusters, file size limited by volume size, 4068 files with 8 KiB clusters, 16MiB with 4KiB and 32MiB with 8 KiB clusters. FAT16B minimum file system sizes 8 MiB with 128, 32 MiB with 512*, and 256 MiB 4 KiB disk logical sector sizes, 2GiB-1 without LFS and 4GiB-1 with LFS, cluster sizes are powers of 2 from 512 to 32768, 65460 files with 32 KiB clusters, maximum file systems size is 65525 clusters. FAT32 32 MiB-4.5 KiB (with 65525 clusters and 512 byte sectors) and 256 MiB-36 KiB (with 65525 clusters and 4 KiB sectors), same filesize limits as FAT16B, cluster sizes that are powers of 2 from 512 to 2,097,152. exFAT maximum file size practical 128 PiB-1, structural limit 16 EiB-1, maximum volume size practical 128 PiB, maximum number of files per directory 2,796,202. * almost all non CHR disks are 512 byte sectored. People will tell you that you can not use a SD card larger than a certain size dependent on Garmin receiver model. This is not true. The actual requirement is that a Garmin receiver only looks that the first primary partition on a SD card. Simply, divide the SD card into two partitions (in Windows, the disk manager can do this), format that partition as the appropriate FAT format, and put the map or maps there. The second partition can be formatted as one desires and used as desired. This is a handy space in which to store other previously made maps or even a complete map building system. I have done this on Garmin receivers as old as Garmin StreetPilot 2610 with SD cards as large as 256 GB (the card uses some of the memory for its management purposes). On 10/18/2020 2:14 AM, Carlos Dávila wrote: As far as I know, mkgmap is able to produce unlimited size gmapsupp files, but SD cards and internal device memories have a limit of 4 GB in a single file. To overcome that limit, recent versions of Garmin City Navigator maps are split into several gmapsupp that work as a single one in devices which include them. Would it be possible to add an option to mkgmap, so that it automatically splits gmapsupp when you process a map that is larger than 4 GB? ___ 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] A contribution to the vocabulary based on the mkgmap default style and typ files.
Dear, Sir: Apparently, I did not make myself sufficiently clear. I apologize. First, I request the codes from 0x23 to 0x2e so that I can assign the correct languages to those codes. Second, and I quote myself: "I arbitrarily assigned codes for the other languages." I see two uses for the table I provided. First, for someone that does not use a language whose code is 0x01 to 0x22 to use one of the "extra" languages to fill slot 0x00 or, in fact, any of the slots to have a more comfortable language in their Garmin receiver. Second, for some who does not not want to do a language re-assignment, to find translations from a more comfortable language to one of the Garmin "official" languages. In no way to I contradict your statement: "As far as I know Garmin only uses codes up to 0x2E." As I said before: "I request consideration: I intend no offense and corrections are welcome." Sincerely, Randolph J. Herber On 8/9/2020 4:41 AM, nick wrote: Hi I'm interested to learn the source you used for language codes > &0x2F . As far as I know Garmin only uses codes up to 0x2E Regards Nick On 08/08/2020 21:42, Randolph J. Herber wrote: Hi, all! First, note the attached file is in JSON format and is inherently UTF-8. Second, the file contains four sub-tables: point, line, polygon, and language. The first three should be obvious. The language sub-table contains the languages presented. I used the extant codes for the extant languages mentioned in the mkgmap web documentation. I arbitrarily assigned codes for the other languages. Altogether, one hundred three languages are presented. I used Google Translate and am paying for Google's services here. Therefore, this is work-for-hire and I may give them away. Yes, I readily admit some of translations are awkward or even incorrect. There, I request consideration: I intend no offense and corrections are welcome. I tended not to change Eurocentric terms to American terms although in some cases I added the equivalent American term. I expanded some of the phrases in hopes of improving the machine translations. Third, I feel that all urban areas should be treated equivalently and I note Ticker Berkin's previous comments on that topic, the translations reflect my preferences. I did incorporate Ticker's most significant objection which I did find valid. Also, I feel that an logarithmic scale is appropriate in this application and that 3.2*3.2 is 10.24, which is about 10. This allows a good range of population values. Fourth, I am working on incorporating this material into the default style and typ files, in particular the typ file. Thank you, Randolph J. Herber ___ 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] Error in Africa?
Hello, all! Does this tile happen to contain the Port Said area near Cairo, Egypt? If so, you may be facing the same problem that I encountered in splitter. Splitter only limits the number of nodes in a tile. It ought to limit the number of ways as well. The Port Said area has an immense number of single city block length streets not joined into longer streets. I have built maps for the entire planet. That is the only place that I found that had that problem. The solution was to build Africa using a max nodes value of about 600 thousand nodes as you did, which brought the number of ways down sufficiently to avoid the problem in mkgmap. If splitter had an option to limit the number of nodes, then splitter would have divided the Port Said tile sufficiently that just those tiles would have had to be made small. Randolph J. Herber On 7/31/2020 3:09 PM, valentin3...@gmail.com wrote: Re: Error in Africa? Hi Ticker, hi Gerd, thanks for your attention. I continue to do my experiments. I tried to compile the map from this one 63240201.osm.pbf with and without the --gmapsupp option (of course to an empty output folder). I get the same result on my two FreeBSD servers and my Windows home computer. I am getting this error on all my systems. Command line for testing: java -jar ^ D:\OSM\mkgmap\mkgmap-r4564\mkgmap4564.jar ^ --output-dir=D:\Garmin\test\ ^ --family-name="OSM test %date%" ^ --series-name="OSM test %date%" ^ --overview-mapname="OSM_test" ^ --area-name="OSM Test %date%" ^ --family-id=480 ^ --read-config=./config2018/optionsfile.args ^ --mapname=6308 ^ --style-file=Config2018 ^ --tdbfile ^ --bounds=D:\OSM\mkgmap\boundary\world ^ --road-name-config=./config2018/roadNameConfig.txt ^ --name-tag-list=name:en,int_name,name ^ --code-page:65001 --style-option=code-page=1250 ^ ./config2018/OSM-2018.txt --description="OSM test" ^ --gmapsupp ^ --add-boundary-nodes-at-admin-boundaries=3 ^ D:\OSM\test\63240201.osm.pbf Link to my Style files: https://maptourist.org/osm-garmin/CurrentConfigs/ Earlier I found a way to fix this error when I use the --max-nodes=60 value. But this will produce an extremely large number of tiles! I really don't like this result. The same number of tiles is produced by the splitter when I making a map of the whole of Europe without the --max-nodes option. The compilation of the map of Europe is stable and looks very good without errors. But the original europe-latest.o5m is four times larger than africa-latest.o5m! I see this is an old and complex spiltter problem. I'm just trying to find out how OSM data is causing this error. It is still unpredictable for me. Hi Ticker, hi Valentin my understanding is that the error message from MapSplitter was a false positive because mkgmap reports 0 MapFailedExceptions. The crash with IndexOutOfBoundsException occurs in the final combiner phase for the gmapsupp. It might be caused by an I/O error or a corrupted *.img file. @Valentin: If you didn't already try that I suggest to clear the directory and restart the compilation. If that produces the same IndexOutOfBoundsException please try again without the file 63240201.osm.pbf. Only if that works fine we can be sure that 63240201.osm.pbf is causing the crash. ciao, Gerd Von: mkgmap-dev <[hidden email] > im Auftrag von Ticker Berkin <[hidden email] > Gesendet: Freitag, 31. Juli 2020 17:01 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Error in Africa? Hi Valentin & Gerd @Gerd, have you started looking at this? The initial error is related to the splitting of the tile into subdivisions and is VERY dependent on the size and layout of all map elements in the tile, which will depend on the style and many options as well as the actual OSM input. If not using the default style, can you zip up and post what you are using, also mkgmap command line and options. The exception happens later but is probably a consequence of the split failure. Ticker On Thu, 2020-07-30 at 23:33 +0300, [hidden email] wrote: > Hi all, > My daily compilation of Africa was stopped because error is appear: > SEVERE (MapSplitter): 63240201.osm.pbf: Single item predicted to > exceed subdivision > http://www.openstreetmap.org/?mlat=10.412207=-13.010709=17 > Number of MapFailedExceptions: 0 Exception in thread > "main" > java.lang.IndexOutOfBoundsException: Index: 113, Size: 3 > at java.util.ArrayList.rangeCheck(Unknown Source) > at java.util.ArrayList.get(Unknown Source) > at > uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.ja > va:116) > at > uk.me.parabola.imgfmt.app.map.MapReader
Re: [mkgmap-dev] Changes that I made in a recent set of default style files and the reason I have for making those changes.
Hi, Tinker, Thank you for the timely response. I was going by what the Map Tool Kit manual said. I will make the appropriate adjustments. The remainder of my points in that remain valid. Did you see my point about separating prisons and military areas? Thank you, Randolph J. Herber On 7/29/2020 6:29 AM, Ticker Berkin wrote: Hi Randolph Another thing I forgot to check and mention is that "Find" > "Cities" only shows nearby POI with range 0x0100 .. 0x0d00, ie not 0x0e00 .. 0x1100. Changing to "Search by Name"/"Spell Search", it also finds POI in range 0x0d00 .. 0x1000/ Ticker ___ 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] Misc documentation fixes
The largest two problems are that I have never been able find a means to select a small number of tiles to download into one of my small memory sized devices and the user interface is miserable for any purpose other than an entire mapset and loading it into a device (which I do by USB or memory downloads and neither BaseCamp or MapSource when I want to install and entire mapset). Randolph J. Herber On 6/19/2020 3:02 AM, Mike Baggaley wrote: I suggest that the command arguments page refers to just current or most recent products and that a new web page be used to give information on the range of other products that people like to use, why they might be used in preference to others and where they can be obtained. I have just downloaded QMapShack and it loads my GB map, so I suggest replacing QLandkarte with QMapShack in the command arguments page. Ticker - can you explain what functionality is not available in BaseCamp but is available in MapSource? I haven't found anything, although as I started from BaseCamp I may well have missed something. Cheers, Mike -Original Message- From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] Sent: 16 June 2020 10:49 To: Development list for mkgmap Subject: Re: [mkgmap-dev] Misc documentation fixes Hi Gerd I think mentioning MapSource in the documentation is useful. I had not used it before and found it trivial to install compared with the difficulties there are in installing Basecamp on a Windows 7 machine. Once installed it was simpler and faster than Basecamp and had capabilities close to my eTrex HCx which seem to have been removed from Basecamp and newer Garmin devices. I was also pleasantly surprised that it found my --gmapi maps from the same location as Basecamp uses. I also note that the documentation mentions QLandkarte. This has been discontinued and QMapShack is recommended instead; but from this information I wouldn't remove QLandKarte from the documentation and wouldn't add QMapShack unless it is known to work with mkgmap maps. Ticker On Tue, 2020-06-16 at 08:37 +, Gerd Petermann wrote: Hi Ticker, I like the idea to fix the svn version :) Should work for quite a while... Not sure why you want to add MapSource again to the documentation? It was removed after this discussion: http://gis.19327.n8.nabble.com/License-File-mapid-000-license-txt-tp5 963502p5963711.html Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 15. Juni 2020 18:07 An: mkgmap development Betreff: [mkgmap-dev] Misc documentation fixes Hi Gerd Here are some documentation fixes & improvements + a change to build.xml to use 4 chars for the unknown version number so that offsets match the typical 4 digit svn version number. This minimises noise when comparing the display of internal structures. I can't tell if I've got the layout in typ-compiler.txt correct until it appears on http://www.mkgmap.org.uk/doc/typ-compiler If it looks bad I'll do another patch. Ticker ___ 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] nearby-POI: What to do with several POI arranged on a circle?
Perhaps averaging the latitude and longitude coordinates of all the points separately would work. That is not quite the same as meet in the middle. If the points are evenly spaced around the edge of a circle, even though the latitude and longitude scalings (except at the equator) are not the same. What I believe you are trying to do is minimize the total distance from the selected point to the collection of points. Randolph J. Herber On 5/7/2020 2:42 AM, Gerd Petermann wrote: Hi all, while doing further tests I've found this edge case (see attached file) Draw a circle with a diameter of ~56m and tag all nodes amenity=bank. The default style has amenity=bank [0x2f06 resolution 24] With --nearby-poi-rules=0x2f06:30:merge-at-mid-point one might expect a single POI in the middle of the circle, but the result is different: Since there is no POI near the center of the circle the current algo finds 4 groups, all close to the edge of the circle. I think for merge-at-mid-point I need a different algo. I'm looking at https://en.wikipedia.org/wiki/Cluster_analysis now. Gerd ___ 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] "Small" SRTM1 files and DEM maps
That seems to be bash on linux. Perhaps, this will help. The double
quotes are to handle file names with spaces and the like in them.
$ for tiffile in *.til; do echo gdal_translate -of SRTMHGT "$tiffile"
`basename "$tiffile" .til`.hgt; done
gdal_translate -of SRTMHGT xyz.til xyz.hgt
$ ls
xyz.til
Randolph J. Herber
On 4/16/2020 3:54 AM, Steph wrote:
Hi,
Uggly scripts I use…
- tif2hgt.sh:
for tiffile in *.tif;do
gdal_translate -of SRTMHGT $tiffile $tiffile.hgt;
done
- tif_dim.sh (if .tif downloaded by phyghtmap are "too" small…)
for tiffile in *.tif;do
gdalwarp -of GTiff -srcnodata 32767 -rcs -order 3 -ts 1201 1201
-multi $tiffile $tiffile.TIF;
done
Renaming is not integrated within the scripts… (removing first
extension)
Perhaps the second can help…
On Linux !
@+
Steph
Le 16/04/2020 à 10:18, Gerd Petermann a écrit :
Hi Carlos,
are you talking about geotiff format? I think someone documented how
that format can be converted to *.hgt.
Can you post a link to such a file?
Gerd
Von: mkgmap-dev im Auftrag
von Carlos Dávila
Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps
Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
|| if srtmVersion == 2.1:||
|| return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
|| elif srtmVersion == 3.0:||
|| if resolution == 1:||
|| urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
|| elif resolution == 3:||
|| urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
|| return urlRe|
They should come from the second URL above.
El 13/4/20 a las 8:24, Gerd Petermann escribió:
Hi Carlos,
sorry for the late response. I found no hint on the phyghtmap page
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not
compressed. Do you know from where these 12.4 MB files came from?
Gerd
Von: mkgmap-dev im Auftrag
von Carlos Dávila
Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps
I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and report them as
missing. Would it be possible to get support for such files in mkgmap?
___
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 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] splitter and options --description / --geonames-file
Hi, all, The Definition of Google Plus Codes, a.k.a. Opern Location Codes, can be found at https://en.wikipedia.org/wiki/Open_Location_Code The complete code also specifies, by its length, the size of the area being described. When using them in splitter, I have never seen a tile whose code was longer than 8 characters, an area 250m east to west and 125m north to south. I use the largest OLC centered on the tile in question that fits within the tile. Randolph J. Herber On 4/8/2020 4:59 AM, Ticker Berkin wrote: Hi Gerd I'd say that if the splitter is going to generate descriptions per tile (geonames) it should generate one for each tile and, if there isn't a centre of a city within the tile and no default description, it should use a modified form of the nearest city to make it unique from a possible adjacent tile that might use the same city. Maybe something like "GB-~Basingstoke", but no solution is ideal and there could still be duplicates. The splitter could keep track of which names were have been used and, for the ones outside the tile, added an increasing suffix number, so would have "GB-Basingstoke-2" etc Ticker On Wed, 2020-04-08 at 08:38 +, Gerd Petermann wrote: Hi all, this is a follow up of http://gis.19327.n8.nabble.com/documentation-i mprovement-tp5962609p5962747.html Since I don't use these options for my maps I am unsure what is best. The --geonames-file option tries to find a city within the calculated tile. If none is found it either writes the value given with --description or just a comment. I think it would be best to always write the nearest city. Gerd ___ 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] splitter and options --description / --geonames-file
Hi, all! It would be best if each title has its own, separate identity. Randolph J. Herber On 4/8/2020 3:38 AM, Gerd Petermann wrote: Hi all, this is a follow up of http://gis.19327.n8.nabble.com/documentation-improvement-tp5962609p5962747.html Since I don't use these options for my maps I am unsure what is best. The --geonames-file option tries to find a city within the calculated tile. If none is found it either writes the value given with --description or just a comment. I think it would be best to always write the nearest city. Gerd ___ 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] documentation improvement
Hi, all! This brings up an old topic of mine. Europe is densely populated with many, small villages. Very few tiles, if any, do not contain a village. In other parts of the world, there are areas with low population and no villages with population over 500 (the largest cities file in bytes). I patched splitter to append the Google Pluscode to the area's description. This provides the service that every tile has its own, separate identity within the mapset. Is there any interest in the patch now? Randolph J. Herber On 4/8/2020 2:40 AM, Mike Baggaley wrote: Hi Gerd, please find an updated patch and another for the splitter documentation that describe the current operation. It seems wrong to me for splitter to put the default description in a comment if --geonames-file is used without also specifying --description. This means that a tile that cannot get a suitable value from the geonames file will end up getting the description of the preceding tile. I think that splitter should always output a description to the template.args file when --geonames-file is specified. Regards, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 08 April 2020 06:34 To: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] documentation improvement Hi Mike, I've attached the template.args generated for this command: java -jar d:\splitter\dist\splitter.jar --description=test --max-nodes=10 --geonames-file=f:\osm\cities15000.zip f:\osm\bremen-latest.osm.pbf and java -jar d:\splitter\dist\splitter.jar --description=test --geonames-file=f:\osm\cities15000.zip f:\osm\niedersachsen-latest.osm.pbf Note that the one for Bremen is special because some tiles get the default description given with the --description option. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Mittwoch, 8. April 2020 00:55 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement Hi Gerd & Ticker, Please find an updated patch that includes the essence of your comments on the --description option (I hope). Please let me know if you think further tweaks are needed. Note, I'm not clear on the effect the splitter --geonames-file option has on the description. The splitter documentation only indicates it affects the file names of tiles. Does the splitter documentation need something adding? There is still the question of whether the quote symbols need to be replaced with 'arc seconds' or whether the HTML creation process should be amended. Also, clarification on the 3314/3312 values in --dem-dists. Regards, Mike -Original Message- From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] Sent: 07 April 2020 10:34 To: Development list for mkgmap Subject: Re: [mkgmap-dev] documentation improvement Hi Gerd & Mike @gerd - as you say, it is better to just improve the documentation of what is there. As far as I could see it was only the tiles and gmapsupp that took the --description. I'd suggest changing from: ;--description=text : Set the descriptive text for the map. This may be displayed in QLandkarte, MapSource or on a GPS, where it is normally shown below the family name. Example: --description="Germany, Denmark" Please note: if you use splitter to build a template.args file and pass it to mkgmap, then that file may contain a "description" that will override this option. To prevent splitter from overriding your description, place the --description option after "-c template.args". to: ;--description=text : Set the descriptive text of map components. Map tiles take the most recent --description before the --input-file that defines the tile. gmapsupp.img takes the last --description. Note that the splitter generated template.args includes relevant --description values (see splitter --geonames-file). The usage of the component descriptions is not consistent between GPS devices, MapSource, Basecamp and QLandkarte. Some use the --family-name to enable the complete map, others use the gmapsupp.img description. Some devices can enable individual tiles using the tile description. Suggested usage: ... -c options.cfg -c template.args --family-name=Scandinavia --description=Scandinavia --gmapsupp typFile.txt @mike - if you & Gerd are happy with something like this, do you want to put it into your patch, otherwise I'll do it once your option changes are out of the way. Ticker On Tue, 2020-04-07 at 07:57 +, Gerd Petermann wrote: Hi Ticker, I think this was discussed before and that discussion lead to the chapter about template.args. My suggestion would be to add a hint that the last given description is used by the combiners. I found usage in OverviewBuilder, TdbBuilder, and GmapsuppBuilder, not sure what the other combiners use. NsisBuilder and GmapiBuilder should be checked. I don't like the idea to introduce just another "descriptio
Re: [mkgmap-dev] missing check for option --family-id
Hi, I am not sure about the lower limit of 1. Zero may be acceptable. The upper limit should be checked for as some Garmin receivers have problems with file names\ prefixes longer than eight characters, which comes from the old MSDOS FAT limit of 8 character prefix and 3 character suffix file name format. Randolph J. Herber On 4/7/2020 5:08 AM, Gerd Petermann wrote: Hi all, in the garmin forum there is a discussion about the range : https://forum.openstreetmap.org/viewtopic.php?pid=782395#p782395 The current options.txt says --family-id=integer This is an integer that identifies a family of products. Range: [1..] Default: 6324 This limit is neither checked nor is it correct. The corresponding value is stored in a two byte field and most mkgmap sources interpret it as a 16-bit-unsigned integer. However, in class uk.me.parabola.tdbfmt.HeaderBlock the field is stored in a short (signed 16-bit-int). My conclusion: We should print a warning when the value given in --family-id is < 0 or > 32767. Gerd ___ 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] North Arrow on Garmin Devices
The arrow occurs on Garmin provided maps also. It is generated by the operation of the device. I have more than a dozen Garmin devices. All generate a North arrow of some form. The direction of the arrow on the device depends on a number of factors: has the device moved since it was turned on and in what orientation was it instructed to present the map. On 4/2/2020 3:05 PM, Pitney wrote: Hello Displayed on my Garmin devices with maps made with mkgmap is a North arrow that is beige in color. Not highly visible and I use the North arrow allot. I want to change this to a red arrow so that it is more visible. Is this possible via the .typ file or is this a firmware setting? I have searched but it seems I am the only one interested in this change. Thanks Pitney ___ 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] cities*.zip extract error
The fact that cities15000 is smaller than cities500 is both reasonable and normal. There are more cities with a population 500 or more than there are cities with a population of 15 000 or more. It is reasonable that the compressed versions of these file have the same relationship. On 4/2/2020 12:42 PM, DD8KQ wrote: Seems to be an error with all of the cities zip files. Also, if you look at the size of the files, there was something strange, because cities15000 is smaller in size than cities500 Am 02.04.2020 um 18:56 schrieb Steph: Hi, Have you got an error extracting cities*.zip files from http://download.geonames.org/export/dump/ since today ? $ unzip cities15000.zip Archive: cities15000.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of cities15000.zip or cities15000.zip.zip, and cannot find cities15000.zip.ZIP, period. So java (splitter) crash on this file… Regards Steph ___ 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] New branch for default typ file
Dear Sirs:
There has been a thread of discussion of whether there should be a
/Beginning Of Message/ /(BOM)/ at the beginning of a UTF-8 file.
This discussion is complicated by the fact that some of the developers
work on Unix, Linux, BSD, iOS, Solaris and Windows. These operating
systems have UTF-8 handling libraries written at different times and to
different Unicode standards. Originally the Unicode standard said that
UTF-8 should *not* have a BOM character at the beginning of a file.
Later Unicode changed the standard to a BOM is permissible, not required
and not recommended. Microsoft added a BOM to the beginning of UTF-8
files before doing so was permissible to ease the problem of recognizing
a UTF-8 file. This broke the other operating systems' handling of UTF-8.
Microsoft petitioned for the permissibility of a BOM to avoid changing
their file handling.
At this time, I believe at all programs should use Unicode and not
Microsoft code pages. I have had problems with Microsoft code pages
since MSDOS days.
Splitter and mkgmap are written in Java. Java still follows the original
Unicode standard of no BOM at the beginning of a UTF-8 text file. This
is a "not to fixed" situation per the Java language developers. This
situation results in problems with Java, particularly in a Microsoft
Windows environment,
The code fragments below provide Java solutions to writing a BOM at the
beginning of a UTF-8 text files so that Microsoft native text editors
can handle them and, on reading a text file, provides a automatic way of
ignoring an optional BOM by checking for the BOM after file opening.
A test for execution in a Windows environment is provided below if one
decides to add a BOM only on Microsoft Windows.
I have not downloaded the splitter and mkgmap sources and searched for
the appropriate places in their sources to apply the changes. I feel the
main splitter and mkgmap developers are placed better to make these
changes. This is the reason that I did not provide patches to the sources.
Randolph J. Herber.
On 12/14/2019 9:44 AM, Randolph J. Herber wrote:
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
<https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Intl/using-byte-order-marks.md>
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 c
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
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
Re: [mkgmap-dev] Please test branch NET-no-NOD
There is an area like that is the older part of Port Said near Cairo, Egypt, that blows up map making in mkgmap. Examine the area in the vicinity of 31.0755N 32.2661E. There are many single block streets. This causes problems as there is no parameter setting a limit on the number of ways similar to the parameter setting a limit on the number of nodes in a tile. In this area, there are almost half as many ways as there are nodes. Perhaps, after the initial tile split in splitter, if the number of ways is excessive, just that tile could be split until the number of ways becomes "reasonable." Randolph J. Herber On 10/18/2019 9:28 AM, Ticker Berkin wrote: Hi Gerd That runs OK. As before, I get lots of 2 node roads - often bridges over streams in open land, and quite a few (about 1/10 the number of the 2 noders) are 3 and 4 nodes - frequently paths between buildings in schools / campuses and short bits of path at either end of the bridges in open land. I upped the test from 5 to 10 and got more of the same + networks of short paths on golf courses, walkways on piers (which should have been connected to something), paths in an enclosed quadrangle, etc, etc All of these I would consider to be a hindrance to route calculations. Having an option, defaulting to, say, 10, to stop these road-islands being added to NOD must be a good idea. Setting the value to 0 would give the current behaviour Ticker On Fri, 2019-10-18 at 12:35 +, Gerd Petermann wrote: Hi Ticker, here is the patch without recursive call. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Freitag, 18. Oktober 2019 12:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Please test branch NET-no-NOD Hi Ticker, thanks for testing. I'll work on a patch without recursive calls. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Freitag, 18. Oktober 2019 12:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Please test branch NET-no-NOD Hi Gerd I've applied the patch to my 'current' version and tried running it but it gives: java.lang.StackOverflowError at uk.me.parabola.imgfmt.app.net.RouteNode.visitNet(RouteNode.java:938) at uk.me.parabola.imgfmt.app.net.RouteNode.visitNet(RouteNode.java:941) ... 1020 lines like this ... at uk.me.parabola.imgfmt.app.net.RouteNode.visitNet(RouteNode.java:941) at uk.me.parabola.imgfmt.app.net.RouteNode.visitNet(RouteNode.java:941) Exiting - if you want to carry on regardless, use the --keep-going option My source had the patches "avoid-to-split-via-ways.patch" and "only_with_via_ways.patch". I can remove these and try again if you think there might be an interaction. I don't think there is a need to try and check on islands of different access modes; the apparent behaviour of my device is that it finds the closest highway of any type to get into or out of the main road network. ie, if here is a footpath closer to the destination that any motor-vehicle road, car route planning will direct me onto it. Ticker On Fri, 2019-10-18 at 09:25 +, Gerd Petermann wrote: Hi Ticker, please check: attached is a simple patch that implements the calculation of routing islands. It just reports islands with less than 5 routing nodes and the position of one of the nodes. It ignores such islands which have at least one node that is a boundary node. Remember that we also create nodes oncountry borders. Maybe those should be ignored here? A more detailed test might also check the access attributes, so that we report islands for pedestrian, bicycle etc. The patch doesn't change the data written to the img files. Please play with it and let me know how it works for you. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 12. Oktober 2019 19:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Please test branch NET-no-NOD Hi Gerd I was thinking of a threshold (maybe < 5) and then not adding any of them to NOD. The reason is that a while ago I found many instances where tracks lead up to the edge of car-parks but didn't join to each other or the car -park access road and so walking routing, where one was expected to cross the car-park, didn't work. I tried adding a footway around the edge of the car-park and this helped in a lot of cases but I got driving route-calculation-error in or out of the car-park if the access road wasn't correctly specified. Your latest change will help in a lot of instances but sometimes there car-park was defined by more than 1 line. Ticker On Sat, 2019-10-12 at 10:10 -0700, Gerd Petermann wrote: Ticker Berkin wrote Do you attempt to isolate small road networks that are not connected to the rest of the system or just a single road? Not yet. Do you think about some kind of threshold value giving the minim
[mkgmap-dev] A minor, documentation only change request
This request may cause changes in many places; but, no changes to mkgmap behavior. It took me close to five years to learn what really was meant by: " but the lowest usable resolution with MapSource seems to be 11." in --overview-levels. I suggest a change to " but the lowest usable resolution (coarsest scale, smallest scale number) with MapSource seems to be 11." I had interpreted that the numbers to the right of the colon had to be 11 or smaller numerically. Randolph J. Herber ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile
Dear Sirs: My definition of "ways" was requested. Splitter first scans nodes (points of various kinds), then ways (forming lines, paths and polygons) and finally relations (container polygons for any or all of nodes, ways or relations). I was using "ways" in the same sense that I understand that splitter uses "ways" in its messages. I hope this helps. --maxnodes sets a soft upper limit on the number of nodes in a map tile. I am requesting a similar in concept --maxways to set a soft limit on the number of ways in a map tile. Randolph J. Herber On 5/21/2018 12:27 PM, Andrzej Popowski wrote: > Hi Randolph, > > what do you mean by "ways"? Any line, road with an address, road used > for routing? I don't remember if I ever spotted similar problem. > > On the other side, I think splitter can be better tuned for current > mkgmap. I get impression, that splitter is designed to make a good > work with simple maps and doesn't account for addresses, routing nodes > od DEM data. It would be nice, if there were more options, than maxnodes. > > For my maps, I split OSM data in two stages. First I prepare > artificial data, that I believe represent better actual size of > compiled tiles. > > I extract addresses as points and highways as simple 2-points lines (I > do it with modified osmfilter). Then I make splitter to calculate all > tiles using as an input following data: > - OSM source > - 0-2 times extracted addresses > - 6-10 times extracted highways > - 1-2 times contour lines > > I believe, that additional points form address account for some NET > size, points form highways for additional NOD size and duplicated > contour lines for DEM size. It needs some tuning for different areas, > but I think I get a bit more uniform sizes of img than with direct > splitting. > > On second stage I use prepared areas.list to split real data. > > Basically I do something like this: > > osmfilter.exe data.o5m --keep= --keep-ways=highway=* -o=net.o5m > osmfilter.exe data.o5m --keep= --keep-nodes=addr:housenumber=* -o=adr.o5m > > splitter.jar --stop-after=split --max-nodes=300 data.o5m net.o5m > net.o5m net.o5m net.o5m net.o5m net.o5m net.o5m net.o5m adr.o5m > adr.o5m contour.pbf contour.pbf > > splitter.jar --split-file=areas.list data.o5m contour.pbf > > It would be helpful, if I could do it in a single pass. Maybe splitter > could filter internally specific nodes - these which would end as > routing nodes or address information and add some multiplier when > counting these nodes for splitting? Assuming this is easy to > implement, otherwise my procedure is good enough. > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile
Dear Sirs: I have been trying to build a World map for use in Garmin's Mapsource. I have encountered cases where tiles had too many ways (also polygons and relations) for Mapsource to handle, even though the tile had a sufficiently small numbers for Mapsource. This is because the area had a large number of ways with only begin and end nodes. I can constrain the number of ways, etc., by constraining the number of nodes severely. This causes many more tiles. Above 2025 tiles in a map, Mapsource appears to fail. This code should parallel the code for maxnodes. Randolph J. Herber ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Proposed change to splitter to make tile names unique
Dear Sirs:
I propose adding the following to uk.me.parabola.splitter.AreaList.java:
*** AreaList-old.java 2019-05-20 11:28:45.739455200 -0500
--- AreaList.java 2018-05-11 20:01:47.861375200 -0500
***
*** 280,286
cityFinder = new DefaultCityFinder(cities);
}
for (Area area : getAreas()) {
! area.setName(description);
if (cityFinder == null)
continue;
--- 280,286
cityFinder = new DefaultCityFinder(cities);
}
for (Area area : getAreas()) {
! area.setName(description + "-" + openLocationCode(area));
if (cityFinder == null)
continue;
***
*** 350,354
--- 350,401
}
}
+ private static final String codes = "23456789CFGHJMPQRVWX";
+ private static String openLocationCode(Area area) {
+ return openLocationCode(
+ Utils.toDegrees(area.getMinLat()),
+ Utils.toDegrees(area.getMinLong()),
+ Utils.toDegrees(area.getMaxLat()),
+ Utils.toDegrees(area.getMaxLong()));
+ }
+
+ private static String openLocationCode(
+ double south,double west,double north,double east) {
+ double centerLatitude = 0.5 *(south + north)+90.;
+ double centerLongitude = 0.5 * (west + east)+180.;
+ double boxHeight = north - south;
+ double boxWidth = east - west;
+ double height = 400.;
+ double width = 400.;
+ String code = "";
+ boolean done = false;
+ while(code.length() < 8 & !done) {
+ int p;
+ height /= 20.;
+ width /= 20.;
+ p = (int)Math.floor(centerLatitude/height);
+ code += codes.charAt(p);
+ centerLatitude -= p * height;
+ p = (int)Math.floor(centerLongitude/width);
+ code += codes.charAt(p);
+ centerLongitude -= p * width;
+ done = width <= boxWidth && height <= boxHeight;
+ }
+ if(!done) {
+ code += "+";
+ while(!done) {
+ int la, lo;
+ height /= 5.;
+ width /= 4.;
+ la = (int)Math.floor(centerLatitude/height);
+ centerLatitude -= la * height;
+ lo = (int)Math.floor(centerLongitude/width);
+ centerLongitude -= lo * width;
+ code += codes.charAt(5*la+lo);
+ done = width <= boxWidth && height <= boxHeight;
+ }
+ }
+ return code;
+ }
}
The purpose is to give each tile an unique name by appending the Open
Location Code of the largest region (shortest code) that fits within the
tile. I have been using this code myself.
https://en.wikipedia.org/wiki/Open_Location_Code
Randolph J. Herber
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Erroneous error message
Dear Sirs:
The code and the error message do not agree:
if (value <= 0 || value > 24)
throw new ExitException("Error: Resolution value out of range 0-24:
" + s + " in levels specification " + levelSpec);
Randolph J. Herber
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
