• Поддержка 10g Topology и сетевых моделей данных

• Прозрачная поддержка JPEG и формата PNG

• Поддержка спецификации Web Map Server 1.1.1 консорциума Open Geospatial Consortium

• Поддержка Workspace Manager

• Динамическое преобразование системы координат в запросе на карту

• Поддержка карт SVG

• Источник данных контейнера как источник данных карты

• Усовершенствования стиля

• Временные стили в запросе карты

• Опция ограничения тем для ограничения объема отображенных данных

• Высокая готовность и MapViewer

Примечание 1: [Информацию о том, как установить и развернуть MapViewer и добавить источник данных, можно найти в MapViewerUser’s Guide ( “Руководстве пользователя по MapViewer”)]

Все стили хранятся в таблице пользователя системы MDSYS, но доступны каждому пользователю через его собственное представление USER_SDO_STYLES.

Любая географическая характеристика, типа дороги, может быть отображена по-другому, если для этого будут назначены или применены дополнительные стили, даже притом, что основная геометрическая структура самой характеристики идентична. Рисунок 2 служит примером одной и той же дороги, формируемой с использованием трех различных типов линий.

Рисунок 2. Одинаковая геометрия, различные типы линии

Отметьте, что представления XML для каждого типа стиля являются собственностью Oracle, но эти определения стиля определены в “Руководстве пользователя MapViewer”. В будущем, по мере того как будет разрабатываться и “взрослеть” стандарт для такого рода информации (изображений), MapViewer также присоединится к его поддержке.

Каждое правило моделирования кодируется в XML в соответствии с приведенными ниже соглашениями. В приводимом ниже примере правило является частью темы, названной theme_us_airports, базовая таблица которой содержит данные об аэропорте и имеет, например, такие столбцы, как GEOM, NAME и RUNWAY_NUMBER.

<rule>
<features style="c.black gray">
runway_number &gt; 1
</features>
<label column="name" style="t.airport name">
1
</label>
</rule>

В этом правиле, как и в каждом из правил моделирования, есть две части: <features> и <label>. Элемент <features> сообщает MapViewer, какие строки должны быть выбраны, и какой стиль следует использовать при формировании из этих строк геометрических форм. Для определения строк можно использовать, как значение элемента <features>, любую допустимую фразу WHERE (без самого ключевого слова WHERE). В этом случае будут выбраны все строки, удовлетворяющие условию SQL “runway_number> 1”, и для изображения геометрии аэропорта для этих строк будет использован стиль цвета c.black gray.

Отметьте, что из-за ограничений XML символ ‘>’ в соответствии с синтаксисом XML представлен как ‘&gt;’. Во время выполнения это представление будет преобразовано MapViewer обратно в символ ‘>’, чтобы можно было сформулировать надлежащий запрос SQL.

Вторая часть предшествующего правила моделирования – это (дополнительный) элемент <label>, который может принимать два значения: 0 или 1. Когда значение этого элемента есть 1, MapViewer попытается при генерации карты помечать аэропорты. Текст метки будет получаться из столбца 9 NAME, а стиль текста будет t.airport name. Заметьте, что если задание метки не является необходимым, вы можете опустить элемент <label> или указать для него значение 0.

Также заметьте, что при ссылке на характеристику или метку стиля имя стиля может принять форму <user>:<style_name>, например, MDSYS:t.airport name. Такое имя заставляет MapViewer применить названный стиль из схемы указанного пользователя, в нашем случае, пользователя MDSYS. Таким образом, в составе стандартной пользовательской схемы (например, MyOrgSchema) можно определить все основные символы карты организации, и добиться того, чтобы все другие пользователи пользовались ей совместно, не записывая один и тот же набор символов карты по много раз.

Список SELECT будет иметь тот же самый порядок и те же типы данных для каждого правила моделирования, и вследствие этого может быть объединен с использованием UNION ALL, если для темы имеется несколько правил моделирования. Несколько правил моделирования требуются, например, в тех случаях, когда различные наборы строк для темы выбираются на основании различных условий, и каждый набор строк имеет свои собственные стили формирования и маркирования изображения. Например, если в таблице хранятся геометрические формы для автомагистралей между штатами, государственных дорог, городских улиц и улиц пригородных поселков, в запросе к MapViewer можно указать, что каждый из этих типов дорог на карте должен быть представлен по-разному. В этом случае должно иметься четыре набора правил моделирования, на которые будут делаться ссылки.

В этом случае определяется динамическая тема, названная sales_by_region. Запрос, который выбирает строки/характеристики для этой темы, имеет вид SELECT REGION, MANAGER FROM FOO_SALES_2001. Имена стилей характеристики метки определены как атрибуты render_style и label_style, соответственно. Заметьте, что информация подключения базы данных перечислена явно, как часть определения темы.

