[Hamza97]

Hi everybody...
So, I have been using Goku`s wonderful route editor and its DEM capability to build some routes using the worldwide low resolution DEM`s available at viewfinder.org. Yesterday, I came across this site: Bhuvan, Indian Geo-Platform of IRSO which offers high resolution DEM of India, part of CARTOSET series launched by ISRO, the interesting thing was that i knew about this satellite but didn't knew that also offered data for general use and assumed no hi-res DEM data is available for India.. :whistling: .

Anyways, I downloaded some DEM`s from the site, but unfortunately their is a problem. The data is made available in .tiff, .shp, .drb formats but not in .hgt format which Goku`s RE uses. Googling online, i found GDAL which can convert to different formats but unfortunately it shows error in converting the .tiff file to .hgt . Then i came across this utility Terrain File Converter which can convert the DEM, but again when i drag n drop the file to it and press enter the program just closes down... :furiousPC: , also the usage instructions on site are bit sketchy. So can anyone help me how to use this application or any other way to convert the DEM, I am totally confused now... :ko2:

[Lindsayts]

Welcome to the confusing world of geoinfo data/utils. I myself do not have to much experience but we will see what we can do.

The main problem is there appears to be no introductory style of information around and while the GDAL utils are documented these assume you have a real good grounding in geo info systems and cartography.
A major contributor to the confusion is some data formats can be either in raster OR vector formats and its NOT immediately obvious which is used and one can convert raster to vector formats but you cannot do the reverse, HGT being a raster format as is Geotiff.

I have used gdal_translate to convert ESRI adf raster files to geotiff format, it being a raster format like HGT files, differences are Geotiff files have a header structure that tells one exactly what one has and the data is in 32 bit floats, where as HGT files have no header structure at all and the data is in (from memory) 32 bit integers.

What commands did try in the gdal_utils and what errors did you get, I have found the docs quite difficult to understand with little help availible on the net and it appears one has to be quite specfic on the command line with the Gdal utils. I did though manage to get the data as supplied (which was in a non open format) into an understandable and well documented open format., Note my own terrain manipulation program uses geotiff files as direct input.

Lindsay

[Hamza97]

I am getting this error when using GDAL_translate:

Quote

0Warning 1: The corner coordinates of the source are not properly aligned on pla
in latitude/longitude boundaries.
ERROR 1: Image dimensions should be 1201x1201 or 3601x3601.

this was the command i used

gdal_translate -of SRTMHGT cdnd43.tif cdnd43.hgt

[Lindsayts]

Hamza97, on 14 August 2016 - 04:01 AM, said:

I am getting this error when using GDAL_translate:



this was the command i used

gdal_translate -of SRTMHGT cdnd43.tif cdnd43.hgt

GDAL_translate just changes files between co-ordinate systems, it does NOT change there size. It appears that tilecdnd43 is either not 1 degree square or is not the required resolution. HGT files can be 3 or 1 sec resolution (1201 x 1201 or 3601x3601).

Do you have the "listgeo" command, the command "listgeo cdnd43_1.tif" will tell you whats in the file here is an example..........

linw@wolflianli:~/projects/geo/1_sec_terrain$ listgeo Vic_West_1.tiff
TIFFReadDirectory: Warning, Unknown field with tag 42113 (0xa481) encountered.
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0
         144.922361111615  -35.8034722224461 0
      ModelPixelScaleTag (1,3):
         0.000277777777782254 0.000277777777782254 0
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogCitationGeoKey (Ascii,7): "WGS 84"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      GeogSemiMajorAxisGeoKey (Double,1): 6378137
      GeogInvFlatteningGeoKey (Double,1): 298.257223563
      End_Of_Keys.
   End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: User-Defined (1.000000m)

