= DODSExample2 =

== DODS Example 2 - Render and Query ==

This example is similar to DODSExample1 in how rendering is accomplished. However, in order to produce per-depth reading query results it is necessary to do the queries again the layer in "normalized" form. That is, with each depth reading sub-sequence record at a profile point treated as a feature.

To accomplish this we need to provide hint "AIS" information to the OGR driver to tell it what strategies to use for the layers. The .das file for this looks like this:
{{{
natl_prof_bot.cdp.das:

Attributes {
    ogr_layer_info_1 {
	string layer_name normalized;
	string spatial_ref WGS84;
	string target_container location.profile;
        x_field {
            string name location.lon;
	    string scope dds;
        }
        y_field {
            string name location.lat;
	    string scope dds;
        }
    }
    ogr_layer_info_2 {
	string layer_name profiles;
	string spatial_ref WGS84;
	string target_container location;
        x_field {
            string name location.lon;
	    string scope dds;
        }
        y_field {
            string name location.lat;
	    string scope dds;
        }
    }
}
}}}
The things to note are that the first layer definition (named normalized) references location.profile as the target_container. So a feature (shape in MapServer-speak) is produced for each record in the location.profile sequence. That is a feature for each depth reading.

The second layer (profiles) references just location as the target_container, so a feature is produced for each location at which readings were taken.

In order to instruct the DODS client side libraries to associate the above information as additional DDS info (via the DODS AIS mechanism) we need to provide an AIS file mapping the DODS url to the das file like this:
{{{
ogr_ais_eg.xml:

<?xml version="1.0" encoding="US-ASCII" standalone="no"?>
<!DOCTYPE ais SYSTEM "http://www.opendap.org/ais/ais_database.dtd">
<ais xmlns="http://xml.opendap.org/ais">

  <entry>
    <primary regexp="http://www.epic.noaa.gov:10100/dods/wod2001/natl_prof_bot.cdp*"/>

    <ancillary url="/u/www/dods/natl_prof_bot.cdp.das"/>
  </entry>
</ais>
}}}
Now the mapfile looks like this:
{{{
MAP
NAME  "test"
SIZE  400 400
EXTENT  -5 -2 5 8
CONFIG DODS_CONF "/u/www/dods/dodsrc"
CONFIG DODS_AIS_FILE "/u/www/dods/ogr_ais_eg.xml"

PROJECTION
"proj=latlong"
END

#
# Start of web interface definition
#
WEB
  HEADER demo_header.html
  TEMPLATE demo.html
  FOOTER demo_footer.html
  MINSCALE 1
  MAXSCALE 15500000000
  IMAGEPATH "/u/www/tmp/"
  IMAGEURL "/tmp/"
#  LOG "demo.log"
END

SYMBOL
  NAME "cross"
  TYPE vector
  POINTS
    2 0
    2 4
    -99 -99
    0 2
    4 2
  END 
END

LAYER
  NAME  "test_locations"
  TYPE POINT
  CONNECTIONTYPE OGR
  CONNECTION 'DODS:http://www.epic.noaa.gov:10100/dods/wod2001/natl_prof_bot.cdp?lat,lon'
  DATA 'profiles'
  STATUS  default
  CLASS
    COLOR 255 255 0
    SYMBOL 'cross'
    SIZE 8
  END
END

LAYER
  NAME  "test_query"
  TYPE QUERY
  CONNECTIONTYPE OGR
  CONNECTION 'DODS:http://www.epic.noaa.gov:10100/dods/wod2001/natl_prof_bot.cdp'
  DATA 'normalized'
  TEMPLATE normalized_query.html
  STATUS  default
END

END
}}}
Key things to note are that CONFIG statements are used to ensure particular dodsrc and AIS info files are used. Also, note that the rendering layer (TYPE POINT) uses the profiles layer restricted to the lat,lon values as done before. However, the new query layer (TYPE QUERY) uses the normalized layer, so that a query record is returned for each depth reading.

This can be see in operation at:

  http://gdal.velocet.ca/dods/demo_init.html

If you check, you should see that a multiple query on a point returns a bunch of different depth readings for the same _id (profile) location.