Hi Yves,
Post by Eric van den BergFor some time now I have suspected that srtmchop does not do its job
1. At ELLX the VOR LUX, although placed at the correct lat/lon is
located at the foot of a hill which if it would be there in RL would not
http://www.emmerich-j.de/EDDF/EDDF-ELLX.zip)
Hi Eric
As I understand this is "just" a slightly misplace VOR, isn’t it? You
can get the right location and submit this to xplane data source. Then
the right location will come to flightgear scenery data automatically
once, and will be available also for custom scenery builds.
http://data.x-plane.com/faq_designer.html
No, I think you misunderstand. The VOR is placed correctly. The Terrain
is wrong, the hill is shifted to the south. That is how my suspicion of
false elevation was raised in the first place.
Post by Eric van den Berg2. The north border of the geotiff files is 0 elevation over the entire
west-east line in the output files (*.arr.gz)
So I experimented a bit and to make a long story short I wrote something
that handles the data correctly. Called ascchop as it chops *.asc files
(from http://srtm.csi.cgiar.org) and not the geotiff-s (same data
though). Only works on linux and as I only know a bit of fortran written
in that language.
Let me know if interested.
So it looks like srtmchop somehow 'forgets' the entire south border and
shifts all elevation data 0.0008333 degrees south. Of course when it
gets to the north border, no data left and makes it all 0.
Cheers,
Eric
I had a look to srtmchop once and I guess there are also other
problems with this "chopper". I don’t use it because all my tests
failed, I’m still using hgtchop which works like a charm. AFAIK
srtmchop was mainly thought for CGIAR data and is a side project,
hooking on CGIAR data it will produce scenery data that can’t be
distributed under common used FlightGear scenery data license (GPL).
1. I do not see why CGIAR data derived works cannot be published under
GPL. They just want to be mentioned in the credits and put no
restrictions on derived works what so ever. Therefore I (or anyone else)
using the data can put it under any licence they want. But I will sent
them an email to clarify.
2. Are you sure current official scenery is published under GPL? There
are certain things you need to do for that to happen. Like (quote from
GPL v2):
"For example, if you distribute copies of such a program, whether gratis
or for a fee, you must give the recipients all the rights that you have.
You must make sure that they, too, receive or can get the source code.
And you must show them these terms so they know their rights."
When I download official FG scenery, be it from the homepage or
terrasync or I use it, there is never any notion that it is under GPL
and neither are "these rights shown to me". In my opinion the
prerequisites of the GPL v2 license are not met, so it simply is not GPL'd.
You can pull terragear source at http://www.gitorious.org/fg/terragear
and send a merge request to try to add your ascchop code. To be honest
I don’t know if it’s good practice to have this written in fortran and
have it available for linux only, but maybe you can send a merge
request there and ask for review? And maybe you can try to improve
srtmchop also, so your work comes to tools already there?
-Yves
Well good point. But I only know (a bit of) fortran, so I am unable to
improve srtmchop, sadly. The question is if we want to have a C program
that we know has a bug or a fortran program that works. I will try and
see to make ascchop work on windoze also as good as I can, but as I do
not have windoze, I will need a volunteer to test it!
Eric