Это твой MatLab такой медленный?

Кидай. Можешь pull-request сделать.

Добавил в коллекцию синтетических карт https://github.com/Mark-Kovalyov/islands/tree/master/heightmap-synthetic

Хм. А я не могу найти Median Blur в редакторе Gimp. Помнится мне что он там был в старых версиях?
Удалили? Кому он мешал. Точно уж патент на него не нужен. Алгоритм тупой до безобразия.

Кстати предлагаю подумать над его оптимизацией.

Медиана считает яркость 8 соседних пикселов. Сортирует. Вычисляет медиану (среднюю
величину которая делит эти 8 яркостей на две группы. И ставит это среднее значение
вместо пиксела.

(Я могу ошибаться учитывается ли сам пиксел? ХЗ. Но можно учитывать. Хуже не будет).

Фильтр - дешевый и жлобский но очень хорошо удаляет с фоток случайные битые пикселы
и яркие всплески. В отличие от матричных фильтров - не имеет ярко выраженного эффекта
фильтра низкой частоты. Тоесть картинка в целом не теряет деталей.

Вот я и подумал что Медиана замечательно уберет эти концетрические борозды по центру
дорожек Вавилонской башни.

В и других картинках где есть резкая трещина или ямка - будет все красиво замазано.

Астанавитесь! (с)

Спираль готова. Я ее добавил в коллекцию синтетических тестов. По спирали работы закончены.
Еще я сделаю пирамиду и бассейн. И всё и можно приступать к разработке с тестами скорости.

Кстати я на клеточной тетради нарисовал свою идею топологического затопления острова. Но это
только для местности особого свойства. Где есть большие плато.

В топике есть основная цель. Ее озвучил автор. И ее реализовал Саша Шарахов.
На этом топик можно закрыть.

Остались только скучающие завсегдатаи которые чего-то себе придумывают.
И я в том числе. Но вы - можете не беспокоиться по этому поводу. Многие
топики sql.ru текут в таком режиме.

А какой из этих пунктов был непонятен 22091467 ?

Я догадываюсь что я иногда бываю слишком краток. Но никто - не спрашивает.
И я думаю что все в теме. Или всем пофиг.

Да это непринципиально. Браузеру тоже непринципиально было что поддерживать HTML5 или XML.
XML даже выгоднее. Строгий и однозначный парсер. Но люди подвели. Не умеют они писать в XML.
Такие они несовершенные.

А по сабжу. 100% данных по высотам (реальная картография или искусственная украденная из комьютерных
игр или созданная на Corel Bryce) всегда экспортируется в растровом формате. Не в графовом. И я когда
ставил задачу - исходил из предположения что найти такие данные будет легко. В противоположность
если вы решили играться с хексагональной сеткой то вы будете постоянно терпеть неудобства конвертации
из обще-принятого формата в свой собсвтвенный. Опять-же я исходил из возможностей людей а не из
мощности вершин графа.

В некотором вырожденном случае мы могли вытянуть остров в одно-мерный. Математика тут и там будет
одинакова.

Против графов я не имею ничего против даже более того. Моя идея основана на том что остров даже
меняя уровень затопления - имеет фиксированную топологию высот. И эта топология может (и должна
быть задана в виде графа). Это облегчит алгоритм затопления (особенно на итерациях).

Какую задачу решаем? Я почему то предполагаю, после очередного дня с паяльником что одно жало лучше другого. Абсолютно не формализовано. Хочется как лучше.... Ну.. Для мира... Чтобы был безоговорчный лидер.
Я вам предлагаю ... просто отдохнуть от этого топика. Ну рано вы сюда зашли. Вообще всё что было написано вами выше
про стандартизацию и интерфейс исполнителей - это никому не нужно я уже понял. Люди не хотят ничего делать
под чужой интерфейс (я кстати его предлагал в самом начале).

Чтобы провести бенчмарк или сравнение алгоритмов - должны быть установлены одинаковые правила игры.
Тоесть - одинаковые исходные данные (остров). И одинаковое железо (это значит я должен взять алгоритм
Саши и адаптировав его (боже упаси делать мне нечего) - заставить его (алгоритм) работать с квадратной
сеткой высот чтобы просто сравнить его с алгоритмом пользователя iOracle, который писал код на Java
и использовал растровые картинки как исходные данные. Боже упаси сравнивать Делфи с Java,
где на коротких дистанциях (меньше секунды) Делфи побеждает сразу. Вобщем нету времени
на причёсывание чужого кода. Когда я публиковал задачу на бенчмарк трассирующего луча
на разных компилляторах - Тяпничный бенчмарк CPU (part-1) я понял что там так и не решена главная задача. Стандартизация отчотов
о бенчмарках и формализация процедуры деплоя (я хотел это сделать через Docker но руки не дошли).
Вобщем к чему я все это. Рук не хватает. Некому делать. Понимаете? Опенсорц - это такая
ненадежная штука. Нет договорных отношений - результат можно ждать завтра а можно
ждать 100 лет и все равно никто не сделает. Я просил некоторых мемберов с этим помочь
но никто не взялся.

По поводу целей. Я уже писал где-то что для меня многие топики - вторичны. Цели у меня на самом деле
могут быть другие. Например мне интересно изучать Rust и Haskell и пытаться применить их где-то в
задачах .. ну если не продуктовых то хотя-бы здесь. В форумных. Мне интересно искать различные
способы распараллеливания алгоритмов с целью запуска их в Amazon EMR (Spark/Hadoop). Опять-же.
Графы - это челлендж. Графы - сопротивляются параллелизму. Они липнут к блокировкам. Их трудно
сегментировать для независимого процессинга сегментов. Мне также было интересно погонять
OptimisticTimestamped locks (Java) на графах только для этого нужно было мясо. Много мяса.
Я имею в виду алгоритмы и цель - минимизации времени. Мне также было интересно понять
как Haskell обходится вообще без переменных и конкуренции решая сверх сложные задачи.

Вы там что-то писали про геологию и бурение нефти. Прекрасная постановка. Но я о ней вообще не думал.
Но если вы наполните этот (безумный) топик материальным и физическим смыслом (расчет объемов
залежей) или скорость затопления долины в случае аварии на дамбе - то я буду не против
и очень даже рад.

Вот набросок. Моей мысли по топологичесому "затоплению". Матрица 8х8 высот представляет
собой микро остров (слева) и справа ей соответсвующий граф высок. Для расчета затопления
нам достаточно графа. Остальные дейтвия - публикация картинки с водой сугубо сервисная.