Учтывая количество столбов ок. 520 тысяч объявляю сбор команды ОТК чтобы понять, может ли указанный набор данных принести пользу OSM. В этой теме предлагаю вести обмен мнениями о качестве данных и обсуждение скриптов обработки в PostGIS.
Столбы имели бы хоть какой-то смысл если бы их без проблем было видно на подложках. Поэтому пока у нас нет аэрофотоснимков это будет лежать в базе грузом (по большей части мешающим), ибо уточнить данные проблематично. В итоге как внесли их так они и останутся, даже большее скажу, часть наверняка удалят. И проще это держать нуждающимся отдельным датасетом у себя.
Если между точками из разных источников менее 10 метров, то это, вероятно, одна и та же точка.
Отфильтровать вероятные дубли можно так:
Взять точки столбов из ОСМ.
Построить вокруг них полигоны в виде круга радиусом 15 м. Удалить из импортируемого файла все точки внутри этих полигонов (типовые операции в любой серьёзной ГИС).
Примеч.: число 15 можно немного поменять опытным путём на иное.
Нужны ли столбы в ОСМ? Сами по себе вряд ли, а вот как вспомогательные данные для мапинга иных объектов могут быть полезны, так как задают обычно край проезжей части.
Мне не мешают (местами замаплены по снимкам высокого разрешения и GPS).
В Дюссельдорфе с Вами не согласны, ув. fndoder. Чем Москва хуже с точки зрения ГИС?
Что касается края проезжей части, то приглашаю Вас оценить реальные данные если PostGIS под рукой с полугигом дискового пространства. Именно для предметной оцнеки даны ссылки на скрипты с подробной документацией процесса закачки и подготовки данных. Вот только столбы соотносятся долговато, когда в ОСМ ок. 6 тысяч, а в экспорте ок. 520 тысяч. За 4 часа считается. Если у Вас есть предложения как сделать быстрее, то с удовольствием попробую.
Попробовал строить кружочки на 5,8,10,15 и 20 метров. Каждое построение по 30 минут, нормально. Проверка точек на принадлежность кружочу из индексирвоанного поля значительно ускоряется.
Эх, fndoder… Я то думал, что уж Вы можете отличить платформу пространственных вычислений PostGIS https://ru.wikipedia.org/wiki/PostGIS от программных оболочек QGIS и ArcGIS.
QGIS больше нужен для создания и оформления картографических документов, для объединения в них разнородных источников, чем для вычислений пересечения, принадлежности и пр. В отношении крупных массивов данных QGIS как правило опирается на платформы простарнственных вычислений в БД: PostGIS, OracleSpatial, Spatialite и т. д.
ГИС вполне может и без СУБД работать, просто имея локальные файлы с данными. СУБД несёт с собой накладные расходы на многопользовательскую работу (и иные, вытекающие из требований ACID), поэтому ряд операций без СУБД можно сделать существенно быстрее.
Второй важный момент - открытое ПО, такое как PostGIS, конечно, хороший инструмент. Но в проприетарное ПО вложено на порядки больше ресурсов. Поэтому вполне может быть так, что PostGIS решает задачу за 4 часа, кручением ручек можно получить 1 час, а ArcGIS сделает всё за минуту с первого захода без доп. настроек.
Да, пробовал так в QGIS. Всё подписали и перевели, но всё равно маловато понятного, когда в ИТ прохожий. В QGIS дальше одноцветных контурных карт не пролез :(.
Да, в особенности вычисления точек на одной проекции могут замедляться. Если PostgreSQL не коллективный и запросы в 1-2 потока, то заметных накладных расходов нет.
Скорее всего именно так. Увы, мой случай плох тем, что нет ни денег на пропитиетарное ПО, ни квалификации чтобы в нём разобраться ни даже толковых консультантов. Поэтому и импорт столбов, и импорт часов оформляю как скрипт SQL PostGIS.
Как минимум, станут возможны полуручные обновления из портала открытых данных по наложенным критерям качества. Жду предложений по их выработке, можно в виде процесса для PostGIS.
По опыту других тегов могу предположить, что постепенно подтянутся местные картографы как только увидят что столбы есть.
В Москве большой объём дорожного строительства, очень быстро импортированные столбы станут неактуальными (ошибочными то есть).
Если взять небольшой город, с небольшим объёмом дорожных строек, то там ещё можно было бы столбы поддерживать, при наличии нескольких местных интересующихся.
Да не стоит льстить, ни в большом, ни тем более в маленьком, не будут поддерживать это. Есть куда более интересные объекты, которые не замаплены. Проблемы до сих пор есть в гигантскими конструкциями ЛЭП, которые 1 штука на десятки квадратных километров в округе, но и их не кто не мапит, нарисовали провода и на этом всё.
Если посмотреть Москву, то уличных столбов с историей изменений больше 5 можно сказать нет, за исключением небольшого парка (и ещё 3 столбов), да и те кто-то заимпортил, и то похоже очень плохо если их пришлось столько раз менять.
Я тоже против импорта столбов. 500+ тысяч объектов разом, которые невозможно провалидировать по спутниковому снимку, только ногами - это наповал.
Инженерная инфраструктура с детализацией такого уровня хорошо заходит в локальных ограниченных объёмах - например, в тех же парках, где один человек отрисовал его в деталях по аэрофото и может поддерживать в актуальном состоянии. В объёмах мегаполиса - без шансов. То же самое относится, например, к импорту в масштабах Москвы всех отдельных деревьев с указанием биологического вида, железнодорожных шпал, канализационных люков и т. д.
Такие заявления, чтобы не быть голословными, должны быть основаны на оценке состояния набора данных в областях дорожного сироительства. И оценке обширности областей дорожного строительства по сравнению с другими городами. Именно для этого были опубликованы скрипты PostGIS чтобы каждый желающий мог их воспроизвести и дать свою оценку.
Я тоже, как и многие высказавшиеся, болею за качество данных в OSM, но не хочу, чтобы решение вопроса о лиензионно совместимом источнике данных по своей беспредметности выглядело как трусость. У нас ведь тема называется “Огни Москвы”: собираем ОТК, а не “Огни Москвы”: собираем мнения без оценки качества данных.
Вот это высказывание о результате работы автора http://moscowparks.narod.ru и нескольких моих уточняющих вылазок. Массовые измнения даже не были опознаны как уточняющие систему тегов :/, а не только расположение. Не знаю, право, можно ли считать “кто-то заимпортил” комплементом в случае сбора данных на местности…
А что касается небольшого парка, то общая площадь, где размечались фонари 693,4 га, включая 230 га испорченного псевдо-реконструкцией классического парка. Именно в этой части плотная сеть освещения. При конструктивном подходе ув. freeExec мог бы догадаться, что парк был пробным шаром для сравнения реально снятых данных с импортом data.mos.ru. Кстати, один коллега сейчас именно по этому парку пытается сделать какие-то выводы и я тоже пытаюсь проверить пару гипотез по сходимости данных через PstGIS.
select *
from "Часы Москвы"."1 Столбы data.mos.ru" d
where d."Округ" = 'Зеленоградский административный округ';
можно и по районам вписать список
select *
from "Часы Москвы"."1 Столбы data.mos.ru" d
where d."Район" in ('', '')
От literan
Так тут, как минимум, описано нарушение проверяемого на местности offical_name. А что на местности с реально присутствующими столбами? Зачем мы тогда в этой теме проводим обсуждение?
