Re: [Opengrads-devel] Shapefile extension: first crack

[Efren S. <efr...@me...>]

-----Original Message-----
From: arl...@gm... [mailto:arl...@gm...] On =
Behalf
Of Arlindo da Silva
Sent: Tuesday, November 27, 2007 5:49 PM
To: efr...@me...
Cc: Mike Fiorino; ope...@li...
Subject: Re: [Opengrads-devel] Shapefile extension: first crack


On 11/27/07, Efren Serra <efr...@me...> wrote:
> http://mapserver.gis.umn.edu/docs/howto/svg-howto
>
> Note that Mapserver is built on the GDAL/OGR library and hence, it can =

> be extended to pretty much generate anything one wants from a single=20
> ESRI Shapefile.

Actually, I was asking whether SVG would be a viable INPUT format for
Mapsever. I guess I need to understand what exactly you would like to =
use
GrADS for, and then find the best way to interface to Mapserver. Let me
digress just bit...

I was hoping to use GrADS to generate Shapefiles; this provides the =
ability
to zoom in/out, do rubber-banding, querying features, etc.

1) As you know GrADS graphics are all vector instructions. At this point
even fonts are rendered internally. Image generation relies on libraries
such as gd (printim) and cairo (gxyat) for rasterization.

2) At a higher level GrADS can produce contour plots, filled contours
(shaded) plots, streamlines, wind barbs, wind vectors, station model =
plots
(with rendered). An these can be produced without any maps, frames, =
axis,
etc. Just naked plots at the surface of the earth. Are these the kind of
output that you would like to ingest into Mapserver for further =
compositing?

These can be left as transparent raster layers to ingest into Mapserver
since things such as wind barbs are not very well put into Shapefiles.

3) Right now these can be written out as vector output in encapsulated
postscript, PDF or SVG. In the beginning of this thread I commented that =
one
might be able to write these vector instructions as shapefiles (.shp, =
.shx,
and .dbf) --- I need to read the shapefile white paper to better =
understand
the functionn of these 3 files.

I think wind barbs are hard to encode in Shapefiles specially when one =
zooms
in, eh?

4) If SVG is a viable *input* format for Mapserver then a little tweak =
in
the on-line version of gxyat might allow us to write some extra metadata =
to
make Mapserver happy. This could be a quicker approach to achieve what =
you
need, bypassing shapefiles altogether. Not that shapefiles wouldn't be
useful for truly GIS desktopers...

Mapserver can generate SVG from Shapefiles; I don't know if Mapserver =
can
read SVG and generate raster images.

5) Here at NASA/GSFC we provide our homegrown WMS server with nice PNG
images which it then servers to the world, e.g.,

               http://www.map.nasa.gov/cgi-bin/tc4-d5fcst-hwl.cgi

I am assuming that you are pursuing a vector graphics approach for speed =
and
scalability. Am I correct?

This would be up to the client side; we tend to focus more on the server
endpoints.

      Arlindo