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.
