Была бы ещё польза от показометра для размеров создаваемых объектов (углы, расстояния, и т. п.) А то одного маленького кусочка линейки явно не хватает для осознания величия рисуемого объекта.
Магниты хороши были бы и при редактировании (выпрямлении) уже нарисованного.
Сделал программку. Ее смысл в проверке и поддержании адресной базы города. Алгоритм был такой через 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 в треке сегменты раскрашивались соответственно скорости!
Вообще-то они и так раскрашиваются…
а как? я не нашёл кнопки, только выбор цвета для всего трека
В настройках же, на первой вкладке “Раскрасить треки и точки”
Кстати, было бы удобно, если бы в джосме по двойному клику на линии создавалась новая точка.
Дык в настройках на первой же вкладке - Скорость.
о, спасибо
По-моему, таскать за крестик между узлами удобнее. А по двойному тыку лучше выводить редактор тэгов.
Иногда крестик ну очень далеко. Особенно, когда работаешь на мелких масштабах, а линия длинная. И приходится жать ‘a’, кликать в нужном месте, потом ‘s’.
Блин…
А я про крестик и не знал… И как лох - жму “а” ставлю кучу точек на линии, потом “s” и расставляю ноды на нужные места.
Век живи - век учись… спасибо
- Не хватает структуры в базе. В первую очередь не хватает такого понятия как ОБЪЕКТ. Узлы, пути, отношения - лишь кирпичики, из которых должны строиться объекты.
В OSM есть понятие объекта. Объект - это узел, путь или отношение. Ну подумайте сами, вот у меня есть дом (вей), у него есть входы (узлы), и он является членом отношения типа street (улица). Это все объекты в вашем понимании. Это получается, что мне надо удвоить количество хранимой информации в базе данных и удвоить количество своих действий, чтобы это рисовать? Просто представьте, что вместо того, чтобы вешать теги прямо на пути и узлы вам надо создавать каждый раз отношение (type=object). Ничего кроме гемороя с обработкой, рисованием и хранением введение объектов не даст.
- Не хватает нормального редактора, который бы:
2а. Был написан на компилируемом языке и не тормозил (не важно, из-за интерпретации кода или из-за нехватки памяти для ВМ).
А с каких пор яву нельзя скомпилировать? Есть компиляторы для явы, прямо в машинные коды, без WM.
2б. Поддерживал бы в полном объеме существующие структуры данных, а в идеале - ограждал бы пользователя от ошибок (например, не давал записать узлы либо пути, если они не принадлежат никакому объекту).
А почему “не давал”. Зачем мне редактор, который не дает мне делать то, что мне нужно? Вот предупредить, это полезно. А решать буду я. Какие структуры не поддерживает JOSM? Кстати, он предупреждает об узлах либо путях, не принадлежащих никакому объекту (то бишь просто не имеющих тегов).
2в. Обладал интуитивно понятным интерфейсом и удобными средствами навигации и редактирования.
А точнее? Какой должен быть интерфейс, как устроены средства управления? И что значит интуитивными? Предложите.
удвоить количество своих действий, чтобы это рисовать?
Што?
Зачем мне редактор, который не дает мне делать то, что мне нужно?
Значит, вы будете пользоваться другим редактором.
А редактор для простолюдинов - все равно нужен. Удобный, простой и понятный им. Который умеет решать за неопытного пользователя, ошибся он или нет.
А точнее? Какой должен быть интерфейс, как устроены средства управления? И что значит интуитивными? Предложите.
Лучше бы помогли, чем ворчать. Предложим.