Anonymous | Login | Signup for a new account | 21-11-24 12:40 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001819 | SAS.Планета | [All Projects] Хотелка | public | 14-02-2013 04:55 | 24-04-2013 18:35 | ||||
Reporter | vasketsov | ||||||||
Assigned To | |||||||||
Priority | normal | Severity | tweak | Reproducibility | N/A | ||||
Status | closed | Resolution | won't fix | ||||||
Platform | Windows | OS | Vista | OS Version | Ultimate | ||||
Product Version | .Nightly | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0001819: При выводе информации о метке опционально (не) считать площадь | ||||||||
Description | По полигону типа Иркутской области в 60 с лишним тыщ точек информация о метке выводится сильно больше минуты. По Якутии или Татарстану даже запускать боюсь )) Практически всё это время занимает расчёт площади. А он пропорционален числу точек в границе. Не касаясь корректности и оптимальности самого расчёта, а также не касаясь возможности или невозможности прервать вывод информации о метке (на что здесь имеется отдельный пункт), необходимо видимо иметь какую-то отсечку по числу точек (желательно какое-то разумное число, чтобы например границы снимков, земельных участков и кварталов наверное были меньше), больше которого не считать площадь. Кому надо - сходит по ПКМ и посчитает. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0010563) Fetser (reporter) 14-02-2013 09:02 |
Я создавал хотелку 1641 немного про другое, но близкое по смыслу. Дело в том что при сложных полигонах программа просто перестаёт считать и выводит NAN. Это конечно не от числа точек зависит, а от формы полигона, если есть точки с совпадающими координатами. До 5000 точек программа считает достаточно быстро. Если бы была возможность упрощать (редуцировать)подобные полигоны для подсчёта площади. А в случае совпадения точек то и оптимизировать их. Хотя Глобал мапер как то считает любые полигоны очень быстро. |
(0010564) vasketsov (manager) 14-02-2013 09:26 |
Глобал мапер скорее всего просто с некоторой алгоритмической погрешностью считает, даже если нет пересечений, дырок и т.п. В сасе сейчас для простых полигонов с длинной границей формально используется точный метод (ошибки возможны только не алгоритмические). Его адаптивное огрубление теоретически тоже поможет. Пописал сейчас немного расчёт площади - минус 25% от времени для иркутской области. Практически на пустом месте сами себе привезли лишних полминуты при теперешних полутора. |
(0010566) vdemidov (manager) 14-02-2013 10:01 |
Там бы еще умножение на Sqr(FRadiusA) вынести из SphericalTriangleSquare за сумму, еще б ускорилось бы. |
(0010567) vasketsov (manager) 14-02-2013 10:08 edited on: 14-02-2013 10:44 |
>умножение на Sqr(FRadiusA) тогда уж 4*Sqr(FRadiusA) надо выносить )) ща поколдуем )) зы. ничего не выигралось, совсем (что конечно странно). |
(0010588) zed (manager) 19-02-2013 07:29 |
Проверь быстродействие на новом алгоритме. Есть подозрение, что считать стало сильно быстрее. |
(0010590) vasketsov (manager) 19-02-2013 13:16 |
Пока никак не могу проверить, инет тут кастрирован. |
(0010591) Fetser (reporter) 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 кв. км |
(0010593) vdemidov (manager) 20-02-2013 14:01 |
Итого 100 000 точек можно считать максимально допустимым количеством. |
(0010594) vasketsov (manager) 20-02-2013 14:32 edited on: 20-02-2013 14:32 |
Да можно и 70 тыщ. Мне вот что в глаза бросилось (но я ещё не смотрел чего там): старый алгоритм в примере Fetser во втором случае вчетверо дольше первого, а новый - в 10 раз замедлился. Хотя конечно может быть это следствие ошибок в полигоне, или дырок всяких. Опять же почему-то во втором случае сильно меньше площадь получилась (какой-то кусок не просчитался?). |
(0010595) Fetser (reporter) 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 (manager) 20-02-2013 16:37 |
vdemidov >Итого 100 000 точек можно считать максимально допустимым количеством. Лучше уйти от относительного понятия "количество" к абсолютному - времени расчёта, задаваемом в настройках. vasketsov >какой-то кусок не просчитался? Наврят ли. Может слишком большая погрешность в расчётах? Скажем, если вершины треугольника расположены относительно близко друг от друга, то погрешность небольшая, но чем дальше точки одна от одной, она может нарастать. |
(0010597) vdemidov (manager) 20-02-2013 20:00 |
>Лучше уйти от относительного понятия "количество" к абсолютному - времени расчёта, задаваемом в настройках. И как ты собираешься его учитывать? Пробрасывать этот параметр внутрь алгоритма и постоянно проверять время? Это маразм. А вот ограничить по количеству точек запуск вычисления площади при отображении информации о полигоне можно легко. |
(0010598) zed (manager) 20-02-2013 20:28 |
Нет. Я уже давно предлагал заюзать для подобных задач (как то: для расчёта количества тайлов в сложном полигоне в итераторе) компонент AsyncCall, который позволяет прозрачно вынести выполнение любой процедуры в поток. При этом, потоки он пачками не плодит, а юзает пул. |
(0010599) vasketsov (manager) 20-02-2013 20:31 |
>уйти от относительного понятия "количество" ЕМНИП это единственный параметр полигона (куска мультиполигона), который абсолютно бесплатно можно проанализировать перед расчётом. >Может слишком большая погрешность в расчётах? А откуда она там? Оно на поские треугольники делится и в минус уходит поэтому, или как было по телесному углу считается? >времени расчёта, задаваемом в настройках Хочешь поток испускать? ))) Имхо нереально и ненужно. Более чем достаточно прямо на странице или написать что слишком сложный полигон, или кнопку сделать или ссылку для пересчёта площади. |
(0010600) zed (manager) 20-02-2013 20:42 |
>который абсолютно бесплатно можно проанализировать перед расчётом Ага, вот только ты никак не соотнесёшь его с производительностью железа. Может оно и миллион точек за секунду обсчитает на данном компе? >А откуда она там? Расчёт площади треугольника я не трогал, и что там было до этого и как оно там считало я без понятия. В минус ничего уходить не должно при любом раскладе - это ж площадь как ни как. >Хочешь поток испускать? Да. Мне не жалко вынести потенциально-длительную операцию в отдельный тред. |
(0010601) zed (manager) 20-02-2013 20:54 |
И было бы хорошо, выводить информацию не в браузере, а как обычно, через контролы, чтобы можно было сразу отобразить основную информацию, а площадь дописать по мере готовности. В браузере же выводить только описание полигона. |
(0010602) vasketsov (manager) 20-02-2013 21:18 |
>никак не соотнесёшь его с производительностью железа Так может тогда если хочешь время в настройки вынести - может число точек в настройки вынести? Один хрен там INT будет. |
(0010603) vdemidov (manager) 20-02-2013 21:23 |
В кои то веки полностью согласен с vasketsov. |
(0010604) zed (manager) 20-02-2013 21:33 edited on: 20-02-2013 21:35 |
Если переделать окошко (как я описал выше) и вынести расчёт в отдельный поток, то никаких дополнительных лимитов выносить в настройки не нужно. Если пользователю интересна площадь, он дождётся расчётов (при этом, будет видеть всю информацию о полигоне, кроме площади). Если не интересна - закроет окошко и пойдет дальше. >В кои то веки полностью согласен с vasketsov. Ага и будет никакущий юзабилити - "зато сделать проще". Тьфу. |
(0010605) vdemidov (manager) 21-02-2013 04:48 |
Пределывай окошко, используй AsyncCall, главное, что бы делфовские типы не торчали в интерфейсах. Но я все равно, не понимаю, как ты хочешь этого добиться не нагородив кучу кода. |
(0010606) zed (manager) 21-02-2013 06:43 |
Оно мне надо? |
(0010607) vdemidov (manager) 21-02-2013 07:25 |
А как же "никакущий юзабилити"??? Я не спорю, что текущее окошко информации о метке не идеально. Но оно лучше тех месседжбоксов, которые были до него. |
(0010613) zed (manager) 22-02-2013 13:49 |
Ввиду проведённой доработки с выносом расчётов в отдельный поток, этот тикет можно считать неактуальным. |
(0010615) Tolik (manager) 22-02-2013 13:55 |
Эта доработка проведена в SAS или только в SACS? 0001641 решён вроде как в SACS. |
(0010616) zed (manager) 22-02-2013 13:57 |
В SACS. Если vdemidov посчитает нужным - перенесёт её и в SAS. |
(0010617) Tolik (manager) 22-02-2013 13:58 |
Значит, этот тикет (который живёт в SAS) закрывать рановато? |
(0010618) zed (manager) 22-02-2013 13:59 |
Так устроит? |
(0010628) vasketsov (manager) 24-02-2013 18:41 |
Немного у себя подправил: сделал чтобы использовалась мозилла или IE в зависимости от настроек (вырезал WmbeddedWB, это очевидно к vdemidov-у не улетит), ну и по мелочи там форму перенёс да убрал ей модальность (не вижу критичных причин для вызова формы в модальном режиме, если что всплывёт - будем лечить по факту возникновения проблем). |
(0011195) vasketsov (manager) 24-04-2013 18:12 |
>AsyncCall Это оно? http://andy.jgknet.de/blog/bugfix-units/asynccalls-29-asynchronous-function-calls/ зы. There will be no further development |
(0011196) zed (manager) 24-04-2013 18:16 |
Да. |
(0011197) vasketsov (manager) 24-04-2013 18:20 |
Странная конечно штука, юзать пул потоков без IoCompletion aka CompletionPort, ну да ладно, может оно всё из себя кросплатформенное. |
(0011198) zed (manager) 24-04-2013 18:22 |
А чё вдруг про неё вспомнил? |
(0011199) vasketsov (manager) 24-04-2013 18:35 |
Да тему искал про метки (другую), а пока подобрал ключевые слова для поиска )))) - нашёл эту, и внезапно увидел отсыл к AsyncCall. А вот почему при обсуждении тогда пропустил мимо глаз этот самый AsyncCall - хз. |
Issue History | |||
Date Modified | Username | Field | Change |
14-02-2013 04:55 | vasketsov | New Issue | |
14-02-2013 09:02 | Fetser | Note Added: 0010563 | |
14-02-2013 09:26 | vasketsov | Note Added: 0010564 | |
14-02-2013 10:01 | vdemidov | Note Added: 0010566 | |
14-02-2013 10:08 | vasketsov | Note Added: 0010567 | |
14-02-2013 10:44 | vasketsov | Note Edited: 0010567 | View Revisions |
19-02-2013 07:29 | zed | Note Added: 0010588 | |
19-02-2013 13:16 | vasketsov | Note Added: 0010590 | |
19-02-2013 15:04 | Fetser | Note Added: 0010591 | |
19-02-2013 15:20 | Fetser | Note Edited: 0010591 | View Revisions |
19-02-2013 15:24 | Fetser | Note Edited: 0010591 | View Revisions |
20-02-2013 14:01 | vdemidov | Note Added: 0010593 | |
20-02-2013 14:32 | vasketsov | Note Added: 0010594 | |
20-02-2013 14:32 | vasketsov | Note Edited: 0010594 | View Revisions |
20-02-2013 15:47 | Fetser | Note Added: 0010595 | |
20-02-2013 16:37 | zed | Note Added: 0010596 | |
20-02-2013 20:00 | vdemidov | Note Added: 0010597 | |
20-02-2013 20:28 | zed | Note Added: 0010598 | |
20-02-2013 20:31 | vasketsov | Note Added: 0010599 | |
20-02-2013 20:42 | zed | Note Added: 0010600 | |
20-02-2013 20:54 | zed | Note Added: 0010601 | |
20-02-2013 21:18 | vasketsov | Note Added: 0010602 | |
20-02-2013 21:23 | vdemidov | Note Added: 0010603 | |
20-02-2013 21:33 | zed | Note Added: 0010604 | |
20-02-2013 21:35 | zed | Note Edited: 0010604 | View Revisions |
21-02-2013 04:48 | vdemidov | Note Added: 0010605 | |
21-02-2013 06:43 | zed | Note Added: 0010606 | |
21-02-2013 07:25 | vdemidov | Note Added: 0010607 | |
22-02-2013 13:49 | zed | Note Added: 0010613 | |
22-02-2013 13:49 | zed | Status | new => closed |
22-02-2013 13:49 | zed | Resolution | open => won't fix |
22-02-2013 13:55 | Tolik | Note Added: 0010615 | |
22-02-2013 13:57 | zed | Note Added: 0010616 | |
22-02-2013 13:58 | Tolik | Note Added: 0010617 | |
22-02-2013 13:58 | zed | Project | SAS.Планета => SACS.Планета |
22-02-2013 13:59 | zed | Note Added: 0010618 | |
23-02-2013 09:29 | vdemidov | Project | SACS.Планета => SAS.Планета |
24-02-2013 18:41 | vasketsov | Note Added: 0010628 | |
24-04-2013 18:12 | vasketsov | Note Added: 0011195 | |
24-04-2013 18:16 | zed | Note Added: 0011196 | |
24-04-2013 18:20 | vasketsov | Note Added: 0011197 | |
24-04-2013 18:22 | zed | Note Added: 0011198 | |
24-04-2013 18:35 | vasketsov | Note Added: 0011199 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |