А может. ещё какой метод есть, более простой, поищи в Инет, пожалуй.
Далее, соответственно, создаёшь окно, устанавливаешь в начале. перед его показом, непрозрачность 0. Затем в цикле, лучше по таймеру или даже в нитке с засыпанием (sleep с каким-то интервалом), повышаешь непрозрачность до 1.
Отдельные полигоны - лишь замкнутые контура из точек залитые цветом. Система отрисовки не знает про их соседство и отсюда такие артефакты. Вам необходимо подтянуть все близлежащие точки соседних полигонов друг к другу, чтобы они совпадали. Есть специальные инструменты для этого в ГИС-системах, которые занимаются и векторизацией.
Более профессиональное решение - хранить все полигоны как массивы индексов из единого массива точек, где один индекс может присутствовать в двух (и более, в случае угловой точки) соседних полигонах.
Рисуй в BufferedImage (BI) размером ровно в область отрисовки. А repaint() пусть выводит запрошенный для обновления кусок этого BI уже на канву, в графику Swing.
Область перерисовки в Swing оптимизируется, т.е. мелкие прямоугольники, не выведенные в небольшой промежуток времени , будут объединяться в более крупные, включающие мелкие, И тогда скорости будет хватать на всё.
Если что-то очень сложное - переносить само рисование в отдельную нить, куда передавать свои примитивы рисования (можно в очередь синхронную). BI позволяет создать свою Graphics2D, куда можно рисовать из любой нити без особого риска, особенно если озаботиться синхронизацией по доступу к единому BI. Но хватит и одной дополнительной нити отрисовки в BI, думаю. А уже отрисовывать BI на JPanel (скажем) - дело техники. Возможно, стоит синхронизовать доступ к BI из repaint() и из дополнительной нити на его изменение.
Спутник не работает ни с чем, если это не спутник ПРО, конечно. Он просто выполняет свою работу, в вашем случае, сканирует земную поверхность и в сыром виде отправляет снятые данные на земную антенну.
Там снимки очищаются, обрабатываются и сохраняются в хранилище в стандартном, привязанном к координатам виде. Всё это занимает время, достаточно немалое. Поэтому о работе в реальном масштабе времени, тем более о слежении за какими то конкретным объектами (как с вертолёта за авто или даже с самолёта с хорошей оптикой) речи не идёт и идти не может.
Даже спутник ПРО вряд-ли обрабатывает что-то на борту. Скорее, он отсылает быстро на Землю, где быстро и грубо обрабатывают отдельные ИЗВЕСТНЫЕ места нахождения баллистических ракет на предмет известных признаков, типа инфракрасных факелов, например. На деле распознаванием подлетающих ракет занимаются на загоризонтных РЛС той же ПРО, но на земле. Там рассматривают небо, где объектов практически нет (те же спутники, их всего несколько тысяч и все наперечёт известны, где и когда находятся). И если в небе появляется объект со скоростью близкой к 1-й космической, распознать его достаточно просто (Доплеровский эффект)
Далее снимки берёт (покупает) та или иная организация и уже ищет на снимке интересующие её объекты своим способом. Вот тогда уже можно найти и авто и дороги и здания. Собственно, это задача т.н. аэрогеодезических предприятий - обновление карт по данным спутниковой (и не только) съёмки. Автомобили такую контору не интересуют, конечно.
Авто интересуются какие нибудь другие службы, типа учёных, дорожников, гиббонов и прочих.
Итак, существует конечная картинка с заданным размером. И она не вертикальная.
Предположим, что пропорции исходной картинки изначально как у смартфона, это ведь она вертикальная, не так ли?
Затем вписываешь вертикальную в конечную так, чтобы она стала высотой с результирующую картинку.
При этом результат представляет собой картинку из трех сопряжённых частей, где центральная занята исходной картинкой, а боковые надо скопировать (с масштабированием и результирующим размытием) из части центральной картинки.
Это достаточно просто - просто берёшь из боковых частей центра куски изображения пропорциональные по размерам с боковыми частями. Будут ли эти кусочки стыковаться боковыми частями по центру вертикалки или нет - зависит от вкуса. На примере они явно не стыкуются. Т.е. примерно так выглядит алгоритм графически:
При масштабировании надо размывать картинку, а не копировать дополнительные пикселы, иначе получится мозаичность, а не размытие. На Java (как пример) всё описанное делается элементарно без всяких библиотек, встроенными средствами, в т.ч. и плавное размытие.
Если требуется поставить точку на полилинии (имеющую несколько вертексов/точек) на середине её общей длины от начальной точки P0, то можно так:
1. Проходим по всем её отрезкам, считаем сумму их длины (Ls).
2. Определяем геометрическую середину полилинии Lm = Ls/2;
3. Снова идём по отрезкам, пока не обнаруживаем, что текущий счётчик сумм длин отрезков Lс не оказывается больше или равен Lm. Это означает что мы либо нашли среднюю точку (если Lc==Lm точно) либо нашли отрезок, на котором и должна находиться средняя точка!
3. Определяем положение искомой точки на текущем отрезке, которая будет размещена на текущем отрезке полилинии состоящем из точек PN и PN+1 (с расстоянием между ними DN) на расстоянии DM = Lm - Lc + DN от точки PN (начало полилинии).
4. Вычисляем координаты найденной точки по полученной пропорции DM/DN, прибавляя разницу к X и Y для точки PN и рисуем её.
Взять внятный и простой (на вид) исходный текст с комментариями из сторонней библиотеки и вставить к себе, вызывая из своего кода как свой метод. После сдачи работы изучить чужой текст, чтобы уметь сделать самому)))
Задание не понятно до конца, но предположим, что Вам надо найти все пары (id,string) не сущестующие в обеих массивах одновременно.
Просто и понятно (мне, без стримов) сделать через Set.
Свои пары создавайте в классе с двумя полями int id и String string. Перезапишите в этом классе методы из класса Object hashCode и equals.
В hashCode проще всего преобразовывать int в строку и добавлять спереди к string и брать от новой строки её hashCode. Оно сработает!
В equals сравнивайте this и obj по id и по string.
Возвращайте true только если они попарно равны в обоих объектах.
Например return (this.id == obj.id) && (this.string.equals(obj.string);
Затем засовывайте все пары в любой очереди из обеих массивов в соответствующий Set. Главное, чтобы каждую сунуть только один раз! После завершения засовывания Вы имеет Set с уникальными парами. Всё!
Как извлечь из Set все пары в виде ArrayList - дело вкуса.
Bavashi, спасибо за грамотный ответ))) Другой мог бы и обидеться((( Полностью согласен со всеми 3-мя пунктами. Swing начал использовать в 2000-х, когда JavaFX был ещё глюкавым и порочным))) Даже интересно. что с ним сегодня, можно ли его пользовать. В целом мне лично нужно только стандартное GUI, никаких динамических спрайтов и прочих около игровых плюшек. Но если они есть и работают без усилий - почему бы и нет? Надо подумать. Спасибо за наводку!
Про то, что начало использования Swing вызывает некоторое отторжение - согласен. Но постепенно диспетчеры компоновки перестают пугать, а польза от них, несомненно, есть. В Delphi (по кр. мере старом, вплоть до 7-й версии) создавать окна с динамически меняющимися размерами было ещё тем геморроем с ручной шлифовкой, а в Swing ведь всё это делается автоматом, достаточно использовать нужный чёртов диспетчер :o) Парадигма всех этих диспетчеров? то ли вдохновлялась принципами HTML, то ли она и вдохновила HTML)))
P.S. На конференции не был. Хожу на них, только когда везёт работать в гео-сферах( ГИСы, любая геология, были уран (пост-СССР), нефть, рудные ископаемые), в последний раз перерыв, с погружением в фулл-стек технологии (брррр), был как раз с 2016 по 2020 года. Теперь снова буду ходить, надеюсь. Где-то там и увидимся, возможно :o!
Bavashi, делаю на Swing произвольный GUI для кода, обрабатывающего большие массивы на основе нерегулярных данных для геологии, так уж сложилось исторически, и генерирующего матрицы результатов в битовом виде.
Достаточно существенная работа с изображениями, скажем, формирование синтезированных цветов из мудьти-спектральных сканерных космических изображений. Всё работает нормально, никаких нареканий на внешний вид нет. Строится сам интерфейс (при опыте) достаточно быстро.
Даже и требований к совместимости уже нет, но переходить на устаревшие среды разработки Delphi (потратил на них до 8 лет жизни) никакого желания нет. А С++ не зашёл по причине своей избыточной (ПМСМ) модели наследования. Но тут - уже дело вкуса. Не навязываю свой, но и не готов согласиться с Вами по поводу ужасов "городка" )))
Но в целом, согласен, Swing - это никак не массовый тренд, требующий стандартные мозги кубической или спиралевидной (как уж потребуют библиотеки того или иного названия и назначения) формы.
azerphoenix, не "... Java имеет больше enterprise направленность", а библиотеки и сервисы на Java имеют оную. Но есть и другие направленности, в частности, параллельные и математические библиотеки в мировых научных центрах, например, в ЦЕРН.
Сама Java заточена чисто на запуск одинаковых кодов в разных средах. И да, наблюдал подобные фокусы. Разрабатываешь и отлаживаешь на Windows (корпоративный стандарт в конторе), а работает оно на каком-то IBS Unix (требование заказчика). При этом без какой-либо переделки!!! Лишь бы версия Java совпадала. Разве не магия?
Bavashi, дело вкуса. Если не зажмуриваться на свет, то кроме WEB разработки есть множество гораздо более интересных (ПМСМ) вещей, которые можно делать на любых языках, в т.ч. и на java.
И тут Swing весьма выручает. Он позволяет писать GUI произвольного уровня, трудно отличимые от Delphi или С++.
Но да, это не массовая разработка (клепание) интерфейсов для интернет-магазинов на стандартных компонентах вокруг Spring + Hibernate, а творческое дело, требующее размышлений, универсализма и базового образования в вычислительной технике.
Например, так:
А может. ещё какой метод есть, более простой, поищи в Инет, пожалуй.
Далее, соответственно, создаёшь окно, устанавливаешь в начале. перед его показом, непрозрачность 0. Затем в цикле, лучше по таймеру или даже в нитке с засыпанием (sleep с каким-то интервалом), повышаешь непрозрачность до 1.