Re: [mkgmap-dev] Optimizing MapSplitter
Hi Steve, I don't think that the current algo is completely wrong. I think it is better to start with the complete data and divide it into smaller parts as that algo keeps the information of the location of elements, while your approach is likely to compare many bboxes which are (too) far away from each other. I think my last patch (mapsplit-mini-v2.patch) does not work because of probems with high precision coordinates, but it also is too simple. I am now working on a more complex one. Gerd Date: Fri, 14 Nov 2014 12:05:08 + From: st...@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Optimizing MapSplitter Hi I think I'll try to change this: 1) Put large objects (large bbox, maybe only few points as with 0x4b background polygon) into there own sub divs and don't add small objects to those sub divs 2) Create smaller sub divisions in dense areas I've been thinking of this way 1. Start with everything in its own subdivision. 2. For each subdivision: Find other subdivisions that completely contain it. ...but ignore subdivisions that are too big. Combine the subdivision into the smallest of those found that still have room. 3. Repeat enough times. - too big: a desktop zoomed to just the level covers less than 100 square units. My etrex 30 covers about 4 square units if I measured it correctly. So I would guess that divs can be freely combined up to those kinds of sizes. But for larger containing divs, you would probably want to make sure that all elements are at least 50% of the size of the division. - enough: I've no idea what that would mean or even if this would work at all! I don't know yet how to do that, so I'll sleep about about again ;-) Yes that is the problem! ..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] Optimizing MapSplitter
Hi Andrzej, yes, I did not test with your data yesterday and did not notice an old problem with high precision coordinates. Attached is a new patch that implements both changes which I suggested here: http://gis.19327.n5.nabble.com/Optimizing-MapSplitter-tp5823702p5824224.html I am not sure about the criteria. The line final int LARGE_OBJECT_DIM = 1024; gives a measurement for large objects in map units. Each large object is placed in its own sub div. The line int wantedSize = MAX_RGN_SIZE / 10; // smaller values result in more sub divs determines the approx. number of bytes in one sub div. A value near 0 means many very small sub divs, a value near MAX_RGN_SIZE is what the trunk version uses. Maybe we have to create parameters for them. Gerd Date: Fri, 14 Nov 2014 22:54:38 +0100 From: po...@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Optimizing MapSplitter Hi Gerd, your second patch doesn't work for me. When compiling I get multiple warnings like this: SEVERE (MapArea): 29483021.osm.pbf: Point with type 0x2d02 at http://www.openstreetmap.org/?mlat=54.594173mlon=18.815332zoom=17 is outside of the map area centred on http://www.openstreetmap.org/?mlat=54.509804mlon=18.684912zoom=17 width = 12155 height = 8502 resolution = 15 Img is much bigger, like 5MB instead of 3.8MB and I can't decompile it with GPSMapEdit. BaseCamp doesn't display it. I assume img is damaged. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev mapsplit-mini-v3.patch 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] Optimizing MapSplitter
Hi Gerd, patch v3 is working. I have done some speed test on nuvi but conclusions aren't clear. My feeling is that your original settings is a bit slower than standard mkgmap. I have tried some values and settled to: LARGE_OBJECT_DIM = 8192; int wantedSize = MAX_RGN_SIZE / 4; This seems to be a bit faster than standard mkgmap, maybe about 10%, sometimes more. But redraw times aren't always repeatable and my tests are limited to single nuvi model. I would rather say, that there is no significant improvements. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Optimizing MapSplitter
Hi Gerd I tried out the v3 of the patch. It looks good, just looking at the pattern in inkscape. There is a shift towards smaller divs, though the average is still quite large (in area). I don't think that the current algo is completely wrong. I think it is better to start with the complete data and divide it into smaller parts as that algo keeps the information of the location of elements, while your approach is likely to compare many bboxes which are (too) far away from each other. Yes, implementation speed might require some more complexity - but it seems that it should produce a division split where all of them are no bigger than required without further splitting the elements. If that is the case, and it still makes no difference in speed, then maybe we are pretty much as good as we are going to get. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Optimizing MapSplitter
Hi Andrzej, thanks for testing. I also think that the possible improvements are rather small. I'll try a few more changes, e.g. splitting large objects earlier, but I don't expect any big improvements. A typical case where it would help is a long diagonal line. The bbox for it is very big, and a split in the middle would produce two much smaller bboxes. Splitting an rectangle like that for the background earlier will probably not help at all. Gerd popej wrote Hi Gerd, patch v3 is working. I have done some speed test on nuvi but conclusions aren't clear. My feeling is that your original settings is a bit slower than standard mkgmap. I have tried some values and settled to: LARGE_OBJECT_DIM = 8192; int wantedSize = MAX_RGN_SIZE / 4; This seems to be a bit faster than standard mkgmap, maybe about 10%, sometimes more. But redraw times aren't always repeatable and my tests are limited to single nuvi model. I would rather say, that there is no significant improvements. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Optimizing-MapSplitter-tp5823702p5824476.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Optimizing MapSplitter
Hi Steve, I don't think that the current algo is completely wrong. I think it is better to start with the complete data and divide it into smaller parts as that algo keeps the information of the location of elements, while your approach is likely to compare many bboxes which are (too) far away from each other. Yes, implementation speed might require some more complexity - but it seems that it should produce a division split where all of them are no bigger than required without further splitting the elements. Maybe, but I don't think that this would be optimal, as we may get too many sub divs and thus a much larger img file. I don't know how the device determines the relevant sub divs, but even a good algo will suffer if we produce 1 instead of 250 sub divs. If that is the case, and it still makes no difference in speed, then maybe we are pretty much as good as we are going to get. I thought about writing an algo to test this, but that seems to be even more complicated. I'd try to simulate the rendering for each element in a grid, and compare the number of rendered elements (caused by overlaps) which are not visible in the grid element. This could be done for each level, and maybe one has to take into account that a device has to render a rectangle which heads to north-west or west. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Driving on Trail
Frequently in areas where sidewalks are drawn, my GPS decides we are driving on the sidewalk and not on the road. When this happens it displays 'Driving on Trail'. I've verified the footways are tagged, and I've viewed the default style rule. I've double checked to make sure my GPS is in driving mode, which it is. I can't figure out anyway to have it ignore pedestrian routes, short of removing them from the map. Any suggestions on how to fix this issue? Brian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
