|
Notes |
|
|
(0010563)
|
|
Fetser
|
|
14-02-2013 09:02
|
|
Я создавал хотелку 1641 немного про другое, но близкое по смыслу. Дело в том что при сложных полигонах программа просто перестаёт считать и выводит NAN.
Это конечно не от числа точек зависит, а от формы полигона, если есть точки с совпадающими координатами.
До 5000 точек программа считает достаточно быстро. Если бы была возможность упрощать (редуцировать)подобные полигоны для подсчёта площади. А в случае совпадения точек то и оптимизировать их.
Хотя Глобал мапер как то считает любые полигоны очень быстро. |
|
|
|
|
Глобал мапер скорее всего просто с некоторой алгоритмической погрешностью считает, даже если нет пересечений, дырок и т.п. В сасе сейчас для простых полигонов с длинной границей формально используется точный метод (ошибки возможны только не алгоритмические). Его адаптивное огрубление теоретически тоже поможет.
Пописал сейчас немного расчёт площади - минус 25% от времени для иркутской области. Практически на пустом месте сами себе привезли лишних полминуты при теперешних полутора. |
|
|
|
|
|
Там бы еще умножение на Sqr(FRadiusA) вынести из SphericalTriangleSquare за сумму, еще б ускорилось бы. |
|
|
|
(0010567)
|
|
vasketsov
|
14-02-2013 10:08
(edited on: 14-02-2013 10:44) |
|
>умножение на Sqr(FRadiusA)
тогда уж 4*Sqr(FRadiusA) надо выносить )) ща поколдуем ))
зы. ничего не выигралось, совсем (что конечно странно).
|
|
|
|
(0010588)
|
|
zed
|
|
19-02-2013 07:29
|
|
|
Проверь быстродействие на новом алгоритме. Есть подозрение, что считать стало сильно быстрее. |
|
|
|
|
|
Пока никак не могу проверить, инет тут кастрирован. |
|
|
|
(0010591)
|
|
Fetser
|
19-02-2013 15:04
(edited on: 19-02-2013 15:24) |
|
Московская область 20000 точек
старый алгоритм 30 сек площадь 44409 кв. км
новый алгоритм 1 сек площадь 44384 кв. км
глобал мапер 1 сек площадь 44354 кв. км
википедия 44379 кв. км
Эвенкийский АО 55764 точек
старый алгоритм 2 мин площадь 760280 кв. км
новый алгоритм 10 сек площадь 748741 кв. км
глобал мапер 1 сек площадь 769785 кв. км
википедия 767600 кв. км
|
|
|
|
|
|
Итого 100 000 точек можно считать максимально допустимым количеством. |
|
|
|
|
Да можно и 70 тыщ. Мне вот что в глаза бросилось (но я ещё не смотрел чего там): старый алгоритм в примере Fetser во втором случае вчетверо дольше первого, а новый - в 10 раз замедлился. Хотя конечно может быть это следствие ошибок в полигоне, или дырок всяких. Опять же почему-то во втором случае сильно меньше площадь получилась (какой-то кусок не просчитался?).
|
|
|
|
(0010595)
|
|
Fetser
|
|
20-02-2013 15:47
|
|
Мурманский 8129 точек
старый алгоритм 3 сек площадь 147208 кв. км
новый алгоритм менее 1 сек площадь 144639 кв. км
глобал мапер 1 сек площадь 143990 кв. км
википедия 144902 кв. км
Свердловский 11966 точек
старый алгоритм 6 сек площадь 193689 кв. км
новый алгоритм 1 сек площадь 192863 кв. км
глобал мапер 1 сек площадь 190832 кв. км
википедия 194307 кв. км
Ханты-Мансийский 8557 точек
старый алгоритм 3 сек площадь 540438 кв. км
новый алгоритм менее 1 сек площадь 539514 кв. км
глобал мапер 1 сек площадь 526438 кв. км
википедия 534801 кв. км
Якутский 48253 точек
старый алгоритм 1 мин 29 сек площадь 3065108 кв. км
новый алгоритм 8 сек площадь 2913180 кв. км
глобал мапер 1 сек площадь 3148033 кв. км
википедия 3489689 кв. км
Все полигоны росреестра без дырок. |
|
|
|
(0010596)
|
|
zed
|
|
20-02-2013 16:37
|
|
vdemidov
>Итого 100 000 точек можно считать максимально допустимым количеством.
Лучше уйти от относительного понятия "количество" к абсолютному - времени расчёта, задаваемом в настройках.
vasketsov
>какой-то кусок не просчитался?
Наврят ли. Может слишком большая погрешность в расчётах? Скажем, если вершины треугольника расположены относительно близко друг от друга, то погрешность небольшая, но чем дальше точки одна от одной, она может нарастать. |
|
|
|
|
>Лучше уйти от относительного понятия "количество" к абсолютному - времени расчёта, задаваемом в настройках.
И как ты собираешься его учитывать? Пробрасывать этот параметр внутрь алгоритма и постоянно проверять время? Это маразм. А вот ограничить по количеству точек запуск вычисления площади при отображении информации о полигоне можно легко. |
|
|
|
(0010598)
|
|
zed
|
|
20-02-2013 20:28
|
|
|
Нет. Я уже давно предлагал заюзать для подобных задач (как то: для расчёта количества тайлов в сложном полигоне в итераторе) компонент AsyncCall, который позволяет прозрачно вынести выполнение любой процедуры в поток. При этом, потоки он пачками не плодит, а юзает пул. |
|
|
|
|
>уйти от относительного понятия "количество"
ЕМНИП это единственный параметр полигона (куска мультиполигона), который абсолютно бесплатно можно проанализировать перед расчётом.
>Может слишком большая погрешность в расчётах?
А откуда она там? Оно на поские треугольники делится и в минус уходит поэтому, или как было по телесному углу считается?
>времени расчёта, задаваемом в настройках
Хочешь поток испускать? ))) Имхо нереально и ненужно. Более чем достаточно прямо на странице или написать что слишком сложный полигон, или кнопку сделать или ссылку для пересчёта площади. |
|
|
|
(0010600)
|
|
zed
|
|
20-02-2013 20:42
|
|
>который абсолютно бесплатно можно проанализировать перед расчётом
Ага, вот только ты никак не соотнесёшь его с производительностью железа. Может оно и миллион точек за секунду обсчитает на данном компе?
>А откуда она там?
Расчёт площади треугольника я не трогал, и что там было до этого и как оно там считало я без понятия. В минус ничего уходить не должно при любом раскладе - это ж площадь как ни как.
>Хочешь поток испускать?
Да. Мне не жалко вынести потенциально-длительную операцию в отдельный тред. |
|
|
|
(0010601)
|
|
zed
|
|
20-02-2013 20:54
|
|
|
И было бы хорошо, выводить информацию не в браузере, а как обычно, через контролы, чтобы можно было сразу отобразить основную информацию, а площадь дописать по мере готовности. В браузере же выводить только описание полигона. |
|
|
|
|
>никак не соотнесёшь его с производительностью железа
Так может тогда если хочешь время в настройки вынести - может число точек в настройки вынести? Один хрен там INT будет. |
|
|
|
|
|
В кои то веки полностью согласен с vasketsov. |
|
|
|
(0010604)
|
|
zed
|
20-02-2013 21:33
(edited on: 20-02-2013 21:35) |
|
Если переделать окошко (как я описал выше) и вынести расчёт в отдельный поток, то никаких дополнительных лимитов выносить в настройки не нужно. Если пользователю интересна площадь, он дождётся расчётов (при этом, будет видеть всю информацию о полигоне, кроме площади). Если не интересна - закроет окошко и пойдет дальше.
>В кои то веки полностью согласен с vasketsov.
Ага и будет никакущий юзабилити - "зато сделать проще". Тьфу.
|
|
|
|
|
|
Пределывай окошко, используй AsyncCall, главное, что бы делфовские типы не торчали в интерфейсах. Но я все равно, не понимаю, как ты хочешь этого добиться не нагородив кучу кода. |
|
|
|
(0010606)
|
|
zed
|
|
21-02-2013 06:43
|
|
|
|
|
|
|
А как же "никакущий юзабилити"??? Я не спорю, что текущее окошко информации о метке не идеально. Но оно лучше тех месседжбоксов, которые были до него. |
|
|
|
(0010613)
|
|
zed
|
|
22-02-2013 13:49
|
|
|
Ввиду проведённой доработки с выносом расчётов в отдельный поток, этот тикет можно считать неактуальным. |
|
|
|
(0010615)
|
|
Tolik
|
|
22-02-2013 13:55
|
|
Эта доработка проведена в SAS или только в SACS?
0001641 решён вроде как в SACS. |
|
|
|
(0010616)
|
|
zed
|
|
22-02-2013 13:57
|
|
|
В SACS. Если vdemidov посчитает нужным - перенесёт её и в SAS. |
|
|
|
(0010617)
|
|
Tolik
|
|
22-02-2013 13:58
|
|
|
Значит, этот тикет (который живёт в SAS) закрывать рановато? |
|
|
|
(0010618)
|
|
zed
|
|
22-02-2013 13:59
|
|
|
|
|
|
|
Немного у себя подправил: сделал чтобы использовалась мозилла или IE в зависимости от настроек (вырезал WmbeddedWB, это очевидно к vdemidov-у не улетит), ну и по мелочи там форму перенёс да убрал ей модальность (не вижу критичных причин для вызова формы в модальном режиме, если что всплывёт - будем лечить по факту возникновения проблем). |
|
|
|
|
>AsyncCall
Это оно?
http://andy.jgknet.de/blog/bugfix-units/asynccalls-29-asynchronous-function-calls/
зы. There will be no further development |
|
|
|
(0011196)
|
|
zed
|
|
24-04-2013 18:16
|
|
|
|
|
|
|
Странная конечно штука, юзать пул потоков без IoCompletion aka CompletionPort, ну да ладно, может оно всё из себя кросплатформенное. |
|
|
|
(0011198)
|
|
zed
|
|
24-04-2013 18:22
|
|
|
А чё вдруг про неё вспомнил? |
|
|
|
|
|
Да тему искал про метки (другую), а пока подобрал ключевые слова для поиска )))) - нашёл эту, и внезапно увидел отсыл к AsyncCall. А вот почему при обсуждении тогда пропустил мимо глаз этот самый AsyncCall - хз. |
|