Re: [mkgmap-dev] Style + TYP, next iteration
M... Yellow on yellow, may indeed be not ideal. Ill try and find something else! Those extended linetypes, will they have any effect on devices that don't support them? Or are they simply ignored? I may use them for non-routable, non-essential lines. And: may I compliment you on openfietskaart.nl? I'm definitely going to try that map! The screenshots look vey nice, and I saw the maps are very up to date. Regards, J-. Op 12 feb. 2011 om 19:04 heeft Minko het volgende geschreven: > Jeroen wrote: > - other paths were green, now yellow > > On a yellow background? Hard to see I guess ;-) > > You can try to use extended line types like 0x100/00-1f 0x101/00-1f etc > Note that even with a typ file some of them will not show up on some devices, > and they are not routable. See my typ files on http://openfietsmap.nl > > ___ > 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] Index branch - success!
Am 12.02.2011 15:08, schrieb Henning Scholland: >> Now when I find for addresses on my Legend HCX, I can choose >> between region "Deutschland" and region "Germany". >> [...] >> I used location-autofill=1 and >> --country-name=germany >> --country-abbr=DE >> --area-name=DE when I change this to --country-name=Deutschland --country-abbr=DEU --area-name=DEU then only region "Deutschland" is available and this is choosen automatically in the address-find page. >> For region Deutschland I have to enter "LÜ" to find >> cities starting with "Lü" but for Region Germany I >> have to enter "LU" to find cities starting with "Lü". > did you use --code-page//=1252? This should fix the problem with > umlauts. I used -latin1 but when I change to codepage/charset 1252 there is no difference. So, searching cities with "LÜ" now gives: Lünen, Kreis Unna Lünen-Süd, DEU and looking for "LU" gives: Lüdinghausen, Kreis Coesfeld Lünen, Kreis Unna Lünen-Süd, DEU Very funny. Another question: Searching for housenumbers is not yet possible? Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style + TYP, next iteration
Jeroen wrote: - other paths were green, now yellow On a yellow background? Hard to see I guess ;-) You can try to use extended line types like 0x100/00-1f 0x101/00-1f etc Note that even with a typ file some of them will not show up on some devices, and they are not routable. See my typ files on http://openfietsmap.nl ___ 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 perhaps don't allow non ASCII characters in the description, since I don't know if they are accepted or in what circumstances. Just need to try it and see what happens. ___ 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!)
El 12/02/11 17:05, Clinton Gladstone escribió: > 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 > > Failing maps are generated with: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=14 --product-id=1 --series-name="OSM-España" --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args Working maps are generated with: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=SPAIN --country-abbr=ESP --area-name=Spain --family-name="OpenStreetMap Spain" --family-id=14 --product-id=1 --series-name="OSM-Spain" --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args 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 ___ 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] Converting mkgmap generated maps to Mac format (was Index branch - success!)
El 11/02/11 23:58, Clinton Gladstone escribió: > 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.) 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) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and long way-segments
On Wed, Feb 9, 2011 at 5:15 AM, Henning Scholland wrote: > Am 07.02.2011 23:45, schrieb Minko: >> Henning, >> Did you try a higher overlap setting? >> Maybe --overlap=6000 ? >> >> --overlap >> Nodes/ways/rels that fall outside an area will still be included if they are >> within this many map units. Default is 2000 > Sorry for late answer, but I tried this already. In some cases it works. > But ferries at north sea or baltic sea (eg. Rostock-Helsinki) or other > "ocean"-ferries (Norway-GB) have waysegments with length of more than > 100km. These lines gets broken an I think its impossible to increase > tiles so much. The best workaround is to break these ways up into segments that are smaller. It is possible for the splitter to go back and when it finds that it missed a node in a way, to go back and re-fetch it. However, this requires an extra pass, more memory, and will generate files that aren't ordered nodes-ways-relations (and may need to be re-sorted?). Scott ___ 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 12/02/11 15:32, WanMil wrote: > I observed that the MapSource search menu is disabled if the MDR file is > larger than 0x7FF (134217727) bytes. > > Maybe in this case a flag must be set? My guess is in ImgHeader: // This sectors, head, cylinders stuff appears to be used by mapsource // and they have to be larger than the actual size of the map. It // doesn't appear to have any effect on a garmin device or other software. int sectors = 0x20; // 0x20 appears to be a max header.putShort(OFF_SECTORS, (short) sectors); int heads = 0x20; // 0x20 appears to be max header.putShort(OFF_HEADS, (short) heads); int cylinders = 0x100; // gives 128M will try more later Try boosting cylinders to 0x200, or try to find if there is a maximum useful value like it appears that there is for the others. ..Steve ___ 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!
I observed that the MapSource search menu is disabled if the MDR file is larger than 0x7FF (134217727) bytes. Maybe in this case a flag must be set? WanMil > Hi > > Some progress on the index branch. > > I found that the flags at the end of mdr7 trigger the acceptance of > the 20-29 sections. > > I can now download the maps to my Legend. > > Now when you try address search, it is in a completely different mode. > There is a country field (although labelled region) and as you make > selections in the country/city fields it reduces the options available > in the streets field > > Addresses can be found in other tiles and not just the closest one. > > ..Steve > ___ > 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] Index branch - success!
Sorry, I was wrong... is_in contains Deutschland Henning ___ 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!
Am 12.02.2011 14:56, schrieb Chris66: Am 12.02.2011 13:24, schrieb Steve Ratcliffe: Now in Basecamp the Mapinstall crashes when the progress bar of the index generating process is at 16%. I had this problem while upload a complete UK. I've since found that if I just upload a few tiles it doesn't happen. OK, when only sending *one* tile it works. Now when I find for addresses on my Legend HCX, I can choose between region "Deutschland" and region "Germany". Region Deutschland seems to show the basemap entries: Ahsen, DEU Alstätte, DEU Altenrheine, DEU ... while region "Germany" shows the OSM entries: Ahaus, Kreis Borken Albachten, Münster ... I used location-autofill=1 and --country-name=germany --country-abbr=DE --area-name=DE For region Deutschland I have to enter "LÜ" to find cities starting with "Lü" but for Region Germany I have to enter "LU" to find cities starting with "Lü". Greetings Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-de Hi, did you use --code-page//=1252? This should fix the problem with umlauts. Germany instead of Deutschland seems to to a "bug" in OSM is_in-tag, which contains the english name ;) Henning ___ 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!
Am 12.02.2011 13:24, schrieb Steve Ratcliffe: >> Now in Basecamp the Mapinstall crashes when the progress bar >> of the index generating process is at 16%. > > I had this problem while upload a complete UK. I've since found that if > I just upload a few tiles it doesn't happen. OK, when only sending *one* tile it works. Now when I find for addresses on my Legend HCX, I can choose between region "Deutschland" and region "Germany". Region Deutschland seems to show the basemap entries: Ahsen, DEU Alstätte, DEU Altenrheine, DEU ... while region "Germany" shows the OSM entries: Ahaus, Kreis Borken Albachten, Münster ... I used location-autofill=1 and --country-name=germany --country-abbr=DE --area-name=DE For region Deutschland I have to enter "LÜ" to find cities starting with "Lü" but for Region Germany I have to enter "LU" to find cities starting with "Lü". Greetings Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Style + TYP, next iteration
Marko, Minko, and others, Thank you for your feedback. I'm aware my style/TYP files use the contour types for bridges. Guess contours are not very importnt to me, living in the flat Netherlands. If anyone has a better suggestion, please let me know. The fact the contours may not be routable is no problem, as I use them as an addition to the 'normal' ways. I had already noticed the 0x14 lines disappearing. Now I know is't a Garmin thing, I switched between 0x14 and 0x24 (before 0x24 was used in an overlay to show tramways on roads). The widths of the different ways now match - in my opinion. To lose the yellow roads (that hardly show on a yellow background), I switched around some other colours: - footpath was green, now grey - other paths were green, now yellow - tracks were green, now grey (with transparent centre) - pedestrian was green, now grey - bicycle was purple, now green - motorways and primaries were red, now purple - secondary roads etc. were orange, now red - local roads were yellow, now orange For who's interested, I uploaded a copy of the latest TYP file, for family ID 1: http://dl.dropbox.com/u/20232727/M001-JM-new_colours.TYP With the current default style not all element will show. Some alterations needed changes in the style files too (like the bridges). I attached a patchfile wth those changes. It's also uploaded: http://dl.dropbox.com/u/20232727/style-JM-20110212_1848.diff Please comment! And for if and when (some of) my changes make it to the trunk, what's the correct way to get this done? Regards, J-. -Oorspronkelijk bericht- From: Minko Sent: Friday, February 11, 2011 9:07 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] 0x10 for residential in default style Hi Jeroen, A few remarks on your typ file: You use bridges for the lines that are reserved for contour lines. I dont know if they are routable, and this not make it possible to make maps with contour lines (elevation profiles might not work?). When zooming out, Railway type 0x14 disappears quickly on many gps units by default (strange bug in garmin software). Maybe you can "recycle" type 0x24 for the railways at lower zoomlevels (22-18?). -Oorspronkelijk bericht- From: MarkoMäkelä Sent: Thursday, February 10, 2011 10:23 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] 0x10 for residential in default style Hi Jeroen, On Thu, Feb 10, 2011 at 09:18:26PM +0100, Jeroen Muris wrote: Marko (and others interested), A copy of the current version of my TYP file can be found on http://dl.dropbox.com/u/20232727/M001-JM.TYP. Personally I use product 1 and family 3141, but this copy is compiled for family ID 1. It is a work in progress, and not all types are used in the default style. All types from the default style should be present though... Please let me know how it looks on your device. I liked the landuse and building polygons. I do not like the spaghetti (black border lines of 0x05, 0x06 and 0x01, among others). 0x09 looks fine (albeit a little wide). Actually, most ways look a bit too wide; they are hiding the cycleway or footway next to them. You can see an example of the spaghetti (with gray border lines instead of black) here: http://cferrero.net/maps/img/spag4.bmp Can you override the Garmin yellow background colour with the TYP file? If you can, that would make the black border lines unnecessary, wouldn't it? Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev style-JM-20110212_1848.diff Description: Binary data ___ 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!
Hello > Now in Basecamp the Mapinstall crashes when the progress bar > of the index generating process is at 16%. I had this problem while upload a complete UK. I've since found that if I just upload a few tiles it doesn't happen. Hopefully I can track down exactly which tile(s) causes it which might lead to a solution. It would be worth trying the r1848 as there is an extra fix in there. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Ways with 'shadows'
Hello all, By accident/serendipity I found a bug/feature regarding the borders/'shadows' on ways on Garmin devices. If in your TYP file you set a type up to use 2 colours (background and border), but set the border width to 0, then BaseCamp, MapSource and the Garmin Oregon 550t display this with a very thin border/shadow. Regards, J-. -Oorspronkelijk bericht- From: MarkoMäkelä Sent: Monday, February 07, 2011 10:41 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] 0x10 for residential in default style --- 8< --- snip --- 8< --- Do you know this problem? Does your TYP file have extra "border" lines around lines (other than motorways)? http://cferrero.net/maps/img/spag4.bmp http://cferrero.net/maps/img/nospag.bmp Marko ___ 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] Index branch - success!
On 12/02/11 11:27, Chris66 wrote: Hello > SCHWERWIEGEND (BlockManager): overflowed directory with max block 65534, > current=65535 > > Exception in thread "main" uk.me.parabola.imgfmt.MapFailedException: > Too many blocks. Use a larger block size with an option such as > --block-size=4096 or --block-size=8192 > at uk.me.parabola.imgfmt.sys.BlockManager.allocate(BlockManager.java:58) > at uk.me.parabola.imgfmt.sys.FileNode.write(FileNode.java:241) > at > uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:377) This error is being caused while creating the gmapsupp.img. That is the one place where the block size is adjusted automatically and so the option does not have an affect. Obviously there must be a bug when the size is very close to a boundary needing a larger block size. I think that changing anything so that the size is a little larger or smaller will work round the problem. (From your next message I see you changed the size of the tiles which probably changed the size of the gmapsupp a bit). ..Steve ___ 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!
Am 12.02.2011 12:27, schrieb Chris66: > SCHWERWIEGEND (BlockManager): overflowed directory with max block 65534, > current=65535 Ok, I could get rid of this error by using smaller tiles. Now in Basecamp the Mapinstall crashes when the progress bar of the index generating process is at 16%. mkgmap-index V1845 Christian ___ 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!
Hi > Initializing lastName with null should do (?). > The patch initializes lastName with null in all Mdr classes. This seems > to be a c&p problem that might happen with all names in lot's of Mdr > classes. > > Don't know if an empty name should be contained in map?! A region without a name is pretty useless as its name is its only useful attribute in the map. I'll apply the patch as it is reasonable. I think we should throw out regions with empty names at some point though. ..Steve ___ 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!
Hi, I get following error when testing with northrhinewestfalia.osm.bz2 (9 tiles). Already tried the suggested --block-size=8192, same error. Error seems to occur at the combine after the tiles have been created. SCHWERWIEGEND (BlockManager): overflowed directory with max block 65534, current=65535 Exception in thread "main" uk.me.parabola.imgfmt.MapFailedException: Too many blocks. Use a larger block size with an option such as --block-size=4096 or --block-size=8192 at uk.me.parabola.imgfmt.sys.BlockManager.allocate(BlockManager.java:58) at uk.me.parabola.imgfmt.sys.FileNode.write(FileNode.java:241) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:377) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:361) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:348) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyAllFiles(GmapsuppBuilder.java:301) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.addImg(GmapsuppBuilder.java:276) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.addAllFiles(GmapsuppBuilder.java:162) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:110) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:419) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:129) Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] coastlinefile option
Hi Tomas, you seem to be the first person that uses the coastlinefile option... There is a bug which is fixed in r1846. Thanks for reporting that! WanMil > Hello > >I'm trying to use a separate file with natural=coastline information. >I then provide it to mkgmap using option: >--coastlinefile=lithuania_coast.osm > >But I get this when executing: > > SEVERE (CoastlineFileLoader): lithuania_.osm: > java.lang.UnsupportedOperationException > java.lang.UnsupportedOperationException > at java.util.AbstractCollection.add(AbstractCollection.java:238) > at java.util.AbstractCollection.addAll(AbstractCollection.java:322) > at > uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.createConverter(OsmMapDataSource.java:251) > at > uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:131) > at > uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:69) > at > uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadFromFile(CoastlineFileLoader.java:90) > at > uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadFile(CoastlineFileLoader.java:119) > at > uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadCoastlinesImpl(CoastlineFileLoader.java:133) > at > uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadCoastlines(CoastlineFileLoader.java:79) > at > uk.me.parabola.mkgmap.reader.osm.SeaGenerator.init(SeaGenerator.java:135) > at > uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.pluginChain(OsmMapDataSource.java:158) > at > uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:126) > at > uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:69) > at > uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:145) > at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) > at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) > at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:217) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > > I tried creating coastline file using JOSM. Then I tried modifying > this file (removing elements with action="delete" etc.). The last > thing I've tried was to provide the full data osm file (the one used > to generate a map) as natural coastline just to check that file format > is OK, but I was still getting the same error... > > Full command line when creating a map: > > java -jar mkgmap.jar \ > --style-file=/home/tomas/garmin/tomas_style \ > --gmapsupp \ > --tdbfile \ > --family-name=OpenStreetMap \ > --description=Lietuva`date +%Y%m%d` \ > --country-name=Lithuania \ > --country-abbr=LTU \ > --preserve-element-order \ > --lower-case \ > --charset=windows-1257 \ > --route \ > --add-pois-to-areas \ > --generate-sea=multipolygon \ > --coastlinefile=lithuania_.osm \ > lithuania_.osm > >What am I doing wrong? What should the format of this coastline file be? > >Thank you > > P.S. This is using rev1838. > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1846: Fixing UnsupportedOperationException when using the coastlinefile option
Version 1846 was commited by wanmil on 2011-02-12 10:00:36 + (Sat, 12 Feb 2011) Fixing UnsupportedOperationException when using the coastlinefile option ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] coastlinefile option
Hello I'm trying to use a separate file with natural=coastline information. I then provide it to mkgmap using option: --coastlinefile=lithuania_coast.osm But I get this when executing: SEVERE (CoastlineFileLoader): lithuania_.osm: java.lang.UnsupportedOperationException java.lang.UnsupportedOperationException at java.util.AbstractCollection.add(AbstractCollection.java:238) at java.util.AbstractCollection.addAll(AbstractCollection.java:322) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.createConverter(OsmMapDataSource.java:251) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:131) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:69) at uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadFromFile(CoastlineFileLoader.java:90) at uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadFile(CoastlineFileLoader.java:119) at uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadCoastlinesImpl(CoastlineFileLoader.java:133) at uk.me.parabola.mkgmap.reader.osm.CoastlineFileLoader.loadCoastlines(CoastlineFileLoader.java:79) at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.init(SeaGenerator.java:135) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.pluginChain(OsmMapDataSource.java:158) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:126) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:69) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:145) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:217) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) I tried creating coastline file using JOSM. Then I tried modifying this file (removing elements with action="delete" etc.). The last thing I've tried was to provide the full data osm file (the one used to generate a map) as natural coastline just to check that file format is OK, but I was still getting the same error... Full command line when creating a map: java -jar mkgmap.jar \ --style-file=/home/tomas/garmin/tomas_style \ --gmapsupp \ --tdbfile \ --family-name=OpenStreetMap \ --description=Lietuva`date +%Y%m%d` \ --country-name=Lithuania \ --country-abbr=LTU \ --preserve-element-order \ --lower-case \ --charset=windows-1257 \ --route \ --add-pois-to-areas \ --generate-sea=multipolygon \ --coastlinefile=lithuania_.osm \ lithuania_.osm What am I doing wrong? What should the format of this coastline file be? Thank you P.S. This is using rev1838. -- Tomas Straupis ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
