DEV Community: Raul Jimenez Ortega

ArcGIS Hosted Services Explained: Feature, Vector & Map Tiles Services

Raul Jimenez Ortega — Wed, 03 Sep 2025 16:08:50 +0000

You can also find a Spanish translation of this article: leer en español

What exactly is an ArcGIS feature service, and why is it considered so special? What are the differences between feature services and vector tile services? How can I optimize performance and cost by combining these services? How do I automate their creation and maintenance?

If any of these questions resonate with you, then this blog series is for you, we’ll explore all of these topics and more.

It is designed to help developers, solution architects, data engineers, and other technical decision-makers understand the differences between these widely used ArcGIS-hosted data services (available through a consumption-based model) and how each is specially optimized for different use cases:

Hosted map tile services: for large amounts of static geospatial data.
Hosted vector tile services: for large geospatial data that doesn’t change frequently, supporting customization and basic interaction.
Hosted feature services: for large, highly interactive, and editable data that needs to change efficiently.

⚠️ Important note: If you’re new to working with geospatial data, I highly recommend you read “What’s special about geospatial data?” before diving into this series. It will help you better understand the value these services provide.

⊕ Other ArcGIS data services

Keep in mind that in addition to the three services covered in this series, there are additional popular data services within the ArcGIS system optimized for other purposes, such as imagery (hosted image services and image services), 3D services (including 3D scenes, 3D tiles, etc.), real-time datasets (stream services), and others to work with big data, and more.

Content focus

This serie focus specifically on these three cloud-hosted services managed by Esri, which are available as Software as a Service (SaaS) and Platform as a Service (PaaS) through ArcGIS Online and ArcGIS Location Platform.

While these services are also available in self-managed environments via ArcGIS Enterprise, we won’t cover them here to keep the focus clearer, as they involve a different set of considerations.

We will also not include code samples and very few implementation steps; however, we’ll link to relevant resources from the Portal and data services guide, as well as other documentation pages when needed.

Why learn about ArcGIS hosted data services?

Sometimes you need to scale your infrastructure and reduce operational overhead. Using managed services lets you offload many technical complexities. Having cloud-hosted services to store, query, and update spatial data efficiently allows you to focus on the things that matter the most, delivering real value to the end user.

This is where ArcGIS hosted data services come in. They are the result of decades of experience supporting hundreds of thousands of organizations in the geospatial field. They can seamlessly complement your existing infrastructure, reducing your workload and making your life easier.

They also offer interoperability benefits, as they can also be exposed using open standards like OGC APIs, de facto standards like tiled web maps (also known as XYZ tiles*), MVT, and widely adopted plain-text formats like GeoJSON, making them easily accessible from both Esri and third-party clients*.

Throughout the series, you’ll also see comparisons with other technologies you may already be familiar with, to help you understand where they overlap, how they differ, and in which aspects the ArcGIS services stand out.

Why are we writing this series?

You might be wondering why we decided to write this series of articles when official documentation for these services already exists. I’m glad you asked! 😁.

The main reasons are:

Some low-level technical details aren’t covered in the official docs. While not required to use the services, they help you understand the differences between them and choose the best fit for your needs.
There are some advanced workflows and tools for highly automated use cases that aren’t widely known.
Technical and business documentation are not always closely connected, making it more challenging to make decisions that involve both perspectives.

That’s why we created this series: to provide you with a focused resource you can use, to help you:

Evaluate *which service is best suited for each dataset and workflow.
*
Reduce the learning curve, speed up the integration process, and reduce the maintenance work you will have to do
Learn how to enhance the end-user experience of your applications.
Reduce the associated costs.

That said, it’s also important to keep in mind that both the technology and the business model evolve rapidly, which means some details mentioned in the articles may become outdated over time. For this reason, each article includes references to the official documentation, where the most up-to-date information can be found.

In case of any discrepancy, the official documentation takes precedence over all other content.

By the end of this series, you’ll be able to clearly distinguish the capabilities, use cases, and trade-offs between these services. And you will be able to fully understand the following diagram that illustrates some of these differences:

In addition, your team will know which option is the most suitable for hosting each dataset based on your specific needs and preferences, as well as how to combine them within your applications.

Next steps

As mentioned at the beginning, this blog series is designed for different types of roles involved in using these services. The following table summarizes what each post will cover, who it’s intended for, and what you can expect to gain from reading it:

