Ваши аналогии к проблемам ПО не имеют отношения.
Аналогия тут ближе к ситуации вокруг 32-х битных OSM id узла, линии,…
Вот бы все боялись, что номера кончатся, и перестали бы новые объекты мапить, стали бы id экономить. Так нет же, возникавшие проблемы програмного обепечения никого не останавливали, а производители ПО успешно поддержали 64-битные id.
А как часто обновляется информация на data.mos.ru? Может быть стоит подумать о механизме каких-нибудь регулярных дифференциальных обновлений?
А какая разница. Эти столбы не “вживляются” в ОСМ, как например какие-нибудь адреса, а будут лежать просто рядом. По сути не будет никакой разницы удалить всё и залить заново, никакой новой информации ОСМ им не приносит. Т.е. в итоге куда надёжней использовать датасет с мос.ру, а не возиться в ОСМ.
Согласно информации https://data.mos.ru/opendata/61762/passport?versionNumber=1&releaseNumber=34 обновляют по мере поступления.
На прмиере часов напишем валидатор привязки по расположению. Как только убедимся что он работает, добавим генерацию .osc для обновления данных по тегам и предупреждения о сильном расхождении координат.
В случае полного импорта столбов можно будет свести дело к валидатору для ручного подтверждения измнений. В случае неполного может обкатать технологию на столбах с вышками мобильной связи по той же самой схеме отслеживания измнений что и для часов.
Допустим по парку в 600 га столбы вживятся. И по вышкам мобильной связи тоже. Нужна оценка вживляемости по этим ограниченным примерам по которым можно судить об адекватности всего набора данных.
Вы тут всё упираете в качество данных, а я говорю об их сути, вообще не взирая на качество. Сейчас в ОСМ 0.0% столбов от существующего. Это чуждый для маперов объект, и влив 100500+ таких объектов, вы ни как не заставите их прижиться.
Эти столбы самодостаточный, полноценный и готовый набор, ОСМу нечего предложить ему.
В качестве предварительного итога.
Запланированы три работы по оценке качества.
Выводы для себя:
Приходится ставить многоточие и брать длинную паузу на исследовательскую работу.
Беспредметный разговор.
В соседней теме RocketData предлагает для импорта различные POI. Только там количество объектов = несколько сотен за пару недель (суммарно, разделено на пакеты по бренду). И те, кому это интересно, проверяют эти данные.
А кому могут быть интересны столбы? На этом портале очень много данных, которые гораздо более полезны для сообщества (кому нужны столбы?) И как быстро проверять точность данных? Сколько времени уйдёт на полный импорт?
Вы, кстати, сами проверяли качество данных до создания темы? Половина столбов внесена нормально, а половина несколько разных столбов в одной точке. Как собираетесь проверять эти данные?
Также есть проблема с точностью данных, здесь как подложка использована 2ГИС и, кажется, некоторые столбы находятся не совсем там, где они должны быть.
В общем, Вам уже сказали в одном из сообщений. Если считаете, что нужно вносить именно эти данные, то выбирайте какой-нибудь небольшой район пробуйте. Но я рекомендую заняться каким-нибудь другим импортом. Вернуться обратно к столбам можно будет в любой момент.
Так сами параметры качества и их желаемые значения зачастую именно рождаются в процессе обсуждения, а зачастую только в процессе реализации.
классика, не первый раз за эти годы
Вот это уже предметно. Не факт что основная подложка при создании БД 2ГИС, но внутридворовые столбы пешеходных дорожек и площадок можно отсеять. Вот и один из принципов отсева.
Почему сразу вносить? В названии темы: собираем ОТК. Нужно понять что именно мы имеем во всей конкретике.
Собственно, я так и делаю. Сейчас вылеживается импорт по часам с того же самого портала.
Рассмотрим: “нам это не надо по этим, этим, этим и еще вот этим причинам”. Рациональное обоснование, да ещё с картинкой, появилось только за 2 реплики до Вашего заявления, ув. literan. Указанная там фильтрация отсеивает не менее 20% набора данных. То есть значение слова в Вашем высказывании “нам это не надо по этим, этим, этим и еще вот этим причинам” прояснилось только 2 реплики назад.
Что касается “сообщество недееспособно!”, то не нужно игнорировать важное и изначальное замечание: в качестве ОТК.
От Grass-snake
Небольшому кругу специалистов и моделистов. Не возразишь.
Предлагайте. Передам скрипты и поддержу обсуждение в соседних темах.
Быстро не нужно. Пока нет идей кроме объхода и осомтра. Надеялся что кто-нибудь сможет предложить исследование данных на уровне операторов PostGIS, чтобы самое подозрительнео вырезать а самое предположительно достоверное выборочно проверить.
Можно через maproulette или аналогичную службу на много месяцев запустить ручную выверку участков. Дело не в скорости, а в качестве.
Посмотрел случайные места, увы, качество данных низкое:
Спасибо, Grass-snake! Обсуждение пошло по существу.
Это общая закономерность. Подозревается отставание данных на год или больше. По хорошему, мы обнаружили задачу для фильтрации. Подозрительны не только школы и детские сады, а также собачьи, спортивные и детские площадки.
Вот этого не заметил, кроме одного специфического случая на парковой аллее. Можете раскрыть утверждение или просто назвать код столба, где вокруг дубли?
Да, увидел. На отдельных удицах до 10-15%. что, увы, обесценивает более-менее простой перенос. Для исправления получается процесс с использованеим проекции столба на дорогу через ST_ClosestPoint, линии от столба до дороги и среднего расстояния в зависимости от типа дороги. Слишком сложно считается и долго.
PostGIS + DBeaver на материалах материализованного представления “1 Столбы data.mos.ru” из https://github.com/mkgrgis/OSM_clock_mos/blob/main/PostGIS%20часы%20Москвы%20Моссвет.sql#L251
Что скажите?
Я пользовался стандартным функционалом портала открытых данных, там карта группирует рядомстоящие точки. Возможно в исходных данных данные отличаются.
Я имел ввиду не исключать данные, я имел ввиду что данные очень сильно проверять, даже на качественных спутниковых снимках столбы не видно.
Я не представляю как проверять эти данные.
ЯПанорамы, mapillary, survey, дронофото, …
При таком размере значка столба группировка скорее препятстсвует просмотру положения столбов, чем способствует. На рисунках из Вашей, Grass-snake, реплики и из моей это хорошо видно.
Нисколько. Представление фонарных столбов было получено самым тупым способом, если Вы заглядывали в скрипт PostGIS.
На первом исследовательском этапе принято пытаться фильтровать сомнительное подмножество. После выясняется возможна ли нормализация того, что обозначено как некачественное.
Вывод по набору данных
Столбы на проезжей части слишком частые, есть глюки дублирования и отставания от реальности на год или больше. Особенно подозрительны школы, детские сады, собачьи, спортивные и детские площадки.
Автоматизированный импорт без предварительной нормализации не целессообразен. Ее алгоритм обещает быть сложным. Опираясь на три содержательных отзыва по выборочной проверке данных считаю нужным прекратить обсуждение импорта данных по столбам.
В сухом остатке имеем три возможных работы по имопрту в ОСМ ограниченных подмножеств набора данных по столбам.
Импорт отлежался. Прошу посоветовать куда дальше. Попробовал подписаться на Talks:ru. Отправил сообщение и тишина. Ни ответов ни просто сообщений нет.
Обновление: ошибся веткой форума.
Ничего не отлежалось.
Сообщество против импорта, в теме один голос за импорт и все остальные - против.
Я предлагаю тему этого импорта закрывать, по причине выше.
Дальше попробовать на маленьком кусочке и попробовать его довести до ума.
— Будет прикидка трудозатрат при масштабировании процесса.
— Появятся отзывы, основанные на фактическом материале проведенной пробы, а не на теоретических прикидках.
Вообще не в ту тему написал… Ошибся веткой.
