Table of Contents for

Web Mapping Illustrated

With some minor modifications to Example 13-7, you can start to do some basic colortheming. Example 13-8 shows how to make one county stand out among the others using multiple CLASS objects in the layer, along with the EXPRESSION parameter. The resulting map is shown in Figure 13-7.

Figure 13-6. A map showing the county boundaries from PostGIS with other MapServer layers

LAYER
  NAME usa_counties
  TYPE POLYGON
  STATUS DEFAULT
  CONNECTIONTYPE POSTGIS
  CONNECTION "dbname=project1 user=tyler host=localhost port=5432"
  DATA "wkb_geometry from countyp020"
  CLASS
                     EXPRESSION ("[county]" = 'Sonoma County')
    SYMBOL 'circle'
    SIZE 4
    OUTLINECOLOR 255 0 0
  END
    CLASS
    EXPRESSION ("[county]" != 'Sonoma County')
    SYMBOL 'circle'
    SIZE 2
    OUTLINECOLOR 0 0 0
  END
  PROJECTION
    "init=epsg:4326"
  END
END

Figure 13-7. Sonoma County highlighted using a second class with a different color, line thickness and expression parameter

More sophisticated queries can be used in the DATA line for the layer, but some care is needed to make it work. For example, if you are more comfortable with SQL and want to show only Sonoma County, you might be tempted to use:

DATA "wkb_geometry from countyp020 where county = 'Sonoma County'"

This won’t work. You need to handle any deviation from the most basic DATA parameter as a subquery. Here is an example of a subquery, put onto separate lines for readability only:

DATA "wkb_geometry from (
                  select wkb_geometry
                  from countyp020
                  where county = 'Sonoma County')
                  as myquery"

The subquery is the part in the parentheses and can be much more complex than this example. The myquery keyword is arbitrary but necessary. It can be any name and is simply a placeholder. MapServer needs two more pieces of information to handle subqueries. It needs to be able to uniquely identify each record coming from PostGIS. To do this, add a using unique <field name> clause. If you include a unique number field in your query use that field name: using unique countyID. Otherwise you might try using the geometry field because it will probably have unique values for every record: using unique wkb_geometry. It may be not be the most efficient choice, but it does work.

MapServer also needs to know what spatial reference system the data will be in. This is specified by adding a using srid = < SRID # > clause. If you already have a PROJECTION section for your layer in the map file, you can probably get away with: using srid = -1, which effectively ignores the projection settings.

A working example of this subquery method is shown in Example 13-9.

DATA "wkb_geometry from ( select wkb_geometry from countyp020 where
           county = 'Sonoma County') as myquery using unique wkb_geometry
using srid = -1"

A mixture of other PostGIS and PostgreSQL functions can be used in a subquery. For example:

DATA "wkb_geometry from ( select wkb_geometry from countyp020 where
wkb_geometry && 'POINT(-122.88 38.52)' ) as myquery using unique
wkb_geometry using srid = -1"

This example uses the PostGIS bounding box comparison operator (&&) and a manually constructed point geometry. It selects the geometry of the county polygon using the location of the point, just like in earlier examples in the "Querying for Spatial Proximity" section.

PostGIS can also create new spatial features through queries, and MapServer can then map them. For example, you can use the buffer() function to create a buffered area around your shape. You can create another layer using the exact syntax as Example 13-9, but then change it so that it uses a buffer() to expand the shape. It may also be helpful to simplify the shape a bit so that the buffer is smoother. Here is a complex example that uses both the buffer() and simplify() functions:

DATA "wkb_geometry from (
select buffer( simplify(wkb_geometry,0.01), 0.2)
         as wkb_geometry
from countyp020
where county='Sonoma County ') as foo
using unique wkb_geometry"

Both functions require a numeric value as well as a geometry field. These numeric values are always specified in the units of measure for the coordinates in the data. simplify() weeds out certain vertices based on a tolerance you provide. In this case it simplifies to a tolerance of 0.2 degrees. That simplified shape is then passed to the buffer() function. The buffer drawn around the features is created 0.01 degrees wide.

Many different types of queries can be used, including queries from tables, views, or manually constructed geometries in an SQL statement. For anything other than the most simple table query, be sure to use the using unique and using srid keywords properly and ensure that the query returns a valid geometry.

