halfpixel shift on the seamless server corrected

[Guest vlada stoje]

see athttp://seamless.usgs.gov/SRTM Half Pixel Shift News: Starting February 6, 2007, the SRTM "finished" elevation data no longer contains a half pixel shift. The data has been corrected and verified.good to know this!CheersVlada Stoje

[LuisFelizTirado 33]

Great news, thank you, Vlada. Now I just wonder if the correction has been applied to the files on the ftp site.Best regards.Luis

[Guest vlada stoje]

Hi Luis,I just tried to download one sample from the corrected seamless server and can confirm that everything is ok. Maybe nobody is going right now to use this set for fs mesh, but we can be happy, that perhaps our community helped to USGS with small feedback for this issue. The JPL data from ftp://e0srp01u.ecs.nasa.gov is also without problem (only the version 2 seems little bit blurred above parallel N50 due to sampling to 6x3s and then back to 3x3s). I am mixing the threads (this is my typical disorder) but Luis big thanks for your ideas and advices here! Your thread about the Shp2Vec really helped me to understand the thing!CheersVlada Stoje

[=Hollywood= 0]

yeah the version 2 on the ftp server was correct and didn't contain any pixel shift.it was just the seamless server that caused the issues

[LuisFelizTirado 33]

Hello Dean, or should I say, Aloha!,I have consistently noticed a shift in the data between the versions 1 and 2 from the ftp server.Here are some examples from FS 9, comparing the default mesh (SRTM version 1) at LOD 8 with a custom mesh (version 2 from ftp server) at LOD 9:http://forums.avsim.net/user_files/172253.gifhttp://forums.avsim.net/user_files/172254.gifAnd here is a comparison in FS X between the default SRTM (version 1) and a custom version 2 obtained from the ftp server:http://forums.avsim.net/user_files/172256.gifI do not know the cause of this shift, and hesitate to ascribe it to the same error as the seamless data, but there does seem to be a problem with the ftp data.Best regards.Luis

[Guest vlada stoje]

Hi Luis and Dean,sorry about my confusing first answer, but I also think that the ftp version 2 was and is without any shift, thanks Dean for highlighting it! Formerly I browsed several ftp version 2 tiles to explain the little blur, and it was without shift. Luis, is it possible that the differences in your examples are only in the FS files? I suppose that the FS 9 default mesh wasn't created from SRTM? I have to show also one illustrationhttp://www.volny.cz/stoje/vera/N17W064_vera.gifit is the comparison between ftp version 1 (with the ocean noise) and the 1s model created by Vera from ftp version 2 and the corrected seamless (sorry about the unsolved voids).CheersVlada

[LuisFelizTirado 33]

Thank you, Vlada. I really do not know the cause of this shift, and would not call it a mistake by the FS developers. Perhaps it is due to some error in their source data.I assumed that the default mesh data for this region was obtained from the SRTM source, since there is not any other source as detailed as far as I know. But, the guys in Redmond probably do not get the data directly from the seamless server or from the ftp site, but from a distributor of some sort, I think.Anyway, it was a good occasion to pull out the v1 and v2 ftp data and make a small comparison:http://forums.avsim.net/user_files/172300.gifIn effect, there is no shift in the ftp data at all.Strangely enough, the default FS data and the ftp data are not aligned with each other, but the default data is better aligned with the land masses than the ftp data, as can be seen in my first Saba example where the default mesh is better aligned with the island. And this is valid throughout the region. I have been doing some custom ground textures of the island of St. Barthelemy where the ftp data is very evidently shifted towards the East and creates some unsightly cliffs.As I mentioned, I really do not know the cause of all this, and it could just be that we expect much more precision from all these sources - SRTM, Google Earth, etc. - than really exists.There is an option with the new Resample to determine whether the source pixels are sampled at their center or at their corner (PixelIsPoint), and I have been meaning to see the effect of this on such a problem as the above. Perhaps it will not change much?Best regards.Luis

[Guest vlada stoje]

Hi Luis,thanks for this visualization in TmfViewer, it is perfect way for the bgl files! I believe you are right with the PixelIsPoint parameter, the bad setting should cause half pixel shift. The default value 1 is for the elevation data, where the member of the source numerical matrix means the vertex of the terrain lattice or wireframe model. The value 0 should be for custom textures, where this number means the color of whole pixel area. But as the size of texture pixels is maximum 4.8m and in FSX can be even smaller, the mistake in the PixelIsPoint parameter shouldn't cause too much visible errors? And as you say, also the locating precision of the sources for custom terrain textures mostly can't be better as the pixel size.The half pixel shift in SRTM 3s was different situation, as all types of the 90% geolocation errors were about 10m and better, while the shift was 45 - 63m. Btw the islands on your pictures, it must be wonderful piece of the Earth!Thanks and best regardsVlada Stoje

[=Hollywood= 0]

Hey Luis,I noticed in FSX that it appears that the default mesh has huge shifts in the elevation data, particularly in australia where it is several hundred meters off, also noticed it had been very oversampled and a lot of the detail lost...comparing my own renders with that of the FSG mesh, both our meshes' lined up correctly... i believe the default FSX mesh is very far off but i say that tentatively without having heard from Adam on how the terrain was rendered...Basically tho I did compare an area of SRTM rendered data, default FSX data and 6 foot elevation sampling and the SRTM2 data lined up correctly with the ultra high res data whereas the default mesh displayed a shift...Comparing the SRTM2 FTP data against data from a GPS the figures appeared to be correct... A lot comes down to accuracy of geodetic data in aligning the datasets when comparing them to the real world... but that's a totally different subject lol...Not sure if this helps with the issues you've described above with the shift in data you've seen for your SRTM renders, but personally I don't trust the default elevation data's accuracy, simply because I'd seen such a huge shift in positional accuracy in australia and it was evidenced by a road that was on the side of a known mountain rather than along the top of the ridge line...(edit) I also just looked at the image compare you posted above and you can actually see the error in the default pic along the right hand side as you see a cliff face near the waterline... this is indicative that the elevation data has slid past the coastline and is being 'crushed' by an ocean/water flatten... the granite cliff face shouldn't be there in that rendering of the island, hence i suspect that the SRTM rendering is correct rather than the default FSX mesh...

[LuisFelizTirado 33]

Hello Dean,Thanks for the comments. I never suspected that the default mesh was shifted from its true location. We have had so many problems in this area of the world, such as the incorrect shape, size, and placement of the land masses, that it never occurred to me that the mesh could also have problems. So, many thanks for confirming this. It is one more hurdle to clear in order to get a more realistic depiction of the islands.In this particular instance, though, the island of Saba does have a sharp cliff face just West of the airport, as displayed by the default mesh. So, I assumed that the mesh was correctly aligned. Here is an image of the real thing:http://forums.avsim.net/user_files/172558.jpgI really must pay more attention to these details, so I compared the default Hydro Polygons and a new version that I drew about 6 or 8 months ago for FS X:http://forums.avsim.net/user_files/172559.gifThey are not similar, and are shifted one from the other. So, it would seem that the default mesh fits well with the default Hydro Polygons, but they are unfortunately not in agreement with my new land mass where the default mesh looks bad. Confusing!Best regards.Luis