Здесь есть минимум 3 препятствия:
- Интерпретируемый язык.
- Целевой формат (MP) точно так же непригоден для визуализатора, как и OSM. Т.е. снова требуется конвертер.
- Это уже мой личный недостаток - как только начинаю разбираться в каком-либо проекте, обнаруживаю в нем кучу несуразностей, после чего появляется желание переписать все с нуля.
Теги, встречающиеся разово, конечно не надо никак изображать. Нельзя угодить всем. Да и смысла нет. Если ты сделаешь все теги из мап_фичесов, это УЖЕ будет нечто! Вот, покрытием дорог у нас никто не занимается, хотя оно интересно за городом. Хотя бы через доп.свойства посмотреть (прямо на дороге наверно можно и не рисовать).
Минуточку!
Давай четко разделим понятия: “обрабатывать конвертером” и “отображать визуализатором”.
Визуализатор, естественно, никак не может показать то, что пропущено конвертером, а вот конвертер вполне может (и должен!) обрабатывать то, что не будет показывать визуализатор.
Примеры:
- данные по организации движения - используются для прокладки маршрута, но не рисуются на карте,
- иерархическая структура объектов - используется для поиска, но сама структура не рисуется.
И в принципе, мне кажется, к программе, в число функций которой входит построение картоподобного изображения на экране, нельзя относиться как к карте: у нее может быть масса других функций недоступных бумажной карте, как раз тех, ради которых эту программу и стоит писать. И все эти функции, как правило, требуют определенного гобъема данных, которые непосредственно не отображаются на экране.
Но даже без дополнительных функций (типа поиска, маршрутизации и т.п.) у меня сейчас, например, при щелчке мышью по объекту выводится “простыня” с его свойствами. Я думаю, будет не очень здорово выглядеть, если просто вываливать на экран фрагмент XML-кода, соответствующий данному объекту. А это единственное, что можно сделать без его обработки. Зато есть гарантия, что пользователю будет доступно ВСЕ, что есть в OSM.
А чтобы привести выдачу к “человеческому” виду, конвертер должен это все как-то обрабатывать. При этом отчасти обработка может понадобиться именно чтобы не выводить лишнего - мне трудно представить ситуацию, при которой нужно выводить имя объекта на ВСЕХ языках. Значит, эти теги должны ВСЕ обрабатываться, а выводиться только международное название и название, соответствующее установленной на компьютере пользователя локали.
Что же касается покрытия дорог, то почему бы не предусмореть режим отображения (да, в этом случае именно отображения), при котором вместо статуса дороги показывалось качество ее покрытия. На выбор пользователя - либо одно, либо другое.
схема должна быть жёсткой. Другое дело, что пополняемой. Нельзя, уважаемый andriano, объять необъятное! Конвертер должен обрабатывать конечное число тегов, разумное. Не думаю, что мы, даже совместно, придумаем тут нечто новое.
А почему бы и не придумать?
Мне бы, например, показалось ОЧЕНЬ полезным наличие некоторого ПОПОЛНЯЕМОГО источника, который одновременно мог бы использоваться и в качестве справочника для картографа, и в качесте основы для программы -“теговалидатора” и для программы-конвертера. Собственно, размещенный здесь XML - как раз попытка создания первой итерации подобного источника (сейчас я его правлю ручками и по окончании собираюсь выложить следующую версию). Кстати, было бы желательно подключение его и к редактору - чтобы пользователь в основном не набирал теги вручную, а выбирал из списка.
Но и зажимать сообщество рисовать только известные теги, или их малое подмножество – тоже не дело. Да это и не нужно – каждый понимает, что программа при всём желании пользователя физически не сможет УДОБНО(!) отобразить ВСЕ теги, даже из списка мапфичесов.
Еще раз хочу обратить внимание на разницу между “обрабатывать” и “отображать”.
Кроме того, теги имеют две части: ключ и значение. Сейчас они как бы равнопроавны с точки зрения свободы выбора. А должны быть, на мой взгляд, совершенно неравноправны: употребление в ключе нестандартной комбинации должно рассматриваться как явление крайне нежелательное (именно поэтому я и привел в исходном посте лишь анализ по ключевой части), а значение - в некоторых случаях (как, например, с ключами name или description) просто обязано быть уникальным. Опять же, хотелось бы четко разделить ключи на 3 типа:
- С уникальными значениями.
- Допускающие как уникальные, так и предопределенные значения.
- Только с предопределенными значениями (как частный случай - единственное значение yes).
… но моё мнение, что все программы уже написаны, все интерфейсы уже выдуманы.
Я не разделяю эту точку зрения.
Пиктограмма это стилизованная картинка (неожиданная смена темы)) для изображения сообщения или указания в условиях помех – в цейтноте, в плохой видимости, слышимости, стрессовом состоянии, и т.д. (ну и языковой барьер).
Так вот, программа-навигатор – это тоже самое. Чем больше мы впихиваем информации в экран, тем менее читаемой в условиях помех она оказывается.
А разве я употребил слово “навигатор”?
Я пока еще вообще не решил, будет ли моя программа прокладывать маршрут или нет. Зато, например, она будет работать с базой КЛАДР. Это, кстати, отчасти ответ на вопрос - а все ли программы уже написаны. Я, например, не знаю ни одной, которая бы работала и с базой КЛАДР, и со спутниковыми снимками.