Разместите свой проект бесплатно и начните получать предложения от фрилансеров-исполнителей уже спустя минуты после публикации!

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

закрыт без выполнения


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


Нужно создать визуальный компонент (наследник 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: Бюджет договорной



  1.  фрилансер больше не работает на сервисе
  • Александр Литвинцов
    18 января в 23:34 |

    По моему скромному мнения, автор сия проекта, будучи программистом, "немножко" в розовых очках.
    На делфях тут от 3000 часов работы, боюсь динозавры помнящие что такое TPanel, могут и не дожить))

  • Віталій Янішевський
    19 января в 00:51 |

    Це не компонент, це цілий двіжок. Не те щоб неможливо впринципі, але не на одну тисячу людиногодин задачка.

  • Константин Лях — заказчик проекта
    19 января в 12:35 |

    В первой же строке я написал что это кропотливая работа 🙂

    И да я не в розовых очках, я действительно понимаю что это не работа однодневка за 100 баксов. Готов рассмотреть работу команды программеров.

    И да это почти готовый движок. Почти, - потому как я реально представляю что нужно написать и что потом МНЕ придётся допиливать сверху. Представляю потому как то что нужно (ну почти) уже писал отдельно на VBA (так сложилось), но теперь это нужно написать на DELPHI\С/С++ (не портировать а именно заново написать).  И я, зная чего это будет стоить, - хотел-бы просто заплатить чем заниматься этим гемором самому ....

  • Віталій Янішевський
    19 января в 14:37 |

    Тоді варто почати роботу команди як мінімум з архітектури двіжка. Тоді стане виднійше, що костиль на VBA настільки простий, наскільки й безперспективний, а зайняв майже місяць роботи. Безумовно, можна накатать імітатор подібного функціоналу, десь за місяць. І вже через місяць перероблювати з нуля бо "можливості системи вичерпались".


    В мене є первний досвід розробки "малювалок" (принципові схеми, трасування плат, CAD-оподібні малювалки під гравери), вони всі приблизно місяць робились, і всі були виключно під свої задачі без натяку на масштабування.


    Що запропонувати тут... Навіть незнаю.

  • Константин Лях — заказчик проекта
    19 января в 12:37 |

    ЗЫ: на VBA у меня ушло 3,5 недели работы, так что 3000 часов ИМХО - слегка завышено.

  • Александр Литвинцов
    19 января в 16:37 |

    4 человека 6 месяцев на С# .net,  аналогичный проект. И цифры про часы с реального проекта. Потому знаю о чем говорю, написать что-либо как-либо за 3.5 каждый может. Один только кеш с умной подгрузкой это целая подсистема. Причем, например, Google напрямую запрещает  в сторонних ПО сохранять исходные изображения и мы например юзали openstreetmaps.
    3000 часов, какая там у нас средняя ставка у мидла? как раз чуть больше ляма и выходит))

  • Anton Kravtsov
    19 января в 14:15 |

    Нужно создать визуальный компонент (наследник TPanel или что-то подобное) для отображения/редактирования векторной графики поверх слоя растровой. 

    ...

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

    TPanel - это что-то из VCL, что ли? Т.е. по сути не C++, а Builder C++ (или как оно теперь там зовётся)

    Имело бы смысл добавить к описанию предполагаемый вид API, если допускается реализация на C++.

  • Andrij Kratko
    19 января в 15:11 |

    В описании указана кросс-платформенность и упоминается firemonkey. Поэтому тут, скорее всего, имеется в виду класс FMX.StdCtrls.TPanel, а не Vcl.ExtCtrls.TPanel. Думаю это еще и не окончательное решение.

  • Віталій Янішевський
    19 января в 19:37 |

    Згідно ТЗ, це повноцінний редактор. Тобто не просто наслідний якогось компонента на якому видно картинку, а як мінімум цілий фрейм із вбудованими палітрами інструментів.