Si alguna de estas preguntas resuena contigo, esta serie de artículos es para ti. Exploraremos todas estas cuestiones y muchas más.

Está diseñada para ayudar a desarrolladores, arquitectos de soluciones, ingenieros de datos y otros perfiles técnicos en la toma de decisiones, a comprender las diferencias entre los servicios de datos alojados en ArcGIS más utilizados (disponibles bajo un modelo de consumo) y cómo cada uno está optimizado para distintos casos de uso:

• Servicios de teselas de mapa alojados (Hosted map tile services): para grandes volúmenes de datos geoespaciales estáticos.
• Servicios de teselas vectoriales alojados: para grandes volúmenes de datos que no cambian con frecuencia, con soporte para personalización e interacción básica.
• Servicios de entidades alojados: para datos voluminosos, muy interactivos y editables, que requieren cambios de manera eficiente.

⚠️ Nota importante: si estás empezando con los datos geoespaciales, te recomiendo que leas antes el artículo ¿Qué tienen de especial los datos geoespaciales?, ya que te ayudará a comprender mejor el valor que ofrecen estos servicios.

Otros servicios de datos en ArcGIS
Ten en cuenta que, además de los tres servicios tratados en esta serie, existen otros servicios de datos muy utilizados dentro del sistema ArcGIS, optimizados para distintos fines, como trabajar con imágenes (servicios de imágenes alojadas y servicios de imágenes), los servicios 3D (incluyendo escenas 3D, teselas 3D, etc.), los conjuntos de datos en tiempo real (servicios de streaming de datos), así como otros diseñados para trabajar con big data, entre muchos más.

Contenido y enfoque

Esta serie se centra específicamente en estos tres servicios en la nube gestionados por Esri, disponibles como Software como Servicio (SaaS) y Plataforma como Servicio (PaaS) a través de ArcGIS Online y ArcGIS Location Platform.

Aunque también existen en entornos autogestionados mediante ArcGIS Enterprise, no los trataremos aquí para mantener el enfoque claro, ya que implican consideraciones diferentes.

Tampoco incluiremos ejemplos de código y apenas algunos pasos de implementación; sin embargo, enlazaremos a recursos relevantes del Portal, la guía de servicios de datos y otras páginas de documentación siempre que sea necesario.

¿Por qué aprender sobre los servicios de datos alojados en ArcGIS?

A veces necesitas escalar tu infraestructura y reducir el overhead, o carga operativa. Utilizar servicios gestionados permite descargar gran parte de la complejidad técnica. Contar con servicios en la nube para almacenar, consultar y actualizar datos espaciales de forma eficiente te permite centrarte en lo que realmente importa: aportar valor al usuario final.

Aquí es donde entran en juego los servicios de datos alojados de ArcGIS. Son el resultado de décadas de experiencia dando soporte a cientos de miles de organizaciones en el ámbito geoespacial. Pueden complementar a la perfección tu infraestructura actual, reduciendo su carga de trabajo y facilitándole la vida.

Además, ofrecen ventajas de interoperabilidad, ya que también pueden exponerse mediante estándares abiertos como la OGC API, estándares de facto como las teselas web (también conocidas como XYZ tiles), MVT o formatos de texto plano muy extendidos como GeoJSON, lo que los hace accesibles tanto desde clientes de Esri como de terceros.

A lo largo de la serie también verás comparaciones con otras tecnologías que puede que ya conozcas, para ayudarte a identificar similitudes, diferencias y en qué aspectos destacan los servicios de ArcGIS.

¿Por qué hemos escrito esta serie?

Puede que te preguntes por qué hemos decidido escribir esta serie de artículos si ya existe documentación oficial de estos servicios. Buena pregunta 😁.

Las principales razones son:

• Algunos detalles técnicos de bajo nivel no están cubiertos en la documentación oficial. Aunque no son imprescindibles para usar los servicios, sí ayudan a comprender sus diferencias y a elegir cuál se ajusta mejor a tus necesidades.
• Existen flujos de trabajo avanzados y herramientas para casos de uso que requieren una automatización completa que no son muy conocidos.
• La documentación técnica y la de negocio no siempre están bien conectadas, lo que complica la toma de decisiones desde ambas perspectivas.

Por eso hemos creado esta serie: para ofrecerte un recurso centrado en ayudarte a:

• Evaluar qué servicio conviene más a cada conjunto de datos y flujo de trabajo.
• Reducir la curva de aprendizaje, acelerar la integración y disminuir el esfuerzo de mantenimiento.
• Aprender cómo mejorar la experiencia de usuario en tus aplicaciones.
• Optimizar costes asociados.

Eso sí, conviene tener presente que tanto la tecnología como el modelo de negocio evolucionan rápidamente, lo que significa que algunos detalles mencionados podrían quedar desactualizados con el tiempo. Por ello, cada artículo incluye referencias a la documentación oficial, que siempre prevalece como la fuente más actualizada y prioritaria.

Al finalizar la serie, serás capaz de distinguir claramente las capacidades, casos de uso y compromisos entre estos servicios. Y comprenderás a fondo el siguiente diagrama que ilustra algunas de estas diferencias:

Además, tu equipo sabrá qué opción es la más adecuada para alojar cada conjunto de datos según vuestras necesidades específicas y cómo combinarlos en vuestras aplicaciones.

Próximos pasos

Como mencioné al inicio, esta serie está pensada para diferentes perfiles implicados en el uso de estos servicios. La siguiente tabla resume qué cubrirá cada artículo, a quién va dirigido y qué puedes esperar al leerlo:

Nota: en principio no tengo planeado publicar los siguientes artículos al español, pero si tienes problemas para entenderlos, no dudes en ponerte en contacto con nosotros a través de developers@gmail.com

Espero que esta introducción haya despertado tu interés y te haya dejado con ganas de leer los próximos artículos.

Tienes varias formas de mantenerte al día:

• Siguiéndome aquí en Medium.com.
• Siguiéndome en redes sociales (LinkedIn, Bluesky o X).
• Siguiéndome en dev.to.
• Suscribiéndote al feed RSS de Esri con tu lector favorito.

Si algo te ha resultado confuso, o crees que has detectado un error o inconsistencia en este artículo, me encantaría que me lo contaras. Puedes escribirme a developers@esri.com para seguir mejorando la claridad y la precisión de este contenido.

Gracias a todas las personas que habéis contribuido al contenido de este artículo. ¡Sois la caña! 😍 Y un agradecimiento especial a Rachael Ellen y Nico Loza.

