Opened 12 years ago

Closed 11 years ago

#168 closed defect (wontfix)

WinGRASS: i.ortho.photo fails

Reported by: 4everskiff Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: Default Version: 6.3.0
Keywords: Cc:
CPU: Unspecified Platform: Unspecified

Description

Ortho photo rectification fails.

error output:

can't unset "env(GRASS_RENDER_IMMEDIATE)": no such element in array can't unset "env(GRASS_RENDER_IMMEDIATE)": no such element in array

while executing

"unset env(GRASS_RENDER_IMMEDIATE)"

(menu invoke)

Change History (7)

comment:1 Changed 12 years ago by hamish

i.ortho.photo will not work in native MS-Windows. It needs xmons. The imagery/Makefile should ensure that it is only built if GRASS is compiled with X11 support. Is the module present if you try from the command line?

? Hamish

comment:2 in reply to:  1 Changed 12 years ago by marcopx

Replying to hamish:

i.ortho.photo will not work in native MS-Windows. It needs xmons. The imagery/Makefile should ensure that it is only built if GRASS is compiled with X11 support. Is the module present if you try from the command line?

? Hamish

NO, you're right. Since I didn't have i.ortho.photo module in my *not built modules* list after make command, I supposed that the monitors problem was fixed in it (I didn't know that the make rules was changed).

Good to know, I have to add it to the missing modules list [1] What are the other modules not built, over the ones already listed in [1]?

[1] http://grass.osgeo.org/grass63/binary/mswindows/native/#Missing%20Modules

Thanks

Marco

comment:3 Changed 12 years ago by hamish

What are the other modules not built,

Anything that needs X11 will not work.

For the Imagery modules, see those listed as XMONBASED: http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/imagery/Makefile

optimally the GUI should grey out their menu entries if they are not present.

r.digit now has a Makefile entry like the imagery modules. Probably many of the d.* will not work (d.where, d.what.*, etc), although some of those have non-interactive modes now (e.g. d.path).

It is not a matter of simply "fixing" those modules. They require xmons to work and need to be completely rewritten before they can function on native MS Windows.

As for r.li I am not aware of the issues causing them to fail.

Hamish

comment:4 in reply to:  3 ; Changed 12 years ago by martinl

Replying to hamish:

optimally the GUI should grey out their menu entries if they are not present.

done for wxPython GUI

r31362

Martin

comment:5 in reply to:  3 Changed 12 years ago by glynn

Replying to hamish:

Anything that needs X11 will not work.

To be precise, anything which requires monitors (X or otherwise) will not work. The problem is the monitor/driver architecture, not X. We already have libW11, which allows the use of XDRIVER under Cygwin without requiring X.

In practice, it doesn't really matter, as anything which works with the PNG driver will likely work with direct rendering. I only mention this in case someone is thinking of fixing the issue, in which case it needs to be remembered that it's not X which is the problem, but the communication between the client and the monitor.

comment:6 in reply to:  4 Changed 12 years ago by hamish

Hamish:

optimally the GUI should grey out their menu entries if they are not present.

Replying to martinl:

done for wxPython GUI

r31362

nice one.

H

comment:7 Changed 11 years ago by martinl

CPU: Unspecified
Platform: Unspecified
Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.