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

Alan Millar am12 at bolis.com
Tue Jun 3 04:37:55 BST 2008


I'd like to make a proposal for improving Tiles at Home.  Before anyone asks,
yes, I am volunteering to code this.  I'm looking for clarification,
feedback, or suggestions.

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.

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.

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

Of course, this would require populating the new layer first with a
snapshot of the current z12 entries from oceantiles_12.dat.  Assuming
that, for this new layer, we would only use blank land or sea tiles, then
no file system space would be required on the server, only rows in the
blank tiles table.

How many rows?  I have analysed the current file, breaking it recursively
from z3 to z12 squares to see how many are required.  It will take about
250k tiles to represent the entire set of z12 tiles.

count   zoom
     21 3
     33 4
    185 5
    501 6
   1415 7
   3686 8
   9712 9
  25405 10
  62741 11
 151698 12

That may or may not be a lot of rows; I think I read there are 35 million
rows in there now, so this is not a big addition.

It should not affect the performance of close_areas.pl by much, since it
only needs to retrieve one tile (or 9 tiles if a miss).

The big advantage of this method is that anyone can fix a tile without
needing developer svn access, and without requiring renderers to
constantly update their code.  It only requires a moderate change to
close_areas.pl and the creation of one new layer, and doesn't impact the
rest of the process.

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

- Alan






More information about the Tilesathome mailing list