OpenStreetMap is a free and editable map of the world. Founded in 2004 in the United Kingdom in response to the need for a free geospatial data source, it is a community-driven project, allowing for anyone to edit and contribute information. It has since grown to include data from almost all countries in the world. The map generated from their data can be used as an alternative to commercial map layers such as those found in Google Maps. The OpenStreetMap base layer is rendered using Mapnik, however since the data is free to download and distribute, it is possible to serve it using GeoServer. I recently went through the process of rendering OpenStreetMap’s data with GeoServer.
OpenStreetMap provides instructions on downloading their data. The full data set is a large file, currently about 4GB when compressed and about 100GB when uncompressed. (You can download sections of the data set as well.) This data is an XML-based data format that GeoServer cannot read natively. PostGIS is the optimal way of storing such a large volume of data when using GeoServer. Luckily, there is a converter that allows you to load the OpenStreetMap data into PostGIS called
osm2pgsql. This program is a package available on Debian-based distributions (such as Ubuntu), and is also available as a binary on Windows
Run the following command:
osm2psql -E 900913 -d osm planet.osm
This will process the XML information and load the data into a PostGIS database called “osm”. The -E defines the projection of the source data, which in this case is 900913, the projection used in Google Maps, and the default for OpenStreetMap.
If successful, the database will contain the following tables:
Making sense of the data
OpenStreetMap’s data can be a bit confusing. For a first time user like myself, just trying to figure out their naming convention was challenging. They do, however, have a wonderful map key hidden away in their wiki. This page is a lifesaver.
There are two different tables that contain line data,
planet_osm_roads. The former includes railroads, subways, and other linear information. The latter is made up exclusively of roads. The
planet_osm_point table has a range of data: subway stations, shopping centers, universities, and even brothels. Lastly the
planet_osm_polygon table has, but is not limited to, parks, bodies of water, and even buildings in certain urban areas.
On my map I grouped the roads into three major groups; residential, secondary, and limited-access (highways). To achieve this grouping I used the following SLD filters.
|Residential||highway||residential OR unclassified|
|Secondary||highway||primary OR secondary|
|Limited-access||highway||motorway OR trunk|
I then styled the map to distinctly display the three groups of roads, and also varied their widths depending on the zoom level. This was the most time-consuming part of the process, as I needed to create and evaluate styles for each zoom level. The final SLD is very large, but is available for those interested.
Since the purpose of this map was to create a viable base layer that anyone can incorporate into their mapping projects, performance was a concern. To address this, I used GeoWebCache, a tile cache mechanism built into GeoServer. The GeoWebCache documentation has details on this process.
The finished (?) map
The finished product can be found at http://demo.opengeo.org/openstreetmap.
Feel free to link to this map. Use this OpenLayers code to get started. This map is a work in progress. Future enhancements will include adding public transportation systems, railroads, buildings, and more. If you have any feedback on this map please email me at iwillig at opengeo dot org.
With GeoServer, PostGIS, OpenLayers and the OpenStreetMap data set, it is possible to build high-quality, professional-looking maps, allowing you to take control of what data you present, define your own mapping aesthetic, and free yourself from having to use commercial map layers.
The GeoServer team would like to announce the release of GeoServer 1.7.2. This release brings many exciting new features.
The first major improvement is label rendering. In version 1.7.1, GeoServer added support for curved labeling. In this version, support is added for wrapped labels, which enables a label to span multiple lines. This feature affects the labeling of points and polygons.
Thanks to Andrea Aime for all the great labeling improvements.
Another new styling feature is support for hatching. Among many other new designs, this allows railroad styling to be accomplished for the first time. Also, polygon hatched fills can now be drawn, and GeoServer ships with a new style,
pophatch.sld, that can be applied to the topp:states layer to see this in action.
The 1.7.2 release also brings some great new extensions. The HTML imagemap extension (download), contributed by Mauro Bartolomeoli, allows a user to add interactive features to a map without the use of Flash, SVG, or other dynamic content languages. You can check out the imagemap extension in action. A special thanks to Mauro for the contribution.
The new and improved DB2 extension (download), which allows connection with IBM DB2 databases is based on the GeoTools JDBC Next Generation framework. The extension was contributed by Christian Müller, who is an active member of the GeoTools community. Special thanks to Christian.
The new OGR extension (download) is based on the GDAL/OGR library. The extension adds the ability to output from WFS any of the formats supported by OGR. OGR has a very diverse and comprehensive list of output formats, so this extension very much enhances the utility of the GeoServer WFS.
Improvements were also made to the GeoExt styler extension (download), which is a new graphical interface for map styling initially released with GeoServer 1.7.1. Tim Schaub, Andreas Hocevar, and the rest of the GeoExt team have added support for labels to the styler application.
Thanks to the GeoExt team for this great improvement.
In addition, a total of 70 issues were handled for 1.7.2.
Thanks to everyone who contributed features and bug reports for this release. We encourage you to download GeoServer 1.7.2, try it out, and let us know what you think. Comments and feedback are always welcome on the mailing list, as the community is always interested to hear how people are using GeoServer. Stay tuned for the 1.7.3 release, slated for release in the next month, which will include improvements to Geo Search, and the official release of the REST configuration API.
Improvements to GeoServer are being made all the time, but to the average user, not all improvements are immediately discernible. However, recently a new feature has been added to GeoServer’s rendering algorithms, and all I can say is “wow.” I am referring to curved line labeling.
Labels on lines have rendering challenges that points and polygons do not. This is because lines can curve. Not officially, of course, but lines can be a collection of line segments, which meet at their edges but can be rotated with respect to each other. The default behavior for a label is to appear parallel to the orientation of a line. However, this can cause problems when the label resides along a curve, as the label will not follow it. In some extreme cases, the label can appear only marginally connected to the line, which minimizes the effectiveness of the label! Clearly, there was room for improvement.
This improvement was sponsored by TriMet, the Portland, Oregon area transportation agency that uses GeoServer in their Trip Planner. Lead GeoServer developer Andrea Aime tackled this task with his usual aplomb, and GeoServer now renders labels that follow curves. Below is worth two thousand words:
This new road labeling is only in versions 1.7.1 and later. Currently this functionality is not turned on by default, but is instead must be enabled in GeoServer. One way of doing this is to edit your
web.xml file inside the
WEB-INF directory. Stop your GeoServer instance, and insert the following code block:
` USE_NG_LABELLER true
In addition, you also need to edit your SLD to include a
VendorOption inside your
TextSymbolizer. Add the following line:
Restart your GeoServer, and you’re all set!
For me, the ability for GeoServer to output curved line labels is a huge step forward. There’s something about these labels that make the map seem so much more professional. Special thanks to TriMet for sponsoring this awesome new feature. Have you tried it out yet?
Just in time for the holiday season the GeoServer team is happy to announce the coming of a new SLD editor extension based on the newly founded GeoExt project. Download the new extension and try it out. It also requires the installation of the rest plugin. A quick walk through of the installation and functionality can be found here.
A new post on the Raster Symbolizer tips & tricks, this time I am going to show how to build an RGB image using 8 bits or unsigned 16 bits multi band coverages.
I have been playing lately with some remote sensing data for the geoSDI project specifically the emissive subdataset coming from the MODIS sensor on-board the TERRA satellite. A small sample dataset can be found here. Its gdalinfo is here below:
Files: EmissiveCampania.tiff Size is 63, 156 Coordinate System is: GEOGCS[“WGS 84”, DATUM[“WGS_1984”, SPHEROID[“WGS 84”,6378137,298.2572235630016, AUTHORITY[“EPSG”,”7030”]], AUTHORITY[“EPSG”,”6326”]], PRIMEM[“Greenwich”,0], UNIT[“degree”,0.0174532925199433], AUTHORITY[“EPSG”,”4326”]] Origin = (13.742259882413393,41.506517193315830) Pixel Size = (0.032872864093301,-0.009584951678830) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 13.7422599, 41.5065172) ( 13d44’32.14”E, Lower Left ( 13.7422599, 40.0112647) ( 13d44’32.14”E, Upper Right ( 15.8132503, 41.5065172) ( 15d48’47.70”E, Lower Right ( 15.8132503, 40.0112647) ( 15d48’47.70”E, Center ( 14.7777551, 40.7588910) ( 14d46’39.92”E, Band 1 Block=63x65 Type=UInt16, ColorInterp=Gray NoData Value=65535 Band 2 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 3 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 4 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 5 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 6 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 7 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 8 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 9 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 10 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 11 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 12 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 13 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 14 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 15 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535 Band 16 Block=63x65 Type=UInt16, ColorInterp=Undefined NoData Value=65535
The goal was to build a simple RGB on the fly (WCS usage is als envisioned, hence we could not just build it offline) by using bands 11, 9 and 1 respectively.
The style I have used for doing this is reported here below, it is a nice guideline in case you want to do something similar with Landsat data as an instance and create a false color image from the oiriginal dataset ( I might blog about that as well sooner or later :-) ).
<?xml version=”1.0” encoding=”UTF-8”?>
Since we are here, I will also show another rendering we have set up which applies a user defined colormap to band 11 (emissive temperature) which ranges from blu to red. Here is the style:
<?xml version=”1.0” encoding=”UTF-8”?>
and here is the result: