Подготовка

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

Предпосылки

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

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

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

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

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

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

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

  1. Минимизируйте свойства объекта . Оставьте только те свойства объекта, которые необходимы для оформления карты, например, «id» и «category». Вы можете добавить дополнительные свойства к объекту в клиентском приложении, используя стили на основе данных по уникальному ключу идентификатора. Например, см. раздел «Просмотр данных в режиме реального времени с помощью стилей на основе данных» .
  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 . При использовании неправильных единиц набор данных может импортироваться успешно, но при визуализации данных точки набора данных могут располагаться в неожиданных местах.