Видел у себя в ленте strava одного триатлета, который выкладывал трек перелета, как будто на велосипеде проехал. Непонятно конечно зачем так делать, но зато куча рекордов сразу:)

Если хранить координату как два double-числа, то она будут занимать 16 байт. Для генерализованных тайлов можно сделать относительную систему координат для каждого тайла и предположить, что в клиенте он будет рендериться в картинку максимального размера 256 на 256 пикселей. Тогда все координаты можно преобразовать в целочисленные значения от 0 до 255 и хранить в байте, то есть всего два байта на координату. Это справедливо только для генерализованных тайлов. Для обычных же можно перейти к целочисленным координатам, пересчитанным относительно угла тайла. Значения будут гораздо меньше оригинальных, и из можно хранить переменным числом байт, используя алгоритм ZigZag из Google Protocol Buffers.

Надеемся наши конечные продукты до такого не дойдут:)

Есть возможность посмотреть организации здания, readonly конечно же.

Когда мы начинали делать свой продукт, в конечных вообще были UTM-проекции, для каждого города 2ГИС своя. А нам нужен был весь мир и выбрали EPSG:3395. Потом конечные продукты решили использовать EPSG:3857, а мы не стали у себя что-то менять. Конвертация не вызывает проблем, и если вдруг в какой-то момент конечные продукты захотят использовать другую проекцию, мы легко это поддержим.

Это всего лишь картинка, отражающая множество частых операций картографа. Вы же не думаете, что они после каждого действия «Поправить объект» идут пить кофе?

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

Что-то я давно в код тайлов не заглядывал, каюсь. Сейчас там в точности такая реализация, как Вы описали.

Проекта ДГПП, в котором был бейсик, уже нет:) Он был разделен на несколько независимых частей, одной из которых стал Fiji. Используем .NET-стек и немного Java. Вся работа с карточками организаций происходит в другой системе, картограф в этом не участвует.
Для космоснимков используется отдельный сервис, который отдает данные на клиента по протоколу WMS, никакого локального хранения.

Планы конечно же есть, но никаких конкретных сроков пока нет.

1. Только для небольшой оптимизации — флаг вместо четырех координат, если тайл полностью покрывает объект. Чтобы нарисовать заливку в этом тайле, если она нужна. Очень актуально для больших объектов типа населенных пунктов, районов и т.д.
2. Для некоторых типов объектов картографы специально ставят точку, в которой должна быть подпись, мы ее храним как отдельный атрибут и потом используем в отрисовке. Для всех остальных случаев подпись может дублироваться, если объект попал в несколько тайлов, для нас это нормальная ситуация, никакой склейки геометрий не делаем. Это касается только нашего внутреннего продута, в конечных же продуктах свои алгоритмы расставления подписей.
3. В SQL Server хранятся оригинальные геометрии, сами же тайлы лежат в отдельных базах PostgreSQL. В них один тайл это одна запись в таблице. Однако помимо простой операции получения по ключу нам иногда нужны и более хитрые запросы, поэтому в таблице есть и другие колонки. Key-value хранилище в таких случаях нам не подходит.
4. Сетка регулярная, в итоге получается, что у нас есть все тайлы, которые явно запрашивали пользователи. Если запроса на тайл не было, специально мы его не создаем.
5. Для отрисовки тайлов используется GDI+. А вот для для отображения трекеров при редактировании объектов у нас есть два режима в клиенте — DirectX и GDI+. Первый выигрывает на большом количестве точек и трекеров. Однако на большом зоопарке машин картографов иногда он не работает, поэтому можем отображать трекеры средствами GDI.
Спасибо за предложенные идеи по ускорению. Чтение изменений у нас примерно так и сделано. Про дополнительное получение необработанных изменений с клиента интересно, но может не подойти нам по причине сильной отдаленности некоторых клиентов от центральной БД, попробуем поэкспериментировать.

Глобальные координаты, которые Вы указали, это сферические координаты. То есть координаты на сфере как модели Земли. В реальности гораздо проще работать с плоскими координатами. Мы выбрали WGS84, потому что она покрывает весь мир (есть еще и такие, которые покрывают только часть земной поверхности, например, UTM) и сохраняет углы и формы.
То, что показывает навигатор, скорее всего просто пересчет из используемой им проекции в глобальные координаты, это очень простая операция. Мы в своем клиенте в статусбаре тоже такие координаты показываем.

Рады стараться!

Теперь ничего не напутано.

Действительно перепутали… Спасибо за наблюдательность!

К тайловым серверам пришли постепенно. Сначала у нас был один тайл-сервер, который стоял рядом с мап-сервером в новосибирском дата-центре и обслуживал местных пользователей. Потом пользователей становилось все больше, а их география росла. Один сервер не справлялся, так как запросов становилось очень много и много времени терялось на пингах от удаленных клиентов. Мы решили просто замасштабироваться и ставить тайл-серверы поближе к группам пользователей. Сейчас у нас их девять.
MSSQL был выбран с самого начала, потому что у нас были на него лицензии, был опыт работы плюс наша команда администрирования умеет его хорошо готовить.