Каких инструментов вам не хватает?

надо вежливо просить как-то так
Собственно SLD=global_mosaic.sld это стиль, а STYLES=color_453 - это смесь каналов rgb, в нём описаная.
На примеры с gis-lab это похоже, но сильно я так и не разбирался ещё :frowning:

ps. global_mosaic.sld это стиль, лежащий у самих jpl. В теории, сервак может брать чужой стиль по http, что должно позволить подкорректировать гамму и помесь каналов.

Спасибо. Буду пробовать.

Мы с тобой были невнимательны к инструменту “Q”, смотри, что он умеет:

хотим повернуть домики вдоль улицы

выделяем нужные домики, и ДВЕ ТОЧКИ на проспекте (красные, чуть левее и выше кучки домиков)

и нажимаем кнопку Q

voila, домики маршируют вдоль нашей линии!

Пардон за оффтоп.

Две точки можно выделять и на самих выделенных домиках. Если есть, например, один длинный домик с хорошо выровненной длинной стороной, то одним движением можно спрямить углы у него и у соседних домиков, и выровнять соседние домики относительно длинного дома…

Это вы невнимательны к моим словам. Мы хотим не только повернуть домики параллельно улице, а еще и сделать так чтобы расстояние от улицы до домиков стало одинаковым. Что-то я не наблюдаю на ваших рисунках как домики выстроились в один красивый ряд.

Это нужно, потому что улица большая и красивая, ее можно очень точно нарисовать по трекам или спутнику. А домики маленькие и спрятаны в тени деревьев. Поэтому нарисовать их можно только приблизительно.

Это не поворот.
Это черт знает, что такое, но это не поворот. Это искусственное запараллеливание линий в объекте некой прямой.

Если посмотреть внимательно (на бОльших углах), можно увидеть, что форма здания не сохраняется.

До Q:

После Q:

Hind, ага, получается, как ты говоришь. Значит это именно запараллеливание. Без врашения. Экое гадство, буду знать.))

Kaylee, теперь понял, что ты хочешь.
“а еще и сделать так чтобы расстояние от улицы до домиков стало одинаковым” – теперь решительно понятно, что ты имел ввиду.

Голосую обеими лапами ЗА такую штуку))

Вообще, нужны направляющие и прилипание к ним. Это уже какой-то inkscape получается.

Автокад:)

Снаппинг рулит. Давайте создадим список прилипаний.

  1. При рисовании линии (вея):
    1.1 К прямым под углами 0, 45 и 90 градусов относительно предыдущего сегмента рисуемой линии.
    1.2 К прямой, перпендикулярной началу рисуемой линии.

Все магниты (когда включены одновременно) должны работать и на пересечения этих виртуальных прямых (отдавая пересечениям приоритет).

Была бы ещё польза от показометра для размеров создаваемых объектов (углы, расстояния, и т. п.) А то одного маленького кусочка линейки явно не хватает для осознания величия рисуемого объекта. :slight_smile:
Магниты хороши были бы и при редактировании (выпрямлении) уже нарисованного.

Сделал программку. Ее смысл в проверке и поддержании адресной базы города. Алгоритм был такой через 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
:slight_smile:
[/offtop]

  1. Не хватает структуры в базе. В первую очередь не хватает такого понятия как ОБЪЕКТ. Узлы, пути, отношения - лишь кирпичики, из которых должны строиться объекты.
  2. Не хватает нормального редактора, который бы:
    2а. Был написан на компилируемом языке и не тормозил (не важно, из-за интерпретации кода или из-за нехватки памяти для ВМ).
    2б. Поддерживал бы в полном объеме существующие структуры данных, а в идеале - ограждал бы пользователя от ошибок (например, не давал записать узлы либо пути, если они не принадлежат никакому объекту).
    2в. Обладал интуитивно понятным интерфейсом и удобными средствами навигации и редактирования.
  3. Как и во всех открытых проектах здесь не хватает структурированной иерархической справочной системы.

Хочу, чтобы в JOSM в треке сегменты раскрашивались соответственно скорости! :slight_smile:

Вообще-то они и так раскрашиваются…