1

Hello everyone.

I'm writing a small android application with osmdroid that shows the map and uses the landcover information of the current position for some features. Since the tiles are being stored on the filesystem of the device either way by osmdroid, i had the idea to analyse them instead of using another service like overpass api, to reduce the traffic caused by my application and to allow usage in areas with bad or no internet.

On http://wiki.openstreetmap.org/wiki/Mapnik it says that https://github.com/gravitystorm/openstreetmap-carto is the official style of openstreetmap. Distributed over the relevant .mss files i can find a lot of color hex codes.

But for example the green #c8f9cc which is used in the park at http://a.tile.openstreetmap.org/16/34126/21791.png can't be found anywhere, neither by manual search (going into the files and strg+f) nor with the github search function. looking into the mss file it should be #c8facc

Another example would be the yellow #fef0ba which is used in this tile: http://c.tile.openstreetmap.org/19/274603/166642.png where the beach is marked with natural=beach, so it should be #fff1ba.

Should be values are based on https://github.com/gravitystorm/openstreetmap-carto/blob/master/landcover.mss

I suspect that the gamma adjustments for zoom level and number of nodes are the cause of this, for example:

[feature = 'leisure_park'],
[feature = 'leisure_recreation_ground'] {
[zoom >= 10] {
  polygon-fill: @park;
  [way_pixels >= 4]  { **polygon-gamma: 0.75**; }
  [way_pixels >= 64] { **polygon-gamma: 0.3**;  }
}
}

So i tried playing around with the original colors and the gamma adjustment tool of paint.net, but i was unable to reproduce the used colorcodes.

Is this really the right github project, or am i looking at the wrong one? If it is the wrong one, could you please point me into the right direction?

If it is the right one, what operation gets executed that produces the final colorcodes? Is there maybe somewhere a full list of them?

asked 31 Oct '15, 22:40

EinFreierNick's gravatar image

EinFreierNick
1214512
accept rate: 50%

edited 04 Nov '15, 19:37

aseerel4c26's gravatar image

aseerel4c26 ♦
32.2k16239552

just a quick drop in (no time to think about your question in deep), maybe it is related: https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/

(31 Oct '15, 23:48) aseerel4c26 ♦

@aseerel4c26 that might be possible. At the green area ~1/4th directly below the the New York label the dark green changes from #AACAAE to #AACBAF

(01 Nov '15, 08:32) EinFreierNick
2

meta: Welcome to OSM, @EinFreierNick!

(01 Nov '15, 09:07) aseerel4c26 ♦

2 Answers:
7

You are looking at the correct code for where the colours are defined.

The piece you are missing is how the stylesheet is converted into rendered tiles. The OSMF tileservers use mod_tile and renderd to generate the images. renderd has a hard-coded mapnik image format of "png256" which means that it uses a 256 colour palette with the default settings for calculating the palette. Any differences between the colours set in the stylesheet and those found in the tiles are almost certainly due to the palette creation process.

You can read more details on the available mapnik image formats on the mapnik wiki.

If you use other software to create the images, such as Tilemill, then you might find the colours are slightly different, either by using full 32bit non-paletted images, or paletted images created with different settings.

permanent link

answered 02 Nov '15, 11:07

Andy%20Allan's gravatar image

Andy Allan
11.9k23121147
accept rate: 29%

2
(03 Nov '15, 16:43) gormo

uf, i think i'll have to drop this. there are too many unknowns and even phenomenons in the "creation of the colors". But still, thank you for your help.

(04 Nov '15, 16:12) EinFreierNick
4

You are looking at the right code. Why the color code #c8facc defined in the style sheet ends up as #c8f9cc in the PNG I have no idea - I'd expect some alpha/antialiasing artifacts along the outline of the area but not in the centre.

There's a couple steps from the style sheet to the ready-made image. Some stylesheet instructions that deal with colours (lighten, darken, saturate etc.) are processed by the "carto" compiler that creates a Mapnik XML style description from the CSS files. But the actual drawing (during which the alpha values come into play) is handled by the Mapnik renderer, and more precisely by the AGG library it uses to do the drawing. If you can boil this down to a small test case - Mapnik instructed to render color A but instead rendered color B - then you could perhaps open a ticket on the Mapnik Github repository.

Having said that, trying to deduct geodata from tiles by color codes, and especially with a tolerance so small that a small change like c8facc->c8f9cc trips up the logic, sounds extremely brittle to me. Remember, the map style might change at any time.

permanent link

answered 01 Nov '15, 00:29

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
73.3k866641137
accept rate: 24%

yes ofcause building in a tolerance probably wouldn't hurt. But when i have no clue why (and how) things are like they are, this is going to be rather wearsome. In this case the difference is 1-3 per color, but what if it is somewhere 15 and not 1-3?

(01 Nov '15, 08:33) EinFreierNick

Like it is happening with #FFF1BA -> #FFF0A9 (see the edit of the start post). The difference in blue is 17.

(01 Nov '15, 12:50) EinFreierNick

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×396
×322
×243
×56

question asked: 31 Oct '15, 22:40

question was seen: 6,495 times

last updated: 04 Nov '15, 19:37

powered by OSQA