En este artículo vas a descubrir qué son los datos geoespaciales y por qué, como desarrollador, trabajar con ellos no es lo mismo que con cualquier otro tipo de datos.

Si alguna vez haz intentando:

• Mostrar datos abiertos con coordenadas “extrañas”.
• Guardar formas geográficas complejas en una base de datos normal.
• Mostrar miles de puntos en un mapa interactivo.
• Saber cuáles de esos puntos caen dentro de un área concreta.
• Calcular distancias entre ubicaciones.

Entonces ya te habrás topado con los retos especiales de los datos geoespaciales.

Seguramente incluso acabaste escribiendo demasiado código para resolver esos problemas, o tuviste problemas de rendimiento por la complejidad de lidiar con este tipo de datasets.

Después de más de 10 años ayudando a desarrolladores a empezar con sistemas de información geográfica (SIG), me he dado cuenta de que la mayoría de las carreras de informática ni los bootcamps suelen enseñar nada de esto.

Por eso, la mayoría de los desarrolladores, por defecto, tratamos los datos de localización igual que cualquier otro dato… hasta que “nos la pegamos”: la lógica se vuelve un jaleo, no escala, o directamente no funciona.

En este artículo te voy a contar por qué trabajar con datos geoespaciales es mucho más que “datos con coordenadas” y por qué debería usar tecnologías especializadas como bases de datos espaciales, servidores, APIs y SDKs de mapas.

Tabla de contenidos

• Por qué los datos geoespaciales requieren otra mentalidad
• Cómo se estructuran los datos espaciales
  - Datos discretos vs continuos
  - Tipos de geometrías discretas
• Consultas y análisis
  - Relaciones espaciales (predicados)
  - Operaciones espaciales (transformaciones)
  - Mediciones espaciales
• Integridad de datos geoespaciales
• Estrategias de rendimiento
  - Indexación espacial
  - Simplificación y teselado
• Visualización y experiencia de usuario
  - Tecnologías de mapeo en el cliente
  - Herramientas de desarrollo y diseño cartográfico
• Interoperabilidad
  - Referencias espaciales
  - Formatos de datos geoespaciales
• APIs geoespaciales
• Conclusiones

Por qué los datos geoespaciales requieren otra mentalidad

Imagina esto: sigues trabajando con tablas (filas y columnas), pero en cada fila metes coordenadas que indican dónde está ese dato en el mundo. Puede ser un punto, una línea o un polígono que delimita una zona.

El truco está en que esos datos de localización no deberías guardarlos como un simple string o un float. Para manejarlos bien necesitas tipos de datos espaciales, porque las operaciones que querrás hacer (intersecciones, cálculos de áreas, buffers, etc.) no las soporta SQL tradicional ni los tipos de datos básicos de forma eficiente.

Cómo se estructuran los datos espaciales

Para trabajar bien con datos geoespaciales tienes que entender las distintas formas que pueden tener, porque cómo modeles la localización afecta a cómo los vas a guardar, consultar y usar.

Es como elegir la estructura de datos adecuada en programación: cada forma representa cosas distintas del mundo real y requiere su propia lógica interna.

Aquí hay dos distinciones fundamentales que hay que conocer.

Datos discretos vs continuos

No todos los datos espaciales se comportan igual. Algunos describen objetos discretos (a veces llamados geometrías o datos vectoriales), cosas con límites claros como tiendas, edificios, carreteras o parcelas. Son “objetos” del mundo espacial: existen en un lugar y tienen una forma que se puede describir con coordenadas.

Otros son continuos, como la elevación, la temperatura o el ruido ambiental, valores que cambian poco a poco en el espacio sin bordes claros. Son más bien “degradados”, y no se pueden modelar con una forma simple. Estos se guardan como datos ráster, en forma de cuadrículas, donde cada celda tiene un valor. Aquí no basta con puntos y polígonos: se necesitan otras herramientas para analizarlos y visualizarlos.

Antes de seguir, aclaremos tres conceptos que suelen confundirse:

• Objetos discretos: lo que modelas conceptualmente (ej: carreteras, parcelas, árboles, ríos, edificios).
• Geometrías: la forma de esos objetos, su representación matemática (punto, línea, polígono), definida por coordenadas que marcan su posición y límites.
• Datos vectoriales: la estructura usada en SIG para guardar y manejar esas geometrías (GeoJSON, shapefiles, servicios de entidades, teselas vectoriales).

Al hablar de la estructura de los datos espaciales, es importante diferenciar dos ideas estrechamente relacionadas pero distintas: el modelo de datos utilizado para representarlos (vector vs. ráster) y el tipo de fenómeno (discreto vs. continuo).

• Fenómenos discretos: tienen límites claros, como carreteras, parcelas o categorías como las clases de cobertura del suelo.
• Fenómenos continuos: varían de forma gradual en el espacio, como la elevación o la temperatura.

Cualquier tipo de fenómeno puede almacenarse como vector o como ráster. Por ejemplo, la cobertura del suelo es conceptualmente discreta, pero a menudo se representa como una cuadrícula ráster de clases, mientras que la elevación es continua, pero también puede expresarse como curvas de nivel vectoriales.

Entender la diferencia entre estas dos dimensiones ayuda a no caer en la idea equivocada de que “discreto = vector” y “continuo = ráster”.

👉 Aviso: en este artículo vamos a centrarnos en datasets vectoriales que representan objetos discretos. Aunque los datos ráster son igualmente importantes, plantean retos diferentes que exceden el alcance de esta introducción; por lo tanto, no los trataremos aquí.

Tipos de geometrías discretas

Los más comunes son:

• Puntos: un par de coordenadas (ej.: una cafetería, un buzón o localización de entrega).
• Líneas (o polilíneas): una secuencia de puntos formando un camino (ej.: una carretera, una ruta o un río).
• Polígonos: una forma cerrada que define un área (ej.: un parque o un código postal).

Pero hay más: multipuntos, líneas curvas, polígonos con agujeros o bordes curvos. Cuando nos pasamos al 3D también existen cosas como mallas o vóxeles, que representan volúmenes o estructuras en tres dimensiones.

Estas geometrías no son solo dibujitos: determinan cómo podrás consultarlas, intersectarlas o unirlas. Y afectan al rendimiento, la precisión y las estrategias de indexación. Por eso las bases de datos espaciales las tratan como tipos de datos nativos.

Consultas y análisis

