Подготовка

В этом документе описаны предварительные условия, лучшие практики и распространенные ошибки при работе с наборами данных.

Предварительные условия

При создании набора данных:

  • Отображаемые имена должны быть уникальными в рамках вашего проекта Google Cloud.
  • Отображаемые имена должны быть меньше 64 байтов (поскольку эти символы представлены в кодировке UTF-8, в некоторых языках каждый символ может быть представлен несколькими байтами).
  • Описания должны быть меньше 1000 байт.

При загрузке данных:

  • Поддерживаемые типы файлов: CSV, GeoJSON и KML.
  • Максимальный поддерживаемый размер файла — 500 МБ.
  • Имена столбцов атрибутов не могут начинаться со строки «?_».
  • Трехмерная геометрия не поддерживается. Сюда входит суффикс «Z» в формате WKT и координата высоты в формате GeoJSON.

Лучшие практики подготовки данных

Если ваши исходные данные сложны или велики, например, плотные точки, длинные линии или многоугольники (часто в эту категорию попадают исходные файлы размером более 50 МБ), рассмотрите возможность упрощения данных перед загрузкой, чтобы добиться максимальной производительности на визуальной карте.

Вот несколько рекомендаций по подготовке данных:

  1. Свернуть свойства объекта . Сохраняйте только свойства объекта, необходимые для стилизации вашей карты, например «id» и «категория». Вы можете присоединить дополнительные свойства к функции в клиентском приложении, используя стили, управляемые данными, на ключе уникального идентификатора. Например, см . Просматривайте данные в реальном времени с помощью стилей на основе данных .
  2. По возможности используйте простые типы данных для объектов свойств, например целые числа, чтобы минимизировать размер фрагмента и повысить производительность карты.
  3. Упростите сложную геометрию перед загрузкой файла. Вы можете сделать это с помощью геопространственного инструмента по вашему выбору, такого как утилита с открытым исходным кодом Mapshaper.org , или в BigQuery, используя ST_Simplify для сложной геометрии полигонов.
  4. Сгруппируйте очень плотные точки перед загрузкой файла. Вы можете сделать это с помощью геопространственного инструмента по вашему выбору, такого как функции кластера turf.js с открытым исходным кодом, или в BigQuery, используя ST_CLUSTERDBSCAN для плотной точечной геометрии.

Дополнительные рекомендации по передовым практикам работы с наборами данных см. в разделе Визуализация данных с помощью наборов данных и BigQuery .

Требования GeoJSON

API наборов данных Карт поддерживает текущую спецификацию GeoJSON . API наборов данных Карт также поддерживает файлы GeoJSON, содержащие любые из следующих типов объектов:

  • Геометрические объекты . Геометрический объект — это пространственная форма, описываемая как объединение точек, линий и многоугольников с дополнительными отверстиями.
  • Объекты-характеристики . Объект объекта содержит геометрию плюс дополнительные пары имя/значение, значение которых зависит от приложения.
  • Коллекции функций . Коллекция объектов — это набор объектов объектов.

API наборов данных Карт не поддерживает файлы GeoJSON, содержащие данные в системе координат (CRS), отличной от WGS84 .

Дополнительную информацию о GeoJSON см. в разделе «Соответствие RFC 7946» .

Требования KML

К API наборов данных Карт предъявляются следующие требования:

  • Все URL-адреса должны быть локальными (или относительными) по отношению к самому файлу.
  • Поддерживаются точечные, линейные и полигональные геометрии.
  • Все атрибуты данных считаются строками.
Следующие функции KML не поддерживаются:
  • Значки или <styleUrl> определенные вне файла.
  • Сетевые ссылки, например <NetworkLink>
  • Наложения земли, например <GroundOverlay>
  • 3D-геометрия или любые теги, связанные с высотой, такие как <altitudeMode>
  • Характеристики камеры, такие как <LookAt>
  • Стили, определенные в файле KML.

Требования к CSV

Для файлов CSV поддерживаемые имена столбцов перечислены ниже в порядке приоритета:

  • latitude , longitude
  • lat , long
  • x , y
  • wkt (хорошо известный текст)
  • address , city , state , zip
  • address
  • Один столбец, содержащий всю адресную информацию, например 1600 Amphitheatre Parkway Mountain View, CA 94043

Например, ваш файл содержит столбцы с именами x , y и wkt . Поскольку x и y имеют более высокий приоритет, что определяется порядком поддерживаемых имен столбцов в приведенном выше списке, используются значения в столбцах x и y , а столбец wkt игнорируется.

Кроме того:

  • Каждое имя столбца должно принадлежать одному столбцу. То есть у вас не может быть столбца с именем xy , который содержит данные координат x и y. Координаты x и y должны быть в отдельных столбцах.
  • Имена столбцов нечувствительны к регистру.
  • Порядок имен столбцов не имеет значения. Например, если ваш CSV-файл содержит столбцы lat и long , они могут располагаться в любом порядке.

Обработка ошибок загрузки данных

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

Ошибки GeoJSON

К частым ошибкам GeoJSON относятся:

  • Поле type отсутствует, или type не является строкой. Загруженный файл данных GeoJSON должен содержать строковое поле с именем type как часть каждого объекта Feature и определения объекта Geometry.

Ошибки KML

К частым ошибкам KML относятся:

  • Файл данных не должен содержать ни одной из неподдерживаемых функций KML, перечисленных выше, иначе импорт данных может завершиться неудачно.

CSV-ошибки

Распространенные ошибки CSV включают в себя:

  • В некоторых строках отсутствуют значения для столбца геометрии. Все строки в файле CSV должны содержать непустые значения столбцов геометрии. Столбцы геометрии включают в себя:
    • latitude , longitude
    • lat , long
    • x , y
    • wkt
    • address , city , state , zip
    • address
    • Один столбец, содержащий всю адресную информацию, например 1600 Amphitheatre Parkway Mountain View, CA 94043
  • Если x и y – это столбцы геометрии, убедитесь, что в качестве единиц измерения используются долгота и широта. Некоторые общедоступные наборы данных используют разные системы координат под заголовками x и y . Если используются неправильные единицы измерения, набор данных может быть успешно импортирован, но визуализированные данные могут отображать точки набора данных в неожиданных местах.