Oracle9i Application Server Wireless Edition Implementation Guide Release 1.1 Part Number A86699-01 |
|
This document describes the Region Modeling Tool. Each section of this document presents a different topic. These sections include:
The Wireless Edition enables you to create location-based services using the Region Modeling Tool. The Region Modeling Tool enables you to create services that are visible to Wireless Edition users at specific locations.
The Region Modeling Tool enables developers to create these location-based services by assigning a location to a folder or to a master service from the spatial data repository. The tool enables you to view a spacial object as a map image with its corresponding geometry. In addition, the tool enables you to access, view, and modify the data stored in the spatial database in the Wireless Edition repository.
The Region Modeling Tool presents spatial data as a set of regions, which are divided into system-defined regions (SDRs) and user-defined regions (UDRs).
The SDRs are administrative boundaries organized in a into hierarchy of subregions as follows:
The left frame of the Region Modeling tool presents the SDRs as a hierarchical directory organized by continent, country, state, county, and postal code nodes. Clicking one of these nodes displays its corresponding map and geometry (longitude/latitude) in the right frame, and its identifier (ID: 5055 in Figure 3-6, above), name, and description in the top frame.
In a typical SDR hierarchy, a continent node contains country nodes. Country nodes contain state nodes, and state nodes contain separate child folders for city, postal code, and county. If a country lacks states or provinces, then the country node has separate child folders for city, postal code, and county. If state data exists in any country, then all data for the postal code, city, or county must be contained in a state node.
Except for the continent region, which is at the top of the hierarchy, every item in the table of the hierarchy carries the region identifiers of its parent regions. For example, a county region carries the state identifier as well as the country identifier.
The following is a description of a region model data schema.
Table 4-1 The Region Model Data Schema
In addition to the SDRs, you can create your own regions, or user-defined regions (UDRs). These UDRs can be constructed in two ways:
For example, the Region Modeling Tool allows you to create a service that is available ten miles around a specific address. You can make an aggregate of areas, such as the New England states of Maine, New Hampshire, Vermont, Massachusetts, and Rhode Island.
Unlike the SDRs, the UDRs are not arranged into a hierarchy; however, users can organize their UDRs by creating folders.
There are two methods for accessing the Region Modeling Tool: you can access it in its Standalone mode through the Tools menu in the Service Designer, or in its browse mode when using the Service Designer to create a location-based master service or folder.
In the Standalone mode, you can create both UDRs and load data into SDRs. For more information on using the Region Modeling Tool in its Standalone mode, see Section 4.3, "Managing Spatial Objects".
When you access the Region Modeling Tool while creating a master service or folder, you access the tool in the browse mode. In the browse mode, you create location based services by assigning regions to services and folders. In addition, you can create UDRs and search for regions. For more information on using the Region Modeling Tool in its browse mode, see Section 4.4.
You use the Region Modeling Tool in its Standalone mode to view and manage regions.
To access the Region Modeling Tool in its Standalone mode:
You can create a UDR by selecting from the SDR hierarchy, or you can create a UDR from an address.
To create a UDR using the SDR hierarchy:
To create a UDR from an address:
To delete a UDR:
Note: You can only delete a region that has no services assigned to it. Regions with reference counts of 0 have no services assigned to them. |
The UDRs are not automatically arranged in a hierarchy. They can be made easily accessible through the creation of folders. To create a folder:
To delete a folder:
You create system-defined regions (SDRs) by loading spatial data into the Wireless Edition repository.
Note: The Wireless Edition repository contains a small set of built-in sample system-defined regions. |
The following sections describe two methods of loading data into the repository:
The following example of loading additional spatial data using SQL*Plus assumes that your data exists in a table and that the geometry is in the Oracle spatial format (MDSYS.SDO_GEOMETRY). An example of a table called mystate
of US data is as follows:
Name | Geometry | Description |
---|---|---|
Alabama |
{.........} |
... ... |
Alaska |
{.........} |
... ... |
California |
{.........} |
... ... |
Perform the following steps to load SDR data.
SELECT id, name, cont_id FROM Country;
...
5009 USA 5001
...
In this example, the country ID for USA is 5009, and the continent ID is 5001.
mystate
:
INSERT INTO state
(ID, CONT_ID, COUNTRY_ID, NAME, DESCRIPTION, GEOMETRY, REFCNT)
SELECT
idseq
.nextval, 5001, 5009, name, description, geometry, 0 from mystate;
Geometry data is assumed to be in WGS-84 format. If the geometry data is not in WGS-84 format, you need to transform it before loading using MDSYS.SDO_CS.TRANSFORM. The SRID for WGS-84 is 8307. For more information, refer to Oracle Spatial User's Guide and Reference.
Geometry data must be in Oracle 8.1.6 GTYPE or later. Otherwise, the user must migrate the data using SDO_MIGRATE.FROM_815_TO81X. For more information on GTYPE and the migration utility, refer to Oracle Spatial User's Guide and Reference.
To load SRD data from the Region Modeling Tool:
To add data under a continent:
rownum<11
as the WHERE clause.
Note: This is an optional step. If you do not specify a WHERE clause, the Region Modeling tool loads all rows from the specified table. |
To add data under a country:
rownum<11
as the WHERE clause.
Note: This is an optional step. If you do not specify a WHERE clause, the Region Modeling tool loads all rows from the specified table. |
To add data for the postal code, county, or city:
rownum<11
as the WHERE clause.
Note: This is an optional step. If you do not specify a WHERE clause, the Region Modeling tool loads all rows from the specified table. |
To delete an SDR:
You use the Region Modeling Tool in its browse mode when you make a service or a folder location-based by assigning a region. Folders and services created using the Region Modeling Tool are visibility location-based. Users access these services at specific locations.
In addition, you can use the Region Modeling Tool to create UDRs in the browse mode. For more information on creating UDRs, see Section 4.3.2.
You can access the Region Modeling Tool in its browse mode through the Service Designer or through the Master Service Creation Wizard.
In the Service Designer, you access the Region Modeling tool by selecting the Location Dependent check box in the either the General tab (used for modifying a folder or service in the Wireless Edition repository tree), or the Create New Services or the Create New Folders forms (invoked by right-clicking the Wireless Edition repository) and then by clicking the Browse button. For more information on modifying a folder or a master service, see Section 3.2.3, "Modifying Objects" in Chapter 3, "Wireless Edition Services".
In the Master Service Creation Wizard, you access the Region Modeling Tool by selecting the Browse button in the Creating New Folder and Setting Service Properties screens.
To assign a region to a folder or to a service from the Service Designer:
To create a location-based folder or service from the Service Designer:
To access the Region Modeling Tool from either the Create the Master Service Creation Wizard:
In addition to services that are visible only at certain locations, the Wireless Edition edition also supports location-based services that generate content specific to the current location of the Wireless Edition user. For example, a user located in San Francisco would receive content specific to the San Francisco area, such as a listing of restaurants or business located in San Francisco. These services are supported through customized adapter implementation and location-aware runtime support.
To create a content-specific location-dependent service, you must access the current subscriber's location through the Runtime API or through derived location-related system parameters.
From a customized Java adapter, access the subscriber's current location by using either of the following methods:
Request.getCurrentLocation() Session.getCurrentLocation()
Both of these methods return the geocoded physical location point. If there is no request-specific location information, the Runtime API returns the current location information, if any.
You can use derived location-related system parameters if you pass the location information to a built-in adapter, such as the WebIntegration adapter, or the SQL adapter. The supported derived location-related system parameters include:
Table 4-4 The Derived Location-Related System Parameters
To enable the passing of location information to the existing adapter, you must add the corresponding parameters to the service and make them mandatory. For example, if you wish to pass the postal code information of the current caller to the router service, you must add the _Postalcode parameter to the router service and make it mandatory. The Runtime fills in the value for the derived system parameters with the mandatory values that are missing.
|
Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|