[GRASS-dev] 6.4.0 blocker bugs

[neteler]

On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka <msieczka@sieczka.org> wrote:

W dniu 15.05.2010 12:40, Maciej Sieczka pisze:

@Markus, Paul:

How do you actually do such updates like [3]?

[3]http://trac.osgeo.org/grass/changeset?old_path=grass%2Ftrunk%2Flib%2Fproj&old=41451&new_path=grass%2Ftrunk%2Flib%2Fproj&new=41452

OK now, so this was actually a revert of a massive update which broke
things.

Right - personally, I find it to be a major problem that we are out of
synch with GDAL now.

Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches
lacks towgs84 definition for Pulkovo 1942(58) datum, which results in
locations created from EPSG codes [4] lacking it too. The towgs84 should
be as in [5].

@Markus, Paul

Do I simply modify gcs.csv alone or should this be a somewhat bigger change?

I have no idea, sorry. If you manage to generate a working patch it
will be hopefully
possible to include it in GRASS.

Markus

Maciek

[4]3120 2172 2173 2174 2175 3333 3334 3335 3329 3330 3331 3332 3328 4179
[5]33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84

--
Maciej Sieczka
http://www.sieczka.org

[Paul_Kelly]

Hi Maciej, Markus,

On Sat, 15 May 2010, Markus Neteler wrote:

On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka <msieczka@sieczka.org> wrote:

OK now, so this was actually a revert of a massive update which broke
things.

Right - personally, I find it to be a major problem that we are out of
synch with GDAL now.

I agree it's rather unfortunate. But I think we would be getting a lot more complaints and bug reports if we had kept in-sync; the way GDAL now handles datum transformation parameters by forcing a default choice just
isn't very desirable for the case of a user setting up a new location.
Having a potentially non-optimal choice being automatically made for them could come back to haunt them in the future, perhaps even years into the future.

Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches
lacks towgs84 definition for Pulkovo 1942(58) datum, which results in
locations created from EPSG codes [4] lacking it too. The towgs84 should
be as in [5].

@Markus, Paul

Do I simply modify gcs.csv alone or should this be a somewhat bigger change?

GRASS already has the correct parameters for Poland. The problem is that it doesn't recognise the datum name "Pulkovo_1942_58"; it is looking for "Pulkovo_1942". I would recommend the patch below for working around this problem. In 7.x I hope to change things around so we can try to work with GDAL's new way of doing things, rather than trying to work around it.

Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about?

Paul

Index: lib/proj/convert.c

--- lib/proj/convert.c (revision 42262)
+++ lib/proj/convert.c (working copy)
@@ -744,6 +744,8 @@
      "Militar_Geographische_Institut",
      "Potsdam_Datum_83",
      "Deutsches_Hauptdreiecksnetz",
+ "Pulkovo_1942_58",
+ "Pulkovo_1942",
      NULL
  };

[Maciej_Sieczka]

Paul,

Thanks for looking into this. I'll get back to you, hopefully this week.

Best,
Maciek

W dniu 16.05.2010 21:18, Paul Kelly pisze:

Hi Maciej, Markus,

On Sat, 15 May 2010, Markus Neteler wrote:

On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka <msieczka@sieczka.org>
wrote:

OK now, so this was actually a revert of a massive update which broke
things.

Right - personally, I find it to be a major problem that we are out of
synch with GDAL now.

I agree it's rather unfortunate. But I think we would be getting a lot
more complaints and bug reports if we had kept in-sync; the way GDAL now
handles datum transformation parameters by forcing a default choice just
isn't very desirable for the case of a user setting up a new location.
Having a potentially non-optimal choice being automatically made for
them could come back to haunt them in the future, perhaps even years
into the future.

Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches
lacks towgs84 definition for Pulkovo 1942(58) datum, which results in
locations created from EPSG codes [4] lacking it too. The towgs84 should
be as in [5].

@Markus, Paul

