Эстония

Communities Россия (Russia)
501
  1. http://svimik.com/potrace_209681243.svg Обезался. Контуры, соединённые одним лишь углом (а не целым ребром) за склеенные здания не считаются…
  2. http://svimik.com/potrace_26857466.svg Проблем не возникло. Очень красивое кстати здание :slight_smile: (проблемы будут у ортогонализатора)
  3. http://svimik.com/potrace_26863815.svg Трассировка прошла успешно. Но намёк я понял. Нет, я не буду импортировать здания с мультиполигонами, ещё чего не хватало!

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

Надо будет ещё добавить проверку, чтобы в OSM на месте, куда надо воткнуть здание, ничего не было. Как бы это попроще реализовать…
У OSM кстати нет WMS сервера? Или только тайловые?

Рад за тебя. Я не стал себя утруждать исследованиями (и перегружать читателя информацией), начиная с какой версии IE начал показывать. Возможно, только в последней :slight_smile:

502

Ортогонализуется вменяемо :slight_smile:
http://ge.tt/5JjVoFb/v/1?c
209681243 векторизован с низким разрешением

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

Exe-шнику на вход один контур будет приходить или много (более одного z и m в одном path)?
Лучше бы один. Хотя можно допилить алгоритмы и до связанной ортогонализации нескольких контуров.

503

Наброски интерфейса валидации: http://osm.svimik.com/btrace_verify.php
В процессе ещё рисование контура поверх OSM карты. И, я ещё жду ортогонализатор в виде исполняемого файла под win32 :slight_smile:
Входные данные для теста уже можно примерить из ссылки выше.

Один. Я их сам дроблю на контуры, пример - по ссылке выше.

504

Пишу уже на C. :slight_smile:
Из VB6 в консоль пихать можно только через ацкий хак, так что пока не буду :slight_smile:

Вижу две m-команды:
M1166 1415 m359 -22

505

По спецификации SVG всё верно, просто не делал оптимизацию после вырезания линий.
Их можно или обрабатывать в обычном порядке (установить координаты 1166 1415, потом переместиться на 359 -22), либо я их позже схлопну в одну команду, когда до разбора этой строки дойду.

506

Есть вариант вообще принимать на вход набор координат, например

1385 1313, 1392 1235, 1396 1219, 1401 1202, 1368 1197, 1335 1191, 1253 1184, 1172 1178, 1165 1256, 1158 1335, 1154 1352, 1149 1369, 1192 1374, 1235 1380, 1265 1383, 1295 1387, 1337 1389, 1378 1390, 1385 1313

Сделает программу более универсальной. А я, раз уж начал парсить SVG, то допарсю его доконца.

507

Ну вообще уже можно пробовать (в path-d формате) :slight_smile:
http://ge.tt/5JjVoFb/v/2?c
exe в debug-сборке, test1.bat и образец его выхода - включены
Выводит ровно такие же path как в архиве выше.

508

Windows XP, 32бит.

509

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

510

Если без параметров? Есть такое :), исправлю

511

Да нет, не работает впринципе.

C:\Documents and Settings\SviMik\Рабочий стол\potrace>path_ortho.exe "M6328 8871 l-98 -58 -5 -5 -6 -5 37 -62 3
6 -61 9 0 8 0 93 56 93 56 3 3 3 2 -38 65 -38 66 -97 -57z" >> outp.txt
Не удается выполнить указанную программу.
512

Прошу прощения, MSVC по умолчанию собирает на использование MSVCR80*.dll
Release-сборка как standalone:
http://ge.tt/5JjVoFb/v/3?c

513

Работает, отлично :slight_smile:
Только давай сделаем второй вариант, а то мы немного по-разному воспринимаем формат SVG, и умучаемся подстраиваться. А разбор SVG по всем правилам отнимет много времени…
Да и такой вариант универсальнее будет, не привязанный к каким-то форматам.

(извиняюсь, что так меняю требования на ходу, просто разработка в самом разгаре, а “оптимальное” решение приходит не сразу).

514

Без проблем, мне будет спокойнее, если парсинг SVG будет снаружи :slight_smile:
Одно примечание - если последняя точка не повторяет первую я буду считать, что контур не замкнут.
Теперь вопрос - точность выхода? Сейчас округляется до 1, но можно выводить и цифры после “запятой”, квадратность будет лучше. Подумываю запилить параметр.

515

ок, значит, буду точку повторять.

Вообще, там и так точность до 0.1 пикселя при целых числах. Даже не знаю, есть ли смысл. Но если параметром, то лишним не будет.

516

Мы ещё хотели мелкие уступы срезать. Для этого тоже нужен параметр, т.к. масштаб нефиксирован, насколько я понял.
Предлагаю такие параметры
aX - точность вывода, десятичных знаков после “.”, X - целое от 0 до 20, 0 по умолчанию
cY - минимальный размер ребра, меньше - срезаем, Y - число с плавающей точкой, 0 по умолчанию
Вызов:
path_ortho.exe [params] data

517

Да. Только, напиши потом рекомендуемые параметры, допустим в метрах.
cY я бы взял наверное метр (или полметра?), а вот как работает aX я не очень понимаю.

Масштаб у меня пишется на странице, Zoom: 0.3 означает (если не напутал) 0.3 метра на пиксель.
Система у меня такая: если дом не влазит - картинка потом будет перекачана с другим масштабом, чтобы влез :slight_smile:

518

a0 будет выводить как сейчас
a1 будет выводить 1385.1 1313.3, 1392.4 1235.5, 1396.1 1219.7
a2 будет выводить 1385.13 1313.35, 1392.42 1235.58, 1396.10 1219.72
ну и так далее

519

Можно пробовать в новом формате, параметры поддерживаются. Пока что любой контур считается замкнутым.
http://ge.tt/5JjVoFb/v/4?c

Включил пачку outp_c*.txt - с разными параметрами c при a2
10 - спилились 2 выступа на моём первом комплекте данных
20 - спилились выступы на 209681243
70 - 209681243 начал деградировать
80 и 100 - 209681243 убился

Если на чём-то получаются кривые результаты или падение - пишите.

Исходник залью на github после того как причешу :slight_smile:

520

Не хватает что-то по типу прицела (перекрестия), где дом с номером был бы как-то выделен.