[GRASS-dev] New OpenGL options to test for native Mac and Win NVIZ

GRASS GIS GRASS GIS developer
1

William,

Here is an update.

I downloaded and installed your Mac binaries and all supporting libraries. I
even installed your tcltk 8.4.13 to override the Active States version I had
installed.

-Changing tcltk does not affect nviz running in the version of GRASS I'm
compiling from the cvs.

-Your binaries won't display any maps on my system, but they will run
nviz...sort of. The normal map display bombs somehow with the gism PNG
driver not getting selected. My guess is that somehow the following line is
not working in your binaries on my system...

    set env(MONITOR_OVERRIDE) "gism"

-nviz partly works. It will display the map it started with. But the file
browser doesn't work for loading any new maps (error below). Same for
vectors. The map display keeps spreading over the control panels, though
this can be fixed by resizing a bit. The color selectors don't work either.
Most other controls for rasters seem to work.

-I can copy your version of the nviz binary to my build and nviz works like
yours does. So it is something in the compilation, but I don't know what.

Michael

== nviz file browser error ===

invalid command name ".browse_topo_file.main.files.f.list"
invalid command name ".browse_topo_file.main.files.f.list"
    while executing
"$w.main.files.f.list delete 0 end"
    (procedure "map_browser_list_mapset" line 6)
    invoked from within
"map_browser_list_mapset $w"
    (procedure "set_map_browser_mapset" line 5)
    invoked from within
"set_map_browser_mapset $w {}"
    (procedure "create_map_browser" line 92)
    invoked from within
"create_map_browser .browse_topo_file surf 1"
    (procedure "ap_get_topofile" line 4)
    invoked from within
"ap_get_topofile"
    invoked from within
".temporary_new_surf.f2.map invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 23)
    invoked from within
"tk::ButtonUp .temporary_new_surf.f2.map"
    (command bound to event)
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Tue, 18 Jul 2006 08:53:31 -0500
To: Michael Barton <michael.barton@asu.edu>
Subject: Re: [GRASS-dev] New OpenGL options to test for native Mac and Win
NVIZ

On Jul 17, 2006, at 6:06 PM, Michael Barton wrote:

So I just get rid of these flags? Or say without=glw?...

--with-glw-includes=/usr/X11R6/include --with-glw-libs=/usr/X11R6/lib

I think glw may default to on, so --without-glw. Doesn't hurt to
make sure. This could have something to do with:

I've done a bit of futzing with my system, rebuilding GRASS in
several ways.
In all cases, nviz doesn't work. This is the latest result.

I disabled all earlier versions of tcltk, made an Active States
installation
of 8.4.13 I just downloaded today the default, changed the
configuration
options to just look for this version, set GRASS_TCLSH=tclsh and
GRASS_WISH=wish (i.e., the 8.4.13 version). When I run GRASS and
try to use
nviz, here is the error I get (it looks a bit different from before):

GRASS 6.1.cvs (spearfish60_test):~ > nviz elevation=elevation_dem
Loading Data
Update elev null mask
Loading Data
translating colors
Bus error

========= crash log ==========

===== Monday, July 17, 2006 5:38:42 PM America/Phoenix =====
**********

Host Name: CMBARTON-iMac
Date/Time: 2006-07-17 17:38:58.006 -0700
OS Version: 10.4.7 (Build 8J135)
Report Version: 4

Command: nviz
Path:
/Applications/Grass/grass61cvs.app/Contents/Resources/grass-6.1.cvs/
bin/nviz
Parent: bash [7865]

Version: ??? (???)

PID: 8024
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0 libX11.6.dylib 0x9c2c4000 XQueryExtension + 108
1 libGL.1.dylib 0x9c3df848 glXQueryExtension + 56
2 nviz 0x000132ec Togl_CreateWindow + 64
(crt.c:355)

Somehow it's still getting the X11 OpenGL. Maybe GLw is messing it up.

In include/config.h, which OPENGL_* define is set?

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that
the past isn't a fiction designed to account for the discrepancy
between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe

2

I brought home the PowerBook to test NVIZ. Indeed, some problems.

On Jul 18, 2006, at 2:19 PM, Michael Barton wrote:

