 |
Caro-COOPS.org Discussion Board
Discussion area for Caro-COOPS-related initiatives
|
| View previous topic :: View next topic |
| Author |
Message |
jcothran
Joined: 24 Feb 2025
Posts: 176
Location: Columbia, SC
|
| Posted: Tue May 06, 2025 12:33 pm Post subject: Extending MapServer as a web service |
|
|
We've been looking into the idea of using our Mapserver installation as a GIS mapping service for others. The general idea is that a user/group would enter a form based application which would authenticate them with the system and provide a description of the desired data(layers), possibly animations and desired views of the displayed layers. Once the initial profile has been completed, the stored profile and view(s) could be called/viewed repeatedly as a browser link with the necessary profile argument.
Zope(http://www.zope.org) could be used for the user profile part of this application with the results of the profile being stored in XML for intended use by the MapServer GIS application and supporting functions.
======
Examples of applications/tools which currently combine Zope and Mapserver:
http://www.carocoops.org/bb/viewtopic.php?t=142
ZMapServer is a Zope Product that provides a clean interface to the MapServer (http://mapserver.gis.umn.edu) web mapping application.
http://sourceforge.net/projects/zmapserver/
======
In providing this service, support functions would probably cache user datasets locally on the server to speed retrieval times. The use of network/storage/processing resources should be justifiable either by association or subscription of the requesting party. Initial efforts would be focused on the immediate application and viability of this type of service rather than the long range questions of support.
We anticipate the need that part of the profile for data view generation will be the need to specify the time window for applicable datasets. Since area data is provided at differing times, the final view will probably be a composite of several earlier views within the specified time window.
Other mixed technologies:
======
The following three GIS specifications(WMS, WFS, WCS) were developed by OGC(OpenGIS Consortium http://www.opengis.org ) and form the OWS(OGC Web Services) suite
WMS(Web Mapping Service)
http://www.opengis.org/techno/specs/01-047r2.pdf
| Quote: |
A Web Map Service produces maps of georeferenced data. We define a "map" as a
visual representation of geodata; a map is not the data itself. These maps are generally
rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based
graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics
Metafile (WebCGM) formats. This specification standardizes the way in which maps are
requested by clients and the way that servers describe their data holdings. This document
defines three operations, the first two of which are required of every WMS.
GetCapabilities (required): Obtain service-level metadata, which is a machine-readable
(and human-readable) description of the WMS's information content and acceptable
request parameters.
GetMap (required): Obtain a map image whose geospatial and dimensional parameters
are well-defined.
GetFeatureInfo (optional): Ask for information about particular features shown on a
map.
A standard web browser can ask a Web Map Service to perform these operations simply
by submitting requests in the form of Uniform Resource Locators (URLs) [12]. The
content of such URLs depends on which of the tasks is requested. All URLs include a
specification version number and a request type parameter. In addition, when invoking
GetMap a WMS Client can specify the information to be shown on the map (one or more
"Layers"), possibly the "Styles" of those Layers, what portion of the Earth is to be
mapped (a "Bounding Box"), the projected coordinate system to be used (the "Spatial
Reference System," or SRS), the desired output format, the output size (Width and
Height), and background transparency and color. When invoking GetFeatureInfo the
Client indicates what map is being queried and which location on the map is of interest.
When two or more maps are produced with the same Bounding Box, Spatial Reference
System, and output size, the results can be accurately layered to produce a composite
map. The use of image formats that support transparent backgrounds (e.g., GIF or PNG)
allows the lower Layers to be visible. Furthermore, individual map Layers can be
requested from different Servers. The WMS GetMap operation thus enables the creation
of a network of distributed Map Servers from which Clients can build customized maps.
A particular WMS provider in a distributed WMS network need only be the steward of its
own data collection. This stands in contrast to vertically-integrated web mapping sites
that gather in one place all of the data to be made accessible by their own private
interface.
Because each WMS is independent, a WMS must be able to provide a machine-readable
description of its capabilities. This "Service Metadata" enables Clients to formulate valid
requests and enables the construction of searchable catalogs that can direct clients to
particular WMSes.
A WMS may optionally allow the GetFeatureInfo operation. If it does, its maps are said
to be "queryable," and a Client can request information about features on a map by
adding to the map URL additional parameters specifying a location (as an X, Y offset
from the upper left corner) and the number of nearby features about which to return
information.
|
http://mapserver.gis.umn.edu/doc/wms-client-howto.html
http://mapserver.gis.umn.edu/doc/wms-server-howto.html
http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0301/msg00039.html
======
WFS(Web Feature Service) vector oriented data which is more applicable to GML (Geography Markup Language http://gislounge.com/ucon/ucgmlintro.shtml http://www.opengis.org/techno/documents/02-023r4.pdf ) and SVG(Scalable Vector Graphics http://www.adobe.com/svg/main.html ).
http://www.opengis.org/techno/specs/02-058.pdf
| Quote: |
The OGC Web Map Service allows a client to overlay map images for display served from multiple Web Map Services on the Internet. In a similar fashion, the OGC Web Feature Service allows a client to retrieve geospatial data encoded in Geography Markup Language (GML) from multiple Web Feature Services.
The requirements for a Web Feature Service are:
1. The interfaces must be defined in XML.
2. GML must be used to express features within the interface.
3. At a minimum a WFS must be able to present features using GML.
4. The predicate or filter language will be defined in XML and be derived from CQL as defined in the OpenGIS Catalogue Interface Implementation Specification.
5. The datastore used to store geographic features should be opaque to client applications and their only view of the data should be through the WFS interface.
6. The use of a subset of XPath expressions for referencing properties. |
http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?WFSMapServer
http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0301/msg00029.html
http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0108/msg00254.html
======
Other thoughts:
XML Mapscript?
http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0205/msg00345.html
======
WCS(Web Coverage Service) is another specification, but I didn't see any postings to the Mapserver mail archives showing interest or activity in regards to this specification.
http://www.opengis.org/techno/02-024r1.pdf
| Quote: |
The Web Coverage Service (WCS) supports the networked interchange of geospatial data
as "coverages" containing values or properties of geographic locations. Unlike the Web
Map Service (WMS) (OGC document #01-021r2), which filters and portrays spatial data
to return static maps (server-rendered as pictures), the Web Coverage Service provides
access to intact (unrendered) geospatial information, as needed for client-side rendering,
multi-valued coverages, and input into scientific models and other clients beyond simple
viewers.
The Web Coverage Service consists of three operations: GetCapabilities, GetCoverage,
and DescribeCoverageType. The GetCapabilities operation returns an XML document
describing the service and the data collections from which clients may request coverages.
Clients would generally run the GetCapabilities operation and cache its result for use
throughout a session, or reuse it for multiple sessions.
The GetCoverage operation of a Web Coverage Service is normally run after GetCapabilities
has determined what queries are allowed and what data are available. The Get-
Coverage operation returns values or properties of geographic locations, bundled in a
well-known coverage format. Its syntax and semantics are similar to the WMS GetMap
request, but several extensions support the retrieval of coverages rather than static maps.
|
======
We could also try using the MapLab suite(MapEdit, MapBrowser, GMapFactory) as provided by DM Solutions, but this suite seems more oriented towards developers with a high learning curve than casual initial users.
On the commercial end, the following company has web demos which demonstrate some of the functionality of WMS interfaces and services.
http://www.cubewerx.com/main_en/webdemo.htm
http://postgis.refractions.net/imsemu-0.1.tar.gz
from http://postgis.refractions.net/download.php
| Quote: |
This perl script provides an emulation layer on top of the Mapserver internet map service, to make Mapserver appear to be an ArcIMS map server. It is very rough right now and only emulates image services. When feature service emulation is written, it will be possible to use the emulator on top of PostGIS to provide read-only feature services to ArcGIS clients.
For a demonstration, take ArcCatalog and "Add Internet Server...". Type http://mapserver.refractions.net into the URL field. The "ArcIMS" server providing that service is in fact an emulator on top of Mapserver.
|
======
Current thoughts(05/06/03)
Until we know that there is a demand for this type of application which could form some good base requirements, it's best for us to focus on letting map services/user profiles evolve from what we're doing based on the dynamic needs of our users. My current evaluation is that while users will use a GIS to zoom and visualize area data, I don't think that the GIS configuration needs will vary much after the initial setup.
I'd like to focus on creating an automatic conversion from netCDF to RDBMS so the PostgreSQL/PostGIS/MapServer can automatically provide GIS visualization for convention validated (CF-1.0) netCDF files. Currently I could imagine using XSLT( http://zopexmlmethods.sourceforge.net/ ), ncML ( http://www.unidata.ucar.edu/packages/netcdf-java/v2.1/manual.htm#_Toc33950917
) and ncdump to accomplish this goal. ncML could validate and convert the netCDF file header data to XML. XSLT in combination with ncdump could be used to create the RDBMS tables(XSLT) with the necessary data(ncdump).
There are probably several ways to accomplish this, this is just the one that seems attractive to me currently. Providing XML validation and reference to netCDF files on the header section could also be used to facilitate search functions or provide feedback on netCDF file creation and cataloging. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
Powered by phpBB 2.0.4 © 2001, 2002 phpBB Group
|
FAQ
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in