Do I simply modify gcs.csv alone or should this be a somewhat bigger
change?

GRASS already has the correct parameters for Poland. The problem is that
it doesn't recognise the datum name "Pulkovo_1942_58"; it is looking for
"Pulkovo_1942". I would recommend the patch below for working around
this problem. In 7.x I hope to change things around so we can try to
work with GDAL's new way of doing things, rather than trying to work
around it.

Does this sound acceptable for now - in particular are there any
differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
worrying about?

Paul

Index: lib/proj/convert.c

--- lib/proj/convert.c (revision 42262)
+++ lib/proj/convert.c (working copy)
@@ -744,6 +744,8 @@
"Militar_Geographische_Institut",
"Potsdam_Datum_83",
"Deutsches_Hauptdreiecksnetz",
+ "Pulkovo_1942_58",
+ "Pulkovo_1942",
NULL
};

--
Maciej Sieczka
http://www.sieczka.org

[Maciej_Sieczka]

W dniu 16.05.2010 21:18, Paul Kelly pisze:

On Sat, 15 May 2010, Markus Neteler wrote:

On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka
<msieczka@sieczka.org> wrote:

OK now, so this was actually a revert of a massive update which
broke things.

Right - personally, I find it to be a major problem that we are out
of synch with GDAL now.

I agree it's rather unfortunate. But I think we would be getting a
lot more complaints and bug reports if we had kept in-sync; the way
GDAL now handles datum transformation parameters by forcing a default
choice just isn't very desirable for the case of a user setting up a
new location. Having a potentially non-optimal choice being
automatically made for them could come back to haunt them in the
future, perhaps even years into the future.

Anyway, my point is that gcs.csv as it is now in all GRASS SVN
branches lacks towgs84 definition for Pulkovo 1942(58) datum,
which results in locations created from EPSG codes [4] lacking it
too. The towgs84 should be as in [5].

@Markus, Paul

Do I simply modify gcs.csv alone or should this be a somewhat
bigger change?

GRASS already has the correct parameters for Poland. The problem is
that it doesn't recognise the datum name "Pulkovo_1942_58"; it is
looking for "Pulkovo_1942". I would recommend the patch below for
working around this problem.

Index: lib/proj/convert.c

--- lib/proj/convert.c (revision 42262) +++ lib/proj/convert.c
(working copy) @@ -744,6 +744,8 @@ "Militar_Geographische_Institut",
"Potsdam_Datum_83", "Deutsches_Hauptdreiecksnetz", +
"Pulkovo_1942_58", + "Pulkovo_1942", NULL };

