Re: [mkgmap-dev] Filters for overview map
Hi Thanks for working out what goes wrong with very small maps. Although you are correct that the overview map only contains area definition and background polygons which should not be dropped, in the future the overview map should contain real map features so it might be best to specifically exclude those polygon types. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Filters for overview map
Hi Johann, first some introduction to the overview map: It's only used in mapsource. If you have multiple tiles (for different areas) there is exactly one polygon (rectangle) for each tile. The name for the polygon is the name of the tile plus its map name (the eight digit name). It has a resolution of about 13 (shiftlevel 11). One unit length is on the order of km. The map in that tile usually has a much better resolution, even at its worst level. So the rectangles of the overview map have to be unaligned to the borders of the tile. On Tue, Jun 16, 2009 at 12:03:52AM +0200, Johann Gail wrote: [...] In general i find it an good idea to split up a problem into small parts, but at the moment I cant see the whole thing. Why is it neccessary break things down to smaller rectangles to get an improvement in alignment? Yes, I have seen this error and up to now i thought, there was some rounding error in it. It's rounding errors, yes. And rounding trickery. The problem exists mainly with very small tiles. One can either try to massively enlarge it before the SizeFilter kicks in, or get it with an acceptable size, which could be (1 x 1) units^2 in the relevant resolution. It's on the order of km, so a 1x1 rect is still large. In my testing it turned out, that the SizeFilter and the DouglasPeuckerFilter either dropped my small rectangles or converted them to a triangle. Removing the filters fixed this for me. If you think, that the generated rectangles should be large enough, so that they're not cleaned: - If this is so, then there really is no reason for calling the filters anyway, they should be NOPs in that case. So we can optimize them away. My opinioin: I dont know the special case for the overview map. On a normal map layer I dont assume that all elements are large enough. If an element is to small to be displayed then we can drop it completely. If you drop one polygon, the reference to one tile is dropped, which finally means, that this tile is not displayed at all by mapsource. We may not drop a single polygon, because we want to show all tiles in mapsource. - I hope to show in later patches (don't hold your breath! I will go slowly step by step. There is no need to hurry anyway) that smaller rects might make some sense. As said before, I dont know the complete background. Maybe with the overview map it is reasonable to not drop the indisplayable things. It's not indisplayable. The resolution is just very bad, even for zooming in to meters. It's just containing the borders of the map tiles. So it doesn't really need better resolution. [...] With this patch you introduce the possibility to disable filtering. I see nothing destructed, but (at the moment) no use in it. But if I understand it correctly, then the filtering is switched of for the complete overview map layer. Wouldn't that increase file size a lot? I would expect at this resolution a lot of filtered small streets. As said above, there are no streets or anything else in the overview map. More important: Does it increase redrawing speed at low zoom levels, which is possibly the main use of a overview map? Or is the overview map not used at the gps unit? It's only used by mapsource. It's only generated if you call with --tdbfile. The main intention for the douglas peucker filter was the low drawing speed on my etrex handheld at low zoom levels. Don't be discouraged by my critics. It are only my thoughts at the moment. Regards, Johann ___ 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] Filters for overview map
Hi, My current conclusions from both thread parts: 1) I should only disable the SizeFilter (we really, really don't want to drop any polygon). 2) We should fix DP. Does that make sense? Elrond ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Filters for overview map
Hi, Am 16.06.2009 um 20:39 schrieb Elrond: My current conclusions from both thread parts: 1) I should only disable the SizeFilter (we really, really don't want to drop any polygon). For the overview map obviously not. 2) We should fix DP. From what you explained about the overview map (I was always wondering what it is for...) also DP for the overview map makes no sense. What would make sense though would be to split the tiles in a way that the polygons in the overview map need no rounding. Or is that already the case? And yes, we should fix DP (if it is actually broken). Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Filters for overview map
Hi, On Tue, Jun 16, 2009 at 10:49:45PM +0200, Thilo Hannemann wrote: Hi, Am 16.06.2009 um 20:39 schrieb Elrond: My current conclusions from both thread parts: 1) I should only disable the SizeFilter (we really, really don't want to drop any polygon). For the overview map obviously not. 2) We should fix DP. From what you explained about the overview map (I was always wondering what it is for...) also DP for the overview map makes no sense. I read that as You can commit this. I'll wait for a little for possible other input. :) What would make sense though would be to split the tiles in a way that the polygons in the overview map need no rounding. Or is that already the case? Hmmm, maybe my naming was bad. With tile I meant a region as defined by the boundaries in the foo.osm you're using to create one map. So the boundaries are really set by the user. And getting those boundaries close to the overviewmap-alignment is not easy (for the user). The alignment edges change with the center of the world (the overview map). So in short: I don't see a simple way for doing it. Splitting at the map level would require mkgmap to auto-select new (eight digit) map names for the newly created maps. And this splitting can only happen, when/if the world is known, so quite too late. We'd need two-pass handling or so. And yes, we should fix DP (if it is actually broken). I only noticed it for the overview map. So I can't really tell, if it is broken or not. I just have speculated on its cause in the other thread part. Regards Thilo Elrond ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Filters for overview map (was: Overview map: tiny patch/review series)
Hi,
okay, first part.
In my testing it turned out, that the SizeFilter and the
DouglasPeuckerFilter either dropped my small rectangles or
converted them to a triangle.
Removing the filters fixed this for me.
If you think, that the generated rectangles should be large
enough, so that they're not cleaned:
- If this is so, then there really is no reason for
calling the filters anyway, they should be NOPs in that
case. So we can optimize them away.
- I hope to show in later patches (don't hold your breath!
I will go slowly step by step. There is no need to hurry
anyway) that smaller rects might make some sense.
So this simple patch disables both filters for the overview
map.
If nobody objects or I get some Go, I'll commit it soon.
Elrond
Index: uk/me/parabola/mkgmap/combiners/TdbBuilder.java
===
--- uk/me/parabola/mkgmap/combiners/TdbBuilder.java (revision 1065)
+++ uk/me/parabola/mkgmap/combiners/TdbBuilder.java (working copy)
@@ -227,6 +227,8 @@
*/
private void writeOverviewMap() {
MapBuilder mb = new MapBuilder();
+ mb.setEnableLineCleanFilters(false);
+
FileSystemParam params = new FileSystemParam();
params.setBlockSize(512);
params.setMapDescription(overviewDescription);
Index: uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- uk/me/parabola/mkgmap/build/MapBuilder.java (revision 1065)
+++ uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -108,6 +108,7 @@
private int poiDisplayFlags;
private boolean sortRoads = true;
private static final double FILTER_DISTANCE = 2.6;
+ private boolean enableLineCleanFilters = true;
public MapBuilder() {
regionName = null;
@@ -819,7 +820,7 @@
config.setResolution(res);
LayerFilterChain filters = new LayerFilterChain(config);
- if(res 24) {
+ if (enableLineCleanFilters (res 24)) {
filters.addFilter(new SizeFilter());
filters.addFilter(new DouglasPeuckerFilter(FILTER_DISTANCE));
}
@@ -855,7 +856,7 @@
FilterConfig config = new FilterConfig();
config.setResolution(res);
LayerFilterChain filters = new LayerFilterChain(config);
- if(res 24) {
+ if (enableLineCleanFilters (res 24)) {
filters.addFilter(new SizeFilter());
//DouglasPeucker behaves at the moment not really optimal at low zooms, but acceptable.
//Is there an similar algorithm for polygons?
@@ -907,6 +908,10 @@
this.doRoads = doRoads;
}
+ public void setEnableLineCleanFilters(boolean enable) {
+ this.enableLineCleanFilters = enable;
+ }
+
private static class SourceSubdiv {
private final MapDataSource source;
private final Subdivision subdiv;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Filters for overview map
Hi, okay, first part. In general i find it an good idea to split up a problem into small parts, but at the moment I cant see the whole thing. Why is it neccessary break things down to smaller rectangles to get an improvement in alignment? Yes, I have seen this error and up to now i thought, there was some rounding error in it. In my testing it turned out, that the SizeFilter and the DouglasPeuckerFilter either dropped my small rectangles or converted them to a triangle. Removing the filters fixed this for me. If you think, that the generated rectangles should be large enough, so that they're not cleaned: - If this is so, then there really is no reason for calling the filters anyway, they should be NOPs in that case. So we can optimize them away. My opinioin: I dont know the special case for the overview map. On a normal map layer I dont assume that all elements are large enough. If an element is to small to be displayed then we can drop it completely. - I hope to show in later patches (don't hold your breath! I will go slowly step by step. There is no need to hurry anyway) that smaller rects might make some sense. As said before, I dont know the complete background. Maybe with the overview map it is reasonable to not drop the indisplayable things. So this simple patch disables both filters for the overview map. If nobody objects or I get some Go, I'll commit it soon. With this patch you introduce the possibility to disable filtering. I see nothing destructed, but (at the moment) no use in it. But if I understand it correctly, then the filtering is switched of for the complete overview map layer. Wouldn't that increase file size a lot? I would expect at this resolution a lot of filtered small streets. More important: Does it increase redrawing speed at low zoom levels, which is possibly the main use of a overview map? Or is the overview map not used at the gps unit? The main intention for the douglas peucker filter was the low drawing speed on my etrex handheld at low zoom levels. Don't be discouraged by my critics. It are only my thoughts at the moment. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
