#1544: (Windows/osgeo4w) r.out.tiff is broken
-------------------------+--------------------------------------------------
Reporter: lutra | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Default | Version: unspecified
Keywords: | Platform: MSWindows 7
Cpu: Unspecified |
-------------------------+--------------------------------------------------
The module seems to work fine under Linux.
Under Windows/OSGeo4w/6.4.2rc3 when launching the module I get:
{{{
Traceback (most recent call last):
File "C:/OSGeo4W/apps/grass/grass-6.4.2RC3/etc/wxpython/wx
gui.py", line 492, in OnMenuCmd
menuform.GUI(parent = self).ParseCommand(cmd)
File "C:\OSGeo4W\apps\grass\grass-6.4.2RC3\etc\wxpython\gu
i_modules\menuform.py", line 1732, in ParseCommand
blackList = _blackList)
File "C:\OSGeo4W\apps\grass\grass-6.4.2RC3\etc\python\gras
s\script\task.py", line 460, in parse_interface
tree = etree.fromstring(get_interface_description(name))
File
"C:\OSGeo4W\apps\Python27\lib\xml\etree\ElementTree.py",
line 1283, in XML
return parser.close()
File
"C:\OSGeo4W\apps\Python27\lib\xml\etree\ElementTree.py",
line 1636, in close
self._raiseerror(v)
File
"C:\OSGeo4W\apps\Python27\lib\xml\etree\ElementTree.py",
line 1488, in _raiseerror
raise err
xml.etree.ElementTree
.
ParseError
:
no element found: line 1, column 0
}}}
When running it under QGIS I get the error message you can see in the
attached image
Replying to [ticket:1544 lutra]:
> The module seems to work fine under Linux.
>
> > When running it under QGIS I get the error message you can see in the
attached image
That looks like a broken tiff library in the osgeo4w package. Try
downgrading the tiff library through the osgeo4w package manager.
Replying to [comment:4 lutra]:
>
> > That looks like a broken tiff library in the osgeo4w package. Try
downgrading the tiff library through the osgeo4w package manager.
>
> correct, downgrading makes it work.
has been this bug in `libtiff` package already reported?
Replying to [comment:6 lutra]:
>
> > has been this bug in `libtiff` package already reported?
>
>
> don't think so. So it is just needed to file a ticket in the osgeo4w
tracker?
Yes please! Several different wingrass users (also MartinL) have
experienced problems which could be solved by downgrading the osgeo4w
`libtiff` package.
BTW, also make sure you are not using the osgeo4w `proj4` package version
4.7.1, but 4.7.0, there are OS-independent bugs in `proj4-4.7.1` which is
not yet officially released but proj4 is a core component for other osgeo
projects (most importantly gdal).
> BTW, also make sure you are not using the osgeo4w `proj4` package
version 4.7.1, but 4.7.0, there are OS-independent bugs in `proj4-4.7.1`
which is not yet officially released but proj4 is a core component for
other osgeo projects (most importantly gdal).
so also `proj4-4.7.1` is bugged and need to be fixed/reported in osgeo4w?
> BTW, also make sure you are not using the osgeo4w `proj4` package
version 4.7.1, but 4.7.0, there are OS-independent bugs in `proj4-4.7.1`
which is not yet officially released but proj4 is a core component for
other osgeo projects (most importantly gdal).
the version available now in osgeo4w is 4.7.0-4, so you may want to drop a
mail to osgeo4w packagers *before* they package 4.7.1
xml.etree.ElementTree
.
ParseError
:
no element found: line 1, column 0
Would someone mind fixing the code to generate a more meaningful error
message when --interface-description fails (e.g. when the resulting
string is empty or consists solely of whitespace)?
From OSGeo4W tracker, warmerdam January 2012:
> I have rebuilt the libtiff dll package with VC7.1 which did not use
manifests and this made it so that the tiffinfo.exe binary works again.
>
> It seems that any DLL built using manifests and depending on manifest
oriented runtimes requires that the .exe also be built with manifests.
>
> This is in place now, but I hope to do some investigation of a way
forward that does not depend on ancient compiler versions.