согласен, самая проблема будет в наполняемости :) пока инструмент неизвестен он и не известен.

ага. но она я уже говорил решается в виде комплектной базы: выгрузка осм + собранные из внешних источников модельки.

и еще одна мысль. в базе будет огромное количество повторяющихся или параметрически подобных 3д-моделек. теже самые бетонные панельки. по уму понадобится какаято ссылочная система, дабы не плодить сущности черезмерно.
в системе встроенных моделек это опять придется мудрить, в системе внешних вообще не возникает проблемы.

о блин. пропустил.

даже при наличии текстовых 3д-моделек и текстовых растровых форматов (вспомним XPM), svg - такто векторный,
самое большая проблема что потребуется менять API OSM чтобы они туда влезали. в 256 символов ничего подобного не впихнешь. изменение формата потребует изменения в рендерах и прочем софте, потом допиловку изменений и отлов багов. это растянется на года с криками и стонами “ нафиха?? и так было все хорошо”.

альтернатива - внешние 3д-модельки.
в текущие объекты добавляются несколько тегов (к примеру): 1. урл на полноразмерную многоцветную модельку в любом формате. 2. несколько тегов привязки и масштабирования модельки или что подобное.

изменений API нет. ваааапче нет. все стандартно. весь имеющийся софт работает стандартно, стандартно исключая неизвестные теги, к коим и автоматически отнесутся теги 3д-моделек.

3д-модельки можно централизовано качнуть и собрать в базу: к примеру zip-архив в корне osm.xml, в подпапках модельки, дополнительно либо файл замены урлов на локальный путь, либо прям в осм.хмл править урлы. получится искомая БД ОСМ со всем 3д-модельками. плюс добавить тестирование моделек на правильность.

и это можно сделать вот прям щас, никому не мешая. максимум попросить 3д-рендеров о поддержке данной схемы и получить результат.
т.е. эффективно расширить формат без революций в стакане воды. если нет разницы, то зачем мудрить лишнего.