[OSM-talk] Blue sea tiles for tiles at home

[Frederik Ramm]

Hi David,

> I've been following this development quietly but with great  
> interest. In a
> thread in mid-December, I was questioning how it is possible to  
> render coast
> properly local to a tile unless there is a convention for which  
> side is the
> sea. In January I proposed an algorithm for forming a sea polygon  
> within an
> individual tile from the sections of coastline intersecting with  
> its edges,
> which looks very like what Fred has implemented. I'm afraid I gave up
> pressing these because I got a lot of negative reaction on each  
> occasion, so
> I'm really pleased to see them happening now.

I remember the discussion, and that's why I just implemented it  
without asking. (I must admit that when I started, I thought it was  
just a matter of definining which side the water is on, and  
everything else would just fall into place... it was a bit more  
complicated in the end.)

I've also termed this an "intermediate solution", accepting that  
there are disadvantages, but I think it is better than not having  
water at all.

> 1. I wonder whether the other related suggestion I made at the time  
> may
> still have some usefulness in helping create or verify the tile  
> mask: that
> is, to use the heuristic that if there is a highway in a tile (or  
> any other
> land-based feature, but excluding highways on bridges and railways in
> tunnels for obvious reasons), then that tile has at least some land  
> in it.

That could easily be put into close-areas.pl (for those cases where  
there is NO coastline on the tile, check for any roads before you  
check the tile index to see wheter it is a water tile). But then  
again, it should not be too much work to get the tile index right -  
why implement workarounds for a condition that will soon be removed  
(unless the same workarounds remove the incentive to fix it...) - a  
bad tile index will also upset the lowzoom script which directly  
checks the tile index for those cases where the server doesn't return  
a level-12 tile.

> 2. The same principle of directionality applies to any polygon  
> which is
> large. Tiles do not know they are inside or outside a large polygon  
> because
> no edge of the polygon passes through the tile (or the nearby areas  
> which
> osmarender seems to extends to minimise these problems); and if an  
> edge does
> go through the tile, the polygon may be enormous so expensive to  
> collect all
> of. Large lakes are the obvious example, but if a whole city area  
> is marked
> as 'landuse=residential' the same would apply, for example. If we  
> adopted
> the 'right is best' convention for all large areas, we would be doing
> ourselves a favour (and would remove the need to have vast polygons
> enclosing cities to indicate their extent - shorter and therefore more
> locally manageable connected ways would be enough); and  
> generalising the
> mask for different kinds of area (like 'residential') would be  
> useful in
> future.

I called the script "close-areas.pl" and not "close-coastlines.pl"  
with that future use in mind. The "right is best" rule helps us with  
all tiles where the relevant way cuts through; for fully-enclosed  
tiles, we need extra information. I would advise against using an  
external tile index like we do for coastlines; I would, for this  
purpose, put controller nodes inside the area. A node tagged like  
"close-areas:inside=natural:wood" (the key being "close- 
areas:inside", the value being "natural:wood") would indicate to  
close-areas.pl that if a tile is encountered that does not contain  
any "natural=wood" ways but has such a control node, would be assumed  
to be fully inside a "natural=wood" area.

(Someone suggested doing this for the sea tiles also, and idea that  
has its appeal, but the sheer number of such nodes having to be  
inserted puts me off... and having the opposite, i.e. "non-sea" nodes  
on land, isn't that much better.)

> 3. I wonder whether the sea tile mask could be used in the opposite  
> sense in
> rendering too: I have numerous tiles in my landlocked county which are
> "intentionally left blank", as they say. Now, OK, nothing is ever  
> complete,
> but to the level of completeness I'm working to, many of these  
> rural tiles
> are empty (have no roads etc passing through them), so they don't  
> render.
> This is particularly distracting in mapnik because it slaps "more  
> osm coming
> soon" all over the map, but even in osmarender, they're white  
> rather than
> grey. If the mask had four values for each tile instead of three  
> ('sea',
> 'land', 'coast' and 'no information')

That's exactly what is has. It is just that only the "sea" is  
currently evaluated by close-areas.pl, and everything else ignored.

But the tile index only has level-12 resolution, and I thought you  
were in Cambridge, not in rural China? Are there really level-12  
tiles with *nothing* on them?

> then 'land' tiles could be rendered
> empty, so filling in the holes, while 'no information' tiles could be
> rendered 'more osm coming soon' or whatever. Land could be  
> initialised to
> 'no information' where there are no nodes in the tile area, but  
> edited to
> make explicit the validly empty areas.

This would not currently make a difference, as empty tile detection  
is done after tiles are rendered; if the tile comes out of the  
rendering empty, then t at h client upload a special "empty" tile, and  
the server just throws that away to save space. This notification  
mechanism would have to be upgraded to support "empty but known land"  
in addtion to "empty", or the server would have to check the tile  
index itself.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'