Article title	Who it’s intended for	What you’ll gain from reading it
Use case for each type of data service	Product managers, product owners, and solution architects.	Develop a clear mental model of what each service is best suited for (before diving into details).
Creation and maintenance differences	Data engineers, developers, solution architects, and technical product managers.	Understand the advantages and limitations of each service, and some low-level implementation details, so you can pick the right one and plan for long-term maintainability.
Management tools differences	Backend developers, data engineers, solution architects, and DevOps specialists.	Learn how to manage the full lifecycle of data services (from setup to automation) using the right tools for each task, and streamline operations by reducing manual work.
Behind the scenes and SDK trade-offs	Client-side application developers working in both web and native SDKs.	Learn what impacts client-side performance across services, along with the strengths, limitations, and optimizations of each SDK.
Visualization and interactivity differences	Client-side developers, UX/UI designers, technical leads, solution architects, technical product managers, and performance specialists.	Discover how to get the most out of these services to create the most user-friendly and powerful user interfaces possible.
Terms of use & pricing differences	Product managers, CTOs, and other decision makers.	Clarify when to use ArcGIS Online vs ArcGIS Location Platform based on pricing, quotas, and terms, so you can pick what works best for your needs.
Understanding Service Usage	FinOps, product managers, DevOps, and solution architects.	Connect usage patterns with actual costs to better prepare for forecasting expenses, planning budgets, and optimizing service configurations.

I hope this introduction has sparked your interest and left you eager to read the upcoming articles.

You’ve got several options to stay in the loop.

Follow me here on here (at dev.to)
Subscribing to the ArcGIS Blog RSS feed using your favorite reader.
Follow me on social media (LinkedIn, Bluesky, or X). - Follow me on Medium.com (for the Spanish versions).

If anything was unclear, or if you think you’ve spotted an error or inconsistency in this article, I’d love to hear from you. You can write to me at developers@esri.com to help improve the clarity and accuracy of this content.

Thank you to everyone who contributed to the content of this article. You rock! Extra special thanks to Rachael Ellen and Nico Loza.

What’s special about geospatial data?

Raul Jimenez Ortega — Wed, 27 Aug 2025 08:34:49 +0000

Note: Spanish translation of this article: leer en español | Last updated: 09/01/25

In this article, you will learn about geospatial data for developers.

If you have ever tried to:

Display an open dataset with "strange" coordinates.
Store complex geographical shapes in a regular database.
Display thousands of locations on an interactive map.
Figure out which ones fall inside a specific area.
Calculate distances between them.

You’ve already bumped into the unique challenges of working with geospatial data.

You maybe even ended up writing too much code to account for these challenges, or found your app slowing down due to the complexity in dealing with these complex datasets.

From my 10+ years of experience helping developers get started with geographic information systems (GIS), I’ve come to realize that most computer science degrees and coding bootcamps don’t cover this topic at all.

As a result, many developers try to handle location data using the same tools and mindset they would use for any other kind of data, until they find limitations, the logic becomes painfully complex, or things stop scaling.

In this article, I’ll explain why working with geospatial data involves much more than just “data with coordinates,” and why specialized technologies (such as spatial databases, geospatial servers, APIs, and mapping SDKs) are essential to your work.

Table of contents:

Why geospatial data needs a different mindset
How spatial data is structured
- Discrete vs continuous data
- Discrete geometry types
Querying and analyzing
- Spatial relationships (predicates)
- Spatial operations (transformations)
- Spatial measurements
Geospatial data integrity
Performance strategies
- Spatial indexing
- Simplification and tiling
Visualization and User Experience
- Client-side mapping technologies
- Development and cartographic design tools
Interoperability
- Spatial references
- Geospatial data formats
Geospatial APIs
Takeaways

Why geospatial data needs a different mindset

Think of it like this: most of the time, you’re still working with tables (rows and columns), but each row includes one or more coordinates that define where in the world that data lives. Sometimes it’s a single point, other times, it’s a line or polygon that outlines a route or a region.

And here’s the catch: this location data shouldn’t just be stored as a regular field like a string or a float. It requires specialized spatial field types, because you’ll want to do operations that standard data types or SQL queries cannot handle efficiently.

How spatial data is structured

To work effectively with geospatial data, you need to understand the various shapes it can take, because how you model location affects how you store, query, and use it.

In many ways, it’s like choosing the right data structure for a problem: different shapes represent different kinds of real-world things and require different logic under the hood.

Here are two fundamental distinctions to know.

Discrete vs continuous data

Not all location data works the same way. Some datasets describe discrete objects (also known as geometries or vector data), things with clear boundaries, such as store locations, building footprints, roads, or property lines. You can think of these as the “objects” in the spatial world: they exist in one place and have a shape that has a well-defined boundary that can be represented with a JSON.

Other datasets are continuous, like elevation, temperature, or noise levels, values that vary across space without distinct edges. These are more like gradients, and you can’t model them with a simple shape. Instead, they’re typically stored as raster data, grids of values where each cell represents a measurement at a specific location, and require different tools for analysis and visualization.

Before we move on, let me clarify the difference between discrete objects, geometries, and vector data. While related, they are not the same:

Discrete objects: what you’re modeling conceptually (e.g., roads, parcels, trees, rivers, buildings).
Geometries: the shape of those objects, their technical/mathematical representation (point, line, polygon), defined by coordinates that describe their position and boundaries in space.
Vector data: the data structure used to store and manage them in GIS (e.g., GeoJSON, shapefiles, feature services, or vector tiles).

When discussing the structure of spatial data, it’s important to separate two closely related but distinct ideas: the data model used to represent it (vector vs. raster) and the type of phenomenon (discrete vs. continuous).

Discrete phenomena have clear boundaries, such as roads, parcels, or categories like land cover classes.
Continuous phenomena vary gradually across space, like elevation or temperature.

Either phenomenon type can be stored as a vector or a raster. For instance, land cover is conceptually discrete but often represented as a raster grid of classes, while elevation is continuous but can also be expressed as vector contour lines.

Keeping these two dimensions separate helps avoid the common misconception that “discrete = vector” and “continuous = raster.

⚠️ Disclaimer: To keep things simple, the rest of this article will primarily cover how vector datasets representing discrete objects should be managed. While raster datasets are equally important in geospatial work, they present different challenges that are beyond the scope of this introduction; therefore, we will not cover them here.

Discrete geometry types

The most common geometries to represent discrete datasets are:

Points: A single pair of coordinates (like a coffee shop or delivery drop-off).
Lines (also known as polylines): A sequence of points forming a path (like a walking route or a river).
Polygons: A closed shape that defines an area (like a park or postal code).

However, there are also more complex geometry types, such as multipoints, curved lines, and polygons with curved edges or holes. In 3D contexts, you may also work with 3D objects, such as meshes or voxels, which represent surfaces, volumes, or real-world structures in three dimensions.

These aren’t just visual elements; they define how you’ll query, intersect, or join spatial data. And they also affect performance, precision, and indexing strategies, which is why they’re treated as native field types in spatial databases.

Querying and analyzing

Once your data includes location, you can go far beyond standard filtering or joins. Spatial databases extend SQL with operations that let you analyze how things relate in space and provide mechanisms to enforce spatial integrity.

Let’s explore some of these capabilities.

Spatial relationships (predicates)

These are Boolean operations that evaluate the relationship between two geometries in space. They don’t produce new geometries; they just return true/false or are used in filters/joins.

For example, in a traditional database, you might join tables by ID or name. However, in a spatial database, you can join rows based on their location (spatial joins), allowing you to join data by spatial proximity rather than keys.

Example of the intersect operation between different geometry types:

Find more at: Types of geometry operations.

Spatial operations (transformations)

These generate new geometries as output, often used in analysis or visualization workflows:

Examples include:

Buffering: for proximity searches (creating areas around coordinates or shapes).
Unions: combine several geometries.
Intersection: is a property within a restricted zone?
Service areas: find reachable zones in X minutes.

Another powerful spatial operation is tessellation, which means dividing space into regular, non-overlapping shapes that cover an area completely (commonly squares, hexagons, or triangles).

Tessellations are widely used in spatial analysis to standardize how data is aggregated and compared across regions. Beyond analysis, tessellation also plays a key role in user experience and performance.

Learn more about spatial analysis and how to use tesselation.

Spatial measurements

Not all spatial operations return shapes or yes/no answers; sometimes, what you need is a number, whether you’re calculating the distance between two points, the area of a polygon, or the length of a path.

These operations return quantitative values and are essential for sorting results, displaying meaningful stats, or supporting ranking and filtering logic in your apps.

Some use cases include:

Distance calculations: Compute the shortest distance between two geometries (e.g., how far a user is from the nearest store or point of interest).
Area and perimeter: Measure the surface area of a polygon (e.g., parcel size).
Line length: Calculate the total distance along a route or path.
Geodesic vs planar measurements: Many tools support both planar (flat-earth) and geodesic (earth-curved) calculations, which can significantly affect accuracy over large distances or near the poles.

Geospatial data integrity

Before performing any meaningful spatial analysis, it’s essential to ensure that the data is accurate, as spatial errors are easy to introduce. Common issues include overlapping polygons, gaps between parcels, or disconnected road segments, all of which can compromise the validity of your analysis.

Just as you define NOT NULL, foreign keys, or uniqueness constraints in a traditional schema, geospatial systems enable you to define topology rules that enforce spatial correctness.

For example:

No overlaps allowed: useful for land parcel boundaries.
Must be within another shape: e.g., buildings must be inside property zones.
Lines must connect at endpoints for routing networks.

These rules help maintain data quality and prevent logic errors in downstream apps, maps, or analyses.

Performance strategies

Now that we’ve covered how spatial data is stored, queried, and analyzed, it’s time to focus on the next challenge: efficiently working with large and complex geospatial datasets.

As the volume and complexity of spatial data grow, so do the performance demands, and solving them requires more than just faster hardware. We need to apply specialized techniques and strategies that account for the unique nature of spatial operations.

Here are some of the key techniques, like spatial indexing, geometry simplification, and tiling, that make responsive, scalable geospatial apps possible.

Spatial indexing

Some geospatial datasets can easily contain thousands or millions of shapes, ranging from small collections of local objects to datasets that cover vast areas, such as countries, intergovernmental regions, transoceanic zones, or even the entire world. These shapes may include thousands of vertices, making them complex to process.

To run fast spatial queries (e.g., intersects, within), spatial databases use specialized spatial indexes like R-trees. These indexes organize geometries by their bounding boxes, enabling the system to quickly filter out irrelevant areas, much like how B-tree indexes help accelerate range queries in traditional databases.

Without spatial indexing, even simple queries would require scanning every geometry, which quickly becomes unmanageable at scale.

How do spatial indexes work?

Spatial indexes work by simplifying complex geometries into bounding boxes (rectangular envelopes that fully contain each shape). Take a look at the following image, which illustrates how spatial indexes work:

In the illustration, each feature (A, B, C, and D) is enclosed by a bounding box, which is what the spatial index stores, not the full geometry.

If we want to know which shapes intersect with feature A (the area around the marker), the spatial index performs a fast initial filtering step. It identifies all features whose bounding boxes intersect with A’s bounding box. In this case, B and D are potential matches.

This step avoids checking geometries that are clearly irrelevant (like C), improving performance significantly.

Then, in a second phase, the database performs a precise geometric check on the candidate features (B and D) to verify actual intersections.

This two-step process: bounding box filtering followed by exact geometry comparison, is what makes spatial queries efficient, especially when dealing with large and complex datasets.

Simplification and tiling

This is about delivering data at the right level of detail. When you build a map application, users will pan and zoom. The same dataset that looks fine when zoomed in can become overwhelming and difficult to render efficiently when zoomed out.

To keep things fast, you need to adapt the data dynamically:

Simplify geometries: Just like responsive design adapts to screen sizes, maps need to adapt detail to scale. This is done by reducing the number of vertices in a shape as the user zooms out, a process known as generalization.
Tile the data: Geospatial systems often split data into tiles, small chunks representing a specific area and zoom level. This is like lazy-loading components in a frontend app: only load what you need, when you need it. Tiling lets you render massive datasets progressively, keeps memory usage low, saves bandwidth, and speeds up load times.
Compress with topology-aware encoding: reduce file size by encoding shared boundaries only once and storing coordinates as deltas from previous points. This minimizes redundancy and ensures topological consistency between adjacent shapes, making data smaller and cleaner for delivery.

Without simplification and tiling, rendering large geospatial datasets would quickly become a bottleneck. You’d be forced to load entire layers into memory, process overly detailed geometries at every scale, and deal with slow rendering, high bandwidth usage, and unresponsive user interfaces.

Visualization and User Experience

Maps are often the primary interface for interacting with geospatial data, and how that data is visualized can make or break the user experience. Clear, performant map design depends on techniques like scale-based visibility, proper symbolization, and more.

Client-side mapping technologies

To work effectively with spatial data and build fast, interactive, and insightful geospatial applications, you need specialized mapping tools.

These tools need to be optimized to:

