A quick announcement, that we’ve been showing off at Where 2.0: OpenGeo is building GeoServer 1.7.0 to be automatically crawlable by Google’s Geo Search. David and Arne have been working on trunk, and we’ve stood up a working prototype at http://geosearch.opengeo.org/geosearch/rest/. This has been crawled by Google’s crawler, and is now findable from Google Maps or Google Earth. The dataset we’re standing up is Benzo(a)pyrene emission levels around the Great Lakes region, so now you can search for those levels directly on the places in the PostGIS database, like ‘Benzo(a)pyrene Carbit Paint’. That link shows the search results on Google Maps, with the blue marker at the top of the list containing data coming straight from GeoServer. You can also constrain the search to just geosearch.opengeo.org and browse through the results. Try clicking on the various links, which will take you to visualizing the whole dataset in google earth, using GeoServer’s traditional KML output, or you can click on the glc:glin_benzo link to see the KML in Google Maps.

Though it’s not incredibly flashy, this feature to me is one of the most exciting things to come in awhile.  It speaks to the future of the geospatial web, where your data is just available on a variety of platforms.  Instead of making a specific mapping application and putting some metadata on it, your geospatial data - the actual data - is crawlable and available on the geospatial web.  Our dream is that GeoServer is like Apache for the geospatial web, the standard open source way to get your information on the web.   Google and others can then crawl and figure out better and better ways to return and rank the results.

At Where 2.0 John Hanke and Jack Dangermond just announced that ESRI ArcGIS Server 9.3 will also support all content being crawlable, which is great to see as well, to get all the people who already have their server set up to easily expose their data to the geospatial web.  Though Jack seemed to almost gloss over that fact, he was eager to get to the point that these are real services that offer real GIS analysis.  John twice had to bring it back to the availability of this data to be easily found and used by other people in new ways, which to me is the much bigger point, that anyone will be able to do new analysis, even if they aren’t ‘GIS Experts’.  The geospatial web is not about the GIS analysis (though it’s an interesting aspect for sure), it’s about getting many more eyeballs on the problems facing us today.  GeoServer and ArcGIS Server 9.3 will both be great ways to open up vast amounts of existing geospatial data to be found and used by everyone, to be combined and reused in ever more interesting ways.

Chris Holmes and I are at JavaOne in San Francisco this week, and Chris and Justin will also be going to Where 2.0. We are wondering whether there are any GeoServer users here, or in the bay area in general, that would be interested in meeting for lunch?

Tentatively around noon tomorrow, Thursday the 8th, near the Moscone center. Just an informal chat and a great opportunity to meet other users. Please email ak+meetup@openplans.org if you’re interested and I’ll be in touch with the details.

Also email me if you’re going to Where 2.0, we’ll try do something similar there as well.

I just wanted to give a quick hello to those in the wider world working on GeoServer. The GeoServer website recently got a bump in network traffic, and when we investigated, we saw it was directed by a group in Russia called GIS-Lab, who have an introduction to using GeoServer on their site. (Google translation)

Also, if you are a faithful reader of this blog, you’ll notice that Fernando Quadro often paraphrases some of our posts in Portuguese. There is a GeoServer mailing list in Portuguese as well. Earlier this month, the GeoServer website was “slashdotted” by Slashdot Japan regarding a company which is using OpenLayers, GeoServer, and GeoWebCache.

We currently have local translations for our web interface in Japanese, Chinese, French, German, Portuguese, and Spanish. We’re always looking for people to write more localizations as well (please see our website for information on how to localize GeoServer). We’re eventually looking to have the core of our documentation translated as well.

This is all very promising, as it shows that the need for an open-source mapping framework is a worldwide desire, transcending the boundaries of nation and language. We have set up a page denoting these international resources. If you know of other GeoServer blogs, mailing lists, or other websites that we may not be aware of, please add them to that page, as we would love to know about them.

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.

GeoWebCache has been pulled apart and put together again with Spring, the result is version 0.8.0 (click here to download WAR and source) and it is much more modular and configurable than previous versions. The goal of this exercise was to make it easier to integrate with GeoServer, which has already been done and will be documented very soon. GWC can now configure itself automatically based on a WMS getCapabilities document and serve both EPSG:4326 and EPSG:900913 using the same layer definition. It can also create KML super-overlays for Google Earth, in addition to the Virtual Earth and Google Maps support that was introduced in 0.7.2.

Along the way I learned that there have been some issues with JPEG and metatiling, and consequently GeoWebCache now falls back to Java 2D (instead of JAI) when dealing with those. Note that URLs used in GWC, and a few configuration parameters, have changed since the previous version.