Hi,
Chris Metzler schrieb:
hgtchop didn't freak out for me; it was more of a subtle clue that
there were problems that manifested themselves later at the end of
the chain. When you run hgtchop on the data and produce the *.arr.gz
files, hgtchop prints status info on each tile to the screen. Does
that all look OK? Mine looked just fine, *except* when it printed
the lat/lon of the tile where it was working, there were non-Latin-1
characters (non alphanumeric symbols) in there, which occasionally
caused beeping (ctrl-g, the keyboard bell) when it tried to print
them on the screen. Otherwise it looked perfectly fine. But that
was the first sign that something was up.
I have read your mails on terragear-devel but until now nothing of that
seemed familiar. Until now. I think the non-latin-characters stem from
the fact that HGT.write_area - which is called from hgtchop - writes the
bucket to cout. SGBucket stores x and y as char. The operator<< declared
in simgear/bucket/newbucket.hxx simply prints that as char. Try the
attached patch on SimGear.
If anything else doesn't work, I suspect that it doesn't have anything
to do with this.
Cheers,
Ralf
Index: simgear/bucket/newbucket.hxx
===================================================================
RCS file: /var/cvs/SimGear-0.3/source/simgear/bucket/newbucket.hxx,v
retrieving revision 1.9
diff -u -r1.9 newbucket.hxx
--- simgear/bucket/newbucket.hxx 8 Mar 2006 18:16:08 -0000 1.9
+++ simgear/bucket/newbucket.hxx 13 Apr 2006 13:25:11 -0000
@@ -316,7 +316,7 @@
inline ostream&
operator<< ( ostream& out, const SGBucket& b )
{
- return out << b.lon << ":" << b.x << ", " << b.lat << ":" << b.y;
+ return out << b.lon << ":" << (int)b.x << ", " << b.lat << ":" << (int)b.y;
}