Does the trick for location wizard at GRASS startup (e.g. for epsg 2174
a nice selection GUI pops up) and the resulting PROJ_INFO as well as
`g.proj -p' output are OK, but `g.proj -p epsg=2174' on the command line
still fails to include the towgs84 parameter set at all, so does `g.proj
-c epsg=2174'.

In 7.x I hope to change things around so we can try to work with
GDAL's new way of doing things, rather than trying to work around
it.

Does this sound acceptable for now - in particular are there any
differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
worrying about?

I don't know. All I know is that "Pulkovo 1942 (58)" equal
"33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84" is the official solution
for Poland.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

[Paul_Kelly]

On Mon, 17 May 2010, Maciej Sieczka wrote:

GRASS already has the correct parameters for Poland. The problem is
that it doesn't recognise the datum name "Pulkovo_1942_58"; it is
looking for "Pulkovo_1942". I would recommend the patch below for
working around this problem.

Index: lib/proj/convert.c

--- lib/proj/convert.c (revision 42262) +++ lib/proj/convert.c
(working copy) @@ -744,6 +744,8 @@ "Militar_Geographische_Institut",
"Potsdam_Datum_83", "Deutsches_Hauptdreiecksnetz", +
"Pulkovo_1942_58", + "Pulkovo_1942", NULL };

Does the trick for location wizard at GRASS startup (e.g. for epsg 2174
a nice selection GUI pops up) and the resulting PROJ_INFO as well as
`g.proj -p' output are OK, but `g.proj -p epsg=2174' on the command line
still fails to include the towgs84 parameter set at all, so does `g.proj
-c epsg=2174'.

It does include the datum though (there is a line "datum: S-42"), which means that the default GRASS parameters for S-42 (over the whole region it is used in) will be used where necessary (e.g. in g.proj -jf epsg=2174). I think this is the best we can hope for for now; in GRASS versions 6.2.1 and earlier g.proj when used on the command-line used to interactively prompt for the user to select a datum transformation if the datum was not fully specified, but this behaviour had to be removed when we were working towards removing all command-line interaction from modules so they could be used in scripts with no side-effects. Since GRASS 6.2.2 if you want g.proj to give you a choice of datum transformation parameters (when one is available), you have to add "datumtrans=-1" to the command-line; this is what the location creation GUIs do to determine the available sets of datum transformation parameters.

Does this sound acceptable for now - in particular are there any
differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
worrying about?

I don't know.

OK well I will guess that any differences are not relevant for us here, and will see about adding the equivalence of Pulkovo_1942_58 and Pulkovo_1942 to SVN.

Paul

[Paul_Kelly]

On Wed, 19 May 2010, Paul Kelly wrote:

On Mon, 17 May 2010, Maciej Sieczka wrote:

Does this sound acceptable for now - in particular are there any
differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
worrying about?

I don't know.

OK well I will guess that any differences are not relevant for us here, and will see about adding the equivalence of Pulkovo_1942_58 and Pulkovo_1942 to SVN.

Actually it is a bit more complicated than this. According to the EPSG database, Pulkovo_1942 is used in the following countries:
Armenia; Azerbaijan; Belarus; Estonia; Georgia; Kazakhstan; Kyrgyzstan; Latvia; Lithuania; Moldova; Russian Federation; Tajikistan; Turkmenistan; Ukraine; Uzbekistan.
and Pulkovo_1942_58 is used in the following countries:
Albania; Bulgaria; Czech Republic; Germany (former DDR); Hungary; Poland; Romania; Slovakia.

So it seems to me that we should have two separate datum entries in GRASS, and that it is arguably a bug treating them both as one.

I would appreciate some suggestions on what the GRASS abbreviation for Pulkovo 1942 (58) should be; for Pulkovo 1942 it is S-42 - which IMHO is not nice as it has a capital letter in it, but of course we can't change it without breaking existing locations.

Paul

[Maciej_Sieczka]

W dniu 20.05.2010 17:48, Paul Kelly pisze:

On Wed, 19 May 2010, Paul Kelly wrote:

On Mon, 17 May 2010, Maciej Sieczka wrote:

Does this sound acceptable for now - in particular are there any
differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
worrying about?

I don't know.

OK well I will guess that any differences are not relevant for us
here, and will see about adding the equivalence of Pulkovo_1942_58 and
Pulkovo_1942 to SVN.

Actually it is a bit more complicated than this. According to the EPSG
database, Pulkovo_1942 is used in the following countries:
Armenia; Azerbaijan; Belarus; Estonia; Georgia; Kazakhstan; Kyrgyzstan;
Latvia; Lithuania; Moldova; Russian Federation; Tajikistan;
Turkmenistan; Ukraine; Uzbekistan.
and Pulkovo_1942_58 is used in the following countries:
Albania; Bulgaria; Czech Republic; Germany (former DDR); Hungary;
Poland; Romania; Slovakia.

So it seems to me that we should have two separate datum entries in
GRASS, and that it is arguably a bug treating them both as one.

I would appreciate some suggestions on what the GRASS abbreviation for
Pulkovo 1942 (58) should be; for Pulkovo 1942 it is S-42 - which IMHO is
not nice as it has a capital letter in it, but of course we can't change
it without breaking existing locations.

Hi,

Another solution is available now. In GDAL stable branch r19810 https://svn.osgeo.org/gdal/branches/1.7/gdal/data/gcs.override.csv, overrides for problematic Polish CRSes [1] were added [2]. After copying it over $GISBASE/etc/ogr_csv/gcs.override.csv, the wxGUI location wizard behaves OK when using Polish EPSG codes [1]. Same as g.proj does, e.g. instead of a warning and a lacking towgs84:

---
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2174
UWAGA:Datum <Pulkovo_1942_58> not recognised by GRASS and no parameters
       found
+proj=sterea +lat_0=51.67083333333333 +lon_0=16.67222222222222 +k=0.9998 +x_0=3703000 +y_0=5627000 +no_defs +a=6378245 +rf=298.3 +to_meter=1
---

it returns a correct string:

---
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2174
+proj=sterea +lat_0=51.67083333333333 +lon_0=16.67222222222222 +k=0.9998 +x_0=3703000 +y_0=5627000 +no_defs +a=6378245 +rf=298.3 +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +to_meter=1
---

Can I upload the new gcs.override.csv to GRASS SVN? Mind it also overrides the current GRASS ETRS89 definition, as per datum.table:

---
# Datum parameters for/from European Terrestrial Reference System ETRS89
etrs89 "European_Terrestrial_Reference_System_1989" grs80 dx=0 dy=0 dz=0
---

with:

---
# Backported from 1.8dev (see ticket #3579)
4258,ETRS89,6258,European Terrestrial Reference System 1989,6258,9122,7019,8901,1,0,6422,9603,0,0,0,
---

thus, e.g. EPSG 2180 would no longer be:

--
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2180
+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1
---

but:

---
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2180
+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0,0,0,0,0,0,0 +to_meter=1
---

I guess it doesn't hurt; does it?

[1] 3120 2172 2173 2174 2175 3333 3334 3335 3329 3330 3331 3332 3328 4179

[2] http://trac.osgeo.org/gdal/ticket/3579#comment:7

Best,
Maciek

--
Maciej Sieczka
http://www.sieczka.org

[Maciej_Sieczka]

W dniu 17.06.2010 21:13, Maciej Sieczka pisze:

W dniu 20.05.2010 17:48, Paul Kelly pisze:

On Wed, 19 May 2010, Paul Kelly wrote:

On Mon, 17 May 2010, Maciej Sieczka wrote:

Does this sound acceptable for now - in particular are there any
differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
worrying about?

I don't know.

OK well I will guess that any differences are not relevant for us
here, and will see about adding the equivalence of Pulkovo_1942_58 and
Pulkovo_1942 to SVN.

Actually it is a bit more complicated than this. According to the EPSG
database, Pulkovo_1942 is used in the following countries:
Armenia; Azerbaijan; Belarus; Estonia; Georgia; Kazakhstan; Kyrgyzstan;
Latvia; Lithuania; Moldova; Russian Federation; Tajikistan;
Turkmenistan; Ukraine; Uzbekistan.
and Pulkovo_1942_58 is used in the following countries:
Albania; Bulgaria; Czech Republic; Germany (former DDR); Hungary;
Poland; Romania; Slovakia.

So it seems to me that we should have two separate datum entries in
GRASS, and that it is arguably a bug treating them both as one.

I would appreciate some suggestions on what the GRASS abbreviation for
Pulkovo 1942 (58) should be; for Pulkovo 1942 it is S-42 - which IMHO is
not nice as it has a capital letter in it, but of course we can't change
it without breaking existing locations.

Another solution is available now. In GDAL stable branch r19810
https://svn.osgeo.org/gdal/branches/1.7/gdal/data/gcs.override.csv,
overrides for problematic Polish CRSes [1] were added [2]. After copying
it over $GISBASE/etc/ogr_csv/gcs.override.csv, the wxGUI location wizard
behaves OK when using Polish EPSG codes [1]. Same as g.proj does, e.g.
instead of a warning and a lacking towgs84:

Committed as r42664, r42665, r42666 to trunk, develbranch_6 and releasebranch_6_4, respectively.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

[neteler]

Hi,

time to get out 6.4.0final

Please check the list at
https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&priority=blocker&priority=critical&milestone=6.4.0&order=id

Several of the entries seem to be (almost?) solved but awaiting
feedback/closure. Perhaps for the others we have to revisit of
"critical" state is really reflecting the actual state (in a context
of a 400 modules GIS).

Markus

[Markus_GRASS]

Markus Neteler wrote:

time to get out 6.4.0final

Please...

Please check the list at
https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&priority=blocker&priority=critical&milestone=6.4.0&order=id

Several of the entries seem to be (almost?) solved but awaiting
feedback/closure. Perhaps for the others we have to revisit of
"critical" state is really reflecting the actual state (in a context
of a 400 modules GIS).

The latest officially stable release of GRASS is GRASS 6.2.3. The
reluctance to release 6.4 means that 6.2.3 is still regarded as more
stable??? A release candidate is by definition not stable, even if it
might be reasonably stable by nature. This is not only about a stable
wingrass, this is also about what is available in the standard
repositories of major Linux distros. Fedora, which has a reputation of
being adventurous, provides 6.3.0. If the aim is to provide an
up-to-date GIS package to as many users as possible, a fairly recent
GRASS version must be available through standard Linux repositories.

Since I am on it, we should provide a Linux x86_64 installer, today
the minority of Linux users have a i686 system, I get complains that
there is no 64bit Linux binary installer. 64bit Linux has been
available for a couple of years, and most systems sold in the past say
four years support 64bit (excluding palms and netbooks).

IMHO, grass should officially release a new version every 6 months,
synchronized to the release schedule of major Linux distros. The more
feedback from users, the better. 6.4 should go out now, in the last
quarter of 2010(!!!) there should be 6.5, bugs can be fixed in e.g.
6.4.1 and 6.5.1. I am aware that 6.5 aka devbr6 is not supposed to be
a stable release, but neither was 6.3.

My 2c, coming from a summer school where I had a hard time explaining
the grass release schedule to GIS professionals.

Markus M

[martinl]

Hi,

2010/7/5 Markus Metz <markus.metz.giswork@googlemail.com>:

Markus Neteler wrote:

time to get out 6.4.0final

Please...

one huge +1 ...

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[neteler]

On Mon, Jul 5, 2010 at 10:05 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2010/7/5 Markus Metz <markus.metz.giswork@googlemail.com>:

Markus Neteler wrote:

time to get out 6.4.0final

Please...

one huge +1 ...

I learned that we should await the ctypes port to get rid of SWIG?

(the 64bit binaries we can create as soon we can migrate to a new
OSGeo virtual machine - soon).

Markus

[martinl]

Hi,

2010/7/5 Markus Neteler <neteler@osgeo.org>:

one huge +1 ...

I learned that we should await the ctypes port to get rid of SWIG?

ctypes are still not backported to 6.5. Then we would need another RC
for 6.4.0.... I would vote for testing ctypes in 6.5 first and then
backport it to 6.4.1. Let's go ahead, and release 6.4.0 ASAP.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Glynn_Clements1]

Markus Neteler wrote:

>>> time to get out 6.4.0final
>>
>> Please...
>
> one huge +1 ...

I learned that we should await the ctypes port to get rid of SWIG?

SWIG is only used within GRASS for the wxGUI vdigit and nviz modules.
It's also used to generate wrappers for programmers who wish to access
the libraries directly, but these aren't used by any part of GRASS.

I suggest disabling all of this in the final release. The vdigit and
nviz modules don't work on Windows, and aren't particularly robust on
other platforms (and being loaded in-process means that any problems
affect the GUI as a whole, not just the vdigit/nviz modules).

The SWIG wrappers for the libraries are barely usable and are planned
to be replaced, so we shouldn't be encouraging their use.

IOW:

1. The "swig" directory should be removed from DIRS in the top-level
Makefile, so it isn't built (unless the user builds it manually).

2. Official binaries shouldn't use --with-python; this will prevent
the vdigit and nviz modules from being built.

3. Optionally back-port the ctypes wrappers (lib/python/ctypes). Even
if this doesn't work (fails to build or generates broken wrappers), it
shouldn't break anything which would otherwise work.

4. Optionally back-port the ctypes-based nviz module (wxnviz.py). This
has most of the same issues as nviz/vdigit (i.e. the GRASS libraries
are being accessed directly from the GUI process, so a segfault or
G_fatal_error() will kill the GUI), but not all of them.

4b. Alternatively, back-port the changes but not wxnviz.py itself. The
result is equivalent to just building --without-python (i.e. the GUI
will try to import the wxnviz module, fail, and warn that it's
disabled), except that the user can drop in wxnviz.py from SVN if they
want to try it out.

--
Glynn Clements <glynn@gclements.plus.com>

[Helena_Mitasova]

On Jul 5, 2010, at 5:11 PM, Glynn Clements wrote:

Markus Neteler wrote:

time to get out 6.4.0final

Please...

one huge +1 ...

I learned that we should await the ctypes port to get rid of SWIG?

SWIG is only used within GRASS for the wxGUI vdigit and nviz modules.
It's also used to generate wrappers for programmers who wish to access
the libraries directly, but these aren't used by any part of GRASS.

I suggest disabling all of this in the final release. The vdigit and
nviz modules don't work on Windows, and aren't particularly robust on
other platforms (and being loaded in-process means that any problems
affect the GUI as a whole, not just the vdigit/nviz modules).

Glynn,
I assume you are talking about wxnviz here, not the TclTk based nviz
which runs on windows just fine?

I agree that it is really important to get 6.4 final released, especially given
that FOSS4G in Barcelona is coming soon

Helena

The SWIG wrappers for the libraries are barely usable and are planned
to be replaced, so we shouldn't be encouraging their use.

IOW:

1. The "swig" directory should be removed from DIRS in the top-level
Makefile, so it isn't built (unless the user builds it manually).

2. Official binaries shouldn't use --with-python; this will prevent
the vdigit and nviz modules from being built.

3. Optionally back-port the ctypes wrappers (lib/python/ctypes). Even
if this doesn't work (fails to build or generates broken wrappers), it
shouldn't break anything which would otherwise work.

4. Optionally back-port the ctypes-based nviz module (wxnviz.py). This
has most of the same issues as nviz/vdigit (i.e. the GRASS libraries
are being accessed directly from the GUI process, so a segfault or
G_fatal_error() will kill the GUI), but not all of them.

4b. Alternatively, back-port the changes but not wxnviz.py itself. The
result is equivalent to just building --without-python (i.e. the GUI
will try to import the wxnviz module, fail, and warn that it's
disabled), except that the user can drop in wxnviz.py from SVN if they
want to try it out.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Glynn_Clements1]

Helena Mitasova wrote:

>> I learned that we should await the ctypes port to get rid of SWIG?
>
> SWIG is only used within GRASS for the wxGUI vdigit and nviz modules.
> It's also used to generate wrappers for programmers who wish to access
> the libraries directly, but these aren't used by any part of GRASS.
>
> I suggest disabling all of this in the final release. The vdigit and
> nviz modules don't work on Windows, and aren't particularly robust on
> other platforms (and being loaded in-process means that any problems
> affect the GUI as a whole, not just the vdigit/nviz modules).

Glynn,
I assume you are talking about wxnviz here, not the TclTk based nviz
which runs on windows just fine?

Correct.

--
Glynn Clements <glynn@gclements.plus.com>