Расчет площади

[Ivan30]

а я вот это вспомнил

[Parasite]

а я вот это вспомнил

Не, ну на самом-то деле вопрос-то как раз по существу, ибо там - голая математика, а она, как известно - царица наук, и разночтений над одним и тем же не допускает. Но вот САС - это не полноценный GIS, и вообще сделан для развлечения себя любимых, а не для серьезных геодезических работ с вычислениями до знаков после запятой. Так что по сути-то вопрос верный, но вот садиться и всем миром ловить этого Неуловимого Джо - ну, вы понимаете... Так что кому надо - программеры примут патч с удовольствием, а кто не все - те просто пользуются тем, что есть. Благо что работает, и всех устраивает уже кучку лет. А без конкретных предложений этот вопрос тут просто сгинет в Бездну через день-два, и всё вернется на круги своя.

[vdemidov]

Способ №1
Замеряем ширину тайла на полюсе в том же z10 масштабе = 6 км 774.73 м умножаем на 512 и получаем длину окружности полюса 3 468.66176 км, соответственно площадь этой окружности = 957 445.4529 км2, добавляем площади 2-х полюсных окружности к тому что измерили и получаем площадь сферы 512 376 597.1 км2.
Это больше гугловского геоида (511 207 893.4 км2) на 1 168 703.75 км2

Итого погрешность 0,2%. Отличная точность, для программы, которая раньше ошибалась в несколько раз

[vasyaddd]

Итого погрешность 0,2%. Отличная точность, для программы, которая раньше ошибалась в несколько раз

0.2% в данном случае не погрешность, а предполагаемая площадь поверхности геоида, за пределами N85°03'04.06" и S85°03'04.06". При этом если радиус сферы 6378.137 км эта цифра (0.2%) не верна.

Если быть точнее, речь не о погрешности, а о площади полюсов, которая в сумме с площадью видимой карты (от N85°03'04.06" до S85°03'04.06") должна быть равна площади Google WGS84 Sphere

Вроде все просто: S=a+2b

где:
S — площадь Google WGS84 Sphere
a — площадь геоида от N85°03'04.06" до S85°03'04.06"
b — площадь геоида за пределами 85°03'04.06 к северу или югу

Сейчас получается, что эти три числа не сходятся.

[vdemidov]

Сейчас получается, что эти три числа не сходятся.

А не сходятся они потому что при вычислении a есть погрешности, и, возможно, при вычислении b также есть погрешности. В сумме эти погрешности составляют 0.2%, что на мой взгляд является отличным результатом. Но если есть конкретные предложения как эту погрешность можно уменьшить, то мы с удовольствием их выслушаем.

[vasyaddd]

Не, ну на самом-то деле вопрос-то как раз по существу, ибо там - голая математика, а она, как известно - царица наук, и разночтений над одним и тем же не допускает. Но вот САС - это не полноценный GIS, и вообще сделан для развлечения себя любимых, а не для серьезных геодезических работ с вычислениями до знаков после запятой. Так что по сути-то вопрос верный, но вот садиться и всем миром ловить этого Неуловимого Джо - ну, вы понимаете... Так что кому надо - программеры примут патч с удовольствием, а кто не все - те просто пользуются тем, что есть. Благо что работает, и всех устраивает уже кучку лет. А без конкретных предложений этот вопрос тут просто сгинет в Бездну через день-два, и всё вернется на круги своя.

В том-то и дело, что SASPlanet всё довольно круто измеряется и сходится с другими информационными источниками подобного типа, и в принципе на SAS.Planet вполне можно ссылаться как на информационный источник. Но вот конкретно это нестыковка рубит все расчеты в exel нахрен, походу придется построить свою модель

[zed]

vasyaddd
Рекомендую перечитать моё сообщение почти двухлетней давности: viewtopic.php?f=2&t=2211&start=40#p35328 - там и ссылка на алгоритм и прочие уточнения. В алгоритме используется весьма простая математика и если у вас есть предложения по улучшению алгоритма, то мысли в студию.

[zed]

Способ №3
Спросить у разработчиков:
— Какова площадь всего геоида, который обмеряется в SASPlanet или какова площадь отсутствующих полюсов (за пределами 85°03'04.06") по мнению разработчиков?

А кто ж его знает? Это можно выяснить только если вычленить алгоритм и скормить ему на вход нужные координаты. Задача, в общем-то, весьма тривиальная, но мне не понятно что вы хотите выяснить в итоге. Можно ли доверять показаниям SAS при измерении площадей? Ну, тогда анализируйте наш алгоритм напрямую, а не путём косвенных измерений. Паскаль - язык весьма простой, кода, реализующего алгоритм, с гулькин нос, так что задача решаема. Единственное, что я вам никак не подскажу, почему алгоритм именно такой, потому как я его не писал. Да и судя по комментариям к коду, ребята из QGIS, откуда взят код, тоже в него не особо вникали - работает и ладно

[vasyaddd]

На 3D модели в Автокаде

скрытый текст: показать

видно что у сферы радиусом 6378137 м (WGS84) — радиус N85°3'4.06'' параллели равен 550.22118677 км, её длинна 3457.14167639 км, площадь сечения 951096.29800428 км, площадь поверхности сферы за этой параллелью (площадь полюса) 952872.41659328 км.

Корень погрешностей — количество знаков после запятой. Например в масштабе z10 у нас 512 тайлов. Ширина тайла на N85°3'4.06'' параллели = 3457.14167639 / 512 = 6.752229836699219 км. То есть нужно 15 знаков после запятой, что бы при умножении обратно на 512 получить ровно ту же длину параллели 3457.14167639 км. Тот же Автокад поддерживает максимум 8 знаков после запятой.

Также на 3D модели выясняем, что площадь поверхности от N85°3'4.06'' до S85°3'4.06'' = 509302148.6 км. То есть тут площади поверхностей a+2b собираются точно в Гугл сферу WGS84 . Всё идеально сходится на 100% (отклонение от 511207893.4 всего на >0.0000000064553%). Теперь, чтобы построить сетку тайлов на сфере мне всего лишь нужны координаты каждой параллели тайловой сетки в формате DDMMSS или DD.DDDDD.

Тут, точность начинает портить формат DDMMSS. Во первых в этом формате не удается точно установить метку в масштабе z20 и более, не хватает нулей после запятой у секунд. Во вторых радиус в формате DDMMSS каждый раз нужно либо перепечатывать из SAS.Планеты в Автокад (вместо того чтобы скопировать и вставить), или вовсе каждый раз конвертировать в формат DD.DDDDD повторяя как проклятый DD+MM/60+SS/3600 = DD.DDDDD (попробуйте проделать такое хотя бы раз 128 тем более без exel). Не все триде редакторы поддерживают формат DDMMSS а вот DD.DDDDDD — все. Пиксельные и тайловые координаты отлично решают проблему точной установки метки но за пределами SAS.Планеты от этой фичи пользы практически нет. Гугл например не показывает координаты в формате DDMMSS, поэтому сравнивать координаты меток одновременно в Браузере и SAS.Планете — зрелище ещё то.

Короче было бы круто если бы в SAS.Планете можно было бы ставить метки точнее 00°00'0.000", а ещё лучше, чтоб без гемороя — 0.00000000°, ведь за окном уже 21-й век.

[zed]

Формат координат переключается в настройках.