And, as usual, I was too fast for my own good.
Your last sentence summarized the abstracts of the Open Geospatial
Consortium for WMS, WFS and WCS. However, it begs the question of
defining the terms. A knowledge of teh definitions is necessary to
understand what you want to access and what you're getting. Mistakes
are common where one thinks they understand a "feature" but then get
something back that didn't match their understanding. I could
substitute 'map' or 'coverage' for feature above.
And then, there's the metadata. Metadata and a coherent vocabulary and
ontology, often formated as a registered schema (GML in this case)
provides the description of the data for further use. When one issues a
GetCapabilities request to a Web [Map|Feature|Coverage] server one gets
a GML response back with all the pertinent metadata available about the
requested object that's on that server. From that, one may craft a
request for the data and data-type desired. While you're working with
that object, you will need to retain the metadata.
Note that in my earlier post, I indicated use of a 3-band geotiff of
landsat data. This represents a processed image, as you've restricted
the dataset to those three bands of data. The netCDF example was an
unprocessed (potentially) example (Hmmm. Maybe I should add some
cgi-hooks for NCAR's NCL package for netcdf subsetting and processing?).
The "WxS" packages, as I've taken to calling them, are powerful tools
for their specific tasks. They can be used out-of-context, too, but
that tends to confuse others who aren't familiar with how you were
thinking if you ask them to do strange things.
Your approach to this does not appear incorrect to me, but doesn't take
advantage of the full capabilities of the services.
gerry
Rahkonen Jukka wrote:
Hi,
Thank you for clarifying my quick answer. I am looking WCS from a narrow
viewport because I use it mostly for delivering aerial images in original
resolution and quality. WCS does give more. Delivering raw data is not the only
alternative with WCS but it offers also some limited processing options like
resampling to different resolution, reprojecting and a set of user selectable
outputformats.
When it comes to spatial relevance, for me the image captured from WMS does not
have much spatial relevance after it has arrived to the computer if the request
used for ordering it from the server is not known. GIS program who made the
request does remember it but save it on a disk, or capture it with a web
browser and it is just an image. Of course the situation is similar if you take
an image from WCS server in png or jpeg format which do not carry embedded
metadata. But this is not black and white either, Mapserver WMS can also create
georeferenced geotiff or ecw files, even most WMS clients do not know what do
do with them. Is it too simple to say that WMS was planned to be used for
showing a map, WCS for downloading coverages and WFS for querying and
downloading features?
-Jukka-
Gerald Creager wrote:
Er... not quite.
WMS is designed to provide a map for, say, a baselayer or background
with spatial relevance for GIS work. A picture on a screen is similar,
but a WMS result has spatial relevance.
Web Coverage Service delivers a product with spatial relevance and data
embedded within the pixels, voxels, etc of the coverage. You're not too
far off, but I believe you're attempting to oversimplify this.
A WFS result will provide a feature (line, polygon, point, polyline,
etc.) with all of its attributes.
In a coverage, e.g., a geotiff of a 3-band LandSAT image, you would have
information on which bands were provided for the RGB elements, and the
pixel values for each. The coverage is georegistered so that the
spatial relevance of the "image" is preserved. Similarly, a netcdf with
significantly more values could be passed as a coverage and utilized,
not limited to simply 3 "bands" of "color" (data).
gerry
Rahkonen Jukka wrote:
Hi,
I would say that the main difference is that WMS is meant for showing a map on
a computer screen, while WCS is made for letting users to download data so they
can utilise it locally or process further. Real life is not so black and
white. I promise you will find lots of good reading about WMS and WCS easily.
Do not forget to read a little bit about WFS as well, service for downloading
vector data.
-Jukka Rahkonen-
fla83tn wrote:
Lähetetty: ti 1.12.2009 17:31
Vastaanottaja: Rahkonen Jukka; mapserver-users@lists.osgeo.org
Aihe: Re: Re: [mapserver-users] WMS: raster's x and y pixel dimension
Thank you Jukka for the quick reply. Now I'm able to correctly generate z-
dimension from DEM layer.
However, since I'm new to GIS, I'm not able to
understand the differences between WCS and WMS..could
you briefly summarize
the goal of the two approach?
And, as last question , should I set the resX and
resY parameters from client or could I embed them directly into the map file?
Best regards,
Flavio
Hi,
Width, height and BBOX are all compulsory
parameters in WMS GetMap
request and Mapserver is sending an image according
to the request. If
you want to be able to control the pixel size easily,
without making WMS
client to balance the BBOX and image size in pixels,
consider using WCS.
One way to make a WCS request is
http://server.fi/cgi-
bin/mapserver_wcs?SERVICE=WCS&VERSION=1.0.0&REQUEST
=GetCoverage&COVERAGE=DEM&FORMAT=image/tiff&CRS=EPSG:3067&ResX=1.0&ResY=
1.
0&BBOX=533652,6973434,534658,6974219
You can see parameters ResX and ResY
which are used for controlling the
pixel size.
-Jukka Rahkonen-
fla83tn
wrote:
Hi to all,
I've a problem with the loading of a raster
image via WMS (1.3.0).
To load the layers of my project I use gvSIG. If
I load my
digital elevation model (DEM) directly from filesystem (which
is a HFA/Erdas Image file - .img),
x and y pixel dimension are fixed to
2.5 and -2.5 meters
respectively, and fixed are also the width and height
attributes.
If I load the layer from
Mapserver's WMS instead, x and y
pixel dimension change as I
zoom in or out (i.
e. changing the width
and height parameters of the getMap request).
Is there
the possibility
to tell the wms client that x and y pixel
dimension are constant and should
never be calculated?
Here's my layer definition and the
tiff
outputformat definition:
OUTPUTFORMAT
NAME GTiff
DRIVER
"GDAL/GTiff"
MIMETYPE "image/tiff"
IMAGEMODE FLOAT32
EXTENSION "tif"
END
LAYER
NAME
"my_dem"
EXTENT 669913.75
5143998.75 678313.75 5150701.25
METADATA
"wms_title"
"my_dem" ##required
"wms_extent" "669913.75 5143998.75
678313.75
5150701.25"
"gml_include_items" "all"
END
TYPE RASTER
STATUS ON
PROJECTION
"init=epsg:25832"
END
DATA "my_dem.tiff"
PROCESSING "NODATA=-9999"
PROCESSING
"SCALE=227.23,1741.15"
PROCESSING
"SCALE_BUCKETS=2000"
PROCESSING
"BANDS=1"
DEBUG on
DUMP true
TEMPLATE "void" # enable
queryable attribute on the layer END
Any help is
appreciated,
Flavio
_______________________________________________
mapserver-users
mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.
org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
