ВОПРОСЫ АБСОЛЮТНЫХ НОВИЧКОВ

[acHawk]

Вопрос про точность вычисления программой площади полигона.
Не знаю в какой раздел лучше вынести эту тему...
Вопрос скорее разработчикам.
Ввожу ПРЯМОУГОЛЬНЫЙ полигон из 5 точек:
37.2904653321326,55.597798008645
37.2901139235351,55.5982988490921
37.2385156455409,55.586703102331
37.2388669505387,55.5862022609298
37.2904653321326,55.597798008645
Теоретические размеры сторон: 3500х60 метров, они совпадают с измерениями в программе.
Теоретическая площадь равна 210 000 кв. м.
Программа показывает 208 981 кв.м.
Ошибка = 5%, не многовато-ли?
Здесь я написал чушь - не 5% а 0.5% - но все равно много!

[vlasto1]

Вопрос про точность вычисления программой площади полигона.
Не знаю в какой раздел лучше вынести эту тему...
Вопрос скорее разработчикам.
Ввожу ПРЯМОУГОЛЬНЫЙ полигон из 5 точек:
37.2904653321326,55.597798008645
37.2901139235351,55.5982988490921
37.2385156455409,55.586703102331
37.2388669505387,55.5862022609298
37.2904653321326,55.597798008645
Теоретические размеры сторон: 3500х60 метров, они совпадают с измерениями в программе.
Теоретическая площадь равна 210 000 кв. м.
Программа показывает 208 981 кв.м.
Ошибка = 5%, не многовато-ли?

А если посчитать, 5% от 210000 = 10500
Разница 210000- 208981 = 1019 что значительно меньше 10500
И составит меньше 0.5% от 210000

[acHawk]

Ну конечно 0.5% - но это все равно много.

[Parasite]

Ну конечно 0.5% - но это все равно много.

Ваши предложения (в виде готового участка кода, считающего площадь из координат более точно)?

[DJ VK]

Ну конечно 0.5% - но это все равно много.

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

на данный момент в программе написано (перевожу):

// код скопирован из GRASS
// понятия не имеем как он работает, и всё-таки он работает

Вам еще не понятно, как пишутся программы со сложными математическими конструкциями? Вот вам пример:

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

Когда мне в плеер понадобился графический эквалайзер, я не стал его придумывать. Я нашел готовую реализацию на фильтрах Баттерворта 4-го порядка в CALF и адаптировал код под свою программу. И не такая уж и линейная получилась АЧХ на верхних частотах, такие уж фильтры...
Когда мне в плеер понадобился парметрический эквалайзер, я не стал его придумывать. Я нашел готовую реализацию на фильтрах-биквадах в CALF и адаптировал код под свою программу. Работает ну просто офигенно.
Когда мне в плеер понадобился лимитер, я не стал его придумывать. Я нашел готовую реализацию в CALF и адаптировал код под свою программу. Ни хрена не работает, если ручку покрутить.
(если кто-то захотел глянуть - все наработки любезно выложены в open-source библиотеку newAC)
Нету в России кафедры эквалайзеров и сотни методичек на эту тематику (на русском). По фильтрам Высоких порядков с реальным формулами всего 1 статья и та на английском. Да три-четыре примера реализации в коде.

Аналогичная хрень и в географических рассчетах. Эмпирические методики, ровные столбики формул и десятки примеров. Какие из них более точные? какие лучше работают в частных случаях? Да разобраться в этом - по объему на диссертацию потянет!
даже эти приблизительные рассчеты очень долго появлялись в планете, до этого не было совсем никаких. Пока не подвернулась под руку формула.
Так что, как и сказал Parasit - присылайте нам вашу методику. Вы ведь найдете нам диссертацию на тему повышения точности рассчетов площадей какого-нибудь американского, японского или, скажем, иранского (если не будет российского) ученого в подлиннике с офигенно точными формулами? Ну или хотя бы без формул, но с точными названиями методики и фамилиями кто ее придумал, нагуглим....

[acHawk]

Ну конечно 0.5% - но это все равно много.

