Спасибо. Буду пробовать.
Мы с тобой были невнимательны к инструменту “Q”, смотри, что он умеет:
хотим повернуть домики вдоль улицы
выделяем нужные домики, и ДВЕ ТОЧКИ на проспекте (красные, чуть левее и выше кучки домиков)
и нажимаем кнопку Q
voila, домики маршируют вдоль нашей линии!
Пардон за оффтоп.
Две точки можно выделять и на самих выделенных домиках. Если есть, например, один длинный домик с хорошо выровненной длинной стороной, то одним движением можно спрямить углы у него и у соседних домиков, и выровнять соседние домики относительно длинного дома…
Это вы невнимательны к моим словам. Мы хотим не только повернуть домики параллельно улице, а еще и сделать так чтобы расстояние от улицы до домиков стало одинаковым. Что-то я не наблюдаю на ваших рисунках как домики выстроились в один красивый ряд.
Это нужно, потому что улица большая и красивая, ее можно очень точно нарисовать по трекам или спутнику. А домики маленькие и спрятаны в тени деревьев. Поэтому нарисовать их можно только приблизительно.
Это не поворот.
Это черт знает, что такое, но это не поворот. Это искусственное запараллеливание линий в объекте некой прямой.
Если посмотреть внимательно (на бОльших углах), можно увидеть, что форма здания не сохраняется.
Hind, ага, получается, как ты говоришь. Значит это именно запараллеливание. Без врашения. Экое гадство, буду знать.))
Kaylee, теперь понял, что ты хочешь.
“а еще и сделать так чтобы расстояние от улицы до домиков стало одинаковым” – теперь решительно понятно, что ты имел ввиду.
Голосую обеими лапами ЗА такую штуку))
Вообще, нужны направляющие и прилипание к ним. Это уже какой-то inkscape получается.
Автокад:)
Снаппинг рулит. Давайте создадим список прилипаний.
- При рисовании линии (вея):
1.1 К прямым под углами 0, 45 и 90 градусов относительно предыдущего сегмента рисуемой линии.
1.2 К прямой, перпендикулярной началу рисуемой линии.
Все магниты (когда включены одновременно) должны работать и на пересечения этих виртуальных прямых (отдавая пересечениям приоритет).
Была бы ещё польза от показометра для размеров создаваемых объектов (углы, расстояния, и т. п.) А то одного маленького кусочка линейки явно не хватает для осознания величия рисуемого объекта.
Магниты хороши были бы и при редактировании (выпрямлении) уже нарисованного.
Сделал программку. Ее смысл в проверке и поддержании адресной базы города. Алгоритм был такой через Josm скачивал xml и дальше конвертировал его в Access базу данных. Ее сравнивал с имеющейся базой. После сравнения сразу понятно, если какой-то адрес был удален. Ну или найти какого адреса не хватает. Но так как сам не программист, программка оказалась медленной и не удобной. Может кто из программеров заинтересуется и сделает что-то подобное.
Думаю требования должны быть следующими: Данные скачиваются по границам полигона (обозначающего границы города). Далее сравниваются с имеющейся базой данных и в двух таблицах выводится разница: “отсутствует в базе”, “отсутствует в осм”. При желании пользователь может добавлять объекты из ОСМ, отсутствующие в базе. Дальнейшее развитие это сравнение различных объектов. Например, школ, д/с и т.д с имеющимися в базе данных (списки школ города можно легко найти в открытых источниках). Таким образом, можно будет находить не хватающие в ОСМ объекты. Тоже самое можно сделать для relations запртов поворотов. Еще одно назначение поиск тегов с опечатками и неправильных тегов.
Если кто-то заинтересуется и будет необходимость, могу отдать все исходники (на VB) и SQL запросы.
Если б они были уже в готовом для использования виде… А если просто брать из открытых источников - то, ИМХО. что заносить в БД, что напрямую в ОСМ - разница невелика. Так зачем делать двойную работу?
Смысл просто вытащить список уже имеющихся объектов в ОСМ и сверить с полным списком.
Еще хотелось бы при рисовании домов, при зажатом шифте или контроле, разрешало рисовать углы с шагом 45 градусов.
И еще, в в режиме селект, при выделенном объекте, чтоб курсорами можно было его подвинуть с маленьким шагом.
Очень не хватает в Josm визуального отображения максимально допустимых скоростей (maxspeed и maxspeed:practical) типа http://latlon.org/maxi?zoom=17&lat=55.71068&lon=37.73508&layers=000000000000BFF. Может отдельным слоем или еще как…
[offtop]Мне кажется, что очень не хватает ринга, чтобы можно было выйти и нормально разрешить вопросы:
http://forum.openstreetmap.org/viewtopic.php?id=8471&p=4
[/offtop]
- Не хватает структуры в базе. В первую очередь не хватает такого понятия как ОБЪЕКТ. Узлы, пути, отношения - лишь кирпичики, из которых должны строиться объекты.
- Не хватает нормального редактора, который бы:
2а. Был написан на компилируемом языке и не тормозил (не важно, из-за интерпретации кода или из-за нехватки памяти для ВМ).
2б. Поддерживал бы в полном объеме существующие структуры данных, а в идеале - ограждал бы пользователя от ошибок (например, не давал записать узлы либо пути, если они не принадлежат никакому объекту).
2в. Обладал интуитивно понятным интерфейсом и удобными средствами навигации и редактирования. - Как и во всех открытых проектах здесь не хватает структурированной иерархической справочной системы.
Хочу, чтобы в JOSM в треке сегменты раскрашивались соответственно скорости!
Вообще-то они и так раскрашиваются…
а как? я не нашёл кнопки, только выбор цвета для всего трека