04.16.08
Posted in Features at 10:04 am by Mike Pumphrey
As time goes on, more and more systems are moving towards 64 bit architecture. Pretty much all new servers are 64 bit, and the vast majority of desktop/laptop systems are 64 bit as well. (And if you are running SPARC hardware, well, then you’ve been running 64 bit hardware since 1995, but that’s a different story.) We at GeoServer HQ are starting to get this question more and more: Does GeoServer run on 64 bit systems?
The quick answer: yes!
GeoServer is built entirely on Java. Therefore, it can run on any hardware supported by Sun’s Java Runtime Environment. Unlike compiled languages, like C++, as long as the JRE supports the architecture, GeoServer can come along for the ride. Happily, 64 bit support exists in Java. So without any redesign or recompiling on our part, GeoServer can be run on 64 bit systems. That’s points for Java!
However, there are some caveats. Sun’s 64 bit JRE has been known be a bit buggier than their 32 bit version, which could be of concern in a production environment. Also, and probably related, performance takes a small hit with 64 bit (on the order of a few percent). Although there will be more discussion here later about performance tips, this seems like as good a place as any to mention that if performance is an issue on your system, we recommend that you look at updating your JRE to the latest version, if you can. Version 1.5 is much faster than 1.4, and version 1.6 appears to be roughly twice as fast as 1.5 in the context of running GeoServer. So, if you are moving to 64 bit but can’t afford the performance hit, you may want to look at updating your Java version as well.
Moving to 64 bit doesn’t need to be an either/or situation either. Our servers here (all 64 bit) are running both 32 bit and 64 bit Java instances, with few difficulties. Your mileage may vary. And of course, the big advantage of 64 bit is the ability to access more than 4 GB of RAM. This may not be an issue in your environment now, but if history is any guide, it will be eventually.
For more information on running GeoServer in a production environment, please see this guide.
Many software companies are at pains to inform the community when they offer 64 bit support. We have never explicitly mentioned this feature before because it has been offered from the beginning. We can’t take credit for the work, but we can surely enjoy the perks.
Permalink
12.19.07
Posted in Features, Announcements at 10:02 am by Justin Deoliveira
We are happy to announce the second release candidate of GeoServer 1.6.0. You can download the release from SourceForge.
As usual this release candidate brings a heap of bug fixes, with a few minor improvements. Output formats such as KML, SVG, and GeoRSS have been tightened up fixing a few minor bugs. Backend issues such as PostGIS bounds reprojection and Oracle permissions have also been addressed. For a complete list check out the change log.
There are also a few notable improvements to mention. The first being a “strict” request parameter which allows clients to turn on WFS XML validation on a request by request basis. This provides a nice debugging tool for clients to use for validating WFS requests. Also worth mention is the ongoing work and improvements to the experimental Versioning WFS protocol.
With any luck this will be the last release candidate before the official 1.6.0 release. You can help us out by downloading it and trying out. Please report any issues encountered in the bug tracker.
Permalink
12.07.07
Posted in Features at 5:00 pm by Sebastian Benthall
Check out the two Geoserver-provided images below:
| Exhibit A |
 |
| Exhibit B |
 |
They may look very similar, but they have two important differences. First, the scaling of the second map is better for conveying the data. The second and more important difference you won’t be able to see unless you view this page’s source. The markup that produced Exhibit A involved the burdensome URLs you may be used to:
<img src="http://geo.openplans.org:8080/geoserver/wms?service=WMS &request=GetMap &version=1.1.1 &format=image/png &width=256 &height=108 &srs=EPSG:4326 &layers=topp:states &styles=population &bbox=-138.4239531951185,19.168145657378737,-53.27731780488149,55.15955634262126" />
Exhibit B, on the other hand, uses a far more concise URL for the image source:
<img src="http://geo.openplans.org:8080/geoserver/wms/reflect? layers=topp:states&width=256" />
How is this possible? Exhibit B uses the new WMS Reflector, written by Justin DeOliveira and augmented by Arne Krepp for 1.6.0 for RC1. The URL asks the reflector (wms/reflect) to display the feature “topp:states” (layers=topp:states) and that the width should be 256 pixels (width=256). The rest of the parameters are filled in either by sensible but overridable defaults–such as format=image/png–or with values calculated on the fly. The bounding box, for example, was inferred from the bounds of the content instead of being explicitly defined.
Less Pain
The WMS Reflector is designed to make it easier to play around with Geoserver without having to waste time tweaking cumbersome URLs. Before, writing a WMS request by hand was almost impossible, since you had to manually make sure that the ratio between the width and height parameters was the same as the ratio for the bounding box. You also had to know what a spatial reference system is, what version of WMS you wanted to use, and so on.
None of this should be weighing on the user who just wants to get Geoserver to show them a map. The WMS Reflector frees them from this kind of micromanagement. As seen in Exhibit B above, all you need to do is supply either a height or a width attribute and the rest–the bounding box, the other dimension–are automagically tailored to the data.
Overriding the Defaults
With the WMS Reflector handling the sizing and bounding box issues, it’s easier to play with Geoserver’s different output formats. The default request returns a PNG image of a map. But the following URL gets you a PDF
http://geo.openplans.org:8080/geoserver/wms/reflect?format=application/pdf&layers=topp:states
Once again, with the Reflector, the URL contains just what needs to be said, and no more. You can even use the Reflector to quickly make navigable OpenLayers maps using the format=application/openlayers option.
http://geo.openplans.org:8080/geoserver/wms/reflect?format=application/openlayers &layers=topp:states&height=300
If you are interested in learning more about the WFS Reflector and the parameters it supplies and derives, take a look at Arne’s documentation, which provides more details and examples.
Permalink