Examples for URI requests to the Map REST Service

Integrate clear colourful maps into your own website or application. Choose data sources and adapt colour, symbology, extent, background textures and line types to fully customise your map.

This page give some usage examples of the Map REST Service API.

Be aware that these examples do not conform to RFC 3986, as the current implementation still doesn't follow the proposed syntaxis. It means that the syntaxis of these examples (and MapRest Services) may change in the coming weeks.

WMS and Layers

The WMS bound to the service is (don't forget the trailing slash).

Since December 2012, this service use the version 2.2.2 of GeoServer.

The services displays TDWG and vmap0 layers ( imported in the "topp" namespace.

The list of layers can be accessed by executing a WMS GetCapabilties request on the "topp" dataset:

Alternatively, you can also use the "preview layer" part of the graphical interface of GeoServer;?wicket:bookmarkablePage=:org.geoserver.web.demo.MapPreviewPage

If you have requests or questions related to the available layers contact franck.theeten @

Description of layers

Since 2011, any layer registered in the WMS can be used in distribution maps and have its style dynamically defined in the HTTP GET parameters (this functionnality was originally limited to TDWG layers).

When building a query, the programmer needs to know the structure of a layer (i.e. the name and the type of fields) since some functionnalities do not work withnumeric attributes. For instance, you can define a filter to apply a style on specific values (like names of countries), but only if the correponding attribute in the database has a text format (you cannot apply filter on integer column).

It is possible to get an XML describing the types and fieldnames of a layer by running a WFS "DescribeFeature" query on GeoServer like in the example below ("typename" being the name of the layer)


=> in the answer: "xsd:string" corresponds to attribute having a test format that can be used in filter.

Map REST Service - Version 1

Does not conform to the latest syntax definition!

Distribution Maps

Service URL:

Basic Issues

Map Image size is specified as 400 pixels width. It means the height will be 200 pixels (just the half). Attention: you cannot specify an odd number as width/height.

A bounding box (bbox) is specified. We strongly recommend to use bbox if know it (for example if all your data is on the same zone).

We provide world country borders and all TDWG levels as background. This parameter must be specified in "l" parameter (l=earth in that example).

Current codes for background layers are:

  • Country borders: earth
  • TDWG level 1: tdwg1
  • TDWG level 2: tdwg2
  • TDWG level 3: tdwg3
  • TDWG level 4: tdwg4


Recalculate Parameter

We see here the "recalculate" parameter in action.

When the bbox is not specified, the service will calculate it and try to fit the image to the specified dimensions (width/height). It can cause distorted images.

Recalculate=true (this is the default if nothing is specified) tries to avoid these distortions. It means also that in some cases the final image size will change as you can see in the first image.


Different TDWG Layers

You can mix different TDWG layers. In that case, TDWG level 3 and TDWG level 1.

No background layer is defined, so you simply get the specified areas.


Symbolize Parameters

A more complex styling. The parameters for styling an area are:

  • Area fill color
  • Area stroke color
  • Area stroke width
  • Area stroke dash style: we currently provide 1_2,1_4,2_2,2_4,5_7 and 10_5 but it can change. First parameter determine the length in pixels to draw the line, and the second, the length in pixels to blank out the line. As example, 5_7 means a very dashed line (separated 7 pixels one line from another).

We always provide default values. So, you could even specify styles "a" and "b" as a:|b: and the image will be generated.

A style like b:0000ff~2 would mean 0000ff fill color and 2 pixels stroke width. The other parameters would be set as default.


Map Legends

A legend can be appended to your map in different positions.

Specify "title" parameter, associating to each style the desired legend. Also legend=1 and "mlp" (map legend position)

It is important to assign, for each style, a title, otherwise cause error.

The map legend position can be:

  • 1: outside of the map, up left
  • 2: outside of the map, up
  • 3: outside of the map, up right
  • 4: outside of the map, below left
  • 5: inside of the map, below right
  • 6: inside of the map, below left
  • 7: inside of the map, up right


A separate service generating legend is working, so you can put the legend wherever you want on your html.|b:native|c:rare|d:unknown&as=a:329d2a,483eef,2,2_2|b:ab8dc9F,da1029,2,5_7|c:d2e347|d:f7555d&ms=60,50

Hatching Patterns

You can also specify a hatch pattern. You need to fill "images_url" and "symbols" for each pattern as shown below. The URL to the image can be remote or local.

The second parameter of "symbols" specifies the size of the image used for hatching.


Using MapRest on a webmapping application

All these mapping services can be used on a dynamic webmapping application like OpenLayers

The question is that, if desired, we return back not an image but a file that specifies the path to the XML that is used for layer symbolization.

With some little javascript coding you can get dynamic maps (zoom in/out, panning...).

Some EDIT dataportals using this technology are PalmWeb ( and Cichorieae (

How to get this file to be integrated on webmapping application? just specify "img=false" and will get a JSON file that could be something similar to...

"layers":[{"tdwg": "tdwg3","session": "","sld": "tdwg3_4e9b417a9789481932b57e53c47291c6.sld"},
{"tdwg": "tdwg1","session": "","sld": "tdwg1_4e9b417a9789481932b57e53c47291c6.sld"}]}]

As you can see, there is the name of XML (SLD) files that provide symbolization for each of specified TDWG layer. Also the legend is specified there.

With some javascript coding you can get dynamic maps. A big advantage of using these widgets is that they automatically calculate the scale at which the image has to be visualized.

By this way you can avoid distorted images that too often happen with "image" MapRest services.

Occurrence Maps

Service URL:

MapRest services also can plot occurrences. Just specify each point data coordinates (in latitude/longitude)

This service is subject to changes soon.

Current symbolization parameters are:

  • symbol: you can choose "c" (a circle), "s" (a star), and "sq" (square)
  • symbol size
  • a name to be used on the legend

Also a "q_layer" has to be specified. It must be the same than the background layer and is used to calculate the bbox.

ATBI sites like Gemer ( and Mercantour/Alpi-Marittime ( are already using this service.

Also point occurrences can be mapped on a dynamic webmapping application but it is still not implemented.


Map REST Service - Version 2

The major improvement of version 2 is that transparency can be applied both on point data and overlay layers.

Distribution Maps

Service URL:

"rest_gen.php" merges the functionalities of points.php and areas.php.

"points.php" and "areas.php" are still available as aliases to rest_gen for backward compatibility reasons.

Compatibility with OGC syntax

Since version 1.2, the service compliant with the syntax version 2.2.2 of GeoServer.

Geoserver follows now more strictly the OGC syntax than before, especially for legends, a point which created an importantbackward compatibility issue when upgrading Geoservber.

Since GeoServer 2.2.1, the syntax of the “GetLegendGraphic” request used in the original version of the PHP script was not valid anymore.

The previous version had this element in the URL: “...geoserver/GetLegendGraphic?service=WMS&…”

...while GeoServer awaits now: “...geoserver/wms?REQUEST=GetGraphicLegend&…”

This has been fixed in version 1.2 and also commited back to version 1.1

Merging point and area data

Transparency on overlay layers