logo separator

[mkgmap-dev] Sensible resolutions - (or patch 5)

From Marko Mäkelä marko.makela at iki.fi on Sat Mar 26 07:12:42 GMT 2011

On Sat, Mar 26, 2011 at 02:06:11AM +0100, Felix Hartmann wrote:
>Well then add a note to the options file, that while it is nicer and 
>faster on the GPS to draw (if level 21 and 19 are included) - however 
>it adds up 15% to filesize of gmapsupp.img (though I don't get how you 
>get 15% when I get around 5% - well that's with exporting from 
>Mapsource where the mdr file takes up quite a lot of space too).

One thing that I did not measure was the impact of the additional tile 
splitting, without changes to the options.

>What is your commandline options?

Pretty basic, see http://www.polkupyoraily.net/osm/files/mkgmap.args 
(this is the version before the additional splitting).

>Also I don't really sea why healthcare polygons should be visible
>already at resolution 22. I think 23 (so 24 for everyone who does not
>use 23) is enough. Essentially it's no more important than plain houses
>in my opinion.

I was trying to be consistent with amenity=hospital, but I guess we 
could lower amenity=hospital to 23 as well. Hmm, there is no 
amenity=doctors in the polygons file. I will add that too.

>highway=service at 23 is another thing I'm not too happy. Often 
>highway=service connect residential roads and tracks.

I haven't seen that around here. The highway=service are usually 
driveways and parking aisles, not for passing through (at least not by 
motor vehicles).

>That's why I put them to 22. Maybe a finer seperation would be needed 
>using service=* tag.

What would you suggest? Do you agree that service=parking_aisle should 
be 23 or 24? What about service=alley and service=driveway? I have drawn 
lots of tiny service=driveway that connect properties to a 
highway=residential or highway=tertiary and intersect with a 
cycle/footway. It would seem awkward if service=alley were visible 
before service=driveway or service=parking_aisle, because alleys are 
even more minor.

	Marko



More information about the mkgmap-dev mailing list