Render rich, data-driven visualizations: Support both continuous and discrete data, with the ability to symbolize 2D and 3D geometries using dynamic styles. Visualize spatial data through heatmaps, clusters, geolocated pie charts, and more. Provide curated libraries of cartographic symbols for common use cases (points of interest, transportation, boundaries, etc.) so you don’t need to design everything from scratch.
Manage spatial references and projections: Support rendering maps in various coordinate systems, and reproject data on-the-fly to ensure spatial accuracy and consistency across layers (we’ll cover spatial references in more detail below).
Perform client-side spatial analysis: Enable real-time operations such as distance calculations, buffering, spatial joins, and geometry processing, directly in the client.
Ensure performance at scale: Handle large datasets efficiently using the tile-based rendering, topology-aware geometry compression, and hardware acceleration through WebGL, WebGPU, Web Workers, and other performance enhancements.
Provide prebuilt UI widgets and interaction tools: Offer customizable, ready-to-use components like zoom controls, search bars, legends, measurement tools, sketch editors, popups, and more, accelerating UI development.
Support interoperability and extensibility: Work seamlessly with widely adopted geospatial standards such as GeoJSON, WMS, WMTS, 3D Tiles, or COG. Some of these are defined by the OGC, the geospatial equivalent of the W3C. These tools should also let developers add custom layers or renderers and extend functionality (e.g., through a plugin-friendly architecture).

Without client-side mapping technologies, you’d end up reinventing the wheel, manually building performance optimizations, drawing logic, interactive behaviors, and UI components that these tools already handle for you.

Development and cartographic design tools

Building great maps isn’t just about code. Great user experiences depend not only on data and logic, but also on how that data is styled, labeled, and presented across different scales and contexts.

A good development experience requires tools that make it easier to design, develop, test, and refine cartographic styles without starting from scratch.

These tools accelerate development and improve design quality by enabling:

Data exploration: Inspect spatial data visually to understand distributions, outliers, or gaps, helping you make better styling and filtering decisions early in the workflow.
Visual style editors and map builders: Quickly experiment with map designs (symbols, layers visibility, labels, popups, and more) using interactive GUIs with live preview. This saves time during design iteration.
Custom symbol builders: Create symbols visually (e.g., advanced markers) using visual tools.
Style import/export: Save and reuse visual styles across projects or environments. Load styles dynamically from the client SDK to reduce code and ensure consistent map design across teams and apps.

An example of this type of data exploration, map authoring, and even analysis tool would be the ArcGIS Map Viewer.:

And an example of a cartographic design tool is the Vector Tile Style Editor:

Without development and cartographic design tools, every visual change would require manual code edits, refresh cycles, and trial-and-error guessing. You’d waste valuable time tweaking styles without visual feedback, struggle to maintain consistency across projects, and overload developers with work that designers could handle more efficiently through visual tools.

Interoperability

As with any software system, interoperability within a geospatial system also matters. This section highlights the importance of spatial references, file formats, and API specifications when integrating and working across systems.

Spatial references

There’s no single universal way to represent location. The most widely known system used by GPS and expressed in latitude and longitude is known as WGS84. But many datasets, especially from open data portals or government agencies, use other spatial reference systems like UTM or Web Mercator, which express positions differently (e.g., in meters instead of degrees).

Although spatial references ensure interoperability, they also play a crucial role in ensuring accuracy. Just like mixing text encodings (UTF-8 vs ISO-8859-1) can cause characters to display incorrectly, mixing spatial data with different coordinate systems without reprojection can cause features to appear in the wrong place, or not show up at all.

The following image illustrates how the same coordinates expressed in two different systems represent different locations on Earth.

If you want to know more about this, you can check Spatial references in our developer docs.

Geospatial data formats

All geospatial file formats define the spatial reference of the data (either explicitly or implicitly) along with the geometry itself. Well-known formats like GeoJSON, Esri JSON, TopoJSON, GeoPackage, and Shapefile are designed to carry not just raw coordinates, but also essential metadata.

Unlike plain CSVs that may contain coordinates but lack spatial context, these formats embed critical information such as spatial references, attribute schemas, and projection details, ensuring the data is accurately interpreted, styled, and integrated across different systems.

Geospatial APIs

To make it easier to discover and interact with such data via APIs, there are well-established open specifications explicitly designed for geospatial content. These include OGC standards like WMS, WFS, and OGC API, as well as our ArcGIS REST APIs and STAC.

These APIs typically expose:

Service metadata (e.g., name, description, provider, license)
Available layers or feature collections
Supported spatial reference systems
Supported output formats
And other technical capabilities that make the data easier to explore, visualize, or analyze across different systems.

For developers, understanding geospatial APIs is key not only to saving valuable development time (by leveraging existing tools and workflows instead of reinventing them) but also to building interoperable solutions that work across different platforms. By following well-known specifications, these APIs provide consistent access to spatial data, reducing the need for custom parsing, manual conversions, or coordinate fixes.

