discrepancy between ASCII file and pixel size and pixel width in metadata.
yianni
Global Mapper UserTrusted User
Hi all,
I have an ASCII file that if I load it as an elevation grid from 3d point data and I choose to treat the 3rd coordinate value as elevation, it will load as expected as a nice colorful background
Now if I go to check the metadata of the file then the pixel width is 1.006 meters and the pixel height is 2.787 meters.
Also when I change the resampling of the specific file, from bilinear interpolation to say box average 2x2 the hole layer gets "pixelised" and if I physically measure the edges of the pixel, I get the same 1x2.7m, which is great ( I used to think that I just told GM to show me the ASCII as it actually is, no interpolations).
Here is where it gets confusing:
if I chose to load the same file as a point only from the "generic ascii text file input options" card (NOT as an elevation grid from 3d point data as I did before) I expect my screen to fill up with rows upon rows of points, which have as an attribute the elevation value of the specific location.
However, if I measure the spacing of those points it is different to the 1.0m x 2.7m as mentioned above. Actually in the file that I just tried to load, all points are now 0.5m. apart when I measure their distance on my screen with the GM distance ruler.
Any ideas on why is that? I was expecting to see a point every 1x2.7 m and not every 0.5m. Why do not I get a pixel size and width of 1m x 2.7m when the ASCII file has points are every 0.5m?
Any good ideas on the above? I am inclined to believe that I am doing something wrong or have gotten the idea backwards and some guidance would be nice..
On a different note I do remember seeing this weird 1.0m x 2.7m pixel width and height before in the metadata of XYZ files in global mapper.
Thanks
y
I have an ASCII file that if I load it as an elevation grid from 3d point data and I choose to treat the 3rd coordinate value as elevation, it will load as expected as a nice colorful background
Now if I go to check the metadata of the file then the pixel width is 1.006 meters and the pixel height is 2.787 meters.
Also when I change the resampling of the specific file, from bilinear interpolation to say box average 2x2 the hole layer gets "pixelised" and if I physically measure the edges of the pixel, I get the same 1x2.7m, which is great ( I used to think that I just told GM to show me the ASCII as it actually is, no interpolations).
Here is where it gets confusing:
if I chose to load the same file as a point only from the "generic ascii text file input options" card (NOT as an elevation grid from 3d point data as I did before) I expect my screen to fill up with rows upon rows of points, which have as an attribute the elevation value of the specific location.
However, if I measure the spacing of those points it is different to the 1.0m x 2.7m as mentioned above. Actually in the file that I just tried to load, all points are now 0.5m. apart when I measure their distance on my screen with the GM distance ruler.
Any ideas on why is that? I was expecting to see a point every 1x2.7 m and not every 0.5m. Why do not I get a pixel size and width of 1m x 2.7m when the ASCII file has points are every 0.5m?
Any good ideas on the above? I am inclined to believe that I am doing something wrong or have gotten the idea backwards and some guidance would be nice..
On a different note I do remember seeing this weird 1.0m x 2.7m pixel width and height before in the metadata of XYZ files in global mapper.
Thanks
y
Categories
- 13K All Categories
- 5.8K Features Discussion
- 351 Downloading Imagery
- 1.3K Elevation Data
- 385 Georeferencing Imagery Discussion
- 652 GM Script Language
- 56 User Scripts
- 115 GPS Features
- 422 Projection Questions
- 837 Raster Data
- 1.4K Vector Data
- 6.7K Support
- 182 Announcement and News
- 944 Bug Report
- 565 SDK
- 1.2K Suggestion Box
- 3.8K Technical Support
- 582 Other Discussion
- 132 GIS Data Sources
- 27 Global Mapper Showcase
- 245 How I use Global Mapper
- 111 Global Mapper Forum Website
