Эстония

Ну висит же:
Скачивание минутных диффов Последняя проверка: 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:

Да, выглядит красиво :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 вовсе не главный.