Re: [mkgmap-dev] Problems with latest splitter versions
On Thu, 03 Mar 2011 00:36:10 +0100, Michael Prinzing wrote: 2.) File containing contour data cannot be processed The problem that the splitter did not finish with only a single thread is solved now, but the problem with the splitter crashing on some data still exists. I could track it down to a very simple example. When I am trying to split the following data: -- ?xml version='1.0' encoding='UTF-8'? osm version=0.6 generator=Osmosis 0.38 node id=2073742179 version=1 timestamp=2011-03-03T22:05:10Z lat=50.8776211 lon=6.093/ node id=2073742180 version=1 timestamp=2011-03-03T22:05:10Z lat=50.88 lon=6.0969358/ node id=2073742181 version=1 timestamp=2011-03-03T22:05:10Z lat=50.8859414 lon=6.107/ node id=2073742182 version=1 timestamp=2011-03-03T22:05:10Z lat=50.8922471 lon=6.12/ node id=2073742183 version=1 timestamp=2011-03-03T22:05:10Z lat=50.893 lon=6.1235571/ way id=20 version=1 timestamp=2011-03-03T22:05:10Z nd ref=2073742179/ nd ref=2073742180/ nd ref=2073742181/ nd ref=2073742182/ nd ref=2073742183/ tag k=contour v=elevation/ tag k=contour_ext v=medium/ tag k=level v=5/ tag k=ele v=200/ /way /osm -- I am getting the following: -- java -jar splitter.jar test.osm cache= description= geonames-file= legacy-mode=false mapid=63240001 max-areas=255 max-nodes=160 max-threads=1 (auto) mixed=false no-trim=false output-dir= overlap=2000 resolution=13 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 15MB (1MB used, 14MB free) Max 247MB Time started: Fri Mar 04 02:32:06 CET 2011 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing test.osm in 1 file Time: Fri Mar 04 02:32:06 CET 2011 Exact map coverage is (50.87762117385864,6.093313694000244) to (50.89332818984985,6.123547554016113) Trimmed and rounded map coverage is (50.888671875,6.064453125) to (50.9765625,6.15234375) Splitting nodes into areas containing a maximum of 1.600.000 nodes each... Area (50.888671875,6.064453125) to (50.9765625,6.15234375) contains 2 nodes. DONE! 1 areas: Area 63240001 covers (0x243000,0x45000) to (0x244000,0x46000) Writing out split osm files Fri Mar 04 02:32:06 CET 2011 Processing 1 areas in a single pass Starting pass 1 of 1, processing 1 areas (63240001 to 63240001) Making SparseMultiMap Making SparseMultiMap Processing test.osm Exception in thread main java.lang.ArrayIndexOutOfBoundsException: Start index (-30655339) is negative at it.unimi.dsi.fastutil.Arrays.ensureFromTo(Arrays.java:45) at it.unimi.dsi.fastutil.objects.ObjectArrays.ensureFromTo(ObjectArrays.jav a:351) at it.unimi.dsi.fastutil.objects.ObjectArrays.fill(ObjectArrays.java:313) at it.unimi.dsi.fastutil.objects.ObjectArrayList.size(ObjectArrayList.java: 308) at uk.me.parabola.splitter.SparseInt2ShortMapInline.resizeTo(SparseInt2Shor tMapInline.java:96) at uk.me.parabola.splitter.SparseInt2ShortMapInline.put(SparseInt2ShortMapI nline.java:123) at uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2Shor tMultiMap.java:81) at uk.me.parabola.splitter.SparseInt2ShortMultiMap.put(SparseInt2ShortMulti Map.java:31) at uk.me.parabola.splitter.SplitProcessor.writeNode(SplitProcessor.java:209 ) at uk.me.parabola.splitter.SplitProcessor.processNode(SplitProcessor.java:1 18) at uk.me.parabola.splitter.OSMParser.endElement(OSMParser.java:243) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:5 7) at uk.me.parabola.splitter.Main.processMap(Main.java:399) at uk.me.parabola.splitter.Main.writeAreas(Main.java:355) at uk.me.parabola.splitter.Main.split(Main.java:188) at uk.me.parabola.splitter.Main.start(Main.java:116) at uk.me.parabola.splitter.Main.main(Main.java:105) -- Is there a limit for Node-IDs and Way-IDs lower than 2^32 that was introduced after r161? Michael ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recommended version?
On 04/03/11 08:28, NopMap wrote: Hi! I'm packing an update of my beginners' tool set and so I am here with my ususal question: Which version of mkgamp would you recommend as reliable? We should update the wiki to 1867, just before the index merge as there is still an issue on some devices after the index merge. I'll do the English page, could someone do the same for the other languages please. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1879: Handle relations with type=boundary as multipolygons
On Thu, Mar 03, 2011 at 08:27:50PM +, svn commit wrote: Handle relations with type=boundary as multipolygons For what it is worth, this issues quite a few multipolygon error messages in country extracts. For Finland, I will go them through and blacklist them in my logging.ignore one by one. In JOSM, I hit Ctrl-L and type http://api.openstreetmap.org/api/0.6/relation/397159 and so on. I am omitting the /full from the URL on purpose, because it suffices for me to see the relation attributes. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1879: Handle relations with type=boundary as multipolygons
On Fri, Mar 04, 2011 at 01:55:22PM +0200, Marko Mäkelä wrote: In JOSM, I hit Ctrl-L and type http://api.openstreetmap.org/api/0.6/relation/397159 and so on. I found a faster method, loading a file like this: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' relation id='-1' action='modify' timestamp='2011-03-04T12:22:00Z' visible='true' member type='relation' ref='37355' role='' / member type='relation' ref='38090' role='' / /relation /osm Then, in the relation editor, download all incomplete members. It will only load the child relations, not their children. All were listed as 'boundary' in the relation editor. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Preparing patches (Re: POIs for areas)
Marko Mäkelä schrieb am 03.03.2011 22:54: Could you elaborate what your patch does? Does it remove the option add-pois-to-areas altogether? Even though an add_poi action would replace add-pois-to-areas, I think that we should support both forms for some time. Sadly this patch disables the add-pois-to-areas option completely. I also would like to have both capabilities for backward compatibiliy, but in the style processing the command line arguments are not visible at the moment. So there is no easy way for testing either whether the addpoi command is set in the style or whether the command line argument is set. The trunk version generates in the style processing the basis for the POI generation for ALL objects regardless the command line argument. During the map generation the command line argument is test, for whether the available POIs are generated or not. In my patch during the style creation only the basis for the POI generation of the objects with the addpoi command is created. And during the map generation a POI is ALWAYS created, if for an object the corresponding basis is found. You may ignore the rest of this message. I did a too quick read of the patch and thought that you had changed accidentally white space in some lines. You did that on purpose, because you removed one level of indentation when removing the check for the add-pois-to-areas parameter. I have read the rest of your message, but probably only understood half of it. (I am neither familiar with eclipse nor with svn, so I hardly now what I am doing when building my own mkgmap.) What is the desired approach on the indentation when a patch has such a structure change like removing an if-bracketing? In my change I also corrected the indentation of otherwise unchanged lines. Shouldn't such changes be included in the patch? If they are not included, how is the indentation then corrected? Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Preparing patches (Re: POIs for areas)
On Fri, Mar 4, 2011 at 8:48 AM, Torsten Leistikow de_m...@gmx.de wrote: What is the desired approach on the indentation when a patch has such a structure change like removing an if-bracketing? Changing indentation when removing a nesting level is fine, but it should be confined to the area where the nesting was removed. In my change I also corrected the indentation of otherwise unchanged lines. Shouldn't such changes be included in the patch? If they are not included, how is the indentation then corrected? Whitespace-only changes should be included in a separate patch that does not change any functionality. That makes it easier to review changes. -- Jeff Ollie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Preparing patches (Re: POIs for areas)
Jeffrey Ollie schrieb am 04.03.2011 16:09: Whitespace-only changes should be included in a separate patch that does not change any functionality. That makes it easier to review changes. Thanks for the clarification. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
Hi, On Wed, Mar 02, Thorsten Kukuk wrote: On Wed, Mar 02, Steve Ratcliffe wrote: There have now been a few reports of problems searching on some devices with the latest version of mkgmap. It seems that it occurs when a gmapsupp.img is created directly by mkgmap and sent to the device. In other words the index itself has nothing to do with the problem, if this is correct. I see this with --index and without --index. So yes, it looks like the index itself has nothing to do with the problem. Going back to mkgmap-r1866 solved the problem for both cases for me. If this helps: with mkgmap-r1863 from the index branch the 62s is already crashing. Is there any special version I should test to help to find out, when this problem was introduced? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recommended version?
Am 04.03.2011 12:45, schrieb Steve Ratcliffe: On 04/03/11 08:28, NopMap wrote: Hi! I'm packing an update of my beginners' tool set and so I am here with my ususal question: Which version of mkgamp would you recommend as reliable? We should update the wiki to 1867, just before the index merge as there is still an issue on some devices after the index merge. I'll do the English page, could someone do the same for the other languages please. ..Steve I've done that for the German page. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
On Fri, Mar 04, Steve Ratcliffe wrote: Knowing if 1825 breaks might be a good clue, I've built a version at: http://files.mkgmap.org.uk/download/9/mkgmap-index-r1825.jar Build is running. Sorry, this is going to be a difficult one to solve as nothing unusual happens on my Legend. No problem, I can help bisecting this if time permits. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
OK, that is fairly close to the current version in areas that I expect might make a difference so I'm not too surprised. Knowing if 1825 breaks might be a good clue, I've built a version at: http://files.mkgmap.org.uk/download/9/mkgmap-index-r1825.jar This seems to work ok for me. No crashes with city search and address search produces sensible results as normal Cheers Paull ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [index] Automatic location completion
El 03/03/11 20:40, WanMil escribió: I have improved calculation of the country information. In case no country information is available the most used country in a tile is used for all elements without country tag. The patch now patches the trunk and no longer the index branch. I have observed that lots of POIs are assigned the default country although I they are assigned a different country. I have no clue where this happens. Maybe an index related problem? I was hoping that Steves commit today would fix that problem but it didn't. My findings with your v3 patch: 1-Streets are now correctly assigned to cities, instead of suburbs or nearest (wrong) cities. Great! 2-State/Province field now includes regions and provinces, not only regions as with v2 of your patch. Spanish regions (admin_level=4 according to [1]) are formed by one or generally more than one province (admin_level=6), so every province is part of a region. According to that, a place found in a province should also be found in the matching region, but this is not the case; some places are assigned to provinces and others are assigned to regions. 3-A new country has appeared in the Mediterranean coast of Spain, called Maresme;Barcelona;Catalunya;España (coming from node 418639079 or way 37229141). Another buggy new country is Vega de Valcarce;León;Castilla y León;España,Europe (node 474558975) 4-España and Europe are found under State/Province. 5-The problem with State/Province info not taken into account when the country field is filled in any of the search tabs remains. [1] http://wiki.openstreetmap.org/wiki/Key:admin_level#admin_level ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Include the following patches into trunk -- Patch4 - decrease douglas peucker error
Am 03.03.2011 22:56, schrieb Felix Hartmann: On 03.03.2011 22:37, Felix Hartmann wrote: For lines it works perfect. But somehow polygons really get munged and destructed (lots of straight line holes - that are fewer without this patch). Could you check what is going on for polygons? For polygons the old algo should be used, it looks like it would be even worse than the straight line algo has ever been before. Sorry, for my complaint. Polygons are nice up to level 21. But really bad from level 20 down. The new aggressive filter should only be for lines, not for polygons as it does not work well for them. As for lines it does work well though. No idea, what goes wrong in your case. I didn't expect big differences for polygons at resolutions =20. In my test cases there I can't see any difference. I have just tested. Polygons looks a bit ugly with or without the recent change. I know, that the dp filter is not really optimal for cleaning up polygons in general. Maybe needs an other approach... Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
Thorsten Kukuk ku...@suse.de wrote: On Fri, Mar 04, Steve Ratcliffe wrote: Knowing if 1825 breaks might be a good clue, I've built a version at: http://files.mkgmap.org.uk/download/9/mkgmap-index-r1825.jar Build is running. Ok: - No Crash - City-Search is working fine - Address-Search in the limited range is working as before What's not working: The TYP file is ignored :(. gmt shows it is there and everything is correct, but still it is not used. Thanks. By the way that was actually 1852 not 1825 If you would be so good to try out 1853 that would be helpful (it is particular suspicion I have - if its not that then I will go back to bisecting properly :) Sorry, took a little bit longer since I did a retest with 1852 first, since the TYP file problem didn't looked correct. Now that is working again. Now I have: 1852: everything works fine, no crash, city search works correct, address search in the known limited range 1853: Searching for a special city either leads immeaditly to a crash, or no city at all is displayed/found. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Hi That's great. It's a very small change so clear what the problem is. As for what to do about it is a different matter since that change is essential in some circumstances. Anyway - progress. Thanks Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
On 04/03/11 19:02, Steve Ratcliffe wrote: Hi Knowing if 1825 breaks might be a good clue, I've built a version at: http://files.mkgmap.org.uk/download/9/mkgmap-index-r1825.jar Build is running. Ok: - No Crash - City-Search is working fine - Address-Search in the limited range is working as before What's not working: The TYP file is ignored :(. gmt shows it is there and everything is correct, but still it is not used. Thanks. By the way that was actually 1852 not 1825 If you would be so good to try out 1853 that would be helpful (it is particular suspicion I have - if its not that then I will go back to bisecting properly :) http://files.mkgmap.org.uk/download/10/mkgmap-index-1853.jar Thanks ..Steve Your suspicion would seem to be correct. With index-1853 city search crashes my 605 and the address search returns no results Cheers Paul ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
