Re: [mkgmap-dev] Regression causing Heap space exhaustion?
On 21/08/2009, at 23.26, Steve Ratcliffe wrote: > When support for relations was added the memory required increased. I > think that was added along with routing, I believe, which was in > version > 684 or thereabouts, so that will explain what you see. > > I don't use debian, but I just downloaded their package to have > a look at their mkgmap script. If you add the option -Xmx512m after > the $JAVACMD in the line: > > exec $JAVACMD -jar /usr/share/mkgmap/mkgmap.jar "$@" > > That should help. I've tried at 512M, 1024M, all the way up to 4096M, with the same result. The only difference is at 4G it takes much longer before mkgmap gives up. I don't think there's much point in going further than 4G, the problem must lie elsewhere. Thanks a lot for your suggestions so far! Cheers, Morten PS: I've put the Ubuntu sync-request on standby for now ( https://bugs.edge.launchpad.net/ubuntu/+source/mkgmap/+bug/416656 ) -- Morten Kjeldgaard Ubuntu MOTU Developer GPG Key ID: 404825E7 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Regression causing Heap space exhaustion?
On 22/08/2009, at 01.53, Greg Troxel wrote: > With splitter/mkgmap, the general strategy I use is: > > set heap size to a bit less than RAM, to avoid paging > > use --max-nodes to splitter to make small enough areas. > > > Here is the script I use (with a mac that has 4G physical ram): Great! Thanks, I will explore this and report back! In the meantime, I've run mkgmap on some of the files from geofabrik, here are the results when running the current svn version, using: java -Xmx1024m -jar mkgmap file.osm SizeFileResult -- 2,2Gdenmark.osm Fail 474M63240001.osm dk, split1 Fail 654Mnorway.osm Fail 629Mpoland.osm Fail 289Mbelgium.osm OK 266Mromania.osm OK 59M luxembourg.osm OK 4,8Mandorra.osm OK --- Although it seems that the problem is somewhat related to file size, there is no simple interpretation possible, since file #2 is less than twice the size of belgium.osm, but that fails even with 4x the amount of RAM for the VM. Also, there are probably great differences in the use of various tags in the different areas of the maps. Perhaps someone can see another pattern here. Cheers, Morten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Regression causing Heap space exhaustion?
Morten Kjeldgaard writes: > On 21/08/2009, at 23.26, Steve Ratcliffe wrote: > >> When support for relations was added the memory required increased. I >> think that was added along with routing, I believe, which was in >> version >> 684 or thereabouts, so that will explain what you see. >> >> I don't use debian, but I just downloaded their package to have >> a look at their mkgmap script. If you add the option -Xmx512m after >> the $JAVACMD in the line: >> >> exec $JAVACMD -jar /usr/share/mkgmap/mkgmap.jar "$@" >> >> That should help. > > I've tried at 512M, 1024M, all the way up to 4096M, with the same > result. The only difference is at 4G it takes much longer before > mkgmap gives up. I don't think there's much point in going further > than 4G, the problem must lie elsewhere. With splitter/mkgmap, the general strategy I use is: set heap size to a bit less than RAM, to avoid paging use --max-nodes to splitter to make small enough areas. Here is the script I use (with a mac that has 4G physical ram): #!/bin/sh cd $HOME/OSM || exit 1 # rm all img/tdb/etc. rm -f *.img *.tdb INPUT=$* ## SPLIT INPUT MAPS if [ "$INPUT" != "" -o ! -f template.args ]; then rm -f 63*.osm.gz if [ "$INPUT" = "" ]; then INPUT=`ls *.osm.bz2` fi rm -f areas.list template.args* echo "SPLITTING $INPUT:" time \ java \ -enableassertions \ -Xmx2000m \ -jar splitter.jar \ --max-nodes=160 \ $INPUT \ > OUT.01.splitter 2>&1 cp -pf template.args template.args.orig ed template.args < OUT.02.mkgmap 2>&1 echo OPTIONS not used: \ --overview-mapname=6324 - test default claim \ --ignore-osm-bounds \ ## PREPARE GMAPI FORMAT FOR ROADMAP mkdir -p GMAPI echo "GMAPI:" time \ /Users/gdt/SOFTWARE/GMAPIBUILDER/gmapi-builder/gmapi-builder.py \ -o GMAPI \ -t 6324.tdb \ -b 6324.img \ -v 6324*.img \ > OUT.03.gmapi 2>&1 echo "test-map:all-elements" export BASE_LAT=42.0 export BASE_LONG=-70.0 time \ java \ -enableassertions \ -Xmx2048m \ -jar mkgmap.jar \ --overview-mapname=6350 \ --mapname=6351 \ --description="OSM_test" \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="MA" \ --region-name="Massachusetts" \ --series-name="OSM_test_series" \ --family-id=402 \ --family-name="OSM_test_family" \ --product-id=14 \ --series-name="OSM_test_series" \ --area-name="OSM_test_area" \ --tdbfile \ test-map:all-elements > OUT.04.mkgmap 2>&1 mkdir -p GMAPI-TEST echo "GMAPI-TEST:" time \ /Users/gdt/SOFTWARE/GMAPIBUILDER/gmapi-builder/gmapi-builder.py \ -o GMAPI-TEST \ -t 6350.tdb \ -b 6350.img \ -v 6350*.img \ > OUT.05.gmapi-test 2>&1 pgp5Fry5HGRNx.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - support for extended type attributes
Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below) mkgmap:xt-light-type (a type name from list LT below) mkgmap:xt-period (optional period in secs (not limited to integer) Point types 0x0103xx (entities with depth/height) and 0x0104xx (obstructions) mkgmap:xt-depth (a depth with optional units (ft or m) default is m) mkgmap:xt-height (alias for, and mutually exclusive to, xt-depth) mkgmap:xt-position (an optional position from list P below) These attributes are turned into a sequence of bytes that are embodied in the map object. For testing purposes you can also specify those bytes explicitly as a sequence of hex digits using the mkgmap:xt-extra-bytes tag but you won't want to use that unless you are working on attribute value encoding (like me!) Next up will be lights which I understand how to encode except for multiple lights and angles - still working on that. Then will come lines and areas. All feedback welcome. BTW a good source of info is the cgpsmapper manual which is readily available on the net. It has a chapter on marine types. - List FC "red", "green", "yellow", "white", "black", "black-yellow", "white-red", "black-red", "white-green", "red-yellow", "red-green", "orange", "black-yellow-black", "yellow-black", "yellow-black-yellow", "red-white", "green-red-green", "red-green-red", "black-red-black", "yellow-red-yellow", "green-red", "black-white", "white-orange", "orange-white", "green-white" List LC "unlit", "red", "green", "white", There is possibly some more light colours but I don't yet know how to encode them so we should stick with these for the moment. List LT "fixed", "isophase", "flashing", "group flashing", "composite group flashing", "occulting", "group occulting", "composite group occulting", "long flashing", "group long flashing", "morse", "quick", "group quick", "group quick and long flashing", "interrupted quick", "very quick", "group very quick", "group very quick and long flashing", "interrupted very quick", "ultra quick", "interrupted ultra quick", "fixed and occulting", "fixed and group occulting", "fixed and isophase", "fixed and flashing", "fixed and group flashing", "fixed and long flashing", "alternating", "alternating occulting", "alternating flashing", "alternating group flashing" The morse type takes a letter argument but I don't know how to encode that yet. List P "unknown", "doubtful", "existence doubtful", "approximate", "reported" diff --git a/src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java b/src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java new file mode 100644 index 000..aadde77 --- /dev/null +++ b/src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java
Re: [mkgmap-dev] Regression causing Heap space exhaustion?
On 21/08/2009, at 23.26, Steve Ratcliffe wrote: > When support for relations was added the memory required increased. I > think that was added along with routing, I believe, which was in > version > 684 or thereabouts, so that will explain what you see. > > I don't use debian, but I just downloaded their package to have > a look at their mkgmap script. If you add the option -Xmx512m after > the $JAVACMD in the line: > > exec $JAVACMD -jar /usr/share/mkgmap/mkgmap.jar "$@" > > That should help. I've tried at 512M, 1024M, all the way up to 4096M, with the same result. The only difference is at 4G it takes much longer before mkgmap gives up. I don't think there's much point in going further than 4G, the problem must lie elsewhere. Thanks a lot for your suggestions so far! Cheers, Morten -- Morten Kjeldgaard Ubuntu MOTU Developer GPG Key ID: 404825E7 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Sea Polygons and java 1.6
Hi The sea polygon patch uses a feature from java 1.6 (NavigableSet), whereas mkgmap is currently released for java 1.5. Perhaps there is a different way to do it that avoids the use, but it could be time to consider going to 1.6. Now I don't personally mind going to 1.6 and in fact I announced that this would 'happen soon' over a year ago. The only problem is people with Macs. As I have experienced with splitter (which always has required 1.6) there were quite a few queries to the mailing list and to my own email address from people not being able to run it. As there are many more downloads of mkgmap than splitter, I expect that there would be far more queries generated for mkgmap. Now as far as I know, it is no longer a problem getting 1.6 for all Macs, so I don't think anyone will be unable to run it, it is just a case of knowing what to download from where for which Mac 32/64 bit etc. So if we were to start requiring 1.6 I would like to prepare by adding a specific error message to mkgmap stating the version requirements, rather than just a stack trace that you would currently see, and to get a description of how to obtain 1.6 for the different Macs that can be placed on the wiki and web site etc. What do you think? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Regression causing Heap space exhaustion?
On 08/21/2009 09:26 AM, Morten Kjeldgaard wrote: > The default version of mkgmap distributed with Ubuntu 9.04 (jaunty) is > svn630. I tried upgrading to version svn1067 which has recently appeared > in Debian unstable, but now I get a Java heap space exception on the > _same_ .osm file that worked before. When support for relations was added the memory required increased. I think that was added along with routing, I believe, which was in version 684 or thereabouts, so that will explain what you see. I don't use debian, but I just downloaded their package to have a look at their mkgmap script. If you add the option -Xmx512m after the $JAVACMD in the line: exec $JAVACMD -jar /usr/share/mkgmap/mkgmap.jar "$@" That should help. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Regression causing Heap space exhaustion?
On 21/08/2009, at 13.20, Greg Troxel wrote: >> The default version of mkgmap distributed with Ubuntu 9.04 (jaunty) >> is >> svn630. I tried upgrading to version svn1067 which has recently >> appeared in Debian unstable, but now I get a Java heap space >> exception on the _same_ .osm file that worked before. >> >> The map I was working with is the latest denmark.osm from >> geofabrik. The command I used was: >> >> mkgmap --gmasupp --latin1 --route --make-all-cycleways denmark.osm >> >> I tried omitting "--route" but that didn't change things. > > A lot has changed since r630. I suspect more items from the same .osm > will get turned into .img objects. So the fact that the previous > version fit in some amount of memory and the new one doesn't isn't > really a bug per se. > > If you could find the smallest one that works with both r630 and r1067 > that would be interesting. Being a neophyte wrt. the use of mkgmap, you'll have to give me some hints on how to create "the smallest thing". I tried running the splitter on denmark.osm, which created 3 pieces, but it did not help. Cheers, Morten -- Morten Kjeldgaard Ubuntu MOTU Developer GPG Key ID: 404825E7 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1142: Always
Version 1142 was commited by steve on 2009-08-21 19:32:36 +0100 (Fri, 21 Aug 2009) BRANCH: multipolygon Always ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Strange issue when searching for POI
Hello, I own a Garmin Vista HCx and I have generated a map around my area from SOM using mkgmap. When I search for a POI I see a strange behavior: if I use "Nearest containing..." or "Select Category", the POIs show up correctly. If I use "Find by name" no POI show up in the list. Is there something I should chaange in the way I use mkgmap to solve this? Thanks in advance, N. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overflowed directory error
Carlos Dávila escribió: > char...@cferrero.net escribió: > >> Quoting Carlos Dávila : >> >> >> >>> Hello all >>> While compiling a map from 6 tiles obtained with splitter (manually >>> adjusted areas.list) I get the following error: >>> GRAVE (BlockManager): overflowed directory with max block 65534, >>> current=65535 >>> There is not enough room in a single garmin map for all the input data >>>The .osm file should be split into smaller pieces first. >>> I guess I must split some of the tiles but, how to know which one? Does >>> it depend on the size (in MB) of the resulting maps? >>> Regards >>> Carlos >>> >>> >> I also create manual areas.list files. My experience is that even if >> I set max-nodes smaller in splitter, it can still create tiles that >> are too big for mkgmap. My rule of thumb is that no tile created by >> splitter should be bigger than ~20MB (compressed, obviously). This >> makes it easy to spot tiles that are too big and I've not (yet) had >> mgkmap fail when applying this rule. >> > Thanks for the figure. I'm currently splitting the same input osm with a > new areas.list. I'll take your size into account before processing tiles > with mkgmap (previously I had one of 28 MB, thus the overflow). Just for information, with a compressed input file of 25 MB I had no problem. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Am 21.08.2009 um 12:43 schrieb Felix Hartmann: > Is noone else using these features? Thilo, what about you? Are you > able to use 1140 as a base? Hi Felix, sorry, I didn't see that thread earlier. The feature with the relations that you are using was never integrated into trunk. I assume that it is the generate_ways_from_relations.patch that I posted some time ago on this list. I'm using it, but it probably doesn't compile with 1140 right now. Too much has changed. I'm still busy with the "merging of similar ways" patch so that I don't update mkgmap for now, but stay at revision 1136. It would be too much work to keep all my patches in working order with relevant code files of mkgmap changing all the time. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r1135: Patch by Rudi for problems with multipolygons
Hi > In the patch, this solution is applied when the number > of points is less than 32. > > Is that an exactly determined number, or is it > just a rough estimate of where things start to go wrong? I think the problem might be that the polygon splitting goes wrong when the lines touch. Only large polygons are split, so that could explain the size related aspect. The multipoly_test3.osm file (which has less than 32 points but is very large) works perfectly without any further patching if I modify your patch to always use the shifted points. It may be possible to modify the splitting code to work, but I will just change the 32 to a 0 for now and see if that helps with the sea polygons too. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug or feature?
Steve, Steve Ratcliffe schreef: > It works as intended, so I guess it must be a documentation bug ;) Good, I'll send a patch. My English is still better than my java programming skills (Or so I think ;) > Hope that makes it all clear. It does. Thank you very much. V. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overflowed directory error
char...@cferrero.net escribió: > Quoting Carlos Dávila : > > >> Hello all >> While compiling a map from 6 tiles obtained with splitter (manually >> adjusted areas.list) I get the following error: >> GRAVE (BlockManager): overflowed directory with max block 65534, >> current=65535 >> There is not enough room in a single garmin map for all the input data >>The .osm file should be split into smaller pieces first. >> I guess I must split some of the tiles but, how to know which one? Does >> it depend on the size (in MB) of the resulting maps? >> Regards >> Carlos >> > I also create manual areas.list files. My experience is that even if > I set max-nodes smaller in splitter, it can still create tiles that > are too big for mkgmap. My rule of thumb is that no tile created by > splitter should be bigger than ~20MB (compressed, obviously). This > makes it easy to spot tiles that are too big and I've not (yet) had > mgkmap fail when applying this rule. Thanks for the figure. I'm currently splitting the same input osm with a new areas.list. I'll take your size into account before processing tiles with mkgmap (previously I had one of 28 MB, thus the overflow). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug or feature?
Hi > I guess I found out that > --description > does not work when using a "-c template-file". Is this a bug or a > feature, i.e. does the source need to be patched or should I patch the > documentation? (I'm willing to do the latter, but not if a fix in the > source is really easy). It works as intended, so I guess it must be a documentation bug ;) What I expected to happen is that people would copy the template-file and edit it to include all the options, set the descriptions, mapname etc. as desired and then use that file with -c, rather than putting all the options on the command line. The best way to think about the template-file is that is just another way of specifying a lot of options in a more convenient way. For example if you have a file with the following contents: -=- mapname: 63240001 description: OSM Map 1 input-file: 63240001.osm.gz mapname: 63240002 description: OSM Map 2 input-file: 63240002.osm.gz -=- Then the command: java -jar mkgmap.jar -c file is *exactly* the same as saying: java -jar mkgmap.jar --mapname=63240001 --description="OSM Map 1" 63240001.osm.gz --mapname=63240002 --description="OSM Map 2" 63240002.osm.gz Options are read from left to right, and the options in force when a file is read are the ones that apply. So in this case 63240001.osm.gz will be compiled with a mapname of 63240001 and a description of "OSM Map 1", and 63240002.osm.gz will have the mapname of 63240002 and a description of 'OSM Map 2'. You can mix command line options and options in a file, there is nothing wrong with that. If you do so then still work as though you were reading from left to right and inserting the content of the file at the point it is read. So the command: java -jar mkgmap.jar --description="My Map" -c file --description="Third map" 63240003.osm.gz is exactly the same as: java -jar mkgmap.jar --description="My Map" --mapname=63240001 --description="OSM Map 1" 63240001.osm.gz --mapname=63240002 --description="OSM Map 2" 63240002.osm.gz --description="Third map" 63240003.osm.gz Now you can see that the first --description (My Map) is not used because it is the second one (which has the value 'OSM Map 1') that is the one that gets used to build the first map. If the file did not contain either of the 'description' lines, then the first and second maps would have the name 'My Map' and the third one would still have the description of 'Third map' Hope that makes it all clear. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overflowed directory error
Quoting Carlos Dávila : > Hello all > While compiling a map from 6 tiles obtained with splitter (manually > adjusted areas.list) I get the following error: > GRAVE (BlockManager): overflowed directory with max block 65534, > current=65535 > There is not enough room in a single garmin map for all the input data >The .osm file should be split into smaller pieces first. > I guess I must split some of the tiles but, how to know which one? Does > it depend on the size (in MB) of the resulting maps? > Regards > Carlos I also create manual areas.list files. My experience is that even if I set max-nodes smaller in splitter, it can still create tiles that are too big for mkgmap. My rule of thumb is that no tile created by splitter should be bigger than ~20MB (compressed, obviously). This makes it easy to spot tiles that are too big and I've not (yet) had mgkmap fail when applying this rule. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Steve, > Mark, great work on implementing the extended types. Thanks, still more goodies to come as I have now moved on to the encoding of various xtype attributes (depth/height, various colours, buoy/light types, etc.) Making good progress. > As for this problem, I don't see it. With a simple style that > only includes one line type with overlays it works just fine. Same > with relations. > > Also looking at the code change, there is nothing that appears to > touch that area of the styling at all. Yes, I can't see how the xtype stuff could have broken those features. > Felix, I don't mind looking into it, but I will need a lot more > information including the complete style, an input file that doesn't > work and an example of a road that doesn't work in the new version. It would be great if you could help there. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overflowed directory error
Clinton Gladstone escribió: > 2009/8/21 Carlos Dávila : > >> Hello all >> While compiling a map from 6 tiles obtained with splitter (manually >> adjusted areas.list) I get the following error: >> GRAVE (BlockManager): overflowed directory with max block 65534, >> current=65535 >> There is not enough room in a single garmin map for all the input data >> The .osm file should be split into smaller pieces first. >> I guess I must split some of the tiles but, how to know which one? Does >> it depend on the size (in MB) of the resulting maps? >> > > My understanding is that this is not directly related to the size in > MB of the map, but of the complexity of the individual tiles (number > of nodes, etc.). Normally, if you use splitter to automatically > generate the tiles, you can lower the --max-nodes values until the map > correctly compiles. > > However in your case, since you are using a manually adjusted > areas.list file, you cannot do this so easily. But since mkgmap > normally generates the tiles more or less sequentially, can you not > see on which .img file mkgmap died? > In a first sight all maps seemed to be correct, at least in MapSource, but some route calculation is not working. I'll reduce the bbox of some tiles and see what happens. > Hope this helps. > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Mark, great work on implementing the extended types. As for this problem, I don't see it. With a simple style that only includes one line type with overlays it works just fine. Same with relations. Also looking at the code change, there is nothing that appears to touch that area of the styling at all. Felix, I don't mind looking into it, but I will need a lot more information including the complete style, an input file that doesn't work and an example of a road that doesn't work in the new version. > Overlays. I mean the overlays file in the style-files. Before 1139 if > you had a line in your lines file saysing for example: > highway=footway & highway=cycleway [0x123 resolution 20] you could now > define in the overlays file 0x123: 0x2a, 0x0c > and both 0x2a and 0x0c were included in the map at the same place. So if > your footway looks like 0x0x0x (with 0 being transparent in typfile, and > x being a color) and cycleway y0y0y0 (with y being another color), the > result would be both footway and cycleway rendered as yxyxyx. > > routes... ups sorry should have said relations. Anything written to the > relations file is not enacted anymore. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] bug or feature?
Hi list, I guess I found out that --description does not work when using a "-c template-file". Is this a bug or a feature, i.e. does the source need to be patched or should I patch the documentation? (I'm willing to do the latter, but not if a fix in the source is really easy). Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
On Fri, Aug 21, 2009 at 12:43 PM, Felix
Hartmann wrote:
> routes... ups sorry should have said relations. Anything written to the
> relations file is not enacted anymore.
I was at least able to get some simple items working in the relations
file with r1140, for example the following:
route=railway_track {apply {add blarg='hello'}}
Unfortunately, I have not used relations previously, so I can't
comment on how the behaviour has changed. I tried something like the
following though, which seemed similar to what you do in your
relations file:
route=railway_track {apply {add blarg='hello'}} [0x06 resolution 20]
This did not work with r1140, but it also did not work when I tried it
with an earlier release (1131). Are you using some special patches
which may have altered or corrected the behaviour of the relations
file? (I, of course, admit that I might be doing things completely
incorrectly in my attempts to reproduce the problem.)
Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Regression causing Heap space exhaustion?
Morten Kjeldgaard writes: > The default version of mkgmap distributed with Ubuntu 9.04 (jaunty) is > svn630. I tried upgrading to version svn1067 which has recently > appeared in Debian unstable, but now I get a Java heap space > exception on the _same_ .osm file that worked before. > > The map I was working with is the latest denmark.osm from > geofabrik. The command I used was: > > mkgmap --gmasupp --latin1 --route --make-all-cycleways denmark.osm > > I tried omitting "--route" but that didn't change things. A lot has changed since r630. I suspect more items from the same .osm will get turned into .img objects. So the fact that the previous version fit in some amount of memory and the new one doesn't isn't really a bug per se. If you could find the smallest one that works with both r630 and r1067 that would be interesting. pgpZYxiyTRZz2.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Felix, > Overlays. I mean the overlays file in the style-files. Before 1139 if you > had a line in your lines file saysing for example: > highway=footway & highway=cycleway [0x123 resolution 20] you could now > define in the overlays file 0x123: 0x2a, 0x0c > and both 0x2a and 0x0c were included in the map at the same place. So if > your footway looks like 0x0x0x (with 0 being transparent in typfile, and x > being a color) and cycleway y0y0y0 (with y being another color), the result > would be both footway and cycleway rendered as yxyxyx. > > routes... ups sorry should have said relations. Anything written to the > relations file is not enacted anymore. Thanks for spelling this out for me. I'm such an airhead that I didn't even know these features existed! I have looked at the overlay stuff and still can't see why the extended type code should break it so, at the moment, it remains a mystery. I shall keep thinking about it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
2009/8/21 Mark Burton > > Felix, > > > No I'm still unable to get routes and overlays to show up on the map. > > > > either using 1140 with multiple elements patch (no other patches), nor > with > > clean svn version. > > That's sad. > > I don't know what you mean by routes or overlays so I can't imagine > what the problem is. If you could supply more info about what you are > doing, perhaps it will become clear. Is it a styling issue? Related to > types? Give me a clue. > > Is anyone else seeing issues with 1140? > > Cheers, > > Mark > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > Overlays. I mean the overlays file in the style-files. Before 1139 if you had a line in your lines file saysing for example: highway=footway & highway=cycleway [0x123 resolution 20] you could now define in the overlays file 0x123: 0x2a, 0x0c and both 0x2a and 0x0c were included in the map at the same place. So if your footway looks like 0x0x0x (with 0 being transparent in typfile, and x being a color) and cycleway y0y0y0 (with y being another color), the result would be both footway and cycleway rendered as yxyxyx. routes... ups sorry should have said relations. Anything written to the relations file is not enacted anymore. Is noone else using these features? Thilo, what about you? Are you able to use 1140 as a base? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overflowed directory error
2009/8/21 Carlos Dávila : > Hello all > While compiling a map from 6 tiles obtained with splitter (manually > adjusted areas.list) I get the following error: > GRAVE (BlockManager): overflowed directory with max block 65534, > current=65535 > There is not enough room in a single garmin map for all the input data > The .osm file should be split into smaller pieces first. > I guess I must split some of the tiles but, how to know which one? Does > it depend on the size (in MB) of the resulting maps? My understanding is that this is not directly related to the size in MB of the map, but of the complexity of the individual tiles (number of nodes, etc.). Normally, if you use splitter to automatically generate the tiles, you can lower the --max-nodes values until the map correctly compiles. However in your case, since you are using a manually adjusted areas.list file, you cannot do this so easily. But since mkgmap normally generates the tiles more or less sequentially, can you not see on which .img file mkgmap died? Hope this helps. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Felix, > No I'm still unable to get routes and overlays to show up on the map. > > either using 1140 with multiple elements patch (no other patches), nor with > clean svn version. That's sad. I don't know what you mean by routes or overlays so I can't imagine what the problem is. If you could supply more info about what you are doing, perhaps it will become clear. Is it a styling issue? Related to types? Give me a clue. Is anyone else seeing issues with 1140? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
2009/8/21 Mark Burton > > Hi Felix, > > Is this still a problem or did it get better? > > Cheers, > > Mark > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > No I'm still unable to get routes and overlays to show up on the map. either using 1140 with multiple elements patch (no other patches), nor with clean svn version. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1141: Avoid NPE if no name tag present when processing mkgmap:gtype.
Version 1141 was commited by markb on 2009-08-21 09:49:12 +0100 (Fri, 21 Aug 2009) Avoid NPE if no name tag present when processing mkgmap:gtype. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Felix, Is this still a problem or did it get better? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Regression causing Heap space exhaustion?
Hi, The default version of mkgmap distributed with Ubuntu 9.04 (jaunty) is svn630. I tried upgrading to version svn1067 which has recently appeared in Debian unstable, but now I get a Java heap space exception on the _same_ .osm file that worked before. The map I was working with is the latest denmark.osm from geofabrik. The command I used was: mkgmap --gmasupp --latin1 --route --make-all-cycleways denmark.osm I tried omitting "--route" but that didn't change things. Cheers, Morten -- Morten Kjeldgaard Ubuntu MOTU Developer GPG Key ID: 404825E7 mkgmap.log Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
