Труды потлатчеров: сделайте меня развидеть это.

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

В одиночку с этим явно не справиться. У меня появляличь идеи с созданием около OSM репозитория на том же github. Чтобы туда можно было сливать данные для валидаторов в однообразном формате. Как для валидаторов данных так и для валидаторов тегов.

Ну список тегов хостить на гитхабе как-то нэ то… сейчас запилю-ка темку.

А если это считать базой данных. Просто это удобно. Есть версионость, возможность совместного редактирования, смотреть изменения)) Причем там же еще можно хранить скритпы для вытаскивания данных POI с сайтов для валидатров. И базу данных POI.

А тут кто-то выкладывал ссылку для 1 версии, у меня и оставалась.

а почему не json. Хотя это дело религии, но я как сначала знакомый с xml, а потом json (спасибо осм), теперь дружу с json

По поводу такого файла надо сначала подумать что в него нужно запихнуть.
И тут есть “НО” разного толка:

  • Как организовывать вложения элементов: через вложенность объектов, или через parent=;
  • Указывать ли возможные сочетания тегов: ведь бывает группа тегов описывает один элемент, например highway=service, living_street=yes (ну конечно это не POI, первое что пришло на ум)
  • Указывать ли в инфо тега возможные доп параметры, например у тега amenity=pharmacy - dispensing=yes

P.S. пока искал инфу для текста, наткнулся на очередное дублирование, догадайтесь чем оно сделано?

Щито? Там в пресетах светофора нет не было до 12 февраля. Подозреваю, что не только его. И добавлялся этот нехитрый тег больше года.

Никак не узнаешь, потому что ни один рендер не знает тега decriptoin.

Вот скажите, что бы вы посоветовали конкретно мне.
Я - не маппаер, я - потребитель данных.
Из-за этого:

  1. У меня мало правок.
  2. Те правки, что я делаю, это, в основном, именно правка - т.е. исправление чужих ошибок. Просто потому, что как потребитель я сталкиваюсь с существующими в OSM ошибками чаще, чем мапперы.
  3. Я ненавижу жосм, т.к. считаю его беспрецедентным образчиком того, как не следует программировать. И как вообще не должны вести себя программы (почему-то жосм считает, что истинный хозяин моего компьютера - он, а вовсе не я).

И чем пользоваться человеку?

  • у которого мало правок,
  • потребности в правках практически ограничены исправлением чужих ошибок,
  • который ненавидит жосм.

PS. Прошу не спорить насчет жосма - во избежание холивара. Поверьте, что у меня есть что сказать по его поводу.

PPS. Я уже давно в теме “Чего вам не хватает в OSM” высказывал мнение, что нужен редактор, ограничивающий пользователя в выборе из набора существующих тегов. Но только ограничивающий, а не запрещающий ему какую-либо правку вообще!

Опечатки неизбежны, но их надо исправлять :slight_smile:

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

А вы почитайте форум. Он просто завален советами (на вопрос “как?”) дублировать существующие линии, приписывая дублям другие теги.
Ничего не поделаешь - спрос рождает предложение.

Кстати, интересный вопрос: можно ли придумать алгоритм, удаляющий подобные дубли без потери информации?

А вот вам пример от джосмера: дорога удалена, а точки, из которых она состояла - остались. Ну вот как так, а?

Данные недозагружены были в рабочую область, а предупреждения программы или проигнорированы или не сработали почему-то.

Значит, при каком-то раскладе джосм позволяет удалить вей, не удаляя ноды. Довольно хитром раскладе, так как в обычном рабочем процессе при скачивании вея скачиваются и его ноды, а при удалении вея свободные ноды выпиливаются.

У меня такое при попытке откатить правку получилось.

Без хитрых раскладов такое частенько случается при разрыве связи во время заливки пакета. Сам на мобильном тырнете постоянно с этим сталкиваюсь. Вне зависимости от того сколь удачно он впоследствии был дозалит, место нужно проверять руками на предмет отсутствия дублей.

Понимаю, что некрофилия но отпишусь.
В проект сам пришел из потлача. НО…
пользовался им совсем не много и ничего не сломал. Но это только потому что я понимал, что такое данные и в каком виде они могут существовать (хоть и не знал в каком виде они в OSM). Прежде чем что-то добавить/изменить я тщательно искал информацию и разбирался как надо, как делают другие. И только “осознав” как сделать правильно начинал “постоянно” работать с этим.

Как показывает опыт, большинство новичков этого не делают, и после внятных объяснений о том, что из себя представляем OSM прозревают (в разных смыслах))). Те кто более вменяемый долго спрашивают, удивляются, рассказывают “как они думали”, еще раз прозревают и либо остаются, либо отваливают.
Некоторые все таки слушать не пытаются и продолжат гнуть свою линию в потлаче. И тут в дело вступает не неадекватность новичка, а “зло” потлача. Те же POI и amenity реализованы очень плохо - их мало, а некоторые совсем не соответствуют.

Но в последнее время столкнулся с новым злом - iD. После связи с несколькими новичками после правок в iD и посмотрев причину - понял: в iD описание понятий совершенно не соответствует значению тегов + даже при наличии тегов в iD не гарантирует того что они будут использованы в виду того что они видны только после применения поиска (что не очевидно новичкам)

Одно из того что мне не нравится, так это выставление новичками очевидных умолчательных свойств. Как например поголовно лепят везде oneway=no, очень часто на дороги вешают bicycle: yes, foot: yes, motor_vehicle: yes. Мне видится, что в редакторе нужно серым писать значение по умолчанию, чтобы не возникало желания переправлять yes на yes.

Здравая идея, осталось донести до автора iD