Здесь можно сделать использование отдельных стилей для всех меток выше таксационной формулы и отдельно для таксационной формулы, программа задаёт числом номер стиля для метки, может задать разные. Тогда в проекте надо будет сделать стиль 1 для меток планшетов, и, например, стиль 11 для формулы плана.  Или требуется какое-то более сложное решение, зависимость от "Базового масштаба карт" в параметрах таксационной базы?

Выложена, пробуйте.

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

Если выводить только номера или что-то из базы блока для точек, то нужно проверять, есть ли эти поля в базе, то есть убедиться, проверит ли это сам TopoL или надо делать проверку нам в нашей части во избежание вывода ошибок.

Таксационная формула запрашивает данные из таксационной базы через модель связи баз данных, и тут уже получается гораздо сложнее. То есть надо сначала подключить к точкам повыдельную базу, построить модель связи, чтобы от точек эта база была видна, а значит точки должны в обязательном порядке иметь заполненные ключевые поля для связи - KvrNom и VydNom.
При закрытии блока таксационную базу надо отключать и модель удалять во избежание того, что после редактирования блока или таксации не возникло конфликтов несоответствия. При операциях перенумерации полигонов выделов надо как-то отслеживать эти изменения в точки. И это только то, что сходу пришло в голову, возможно, есть ещё какие-то "скрытые камни".

Дело не только в заморочности. Любое дублирование информации, любые параллельные связи - это утяжеление базы данных. А она и так уже слишком тяжелая и сократив "время работы оформителя" мы можем сделать базу неподъемной на объектах с большим числом выделов. Мне сейчас для работы в качестве лесоустроителя приходится отключать все что можно. Иначе после 20-й перерисовки подряд терпение на больших базах кончается.
Например, что касается дорог - ее тип есть в БД и взять его оттуда легко. Отдельный блок дорог - вещь нужная, но не для того, чтобы "увидеть тип", а для решения задач оптимизации вывозки... оценки себестоимости заготовок... их проектирования... планирования и осмечивания их ремонта... Но для этого отрасль еще не готова. Ни своей нормативной базой, ни уровнем "цифровизации", ни пониманием ее места в общей информационной структуре. Проще говоря - этого не будет пока все зиждется на периодическом лесоустройстве и оторванности конечных пользователей от БД.

И тем не менее, начинать нужно с этого. Я плохо понимаю, что ты хочешь, точнее - зачем. Объясни понятно как ты это хочешь использовать на простом примере. Прежде чем Д.А. начать думать над чем то, нам нужно четкое понимание для чего конкретно это потребуется и чем это будет обеспечено. По принципу - "мне нужна точка, привязанная к полигону (реке... дороге... смежеству...) для того, чтобы я мог сделать то-то и потому, что этому сейчас мешает то то... И только после этого мы можем напрягать Д.А. Примерно так.

Обязательно учтем, надеюсь в ближайшем обновлении.

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

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

Сергей, твою логику формирования полей я понимаю. Я то о другом. Для тебя есть разница двигать тексты или точки? Если предположим БД точек каким то образом создалась автоматом все равно захочешь тексты двигать?

Сергей, пожалуйста, конкретнее пиши, что не так со сдвигом точек? Я повторил то, что ты делал с текстами и с точками и существенной разницы не увидел. Исходя из этой информации мы будем решать, что менять - формирование текстовых полей... метод сдвига точек... или еще что.

Теперь понятно.

По большому счёту - первое, это частный случай второго, то есть VydNom или @VydNom. Составлять список полей БД, как делает TopoL - это потребует большого программного кода и зачем это дублировать, когда это есть в TopoL-е.

Как вы себе это представляете с точки зрения интерфейса? Появляется диалоговое окошко, где выпадающий список выражений, куда можно дополнить своё, и задаётся номер стиля текста? И для какой группы точек это будет устанавливаться?

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

Когда мы прорабатывали этот вопрос, было решено отказаться от переходных знаков и ставить номера на всех частях выделов, так как чисто по карте, особенно для территорий Центральной России, не всегда понятно, что к чему относится. За более чем двадцать лет такую потребность не высказывали.

Это можно сделать, используя следующее выражение ToPas:
  STRTRIM(STRCOPY(@VydNom:C:3, 1, 3*TRUNC(@VydPls)))