10g (9.0.4)
Part Number B10559-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle® Application Server 10g MapViewer User's Guide 10g (9.0.4) Part Number B10559-01 |
|
This chapter explains concepts that you should be familiar with before using MapViewer.
The fundamental concepts are style, theme, base map, mapping metadata, and map.
When an application uses MapViewer, it applies specific styles (such as colors and patterns) to specific themes (that is, collections of spatial features, such as cities, rivers, and highways) to render a map (such as a GIF image for display on a Web page). For example, the application might display a map in which state parks appear in green and restaurants are marked by red stars. A map typically has several themes representing political or physical entities, or both. For example, a map might show national and state boundaries, cities, mountain ranges, rivers, and historic sites. When the map is rendered, each theme represents a layer in the complete image.
MapViewer lets you define styles, themes, and base maps, including the rules for applying one or more styles to each theme. These styles, themes, base maps, and associated rules are stored in the database in map definition tables under the MDSYS schema, and they are visible to you through metadata views. All styles in a database instance are shared by all users. The mapping metadata (the set of styles, themes, and base maps) that you can access is determined by the MapViewer metadata views described in Section 2.5 (for example, USER_SDO_STYLES, USER_SDO_THEMES, and USER_SDO_MAPS). The set of map definition objects that a given user can access is sometimes called that user's mapping profile. You can manage styles, themes, and base maps with the Map Definition Tool, described in Chapter 7.
A style is a visual attribute that can be used to represent a spatial feature. The basic map symbols and labels for representing point, line, and area features are defined and stored as individual styles. Each style has a unique name and defines one or more graphical elements in an XML syntax.
Each style is of one of the following types:
When a marker style is specified for a line feature, the rendering engine selects a suitable point on the line and applies the marker style (for example, a shield marker for a U.S. interstate highway) to that point.
BucketStyle, which defines the relationship between a set of simple styles and a set of buckets. For each feature to be plotted, a designated value from that feature is used to determine which bucket it falls into, and then the style associated with that bucket is used to plot the feature.
The AdvancedStyle class is extended by BucketStyle, which is in turn extended by ColorSchemeStyle and VariableMarkerStyle. (Additional advanced styles, such as for charts, are planned for a future release.)
Table 2-1 lists the Java class for creating styles of each type.
All styles for a database user are stored in that user's USER_SDO_STYLES view, which is described in Section 2.5 and Section 2.5.3.
For more detailed information about the types of styles, including information about the XML format for defining each type, see Appendix A.
A theme is a visual representation of a particular data layer. Each theme (except for image themes) is associated with a specific spatial geometry layer, that is, with a column of type MDSYS.SDO_GEOMETRY in a table or view. For example, a theme named US_States might be associated with the STATE_SHAPE spatial geometry column in a STATES table.
A theme can have its definition, including styling rules, stored permanently in the database (a predefined theme), or a theme can be dynamically defined with a map request (a JDBC theme).
All predefined themes for a database user are stored in that user's USER_SDO_THEMES view, which is described in Section 2.5 and Section 2.5.2.
Each predefined theme is associated with one or more styling rules. The styling rules for each predefined theme are expressed using XML, such as in Example 2-1 for an Airport theme.
<?xml version="1.0" standalone="yes"?> <styling_rules> <rule> <features style="c.black gray"> runway_number > 1 </features> <label column="name" style="t.airport name"> 1 </label> </rule> <rule> <features style="m.airplane"> runway_number = 1 </features> </rule> </styling_rules>
Each styling rule has a required <features> element and an optional <label> element. The <features> element specifies which rows (features) in the table or view will be selected based on its attribute value, and the style to be used for those selected features. The <label> element specifies whether or not to annotate the selected feature, and if so, which column in the table or view to use for text labels.
In Example 2-1, there are two styling rules associated with the Airport theme:
runway_number > 1 (that is, runway number greater than 1) will be selected, and these will be rendered using the style named c.black gray. Any valid SQL WHERE clause conditions can be used as the value of a <features> element. If no value is supplied, no WHERE clause condition is applied. For example, assume that the definition had been the following (that is, omitting the runway_number > 1 condition):
<?xml version="1.0" standalone="yes"?> <styling_rules> <rule> <features style="c.black gray"/> <label column="name" style="t.airport name"> 1 </label> </rule> </styling_rules>
In this case, all airport features would be selected and would be rendered using the color style named c.black gray.
The first rule also has a <label> element, which specifies that the NAME column in the table or view will be used to annotate each airport, using the text style t.airport name. The value of the <label> element, which can be any SQL expression, is used to determine whether or not a feature will be annotated. If the value is greater than zero, the feature will be annotated. In this case, because the value is the constant 1, all features specified by the <features> element will be annotated, using the values in the NAME column. If the value is less than or equal to zero for a feature, that feature will not be annotated.
<label> element, thus preventing all such airports from being annotated. In addition, the features that satisfy the second rule will be rendered using a different style (m.airplane), as specified in its <features> element.
If two or more rules are specified, a UNION ALL operation is performed on the SQL queries for the rules (from first to last) to fetch the qualified features from the table or view.
If an advanced style is specified in a rule, the SELECT list of the query to fetch qualified features contains the spatial column, the attribute column or columns, the name of the feature style, the label information, the WHERE clause, and the feature query. Based on the value of the attribute column or columns and the definition of the specified feature style, each feature is associated with a style.
A JDBC theme is a theme that is dynamically defined with a map request. JDBC themes are not stored permanently in the database, as is done with predefined themes.
For a JDBC theme, you must specify a valid SQL query that retrieves one or more geometries from the database. You can also specify a rendering style and labeling style, to be used if you also selected text values in the query that can be used for labeling the geometries.
Example 2-2 is a map request that includes a JDBC theme.
<?xml version="1.0" standalone="yes"?> <map_request title="My MAP" datasource = "mvdemo"> <themes> <theme name="jdbc_theme_1"> <jdbc_query datasource="mvdemo" jdbc_srid="41052" spatial_column="geometry" render_style="C.RED"> SELECT geometry from states where name='MA' </jdbc_query> </theme> </themes> </map_request>
The full query that MapViewer executes for the JDBC theme in Example 2-2 is:
SELECT geometry FROM states WHERE name='MA';
For this request, MapViewer generates a map that contains only the selected geometry as a result of executing this JDBC theme's query. In a more typical case, however, the map request will need to use several JDBC themes to plot additional dynamic data on top of the base map. Furthermore, the map request may have a query window associated with it; that is, the user may want to see only a portion of the area included in the whole base map. In this case, the SQL queries in the JDBC themes will be subjected to a spatial window query, to eliminate any unwanted results.
For more information about JDBC themes, see the information about the <jdbc_query> element in Section 3.2.7.
Sometimes the SQL query for a JDBC theme is so complex that you may want to save the query. In such cases, you can define a predefined theme (whose definition is stored in the database's USER_SDO_THEMES view), and then include the full SQL query as the content of the <features> element in the styling rules for that theme.
The feature style specified in the <features> element is then used to render the geometries retrieved using the full query. The base table as defined for such a theme is ignored because the full SQL query already includes a FROM clause. The geometry column defined in the USER_SDO_THEMES view is still needed, and it must be the same as the geometry column selected in the user-supplied SQL query. If you have a <label> element for a styling rule, the label style specified is used to label the geometries, as long as the query selects a column that contains label text.
Example 2-3 is a sample <styling_rules> element of a predefined theme with a complex SQL query.
<?xml version="1.0" standalone="yes"?> <styling_rules> <rule> <features style="L.POOR_ROADS" asis="true"> select sdo_lrs.clip_geom_segment(geometry,start_measure,end_measure) geometry from (select /*+ no_merge use_hash(a b) */ a.street_id, name, start_measure, end_measure, geometry from (select /*+ no_merge */ a.street_id, name, geometry from philly_roads a where sdo_filter(geometry,mdsys.sdo_geometry(2002,41124,null, mdsys.sdo_elem_info_array(1,2,1), mdsys.sdo_ordinate_array(?,?,?,?)), 'querytype=window')='TRUE') a, philly_road_conditions b where condition='POOR' and a.street_id = b.street_id) </features> </rule> </styling_rules>
Even though Example 2-3 is defined as a predefined theme, MapViewer still treats it as a JDBC theme at runtime when a user requests a map that includes this theme. As with a normal JDBC theme, MapViewer by default imposes a window filtering process (if a query window was included in the map request) on top of the SQL query. To override this default behavior and have the supplied query string executed without any modification, specify asis="true" in the <features> element, as shown in Example 2-3. (For information about the asis attribute, see Section 3.2.7.)
Thematic mapping refers to the drawing of spatial features based on their attribute values. MapViewer uses thematic mapping to create maps in which colors or symbols are applied to features to indicate their attributes. For example, a Counties theme can be drawn using colors with different hues that map directly with the population density of each county, or an Earthquakes theme can be plotted with filled circles whose sizes map to the scale or damage of each earthquake.
To achieve thematic mapping, specify advanced styles in the styling rules associated with a theme. You must specify attribute columns in the table or view whose values will be used to determine exactly how a feature will be rendered thematically. Example 2-4 is the XML definition for an Earthquakes theme.
<?xml version="1.0" standalone="yes"?> <styling_rules theme_type="nature"> <rule column="RICHTER_SCALE"> <features style="v.earthquakes"> </features> </rule> </styling_rules>
The theme in Example 2-4 has only one rule. The <rule> element includes an attribute named column that does not appear in the Airport theme in Example 2-1. The column attribute specifies one or more columns (comma-separated) that provide the attribute values needed for thematic mapping. The style specified for the features element is named v.earthquakes, and it is an advanced style.
Another part of the definition of the Earthquakes theme specifies the table that contains the data to be rendered. This table must contain a column named RICHTER_SCALE in addition to a column (of type SDO_GEOMETRY) for the spatial data. (The table and the column of type SDO_GEOMETRY must be identified in the BASE_TABLE and GEOMETRY_COLUMN columns, respectively, of the USER_SDO_THEMES view, which is described in Section 2.5.2.) The RICHTER_SCALE column must be of type NUMBER. To understand why, look at the advanced style definition in Example 2-5.
<?xml version="1.0" ?> <AdvancedStyle> <VariableMarkerStyle basemarker="m.circle" startsize="7" increment="4" > <Buckets> <RangedBucket seq="0" label="less than 4" high="4" /> <RangedBucket seq="1" label="4 - 5" low="4" high="5" /> <RangedBucket seq="2" label="5 - 6" low="5" high="6" /> <RangedBucket seq="3" label="6 - 7" low="6" high="7" /> <RangedBucket seq="4" label="7 and up" low="7" /> </Buckets> </VariableMarkerStyle> </AdvancedStyle>
This style specifies that the marker named m.circle is used to indicate the location of an earthquake. The size of the marker to be rendered for an earthquake depends on the numeric value of the RICHTER_SCALE column for that row. In this example there are five buckets, each covering a predetermined range of values. For example, if an earthquake is of magnitude 5.7 on the Richter scale, the marker size will be 15 pixels (7 + 4 + 4), because the value 5.7 falls in the third bucket (5 - 6) and the starting marker size is 7 pixels (startsize="7") with an increment of 4 for each range (increment="4").
Example 2-5 used the <VariableMarkerStyle> tag. The following examples use the <ColorSchemeStyle> tag in creating thematic maps of census blocks in California. Example 2-6 illustrates the use of a graduated color scale for a thematic mapping of population density. Example 2-7 is a thematic mapping of average household income using a graduated color scale. Example 2-8 is also a thematic mapping of average household income, but it uses a specific color style for each income range rather a graduated scale.
# ca pop density usbg_hhinfo <?xml version="1.0" standalone="yes"?> <styling_rules theme_type="political"> <rule column="densitycy"> <features style="v.CA Pop density"> </features> </rule> </styling_rules>
The table named USBG_HHINFO includes columns named DENSITYCY (used in Example 2-6). The definition of the style (v.CA Pop density) that corresponds to this population density theme is as follows:
<?xml version="1.0" ?> <AdvancedStyle> <ColorSchemeStyle basecolor="#ffff00" strokecolor="#00aaaa"> <Buckets low="0.0" high="20000.0" nbuckets="10" /> </ColorSchemeStyle> </AdvancedStyle>
The base color (basecolor) and the stroke color (strokecolor) are 24-bit RGB (red-green-blue) values specified using a hexadecimal notation. The base color value is used for the first bucket. The color value for each subsequent bucket is obtained by first converting the base color from the RGB to the HSB (hue-saturation-brightness) model and then reducing the brightness by a fixed increment for each bucket. Thus, the first bucket is the brightest and the last is the darkest.
As in Example 2-6, Example 2-7 illustrates the use of a base color and a graduated color scheme, this time to show household income.
<?xml version="1.0" standalone="yes"?> <!-- # ca hh income theme table = usbg_hhinfo --> <styling_rules> <rule column="avghhicy"> <features style="v.ca income"> </features> </rule> </styling_rules>
The table named USBG_HHINFO includes a column named AVGHHICY (used in Example 2-7 and Example 2-8). The definition of the style (v.ca income) that corresponds to this average household income theme is as follows:
<?xml version="1.0" ?> <AdvancedStyle> <ColorSchemeStyle basecolor="#ffff00" strokecolor="#00aaaa" > <!-- # income range with a color gradient --> <Buckets> <RangedBucket seq="0" label="less than 10k" high="10000" /> <RangedBucket seq="1" label="10-15k" low="10000" high="15000" /> <RangedBucket seq="2" label="15-20k" low="15000" high="20000" /> <RangedBucket seq="3" label="20-25k" low="20000" high="25000" /> <RangedBucket seq="4" label="25-35k" low="25000" high="35000" /> <RangedBucket seq="5" label="35-50k" low="35000" high="50000" /> <RangedBucket seq="6" label="50-75k" low="50000" high="75000" /> <RangedBucket seq="7" label="75-100k" low="75000" high="100000" /> <RangedBucket seq="8" label="100-125k" low="100000" high="125000" /> <RangedBucket seq="9" label="125-150k" low="125000" high="150000" /> <RangedBucket seq="10" label="150-250k" low="150000" high="250000" /> <RangedBucket seq="11" label="250-500k" low="250000" high="500000" /> <RangedBucket seq="12" label="500k and up" low="500000" /> </Buckets> </ColorSchemeStyle> </AdvancedStyle>
For individual range-based buckets, the lower-bound value is inclusive, while the upper-bound value is exclusive (except for the range that has values greater than any value in the other ranges; its upper-bound value is inclusive). No range is allowed to have a range of values that overlaps values in other ranges.
Example 2-8 uses specific color styles for each average household income range.
<?xml version="1.0" standalone="yes"?> <!-- # ca hh income theme table = usbg_hhinfo --> <styling_rules> <rule column="avghhicy"> <features style="v.ca income 2"> </features> </rule> </styling_rules>
The definition of the v.ca income 2 style is as follows:
<?xml version="1.0" ?> <AdvancedStyle> <BucketStyle> <Buckets> <!-- # income ranges with specific colors --> <RangedBucket seq="0" label="less than 10k" high="10000" style="c.rb13_1" /> <RangedBucket seq="1" label="10-15k" low="10000" high="15000" style="c.rb13_2"/> <RangedBucket seq="2" label="15-20k" low="15000" high="20000" style="c.rb13_3"/> <RangedBucket seq="3" label="20-25k" low="20000" high="25000" style="c.rb13_4"/> <RangedBucket seq="4" label="25-35k" low="25000" high="35000" style="c.rb13_5"/> <RangedBucket seq="5" label="35-50k" low="35000" high="50000" style="c.rb13_6"/> <RangedBucket seq="6" label="50-75k" low="50000" high="75000" style="c.rb13_7"/> <RangedBucket seq="7" label="75-100k" low="75000" high="100000" style="c.rb13_8"/> <RangedBucket seq="8" label="100-125k" low="100000" high="125000" style="c.rb13_9"/> <RangedBucket seq="9" label="125-150k" low="125000" high="150000" style="c.rb13_10"/> <RangedBucket seq="10" label="150-250k" low="150000" high="250000" style="c.rb13_11"/> <RangedBucket seq="11" label="250-350k" low="250000" high="350000" style="c.rb13_12"/> <RangedBucket seq="12" label="350k and up" low="350000" style="c.rb13_13"/> </Buckets> </BucketStyle> </AdvancedStyle>
Each <RangedBucket> definition has a specified style.
The following examples create an advanced style to identify gasoline stations operated by different oil companies, and a theme that uses the style. A <CollectionBucket> tag is used to associate a column value (Shell; Esso; Texaco; BP; any of Avia, Benzinex, Q8, Total, Witte Pomp; and all others for a default category) with a style appropriate for that company's stations, as shown in Example 2-9.
<?xml version="1.0" ?> <AdvancedStyle> <BucketStyle> <Buckets> <CollectionBucket seq="0" label="Shell" style="m.shell gasstation"> Shell </CollectionBucket> <CollectionBucket seq="1" label="Esso" style="m.esso gasstation"> Esso </CollectionBucket> <CollectionBucket seq="2" label="Texaco" style="m.texaco gasstation"> Texaco </CollectionBucket> <CollectionBucket seq="3" label="BP" style="m.bp gasstation"> BP </CollectionBucket> <CollectionBucket seq="4" label="Other" style="m.generic gasstation"> Avia,Benzinex,Q8,Total,Witte Pomp </CollectionBucket> <CollectionBucket seq="5" label="DEFAULT" style="m.default gasstation"> #DEFAULT# </CollectionBucket> </Buckets> </BucketStyle> </AdvancedStyle>
Notes on Example 2-9:
m.esso gasstation, m.texaco gasstation, and the other style names have a space between the words in their names.
t.Street and T.STREET are considered the same name.
#DEFAULT# as its value. This bucket is used for any column values (gas station names) that are not specified in the other buckets.
A theme (theme_gasstation) is then defined that specifies the column (MERK) in the table that contains company names. The styling rules of the theme are shown in Example 2-10.
<?xml version="1.0" standalone="yes"?> <styling_rules> <rule column="merk"> <features style="v.gasstations"> </features> <label column="merk" style="t.SansSerif red 10"> 1 </label> </rule> </styling_rules>
This theme depends on a table named NED_GASSTATIONS, which has the columns shown in Table 2-2 (with column names reflecting the fact that the developer's language is Dutch).
In this table, the GEOM column contains spatial geometries, and the MERK column contains company names (Shell, Esso, and so on).
The styling rules for the theme_gasstation theme specify that the marker (style v.gasstations) at a location specified by the content of the GEOM column is determined by the value of the MERK column for that row. The style v.gasstations (see Example 2-9) specifies that if the column value is Shell, use the style m.shell gasstation; if the column value is Esso, use the style m.esso gasstation; and so on, including if the column value is any one of Avia, Benzinex, Q8, Total, and Witte Pomp, use the style m.generic gasstation; and if the column value is none of the preceding, use the style m.default gasstation.
An image theme is a special kind of MapViewer theme useful for visualizing geographically referenced imagery (raster) data, such as from remote sensing and aerial photography.
You can define an image theme dynamically or permanently (as a predefined theme) in the database. You can use image themes with vector (non-image) themes in a map. Figure 2-1 shows a map in which an image theme (showing an aerial photograph of part of the city of Boston) is overlaid with themes showing several kinds of roadways in the city.
Before you can define an image theme, you must follow these rules in organizing your image data:
Each geometry in the MBR column contains the geographic bounds for an image, not its size in the pixel space. For example, if an orthophoto image is 2000 by 2000 pixels in size, but covers a ground rectangle starting at the corner of (936000, 248000) and having a width and height of 8000 meters, the MBR for the geometry column should be populated with (936000, 248000, 944000, 256000).
To predefine an image theme, follow the guidelines in Section 2.3.4.1. To define a dynamic image theme in a map request, follow the guidelines for defining a JDBC theme, as explained in Section 2.3.2 and Section 3.2.7, but note the following additional considerations with dynamic image themes:
imagescaling="false" in the map request.
For any image theme definition, note the following considerations:
oracle.sdovis.CustomImageRenderer interface in Java, and then register your implementation class in the mapViewerConfig.xml file (to tell MapViewer which custom image renderer to use for image data in a specific format). For detailed information about implementing and registering a custom image renderer, see Appendix B.
For an example of a map request specifying an image theme, including an explanation of how MapViewer processes the request, see Example 3-5 in Section 3.1.5.
To permanently store the definition of an image theme, you must insert a row into the USER_SDO_THEMES view. Example 2-11 stores the definition of an image theme.
INSERT INTO user_sdo_themes VALUES ( 'IMAGE_LEVEL_2', 'Orthophotos at pyramid level 2', 'IMAGES', 'IMAGE_MBR', '<?xml version="1.0" standalone="yes"?> <styling_rules theme_type="image" image_column="image" image_format="JPEG" image_resolution="2" image_unit="M"> <rule > <features style="C.RED"> plevel=2 </features> </rule> </styling_rules>' );
Example 2-11 creates an image theme named IMAGE_LEVEL_2. The base table (where all image data and associated MBRs are stored) is named IMAGES, and the MBRs for the images are stored in the column named IMAGE_MBR. In the STYLING_RULES column of the USER_SDO_THEMES view, an XML document with one <styling_rules> element is inserted.
The <styling_rules> element for an image theme has the following attributes:
theme_type must be image in order for this theme to be recognized as an image theme.
image_column specifies the column in the base table or view that stores the actual image data.
image_format is a string identifying the format of the image data. If you specify GIF or JPEG, MapViewer can always render the image data. If you specify any other value, such as ECW, you must have implemented a custom image renderer and registered it to MapViewer in order for the image to be rendered properly. For information about implementing a custom image renderer, see Appendix B.
image_resolution is an optional attribute that identifies the original image resolution (number of image_unit units for each pixel).
image_unit is an optional attribute, except it is required if you specify the image_resolution attribute. The image_unit attribute specifies the unit of the resolution, such as M for meter. The value for this attribute must be one of the values in the SDO_UNIT column of the MDSYS.SDO_DIST_UNITS table. In Example 2-11, the image resolution is 2 meters per pixel.
A map can consist of a combination of elements and attributes, such as the following:
These elements and attributes, when specified in a map request, define the content and appearance of the generated map. Chapter 3 contains detailed information about the available elements and attributes for a map request.
A map can have a base map and a stack of themes rendered on top of each other in a window. A map has an associated coordinate system that all themes in the map must share. For example, if the map coordinate system is 8307 (for Longitude / Latitude (WGS 84), the most common system used for GPS devices), all themes in the map must have geometries defined using that coordinate system.
You can add themes to a map by specifying a base map name or by using the programming interface to add themes. The order in which the themes are added determines the order in which they are rendered, with the last specified theme on top, so be sure you know which themes you want in the background and foreground.
All base map names and definitions for a database user are stored in that user's USER_SDO_MAPS view, which is described in Section 2.5 and Section 2.5.1. The DEFINITION column in the USER_SDO_MAPS view contains an XML description of a base map.
Example 2-12 shows a base map definition.
<?xml version="1.0" ?> <map_definition> <theme name="theme_us_states" min_scale="10" max_scale="0" /> <theme name="theme_us_parks" min_scale="5" max_scale="0" /> <theme name="theme_us_highways" min_scale="5" max_scale="0" /> <theme name="theme_us_streets" min_scale="0.05" max_scale="0" /> </map_definition>
Each theme in a base map can be associated with a visible scale range within which it is displayed. In Example 2-12, the theme named theme_us_streets is not displayed unless the map request is for a map scale of 0.05 or less and greater than 0 (in this case, a scale showing a great deal of detail). If the min_scale and max_scale attributes are not specified, the theme is displayed whenever the base map is displayed. (For more information about map scale, see Section 2.4.1.)
The display order of themes in a base map is the same as their order in the base map definition. In Example 2-12, the theme_us_states theme is rendered first, then theme_us_parks, then theme_us_highways, and finally (if the map scale is within all specified ranges) theme_us_streets.
Map size is the height of the map in units of the map data space. For example, if the map data is in WGS 84 geographic coordinates, the map center is (-120.5, 36.5), and the size is 2, then the height of the map is 2 decimal degrees, the lower Y (Latitude) value is 35.5 degrees, and the upper Y value is 37.5 decimal degrees.
Map scale is expressed as units in the user's data space that are represented by 1 inch on the screen or device. Map scale for MapViewer is actually the denominator value in a popular method of representing map scale as 1/n, where:
For example:
The min_scale and max_scale attributes in a <theme> element describe the visible scale range of a theme. These attributes control whether or not a theme is displayed, depending on the current map scale. The default scale value for min_scale is positive infinity, and the default value for max_scale is negative infinity (or in other words, by default display the theme for all map scales, if possible given the display characteristics).
min_scale is the value to which the display must be zoomed in for the theme to be displayed. For example, if parks have a min_scale value of 5 and if the current map scale value is 5 or less but greater than the max_scale value, parks will be included in the display; however, if the display is zoomed out so that the map scale value is greater than 5, parks will not be included in the display.
max_scale is the value beyond which the display must be zoomed in for the theme not to be displayed. For example, if counties have a max_scale value of 3 and if the current map scale value is 3 or less, counties will not be included in the display; however, if the display is zoomed out so that the map scale value is greater than 3, counties will be included in the display.
A high min_scale value is associated with less map detail and a smaller scale in cartographic terms, while a high max_scale value is associated with greater map detail and a larger scale in cartographic terms. (Note that the MapViewer meaning of map scale is different from the popular meaning of cartographic map scale.) The min_scale value for a theme should be larger than the max_scale value. Example 2-12 in Section 2.4 includes min_scale and max_scale values.
To determine the current map scale for a map returned by MapViewer, first find the map size, namely the height (vertical span) of the map in terms of the coordinate system associated with the map data. For example, assume that a map with a height of 10 (miles, meters, decimal degrees, or whatever unit of measurement is associated with the data) is requested, and that the map is drawn on a device with a size of 500 by 350 pixels, where 350 is the height. MapViewer assumes a typical screen resolution of 72 dpi. Because 72 pixels equals 1 inch, the height of the returned map is 4.86 inches (350/72 = 4.86). In this example, the size of the map is 10, and therefore the map scale is approximately 2.057 (10/4.86 = 2.057).
A map legend is an inset illustration drawn on top of the map and describing what various colors, symbols, lines, patterns, and so on represent. You have flexibility in specifying the content and appearance of the legend. You can:
Example 2-13 is an excerpt from a request that includes a legend.
<?xml version="1.0" standalone="yes"?> <map_request basemap="density_map" datasource = "mvdemo"> <center size="1.5"> ... </center> <legend bgstyle="fill:#ffffff;fill-opacity:128;stroke:#ff0000" position="NORTH_WEST"> <column> <entry text="Map Legend" is_title="true" /> <entry style="M.STAR" text="center point" /> <entry style="M.CITY HALL 3" text="cities" /> <entry is_separator="true" /> <entry style="C.ROSY BROWN STROKE" text="state boundary" /> <entry style="L.PH" text="interstate highway" /> <entry text="County population:" /> <entry style="V.COUNTY_POP_DENSITY" tab="1" /> </column> </legend> <themes> ... </themes> </map_request>
Figure 2-2 shows a map with the legend specified in Example 2-13.
Notes on Example 2-13 and Figure 2-2:
is_title="true"), a style name and associated text, or a separator (is_separator="true") for vertical blank space to be added (after the cities entry in this example).
For detailed information about adding a legend to a map request, see Section 3.2.10.
If you also specify a map title, note, or logo (or any combination), be sure that the legend and the other features have different positions. (Map titles, notes, and logos are explained in Section 1.5.5.) The default position for a legend is SOUTH_WEST.
A map specified in the XML map request includes a data source name, an optional base map name, and an optional array of theme descriptors for a set of predefined and dynamic themes. If a base map name is specified, the description of that base map (that is, the theme names, their display order, and their scale ranges) is determined by reading the DEFINITION column value associated with that base map in the ALL_SDO_MAPS view (described in Section 2.5.1). That is, MapViewer performs the following query from the user-specified data source:
SELECT DEFINITION FROM ALL_SDO_MAPS WHERE NAME=:basemap AND OWNER=:username;
The mapping metadata describing base maps, themes, and styles is stored in the global tables SDO_MAPS_TABLE, SDO_THEMES_TABLE, and SDO_STYLES_TABLE, which are owned by MDSYS. However, you should never directly update these tables. Each MapViewer user has the following views available in the schema associated with that user:
You are encouraged to use the Map Definition Tool (described in Chapter 7) to manage the mapping metadata. Only advanced users should consider using SQL statements to update the MapViewer metadata views.
Note:
The USER_SDO_xxx views contain metadata information about mapping elements (styles, themes, base maps) owned by the user (schema), and the ALL_SDO_xxx views contain metadata information about mapping elements on which the user has SELECT permission.
The ALL_SDO_xxx views include an OWNER column that identifies the schema of the owner of the object. The USER_SDO_xxx views do not include an OWNER column.
All styles defined in the database can be referenced by any user to define that user's themes, markers with a text style, or advanced styles. However, themes and base maps are not shared among users; so, for example, you cannot reference another user's themes in a base map that you create.
The following rules apply for accessing the mapping metadata:
The MapViewer metadata views are defined in the following file:
$ORACLE_HOME/lbs/admin/mapdefinition.sql
The following sections describe each set of views.
The USER_SDO_MAPS and ALL_SDO_MAPS views have the columns listed in Table 2-3.
The USER_SDO_THEMES and ALL_SDO_THEMES views have the columns listed in Table 2-4.
The USER_SDO_STYLES and ALL_SDO_STYLES views have the columns listed in Table 2-5.
|
 Copyright © 2001, 2003 Oracle Corporation. All Rights Reserved. |
|