Spud stuff: other survey software; and a few other bits.

[Philip Underwood]

On Tue, 10 Oct 2000, you wrote:
> In message <00100923382301.00674@localhost.localdomain>, Philip Underwood
> write
>
> s:
> >On Mon, 09 Oct 2000, Mark SHinwell wrote:
> >> - Has integration with GIS stuff like ArcView
>
> I think integration with ArcView just needs shapefile output.  The
> shapefile format is a bit strange, but there's a free (user's choice of
> LGPL or old MIT style) library to read and write them:
>
> http://gdal.velocet.ca/projects/shapelib/shapelib.html
>
> >>   can read standard
> >>   DEM (Digital Elevation Map) files for terrain data.  We ought to do
> >>   the latter (I will investigate).
> >
> >Yup -DEMs are definitely feasible. I've got some code knocking around
> >somewhere that does the job quite nicely. I've written some progs that
> > will convert dems into svx files (*huge* svx files), and also into 3dx
> > files. I'll dig them out if you want.
>
> If they work we ought to put them on the web site for download.  For spud,
> is it likely to be better to start from these, or go back to the original
> code?
Go back to the original, I say; I've hacked the code quite nastily about. 
Incidentally the dem2svx file is on my website 
(http://members.xoom.com/bighairyone/chasm/ (at the bottom of the page; you 
have to look))
>
> >It's based on someone elses code; its called g3DGMV
> >by Nick Yost (yostn@gte.net, available at (I think) freshmeat) I think
> > this would be an excellent example where a module would be useful.
>
> Home page seems to be:
>
> http://members.linuxstart.com/~g3DGMV/
>
> Currently seems to be down, but Google has it cached:
>
> http://www.google.com/search?q=cache:members.linuxstart.com/~g3DGMV/
>
Oops. My mistake.

> Incidentally, if you do pull in code from elsewhere, be sure to make sure
> the license is compatible with the GPL.  We probably ought to keep a
> central list of such code, as we may want to track it and collect
> enhancements and bug fixes.
>
g3DGMV is definitely GPL; but I agree about the GPL compatibility thing.

> >> - Context-sensitive help.  We need to think about how we will provide
> >>   help.
> >
> >I like HTML - the user can specify their own browser, its easy to write,
> > and reasonably flexible. Under Win32 its very easy to set the help up to
> > use the default HTML browser automatically. Or possibly SGML, which is
> > more general, but is more tricky to include graphics.
>
> Assuming you mean the docbook DTD, it's not trickier, just more verbose.
> Here's an example from http://www.docbook.org/tdg/html/imageobject.html :
>
<example snipped>
> Note you typically need to generate each graphic in several formats - gif
> or png for a web page, eps for pdf or postscript output, etc.
>
> The real benefit of using docbook is you can generate a nice printed
> version. I believe you can also generate ms windows help files.
Is it possible to set up the sgml so that specific bits are output to 
specific files and sub-dirs; this makes context sensitive help a lot easier.

Under chasm, a help window is brought up by calling runhelp(const char *path) 
where path is the location of the HTML file, appended to a globally set path 
for the help file. Seems to work quite well.

Also, Mark Shinwell wrote:
> Yeah, but one says just "HTML" but how do we display it?  Netscape?
> Konqueror?  Internet Explorer?  Mozilla?  
I'd let the user decide. Virtually everyone with the set-up that would be 
needed to run spud will have a browser of some description. It's easy enough 
to get windows to open a HTML file with the appropriate browser (appropriate 
as defined by Win32; we don't need to actually specify the browser). We could 
set up Unix versions to run something fairly general eg "xterm -e lynx", and 
let the user specify whatever they want - should be a fairly trivial user 
set-up thing. we could possibly get the program to autodetect the more common 
browsers on start-up (maybe just on the first startup, and save the results 
in an options file/registry); I'd need to look at this....

> Nasty problem... I think a
> Mozilla plug-in to GTK might be the best option...
If we do code a browser in, can we have a really simple, stable one. Help 
files shouldn't really need very fancy abilities - tables, images, and 
various sized text should be all that's needed. Maybe there's a simple GTK 
plug-in available. I think Mozilla might be a bit too big for this.

>
> Cheers,
> Olly

--
Phil Underwood <furbrain@furbrain.screaming.net>
Fighting disease, illness, and little flaky bits throughout the North West.
--