Takeaways

As we have seen, geospatial data isn’t just “data with coordinates”. Working with location data presents unique challenges that require new tools and ways of thinking. So, if you’ve ever struggled with location data, now you know why.

The good news? There’s a whole ecosystem of tools built to help you. To address them, you can embrace the tools explicitly built to work with geospatial data, such as spatial databases, geospatial servers, client-side SDKs, and specialized cartographic design tools, and you’ll save time and headaches.

What’s next? If you’d like to dive deeper, I recommend exploring our developer guides and the Interactive Learner GIS. If you’re interested in hosted cloud services, I’ve also started a blog series that breaks down ArcGIS hosted services in detail (feature services, vector tile services, and map tile services).

And if you find something confusing or believe you’ve spotted an error or inconsistency in this article, we’d love to hear from you. Please reach out to us at developers@esri.com so we can ensure the content remains clear, accurate, and insightful.

If you found this article helpful and believe others in your professional network may benefit from it, we would greatly appreciate it if you could share or engage with the post on LinkedIn, Bluesky, or X.

My Experience at Commit Conf 2025

Raul Jimenez Ortega — Wed, 04 Jun 2025 17:35:54 +0000

A couple of months ago, I attended Commit Conf, one of my favorite conferences in Spain (and I never get tired of saying it).

Around 1,000 of us gathered (including 80 speakers) to talk about:

Development (e.g., programming languages, databases, web & mobile development)
User Experience design (e.g., UX/UI design, accessibility)
Development practices (e.g., Agile and Lean methodologies, DevOps practices)
Artificial Intelligence and data science (e.g., machine learning, LLMs, data science)
Infrastructure (e.g., cloud computing, IoT)
Information security and privacy (e.g., cybersecurity, data protection)
And much more (e.g., power skills, blockchain, etc.).

As expected... I loved the SWAG this year, the design was A MAP created with GitHub Commit contributions! (Amazing work 😍):

GitHub contribution activity screenshot.

Once again, dozens of tech communities joined forces to help promote the event and select talks. In our case, through the Geo Developers community.

In this post, I want to highlight three main things:

Our talk about map APIs.
Reconnecting with tech communities.
And what I learned from the talks and hallway chats.

The Billion Dollar Code 🤑

We named our talk after the Netflix miniseries (which we also used as a storytelling thread). Although my talk titles are usually more descriptive, this one had the intended effect — we exceeded my expectations for attendance, and apparently those of the organizers too, because the room was packed.

Juanma and I counted around 70 people:

As stated in the abstract, this talk focused on the technical challenges and complexities of implementing map services at a global scale.

Our goals were:

Spark interest in the topic: Show some lesser-known but fascinating aspects of these services.
Highlight technical complexity: Reveal just how intricate these technologies are, and the level of software and data engineering required.
Value continuous effort: Emphasize the ongoing work involved in maintaining, improving, and innovating within map APIs, and hint at what’s coming next.
Help people make better tech decisions: Raise awareness of the variety of providers out there and improve the ability to choose the right mapping tech for future projects.

I usually don’t co-present, but after this experience, I think I should do it more often.

This time I really wanted it to be Juanma and me. Not just because we’ve had a great relationship for years, but also because we work at two of the most established companies in the industry (with over 100 years of combined experience). Plus, we complement each other really well — we cover the challenges from both a software and data perspective, not just for creating, but especially for keeping these services up to date.

The feedback we received both via the platform and in the hallways was excellent. In short:

What worked well:
- People loved the content and many said it surprised them.
- Several folks mentioned they had never stopped to consider the technical complexity behind these services.
- Visual examples were especially appreciated — they helped people understand the concepts and challenges better.
Areas for improvement:
- Consider the timing (it was the last talk of the day) and adjust pacing and depth accordingly.
- Break the session into multiple parts next time to go into more detail.

Quite a few people told us they were feeling tired as it was the final talk of the day. Even so, the response was very positive (we scored 4.5 out of 5), despite the very fast pace (around 33 seconds per slide on average 😅).

You can find the presentation here (in Spanish), and the recording is available on Commit Conf’s YouTube channel (also in Spanish, but you can activate English subtitles 🤷).

Reconnecting with Communities

Another reason I love Commit is that it brings together a lot of us who organize and run tech communities.

For the third year in a row, the organizers accepted our Open Spaces proposal, which is always a great opportunity to meet new people and learn from their experiences.

