[mkgmap-dev] default style improvements

Sun Feb 24 08:02:22 GMT 2019

Hello Ticker,

thanks for your detailed explanations.
The colours and appearance from the typ-file is quite individual, so I followed the idea of creating a map without a typ-file.
Checking several familiar spots in Europe I find, that it is working with the changes and my Montana 610.

Kind regards, Michael

-----Ursprüngliche Nachricht-----
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> Im Auftrag von Ticker Berkin
Gesendet: Dienstag, 19. Februar 2019 11:57
An: Development list for mkgmap <mkgmap-dev at lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] default style improvements

Hello Michael

Thank you for your work checking all of this and your feedback. 

See embedded for my comments.

Kind regards
Ticker

On Sun, 2019-02-17 at 11:01 +0100, Michael Poesdorf wrote:
> Hello Ticker
> 
> I had a look into the 3 mails/proposals of yours.
> Point and Lines are in a way easy. More interesting is the look into 
> the polygons.

Other users need to be slightly aware that the versions of points, lines & polygons you attached are slightly different from the result of applying my patches.

> To get the map impression I implemented the changes to polygons, lines 
> and points of r4268. I also modified the mapnik.typ.
> Please find the relevant files attached. Maybe someone else wants to 
> have a look.
> Recognize changed style lines by my comments starting with ###. The 
> added polygons in the typ-file should be easily recognizable. Also the 
> lines and points.
> 
> Please have a look at these 3 topics:
> 1)
> “Park”. There is already 0x17. You ask for 0x1e and 0x1f, also as 
> “Park”.
> Not sure if we need this kind of differentiation.
> 0x1e is not on the typ - I created a 0x1f.

I had various objectives. The main one was to stop the overloading of type 0x17 for 9 different OSM objects.

My Garmin device, without a TYP file, shows types 0x14 to 0x17 and 0x1e to 0x20 as green, with label 'Park' and 0x1b to 0x1d as green with label 'Area'.
So I moved some of the overloaded OSM objects where green would be a good representation to other, unused green areas and, where green is not a good colour (eg square/plaza) to unused types elsewhere. I also moved other OSM objects that were in this 'green' range, but green is not a sensible representation, elsewhere

So, without a typ-file the representation should be reasonable and, with a typ-file, each area can be labeled correctly and the representation can chosen appropriately.

> 
> 2)
> landuse=retail, 0x12. What is the difference to “Shopping center”?
> Nevertheless implemented in the typ.

My interpretation is that Garmin type 0x08, labeled "Shopping center"
is used for buildings, eg actual shops or a number of shops and maybe some supporting services within a single building (ie a shopping centre), whereas landuse=retail is an area that people go to shop, so it will have lots of buildings (shops and eating places possibly), car parks, maybe petrol etc. For this I've introduced previously unused type 0x12

> 3)
> 0x17 – the Park-topic
> I implemented the requested typs also. And I understand that there are 
> many different usages for areas.
> The problem that I see is the colouring. We might get many quite 
> similar coloured areas. Fifty shades of green.
> Maybe recognizable in Basecamp on a computer, but not that easy to 
> distinguish on devices (like my Montana 610).

I agree that it is difficult to differentiate all the colours that could be used, but it is now the choice of the typ-file. I use a very limited set of colours: 
 green for farmland/meadow/park/grass etc.
 light yellow for built areas (including residential, farm/yard,
     suburb, village, commercial, retail).
 brown (brick colour) for building, shopping center, historic, amenity.
 striped green/transparent for nature reserve.
 striped red/transparent for danger area.
 pinkish for square/plaza.
and the default Garmin representation for everything else.

> In case DEM is used, all the flavours become darker. Night colours not 
> considered.
> It is do-able, but requires some a sense for colours. 
> With landuse=farmland I had to split that line into two, to follow 
> your idea. You will see it from the comments.

I had already split these:

landuse=farm [0x26 resolution 22]
landuse=farmland [0x1c resolution 20]
landuse=farmyard [0x26 resolution 22]

but I'd made minimal reorganisation of the file in this iteration because I just wanted to concentrate on the type changes.

> To sum up: It works for me. If we do the changes to the default style, 
> we should also change the default typ-file with some reasonable 
> colouring.
> Maybe Joris could comment what is do-able in the mapnik colour schema.
> 
> @ Gerd: Could you check the latest releases, please. I cannot find the 
> mapnik.txt in the zip.
> 
> Cheers, Michael

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev