[OSM-dev] [Tilesathome] Proposal for T at H land/sea updates

[Sebastian Spaeth]

Alan Millar wrote:
> Before anyone asks, yes, I am volunteering to code this.

;-)

> There is a problem right now that some z12 tiles are built wrong. 
> Sometimes a land tile is colored as sea, and vice versa.  (I am not
> talking about the "unknown type" tiles which will fix themselves over
> time).

> As I understand the Tiles at Home process, the ultimate decision on
> distinguishing land from sea happens in close_areas.pl, based on
> oceantiles_12.dat.  I have found that there are areas where the data in
> there is simply wrong.  This mostly happens in coastal areas around large
> water inlets or river deltas, because the data in the oceantiles_12.dat
> file isn't clear.  It looks like close_areas.pl does a good job of
> guessing in many cases, but in others the file needs to be corrected.

oceantiles_12.dat is only consulted if close_areas.pl can't decide. So 
the issue could be with either close_areas.pl *or* with 
oceantiles_12.dat. There have been bugs in close_areas.pl previously, so 
it might be worth checking if it's really the oceantiles.dat that is at 
fault.

> The problem with this is that this data is distributed as part of the
> code.  The file can be updated and recommitted to svn, but areas will be
> rendered incorrectly until every t at h client gets every update.

That is correct and it is not perfect. One idea of improving this is to 
have the server send a blankness hint when it distributes a task, that 
is, it could send to the client
"render z12-tileset x=34,y=234, if blank it should be sea"

The blankness hint could come either from the servers oceantiles.dat 
that it would keep current. Or it could come from the blankness entries 
that already are stored in the default layer, or it could come -as you 
suggest- from a blankness layer of its own.

> How big of a problem is this?  In the oceantiles file, there are about 13
> million sea pixels, 3 million land pixels, and about 203000 mixed
> (ambiguous) pixels.  The data is mostly correct, but how much is in error?
>  If we assume the land and sea ones are all correct (which they are not),
> and the mixed ones only have 1% errors, that could leave a few thousand
> errors. With 16 million pixels, a few thousand in error is not bad at all.
>  But we will still want to fix them without dozens of svn commits and t at h
> client updates.

> I propose that we create a new layer which could hold this information in
> the blank tiles table.  The close_areas.pl script would use the same logic
> it does now, but retrieve the z12 tile from this layer instead of the flag
> from the oceantiles_12.dat file.  It could even check the neighboring
> tiles if the desired one is missing or ambiguous, like it checks the
> neighboring flags in oceantiles_12.dat currently.  It should not be a
> difficult change to close_areas.pl

Possible, but IMHO it should still be possible to use close_areas.pl in 
offline mode, as some use it to render local data files...

I'd say that a new layer *might* be a bit overkill, as blankness 
information is in the current default layer as well. As proposed 
earlier, the server could give blankness hints together with a request 
based on what's in the default layer's blankness entry. If that hint 
turns out to be wrong, you can simply upload the right land/sea tile to 
make it right without need to SVN access.

But if you think it could/should best be done with a new layer, than 
that would work too.

> Comments, feedback, or suggestions?  Let me know what you think,
> especially if the situation is more complicated than I think.


Sounds good. I don't think it's more complicated than that. I'd say that 
it might be easier to use the default layers blankness information 
rather than having a new one, and I'd say that the blankness hint could 
be distributed at task distribution time, which would save you one more 
HTTP roundtrip (and would remove the neccessity to make close-area.pl 
online-capable).

spaetz