Note: In case you didn’t know, the “meta-community” we launched last year — Community Builders — was born from the idea of keeping these kinds of conversations going after events like this. 😍

We even recorded audio from the open space session, and shared the materials and notes here (again, everything is in Spanish 😅).

At the closing session, I was invited onstage with the other communities to introduce each one. I took the chance to briefly explain what Community Builders is.

To wrap up, we had a post-conference dinner at Casa Mingo, where Álvaro and I brought together around 20 people who help run communities (including some who couldn’t attend the conference). A perfect way to end the event.

No doubt about it — these activities help us connect on a human level, something much harder to achieve remotely. Bonds are formed, relationships are strengthened, and there's a real sense of closeness that just doesn’t translate through video calls.

Lessons Learned About AI

No offense to the other topics (there were some excellent talks, many of which are now on YouTube), but this year’s big star was AI. Of the 70 sessions, 17 focused on it — so pretty much at any given time, you could find a talk on Machine Learning or LLMs.

Here’s a quick rundown of themes and the interest I observed:

Practical AI integration in real-world apps: People are eager to understand how to embed AI into existing apps using commercial or open-source models without switching tech stacks.
Autonomous AI agent development: High curiosity around building agents that can learn and act on their own.
Security and auditing in generative models (LLMs): Rising concern over the risks of generative AI — from running unknown code to accidentally introducing vulnerabilities. There's growing demand for tools that provide auditing and control.
Observability and performance (in production): More and more interest in understanding LLM behavior in real time, with tools that offer metrics, logs, and traces to improve stability and performance.
Advancements in RAG architectures (RAG 2.0): Curiosity around new variants that improve contextual retrieval.
AI on mobile devices: Moderate interest in running AI directly on phones without relying on the cloud.
AI applications in real-world scenarios: Less buzz overall, but still some interest in learning about how AI is being used in everyday situations.

I also had a bunch of hallway conversations worth sharing:

AI is replacing traditional platforms like Stack Overflow, Reddit, and Google Search for developers — tools like GitHub Copilot, Cursor.ai, and Windsurf are seen as faster, more tailored, and more efficient.
- My takeaway: How will this affect traditional educational channels?
Vibe coding seems to be mostly well-received — as long as it's for small utilities, side projects, or low-risk tools (e.g., a command-line client for an API).
AI-assisted coding is becoming widespread (even among senior devs), often used for inspiration or to explore alternatives — though the code is always double-checked.
Some people pointed out how tempting it is to use AI with unfamiliar tech — the danger being that you may not catch mistakes or bad practices in the generated code.
Jon Vila shared a great insight: the risk of empowering less technical roles, like product managers, who start generating code with AI and then challenge development estimates.
AI is creeping into every phase of software development — from writing tests and documentation to generating test data and even creating pull requests.
People are really interested in tools like:
- AI-powered IDEs: Cursor, Windsurf
- Coding assistants and autocomplete: GitHub Copilot, Cody
- Agent/LLM frameworks: LangChain
- LLM APIs: GPT-4, Claude 3, LLaMA 2
- Workflow automation: n8n, Langflow
- UI/component generators: Vercel V0, Lovable

Final Thoughts

As long as I can, I’ll keep going to Commit — because to me, it’s one of those rare events where you learn, connect, and leave with a full dose of community spirit. It’s intense, sure, but it’s an event where:

You learn a ton (in talks and in the hallways)
You meet new people
You reconnect with old friends
And it’s a meeting point for tons of tech communities

Thanks, thanks, and a thousand thanks to Laura, Abraham, Nacho, Kini, and all the volunteers and sponsors who made this event possible once again.

If you’re still hungry for more, check out the piece I wrote last year: Why Attend Developer Conferences

Why Attend Developer Conferences

Raul Jimenez Ortega — Mon, 22 May 2023 10:35:41 +0000

Translations: Spanish 🇪🇸

If you want to know what the benefits of attending developer conferences like CommitConf and why you should consider submitting a proposal for a talk or workshop, keep reading! 😄.

Recently, I was fortunate enough to attend CommitConf. It is one of the largest events for developers that is held annually in Spain. It is well attended and draws strong participation from around 50 Spanish technical communities.

Why attend conferences like CommitConf?

At the conference, developers were brought together to retrain, discover, and share new insight and knowledge about our profession. For example, attendees shared information about:

New tools and languages.
New capabilities for the tools and languages already used by the community.
How companies solve different software development challenges.
Best practices in accessibility, security, and design patterns.
New trends.

