Comments 44
Сколько ни пытался начать коммитить в осм, именно эти странности с тегами сбивали с толку.
Ода из очень больших странностей, по моему мнению — нет договоренности, как правильно проставить одному зданию два адреса(такая адресация есть почти у каждого углового дома в России).
Ну, не то, чтобы совсем нет договорённости. Но способов, как это можно обозначить, действительно штук пять.
На домах ведь таблички есть с официальным адресом. Неужели их две разных? Никогда не обращал внимания, наверное.
В масштабах целой страны таких случаев более чем достаточно.
Полно́. Буквально соседний дом имеет два адреса. Я 10 лет проучился в школе с двумя адресами. В центре города, где живу, наверное, в каждом квартале найдётся такой дом.
Может быть просто у вас в городе таких домов нет. Я у себя из всего того, что обошёл видел только 2 таких дома. Раньше были два маленьких домика, потом иснесли и на их месте поставили двухвартирный дом. В результате получился один дом с двумя адресами. Пришлось дом разрезать на 2 части и каждой присвоить свой адрес. Больше ничего подобного не видел.
«Любые тэги» — самое большое проклятие осма. Видно, что изобретали его люди с линуксом головного мозга. Если бы сформулировать это хотя бы как "допускаются кастомные тэги" — уже было бы намного лучше. Да, возможности кастомизации и подстройки под частности нужны — но основное ядро должно быть тщательно продумано и стандартизировано. Мне казалось, что это аксиомная аксиома. Ан нет, кто-то любит себе проблемы создавать под предлогом свободы и настраиваемости :)
Строго говоря, оно так и есть на практике — допускаются любые пользовательские теги. То есть если вы хотите вносить какие-нибудь диковинные признаки (скажем, толщину стен домов, если вы ее знаете и она зачем-то вам нужна) вы можете, никого не спрашивая, ввести новый ключ, описать его в Wiki (чтобы у людей не возникало вопроса, а что это за тег) и назначать. А если это что-то для общего употребления, то следует пройти процедуру внесения предложения, его обсуждения и голосования. Но во-первых, даже обсуждение и голосование не гарантируют, что плохой, бестолковый тег не будет принят. Во-вторых, даже официально не одобренные теги становятся общеупотребительными, особенно когда они с горем пополам позволяют обозначить то, для чего нормальной схемы до этого придумано не было — есть множество участников, у которых зудит в каком-то месте, только дай что-то обозначить. А хорош или плох способ — их не очень волнует.
Так что зло не в том, что можно придумать любой тег, а в том, что любой тег может, в конце концов, стать общеупотребительным, несмотря на свою бессмысленность. И это, фактически, ворует у проекта возможность иметь качественное обозначение, потому что когда какое-то уже есть, изменить его — уже куда сложнее.
Так что зло не в том, что можно придумать любой тег, а в том, что любой тег может, в конце концов, стать общеупотребительным, несмотря на свою бессмысленность. И это, фактически, ворует у проекта возможность иметь качественное обозначение, потому что когда какое-то уже есть, изменить его — уже куда сложнее.
С одной стороны да, бардак есть. Особенно это ощущал, когда делал справочник адресов для Москвы из выгрузки OSM. Где-то есть КЛАДР код, бывает информация ОКАТО. Хотелось найти парсер названий и что есть улица, что переулок, что проезд и т.д
Но вот постороение онтологий для обозначений значительно уменьшило бы количество вносимых данных в карту. А так они вроде есть и вроде нет
Но вот постороение онтологий для обозначений значительно уменьшило бы количество вносимых данных в карту. А так они вроде есть и вроде нет
Улица, переулок и проезд — это части названий. Также как street, avenue, gata, katu и прочее. Типы улиц в OSM определяются не этим, а использованием и значимостью в дорожной сети.
Что касается уменьшения объема вносимых данных — я не уверен, что качественные классификации могут реально помешать что-то вносить. Тем более, что бездумно можно выбрать произвольный тег, который просто кажется подходящим. Разница в том, что сейчас и те, кто думают над значением тегов, и те, кто об этом не думают, в определенных случаях вносят неопределенные данные, значение которых слишком размыто, чтобы их использовать каким-то полезным образом.
Что касается уменьшения объема вносимых данных — я не уверен, что качественные классификации могут реально помешать что-то вносить. Тем более, что бездумно можно выбрать произвольный тег, который просто кажется подходящим. Разница в том, что сейчас и те, кто думают над значением тегов, и те, кто об этом не думают, в определенных случаях вносят неопределенные данные, значение которых слишком размыто, чтобы их использовать каким-то полезным образом.
>> даже многие опытные участники проекта не понимают этой проблемы или понимают ее, но утверждают, что она незначительна
Не знаю, насколько я опытный участник (265 правок), но меня тоже как-то не убедило большинство приведенных в статье примеров.
Не знаю, насколько я опытный участник (265 правок), но меня тоже как-то не убедило большинство приведенных в статье примеров.
Опыт определяется не количеством правок, а тем, пытались ли вы использовать данные, а не только вносить. При чем именно такие данные, которые используют теги с перечисленными выше проблемами. И тем, как вы эти проблемы для себя решили. Ну и встречный вопрос: как вы для себя решаете, что перед вами, kiosk, convenience shop, supermarket? И каким редактором вы пользуетесь — iD или JOSM? Используете ли пресеты в JOSM или пишете теги вручную?
В том же JOSM иногда проще/быстрее внести тэг вручную.
Я про iD спросил не потому, что «JOSM — для крутых, iD — для лохов», а потому, что в iD сам по себе механизм ввода обозначения предполагает, что человек берет и начинает писать слово, которое относится к обозначаемому объекту. Это как-бы прячет реальные теги от пользователя, то есть он их, теоретически, может вообще не видеть. И не задумываться, соответственно, ни о чем, потому что для этого нет никаких причин: он думает, что раз он написал там «супермаркет», то система как-то сама разберется, какой тип присвоить и так далее. В JOSM это невозможно даже с использованием пресетов — пользователь всегда видит получившиеся теги, а потому, у него есть хоть какая-то пища для ума на эту тему.
Мир не идеален, вот что я думаю :) При всех своих недостках OSM дает порой такие данные, которых нигде больше нет.
Пользуюсь JOSM, пресетов стало гораздо больше и это славно, но иногда все равно приходится в wiki лезть за тэгами.
Kiosk — совсем небольшой по площади, зато у него хорошие часы работы. Сonvenience shop — небольшой магазинчик на углу, побольше площадь и ассортимент. Supermarket — еще больше по площади, часто там есть что-то иное, чем просто еда + мыло и зубная паста. Например, там могут быть баллоны для газовых горелок, одежда, еще что-то полезное, но редко нужное.
В общем-то все это не очень важно, т.к. большинство магазинов выглядят на карте одинаково (тележка).
Пользуюсь JOSM, пресетов стало гораздо больше и это славно, но иногда все равно приходится в wiki лезть за тэгами.
Kiosk — совсем небольшой по площади, зато у него хорошие часы работы. Сonvenience shop — небольшой магазинчик на углу, побольше площадь и ассортимент. Supermarket — еще больше по площади, часто там есть что-то иное, чем просто еда + мыло и зубная паста. Например, там могут быть баллоны для газовых горелок, одежда, еще что-то полезное, но редко нужное.
В общем-то все это не очень важно, т.к. большинство магазинов выглядят на карте одинаково (тележка).
А вот то, что реально важно — это чтобы вообще на карте было что-то отмечено, пусть и не очень точно. Мне гораздо больше поможет информация о том, что в каком-то населенном пункте есть два магазина и три кафе, чем информация о том, какие они.
Ваша позиция по этому вопросу вполне объяснима: во-первых, вы не используете сами данные OSM, вы используете карту на их основе, которая является самым примитивным вариантом производного продукта из этих данных. Лично вам (подчеркиваю — лично) сгодилось бы, вероятно, даже если бы все было отмечено просто «магазин». Естественно, человеку, который весьма ограничен в своих запросах и оценивает ситуацию только по себе, сложно или почти невозможно представить себе проблемы, стоящие, например, перед создателями каталогов POI или перед теми, кто настраивает поисковые системы. Ваш случай — то, что в науке называется «вырожденный». И по нему судить об общей ситуации абсолютно неверно.
Так OSM же делается людьми для людей в первую очередь, а не для создателей каталогов POI. Те, кто профессионально заинтересован в подобного рода данных, имеют совершенно иные требования и возможности, поэтому они могут создать/купить свою карту, а не говорить пользователям OSM, что они что-то делают не так. Зачем пользователю заниматься в свое свободное время точной классификацией того, что он все равно не увидит?
У вас весьма ограниченное представление о проекте и его задачах.
Во-первых, известное правило «не рисовать под рендер» и само существование огромного количества ключей, содержимое которых никак не отображается ни в одной из растровых карт, четко указывают на то, что OSM — это нечто несравнимо большее, чем карта на osm.org
Во-вторых, проект хоть и называется OpenStreetMap, но исходные данные распространяются под Open Database License, и эта база — первична, а все картинки, которые на ее основе создаются — вторичны.
В-третьих, те самые люди, для которых все это создается, пользуются вторичными, производными продуктами: онлайн-сервисами карт, картами, встроенными в картографические приложения вроде OSMAnd, Maps.ME, альтернативными картами для навигаторов Garmin, ПРО Город, Автоспутник и так далее. Также, выгрузки из OSM в виде shape-файлов использует невообразимое число отдельных разработчиков и сервисов. И это все — для людей. Если бы задачей OSM было рисование единственной карты, то у нас был бы графический редактор, а не JOSM или iD с весьма сложными структурами векторной геометрии и семантической атрибутики.
В-четвертых, есть целые сервис, являющийся органической частью проекта, overpass-turbo.eu предназначенный для выборок по сложным пространственным и логическим запросам. Плюс — публикация planet.osm и diff-файлов к нему, именно для нужд обеспечения доступности исходных данных. Если бы задачей проекта была карта-картинка, этого всего бы, вероятно, просто не было.
Собственно, многие из тех сервисов и навигационных средств для своего функционирования создают те самые каталоги POI и системы поиска. То же можно сказать о системах роутинга (прокладки маршрута).
И вот там во всей красе расцветают все те атрибуты, которые мы не видим на карте стандартного стиля на osm.org: время работы магазинов, назначение социальных учреждений, запреты поворотов на улицах, ограничения скорости и прочее. К большому сожалению, таких как вы — очень много, и эти люди вносят в базу только то, что видно на карте. Это, конечно, тоже какой-то вклад, но заведомое ограничение информации только этим делает базу неполной.
Так что ваше понимание — узко и приземленно. Так что или изучите предмет лучше, или не спорьте упорно о том, о чем знаете очень мало.
Во-первых, известное правило «не рисовать под рендер» и само существование огромного количества ключей, содержимое которых никак не отображается ни в одной из растровых карт, четко указывают на то, что OSM — это нечто несравнимо большее, чем карта на osm.org
Во-вторых, проект хоть и называется OpenStreetMap, но исходные данные распространяются под Open Database License, и эта база — первична, а все картинки, которые на ее основе создаются — вторичны.
В-третьих, те самые люди, для которых все это создается, пользуются вторичными, производными продуктами: онлайн-сервисами карт, картами, встроенными в картографические приложения вроде OSMAnd, Maps.ME, альтернативными картами для навигаторов Garmin, ПРО Город, Автоспутник и так далее. Также, выгрузки из OSM в виде shape-файлов использует невообразимое число отдельных разработчиков и сервисов. И это все — для людей. Если бы задачей OSM было рисование единственной карты, то у нас был бы графический редактор, а не JOSM или iD с весьма сложными структурами векторной геометрии и семантической атрибутики.
В-четвертых, есть целые сервис, являющийся органической частью проекта, overpass-turbo.eu предназначенный для выборок по сложным пространственным и логическим запросам. Плюс — публикация planet.osm и diff-файлов к нему, именно для нужд обеспечения доступности исходных данных. Если бы задачей проекта была карта-картинка, этого всего бы, вероятно, просто не было.
Собственно, многие из тех сервисов и навигационных средств для своего функционирования создают те самые каталоги POI и системы поиска. То же можно сказать о системах роутинга (прокладки маршрута).
И вот там во всей красе расцветают все те атрибуты, которые мы не видим на карте стандартного стиля на osm.org: время работы магазинов, назначение социальных учреждений, запреты поворотов на улицах, ограничения скорости и прочее. К большому сожалению, таких как вы — очень много, и эти люди вносят в базу только то, что видно на карте. Это, конечно, тоже какой-то вклад, но заведомое ограничение информации только этим делает базу неполной.
Так что ваше понимание — узко и приземленно. Так что или изучите предмет лучше, или не спорьте упорно о том, о чем знаете очень мало.
Звучит убедительно, но наезды на конкретного человека не приносят никакой пользы ни Вам, ни проекту OSM.
Если конечные пользователи делают что-то «неправильно», то на это можно повлиять техническими средствами (удобными редакторами со стандартизированным набором тэгов), предупреждениями о недопустимых сочетаниях тэгов и т.д., но никак не морализаторством и обвинениями.
P.S. В точности то же самое наблюдается при строительстве некоторых городов. Проектировщики создают сложное и нелогичное окружение, а люди потом используют его «неправильно» — вытаптывают тропинки для обеспечения самого быстрого пути, переходят на красный в определенных местах гораздо чаще, чем в других, игнорируют нелогично проложенные велодорожки и т.д. В городах, где есть разум, окружение потом приводят под нужды людей. В остальных городах выставляют полицейских, чтобы они штрафовали за «неправильное» поведение, пишут в газетах о нарушителях порядка и т.д.
Если конечные пользователи делают что-то «неправильно», то на это можно повлиять техническими средствами (удобными редакторами со стандартизированным набором тэгов), предупреждениями о недопустимых сочетаниях тэгов и т.д., но никак не морализаторством и обвинениями.
P.S. В точности то же самое наблюдается при строительстве некоторых городов. Проектировщики создают сложное и нелогичное окружение, а люди потом используют его «неправильно» — вытаптывают тропинки для обеспечения самого быстрого пути, переходят на красный в определенных местах гораздо чаще, чем в других, игнорируют нелогично проложенные велодорожки и т.д. В городах, где есть разум, окружение потом приводят под нужды людей. В остальных городах выставляют полицейских, чтобы они штрафовали за «неправильное» поведение, пишут в газетах о нарушителях порядка и т.д.
Пиво/водку/сигареты куда идти покупать, если возле дома есть kiosk? Ещё не так давно можно было всё это купить именно в нём. Сейчас водку точно нельзя там купить. Ну и как бы kiosk сам по себе не магазин ни капли, сейчас часто вижу building=kiosk, а в shop пишут уже что-то осмысленное.
Самое главное — быстро найти такой магазин где ты можешь всё что тебе требуется купить. В незнакомом городе зарядник для ноутбука не найдёшь (как бы computer должно быть наверняка, но может быть ещё и в electronics, и в mobile_phone), если по названию магазина не можешь определить ассортимент. Т.е. очень много остаётся тыкательного поиска, чем и приходится заниматься.
Ну и пример с лечебными учреждениями: в Новосибирске были очень популярны клиники типа «гинеколог/стоматолог» — как такое одним тегом обозначить? А кафе + кондитерская + пекарня? Или мастерская «минутка» — ателье, ключи, обувь? А какая разница между supermarket и department_store, и в чём проблема для покупателя что их разделили на два различных магазина? Вот и приходится выбирать что-то одно имеющееся, а остальное хотя бы в description пытаться втиснуть.
Самый жизненный пример осмысленного тегирования — АЗС, на форуме неоднократно всплывало «не нужны мне АЗС, хочу АГЗС». Вот теперь эти люди могут и затегировать и найти такие заправки. А так-то wikimapia уже давно существует, и если есть желание, то на примере, опять же, Новосибирска (ему совсем не повезло, никто им не занимается ибо ДубльГИС родом оттуда) можно попытаться найти что-то нужное, там пользователи очень хорошо применили навыки wikimapia в osm.
Самое главное — быстро найти такой магазин где ты можешь всё что тебе требуется купить. В незнакомом городе зарядник для ноутбука не найдёшь (как бы computer должно быть наверняка, но может быть ещё и в electronics, и в mobile_phone), если по названию магазина не можешь определить ассортимент. Т.е. очень много остаётся тыкательного поиска, чем и приходится заниматься.
Ну и пример с лечебными учреждениями: в Новосибирске были очень популярны клиники типа «гинеколог/стоматолог» — как такое одним тегом обозначить? А кафе + кондитерская + пекарня? Или мастерская «минутка» — ателье, ключи, обувь? А какая разница между supermarket и department_store, и в чём проблема для покупателя что их разделили на два различных магазина? Вот и приходится выбирать что-то одно имеющееся, а остальное хотя бы в description пытаться втиснуть.
Самый жизненный пример осмысленного тегирования — АЗС, на форуме неоднократно всплывало «не нужны мне АЗС, хочу АГЗС». Вот теперь эти люди могут и затегировать и найти такие заправки. А так-то wikimapia уже давно существует, и если есть желание, то на примере, опять же, Новосибирска (ему совсем не повезло, никто им не занимается ибо ДубльГИС родом оттуда) можно попытаться найти что-то нужное, там пользователи очень хорошо применили навыки wikimapia в osm.
Напрягите логику, пожалуйста.
Если возле дома есть shop=kiosk, то там может оказаться что угодно — от исключительно сигарет до исключительно игрушек, потому что ассортимент за этим тегом не закреплен. И такого — пятьдесят тысяч вхождений в базе.
Почему вы решили, что клинику «гинеколог/стоматолог» нужно обозначать одним тегом? Читайте healthcare 2.0. Вы просто плохо ориентируетесь в системах обозначений, потому вам кажется, что есть проблемы, которых на самом деле нет.
Вопросы по поводу АЗС/АГЗС — того же порядка: кто-то не знает про wiki.openstreetmap.org/wiki/Key:fuel
И с Викимапии пример брать абсолютно нечего — нет там ни одной положительной практики, пригодной для OSM. Так что все — мимо.
Если возле дома есть shop=kiosk, то там может оказаться что угодно — от исключительно сигарет до исключительно игрушек, потому что ассортимент за этим тегом не закреплен. И такого — пятьдесят тысяч вхождений в базе.
Почему вы решили, что клинику «гинеколог/стоматолог» нужно обозначать одним тегом? Читайте healthcare 2.0. Вы просто плохо ориентируетесь в системах обозначений, потому вам кажется, что есть проблемы, которых на самом деле нет.
Вопросы по поводу АЗС/АГЗС — того же порядка: кто-то не знает про wiki.openstreetmap.org/wiki/Key:fuel
И с Викимапии пример брать абсолютно нечего — нет там ни одной положительной практики, пригодной для OSM. Так что все — мимо.
Перечитайте начиная с комментария на который я отвечал, пожалуйста.
Проблемы были и их в hc2.0 и fuel успешно решили (пожарники и лесники тоже в этом списке), но в остальных случаях (shop/amenity/craft/highway/natural) проблемы так и остались, никто их не решает (opensource же), но хоть споры не утихают. С кондитерской/пекарней и «минуткой» что делать-то будем?
Новосибирск в OSM уже успешно наполовину заполнен в духе wikimapia и это был пример достаточной карты, судя по описанию bpeme4ko.
Проблемы были и их в hc2.0 и fuel успешно решили (пожарники и лесники тоже в этом списке), но в остальных случаях (shop/amenity/craft/highway/natural) проблемы так и остались, никто их не решает (opensource же), но хоть споры не утихают. С кондитерской/пекарней и «минуткой» что делать-то будем?
Новосибирск в OSM уже успешно наполовину заполнен в духе wikimapia и это был пример достаточной карты, судя по описанию bpeme4ko.
Очень хорошо обозначена проблема. Но уйти от нее ой как тяжело: поменять принцип тегирования от общего к частному. Да, в отдельных областях типа healthcare, это почти получилось, но все эти убеждения и споры на форуме иногда выглядят как борьба с ветряными мельницами.
Фактически, это единственный путь сохранить гибкость и максимально формализовать данные: использовать атомарные теги для обозначения конкретных независимых свойств по отдельности, а не пытаться засунуть в значение тега, комплекс субъективно подразумеваемых свойств, придумывая новые собирательные категории и переосмысливая значения старых.
Людям с системным мышлением очень тяжело влиться в ОСМ, когда они встречают такие дикие вещи как противопоставление «сладкого», «твердого» и «зеленого». Или, например, непоследовательность с «shop» и «amenity». Вот начинающий маппер видит shop=bycicle, shop=grocery, shop=clothes, amenity=cafe, amenity=library, amenity=parking, amenity=car_wash и у него может сложится представление, что он все понял, мол, ага, значит shop — это продажа товаров (по разным типам), а amenity — это, похоже, место предоставления каких-либо услуг. Потом он видит shop=hairdresser, shop=beauty, shop=copyshop, shop=laundry и понимает, что shop это и услуги тоже. Потом он видит shop=mall, shop=kiosk и понимает, что значение shop — это не обязательно вид товара/услуги. Потом замечает, что highway означает не только условный статус дороги, а может означать также ее покрытие, скоростной режим и назначение (track, motorway), или может обозначать всякие объекты на дороге: crossing, traffic_signals, или вообще то, что почему-то не попало в amenity/shop: services, rest_area, phone. И уходитв монастырь мапить в народные карты.
Фактически, это единственный путь сохранить гибкость и максимально формализовать данные: использовать атомарные теги для обозначения конкретных независимых свойств по отдельности, а не пытаться засунуть в значение тега, комплекс субъективно подразумеваемых свойств, придумывая новые собирательные категории и переосмысливая значения старых.
Людям с системным мышлением очень тяжело влиться в ОСМ, когда они встречают такие дикие вещи как противопоставление «сладкого», «твердого» и «зеленого». Или, например, непоследовательность с «shop» и «amenity». Вот начинающий маппер видит shop=bycicle, shop=grocery, shop=clothes, amenity=cafe, amenity=library, amenity=parking, amenity=car_wash и у него может сложится представление, что он все понял, мол, ага, значит shop — это продажа товаров (по разным типам), а amenity — это, похоже, место предоставления каких-либо услуг. Потом он видит shop=hairdresser, shop=beauty, shop=copyshop, shop=laundry и понимает, что shop это и услуги тоже. Потом он видит shop=mall, shop=kiosk и понимает, что значение shop — это не обязательно вид товара/услуги. Потом замечает, что highway означает не только условный статус дороги, а может означать также ее покрытие, скоростной режим и назначение (track, motorway), или может обозначать всякие объекты на дороге: crossing, traffic_signals, или вообще то, что почему-то не попало в amenity/shop: services, rest_area, phone. И уходит
Вы так говорите про Народные Карты, будто там — порядок с этим вопросом.
Да, там есть фиксированный набор типов, но этот набор навечно заморожен, а потому люди, у которых зуд, отмечают все, что только взбредет в голову, подписывая это словами. Ну и некорректно сравнивать международный проект, данные из которого доступны всем и каждому (даже с учетом всех его несовершенств), с проприетарной кормушкой для фанатов Яндекса.
Все, как всегда, зависит от людей. Пока те, кто не видят в этом проблемы, потому что либо не обладают системным мышлением, либо никогда не пытались использовать данные OSM самостоятельно, находятся в некотором подавляющем большинстве, такое безобразие и будет твориться. Теоретически, можно предположить, что какая-нибудь компания, использующая данные OSM, где мучаются с их конвертированием, может предложить какие-то схемы обозначений, разработанные более профессионально. Таких прецедентов пока нет. Есть отдаленно похожие — например, сотрудники картографического подразделения «Спутника» часто тормошат людей на форуме на тему того, какие обозначения поддерживать для каких-то чисто российских объектов. Например, недавно таким образом дошли руки до молочных кухонь. На счастье, получилось выработать расширение схемы
Да, там есть фиксированный набор типов, но этот набор навечно заморожен, а потому люди, у которых зуд, отмечают все, что только взбредет в голову, подписывая это словами. Ну и некорректно сравнивать международный проект, данные из которого доступны всем и каждому (даже с учетом всех его несовершенств), с проприетарной кормушкой для фанатов Яндекса.
Все, как всегда, зависит от людей. Пока те, кто не видят в этом проблемы, потому что либо не обладают системным мышлением, либо никогда не пытались использовать данные OSM самостоятельно, находятся в некотором подавляющем большинстве, такое безобразие и будет твориться. Теоретически, можно предположить, что какая-нибудь компания, использующая данные OSM, где мучаются с их конвертированием, может предложить какие-то схемы обозначений, разработанные более профессионально. Таких прецедентов пока нет. Есть отдаленно похожие — например, сотрудники картографического подразделения «Спутника» часто тормошат людей на форуме на тему того, какие обозначения поддерживать для каких-то чисто российских объектов. Например, недавно таким образом дошли руки до молочных кухонь. На счастье, получилось выработать расширение схемы
social_facility=*, вместо того, чтобы бездумно добавить еще один тип в amenity=*. Может так дойдет и до чего-то другого, постепенно. Но совсем исключать возможность изменений, а потому вообще не пытаться ничего сделать — неправильно.про уход в народные карты я упомянул скорее как про крайнюю форму отчаяния, а не как что-то приемлемое в плане категоризации, по тому, что я видел, там все очень скудно: с ОСМ даже сравнивать не стоит.
и да, я не говорю, что не стоит ничего делать, делать надо, просто будет очень сложно
и да, я не говорю, что не стоит ничего делать, делать надо, просто будет очень сложно
Почему «будет»? Оно есть сложно. Но оно делается, понемногу.
Хотелось бы большего понимания проблемы со стороны пользователей (хотя по поводу большинства я иллюзий не имею). Для чего, в том числе, эта статья.
Хотелось бы большего понимания проблемы со стороны пользователей (хотя по поводу большинства я иллюзий не имею). Для чего, в том числе, эта статья.
«Но оно делается, понемногу» — похоже на оправдание. Процесс ради процесса. Большие профи в области онтологий вроде Левенчука свидетельствуют, что дела в этой сфере плохи. Сама по себе идея их формирования не «выстреливает». Так зачем биться в стену?
По мне так лучше бы в ОSM за основу взяли какую-нибудь графовую СУБД («использовать атомарные теги») и посмотрели как это отобразится на результате.
Впрочем, сама по себе статья очень интересна и даже изумительна по доходчивости. Браво!
По мне так лучше бы в ОSM за основу взяли какую-нибудь графовую СУБД («использовать атомарные теги») и посмотрели как это отобразится на результате.
Впрочем, сама по себе статья очень интересна и даже изумительна по доходчивости. Браво!
Редактирование OSM во многом, действительно, «процесс ради процесса» вообще. Хотя бы по той причине, что множество тегов нигде не только не отображаются, но и не поддерживаются. Так что это некий «дзен».
Поскольку проект, в то же время, крайне анархический, то есть даже OSMF не имеет сколько-нибудь заметной власти над происходящим, идеи вроде «лучше взять графовую СУБД» утопичны чисто технически. Я понимаю, что вы этого не предлагаете, но, тем не менее, проекту так или иначе приходится обходиться тем, что есть. Иллюзий у меня нет и оправдывать я никого не собираюсь, тем более, что некоторые участники проекта, что в России, что в других странах — сторонники полного анархизма, которым прикрывают решение своих частных задач и удовлетворение собственных амбиций (рисование под рендер, расширительная трактовка значений тегов вместо внедрения новых и так далее). Но в то же время, OSM — проект, в котором иногда отдельные участники могут изменить многое почти что одним движением. Свежие примеры — это leaf_type и leaf_cycle, а также ситуация со стандартным стилем (см. недавнее изменение способов отображения дорог). Так что да, все довольно запущено, дураков среди участников достаточно, но это пока не переросло в необратимо негативную ситуацию.
За оценку статьи — спасибо.
Поскольку проект, в то же время, крайне анархический, то есть даже OSMF не имеет сколько-нибудь заметной власти над происходящим, идеи вроде «лучше взять графовую СУБД» утопичны чисто технически. Я понимаю, что вы этого не предлагаете, но, тем не менее, проекту так или иначе приходится обходиться тем, что есть. Иллюзий у меня нет и оправдывать я никого не собираюсь, тем более, что некоторые участники проекта, что в России, что в других странах — сторонники полного анархизма, которым прикрывают решение своих частных задач и удовлетворение собственных амбиций (рисование под рендер, расширительная трактовка значений тегов вместо внедрения новых и так далее). Но в то же время, OSM — проект, в котором иногда отдельные участники могут изменить многое почти что одним движением. Свежие примеры — это leaf_type и leaf_cycle, а также ситуация со стандартным стилем (см. недавнее изменение способов отображения дорог). Так что да, все довольно запущено, дураков среди участников достаточно, но это пока не переросло в необратимо негативную ситуацию.
За оценку статьи — спасибо.
Ну если «переход на графовые базы данных» — утопия, то наверное ситуация у вас в ОSM может сильно улучшиться с приходом нейронных сеток. Когда за семантический слой будут отвечать не белковые/ленивые анархисты, а кремниевые трудяги. Сейчас там бурный подъем. Натаскиваешь такую сеточку на правильное тегирование медицинских объектов по Healthcare и далее она пускается в свободный мониторинг реальности: видит, допустим, в гугл-стрит новую больницу и сама все супер-верно все размечает в ОSM, попутно еще выспрашивая у кого надо подробности.
По поводу статьи мне есть с чем сравнивать: в более близкой для меня теме semantic-web собственно такие же корневые проблемы с заразительной активностью апологетов, но слабой методологической базой всего проекта. И там вот не дай бог сказать — «топчитесь». А при этом уровень популяризаторских статей средненький.
По поводу статьи мне есть с чем сравнивать: в более близкой для меня теме semantic-web собственно такие же корневые проблемы с заразительной активностью апологетов, но слабой методологической базой всего проекта. И там вот не дай бог сказать — «топчитесь». А при этом уровень популяризаторских статей средненький.
На самом деле, даже более приличные пресеты для редакторов OSM могут дать заметное улучшение, потому что множество сущностей действительно весьма однотипны и предложив людям готовый шаблон, можно уменьшить число ошибок. В том же iD (который веб-редактор, встроенный в osm.org) русскоязычные метки часто просто ужасны и вводят в заблуждение. А в JOSM они не входят в комплект по умолчанию (или входят, но не те, что надо).
barrier=bollardХе-хе, хотел бы я посмотреть на «барьер, убираемый, бетонный, высотой 70 см» :)
bollard=removable
material=concrete
height=0.7
highway=alleyНаверное, highway=service + service=alley?
Вики-страница этого тега
Конечно про неё, просто автор сократил, я по памяти тоже помню именно как highway=alley.
Ну и если width=0.01, то не вижу проблем.
Ну и если width=0.01, то не вижу проблем.
barrier=bollardТут кстати тоже разброд и шатание, ибо в других тегах уточнение задавалось бы в духе barrier:type или barrier_type или даже bollard:type/bollard_type, что опять же не снижает порог вхождения. Плохо что в редакторах кишки наружу торчат, если бы сделали это более юзерфрендли, то может и пошёл бы продукт в массы.
bollard=removable
Тут кстати тоже разброд и шатание, ибо в других тегах уточнение задавалось бы в духе barrier:type или barrier_typeСчитаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.
Плохо что в редакторах кишки наружу торчатНе знаю, в JOSM все ":type", "_type" и прочие выдумки мапперов спрятаны за чекбоксами и выдающими меню, в которых стоят понятные слова на человеческом языке.
Это сложно для программистов, которые используют данные OSM и вынуждены проверять, где используется ":type", где — "_type", а где — ещё что-то.
если бы сделали это более юзерфрендли, то может и пошёл бы продукт в массы.А сейчас OpenStreetMap не «в массах»? :)
Сейчас не в массах. На регион приходится с десяток более-менее постоянных мапперов. Иногда можно увидеть «смотри какая клёвая карта», а чаще сам показываю. На фразу «её и редактировать можно» можно услышать от «ммм» до «нахернужно».
JOSM сам по себе неинтуитивен для новичка. Пресеты не на всё есть, и не всё в них есть, так что периодически приходится лезть в вики и смотреть как же всё-таки правильно. Понятные слова, к примеру, в biycle_parking (building или shed, ну может где-то в Японии с ихними автоматическими парковками работает и это), мало чем помогают.
JOSM сам по себе неинтуитивен для новичка. Пресеты не на всё есть, и не всё в них есть, так что периодически приходится лезть в вики и смотреть как же всё-таки правильно. Понятные слова, к примеру, в biycle_parking (building или shed, ну может где-то в Японии с ихними автоматическими парковками работает и это), мало чем помогают.
Считаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.На форуме в теме «одно или двухвейная улица» периодически заикаются про маршрутизацию для спецтранспорта, которому двухвейность не должна быть препятствием для манёвров через двойную сплошную, так же и некоторые типы barrier. То же самое можно сказать про велосипедистов.
Извините, это здесь при чём?Считаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.На форуме в теме «одно или двухвейная улица» периодически заикаются про маршрутизацию для спецтранспорта, которому двухвейность не должна быть препятствием для манёвров через двойную сплошную, так же и некоторые типы barrier. То же самое можно сказать про велосипедистов.
Я имел в виду, что между ключами что-то:type=*, что-то_type=* и что-то=* нет никакой разницы, поэтому лучше использовать ключ что-то=*.
Я не говорил, что уточняющие теги не несут смысла.
Я говорил только о том, какую «форму», какой «шаблон» правильнее использовать для уточняющих тегов.
Исходное
ключ=значениеДля этого в данный момент для разных ключей применяются различные схемы уточняющих тегов:
значение:type=*Что оставляем? Если вы за
значение_type=*
значение=*
ключ_type=*
ключ:type=*
значение=* (ну и любой другой использующий значение в качестве ключа), то, на мой взгляд, это очень плохая схема, т.к. изначально не известно каким будет уточняющий тег.Да, использовать значение=* в качестве ключа уточняющего тега можно только тогда, когда данное свойство относится только к данному объекту, а не ко всей категории. Например, мы можем использовать residential=urban/rural, потому что residential=* относится только к landuse=residential, а не ко всем landuse=*.
Если же свойство относится ко всей категории (например, building:levels=* относится ко всем building=*), то в ключе уточняющего тега должен стоять ключ основного тега, а не какое-нибудь его значение. И тут не обойтись без *:type=*, да.
Когда писал, что *:type=* не имеет смысла, рассматривал только первый вариант. Почему-то не упомянул это, извините.
Если же свойство относится ко всей категории (например, building:levels=* относится ко всем building=*), то в ключе уточняющего тега должен стоять ключ основного тега, а не какое-нибудь его значение. И тут не обойтись без *:type=*, да.
Когда писал, что *:type=* не имеет смысла, рассматривал только первый вариант. Почему-то не упомянул это, извините.
residential=* уже однозначно говорит нам о том, что перед нами landuse=residential. Так зачем повторяться?
Что именно повторять?
landuse=residential residential=urban/ruralПервая строчка явно не несёт никакой дополнительной информации, ибо вторая недвусмысленно намекает на её наличие. Вполне можно б и в пресетах фильтровать уточняющие теги в зависимости от основного тега. А вообще я за многоуровневые ветвистые теги, там таких проблем не будет.
Sign up to leave a comment.
Понятия естественного языка против формальных классификаций в OpenStreetMap