По моей первой ссылке как раз подобное сооружение связи и видно. Я его тоже как мачту замапил…
При чем здесь суда? Речь о строительной инженерии, предметом которой является то, что обозначается в OSM.
Термины “мачта” и “башня” в России определены СНиП I-2 “Строительная терминология”. В иностранной литературе я это тоже находил, но сейчас не могу сходу вспомнить, где точно.
Области инженерии, которые занимаются эксплуатацией (а не непосредственно проектированием) самих башенных и мачтовых опор, а также оборудования, на них установленного, уже достаточно вольно распоряжаются этими терминами. Например, светотехники называют все мачтами или опорами (последнее - более общий термин).
В контексте этой темы, то есть моделирования объектов, нужно понимать, что “ИМХО, не тянет” и “чё-то он дофига большой” - это не критерии.
Критерий модели - это верифицируемый параметр.
С точки зрения вопроса моделирования все эти “башни”, “мачты” и “столбы” вообще лишены смысла, потому что должен быть набор тегов, описывающих конструкцию, а не называющих ее. Например, такая схема:
“вертикальная поддерживающая конструкция”
“с оттяжками или без”
“материал”
“высота”
“назначения”
“диаметр”.
Это однозначные верифицируемые свойства. А “мачта” и “башня” всегда будут вызывать у кого-нибудь сомнение (из-за привычки, которая не имеет никакого отношения к формальному моделированию), даже если придерживаться строгого инженерного критерия. Что, как показывает практика, никому в голову за все существование OSM пока не приходило, потому что я был первым, кто внес инженерное определение (как рекомендацию) в Wiki.
Дискуссия выше (о том, что же это, башня или мачта по ссылкам) прекрасно демонстрирует, что вы, коллеги, все еще не хотите или не можете мыслить в терминах модели, а пытаетесь всего лишь чуть-чуть (на основе субъективных собственных ощущений) формализовать термины естественного языка. И это никакого порядка не добавляет, потому что Вася считает, что башней конструкция становится, когда она “охеренно большая”, а Петя - когда “несколько больше того, что Коле кажется мачтой”.
Что и требовалось доказать.
Только не пишите, пожалуйста, в очередной раз ерунды по поводу того, что обозначить конструкцию, как “опора” и добавить ей пару-тройку однозначных признаков (оттяжки, материал, применения) - это сложнее, чем сломать голову о неразрешимый вопрос, мачта это, или башня.
Особенно, когда это опора ЛЭП, на которой размещены сотовые антенны и к ней прикручен фонарь освещения.
Вот только я так и не увидел от тебя предложений, как тегировать конструкции по ссылкам: https://www.google.ru/maps/@55.8267228,37.4962063,3a,75y,358.61h,102.83t/data=!3m6!1e1!3m4!1sNZyNBb6PFQB9WWruZ7aXEw!2e0!7i13312!8i6656!6m1!1e1 и http://www.setuntrans.ru/page5.html - как man_made=tower? Вместо этого в который раз - завуалированные упреки и личные оценки коллег по проекту.
хотелось бы, конечно, поискать нормальное определение слова mast в инженерном значении на английском языке. Как-то не очень авторитетен для меня СНИП (напомню, документ узкоспециализированный, предназначенный для проектировщиков и строителей), разработанный в СССР в 1980 году (35 лет назад), при вопросе определения термина в международном проекте.
сделать-то схему можно
проблема будет с её внедрением:
во-первых, надо будет пересмотреть и переработать все уже существующие объекты
во-вторых, перенастроить весь софт, используемый потребителями данных
Не надо принимать то, что я сказал, как упрек, тем более - завуалированный. Я что, когда-то стеснялся назвать кого-то идиотом, если у меня было основание и желание это сделать? Так что не сомневайтесь, хотел бы - назвал, без всякой “завуалированности”. Так что вам тут дофига чего кажется в том, что я написал. Задача была в том, чтобы продемонстрировать, что за частностями люди (включая вас, да) плохо видят или не видят, или не хотят видеть общности.
Я всего лишь хочу разговаривать с людьми на одном языке и будучи уверенным, что они понимают суть того, о чем идет речь.
Речь в этой конкретной теме идет о принципах обозначения, а не о конкретных обозначениях. И пока тема сваливается на конкретные обозначения, я не вижу понимания со стороны коллег.
Не договорившись о том, чего же мы хотим в смысле этих самых обозначений, принципиально улучшить ничего не удастся. Именно потому я не хочу поддерживать частный вопрос об обозначении двух конкретных опор, на которые вы упорно даете ссылки. Тем более, что в настоящий момент, даже если я вам что-то скажу на основании какой-то книги, которую вы сочтете “достаточно весомой”, это не будет значить ровно ничего: в базе уже есть два десятка тысяч обозначенных мачт и пара сотен тысяч башен, которые обозначены непонятно по каким критериям (у каждого-свои).
Я (в контексте этой темы) от вас хочу услышать, наконец, согласны ли вы, что имеющиеся обозначения вроде этих mast и tower - это невнятная неверифицируемая ерунда, или нет?
Калиточка «всплыла».)
Только при чём тут моделирование — мне не понятно. Есть ограничители передвижения на местности, барьеры. Их набор достаточно ограничен, чтобы обойтись простыми языковыми терминами, понятными абсолютному большинству и обозначающими объекты со специфическими особенностями (почему это не могут быть размеры, в том числе?). При этом нет необходимости бегать с лазерным дальномером, уровнем, лидаром, рулеткой, масс-спектрометром, геодезическими приборами и т. д., чтобы отметить конкретное препятствие. Это называется «условное, схематичное обозначение объекта в базе данных (сиречь карте)». Это как значок на бумажной схеме: вот здесь находится то-то. И мы понимаем, что это за препятствие (в его предельно общем виде, что является минимально достаточным условием, чтобы обозначение «состоялось» и обладало полезной нагрузкой).
Габариты, материалы, цвет, температура, фазовое состояние и прочие тонкости реального мира — на усмотрение и в возможностях человека, вносящего данные.
Конечно, всплыла, потому что это еще один случай той же самой ситуации.
Если вы согласны, что критерием различия “калитки” и “ворот” может являться размер, почему вы, тем не менее, категорически против того, чтобы этот размер и указать?
Это всего-навсего два тега (конструктив ворот и их ширина) вместо одного.
Зато информативность повышается: можно выяснить, что реально пройдет через эти ворота, а не гадать.
BushmanK, из чего следует, что я против? Тот случай, когда не «вместо», а «вместе».
Если два разных объекта, обладающих схожими функциями и даже близких конструктивно, обозначить одной и той же абстрактной единицей (тегом), а различия оставить на откуп сугубо физическим параметрам, то автоматически все недетализированные (доп. тегами) объекты (в БД) будут отражать 50/50 нечто неопределённое. И таких будет, естественно, большинство. Верификация тех же габаритов — дело благородное и технически возможное, но кто этим заниматься станет и зачем? Нереализуемо на практике (в прикладном плане).
Разделяя абстракции через использование понятий языка (терминологии из соответствующих областей знания), мы избегаем указанной двойственности, даже с учётом отсутствия детальных характеристик.
Атомарные свойства хороши, но не всегда. И уж, тем более, они не самодостаточны. Таких примеров много: дороги, водные потоки, торговые, учебные заведения, медицинские и др.
Всё, в конечном итоге, зависит от нашего восприятия и поставленных целей.
P. S. Насчёт «указать размер»: его просто никто не знает (даже хозяин, скорее всего) без процедуры измерения.
P. P. S. Surly развёрнуто дополнил наглядно-примерными выкладками 
Если заменять общие категорийные понятия (ясные на интуитивном уровне) на детальные описания, есть риск, что до внесения этих данных дело уже не дойдёт.
На примере ворот и калитки:
-
(с точки зрения мапера) Я издали вижу дверь, навскидку вижу, что человек пройдет, а машина нет, отмечаю вход как калитку.
Теперь же предлагается вместо этого идти к двери рулеткой, измерять ширину и вносить её в данные. Не всегда есть такая возможность и желание. В итоге объект остается незамапленным. -
(с точки зрения юзера) Я на карте вижу нечто, обозначенное калиткой. Я понимаю, что в неё не въедет среднестатистическая машина (а значит, с вероятностью близкой к 100%, не въедет и моя), но войдёт среднестатистический человек (а значит, с вероятностью близкой к 100%, смогу войти и я).
Теперь же предлагается посмотреть на тэг ширина, прикинуть в уме, пройдет ли там машина или тело, и из этого принять решение. Это очень весело, если “численный глазомер” не очень, раскладывать рулетку, чтобы наглядно почувствовать ширину входа. Совсем весело, если значения близки к границе “уже больше чем типичная калитка, но не настолько, чтоб выглядеть типичными воротами”.
“mast” или “tower” = “вертикальная поддерживающая конструкция”
если надо поставить на карте значок, то вполне сойдёт, а большего, часто, и не требуется
за спором с “калитками” не следил
но мне кажется, что критерий “проедет ли машина” достаточно хорош
записать его в вики да и всё
то есть, создавать непротиворечивую схему вполне можно
только надо задумываться над вопросом “зачем”:
для потребителя: какая ему будет польза от новой структуры данных?
для редактора: насколько усложнится внесение данных по новой схеме?
Этого легко избежать нормальными моделями:
barrier=gate - что-то калиточное, для быстро замапил и пошёл
barrier:width=wicket - “калитка”
barrier:width=gate - “ворота”
Приближённых и с потолочных значений в width=* вообще нет. Рулетка осталась дома.
Пример в английском:
https://en.wikipedia.org/wiki/Wicket_gate#/media/File:Burg_Friedestrom_Suedtor_02.jpg
либо
entrance=yes
entrance:width=wicket
entrance:width=gate
Ну, если мы допустим наряду с числовыми значениями еще и категорийные (как сейчас для voltage), то проблема нечётких данных снимется. Вопрос в том, не превратится ли это в ад для парсера.
вообще-то говоря, когда мы говорим об измерении значения физической величины, например ширины калитки, надо всегда иметь ввиду не обно, а два числа.
Ведь точность измерения еще никто не отменял. Какая-то она всегда есть.
В ОСМ принято вносить только одно число, отсюда некоторые сложности.
Если рулетка дома, то возможность измерения этим не отменяется, надо лишь понимать, что точность будет хуже. Осталось лишь ее правильно внести в данные.
Например можно предложить что-то
width=1.2-1.7m
width=1.5m (25%)
и т.п.
Для рисования такой точности хватит, для построения через калитку маршрута на мотоцикле без коляски тоже, а с коляской - нет (вдруг не пролезет)
Хыхы, я злорадно ждал идеи про “пройдет автомобиль”.
Мультик про измерение удава в попугаях помните?
Вот этот автомобиль шириной 1510мм
или вот этот автомобиль шириной 2438мм
(оба - легковые, между прочим)?
Коллеги, вы меня реально пугаете, раз вот такие простые вещи на шаг вперед вам в голову не приходят.
wowik - пока единственный, кто продемонстрировал мышление в верном направлении.
Боюсь, до появления API 0.7 (а скорее даже API 0.8) нам эта прелесть не светит.
А я не зря в своем ответе везде упомянул слово “среднестатистический” (видимо, зря тогда не выделил жирным курсивом), так что лично я твои претензии про крайние случаи принимать отказываюсь.
Я знаю без рулетки что в деревне все калитки уже 1000 мм. Отметить их тегом-категорией “войдёт только человек” проще и быстрее чем носится с рулеткой.
Никто не будет пробовать заехать в них на Smart Fortwo.
Тот кто хочет width=* указывать - пусть его и указывает. Текущий width и est_width=* не решает проблему доверительного интервала.
По-моему калитка/ворота, стоящие сами по себе - явление довольно редкое. В нормальной ситуации - это точка пересечения highway и barrier. Соответственно, машина, которая пролезет (или не пролезет) в калитку, должна сначала по этому highway подъехать. И то, будет это footway/path или sevice, определяет характер ворот/калитки заметно лучше. Безусловно, никто не запрещает проставить и ширину, как дороги, так и ворот, но это скорее уточнение. Никто же, например, не предагает для мостиков из нескольких досок вводить какой-то особый тег.
Что-то я наблюдаю тут какие-то странные размахивания шашкой (с наклеиванием ярлыков на всех окружающих, конечно же).
У тех же ворот помимо ширины есть масса параметров. Например, высота (вот не факт, что тот же додж пролезет под шлагбаумом, которые дачники вешают от нашествия грузовиков), или наличие рядом будки с дедом-охранником. Ещё можно отмечать конструкцию (ещё 100500 разных тэгов), цвет, материал…
А если рассмотреть вопрос “можно ли проехать на мотоцикле”, параметр “ширина” становится и вовсе бессмысленным.
Для карты, на мой взгляд, вполне достаточно параметров “тут калитка/ворота, всем можно ходить пешком, свои (у кого есть ключи) могут ездить на машине”.
При желании отмечать ширину - да ради бога. Any tags you like. Только бывают, например, ворота (закрытые), в середину которых врезана калитка (открытая). Или калитка эта рядом расположена.
Или регулярно встречаются шлагбаумы, которые формально напрочь закрыты, но в обход (прямо в полуметре) натоптаны отличные тропы. Как это сделать, не сломав совместимость с имеющимися рендерами-конвертерами?
Давайте определимся, что же мы рисуем? Карту? Или проектную документацию на калитки и лавочки?