Лес, просеки и кварталы лесничеств

А где можно посмотреть соответствие значений растра классам?


GRASS 6.4.0RC4 (EPSG_32635):/mnt/raid0/data/tmp > r.stats -l lceugr100_00_pct_reclass
 100%
1 Continuous urban fabric
7 Mineral extraction sites
8 Dump sites
10 Green urban areas
12 Non-irrigated arable land
18 Pastures
20 Complex cultivation patterns
21 Land principally occupied by agriculture, with significant areas of natural vegetation
23 Broad-leaved forest
24 Coniferous forest
25 Mixed forest
26 Natural grasslands
27 Moors and heathland
29 Transitional woodland-shrub
30 Beaches, dunes, sands
32 Sparsely vegetated areas
35 Inland marshes
36 Peat bogs
37 Salt marshes
41 Water bodies
* no data
[Raster MASK present]

Может быть тут кое-что можно еще убрать.
Теперь надо как.то бороться с недоделками grass: v.split не умеет работать с полигонами,
и непонятно как заставить v.build не создавать острова и ограничить число вертексов в area.
Можно пытаться сделать v.to.points, потом v.delaunay и прибить все треугольники принадлежащие островам.
При этом получится порядка 5 миллионов треугольников на сцену :wink:
Я конечно, сразу взялся за большую и очень сложную задачу, в местах с бескрайними полями все будет гораздо
проще, это видно даже по южной части моей сцены.
Но если всерьез думать о классификации IRS, то эти геометрические проблемы надо как-то решать.
С полигонами по 200000 нодов в “outer” и 10000 “inner” островов, cо своими вложенными полигонами
далеко не уедешь.

Другой вариант - это резать сцену на мелкие квадраты, обрабатывать и заливать данные по квадратам.
Тогда появятся сдвоенные ноды на границах, и нестыковки. Но это можно пережить.

Насчет лимита нодов, у меня были мысли делать это в PostGIS + pl/SQL.

  1. разделяем мультиполигоны так, чтобы у полигона был 1 outer, но по идее при классификации таких и быть то не должно.
  2. берем outer мультиполигона находим две ближайшие противоположные по порядку точки и получаем два куска outer-а.
  3. замыкаем эти куски получаем два полигона p1 и p2
  4. делаем intersect(mp, p1) и intersect(mp, p2) получая таким образом два куска исходного mp.

Пункт 2 скорее всего нужно будет подточить, чтобы не разрезать С-образный полигон по концам, т.е надо еще проверить лежит ли внутри outer-а.
Еще можно брать не строго противоположные узлы, а противоположные ± 10% или что-то подобное.

Если убрать Финский залив и Ладожское озеро, основные источники coastline проблем,
то выяснится, что практически все остальное это острова внутри двух огромных “outer” полигонов “хвойный лес”.
Если их убрать, то гораздо легче и приятнее будет работать.
2km сетку из mapsets держу тем не менее про запас.

После 10 суток раздумий вычислитель выдал результаты классификации.
Эти два класса тоже никуда не годятся, надо убирать и переклассифицировать.


8 Dump sites
10 Green urban areas

Многие дороги и сухие пески попали вот сюда, но видимо ничего не поделаешь:


7 Mineral extraction sites

Буду задавать 512-пиксельную сетку (utm35, 15m/pix), векторизовывать, впатчивать
дорожную сеть и прочие линейные объекты, зачищать. Для заливки не хватает v.out.osm,
придется написать. Посмотрим, как с этими результатами справятся конвертеры и рендереры.

А кто-нибудь рассматривал возможность использования данных GlobCover? http://ionia1.esrin.esa.int/index.asp
Правда, это растр с разрешением 300 м на пиксель, зато классифицированный. Для крупных участков может пригодиться?

Классификация MERIS за пределами Европы иногда совершенно непотребно выглядит, даже километровый MODIS и тот точнее.
Если для вашего района есть безоблачные летнии сцены Ландсат, то скачайте их и попробуйте.
Но сначала стоит, как здесь уже упоминалось, вычислить NDVI (идеально и альбедо), по ним можно очень неплохо
нарисовать воду (моря, озера, крупные реки), и использовать уже сам ОСМ в качестве тренировочной карты.

Вышел на финишную прямую, осталось отрезать ту часть, которая лежит в Финляндии и можно будет заливать тестовую версию.
Это будет довольно большой импорт.
Так как я в этой области профессионально не работаю, получил интересный опыт :slight_smile:

Когда можно будет увидеть результат? А то у нас в крае лесов куча, и хотелось бы это все разнообразить.

На выходных. По 3G из дома не осилить, слишком медленно.

Залил пробный кусок из 3x3 тайлов по 256x256 15 метровых пикселов. Смотреть здесь
http://www.openstreetmap.org/?lat=60.95675&lon=29.12733&zoom=15

http://www.openstreetmap.org/browse/changeset/4450170

Видна неприятная техническая багофича векторизатора r.to.vect -s ,
связанная со срезанием пол-пиксела на углу g.region, которая потом
усугубляется генерализатором. Я посмотрел исходники GRASS, это можно
поправить, но придется пересобирать GRASS, что сильно усложнит использование
методики “нормальными” людьми :wink:
Мапник весьма быстро справился с рендерингом, но style у него конечно довольно примитивный,
типы леса неразличимы и видны только границы полигонов.
Еще хочу сказать вот что: если для вашей местности есть безоблачный landsat7, не
тратьте время на прорисовывание берегов водоемов и границ лесов!!!
Это все равно все придется стирать, и годится только как тренировочная карта.
Рисуйте только “чистую” воду и “чистый” лес данного типа.
То же касается и использования fuzzer. Он не умеет отделять прибрежные болота от воды,
поэтому при правильной классификации эти труды придется опять же стирать.
Тип леса тем более.
Есть много других технических моментов, давайте для этой проблематики открывать отдельную тему.

Ой, какая знакомая картинка. Я неделю назад в грассе баловался с разными векторизаторами, получил такое же лоскутное одеяло :slight_smile:

Так это, сделай эту фишку конфигурабельной и патчик в апстрим отправь.

Как тут водится, я спрошу, кто даст вам право стирать нарисованные, например мной, леса? http://osm.org/go/0t0EYW
Это же вандализм, о котором нужно сразу жаловаться маме писать в DWG!


Оно?

Я бы все-таки исходил из того насколько результат такой классификации соответствует groundtruth. К сожалению в обозначенном квадрате я не бывал, но можно глянуть вот сюда, хотя там тот же ландсат по всей видимости.

Там вполне отчетливо видно, что с landuse=residential классификация явно кривоватая, хотя это видно и без спутника, т.к. ситуация в которой жилые кварталы располагаются вокруг карьера мне видится очень маловероятной, а там такое сплошь и рядом.

Лес и вода местами неплохи - хотя я бы подумал бы про snakes генерализацию в грассе - мне она вполне не плохиве результаты давала.
landuse=farm(даже при учете того что имелся ввиду farmland) довольно сомнительный, кмк.

В общем на данный момент вижу смысл только в выборочной выгрузке классов, например леса и воды.
И ИМХО мультиполигоны везде мне кажется не очень удачная идея.

Он, наверное, о случае, когда рисуешь какую-то область, видишь кривой лес, и рисуешь новый, понимая, что проще стереть и нарисовать заново.

Вы совершенно напрасно иронизируете. Звонок в полицию вы тоже сравниваете с “жалобой маме”?

Мне бы никогда и в голову не пришло стирать леса в Подмосковье или Краснодарском крае. Я там никогда не был,
и какие и где там леса знать не могу. Для работы алгоритма классификации в любом случае
нужна хоть какая-то карта ground truth, это статистический анализ многоканальных радиометрических измерений.
Ваша карта вполне подойдет, вопрос заключается только в том, по каким классам проводить классификацию.
CORINE landcover (CLC) это единый классификатор из 44 классов применяемый в ЕС. Мне пришлось по разным
причинам, описанным выше, уменьшить число классов до 18, среди них все 3 типа лесов.
К тому же надо различать “вандализм” геометрический и аттрибутивный. Уточнение геометрии лесов и озер по Landsat
никак вандализмом быть не может.
В том районе, который я добавил, полигоны лесов можно вообще пересчитать по пальцам, а озера нарисованы либо
очень грубо, или неточно с помощью fuzzer и lakewalker. Леса, болота и озера составляют там 95% площади,
плотность населения очень низкая.

Там обычный композит ландсат, он не может быть точнее по определению. Ужо задумался о районе Сайменского канала (несколько западнее).

landuse=residential это очень тяжелый радиометрический класс. Шиферные крыши домов практически невозможно отделить от “minerals extraction site” при геометрическом разрешении landsat7 в
мультиспектральных каналах (30 метров). К тому же ground truth/статистика взята из Финляндии, так что без ручной работы все равно никак.
Это открыто признают и профессионалы со всеми их недешевыми ArcGIS, PCI Geomatics и eCognition/Definiens, что качественная классификация без ручной работы невозможна.
Тут бы помог GeoEye или на худой конец IRS, будем разбираться с лицензионными и прочими проблемами :slight_smile:

v.generalize не использовал, только v.clean, по одной простой причине: он портит границы тайлов еще больше, чем то что есть сейчас. Придумаете как объяснить ему не трогать вертексы
на границе g.region, буду очень рад услышать.

Так написано в
http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover/Tagging_scheme

Болота тоже неплохи. Остальные надо смотреть.
В перспективе надо править то, что есть, пересматривать классификатор и использовать ОСМ в качестве ground truth.

Это результат ogr2osm
http://wiki.openstreetmap.org/wiki/Ogr2osm
Справится ли polyshp2osm.py из http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover/Corine_Data_Import
с мультиполигонами не знаю.
К тому же я этого конкретного polyshp2osm.py для corine не нашел, даже полазив по французскому форуму.

Оно :smiley:
Тем не менее, накаркиваю для liosha скорое переписывание конвертера на с/c++.

Я тоже видел что он границу тайла ни сколько не уважает, поэтому брал изначально сильно больший тайл и обрезал только в конце, после генерализации.