William,

Here is an update.

I downloaded and installed your Mac binaries and all supporting libraries. I
even installed your tcltk 8.4.13 to override the Active States version I had
installed.

-Changing tcltk does not affect nviz running in the version of GRASS I'm
compiling from the cvs.

From Glynn's comment today, this is right - NVIZ is C linked to the Tcl/Tk libraries, so it will use whichever Tcl/Tk it was linked against at build time. So it's not affected by GRASS_TCLSH or GRASS_WISH.

-Your binaries won't display any maps on my system, but they will run
nviz...sort of. The normal map display bombs somehow with the gism PNG
driver not getting selected. My guess is that somehow the following line is
not working in your binaries on my system...

    set env(MONITOR_OVERRIDE) "gism"

I also get an error starting gis.m:

child process exited abnormally
     while executing
"exec -- d.font romans >& /dev/null"
     ("eval" body line 1)
     invoked from within
"eval exec -- $cmd $args >& /dev/null"
     (procedure "run" line 6)
     invoked from within
"run d.font romans"
     ("eval" body line 1)
     invoked from within
"eval run $cmd $args"
     (procedure "runcmd" line 6)
     invoked from within
"runcmd "d.font romans""
     (procedure "MapCanvas::runprograms" line 25)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 43)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

After clicking thru the error, no maps will display.

BUT, gis.m (same universal build of GRASS) DOES work on my MacBook. I suspect there is a cross-compiler build error here. Now that I think about it, the font part of building GRASS is one place I had to fiddle with things - make wants to run a program to process the fonts... hm, maybe an endian thing. I'll have to check that out.

I suspect if you get a PPC build to work, it'll be fine. In fact, since NVIZ and wish have nothing to do with each other, you can do a normal X11 build, but use the Aqua wish when you run the GUI.

-nviz partly works. It will display the map it started with. But the file
browser doesn't work for loading any new maps (error below). Same for
vectors. The map display keeps spreading over the control panels, though
this can be fixed by resizing a bit. The color selectors don't work either.
Most other controls for rasters seem to work.

Ah, I see what you mean now. And that's a nasty wiggling on the browser dialog box! This DID work before. Something that changed in the NVIZ source between my first success (the browser did work and I could add other rasters and vectors) and the refinements must have broke it (I only tested loading the initial raster after that).

More to investigate...

I also noticed the GUI layout problems. I figured that was a separate issue, with the GUI widgets that are drawn natively by OSX (like buttons and menus) being a little bigger than in X11.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

3

OK. Glad to hear that the issues I reported are reproducible. That's a good
start to figuring out what's what. Thanks for all the work on nviz for Mac.
I'm waiting to buy a MacBook Pro until these are worked out, because GRASS
is important to my research.

If you haven't checked out the GUI recently, you should do so. I use the
command line for some stuff, but TclTk can be quite nice with an
understanding of how it works. And it looks good in the aqua version for
Mac. I'm guessing that, at least at first, switching to wxPython will do
more 'under the hood' of the GUI than change the overall look/feel a lot.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: William Kyngesburye <woklist@kyngchaos.com>
Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Wed, 19 Jul 2006 20:09:04 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] New OpenGL options to test for native Mac and Win
NVIZ

I brought home the PowerBook to test NVIZ. Indeed, some problems.

On Jul 18, 2006, at 2:19 PM, Michael Barton wrote:

William,

Here is an update.

I downloaded and installed your Mac binaries and all supporting
libraries. I
even installed your tcltk 8.4.13 to override the Active States
version I had
installed.

-Changing tcltk does not affect nviz running in the version of
GRASS I'm
compiling from the cvs.

From Glynn's comment today, this is right - NVIZ is C linked to the
Tcl/Tk libraries, so it will use whichever Tcl/Tk it was linked
against at build time. So it's not affected by GRASS_TCLSH or
GRASS_WISH.

-Your binaries won't display any maps on my system, but they will run
nviz...sort of. The normal map display bombs somehow with the gism PNG
driver not getting selected. My guess is that somehow the following
line is
not working in your binaries on my system...

    set env(MONITOR_OVERRIDE) "gism"