Una vez que tus datos están localizados, se abre un mundo más allá de los filtros estándar o los joins por ID. Las bases de datos espaciales extienden SQL con operaciones que te permiten analizar cómo se relacionan las cosas en el espacio y mantener la integridad espacial.

Relaciones espaciales (predicados)

Son operaciones booleanas que evalúan la relación entre dos geometrías en el espacio. No producen nuevas geometrías, solo devuelven verdadero/falso o se utilizan en filtros/uniones.

Responden preguntas como: ¿estas dos geometrías se tocan? ¿Una contiene a la otra? ¿Se solapan?

Ejemplo: en lugar de unir tablas por ID, en una base espacial puedes hacer joins espaciales, uniendo datos por proximidad en lugar de por claves.

Aquí puedes comprobar visualmente el resultado de la operación de intersección entre diferentes tipos de geometrías:

¿Te interesa saber más sobre tipos de operaciones con geometrías?.

Operaciones espaciales (transformaciones)

Aquí ya no hablamos de true/false, sino de generar nuevas geometrías como resultado. Ejemplos:

• Buffer: crear un área alrededor de un punto o línea (ej: crea un área o perímetro de seguridad alrededor de la ubicación de un accidente).
• Uniones: combinar varias geometrías en una sola.
• Intersección: comprobar si algo cae dentro de una zona restringida.
• Áreas de servicio: calcular hasta dónde llegas en X minutos.

Otra operación muy potente es la teselación, que divide el espacio en formas regulares y no solapadas (cuadrados, hexágonos, triángulos) para analizar datos de forma uniforme.

Sirve tanto para análisis como para mejorar el rendimiento y la experiencia de usuario.

¿Te interesa saber más sobre análisis espacial, o cómo utilizar la teselación?

Mediciones espaciales

No todas las operaciones espaciales devuelven formas o respuestas de sí/no; a veces, lo que necesitas es un número, ya sea para calcular la distancia entre dos puntos, el área de un polígono o la longitud de una ruta.

Estas operaciones devuelven valores cuantitativos y son esenciales para ordenar resultados, mostrar estadísticas significativas o respaldar la lógica de clasificación y filtrado en tus aplicaciones.

Ejemplos:

• Cálculos de distancia: calcula la distancia más corta entre dos geometrías (por ejemplo, la distancia entre un usuario y la tienda o el punto de interés más cercano).
• Área y perímetro: mide el área superficial de un polígono (por ejemplo, el tamaño de una parcela).
• Longitud de línea: calcular la distancia total a lo largo de una ruta o camino.
• Mediciones geodésicas vs planas: muchas herramientas admiten cálculos tanto planos (tierra plana) como geodésicos (tierra curva), lo que puede afectar significativamente a la precisión en grandes distancias o cerca de los polos.

Integridad de datos geoespaciales

Antes de hacer cualquier análisis espacial importante, es vital asegurarse de que los datos sean precisos, ya que es muy fácil introducir errores espaciales. Entre los problemas más comunes se encuentran la superposición de polígonos, los huecos entre parcelas o los segmentos desconectados (carreteras, redes de tuberías…), todos los cuales pueden comprometer la validez del análisis.

Al igual que se definen NOT NULL, claves externas o restricciones en un esquema tradicional, los sistemas geoespaciales permiten definir reglas topológicas que garantizan la corrección espacial.

Por ejemplo:

• No se permiten superposiciones: útil para los límites de las parcelas de terreno.
• Debe estar dentro de otra forma: por ejemplo, los edificios deben estar dentro de las zonas de propiedad.
• Las líneas deben conectarse en los puntos finales para las redes de enrutamiento.

Estas reglas ayudan a mantener la calidad de los datos y a evitar errores lógicos en aplicaciones, mapas o análisis posteriores.

Estrategias de rendimiento

Ahora que hemos visto cómo se almacenan, consultan y analizan los datos espaciales, es hora de centrarnos en el siguiente reto: trabajar de forma eficiente con conjuntos de datos geoespaciales grandes y complejos.

A medida que aumenta el volumen y la complejidad de los datos espaciales, también lo hacen las exigencias de rendimiento, y resolverlas requiere algo más que un hardware más potente. Necesitamos aplicar técnicas y estrategias especializadas que tengan en cuenta la naturaleza única de las operaciones espaciales.

A continuación presento algunas de las técnicas clave, como la indexación espacial, la simplificación geométrica y el mosaicado, que hacen posible la creación de aplicaciones geoespaciales escalables y de alto rendimiento.

Indexación espacial

Algunos conjuntos de datos geoespaciales pueden contener fácilmente miles o millones de formas, desde pequeños conjuntos de objetos locales hasta otros que abarcan enormes áreas, como países, regiones intergubernamentales, zonas transoceánicas o incluso el mundo entero. Estas formas pueden incluir miles o hasta millones de vértices, lo que las hace complejas de procesar.

Para ejecutar consultas espaciales rápidas (por ejemplo, intersecciones, dentro), las bases de datos espaciales utilizan índices espaciales especializados como los Árboles-R (R-trees). Estos índices organizan las geometrías por recuadros que los delimitan, lo que permite al sistema filtrar rápidamente las áreas irrelevantes, de forma muy similar a como los índices de Árboles-B ayudan a acelerar las consultas de rango en las bases de datos tradicionales.

Sin la indexación espacial, incluso las consultas simples requerirían el escaneo de cada geometría, lo que rápidamente se vuelve inmanejable a gran escala.

¿Cómo funcionan los índices espaciales?

Los índices espaciales funcionan simplificando geometrías complejas en cuadros delimitadores (rectángulos que contienen completamente cada forma).

Echa un vistazo a la siguiente imagen, que ilustra cómo funcionan los índices espaciales:

En la imagen, cada elemento (A, B, C y D) está rodeado por una caja delimitadora, que es lo que almacena el índice espacial, no la geometría completa.

Si queremos saber qué formas se cruzan con el elemento A (el área alrededor del marcador), el índice espacial realiza un filtrado inicial rápido. Identifica todos los elementos cuyas cajas delimitadoras se cruzan con el cuadro delimitador de A. En este caso, B y D son posibles candidatos.

Este paso evita comprobar geometrías que son claramente irrelevantes (como C), lo que mejora significativamente el rendimiento.

A continuación, en una segunda fase, la base de datos realiza una comprobación geométrica precisa de las características candidatas (B y D) para verificar las intersecciones reales.

Este proceso de dos pasos: filtrado de la caja delimitadora seguido de una comparación geométrica exacta, es lo que hace que las consultas espaciales sean eficientes, especialmente cuando se trata de conjuntos de datos grandes y complejos.