Кроме того, хотя фактические данные для темы могут быть получены из различных баз данных (как указано в информации подключения базы данных), стили, на которые ссылаются, будут всегда извлекаться из источника данных, указанного в полном запросе карты.

После того как эта тема была определена, ее можно использовать, как любую другую предварительно определенную тему. На рисунке 4 показано сформированное изображение, в котором каждая область округа представлена цветом, отражающим значение плотности населения, приписанное этому округу.

Рисунок 4. Простая тематическая карта

При условии что столбец (или столбцы) атрибута, требующийся для расширенного стиля, будет определен в списке SELECT запроса темы, расширенные стили могут быть также использованы и с динамическими темами. Например:

<theme_name="sales_by_region_2">
<jdbc_query spatial_column="region"
datasource="mvdemo"
label_column="manager"
render_style="V.SALES COLORS"
label_style="T.SMALL TEXT"
>
SELECT region, manager, sales_2003 FROM foo_sales_2003
</jdbc_query>

В предыдущем примере для расширенного стиля необходим столбец атрибута SALES_2003, и он включен в список SELECT запроса темы.

• Если запрос карты ссылается на имя основной карты, упомянутая основная карта должна быть определена в метаданных для построения карты представления USER_SDO_MAPS. Для каждого пользователя базы данных должно быть определено это представление, так как в нем должны храниться все предварительно определенные основные карты этого пользователя. Основная карта, по сути дела, определяет, какие предварительно определенные темы должны быть сформированы, и в каком порядке.
• Для всех предварительно определенных тем основной карты, а также для тех предварительно определенных тем, на которые явно ссылаются в запросе карты, в представлении пользователя USER_SDO_THEMES должны иметься соответствующие определения тем.
• Для всех стилей, на которые ссылаются изо всех тем (как предварительно определенных, так и динамических), в представлении пользователя USER_SDO_STYLES должно иметься соответствующее определение стиля. Или, в том случае, если на имя стиля ссылаются в форме <пользователь>:<имя>, использованный стиль должен существовать в представлении USER_SDO_STYLES для указанного пользователя.

Если все перечисленные выше условия выполнены, MapViewer формирует все темы, которые неявно или явно определены в запросе карты. Этот технологический процесс состоит из следующих шагов:

1. MapViewer создает пустое изображение и заполняет его в соответствии с размером и цветом фона, определенными в запросе карты.
2. На пустое изображение накладываются все темы, являющиеся частью основной карты (если она указана в запросе карты). Темы формируются в том порядке, в котором они перечислены в определении основной карты. В частности, все темы изображения будут всегда сформированы до формирования любых векторных (обычных) тем.
3. Перед формированием темы MapViewer, базируясь на правилах моделирования темы, формулирует SQL-оператор запроса. Затем он выполняет запрос и выбирает данные для этой темы из базы данных. Этот процесс известен как “подготовка темы”, которую необходимо сформировать. Для сокращения числа повторных выборок геометрических данных будет использоваться внутренний кэш геометрических объектов. Кроме того, как часть подготовки темы, подтверждаются все стили, на которые ссылаются в теме, и если они еще не во внутреннем кэше стилей, они (стили) будут выбраны из источника данных.
4. Любые явно указанные темы (будь то предварительно определенные или динамические) в запросе карты подготавливаются и формируются поверх того же самого изображения согласно порядку, в котором они перечислены в запросе.
5. Если есть какие-то индивидуальные геохарактеристики (GeoFeatures), перечисленные в запросе карты, они наносятся поверх изображения.
6. Для тем, имеющих характеристики, которые нужно снабдить метками, имеет место процесс аннотации. MapViewer автоматически обнаруживает все коллизии меток и определяет оптимальное положение для каждого текста метки (если имеется место для его размещения). Темы помечаются в том же самом порядке, как они были сформированы.
7. Если затребованы заголовки карты, сноски, легенды, логотип карты и другие опции, они выводятся на карту.

Как только карта сформирована, MapViewer проверяет запрос карты, чтобы увидеть, какой формат изображения был затребован клиентом. Он преобразовывает внутреннее “сырое” (raw) изображение в требующийся формат и, или сохраняет его в локальной файловой системе, или посылает его назад (непосредственно клиенту) в двоичной форме.

Начиная с выпуска 9.0.4 MapViewer, API XML встроен в API Java, чтобы разработчики Java-приложений могли легко использовать новый API, вместо того чтобы управлять непосредственно XML-запросами карты.

Информацию об API XML и Java можно найти в MapViewer User’s Guide (“Руководстве пользователя MapViewer”).