I also get an error starting gis.m:

child process exited abnormally
child process exited abnormally
     while executing
"exec -- d.font romans >& /dev/null"
     ("eval" body line 1)
     invoked from within
"eval exec -- $cmd $args >& /dev/null"
     (procedure "run" line 6)
     invoked from within
"run d.font romans"
     ("eval" body line 1)
     invoked from within
"eval run $cmd $args"
     (procedure "runcmd" line 6)
     invoked from within
"runcmd "d.font romans""
     (procedure "MapCanvas::runprograms" line 25)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 43)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

After clicking thru the error, no maps will display.

BUT, gis.m (same universal build of GRASS) DOES work on my MacBook.
I suspect there is a cross-compiler build error here. Now that I
think about it, the font part of building GRASS is one place I had to
fiddle with things - make wants to run a program to process the
fonts... hm, maybe an endian thing. I'll have to check that out.

I suspect if you get a PPC build to work, it'll be fine. In fact,
since NVIZ and wish have nothing to do with each other, you can do a
normal X11 build, but use the Aqua wish when you run the GUI.

-nviz partly works. It will display the map it started with. But
the file
browser doesn't work for loading any new maps (error below). Same for
vectors. The map display keeps spreading over the control panels,
though
this can be fixed by resizing a bit. The color selectors don't work
either.
Most other controls for rasters seem to work.

Ah, I see what you mean now. And that's a nasty wiggling on the
browser dialog box! This DID work before. Something that changed in
the NVIZ source between my first success (the browser did work and I
could add other rasters and vectors) and the refinements must have
broke it (I only tested loading the initial raster after that).

More to investigate...

I also noticed the GUI layout problems. I figured that was a
separate issue, with the GUI widgets that are drawn natively by OSX
(like buttons and menus) being a little bigger than in X11.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what
does that remind me of? Ah, yes - life."

- Marvin

4

William Kyngesburye wrote:

I also get an error starting gis.m:

child process exited abnormally
child process exited abnormally
     while executing
"exec -- d.font romans >& /dev/null"

BUT, gis.m (same universal build of GRASS) DOES work on my MacBook.
I suspect there is a cross-compiler build error here.

Yep. The stroke fonts can't be cross-compiled; the build process
compiles the font tools (splitfont and font_2_bin) then tries to run
them to compile the fonts. Obviously, this won't work if the font
tools were built for a different platform.

What it should probably do is to install the tools, the raw font data,
and a script, so that the process can be completed after everything
has been installed on the target system.

There is a similar issue with the datum shift grids used by PROJ.

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

5

On Jul 20, 2006, at 2:03 AM, Glynn Clements wrote:

Yep. The stroke fonts can't be cross-compiled; the build process
compiles the font tools (splitfont and font_2_bin) then tries to run
them to compile the fonts. Obviously, this won't work if the font
tools were built for a different platform.

Can this be changed? Maybe moderize the internal fonts to PostScript or TrueType (probably difficult), or either pick an endian for all platforms, or add an endian tag at the beginning of the font files and the font routines would know how to read them?

What it should probably do is to install the tools, the raw font data,
and a script, so that the process can be completed after everything
has been installed on the target system.

The problem is that, while for now with a unix-style install of a universal binary GRASS on Mac OS X I can have both processor versions available and install the correct font files according to PPC or Intel Mac (or as you suggest process the raw data at install), in the future someone (ie Lorenzo) will want to make a self-contained, drag-n-drop installable grass.app, where there would be no install scripts. A run-time startup script could work in a pinch to rename the correct copy for grass to use, or process the raw files.

There is a similar issue with the datum shift grids used by PROJ.

Oh damn! I'm surprised noone has said anything from using my universal binaries (built on Intel Mac). Maybe the datum grids are just not used much (it's only the extras for the states). And here I was working on frameworks for my installers. The PROJ framework would have the same problem as with the GRASS fonts, but I'm not sure I can do run-time processing in this case.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

6

On Thu, 20 Jul 2006, William Kyngesburye wrote:

On Jul 20, 2006, at 2:03 AM, Glynn Clements wrote:

There is a similar issue with the datum shift grids used by PROJ.

