Вероятно, да! Далеко зашел в описании. От ИнГЕО хочется полную аналогию с топологическими связями, но не требующие точного геометрического совпадения в точке. Создать, увидеть, удалить концептуальную связь. И доступ к концептальным связям и отношениям в API. Всё остальное - работа внешних модулей.

А кроме порядка надо бы ещё:

1. Для каких карт/слоёв/стилей видимость включена/выключена.

2. Используемые в данный момент ФИЛЬТРЫ (меню Вид -> Параметры отображения).

3. Настройки области видимости

4. Для каких из видимых растровых карт включена/выключена видимость сетки

5. Для каких ячеек растра выключена видимость.

6. Включена или выключена видимость вершин, размеры крестиков (они попадают на печать и в создаваемый растр).
Если небыло изменений в метаданных, привилегиях и геометрических объектах, используется прежний проект и под прежним пользователем, есть все нужные шрифты, тогда можно утверждать что изображение будет идентично прежнему, сделанному данным макетом.

Различие в принтерах, уровне чернил, операционных систем, верий GDIplus и настроек ИнГЕО тоже можно принять в расчёт.

Поддерживаю. Очень давно нужный функционал. Как бы это могло выглядеть:

При создании макета, создаётся дополнительный файл настроек, который содержит всё вышеперечисленное. При открытии макета печати, пользователь информируется, что при последнем сохранении данного макета печати были вот такие настройки. У оператора есть выбор: или позволить изменить текущие настройки на ранее сохранённые (все/выборочно) или продолжить работу с нынишними настройками.

Я сильно извиняюсь, но таки я ничего не понял. Нельзя ли ещё раз, специально для меня. Может оно мне надо.

Уже сейчас есть пара решений:

1. Откопайте у себя CD с ИнГЕО. Тот, который вам выслали из Уфы.

Там должен быть каталог "Исходные тексты модулей расширения".

Но если Вы купили ИнГЕО в этом году, тогда такого каталога можете и не найти.

Тогда переходим к пункту 2.

2. На сайте http://www.integro.ru/dl/ingeo/examples/index.htm есть исходники.

Конечно они не свежие, не соответствуют последним релизам самих модулей.

Но и без этого там много всего интересного.

Я бы рад не трогать названия полей, но иногда импорт подкидывает такие названия, с которыми в Oracle и ИнГЕО работать неудобно.

1. Поля на русском языке

2. Поля с чередованием строчных и прописных букв

3. Длинные поля, приближающиеся к ограничению Oracle на длину (30 символов).

ИнГЕО (пока) отображает названия таблиц и полей в верхнем регистре. Подглянув в ИнГЕО, не сразу можно собрать правильное SQL-предложение.

4. При формировании индекса по указанному полю, ИнГЕО формирует имя ограничения добавляя к названию поля суфиксы "_PK" или "_I1". Раньше были проблемы с превышением ограничения в 30 символов, сейчас не пробовал.

Что если завтра, разработчики внесут изменения в алгоритм импорта и в этот момент имена полей и таблиц будут преобразовываться под предпочтения текущей СУБД. Для Oracle все поля на английском в верхнем регистре. Тогда обновление модулей сторонних разработчиков (разрабатывающих под MS-SQL или PARADOX) не смогут идентифицировать собственные поля и таблицы.

Мне не дано воспользоваться не тривиальным способом. Для меня все версии ИнГЕО (177, 4.4.338) размыкают контур одним способом - рвут связь между первой и последней, без вариантов.

Ещё и не всегда данный функционал срабатывает. Пытаешься, а он не рвет и всё тут.

У вас это СЕЙЧАС получается?

Увы показывается. Физическое имя поля показывается пользователям:

1. Меню Анализ -> Запрос по семантическим данным.

2. Импорт dxf. Может и другие импорты.

Порядковый номер поля предлагаю позволить пользователям и через API менять.

Добавлять поля только в конец списка - редко требуется. Заодно необходимо переставить их по смыслу в нужное место.

Может имеет смысл говорить о разных номерах: порядковый номер в СУБД и порядковый номер в ИнГЕО. Порядковый номер в СУБД пользователю будет неважен (ему будет доступен помер в ИнГЕО), следовательно номер в СУБД может использоваться в тех местах, где можно было использовать ID.

Упс. Если поля добавляют в разных базах, что произойдёт при слиянии?

ID эту ситуацию легко разрулит, для этого он и придуман.

Предложенный вариант условно можно назвать решением и вот по чему:

Работа со справочниками в ИнГЕО:

1. Отобразить значение из справочника

2. Выбрать значение из справочника

3. Редактировать справочник

4. Экспорт/импорт справочника

Если использовать View, тогда функции 3 и 4 будут давать сбой.

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

А сторонние разработчики как узнают - что справочник не таблица а вьюшка? Вдруг их продукт предполагает дополнять справочник?

Думаю что View не следует сбрасывать со счетов, но оптимальнее чтобы это реализовывалось из ИнГЕО и сопросождалось во всех новых версиях.

Изначально речь шла о квадратных метрах или гектарах, метрах или милиметрах. По сути это изменение единиц измерения. Если завтра ИнГЕО захочет выйти на мировой рынок, то придётся думать о дюймах, футах, ярдах, милях и акрах.

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

Я голосую за первый вариант!

Обращаю Ваше внимание, что Интегро уже реализовало работу с двумя вычисляемыми значениями (специально не пишу поля - это епархия СУБД), а именно: периметр {.Perimetr} и площадь {.Square}. Предлагаю увеличить количество вычисляемых значений до безобразия: количество форм, количество форм(указанного стиля), наличие форм определяющих геометрию объекта, не определяющих геометрию объекта, площадь форм(указанного стиля), количество вершин(указанной формы по номеру), координата {Х|Y}(по номеру(по номеру формы)), количество рёбер, количество дуг, количество записей в таблице 1 ко многими(по имени) и т.д.. Вычисляемые значения удобно выводить в окно свойств или в набор объектов для быстрого выявления объектов без надписи, или без геометрии, без семантики или с чрезмерной семантикой.