Спасибо, разобрался.
Но тут другая проблемка нарисовалась.
F4Map себя как-то странно ведет. Нарисовал “фронтон” на домике (на примере это дом №4). “Фронтон” сборный, из двух skillion’ов, направленных в противоположные стороны. Одной части “фронтона” задал roof:direction=WNW, противоположному соответственно roof:direction=ESE.
Загрузил изменения на сервер. Вроде всё было в порядке. Но затем F4Map несколько дней не показывал обновленным этот домик. А когда опять начал показывать, то ту часть “фронтона”, которая WNW вывернул южнее, как если бы направление было SSW. Другая часть “фронтона” отображается по прежнему как и задумано мной.
Вопрос. Что делать в этой ситуации? Ждать пока “починиться” F4Map, или есть какие-нибудь танцы с бубнами, способные привести к требуемому результату (например, изменить немного ориентацию, с меньшей степенью детализации, скажем, вместо WNW указать NW)
В Kendzi3d этот “фронтон” рендерится как положено.
Еще испрашиваю совета у многознающих гуру OSM-мапинга.
Есть здание, второй этаж которого по периметру больше чем первый, нависает над ним как-бы. Вдоль стены первого этажа - тротуар, по которому ходят люди, и этот второй этаж нависает над ними. Получается некая защита от непогоды.
Итак, получаем некую дорожку footway с одной стороны которой стена 1-го этажа, а с другой, скажем парковка, отделенная от дорожки бордюром. И над всем этим нависает второй этаж здания.
Мне видится проблема в том, что контур здания (outline) будет перекрывать footway, и бордюры (barrier=kerb, а так же, возможно, часть парковки (мультиполигон amenity=parking) и это будет конфликтовать друг с другом, при отображении на каких-нибудь картах. Значит надо как-то по особому затегировать перекрывающиеся участки. Но как?
Для highway=footway вижу возможность пометить перекрываемый участок как tunnel=building_passage. Только вот терзают сомнения - ведь полноценного тоннеля не получается. Может есть какой специализированный тег для этих случаев.
Обойти эту проблему не так просто. Может оказаться, что эта пешеходная дорожка единственное место, соединяющее далеерасположенный квартал с иной транспортной инфраструктурой.
Алексан9р, мы уже далеко отклоняемся от тематики форума OpenStreetMap, так что по поводу модификации я бы посоветовал обратиться в форум 4pda.ru, там скорей всего есть тема по вашему телефону, где общаются носители практического опыта ковыряний в данной модельке.
Прошу совета. Поиск наиболее подходящего тега для обозначения деревьев, в городской среде.
Рука не поворачивается на пятачок, окружённый с 3-х сторон дорогами, на котором высятся 3 деревца вешать тег natural=wood (хоть пока так и вынужден делать). Ведь это более логично чем landuse=grass, ибо в лесу преимущественно деревья, которые загораживают обзор, а травка, обзору почти не мешает, поэтому логичней вешать лес, чем траву, ведь для пользователя карты может быть важно - есть в этом месте обзор или нет.
Не так давно из видеоуроков Zverik’а увидел новый тег natural=scrub (кустарник) - буду им пользоваться, так как он более логичен во многих местах чем трава или деревья. Может быть есть какие теги для моего случая? Скажем, какие-нибудь аллеи (их часто высаживают вдоль дорог, как в городах, так и за городом - тянуться вдоль дорог в 1-3 деревца шириной целая полоса, разделяющая поля). Неужели и для этих лесополос рекомендуется natural=wood? Странно это.
Какие-то высосанные из пальца проблемы, нет ничего такого чтобы обозначить деревья деревьями. И не надо ничего выдумывать вроде обозначить деревья кустами. Но если что есть natural=tree.
Про назначение scrub четко написано в wiki, обозначать им обычные для средней полосы высокорослые деревья будет ошибкой.
Поймите, что теги в OSM - это условные обозначения, и слова, которые используются для ключей или значений никогда не следует воспринимать буквально. С тем же успехом мы могли бы использовать обозначения, как в некоторых ГИС-классификаторах, цифрами (landuse=12345, например), только это было бы очень сложно запоминать. Статьи в Wiki OSM служат для описания того, что обозначает тот или иной тег. Вот их и нужно читать. Вас же, надеюсь, не смущают теги вроде highway=steps (грубо, “шоссе=ступеньки”)? Вот и тут ничего смущать не должно. Пока не придумана и не принята схема, которая бы включала в себя тег, обозначающий исключительно “тут - деревья” (без всяких ассоциаций с лесом), функцию такого тега выполняет natural=wood (и как частные случаи - natural=tree и natural=tree_row).
Здравствуйте.
Сегодня, почти совершенно случайно обнаружил, что часть мультиполигонов, формирующих одно из моих зданий бесследно исчезло (контур остался, исчезли part’ы формирующие этажи и крышу)
Я регулярно делаю у себя локально бэкапы редактируемой области. Сравнил. Действительно во вчерашней работе, то что отправлял на сервер проблемные мультиполигоны еще были, а в сегодняшней скачанной области их уже нет. Восстановить исходное состояние большой проблемы не составляет, т.к. я это только что обнаружил и еще ничего нового не рисовал. Но остается вопрос: как такое возникло, и как определить - не поломалось ли что еще?
Увидел сегодня тему с откатом правок, но она какая-то не очень активная. Выходит таки есть проблемы, и они носят более менее регулярный характер? Или же это из ряда вон выходящее событие?
Вроде где-то видел, что можно посмотреть историю изменения любого объекта, но в JOSM не нашел.
Вы покажите правку где вы добавили эти исчезнувшие части.
А вообще у вас там куча линий без тегов О_о, какие-то огрызки линий с тегами зданий. Скажу так же, что такой “мапинг” хорошо только мапить первый раз, поддерживать и править его слишком тяжело, по большей части проще потом положить на него болт.
А как её показать? Я могу лишь дать ссылку на объект в том виде, в каком он есть сейчас. И там нет моих мультиполигонов. Они у меня лишь локально на компьютере. Вы хотите чтобы я их снова загрузил на сервер?
Да, там куча линий без тегов, ибо всё в процессе. Каждый день стараюсь чего-то допиливать, чтобы избавиться в конце концов от немаркированных линий. Некоторые линии нужны.
И покажите где огрызки линий с тегами зданий. Обычно стараюсь такого не допускать. Может вы как раз нашли то, что мне порушили.
что-то правил 6 часов назад. Есть предположение, что поступал так же как и я. Скачивал область, пару дней её мапил, а потом загружал на сервер, когда я уже успел внести некие изменения.
Кстати, припоминаю момент, когда при отправке изменений на сервер Josm начал ругаться на некий неулаженный конфликт, как раз в том самом здании, которое у меня сейчас вызывает проблемы.
Явно мы что-то делаем не так. Наверно мы затираем друг друга.
для меня пока загадка, как вы вытаскиваете всю эту информацию.
Посмотрел у себя локально на компе. Здание было нарисовано преимущественно в том виде, как оно должно быть 19.12.2016 в 4:17 msk. в то же время я пакет правок загрузил на сервер.
То, что вы показали, пакет правок, заключался действительно лишь в том, что были проставлены номера квартир на подъезды. Оставил это как образец, чтобы потом, если руки дойдут до других зданий, долго не искать, как обозначать номера квартир. Ну и природу вокруг дома подрисовал.
Прекрасно это понимаю, поэтому и выгружаю-загружаю в рамках одного дня, вернее, как правило, ночи. Это я год или два назад так “работал”. Из-за этого и остаются всякие непомеченные линии-заготовки, ибо лучше я их оставлю и завтра снова скачаю и доделаю их, ибо снова их рисовать - долго, а как-то отдельно их убирать перед выгрузкой на сервер, и сохранять на компе - не умею.
Но всё равно рано или поздно, когда на одной области будут пастись несколько мапперов, при моем подходе начнутся “затрики”. Где-то читал, что есть какая-то процедура, позволяющая перед выгрузкой на сервер проверить область на изменения, с момента предыдущего скачивания. Но там, для меня была какая-то жутко сложная процедура, грозящая уничтожением всего пакета правок (диалоговое окно урегулирования конфликтов, с которым я столкнулся недавно чего стоит. жутко непонятно), а здесь это грозит целым ворохом улаживания подобных конфликтов. Поэтому и сторонюсь этого как можно дольше.