Причем от разной вложенности друг-в-друга можно менять смысл их обработки.
Код-обработчик и запрос-выборка усложнится (в иерархичном варианте), но от этого никуда не деться. Если кто-то очень хочет или не любит теги motorcycles=yes, atv=yes, то это можно определить на вики у основного ключа группы или если очень хочется то и у каждого тега-значения.
И поэтому мы должны мешать эти два подхода прямо сейчас в рамках API 0.6
Мы же такие адекватные,
Мы же используем XML для ответов,
Мы же еще к тому же кодируем значения через ;
Что? Серьезно, тебя это никогда не смущало?
Кроме того, мы так любим потребителей данных что не скажем какие именно ключи у нас многозначные, им придётся абсолютно всю БД парсить. Потому что ; можно поставить везде - легко же.
romul_zurov оговорюсь, что посмотрел очень бегло, но допустим что эта схема лучше. Проблема в том что в осм исправление старой схемы не исправляет ситацию, а порождает использование двух схем параллельно, старой и новой. Поэтому, что сложилось, то, увы, сложилось. Мы не организация и не можем решить подобные проблемы административными методами.
схема была придумана на ходу, возможно, что неудачная.
(терпеливо)
повторяю основную мысль: иерархическая схема с “одним главным тэгом” не всегда удобна.
пункт тех. осмотра мотоциклов - это типа подвид тэга shop=motorcycles
пункт зимнего хранения мото - это неопределённый подвид под-тэга services тэга shop=motorcycles
пункт тех. осмотра авто кат. Б - это подвид чего?
пункт тех. осмотра вообще (легковушки, грузовики, может быть мотоциклы) - это как вообще?
салон продажи экипировки (мото, квадро, вело) - equip или motorcycle/atv/bicycle в качестве основного тэга?
схема нескольких основных тэгов была бы явно удобнее.
Не требуются административные методы, нужно API дать функции
В костыльном варианте нужно добавить “пиши любой XML”, “читай любой XML” для каждой геометрии в OSM. Возвращать и теги и параллельно и опционально пользовательский XML. Пересядут все на пользовательский XML - убьём теги строка=строка. Нет - будем две технически разделённые схемы держать.
Да, меня наконец-то осенило как промежуточную схему в OSM не видеть: выдавать пользовательский XML отдельным запросом или отдельно от “тегов”.
Кто адекватные? Объединение из миллиона человек, редактирующих базу данных, могут быть адекватными (кстаити адекватны кому/чему?) весьма и весьма условно.
Тю, точка с запятой, тоже мне повод смущаться. Я вот например совершенно не питаю илюзий, что добавление коллекций в апи решит проблему.
Будем получать списки вида:
route_ref=[“1,2”, “3”, “3,4;5”, “1;5”]
Ты работаешь, с людьми (не ты Никита лично, а абстрактный осмопрограммист), с огромным количеством людей, знания большинства из которых об информатике нулевые которым ты не платишь и требовать от них ничего, по сути, не можешь.
Приходится идти на компромиссы, приходиться догадываться что такое addr:housenumber=2,4,6,8 хотя разделитель у нас ‘;’. Не все что введено в осм можно распарсить, поддержка коллекций на уровне апи, где-то поможет, а где-то, еще и навредит.
Я вот лично и маперов люблю и потребителей данных. И поверь мне (не веришь мне, спроси у NextGis или у авторов конверторов или у Геофабрики), свистопляска с тегами, далеко не самая большая проблема.
Не в ту степь ведёшь. Это можно решить чисто технически и мапперами которые используют валидаторы.
Для “;” точно также напишем валидатор как для “геометрий самопересечения”. Извини меня - первое тебе любая блондинка исправит, без особых знаний информатики, а второе не каждый программист поймёт о чём речь и что использовать-то.
Есть люди которые только геометрию и исправляют. То что ты говоришь ой, у нас тут 1000000 пользователей, кто нагадит в данные. Ну и что? Конкретно с многозначными значениями всё просто: ищешь на популярные разделители:
либо исправляешь потому что ты эту местность знаешь (как и to-fix дороги)
либо пропускаешь, ждешь пока данные кто-то исправит со знаниями
Как ты думаешь, много пользователей **для себя **:
вводят несуществующие дороги
вводят неверную ардесацию
делают ошибки в полях которые они хотят использовать
У тебя просто взгляд на мир с позиции банхаммера и немедленных откатов. Ох кто-то в интернете неправ.
Мультиселект нужно в iD и JOSM добавить (для костыльных методов, а потом, его сделать основным API если пойдёт), ты зачем про строки продолжаешь когда у тебя коллекции будут?..
Неа. Низачто. Они считают что банхаммер и уровни пользователей это решение. Чтобы выгрузку получить там у разработчиков чуть ли братом нужно быть.
Речь о простом тексте идёт только для самых новых пользователей. Те кто хочет метки добавлять - пусть добавляют.
Прямо сейчас твои пользователи немые и их банить нужно. Еще бы
опять полтачер пришёл все геометрии сломал
опять коммит без комментария
Что ему комментировать если его тегами запрещают описывать? 255 символов? X килобайт хватит каждому? Я понимаю что БД не резиновая, но страницы памяти у всего на свете 4КБ +/-.
Больше всех я люблю чистые и не противоречивые данные которые данные которые можно будет преподать в разном виде в том числе тем людям о которых ты говоришь.
Данные можно отдавать алгоритмам. Людьми свет не закончился.
Не хочешь дружить данные с внешними API и подавать их в съедобном для всех алгоритмов виде - никто их есть не будет.
addr:flats=“1-20”
Это только строка. То, что у тебя есть знания чтобы написать для неё парсер ничего не упрощает для потребителей данных.
им всё равно приходится угадывать что это множество, а не одна квартира “1/20”
им всё равно приходится делать это всё для всей базы, а не только там где ; реально есть
Если ты
то зачем эта
когда можно уже допилить API до нормальных таксономий и множеств? (сюрприз! для этого нужно только лишь разрешить пользовательский XML чтение-запись на начальном этапе)
Зачем ты мне тыкаешь в теги викимапии? Они плоские как доска. Они не значат ничего. Там даже на leisure=/shop= теги не выделяют.
То что вы великий практик в программировании мы уже поняли, до сих пор круги в глазах, от сияния чистого разума. Но если вы и с блондинками имели опыт общения на тему валидации геометрии - тогда… просто нет слов.
Тебя что-то кидает из крайности в крайность.
то
key:value=yes
то
key=[a,b,c]
то
json
то
xml
Но ладно, это лирика, кто делать то будет? Ленивое, косное, надменное англокомьюнити?
Нет. Великие, Имперские Программисты на Плечах Которых Держится Целое Отечество.
Дать любому пользователю сохранить и считать любой xml для геометрии из OSM это так сложно. Потребуются несколько съездов EWG и разработка спецификации, тестирование и внедрение.
Но самое страшное! В этот XML кто-то может внести ложь. О ужас!
Конкретна эта тема в которой мы сидим про этот костыль в рамках API 0.6, да. Но теперь я знаю куда его спрятать: в пользовательский XML.
Это форматы ответа API. Ты не знал что overpass умеет выдавать CSV?! Сумасшедшие! В бан их! У нас геопространственная база, а не викимапия какая-нибудь.
Как параллельный API, для тех, кому жмут теги OSM - почему нет?
Как основной API - нужно будет подождать пока поддержка будет у всего, да потребует времени потому что это изменение, а не плохой подход.
d1g
Ну дык начните вы уж наконец с самого простого — написания полноценной спецификации на ваши хотелки. (и нет, форумные посты за спеки не считаются) Можете пока даже не продумывать миграцию с существующих данных, просто опишите своё виденье сферически вакуумной системы, начиная от точек с БД и заканчивая высокоуровневыми API, валидацией и XSD. Но при этом держите в голове не только пользователей данных, программистов и опытных маперов, но и условных домохозяек и блондинок, которые заносят в базу весомую долю данных, ибо для них нужно будет создавать удобные и понятные инструменты. Пока же вы только разводите трёп, в котором полезного содержания кот наплакал.
Никто за вас спецификации писать не будет, РЛ так не бывает, что приходит гений чистого разума, говорит “хочу вот так”, а сообщество в ответ создаёт на блюдечке с голубой каёмочкой и спеки, и код. Даже после написания спек и длительного обсуждения (в т.ч. и с “англоязычными снобами”), вам (да-да, лично вам, а не мифическим “имперским программистам”), скорее-всего придётся написать хотя бы демку proof-of-concept. В общем, doitcracy в чистом виде.
Иначе, вас весьма скоро начнут просто игнорировать, и не говорите потом про костных и несговорчивых руосмеров.
И вот отмечая их мы получаем викимапию в чистом виде! Только сегодня отметил два shop=doityourself которые имеют совершенно разные ассортименты, которые понять можно только прочитав название.