Анализ участков мировой карты (04.03.2024). Печать
2024 - Март
04.03.2024 17:30
Save & Share
Взаимодействие с картой планеты и её данными требует не только тщательной оптимизации скорости работы исходного кода - но и контейнеров данных. В данной работе планета охвачена целиком. Вдобавок к этому, идёт взаимодействие именно с глючными картами ГИС компании Панорама, в глючной среде программирования Qt, в глючной операционной системе Astra Linux. Это была самая сложная из задач, что программировались в жизни.

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



Специфика разработки программного обеспечения анализа площадных участков мировой карты (на примере ГИС Оператор и Qt).

(добавлено 24.06.2026) Для более глубокого тестирования механизма накладывания площадных участков мировой карты - потребовалась разработка генератора таких участков (координаты в XML-формате). Задача проще, чем представленная выше, - но стоит описать тонкости, которые возникли уже на начальном этапе разработки.

Выбор своей ОС и среды разработки - крайне важный момент в ускорении разработки, и это право нужно у заказчика выбивать. Попытавшись писать это в связке Astra+Qt - стошнило, и выбрал Windows XP x32 и Borland C++ Builder v.6.0.

Несмотря на то, что разработка пошла быстро, - проблема возникла с уравнениями прямых:
- в Qt long double было необходимостью (чтобы, в корректно пересечения линий друг с другом находить - <1мс при 100мс в 1с координат). Так же оказалось и здесь: точности double не хватило даже для расчёта K и B в уравнении прямой (обратный расчёт выдавал ошибку);
- сколько реальных знаков после запятой было у long double в Qt - неизвестно. Одновременно, нет возможности включить наивысшую точность long double через _control87() в float.h: нет константы PC_80, а PC_64 - ломала точность у double вообще полностью;
- поэтому, пришлось написать свою функцию сравнения long double и вычислить реальную точность при >126млрд вычислений: 4.5475e-013L - между 12-13 знаками после запятой (погрешность постоянно меняется - при одних и тех же вычислениях). Но в тесте учитывались максимальные значения X и Y 1млн - пришлось повторить тест для 129.6млн (максимум мс в координатах, без учёта знака широты) - расчёты будут идти очень долго;
- ИИ опять отличился своей тупизной: то миллисекунд в координатах не существует (когда вот он, реальный проект на экране открыт), то константа PC_80 не число (число 0x2 по факту), то точность double пишет 15-17 знаков (а в уточнении рядом - уже 6);
- randomize() - надо вызывать при старте программы 1 раз, а не каждый раз перед вызовом random().

(добавлено 27.06.2026) Небольшие уточнения по погрешностям long double (не смог закончить корректно).
Обновлено ( 27.07.2026 19:13 )