[Tilesathome] Another error
Dirk-Lüder Kreie
osm-list at deelkar.net
Fri Sep 14 11:52:19 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
spaetz schrieb:
> On Fri, Sep 14, 2007 at 01:10:39AM +0100, Robert Hart wrote:
>> On 12/09/2007, Frederik Ramm <frederik at remote.org> wrote:
>>> Hi,
>>>
>>>> [#13 0% jobinit] Doing tileset 2556,2026 (area around
>>>> 1.889302,44.692383)
>>>> [#13 0% default] Frolloizing (part I) ...... ERROR
>>>> The following command produced an error message:
>>>> nice "xmlstarlet" tr frollo1.xsl data-5574.osm > "temp-5574.osm"
>>>> Debug output follows:
>>>> | data-5574.osm:1: parser error : Extra content at the end of the
>>>> document
>>>> | <osm version='0.4'></osm></osm>
>>>> | ^
>>>> | unable to parse data-5574.osm
>> Looks like the mergeOsm function fails if either of the files is empty.
>
> Which would be weird, because it's supposed to return if any of the downloaded files is empty, just before it calls mergeOSM:
> DownloadFile($URL, $partialFile, 0);
>
> if (-s $partialFile == 0)
> {
> printf("No data here...\n");
> # if loop was requested just return or else exit with an error.
> # (to enable wrappers to better handle this situation
> # i.e. tell the server the job hasn't been done yet)
> PutRequestBackToServer($X,$Y,"NoData");
> foreach my $file(@tempfiles) { killafile($file); }
> return if ($Mode eq "loop");
> exit(1);
> }
>
> Anyway, we should avoid calling mergeOSM if there is only 1 data file (in the case of all z12 tilesets). Thanks for the hint and patch, I'll have a look at it next week.
This code just catches zero-length files, (i.e. when the API returns an
error) not zero-data files, which trigger the bug.
- --
Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG6mfiFUbODdpRVDwRAlffAJ9NqYHqMlQJFy+uxkJRth0wbX5fWwCgp4tg
UdBkx5lo0XqaIhMaTsY+/HE=
=e8Qk
-----END PGP SIGNATURE-----
More information about the Tilesathome
mailing list