Simplificación y teselado

Esto se trata de proporcionar datos con el nivel adecuado de detalle. Cuando se crea una aplicación de mapas, los usuarios pueden desplazarse y ampliar la imagen. El mismo conjunto de datos que se ve bien cuando te acercas puede resultar abrumador y difícil de renderizar de manera eficiente cuando te alejas.

Para mantener la velocidad, es necesario adaptar los datos de forma dinámica:

• Simplificar las geometrías: al igual que un responsive design se adapta al tamaño de la pantalla, los mapas deben adaptar los detalles a la escala. Esto se consigue reduciendo el número de vértices de una forma a medida que el usuario aleja el zoom, un proceso conocido como generalización.
• Divida los datos en mosaicos: los sistemas geoespaciales suelen dividir los datos en mosaicos, pequeños fragmentos que representan un área y un nivel de zoom específicos. Es como la carga diferida (lazy-loading) de recursos en una aplicación frontend: solo se carga lo que se necesita, cuando se necesita. La división en mosaicos permite renderizar conjuntos de datos masivos de forma progresiva, manteniendo bajo el uso de memoria, ahorrando ancho de banda y acelerando los tiempos de carga.
• Comprimir con codificación sensible a la topología: reducir el tamaño de los archivos codificando los límites compartidos por las geometrías una sola vez y almacenando las coordenadas como deltas de los puntos anteriores. Esto minimiza la redundancia de valores y garantiza la coherencia topológica entre formas adyacentes, lo que hace que los datos sean más pequeños y limpios al ser servidos.

Sin simplificación y mosaicado, el renderizado de grandes conjuntos de datos geoespaciales se convertiría rápidamente en un cuello de botella. Se vería obligado a cargar capas completas en la memoria, procesar geometrías excesivamente detalladas a todas las escalas y lidiar con un renderizado lento, un alto uso de ancho de banda e interfaces de usuario que se quedan colgadas.

Visualización y experiencia de usuario

Los mapas suelen ser la interfaz principal para interactuar con datos espaciales, y la forma en que se visualizan esos datos puede determinar el éxito o el fracaso de la experiencia del usuario. El diseño de mapas claros y eficaces depende de técnicas como la visibilidad basada en la escala, la simbolización adecuada y otras.

Tecnologías de mapeo en el cliente

Para trabajar eficazmente con datos espaciales y crear aplicaciones geoespaciales rápidas, interactivas y útiles, se necesitan herramientas de cartografía especializadas.

Estas herramientas deben estar optimizadas para:

• Generar visualizaciones ricas y basadas en datos: soportar datos continuos y discretos, con la capacidad de simbolizar geometrías 2D y 3D utilizando estilos dinámicos. Visualizar datos espaciales a través de mapas de calor, clústeres, gráficos circulares geolocalizados y mucho más. Proporcionar bibliotecas seleccionadas de símbolos cartográficos para casos de uso comunes (puntos de interés, transporte, límites, etc.) para que no sea necesario diseñar todo desde cero.
• Gestionar referencias espaciales y proyecciones: soportar la representación de mapas en varios sistemas de coordenadas y reproyectar datos sobre la marcha para garantizar la precisión espacial y la coherencia entre capas (más adelante trataremos las referencias espaciales con más detalle).
• Realizar análisis espaciales del lado del cliente: permitir operaciones en tiempo real, como cálculos de distancia, almacenamiento en búfer, uniones espaciales y procesamiento de geometría, directamente en el cliente.
• Garantizar el rendimiento a escala: gestionar grandes conjuntos de datos de forma eficiente a través del mosaicado, reconocer y saber interpretar las geometrías codificadas topológicamente y usar la aceleración por hardware a través de WebGL, WebGPU, Web Workers y otras mejoras de rendimiento.
• Proporcionar widgets de interfaz de usuario y herramientas de interacción: ofrecer componentes personalizables y listos para usar, como controles de zoom, barras de búsqueda, leyendas, herramientas de medición, herramientas para bocetar, pop-ups y mucho más, para acelerar el desarrollo de la interfaz de usuario.
• Ser interoperables y extendibles: que funcione sin problemas con los estándares geoespaciales más usados, como GeoJSON, WMS, WMTS, 3D Tiles o COG. Algunos de ellos definidos por el OGC, que viene a ser en el mundo geoespacial lo mismo que el W3C en la web. Además, debería dejarte añadir capas o renderizadores a tu medida y ampliar lo que hace, por ejemplo, con un sistema de plugins.

Sin las tecnologías de mapeo del lado del cliente, terminarías reinventando la rueda, creando manualmente optimizaciones de rendimiento, lógica de dibujo, comportamientos interactivos y componentes de interfaz de usuario que estas herramientas ya ofrecen.

Herramientas de desarrollo y diseño cartográfico

Crear buenas aplicaciones de mapas no es solo cuestión de código. Una buena experiencia de usuario no solo depende de los datos y la lógica, sino también de cómo se diseñan, etiquetan y presentan esos datos en diferentes escalas y contextos.

Una buena experiencia de desarrollo requiere herramientas que faciliten el diseño, el desarrollo, la prueba y el perfeccionamiento de estilos cartográficos sin tener que empezar desde cero.

Estas herramientas aceleran el desarrollo y mejoran la calidad del diseño al permitir:

• Exploración de datos: inspeccionar los datos espaciales visualmente para comprender las distribuciones, los valores atípicos o las lagunas (gaps), lo que le ayudará a tomar mejores decisiones de estilo y filtrado en las primeras fases del flujo de trabajo.
• Editores de estilo visual y creadores de mapas: experimentar rápidamente con diseños de mapas (símbolos, visibilidad de capas, etiquetas, ventanas emergentes y mucho más) utilizando interfaces gráficas de usuario interactivas que permitan previsualizar en tiempo real los cambios. Esto ahorra tiempo durante la iteración del diseño.
• Creadores de símbolos personalizados: crear símbolos visualmente (por ejemplo, marcadores avanzados) utilizando herramientas visuales.
• Importación/exportación de estilos: guardar y reutilizar estilos visuales en diferentes proyectos o entornos. Cargar estilos dinámicamente desde el SDK para reducir el código y garantizar un diseño de mapas coherente y consistente entre equipos y aplicaciones.

Un ejemplo de este tipo de herramienta de exploración de datos, creación de mapas e incluso análisis sería ArcGIS Map Viewer.

Un ejemplo de herramienta de diseño cartográfico es el Vector Tile Style Editor:

Sin herramientas de desarrollo y diseño cartográfico, cada cambio visual requeriría ediciones manuales del código, refrescos y comprobaciones manuales, y suposiciones usando el método de prueba y error. Se perdería un tiempo valioso ajustando estilos sin feedback visual, se tendrían dificultades para mantener la coherencia y consistencia entre los proyectos y se sobrecargaría a los desarrolladores con trabajo que los diseñadores podrían hacer de manera más eficiente mediante herramientas visuales.

Interoperabilidad

Al igual que con cualquier sistema de software, la interoperabilidad dentro de un sistema geoespacial también es importante. En esta sección se destaca la importancia de las referencias espaciales, los formatos de archivo y las especificaciones de APIs a la hora de integrar y trabajar entre sistemas.

Referencias espaciales

Desgraciadamente no existe una única forma universal de representar la ubicación. El sistema más conocido, utilizado por el GPS y expresado en latitud y longitud, se conoce como WGS84.

Sin embargo, muchos conjuntos de datos, especialmente los procedentes de portales de datos abiertos o de organismos gubernamentales, utilizan otros sistemas de referencia espacial, como UTM o Web Mercator, que expresan las posiciones de forma diferente (por ejemplo, en metros en lugar de grados).

Aunque las referencias espaciales garantizan la interoperabilidad, también desempeñan un papel crucial para garantizar la precisión. Al igual que mezclar codificaciones de texto (UTF-8 vs ISO-8859–1) puede provocar que los caracteres se muestren incorrectamente, mezclar datos espaciales con diferentes sistemas de coordenadas sin reproyección puede hacer que los elementos aparezcan en un lugar incorrecto o que no se muestren en absoluto.

La siguiente imagen ilustra cómo las mismas coordenadas expresadas en dos sistemas diferentes representan ubicaciones diferentes en la Tierra.

Si quieres saber más sobre este tema, puedes consultar “Spatial references” en la documentación para desarrolladores de ArcGIS.

Formatos de datos geoespaciales

Todos los formatos de archivos geoespaciales definen la referencia espacial de los datos (ya sea de forma explícita o implícita) junto con la geometría en sí. Formatos conocidos como GeoJSON, Esri JSON, TopoJSON, GeoPackage y Shapefile están diseñados para contener no solo coordenadas en crudo, sino también metadatos esenciales.

A diferencia de los archivos CSV simples, que pueden contener coordenadas pero carecen de contexto espacial, estos formatos incorporan información crítica, como referencias espaciales, esquemas de atributos y detalles de proyección, lo que garantiza que los datos se interpreten, diseñen e integren con precisión en diferentes sistemas.

APIs geoespaciales

Para facilitar el acceso y la interacción con estos datos a través de las APIs, existen especificaciones abiertas bien establecidas diseñadas explícitamente para contenido geoespacial. Entre ellas se incluyen estándares OGC como WMS, WFS y OGC API, así como la API REST de ArcGIS y STAC.

Estas API suelen exponer:

• Metadatos del servicio (por ejemplo, nombre, descripción, proveedor, licencia)
• Capas disponibles o colecciones de entidades (feature collections)
• Sistemas de referencia espacial compatibles.
• Formatos de salida compatibles.
• Y otras capacidades técnicas que facilitan la exploración, visualización o análisis de los datos en diferentes sistemas.

Para los desarrolladores, comprender las API geoespaciales es fundamental no solo para ahorrar tiempo de desarrollo (aprovechando las herramientas y los flujos de trabajo existentes en lugar de reinventarlos), sino también para crear soluciones interoperables que funcionen en diferentes plataformas. Al seguir especificaciones bien conocidas, estas API proporcionan un acceso coherente a los datos espaciales, lo que reduce la necesidad de análisis personalizados, conversiones manuales o correcciones de coordenadas.

Conclusiones

Como hemos visto, los datos geoespaciales no son solo “datos con coordenadas”. Trabajar con datos de ubicación presenta retos únicos que requieren nuevas herramientas y formas de pensar. Así que, si alguna vez has tenido dificultades con los datos de ubicación, ahora ya sabe por qué.

¿La buena noticia? Existe todo un ecosistema de herramientas creadas para ayudarle. Para abordarlas, puede adoptar las herramientas creadas específicamente para trabajar con datos geoespaciales, como bases de datos espaciales, servidores geoespaciales, SDK del lado del cliente y herramientas de diseño cartográfico especializadas, que te ahorrarán tiempo y dolores de cabeza.

¿El siguiente paso? Si quieres saber más, te animo a que consultes nuestras guías para desarrolladores de ArcGIS y el Interactive Learner GIS. Si te interesan más los servicios alojados en la nube, también he comenzado una serie de blogs que analizan en detalle los servicios alojados de ArcGIS (servicios de entidades, servicios de mosaicos vectoriales y servicios de mosaicos de mapas).

Y si has encontrado que te resulta confuso o crees que has detectado un error o una incoherencia en este artículo, me encantaría que me lo digas. Ponte en contacto con nosotros en developers@esri.com para que podamos garantizar que el contenido siga siendo claro, preciso y útil.

Si este artículo te ha resultado útil y crees que otras personas de tu red pueden beneficiarse de él, te agradeceríamos mucho que lo compartieras o interactuaras con la publicación en LinkedIn, Bluesky o X.

Nos reunimos unas 1000 personas, 80 ponentes, para hablar de:

• Desarrollo (ej. lenguajes de programación, BDs, desarrollo web, apps móviles)
• Diseño de experiencia de usuario (ej. diseño UX/UI, accesibilidad)
• Prácticas de desarrollo (ej. metodologías Agile y Lean, prácticas DevOps)
• Inteligencia artificial y ciencia de datos (ej. aprendizaje automático, LLMs, ciencia de datos)
• Infraestructura (ej. computación en la nube, IoT)
• Seguridad y protección de la información (ej. ciberseguridad, privacidad)
• Y mucho más (ej. power skills, blockchain, etc.).

Como no podía ser de otra forma… me encantó este año el SWAG, ¡¡el diseño era UN MAPA hecho con el diseño de las contribuciones (“Commits” en GitHub)! (¡qué grandes! 😍):

Captura de la actividad (contribuciones) en GitHub.

Un año más, participamos decenas de comunidades tecnológicas tanto en la difusión del evento como en la selección de charlas; por nuestra parte a través de la comunidad de Geo Developers.

En este artículo quería hablaros de tres cosas principalmente:

• De nuestra charla sobre APIs de mapas.
• Del reencuentro con las comunidades.
• Y de lo que aprendí de las charlas, y las conversaciones de pasillo.

El código del billón de dólares 🤑​

Titulamos la charla como la mini serie de Netflix (que además usamos como hilo conductor), y aunque los títulos de mis charlas suelen ser más descriptivos, parece que logró el efecto llamada esperado, superando mis expectativas de asistencia y parece ser que también las de la organización, porque la sala se llenó.

Juanma y yo contamos unas 70 personas:

Como se puede leer en el abstract, en esta charla nos centramos en los retos técnicos y las complejidades de implementar servicios de mapas a escala mundial.

Nuestros objetivos eran:

• Despertar el interés por este ámbito: Enseñar cosas generalmente desconocidas pero interesantes sobre estos servicios.
• Transmitir la complejidad técnica: Mostrar lo complejas que son estas tecnologías y el nivel de ingeniería y arquitectura (de software y de datos) que requieren.
• Poner en valor el esfuerzo continuo: Destacar el trabajo constante de mantenimiento, mejora e innovación que hay detrás de estas APIs… y dejar entrever lo que aún está por venir.
• Ayudar a tomar mejores decisiones técnicas: Dar visibilidad a la variedad de proveedores existentes y mejorar las habilidades para elegir la tecnología de mapas más adecuada en futuros proyectos.

La verdad es que no suelo tener co-speaker, pero visto la experiencia, creo que debería hacerlo más.

Esta vez me apetecía que fuésemos Juanma y yo. No solo por la buena relación que tenemos desde hace años, sino porque trabajamos en dos de las empresas con más trayectoria del sector (más de 100 años de experiencia acumuladas). Además, nos complementamos muy bien: entre los dos cubrimos los retos tanto a nivel de software como de datos, no solo para crear, sino sobre todo para mantener actualizados este tipo de servicios.

El feedback recibido tanto a través de la plataforma como luego en los pasillos fue muy bueno. En resumen:

Lo que funcionó bien:

• El contenido gustó mucho y sorprendió a más de un@.
• Varias personas nos comentaron que nunca se habían parado a pensar en la complejidad técnica detrás de este tipo de servicios.
• Se valoraron especialmente los ejemplos visuales, que ayudaron a entender mejor los conceptos y retos.

Cosas a mejorar:

• Tener más en cuenta el horario (era la última del día) y adaptar el ritmo y la profundidad del contenido de manera acorde.
• Considerar dividir la charla en varias sesiones, para tratar los temas con más calma y detalle.

Varias personas nos avisaron antes de empezar que al ser la última charla del día, estaban algo agostadas. Aun así, la respuesta fue muy buena (recibimos un 4.5 de 5), a pesar del ritmo tan rápido que tuvo la charla (unos 33 segundos de media por transparencia 😅).

Las presentación la tenéis aquí:

Y la grabación en el canal de Commit Conf en YouTube:

Reencuentro con las comunidades​

Otra de las razones por las que me encanta Commit, es porque allí nos reencontramos muchas personas que dinamizamos comunidades.

Además, la organización lleva tres años consecutivos aceptando nuestra propuestas de Open Spaces, donde siempre conozco a nuevas personas y aprendo de sus experiencias.

Nota: Si no lo sabías, la “metacomunidad” de comunidades tech que creamos el año pasado (Community Builders), nació precisamente con la idea de dar continuidad a las conversaciones que surgen en encuentros como este. 😍

Por si os interesa, grabamos el audio del open space, y compartimos aquí los materiales y apuntes.

Durante el cierre, la organización me invitó a reunir a las comunidades que estábamos presentes, y a subirnos al escenario para presentar a las diferentes comunidades, donde pude presentar brevemente qué es Community Builders.

Y para rematar, tuvimos una cena post-conferencia en Casa Mingo, donde Álvaro y yo conseguimos reunir a unas 20 personas implicadas en la dinamización de comunidades (incluidas algunas que no habían podido venir a la conferencia). Una forma perfecta de cerrar la conferencia.

Sin duda, estas actividades permiten conectar a un nivel humano que cuesta mucho más lograr en remoto. Se crean lazos, se refuerzan relaciones, y se vive una cercanía que difícilmente se puede replicar por videollamada.

Lecciones aprendidas sobre IA​

Sin desmerecer al resto (hubo charlas muy interesantes, muchas ya disponibles en YouTube), la gran protagonista de este año fue la IA. De las 70 sesiones, 17 estaban centradas en este tema, así que casi en cualquier momento podías encontrar alguna sobre Machine Learning o LLMs.

Así empiezo con un resumen de los diferentes temas, y del interés que percibí:

• Integración práctica de IA en aplicaciones reales. Vi gran interés por entender cómo incorporar IA en apps existentes usando modelos (comerciales u open source) y sin cambiar de stack.
• Desarrollo de agentes de IA autónomos. También mucha interés por saber cómo crear agentes capaces de actuar y aprender solos.
• Seguridad y auditoría en modelos generativos (LLMs). Percibí una creciente preocupación por los riesgos de la IA generativa:: desde ejecutar código generado por modelos sin saber qué hace realmente, hasta posibles vulnerabilidades introducidas sin querer. También hay mucho interés en cómo protegerse y en conocer herramientas que permitan auditar y controlar estos riesgos.
• Observabilidad y rendimiento (en producción). También vi un aumento del interés por entender qué pasa con los LLMs en tiempo real, y usar herramientas para obtener métricas, logs y trazas para mejorar estabilidad y rendimiento.
• Avances en arquitecturas RAG (RAG 2.0). Curiosidad por nuevas variantes que mejoran la recuperación contextual.
• IA en dispositivos móviles. Interés moderado por ejecutar IA directamente en dispositivos móviles sin depender de la nube.
• Aplicaciones de IA en contextos reales. Aunque con menor tirón general, hay cierto interés en conocer sobre casos de uso de la IA en contextos reales.

Pero también tuve conversaciones en los pasillos sobre el tema, y quería compartir algunas de las cosas que hablamos:

• La IA está sustituyendo el uso tradicional de plataformas como Stack Overflow, Reddit y Google Search, ya que los desarrolladores consideran que los LLM y herramientas como GitHub Copilot, Cursor.ai, Windsurf, … pueden ser soluciones más rápidas, personalizadas y eficientes.
• Reflexión mía: ¿cómo va a afectar esto a los canales educativos tradicionales?
• Creo que el Vibe coding está generalmente bien visto, siempre y cuando sea para hacer pequeñas utilidades, side-projects, o herramientas de “bajo riesgo” o mantenimiento (ej: un cliente de comandos para conectar con una API), etc.
• Cada vez más personas, (incluídas seniors) utilizan la programación asistida por IA; a veces para buscar inspiración o buscar soluciones alternativas, eso sí, siempre revisando el código generado.
• También hay personas que señalan lo fácil y tentador que es usarlo con tecnologías con las que no se está familiarizado. El problema que en esos casos es difícil identificar los errores y las malas prácticas al revisar.
• Jon Vila me contó una conversación interesante sobre un tema delicado: el riesgo de empoderar a perfiles menos técnicos, como product managers, que empiezan a usar herramientas de IA para generar código y, en algunos casos, pueden terminar cuestionando las estimaciones de los equipos de desarrollo.
• La IA ya se cuela en todas las fases del desarrollo: desde escribir tests y documentar código, hasta crear datos de prueba o dejar que un modelo haga un pull request por nosotros.

En general hay mucho interés por conocer herramientas tipo:

• IDEs potenciados por IA: Cursor, Windsurf, …
• Asistentes de codificación y autocompletado: GitHub Copilot, Cody, …
• Frameworks y orquestadores de agentes/LLMs: como LangChain
• APIs y LLMs: GPT-4, Claude 3, LLaMA 2, …
• Automatización de flujos de trabajo: n8n, Langflow, …
• Generadores de componentes y UI: Vercel V0, Lovable, …
• etc.

Conclusiones​

Mientras pueda, yo seguiré asistiendo a Commit, porque para mi es de esos eventos donde aprendes, conectas, y te vas con el subidón de comunidad en vena. Y aunque es super intenso, es un evento donde:

• Se aprende mucho (en charlas y pasillos).
• Se conecta con personas nuevas.
• Se reconecta con personas conocidas.
• Y un lugar de encuentro con muchas comunidades tech.

Gracias gracias y mil gracias a Laura, Abraham, Nacho, Kini, y a las decenas de personas voluntarias y empresas patrocinadoras que hicieron posible un año más este evento.

Si te has quedado con ganas de más, te dejo el enlace al artículo que escribí el año pasado: Why Attend Developer Conferences

Si quieres saber cuáles son los beneficios de asistir a conferencias como CommitConf y por qué deberías considerar enviar una propuesta de charla, taller u Open Space, ¡sigue leyendo! 😄

Hace poco tuve la suerte de asistir a CommitConf, uno de los mayores eventos para desarrolladores que se celebra anualmente en España. Además de la gran asistencia, cuenta con la participación de unas 50 comunidades técnicas españolas.

¿Por qué asistir a eventos como CommitConf?

En las conferencias, los desarrolladores sirven normalmente para reciclarnos, descubrir y compartir nuevas perspectivas y conocimientos con otros compañeros de profesión. Por ejemplo:

• Nuevas herramientas y lenguajes de programación.
• Nuevas funcionalidades de las herramientas y lenguajes que ya utilizamos.
• Cómo otras empresas resuelven distintos retos del desarrollo.
• Buenas prácticas en accesibilidad, seguridad y patrones de diseño.
• Tendencias.

Además, las conferencias también sirven para conocer gente nueva y reencontrarse con gente conocida. En mi caso, en Commit, me topé con algunos de mis antiguos compañeros de trabajo, y algunos desarrolladores que usan ArcGIS para crear Location-Aware apps o aplicaciones con mapas 🗺️📍😄.

¿Qué hace especial a esta conferencia?

Este evento, como muchos otros, nos da quienes nos dedicamos al mundo de la tecnología, la oportunidad de presentar charlas, talleres y en ocasiones… Open Spaces.

En mi opinión, un factor importante que diferencia este evento de otros, es el sistema utilizado para crear la agenda del evento, desde donde invitan a las propias comunidades a participar en el proceso de selección de las charlas.

💡 Si os interesa, la tecnología que usan se llama Koliseo, y es de uso gratuito para cualquiera 😉.

¿Por qué presentar una propuesta?

Asistir a un evento como CommitConf es una oportunidad para aprender, pero también de contribuir.

Las motivaciones de cada persona para presentar una propuesta son muy variadas.

• Hay personas que simplemente disfrutan compartiendo conocimientos y experiencias.
• Otros asistentes quieren aumentar la visibilidad de su empresa y dar a conocer el gran trabajo que hacen, con la esperanza de atraer talento a la empresa.
• Algunos asistentes quieren crear una marca personal.
• Mientras que otros desean debatir y encontrar soluciones a un problema con otras personas de la profesión.

Y si tienes la suerte de que te acepten una propuesta, como en mi caso, además puedes asistir a la cena de ponentes el día antes del evento, donde conocerás a un montón de expertos en diferentes temas 😍.

¿Qué aportamos desde Esri a la conferencia?

Desde la empresa para la que trabajo (Esri), siempre me ha animado a asistir a conferencias y a enviar propuestas que creyese que podían ser relevantes para otros desarrolladores.

Esta vez presenté varias propuestas:

• DataViz & Map Optimization.
• Designing Beautiful and Intelligent Maps.
• Using and Creating Collections in Postman Like a Pro.
• 🔑🔒 OAuth, OpenID Connect and JWT for Dummies.

Tuve suerte de que la comunidad y la organización de la conferencia aceptaran “🔑🔒 OAuth, OpenID Connect, and JWT for Dummies”, lo que me dio la oportunidad de compartir qué son estos estándares y cómo funcionan. Mostré ejemplos prácticos basados en algunos de los recursos que hemos creado desde el equipo de Developer Experience de Esri, como el workspace de Autenticación en Postman.

Si quieres, puedes consultar las diapositivas aquí. El vídeo de la charla lo compartiré en cuanto la organización lo haga público.

¿Qué aprendí en la conferencia?

A continuación os dejo algunas de las conclusiones de las sesiones a las que asistí:

• Comunidades locales fuera de las grandes ciudades (Open Space): Esta sesión fue super interesante. Tuve la oportunidad de compartir consejos e ideas para superar retos en la creación y mantenimiento de comunidades de desarrolladores con aproximadamente otras treinta personas. Entre ellos había representantes de diferentes comunidades sobre Python, Software Crafting, Datos, Machine Learning, comunidades de generalistas, Software Libre, GNU/Linux, DevOps, Drupal, y yo representando a la comunidad GeoDevelopers.

Nota: Tras la sesión, me he decidido a crear una guía con lo que aprendí durante la sesión y lo aprendido en base a mi propia experiencia. Si te interesa, guarda el artículo en favoritos porque lo añadiré [aquí] en unas semanas.

• Detectando problemas de Web Performance con Chrome DevTools: @nucliweb dio una visión general de las Chrome DevTools y nos mostró cómo siguen añadiendo nuevas herramientas como Recorder y Coverage para ayudar a evaluar tu rendimiento web y optimizarlo. Además, nos mostró cómo el nuevo formato de imagen AVIF mejora el rendimiento de WebP. Más información en web.dev.
• No me chilles que no te veo: el mágico equilibrio entre el Product Manager y el Engineering Manager. @javierabadia y @jameshedaweng nos explicaron cómo dividir las responsabilidades entre estos dos roles para evitar el fracaso a la hora de crear un producto. En resumen, un PM debe ser responsable de qué características añadir y por qué, y el EM en el cómo y el quién. El cuándo debe ser una responsabilidad compartida.
• Why I decided to pursue the Developer Relations path: @kinisoftware nos contó su experiencia como Staff Developer Relations Engineer, donde trabaja para promover la experiencia del equipo técnico de Criteo facilitando entre otras cosas la participación en eventos y comunidades.
• Testeando Accesibilidad Web: @bolonio nos mostró multitud de herramientas y recursos para probar la accesibilidad web: axe-core, eslint-plugin-jsx-a11y, jest-axe, axe-core/cli, pa11y, pa11y-ci, axe chrome extension, arc toolkit, accessibilityinsights.io, wave.webaim.org, y más.
• El error de hacerte manager: @npatarino nos explicó que convertirse en gestor de personas no es la única forma de tener liderazgo o aumentar tu salario. Dijo que para aquellos ingenieros de software sénior que quieran seguir creciendo, existen otros puestos como Staff Software Engineer, Principal Software Engineer, Distinguished Software Engineer y Technical Fellow.
• Pasado, presente y futuro de EducaMadrid: @asanzdiego nos habló de la plataforma educativa de la Comunidad de Madrid que dirige; nos contó los retos técnicos que sufrieron durante la pandemia, cuando el número de usuarios activos creció exponencialmente, junto con las fortalezas y limitaciones de su equipo y su stack tecnológico basado en software libre.

En resumen, si no eres de ir a conferencias de desarrolladores, espero que mi experiencia te haya animado y dado argumentos para asistir en el futuro. Te diría que también al Developer Summit de Esri en USA (o al Europeo), aunque esto más bien aplica si eres partner o cliente de Esri 😉.

Recuerda, aunque gran parte del contenido de estas conferencias luego se hace disponible online, hay otras muchas cosas que solo se pueden lograr asistiendo.

We hope you are as excited as we are. Palm Springs is a very welcoming and enjoyable city. Best of all… it’s going to be full of developers like you! 😄

Before the event

📱 Install and take some time to try the Esri Events app ( iOS | Android), which includes many useful features. You can save the talks you plan to attend and add session reminders. You will always have your agenda handy!

🗓️ Plan the sessions you want to attend. Prioritize the ones you think apply to you the most.

📶 Check your telecom provider rates. International travelers might not have internet access, so be sure to plan accordingly.

☀️ Bring sunscreen and sunglasses for lunch! 😎 Palm Springs is normally very sunny and warm; however, it’s also a good idea to bring a pullover for inside the convention center, which tends to be cool.

#️⃣ Join the conversation with other attendees and Esri staff. We are using the #DevSummit hashtag.

🗺️ Check the convention center indoor map

During the event

🛏️ Wake up early on plenary days. Front row seats, and those with a table, fill up quickly.

📝 Take notes. You will hear a lot of ideas during a session. You may also have some unanswered questions, or will want to jot down contact details and URLs. You can use the mobile app to take notes about sessions, speakers, exhibitors, and sponsors, which you can export afterward.

🙋‍♀️ Ask questions and share experiences! Seriously. Don’t be shy. Take the opportunity to ask any questions you may have. Developers and Esri staff are willing to help you.

👨‍💻 Schedule a 30-minute code review. Consider having a one-on-one meeting with Esri staff to discuss the current state of your app, get practical ideas, etc.

👥 Attend “Meet the Teams”. Maybe you couldn’t get all your answers after your talks, or just want to meet the engineers behind our technologies. On Tuesday, March 8th, at 6:30 PM you will have two hours to spend with Esri’s development teams (drinks and food will be provided).

🏃 Meet other developers. There are many awesome developers like you attending, including some of the most active contributors to the Esri Community. A great place to start is SpeedGeeking on Tuesday, March 8 th, from 4:00–5:30 PM. You will hear awesome 5-minute lightning talks from developers and Esri staff!

🤔 Make use of the showcase area. It is one of the best places to share experiences and ask questions to Esri staff in a relaxed environment.

💬 Don’t miss out on unique moments. Many sessions will be recorded. So, on occasion, it may be worthwhile to continue a conversation 😉.

Post-event

🙏 Rate the session and give us feedback. Sometimes you won’t have time during the event. But, please, when you can (during downtime, on the return trip…), fill out the forms located in the mobile app and tell us how we can improve.

🧹 Process, clean up your notes and follow up. Digest your notes and define the things you need to do next.

Meet the Developer Experience team

Last but not least, some of us from the Developer Experience team will be in the ArcGIS Platform booth at the Showcase Area. We are excited to meet you! Our team is in charge of the developer.arcgis.com website, building developer tools, creating educational resources, and more. We are committed to providing the best developer experience possible. We would love to hear from you about:

• 😩 The challenges you face while developing, finding resources, etc.
• 🎓 Your experience and ideas on what we can do better.
• 🎁 The solutions you are working on.

We also have some ideas about which we would like to hear your feedback. If you want to contact us, our contact details are below.

If you would like to see more photos, here you can see the ones from the Esri DevSummit 2017: Party (Thursday night), Plenary & Keynote.

Originally published at https://www.esri.com.

Next Wednesday, April 13th, a few members of the ArcGIS API for JavaScript team will be getting together to discuss some of the exciting new features in the 4.23 release. The best part is — you get to be a part of it! Join the Livestream at 9am PDT next Wednesday to hear all about the latest and greatest in the API — directly from some of the engineers. We can’t wait to see you there!

Planning on attending? Share it with your network!

Want to stay up to date on the latest ArcGIS Developer technology? Subscribe to our YouTube channel!