Quoting from the geoSDI web site,
“geoSDI is the complete solution for Spatial Data Infrastructure used by the Italian National Civil Protection Department.
The geoSDI solution is based on Open Source Technologies and was born to allow the real time geospatial data sharing between the Functional Centers of the Italian Civil Protection Department, being OGC (Open Geospatial Consortium) standard compliant, INSPIRE Directive compliant and CNIPA Repertorio Nazionali dei Dati Territoriali specifications compliant.”
The geoSDI infrastructure aims to provide a coherent National Spatial Data Infrastructure (NSDI) which is compliant with national and internal recognized standard as outlined by organizations like ISO and OGC as well as by initiatives like INSPIRE.
We are glad to announce that a core role in the geoSID inititive will be played by the GeoServer framework and that GeoSolutions SAS has been selected to provide professional support for the developments and customizations required. Stay tuned for more information on the topic.
Starting with the 1.7.0 release GeoServer comes with a pretty decent (well, at least IMHO :-) ) implementation of the SLD 1.0 RasterSymbolizer element (check here for a technical discussion on the implementation). On a side this means that we can try to style raster data as well as verctor data. On the other side, this means that if you update GeoServer from an older installation, let’s say 1.6.4 you can get into troubles with preexisting raster data since the old default raster.sld in no longer legal. Here you can find the old raster.sld, while here you can find the new one. which works for 1.7.x and successive releases. Long story short, rationale behind this is that with older geoServer releases we did not have a RasterSymbolizer implementation hence we were simply ignoring most elements of the raster.sld file. From 1.7.0 and on we have a decent RasterSymbolizer implementation, hence the old raster.sld style can no longer be used lightly since it makes assumptions on the underlying data. As a result the new default raster style is just an empty stub.
Summarising, if you are updating GeoSerber from 1.6.x or older, make sure to check to replace the raster.sld with the new onw.
Ciao a tutti.
At this point the extension is still quite young and is missing some key features like spatial indexing and support for well known binary. By trying it out and providing us with feedback you can help drive development of these features.
The extension is based on the recent re-architecture in GeoTools for database backed data stores. Code named “JDBC Next Generation”, it provides a framework for building new data store implementations quickly and robustly. Also based on this architecture are soon to come improved extensions for MySQL, Oracle, and DB2. A new extension for SpatiaLite is also in the works.
GeoServer is a open source project, developed and supported by a diverse group of people from around the world. To highlight this, OpenGeo has built a simple map showing the locations of GeoServer developers. Each developer’s location is marked with a blue point. Clicking on that point will produce a pop-up with the developer’s name and a brief bio.
This map interface is built using OpenLayers. The data points are saved in a PostGIS database and are served through GeoServer. OpenLayers accesses the data using the WFS protocol. The background image is currently the Google terrain layer, but will soon be replaced by OpenStreetMap data.
If you are a GeoServer developer and wish to be included on the map, let us know. Please include your name, a short bio, and the city, state, and country where you live. If anyone has any other comments about this map or the technology behind it, please write to us at firstname.lastname@example.org.
OpenGeo and Safe Software have been talking about working together to make life easier for users of FME and GeoServer. We’ve both been hearing more about organizations using FME to solve their data conversion challenges and then making the results available to the world using the OpenGeo Stack.
While many people are making things work with the software now, we figure that a few improvements towards tighter integration could be a big win. Our end goal is to enable FME Server and GeoServer to work together seamlessly. This allows each piece to solve the area they excel at - GeoServer in OGC standards and web output formats, FME at complex data conversions and translations. With a few key improvements the combined solution should solve the ‘Community Schema’ problem that Ron Lake recently brought up better than any software in world. In time the GeoServer community will definitely build the capability to handle the full community schema transformation natively, but integrating with FME should provide a transitional path, and FME will always be ahead in terms of the most advanced translations.
If you are a user of both FME and GeoServer we’d love to hear from you with input on how we could work together to make your life easier (or you can just give us encouragement ;). We are still in the early stages, hoping to put together a rough prototype relatively soon, but beta testers in the future will be appreciated. And of course additional funding will enable us to prioritize the work and get it done faster. If you are interested in helping out please get in touch at the OpenGeo contact form.