Эстония

В таком случае, заголовок таблицы вводит в заблуждение (“Отображает здания, у которых адрес, скорее всего, указан неверно”).
Как верно - не могу сказать, но из данной фразы не вытекает понимание, что они уже были провалидированы вручную и все равно что-то не так.

Тем не менее, если бы для них был бы вызов редактора - можно было бы хотя бы посмотреть пару десятков, чтобы понять, что с ними не так.
Может, после анализа, там вполне можно будет понять, какой автоматический метод к ним можно применить.

А иначе - это кладбище записей.
Ни посмотреть, ни отредактировать, ни понять, зачем их нужно держать в списке.

Небольшая мысль в голову пришла… просто оставлю это здесь.
http://potrace.sourceforge.net/

Осталось придумать, как упростить линии…

В JOSM нажал Q, потом плагин Упростить полигон, и получилось примерно то, что хотел.

Результат:

Осталось три проблемы:

  1. Повторить без JOSM
  2. Автоматизировать
  3. Здания, расположенные впритык, лучше бы склеивать…

Конечно, оставить это как есть я не мог, поэтому допилил вручную с J, M, и снова Q…

В ОСМ она совпадает с данными мааамет, по крайней мере, на момент внесения. Harjumaa, Kõue vald, Habaja küla. Если сейчас в мааамет это алевик, видимо, офф статус изменился. Но свежими сырыми данными земельного ведомства не обладаю.

Для автоматической векторизации выглядит круто.
Но, ИМХО, если результат грузить автоматом в OSM, то нужно средство полуавтоматической валидации - показывать людям контуры домов и просить оценить хорошо ли лежит контур или нет. Если домики в Maa-amet склеены, а векторизатор их разделил - люди отметят контуры как требующие ручной корректировки. Но показывать надо не по одному контуру (как сейчас на вводе номером домов).

Есть две идеи

  1. Для стирания номеров домов
  • Выделяем по цвету заливки дома - в отдельный слой (в терминах фотошопа)
  • Выделяем в этом слое связную область (“Magic Wand”) снаружи домов, инвертируем
  • Сжимаем границу на 1 пиксель (“Contract”)
  • Заливаем цветом “дом”
    Если номера все внутри контура дома, они не захватятся в связную область и будут залиты
  1. Для векторизации
    Параметр “-a 0” - углы не скругляются кривыми.

RM87 прислал вроде бы полезную ссылку

Ну висит же:
Скачивание минутных диффов Последняя проверка: 3 ч. 23 мин. назад

Нельзя ли как-то в системный планировщик вставить проверку флажков, которые будут генерировать запускаемые скрипты,
и если нет соответствующего флажка в течении заданного промежутка времени - отправлять сообщение администратору на мобильный телефон?
Ну, можно и повисшую задачу отстреливать, если это поможет.

Сначала я использовал системный планировщик, но он не выдерживал и полдня - задача заклинивала в положении “Работает” несмотря на то, что процесс завершился. И заного из-за этого не запускалась. И помогает только пересоздание.
Подобное поведение (Scheduled Tasks appear hung in the “Running” state on Windows Server 2003 based systems) широко описывается в интернете, но ни одно решение не помогло. В моём случае даже в логах планировщика никаких ошибок, пишет в логах “Итог: Задание завершено”, а в списке задач - “Работает”. И ни туды и не сюды.

Сейчас в роли планировщика выступает мой собственный скрипт. Работает он хорошо, плюс упростилось программирование.
Единственное но - иногда задача по скачиванию виснет, причём не могу отловить, на чьей причине проблема - “планировщика”, или самого скрипта.
По какой-то причине shell_exec() не возвращает управление, несмотря на то, что вызываемый скрипт самой последней строкой пишет в лог “DONE”, и по идее ну никак не может не завершиться.

Видимо, мне надо как в анекдоте про программу, которая следит за программой, предназначенной для перезапуска программы…

