WinGRASS: i.ortho.photo fails

[4everskiff]

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)

[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

[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

[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

[martinl]

Replying to hamish:

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

done for wxPython GUI

r31362

Martin

[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.

[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