создаешь телефонную али контактную бд, эффективно связываешь ее с осм. выкладываешь ее в свободный доступ и предлагаешь пополнять и уточнять.
осм это таки про географические данные.
не надо натягивать ужа на ежа и заниматься костылингом, вместо создания качественного и функционального нового открытого проекта.
так-то у одного офисного здания большой компании может быть очень до хрена телефонов разной прикладной направленности.
Создатели османда (того самого, у которого 2к открытых issues и базовая навигация толком не работает) так и поступили - пилят очередной сайт отзывов на блокчейне. Вытянут? Готов поспорить на ящик пенного, что нет.
Ну я даже не знаю, что на это сказать. Если вы считаете, что контакты объекта на карте это не географические данные… боюсь предположить что вы думаете про остальные “данные”.
И именно эта информация нужна конечному пользователю, а не 3D домики и форма листьев на деревьях.
и правильно делают. взлетит - начнут все использовать, ибо задумка неплохая. не взлетит - ну и ладно.
или тоже предлагаешь впихивать систему отзывов в апи осм, в основной базе данных собирать эти отзывы и впихивать в выгрузки.
в контакты объекта может входить набор телефонов: директора, бухгалтерии, службы доставки, телефон кадровой службы и приема на работу, телефоны менеджеров направлений деятельности и ваогн и тележка других.
все их впихивать в осм ?? зачем ?? каждый нужен определенному пользователю, а остальным не вперлись.
мне хватит универсального контактного телефона общей направленности - там я могу уточнить куда звонить по моей проблеме и если нужно я его запишу.
для примера “излишеств” стоит упомянуть про предложения впихивать в осм: меню кафешек, вариантов табака для курительной, список товаров продающихся в данном магазине, набор сервисов конкретной автомастерской и т.д.
именно это нужно пользователю, но к сожалению внесение и поддержка такой информации в осм практически невозможна. потому и ее практически нет и никто в нее не упирается.
Можно весь список того, что не интересует pfg21 в ОСМ?
А зачем номера квартир в доме мапить? Жильцам и их знакомым они известны, а остальным не впёрлись.
Вот это как раз вносить не стоит. Как и расписание общественного транспорта. А вот разработать протокол для динамической подгрузки подобной информации уже давно пора.
номера мапятся по подъездно. это вполне нормальная информация для точки подъезда, ничуть неизлишняя.
в отличии от, к примеру, индур-мапинга местоположения входа и формы конкретной квартиры.
для кварталов старых домов питера это весьма пользительная информация %)
почему это не надо вносить к примеру набор сервисов для автомастерских ??
я хочу вбить в поиск “починка двигателя” и чтобы мне показали автомастерские, которые этим занимаются, а кучу незанимающихся не показали.
или к примеру, есть стройтовары, которые специализируются на сантехнике, а другие на отделке, и их весьма стоит отличать.
кроме таких глобальных делений, есть более мелкие тонкости в товаре. к примеру только в одном из кучи стройхозтоваров рядом, есть полный набор всех крепежных элементов, отдельный большой стенд с вариантами крепежа от пола до потолка и шириной метра два. во всех остальных что-то есть а чего-то нет.
почему это вносить не стоит ??
это сильно важнее телефона дира какойто там дальней фирмочки
Ну подождите, вы мешаете в кучу разную информацию. Починкой двигателя они будут заниматься пока не закроются, эту информацию можно внести. А вот акции, скидки и прочая фигня должна подгружаться динамически. Специализацию на сантехнике также можно внести, а крепежных элементов завтра может и не быть. Тут, предложу вам последовать своему совету и запилить Open.Market
это всё - дополнительная информация для пои. как набор кучи разных телефонов, так и варианты сервисов.
вопрос в другом будет ли кто поддерживать предложенную схему множества внесенных телефонов. заинетресует ли она кого-либо, как во внесении, так и в использовании. или она так и зависнет мертвым грузом в виде десятка замапленных лично тобой поишек.
есть уверенность - пиши пропозал, проталкивай в маппинг. а там глядишь пойдет в массы. но потребуется упорство в продвижении. осилишь ??
не для меня я лишь описал противоположную точку зрения на твое предложение. и плюс некоторый опыт различных давних предложений, так и зависших в хотелках.
На английском не осилю. На русском его прочитают те же два человека, что и на форуме.
Если мы говорим о тех маперах, которые наполняют нашу любимую КУЧУ ДАННЫХ ради удовольствия, то ответ – скорее всего нет. Большинство из них и один контакт вносит только по большим праздникам. Главным поставщиком данных должны быть владельцы этих самых данных, но для этого необходимо предоставить им необходимые функции и удобные инструменты. А как, спрашивается, это сделать, если для малейшего изменения требуется год вести переписку? Спасибо хоть не бумажными письмами…
Проходил курс американского языка и там преподаватель сказал что ресторан это место где можно купить еду, сесть и поесть. Поэтому для американцев Макдоналдс это ресторан. Словосочетание “fast food restaurant” не режет им слух. Но в русском языке ресторан имеет другое значение, что периодически вызывает споры при маппинге. Языковые отличия, что делать.
OSM стартовал как английский проект, поэтому первоначальные теги ближе к английскому чем американскому. Ну а так, да, теги это коды, мнемоники, не нужно их переводить со словарём. В разных диалектах значения могут различаться.
ни одного документа по этому поводу нет, так что обсуждать нечего осм отображает реальность, а не формирует.
ну а то, что народ один и тот же, так это и без всяких полит.задрючиваний понятно.
А какие могут быть отличия в тегировании Россия-Беларусь? Бегло посмотрел, там везде в name указывают русское наименование, никаких (даже мелких) отличий в схемах тегирования не нашёл. Границу передвинуть не проблема.
СНТ без СНТ в name.
Озера без озер (вроде)
Остановки автобусов на белорусском Минск и еще много где.
Границы нп не как (мульти)полигоны place, как отношения и с place, и одновременно с boundary administrative admin_level=10