Работа для бота (требуется помощь ботоводов)

полагаю, основная причина появления такого принципа - перфекционизм
данные должны быть ровные, аккуратные, всё разложено по полочкам
при этом рендерер должен это всё умно анализировать и правильно визуализировать
но рендереры есть такие какие они есть
и детальное рассматривание имени “№5” никакой пользы посетителю ресурса не принесёт
он не догадается - больница это, школа или ещё что-то
просто уйдёт с ресурса и всё
хотя данные будут максимально корректны
в аменити будет записан тип, в имени - всё остальное
(это лишь один пример, может не идеально корректный, уверен можно найти ещё)

отпишусь и я… )

как можно увидеть, за “стандартизацию” ОСМ выступают ОСМеры, пришедшие в проект (по крайней мере на форум) в последние 2-3 месяца
для таких “новичков” это нормальная стадия :slight_smile:
все проходили через желание сделать все “под одну гребенку” и со временем бОльшая часть поняла, что это бессмысленно\бесполезно\вредно

т.е. я советую не спешить с попыткой расставить теги типа website=* или operator=*
ведь могут быть магазины\аптеки имеющие такое же название, как у крупной федеральной сети, но не имеющие к ней никакого отношения

короче, не спешите ломать дрова :wink:

лично мне было достаточно один раз хорошо подумать над актуализацией
это относится и к сайтам и к мусорным корзинам/деревцам/etc
внести то можно, но если никто не будет за этим всем следить, то очень быстро эта информация станет неверна
это улицы с домиками стоят довольно долго
а всякие гаражи/киоски могут пропадать и появляться относительно быстро
// может немного не в тему, просто мысли вслух
// немного обобщу: идеальным данным нужна идеальная поддержка

Но с другой стороны мы имеем полный разброд даже в близко расположенных объектах … хотел привести к единому виду церкви в городе и увидел, что применены все N! вариаций как это можно сделать … Как раз не причёсывая (я за Ёфикацию) данные мы получим помойку так как рендер должен быть шибко умный чтобы распознавать все комбинации атрибутов.

Может быть это должны быть и не боты в духе Википедии, но какие-то автоматизирированые тулы а-ля валидаторы …

P.S. А реально ли принципиально писать СШ №15 или Школа №15? Вряд-ли кто-то будет пользоваться OSM чтобы найти ближайшую школу для 14-летнего своего чада … А официальные названия нужны для документов, там она и именуется как юридическое лицо “Муниципальное общеобразовательное учреждение средняя общеобразовательная школа № 15”.

Как только карты от OSM начнут активно использовать всякие “местечковые” сайты “идеальная” поддержка будет гарантирована. Собственно, уже начинают использовать, ибо карты многих городов вполне полноценны, а движок удобней того растрового убожества, что было популярно десяток лет назад.

Возможно надо начать с “пр-т”, “Ул.”, “пл.” и т.п., да и привести наименования улиц в соответствие с нормами русского языка не мешало бы - работа как раз для бота.

Нет, причина другая.

Ваша ошибка в том, что вы считаете, будто рендерер на главной странице проекта — самый лучший, самый официальный, эталонный.
На самом деле данными OSM пользуются множество самых разнообразных визуализаторов и конвертеров, и все они одинаково важны. Подстраивая данные в угоду рендереру на странице OSM, мы тем самым искажаем данные для других рендереров и ухудшаем пригодность данных в общем случае.
Вот именно отсюда появилось правило “Не рисуйте под рендер”. Данные отдельно, обработка данных отдельно.

Так ведь цель OSM — не набор популярности. А сбор и обработка картографических данных в том виде, в каком они требуются участникам проекта.

почему обязательно “искажаем и ухудшаем”?
ведь анализируя визуализацию вполне можно найти более подходящий способ организации данных

вот именно, делается не база ради базы
конечная цель - предоставление качественного сервиса пользователю
и если для этого прийдётся немного отойти от идеальной модели, то что ж…

даже если я так и считаю, это не важно
главное то, какое количество юзеров им пользуется
у меня нет статистики, но если данные отображаются некорректно у 80% посетителей, то это явный повод что-то менять
вполне возможно, что неправ рендерер, но точно так же возможно что некорректно структурированы данные (что в свою очередь мешает рендереру правильно их отобразить)

Для красивого отображения карты на главной web-странице хорошо бы отойти от идеальной модели.
А для качественной карты в навигаторе Garmin — тоже отойти, но чуть-чуть по-другому.
А для навигаторов Навител — отойти еще по-другому.
Для хитрого стороннего online-сервиса хорошо бы чуть отойти от идеальной модели своим, четвертым способом.

Так каким же из четырех способов мы будем отходить от идеальной модели? Которое из перечисленных назначений OSM объявим более приоритетным?

Вот лично мне от проекта OSM нужна карта для навигатора Garmin, причем в пеше-туристском, а не автомобильном стиле. И больше, собственно, ничего. Я могу начать подгонять данные в базе под отображение в навигаторе. Ну, скажем, какой-то тип магазина, который сейчас не попадает в карту, заменять на shop=convienence, чтоб хоть какая-то иконка магазина была. Но если я так буду делать, меня запинают участники OSM, цели у которых иные. И правильно сделают.

