These are some of our favorite client applications. There are some others out there and you can refer to the GeoServer client page for more information.
Udig Udig is a desktop client that supports OGC WMS and WFS requests. It is built off of the same library as GeoServer: GeoTools.
GVSig GVSig is a desktop client that supports OGC WMS and WFS requests, similar to Udig.
OGC Web Services for accessing Geographic Data
The Open Geospatial Consortium has defined several Open Web Services for accessing (usually geographic) data. There are two basic service sets - the Web Feature Services (WFS) and the Web Map Services (WMS). The WFS is concerned with direct access to your data - reading, writing, and updating your features. The WMS is concerned with transforming your data into a map (image).
|!(http://udig.refractions.net/confluence/images/icons/emoticons/information.gif)||**What is a Feature?** A feature is an Object that is an abstraction of a real world phenomenon. This object has a set of properties associated with each having a name, a type, and a value. An example of a feature might be Road with a Name, Location (line geometry), Width, Speed Limit, and Jurisdiction. Typically these features are stored in a [spatial database](http://udig.refractions.net/confluence/pages/viewpage.action?pageId=5223), shapefile, or other format.|
|!(http://udig.refractions.net/confluence/images/icons/emoticons/check.gif)||**OGC Open Web Services** The OGC Web Services provide access to the features - either directly or as images (maps) - in a standardized way independent of the company who created the server or the actual format the data is stored in.|
What to use a the WFS services for
A WFS allows uniform direct access to the features stored on a server. Use a WFS when they want to perform actions such as:
query a dataset and retrieve the features
find the feature definition (feature’s property names and types)
add features to dataset
delete feature from a dataset
update feature in a dataset
lock features to prevent modification
A WMS allows for uniform rendering access to features stored on a server. Use a WMS when you want to perform actions such as:
Very simple Querying of data
Why use Open Services
GeoServer is strongly committed to open standards for its geospatial web services. Currently this is strongly centered around the Open Geospatial Consortium’s Open Web Services architecture, as they have the largest consensus among industry and government, and have some very high quality specifications. But GeoServer remains un-ideological about the particular standard, as long as it is fully open and widely supported.
This insistence on open standards is practical, if immense amounts of geospatial information are to be truly accessible it will only be possible through widely used open standards. The GIS industry has always had a myriad of formats, making the combination of data from different sources an exercise in frustration, spending massive amounts of time and money with data conversion, or simply scrapping the conversion and duplicating the work of gathering the data. The Internet and Web Services open up new possibilities for quickly obtaining geographic data, but unless open standards are utilized users will have to decide which geospatial web they want to access, obtaining the appropriate client software for each. Imagine if Netscape and Internet explorer had different Internets - if the browser wars had extended to servers, instead of having an open source standard with Apache - then users today would have to decide which Internet they wanted to get their information from, depending on which browser they were using.
Relying on a non-open standard for exchanging geographic information ensures that it can only be exchanged with others who have bought the same system. The cost to entry to that geospatial web is whatever the server vendor chooses to charge, and the only geographic information available will be by ones who could afford the cost, or who are in the good graces of the company providing the software. An open standard enables competition in an open marketplace for providing geospatial servers. There is no lock-in to the initial choice, as it is easy to switch one vendor’s implementation for another, or even to migrate to an open source solution (and back if the oss solution did not fully meet the needs). Without an open standard such migrations would involve a replacing the whole system, not just the component needing improvement.
Several mainstream technology corporations are jumping into the geospatial game, giving away access to their geographic information, allowing users to add additional information. But without open standards and a variety of implementations users will have to pick which proprietary geospatial web to join, instead of creating an open Geospatial Web where all information about a place is searchable and available.
It is getting easier and easier to roll a mapping application, directly connecting a PostGIS or MySQL database to a simple web mapping front end. Putting standards between the display of the map (WMS), getting the raw data (WFS) or the updating of information (WFS-T) can seem like an extra hassle for implementors. But doing so allows anyone to access the same information that is displayed, and overlay and combine it with other geographic information, providing more context and the potential of generating new information from analysis. With a self built system there is generally only one way to display the information, the one provided. If an open standard is used then it can be used in a desktop GIS, web applications, 3d viewers, or specially built geographic visualization.
(we should have a picture of a client here getting data from a bunch of different WMSes and even a WFS, as a concrete visualization of what is possible with standards - even a before/after picture, of just putting one’s data up on the web, and then one’s data overlaid on lots and lots of context from diverse sources)
Hello GeoServer fans and developers, this is our first of many GeoServer blog posts. Here we will tell you about the latest news and updates, along with open discussions on where GeoServer is headed. You will also find posts about the latest tutorials and documentation, as well as our new screencasts. For the technically savvy reader, this blog will also contain posts from the developers discussing everything from software design, frameworks, services, and of course, GIS.
This blog is ideal for those who don’t want to sift through the email list to see what is going on in GeoServer-land. And to make your life easier there are four categories of blog posts that you can filter:
- Announcements: Releases, updates, patches, and major decisions will be here.
- Tutorials: New tutorials and FAQ entries will be announced on this thread.
- Tips and Tricks: Tips from the developers and user community on how to tweak GeoServer.
- Developer Notes: Mostly technical notes from the developer community. Topics such as design decisions, frameworks, OGC standards, and various technical discussions.
You can read the About page to find out more information on subscribing to particular message feeds..
Suggestions for blog entries are definitely welcome. And if you would like to be an author to this blog, we invite you to contact the administrator to get registered.
- GeoServer repository transition to main branch
- FOSS4G 2018 GeoServer Developers Workshop
- GeoServer at FOSS4G 2017 Boston
- REST API Code Sprint Prep
- Nov 18th Bug Stomp
- Online GeoServer Bug Stomp - July 2016 Results
- Online GeoServer Bug Stomp
- GeoServer Explorer Plugin for QGIS
- New repository and release delay
- GeoServer FOSS4G 2015 Activities