Hi > * The basemap is really bad. Isn't there a possibility to draw at least > country borders and major highways?
Yes the basemap is a problem as it is empty apart from the required definition areas. In fact an earlier version of mkgmap did include major highways and coastlines, but this was lost when combining pre-existing .img file was added. I need to bring it back, I will probably do this fairly soon as I was thinking about it recently. > * Tile size. Why so many small tiles? That is one part of the mess in > the basemap. And it's a real performance hit to render. I really You can certainly create large files with mkgmap. There are two problems for Carsten's maps. The first is that they are constructed by dividing the world into equal-sized chunks, and so that size is determined by the most dense area. We really need something that splits the map based on the number of features in an area. Second is that the default style is quite heavy weight and includes for example residential streets on two different levels. This will make tiles in city areas about twice as large as they would be on other maps. But this is all configurable and as it is now possible to have several different built-in styles, it would be very valuable to have one that is good for making maps of large areas that had fewer levels. > * Spend more zoom levels in the basemap. Only one is sparse and for the > outer zoom levels the basemap is enough. Right now I have to parse a > huge amount of files for outer zoom levels. Look, these are the zoom > levels for City Navigator Europe V8: This is entirely configurable by the map maker. The option levels="0:23, 1:21, 2:19" would give the same as the City Navigator map example you gave apart from the overview map. > * Another huge performance hit are staircase lines in the outer zoom > levels. I have to re-project every polyline point. That is expensive. If > the highway does not change the average direction it can be interpolated > by a line. No one expects GPS accuracy on that level. It's just for > overview. There is some simplification of lines and it is not very good. However the OSM data tends to split roads into many small pieces and I think that to simplify things properly you would have to join them together or at least know where the next segment was going. That's is a fairly big change but I will keep it in mind. > * Also highways seem to have all their ramps up to the outer zoom > levels. That does not add any information. But eats up resources. If the ramps were tagged differently in OSM then they could be left out at higher zoom levels, but as for trying to recognise them I don't really know how I would do that. Its an extension of the previous problem in that case. > * Every minor water body seems to be drawn in the outer zoom levels. > That does not add information either. Big lakes and major streams are > enough. Yes this is a good point. I had forgotten about selecting features for size. I will think up a way of specifying this in the style. > * Tiles must not overlap. Tile selection is really bad if they do. If the input OSM files do not overlap and they contain a <bounds> element then the tiles should not overlap. I though Carsten's maps did that though. The usage of the map-coverage-area element is somewhat broken - that may also cause problems. ..Steve ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ QLandkarte-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkarte-users
