This seems to be again a problem with the client updating process. The oceantiles.dat is set to land already. But some clients still seem to use an old one.
Thus, I would highly recommend to through that version.txt and newversion.txt files away and instead introduce a lastcheck.txt which is checked and updated on a daily basis and does not depend on what has changed on the svn. Andre On Samstag, 10. Januar 2009, [email protected] wrote: > Hi Maarten, > > Maarten Deen wrote: > > I have another tile that is not rendering properly: 3335 1783. > > This is my horror region! > > > I've tried some things but it still is not working. Is it possible that a > > relation that is not downloaded completely is responsible for this? > > No, it's not because of any relation (although I corrected one in which > you forgot a "type=multipolygon"). > It's because of the tile set as "mixed" in "oceantiles_12.dat". I > corrected this _locally_ (png2tileinfo.pl set 3335 1783 land), rendered > it _locally_ (tilesGen.pl xy 3335 1783) and uploaded it then > (tilesGen.pl upload). This means _at_the_moment_ is shows up correctly. > > So anyone (probably me) has to fix "oceantiles_12.dat" on the server. > If you do a rerender you'll have most probably the old "blue" tile back > again until the "oceantiles_12.dat" fix didn't propagate to the > rendering client (i.e. the machine which the server assigns the tile to > render). > > > Best regards > > Alfons > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
