Боюсь что очень много вопросов одним постом Вы подняли Так вот сесть и за 5-10 минут не ответить Поэтому так мало желающих прокомментировать Ваш довольно интересный пост.
Минимально необходимый набор: addr:street + addr:housenumber + полигон place вокруг.
КЛАДР коды на самих улицах раньше периодически добавляли/обновляли по результатам работы бота. В данный момент за их актуальностью никто не следит и никто не использует, так что можно считать рудиментом. А кода на домах вроде используются конвертером pocketgis. Почему именно так сделано - вопрос к их авторам.
Для удобства формирования почтового адреса и для поиска. Иначе для этого придётся держать сторонюю базу.
Номера присваивают для кадастрового учёта, как минимум. А если строению присвоен номер - то и в OSM было бы неплохо его отразить.
В JOSM-е есть штатная заготовка для задания адресных данных по общепринятой схеме addr:*.
Для контроля есть несколько онлайновых валидаторов, можно ими пользоваться:
17 не нашел (интерполяция для z=13), но есть “оригинальный” 21MB (20281x25821 пикселов 15x15 метров, UTM35)
При 10 цветах в палитре, и прозрачных краях из-за наклона полярной орбиты файл
очень хорошо сжимается.
Часть сосновых лесов определенного вида неправильно классифицирована как болота,
их надо правильно нарисовать в OSM, тогда можно провести переклассификацию.
$ gdalinfo /mnt/raid0/data/corine_class_all_norm_bl512.tif
Driver: GTiff/GeoTIFF
Files: /mnt/raid0/data/corine_class_all_norm_bl512.tif
Size is 20281, 25821
Coordinate System is:
PROJCS["WGS 84 / UTM zone 35N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",27],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","32635"]]
Origin = (438600.000000000000000,6932700.000000000000000)
Pixel Size = (15.000000000000000,-15.000000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=DEFLATE
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 438600.000, 6932700.000) ( 25d48'26.29"E, 62d31'12.72"N)
Lower Left ( 438600.000, 6545385.000) ( 25d55'47.67"E, 59d 2'36.52"N)
Upper Right ( 742815.000, 6932700.000) ( 31d42'28.12"E, 62d26'45.02"N)
Lower Right ( 742815.000, 6545385.000) ( 31d13'32.13"E, 58d58'44.17"N)
Center ( 590707.500, 6739042.500) ( 28d39'55.93"E, 60d46'35.35"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette
Наверное, я припозднился с этим постом, но раз уж меня выше обсуждали, то выскажусь. Мультиполигоны с составным outer использую в тех случаях, если объект имеет сложную форму, и обводить контур несколько раз неинтересно. В большинстве случаев обхожусь обычными полигонами.
Сосновка “пропала” потому, что курсор всё время попадает на объекты forest, а не на сам парк. Благо этого фореста 95% парка. Если хочется проверить наверняка, наведите курсор на южный угол парка, где нет деревьев.
Кстати, как считаете: может будет лучше объединить все участки однотипного леса (берёза, сосна, лиственница, берёза+сосна и т.д.) в несколько больших мультиполигонов, или оставить как сейчас кучу мелких? Если объединять, в каждом будет не одна сотня линий. С другой стороны, их можно будет выделять и редактировать за один раз, что по-моему намного удобнее.
Объединять несвязаные области имеет смысл только если они считаются составными частями одного объекта. Однотипность леса ещё не есть признак единого объекта. Если такового объекта нету, то лучше не объединять.
эмм. А что у него со скорость? Там 100500 правок по ~300 точек. Войтловка прекрасно видна на Bing, да и судя по линиям изгиба именно с него и нарисована. Для того чтобы нарисовать дороги в Тосно хайрес не нужен. Их прекрасно видно на IRS.