Скелет (компонент) для нанесения векторной графики поверх карт

Задача достаточно тривиальная, но кропотливая.

Нужно создать визуальный компонент (наследник TPanel или что-то подобное) для отображения/редактирования векторной графики поверх слоя растровой. В качестве растровой графики выступают изображения Google/Yandex/и т.д. онлайн карт. И "немножко" кода, для наследования в дальнейшем (под наследованием я понимаю что примитивы уже созданы и работают графически и на уровне пользователя (интерактива рисования), а я только добавляю свойства для вычислений бизнес-логики), и создания своих векторных примитивов. Как то: линия, полилиния, многоугольник, круг, дуга, комбинированный многоугольник (линии + дуги + круги) ну и в добавок ко всему точки привязки. Например для линии/поли/дуги = начало/конец, для многоугольника = произвольные точки привязки на стыках линий/дуг и пр ... При этом при редактировании связанные объекты (например линии) должны подтягиваться за перемещаемым объектом "аля" MsVisio.

Требования:

0) Забудьте о фиксированных координатах и привязках в виде пикселей. ТОЛЬКО "относительные" координаты в виде широта/долгота (пиксели оставьте в реализации/отрисовке - они меня не интересуют).

1) C\C++ or Delphi : будет встраиваться в существующий проект.

2) Кроссплатформенность (FireMonkey). Никаких "фич и няшек" для отдельно взятой платформы.

3) Способность подгружать частями (тайлами) карты (растры) как с онлайн сервисов (Google Maps, Yandex Maps и т.д. подгрузить строку урл-запроса из ini-файла я думаю не проблема), так и из локального кеша (база данных), ну и соответственно уметь "дёргать" методы для их (кеша) сохранения/восстановления. При этом я не требую разрабатывать БД, достаточно продумать структуру и методы выгрузки по частям хотя-бы в TStream. (не забываем об "относительности" - хранение координат только в широте/долготе).

4) Родитель(и) "примитивов" должен(ы) уметь отрисовывать себя частями относительно отображаемого Canvas. Т.е. карта может показывать часть улицы но линия (например труба) может быть проложена из другого района в третий а на экране отображаться только часть этой трубы.

5) Карты могу быть огромными (очень) а объекты связывать города, поэтому грузить всё в память нельзя!!! Растр должен отображать только то что "влазит на экран" (желательно конечно +/- для буфера и плавной прокрутки), + объекты которые отображаются (проходят) через отображаемый регион + связанные объекты этого и вышестоящего уровня (лейера/слоя)

6) Отрисовка/хранение примитивов будет базироваться на уровнях/слоях/леерах. Т.е 0-й слой - это растровая карта, все последующие слои - это вектор. На каждом векторном слое будет от 1К до 100К примитивов (зон) каждый вышестоящий слой - то-же самое, но с возможностью связывания с нижестоящим слоем(и) в одной или нескольких точках. Своеобразное дерево...

7) Все объекты должны уметь "дёргать" методы сохранения/восстановления в/из (TStream как минимум, БД - желательно). Основной "визуальный компонент" - должен уметь "дёрнуть цепочку" сохранения/восстановления И уметь "дёргать" "подгрузку"  при отрисовке/смещении просмотра/изменении отображения (в т.ч. редактировании).

8) По примитивах: 

 8.1) линии и все производные должны уметь рассчитывать свою полную длину в метрах, и рассчитывать/отображать на своей длине точки частичной длины начиная от любого конца.

 8.2) многоугольники и др. замкнутые фигуры и все производные должны уметь рассчитывать свою площадь в кв. метрах.

9) Ну и напоследок немножко плюсов для упрощения задачи :) Масштабирование изображений - фиксированное. Фиксация относительно масштабов онлайн-сервисов карт (от 0 до 19). Т.е. растровую подложку - вообще не "ресайзим" (берем то что выдают сервисы), а векторы "ресайзим" относительно фиксированных значений ...

10) Ну и напоследок, не очевидное: объекты и слои их включающие, должны иметь макс и мин значения масштаба отображения (масштаб от сервисов карт). Т.е. нет нужды отображать на карте всей земли топографию водопровода "мухосранска" - при масштабе 0 - весь водопровод уместиться в "0,хрен десятых" точки на экране, а вот на масштабе от 16 до 18 - можно и показать .... И при этом, самое "не очевидное" - сами "примитивы", и толщину их линий - тоже нужно масштабировать в пределах этого диапазона ...

ЗЫ: Жду предложений, возможно и с дальнейшим сотрудничеством.

ЗЗЫ: Т.З. Написано своими словами что-бы не ограничивать Ваше творчество. 

             Мне Важен как конечный результат так и его масштабируемость.

ЗЗЗЫ: Всё обговаривается!. Но миллионов не ждите, - я не гугл ..., а такой же как и Вы "программер", но занимаюсь своей нишей в БД, и лезть в графику и пространственные вычисления - мне влом ... :)

PPPPS: Бюджет договорной