сделать-то схему можно
проблема будет с её внедрением:
во-первых, надо будет пересмотреть и переработать все уже существующие объекты
во-вторых, перенастроить весь софт, используемый потребителями данных
Не надо принимать то, что я сказал, как упрек, тем более - завуалированный. Я что, когда-то стеснялся назвать кого-то идиотом, если у меня было основание и желание это сделать? Так что не сомневайтесь, хотел бы - назвал, без всякой “завуалированности”. Так что вам тут дофига чего кажется в том, что я написал. Задача была в том, чтобы продемонстрировать, что за частностями люди (включая вас, да) плохо видят или не видят, или не хотят видеть общности.
Я всего лишь хочу разговаривать с людьми на одном языке и будучи уверенным, что они понимают суть того, о чем идет речь.
Речь в этой конкретной теме идет о принципах обозначения, а не о конкретных обозначениях. И пока тема сваливается на конкретные обозначения, я не вижу понимания со стороны коллег.
Не договорившись о том, чего же мы хотим в смысле этих самых обозначений, принципиально улучшить ничего не удастся. Именно потому я не хочу поддерживать частный вопрос об обозначении двух конкретных опор, на которые вы упорно даете ссылки. Тем более, что в настоящий момент, даже если я вам что-то скажу на основании какой-то книги, которую вы сочтете “достаточно весомой”, это не будет значить ровно ничего: в базе уже есть два десятка тысяч обозначенных мачт и пара сотен тысяч башен, которые обозначены непонятно по каким критериям (у каждого-свои).
Я (в контексте этой темы) от вас хочу услышать, наконец, согласны ли вы, что имеющиеся обозначения вроде этих mast и tower - это невнятная неверифицируемая ерунда, или нет?
Калиточка «всплыла».)
Только при чём тут моделирование — мне не понятно. Есть ограничители передвижения на местности, барьеры. Их набор достаточно ограничен, чтобы обойтись простыми языковыми терминами, понятными абсолютному большинству и обозначающими объекты со специфическими особенностями (почему это не могут быть размеры, в том числе?). При этом нет необходимости бегать с лазерным дальномером, уровнем, лидаром, рулеткой, масс-спектрометром, геодезическими приборами и т. д., чтобы отметить конкретное препятствие. Это называется «условное, схематичное обозначение объекта в базе данных (сиречь карте)». Это как значок на бумажной схеме: вот здесь находится то-то. И мы понимаем, что это за препятствие (в его предельно общем виде, что является минимально достаточным условием, чтобы обозначение «состоялось» и обладало полезной нагрузкой).
Габариты, материалы, цвет, температура, фазовое состояние и прочие тонкости реального мира — на усмотрение и в возможностях человека, вносящего данные.
Конечно, всплыла, потому что это еще один случай той же самой ситуации.
Если вы согласны, что критерием различия “калитки” и “ворот” может являться размер, почему вы, тем не менее, категорически против того, чтобы этот размер и указать?
Это всего-навсего два тега (конструктив ворот и их ширина) вместо одного.
Зато информативность повышается: можно выяснить, что реально пройдет через эти ворота, а не гадать.
BushmanK, из чего следует, что я против? Тот случай, когда не «вместо», а «вместе».
Если два разных объекта, обладающих схожими функциями и даже близких конструктивно, обозначить одной и той же абстрактной единицей (тегом), а различия оставить на откуп сугубо физическим параметрам, то автоматически все недетализированные (доп. тегами) объекты (в БД) будут отражать 50/50 нечто неопределённое. И таких будет, естественно, большинство. Верификация тех же габаритов — дело благородное и технически возможное, но кто этим заниматься станет и зачем? Нереализуемо на практике (в прикладном плане).
Разделяя абстракции через использование понятий языка (терминологии из соответствующих областей знания), мы избегаем указанной двойственности, даже с учётом отсутствия детальных характеристик.
Атомарные свойства хороши, но не всегда. И уж, тем более, они не самодостаточны. Таких примеров много: дороги, водные потоки, торговые, учебные заведения, медицинские и др.
Всё, в конечном итоге, зависит от нашего восприятия и поставленных целей.
P. S. Насчёт «указать размер»: его просто никто не знает (даже хозяин, скорее всего) без процедуры измерения.
P. P. S. Surly развёрнуто дополнил наглядно-примерными выкладками
Если заменять общие категорийные понятия (ясные на интуитивном уровне) на детальные описания, есть риск, что до внесения этих данных дело уже не дойдёт.
На примере ворот и калитки:
(с точки зрения мапера) Я издали вижу дверь, навскидку вижу, что человек пройдет, а машина нет, отмечаю вход как калитку.
Теперь же предлагается вместо этого идти к двери рулеткой, измерять ширину и вносить её в данные. Не всегда есть такая возможность и желание. В итоге объект остается незамапленным.
(с точки зрения юзера) Я на карте вижу нечто, обозначенное калиткой. Я понимаю, что в неё не въедет среднестатистическая машина (а значит, с вероятностью близкой к 100%, не въедет и моя), но войдёт среднестатистический человек (а значит, с вероятностью близкой к 100%, смогу войти и я).
Теперь же предлагается посмотреть на тэг ширина, прикинуть в уме, пройдет ли там машина или тело, и из этого принять решение. Это очень весело, если “численный глазомер” не очень, раскладывать рулетку, чтобы наглядно почувствовать ширину входа. Совсем весело, если значения близки к границе “уже больше чем типичная калитка, но не настолько, чтоб выглядеть типичными воротами”.
“mast” или “tower” = “вертикальная поддерживающая конструкция”
если надо поставить на карте значок, то вполне сойдёт, а большего, часто, и не требуется
за спором с “калитками” не следил
но мне кажется, что критерий “проедет ли машина” достаточно хорош
записать его в вики да и всё
то есть, создавать непротиворечивую схему вполне можно
только надо задумываться над вопросом “зачем”:
для потребителя: какая ему будет польза от новой структуры данных?
для редактора: насколько усложнится внесение данных по новой схеме?
Ну, если мы допустим наряду с числовыми значениями еще и категорийные (как сейчас для voltage), то проблема нечётких данных снимется. Вопрос в том, не превратится ли это в ад для парсера.
вообще-то говоря, когда мы говорим об измерении значения физической величины, например ширины калитки, надо всегда иметь ввиду не обно, а два числа.
Ведь точность измерения еще никто не отменял. Какая-то она всегда есть.
В ОСМ принято вносить только одно число, отсюда некоторые сложности.
Если рулетка дома, то возможность измерения этим не отменяется, надо лишь понимать, что точность будет хуже. Осталось лишь ее правильно внести в данные.
Например можно предложить что-то
width=1.2-1.7m
width=1.5m (25%)
и т.п.
Для рисования такой точности хватит, для построения через калитку маршрута на мотоцикле без коляски тоже, а с коляской - нет (вдруг не пролезет)
Боюсь, до появления API 0.7 (а скорее даже API 0.8) нам эта прелесть не светит.
А я не зря в своем ответе везде упомянул слово “среднестатистический” (видимо, зря тогда не выделил жирным курсивом), так что лично я твои претензии про крайние случаи принимать отказываюсь.
По-моему калитка/ворота, стоящие сами по себе - явление довольно редкое. В нормальной ситуации - это точка пересечения highway и barrier. Соответственно, машина, которая пролезет (или не пролезет) в калитку, должна сначала по этому highway подъехать. И то, будет это footway/path или sevice, определяет характер ворот/калитки заметно лучше. Безусловно, никто не запрещает проставить и ширину, как дороги, так и ворот, но это скорее уточнение. Никто же, например, не предагает для мостиков из нескольких досок вводить какой-то особый тег.
Что-то я наблюдаю тут какие-то странные размахивания шашкой (с наклеиванием ярлыков на всех окружающих, конечно же).
У тех же ворот помимо ширины есть масса параметров. Например, высота (вот не факт, что тот же додж пролезет под шлагбаумом, которые дачники вешают от нашествия грузовиков), или наличие рядом будки с дедом-охранником. Ещё можно отмечать конструкцию (ещё 100500 разных тэгов), цвет, материал…
А если рассмотреть вопрос “можно ли проехать на мотоцикле”, параметр “ширина” становится и вовсе бессмысленным.
Для карты, на мой взгляд, вполне достаточно параметров “тут калитка/ворота, всем можно ходить пешком, свои (у кого есть ключи) могут ездить на машине”.
При желании отмечать ширину - да ради бога. Any tags you like. Только бывают, например, ворота (закрытые), в середину которых врезана калитка (открытая). Или калитка эта рядом расположена.
Или регулярно встречаются шлагбаумы, которые формально напрочь закрыты, но в обход (прямо в полуметре) натоптаны отличные тропы. Как это сделать, не сломав совместимость с имеющимися рендерами-конвертерами?
Давайте определимся, что же мы рисуем? Карту? Или проектную документацию на калитки и лавочки?
Могу похвастаться 5-ти метровыми path в лесу, есть поляны по десаткам метров. Все “path” на них обозначаются наиусловнейше.
Ворота точкой проще отметить чем “дороги” вокруг этих ворот.
Ширина дороги это не уточнение свойств у калиток и ворот. Ширина калиток указывается вообще независимо от дорог. Тем более когда речь идёт о дорогах-линиями с нулевой шириной, а не площадных дорогах.
Пример: если местность вдруг затопит, то дороги исчезнут почему-то. Но калитки шириной с человека останутся. Большинство лодок туда не пройдёт.
Не понял, там пятиметровая калитка шириной во всю поляну, или причем тут это?
Проще, только ворота без подъезда/подхода к ним не особо полезны, тем более для автоматического рутинга.
А никто и не утверждал обратного. Как справедливо замечено, помимо ширины и ворот еще часто есть высота, ограниченная перекладиной вверху, и другие характеристики. И все эти характеристики указывать никто не запрещает. Речь только о том, что “калитка” - это ворота, расположенные на footway/path, а не какая-то особенная сущность.
Ну уже тут важнее высота ограждения, вместе со всеми его воротами и калитками.
Всё к тому что очень условные модели “дорог” не определяют свойства других объектов. В том числе ворот и калиток. “И то, будет это footway/path или sevice, определяет характер ворот/калитки заметно лучше.”
Нет, не заметно лучше. Дороги всё только усложняют.
Есть большое количество ничего не решающих шлагбаумов и ворот. Безусловными барьерами их считают уже когда забывают о опущении абстракций в модели.
Об этом уже говорилось здесь (мною). Но не всегда есть эти пересечения (из-за отсутствия обозначенных дорог). Обычно точечные барьеры пересекаются с линейными.
По поводу «злорадства»: можно было бы добавить картинки анорексичного организма рядом с крайне ожиревшим. Только это передёргивание и утрирование, а не «на шаг вперёд».