на данный момент в программе написано (перевожу):

// код скопирован из GRASS
// понятия не имеем как он работает, и всё-таки он работает

Понятно...
Спасибо за прямой ответ.
Я ж не в целях вас покритиковать, думал, обратить ваше внимание на эту проблему, может у вас есть по этому поводу какие-нибудь конструктивные мысли и планы.
Кстати, воткнул тот же пример в GlobalMapper - получил = 208900
В GoogleEarth = 209023.
Хотя длины сторон у всех считаются правильно.
Так что вы не одиноки - похоже это общая проблема.
Вот только что с этим делать?

[DJ VK]

Так что вы не одиноки - похоже это общая проблема.
Вот только что с этим делать?

Все не теоретические, а практические расчеты имеют точность (а значит и погрешность можно посчитать), также как все события имеют вероятность.
Если Вы займетесь на досуге изучением существующих методик, то вы узнаете какие есть варианты, какие у них погрешности, и какие ограничения в применении (ибо у нас прямоугольник может быть от метра до всей планеты три раза)
Потратив немало времени на поиск все новых методик, возможно вы найдете ЕЁ. Ту самую, которая здесь нужна. И если она не считается 2-е суток на суперкомпьютере, мы поговорим о возможности ее внедрения.
Начните с копания в исходном коде планеты, найдите точное название методики, и поищите оценки ее погрешности, дабы было с чем сравнивать все остальные.
Великое начинается с малого, никаких как бы было бы здорово, если бы было... Только "я хочу - значит я найду, а Вы мне поможете советом!".
Разработчики, честь им и хвала, сколько имели возможного времени и желания - столько и потратили на поиск в общем не само го плохого метода, его затем и внедрили. Поиск еще лучших методов требует на порядки больше свободного времени и знаний в этой области. Ни разработчки, ни активные форумчане навроде меня, в лучшей методике ценой таких затрат не нуждаются... поэтому, будет огромной помощью проекту помочь нам в этом...

Статья номер 1. Чтобы понять, что предстоит считать:

Поскольку проекция Меркатора имеет различный масштаб на разных участках, эта проекция не сохраняет площади. Если основной масштаб относится к экватору, то наибольшие искажения размеров объектов будут у полюсов. Это хорошо заметно на картах в этой проекции: на них Гренландия кажется в 2—3 раза больше Австралии и сравнима по размерам с Южной Америкой. В реальности Гренландия втрое меньше Австралии и в 8 раз меньше Южной Америки.

https://ru.wikipedia.org/wiki/Проекция_Меркатора
а вот и про метод
viewtopic.php?f=2&t=2211&start=40#p35328

[Gma]

... Кстати, воткнул тот же пример в GlobalMapper - получил = 208900
В GoogleEarth = 209023.
Хотя длины сторон у всех считаются правильно.
Так что вы не одиноки - похоже это общая проблема.
Вот только что с этим делать?...

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

[acHawk]

а вот и про метод
viewtopic.php?f=2&t=2211&start=40#p35328

Почитал...
Похоже это методика пересчета полигона на эквивалентный сфероид, и далее расчет площади уже на нем.
Видимо она предназначена для больших площадей (например, площадь государства).
Мой же пример весьма компактный - прямоугольник всего 3500х60 метров. S = 210 000 кв. м.
Для небольших площадей, видимо надо переходить от широты-долготы в какую-нибудь равновеликую проекцию, и там уже считать площадь.
Попробую проверить эту мысль.

[vdemidov]

Кстати, воткнул тот же пример в GlobalMapper - получил = 208900
В GoogleEarth = 209023.
Хотя длины сторон у всех считаются правильно.
Так что вы не одиноки - похоже это общая проблема.
Вот только что с этим делать?

Не вижу причин что-то делать. 0.5% разницы, с учетом того, что на местности это может быть не совсем прямоугольник, а трапеция с двумя дугами (3.5 км это достаточно заметное уже расстояние). А если сравнить с результатами такой достаточно авторитетной программы как GlobalMapper, то и вообще ошибка выходит меньше 0.04%