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:

[gallery]

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:

`true`

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.

The GeoExt library is a javascript framework for building rich web based mapping applications which is built on top of the the OpenLayers and Ext libraries. The project has recently kicked itself off with the forming of a mailing list, and a call for participation.

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:

Enjoy,

Simone.

In our previous post on dynamic symbolizers, we saw how we can generate dynamic external symbolizers based on feature attributes using only a simple style (SLD).

Today we’ll see two other features of dynamic symbolizers, namely:

• using decorative TrueType fonts as markers in your map

• Programing your own dynamic symbolizer to extend existing ones, with full access to the current feature attributes

Using decorative True Type fonts as markers

As you may already know, the internet is filled with these funny dingbat TrueType (TTF) files that do not contain a recognizable font, but instead include a set of symbols. If you are a Windows user, you should be familiar with the Wingdings font.

Some commercial GIS software use characters in these fonts as point markers, so it’s no surprise that you can find some TTF fonts with cartographic symbols embedded.

As standard, you can use font characters by leveraging the TextSymbolizer.  You can specify a font (say, Wingdings), and then a specific character (or characters) to serve as a point. This works, but has two flaws:

1. Since the markers are labels, not points, they are subject to “conflict resolution.”  Multiple overlapping labels are discarded in favor of a single label.  This means that not all points will necessarily be displayed.

2. You are restricted to choosing the just the fill color of the marker (like a normal character).

Dynamic symbolizers come to the rescue again.  With dynamic symbolizers, you can use a character in a font as a PointSymbolizer.  The syntax for this is specified as:

ttf://FontName#code

Say, for example, that you would like the snowflake symbol from the Wingdings font as a marker in your map. You fire up the Windows charmap utility (the GNOME Character Map program works as well) and learn that the snowflake code is 0x54. (Actually, the code, is in fact 0xF054 (prefix the code with F0).

So your snowflake mark may look like:

<span class="nt"><Mark></span>
  <span class="nt"><WellKnownName></span>ttf://Wingdings#0xF054<span class="nt"></WellKnownName></span>
  <span class="nt"><Fill></span>
    <span class="nt"><CssParameter</span> <span class="na">name=</span><span class="s">"fill"</span><span class="nt">></span>#000088<span class="nt"></CssParameter></span>
  <span class="nt"></Fill></span>
<span class="nt"></Mark></span>

Here is the sample layer sf:archsites drawn with the above mark, and the full SLD.  Notice that the points that overlap are all shown, which would not have happened using a standard TextSymbolizer.

<span class="cp"><?xml version="1.0" encoding="ISO-8859-1"?></span>
<span class="nt"><StyledLayerDescriptor</span> <span class="na">version=</span><span class="s">"1.0.0"</span> <span class="na">xmlns=</span><span class="s">"http://www.opengis.net/sld"</span> <span class="na">xmlns:ogc=</span><span class="s">"http://www.opengis.net/ogc"</span>
  <span class="na">xmlns:xlink=</span><span class="s">"http://www.w3.org/1999/xlink"</span> <span class="na">xmlns:xsi=</span><span class="s">"http://www.w3.org/2001/XMLSchema-instance"</span>
  <span class="na">xsi:schemaLocation=</span><span class="s">"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd"</span><span class="nt">></span>
  <span class="nt"><NamedLayer></span>
    <span class="nt"><Name></span>Snow symbol<span class="nt"></Name></span>
    <span class="nt"><UserStyle></span>
      <span class="nt"><Title></span>Snow symbol<span class="nt"></Title></span>
      <span class="nt"><Abstract></span>Marks each point with a snow symbol<span class="nt"></Abstract></span>

      <span class="nt"><FeatureTypeStyle></span>
        <span class="nt"><Rule></span>
          <span class="nt"><Title></span>Red square<span class="nt"></Title></span>
          <span class="nt"><PointSymbolizer></span>
            <span class="nt"><Graphic></span>
              <span class="nt"><Mark></span>
                <span class="nt"><WellKnownName></span>ttf://Wingdings#0xF054<span class="nt"></WellKnownName></span>
                <span class="nt"><Fill></span>
                  <span class="nt"><CssParameter</span> <span class="na">name=</span><span class="s">"fill"</span><span class="nt">></span>#000088<span class="nt"></CssParameter></span>
                <span class="nt"></Fill></span>
              <span class="nt"></Mark></span>
              <span class="nt"><Size></span>12<span class="nt"></Size></span>
            <span class="nt"></Graphic></span>
          <span class="nt"></PointSymbolizer></span>
        <span class="nt"></Rule></span>

      <span class="nt"></FeatureTypeStyle></span>
    <span class="nt"></UserStyle></span>
  <span class="nt"></NamedLayer></span>
<span class="nt"></StyledLayerDescriptor></span>

Using a TTF character as a PointSymbolizer has another advantage:  you can specify both the fill (inside) color and stroke (outside) color separately.

As we’ve seen before, you also have the option to embed CQL expressions inside the well known name. For example, you could embed the symbol code into a feature attribute, and have each feature use a different marker as a result!

Not happy with the current symbolizer sets? Build your own!

If you’re not happy with the symbolizing capabilities you can now build your own and plug it into GeoServer as any other extensions.

For details of how this can be done have a look at the dynamic symbolizer proposal in GeoTools, and see the sample TTFMarkFactory as an example:

If you haven’t yet employed dynamic symbolizers in your maps, now you have some reasons to do so.  Enjoy!

Are you or your organization serving data publicly via GeoServer?  Would you like this data to be searchable via Google Maps?

At OpenGeo we are testing out new “geo search” functionality in GeoServer.  We believe this is the future of finding geospatial information on the web.  While still in development, this functionality will be available to all in GeoServer 1.7.2 when it is released.

We have a sample of a search in Google Maps that brings up data served by GeoServer.  (You can click on the blue markers to see information about the data set.)

We are very interested in working with organizations with public data to help test this.  We are willing to donate resources to help configure your servers so that your public-facing data can become even more accessible.  When we announce this functionality to the world, your geospatial information will be prominently featured.

If you are interested please email me: mike AT opengeo DOT org.