Мы фактически используем это как вопрос для интервью. Я согласен с jk, вы должны использовать стороннюю библиотеку, но я дам вам идею
Первое сохранение этих данных в виде изображения - неправильный подход. На самом деле мы формулируем наш вопрос, чтобы немедленно отвлечь людей от этого подхода. Вы действительно хотите сохранить отдельные дороги или объекты в виде серии точек (желательно с использованием сплайнов, чтобы вы могли эффективно представлять кривые), а затем визуализировать правильные дороги. Теперь, когда вы используете векторные (а не растровые) данные, ваши проблемы с масштабированием и поворотом решены.
Вы шли по правильному пути, когда обсуждали разбиение его на более мелкие квадраты. Каждый квадрат должен содержать данные обо всех дорогах, которые проходят через него. Если дорога пересекает край, разбейте его на две части, по одной на каждом квадрате. Таким образом, в каждом квадрате достаточно данных для полной визуализации.
Поиск квадратов, которые нужно нарисовать, может быть немного болезненным, но не хуже, чем вы должны были решить с помощью изображений. Лично я бы сохранил кучу структур данных в двоичном файле с индексом в начале, перечисляя, где каждый квадрат начинается в файле и как долго это происходит. Таким образом, вы можете довольно эффективно читать данные для квадрата (перейти к правильному положению в оглавлении, прочитать данные оглавления, перейти к началу квадрата, прочитать данные квадрата). Вы даже можете оптимизировать для пустых квадратов, разделяющих пространство.
Наконец, вы, вероятно, захотите сделать разные уровни масштабирования. Лично я бы хранил совершенно отдельный набор блоков с несколькими различными уровнями масштабирования. Таким образом, вы можете соответствующим образом изменить размер блока.
Опять же, повторюсь, используйте продукт с полки, но нет проблем с использованием этого в качестве мысленного эксперимента.