Corner Coordinates:
Upper Left    (144d55'20.50"E, 35d48'12.50"S)
Lower Left    (144d55'20.50"E, 37d 3'22.50"S)
Upper Right   (146d21' 9.50"E, 35d48'12.50"S)
Lower Right   (146d21' 9.50"E, 37d 3'22.50"S)
Center        (145d38'15.00"E, 36d25'47.50"S)

The odd ending in the coordinates (whatever.50"S) is due to the fact in Geotiff files the actual position of the height data is the centre of the cell, In HGT files its the corner, hence positions in geotiff files are half a step out, the step in this case being 1 sec, So 1 degree square geotiff file will be 3600 x 3600 entries, not 3601 x 3601. Hmmm I wonder if that is the issue, I would have though GDAL_translate would allow for that.

Lindsay

[Hamza97]

Hmmmmmm, Here the content of GeoTIF file, all which went over my head... :ko2:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                0                0
         73.9998611111111 16.0001388888889 0
      ModelPixelScaleTag (1,3):
         0.0002777777777777780.0002777777777777780
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,124): "IMAGINE GeoTIFF Support\nERDAS IMAGINE 2014  14.0.1.378\nProjection Name = Geographic (Lat/Lon)\nUnits = dd\nGeoTIFF Units = dd"
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      End_Of_Keys.
   End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)

Corner Coordinates:
Upper Left    ( 73d59'59.50"E, 16d 0' 0.50"N)
Lower Left    ( 73d59'59.50"E, 15d 0' 0.50"N)
Upper Right   ( 74d59'59.50"E, 16d 0' 0.50"N)
Lower Right   ( 74d59'59.50"E, 15d 0' 0.50"N)
Center        ( 74d29'59.50"E, 15d30' 0.50"N)

Quote

......the step in this case being 1 sec, So 1 degree square geotiff file will be 3600 x 3600 entries, not 3601 x 3601......

I readed on net that tif file should be 1201 or 3601 for 3 arc & 1 arc second respectively. There was some calculation shown that why it is 3601 or 1201, but couldn't find the link to that page right now.

[Lindsayts]

Hamza97, on 15 August 2016 - 04:29 AM, said:

Hmmmmmm, Here the content of GeoTIF file, all which went over my head... :ko2:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                0                0
         73.9998611111111 16.0001388888889 0
      ModelPixelScaleTag (1,3):
         0.0002777777777777780.0002777777777777780
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,124): "IMAGINE GeoTIFF Support\nERDAS IMAGINE 2014  14.0.1.378\nProjection Name = Geographic (Lat/Lon)\nUnits = dd\nGeoTIFF Units = dd"
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      End_Of_Keys.
   End_Of_Geotiff.

Do not worry about data above here, this is just raw data

The data below gives the Ellipsoid (WGS 84), the datum ( World Geodetic System 1984) , the actual values specifying the ellipsoids shape, and lastly the origin meridian of the data.
These are used to get the shape of the earth used in the data provided. The reason this is given is the earth shape is actually an irregular oviod ( a flattened sphere with a variable major diameter) and all cartographic data (base data for maps) use a perfect oviod as the earths shape to simplify things a a consequence all mapping data requires the actual shape of the earth the data uses, this is specfied by the Datum and the Ellipsoid.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)

Below is the coordinates of the square of data in the geotif file, its 3601 elements square, it appears GDAL_translate possibly does not think it is 1 complete degree square, which I assume should be

Upper Left 74d 00' 00.50"E, 16d 0' 0.50"N
Lower Left 74d 00' 00.50"E, 15d 0' 0.50"N
Upper Right 75d 00' 00.50"E, 16d 0' 0.50"N
Lower Right 75d 00 '00.50"E, 15d 0' 0.50"N

instead of........................

Corner Coordinates:
Upper Left    ( 73d59'59.50"E, 16d 0' 0.50"N)
Lower Left    ( 73d59'59.50"E, 15d 0' 0.50"N)
Upper Right   ( 74d59'59.50"E, 16d 0' 0.50"N)
Lower Right   ( 74d59'59.50"E, 15d 0' 0.50"N)
Center        ( 74d29'59.50"E, 15d30' 0.50"N)

I readed on net that tif file should be 1201 or 3601 for 3 arc & 1 arc second respectively. There was some calculation shown that why it is 3601 or 1201, but couldn't find the link to that page right now.

What is required would depend on what the program requires to actual specify a complete 1 degree square to a resolution of 1 sec. in reality this only requires a square of data 3600 a side. HGT files actual contain 1 more row, this being the first row of the next tile.

I ASSUME GDAL_translate is complaining about the data does not exactly line up on a 1 degree boundry. as the data is 3601 square. it may come down to exactly how one needs to speficy the data coordinates in the original source of the data.

I agree its confusing, I am almost as much in the dark as you, I have though been working on this much longer to enable me to write my own world modelling program.

Lindsay

[Hamza97]

Well, then think i have to work with 3arc sec data, or wait till Goku implements support for tif file in RE :huh: . Thanks for your assistance.... :sign_thanks:

[Lindsayts]

A problem I have here with 1 sec data is although its readily availible for all of Australia, the web interface is graphical map and its virtually impossible to specify the coordinates to the required accuracy and one has to put up with data maps with odd coordinate corner values and I have yet t figure out how one can use the GDAL_utils to cut out to particular corner values. Its not chronically difficult though to wtite a small program routine to cut out a specfic square, after all its just a tiff image file with a specialised header values for the tiles geoinfo data.

I think it would be a REAL good idea for ANY new route editor to use Geotif files directly as there on of the standard ways of distributing Geoinfo data.

Sorry I could not be of greater help.

Lindsay

[Hamza97]

Sorry for bumping up the thread, BUT....

I have finally managed to convert the 1arc data into .hgt file from the .tif file, with the help of GDAL tools... :yahoo: :dance3:

[Lindsayts]

Hamza97, on 16 September 2016 - 05:10 AM, said:

Sorry for bumping up the thread, BUT....

I have finally managed to convert the 1arc data into .hgt file from the .tif file, with the help of GDAL tools... :yahoo: :dance3:

Would you please give the command or method used, the GDAL toools are very flexible and it is not immediately obvious how to do anything and I am sure it will be of interest to others at some stage.