редко одна и та же сущность настолько по-разному отображается, что требуются везде корректировки
конфликт возникает лишь тогда, когда корректное отображение одним рендерером ведёт к некорректному отображению другим
если изменение поможет улучшить вид в одном из рендереров, не повлияв негативно на другие и не нарушив логичность внутренней стуктуры базы, то чем же это плохо?

если всё уж настолько коряво отображается, то велика вероятность что проблема не в рендерере, а в данных
и значит необходимо пересмотреть способ хранения конкретных данных

как общее решение - попытаться найти компромисс между отображением самым популярным рендерером и внутренней логичностью данных в базе
если удалось - замечательно, если нет - значит пока трогать нельзя (нужно ждать корректировки модели и/или отображения)

прокомментировал выше
конфликты бывают не всегда
либо бывают настолько незначительны, что ими можно пренебречь - и поставить приоритетом логичность

Прямоуголить здания ботами нельзя - вы весь центр питера похерите (а он и так еще не нарисован до конца :)).

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

Kaylee, не нужно два имени, должно быть правильное имя, т.е. с ё. А вот если поиск без ё не поддерживает, надо его доделывать, но это не повод коверкать названия. И почему веб-сайты надо поддерживать? Один раз поставил и всё. Как будто просто так создан тег website.

Zkir, информационная помойка это скорее сейчас, когда разброд и шатание. Ничего плохого от стандартизации не будет.

dedNikifor, почему стандартизация бессмыслена\бесполезна\вредна? Те же самые теги - это стандартизация. Кроме того, просто позор нагружать человека лишними делами, которые может сделать бот.

TarzanASG
Мы это уже проходили, тема абсолютный повтор этой:
http://forum.openstreetmap.org/viewtopic.php?id=9130

Вот еще:
http://forum.openstreetmap.org/viewtopic.php?id=8645
http://forum.openstreetmap.org/viewtopic.php?id=9464

Чтение хотя бы заголовков тем рулит.

chnav, мда. Какой позор. Находятся ещё внутри страны те, кто “шакалят” у иностранных посольств люди, которые выступают против ё - в Википедии бы быстро на место поставили.

да ничего страшного в таких темах нету
может какая-то свежая мысль проскочит
в любом случае можно дать линки на связанные по смыслу темы
либо даже сделать отдельную ветку с изложением устоявшегося мнения сообщества по теме

А я полагаю, это необходимо для РАЗВИТИЯ проекта - чтобы недостатки существующих рендеров не препятствовали расширять OSM новыми данными.

Нет, рендеры такие, какими их создают их авторы.

Полностью согласен. Поэтому и имени такого быть не должна.
То, что это школа, должно быть видно из основного тега, что средняя - из уточняющего, номер - также из уточняющего, а что именно с углубленным изучением какого-либо предмета - из description. Тегу name для объектов, не имеющих собственного имени, делать нечего.

Ткнет мышкой и получит дополнительную информацию об объекте (т.е. из уточныющих тегов, description, а также о web-сайтах, времени работы и пр.

Изготовление костылей под недостатки и ошибки существующих рендеров сильно мешает как изгтовлению новых более совершенных рендеров, так и совершенствованию существующих, т.к. как только в рендере появляется какая-либо новая технология, она сразу вступает в конфликт с имеющимися костылями.

Слава Б-гу, тут не википедия. Более того, у OSM совсем другой принцип. В отличие от википедии, OSM это один большой сплошной ОРИСС. В OSM мапят то что видят. Править что-то, не имея никакого представления как оно обстоит в действительности ( на местности) - моветон.

Если есть желание ставить кого-то на место, может лучше отправиться обратно, в педивикию википедию?

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

Неочевидно.
В КЛАДР, например, принципиально без ё. Как только вводим ё, получаем проблемы с КЛАДРОМ.

Вопрос на засыпку: предлагаемая стандартизация" предполагает исключительно введение новых тегов или хотя бы иногда их замену либо удаление?
Если второе - то будучи проведенной ботом такая “стандартизация” неизбежно приведет к потере или искажению информации.

Есть такой принцип: Внося свою лепту, не выноси чужую. Та стандартизация, которую бот в состоянии произвести, ботами делается (например, проставление новых тегов). А та, которая подразумевает изменение существующих тегов, ботом делаться не должна.

andriano, ну вот, под КЛАДР подстраиваться. Пусть будет какой-нибудь cladr:name и там будет без ё.

Расстановка веб-сайтов, которую я предлагаю - это как раз добавление новых тегов. Относительно школ можно, во-первых, не трогать то, где будут искажения информации, а, во-вторых, можно переместить информацию из текущего тега в какой-нибудь old_tag_name. Разве нельзя так?

Уже.
Но заметь, не ВМЕСТО того, что было в name, а именно новый тег cladr:name.

А какой в этом смысл?
И в какие теги перемещать информацию после второй, третьей, десятой правки? Тут каждые полгода появляется кто-то с идеями глобальной автоматизированной правки.