Хочу пожаловаться.
Вчера ночью создал с нуля пару мелко-нарезанных зданий, хотел из сам сразу же адресовать, но ночью адресатор висел, а утром они уже были кем-то “обработаны”.
А у меня было опасение, что люди поленятся открывать крупные фрагменты схемы и не увидят номеров домов (а всегда, когда речь идет не об отдельностоящем доме, а о цепочке склеенных - то если номера дома не видно, это не значит, что его нет, нужно открывать и смотреть крупный фрагмент, поскольку на мелком номера иногда не прорисовываются).
Сейчас посмотрел в базе - так и есть: примерно половина домов, имеющих адрес, этот адрес не получила (на скриншоте они выделены красным - у всех них виден адрес на растровой подложке, но его нет на контуре здания).
Хочется, чтобы был озвучен ник героя, который обкликивал эти дома - просто чтобы он знал, что он делает неправильно - такая скорость обкликивания нафиг не нужна, если при этом половина домов сливается в никуда.
Ну и вопрос - что с этими домами делать?
Ведь даже если я руками им присвою адреса в базе - я не могу поставить тег maaamet:ETAK что мне совсем не нравится.
Наилучшим вариантом я бы счел возврат этих домов в обкликиватель.
Ну если не видно номер в обликикере, то такие претензии не понимаю ? Знаешь что-то больше - так возьми и дополни данные, а тег maaamet:ETAK вовсе не главный.
Вообще, проблема интересная затронута. И интерфейс обкливикания тоже в этом виноват, т.к. необходимость открытия большой карты совсем неочевидна. Да и нельзя заставлять её открывать на каждом неподписанном домике.
Надо подумать, как можно её решить… Чуть позже. Если будет сделан массовый импорт, то больше этим заниматься не придётся.
А вот что точно нельзя решить автоматически, так это улицы… Рекомендую заняться ими
Этот тег, наверное, не нужен никому, кроме моих скриптов. По нему они определяют, что адресная запись принадлежит им, и могут точно идентифицировать запись в базе Maa-amet. На адресах, введённых вручную, ему лучше не быть.
freeExec, во-первых, не понимаю, почему любое сообщение о том, что что-то не так, ты воспринимаешь на свой счет?
Видимо, знаешь о чем-то, о чем другие не подозревают?
Во-вторых - ты видел интерфейс обкликивателя? Заметил там кнопочку “Открыть карту в бОльшем разрешении” (не помню, как она точно называется) ?
Ты думаешь, она там зачем? Ты не считаешь эту кнопку частью “обкликивателя”?
Типа, если на мелком разрешении номер не видно - то не моя проблема, ставим “пусто” - так?
Вообще, зачем это все делается - для результата в базе OSM, или для места в рейтинге обкликивателей?
В третьих, я вижу, что ты не разобрался в вопросе, когда написал - ну так и не надо так бурно и мгновенно реагировать на любое сообщение, разберись сначала, о чем речь (а речь была именно об этой кнопке про большое разрешение - которую ПРИХОДИТСЯ нажимать каждый раз при определенных обстоятельствах - я написал каких - а кто-то это дело прохалявил).
Ну и в четвертых, ты сам последний раз обкликивал дома 62 дня назад - уж наверное, вопрос с плохой нумерацией был не про тебя.
Понятно, что за 2 месяца можно и забыть про функциональность обкликивателя, но что тогда так подрываться на пустом месте?
Я не принимаю на себя, но ты упрекаешь в том, что не очевидно и не где не об этом не сказано. Будь это я - тоже бы не догадался, что надо смотреть отдельно. Вообщем мне не понравился тон сообщения, написал бы ты его в познавательном стиле, вопросов бы не было.
Этот как раз “одно из верхних получилось с уступом” - исходный png был скрин JOSM-а, поверх этого здания как раз масштаб карты был написан и potrace сделал “засечку” при векторизации.
Можно, да.
Причём внутри алгоритма это можно сделать сохраняя базовый угол, т.е. не допуская поворота остальных частей контура.
С этим готов согласиться.
Но тут уж кто как умеет.
P.S. Но знаешь ли - меня тоже можно понять, если постараться.
Точно, правильно (ну и красиво) рисовать здания, состоящие из нескольких десятков углов-нод (а видел и делал даже такие, что и под сотню - могу показать) - это не просто, и очень время-емко.
И если уж я иногда берусь за такое - то хотелось бы, чтобы этот труд не пошел в пустоту.
Но приходит некто, который не сильно себя утруждая, тратит ровно 15 секунд на обкликивание десятка зданий, на рисование контуров которых я потратил 10 минут - и спускает половину моего труда в никуда.
Зачем было потрачено время?
На самом деле, больше не хочу перетирать эту тему.
Там размер контура - не единственное условие.
Чтобы проблема проявилась, нужно чтобы сам контур был небольшой, но при этом, чтобы он граничил с другими контурами, внутри которых тоже есть свой лейбл с номером дома.
Но и этого не достаточно - нужно, чтобы номера были длинные - через слеш, и желательно двухзначные.
Вот тогда цифра 12/34 внутри одного контура уже не помещается, но и за границу контура она вылезти не может, поскольку из соседнего выпирает своя цифра.
Тогда Maa-amet рисует такие цифры с пропуском через один контур, что мы и наблюдаем на скриншоте в этом сообщении (там-то цифры показаны все, поскольку я специально подбирал масштаб, но там показано, какие дома оказались не пронумерованы).
Это понятно. Но если для небольших контуров просто увеличить масштаб - проблема будет решена.
OverQuantum, можно глянуть алгоритм ортогонализации?
Сейчас он в виде плагина для JOSM? Будет здорово, если его возможно портировать в самостоятельное приложение\скрипт. Но это я наверное сам справлюсь, лишь бы вся геометрия и матан был в нём (без зависимостей от сторонних библиотек или функций JOSM).
Можно, но сейчас он в виде черновика на VB6 и рассчитан на результат potrace
Делается следующее:
Отрезки контура (как вектора) умножаются на своим длины (длины векторов, таким образом, превращается в кубы длин)
Вектора поворачиваются с шагом кратным 90 градусов, чтобы уложиться в два интервала: от 0 до 90 градусов и от -45 до +45 градусов.
В обоих группах все вектора контура суммируются.
Проверяется, какой суммарный вектор оказался ближе к базисному направлению своего интервала. Для (0;90) это 45 градусов, а для (-45;45) - это 0 градусов. Выбранный вектор объявляется базовым направлением контура и нормализуется.
Все исходные вектора контура (не умноженные) проецируются на базовый вектор и его перпендикуляр. В зависимости от того, какой результат получается больше, вектор контур считается относящимся к базовому направлению или его перпендикуляру.
Внутри последовательно состыкованных векторов, относящихся к одному направлению (базовому или перпендикулярному) определяется параметр С уравнения прямой Ax+By=C, которая хорошо аппроксимирует ломанную, состоящую из взятых векторов. (A,B) - вектор направления (базовый или перпендикулярный)
Для всех точек, которые являются переходными между базовым и перпендикулярным направлениями, определяются новые координаты - по двум параметрам C от базового и перпендикулярного направления.
Результирующий контур строится только из этих точек.
Интересно, что почти всё считается простейшими действиями с векторами. atan() применяется только для выбора одно базового вектора из двух, а квадратный корень - только для его нормализации.
Жалко Жду реализации на как-нидь другом языке, который я понимаю
А можно бинарник, который можно использовать? А то VB6 мне и компилить-то нечем…
Хотелось бы консольную программу с синтаксисом что-то вроде
Я его и буду использовать. Только, думаю его результат я предварительно разберу сам, и выдерну только нужную линию, которую уже отправлю в ортогонализацию.
Это мне сильно облегчить жизнь, т.к. загружать и векторизовать png - не очень тривиально.
В командной строке - хороший вариант. Только у меня предложение данные всё-таки одним параметром, внутри кавычек, например.
Текущий алгоритм мне проще всего переписать на C++.
Уже не надо. Я добился от potrace практически идеальных результатов (не считая необходимости ортогонализации и упрощения).
Это да, так будет и удобнее дополнительные параметры потом задавать.
Категорически за!
А вот мои результаты предварительной обработки, с выделением только интересующего здания:
(разрешение входного изображения я специально чуть занизил, для проверки крайних случаев. так впринципе я могу с WMS и 1024х1024 запросить)
Двойной контур я здесь делаю не спроста: уже на этапе разбора SVG я вижу, что имеем дело с группой из пяти склеенных зданий (внешний контур буду читать как объединение в группу).
А представляете, насколько бы упростилось дело, если бы на пути:
“координаты нодов в базе Maa-amet” → “генератор тайлов Maa-amet” → “векторизатор тайлов + ортогонализатор векторов у SviMik’а” → “получение координат нодов для залития объектов в базу OSM”
исключить два средних звена?
Комментарий, безусловно, риторический, но спрашивал ли кто у Maa-amet, не хотят ли они выгрузить в текст координаты нодов для публичного использования?
Впринципе, у Vitalts есть возможность спросить. Но я не уверен, что они отдадут
(update)
Небольшое превью: http://osm.svimik.com/btrace_view.php (не для IE, он SVG не отображает)
Всё ещё ждёт ортогонализации После этого можно попробовать перевести координаты в географические, сгенерировать .osc, и залить в osm.
Жду реализации на как-нидь другом языке, который я понимаю 
