Re: [mkgmap-dev] overview map
I'd also like to thank everyone involved in implementing this feature. I have not yet tried the new overview map on a device, but I can confirm that map display is considerably faster in Basecamp on Mac OS X. In addition, the overview map makes the selection of map tiles in MapInstall far far easier (used to transfer the selected map tiles to a GPS device). Excellent work. Cheers. On May 31, 2013, at 4:44 PM, Steve Ratcliffe wrote: > This is great news. The overview map was one of the biggest deficiencies in > mkgmap until now. > > So thanks to Gerd and well done. > > Also a lot of bugs have been fixed along the way, so I would like to > acknowledge that too. > > I will put up a news item on the website this evening and push out notices to > freecode. > > ..Steve > > > > GerdP wrote: > Hi all, > > finally I've merged r2629 into trunk. > > A brief description of the changes: > 1) new or changed options > --overview-levels > like levels, specifies additional levels that are to be written to the > overview map. Counting of the levels should continue. Up to 8 additional > levels may be specified, but the lowest usable resolution with MapSource > seems to be 11. > > --remove-ovm-work-files > If overview-levels is used, mkgmap creates one additional file > with the prefix ovm_ for each map (*.img) file. > These files are used to create the overview map. > With option --remove-ovm-work-files=true the files are removed > after the overview map was created. The default is to keep the files. > > --polygon-size-limits=limits code > Allows to specify different min-size-polygon values for each resolution. > Sample: > --polygon-size-limits="24:12, 18:10, 16:8, 14:4, 12 > :2, > 11:0" > If a resolution is not given, mkgmap uses the value for the next higher > one. For the given sample, resolutions 19 to 24 will use value 12, > resolution 17 and 18 will use 10, and so on. > Value 0 means to skip the size filter. > Note that in resolution 24 the filter is not used. > > 2) Optimizations: > - The polygon filter allows larger polygons. > - SeaGenerator generates fewer "sea-only" and "land-only" polygons when > precomp-sea is used. > Both reduce the img size, esp. for maps containing large "sea only" areas. > > 3) Changes regarding styles: > - The support for the out-aged map-features.csv file was removed > - Level ranges can now use min-max or max-min > - Usage of polygon type 0x4a will be flagged with --check-styles > > 4) Other changes > - A few checks are performed regarding the plausibility of the given options > and input files > to help beginners. > > > > > < > br > /> > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/overview-map-tp5763471.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] Precompiled sea
On May 18, 2012, at 12:38, WanMil wrote: > sorry, my fault. I made some changes to the loader and didn't test it again > with pbf. One required method was missing for PBF... > > Attached patch should fix that. Thanks a lot WanMil! This works much better. I'm getting good results with the Europe extract. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] Precompiled sea
On May 17, 2012, at 21:27, WanMil wrote: > I have added the index like Gerd proposed. The number of files is now reduced > by 90%. > > I have uploaded new precompiled files to > http://www.navmaps.eu/wanmil/sea_20120331.zip Hi WanMil, I tried patch v4 and the new precompiled sea files on the Geofabrik extract of Europe. I got a lot of NPE errors such as below. Can I do anything to help? I've included an example from the logfile as well. It appears that src.getElementSaver().getWays() is null in the loadPrecompTile method. Logfile example: 2012/05/18 10:48:24 INFO (SeaGenerator): 2301.osm.pbf: Load precompiled sea tiles 2012/05/18 10:48:24 INFO (SeaGenerator): 2301.osm.pbf: Started loading coastlines from /Users/clinton/dev/mkgmap/styles/sea/sea_1998848_163840.osm.pbf 2012/05/18 10:48:24 INFO (SeaGenerator): 2301.osm.pbf: Finished loading coastlines from /Users/clinton/dev/mkgmap/styles/sea/sea_1998848_163840.osm.pbf 2012/05/18 10:48:24 SEVERE (SeaGenerator): 2301.osm.pbf: java.lang.NullPointerException 2012/05/18 10:48:24 INFO (SeaGenerator): 2301.osm.pbf: Started loading coastlines from /Users/clinton/dev/mkgmap/styles/sea/sea_1998848_196608.osm.pbf 2012/05/18 10:48:24 INFO (SeaGenerator): 2301.osm.pbf: Finished loading coastlines from /Users/clinton/dev/mkgmap/styles/sea/sea_1998848_196608.osm.pbf 2012/05/18 10:48:24 SEVERE (SeaGenerator): 2301.osm.pbf: java.lang.NullPointerException java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.loadPrecompTile(SeaGenerator.java:342) at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.addPrecompSea(SeaGenerator.java:428) at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.end(SeaGenerator.java:562) at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingHooksChain.java:79) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:68) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:144) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:210) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:207) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Precompiled sea
On May 3, 2012, at 23:55, WanMil wrote: > I have already found a few tiles with flooding (e.g. NE of Russia). I > have to investigate that. But I will be happy if you find some other > things :-) I've also been testing a little bit. So far the results have been pretty good. One point I'm not sure on is how the --precomp-sea option should work together with the other coastline related options. - I assume that the --coastlinefile is now redundant, correct? - What about the various --generate-sea parameters? I currently use the following when compiling: --generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000,floodblocker Are most or all of these parameters now redundant? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Precompiled sea
On Apr 29, 2012, at 22:07, WanMil wrote: > attached patch uses precompiled sea files to generate the sea areas. Hi WanMil, Thanks for doing this. This seems like a quite promising approach. I'll try to test it in the next few days. Coincidentally, I noticed a blog entry from Joachim Topf, where he describes work on his OSMCoastline code, which extracts coastline data and renders sea polygons: http://blog.jochentopf.com/2012-03-07-osm-coastlines.html I don't know if any of this is relevant, especially if you are now using the precompiled Mapnik sea areas. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
On Oct 22, 2011, at 17:24, Marko Mäkelä wrote:
> I have seen it when the way closest to the destination point in the
> mkgmap-generated map is part of a "routing island". I guess that we
> should consider translating highway=pedestrian as ways (not areas) in
> the default style, to fix this problem.
I think this was discussed previously on the list. The preferred solution at
the time was to add an additional way around the outside of the pedestrian area
while preserving the original pedestrian area.
I have the following in my lines file:
highway=pedestrian & area=yes {add access = no; add foot = yes} [0x0d
road_class=0 road_speed=0 resolution 22 continue]
And the usual highway=pedestrian & area=yes in my polygons file.
This has some limitations (as pedestrians will always be routed along the
perimeter of a pedestrian area) but at least the routing works.
Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Coastline issues - analysis and possible solution
On Oct 1, 2011, at 10:39, Bartosz Fabianowski wrote: > No problem. I have a batch job running that uploads fresh coastlines to > [1] every day. I will move this to our company webspace somewhere > underneath [2] eventually. > > - Bartosz > > [1] http://fabianowski.eu/osm/coastlines/ By the way, I just used your planet extract with the --coastlinefile option for a map of Canada (Geofabrik extract). The results were vastly superior compared to the same map compiled without the coastline file. Thanks very much for your analysis and for providing the coastline data. I hope you continue to do so. :-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Highway shields
On Sep 5, 2011, at 0:43, Francisco Moraes wrote:
> Does mkgmap support all possible highway shields that Garmin supports?
> Is there any documentation on how to use them to achieve the US highway
> symbols and some of the state symbols as well?
This is what I have from a previous response. It should still be valid:
You need to add highway-symbol prefixes to your lines style file. Example:
highway=motorway {name '${ref|highway-symbol:hbox} ${name}' |
'${ref|highway-symbol:hbox}' | '${name|highway-symbol:hbox}'
>From the source code, these are the possible values for highway shields:
"interstate" // US Interstate
"shield" // US Highway shield
"round" // US Highway round
"hbox" // box with horizontal bands
"box"; // Square box
"oval" // box with rounded end
The US symbols display only numeric values (e.g., "1", "401", etc).
The others are alphanumeric (e.g. "A5").
Cheers
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Amenity=shelter
On Jul 2, 2011, at 9:54, Peter Hendricks wrote: > This discussion has nothing to do with polygons. I don't know what any > of these codes are used for, nor do the users of the maps care. You know, if you are unsatisfied with the default POI mapping, you are free to define your own. This is what I and a lot of others have been doing for quite some time. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cannot search for street/address when sending to device via Mac Garmin MapInstall
On Jun 14, 2011, at 13:26, maning sambale wrote: > I installed the map to mac RoadTrip. I can search > for streets using roadtrip. But when I send the maps to my nuvi 1310 > using Garmin's MapInstall, I can't search for streets anymore. In > nuvi, "Where to" > "Address" then a message will appear "No Map Data > Available". I installed your map on my Mac and viewed it using the latest BaseCamp beta[1]. When I attempted to search for addresses, BaseCamp immediately indicated that address searches were not supported by the map. I then tried a quick recompile of the Philippines extract from Geofabrik with the latest locator build, and could at least search for addresses in BaseCamp. Therefore I would assume there is something in your compilation chain which is causing this problem. What splitter/mkgmap/gmap-builder options do you use? Cheers. [1] http://www8.garmin.com/support/download_details.jsp?id=5285 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with gmapi-builder
Hi maning, The following should be the correct command line: On Jun 3, 2011, at 7:34, maning sambale wrote: > python gmapi-builder.py -v -t for_mapsource/4001.tdb -b > for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i > for_mapsource/4001.mdx -m for_mapsource/4001_mdr.img > for_mapsource/*.img The error which is being reported is caused by an unknown sequence of bytes at the end of the 4001.tdb. However the .gmapi file seems to be compiled correctly despite this. I was able to install and view the resulting map. So the error appears (at least superficially) to be harmless. Can you try and see if the .gmapi file works for you and your users? If so, you could simply remove the -v option from the command line, and the error will not be reported. In case anyone is interested, this is the series of bytes at the very end of the tdb file which cause the problem: 00 00 E4 00 00 00 00 00 00 56 00 00 A9 00 00 00 00 D5 00 00 This comes after the information for the last img file. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index and equally named cities
On Jun 2, 2011, at 16:12, Martin wrote: > I use the following commands: > python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s ./master/basemap.TYP > -i osmmap.mdx -m osmmap_mdr.img osmmap.img 63240*.img osmmap_mdr.img I compared the output from gmapi-builder with that produced by Garmin's MapConverter program: they appear to be identical. Perhaps you could do the following to help isolate the problem: - Run Garmin's MapConverter on the map which you created on your Windows machine. - Install the resulting gmapi map on your Mac OS machine. - Does the problem still occur? If so, it may be a general problem with converting maps to gmapi format, or (perhaps more likely) it could be a problem in Garmin's Mac OS programs (MapInstall, Basecamp, etc.). - Which versions of MapInstall and Basecamp do you have on your Mac? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with gmapi-builder
Hi maning, I'm pretty sure that there is an error in your command line. I was able to compile the map properly with the following: python gmapi-builder.py -v -t for_mapsource/4001.tdb -b for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i for_mapsource/4001.mdx -m for_mapsource/4001_mdr.img for_mapsource/*.img -> Note that I changed the last line of your command from "for_mapsource/4001.img for_mapsource/*.img" to just "for_mapsource/*.img". The extra "for_mapsource/4001.img" was causing the program to attempt to add that file twice, which caused the failure. Cheers. P.S.: Your map looks really nice, by the way. :-) On May 31, 2011, at 5:44, maning sambale wrote: > Dear Clinton, > > I tried splitting the map and I get this error: > python gmapi-builder.py -v -t for_mapsource/4001.tdb -b > for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i > for_mapsource/4001.mdx -m for_mapsource/4001_mdr.img > for_mapsource/4001.img for_mapsource/*.img > Unknown Block: 54, length: 20, > '\x00\x00\xe4\x00\x00\x00\x00\x00\x00V\x00\x00\xa9\x00\x00\x00\x00\xd5\x00\x00' > TDB Version:4.07 > Product ID: 1 > Family ID: 639 > Map Series: OSM_PHIL > Map Family: OSM_PHIL > Product Version:1.00 > > Copyright: OSM Street map > Copyright: http://www.openstreetmap.org/ > Copyright: Map data licenced under Creative Commons > Attribution ShareAlike 2.0 > Copyright: http://creativecommons.org/licenses/by-sa/2.0/ > Copyright: Map created with mkgmap-r1867 > Copyright: Program released under the GPL > > Trademark: Test preview map > > Overview map: >Map Number: 6324 >Parent Map: 0 >Latitude North: 21.4893 >Longitude East: 127.3535 >Latitude South: 4.5264 >Longitude West: 116.3672 >Description:Overview Map > > Processing for_mapsource/4001.img > Processing for_mapsource/4001.img > Traceback (most recent call last): > File "gmapi-builder.py", line 576, in >imgfile.dump(imgoutput) > File "gmapi-builder.py", line 409, in dump >os.mkdir(output_dir) > OSError: [Errno 17] File exists: > './OSM_PHIL.gmapi/OSM_PHIL.gmap/OSMTiles/4001' > > > The imgs are available for testing here: > http://dl.dropbox.com/u/607635/osm-ph_gps_maps/dev/for_gmapi_test.zip > > The largest img is ~20MB. > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index and equally named cities
On Jun 2, 2011, at 16:12, Martin wrote: > I couldn't find any version in the file, so I attached the file. Thanks, I'll take a look and see if I can find anything. Right now I'm comparing the output produced by Garmin's MapConvert with that of gmapi-builder. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index and equally named cities
On Jun 2, 2011, at 15:49, Martin wrote: > I've made a map on a Windows-Machine, using the same files I used on my > Macbook and the nsis-compiler... And now it works... > Damn... So the problem comes from the gmapi-builder. > Anyone here who understand python to fix this problem?! > And sorry for bothering you with this problem. I've never expected that the > problem comes from gmapi. Which version of gmapi-builder are you using? Please also send the command lines you use. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index and equally named cities
On May 30, 2011, at 23:23, Steve Ratcliffe wrote: > The attached patch seems to work better. > > ..Steve > This patch appears to be identical to the first one, with the exception of an empty src/uk/me/parabola/imgfmt/app/mdr/Mdr20.java patch. Did something happen to the patch file, or am I missing something? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with gmapi-builder
The other thing we noticed was that individual files which get too large can also fail. Is it possible to try with smaller map tiles? Or can I download your img files to reproduce the error? Cheers On May 19, 2011, at 4:29, maning sambale wrote: > Clinton, > > I used your attached script and the result is the same: > python gmapi-builder -v -t for_mapsource/4001.tdb -b > for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i > for_mapsource/4001.mdx -m for_mapsource/4001_mdr.img > for_mapsource/4001.img for_mapsource/*.img > Unknown Block: 54, length: 20, > '\x00\x00\xa7\x00\x00\x00\x00\x00\x00\xa2\x00\x00\xab\x00\x00\x00\x00\xfc\x00\x00' > TDB Version:4.07 > Product ID: 1 > Family ID: 639 > Map Series: OSM_PHIL > Map Family: OSM_PHIL > Product Version:1.00 > > Copyright: OSM Street map > Copyright: http://www.openstreetmap.org/ > Copyright: Map data licenced under Creative Commons > Attribution ShareAlike 2.0 > Copyright: http://creativecommons.org/licenses/by-sa/2.0/ > Copyright: Map created with mkgmap-r1867 > Copyright: Program released under the GPL > > Trademark: Test preview map > > Overview map: >Map Number: 6324 >Parent Map: 0 >Latitude North: 21.5771 >Longitude East: 127.7930 >Latitude South: 4.5264 >Longitude West: 115.6201 >Description:Overview Map > > Processing for_mapsource/4001.img > Processing for_mapsource/4001_mdr.img > MDR file > Processing for_mapsource/63240001.img > Missing part: 0 of > S?.ϻ in IMG-file. > > > On Thu, May 19, 2011 at 3:21 AM, Clinton Gladstone > wrote: >> OK, That Wiki version is missing some things, such as index file support and >> latin-1 encoding. >> >> Try the attached file: It's a version which I sent to this list a few months >> ago. >> >> I'll try to update this version in a few days to include the TYP file fix >> from the Wiki too. >> >> Here's an example command line call, which includes index files: >> >> $ gmapi-builder.py -t 1400.tdb -b 1400.img -s 14.TYP -i 1400.mdx >> -m 1400_mdr.img *.img >> >> >> >> >> Cheers. >> >> >> On May 18, 2011, at 4:57, maning sambale wrote: >> >>> Here: >>> http://bitbucket.org/berteun/gmapibuilder/downloads/gmapi-builder.tar.gz >>> as stated here: >>> http://wiki.openstreetmap.org/wiki/Gmapibuilder/New_version >>> >>> On Wed, May 18, 2011 at 2:01 AM, Clinton Gladstone >>> wrote: >>>> On May 17, 2011, at 14:34, maning sambale wrote: >>>> >>>>> I downloaded the latest gmapi-builder and tried the following: >>>> >>>> Where did you download this? I made some corrections, but I'm not sure if >>>> they are in the version you downloaded. >>>> >>>> Cheers. >>>> >>>> ___ >>>> mkgmap-dev mailing list >>>> mkgmap-dev@lists.mkgmap.org.uk >>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>>> >>> >>> >>> >>> -- >>> cheers, >>> maning >>> -- >>> "Freedom is still the most radical idea of all" -N.Branden >>> wiki: http://esambale.wikispaces.com/ >>> blog: http://epsg4253.wordpress.com/ >>> -- >>> ___ >>> 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 >> > > > > -- > cheers, > maning > -- > "Freedom is still the most radical idea of all" -N.Branden > wiki: http://esambale.wikispaces.com/ > blog: http://epsg4253.wordpress.com/ > -- > ___ > 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] problems with gmapi-builder
On May 17, 2011, at 14:34, maning sambale wrote: > I downloaded the latest gmapi-builder and tried the following: Where did you download this? I made some corrections, but I'm not sure if they are in the version you downloaded. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
On May 2, 2011, at 21:46, WanMil wrote: > > So r1935 has fixed the bug. The compiled boundaries need not be > downloaded again. Additionally I committed the changes in the trunk up > to r1932. So far my tests with r1935 have been quite good. I do have one issue though: when I send the maps to a GPS device (Nüvi or eTrex), if there are several towns with the same same, the GPS device will only list one. Example: Walldorf in Germany. There is a Walldorf in Gross-Gerau, Rhein-Neckar-Kreis, and Schmalkalden-Meiningen. The GPS allows only Walldorf, Schmalkalden-Meiningen to be selected. The streets of the "other" Walldorf seem to be listed under this Walldorf, but the GPS cannot display them on the map. - The addresses are found correctly using Basecamp for Mac OS. - I send the maps to my devices using Garmin's MapInstall for Mac OS. Can anyone reproduce this? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
On May 1, 2011, at 21:50, WanMil wrote: > I have also errors in a boundary file. Something seem to be wrong with > the write or the reader. I am checking that... I just updated to SVN revision 1935: the malformed input error has not yet reappeared. You may have caught the error here. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
On May 1, 2011, at 19:54, WanMil wrote: > The European boundaries now compiled with the correct osmosis settings > are available for download: With the new set of boundaries, I now get the following error in the log: 2011/05/01 21:37:31 SEVERE (BoundaryUtil): 9403.osm.gz: Cannot load boundary file bounds/bounds_210_25.bnd: java.io.UTFDataFormatException: malformed input around byte 346 It's now a different file, and a different byte. :-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
On Apr 30, 2011, at 15:13, WanMil wrote: > Could you please try to run the BoundaryFile2Gpx converter for this > boundary file? > > Does it throw the same error? I am not sure if I there is a problem with > the big- and little-endian order on Mac versus PC? The converter does not produce an error. I get the following output: true false bounds_205_10.bnd Start converting bounds_205_10.bnd 318 boundaries loaded Finished bounds_205_10.bnd (Since I am using an Intel Mac there should not be an endian problem.) I'll see if I can narrow down the problem on my side. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
On Apr 30, 2011, at 13:43, WanMil wrote: > 1. Maybe the boundary utils are not thread safe. Do you use more than > one thread? I still get the error with only one thread. By the way, I'm on Mac OS with Java version "1.6.0_24" (64 bit), if that's any help. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
On Apr 30, 2011, at 13:43, WanMil wrote: > 1. Maybe the boundary utils are not thread safe. Do you use more than > one thread? Yes, I do. I'll try it in single threaded mode. Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
On Apr 30, 2011, at 8:51, navmaps wrote: > The European boundaries compiled by WanMil are available for download: > http://www.navmaps.eu/wanmil/europe_bounds_20110429.zip Thanks for uploading the file. Regarding the boundary function, when I compile, I notice a few errors in the log file for bounds_205_10.bnd: 2011/04/30 10:29:20 SEVERE (BoundaryUtil): 9401.osm.gz: Cannot load boundary file bounds/bounds_205_10.bnd: java.io.UTFDataFormatException: malformed input around byte 250 Is there a bad character compiled into this file? It seems to function correctly otherwise. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
On Apr 25, 2011, at 19:21, WanMil wrote: > I have committed changes to the locator branch which implements the > usage of separate precompiled splitted boundary files. This seems like a quite plausible approach. I'll try it out. By the way, for others who attempt this, there were a few typos in WanMil's original osmosis command line. The following seems to be working for me: osmosis --rb europe.osm.pbf --tf accept-ways boundary=admistrative --tf accept-relations boundary=administrative --used-node --wx europe-boundaries.osm Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Prefer multiples of 2048 as cut coordinates in multipolygons
On Apr 3, 2011, at 21:20, WanMil wrote: > Please test it soon. I plan to commit that within the next 2 days if noone > complains about it. I've also done some initial testing and have not found any issues so far. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Converting mkgmap generated maps to Mac format (was Index branch - success!)
On Feb 21, 2011, at 19:56, Carlos Dávila wrote: > I still have problems converting one of my maps: > python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-38.TYP > -i osmmap.mdx -m osmmap_mdr.img 553800*.img osmmap.img osmmap_mdr.img The second file, 55380002.img, appears to have an error. (in the internal FAT table?) At byte x600, there should be a filename, such as 55380002RGN. Instead it is blank. -> I don't know enough about the internal file structure to say. It could also potentially be the case that the blank entry at x600 should be skipped, and the next entry at x800 should be read. Does anyone else know? This is perhaps caused by the very large file size of 55380002.img; it is about 30 Mb. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dropping place:village, hamlet, suburb in city search
On Feb 19, 2011, at 12:14, Chris66 wrote: > I'm a littlebit amused that nobody seems to fully understand > the location-autofill algorithm. ;-) Well, I've been casually going through it, but I don't have much time. There are some interesting things there, including special handling for Germany, Switzerland, and Austria, as these countries seem to have good geonames coverage. Or something. :-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dropping place:village, hamlet, suburb in city search
On Feb 19, 2011, at 7:08, maning sambale wrote: > Any suggested hexcode to use for place:village,hamlet,suburb in city > search that will make it searcheable as a POI but not in the current > city search? I haven't yet had a thorough look at the code here, but from what I've seen, I get the impression that the POI hex codes in the style file have no effect on address search. I think the OSM pace tagging may be directly used for indexing. I could be wrong though. :-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Patch: Add Ireland to LocatorConfig.xml
On Feb 16, 2011, at 14:20, Henning Scholland wrote: > I think it would be better, if this file would be external, so every > user could edit this file. If you place LocatorConfig.xml in a sub-directory called "resources" in the same directory where you process the osm files (i.e., the directory where you call mkgmap from the command line), then this file will be used instead. That way, you can easily add your own country data without recompiling. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Converting mkgmap generated maps to Mac format (was Index branch - success!)
I have now compared the gmapi-builder linked from the Wiki with the one we have in the SVN repository. - The Wiki version includes a minor fix, which ensures that file names are upper-cased (usually not a problem). - The SVN version has updates for the index files, which the Wiki version is missing. I'll try to merge the fixes from the Wiki version into the SVN version, and then also finalize the latin-1 correction. After that we can update the Wiki, and I'll leave some more messages for the original author so he knows about this. Cheers. On Feb 13, 2011, at 16:14, Carlos Dávila wrote: > El 12/02/11 23:54, Clinton Gladstone escribió: >> On Feb 12, 2011, at 17:52, Carlos Dávila wrote: >> >> >>> Conversion to gmap format in both cases: >>> python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-14.TYP >>> 5514*.img osmmap.img >>> >> Try the attached file. I quickly hacked it up to support latin-1 encoding >> for names. >> >> Also, if you are using the --index option in mkgmap, remember to include the >> index files in gmapi-builder. Example: >> >> >> $ gmapi-builder.py -t 1400.tdb -b 1400.img -s 14.TYP -i 1400.mdx >> -m 1400_mdr.img *.img > Thank you for the file, which works fine converting. I have not tested > resulting maps though, because I don't have a Mac. In case any user of > my maps report any problem I'll tell you. > Thank you also for the tips about index. I had not seen any comment > about -i and -m parameters on the wiki [1] neither on > gmapi--builder_README.txt. According to [1] the version from [2] is > supposed to be newer than the one from [3], but the later includes > support for index whereas the former doesn't. Should I change it on the > wiki? > > [1] http://wiki.openstreetmap.org/wiki/Gmapibuilder#Commandline_version > [2] http://bitbucket.org/berteun/gmapibuilder/downloads/gmapi-builder.tar.gz > [3] http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py > ___ > 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] Converting mkgmap generated maps to Mac format (was Index branch - success!)
The mdr file is missing.
Here is the line from the script which I use:
gmapi-builder.py -t /$OVERVIEW_MAPNAME.tdb -b $OVERVIEW_MAPNAME.img -s
$TYP_LOCAL -i ${OVERVIEW_MAPNAME}.mdx -m ${OVERVIEW_MAPNAME}_mdr.img *.img
Note at the end, I have a "*.img" statement, which includes ALL .img files in
the builder.
Your command would likely work with the following:
python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i
osmmap.mdx -m osmmap_mdr.img osmmap.img .img osmmap_mdr.img
- See that osmmap_mdr.img is listed twice on the command line: once after the
-m switch, and once in the list of all .img files.
Yes, this is somewhat redundant. ;-)
Cheers
On Feb 15, 2011, at 18:37, Dermot McNally wrote:
> 2011/2/15 Carlos Dávila :
>
>> Using latest script from Clinton Gladstone with a similar command line
>> as yours I've seen osmmap_mdr.img is not included in the resulting files
>> tree. Maybe this is the reason for the address information complain.
>
> Interesting - I'm not very clued into what files should be in there
> and where, but here's what's being created:
>
> total 40
> drwxr-xr-x 6 dermot staff204 15 Feb 16:36 .
> drwxr-xr-x 3 dermot staff102 15 Feb 16:36 ..
> -rw-r--r-- 1 dermot staff535 15 Feb 16:36 Info.xml
> drwxr-xr-x 5 dermot staff170 15 Feb 16:36 OSMTiles
> -rw-r--r-- 1 dermot staff 11982 15 Feb 16:36 dermot3.TYP
> -rw-r--r-- 1 dermot staff 26 15 Feb 16:36 osmmap.mdx
>
> ./OSMTiles:
> total 8
> drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 .
> drwxr-xr-x 6 dermot staff 204 15 Feb 16:36 ..
> drwxr-xr-x 7 dermot staff 238 15 Feb 16:36
> drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 osmmap
> -rw-r--r-- 1 dermot staff 560 15 Feb 16:36 osmmap.tdb
>
> ./OSMTiles/:
> total 48624
> drwxr-xr-x 7 dermot staff 238 15 Feb 16:36 .
> drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 ..
> -rw-r--r-- 1 dermot staff973088 15 Feb 16:36 .LBL
> -rw-r--r-- 1 dermot staff 3506553 15 Feb 16:36 .NET
> -rw-r--r-- 1 dermot staff 7943265 15 Feb 16:36 .NOD
> -rw-r--r-- 1 dermot staff 12422575 15 Feb 16:36 .RGN
> -rw-r--r-- 1 dermot staff 40062 15 Feb 16:36 .TRE
>
> ./OSMTiles/osmmap:
> total 24
> drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 .
> drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 ..
> -rw-r--r-- 1 dermot staff 275 15 Feb 16:36 6324.LBL
> -rw-r--r-- 1 dermot staff 145 15 Feb 16:36 6324.RGN
> -rw-r--r-- 1 dermot staff 462 15 Feb 16:36 6324.TRE
>
>
> Are there any obvious omissions? If so, can I just copy stuff into place?
>
> Thanks,
> Dermot
>
>
> --
> --
> Igaühel on siin oma laul
> ja ma oma ei leiagi üles
> ___
> 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] Another failure with downloading filrs
On Feb 15, 2011, at 13:46, Steve Ratcliffe wrote: > > I was looking into the umlaut problem - to confirm : the problems are only on > a device and not seen in map source? This appears to be the case. I test with BaseCamp on Mac OS, but it appears to be the same: streets with umlauts are found in BaseCamp but neither in my Nüvi nor my eTrex. Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search and index.
On Feb 13, 2011, at 23:52, Steve Ratcliffe wrote: > > So to make address search really useful the country names have to be cleaned > up, (other countries may be in a better state). > > Does anyone have any good ideas about this? I don't have any good ideas yet, but I can report that Germany is in a similar state. I get the following countries listed: Berlin Bundesrepubblik Deutschland Bundesrepublic Deutschland Deutschland It's going to be hard keeping this under control. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Converting mkgmap generated maps to Mac format (was Index branch - success!)
On Feb 13, 2011, at 16:14, Carlos Dávila wrote: > > Thank you also for the tips about index. I had not seen any comment > about -i and -m parameters on the wiki [1] neither on > gmapi--builder_README.txt. According to [1] the version from [2] is > supposed to be newer than the one from [3], but the later includes > support for index whereas the former doesn't. Should I change it on the > wiki? I'll try and check to see if the "newest" version according to the Wiki has any significant changes compared to the one in the mkgmap repository. I had previously attempted several times to contact the original developer of the script, but it seems that he has mostly lost interest. It could be that the "newest" version is simply the original moved to a new location. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Converting mkgmap generated maps to Mac format (was Index branch - success!)
On Feb 12, 2011, at 16:59, Carlos Dávila wrote: >> > I use gmapi-builder.py to transform my maps into BaseCamp format, but it > fails with those containing an Ñ (from España) in --country-name > --area-name --family-name or series-name. Do you know a way to get it > compiling? (other than changing España by Spain) That's strange. What error message does it give? Could you please send the exact command line options which you use, so I can reproduce this? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - success!
On Feb 11, 2011, at 22:31, fla...@googlemail.com wrote: > Compiled germany with it. Compiling works. > Copy gmap.img to 60CSX. Map works. Search same as in older days. > Do i need Mapsource ? use OS X 10.6 ;-( Just to update: I have now successfully transferred a map on Mac OS X to my Nüvi. Address search works. To review, this is my workflow: 1. Compile map with mgkmap using the --tdbfile option. 2. Use gmapi-builder.py to compile the .img and other map files to a .gmapi file. 3. Use Garmin MapManager to install the .gmapi file on your Mac. (The installed file can be viewed with Garmin BaseCamp. 4. Use Garmin MapInstall to transfer the map to your GPS device. (Using a card reader is normally the fastest method.) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - success!
On Feb 11, 2011, at 20:11, Steve Ratcliffe wrote: > > Some progress on the index branch. I can also report that for the first time ever, address search works in Basecamp for Mac OS X. I'm delighted. You should treat yourself to a glass of Champagne for this, if you are so inclined. :-) I compiled a 36 tile map of Australia/Oceania to test. I have not yet tried to upload the map to my device though. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - success!
On Feb 11, 2011, at 22:31, fla...@googlemail.com wrote: > Compiled germany with it. Compiling works. > Copy gmap.img to 60CSX. Map works. Search same as in older days. > Do i need Mapsource ? use OS X 10.6 ;-( On OS X, you should be able to use Garmin Basecamp and Mapinstall to install the maps. (You first need to create a .gmapi file from the .img files: there is a Perl script for that.) I have done this with older versions of mkgmap with semi-working address search, so I suspect that it should work with the index branch as well. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - success!
On Feb 11, 2011, at 20:11, Steve Ratcliffe wrote: > Some progress on the index branch. This is the best thing I've heard all day. :-) Thanks, I'll try this out. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cgpsmapper open version: initial source released
It looks like the author has only published two parts of cgpsmapper so far: cpreview - tool for index generation and preview files generation mapRead - sub part of cpreview - allowing fast access to IMG file That's interesting enough in itself though. The author indicates that the rest of cgpsmapper will follow at some point. Cheers. On Dec 11, 2010, at 14:47, maning sambale wrote: > http://sourceforge.net/projects/cgpsmapper/ > > Rapidly browsing the sourceforge site, I didn't see any reference to > the license. In any case, I hope mkgmap devs can learn a few things > or two in the open version of cgpsmapper. > -- > cheers, > maning > -- > "Freedom is still the most radical idea of all" -N.Branden > wiki: http://esambale.wikispaces.com/ > blog: http://epsg4253.wordpress.com/ > -- > ___ > 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] basic search
On Sep 28, 2010, at 14:09, Hendrik Oesterlin wrote: > I was not able to handle mkgmap-crated gmapsupp.img with Mapsource... > I'm certain that it is simple as all the rest, but I can't see the > evidence... MapSource will not read gmapsupp.img files. Instead you have to install a mapset with individual .img, .tbd, etc., files. You can find more here: http://wiki.openstreetmap.org/wiki/Mkgmap/help/mapsource Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] basic search
On Sep 22, 2010, at 20:33, Johann Gail wrote: >> >> As far as I understand, the mkgmap --index option produces "half-cooked" >> files that must be transferred by MapSource to the device. Once that is >> done, the search should work. Others can hopefully chime in; I have >> never used MapSource. >> > Same situation for me. I have never tried, but am in the opinion it > should work this way. Can anyone confirm this? If so, it should be > possible to find the differences in mkgmap and mapsource generated indexes. I can confirm this: after transferring maps to my eTrex with either Mapsource on Windows/Wine or MapInstall on the Mac, address search works -- at least with the known limitations of mkgmap's index generation. I have not recently attempted to copy a generated gmapsupp.img file to my device, but I recall that the address index did not work in this case. I assume that this has not changed. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Binary OSM file support?
On Sep 9, 2010, at 19:55, Scott Crosby wrote: > The format is stable, but I want to release one more RC, with a full > validation before I declare it stable. I expect no incompatible > changes. Is this the binary format in discussion: http://wiki.openstreetmap.org/wiki/OSMbin(file_format) I had trouble finding the right description. There seem to be a few other "binary" format projects, apparently primarily intended for mobile applications. (And the link in Scot's original e-mail to this list is sadly broken.) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] svn works ok?
On Aug 31, 2010, at 20:37, Greg Troxel wrote: > no, sun java on intel mac. > I have tried openjdk but had trouble; it would be nice if i works someday I'm also on an Intel mac, and have not had troubles with the latest SVN release. I'm of course using Java 1.6: $ java -version Java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] suggest a polygon hexcode for place of worship
On Aug 10, 2010, at 6:21, maning sambale wrote:
> Any suggested hex others recylce for place_of_worship polygons?
I have this at the beginning of my polygons file:
amenity=place_of_worship & (building!=*) {add building=yes}
Which ensures that a place of worship polygon will be treated as a building
polygon. (I think a place of worship POI gets created too, using the polygon to
POI conversion.)
Cheers
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Strange strings in addresses (r1654)
On Tue, Jul 20, 2010 at 12:04 AM, Daniela Duerbeck wrote: > But Clinton got also strange strings. Without my typ file. Or something else > from me. The "DE DE" that he got should also not be in this string. > These string parts come from elsewhere. I am innocent! I am almost certain that the DE, DE which I get is due to the fact that I set both the country as well as the region abbreviation to "DE". Therefore, this problem is most likely created by me. As I mentioned in my previous e-mail, it would be interesting if you also explicitly set the region information: it could be that mkgmap is picking up random information if you don't set this. Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Strange strings in addresses (r1654)
On Jul 19, 2010, at 20:02, Daniela Duerbeck wrote: > Hi Clinton! >> Hm... with my Geofabrik extract and Mkgmap 1652 I get the following: >> >> Rablstrasse 45 >> 81669, München, DE, DE >> >> Which, aside from the DE, DE part, seems to be correct. I'll try updating >> mkgmap and recompiling to see if that makes a difference. >> >> If it does not make a difference, then either something in the mkgmap >> options or in the JRE/OS may be causing the problem. >> > I do not think so. It is a very strange bug. It changes for example > even, if the osm file, the styles, the mkgmap etc. remain the same and > just the typ file is changed. I noticed that you do not set the region name or abbreviation. Perhaps you could try that? I seem to be getting pretty consistent results, but I always compile with the following options: --country-name="$OSM_COUNTRY" --country-abbr=$OSM_COUNTRY_ABR \ --region-name="$OSM_REGION" --region-abbr=$OSM_REGION_ABR \ (With appropriate variable substitution, of course.) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Strange strings in addresses (r1654)
On Jul 16, 2010, at 14:48, Daniela Duerbeck wrote: > Today, with mkgmap 1655 and current Oberbayern from Geofabrik > http://download.geofabrik.de/osm/europe/germany/bayern/oberbayern.osm.bz2 > I get: > > Mitani > Rablstrasse 45 > 81669 Anzinger Siedlung 19 > 85560 Ebersberg Hm... with my Geofabrik extract and Mkgmap 1652 I get the following: Rablstrasse 45 81669, München, DE, DE Which, aside from the DE, DE part, seems to be correct. I'll try updating mkgmap and recompiling to see if that makes a difference. If it does not make a difference, then either something in the mkgmap options or in the JRE/OS may be causing the problem. Cheers. P.S., If I'm ever in Munich, is that a good restaurant? Japanese? ;-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question regarding house numbers
Sorry for not replying earlier: I started to answer but then got distracted.
What I wanted to write, is exactly what you mentioned in your
self-comment: You have to use a POI type which support address data
Regarding naming, I will have to check again. I seem to recall that
the calculated name from the polygons file gets added to the POI. Try
to set the name in the polygons file, and see if that makes a
difference.
Cheers.
On Mon, May 31, 2010 at 11:35 PM, Daniela Duerbeck
wrote:
> Selfcomment.
>>
>> I have this in my points file:
>> addr:housenumber=* {name '${name} (${addr:street} ${addr:housenumber}
>> ${addr:postcode} ${addr:city})' | '${addr:street} ${addr:housenumber}
>> ${addr:postcode} ${addr:city}'} [0x7100 resolution 24]
>>
> The problem was to choose a number that gets no address info from
> Garmin. With 0x3217 it works.
> The line above seems to copy the address info into the name and this
> works also for numbers that wont't get address info but it doesn't work
> for POIs that generated with add-pois-to-areas. There the default name
> cannot be overwritten, that's why I get the German word "Punkt".
>
> Correct me if I am wrong.
>
> Dani
> ___
> 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] seamarks and style file
On May 22, 2010, at 17:08, frmas wrote: > Do I have the right to write in my style points file something like that : > seamark:buoy_lateral:colour=green [0x1604 resolution 20] > seamark:buoy_lateral:colour=red [0x1605 resolution 20] That looks about right. I have almost identical points in my style file: seamark:buoy_lateral:colour=green [0x1609 resolution 20] This works for me. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New mkgmap styles
On Fri, May 7, 2010 at 7:13 PM, Marko Mäkelä wrote: > > I believe that these layer style files would have to include a TYP file. > I don't have a clear idea how to package the TYP files. Can mkgmap look > for TYP files inside a style directory? Should it? The problem with the TYP files is that the family and product IDs have to match that of the map being generated. I have the following workflow in place: 1. My "generic" TYP file is in a directory where the style directories also are. 2. My map building script copies the TYP file to the directory where the current map is to be generated. In the copy process, the TYP file is also renamed to a unique name matching the current map . (If I recall, the TYP file name must also be unique if combining with several different maps.) 3. A Perl script then adjusts the TYP file family and product IDs to match that of the map being generated. 4. The adjusted TYP file is then passed as a parameter to mkgmap as the map is generated. Therefore, I would suggest that you think about distributing your TYP file, potentially with the style files, but note that users will have to adjust the name and IDs when they generate their own maps. (And by the way, thanks for taking the initiative on this. Last year I created a test public transportation layer, but have not had time to document or distribute what I did.) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] pois and wrong citynames
On Fri, May 7, 2010 at 11:55 AM, Minko wrote: > For instance, I would like to add a statement in the points style file like > addr:city which looksup the correct city name from the polygons style file, > if a poi that lies within a polygon with the tags place=city/town/village (or > boundary=city/..) > or even landuse=residential (with a name). Or maybe even from multipolygons > created > from administrative boundaries (like municipalities)? I can't add too much here, but I think it is worth mentioning that, as I understand it, the algorithm for determining if a point lies within a polygon can be quite performance intensive: http://en.wikipedia.org/wiki/Point_in_polygon There are of course libraries for dealing with this problem, but I still think the performance question is still significant. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question regarding house numbers
On Thu, Apr 29, 2010 at 6:34 PM, Daniela Duerbeck wrote: > > When a house number is mapped in osm as a POI, I can see the house > number in my device but when it is mapped in a polygon (e.g.with > building=yes) the POI is rendered but I can see just the word "Punkt" as > additional information. > Should I add something in the polygons file? A number of months ago, I sent some information regarding the display of house numbers for building polygons to the mailing list. You should be able to find this in the archives (sorry, I don't have good access right now). If I recall correctly, I changed the name attribute of building=yes items in the polygons file, such that the house number was displayed as part of the name of the polygon. It is also possible to map the polygon to a POI, but this becomes impractical in areas with large numbers of houses. Hope this helps. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java crash - any idea?
On Apr 18, 2010, at 21:12, Valentijn Sessink wrote: > Mkgmap seems to crash on my brand new Ubuntu 10.04 installation with > "OpenJDK" and I can't make anything of it (not being a Java wizard, that is). > What does the attachment say? (I just hope it doesn't say "Switch to Oracle > Java for €1,837,838 per seat" ;) I think it says "Don't use OpenJDK" (although I have not actually looked at the log file). Other users indicated that switching to the Sun JVM solved such problems. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
On Apr 18, 2010, at 9:37, maning sambale wrote: > 2. I activated the transparent switch in order to integrate the map > into the regular maps. However, in etrex is see the keepright POIs > underneath the roads. I think you might want to use the draw-priority option to ensure that your FIXME map is drawn on top of your other maps. Example: --draw-priority=30 Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] yet another --add-pois-to-areas question
On Wed, Apr 14, 2010 at 1:05 AM, Daniela Duerbeck wrote: > I cannot figure out what prevents mkgmap from creating a POI for > sport=swimming for this swimming bath. I would like to find it in the > POI search. I have both building=* and public_building in my polygons > and sport=swimming in the points. I think you need sport=swimming in your polygons file too. If I recall, the --add-pois-to-areas option requires identical items in both the polygons and lines files. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Routable pedestrian areas
On Thu, Apr 8, 2010 at 10:07 AM, Felix Hartmann wrote: > Well I think routing over areas sucks, and I would not support it. There > should be clear distinction between ares and highways as lines for > routing. This is true in general, but only an exception for pedestrian squares. The wiki clearly states that pedestrian highways can also be tagged as areas: http://wiki.openstreetmap.org/wiki/Pedestrian As such, there are now a very large number of pedestrian squares tagged in this way. If they are not made routable, this can really hinder foot (and potentially bicycle) navigation in large cities. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Routable pedestrian areas
On Thu, Apr 8, 2010 at 10:00 AM, Minko wrote: > Well, I compiled the map with version 1620, > and on my map the outlines of those pedestrian areas are rendered as footway, > and are routable (dotted lines). The polygon is rendered grey. I'll check this out. It could be that the most recent changes have made this patch completely unnecessary, which is fine with me: I also agree that it is better to have such things cleanly handled in the style files. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH] Routable pedestrian areas
The attached patch is an updated version of an earlier patch which I submitted. It adds a cheap but sub-optimal pedestrian routing option: --route-pedestrian-areas When this option is set, mkgmap will add a pedestrian way around the perimeter of pedestrian areas (Squares and Plazas). This will allow GPS devices to calculate routes through (i.e., on the perimeter of) such squares to other connecting ways. This is not the best solution, as you will always be routed along the edge of the area, but it works. I have been unable to think of a better, practical solution. The code is in the style of (read: shamelessly copied from) Mark's cycleway additions. I have been using the patch for some time, and I have found it quite useful for pedestrian routing in cities where such areas frequently occur. Your feedback and comments would be appreciated. Cheers. cg-route-pedestrian-areas-v2.patch Description: application/apple-msg-attachment ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Highway name or ref
On Apr 6, 2010, at 20:51, Lambertus wrote:
> Someone on the forum seems to have found the solution:
>
> Quote by Vclaw:
>
>> I noticed this same thing on some Garmin maps I was making. I think
>> its caused by the highway shields, as the Garmin can't display those
>> as well as the name at the same time. I fixed it by setting the
>> "display_name" for the highways. eg a style rule like this:
>
>> highway=primary {name '${ref|highway-symbol:box} ${name}' |
>> '${ref|highway-symbol:box}' | '${name}'; add display_name = '$
>
> It's aparently the second part of this patch of which only the first
> part has been committed:
>
Yes, I think it was decided not to include the display_name stuff in the
default style, since it was unclear if this would be generally useful.
However if more people find this helpful, and if we now have more functions
which make use of the multiple labels, it may be time to reconsider adding some
display_name statements to the lines file in the default style.
Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - Code around highway shield crap when sorting labels
On Mar 21, 2010, at 23:36, Mark Burton wrote: > So, those people who are tracking this patch series, please test and if > it doesn't bite your arse, I will commit it soonish I tested v5 today. It seems to be OK. I'll try again with v6 tomorrow. Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to "name "
On Mar 21, 2010, at 22:08, Mark Burton wrote: > Sure, what's the point in having multiple labels the same (apart from > the shield code)? I suppose "because Felix said so" isn't a good argument is it? ;-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - Code around highway shield crap when sorting labels
On Mar 21, 2010, at 23:36, Mark Burton wrote: > So, those people who are tracking this patch series, please test and if > it doesn't bite your arse, I will commit it soonish I've applied the patch and will report on the results in due course. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to "name "
On Mar 21, 2010, at 14:21, Felix Hartmann wrote:
> It seems that dipslay_name internally in mkgmap is not allowed to be set
> to "name". If identical it will not be set at all. Or is this really a
> Garmin limitation?
> To me it seems to be rather an mkgmap bug.
I haven't had time to properly think about this. But if you want to give it a
try, here's a possible, but completely untested solution:
Change the lines from my previous e-mail in Subdivision.java to the following:
if(trSansGC.length() > 0 &&
(!trSansGC.equalsIgnoreCase(nameSansGC) ||
!r.equalsIgnoreCase(name))) {
//System.err.println("Adding ref " + tr
+ " to road " + name);
pl.addRefLabel(lblFile.newLabel(tr));
}
and it might work.
Then again, it might not. ;-)
Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to "name "
On Mar 21, 2010, at 14:21, Felix Hartmann wrote:
> It seems that dipslay_name internally in mkgmap is not allowed to be set
> to "name". If identical it will not be set at all. Or is this really a
> Garmin limitation?
> To me it seems to be rather an mkgmap bug.
As far as I can tell, this behaviour was added by Mark's highway shield "crap"
patch.
I think this change in Subdivision.java is responsible:
if(trSansGC.length() > 0 &&
!trSansGC.equalsIgnoreCase(nameSansGC)) {
//System.err.println("Adding ref " + tr
+ " to road " + name);
pl.addRefLabel(lblFile.newLabel(tr));
}
You can see the additional label will only be added if it differs from the name
after the Garmin codes have been stripped from the name.
Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] - Code around highway shield crap when sorting labels
On Mar 21, 2010, at 11:12, Felix Hartmann wrote: > On 21.03.2010 10:57, Mark Burton wrote: >> BTW - do you think this v4 patch is working well enough to commit now? >> > yes Me too! :-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] - Code around highway shield crap when sorting labels
On Mar 18, 2010, at 23:38, Mark Burton wrote: > v4 - found the motorways (and a load of other roads too!) This version seems to work quite well. I can now locate roads, using the address search, which I could never find before (even with v3 of this patch). I'll test more thoroughly, but it looks good so far. Thanks! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] - Code around highway shield crap when sorting labels
On Mar 18, 2010, at 22:49, Mark Burton wrote: > v3 - now works harder to clean up road names for use in MDR file Er... this patch needs to be applied on top of the v2 patch does it not? It just patches the MDR file, but does not contain the patches to all the other files from the v2 patch. Did you perhaps forget to include the v2 stuff? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Broken Routes based on mkgmap map due to "functional characters" inside name
On Mar 18, 2010, at 20:51, Felix Hartmann wrote: > Hi, I just got this comment yesterday via my homepage. Seemingly mkgmap in > some circumstances puts ENQ - functional characters into the name of streets > (when adding the name from a route relation). ENQ is ASCII 0x05, which is one of the codes for highway shields. Perhaps Mark's patch to code around this "crap" would also help here? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Why are all the un-named peaks called '6140565'?
On Sun, Mar 14, 2010 at 11:29 PM, Mark Burton wrote:
> Hey, that's a really great bug, it causes anonymous peaks to be
> named in honour of a bus stop!
This may be caused by the "def" (default value) and "height" filters.
I believe the statement is attempting the following:
1. ${name|def:} use either the 'name' value, or as default '' (empty string).
2. ${ele|height:m=>ft|def:} Convert the elevation in meters to feet.
If no 'ele' value is present, use an empty string.
I have a feeling that the empty string part may be misinterpreted
right now. It could be that the last value found is instead used.
The relevant files are below, if you want to debug:
DefaultFilter.java - called for the 'def' filter.
HeightFilter.java - called for the 'height' filter (a subclass of
ConvertFilter.java)
ValueBuilder.java - instantiates the filter classes. This would be a
good place to start.
Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] SVN 1598 gives flooded tiles
On Mar 14, 2010, at 1:09, Apollinaris Schoell wrote: > I have tried the patch and it's the first time generate-sea=multipolygon is > working for all my tiles.:) > highly recommended and should be commited Although I see that the patch has already been committed, I can also confirm that it appears to work correctly and may speed up processing. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap gives java error
On Mar 13, 2010, at 20:26, Tony Groves wrote: > java.lang.OutOfMemoryError: Java heap space This generally means that you need to allocate more memory to Java. Try something like the following: java -Xmx2048M -jar ... Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Finland with almost-working generate-sea
On Wed, Mar 10, 2010 at 8:09 AM, Marko Mäkelä wrote: > If I include the Swedish, Russian and Estonian coastlines to reach the > tile borders, then mkgmap will take forever to generate the sea. Maybe > I should try with a grossly simplified coastline (just straight lines > to the tile borders). If, by "forever", you mean "about an hour", then yes. :-) Last week, I generated a map of the entire Geofabrik Europe extract. The coasts of Finland appeared to be correctly generated. This took about 20 hours on my laptop though (memory seemed to be the main bottleneck). The same for an Osmosis extract of the bounding box of Germany takes a few hours. I would expect something similar for Finland, even with the much more complex coastline. Maybe you should just start your map generation and then do something else away from your computer for an hour or two. ;-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Finland with almost-working generate-sea
On Mar 9, 2010, at 20:20, Marko Mäkelä wrote: >> I regularly take the entire Geofabrik extract of Europe and extract a >> bounding-box containing all of Germany. > > Have you been able to make it utilize all cores? I have a dual-core computer, > and java is eating only one CPU. Apparently, the bzip2 is already done. No, but it seemed to me that the major bottleneck in my system was disk access, not CPU. However, I'm doing this on a laptop with a slow 5200rpm drive. I also normally decompress the .osm.bz2 files in advance, as I often access them several times. > [...] > > According to http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage > disabling the date parsing should not make a big difference. I agree; > both --merge and extracting natural=coastline have been relatively fast. I have been using Osmosis 0.31.1. At least with this version, disabling date parsing made a huge difference. It could be that more recent releases are more efficient in this regard. > Are you extracting the bounding box with completeRelations=yes > completeWays=yes? No, as I use quite generous bounds, I have not yet noticed a need for this. This is what I use: OSM="de-bb.osm" # osmosis --read-xml enableDateParsing=no file="europe.osm" --bounding-box left=5 right=16 top=56 bottom=47 --write-xml file=$OSM After that I run splitter on the extract. Perhaps you're trying to do too much at once? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Finland with almost-working generate-sea
On Tue, Mar 9, 2010 at 3:47 PM, Marko Mäkelä wrote: > > When I added > --bb completeWays=yes left=19.1162109375 right=31.5966796875 > bottom=59.4140625 top=70.0927734375 > before the --wx in the chain, I had to interrupt it after letting it > run several minutes. You should disable date parsing (enableDateParsing=no); this considerably speeds up Osmosis. See further discussion here: http://wiki.openstreetmap.org/wiki/Osmosis/Examples I regularly take the entire Geofabrik extract of Europe and extract a bounding-box containing all of Germany. Performance is reasonable (which means under an hour) and I have been getting good results with the MP coastline handling. I don't know how this would work with Finland though. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] SVN 1598 gives flooded tiles
On Mar 7, 2010, at 21:15, Toby Speight wrote: > Everything works fine with revision 1597. But with 1598, every tile > that has any coastline in it becomes completely flooded. This is for > a Great Britain map, using multipolygon sea generation I can confirm the same for a map of Germany. With 1597, everything was (for perhaps the first time) perfect. With 1598, all coastline tiles are flooded. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
On Feb 28, 2010, at 21:24, Carlos Dávila wrote: > Yes, I also think some improvement is better than nothing. I wonder if > nobody else have seen these kind of anomalous turn instructions. More > cases could help guessing what is happening. I also have been seeing such turn instructions. Patch v2 seems to have solved the problem though, in my particular test case. Sorry, I have not had time to properly test and report on this though. I'll keep an eye out for similar incorrect turn instructions. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help: --generate-sea: No coastline
On Feb 21, 2010, at 1:38, Daniela Duerbeck wrote: > I know that generate-sea is still buggy but I cannot achieve any blue > sea. I try to generate a routable map of the Canary Islands. > With the mkgmap version 1580 I do not even get the coast lines. > With 1484 I got blue islands on yellow sea. > > Can there be any interaction between style-files and the generate-sea > option? > > I used these style files: > http://dev.openstreetmap.de/aio/styles/styles.tar.bz2 The last time I looked at the all-in-one (aio) styles, there was no land polygon defined in the polygons style (and I presume in the TYP file). You need this for --generate-sea=polygons to work correctly. See the documentation in the options file for more details. You may wish to try --generate-sea without the polygon option (using the multipolygon option by default). The following works quite well for me: --generate-sea=extend-sea-sectors (And by the way, are you sure you need to run splitter on the Canary Islands? I would imagine that the data is small enough not to warrant splitting.) Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] heed the through_route relation when adjusting turn headings
On Feb 12, 2010, at 12:46, Mark Burton wrote: >> Is "through route" documented in the OSM Wiki? I was unable to find >> any information on this. > > Not yet, but it should be. I was rather hoping that some kind person > would add a page to the Wiki describing it. So about adding this to the Wiki: is there any other information about the through_route relation type, except what has appeared in this mailing list? Is the node with role "junction" now obsolete, or simply optional? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] administrative borders (was: multipolygon with outer polygon within inner polygons)
On Feb 14, 2010, at 11:32, Minko wrote:
> set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}';
Just out of interest, should the parentheses surrounding mkgmap:boundary2_name
not be curly brackets ('{', '}')? I noticed this in the default style as well.
Or is this a syntax which I am unfamiliar with?
Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] heed the through_route relation when adjusting turn headings
On Sat, Feb 6, 2010 at 7:43 PM, Mark Burton wrote: > > This new relation (type through_route) specifies which 2 ways are the > "through route" at a junction. I have been testing this patch too, and have so far not found any problems. Is "through route" documented in the OSM Wiki? I was unable to find any information on this. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - fix Table C size bug + allow Table B to contain up to 255 entries
On Thu, Feb 11, 2010 at 1:36 AM, Mark Burton wrote: > > v2 - oops, the fix was flawed - try this one, sorry I tested v1 on my Nuvi yesterday, and was rewarded with really "interesting" routing. ;-) Today, I tried out v2, which seems to work well. I'll keep testing. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Gmapibuilder: Searching for new site to host source code
On Feb 10, 2010, at 23:25, Lambertus wrote: > As a sidenote, I got a mail today about Gmapibuilder results claiming > that the MapInstaller gives an error with my latest map release. Since I > haven't changed gmapibuilder it might be something in Mkgmap (r1557) > that triggers this. Is someone with access to a Mac able to check? I checked this today: I was able to download and install a map from your site without problem. I would assume that either the other user's download was corrupt, or there was something wrong with the specific map. Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Gmapibuilder: Searching for new site to host source code
On Feb 10, 2010, at 23:25, Lambertus wrote: > As a sidenote, I got a mail today about Gmapibuilder results claiming > that the MapInstaller gives an error with my latest map release. Since I > haven't changed gmapibuilder it might be something in Mkgmap (r1557) > that triggers this. Is someone with access to a Mac able to check? I have been regularly using Gmapibuilder with maps built using the latest releases of mkgmap, so this doesn't seem to be directly a problem. I'll try to download one of your maps tomorrow and see if I can find anything. Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Gmapibuilder: Searching for new site to host source code
Hi All, I, and others, have noticed that the original hosting server for Gmapibuilder appears to be no longer available. Attempts to contact the original author have also failed. Fortunately the source is BSD licensed. I still have the source (which I patched to convert .mdr and .mdx files as well), and would like to find a new permanent host for it. Are there any disadvantages to using Google Source, or is there a better place to host the code? (For those of you who do not know/remember Gmapibuilder converts maps created by mkgmap to the Gmapi format used on Mac OS X.) Any advice is appreciated. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Text format for TYP files
On Feb 2, 2010, at 17:41, Carlos Dávila wrote:
>> I used this knowledge to write a small Perl script which changes the Family
>> and Product IDs of a given TYP file.
>>
> Would you be so kind to share your script with this list? Having to maintain
> several TYP files that only differ in FID and PID is an annoyance using the
> on line editor.
Sorry for not replying earlier: I had to recover my system from a hard drive
failure.
I have attached the script. It should be fairly straight forward to use:
set-typ.pl
I would recommend always running this on a copy of your TYP file, just in case
something goes wrong. :-)
Enjoy.
#!/usr/bin/perl
#
# Usage:
#
# set-typ.pl
#
# Position of bytes in TYP file:
#
# Little-endian
# Bytes 2f-30: Family ID
# Bytes 31-32: Procuct ID
my $familyID = shift(@ARGV);
my $productID = shift(@ARGV);
my $typFile = shift(@ARGV);
my $IDsize = 2;
my $FIDstart = 0x2f;
my $PIDstart = 0x31;
open(TYP, "+<$typFile") || die "Can't update $typFile: $!";
print "Updating $typFile...\n";
seek(TYP, $FIDstart, 0);
read(TYP, $FID, $IDsize) == $IDsize || die "can't read FID: $!";
seek(TYP, $PIDstart, 0);
read(TYP, $PID, $IDsize) == $IDsize || die "can't read PID: $!";
my $FIDu = unpack("S", $FID);
my $PIDu = unpack("S", $PID);
print "Original Fid: $FIDu Pid: $PIDu\n";
#-
# Change FID, PID:
seek(TYP, $FIDstart, 0);
print TYP pack('S', $familyID);
seek(TYP, $PIDstart, 0);
print TYP pack('S', $productID);
#-
seek(TYP, $FIDstart, 0);
read(TYP, $FID, $IDsize) == $IDsize || die "can't read FID: $!";
seek(TYP, $PIDstart, 0);
read(TYP, $PID, $IDsize) == $IDsize || die "can't read PID: $!";
$FIDu = unpack("S", $FID);
$PIDu = unpack("S", $PID);
print "Changed Fid: $FIDu Pid: $PIDu\n";
close TYP;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] adjust turn headings more
On Jan 25, 2010, at 16:36, Mark Burton wrote: > Anyone else tried this? If so, was it good/bad/the same/didn't > notice/don't care/what's for tea? I've been testing a map compiled with this patch for the past couple of days. Since I don't have a good test case, I was not able to notice any large differences. It seemed to me that the Nuvi was a bit more talkative than usual, but that could be my imagination. The patch appears to be at least mostly harmless. ;-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Polygon with barrier problem
On Jan 23, 2010, at 11:59, Charlie Ferrero wrote: > For future reference, > mkgmap processes the style files in a strict order, which is: >1. version >2. info >3. options >4. relations >5. points >6. lines >7. polygons >8. overlays And I assume that the "continue" statement will not allow processing to continue across style files? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding in Germany
2010/1/20 Felix Hartmann > > Just downloaded new data for Germany, problem persists: > > Is this maybe not solvable with current code? > I'll retry with different max-nodes to see if it then maybe works. > I also noticed this with the Geofabrik extract of Germany: The tile around Bremen always gets flooded. My tiles are different from yours, so I assume we have different max-nodes parameters. I did also compile Geofabrik's complete Europe extract: here the problem did not occur. There were a couple of other landlocked tiles in France and Poland which were flooded though (caused by, I assume, some bad data in the tiles). This may mean, therefore, that the problem stems from the way Geofabrik extracts Germany. You could try making your own extract (using a bounding box) for Germany out of the Europe extract. Perhaps this would work better. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Haiti OSM problem on Garmin 76CSx
On Tue, Jan 19, 2010 at 3:26 PM, and...@inveneo.org wrote: > However, when I turn off the unit, I > get I constant low alarm tone. The only way to make it stop is to remove > batteries. This symptom is similar to that caused in certain units (eTrex) when a SD card was used which had been previously written o on a Mac OS X system. Mac OS copied hidden files to the SD card, which interfered with the unit. If your SD card has been used in a Mac OS machine, you may wish to investigate this. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Text format for TYP files
On Jan 17, 2010, at 11:40, Marko Mäkelä wrote: > Have you tried using the source code? I did take a look at this some time ago. I noted that there were a lot of dependencies (such as imagemagick) which could cause troubles. Instead I used the source code to help me understand the TYP file format: I used this knowledge to write a small Perl script which changes the Family and Product IDs of a given TYP file. Based on this experience, it may be advisable for you to also create your program "from scratch", using the http://ati.land.cz/ program as a reference. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Add amenity=bar [0x2d02 resolution 21] to points style file
I noticed that JOSM now has amenity=bar in the presets list. Also OSMdoc indicates that there are 2096 nodes with this tag. Would it make sense to add the following to the points style file: amenity=bar [0x2d02 resolution 21] (This is the same POI used by Pub and Nightclub.) Party on dudes! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mp: PATCH] Multipolygon handling - decomposed polygons
On Jan 9, 2010, at 12:41, WanMil wrote: > Is there any mkgmap tag yet to avoid this? (like mkgmap:noaddpoitoarea=yes) POI generation from areas is disabled by default. Command line option --add-pois-to-areas enables this. Further, POIs will only be generated from areas if there is a corresponding entry in the points style file. Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Translating route=bus relations
On Jan 1, 2010, at 22:34, Marko Mäkelä wrote: > Could someone give me a hand with map layers (families in Garmin speak, > if I understand correctly)? Would I have to invoke mkgmap multiple times, > once for each map layer (family) and finally to combine the families to > a single gmapsupp.img? Or can I ask mkgmap to generate multiple map > families from the set of map tiles? What would be the best way to package > translation rules for bus routes? If the route=bus layer is to be compiled > separately from the "base" layer, then it would need a different style > altogether, right? And I guess it could be compiled with fewer and bigger > map tiles as well? Currently, my "base" layer of Finland is 3 tiles. > I believe that one tile of bus routes would easily cover the entire country, > at least until all bus routes have been mapped. I created a public transit layer for Toronto, Canada. Most of your suppositions are correct, at least the way I did it: - I had to invoke mkgmap once for each layer. Each layer had a different draw priority, TYP file, and mkgmap options (the public transit layer was transparent and not routable). - I did not use mkgmap to create the final gmapsupp.img file though. Instead I used Garmin tools (Roadtrip, MapSource) for this. (Some of the more recent changes to mkgmap's gmapsupp code may better support this now.) - I also created a completely new set of style files for the public transit layer. The style files were very basic, containing only items relevant to the public transit items (bus, tram, and subway stops, and the transit lines). - Since the information in the transit layer was so sparse, I also did not need to split the map into sub-tiles (I generated the layer from an entire map of Ontario, which otherwise needs to be split for the normal layer.) This should also most likely be the case for Finland. Does this help you? Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] amenity=embassy not handled by mkgmap ?
On Dec 7, 2009, at 20:16, Marko Mäkelä wrote: > 0x3003 was already used by amenity=townhall, so it is a safer choice > of these two, although slightly misleading, because the POI submenu > says "City Hall". I committed that in r1420. I just noticed the following blog entry: http://www.openstreetmap.org/user/Serpens/diary/9082 The entry indicates that many embassies are now tagged with ISO country codes (for example Germany embassies would be tagged with "country=de"). This may, or may not, be an interesting addition to the style file. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Understanding the sea
On Dec 28, 2009, at 21:27, Felix Hartmann wrote: > cgpsmapper produced maps may not be used CCBYSA 2.0 (only non > commercial). It would probably nevertheless be best to create a layered > sea map instead of creating it each time. Yes, that's true regarding the license. I suppose it would still be possible to generate the sea polygons from another (public domain) source and distribute the sea layer separately from the OSM layer, but that's a hassle both for the person generating the map, and users of the map. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Understanding the sea
On Dec 28, 2009, at 19:54, Mark Burton wrote: > I have agreed to help produce a marine map of the Baltic so > it would be really nice if the sea was filled in without any really > major problems (flooded land, etc.) I, unfortunately, can't help you specifically with the generate sea stuff. I can only comment that my previous tests with this option were not particularly satisfactory. Since distinguishing land from water seems to be an important feature of marine maps, I wonder if it makes sense to generate a one-off sea layer using cGPSmapper instead of mkgmap, until the generate sea problems are resolved? Or do most marine units have a sufficiently detailed base map? In that case a transparent OSM map (with POIs and other features) might be more appropriate, as this could be layered over the base sea map. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] variable substitution in relation members
On Dec 23, 2009, at 0:55, Steve Ratcliffe wrote: > I don't think it would cause any problems with memory or cpu, but if > an extra argument is added to filter() then I would add the same one > to doFilter() since they are the really the same routine just split so > that the common code can be in the base class. I updated the patch as you suggested and have attached it. I'd appreciate it if you could consider committing the patch. Cheers. cg-notequal-filter-v2.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
