На выходных. По 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, что сильно усложнит использование
методики “нормальными” людьми 
Мапник весьма быстро справился с рендерингом, но style у него конечно довольно примитивный,
типы леса неразличимы и видны только границы полигонов.
Еще хочу сказать вот что: если для вашей местности есть безоблачный landsat7, не
тратьте время на прорисовывание берегов водоемов и границ лесов!!!
Это все равно все придется стирать, и годится только как тренировочная карта.
Рисуйте только “чистую” воду и “чистый” лес данного типа.
То же касается и использования fuzzer. Он не умеет отделять прибрежные болота от воды,
поэтому при правильной классификации эти труды придется опять же стирать.
Тип леса тем более.
Есть много других технических моментов, давайте для этой проблематики открывать отдельную тему.
Ой, какая знакомая картинка. Я неделю назад в грассе баловался с разными векторизаторами, получил такое же лоскутное одеяло 
Так это, сделай эту фишку конфигурабельной и патчик в апстрим отправь.
Как тут водится, я спрошу, кто даст вам право стирать нарисованные, например мной, леса? 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, будем разбираться с лицензионными и прочими проблемами
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 не нашел, даже полазив по французскому форуму.
Оно 
Тем не менее, накаркиваю для liosha скорое переписывание конвертера на с/c++.
Я тоже видел что он границу тайла ни сколько не уважает, поэтому брал изначально сильно больший тайл и обрезал только в конце, после генерализации.
Все v.* ни разу не уважают g.region. Хотя это конечно выход, делать сначала v.overlay на сильно больший тайл, v.generalize, а потом v.overlay на v.in.region
Еще я думаю отказаться от UTM после классификации,
перепроектировать в epsg:3857 с nearest neighbor resampling до z=13 (19.109257 m/pix)
Тогда границы моих тайлов будут совпадать с ОСМ/google, можно будет использовать ту же
нумерацию и подложку à la Komяpa.
Добавил кусок Сайменского канала
http://www.openstreetmap.org/?lat=60.8635&lon=28.678&zoom=14
его уже можно сравнить со снимками высокого разрешения.
Интересный момент - снимки летние (19 августа 2002), и “цветущая” вода в застойных частях
распознается как болото. Такой эффект виден и на нескольких озерах.
Про некоторые я знаю, что так оно и есть, а вот на одно большое озеро надо
будет летом посмотреть, действительно ли оно так “цветет” 
Интересные вещи видны из сравнения с google: при переходе лес-вода и вода-лес похоже наблюдается релаксация детектора
(эффект памяти при порогообразном изменении интенсивности излучения) либо считывающей электроники, и этот нелинейный эффект
ландсатовцами не корректируется.
Ну и погранзастава посреди леса (согласно викимапии) на ландсате однозначно детектируется как landuse=residential
ИМХО это все-таки баг. Патчик для grass70, с которым все работает как надо.
С epsg:3857 у grass70 есть проблемы, которых нет у grass64, но их удалось обойти.
Остался tile alignment с ОСМ, и можно приступать к большой загрузке.
Index: areas_io.c
===================================================================
--- areas_io.c (revision 41933)
+++ areas_io.c (working copy)
@@ -193,13 +193,32 @@
idx = (p->col - last->col);
dy = (idy > 0) ? 0.5 : ((idy < 0) ? -0.5 : 0.0); /* dy = 0.0, 0.5, or -0.5 */
dx = (idx > 0) ? 0.5 : ((idx < 0) ? -0.5 : 0.0); /* dx = 0.0, 0.5, or -0.5 */
- y = cell_head.north - (last->row + dy) * cell_head.ns_res;
- x = cell_head.west + (last->col + dx) * cell_head.ew_res;
+
+ /* do not smooth the region borders */
+ if (last->row == 0 || last->row == Rast_window_rows() || last->col == 0 || last->col == Rast_window_cols())
+ {
+ y = cell_head.north - last->row * cell_head.ns_res;
+ x = cell_head.west + last->col * cell_head.ew_res;
+ }
+ else
+ {
+ y = cell_head.north - (last->row + dy) * cell_head.ns_res;
+ x = cell_head.west + (last->col + dx) * cell_head.ew_res;
+ }
total++;
Vect_append_point(points, x, y, 0.0);
- y = cell_head.north - (p->row - dy) * cell_head.ns_res;
- x = cell_head.west + (p->col - dx) * cell_head.ew_res;
+ /* do not smooth the region borders */
+ if (p->row == 0 || p->row == Rast_window_rows() || p->col == 0 || p->col == Rast_window_cols())
+ {
+ y = cell_head.north - p->row * cell_head.ns_res;
+ x = cell_head.west + p->col * cell_head.ew_res;
+ }
+ else
+ {
+ y = cell_head.north - (p->row - dy) * cell_head.ns_res;
+ x = cell_head.west + (p->col - dx) * cell_head.ew_res;
+ }
total++;
Vect_append_point(points, x, y, 0.0);
Можно чуть подробнее про кварталы лесничеств? Видел столбики (снято к сожалению только с одной стороны):
14 | 14
1 | 2
9 | 15
4 | 2
с тем что сторона показывает на квартал, к которому относятся числа, все вроде понятно. А что значат два числа? Типа X и Y, или что-то иерархическое? Второй случай смущает - получатся у соседних кварталов числа сильно разные.
Числа это номера кварталов. Нумерация идет в пределах одного лесничества обычно с запада на восток и с севера на юг. Но лучше раздобыть квартальню карту у лесников.
Для МО можно скачать тут: http://rutracker.org/forum/viewtopic.php?t=2232316
А два-то номера что значат, один под другим? В #74 два примера столбика, не четыре.
Если на одной грани два номера, то это либо номера в разных лесничествах, либо старая и новая нумерация. Точно можно сказать только имея лесоустроительную карту.