Disk is full writing '.\osm2\ways_filtered.MYD' (Errcode: 28).

Кстати, вот от этой ошибки ни один “отстреливатель” не поможет…

Толку, если я либо на работе, либо сплю?

Чем полезна - не понял, но пускай валяется :slight_smile:

Да, так заметно лучше. Но всё равно линия нуждается в

  1. Приведение углов в шаг 90 градусов

  2. Удаление лишних точек

К сожалению, трассировщику нельзя просто сказать, что всё прекрасное должно быть квадратным :slight_smile:

Ничего не понял. Если в отдельный слой только один цвет - то остальная область у нас будет прозрачная, как прозрачный цвет инвертировать? :slight_smile:

Вообще, у меня такой проблемы нет, я их подтёр просто операциями с цветами (второй скрин предыдущего поста). Оставшийся небольшой мусор трассировщик просто игнорирует.

Очень сложная для программирования операция…

Кстати, из примера не видно, что у тебя со склеенными домами получилось? Должно получиться два контура…

Хорошо, подробнее:

  1. Выделяем по цвету заливки дома
  2. Сохраняем выделение в новый слой
    В этом слое дома будут белые, остальное - чёрным
  3. В новом слое выделяем связную область (“Magic Wand”) снаружи домов, инвертируем выделение
  4. Сжимаем границу на 1 пиксель (“Contract”)
  5. Заливаем всё выделенное белым
    В итоге дома и номера будут залиты белым, фон - чёрным.
  6. Инвертируем слой

Шаг 3 для программирования - волновый алгоритм заливки.
Шаг 4 - дополнительный 1 “шаг” волны на дома.

Так? Или опять не понял? :frowning:
Если нет - покажите результат на моём примере, чтобы я понял…

Если так, то у меня номера домов не только не удалились, но и стали больше, аж до разрыва самого контура.

Ну на шаге 3 надо выбирать связную область снаружи домов. Вырезы от номеров, которые не касаются краёв домов не должны при этом захватиться.

Так?

Да, но “сжать” на 1 пиксель надо после инвертирования выделения. :slight_smile:

Так я сжал… Ладно, мой вариант:

Основан на том, что цвет линии, которая нам нужна, расположен в диапазоне 160…199 (если смотреть синий канал) :slight_smile:

После удаления одиночных пикселей (трассировщик их конечно и так игнорирует, но сделаем красивее для себя):

Можно попробовать запилить свой трассировщик или доп. обработчик, который будет ортогонализировать более корректно, чем JOSM, и сшибать промежуточные точки на прямых рёбрах.
Т.е. чтобы сразу делал так:

Есть пара мыслей по алгоритму.
Но нужно понять

  1. Устроят ли нас не склееные домики. Склеить корректно будет сильно посложнее, идей пока нет.
  2. Какой формат векторизации
    а. Кто-то один обрабатывает всю страну, потом на полуавтомате проверяем
    б. Какждый векторизует кусок карты на выбор, проверяет и загружает в базу сам
  3. На чём можно запилить прогу (что хотелось бы)
  • Какой язык программирования и OS
  • Что на входе (PNG/svg/osmxml)
  • Что нужно на выходе (svg/osmxml)

Мне лично проще на C/C++/C#/VB6 под винды, брать svg или osmxml.
Ещё могу на java/perl/python/php, но если кто-то даст работоспособную обвязку.
Т.о. уже сейчас могу поэкспериментировать с доп. командой для JOSM-плагина CommandLine.

Вариантов особо и нет. Можно
а) импортировать в таких случаях только один домик. всё же лучше, чем ничего
б) оставить несклеенными. всё же лучше, чем ничего
в) кардинально поменять трассировщик, чтобы из этого он делал аналогичную картину одной линией (а не парой внутренняя+наружная). таких трассировщиков мне неизвестно, писать самому - под матан мой моск не заточен, увы :slight_smile:

а. сделать технически проще, б. будут излишние сложности при любой его реализации (а плюсов не вижу, только минусы)

У меня на сервере форточки, а мой любимый язык - пхп :slight_smile: Но, ясен пень, на сях будет производительнее, так что только рад.
Задача выглядит не зависящей от платформы. Если будет написано под никсы, портирование не выглядит сложным (ну в крайнем случае запущу задачу на другом сервере, если разово).

Видимо, PNG :slight_smile: Остальные два варианта - векторные форматы, их как раз надо на выходе :slight_smile:

svg выглядит несложным для разбора. Генерация osmxml и привязка домика к географическим координатам - задача того скрипта, который будет подсовывать png трассировщику. Мы же не хотим, чтобы трассировщик ещё и в географии разбирался? :slight_smile:

Мне нравится, как это делает JOSM. Лучше вряд ли можно придумать (да и нужно ли?).
Была мысль поискать в исходниках и стащить этот алгоритм :slight_smile:


Теперь нужно лирическое отступление. Надо определиться, что мы пишем :slight_smile:

1а. Свой трассировщик. В задачи входит: получить на входе PNG картинку, аналогичную этой, и выдать на выходе набор линий с координатами, аналогичными пиксельным координатам в картинке. Географией и работой с WMS, мне кажется, заниматься здесь излишне.
Опционально (правда, иначе смысла писать свой и нет :)) - алгоритм ортогонализации и упрощения.

1б. Фильтр для готового трассировщика, который сделает ортогонализацию и упрощение.

  1. Скрипты, которые будут качать WMS, кормить трассировщику, получать результат, и раскладывать по полочкам. В целом, выглядит несложно:
  • Берём адресную точку из кадастровой базы, грузим квадрат (типа тех, с которыми уже все знакомы в нумераторе) с центром в этой точке
  • Проверяем по цвету, попали ли мы в здание. Если нет - пропускаем, не заморачиваемся
  • Отправляем задачу на векторизацию-ортогонализацию-упрощение. Получаем векторное представление квадрата
  • Находим в нём центральное здание, берём его вектор. На всякий случай можно проверить, входит ли по-прежнему в него адресная точка, а также наложить маску на исходную картинку, и проверить распознавание например подсчётом пикселей нужного цвета внутри.
  • Переводим координаты векторов в географические. Сохраняем полученный way в базу, вместе с адресом.
  1. Скрипт валидации. Здесь думаю что-то построенное на той же технологии, что и нумератор. Все знакомы, в объяснении не нуждается. Опыт у меня уже имеется :slight_smile:

Если много сильно не прямых углов, встроенный ортогонализатор ошибается в определении базового направления и результат может быть очень сильно не похож на исходный контур. В нашем случае у меня половина векторизованных домиков схлопывалась в ниточку из-за скгрулённых углов.

Я могу попробовать сделать:

  1. Трасировщик под винды, который берёт на вход PNG и на выход высыпает SVG
  2. Команду к JOSM-плагину CommandLine, которая ортогонализирует контур по моему алгоритму (улучшенное определение базового направления, лишние узлы удаляются)

Второе мне более интересно, так как у меня давно чешутся руки сделать ортогонализатор, который мог бы обрабатывать не все точки контура - чтобы проще было ортогонализировать дома со срезанными углами и т.п.

Если результатом будут красивые прямые углы, то я только за :slight_smile:

Конкретно JOSM задействован не будет никак в нашем случае. Но, наработки можно будет использовать, и портировать на другие языки, для работы самостоятельно, да?

Первая проба

  1. Ортогонализированный SVG, сделанный прогой из potrace-овского SVG
  2. Исходные контуры и ортогонализированные в одном SVG для удобства сравнения в JOSM-е.
    По-моему неплохо получается :slight_smile:

Одно из обрезанных краем зданий схлопнулось, ещё одно из верхних получилось с уступом (исходный png - скрин JOSM-а, по этому зданию как раз масштаб карты был нарисован), “пролившиеся” номера домов выгрызли аккуратные ниши :slight_smile: