Antes de comenzar

En este documento, se describen los requisitos previos, las prácticas recomendadas y los errores comunes cuando se trabaja con conjuntos de datos.

Requisitos previos

Cuando crees un conjunto de datos, ten en cuenta lo siguiente:

• Los nombres visibles deben ser únicos para tu proyecto de Google Cloud.
• Los nombres visibles deben tener menos de 64 bytes (dado que estos caracteres se representan en UTF-8, cada carácter puede representarse mediante varios bytes en algunos idiomas).
• Las descripciones deben tener menos de 1,000 bytes.

Cuando subas datos, ten en cuenta lo siguiente:

• Los tipos de archivo admitidos son CSV, GeoJSON y KML.
• El tamaño máximo de archivo admitido es de 500 MB.
• Los nombres de las columnas de atributos no pueden comenzar con la cadena "?_".
• No se admiten las geometrías tridimensionales. Esto incluye el sufijo "Z" en el formato WKT y la coordenada de altitud en el formato GeoJSON.

Nota: La carga puede tardar minutos o incluso horas en completarse, según el tamaño del archivo de datos. Si la carga falla, recibirás un mensaje de error. No intentes borrar el conjunto de datos hasta que se haya mostrado una respuesta de la operación de carga.

Nota: Es posible que las tarjetas de mapas creadas con datos subidos a través de la API de Maps Datasets dejen caer o simplifiquen datos complejos o densos en niveles de zoom bajos. Por ejemplo, cuando un usuario aleja el mapa a un estado o país (por ejemplo, del nivel de zoom 5 al 12), los datos en mosaicos pueden verse diferentes a cuando se acerca a una ciudad o un vecindario (por ejemplo, del nivel de zoom 13 al 18). Esto se hace para mantener las tarjetas delgadas y con un buen rendimiento con un renderizador de mapas.

Sugerencia: Si tu archivo de datos es grande y tiene muchos atributos que no son necesarios para definir el diseño, y deseas optimizar el rendimiento de la renderización, edita el archivo para quitar los atributos innecesarios. Si reduces la cantidad de atributos, se reducirá el tamaño de los mosaicos del mapa y, por lo tanto, mejorará el rendimiento de la renderización.

Prácticas recomendadas para la preparación de datos

Si tus datos de origen son complejos o grandes, como puntos densos, cadenas de caracteres o polígonos largos (a menudo, los archivos de origen de más de 50 MB pertenecen a esta categoría), considera simplificar tus datos antes de subirlos para lograr el mejor rendimiento en un mapa visual.

Estas son algunas prácticas recomendadas para preparar tus datos:

1. Minimiza las propiedades de los componentes. Solo conserva las propiedades de componentes necesarias para aplicar diseño a tu mapa, por ejemplo, "id" y "categoría". Puedes unir propiedades adicionales a un componente en una aplicación cliente con estilos basados en datos en una clave de identificador único. Por ejemplo, consulta Cómo ver tus datos en tiempo real con el diseño basado en datos.
2. Usa tipos de datos simples para los objetos de propiedad siempre que sea posible, como números enteros, para minimizar el tamaño de las tarjetas y mejorar el rendimiento del mapa.
3. Simplifica las geometrías complejas antes de subir un archivo. Puedes hacerlo en la herramienta geoespacial que elijas, como la utilidad de código abierto Mapshaper.org, o en BigQuery con ST_Simplify en geometrías de polígonos complejas.
4. Agrupa puntos muy densos antes de subir un archivo. Puedes hacerlo en la herramienta geoespacial que elijas, como las funciones de clúster de turf.js de código abierto o en BigQuery con ST_CLUSTERDBSCAN en geometrías de puntos densas.

Consulta orientación adicional sobre las prácticas recomendadas de los conjuntos de datos en Visualiza tus datos con conjuntos de datos y BigQuery.

Requisitos de GeoJSON

La API de Datasets de Maps admite la especificación actual de GeoJSON. La API de Maps Datasets también admite archivos GeoJSON que contengan cualquiera de los siguientes tipos de objetos:

• Objetos de geometría. Un objeto de geometría es una forma espacial descrita como una unión de puntos, líneas y polígonos con agujeros opcionales.
• Objetos de componente. Un objeto de componente contiene una geometría y pares de nombre/valor adicionales cuyo significado es específico para cada aplicación.
• Colecciones de componentes: Una colección de características es un conjunto de objetos de características.

La API de Datasets de Maps no admite archivos GeoJSON que tengan datos en un sistema de referencias de coordenadas (CRS) diferente de WGS84.

Para obtener más información sobre GeoJSON, consulta el artículo sobre el cumplimiento de RFC 7946.

Requisitos de KML

La API de Datasets de Maps tiene los siguientes requisitos:

• Todas las URLs deben ser locales (o relativas) al archivo.
• Se admiten las geometrías de punto, línea y polígono.
• Todos los atributos de datos se consideran cadenas.

No se admiten los siguientes componentes de KML:

• Los íconos o <styleUrl> que se definan fuera del archivo
• Los vínculos de red, como <NetworkLink>
• Las superposiciones de suelo, como <GroundOverlay>
• Las geometrías 3D o cualquier etiqueta relacionada con la altitud, como <altitudeMode>
• Las especificaciones de cámara, como <LookAt>
• Los diseños definidos dentro del archivo KML

Requisitos de CSV

Para los archivos CSV, los nombres de columnas admitidos se indican a continuación, en orden de prioridad:

• latitude, longitude
• lat, long
• x, y
• wkt (Well-Known Text)
• address, city, state, zip
• address
• Una sola columna que contiene toda la información de la dirección, como 1600 Amphitheatre Parkway Mountain View, CA 94043

Por ejemplo, tu archivo contiene columnas llamadas x, y y wkt. Dado que x e y tienen una prioridad más alta, según el orden de los nombres de columna admitidos en la lista anterior, los valores en las columnas x y y se utilizan, y la columna wkt se ignora.

Además:

• Cada nombre de columna debe pertenecer a una sola columna. Esto significa que no puedes tener una columna llamada xy que contenga datos de coordenadas "x" e "y". Las coordenadas "x" e "y" deben estar en columnas separadas.
• Los nombres de las columnas no distinguen mayúsculas de minúsculas.
• El orden de los nombres de columna no es relevante. Por ejemplo, si tu archivo CSV contiene columnas lat y long, estas pueden mostrarse en cualquier orden.

Cómo controlar errores de carga de datos

Cuando subes datos a un conjunto de datos, es posible que experimentes uno de los errores comunes que se describen en esta sección.

Errores de GeoJSON

Estos son algunos de los errores comunes de GeoJSON:

• Falta el campo type, o bien type no es una cadena. El archivo de datos GeoJSON subido debe contener un campo de cadena llamado type como parte de la definición de cada objeto de componente y objeto de geometría.

Errores de KML

Estos son algunos de los errores comunes de KML:

• El archivo de datos no debe contener ninguno de los componentes KML no admitidos que se mencionaron en la lista anterior. De lo contrario, la importación de datos podría fallar.

Errores de CSV

Estos son algunos de los errores comunes de CSV:

• A algunas filas les faltan valores para una columna de geometría. Todas las filas de un archivo CSV deben contener valores no vacíos para las columnas de geometría. Entre las columnas de geometría, se incluyen las siguientes:
  • latitude, longitude
  • lat, long
  • x, y
  • wkt
  • address, city, state, zip
  • address
  • Una sola columna que contiene toda la información de la dirección, como 1600 Amphitheatre Parkway Mountain View, CA 94043
  Nota: Este error suele describirse con un mensaje similar al siguiente: "Unable to convert ' ' to a double" o "Could not parse input to geography.: Geography value is missing".
• Si x y y son las columnas de geometría, asegúrate de que las unidades sean de longitud y latitud. Algunos conjuntos de datos públicos usan diferentes sistemas de coordenadas bajo los encabezados x e y. Si se usan unidades incorrectas, el conjunto de datos podría importarse de forma correcta, pero los datos renderizados podrían mostrar puntos del conjunto de datos en ubicaciones inesperadas.