Эстония

Ну на шаге 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:

Да, выглядит красиво :slight_smile:
Нашёл только одну мелочь:

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

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

Есть сложности со зданиями, адресованными по улице Raudtee. (сейчас эта улица - первая в списке пропущенных)
Здания эти вытянуты в ряд между ж/д и некой улицей, которая как нельзя лучше подходит под название Raudtee, но на WMS подложке Waa-amet называется Piibe mnt.
См. скриншот (здания, адресованные по Raudtee - селектнуты красным)
При этом, по другую сторону от Piibe mnt, здания (синие) действительно адресованы по Piibe mnt, т.е. это не ошибка названия улицы на WMS подложке Waa-amet.

То ли улица имеет два названия (Piibe mnt и Raudtee), и с одной стороны дома адресованы по одному названию, а с другой - по другому,
то ли совсем рядом ж/д есть улица Raudtee, просто она не подписана на WMS подложке Waa-amet (а там действительно виден какой-то кривой проездик).
(что, в общем, не так уж и удивительно - я уже встречал дома вокруг не подписанных на WMS подложке улиц, которые все были адресованы по одной улице)

Нужно изучение первоисточника.

Сам отвечаю на свой вопрос из предыдущего сообщения.

Включение “старой” подложки Maa-amet дает ответ - действительно, Raudtee идет рядом с ж/д.
Что-то эта новая подложка, хоть и аккуратная вся из себя - тем не менее, не всегда показывает названия улиц - уже не раз сталкивался.

Да, бывает… Maa-amet тоже не идеален. Особенно его рендер.

Есть ещё вариант получать метаинформацию по клику на карте. Там можно и улицы иногда неподписанные найти, и даже посмотреть тип здание (жилое/коммерческое). Но это надо идти смотреть карту на их сайте.

Хочу пожаловаться.
Вчера ночью создал с нуля пару мелко-нарезанных зданий, хотел из сам сразу же адресовать, но ночью адресатор висел, а утром они уже были кем-то “обработаны”.

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

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

Ну и вопрос - что с этими домами делать?
Ведь даже если я руками им присвою адреса в базе - я не могу поставить тег maaamet:ETAK что мне совсем не нравится.
Наилучшим вариантом я бы счел возврат этих домов в обкликиватель.

Ну если не видно номер в обликикере, то такие претензии не понимаю ? Знаешь что-то больше - так возьми и дополни данные, а тег maaamet:ETAK вовсе не главный.

_sev :slight_smile:

Вообще, проблема интересная затронута. И интерфейс обкливикания тоже в этом виноват, т.к. необходимость открытия большой карты совсем неочевидна. Да и нельзя заставлять её открывать на каждом неподписанном домике.
Надо подумать, как можно её решить… Чуть позже. Если будет сделан массовый импорт, то больше этим заниматься не придётся.

А вот что точно нельзя решить автоматически, так это улицы… Рекомендую заняться ими :slight_smile:

Этот тег, наверное, не нужен никому, кроме моих скриптов. По нему они определяют, что адресная запись принадлежит им, и могут точно идентифицировать запись в базе Maa-amet. На адресах, введённых вручную, ему лучше не быть.

freeExec, во-первых, не понимаю, почему любое сообщение о том, что что-то не так, ты воспринимаешь на свой счет?
Видимо, знаешь о чем-то, о чем другие не подозревают? :slight_smile:

Во-вторых - ты видел интерфейс обкликивателя? Заметил там кнопочку “Открыть карту в бОльшем разрешении” (не помню, как она точно называется) ?
Ты думаешь, она там зачем? Ты не считаешь эту кнопку частью “обкликивателя”?
Типа, если на мелком разрешении номер не видно - то не моя проблема, ставим “пусто” - так?
Вообще, зачем это все делается - для результата в базе OSM, или для места в рейтинге обкликивателей?

В третьих, я вижу, что ты не разобрался в вопросе, когда написал - ну так и не надо так бурно и мгновенно реагировать на любое сообщение, разберись сначала, о чем речь (а речь была именно об этой кнопке про большое разрешение - которую ПРИХОДИТСЯ нажимать каждый раз при определенных обстоятельствах - я написал каких - а кто-то это дело прохалявил).

Ну и в четвертых, ты сам последний раз обкликивал дома 62 дня назад - уж наверное, вопрос с плохой нумерацией был не про тебя.
Понятно, что за 2 месяца можно и забыть про функциональность обкликивателя, но что тогда так подрываться на пустом месте?

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

Этот как раз “одно из верхних получилось с уступом” - исходный png был скрин JOSM-а, поверх этого здания как раз масштаб карты был написан и potrace сделал “засечку” при векторизации.

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

С этим готов согласиться.
Но тут уж кто как умеет.
:slight_smile:

P.S. Но знаешь ли - меня тоже можно понять, если постараться.
Точно, правильно (ну и красиво) рисовать здания, состоящие из нескольких десятков углов-нод (а видел и делал даже такие, что и под сотню - могу показать) - это не просто, и очень время-емко.
И если уж я иногда берусь за такое - то хотелось бы, чтобы этот труд не пошел в пустоту.
Но приходит некто, который не сильно себя утруждая, тратит ровно 15 секунд на обкликивание десятка зданий, на рисование контуров которых я потратил 10 минут - и спускает половину моего труда в никуда.
Зачем было потрачено время?

На самом деле, больше не хочу перетирать эту тему.