Oh damn! I'm surprised noone has said anything from using my universal binaries (built on Intel Mac). Maybe the datum grids are just not used much (it's only the extras for the states). And here I was working on frameworks for my installers. The PROJ framework would have the same problem as with the GRASS fonts, but I'm not sure I can do run-time processing in this case.

This worked in GRASS 5.x. I didn't realise it was missing from the install script for 6.x but I see now it is. I'm going away for the weekend so won't have a chance to look at it until some time next week but look at the 5.x install script to see how it is done:
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass/binaryInstall.src?content-type=text/plain
(search for nad2bin - probably something similar can be done for the fonts).

Is there any particular reason why installable Mac binaries couldn't run an install script? It would seem like a pretty common thing to want to do :confused:

Paul

7

On Jul 20, 2006, at 10:18 AM, Paul Kelly wrote:

On Thu, 20 Jul 2006, William Kyngesburye wrote:

On Jul 20, 2006, at 2:03 AM, Glynn Clements wrote:

There is a similar issue with the datum shift grids used by PROJ.

Oh damn! I'm surprised noone has said anything from using my universal binaries (built on Intel Mac). Maybe the datum grids are just not used much (it's only the extras for the states). And here I was working on frameworks for my installers. The PROJ framework would have the same problem as with the GRASS fonts, but I'm not sure I can do run-time processing in this case.

This worked in GRASS 5.x. I didn't realise it was missing from the install script for 6.x but I see now it is. I'm going away for the weekend so won't have a chance to look at it until some time next week but look at the 5.x install script to see how it is done:
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass/binaryInstall.src?content-type=text/plain
(search for nad2bin - probably something similar can be done for the fonts).

I've never used this. I take it this would start with something like 'make dist' to package it all up, including the raw datum files? Then you run the script when you want to install it on another machine? I'm currently doing a normal install, then archiving the installed folder + the grass61 and gem programs, this works better for a Mac installer package than the script.

The script would work fine for a unix-style install, since the user must use the script to install it, and its destination is fixed by the build configuration. But an OSX Universal .app is a different matter. Usually drag-n-drop, but it can use an installer, destination is not fixed, though normally it's /Applications. So a drag-n-drop install can't take care of platform-specific (PPC/Intel) files at install and would have to do it at runtime.

And, I was thinking of the libproj datum files, but I see that GRASS has it's own copy. So, why the duplication? Why not just use the libproj files in-place, or symlink the proj data folder?

Is there any particular reason why installable Mac binaries couldn't run an install script? It would seem like a pretty common thing to want to do :confused:

A program could. MS Office does it to install support files on the first run (no quite a script, but same idea). I think Lorenzo's grass.app does to start GRASS, maybe setting env vars. But it wouldn't really work for a library, the calling application would have to do it, or set an environment variable (ie PROJ_LIB to point to the correct PPC/Intel copy of the datum files).

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

8

William Kyngesburye wrote:

> Yep. The stroke fonts can't be cross-compiled; the build process
> compiles the font tools (splitfont and font_2_bin) then tries to run
> them to compile the fonts. Obviously, this won't work if the font
> tools were built for a different platform.

Can this be changed? Maybe moderize the internal fonts to PostScript
or TrueType (probably difficult),

True-type fonts are already supported. Abandoning stroke fonts
altogether is probably feasible now that GRASS no longer supports
graphics terminals such as the 4105.

or either pick an endian for all
platforms, or add an endian tag at the beginning of the font files
and the font routines would know how to read them?

The issue isn't just endianness; that could be fixed easily enough.
The font files in the GRASS distribution are in a fundamentally
different format to what the display drivers expect.

Essentially, the source files consist of a single font split into four
text files (hersh.oc[1-4]) plus a collection of "maps" (*.hmp) which
define substets of the complete font, The drivers expect each font in
a separate, binary file.

> What it should probably do is to install the tools, the raw font data,
> and a script, so that the process can be completed after everything
> has been installed on the target system.

The problem is that, while for now with a unix-style install of a
universal binary GRASS on Mac OS X I can have both processor versions
available and install the correct font files according to PPC or
Intel Mac (or as you suggest process the raw data at install), in the
future someone (ie Lorenzo) will want to make a self-contained, drag-
n-drop installable grass.app, where there would be no install
scripts. A run-time startup script could work in a pinch to rename
the correct copy for grass to use, or process the raw files.

So long as the files in CVS are in a different format to what the
drivers require, some form of compilation will be necessary.

As "make -C lib/fonts" only takes ~100ms (on a P3/800), it wouldn't be
particularly onerous (in performance terms) to make the display driver
read the text format directly instead of the binary version.

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

9

On Jul 21, 2006, at 6:32 AM, Glynn Clements wrote:

Can this be changed? Maybe moderize the internal fonts to PostScript
or TrueType (probably difficult),

True-type fonts are already supported. Abandoning stroke fonts
altogether is probably feasible now that GRASS no longer supports
graphics terminals such as the 4105.

Assuming you mean FreeType support, you'd have to make FreeType a requirement, not optional. Maybe locate some basic free fonts to include so GRASS doesn't have to rely on systems having particular fonts installed. Or better, tap into system functions to get default fonts, but that would be different for each platform.

As "make -C lib/fonts" only takes ~100ms (on a P3/800), it wouldn't be
particularly onerous (in performance terms) to make the display driver
read the text format directly instead of the binary version.

That sounds reasonable. I was kinda wondering myself it that was possible (but probably not something I could do).

If you think it's reasonable, I could add it as a wish.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

10

Well, for now I have my GRASS installer build the fonts at install-time. This should assure that they are the correct endian for PPC/Intel Macs.

I also fixed the PROJ datum grid files to do the same, in my GIS Libs package. The GRASS etc/nad is then symlinked to the PROJ data folder to simplify installation and maintenance of the datum files. (I hope this works and doesn't cause problems)

On Jul 20, 2006, at 10:18 AM, Paul Kelly wrote:

On Thu, 20 Jul 2006, William Kyngesburye wrote:

On Jul 20, 2006, at 2:03 AM, Glynn Clements wrote:

There is a similar issue with the datum shift grids used by PROJ.

Oh damn! I'm surprised noone has said anything from using my universal binaries (built on Intel Mac). Maybe the datum grids are just not used much (it's only the extras for the states). And here I was working on frameworks for my installers. The PROJ framework would have the same problem as with the GRASS fonts, but I'm not sure I can do run-time processing in this case.

...

Is there any particular reason why installable Mac binaries couldn't run an install script? It would seem like a pretty common thing to want to do :confused:

Paul

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

11

-nviz partly works. It will display the map it started with. But the file
browser doesn't work for loading any new maps (error below). Same for
vectors. The map display keeps spreading over the control panels, though
this can be fixed by resizing a bit. The color selectors don't work either.
Most other controls for rasters seem to work.

Well, I reinstalled my first package, based on CVS 7/1 source, before the configure options were worked out when I was figuring out the whole Tcl Aqua thing. I'm sure this one worked for this problem. At the time I started NVIZ with a single elevation raster, then used the raster and vector browsers to add a land cover raster, and roads and rivers vectors, successfully. Now that version has the same twitch in the browser dialogs, and it's impossible to add additional data.

That leaves the system... No updates since then, except rebuilding Tcl/Tk Aqua once. The Togl programmers mentioned a bug in Tk 8.1.12 and .13 that affects a certain case in Togl, but I never touched that, before or after everything worked. I'll have to check the other Mac I originally tested it on (I think I haven't touched it since it worked). Possibly try an earlier version of Tcl/Tk.

Maybe there's gremlins in the works :slight_smile:

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

12

William Kyngesburye wrote:

I also fixed the PROJ datum grid files to do the same, in my GIS Libs
package. The GRASS etc/nad is then symlinked to the PROJ data folder
to simplify installation and maintenance of the datum files. (I hope
this works and doesn't cause problems)

IIRC, the New Zealand GD49 grid is distributed with GRASS but not with
GDAL.

the NZ grid is not built from ascii, GRASS provides a binary version; if
that makes any difference.

Hamish

13

On Jul 22, 2006, at 1:23 AM, Hamish wrote:

William Kyngesburye wrote:

I also fixed the PROJ datum grid files to do the same, in my GIS Libs
package. The GRASS etc/nad is then symlinked to the PROJ data folder
to simplify installation and maintenance of the datum files. (I hope
this works and doesn't cause problems)

IIRC, the New Zealand GD49 grid is distributed with GRASS but not with
GDAL.

the NZ grid is not built from ascii, GRASS provides a binary version; if
that makes any difference.

The nzgd2kgrid0005.gsb and ntv1_can.dat files are included in proj-datumgrid-1.3 for PROJ (not GDAL). Tho you need to install the NZ grid manually with PROJ 4.4.9 (fixed in the 4.5.0 beta).

And yes, they start out binary. I wonder if there is an endian problem in these files. I haven't heard complaints from Mac OS X users. If they are little endian, there shouldn't be a problem on Intel Macs, but PPC Macs (or PPC or other big-end linux systems) could have problems. I wonder if these tables have csv/text sources like the US NAD tables?

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

14

William Kyngesburye wrote:

>> I also fixed the PROJ datum grid files to do the same, in my GIS
>> Libs package. The GRASS etc/nad is then symlinked to the PROJ data
>> folder to simplify installation and maintenance of the datum files.
>> (I hope this works and doesn't cause problems)
>
> IIRC, the New Zealand GD49 grid is distributed with GRASS but not
> with GDAL.
>
> the NZ grid is not built from ascii, GRASS provides a binary
> version; if
> that makes any difference.
>
The nzgd2kgrid0005.gsb and ntv1_can.dat files are included in proj-
datumgrid-1.3 for PROJ (not GDAL). Tho you need to install the NZ
grid manually with PROJ 4.4.9 (fixed in the 4.5.0 beta).

Ok, I'm still using 4.4.9 (Debian packages)

And yes, they start out binary. I wonder if there is an endian
problem in these files. I haven't heard complaints from Mac OS X
users. If they are little endian, there shouldn't be a problem on
Intel Macs, but PPC Macs (or PPC or other big-end linux systems)
could have problems. I wonder if these tables have csv/text sources
like the US NAD tables?

We use GRASS on PPC Macs here (NZ) and I haven't noticed it being
broken. (not to say that it couldn't be, but I'd be surprised if it
were and hadn't bitten us yet)

Yes, there is an ASCII version available from LINZ. I'd have to check
the old correspondence to see if we have explicit permission to
redistribute that in the same manner as the binary grid.

Hamish

15

On Jul 22, 2006, at 9:28 PM, Hamish wrote:

The nzgd2kgrid0005.gsb and ntv1_can.dat files are included in proj-
datumgrid-1.3 for PROJ (not GDAL). Tho you need to install the NZ
grid manually with PROJ 4.4.9 (fixed in the 4.5.0 beta).

Ok, I'm still using 4.4.9 (Debian packages)

The proj-datumgrid-1.3 is a separate download from the proj source, but I don't know how linux package managers deal with this. The proj 4.4.9 makefile doesn't know how to install the gsb file, but proj 4.4.9 can use it. I guess if package managers don't try to take care of problems like this, it makes sense to include the datum files with GRASS, rather than tell users to fix their PROJ installation or use a beta.

And yes, they start out binary. I wonder if there is an endian
problem in these files. I haven't heard complaints from Mac OS X
users. If they are little endian, there shouldn't be a problem on
Intel Macs, but PPC Macs (or PPC or other big-end linux systems)
could have problems. I wonder if these tables have csv/text sources
like the US NAD tables?

We use GRASS on PPC Macs here (NZ) and I haven't noticed it being
broken. (not to say that it couldn't be, but I'd be surprised if it
were and hadn't bitten us yet)

Yes, there is an ASCII version available from LINZ. I'd have to check
the old correspondence to see if we have explicit permission to
redistribute that in the same manner as the binary grid.

From my first look at the proj grid loading, all I saw was that it simply dumped the datum file into memory - platform dependent. I dug around some more, and it looks like it handles ntv1 (Canada) and ntv2 (.gsb/NZ) as separate cases which take care of byte swapping issues. So it looks like those are OK, no endian issues.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy