При внесении осм даных в рабочую базу можно дропить ид безтеговых точек, будет желаемое. Коррежить уже отработанную давно работающую систему… ну вы поняли.
Это бзик такой в ОСМ - любая операция должна сводиться к препроцессингу и внесением в базу - на меньшее не согласны ))
Я понимаю что никто ничего не изменит, но представим обычный файл osm-xml и операцию геокодинга point-in-polygon. Сколько телодвижений надо сделать и сколько ресурсов требуется сейчас, а сколько - если каждый вей будет состоять из готовых координат (shp).
Cуть проста как три рубля, заменить одни id - 64-битные в текущем варианте + 64 бит на саму координату (итого 128 бит, которые предварительно нужно транслировать через mapped array), на другие id, готовые 63-битные координаты. Это также решает вопрос с мертвыми id, которые висят в базе впустую. Кто-то нарисовал криво-косо, или вообще фейк - id уже заняты и никогда не вернутся в общий пул. Когда пул закончится, будем работать с 80-96-128-bit id ))
(added)
Где бы посмотреть статистику сколько нодов в ОСМ имеют минимум один тег, т.е. несут функцию POI…
(added2)
В памяти всплывает что основной базе ОСМ данные переехали с MySQL на Postre/PostGIS. Может они уже хранятся шейпами ? В этом случае достаточно добавить протокол обмена в дополнение к osm-xml, чтобы не гонять данные туда-обратно через node id.
- Сейчас могут быть 2 точки с одинаковыми координатами, но не связанные. Если две линии используют одну точку (один node ID), то они связанны. А если нет - то не связанны. В этом случае можно рисовать многослойную и т.д. геометрию и будет понятно, что с чем связано.
Если точка будет иметь только координаты, тогда будет не ясно - связаны ли разные объекты, использующие точку с одними координатами.
Вот, например, если сейчас нарисован лес и река, граница “в стык” - по одним и тем же одним точка. Сейчас если двигаешь точку, двигается граница и того, и другого. А если точка будет иметь только координаты, тогда надо будет отдельно двигать обе точки отдельно или выделять все точки в данном месте. - Если не будет связи геометрии, чаще будут происходить наложения и разрывы нарисованного “в стык”. Подвинул лес на 1см - и его граница оторвалась от границы реки. А то и где-то оторвалась, а где-то наложилась.
А если всегда подразумевать, что одинаковые координаты означают связь геометрии, то будут происходить случайные “прилипания” точек одних объектов к другому в процессе смещения и т.д. - Если точки всегда лежат на координатной сетке, то при каждом повороте, масштабировании и т.д. будет деградировать точность геометрии. Нарисовали строго прямые углы, повернули несколько раз - оп, они уже не совсем прямые. Сейчас геометрия “деградирует” только при загрузке в базу (ну если в JOSM рисовать).
https://taginfo.openstreetmap.org/reports/database_statistics
Number of nodes with at least one tag: 109 710 280
Percentage of nodes with at least one tag: 3.27%
http://resultmaps.neis-one.org/osm-discussions?c=Russia#2/48.5/98.6
Контора пишет - комментарии к наборам правок! Оо
Нужно ещё учитывать что безтеговые точки могут быть в отношениях. Удалять безтеговые точки просто так это вообще-то, моветон, сначала нужно убедиться в отсутсвии предков (линий отношений).
Нужно ещё учитывать что безтеговые точки могут использовать в двух way или отношениях. И скачивание предков общей точки приведёт с целостным данным хотя бы на этой части.
OverQuantum примерно то же сказал.
chnav, в путаете исходники и скомпилированную систему.
действительно никто в здравом уме не будет использовать исходники в работе, они для этого не подготовлены. исключение - скриптовые языки, да и то в них используется для ускорения работы предкомпилированный байт-код.
явный пример ядро линукса, на кернел.орг лежат исходники, содержащие в себе огромное количество различного кода для кучи различной аппаратуры. А конечный продукт, ввиде скомпиленного ядра содержит только то, что нужно, плюс вместо текстовых индентификаторов функций в нем используются прямые указатели на нужные участки кода. Если бы в исходниках вместо человекочитаемых имен функций/переменных использовались машиночитаемые указтаели-индентификаторы (как в скомпиленном варианте) то это была большая проблема для редакторов исходников.
самый большой проблемой в свете высказываний, на мой взгляд является то, что в осм есть апи только к исходникам.
Нашелся бы умный человек, создавший апи для конечного использования, к примеру выдаче объектов в виде gejson, аль чего подобного, где без дополнительных запросов и разбора структуры, сразу имеется имеется список точек для отображения, то таких вопросов бы не возникало.
Попробовал. Действительно около 10 метров, и есть свежие, но на многих снимках облака. Раз в 12 дней превращается в “примерно раз в год”.
Но интересно, что там помимо видимых каналов есть ещё 9. Вот полный перечень с базовыми длинами волн и разрешением (отсюда):
B01 - 443 nm, 60m (visible blue)
B02 - 490 nm, 10m (visible blue)
B03 - 560 nm, 10m (visible green)
B04 - 665 nm, 10m (visible ~red)
B05 - 705 nm, 20m (VNIR)
B06 - 740 nm, 20m (VNIR)
B07 - 783 nm, 20m (VNIR)
B08 - 842 nm, 10m (VNIR/SWIR)
B8A - 865 nm, 20m (VNIR/SWIR)
B09 - 940 nm, 60m (VNIR/SWIR)
B10 - 1375 nm, 60m (SWIR)
B11 - 1610 nm, 20m (SWIR)
B12 - 2190 nm, 20m (SWIR)
Есть идеи, можно ли какую-то информацию извлечь из таких каналов, сверх RGB из B02+B03+B04?
Можно ли отличить, скажем, заболоченный лес от обычного?
RGB вообще мало для чего пригоден. Можете попробовать 3+5+10, например. Материалов по композитам Landsat очень много, можно грубо прикинуть соответствие диапазонов и поэкспериментировать. Результат, надо помнить, зависит от времени года и погоды перед моментом съемки, полностью универсальных решений тут нет.
Можно попробовать оттолкнуться от этих комбинаций каналов: http://gis-lab.info/qa/landsat-bandcomb.html
Хоть там и на примере Landsat, но есть ссылка с соотношением канала и длины волны.
А это из каких соображений комбинация, если не секрет?
Я что-то не вижу у Landsat-а аналогов B05 и B10.
Спасибо, буду пробовать B08,B04,B03 (4,3,2); B11,B08,B04 (5,4,3) и B12,B08,B03 (7,4,2)
Из соображения участков спектра, в которых существенно разные поглощающие свойства наблюдаются у зеленой массы, воды/не воды и сухой/влажной земли. Но для каждого конкретного случая может требоваться что-то свое.
А никто по Wikimapia API не подскажет?
Запрашиваю выгрузку небольшого региона через getbyarea, а там части объектов с карты нету.
Например, в bbox=34.9652,57.4168,34.9771,57.4210 - ничего нет, хотя на карте например вот домик http://wikimapia.org/34303066 и ещё дофига вокруг.
В том числе их пример-форма такой же результат даёт. Такое впечатление, что объекты после id~34000000 через getbyarea не выдаются, хотя через getbyid - выдаются.
P.S. Мне не для обрисовки.
Что делают то ?
Спасибо.
Данные в 10м канале, оказались плохие(?), информативных всего 2 бита или около того. Взял вместо него 11й.
В итоге экспериментов больше всего похожий на правду результат даёт деление данных B05 на B11. Где больше 1 - или водоём или река или болото. Подозреваю, это некая общая “влажность” растительности, т.к. на снимке от 1-го мая поля почти чёрные, а на августовском - довольно светлые. Возможно, где-то я получаю False Positive на особо увлажнённом лесе. Обрисовывать пока не буду, попробую проверить на местности за сезон.
В практике ДЗЗ считается, что полностью автоматическая классификация данных оптического диапазона без данных, которые собраны на местности, невозможна. Возможна только в совмещении с радарными данными среднего или высокого разрешения.
Тут один пользователь наплодил дубликатов в редакторе iD
Это разве возможно?
11 дорог в одном месте.
один из changeset-ов
https://www.openstreetmap.org/changeset/39215501#map=12/42.6082/59.6322
Сегодня зашёл к знакомым ДЗЗ-шникам, они меня ткнули вот в эту страницу:
https://www.harrisgeospatial.com/docs/CanopyWaterContent.html
Для Moisture Stress Index по Sentinel-2 надо данные B11 делить на данные B08, грубо говоря.
Попробовал, результат довольно похож на то, что я получил выше, хотя реки и чистые водоёмы перестали подсвечиваться.