[Tilesathome] Tackling the Z12 tile enclosed by landuse issue

[Robert (Jamie) Munro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brent Easton wrote:
> Have been thinking about solving the problem where a zoom level 12 tile is completely enclosed within a large landuse=forest area. Currently, the forest is not renderered. Interested in ideas to approach this. 
> 
> So far I have come up with:
> 
> 1. Use a relation type=enclosed to connect any node or way within  the tile (role=within) to the enclosing landuse (role=enclosing). Change the data download to download the enclosing landuse whenever the enclosed relation is downloaded.
> 
> Pros: Simple, easy to implement. Good for smaller enclosing areas. Can be maintained using JOSM
> Cons: Will be clumsy for large enclosing forests. 
> 
> 2. Expand the current oceantiles process from just water/land to include other landuse types using other colors as needed.
> 
> Pros: Easier to maintain (for people who can cope with png2tileinfo)
> Cons: Hard to maintain (for people who cannot cope with png2tileinfo). More work to implement.


3. Expand the current oceantiles process and replace the tileinfo
database with something automatic :-)

I propose we extend close-areas.pl so that whenever it finds an that
crosses it's borders, it reports to a central database the background
colour that the neighboring tiles on it's other borders should be (based
on the colour on the right rule). When an area has no borders in it to
indicated it's colour, it finds the "nearest" known tile from that
central database and uses it's background colour. Nearest can just be a
simple indexed search in the database on the (x,y) of the tile - If the
database is complete, it doesn't matter if it searches horizontally,
vertically, forwards or backwards it will find the right answer. If the
database is incomplete, it might be worth trying all 4 directions and
using the nearest value, so that tiles close to known coastlines are
correct even if the other side of the ocean they are near isn't.

The central database table would have the following fields:

x, y (integers, self explanatory),
source (a char(1), one of N,S,E,W - the direction of the tile that
          told us what colour we are)
colour (the colour the tile should be)
lastUpdate (the date it was last updated)

The primary key would be (x,y,source). We need to keep track of the
source so that if the coastline is moved out of that tile, we can delete
its records from the database.

There is a slight flaw with this system in that it doesn't support more
than one colour on top of each other, but I don't think that will be a
problem in practise - we just need to make sure that a landuse on top of
another landuse is also a hole in that landuse, which sounds like a
sensible restriction to have anyway.

I'd be happy to write the code for the central database if someone who
knows about closed-areas.pl is able to write that side of it.

Robert (Jamie) Munro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaoT1z+aYVHdncI0RAjG6AJ9if+g/uqWFwru3F3uSJZEnfIvRQwCg2qhH
RTi8v1qQzHBTT7hl004AIcs=
=p6s9
-----END PGP SIGNATURE-----