Hi Steve,

thanks a lot for the detailed answer.

Garmin seems to split it's map by equal areas, feature density and
country border. The last is pretty nice, but I can understand if it's
not of much interest for OSM, as your maps don't have to stop at the
country borders for commercial reasons.

For the overlapping maps have a look:

http://www.qlandkarte.org/shot8.png

I just selected my favorite spot by a single click. Think that is very
confusing for most users.

Oliver


> 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


-- 
--------------------------------------------------------------------
DSP Solutions GmbH & Co. KG, Schwandorfer Str. 3a, 93059  Regensburg

Email: [EMAIL PROTECTED]     http://www.dspsolutions.de
Phone: +49(0) 941 / 830 551               Embedded Signal Processing
Fax:   +49(0) 941 / 830 5579              DIN EN ISO 9001:2000

Gesellschaftssitz: Regensburg, Registergericht: Regensburg HRA  7862
Komplementaer: DSP Solutions Beteiligungs-GmbH, Regensburg HRB 10932
--------------------------------------------------------------------

-------------------------------------------------------------------------
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

Reply via email to