Additionally, the conference provided a place to meet new people and reconnect with those already known. At events like this, it’s not uncommon to run into people you know! In my case, I bumped into some of my former colleagues, and some developers who use ArcGIS to create Location-Aware apps or map applications.

What made this conference special?

This event, like many others, gives us, developers, the opportunity to present talks, workshops, and even Open Spaces.

For attendees, a unique factor that sets this event apart from others is the system used to create the event‘s agenda, allowing the communities themselves to be involved in the selection process of talks. This system is called Koliseo and is free for anyone to use.

Why submit a proposal?

Going to an event like CommitConf is an opportunity to learn from and contribute to the developer community. And, there are many different motivations for a person to send a proposal.

There are people who simply enjoy sharing knowledge and experiences.
Other attendees want to increase the visibility of their company and to raise awareness of the cool work they do, with the hope of attracting new talent.
Some attendees want to create a personal brand.
While others want to discuss and find solutions to a problem with their colleagues.

And if you are lucky enough to have a proposal accepted, as in my case, you can attend the speakers’ dinner the day before the event, where you meet a lot of experts on different topics 😍.

What did Esri bring to the conference?

From the company I work for (Esri), they have always encouraged me to attend to conferences and to send proposals that I thought might be relevant to other developers.

This time, I presented a variety of proposals:

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

I was lucky that the conference organizers accepted “OAuth, OpenID Connect, and JWT for Dummies” because it gave me the opportunity to share what these auth standards are and how they work. I showed practical examples based on some of the resources that we have created from Esri's Developer Experience team, like the Authentication workspace in Postman.

In case you want, you can check the slides out here. If you are interested in the topic and want me to repeat this talk online, just let me know in the comments!

What did I learn at the conference?

Below are some of the takeaways from the sessions that I attended:

Local Communities Outside Big Cities (Open Space): This session was super interesting. I had the opportunity to share tips and ideas to overcome challenges in creating and maintaining developer communities with approximately thirty other people. Among them were representatives from different communities about Python, Software Crafting, Data, Machine Learning, generalists’ communities, Free Software, GNU/Linux, DevOps, Drupal, and us representing the GeoDevelopers community.

Note: After the session, I decided to create a guide with what we learned and our own experience. If you are interested, save the article in favourites because we will add it [here] in a few weeks.

Detecting Web Performance Issues with Chrome DevTools: @nucliweb gave an overview of the Chrome DevTools and showed us how they keep adding new tools like Recorder and Coverage to help evaluate your web performance and optimize it. Also, he showed us how the new AVIF image format improves WebP performance. More info at web.dev.
Don’t Yell at Me, I Can’t See You: @javierabadia and @jameshedaweng explained to us how to divide the responsibilities between an Engineering Manager and a Product Manager to avoid failure when creating a product. In summary, a PM must be responsible for what features to add and why, and the EM in the how and the who. The when should be a shared responsibility.
Why I Decided to Pursue the Developer Relations Path: @kinisoftware told us about his experience as a Staff Developer Relations Engineer, where he works to promote the expertise of Criteo’s technical team by facilitating participation in events and communities.
Testing Web Accessibility: @bolonio showed us a multitude of tools and resources for testing web accessibility: axe-core, eslint-plugin-jsx-a11y, jest-axe, axe-core/cli, pa11y, pa11y-ci, axe chrome extension, arc toolkit, accessibilityinsights.io, wave.webaim.org, and more.
The Mistake of Becoming a Manager: @npatarino explained to us that becoming a manager of people is not the only way to have leadership or increase your salary. He said that for those senior software engineers who want to continue growing, there are other positions such as Staff Software Engineer, Principal Software Engineer, Distinguished Software Engineer and Technical Fellow.
Past, Present and Future of EducaMadrid: @asanzdiego talked to us about the educational platform of the Community of Madrid that he leads; he told us about the technical challenges they suffered during the pandemic, when the number of active users grew exponentially, along with the strengths and limitations of his team and his technological stack based on free software.

In summary, if you don't use to go to developer conferences, I hope my experience has encouraged you and given you arguments to attend in the future. I would say also to the Esri Developer Summit in the USA (or in Europe), although this rather applies if you are an Esri partner or customer 😉.

Remember, although much of the content of these conferences is then made available online, there are many other things that can only be achieved by attending.

What’s New in the ArcGIS API for JavaScript, version 4.23

Raul Jimenez Ortega — Tue, 26 Apr 2022 17:29:07 +0000

Update: Did you miss the event? We have it recorded, and you can watch the Livestream here.

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!

https://twitter.com/hhkaos/status/1603669698222112768