Измененные области и работа с версиями наборов сетевых данных

Доступно с лицензией Network Analyst.

Редактировать исходные объекты набора сетевых данных, хранящегося в базе геоданных рабочей группы или корпоративной базе геоданных, могут одновременно несколько пользователей. Этот раздел и содержащиеся в нем схемы описывают, что происходит с измененными областями наборов сетевых данных при согласовании версий.

Есть несколько основных моментов, которые следует учитывать при работе с наборами сетевых данных в базах геоданных рабочих групп или корпоративных базах геоданных:

• Исходные объекты набора сетевых данных должны быть зарегистрированы как версионные, чтобы в них можно было вносить какие-либо изменения.

  Прежние версии:

  В версиях, предшествующих ArcGIS 10, наборы сетевых данных не могли быть версионными. Это значит, что исходные классы объектов могли редактироваться, как если бы они были простыми классами пространственных объектов. Это значит, что исходные классы объектов могли регистрироваться, как версионные, и редактироваться с возможностью отмены и повторения изменений, или же они могли оставаться неверсионными данными и редактироваться без возможности отмены и повторения изменений.

  Но начиная с выпуска ArcGIS 10 исходные объекты невозможно редактировать, не зарегистрировав их как версионные.

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

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

В целях полноты на схематической диаграмме в этом разделе показан весь процесс: от создания родительского и дочернего объектов до согласования и закрепления правок и построений. В действительности вы не всегда будете начинать с формирования родительской версии, так что любое действие, создающее дочернюю версию, можно считать моментом, когда существующие дочерняя и родительская версии находятся в одном и том же состоянии.

Хотя на рисунках показано закрепление построенного набора сетевых данных в родительской версии, вполне допустимо закрепление сети с измененными областями. Обратите внимание, что в таком случае предполагается, что набор сетевых данных будет впоследствии построен пользователем с правами доступа на редактирование родительской версии.

Следующая легенда поможет понять диаграммы:

Согласование и закрепление без правок исходных объектов

В этом разделе описывается, как измененные области ведут себя в различных вариантах работы с версиями, в том числе при изменении, построении, согласовании и закреплении наборов сетевых данных. Эти варианты исключают редактирование исходных объектов из процесса (редактирование описывается в следующем разделе). Ознакомившись с этим разделом, вы в общем поймете, какие рабочие процессы приводят к созданию построенных наборов сетевых данных без измененных областей.

Сценарий 1: измененные области введены и построены в родительской версии

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

Сценарий 2: измененные области введены в родительской версии и построены в дочерней версии

Этот сценарий подобен предыдущему в том, что дочерняя версия наследует измененную область у родительской версии. Но затем построение сети происходит в дочерней версии, а не в родительской. При согласовании после операции построения из родительской версии вносятся измененные области. Чтобы закрепить построенную сеть в родительской версии, необходимо перестроить дочернюю версию перед закреплением.

Сценарий 3: измененные области введены в родительской версии, построены и в дочерней, и в родительской версиях

В этом сценарии сочетаются два предыдущих сценария. Дочерняя версия, как и ранее, наследует измененные области у родительской версии. Построение дочерней и родительской версий перед согласованием производится по отдельности. Процесс согласования оставляет дочернюю версию в чистом состоянии.

Согласование и закрепление с правками исходных объектов

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

Сценарий 4: изменение различных исходных объектов в родительской и дочерней версиях

Но затем построение сети происходит в дочерней версии, а не в родительской. После создания дочерней версии класс исходных объектов улиц изменяется, при этом в южной части карты добавляются улицы. В то же время родительская версия редактируется – в ней улицы добавляются на северной стороне. Теперь в двух версиях имеются измененные области на разных сторонах карты. Процесс согласования переносит правки и связанные с ними измененные области в дочернюю версию. Таким образом строится сеть, которая может быть закреплена в родительской версии без измененных областей.

Более подробно:

Набор сетевых данных на схеме выше не был построен непосредственно перед согласованием ни в родительской, ни в дочерней версиях. Но если бы он был построен в это время в обеих версиях, при согласовании вновь возникла бы измененная область в южной части карты, как показано на рисунке ниже. Это происходит потому, что в процессе согласования состояние родительской версии становится видимым в дочерней версии, чтобы смогло произойти слияние. Так как правки дочерней версии являются новыми относительно родительской, связность этих правок должна быть перестроена с учетом согласованных данных родительской версии.

Сценарий 5: новые исходные объекты, пересекающиеся в родительской и дочерней версиях

Этот сценарий показывает еще одну причину, по которой после внесения правок в исходные объекты дочерней и родительской версий необходимо перестроение набора сетевых данных. В этом случае правки, вносимые в родительскую и дочернюю версии, пересекаются. Хотя в соответствующих версиях сеть очищена, при согласовании возникает измененная область, так как в ней необходимо определить связность пересекающихся объектов.