2018-07-19 06:06 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001432MonteverdiGeneralpublic2017-09-18 16:16
Assigned Togpasero 
PlatformOSOS Version10
Summary0001432: RGE Alti files inverted on Monteverdi
DescriptionSome DEM files from 'RGE Alti' are inverted in Y axis when loaded in monteverdi. The file format is .BIL (EHdr -- ESRI .hdr Labelled).

The projection system is not recognized by Monteverdi and it inverts the image only in Y axis.
Steps To ReproduceLoad an RGE alti image (see attached file)
Additional InformationThe original file to reproduce the problem is larger than 2Mbytes.

File available till 10th July 2017:

 Please contact me to get it after the expiration date.
TagsNo tags attached.
Attached Files

duplicate of 0001431resolvedgpasero RGE Alti files inverted on Monteverdi 



gpasero (administrator)

I think I managed to reproduce the bug using sample datasets from IGN. The images are in GeoTIFF, but when opened in monteverdi, the projection is marked "Unknown", and the Y axis is inverted. gdalinfo reports the following details:

Driver: GTiff/GeoTIFF
Files: RGEALTI_FXX_0574_6274_SRC_LAMB93_IGN69.tif
Size is 1000, 1000
Coordinate System is:
LOCAL_CS["Lambert 93",
Origin = (573999.500000000000000,6274000.500000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)

I think the LOCAL_CS projections are not handled in monteverdi.


gpasero (administrator)

For ASC files, no coordinate system is detected by GDAL :

gdalinfo RGEALTI_FXX_0577_6272_MNT_LAMB93_IGN69.asc
Driver: AAIGrid/Arc/Info ASCII Grid
Files: RGEALTI_FXX_0577_6272_MNT_LAMB93_IGN69.asc
Size is 1000, 1000
Coordinate System is `'
Origin = (576999.500000000000000,6272000.500000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Corner Coordinates:
Upper Left ( 576999.500, 6272000.500)
Lower Left ( 576999.500, 6271000.500)
Upper Right ( 577999.500, 6272000.500)
Lower Right ( 577999.500, 6271000.500)
Center ( 577499.500, 6271500.500)
Band 1 Block=1000x1 Type=Float32, ColorInterp=Undefined
  NoData Value=-99999


gpasero (administrator)

I see several options:
1 - offer an extended filename to manually specify the right cartographic projection
2 - detect RGEAlti products as done for sensor products (with OSSIM?) and fix the ProjRef.
3 - create a dedicated otb::ImageIO for RGEAlti files (this ImageIO would internally use GDAL)
4 - create a new GDAL plugin for RGEAlti files.
5 - do nothing, let the user convert these datasets using gdal_translate

Any preference?


gpasero (administrator)

For me, solutions 1 and 3 seem good choices. However, this is not really a bugfix since the problem comes from incomplete image files.


gpasero (administrator)

For BIL format, gdalinfo gives the following output :

Driver: EHdr/ESRI .hdr Labelled
Files: RGEALTI_FXX_2125_47197_MNT_WGS84_EGM96.bil
Size is 1000, 1000
Coordinate System is:
Origin = (2.124708476649060,47.196768603203402)
Pixel Size = (0.000011000000000,-0.000011000000000)


gpasero (administrator)

Fix pushed on develop:

It should handle the case of BIL format. The support of other formats is not strictly part of this issue, so I will consider it resolved.


julien (administrator)

Good. Still all those datasets have a negative Y spacing, so I find it strange that they appeared flipped in Monteverdi, even in unprojected mode, which should use the spacing.


gpasero (administrator)

Not exactly, this is the eternal problem of "Unprojected mode":
- If you open a dataset with unknown projection first, monteverdi uses unprojected mode, and sets by default the Y-axis downwards (because this is what you would expect to view a plain jpeg file correctly, with spacing [1,1] ). In this case, the negative Y spacing is correctly interpreted, but the coordinate system in the rendering view is flipped.
- If you open a dataset with valid projection and negative spacing first, then you open a second dataset with unknown projection: monteverdi first sets the Y-axis upwards before switching to unprojected mode. In this case the second image is not flipped.

Do you suggest that we check the sign of the Y-spacing before initializing the coordinate system in the unprojected mode ? (it may re-open past issues/discussions)

-Issue History
Date Modified Username Field Change
2017-06-19 17:08 penaluques New Issue
2017-06-22 17:20 grizonnetm Status new => confirmed
2017-06-22 17:20 grizonnetm OS Windows =>
2017-06-22 17:20 grizonnetm Platform Windows =>
2017-09-07 17:35 gpasero Priority low => urgent
2017-09-11 17:59 gpasero Assigned To => gpasero
2017-09-11 17:59 gpasero Status confirmed => assigned
2017-09-11 18:02 gpasero Note Added: 0004276
2017-09-11 18:38 gpasero Note Added: 0004277
2017-09-11 18:51 gpasero Note Added: 0004278
2017-09-12 09:56 gpasero Note Added: 0004279
2017-09-13 10:12 gpasero Note Added: 0004283
2017-09-13 17:12 gpasero Note Added: 0004284
2017-09-13 17:12 gpasero Status assigned => resolved
2017-09-13 17:12 gpasero Resolution open => fixed
2017-09-15 11:37 julien Note Added: 0004288
2017-09-15 16:57 gpasero Note Added: 0004290
2017-09-18 16:16 gpasero Relationship added duplicate of 0001431
+Issue History