OpenGeo

By now you might have heard the buzz about the OpenGeo Suite, OpenGeo’s newest product offering that we unveiled at this year’s Where 2.0 Conference. Now we’re sure you’re looking for the details…

OpenGeo has an open pricing structure, and clients are encouraged to tailor their support hours to meet their unique needs. Every client gets access to core developers of each component of the OpenGeo Suite. OpenGeo has committers on all the projects it supports, ensuring that bugs will get fixed quickly – usually on the order of days or hours instead of weeks or years.

Take a look at the full press release for more.

You’ll see that OpenGeo has a shiny new Press Center - we’ll be using this space to keep the world updated on the happenings at OpenGeo, so check back to learn about what we’ve been up to.

Our OpenGeo team descended on Where 2.0 this week for the annual festival of geo-location as perceived by Silicon Valley.  All our content was delivered on the first day, workshop day, in presentations on the components of the OpenGeo Suite — GeoServer, OpenLayers and PostGIS.  The facilities and technical support at the conference were great, as usual with an O’Reilly event.

We talked to lots of people at the conference and received positive feedback on our recently published architecture document and enterprise product offering–the OpenGeo Suite. We also heard interest in more support materials about organizations using our software and their decision process moving towards open source. So we will be beefing up the case studies section of the web site to provide that information.

The workshop materials we presented at Where 2.0 are going to be released as Creative Commons Attribution Share-alike, at the workshops.opengeo.org site in the near future. Right now the site is a bit skeletal, but we look forward to filling it up with more material as we go to more events and prepare more training sessions.

… OpenGeo will be next week! 

On workshop day, Paul Ramsey will be presenting on Spatial Database Tips and Tricks, and Justin Deoliveira will be presenting on the OpenGeo suite of software.  Sophia Parafina and Mike Pumphrey will also be along for the schmooze, and helping with the workshops.

Want to get in touch? We will be hanging around the OSGeo booth at the exhibition a good deal, and Where has provided a snazzy “get in touch” feature for their attendees.

James Dixon over at Pentaho relays some good advice he heard from CIOs about how to deal with software suppliers:

Basically [these CIOs] have a policy of having relationships with two vendors for all major systems: operating systems, databases, application servers etc. This way if one of the vendors tries to force price increases the CIO can threaten to move applications over to the other vendor to reduce their dependency (and costs). Of course, dual-vendor strategy or not, anyone can threaten to change vendor at any time. But without an existing dual-vendor strategy there are obvious costs involved in switching. When the dual-vendor strategy is in place the threat is real, without it the threat is fairly weak.

In order to have a legitimate dual-vendor strategy, you’ll have to spend a bit more staff time, testing and ensuring your applications can be migrated from component to component. But that staff time should be returned in the form of price breaks from vendors.

For us in the geospatial realm, it means keeping an eye on our architectures: are we using standards for inter-component communication or are we relying entirely on the vendor to handle communication between components? The more we let vendors sell us stovepipes, the more radically we must be willing to change in order to maintain a credible dual vendor threat.

For example, a web application built on interoperable components can be re-formulated in myriad ways, depending on what vendor we are using. An Oracle/GeoServer/OpenLayers application becomes an Oracle/Mapserver/OpenLayers application or a PostGIS/GeoServer/OpenLayers application or a PostGIS/GeoServer/GoogleMaps application or an Oracle/GeoServer/GoogleMaps application relatively easily, because the layers are not very tightly coupled.

Open architectures, combined with an dual vendor strategy keeps options (both technical and budgetary) open. That’s a good thing.

OpenGeo is pleased to announce the first release of Styler (demo), which we believe is one of the best SLD editors out there.

“SLD” stands for ‘Styled Layer Descriptor.’ It is an open standard of rules for rendering of maps. Think of it as CSS for maps: it controls the colors, line widths, strokes, labels, varying them according to scale and attributes of the data.

Our initial goal is modest – make it easier for people to get their data in GeoServer and portrayed as they want. One of GeoServer’s advantages is its point-and-click web administration GUI. But when it comes to configuring how your map looks, GeoServer currently provides only a text box to fill out with SLD. Styler is the last piece needed for full GUI configuration of data. The initial release doesn’t cover all the potential rendering options that GeoServer supports, but we think it does a good job of covering the basics.

Despite humble beginning, Styler’s future is ambitious. Our aim is to democratize cartography, enabling anyone to create a map that emphasizes what they want to emphasize. And we want to give web designers the ability to design maps that match the rest of their site’s aesthetics, instead of picking between the handful of commercially provided options. In time we hope to incorporate full thematic mapping of statistics, as well as the ability to take someone else’s map and restyle it as one likes.

Though the initial release of Styler is a full application that integrates with GeoServer, Styler has been designed to be a component of GeoExt. This means the styling of data can be incorporated in other mapping applications. We seek to grow consumers of maps in to producers, so that users see maps as something that they can change and make their own, even within the context of another application.

Doing this well demands many usability improvements. Our goal is to make map creation an intuitive process that anyone can do. If you are interested in the goals or the results, please join us, we can use help with coding, testing, and funding. You can join the mailing list, and check out the roadmap to see where we’re hoping to head.

The scene—several men crowded into a corner of a library overlooking a large volcanic lake in an old Franciscan monastery in central Italy—would make for quite a romantic origin story if it weren’t for the cables snaking across the floor at the OSGeo Hacking event that took place in Bolsena in June 2008. In that improvisational atmosphere, the GeoSilk Icon Set was born.

There, GeoServer developers found that they needed icons for the new GeoServer 2.0 administrative interface. Mark James’s Silk icons were a good starting point, but when it came to expressing geospatial concepts like features, grids, or datastores the set just didn’t hold up. Because the liberal Creative Commons Attribution 3.0 license made it easy to extend the set, we decided to pilfer from Jody Garnett’s uDig icons for core geospatial concepts and brought them into line with the Silk aesthetic rather than reinvent the wheel.

It’s our hope that GeoSilk will become for open source web-based geospatial software what the Silk set has become for the rest of the web—ubiquitous, well-recognized, clear, and understandable. We have already adopted the icon set for all of our GeoExt-based applications because of how well it integrates with the Silk set used by ExtJS. By standardizing our icon metaphors with uDig, we hope to bring this same universal recognizability to all open source geospatial applications. Using consistent metaphors for geospatial concepts like features, grids, and datastores means that we reduce barriers to entry for our users because they no longer need to learn a new vocabulary for each individual application.

If you would like to use GeoSilk yourself, contribute to the set, or just learn more about the project please visit our Trac instance and SVN repository.