As with any MapServer data source that has attribute data, PostGIS layers can also use this information to label a map. Example 13-10 is the same as Example 13-8, but includes parameters required for labeling.

LAYER
  NAME usa_counties
  TYPE POLYGON
  STATUS DEFAULT
  CONNECTIONTYPE POSTGIS
  CONNECTION "dbname=project1 user=tyler host=localhost port=5432"
  DATA "wkb_geometry from countyp020"
  LABELITEM
                     "county"
  CLASS
    EXPRESSION ("[county]" = 'Sonoma County')
    SYMBOL 'circle'
    SIZE 2
    OUTLINECOLOR 0 0 0 #222 120 120
    LABEL
                     COLOR 0 0 0
                     OUTLINECOLOR 255 255 255
                     TYPE TRUETYPE
                     FONT ARIAL
                     SIZE 14
                     END
  END
  PROJECTION
    "init=epsg:4326"
  END
END

This example assumes you have a FONTSET specified in the map file, with a font named ARIAL available. If you don’t have these, remove the TYPE, FONT, and SIZE lines in the example.

Adding labels to maps is discussed in more detail in Chapters 10 and 11. With PostGIS, there are a couple additional considerations to keep in mind. The attribute specified by LABELITEM must exist in the table that holds the geometry or in the subquery used. While this sounds like common sense, it is easy to forget. Example 13-10 has a simple DATA parameter and doesn’t include a subquery. Because it points to an existing table, all the attributes of that table are available to be used as a LABELITEM. However, if a subquery is used as in Example 13-9, the attribute used in LABELITEM must also be returned as part of the subquery. To use the code in Example 13-9, more than just the wkb_geometry column needs to be returned by the subquery. The resulting settings needs to look like:

DATA "wkb_geometry from ( select county
                  , wkb_geometry from countyp020 where county =
'Sonoma County') as myquery using unique wkb_geometry using srid = -1"

The only addition was county in the subquery. This makes the county attribute available to MapServer for use with labels, in addition to the wkb_geometry attribute which was already part of the subquery.

The other common issue encountered when creating labels is related to the case of field names. In PostgreSQL (as with other relational databases), it is possible to have upper- and lowercase field names, in addition to normal names with no explicit case. All the field names used in the examples so far have been normal, but some tools may create fields that are all uppercase, all lowercase, or (even worse) mixed case. This makes it difficult to refer to field names because the exact case of every letter in the field name needs to be specified throughout your MapServer layer parameters. This is done by using double quotes around field names, which gets confusing when you may already be using double quotes around a field name as in LABELITEM "county" in Example 13-10. If the county attribute is stored as an uppercase field name, then a set of single quotes must be wrapped around the field name. The field name must be written in uppercase, like: LABELITEM '"COUNTY"'.

If you use ogr2ogr for loading data into PostgreSQL, you may need to use another option to ignore uppercase table and field names. The layer creation option -lco LAUNDER=YES ensures that all table and field names are in normal case. By default, ogr2ogr maintains the case used in the data source.

Even if you’re using PostGIS, your organization may still be using ESRI’s proprietary tools. A common question for ESRI ArcGIS users is “How can I access PostGIS data in ArcMap?” There is an open source project called the PostGIS-ArcMap Connector, PgArc for short. You can find this project at http://pgarc.sourceforge.net/.

PgArc automates the import of PostGIS tables into temporary shapefiles and loads them into ArcMap. Layers can then be edited and put back into PostGIS, overwriting the existing table in the database. There have been some changes introduced with ArcMap 9 that are currently being addressed. More improvements can still be made to strengthen the product; volunteer ArcMap programmers are always welcome.

Another way to access PostGIS data is to use the Web Mapping Server capabilities of MapServer. MapServer can access PostGIS data and create map images using the WMS standard. ESRI has an interoperability extension for ArcMap that allows users to access WMS layers. MapServer is excellent at filling this middle-man role. Chapter 12 is devoted to using MapServer with Open Geospatial Consortium Web Mapping Standards.

For ArcView 3 users, Refractions Research has an excellent WMS connector available at http://www.refractions.net/arc3wms/. An ArcIMS emulator is also available that can make MapServer layers available as ArcIMS layers. More information about the emulator is at http://mapserver.refractions.net/.