# Wherobots > The AI Context Engine For the Physical World Site: https://wherobots.com/ Generated: 2026-10-25 (full-content companion to /llms.txt) --- ## Most Dangerous Roads for Pedestrians and Cyclists in the US (Part 2) URL: https://wherobots.com/blog/most-dangerous-roads-for-pedestrians/ Updated: 2026-10-21 This is a follow up post to an analysis I worked through on October 17th about the most risky road segments in the U.S. for driving and generally. The following day, Oct. 18, 2026, The Wall Street Journal published an analysis of 1.5 miles of Union Avenue in Memphis, Tennessee by Rebecca Cadenhead and Andrew Mollica. The Journal counted 10 pedestrians killed on that stretch since 2020. Union Avenue has six lanes and carries about 30,000 cars a day. The Journal used Union Avenue to show how people on foot are put at risk on a common American road design, the “stroad”. A stroad is a road that serves shops and homes, like a street, while also moving fast traffic, like a highway. We ran the Journal’s test on every arterial road in the United States. The stretch with the most pedestrians killed is 1.5 miles of Westheimer Road in Houston. From 2020 to 2024, 19 people walking were killed there. A road with the same traffic would have about one pedestrian death in five years. Union Avenue ranks 137th. It is one example of a road design that repeats in cities across the country. Wherobots ran this analysis on public federal data. Wherobots is the AI Context Engine for Physical World Data: a platform that joins location data, such as crash records, road maps and traffic counts, at planetary scale. How we extended the Journal’s analysis The Journal looked at one street with Tennessee’s crash records. We looked at all of them with the national record. We kept the Journal’s rules where the national data allowed it, and added a test for chance. Deaths. We took every pedestrian and cyclist killed from 2020 to 2024 from the Fatality Analysis Reporting System (FARS), the national record of every fatal traffic crash. That is 36,075 pedestrians and 5,247 cyclists. Roads. We took every principal arterial, minor arterial and major collector from the road inventory that states report to the Federal Highway Administration. These are the busy roads between freeways and side streets, about 918,000 miles in all. Freeways are left out, as in the Journal’s analysis. Stretches. We joined road pieces into continuous streets and slid a 1.5-mile window along each one, 0.1 mile at a time. A death counts for a window when the crash record places it within 200 feet of the road, the Journal’s rule. Chance. On a 1.5-mile stretch, two or three deaths in five years can come from chance. We used the Empirical Bayes method from the Highway Safety Manual, the reference U.S. road agencies use to find dangerous roads. With it, we weigh each stretch’s deaths against the deaths on roads with the same traffic. A stretch ranks high only when its count is both large and far above that norm. Checks. We picked the top 25 so that no two share a death. We checked that each one is a single, continuous piece of road 1.5 miles long. One stretch in Phoenix failed that check, and we set it aside. We also checked that the street names on each crash record match the road. We screened every arterial and major collector outside freeways. Of the 36,075 pedestrians killed, 25,433 (70%) died within 200 feet of those roads and are counted. Another 1,315 died within 200 feet of them in crashes the federal record places on a freeway, so they are not counted. Our count of pedestrians killed in 2021, 7,470, matches the figure in the National Highway Traffic Safety Administration’s pedestrian fact sheet. The national record has two limits the Journal’s did not. It holds deaths only, so injury crashes are not counted. It also ends in 2024, so deaths in 2025 and 2026 are not counted. The 25 most dangerous roads for pedestrians The map shows the 1.5-mile stretches with the most pedestrians killed from 2020 to 2024, after the Highway Safety Manual adjustment. Click a stretch for its rank, the deaths counted and the number expected. “Expected” is the number of pedestrian deaths a road with the same traffic would have in five years. The 25 stretches in red and Union Avenue in blue. Zoom in to see each death, dark for a death after dark. Click a stretch for its numbers. Open the full map ↗ Central Avenue in Albuquerque had 17 deaths, the second most of any stretch. It ranks seventh because its traffic is lower, and under the method we give a low-traffic road’s count a little less weight. With a narrower 100-foot rule, all of the top 10 stay in the top 25. With shorter 0.5-mile stretches, 8 of the top 10 stay. Each stretch’s records are in the full map. Choose a stretch to list every person killed there, with the date, the time and the nearest cross street. Each row also says whether a crosswalk was present and gives the case number in FARS, the federal record of fatal crashes. A reporter can request the police report with that case number. The list downloads as a spreadsheet file (CSV). Where Union Avenue ranks Union Avenue’s worst 1.5 miles runs from Cleveland Street east to Florence Street. In the national record, 7 pedestrians were killed there from 2020 to 2024. A road with its traffic would have about 0.5 deaths in five years, so Union Avenue had about 15 times the expected number. The Journal counted 10 deaths on its stretch, from Tennessee’s records through September 2026. Union Avenue ranks 137th among U.S. stretches. We scored about 2.3 million windows on roads with at least one pedestrian or cyclist death, and 136 stretches had a worse record than Union Avenue. Bakersfield, California, also has a Union Avenue in the top 25. Its 1.5 miles at number 13 had 13 pedestrians killed, all of them after dark. What the most dangerous stretches have in common The 25 stretches look like Union Avenue. Every one has at least four through lanes, and 17 have about six or more. The middle stretch carries about 52,000 vehicles a day. Most deaths happened at night. On the 25 stretches, 220 of the 266 pedestrians killed died in the dark, or 83%. The Journal reported the same pattern: people crossing between intersections at night are the most likely to die. The vehicle struck the pedestrian first in 254 of the 266 deaths. Florida has six of the 25 stretches, California five and Texas three. Two stretches are on U.S. 441 in Broward County, Florida, and two are on Beach Boulevard in Stanton, California. The stretches in each pair are less than 3 miles apart and share no death. The most dangerous roads for cyclists Cyclist deaths are rarer, so 1.5 miles holds too few to compare. No 1.5-mile stretch had more than 5 cyclists killed in five years. We used 5-mile corridors instead. We ranked them by how many more cyclists were killed than the number expected for the corridor’s traffic. Click a corridor on the map for its rank, the cyclists killed and the number expected. The 25 corridors for cyclists. Click a corridor for its numbers. Open the full map ↗ Florida has 19 of the 25 corridors with the most cyclists killed above the expected number. The other six are in Arizona (2), California, Hawaii, Louisiana and Nevada. The top corridor, U.S. 19 in Pasco County, is the same road that ranks first in our ranking of the most dangerous highway stretches. The counts are small: each of the 25 corridors had 3 to 7 cyclists killed. Ranked by raw count instead, all of the top 10 still appear in the top 25. The cities where walking and biking are most dangerous We also counted deaths in each of the 327 U.S. cities with 100,000 or more residents, on all roads. Where a city has few deaths, we adjusted its rate toward the average of all 327, the same Empirical Bayes idea used for the roads. Memphis has the highest rate of pedestrian deaths. From 2020 to 2024, 304 people walking were killed in the city, about 9.8 a year per 100,000 residents. The next four cities are in the South: Jackson, Mississippi: 70 killed, 8.7 a year per 100,000 residents Fort Lauderdale, Florida: 84 killed, 8.6 Little Rock, Arkansas: 88 killed, 8.5 Baton Rouge, Louisiana: 90 killed, 8.0 For cyclists, Fort Lauderdale has the highest rate, with 17 killed, about 1.3 a year per 100,000 residents. New Orleans, St. Petersburg, Tampa and Baton Rouge follow, each about 1.1. Cities differ in how many people ride a bike, so we also compared deaths with the number of people who bike to work. That count comes from the Census Bureau’s American Community Survey. Among cities with at least 500 bike commuters, Baton Rouge ranks first, with about 40 cyclists killed a year per 10,000 bike commuters. Jacksonville, Fresno, Detroit and Orlando each have about 35 to 38. New York has about 3 and Chicago about 4. Cities of 100,000 or more residents, colored by deaths a year per 100,000 residents. Switch between people walking and people biking. Open the full map ↗ Data and rules Deaths: FARS 2020 to 2024, the person file. Pedestrians and cyclists killed in a crash with a vehicle on a public road. Roads and traffic: the Highway Performance Monitoring System, the road inventory states report to the Federal Highway Administration, 2024 edition. Residents and commuters: American Community Survey estimates for 2020 to 2024, inside Census place boundaries. Method: the Federal Highway Administration’s guidebook for finding high pedestrian crash locations, with the network screening method in the Highway Safety Manual. Expected deaths come from a model of deaths against vehicle traffic on each type of road. They are modeled, not counted. Computation: every join, count and model ran in Wherobots. The pipeline and the method checks are public in our working notes. What the ranking leaves out No national count of people walking or biking exists. The expected numbers use vehicle traffic only, so a busy sidewalk and an empty one look the same to the model. Deaths are a floor: crashes the record places more than 200 feet from the road are not counted, and neither are injuries. About 30% of pedestrian deaths are not counted. The federal record places 6,123 of them on a freeway, which the ranking leaves out. The other 4,519 lie more than 200 feet from the roads we screened or have no recorded location. Why AI is blind to the most dangerous roads Every number in this post comes from joining three kinds of records: crash locations, road lines and population counts. AI models are trained on text, documents, databases and the internet. They can describe a stroad. Finding the worst ones takes a join of about 41,000 crash records against 918,000 miles of road, and Wherobots runs that join in one engine. Frequently asked questions What is the most dangerous road for pedestrians in the US? A 1.5-mile stretch of Westheimer Road in Houston. From 2020 to 2024, 19 people walking were killed there, 16 of them after dark. A road with the same traffic would have about one pedestrian death in five years. Where does Union Avenue in Memphis rank? Its worst 1.5 miles, from Cleveland Street east to Florence Street, ranks 137th in the country. Seven pedestrians were killed there from 2020 to 2024, about 15 times the number expected for its traffic. What is the most dangerous road for cyclists in the US? A 5-mile stretch of U.S. 19 in Pasco County, Florida, where 7 cyclists were killed from 2020 to 2024. Florida has 19 of the 25 corridors with the most cyclists killed above the number expected for their traffic. Which US city is the most dangerous for pedestrians? Memphis. From 2020 to 2024, 304 pedestrians were killed in the city, about 9.8 a year for every 100,000 residents. That is the highest rate of the 327 U.S. cities with 100,000 or more residents. Why do so many pedestrian deaths happen at night? On the 25 stretches in our ranking, 220 of the 266 pedestrian deaths happened in the dark. Wide roads are hard to light, and drivers on them often travel faster than the posted limit. --- ## Most Dangerous Highway in the US: 25 Deadliest Stretches URL: https://wherobots.com/blog/most-dangerous-highway-in-the-us/ Updated: 2026-10-21 The most dangerous highway in the US is a 10-mile stretch of U.S. 19 in Pasco County, Florida, between Port Richey and Hudson. From 2019 to 2023 it had 61 fatal crashes, in which 64 people died. A typical road with the same traffic and design would have about 15 fatal crashes in five years. U.S. 19 had about four times that number. Wherobots ran this analysis on public federal data. Wherobots is the AI Context Engine for Physical World Data: a platform that joins location data, such as crash records, road maps and traffic counts, at national scale. We ranked every 10-mile stretch of Interstate and U.S. route with traffic counts in 48 states by how many more fatal crashes it had than a typical road like it. The crash records come from the Fatality Analysis Reporting System (FARS), the national record of every fatal traffic crash. Road maps and traffic counts come from the data states report to the Federal Highway Administration. The method is the network screening method in the Highway Safety Manual, the reference that U.S. road agencies use to find dangerous roads. How we ranked the stretches We asked two questions about each stretch. Did this road have more fatal crashes than it should? And is that a lasting pattern, or a bad year or two? We followed six steps: Place each crash on the road. A crash counts on a road when it lies within 100 meters (about 330 feet) of a road section with the same route number. That placed 47,739 fatal crashes from 2019 to 2023. Join each route into one continuous road. Some states record one highway as a separate piece for each county. We joined those pieces end to end. A road ends where the pavement is shared with a different route number, because the crashes there are recorded under that other route. Slide a 10-mile window along each road. A new window starts at every mile, so every possible stretch gets a count. That gave 145,592 windows on 2,167 roads. Work out the expected number of fatal crashes. We fitted a model to all of these roads. For each window, it gives the fatal crashes expected on a typical road like it. The model matches roads on daily traffic, number of lanes, speed limit, access control, truck traffic and urban or rural setting. Give less weight to small counts. A window with 3 crashes could easily have had 1 or 6 by chance. The Highway Safety Manual's Empirical Bayes step blends the actual count with the expected count. The fewer crashes a window has, the closer the result moves to the expected count. Rank by excess crashes. The excess is the adjusted count minus the expected count. We ranked windows by their excess and kept only windows that do not overlap. Here is how the steps work on U.S. 19 in Pasco County. The window had 61 fatal crashes. The model expected 14.7. The adjusted count is 53.6, so the excess is 38.8 fatal crashes, the most of any stretch in the country. The 10-mile stretch of U.S. 19 between Port Richey and Hudson. Click the line to see its fatal crashes, deaths, expected crashes and excess. Open the full map ↗ The 25 most dangerous highway stretches in America Ranked by excess fatal crashes, 2019 to 2023. Every stretch is 10 miles long (one is 9.9). "Expected" is the number of fatal crashes on a typical road with the same traffic and design. Routes that start with "I-" are Interstates, so I-35 is Interstate 35. The map below shows all 25 stretches. Click a stretch to see its fatal crashes, deaths, expected fatal crashes and excess. These five had the most excess fatal crashes: U.S. 19 in Pasco County, Florida, from Port Richey to Hudson: 61 fatal crashes, where 14.7 were expected. The excess is 38.8. U.S. 441 in Broward County, Florida, from North Lauderdale to Davie: 50 fatal crashes, where 15.5 were expected. The excess is 29.2. I-35 in Dallas, Texas: 51 fatal crashes, where 16.4 were expected. The excess is 27.0. I-30 from Dallas to Mesquite, Texas: 48 fatal crashes, where 13.3 were expected. The excess is 25.8. I-75 from Forest Park to Atlanta, Georgia: 51 fatal crashes, where 20.2 were expected. The excess is 25.1. The excess fatal crashes come from the Empirical Bayes adjustment, so they are smaller than the fatal crashes minus the expected crashes. The 25 stretches, colored by excess fatal crashes. Click a color in the key to hide it, or click a stretch for its numbers. The full map also shows 300 two-mile hot spots and a list ranked by crash rate. Open the full map ↗ What the 25 most dangerous stretches have in common All 25 stretches are in urban areas. Fifteen are Interstates and 10 are U.S. routes. Eight states hold all 25: Florida has 7, Texas 6, Georgia 4, California 3 and Louisiana 2. Colorado, Illinois and Missouri have 1 each. Together the 25 stretches had 1,062 fatal crashes and 1,139 deaths from 2019 to 2023. A typical road with the same traffic and design would have had about 352 fatal crashes. These stretches had about three times as many. The U.S. routes on the list are busy roads lined with shops, homes and side streets. Examples are U.S. 19 in Pasco and Pinellas counties, U.S. 441 and U.S. 1 in Broward County, and Colfax Avenue, which carries U.S. 40 through Denver. The Interstates run through Dallas, Fort Worth, Houston, Austin, Atlanta, Miami, New Orleans, St. Louis, Chicago and the Los Angeles area. The ranking holds when the window moves. For each of the 25 stretches, we checked every window that overlaps it by at least half. Each of those windows still had at least 4.8 more fatal crashes than expected. Which types of road are most dangerous per mile driven The ranking above ranks places. A death rate measures something else: the risk of each mile a driver travels on a type of road. A vehicle mile is one vehicle driving one mile. These are the totals for all 14,570 Interstate and U.S. route stretches of at least 10 miles with traffic counts, from 2019 to 2023. Together they had 49,050 deaths, or 0.83 deaths per 100 million vehicle miles. Road typeShare of vehicle milesShare of deathsDeaths per 100 million vehicle milesInterstates66.8%46.2%0.57Urban U.S. routes16.8%24.6%1.21Rural U.S. routes with 4 or more lanes11.4%17.8%1.29Rural two-lane U.S. routes5.0%11.4%1.91 Rural two-lane U.S. routes are the most dangerous type of road per mile driven. Their rate is 3.3 times the Interstate rate. They do not lead the ranking above because they carry little traffic. A 10-mile stretch of rural two-lane road rarely has enough fatal crashes to stand out from chance. A busy urban road that is more dangerous than it should be has many more crashes to count. How weather and the calendar change the risk Deaths on these roads peak in late summer and fall. From 2019 to 2023, August had the most deaths, 4,551, and February had the fewest, 3,415. More driving explains part of that gap. Per mile driven, the death rate was lowest in March, at 0.76 deaths per 100 million vehicle miles. It was highest in September, at 0.87, and stayed above 0.85 from August through December. To see where weather matters, we matched each state's weather to its fatal crashes, day by day and month by month. The weather comes from hourly reports at about 2,000 airports in the 48 states, from 2019 to 2022, the last year in the data. Monthly rain and temperature for each state come from the National Oceanic and Atmospheric Administration. Crash reports on these roads list rain, snow, ice or fog at 10.8% of deaths. The Federal Highway Administration counts 9% of deaths on all U.S. roads as weather-related for the same years. Where the weather is worst each month Michigan has the most hours of snow of any state from November through February. Its airports reported snow for about 121 hours in an average February. Wyoming has the most snow from March to May, and Montana in September and October. Oregon and Washington get the most hours of rain from November to January, and Rhode Island and Massachusetts in April and October. Heavy fog is most common in Oregon and Washington in winter, and in New England from May to October. Weather and fatal crashes by state and month. Use the arrows to change the month, and the buttons to show snow, rain, heavy fog or fatal crashes against the number expected. Click a state for its numbers. Open the full map ↗ Heavy rain raises the number of fatal crashes Heavy rain is the clearest danger in the data. We called a day a heavy-rain day when a quarter or more of a state's airports reported moderate or heavy rain. We compared each one with the same state and weekday one week earlier or later, on a dry day. Heavy-rain days had 297 fatal crashes on these roads, and the matched dry days had 236. That is 1.26 times as many. The wider the rain, the bigger the increase. When half or more of a state's airports reported it, there were 1.42 times as many fatal crashes as on the matched dry days, though that rests on fewer days. Of the heavy-rain days, 54% were in the South, where the increase was 1.27 times. This design follows Andrey and Yagar (1993), who compared crashes in rain with crashes in matched dry periods. Snow and fog days show no clear increase Snow days had 437 fatal crashes, and the matched dry days had 444. The two counts are within the range that chance alone produces. Heavy-fog days had 1.12 times as many fatal crashes as their dry days, which is also within that range. The data hold no traffic counts for each day, so they cannot show whether fewer people drove in snow. Over a whole month, region matters more than weather Over a whole month, the weather does not line up with excess fatal crashes. A month with more snow or rain than usual for that state had about as many fatal crashes as expected. Eisenberg (2004) studied the 48 states from 1975 to 2000 and found that wetter months had slightly fewer fatal crashes, while rainy days had more. The region matters more. The South as a whole had more fatal crashes than expected in every month, and the Northeast and Midwest had fewer, snowy or not. The most dangerous stretch in each state The map below shows the 10-mile stretch with the most excess fatal crashes in each of 48 states, one state at a time. It opens on Florida. Use the arrows to move through the states in order of excess. Each view shows the same road for up to 25 miles on each side and every fatal crash on it from 2019 to 2023. Alaska, Hawaii and the District of Columbia are left out. Alaska's Interstates have no route number in the federal road data. Hawaii and the District of Columbia have no stretch that meets the rules. Tennessee's U.S. routes are not in the data, so its stretches are all Interstates. Florida's worst stretch is also the worst in the country: U.S. 19 in Pasco County, with 38.8 excess fatal crashes. Eight of the 48 state stretches are in the national top 25. Of the 48, 21 are Interstates and 27 are U.S. routes. In states with few fatal crashes, the excess is small. In 17 states the worst stretch has fewer than 5 excess fatal crashes. The smallest is I-94 in North Dakota, at 0.6. For those states, the stretch on the map is the worst in the state, but it may not differ much from a typical road. The worst 10-mile stretch in each state, with up to 25 miles of the same road on each side. Each dark point is a fatal crash on that road from 2019 to 2023. Click a point or the stretch for its numbers. Open the full map ↗ Work zones on the most dangerous stretches Work zones do not explain the list. We downloaded a snapshot of the public work zone feeds that states publish in the Work Zone Data Exchange (WZDx) format on October 15, 2026. Three of the 25 stretches overlapped an active work zone that day: U.S. 441 in Broward County, I-95 in Miami-Dade County and U.S. 1 between Goulds and Florida City. Crash reports marked 25 of the 1,139 deaths on the 25 stretches as work-zone related. The snapshot covers 16 of the 25 stretches. The other 9 are in Georgia, California, Colorado and Illinois, which had no WZDx feed that anyone could download without a key on the snapshot date. The snapshot covers one day, so a work zone that started or ended at another time would not appear. Data and rules Every step ran in Wherobots. These are the data sources and the rules behind the ranking: Crashes. FARS fatal crashes from 2019 through 2023, the five most recent final years. Our FARS totals match the federal counts for each year, for example 42,721 deaths in 2022. Crash locations. Crashes with missing or placeholder coordinates are left out. On Interstates and U.S. routes, that removed 170 crashes, and 437 more had no route number we could read. Of 53,187 eligible crashes, 47,739 (89.8%) lie within 100 meters of a section with the same route number. Roads and traffic. The road map and traffic counts come from the 2024 Highway Performance Monitoring System (HPMS), the road data states report to the Federal Highway Administration. The 2024 average daily traffic is applied to all five years. Tennessee's U.S. routes are left out because Tennessee's road data does not identify them, and Texas frontage roads are left out. Continuous roads. A road is cut where two sections in a row are more than 1 kilometer (0.6 miles) apart. Pieces of the same route number are joined when their ends meet within 200 meters. Every ranked stretch is one continuous piece of road. Windows. Each window is 10 miles long, and a new one starts every mile. A window needs traffic counts on at least 95% of its length. Months and weather. Each crash takes the month and the weather listed in its FARS record, and crash reports gave no weather for 2,889 of the deaths. Monthly traffic is an estimate. Each stretch's five-year traffic is split by the monthly travel shares for its state's rural or urban main roads, from the Federal Highway Administration's Traffic Volume Trends report. The months add back to the five-year totals for crashes, deaths and traffic. Weather by state and day. Airport weather reports from 2019 to 2022 give the hours of snow, rain and heavy fog at each airport. Each report counts on the local date it starts, and no report counts for more than 24 hours. A heavy-rain day is a day when a quarter or more of a state's airports reported moderate or heavy rain for an hour or more. A dry control day is the same weekday one week before, or else after, when no more than 1 in 20 of the state's airports reported rain, snow or fog. Weather by month. The monthly comparison counts fatal crashes in each state, month and year from 2019 to 2022. It compares them with the expected number, after allowing for each state's usual level in each calendar month. That leaves the year-to-year change in weather as the thing being tested, as in Eisenberg (2004). Expected crashes. The model is a Poisson regression, fitted separately for Interstates, urban U.S. routes, rural U.S. routes with 4 or more lanes, and rural two-lane U.S. routes. It uses daily traffic, lanes, speed limit, access control, truck share and urban share. Where the road data has no speed limit or truck count, the model uses the national median and records that the value was missing. Empirical Bayes adjustment. The weight on the expected count is 1 / (1 + k × expected), where k measures how widely real counts vary around the model. This is the formula in Part B of the Highway Safety Manual, published by the American Association of State Highway and Transportation Officials (AASHTO). Ranking. Windows are ranked by excess fatal crashes. A window that overlaps a higher-ranked window on the same road is skipped. What the ranking leaves out The ranking covers fatal crashes only. FARS records crashes in which someone died within 30 days, so crashes with only injuries are left out. Road agencies usually build their expected-crash models from all injury crashes. With fatal crashes alone, the counts are small everywhere, which is why the adjustment for small counts matters here. The model uses the road features that the federal road data records on nearly every section. Traffic signals, driveways, curves and hills are recorded on only a sample of sections, so they are not in the model. Some of a stretch's excess may come from those features. The ranking covers only Interstates and U.S. routes. From 2019 to 2023, 132,604 of the 186,398 fatal crashes in FARS happened on other roads, such as state routes and local streets. A road that is not on this list may still be more dangerous than it should be. Why AI is blind to the most dangerous roads AI is blind to the physical world. The AI models people use every day were trained and grounded on text, documents, databases, and the internet. They can describe a highway's reputation from news stories. They cannot place 47,739 crash locations on a road map by themselves. A state traffic safety engineer who asks an AI assistant where the most dangerous stretch is needs that placement. The answer depends on which road each crash was on, how much traffic each stretch carries and how many fatal crashes a typical road like it has. Without that context, the assistant can only repeat the roads that made the news. The engineer may then spend a safety budget where the headlines were. Wherobots supplies that context. For this ranking, Wherobots placed each crash on its road, built 145,592 windows on 2,167 roads and computed the expected and excess fatal crashes for each window. A road agency can run the same steps on its own crash records and road data. To screen your state's roads, contact the Wherobots team. Frequently asked questions What is the most dangerous highway in the US? The 10 miles of U.S. 19 between Port Richey and Hudson in Pasco County, Florida. From 2019 to 2023 it had 61 fatal crashes and 64 deaths. A typical road with the same traffic and design would have about 15 fatal crashes in that time. How was this ranking calculated? We used the network screening method in the Highway Safety Manual, the reference that U.S. road agencies use to find dangerous roads. We placed 47,739 fatal crashes on the Interstate and U.S. route map and counted them in 10-mile windows. Each window was then compared with the fatal crashes expected on a typical road with the same traffic and design. Why not rank roads by death rate? A death rate divides deaths by miles driven. On a quiet road, a few crashes produce a high rate by chance, so a rate ranking fills up with roads that had a bad year or two. The Highway Safety Manual method gives less weight to small counts, so the list favors roads that are dangerous year after year. What are the most dangerous types of road? Per mile driven, rural two-lane U.S. routes are the most dangerous type of road. They had 1.91 deaths per 100 million vehicle miles from 2019 to 2023, 3.3 times the Interstate rate of 0.57. When do most fatal highway crashes happen? From 2019 to 2023, August had the most deaths on Interstates and U.S. routes, 4,551. Per mile driven, the death rate was highest from August through December and lowest in March. Crash reports list rain, snow, ice or fog at fewer than 1 in 5 deaths in any month. Does bad weather make highways more deadly? Heavy rain does. From 2019 to 2022, Interstates and U.S. routes had 1.26 times as many fatal crashes on heavy-rain days as on dry days one week apart. A heavy-rain day is one when a quarter or more of a state’s airports reported moderate or heavy rain. Snow days showed no clear increase. Do work zones explain the most dangerous stretches? No. On the day we checked, 3 of the 25 stretches overlapped an active work zone in public state work zone feeds. Crash reports marked 25 of the 1,139 deaths on those 25 stretches as work-zone related. --- ## RasterFlow vs. Google Earth Engine and ArcGIS URL: https://wherobots.com/rasterflow-vs-google-earth-engine/ Updated: 2026-10-15 Comparison RasterFlow vs. Google Earth Engine and ArcGIS RasterFlow, the imagery engine in the AI Context Engine for Physical World Data, turns satellite and aerial imagery into features you can query. See how it compares with Google Earth Engine and ArcGIS Online at each step. Start for free Talk to sales Cost before you run Priced by data processed. Models included Five built-in models plus your own. Your storage, open formats Zarr and GeoParquet on Amazon S3. Computer vision for geospatial data RasterFlow, Earth Engine and ArcGIS Online, capability by capability Each row is a step from raw imagery to features you can query. Every Earth Engine and ArcGIS Online cell comes from Google and Esri documentation, linked below the table. RasterFlow is in Public Preview. Wherobots RasterFlow Google Earth Engine ArcGIS Online RasterFlow, Earth Engine and ArcGIS Online, capability by capability Capability Imagery engine Wherobots RasterFlow Mosaics, model inference and vectorization as managed tasks, priced by data processed. Imagery platform Google Earth Engine Public data catalog and scripted analysis on Google Cloud. GIS platform ArcGIS Online Esri SaaS with imagery hosting, raster analysis and pretrained models. Prepare imagery Bring your own imagery How your own rasters get into the platform Included: Reads your own GeoTIFF and Cloud Optimized GeoTIFF (COG) imagery in place from your S3 bucket, indexed in a GDAL Raster Tile Index; no upload or ingest step Partial: Upload GeoTIFFs as image assets: up to 10 GB in the Code Editor, larger files from the command line. Or register COGs in Cloud Storage as COG-backed assets. Assets count against your storage quota Partial: Upload imagery to create hosted imagery layers, converted to Cloud Raster Format; needs a Creator, Professional or Professional Plus user type, and storage consumes credits Built-in imagery Imagery ready to use without loading it Sentinel-2 L2A with all 12 bands at 10 m, and USDA NAIP aerial imagery at 30 cm and 60 cm Included: The Earth Engine public data catalog, including Sentinel-2 surface reflectance Included: ArcGIS Living Atlas imagery such as Landsat, Sentinel and NAIP Mosaicking One mosaic over an area of interest and a time range Included: One task builds a seamless mosaic, reprojected onto your output grid Included: mosaic(), qualityMosaic() and median() composites you script over a filtered collection Included: Mosaic multiple images into one imagery layer in raster analysis Cloud cover removal Cloud-free composites Included: Built into Sentinel-2 mosaics: scene filter, per-pixel mask of cloud, shadow and cirrus, median composite Partial: Cloud Score+ and the QA60 band; you write the masking step Partial: A pretrained Living Atlas cloud mask model run through Classify Pixels Run models Built-in models Pretrained models run by the platform Included: SAM3, Fields of the World, Tile2Net, Meta CHM v1 and ChesapeakeRSC, plus bi-temporal change detection Partial: Classical classifiers you train (CART, RandomForest, NaiveBayes and SVM); no deep learning in the Machine Learning APIs Included: Over 100 pretrained Living Atlas models, such as building footprints, land cover and trees Bring your own deep learning model Included: PyTorch or TensorFlow models; PyTorch 2 archives load from Amazon S3 or Hugging Face Partial: TensorFlow, PyTorch or AutoML model on a Vertex AI endpoint, through ee.Model.fromVertexAi (public preview) Included: TensorFlow, PyTorch or Keras models packaged as .dlpk Model hosting Where the model runs Included: On Wherobots GPU runtimes, inside the RasterFlow task A Vertex AI endpoint you create, deploy and pay for separately; 1.5 MB default payload per request Raster analysis in ArcGIS Online with a Professional or Professional Plus user type; GPU use not documented Edge effect cleanup Overlapping tiles merged at seams Included: Overlapping windowed inference, merged by weighted average Partial: inputOverlapSize sets tile overlap (default 0); you discard the edge pixels in your code Included: Padding blends predictions at tile borders, up to half the tile size Use the results Vectorize predictions Raster output to polygons Included: vectorize_mosaic, written as GeoParquet Included: reduceToVectors Included: Raster to feature conversion; object detection writes polygon feature layers Output formats Included: Zarr stores, multiscale Zarr for maps and GeoParquet; PMTiles through WherobotsDB Included: GeoTIFF, Cloud Optimized GeoTIFF and TFRecord images; CSV, SHP, GeoJSON, KML, KMZ and TFRecord tables Partial: Hosted imagery layers (Cloud Raster Format); feature exports to CSV, shapefile, file geodatabase, GeoJSON, KML and GeoPackage Where results land Included: Written to your own S3-compatible storage Partial: Export tasks to Google Drive, Cloud Storage, an Earth Engine asset or BigQuery; 8 or 20 concurrent batch exports by plan Partial: Hosted layers in ArcGIS Online; writing to your own bucket not documented Open formats and catalogs Included: Zarr, GeoParquet, Parquet and COG; Apache Iceberg tables through a Managed Catalog Partial: Reads Zarr v2 from Cloud Storage; Zarr, GeoParquet, Iceberg and STAC output not documented Partial: STAC read; Zarr output, GeoParquet export and Iceberg not documented Data on Amazon S3 Included: Reads from and writes to Amazon S3 Not included: Not documented Partial: S3 and Azure data stores feed ArcGIS Data Pipelines; imagery from S3 not documented Join results with vector data in SQL Included: WherobotsDB spatial SQL over the vectorized output, in the same platform Partial: Export to BigQuery, then BigQuery SQL, including ST_REGIONSTATS Partial: SQL queries on hosted feature layers; Join Features and zonal statistics tools Cost and operations Infrastructure Included: Serverless; no cluster or model endpoint to manage Partial: Fully managed compute; model endpoints run on Vertex AI Included: SaaS managed by Esri Data volume per run Included: No documented limit; the Fields of the World 2024 to 2025 global release ran on RasterFlow Exports capped by maxPixels per task; 8 or 20 concurrent batch exports by plan Uploads up to 500 GB per file; dynamic imagery requests up to 4,000 x 4,000 pixels Billing unit RasterFlow Spatial Units: pixels × bands × time periods × a complexity factor EECU-hours, plus a monthly plan from $500 (Basic) or $2,000 (Professional) ArcGIS Online credits by pixels processed, plus 1.2 credits per GB per month for tiled imagery storage Cost known before a run Included: Calculated from area, resolution, bands and time periods before a task starts Partial: Usage is reported when a request completes; a Pricing Calculator estimate is based on projected usage Included: Estimate credits before you run a tool Example: 150,000 km² Sentinel-2 mosaic, 12 bands Wherobots estimate for one mosaic About $13.50 About $50 to generate and export Not published Noncommercial use Billed by RasterFlow Spatial Units Included: Free for nonprofit scientific research, education and noncommercial activities Credits apply to analysis and storage Sources, checked October 2026: RasterFlow overview, datasets, models, change detection, bring your own rasters, storage integration and billing; Earth Engine image upload, COG-backed assets, compositing and mosaicking, Sentinel-2 surface reflectance, machine learning, classification, Vertex AI models, ee.Model.fromVertexAi, reduceToVectors, exporting, Zarr v2 loading, usage monitoring, quotas, pricing and noncommercial use. ArcGIS Online credits, imagery layers, hosted layer exports, data stores, SQL and upload limits; Esri pretrained models, ArcGIS Image, the Detect Objects Using Deep Learning tool reference, the raster analytics API and the cloud removal sample. The Fields of the World release and the 150,000 km² mosaic figures come from the RasterFlow Public Preview announcement, and the mosaic figures are Wherobots estimates. “Not documented” means the vendor’s documentation does not describe the capability. Customer proof Getting data, algorithms, and compute in one place with Spark/Sedona notebooks is a huge boost. Powerful like Earth Engine, but with the control developers need to get jobs done. John Powell Sr. Geospatial Data Engineer, Addresscloud Which one fits your imagery work Production imagery pipelines RasterFlow fits teams that run the same mosaic, model and vectorize steps over any area, from one county to a global release, and need each run priced before it starts. Results land in open formats in their own storage, ready to join with parcels, roads or assets in WherobotsDB. Open the Model Hub Your own models at scale RasterFlow runs your own PyTorch or TensorFlow model over any mosaic on Wherobots GPU runtimes, with overlapping inference to clean up tile seams. There is no endpoint to deploy. Bring your own model Teams on AWS RasterFlow reads from and writes to Amazon S3, so imagery and results stay in the account where the rest of the data lives. Use your own storage Teams standardized on ArcGIS ArcGIS Online fits teams already working in ArcGIS that want pretrained Living Atlas models inside their GIS, with results as hosted layers for their maps and apps. Exploration over a public catalog Earth Engine fits analysts exploring its public data catalog in the Code Editor, training classic classifiers such as random forest, and noncommercial research, which Earth Engine offers free of charge. RasterFlow and Google Earth Engine FAQ Is RasterFlow an alternative to Google Earth Engine? Yes, for turning imagery into features. RasterFlow builds the mosaic, removes clouds, runs a computer vision model and vectorizes the output as managed tasks, and writes the results to your own storage. See satellite imagery analysis. How does RasterFlow pricing compare with Earth Engine pricing? RasterFlow bills by data processed, so the cost of a task is known before it runs. Earth Engine bills EECU-hours plus a monthly plan and reports usage when a request completes. Wherobots estimates a 150,000 km² Sentinel-2 mosaic with all 12 bands at about $13.50 in RasterFlow and about $50 to generate and export in Earth Engine. Can Earth Engine run deep learning models? Earth Engine’s Machine Learning APIs do not support deep learning. Earth Engine sends image tiles to a TensorFlow, PyTorch or AutoML model you deploy on a Vertex AI endpoint, which Vertex AI bills separately. RasterFlow runs five built-in models and your own PyTorch or TensorFlow model on Wherobots GPU runtimes. How does RasterFlow remove clouds from Sentinel-2 imagery? RasterFlow skips scenes with 75% or more cloud cover. It masks cloud, cloud shadow and thin cirrus pixel by pixel, using the Sentinel-2 Scene Classification Layer. Then it takes the median of the clear observations for each pixel. See Sentinel-2. Can I join RasterFlow results with my vector data? Yes. vectorize_mosaic writes polygons as GeoParquet, and WherobotsDB joins them with parcels, roads or assets in spatial SQL. See WherobotsDB and change detection. How does RasterFlow compare with ArcGIS for deep learning on imagery? Both run pretrained and your own deep learning models over imagery and blend predictions at tile borders. ArcGIS Online keeps results as hosted layers in ArcGIS and bills credits by pixels processed. RasterFlow writes Zarr and GeoParquet to your own storage and bills by data processed, calculated before each task runs. Run your imagery pipeline on RasterFlow Bring an area of interest and a model, and we will price and run it with you on Wherobots Cloud. Schedule use case review --- ## Best cloud geospatial analytics platforms compared URL: https://wherobots.com/best-cloud-geospatial-platforms/ Updated: 2026-10-15 Comparison Best cloud geospatial analytics platforms compared Wherobots is the cloud geospatial analytics platform for raster and vector data, built as the AI Context Engine for Physical World Data. See how it compares with Snowflake, Databricks and BigQuery. Start for free Talk to sales Raster and vector in one query Zonal statistics in spatial SQL. Serverless or in your VPC Distributed on Apache Spark. Built for AI agents Wherobots MCP (Model Context Protocol) Server for AI tools. Cloud data platforms Wherobots, Snowflake, Databricks and BigQuery side by side Each row is a capability a geospatial team tests before it picks a platform. Every answer for Snowflake, Databricks and BigQuery comes from that vendor’s own documentation, linked below the table. For every Wherobots capability and spatial SQL function, see the Wherobots vs. Apache Sedona feature comparison. Wherobots Cloud Snowflake Databricks Google BigQuery Wherobots, Snowflake, Databricks and BigQuery side by side Capability Spatial compute Wherobots Cloud Fully managed spatial compute, RasterFlow, Havasu catalog, and Spatial AI tools. Data warehouse Snowflake Cloud data warehouse with geospatial types. Lakehouse Databricks Lakehouse with native spatial SQL. Data warehouse Google BigQuery Serverless warehouse with geography functions. Raster and vector analysis Vector data Geometry and geography types and spatial SQL functions Included: GEOMETRY and GEOGRAPHY types, 389 spatial SQL functions for vector and raster Included: GEOGRAPHY and GEOMETRY types, ST_ and H3 functions Included: GEOMETRY (generally available, GA) and GEOGRAPHY (Public Preview), 97 ST_ functions Included: GEOGRAPHY type on the WGS84 spheroid Raster data A raster type or raster functions in SQL Included: Out-of-database raster, loading pixels on demand from object storage or a SpatioTemporal Asset Catalog (STAC) Not included: Not documented Not included: Not documented Partial: Earth Engine images and Cloud Optimized GeoTIFFs through ST_REGIONSTATS Raster and vector in one query Statistics of raster pixels inside vector polygons Included: RS_ZonalStats and RS_ZonalStatsAll in spatial SQL Not included: Not documented Not included: Not documented Included: ST_REGIONSTATS (GA) Imagery inference Computer vision models run over satellite and aerial imagery Included: RasterFlow (Public Preview), with five built-in models plus your own PyTorch or TensorFlow model Partial: AI_COMPLETE on image files; no geospatial imagery documented Not included: Not documented Partial: ML.ANNOTATE_IMAGE with Cloud Vision; no geospatial imagery documented Scale and operations Scale Distributed and serverless, on Apache Spark Distributed virtual warehouses Distributed on Apache Spark and Photon Distributed and serverless How compute runs Serverless in Wherobots Cloud, or deployed in your VPC Managed warehouses you size Serverless, Pro or Classic SQL warehouses Serverless, with optional slot reservations SQL and Python Included: Spatial SQL, Python and Scala Included: SQL and Snowpark Python Included: SQL and PySpark Included: SQL and BigQuery DataFrames Pricing model Spatial Units per hour; RasterFlow by data processed Credits per warehouse size and hour Databricks Units (DBUs) Per TiB scanned, or capacity per slot-hour Open formats and AI access GeoParquet Read and write Included: Read and write Not included: Not documented Not included: Not documented Included: Load and export Apache Iceberg geometry types Geometry columns in Iceberg tables Included: Iceberg geometry and geography types with a declared coordinate reference system (CRS) Included: GEOGRAPHY and GEOMETRY columns in Iceberg tables Included: GEOMETRY and GEOGRAPHY columns in Iceberg v3 tables Not included: GEOGRAPHY not supported in BigQuery Iceberg tables MCP server for AI agents An official Model Context Protocol server Included: Wherobots MCP Server for Claude, Cursor, and VS Code Copilot Included: Snowflake-managed MCP server (GA) Included: Genie One MCP (GA) and Databricks SQL MCP (Beta) Included: BigQuery remote MCP server (GA) Sources, checked October 2026: Wherobots Cloud from the Wherobots vs. Apache Sedona feature comparison and Wherobots documentation; Snowflake geospatial data types, AI_COMPLETE, Iceberg data types and MCP server; Databricks ST geospatial functions, SQL warehouse types, Iceberg v3 and MCP services; BigQuery raster data, geospatial data, Iceberg tables, ML.ANNOTATE_IMAGE, MCP server and pricing. “Not documented” means the vendor’s documentation does not describe the capability. Libraries and databases you run yourself Wherobots, ArcGIS GeoAnalytics Engine and PostGIS side by side The same rows for two tools teams often weigh against a spatial compute platform. Neither is a managed analytics service. GeoAnalytics Engine runs on a Spark cluster you run. PostGIS runs on your own PostgreSQL server or on hosted PostgreSQL such as Amazon RDS. Each answer comes from the vendor’s or project’s own documentation, linked below the table. Wherobots Cloud ArcGIS GeoAnalytics Engine PostGIS Wherobots, ArcGIS GeoAnalytics Engine and PostGIS side by side Capability Spatial compute Wherobots Cloud Fully managed spatial compute, RasterFlow, Havasu catalog, and Spatial AI tools. Spark library ArcGIS GeoAnalytics Engine Esri spatial analysis on your own Spark clusters. Database extension PostGIS Open-source spatial extension for PostgreSQL. Raster and vector analysis Vector data Geometry types and spatial SQL functions Included: GEOMETRY and GEOGRAPHY types, 389 spatial SQL functions for vector and raster Included: 148 ST_ SQL functions plus analysis tools Included: geometry and geography types Raster data A raster type or raster functions in SQL Included: Out-of-database raster, loading pixels on demand from object storage or STAC Included: Raster type with 30+ raster functions and tools since version 2.0 Included: raster type in the postgis_raster extension Raster and vector in one query Statistics of raster pixels inside vector polygons Included: RS_ZonalStats and RS_ZonalStatsAll in spatial SQL Included: RT_ZonalStatistics Included: ST_SummaryStats over ST_Clip Imagery inference Computer vision models run over satellite and aerial imagery Included: RasterFlow (Public Preview), with five built-in models plus your own PyTorch or TensorFlow model Not included: Not documented Not included: Not documented Scale and operations Managed service Who runs the compute Included: Fully managed by Wherobots Not included: A library you install and license on a Spark cluster you run You run the database, or rent hosted PostgreSQL such as Amazon RDS and Cloud SQL Scale Distributed and serverless, on Apache Spark Distributed on the Spark cluster you run One PostgreSQL server How compute runs Serverless in Wherobots Cloud, or deployed in your VPC On Databricks, Amazon EMR, Azure Synapse or Google Cloud Managed Spark Self-run, or on managed PostgreSQL such as Amazon RDS and Cloud SQL SQL and Python Included: Spatial SQL, Python and Scala Included: Spark SQL, Python and Scala Included: SQL; Python through drivers such as psycopg Pricing model Spatial Units per hour; RasterFlow by data processed Prepaid subscription, connected (core-hours) or disconnected, plus your Spark compute Free (GPL v2 or later), plus your database server Open formats and AI access GeoParquet Read and write Included: Read and write Included: Read and write Not included: Not documented Apache Iceberg geometry types Geometry columns in Iceberg tables Included: Iceberg geometry and geography types with a declared CRS Not included: Not documented Not included: Not documented MCP server for AI agents An official Model Context Protocol server Included: Wherobots MCP Server for Claude, Cursor, and VS Code Copilot Not included: Not documented Not included: Not documented Sources, checked October 2026: Wherobots Cloud from the Wherobots vs. Apache Sedona feature comparison and Wherobots documentation; ArcGIS GeoAnalytics Engine SQL functions, raster data, install, GeoParquet and licensing; PostGIS data management, ST_SummaryStats and license; Amazon RDS PostGIS. “Not documented” means the vendor’s or project’s documentation does not describe the capability. Customer proof We went from babysitting compute jobs for a week to getting results before lunch. Steven Yee Founding Staff Engineer, Aarden.ai Computer vision for geospatial data: RasterFlow Bring your own data Query a STAC catalog. Index your own Cloud Optimized GeoTIFFs (COGs) in a GDAL Raster Tile Index, a file that lists each image and its footprint. Then build a mosaic from them with build_gti_mosaics. RasterFlow reads from and writes to your own S3-compatible storage. Bring your own rasters Mosaicking RasterFlow builds one seamless, analysis-ready mosaic across an area of interest and a time range. Built-in datasets cover Sentinel-2 with all 12 L2A bands at 10 m, and USDA NAIP aerial imagery at 30 cm and 60 cm, reprojected onto your output grid. Build a Sentinel-2 mosaic Cloud cover removal Sentinel-2 mosaics skip scenes with 75% or more cloud cover. They mask cloud, cloud shadow and thin cirrus pixel by pixel from the Scene Classification Layer, then take the per-pixel median of the clear observations. See the cloud filtering rules Edge effect cleanup Inference runs over overlapping patches. Patch size and clip size set the overlap, and a merge mode such as weighted average blends neighboring patches. Overlapping windows reduce the edge effects that non-overlapping tiles leave at seams. See overlapping inference Five built-in models Meta SAM3 detects objects from a text prompt. Fields of the World maps field boundaries, Tile2Net maps sidewalks and crosswalks, Meta CHM v1 estimates canopy height, and ChesapeakeRSC maps rural roads. Change detection runs a model over two seasons or years in one pass. Open the Model Hub Bring your own model Run your own PyTorch or TensorFlow model. Export a PyTorch model as a PyTorch 2 archive, load it from Amazon S3 or Hugging Face, and run it over any mosaic on GPU runtimes, alongside the built-in models. Bring your own model Standard formats after inference Mosaics and predictions are written as Zarr stores. vectorize_mosaic converts predictions into polygons written as GeoParquet, and Build Multiscales adds overview levels for map viewing. WherobotsDB turns the vectors into PMTiles. Visualize RasterFlow outputs Open interoperability RasterFlow reads COG, GeoParquet and Parquet, writes Zarr and GeoParquet, and reaches Apache Iceberg tables through a Managed Catalog. WherobotsDB joins the vectorized results with parcels, roads or assets in spatial SQL. See supported formats Serverless, priced before you run No cluster to provision or manage. RasterFlow bills by data processed (pixels × bands × time periods × a complexity factor), so you can calculate a task’s cost before it runs. A 150,000 km² Sentinel-2 mosaic with all 12 bands costs about $13.50 in RasterFlow and about $50 to generate and export in Google Earth Engine. Compare with Google Earth Engine RasterFlow results in the platform you already run Databricks Wherobots reads and writes managed Iceberg tables in Databricks Unity Catalog and writes external Delta tables there. Field boundaries, roofs or canopy heights from RasterFlow land as Unity Catalog tables for Databricks ML models and BI dashboards. Connect Unity Catalog Snowflake Wherobots writes Apache Iceberg tables to your own Amazon S3 bucket. Snowflake supports externally managed Iceberg tables with GEOMETRY and GEOGRAPHY columns, so RasterFlow output can be queried alongside your Snowflake data. See Snowflake Iceberg types Google BigQuery RasterFlow writes vectorized results as GeoParquet, and BigQuery loads GeoParquet into GEOGRAPHY columns. Predictions then join your BigQuery tables in SQL. Load GeoParquet into BigQuery Function reference Every spatial SQL function, by platform Search 826 spatial SQL functions from each platform’s own function reference, filter by vector or raster, and see which platforms have each one. Functions match by name, so the same operation can appear under two names, such as ST_GeomFromWKT in Wherobots and ST_GEOGRAPHYFROMWKT in Snowflake. Raster functions also carry different prefixes on each platform (RS_ in Wherobots, RT_ in GeoAnalytics Engine, ST_ in PostGIS Raster). Search functions Data type Vector and raster Vector Raster Availability All platforms Available in Wherobots Cloud Available in Snowflake Available in Databricks Available in BigQuery Available in GeoAnalytics Engine Available in PostGIS Only in Wherobots Cloud Only in Snowflake Only in Databricks Only in BigQuery Only in GeoAnalytics Engine Only in PostGIS Category All categories Address Functions Affine Transformations Aggregate Functions Aggregates Band Accessors Bounding Box Functions Clustering Functions Connected Components (CC) Predicates Geography Type Functions Geometry Accessors Geometry Constructors Geometry Editors Geometry Output / Export Geometry Processing Geometry Validation Linear Referencing Map Algebra Operators Measurement Functions Operators Output Overlay Functions Per-Pixel Math (Map Algebra) Pixel Functions Predicates Predicates / Topological Relationships Raster Accessors Raster Constructors Raster Geometry Functions Raster Processing Spatial Indexing (H3, S2, Bing Tiles, GeoHash) Spatial Reference System Spatial Statistics Tiles Track Functions 826 functions Function Category Wherobots Cloud Snowflake Databricks BigQuery GeoAnalytics Engine PostGIS What it does ST_Area Measurement Functions Available Available Available Available Available Available compute area ST_AsBinary Geometry Output / Export Available Available alias of ST_ASWKB Available Available Available Available output WKB ST_AsText Geometry Output / Export Available Available alias of ST_ASWKT Available Available Available Available output WKT ST_Buffer Geometry Processing Available Available Available Available Available Available compute buffer geometry; Wherobots also supports spheroidal ST_Centroid Geometry Processing Available Available Available Available Available Available return centroid point ST_Contains Predicates / Topological Relationships Available Available Available Available Available Available test containment ST_Difference Overlay Functions Available Available Available Available Available Available compute point-set difference ST_Dimension Geometry Accessors Available Available Available Available Available Available return topological dimension (0=point, 1=line, 2=polygon) ST_Disjoint Predicates / Topological Relationships Available Available Available Available Available Available test disjointness ST_Distance Measurement Functions Available Available Available Available Available Available compute Euclidean distance ST_EndPoint Geometry Accessors Available Available Available Available Available Available return last point of linestring ST_Intersection Overlay Functions Available Available Available Available Available Available compute point-set intersection ST_Intersects Predicates / Topological Relationships Available Available Available Available Available Available test intersection ST_Length Measurement Functions Available Available Available Available Available Available return length/perimeter ST_NumPoints Geometry Accessors Available Available alias of ST_NPOINTS Available Available Available Available return number of points ST_PointN Geometry Accessors Available Available Available Available Available Available return Nth point from linestring ST_StartPoint Geometry Accessors Available Available Available Available Available Available return first point of linestring ST_Union Overlay Functions Available Available Available Available Available Available compute point-set union of two geometries ST_Within Predicates / Topological Relationships Available Available Available Available Available Available test if A is within B ST_X Geometry Accessors Available Available Available Available Available Available return X coordinate of point ST_Y Geometry Accessors Available Available Available Available Available Available return Y coordinate of point ST_AsGeoJSON Geometry Output / Export Available Available Available Available Available Available output GeoJSON string ST_Azimuth Measurement Functions Available Available Available Available Available Available return azimuth in radians between two points ST_Boundary Geometry Accessors Available Not available Available Available Available Available return combinatorial boundary ST_ConvexHull Geometry Processing Available Not available Available Available Available Available compute convex hull ST_DWithin Predicates / Topological Relationships Available Available Available Available Available Available test if within distance ST_Envelope Geography Type Functions Available Available Available Not available Available Available bounding box for geography type ST_Equals Predicates / Topological Relationships Available Not available Available Available Available Available test geometric equality ST_ExteriorRing Geometry Accessors Available Not available Available Available Available Available return exterior ring of polygon ST_GeometryType Geometry Accessors Available Not available Available Available Available Available return geometry type as string ST_IsEmpty Geometry Accessors Available Not available Available Available Available Available test if geometry is empty ST_MakeLine Geometry Editors Available Available Available Available Not available Available create linestring from points ST_MakePolygon Geometry Editors Available Available Available Available Not available Available create polygon from shell + optional holes ST_NumGeometries Geometry Accessors Available Not available Available Available Available Available return number of geometries in collection ST_Point Geometry Constructors Available Available alias of ST_MAKEPOINT Available Not available Available Available create point from X,Y ST_Simplify Geometry Processing Available Available Available Available Available Available use Douglas-Peucker simplification ST_SRID Spatial Reference System Available Available Available Not available Available Available return SRID value ST_Touches Predicates / Topological Relationships Available Not available Available Available Available Available test touch relationship ST_Transform Spatial Reference System Available Available Available Not available Available Available reproject geometry; Wherobots supports source+target CRS ST_AsEWKB Geometry Output / Export Available Available Available Not available Not available Available output EWKB (includes SRID) ST_AsEWKT Geometry Output / Export Available Available Available Not available Not available Available output EWKT ST_ClosestPoint Measurement Functions Available Not available Available Available Available Available return closest point on geom1 to geom2 ST_Collect Geometry Editors Available Available Available Not available Not available Available collects into multi-geometry ST_Covers Predicates / Topological Relationships Available Available Available Available Not available Available test if A covers B ST_GeoHash Geometry Output / Export Available Available Available Available Not available Available return geohash string ST_GeometryN Geometry Accessors Available Not available Available Not available Available Available returns the Nth geometry in a collection ST_HausdorffDistance Measurement Functions Available Available Not available Available Available Available Hausdorff distance with optional density ST_InteriorRingN Geometry Accessors Available Not available Available Not available Available Available return Nth interior ring of polygon ST_IsClosed Geometry Accessors Available Not available Not available Available Available Available checks if linestring is closed ST_IsRing Geometry Accessors Available Not available Not available Available Available Available checks if closed and simple Available Not available Show all 826 functions No functions match these filters. Check marks link to each platform’s documentation for the function. Sources, checked October 2026: the Wherobots function reference, Snowflake geospatial functions, Databricks ST and H3 functions, BigQuery geography functions, ArcGIS GeoAnalytics Engine 2.1 SQL, raster and track functions, and the PostGIS 3.6 reference and raster reference (functions only; operators, version and management functions and the SFCGAL, Topology and Tiger extensions are left out). Which platform fits your workload Raster plus vector at scale Wherobots fits teams whose work joins imagery, elevation or climate rasters with buildings, parcels, roads or assets, from one city to the whole planet. WherobotsDB runs zonal statistics and spatial joins in one engine, and RasterFlow turns imagery into features you can join. Vector analysis inside your warehouse Snowflake, Databricks and BigQuery fit teams adding point-in-polygon lookups, distance filters and H3 binning to data already in the warehouse, with no new platform to run. Raster statistics on Google Cloud BigQuery fits teams on Google Cloud that need statistics of Earth Engine rasters inside polygons, through ST_REGIONSTATS. One PostgreSQL database PostGIS fits applications and analysis that fit on one PostgreSQL server, such as a service that reads and writes features through the day. Esri teams on their own Spark ArcGIS GeoAnalytics Engine fits teams standardized on ArcGIS that already run Spark on Databricks, Amazon EMR, Azure Synapse or Google Cloud. Cloud geospatial analytics platform FAQ What is a cloud geospatial platform? A cloud geospatial platform stores and analyzes location data on managed cloud compute. It has spatial types and functions for vector data, such as points, lines and polygons. Many also handle raster data, such as satellite imagery and elevation. See what geospatial data is and what a geospatial database is. Which cloud geospatial database supports both vector and raster analysis? WherobotsDB has native vector and raster types, so one spatial SQL query can compute raster statistics inside vector polygons. BigQuery does the same for Earth Engine rasters with ST_REGIONSTATS. See WherobotsDB and raster vs. vector data. What are the top serverless options for spatial SQL analytics? Wherobots Cloud runs WherobotsDB serverless, BigQuery is a serverless query service, and Databricks offers serverless SQL warehouses. Of these, Wherobots and BigQuery also query raster data. Which cloud geospatial platforms support spatial SQL and Python? All of the platforms on this page support spatial SQL. Wherobots runs the same spatial functions from SQL, Python and Scala, Databricks through PySpark, Snowflake through Snowpark Python, and BigQuery through BigQuery DataFrames. Can RasterFlow results go into Snowflake, Databricks or BigQuery? Yes. Wherobots writes RasterFlow results to Iceberg tables in Databricks Unity Catalog, to Apache Iceberg tables in your S3 bucket that Snowflake reads, and to GeoParquet that BigQuery loads. Google Earth Engine is the imagery platform RasterFlow compares with most often; see RasterFlow vs. Google Earth Engine. Why do spatial joins get slow on general-purpose platforms? A spatial join compares geometries by location, so an engine without spatial partitioning compares far more pairs than it needs to. See what a spatial join is and the partitioning tax. Run your raster and vector workload on Wherobots Bring a query or a dataset and we will run it with you on Wherobots Cloud. Schedule use case review --- ## SedonaDB vs. DuckDB URL: https://wherobots.com/apache-sedona/sedonadb-vs-duckdb/ Updated: 2026-10-15 Comparison SedonaDB vs. DuckDB for spatial SQL on one machine SedonaDB and DuckDB both run spatial SQL on one machine. SedonaDB adds a geography type, coordinate reference system (CRS) checks before a query runs, spatial joins that spill to disk and raster functions. DuckDB adds spatial SQL to a general-purpose embedded database. Get started with SedonaDB Talk to us Single-node engines Both run in process on one machine. Spatial and KNN joins SedonaDB joins spill to disk. Raster and vector SedonaDB reads rasters in SQL. Feature comparison SedonaDB and DuckDB side by side Each answer comes from the project’s own documentation, release posts or repository, linked below the table. SedonaDB 0.5.0 and DuckDB 1.5.6 are the current releases. SedonaDB DuckDB SedonaDB and DuckDB side by side Capability Apache Sedona SedonaDB Single-node spatial engine in Rust, on Apache Arrow and DataFusion. Embedded database DuckDB In-process analytical database with the spatial extension. Engine and license Query engine What runs the SQL Built on Apache DataFusion (Rust); general-purpose SQL works alongside spatial functions DuckDB's own columnar-vectorized engine; spatial through the spatial extension Execution model Single node, written in Rust on Apache Arrow and Apache DataFusion In process, embedded in the host application License Apache License 2.0, an Apache Software Foundation project MIT, held by the DuckDB Foundation APIs SQL, Python (apache-sedona[db]), R and Rust SQL, Python, R, Rust, CLI, and clients for C, Java, Go, Node.js and Wasm Spatial types and functions Geometry type Included: Geometry Included: GEOMETRY, a built-in type since 1.5 Geography type Calculations on the sphere or spheroid Included: Geography, built on s2geography since 0.4.0 Partial: No geography type; _Spheroid functions such as ST_Distance_Spheroid Spatial functions Included: 212 functions in the SQL reference (141 ST_, 67 RS_), compatible with SedonaSpark Included: 158 functions in the spatial function index, including aggregate and table functions Coordinate reference system Included: CRS carried in the column type and read from Parquet; mismatched CRSs fail at planning Included: Optional CRS in the GEOMETRY type since 1.5; functions check that inputs share a CRS Raster data Raster functions in SQL Included: RS_ functions since 0.3.0, including RS_ZonalStats and RS_Clip Not included: Raster formats are not supported Raster and vector in one query Statistics of raster pixels inside vector polygons Included: RS_ZonalStats over polygons in SQL Not included: No raster support Spatial joins Spatial join Included: Spatial index join with automatic disk spilling for larger-than-memory joins Included: In-memory R-tree join; the right side must fit in memory KNN join Find the k nearest features to each record Included: ST_KNN in the join condition Not included: Not documented GPU acceleration Included: Optional GPU spatial join since 0.4 Not included: Not documented Data formats GeoParquet Included: Read, and write GeoParquet 1.1 Included: Read and write Parquet geometry and geography types Included: Write since 0.4.0 Not included: Not documented GeoArrow Included: GeoArrow integration Included: Arrow import and export since 1.5 GDAL vector formats Shapefile, GeoPackage, FlatGeobuf and more Included: Read and write through GDAL/OGR Included: ST_Read and COPY through GDAL Remote files Included: S3 and HTTPS Included: S3 read and write, HTTP(S) read Sources: Apache DataFusion; DuckDB Why DuckDB; SedonaDB repository, documentation, CRS examples, SQL joins and release posts for 0.3.0, 0.4.0 and 0.5.0; DuckDB why DuckDB, GEOMETRY type, spatial functions, GDAL integration, spatial joins, DuckDB 1.5.0 and httpfs. Checked October 2026. “Not documented” means the project’s documentation does not describe the capability. SpatialBench SpatialBench results on one machine The Apache Sedona project published these SpatialBench single-node results from a run on September 22, 2025. The run used SpatialBench v0.1.0, SedonaDB 0.1.0 and DuckDB 1.4.0 on an AWS EC2 m7i.2xlarge with 8 CPUs and 32 GB of RAM. Each query had a 1,200-second timeout. Times are in seconds at scale factor 10 and include loading data from Parquet. Both engines have shipped newer releases since. SedonaDB 0.1.0 DuckDB 1.4.0 SpatialBench results on one machine Capability Apache Sedona SedonaDB 0.1.0 Embedded database DuckDB 1.4.0 Scale factor 10 Queries completed 12 queries Included: 12 of 12 Partial: 9 of 12 Q1 distance filter ST_DWithin 3.04 4.58 Q2 point-in-polygon filter 8.89 8.26 Q5 convex hull aggregation 50.81 14.40 Q9 building self-join Intersection over union 0.38 942.98 Q10 spatial left join 42.02 Not included: Error Q11 multi-way spatial join 97.52 Not included: Error Q12 KNN join 145.66 Not included: Error Source: SpatialBench single-node benchmarks, which lists all 12 queries at scale factors 1 and 10, plus GeoPandas. SpatialBench comes from the Apache Sedona project, and SedonaDB is an Apache Sedona engine; the benchmark code is open at apache/sedona-spatialbench for anyone to rerun. Function reference Every spatial SQL function in SedonaDB and DuckDB Search 280 spatial SQL functions from the SedonaDB SQL reference and the DuckDB spatial function index, filter by vector or raster, and see which engine has each one. Functions match by name, and the same operation can have a different name in each engine, such as ST_GeomFromWKT in SedonaDB and ST_GeomFromText in DuckDB. Search functions Data type Vector and raster Vector Raster Availability All platforms Available in SedonaDB Available in DuckDB Only in SedonaDB Only in DuckDB Category All categories Affine Transformations Aggregate Functions Band Accessors Bounding Box Functions Engine Utilities Geography Type Functions Geometry Accessors Geometry Constructors Geometry Editors Geometry Output / Export Geometry Processing Geometry Validation Linear Referencing Measurement Functions Operators Output Overlay Functions Pixel Functions Predicates / Topological Relationships Raster Accessors Raster Constructors Raster Functions Raster Geometry Functions Spatial Indexing Spatial Reference System Table Functions Tiles 280 functions Function Category SedonaDB DuckDB What it does DuckDB_PROJ_Compiled_Version Engine Utilities Not available Available Returns a text description of the PROJ library version that this instance of DuckDB was compiled against. DuckDB_Proj_Version Engine Utilities Not available Available Returns a text description of the PROJ library version that is being used by this instance of DuckDB. RS_AsGeoTiff Output Available Not available Encodes a raster as a GeoTIFF and returns the bytes as binary, with optional compression and tiling. RS_AsRaster Operators Available Not available Rasterizes a geometry using the grid of a reference raster. RS_BandIsNoData Band Accessors Available Not available Returns true if every pixel of the band holds the band’s nodata value. Returns false if any pixel holds data, or if the band has no nodata value. RS_BandNoDataValue Band Accessors Available Not available Returns the nodata value of the specified band as a double. Returns null if the band has no nodata value defined. RS_BandPath Raster Accessors Available Not available Retrieves the file path of an out-of-database (out-db) raster band, returning the external raster file location referenced by the raster. RS_BandPixelType Band Accessors Available Not available Returns the pixel data type of the specified band as a string. RS_BandToDim Raster Functions Available Not available Collapses all bands into a single band with a new dimension. RS_Clip Operators Available Not available Clips a raster to a geometry, setting pixels outside the geometry to nodata and (by default) cropping to the geometry’s bounding box. RS_Contains Predicates / Topological Relationships Available Not available Returns true if the first argument’s extent contains the second. RS_ConvexHull Raster Geometry Functions Available Not available Returns the convex hull geometry of a raster. RS_CRS Operators Available Not available Returns the CRS string for a raster. RS_DimNames Raster Functions Available Not available Returns the ordered list of dimension names for a raster band. RS_DimSize Raster Functions Available Not available Returns the size of a named dimension in a raster band. RS_DimToBand Raster Functions Available Not available Promotes a within-band dimension into separate bands. RS_Envelope Raster Geometry Functions Available Not available Returns the envelope (bounding box) of a raster as a geometry. RS_Example Raster Functions Available Not available Creates a simple example raster for testing and demos. RS_FromGDALRaster Raster Functions Available Not available Decodes a GDAL-readable raster (e.g. a GeoTIFF) from binary content into an in-database raster. RS_FromPath Raster Constructors Available Not available Creates an out-of-database raster from a raster file path. RS_GeoReference Raster Accessors Available Not available Returns the georeference metadata of raster as a string in GDAL or ESRI format as commonly seen in a world file. Default is GDAL if not specified. Both formats output six lines: scalex, skewy, skewx, scaley, upperleftx, upperlefty. In GDAL format the upper-left coordinates refer to the corner of the upper-left pixel, while in ESRI format they are shifted to the center of the upper-left pixel. RS_GeoTransform Raster Accessors Available Not available Returns the raster’s geotransform decomposed into a struct of six doubles, matching Sedona Spark’s RS_GeoTransform: magnitudeI and magnitudeJ (pixel sizes along the transformed i and j axes), thetaI (rotation of the raster in radians, positive clockwise), thetaIJ (angle from the transformed i axis to the transformed j axis in radians, positive counter-clockwise), and offsetX and offsetY (the upper-left corner of the upper-left pixel). For the raw affine coefficients instead of this decomposition, use the individual accessors (RS_ScaleX, RS_SkewX, RS_UpperLeftX, …) or RS_GeoReference. RS_Height Raster Accessors Available Not available Returns the height of a raster in pixels. RS_Intersects Predicates / Topological Relationships Available Not available Returns true if the extents of the two arguments intersect. RS_IsEmpty Raster Functions Available Not available Returns true when the raster has zero visible volume — some dimension has length 0, so it holds no cells. This is visible-volume emptiness, not byte-emptiness: a lazy raster whose pixels are resolved on demand carries no bytes but is not empty. RS_MakeEmptyRaster Raster Constructors Available Not available Creates an in-database raster from a grid definition: a pixel count, a placement (an extent geometry, or an upper-left corner with pixel size or a full affine transform), and a number of zero-filled bands. Use it to define a target grid for RS_AsRaster or as a template for other rasters. RS_MetaData Operators Available Not available Returns raster metadata as a struct. RS_MinConvexHull Raster Geometry Functions Available Not available Returns the footprint of the raster’s data pixels: the polygon over the smallest pixel-aligned rectangle of the grid that holds every pixel not equal to its band’s nodata value. Returns null if no pixel holds data. RS_NumBands Operators Available Not available Returns the number of bands in the raster. RS_NumDimensions Raster Functions Available Not available Returns the number of dimensions in a raster band. RS_PixelAsCentroid Pixel Functions Available Not available Returns the centroid of the specified pixel as a Point geometry. RS_PixelAsPoint Pixel Functions Available Not available Returns the upper-left corner of the specified pixel as a Point geometry. RS_PixelAsPolygon Pixel Functions Available Not available Returns the bounding polygon of the specified pixel. RS_Polygonize Pixel Functions Available Not available Converts a raster band into polygons grouped by connected pixel value regions. RS_RasterToWorldCoord Raster Accessors Available Not available Converts raster pixel coordinates to world coordinates as a point. RS_RasterToWorldCoordX Raster Accessors Available Not available Converts raster pixel coordinates to world X coordinate. RS_RasterToWorldCoordY Raster Accessors Available Not available Converts raster pixel coordinates to world Y coordinate. RS_ReplaceBandNoDataValue Raster Functions Available Not available Moves a band’s nodata value to a new value, carrying the nodata pixels with it: every pixel that reads as nodata is rewritten to the new value, which then becomes the band’s nodata, so the same pixels read as nodata before and after. RS_ReprojectMatch Operators Available Not available Reprojects a raster onto a reference raster’s CRS, grid, and extent. RS_Resample Operators Available Not available Resamples a raster onto a new pixel grid — a new width/height, a new pixel size, and/or a snapped origin — in the same CRS. RS_Rotation Raster Accessors Available Not available Returns the raster rotation in radians based on skew parameters. RS_ScaleX Raster Accessors Available Not available Returns the pixel width (scale X) of a raster. RS_ScaleY Raster Accessors Available Not available Returns the pixel height (scale Y) of a raster. RS_SetBandNoDataValue Operators Available Not available Sets the nodata value of the specified band, packing the value into the band’s native data type. A null raster or band yields a null raster; a null nodata value instead clears the addressed band’s nodata. This is metadata-only: raster cell values are not modified. RS_SetCRS Operators Available Not available Sets the Coordinate Reference System (CRS) for a raster. RS_SetGeoReference Operators Available Not available Sets the affine geotransform of a raster from a world-file georeference string of six whitespace-separated numbers in the order scalex, skewy, skewx, scaley, upperleftx, upperlefty — the same order RS_GeoReference emits. The format is ‘GDAL’ (default) or ‘ESRI’; in GDAL the upper-left coordinates refer to the corner of the upper-left pixel, while in ESRI they refer to its center. The transform can also be given as six numeric arguments instead of a string, always as GDAL/corner coordinates. This is metadata-only: raster cell values are not resampled. RS_SetSRID Operators Available Not available Sets the SRID (spatial reference identifier) for a raster. RS_SetValue Operators Available Not available Returns the raster with one pixel of a band set to a new value. RS_Shape Raster Functions Available Not available Returns the shape (size of each dimension) of a raster band. RS_SkewX Raster Accessors Available Not available Returns the X skew (rotation) parameter of a raster. Available Not available Show all 280 functions No functions match these filters. Check marks link to each engine’s documentation for the function. Sources: the SedonaDB SQL reference and the DuckDB spatial function index, checked October 2026. Which engine fits your work Spatial filters inside an application DuckDB fits teams that already embed DuckDB and need point-in-polygon and distance filters on data that fits on one machine, from any of its language clients. Spatial joins, geography and rasters on one machine SedonaDB fits spatial joins and k-nearest-neighbor (KNN) joins larger than memory, calculations on the sphere, columns that must keep their CRS, and raster statistics inside polygons. It runs from SQL, Python, R or Rust. The same engine runs the non-spatial joins, aggregations and window functions in the pipeline, through Apache DataFusion. Workloads larger than one machine SedonaDB functions are compatible with SedonaSpark, so the same spatial SQL moves to a cluster. Wherobots Cloud runs it fully managed, with 389 spatial SQL functions and RasterFlow. See the Wherobots vs. Apache Sedona comparison. SedonaDB vs. DuckDB FAQ What is SedonaDB? SedonaDB is a single-node analytical engine from the Apache Sedona project, written in Rust on Apache Arrow and Apache DataFusion, with geometry and geography as core types. It is free under the Apache License 2.0 and installs with pip install "apache-sedona[db]". Can SedonaDB run regular SQL, not just spatial queries? Yes. SedonaDB is built on Apache DataFusion, a general-purpose SQL query engine written in Rust, so joins, aggregations and window functions run in the same queries as spatial functions. See the SedonaDB documentation and the DataFusion SQL reference. Does DuckDB support spatial data? Yes. GEOMETRY is a built-in DuckDB type since version 1.5, and the spatial extension adds ST_ functions, an R-tree index and GDAL vector file formats. It does not read raster formats. Which is faster for spatial joins, SedonaDB or DuckDB? In the published SpatialBench run at scale factor 10, SedonaDB 0.1.0 completed all 12 queries. DuckDB 1.4.0 returned errors on the spatial left join, the multi-way join and the KNN join. DuckDB was faster on the convex hull aggregation. Both engines have released newer versions since that run. Can SedonaDB and DuckDB read GeoParquet? Yes. Both read and write GeoParquet, and SedonaDB also writes the native Parquet geometry and geography types. When does a single-node engine stop being enough? When the data or a join outgrows one machine, a distributed engine splits the work across a cluster. SedonaDB functions are compatible with SedonaSpark, and WherobotsDB runs the same spatial SQL fully managed in Wherobots Cloud. See what a spatial join is. Who builds SedonaDB? SedonaDB is part of Apache Sedona, an Apache Software Foundation project. Engineers at Wherobots, founded by the original creators of Apache Sedona, contribute to it alongside the Sedona community. Take your spatial SQL from one machine to a cluster Bring a SedonaDB or DuckDB query and we will run it with you on Wherobots Cloud. Schedule use case review --- ## Utility Vegetation Management at Scale with Earth Intelligence URL: https://wherobots.com/blog/utility-vegetation-management-earth-intelligence/ Updated: 2026-10-19 Modern computer vision models and new tooling make open and proprietary Earth observation data practical for observing risk remotely, at scale. With Wherobots RasterFlow, teams and AI agents can build risk measurement solutions on demand from these datasets in a couple of hours. The solutions run as an extension of your existing data platform. Pricing is usage-based and predictable, on a platform built for physical world data, scale and interoperability. Companies traditionally book environmental risk as a cost line they cannot control, and this line keeps growing. According to Swiss Re, insured losses from natural catastrophes reached $107B in 2025, the sixth straight year above $100B. The Los Angeles wildfires alone cost $40B. Wildfire, flood and extreme weather risks compound with geopolitical and social change, and the economic costs follow suit. Nature carries risk, and so do human activities. But both have elements that can be observed. Teams can monitor flammable vegetation that encroaches on power lines and fuel levels, to predict the damage a wildfire is likely to cause. They can also monitor changes in land development and use. Each of these needs Earth observation (EO) data, images of the ground taken from satellites or aircraft, to observe conditions remotely. It also needs tools that measure physical world conditions over time. Open and proprietary EO data is growing more available. Wherobots RasterFlow lets teams experiment with this data and computer vision models for imagery quickly, and ship production-ready solutions in days, without building infrastructure first. Key takeawaysWherobots mapped the trees that could reach overhead transmission lines in King County, Washington and Shasta County, California, from open aerial imagery and Meta’s canopy height model.Of the trees that could reach the lines, 25.7% stand 10 to 20 m from the line in King County, compared to 5.6% in Shasta County.King County’s lines run through far more tall trees within falling distance than Shasta County’s.Claude Code ran each county’s analysis in under an hour, at a Wherobots cost of about $40 for King County and about $30 for Shasta County at public pricing.The result can be a critical input to a risk model. It does not measure wildfire or wind risk on its own. Utility vegetation management: which trees can reach a power line? Utility vegetation management is the work of keeping trees and other plants clear of power lines. A utility with transmission lines through forest needs to know how tall the trees near each line are, to keep service safe and reliable. Trees and other vegetation, if close enough, can come in contact with a conductor, the wire that carries the current, particularly when wind moves them. Those trees are fire fuel and an outage risk, and the risk grows with the number of homes nearby. From a single prompt, Claude Code exercised Wherobots and measured the trees along the overhead transmission lines of two counties in different states: King County, Washington and Shasta County, California. Wherobots processed open data, and the full analysis completed in under an hour. The method was the same in both counties, so the differences in the results represent differences in the state of the canopy and its distance to the power lines. Start with open imagery and asset data. The power lines came from an Open Infrastructure Map export of 105,147 US transmission lines. We kept each county’s overhead lines and cut each line into segments of about 100 m. The imagery is each county’s latest National Agriculture Imagery Program (NAIP) flight at 60 cm per pixel: 2023 for King County and 2022 for Shasta County. Overture Maps supplied the building footprints. Prepare the imagery. RasterFlow prepared the NAIP imagery for the model. It stitched the NAIP scenes along each county’s lines into one mosaic, a single image with no seams between scenes. Newer, higher-resolution imagery with more coverage can replace NAIP. We chose NAIP because it is free and its resolution is high enough for Meta’s canopy height model. Run the model. RasterFlow ran Meta’s Canopy Height Model (CHM v1) across each mosaic on GPUs. The output is a canopy height raster: a grid with the height of the tree canopy for every 0.6 m pixel. The maps below show it. Score each line segment. WherobotsDB drew four strips of ground, called zones, on each side of every line segment: 0 to 10, 10 to 20, 20 to 30 and 30 to 45 m from the line. For each zone, RS_ZonalStatsAll measured how tall the trees in it are on the canopy height raster. This is a raster-to-vector join: the zones are vector shapes, and the heights come from the raster. A zone is flagged when its trees are tall enough to fall onto the line. Each segment then got a risk score that rises with its number of flagged zones and the number of buildings within 100 m. The segments were ranked by that score. Inspect the results. A Wherobots GL map layers the NAIP mosaic, the canopy height raster, the flagged zones, and each segment colored by its risk score. The maps for King County and Shasta County are below. Link to visualization: King County Link to visualization: Shasta County Tree risk to power lines: King County vs. Shasta County King County’s lines run through far more tall canopy within falling distance of the power lines. Of the trees that could reach the lines in King County, 25.7% stand 10 to 20 m from the line, compared to 5.6% in Shasta County. Share of line segment sides with trees that could reach the line, by distance from the line. Source: Wherobots analysis of NAIP imagery (King County 2023, Shasta County 2022) with Meta’s Canopy Height Model. Wildfire and wind risk This comparison measures where trees could reach a line today. It does not measure the risk of a wildfire or a windstorm. But it can be used as a critical input to a risk model. You could take the next step by layering in live wildfire risk with RasterFlow, by measuring NDVI, a measure of how green and dense vegetation is, ground surface temperature, and other elements. Or you could easily incorporate a prevailing wind filter to hone in on the power line segments that are at risk of tree-fall from high, prevailing winds. Wildfire and severe wind may become more frequent west of the Cascades as the climate changes. If they do, King County’s lines start from a position with roughly four times Shasta County’s share of reachable trees. Many of those trees stand near homes. From this foundation, you can identify the highest risk and highest impact opportunities to tackle next. You can also put it into operation with fresh, high-resolution imagery with the coverage you need. Earth Intelligence for utilities in days Claude Code ran each county’s analysis in under an hour. At public pricing, the Wherobots cost was about $40 for King County and about $30 for Shasta County. It also shows how companies can use AI with Wherobots to build Earth Intelligence solutions like this one quickly, without building and running their own data and AI infrastructure. Their existing AI agents drive Wherobots directly. That cuts the time to a working Earth Intelligence solution, and the results go into the data platforms you already use. How to get started Want to talk about infrastructure risk management? Reach out to schedule a conversation with the experts. Get started at $0 with the Professional EditionThe plan includes every capability builders need to ship solutions from spatial data. Start at $0 with a 14-day free trial that covers up to $95 of usage. In that time you can connect a catalog, run the canopy height model over your own lines, and write the first Iceberg table back to Databricks, AWS Glue or another S3-based lakehouse. Frequently Asked Questions What is utility vegetation management? Utility vegetation management is the work electric utilities do to keep trees and other plants clear of power lines. Trees that touch a line can cause outages and start fires. Imagery and a canopy height model show where trees are tall enough to reach a line. How do you find trees that could fall on power lines from imagery? In this analysis, RasterFlow ran Meta’s Canopy Height Model on 60 cm NAIP aerial imagery to get a tree height for every 0.6 m pixel. WherobotsDB drew zones 0 to 10, 10 to 20, 20 to 30 and 30 to 45 m from each line segment of about 100 m. A zone was flagged when its trees were tall enough to fall onto the line. What is a canopy height model? A canopy height model is a raster that gives the height of the tree canopy above the ground for each pixel. Meta’s Canopy Height Model estimates that height from ordinary color imagery.Tolan and colleagues (2024) trained it on aerial lidar. In this analysis it produced a height for every 0.6 m pixel of NAIP imagery. How long does the analysis take, and what does it cost? Claude Code ran each county’s analysis in under an hour. At public pricing, the Wherobots cost was about $40 for King County, Washington and about $30 for Shasta County, California. The Professional Edition starts at $0 with a 14-day free trial that covers up to $95 of usage. Which county has more trees within reach of its power lines? King County, Washington. Of the trees that could reach the lines in King County, 25.7% stand 10 to 20 m from the line, compared to 5.6% in Shasta County, California. King County’s lines start with roughly four times Shasta County’s share of reachable trees. --- ## Putting the HERE Technologies and Wherobots partnership to work URL: https://wherobots.com/blog/here-wherobots-wildfire-evacuation-routes/ Updated: 2026-10-19 Today, October 14, 2026, Wherobots and HERE Technologies announced a strategic partnership to give AI agents geospatial intelligence. The first step brings HERE Location Reasoning (HLR) into the Wherobots MCP server. Through one connection, an agent can now run large-scale spatial analysis in Wherobots and call HERE for geocoding, routing, live traffic and drive-time maps. Key takeawaysOn October 14, 2026, Wherobots and HERE Technologies announced a strategic partnership to give AI agents geospatial intelligence. The first step brings HERE Location Reasoning (HLR) into the Wherobots MCP server.Through one connection, an agent can run large-scale spatial analysis in Wherobots and call HERE for geocoding, routing, live traffic and drive-time maps.Wherobots scored all 357,554 transmission spans in California for wildfire exposure. 22,420 of them, 6.3%, score 6 or more and sit in a CPUC High Fire Threat District.HLR returned 21 routes out of Mount Hermon, a forest town of about 4,200 people. Every one runs within 330 feet (100 m) of a high-risk span for 0.79 to 2.04 miles.Halving the exposure costs about 17 to 21 minutes of driving. The least exposed route down to the coast takes more than twice as long as the fastest.Claude Code ran the workflow through the Wherobots MCP Server: Wherobots for spatial joins and risk scores, HLR for routes and drive-time areas. The author built the California Grid Wildfire app in under three weeks, part-time. This post puts that integration to work on one problem: wildfire evacuation routes in California. Identifying wildfire evacuation routes in California Every road out of Mount Hermon, a forest town of about 4,200 people in California’s Santa Cruz Mountains, runs beside high-risk power lines. The least exposed route down to the coast takes more than twice as long as the fastest. Claude Code (Opus 5.5), Wherobots, and HERE Location Reasoning (HLR) made that analysis easy. Wherobots scored every transmission span in California for wildfire exposure and flagged the communities whose roads most likely used in an evacuation run beside the riskiest lines. HLR computed the evacuation routes and drive times. Utilities must choose which lines to maintain first, and counties plan evacuations. For both, that trade-off can be the difference between a community at risk and residents who get out safely. A utility’s wildfire mitigation team ranks its transmission lines by risk score. A county emergency planner maps the roads people use to evacuate. Join those two maps and you can answer two questions: Miles at risk. When people have to leave town because of a wildfire, how many miles of their way out run beside high-risk power lines? Minutes to avoid them. How much driving time does a less exposed road add? A span is the stretch of line between two towers. A high-risk span scores high for wildfire exposure and sits inside a state-designated fire threat district. Mount Hermon shows how this works. HLR returned 21 routes from the town to four destinations. Every one of them runs within 330 feet (100 m) of a high-risk span for 0.79 to 2.04 miles. The app at Mount Hermon: spans colored by risk score (red is 6 or more), with HLR routes out of town and the 15, 30 and 60 minute drive-time areas. Open the full map ↗ AI coding tools harnessed to Wherobots unlock answers, fast If you’d asked me a year ago whether I could do an analysis like this, I probably would have stared at you, or maybe chuckled. Over the last few weeks I used Wherobots to score all 357,554 transmission spans in California against vegetation, terrain, fuels and buildings. HLR computed the routes on HERE’s road network. I didn’t need a master’s degree in distributed computing or geospatial analytics. All I had to do was connect Claude Code to Wherobots and HLR. I built the California Grid Wildfire app, which joins those scored spans with the main transportation and evacuation corridors, in under three weeks, part-time. How the workflow runs Score every span and count the people near it, in Wherobots. The agent joined satellite and elevation grids to each span, and Census population counts to the buildings nearby. Compute the routes, in HLR. It asked HLR for evacuation routes and alternatives, timed each one at typical rush hour, and mapped how far a car gets in 15, 30 and 60 minutes. Measure the overlap, in Wherobots. It measured how much of each route and drive-time area runs beside high-risk spans. Claude runs all three steps through one endpoint, the Wherobots MCP Server. Through it, the agent reaches Wherobots for large-scale spatial joins and risk scores, and HLR for address lookup, routing and drive-time areas. HLR can be called at any time for real-time conditions. Without these tools, each step would require far more time and effort. Scoring every transmission span in Wherobots The app covers every transmission span in California that Overture Maps Foundation’s infrastructure data includes, from any operator. For each span, Wherobots draws a corridor about 100 feet (30 m) either side of the line. It then summarizes four raster layers inside that corridor. A raster is a grid of values that covers the state: Fuels: the US Forest Service Wildfire Hazard Potential raster. Vegetation vigor: the Normalized Difference Vegetation Index (NDVI), which measures how green and dense plants are. It is a seasonal median from Sentinel-2 satellite imagery. These can be run on more frequent imagery, based on what the system has access to. Canopy: the tallest trees in the corridor, from Meta’s Global Canopy Height map. You can also run the Meta tree canopy height model on demand in Wherobots RasterFlow, with more recent imagery. Slope: from the Copernicus elevation model, whose cells are about 100 feet (30 m) across. The Meta model is one of several models in RasterFlow today. All four layers can be built with trained models in RasterFlow or using WherobotsDB and refreshed as often as new satellite imagery arrives and with what’s practical. Wherobots then counts the buildings inside the same corridor. The four layers and the building count add up to a score from 0 to 9. A span with any missing input is marked “insufficient data” and is never scored as zero. Of the 357,554 spans, 329,303 (92.1%) have a score. The California Public Utilities Commission (CPUC) draws High Fire Threat Districts (HFTD) in two tiers: Tier 2 (elevated) and Tier 3 (extreme). In this post, a high-risk span scores 6 or more and sits in Tier 2 or Tier 3. California has 22,420 of them, 6.3% of all transmission spans. Every scored transmission span in California, summarized into hexagons. Darker hexagons hold a larger share of spans scoring 6 or more. Dashed outlines are the CPUC fire-threat districts. Open the full map ↗ Wherobots also estimates who lives near those spans. It takes population counts for each Census block group, a neighborhood of roughly 600 to 3,000 people, from the American Community Survey. It spreads each block group’s people over its buildings. People in buildings within 1.2 miles (2 km) of a high-risk span count as living near one. In Mount Hermon, that is all 4,249 residents and all 1,720 mapped buildings. Computing the routes in HLR The agent used HLR for 341 routes, each timed with no traffic and at typical rush hour, plus 54 drive-time areas. The app shows 115 routes from 17 communities to 18 fairgrounds and event centers. It also shows 189 routes from 100 neighborhoods where many people may need help evacuating. For each community, the agent called HLR tools in this order: geocode turned each destination’s address into map coordinates. The agent kept a destination only if it sits at least 1.2 miles from every Tier 2 or Tier 3 span scoring 5 or more. That rule dropped the Santa Cruz Civic Auditorium (1.1 miles away) and Oroville city hall (0.9 miles). calculate-route returned the fastest car route to each destination and up to six alternatives, with no traffic. Reroutes. calculate-route has no option to avoid an area. So the agent forced each reroute through a via point, a stop the route must pass. Each via point sits on an exit with fewer high-risk spans: Felton Empire Road, Heller Drive, Empire Grade or McLaughlin Drive. get-route-from-polyline re-timed each route on the same path, at HERE’s typical traffic for a Tuesday at 8:00 and 17:00 Pacific time. Because the path stays the same, any change in minutes comes from traffic. isoline-route mapped the area a car can reach in 15, 30 and 60 minutes, called an isochrone. The agent also ran it from one starting point in each of the eight large cities with the most people near high-risk spans. The routes and drive-time areas are published as GeoJSON when using HLR, a standard map data format. Measuring each route’s exposure in Wherobots HLR returns each route as an encoded polyline, a compact text string of coordinates. Wherobots decodes each string and converts it to a California map projection measured in meters. It then measures how much of the route lies within 330 feet (100 m) of a high-risk span. The same query also gives the roads involved. For each drive-time area, Wherobots measures the length of high-risk line inside it: the line within reach of people as they start to leave. A span inside the area may sit on a road nobody drives in an evacuation scenario, so this number does not describe a single route. What came back Every route out of Mount Hermon runs past high-risk spans Route from Mount HermonDistance (mi)No traffic (min)Tue 8:00 (min)Tue 17:00 (min)Beside high-risk spansBoardwalk, fastest (Graham Hill Road)7.6715.116.417.61.67 mi, 19 spansBoardwalk, via Felton Empire Rd and Heller Dr16.4032.436.838.40.79 mi, 11 spansCapitola, fastest10.9518.620.527.21.67 mi, 19 spansCapitola, HLR alternative via State Route 912.7323.725.733.10.85 mi, 12 spansSanta Cruz County Fairgrounds, fastest25.0733.336.853.61.91 mi, 24 spans Halving the exposure costs about 17 to 21 minutes. The Felton reroute to the Boardwalk adds 17.3 minutes with no traffic, 20.4 at the 8:00 peak and 20.8 at the 17:00 peak. For Capitola, HLR’s own alternative is the better trade. The State Route 9 route adds 5.1 minutes (5.9 at the 17:00 peak) for 0.85 miles of exposure. The forced reroute adds about 20 minutes for 0.79 miles. No route reaches zero. Every route leaves town on Conference Drive, which runs past high-risk spans for 690 to 1,510 feet. Traffic matters most on the longest trip. The fastest route to the Fairgrounds goes from 33.3 minutes with no traffic to 53.6 minutes at a typical 17:00 peak. Within a 15-minute drive of Mount Hermon, HLR’s drive-time area covers 81.4 square miles and holds 323 high-risk spans, 21.85 miles of line. Two ways from Mount Hermon to the Santa Cruz Beach Boardwalk. Dark blue is HLR’s fastest route, down Graham Hill Road; green is the reroute west through Felton. Red and orange lines are spans colored by risk score; dashed blue lines are drive-time areas. The Boardwalk is a reference point, not an evacuation center. Open the full map ↗ Paradise and Magalia ridge at two score thresholds Paradise is the town the 2018 Camp Fire destroyed, a fire that started at a transmission line. Here the threshold changes the answer. At the high-risk cut of 6 or more, no route from Paradise or Magalia ridge passes within 330 feet of a high-risk span. Only 55 Paradise residents live within 1.2 miles of one. By that measure the ridge looks clear. Lower the cut to 5, and 2,187 Paradise residents live within 1.2 miles of a qualifying span. Most routes out pass those spans on Skyway Road or State Route 191. In HFTD Tier 2 or 3, a 5 is still a serious score, so the app shows both cuts. At a composite of 5: Paradise to Chico: HLR returned a single route. It takes 16.1 minutes and runs 0.35 miles beside five Tier 2 spans on Skyway Road. Paradise to Gridley: the fastest route takes 35.9 minutes with 0.12 miles exposed. HLR’s second alternative takes 41.1 minutes and has no measured exposure at either threshold: about 5 minutes more (+5.2 with no traffic, +4.9 at the 17:00 peak). Magalia ridge to Gridley: the alternative with no measured exposure costs under a minute (+0.9 with no traffic, +0.7 at the 17:00 peak). Routes out of Paradise, highlighted in pink: to Chico on Skyway Road, and to Gridley by HLR’s fastest route (dark blue, center) and its second alternative (east, through Oroville). Hatched areas are neighborhoods in California’s top 25% for residents who may need help evacuating. None fall inside Paradise; the nearest are around Oroville. Open the full map ↗ Drive-time reach in eight large cities In each large city, the agent placed the starting point in the block group with the most people near high-risk spans. Oakland’s 15-minute area holds the most high-risk line: 70.53 miles across 464 spans in 281.9 square miles. Santa Clarita’s holds 32.33 miles and Glendale’s 32.09 miles. Each city has a single starting point, so these figures describe one neighborhood, not the whole city. Who may need help leaving A drive time assumes everyone can get in a car and go. Many people can’t. California law calls people who may struggle to evacuate in an emergency the access and functional needs (AFN) population. Counties must plan for them in evacuation, sheltering and emergency alerts, and utilities address them in their wildfire and power-shutoff plans. The definition covers: older adults children people with disabilities or chronic conditions people with limited English people with low incomes people without a car or who depend on transit pregnant people people in institutions people experiencing homelessness The law names the groups but gives no way to score a place. So the agent used Wherobots to score every California block group with the method the state already uses for CalEnviroScreen, its tool for ranking communities by pollution burden: Six measured groups. From the Census Bureau’s American Community Survey: older adults (65+), children (under 18), disability, limited-English households, people below the poverty line, and households without a car or workers who commute by transit. Pregnancy, institutional settings and homelessness aren’t measured at neighborhood scale, so the app lists them as “not measured” rather than zero. Statewide percentiles, averaged. Each group’s share becomes a statewide percentile. The percentiles are averaged and ranked again, and the top 25% are flagged, the same cut CalEPA uses for disadvantaged communities. Reliable estimates only. Where a block-group estimate fails CalEnviroScreen’s reliability rule, the surrounding census tract’s value is used and labeled “tract-wide”. With the same building-based count, Wherobots counted at least these numbers within 1.2 miles of a high-risk span: 768,000 older adults; 438,000 people with a disability; 61,000 households without a car; 535,000 people in top-25% AFN neighborhoods, across 565 neighborhoods. Los Angeles County has the most. Highland Park and Mount Washington, northeast Los Angeles. Hatched neighborhoods rank in California’s top 25% for access and functional needs, and several sit right beside spans scoring 6 or more. In one, all 1,371 residents live within a third of a mile of a high-risk span, the nearest about 75 feet away: 36% are 65 or older, one in five households has limited English, and 15% have no car. Open the full map ↗ HLR then routed the 100 top-25% neighborhoods with the most residents near high-risk spans to up to two fairgrounds each, in different directions. That gave 189 routes, timed the same way as before. Of these, 59 run within 330 feet of a high-risk span. The most exposed run from Ventura County neighborhoods to the Antelope Valley Fairgrounds (2.5 miles beside high-risk spans) and from Lake County neighborhoods to the Sonoma County Fairgrounds (2.3 miles). The score ranks neighborhoods. It does not count the people who need help, and a neighborhood outside the top 25% may still have residents in need. The people counts are modeled minimums. A drive time does not help a household without a car, so the app shows the share of those households next to each route. Explore it in the app The California Grid Wildfire app is one HTML page. It draws its maps with MapLibre GL JS, an open-source map library, from tile files stored on Amazon S3. Wherobots vector tile generation (VTiles) built those tiles as PMTiles archives, for the whole state, in minutes. Ask the map. A Claude copilot flies the map, switches layers and finds the top spans in view. “Ask the data” runs SQL queries inside your browser with SedonaDB, over a published copy of the span data. The in-browser engine is CereusDB, a WebAssembly build of Apache SedonaDB created by Tobi (tobilg). How it was built with Claude Code I built the app and the pipeline with Claude Code between 22 September and 13 October 2026, across 48 merged pull requests. Each result in the repository records the Wherobots query that produced it. Along the way, the agent worked around two gaps: A missing function. The SQL session had no function to decode HLR’s route strings. The agent wrote the decoding in plain SQL and checked the query plan before running it. A missing option. HLR’s calculate-route call has no way to block off an area. To steer a route around the riskiest power lines, the agent added stops on other roads for the route to pass through. WherobotsDB then measured how exposed each new route was. Where the app is today As of mid October 2026 the app covers the whole state, and it is live in two places: the California Grid Wildfire app and its page on wherobots.com. The live app now includes: A score for every span. People, buildings and fire history. Evacuation routes for 17 communities. Neighborhoods that may need help evacuating. Questions in plain English. A layout for anyone, on any screen. The data is a snapshot, not a live feed. Most of its sources change about once a year: Census estimates each December, CAL FIRE’s fire perimeters each spring and the vegetation season each fall. Scheduled refreshes and current-season fire perimeters will follow once the data already in the app has been checked further. What comes next Next come live traffic on the exit roads and HLR routes for more communities. The HLR integration will be available soon through Wherobots Spatial AI Tools and the Wherobots MCP Server. If you are interested in early access contact us on our Wherobots + HERE partnership page. Reach out to get early access to HLR in Wherobots. Contact us This build routes residents leaving by car. Routing the crews who inspect and repair the lines is an easy addition with HLR: the same routing calls handle truck rules and seasonal road closures. Wherobots would then measure each crew route against high-risk spans, the same way it measures evacuation routes. Today’s score measures exposure. It is not an ignition probability, and it leaves out fire weather and live fire detections on purpose. Wherobots is working with the US Forest Service on the FireCon model, which delivers wildfire risk and potential control locations across the western United States, updated daily. Potential control locations are the ridges, roads and other features where firefighters can stop a fire’s spread. That work can feed this app as another layer, both for analysis and in real time, and it would extend the same approach beyond California. If you run wildfire mitigation for a utility or evacuation planning for a county, open the app at Mount Hermon and compare its routes to the fairgrounds. Then contact us on the HERE and Wherobots partner page for early access, and run the same workflow on your territory. Frequently Asked Questions What is HERE Location Reasoning? HERE Location Reasoning (HLR) is a set of HERE routing and location tools that an AI agent can call. In this analysis it turned destination addresses into map coordinates and computed car routes and alternatives. It also timed each route at typical rush hour and mapped how far a car gets in 15, 30 and 60 minutes, called an isochrone. How does Wherobots score wildfire risk for a transmission line? Wherobots draws a corridor about 100 feet (30 m) either side of each span. A span is the stretch of line between two towers. Inside that corridor it summarizes four raster layers: fuels, vegetation vigor, tree canopy height and slope.Vegetation vigor is NDVI, a measure of how green and dense plants are, from Sentinel-2 satellite imagery. Wherobots also counts the buildings in the corridor, and together these give a score from 0 to 9.Of California’s 357,554 transmission spans, 329,303 (92.1%) have a score. A span with any missing input is marked “insufficient data”. What counts as a high-risk span? In this analysis, a high-risk span scores 6 or more and sits in a California Public Utilities Commission (CPUC) High Fire Threat District, Tier 2 (elevated) or Tier 3 (extreme). California has 22,420 of them, 6.3% of all transmission spans. How exposed are the evacuation routes out of Mount Hermon? HLR returned 21 routes from Mount Hermon to four destinations. Every one runs within 330 feet (100 m) of a high-risk span for 0.79 to 2.04 miles. No route reaches zero, because every route leaves town on Conference Drive.Halving the exposure costs about 17 to 21 minutes of driving. You can compare the routes in the California Grid Wildfire app. How did the agent find routes that avoid high-risk lines? HLR’s calculate-route has no option to avoid an area. So the agent forced each reroute through a via point, a stop the route must pass.Each via point sits on an exit with fewer high-risk spans, such as Felton Empire Road or Empire Grade. Wherobots then measured how much of each reroute runs beside high-risk spans. How do the AI agent, Wherobots and HLR work together? MCP (Model Context Protocol) is a standard way for an AI agent to call outside tools. Claude Code, the AI agent, connects to one MCP endpoint: the Wherobots MCP Server. Through it, the agent reaches Wherobots for large-scale spatial joins, risk scores and route exposure, and HLR for address lookup, routing and drive-time areas. How many people near high-risk lines may need help evacuating? Wherobots counted at least 535,000 people in California’s top 25% of neighborhoods for access and functional needs living within 1.2 miles (2 km) of a high-risk span, across 565 neighborhoods. Access and functional needs is California’s term for people who may struggle to evacuate, such as older adults, people with disabilities and households without a car. These counts are modeled minimums. How can I use HERE Location Reasoning with Wherobots? The HLR integration is available through Wherobots Spatial AI Tools and the Wherobots MCP Server. Contact us on the HERE and Wherobots partner page for early access. --- ## Texas Drone Delivery Map: LAANC Airspace and Reach URL: https://wherobots.com/solutions/mobility-and-map-making/texas-drone-delivery-map/ Updated: 2026-10-12 Airspace Texas Drone Delivery Map: LAANC Airspace and Reach A shortlist of drone delivery nest sites across Texas. Wherobots scored 100 candidate sites on the people within 10 km, the FAA LAANC airspace ceilings above them, and the towers and power lines nearby. Open the full map Talk to our team 100 candidate nest sites 82 operable sites 5.07M people within 10 km of the top 21 Dallas-Fort Worth, Texas FAA LAANC airspace ceiling (ft above ground) 0 ft, no LAANC 50 ft 100 ft 150 ft 200 ft 250 ft 300 ft 350 ft 400 ft 7 of the top 21 sites have more than a quarter of their 10 km circle capped at 200 ft or lower. Airspace: FAA UAS Facility Maps. Towers: Overture Maps. Power lines: OpenStreetMap contributors. Population: US Census ACS. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. How the map is built Place candidate sites 100 candidate nests sit on a 0.1 degree grid across the Texas metros. They mark areas to study, not surveyed pads. Count who each site reaches US Census ACS estimates give the people and households inside each site’s 10 km delivery circle. Map the airspace The FAA’s UAS Facility Maps list the LAANC ceiling for each grid cell, from 0 to 400 ft above ground. Areas with no facility-map cell are uncontrolled Class G airspace. Flag the obstacles Overture towers and OpenStreetMap power lines are the obstacles to low flight. Few towers carry a height, so the obstacle count is a floor. FAQ Texas drone delivery map FAQ What is a LAANC map? LAANC (Low Altitude Authorization and Notification Capability) is the FAA system for approving drone flights in controlled airspace. Its facility maps set the highest altitude an approval can grant in each grid cell, from 0 to 400 ft above ground. Does a 400 ft ceiling mean a drone can fly there? No. The ceilings omit temporary flight restrictions, part-time security restrictions, Part 135 conditions and local approvals to fly beyond visual line of sight. How were the sites ranked? 82 of the 100 candidates are operable. The top 21 are the operable sites ordered by the people within 10 km, and together they reach 5,070,748 people. Which obstacles does the map show? Towers and masts from Overture Maps and transmission lines from OpenStreetMap, near each candidate site. What did Wherobots compute? Wherobots joined the candidate sites to the FAA facility-map grid, the ACS population, and the towers and power lines, then scored and ranked every site. Plan your drone network Tell us where you want to fly, and we will walk you through the siting on your markets. Talk to our team --- ## Colorado Wildfire Risk Map by Property URL: https://wherobots.com/solutions/financial-services/colorado-wildfire-risk-map/ Updated: 2026-10-12 Wildfire exposure Colorado Wildfire Risk Map by Property Every building in Colorado, screened for wildfire, hail, flood, wind and access to a fire department. The map rolls 2,771,126 buildings up to parcels, H3 hexagons and counties, so underwriting and portfolio teams can see where exposure concentrates. Open the full map Talk to our team 2,771,126 buildings screened 307,679 in the top wildfire tier 547,396 more than 5 road miles from a fire department Boulder County, Colorado Highest wildfire score (0-2) per parcel 0, none detected 1, moderate 2, elevated 307,679 of the 2,771,126 buildings in Colorado (11.1%) are in the top wildfire tier. Buildings: Overture Maps. Wildfire: USFS Wildfire Risk to Communities. Parcels: Regrid. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. How the map is built Start from every building Overture Maps building footprints cover Colorado statewide: 2,771,126 buildings across 64 counties. Score five perils Each building gets wildfire, hail, flood and wind scores from USFS Wildfire Risk to Communities and FEMA data, plus the road distance to the nearest fire department, routed with HERE. Roll up to parcels and hexagons Buildings roll up to Regrid parcels and 24,868 H3 hexagons, so the map reads from county level down to a single roof. Read it as a screen Each score is a screening tier for where to look. It is not a loss estimate or an insurability decision. FAQ Colorado wildfire risk map FAQ What does the wildfire score mean? A 0 to 2 screening indicator per building: 0 means no wildfire exposure detected, 1 moderate and 2 elevated, the top tier. A parcel shows the highest score among its buildings. Which perils does the map cover? Wildfire, hail, flood, wind and access, measured as the road distance to the nearest fire department. How many buildings are in the top wildfire tier? 307,679 of the 2,771,126 buildings in Colorado, or 11.1%. Is the map an insurability determination? No. The scores are risk indicators for where to look. They are not loss estimates or insurability determinations. What did Wherobots compute? Wherobots joined every Overture building to the wildfire, hail, flood and wind layers and the HERE routes to fire departments, then rolled the scores up to parcels, hexagons and counties. Screen your portfolio Tell us about your book of business, and we will walk you through the perils on your locations. Talk to our team --- ## California Mobile Signal Quality Map URL: https://wherobots.com/solutions/communication-service-providers/california-signal-quality-map/ Updated: 2026-10-12 Signal quality California Mobile Signal Quality Map Where mobile service in California is slow, and why. Wherobots joined Ookla speed tests with towers, terrain and tree canopy to separate slow areas with a clear line of sight to a tower, a capacity problem, from areas where hills or trees block the signal. Open the full map Talk to our team 2,854 slow areas within 2 km of a tower 79.9% of those have a clear line of sight 1.51M people in capacity-limited areas Los Angeles basin, California Share of measured service that is underserved under 10% 10-25% 25-50% 50-75% 75% or more not measured Of 2,854 slow areas within 2 km of a tower, 2,281 (79.9%) have a clear line of sight: a capacity problem. Speed tests: Ookla Open Data. Towers and buildings: Overture Maps. Terrain: Copernicus. Canopy: Meta. Population: US Census ACS. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. How the map is built Measure service Ookla speed tests cover 48,999 map tiles and 231,828 tests across California. 6,664 of those tiles (13.6%) are underserved. Find the nearest tower Slow areas within 2 km of an Overture Maps tower are the near-tower set, where tower distance does not explain the slow service. Check the line of sight A modeled sightline over terrain and tree canopy splits slow areas into capacity-limited, terrain-blocked and foliage-blocked. Count the people US Census ACS estimates give the population of each kind of slow area. Capacity-limited areas hold 1.51 million people. FAQ California signal quality map FAQ Why is most bad service a capacity problem? Of the 2,854 slow areas within 2 km of a tower, 2,281 (79.9%) have a clear line of sight to it. The signal reaches them, so the limit is network capacity. Why are many hexagons grey? Only 8,872 of the 78,109 hexagons have a speed test. Grey means not measured, never zero, so every underserved count on the map is a floor. Is the line-of-sight check a speed prediction? No. It is a modeled sightline screen over terrain and tree canopy that sorts slow areas by likely cause. Where does the data come from? Ookla Open Data speed tests, Overture Maps towers and buildings, Copernicus terrain, Meta canopy height and US Census ACS population estimates. What did Wherobots compute? Wherobots joined the speed tests to the nearest towers, ran the line-of-sight checks over terrain and canopy, and counted the people in each slow area. Find your capacity gaps Tell us about your network, and we will walk you through the analysis on your markets. Talk to our team --- ## California Power Line Wildfire Risk Map URL: https://wherobots.com/solutions/energy-utilities/california-power-line-wildfire-map/ Updated: 2026-10-12 Wildfire exposure California Power Line Wildfire Risk Map Every high-voltage transmission span in California, screened for the wildfire exposure of the land around it on a 0 to 9 score. Wherobots scores fuels, vegetation greenness, tree height, slope and nearby buildings inside a 30 m buffer of each span. Open the full map Talk to our team 357,554 spans screened statewide 329,303 spans scored 7.7% of scored spans score 6 or more Sierra foothills, Auburn to Placerville Risk score (0-9) per transmission span 0-2 3-4 5 6-7, elevated 8-9 25,401 of the 329,303 scored spans in California (7.7%) score 6 or more. Fuels: USFS. Canopy: Meta. Greenness: Sentinel-2. Slope: Copernicus GLO-30. Lines and buildings: Overture Maps. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. How the map is built Cut lines into spans Overture power lines are cut tower to tower where towers sit within 30 m of the line, and into 100 m pieces elsewhere. Score the land around each span Inside a 30 m buffer, fuels, greenness, tree height and slope add up to a landscape score of 0 to 7. Buildings nearby add 0 to 2. Roll up for the statewide view Zoomed out, H3 hexagons show the share of spans that score 6 or more, and whole lines show the mean of their three worst spans. Read it as a screen The score is a screen of environmental exposure for review. It carries no equipment, clearance or outage data, and it is not an ignition probability or a loss estimate. FAQ California power line wildfire map FAQ What does the risk score measure? The wildfire exposure of the land within 30 m of a span: fuels, vegetation greenness, tree height and slope, plus the buildings nearby. Scores run from 0 to 9. Is the risk score an ignition probability? No. It is a screening score of environmental exposure. It holds no equipment, clearance or outage data, so it cannot estimate the chance of an ignition. Which power lines are on the map? Every transmission span on the Overture Maps power lines in California, whatever the operator, plus the spans of lines that cross the state line: 357,554 spans in all. Why do some spans have no score? 28,251 spans are missing at least one input, so they get no score. A missing input is not a low score. The full map draws these spans in grey. What did Wherobots compute? Wherobots cut the lines into spans, read the fuels, greenness, canopy and slope rasters inside each 30 m buffer, counted the buildings nearby and scored every span with all its inputs. Screen your own network Tell us about your lines and assets, and we will walk you through the scoring on your data. Talk to our team --- ## Yulin Naval Base in Satellite Imagery: AI-Assisted Vessel Counts URL: https://wherobots.com/blog/yulin-naval-base-satellite-imagery/ Updated: 2026-10-19 Commercial satellites collect imagery often, and it arrives ready to analyze within hours. The slow step in geospatial intelligence (GEOINT) is exploitation: an analyst finds, measures and compares the objects in each image. The report that comes out of it, called dissemination, goes out of date when the next image arrives. We ran six Vantor satellite images of Yulin Naval Base on Hainan through Wherobots RasterFlow and Meta’s SAM3 model, then checked every large detection by eye. The test shows what changes in exploitation and reporting when a text prompt finds the objects and the results go into a database table. It also shows which steps still need an analyst. Key takeawaysYulin Naval Base on Hainan is the center of China’s naval presence in the South China Sea, with China’s only base for ballistic-missile submarines and a pier for aircraft carriers.We ran six Vantor images of two docking areas, taken on five dates from May 25 to June 8, 2026, through one pipeline in Wherobots.WherobotsDB pan-sharpened the images, SAM3 on RasterFlow returned 902 outlines for the prompts “ship” and “boat”, and spatial SQL measured each one.Of the 72 outlines 30 m or longer with a score of 0.5 or more, a review of each crop confirmed 37 vessels and found 20 piers.A confidence score did not separate vessels from piers at this port, so the counts come from reviewed detections, joined to their verdicts in SQL.Each new image becomes measured rows in a database. Analysts check a short list of detections and explain what changed. Area 2, Yulin Naval Base, Hainan, June 3, 2026, 03:18 UTC. Image: Vantor. Area 2, Yulin Naval Base, Hainan, June 4, 2026, 23:20 UTC. Image: Vantor. Why Yulin Naval Base matters Yulin Naval Base, on the southern tip of Hainan Island, is the center of China’s naval presence in the South China Sea. A Pentagon-commissioned analysis of open-source data, reported by The Washington Post in 2024, valued the infrastructure of the Greater Yulin Naval Base at more than $18 billion as of 2022. The same report says the eastern base holds China’s only base for ballistic-missile submarines, with a cave cut into a hillside to keep them out of sight of satellites. The Federation of American Scientists first showed one of those submarines at Yulin in a satellite image from 2008. Large surface ships are based there too. Yulin has a pier for aircraft carriers, which let the navy station the carrier Shandong at the base, according to Defense News. The same report says most of China’s amphibious assault ships, built to land troops by boat or helicopter, are assigned to the fleet based there. China commissioned its newest carrier, the Fujian, at a naval port in Sanya on November 5, 2025. The base also keeps changing. Satellite images from July 2022 showed two new piers under construction beside four existing ones, according to that report. Ships arrive and leave with deployments and exercises, so a count from one image goes out of date quickly. That makes Yulin a fair test for a pipeline that counts vessels on every new image. Where time goes in imagery exploitation Take one question through the usual process. A watch officer asks: “Has berthing activity at this naval port changed this week?” Berthing activity means the ships that dock at the port and leave it. Ordering and collecting the imagery is now the easy part. Very-high-resolution (VHR) satellites such as Vantor’s record detail finer than 1 m, and Planet’s satellites image the same place every day. The picture often exists before anyone asks for it. Processing is fast too. Imagery arrives corrected for terrain and camera angle (orthorectified) within hours of reaching the ground. Exploitation still depends on analysts. An analyst finds each vessel, measures it and compares it with the previous image. The work grows with every image: six images of two docking areas mean six sessions of an analyst studying the screen. The answer goes out as an annotated image and a paragraph. Collection is measured in hours, and exploitation in days. To show a week of change, the analyst repeats that work on every image and compares the results by hand. One pipeline over six satellite images We ran one pipeline, unchanged, over six images of two docking areas at Yulin Naval Base from Vantor, the company called Maxar Intelligence until October 2025. The two areas are neighboring stretches of waterfront, about 1.5 km and 2 km on a side; area 2 borders area 1 to the north. Area 1 was imaged on May 25, June 4, June 6 and June 8, 2026, and area 2 on June 3 and June 4. Dates are in UTC; local time on Hainan is eight hours ahead. Each delivery holds a panchromatic band at 0.39 to 0.61 m per pixel and eight multispectral bands at 1.5 to 2.4 m per pixel. panchromatic and multispectral image → WherobotsDB raster SQL pan-sharpens it to color → RasterFlow builds one mosaic per image at 0.5 m → SAM3 returns outlines for the prompts "ship" and "boat" → spatial SQL removes duplicates and measures each outline → visual review of every outline 30 m or longer → results table, one row per object, by area and date WherobotsDB raster functions combine the sharp panchromatic band with the red, green and blue bands (pan-sharpening). The result is a color image at the panchromatic detail. RasterFlow then turns each image into a mosaic at 0.5 m per pixel on the local UTM grid, a map projection that keeps distances accurate. The detection model is Meta’s SAM3, run on RasterFlow’s managed GPUs (graphics processors, the chips that run AI models). SAM3 is not a ship model. It is a foundation model, trained on broad image data, that finds objects described in words. We typed “ship” and “boat”. For each object it found, SAM3 returned an outline placed on the map and a confidence score. Each image took 4 to 7 minutes on the GPUs. Pointing the model at other objects takes a new prompt and no new code. Spatial SQL then measures every detection, the job an imagery analyst does by hand for each vessel (mensuration). The query converts each outline to meters on the UTM grid. It fits the smallest rectangle around each outline, at whatever angle the vessel is moored, and reads the length and width (beam) from it. When both prompts return the same vessel, it keeps the higher-scoring outline. Each detection becomes one row in a table, with its area, date, outline, length, width and score. One query that counts the rows for each area and date answers the watch officer’s question. The count for every new image is ready to chart, compare or set an alert on as soon as the image is processed. No analyst has to write it down. Area 1, Yulin Naval Base, Hainan, June 4, 2026, 23:20 UTC. Image: Vantor. Area 1, Yulin Naval Base, Hainan, June 6, 2026, 03:16 UTC. Image: Vantor. What the satellite images of Yulin Naval Base show SAM3 returned 902 outlines across the six images. After duplicates were removed, 72 were 30 m or longer with a score of 0.5 or more. The visual review confirmed 37 of those 72 as vessels. Twenty were piers. AreaDate (UTC)SAM3 outlines 30 m or longer, score 0.5 or moreConfirmed vesselsPiersPart of a vessel already countedOtherArea 1May 25118021Area 1June 452111Area 1June 6106130Area 1June 873121Area 2June 32010721Area 2June 41981010Total723720114Confirmed vessels counts outlines; at area 2 on each date, one outline holds two vessels moored side by side. Other: three floating solar arrays and one stretch of shore. Source: Wherobots RasterFlow (SAM3) detections and WherobotsDB counts on Vantor imagery. Each count is a snapshot of one image, not a log of arrivals and departures, so comparing dates is a change detection question. The images differ in light and weather. The May 25 and June 4 images were taken in the early morning local time (07:49 and 07:20), with the sun 22° and 15.7° above the horizon. The metadata for the June 8 image reports 27% cloud cover. At area 1, confirmed vessels went from 2 on June 4 to 6 on June 6 and 3 on June 8. That change could be ships arriving and leaving, or ships SAM3 missed in poorer light. Telling the two apart is the analyst’s question the pipeline sets up. At area 2, 17 of the 39 large outlines were piers. Long piers there carry rows of construction modules, and at 0.5 m per pixel SAM3 scored some of them as high as moored ships. How we checked the output Every step below ran in Wherobots, and each check is logged in the job runs, so the numbers in the table can be traced back to the images. Color images. For each pan-sharpened image, the job logged the pixel size, the count of valid pixels and the footprint. All six covered the same two areas, at 0.37 to 0.48 m per pixel. Model settings. SAM3 ran with the settings Wherobots publishes on the model’s card. We tested it on the June 6 image before running the other five. Duplicates and measurement. The “ship” and “boat” prompts often returned the same vessel. An outline was dropped when a higher-scoring outline covered more than half of it, which cut 902 outlines to 699. Each kept outline was measured with a rectangle turned to the vessel’s own angle, so pier deck beside an angled hull does not add to its length. A look at every image. We drew every measured rectangle 10 m or longer over all six images. Most sat on vessels. At area 2, several high-scoring rectangles covered a whole pier, sometimes with the ships moored along it. Two automatic pier filters, tested and dropped. Overture Maps, the open map data in the Wherobots catalog, has only two pier lines at this port and no pier areas, so it could not mask the piers. We then ran SAM3 with the prompts “pier” and “wharf” to map the piers from the imagery itself. That mask also covered ships: it would have removed a 99 m vessel in open water that scored 0.92. Neither filter was used. A visual review of every large outline. All 72 outlines 30 m or longer with a score of 0.5 or more were cut from the color images at full 0.5 m detail, with a 60 m margin. Each crop got one verdict: vessel, two vessels in one outline, part of a vessel already counted, pier, floating structure or shore. Claude, Anthropic’s AI assistant, made the 72 calls from the crops while preparing this post. Each verdict is stored with its outline, so an analyst can audit or change any of them and rerun the count. Counts from the database. The verdicts went back into WherobotsDB as a table, and the counts in the table above come from a SQL join of verdicts to outlines. A check confirmed that each of the 72 outlines has exactly one verdict. The measurement and the count are short queries. This one measures every SAM3 outline in meters on the UTM zone 49N grid: WITH m AS ( SELECT scene_id, label, bbox_score, ST_Transform(geometry, 'EPSG:4326', 'EPSG:32649') AS g FROM detections ), r AS ( SELECT *, ST_ExteriorRing(ST_OrientedEnvelope(g)) AS ring FROM m ), s AS ( SELECT scene_id, label, bbox_score, ST_Distance(ST_PointN(ring, 1), ST_PointN(ring, 2)) AS s1, ST_Distance(ST_PointN(ring, 2), ST_PointN(ring, 3)) AS s2 FROM r ) SELECT scene_id, label, bbox_score, GREATEST(s1, s2) AS length_m, LEAST(s1, s2) AS beam_m FROM s This one joins the review verdicts to the outlines and returns the table above: SELECT c.area, c.acquired, COUNT(*) AS candidates, SUM(CASE WHEN v.verdict IN ('vessel', 'merged') THEN 1 ELSE 0 END) AS vessels, SUM(CASE WHEN v.verdict = 'pier' THEN 1 ELSE 0 END) AS piers FROM review_candidates c JOIN verdicts v ON c.hid = v.hid GROUP BY c.area, c.acquired ORDER BY c.area, c.acquired Area 2, June 4, 2026: every SAM3 outline 30 m or longer with a score of 0.5 or more, by review verdict. Green: vessel. Orange: pier. Yellow: part of a vessel already counted. Imagery: Vantor. Detections: Wherobots RasterFlow with SAM3. Counts: WherobotsDB. Review examples at full 0.5 m detail: a vessel, two vessels in one outline, a pier, and part of a vessel already counted. Imagery: Vantor. Detections: Wherobots RasterFlow with SAM3. The review checks the outlines SAM3 returned. It does not find vessels SAM3 missed, and outlines under 30 m were not reviewed. The table therefore counts confirmed detections, which can be fewer than the vessels in port. What changes at each stage of the cycle In the usual process of satellite imagery analysis, detection produces marks on an image. Here it produces measured outlines stored as rows in a table. Exploitation now costs computing time: the sixth image, or the six-hundredth, adds 4 to 7 minutes on the GPUs. Analyst time goes to the detections worth checking: here, 72 close-up crops in place of six full images. The pipeline ran as jobs on a small Wherobots runtime, and RasterFlow ran the model on its own GPUs. First-phase exploitation of every new image of every port of interest stops being a staffing decision. Reporting becomes a query. No one builds and sends a report. The detections and review verdicts sit in open-format tables (Apache Iceberg). Map tools can display them, and SQL can query them. The Wherobots server for the Model Context Protocol (MCP), an open standard for connecting AI assistants to data, gives them access to the same tables. People can then ask in plain English, for example: “how many vessels were at area 1 on June 8?” The answer is computed from the detections. People get the answer when they need it, instead of waiting for a report to be published. Analysts spend their time on judgment. The pipeline reports where the vessels are and how big they are. What they are doing stays the analyst’s call. The analyst’s task used to be “review six images.” Now it is “check 72 detections, then explain why the count at area 1 changed between June 4 and June 8.” That is the question their training prepared them for. A change used to reach a decision-maker after the image waited in an analyst’s queue. Now it arrives after one pipeline run and a short review. The five steps (tasking, collection, processing, exploitation and dissemination, known together as TCPED) stay separate. The two that ran at human speed now run mostly on computers. So the time from one detection run to the next decision about what to image gets shorter. Combining sources with a spatial join Each detection is a row in a spatial database, so it can be combined with other data (fusion) as soon as it is saved. Each row holds an outline, a time, a measured length and width, and a confidence score. The same database can hold every other source an intelligence team uses. Area 1, Yulin Naval Base, Hainan, June 8, 2026, 05:45 UTC. Image: Vantor. Combining sources becomes a query: Different satellites and resolutions. A common pattern is called tip and cue. A satellite that images wide areas daily, such as Planet’s at about 3 m per pixel, shows activity. A sharper satellite, such as Vantor’s, confirms it. When both write to the same table with the same columns, “what did the sharper image confirm about yesterday’s activity?” is one query that matches the table against itself by place and time. Other sources. Ships broadcast their position and identity by radio, a system called AIS. A “dark” vessel is one seen in imagery with no matching AIS signal. Finding them means matching detections to AIS tracks by distance (ST_DWithin) and time, in the same SQL used for the measurements. Radar (SAR) detections, maps of port facilities and lists of known military units (order of battle) match on place and time the same way. Base maps. Open map data such as Overture Maps (coastlines, facilities, administrative areas) is already in the Wherobots catalog. So “detections inside the naval base boundary” is one filter, where the map data covers the place. At Yulin it maps only two pier lines, which is why the pier filter above came from a visual review. This test used optical imagery only and did not run these matches. When every source lands as measured shapes in one planetary-scale spatial database, each pair of sources no longer needs its own system. A new source is one more table in the query. Limits of the workflow A SAM3 confidence score ranks how closely an object matches the prompt. It does not say what type of vessel the object is. At this port, a score of 0.5 or more did not separate vessels from piers: 20 of the 72 large outlines were piers. Some outlines hold two vessels moored side by side, and some cover only part of a vessel. Vessels SAM3 missed are not counted, because no second source was checked. Prompts and score cutoffs need tuning for each port and satellite. Analysts still decide what a change means. The pipeline gives them detections from every new image, sooner, and a short list to check. What the test shows In GEOINT, analyzing images has been slower than collecting them for years. This test shows that the first look at each image, and the report, can now keep up with collection. A text prompt pointed the detection model at vessels. The model ran on managed GPUs and turned images into outlines. The results became time-stamped rows that can be queried, checked and matched with other data. The test covered six images of two areas of one port over two weeks, all processed by one pipeline. A question that used to wait in an analyst’s queue is now a SQL query that anyone cleared to ask it can run, plus a review of the detections that need a person’s judgment. Built on Wherobots: RasterFlow (SAM3 detection from text prompts on managed GPUs) and WherobotsDB / Apache Sedona spatial SQL and raster functions (pan-sharpening, measurement and counts). Imagery: Vantor very-high-resolution panchromatic and multispectral, processed in Wherobots Cloud. Frequently Asked Questions Where is Yulin Naval Base? On the southern tip of Hainan Island in China, on the edge of the South China Sea (Defense News, 2022). The naval complex lies east of the city of Sanya (Defense News, 2021). What is based at Yulin Naval Base? Submarines and large surface ships. The Washington Post reported in 2024 that the eastern base holds China’s only base for ballistic-missile submarines.Defense News reported in 2022 that a carrier pier let the navy station the carrier Shandong there. The same report says most of China’s amphibious assault ships are assigned to the fleet based there. How do you count ships in satellite imagery? In this test, SAM3 on RasterFlow returned an outline for each object matching the prompts “ship” and “boat”. Spatial SQL removed duplicates and measured each outline with a rectangle at the vessel’s angle.Every outline 30 m or longer with a score of 0.5 or more was reviewed on a close-up crop. A SQL join then counted the confirmed vessels for each area and date. Can AI tell what type of warship is in a satellite image? Not in this pipeline. A SAM3 score ranks how closely an object matches a prompt such as “ship”. It does not give a vessel class.At Yulin, 20 of the 72 large outlines with a score of 0.5 or more were piers. Naming the type of each vessel stays with the analyst. What is TCPED? TCPED stands for tasking, collection, processing, exploitation and dissemination, the five steps that take an intelligence question from ordering an image to a finished report. This test speeds up exploitation and dissemination, the two steps that ran at human speed. --- ## Felt and Wherobots URL: https://wherobots.com/partners/felt/ Updated: 2026-10-09 Wherobots and Felt Wherobots processes physical world data at petabyte scale. Felt turns the results into collaborative maps in the browser. Felt connects to Wherobots as a native data source, so teams query data in place and share the map with a link. Connect Felt to Wherobots Read the announcement How the integration works Connect with an API key In Felt, add Wherobots as a data source with a Wherobots API key, then choose the region and runtime size for your queries. Follow the setup guide Query with SQL or Felt AI Add catalog tables to a map or write a SQL query. Felt AI can write the SQL. Felt runs SELECT statements only, so your data in Wherobots stays as it is. Keep layers current Refresh a Wherobots layer on demand or on a schedule. Each refresh reruns the query on Wherobots. Share the map Share interactive maps and spatial dashboards with your team through a link, viewable from any device. Partnership Wherobots and Felt’s new integration allows organizations to move seamlessly from processing petabytes of raw geospatial data in the cloud to visualizing actionable insights in a browser-based, collaborative environment. Rachel Zack Chief Strategy Officer and co-founder, Felt Wherobots and Felt in production Leaf Agriculture Leaf uses Wherobots to build data products from agricultural, parcel and tractor telemetry data, then uses Felt to build interactive maps from the results. The Leaf team shares maps by link instead of screen-sharing. Open the example map From satellite to signal on AWS A hands-on workshop from Felt, Wherobots and AWS that scores 1,035,306 San Diego buildings for wildfire, flood and severe weather risk, then builds Felt maps from natural language. Open the workshop FAQ Wherobots and Felt FAQ What do I need to connect Felt to Wherobots? An account in a Wherobots Professional, Innovation or Enterprise organization, a Wherobots API key, and a Felt plan that includes database sources. See the setup guide. Who pays for the queries Felt runs? Each Felt query runs on the Wherobots runtime you select, and the runtime size sets the Wherobots cost of the query. Can Felt change data in Wherobots? No. Felt runs read-only SELECT queries against Wherobots. Can a Felt map stay up to date with Wherobots data? Yes. Wherobots layers in Felt refresh on demand or on a schedule, and each refresh reruns the query. How do I get started? Start a free Wherobots trial, create an API key, and add Wherobots as a data source in Felt, or talk to our team. Put your spatial data on a shared map Tell us about your data and we will show you the Wherobots and Felt workflow on it. Talk to our team --- ## AWS and Wherobots URL: https://wherobots.com/partners/aws/ Updated: 2026-10-09 Wherobots on AWS Wherobots runs on AWS. Buy it through AWS Marketplace, process the spatial data you keep in Amazon S3 where it lives, and pick the AWS Region that keeps your data resident. Buy on AWS Marketplace Start for free How Wherobots works with AWS AWS Marketplace Subscribe with pay-as-you-go pricing and one AWS bill. Purchases through AWS Marketplace can use your AWS committed spend. View the listing Amazon S3 Read from and write to public and private S3 buckets, governed by your AWS IAM permissions. A guided CloudFormation template creates the access role. Connect S3 AWS Glue Data Catalog and Amazon S3 Tables Wherobots federates with AWS Glue Data Catalog and connects an Amazon S3 table bucket as an Apache Iceberg catalog, with read-only or read-write access. Read about Glue federation AWS Regions and your own VPC Run in US West (Oregon), US East (N. Virginia), US East (Ohio), EU West (Ireland) or AP South (Mumbai). Innovation and Enterprise customers can run the Wherobots compute plane in a VPC in their own AWS account. See editions and regions Customer proof With Wherobots on AWS, we can now scale to millions of acres reliably and cost-effectively. G. Bailey Stockdale CEO, Leaf Agriculture Build on AWS Orchestrate jobs with AWS Step Functions A reference architecture for scheduling and chaining Wherobots jobs from AWS Step Functions. Read the architecture From satellite to signal on AWS A hands-on workshop from Felt, Wherobots and AWS that scores 1,035,306 San Diego buildings for wildfire, flood and severe weather risk with the Wherobots MCP server and an Amazon Bedrock agent. Open the workshop FAQ Wherobots on AWS FAQ Is Wherobots available on AWS Marketplace? Yes. Wherobots is available on AWS Marketplace with pay-as-you-go pricing and AWS integrated billing. Which AWS Regions does Wherobots run in? WherobotsDB runs in US West (Oregon), US East (N. Virginia), US East (Ohio), EU West (Ireland) and AP South (Mumbai). RasterFlow runs in US West (Oregon). Does Wherobots copy my data out of Amazon S3? No. Wherobots reads and writes your S3 buckets in place through an IAM role you control, and does not charge for cross-region transfer between its service and S3. Does Wherobots work with AWS Glue Data Catalog and Amazon S3 Tables? Yes. Wherobots federates with AWS Glue Data Catalog and connects Amazon S3 table buckets as Apache Iceberg catalogs. Read about Glue federation. Can I run Wherobots in my own AWS account? Yes. Innovation and Enterprise customers can run the Wherobots compute plane in a VPC in their own AWS account, so data stays in their cloud. How do I get started? Subscribe on AWS Marketplace, start a free trial, or talk to our team. Run your spatial workloads on AWS Bring a dataset in S3 and we will show you how it runs on Wherobots. Talk to our team --- ## HERE and Wherobots URL: https://wherobots.com/partners/here/ Updated: 2026-10-09 Partnership Wherobots and HERE give AI agents precise answers about the physical world. Wherobots processes physical world data at regional to planetary scale. HERE adds trusted, live location intelligence. Get early access → See the demos in Havasu Houston, Texas Drive time from downtown, and the buildings in the 100-year river flood Drive time from downtown: 5, 10, 15, 20 and 30 min (HERE) Buildings in the 100-year river flood (Overture, JRC) Mostly 1 m deep or more 205,789 of the 1,779,025 buildings in the study area are in the 100-year flood area. Drive time: HERE. Buildings: Overture Maps. Flood depth: JRC (data ends at 30° N). Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. Why it matters AI agents still cannot reason about the physical world. Today Imagery, GPS traces, roads, buildings and climate data are too large and too varied for general-purpose AI. With Wherobots Wherobots processes them together at regional to planetary scale. Today Agents guess at addresses, routes and travel times. With HERE HERE returns rooftop geocodes, truck-legal routes and live traffic. Today Teams stitch context together by hand from many tools. With Wherobots One endpoint sends each task to the engine built for it. First integration · coming soon HERE Location Reasoning in the Wherobots MCP server. Your AI agent Wherobots MCP server Wherobots Spatial joins across billions of geometries Satellite imagery and mobility processing Forecasts, risk surfaces and scores HERE Location Reasoning Geocoding and place search Car and truck routing, drive-time areas Live traffic and EV charging data Early access Be first to build with it. Agents increasingly answer questions, complete tasks, and run workflows on our behalf, and many of those tasks require deterministic answers about the physical world. Mo Sarwat CEO, Wherobots AI is moving from generating content to making decisions and taking action in the physical world. That requires more than a language model. Mahesh Shah Senior Vice President of Enterprise & AI Solutions, HERE Technologies Get early access --- ## Partners URL: https://wherobots.com/partners/ Updated: 2026-10-09 Wherobots partners Wherobots partners with data and platform companies to bring physical world context to the tools and AI agents teams already use. Talk to us about partnering Partnerships AWS Wherobots runs on AWS. Buy through AWS Marketplace, process data in Amazon S3 in place, and connect AWS Glue Data Catalog and Amazon S3 Tables. Wherobots on AWS Databricks Run spatial analytics on your Databricks data. Wherobots connects to Unity Catalog, reads Delta and Iceberg tables in place, and keeps your existing governance. Wherobots and Databricks Felt Query Wherobots from Felt and turn spatial data at any scale into collaborative maps your whole team can use. Wherobots and Felt HERE Wherobots and HERE give AI agents precise answers about the physical world. HERE Location Reasoning is coming to the Wherobots MCP server, with early access open now. Wherobots and HERE --- ## Homepage v2 URL: https://wherobots.com/ Updated: 2026-10-14 Unleash AI on physical world data. The most capable cloud for earth intelligence and physical world data at any scale. Start for free Explore Havasu Catalog Wherobots Replay of a real Wherobots analysis Example question Which peril exposes the most buildings in Colorado, across every building and parcel in the state? Searched the Havasu Catalog: Overture, Regrid, FEMA NRI + NFHL, USFS2.77M buildings · 2.72M parcels Wrote spatial SQLWherobotsDB SELECT r.peril, COUNT(DISTINCT b.id) AS buildings_exposed FROM wherobots_open_data.overture_maps_foundation.buildings_building b JOIN co_risk.parcels p ON ST_Intersects(b.geometry, p.geometry) JOIN co_risk.peril_zones r ON ST_Intersects(b.geometry, r.geometry) WHERE r.peril IN ('hail', 'wildfire', 'tornado', 'flood', 'wind') GROUP BY r.peril ORDER BY buildings_exposed DESC Ran the query: 5 perils rankedstatewide 2,172,394 Colorado buildings exposed to hail, 78.4% of the state. Hail leads wildfire. View on map Colorado property risk, every building Punjab farm fields with RasterFlow Arizona rooftop solar with RasterFlow California network capacity gaps Rhine basin flood exposure New Hampshire tree canopy with RasterFlow Trusted by teams building with AI on physical-world data with Wherobots and Apache Sedona Customer proof We went from babysitting compute jobs for a week to getting results before lunch. Steven Yee Founding Staff Engineer, Aarden.ai <2 hour runs From a complex infrastructure project that took months to mission critical fire forecasts updated throughout the day for the US Forest Service Learn more → 300x faster core processing at Aarden.ai, 7 days to 30 minutes Learn more → 20x faster buildings pipelines at Overture Maps Foundation Learn more → 2.5x faster spatial queries and joins, with up to 45% better price-performance, across SpatialBench at SF 1000 Learn more → Architecture Spatial data in, answers out, built with the stack you already run. Connect your AI agent through the Wherobots MCP server and it can run the whole workflow, from finding the data to writing and running the job. Wherobots reads spatial data where it lives, processes it with WherobotsDB and RasterFlow, and serves results to maps, apps and BI tools in open formats. Get started with AI coding tools Open a group to see its integrations, then hover a logo for details Catalogs & data platformsDatabricks Unity CatalogRead Delta, read and write IcebergSnowflake Horizon CatalogRead and write with the Spark connectorAWS Glue CatalogIceberg catalog from the Data HubAmazon S3 TablesIceberg table bucketsPostGISRead and write over JDBCArcGIS Feature ServiceREST reader with pushdownFiles & formatsGeoParquetRead and writeCOGGeoTIFF & COGIn-DB and out-DB rastersZarrZarr & NetCDFMultidimensional rastersSTACCollections and itemsSHPShapefile, GeoPackage, GeoJSONVector filesOSM PBFOpenStreetMap extractsFile GeodatabaseRead without GDAL Read & ingest Context engine for physical world data Observe RasterFlow: Earth intelligence & perception Imagery becomes physical-world features. AI for Earth ↗ Compute WherobotsDB: Spatial-first compute engine Planetary-scale joins on data where it lives. Compute ↗ readwrite back readwrite back Havasu Catalog Open datasets, RasterFlow models, notebooks and apps next to your own datasets, in open formats and Apache Iceberg. Open datasets ready to queryOverture MapsBuildings, places, roads, divisionsSentinel-2Scene index and RasterFlow imageryNAIPUS aerial imagery for RasterFlowCopernicus DEM30 m global elevationUS CensusTIGER boundaries and ACS+3737 more datasets →42 open datasets in the Havasu Catalog, plus RasterFlow models, notebooks and appsStored in your cloud, in open formatsAmazon S3Your buckets, managed storage or BYOCApache IcebergHavasu spatial tablesDelta LakeRead through Unity CatalogPMTPMTilesPlanet-scale vector tiles Discover ↗ SQL sessions, notebooks, and CLIsBuild ↗ Jobs and orchestrationAutomate ↗ Vector tiles and map interfacesTiles ↗ Extends Apache Sedona, no code changes Query & serve AI agents & coding toolsClaudeOfficial connectorVS CodeWherobots extensionCursorExtension, MCP and skillsChatGPT & CodexMCP over OAuthDevinExtension, MCP and skillsAny MCP clientWherobots MCP serverMaps & front endsFeltNative Wherobots connectorDekartNative connector, kepler.gl mapsMapLibrePMTiles vector tilesArcGIS Maps SDK for JavaScriptPMTiles vector tilesGLPreviewWherobots-GLZarr, GeoParquet, COG, PMTilesNotebook mapsleafmap, kepler.gl, pydeckApps, SQL & BI clientsPythonDB-API driverDBeaverOver JDBCDataGripOver JDBCApache AirflowRun and SQL operatorsdbtdbt adapter for Wherobots SQLAPIREST & SQL APIJob Runs and SQL sessions Learn more: Havasu Catalog · Compute · AI for Earth · Automate · Build Why teams love Wherobots Four challenges teams overcome building with physical world data. These are the most commonly referenced reasons why our customers build their physical world data products with Wherobots. Talk to sales 01Velocity is slow The problem Ideas take weeks to months to ship. Many never reach production at allBespoke infrastructure for every projectUnfamiliar data structures and silos buildings × parcels+ elevation, slope9h 58mtimeout97% With Wherobots Test ideas in minutes, ship solutions in days. Prototype to production on one platformManaged compute, no infrastructure to buildRaster, vector and your tables in one query buildings × parcels+ elevation, slopecompleteone query100% 02Finding and preparing spatial data takes weeks The problem The right data is hard to find. Hunting across data portals and vendor sitesDownload, clean and reproject before any queryRepeat the search for every new project .shp.tif.csv.gpkg.kmlEPSG:27700DAY30 With Wherobots Query the right data in place from day one. Overture, NAIP, Sentinel-2 and easy STAC collectionsSchemas and sample SQL, ready to query in placeNext to your own tables, reused across projects overture.buildingsopenoverture.placesopensentinel2.l2aopenyour_org.parcelsyoursDAY1 03AI and teams can't use physical world data The problem Spatial engineering expertise is scarce. Projections, spatial indexes and tilingHard-won knowledge locked in a few headsSpatial code from general AI breaks on real data SELECT ST_MagicJoin( a.geom, b.geom)FROM roads a, pts blat/lon swapped With Wherobots Expertise baked into every layer. Projections, indexing and tiling handled for youFamiliar SQL and Python for everyone on the teamAI agents get spatial expertise through MCP SELECT ST_Intersects( a.geom, b.geom)FROM your_catalog.roadsEPSG:4326 04Handcuffed by tooling limitations and seat-based licensing The problem GIS lock-in or data platform gaps. Legacy GIS lock-in and per-seat licensesData platforms that are incomplete for spatial workSpatial is a side quest on their roadmaps .gdb .lyrx .sdeper-seat licenserenewal With Wherobots Extend your data platform, pay on demand. Open file and table formats, no per-seat licensesExtends the data platform you already runSpatial-first expertise, priced on demand GeoParquet · COGno seat licensespay per job Solutions by industry See how your industry builds with Wherobots. Physical world context for the teams that plan, insure, power and connect the world. Talk to sales See all solutions Aerospace & Earth observation Satellite imagery analysis and geospatial AI inference at petabyte scale. Energy & utilities Wildfire risk, solar site selection and grid intelligence. Financial services & insurance Climate and property risk across millions of locations. Mobility & map making Billions of GPS points turned into location intelligence and maps. Communication service providers Network events, 5G planning and coverage analytics. Sustainability & agriculture Satellite crop monitoring and field boundary detection. Open-source foundation From the original creators of Apache Sedona. Apache Sedona is the most widely deployed open-source distributed spatial engine in the world. The team that created it built Wherobots on the same foundation, so Wherobots is 100% compatible with existing Apache Sedona workloads: your Sedona code runs unchanged. Explore Apache Sedona Compare Sedona and Wherobots Downloads 80M+ Apache Sedona downloads In production 20,000+ organizations run Sedona O'Reilly book Download the Apache Sedona book. Cloud Native Geospatial Analytics with Apache Sedona: a hands-on guide to running Sedona locally and in the cloud, querying large geospatial datasets with spatial SQL, and applying machine learning to spatial data. Download the book Blog Latest from Wherobots Visit blog 20 Oct 20268 min read Most Dangerous Roads for Pedestrians and Cyclists in the US (Part 2) Learn more → 17 Oct 202614 min read Most Dangerous Highway in the US: 25 Deadliest Stretches Learn more → 14 Oct 20266 min read Utility Vegetation Management at Scale with Earth Intelligence Learn more → FAQ Frequently asked questions What is Wherobots? Wherobots is a cloud platform for analyzing physical world data, built by the original creators of Apache Sedona. WherobotsDB runs spatial SQL and Python with 300+ vector and raster functions, RasterFlow turns satellite and aerial imagery into physical-world features, and the Havasu Catalog keeps open datasets next to your own. Does Wherobots work with Databricks, Snowflake and AWS? Yes. Wherobots reads data where it lives, including Databricks Unity Catalog, Snowflake Horizon Catalog, AWS Glue Catalog, Amazon S3 Tables and PostGIS, and writes results back in open formats such as Apache Iceberg and Delta Lake. See the Havasu Catalog for the datasets ready to query. How fast is Wherobots? Across SpatialBench at SF 1000, WherobotsDB runs spatial queries and joins 2.5x faster, with up to 45% better price-performance. Read the benchmark results. What is the connection between Wherobots and Apache Sedona? Wherobots was built by the team that created Apache Sedona, the open-source distributed spatial engine with 80M+ downloads. Wherobots is 100% compatible with existing Apache Sedona workloads, so your Sedona code runs unchanged. Compare Sedona and Wherobots. Can I use Wherobots with AI coding tools? Yes. The Spatial AI Coding Assistant brings spatial SQL to VS Code and Claude Code, and agents such as Claude, Cursor, ChatGPT and Codex, Devin or any MCP client can connect through the Wherobots MCP server. Read the AI coding tools docs. How do I get started with Wherobots? Start a free trial and test your first idea at $0, or talk to our team about your use case. What is physical AI? Physical AI is artificial intelligence that perceives, reasons about, and acts in the physical world, from robots and autonomous vehicles to models that read satellite, aerial, and sensor data. Read what physical AI is and the spatial data it runs on in our Discover guide. Run your first spatial query. Create an account, and test your first idea at $0. Start for free Talk to sales --- ## Wherobots vs. Apache Sedona URL: https://wherobots.com/apache-sedona/wherobots-vs-apache-sedona/ Updated: 2026-10-09 Comparison Wherobots vs. Apache Sedona: three paths to spatial at enterprise scale Most enterprise spatial work starts on Apache Sedona. As workloads grow into joins at scale, raster processing, nearest-neighbor queries, and production SLAs, teams are best served by the fully managed and most capable Physical AI compute cloud, Wherobots, or can also use a drop-in enterprise runtime for Apache Sedona. Talk to sales Start for free Wherobots Cloud The context engine for physical world data, fully managed, and most capable. Apache Sedona The open-source distributed spatial engine where most teams start. WherobotsDB BYOS A drop-in replacement for Apache Sedona with enterprise support. Feature comparison Wherobots Cloud, WherobotsDB BYOS, and Apache Sedona side by side Capabilities grouped by area, from core spatial SQL to raster, Earth intelligence and perception, and spatial AI tools. Wherobots Cloud WherobotsDB BYOS Apache Sedona Wherobots Cloud, WherobotsDB BYOS, and Apache Sedona side by side Capability Option A Wherobots Cloud Fully managed spatial compute, RasterFlow, Havasu catalog, and Spatial AI tools. Option B WherobotsDB BYOS Bring Your Own Spark: a drop-in runtime for existing Sedona clusters. Option C Apache Sedona Open source, Apache 2.0. Where most teams start. Fit and economics Best for Maximum performance, Earth intelligence and perception, managed infrastructure and catalog, and spatial AI developer tools Enterprise workloads that must stay on self-managed Spark Teams starting with spatial analytics, proofs of concept, Spark experts comfortable tuning by hand, and less complex workloads not requiring enterprise support Cost model Pay as you go WherobotsDB license plus your compute Free (Apache 2.0) Infrastructure Included: Fully managed by Wherobots Customer managed (drop-in runtime) Customer managed Enterprise support Included: Dedicated SLAs Included: Dedicated SLAs Not included: Community only Spatial compute capabilities Spatial SQL functions Vector and raster functions in the function reference below Included: 389, including 31 exclusive to Wherobots Included: All of Apache Sedona plus Wherobots-exclusive functions Included: 358, the full Apache Sedona set Query optimization Join strategy, skew prevention, spatial acceleration Included: Automatic, plus purpose-built engine optimizations Included: Automatic join selection and dynamic optimization Not included: Manual tuning Spatial joins at scale SpatialBench SF-1000, 12 query patterns Included: Completes all 12 Included: Completes all 12 Partial: Completes 6 of 12 (Q1 to Q5, Q7) Approximate KNN Find the N nearest features to each record Included: Available, with optimized runtime Included: Available Not included: Exact comparison only, impractical at enterprise volumes Apache Sedona API compatibility Included: 100% compatible Included: 100% compatible Included: Native Raster and out-of-database processing Out-of-database raster Load pixels on demand from object storage or STAC Included: Full support with managed runtime optimizations Included: On-demand loading, caching, Cloud Optimized GeoTIFF Not included: Loads full files into executor memory Raster processing and map algebra Zonal statistics, raster algebra, raster to vector, multi-band Included: Full suite plus distributed raster tile generation Included: Full suite with spatial filter push-down Included: In-memory raster processing Earth intelligence and perception with RasterFlow Wherobots Cloud only Mosaics from satellite and aerial imagery Sentinel-2, NAIP, and custom sources over an area of interest Included: Public Preview Not included: Cloud only Not included Computer vision inference at planetary scale Semantic segmentation, regression, patch-based processing Included: Public Preview Not included: Cloud only Not included Built-in models SAM3, Fields of the World, Tile2Net, Meta canopy height, ChesapeakeRSC Included: Five built-in models plus bring your own Not included: Cloud only Not included Bring your own PyTorch model Included Not included: Cloud only Not included Vectorize model outputs Turn raster predictions into geometries for spatial analysis Included Not included: Cloud only Not included Analytics and location intelligence Geostatistics DBSCAN clustering, Getis-Ord Gi* hot spots, outlier detection Included: Built in, distributed, and tuned for scale Included: Available Included: Available Location intelligence Reverse geocoding with Overture Maps, isochrones, map matching Included: Included, plus PMTiles generation Partial: Optional add-on Not included Spatial AI developer tools Wherobots Cloud only Spatial AI Coding Assistant for VS Code Build notebooks, submit jobs, and manage workspaces from VS Code Included: All editions Not included: Cloud only Not included Wherobots MCP Server Natural-language data discovery and SQL generation in Claude, Cursor, and VS Code Copilot Included: Available Not included: Cloud only Not included Wherobots CLI Automate spatial workflows from the command line Included Not included: Cloud only Not included Performance Performance vs Apache Sedona Measured on identical infrastructure Included: About 3x faster on the Rust-native, Arrow-columnar runtime Included: About 2x faster Baseline Price-performance Included: 20 to 30% better price-performance Your infrastructure costs Baseline Sources: Wherobots documentation, Wherobots pricing, and SpatialBench results. Updated April 2026. Benchmark SpatialBench results: spatial joins at scale Both WherobotsDB options complete all 12 SpatialBench query patterns at scale factor 1000. Apache Sedona completes six. The six it does not complete are zone statistics within a search radius (Q6), radius joins (Q8), polygon overlap detection (Q9), zone statistics through a spatial join (Q10), cross-zone trip counting (Q11), and KNN joins (Q12). Wherobots Cloud WherobotsDB BYOS Apache Sedona SpatialBench results: spatial joins at scale Capability Wherobots Cloud WherobotsDB BYOS Apache Sedona SpatialBench SF-1000: 520 GB, 6 billion records, 12 query patterns Q1 to Q5, Q7 Filtering, aggregation, convex hull, and basic joins Included: Pass Included: Pass Included: Pass Q6 Zone statistics aggregated within a search radius Included: Pass Included: Pass Not included: Does not complete Q8 Radius join: count nearby features per building Included: Pass Included: Pass Not included: Does not complete Q9 Polygon overlap detection and IoU Included: Pass Included: Pass Not included: Does not complete Q10 Zone statistics through a spatial join Included: Pass Included: Pass Not included: Does not complete Q11 Cross-zone trip counting, two spatial joins per record Included: Pass Included: Pass Not included: Does not complete Q12 KNN join: five nearest neighbors per record Included: Pass Included: Pass Not included: Does not complete SpatialBench is the open benchmark for spatial query engines from the Apache Sedona project. Read about WherobotsDB on SpatialBench. How to choose Your Sedona code comes with you Wherobots Cloud is the fastest way to run spatial in production, with WherobotsDB, RasterFlow, and the Havasu Catalog in one managed platform. Apache Sedona code runs on it without changes, and teams that must stay on their own Spark clusters run the same code on WherobotsDB BYOS. Raster and Earth intelligence Out-of-database raster comes with both WherobotsDB options. RasterFlow, Earth intelligence and perception as a service that turns imagery into physical-world features, runs in Wherobots Cloud. Spatial AI developer tools The Spatial AI Coding Assistant, MCP Server, and CLI come with Wherobots Cloud and put spatial analysis within reach of the whole team. Infrastructure control and data residency If compute must stay on your own infrastructure for compliance, procurement, or architecture reasons, WherobotsDB BYOS adds enterprise spatial without a managed platform. Function reference Every spatial SQL function, by platform Search 389 Apache Sedona and WherobotsDB functions across 32 categories, filter by vector or raster, and see where each one runs. Need a function that is not listed? Wherobots adds custom ST_ and RS_ functions for customers on request. Search functions Data type Vector and raster Vector Raster Availability All platforms Wherobots only (not in Apache Sedona) Available in WherobotsDB BYOS Category All categories Address Functions Affine Transformations Aggregate Functions Aggregates Band Accessors Bounding Box Functions Clustering Functions Connected Components (CC) Predicates Geography Type Functions Geometry Accessors Geometry Constructors Geometry Editors Geometry Output / Export Geometry Processing Geometry Validation Linear Referencing Map Algebra Operators Measurement Functions Operators Output Overlay Functions Per-Pixel Math (Map Algebra) Pixel Functions Predicates Predicates / Topological Relationships Raster Accessors Raster Constructors Raster Geometry Functions Spatial Indexing (H3, S2, Bing Tiles, GeoHash) Spatial Reference System Spatial Statistics Tiles 389 functions Function Category Apache Sedona WherobotsDB BYOS Wherobots Cloud What it does ExpandAddress Address Functions Available Available Available libpostal address expansion ParseAddress Address Functions Available Available Available libpostal address parsing ST_GetReverseGeocodingLayers Address Functions Not available Available Available layers available to ST_ReverseGeocode ST_ReverseGeocode Address Functions Not available Available Available address for a geometry ST_Affine Affine Transformations Available Available Available general affine transformation ST_Rotate Affine Transformations Available Available Available rotate geometry; Wherobots supports custom origin ST_RotateX Affine Transformations Available Available Available rotate around X axis ST_RotateY Affine Transformations Available Available Available rotate around Y axis ST_Scale Affine Transformations Available Available Available scale geometry ST_ScaleGeom Affine Transformations Available Available Available scale using factor geometry ST_Translate Affine Transformations Available Available Available translate geometry by offsets ST_Analyze_Aggr Aggregate Functions Not available Not available Available aggregate geometry statistics ST_Collect_Agg Aggregate Functions Available Available Available collects without dissolving ST_Envelope_Agg Aggregate Functions Available Available Available return aggregate bounding envelope ST_Intersection_Agg Aggregate Functions Available Available Available aggregate polygon intersection ST_Union_Agg Aggregate Functions Available Available Available compute aggregate union ST_3DExtent Aggregate Functions Available Available Available 3D bounding box aggregate (Box3D) ST_Extent Aggregate Functions Available Available Available bounding box aggregate (Box2D) RS_Union_Aggr Aggregates Available Available Available stacks bands from multiple rasters RS_Band Band Accessors Available Available Available returns a new raster with one or more bands of an existing raster RS_BandIsNoData Band Accessors Available Available Available returns true if the band is filled with only nodata values RS_BandNoDataValue Band Accessors Available Available Available returns the no data value of the given band of the given raster RS_BandPixelType Band Accessors Available Available Available returns the pixel data type of a band as a string RS_Count Band Accessors Available Available Available returns the number of pixels in a given band RS_SummaryStats Band Accessors Available Available Available returns one summary statistic for a band RS_SummaryStatsAll Band Accessors Available Available Available returns count, sum, mean, standard deviation, min, and max for a band RS_ZonalStats Band Accessors Available Available Available returns one statistic computed over a zone geometry RS_ZonalStatsAll Band Accessors Available Available Available returns a struct of statistics computed over a zone geometry RS_ZonalStatsAllBands Band Accessors Not available Available Available zonal statistics for all bands in one call ST_BoundingDiagonal Bounding Box Functions Available Available Available diagonal linestring of bbox ST_Envelope Bounding Box Functions Available Available Available return 2D bounding box ST_Expand Bounding Box Functions Available Available Available expand bounding box ST_MMax Bounding Box Functions Available Available Available max M coordinate ST_MMin Bounding Box Functions Available Available Available min M coordinate ST_XMax Bounding Box Functions Available Available Available return max X coordinate ST_XMin Bounding Box Functions Available Available Available return min X coordinate ST_YMax Bounding Box Functions Available Available Available return max Y coordinate ST_YMin Bounding Box Functions Available Available Available return min Y coordinate ST_ZMax Bounding Box Functions Available Available Available return max Z coordinate ST_ZMin Bounding Box Functions Available Available Available return min Z coordinate ST_3DMakeBox Bounding Box Functions Available Available Available Box3D from two corner points ST_Box2D Bounding Box Functions Available Available Available planar bounding box as Box2D ST_Box3D Bounding Box Functions Available Available Available 3D bounding box as Box3D ST_GeomFromBox2D Bounding Box Functions Available Available Available Box2D to a rectangular polygon ST_MakeBox2D Bounding Box Functions Available Available Available Box2D from two corner points ST_DBSCAN Clustering Functions Available Available Available density-based spatial clustering ST_LocalOutlierFactor Clustering Functions Available Available Available LOF anomaly detection ST_ContainsCC Connected Components (CC) Predicates Not available Available Available spatial connected components via Contains ST_CoveredByCC Connected Components (CC) Predicates Not available Available Available spatial connected components via CoveredBy ST_CoversCC Connected Components (CC) Predicates Not available Available Available spatial connected components via Covers Available Not available Show all 389 functions No functions match these filters. Function names link to the Wherobots documentation. Wherobots vs. Apache Sedona FAQ What is the difference between Apache Sedona and Wherobots? Apache Sedona is the open-source spatial engine for Apache Spark, free under the Apache 2.0 license. Wherobots is the fully managed context engine for physical world data from the original creators of Sedona. It brings together WherobotsDB, the enterprise spatial runtime; RasterFlow, Earth intelligence and perception as a service that turns imagery into physical-world features; the Havasu Catalog of open datasets, RasterFlow models, notebooks, and apps next to your own data in Apache Iceberg; and Spatial AI developer tools, including the Spatial AI Coding Assistant for VS Code, the Wherobots MCP Server, and the Wherobots CLI. Apache Sedona code runs on Wherobots without changes. What is the difference between Apache Sedona and WherobotsDB? WherobotsDB is the enterprise spatial runtime from the original creators of Apache Sedona. It is 100% compatible with Sedona APIs and adds automatic query optimization, out-of-database raster, approximate KNN, and support SLAs. WherobotsDB runs on your own Spark clusters (BYOS) or fully managed in Wherobots Cloud. Is WherobotsDB compatible with Apache Sedona? Yes. WherobotsDB is 100% compatible with Apache Sedona APIs, so existing Sedona SQL and Python code runs without rewrites. Can I run WherobotsDB on my own Spark clusters? Yes. WherobotsDB Bring Your Own Spark (BYOS) is a drop-in runtime for existing Spark clusters, offered in the Enterprise edition. Data stays where it is and governance does not change. See pricing. Who builds Apache Sedona? The original creators of Apache Sedona are the founders of Wherobots. They continue to contribute to the project, which is maintained by the Apache Software Foundation community. What is SpatialBench? SpatialBench is an open benchmark for spatial query engines from the Apache Sedona project. It runs reproducible workloads such as point-in-polygon, range queries, spatial joins, and nearest-neighbor joins at multiple scale factors, so teams can compare engines on their own infrastructure. Does Apache Sedona support raster data? Yes, Apache Sedona processes rasters in memory. WherobotsDB adds out-of-database raster, which loads pixels on demand from object storage, and Wherobots Cloud adds RasterFlow for mosaics and computer vision inference over satellite and aerial imagery. Can Wherobots add a spatial function I need? Yes. Wherobots adds custom ST_ vector and RS_ raster functions for paying customers on request. Talk to us about your workload. See how your Sedona workloads run on Wherobots Bring a query or a dataset and we will compare Wherobots Cloud, Apache Sedona, and WherobotsDB BYOS on your workload. Schedule use case review --- ## RasterFlow Offer URL: https://wherobots.com/rasterflow-offer/ Updated: 2026-10-05 RasterFlow Price your geospatial workload before you run it. Get $1,000+ in usage credits to run a proof of concept on RasterFlow, the serverless Earth Intelligence engine. Claim Your Credits $1,000+ in usage credits Get $1,000+ in usage credits for RasterFlow RasterFlow builds mosaics, runs computer-vision inference, and vectorizes results as area-priced tasks against your own S3 storage. Same workload, priced up front 150,000 km² · Sentinel-2 · 12 bands You price the workload before running it. The same 150,000 km2 Sentinel-2 mosaic across 12 bands runs about $50 on Earth Engine and about $13.50 on RasterFlow. Earth Engine ~$50 RasterFlow ~$13.50 01 Bring one real workload from your Earth Engine-style tool and we deposit the credits. 02 If the scope runs past the first $1,000, we raise it to cover the full POC. Claim Your Credits👇 First name*Last name* Email* Company name* Job title* --- ## Wherobots for QGIS: Cloud-Scale Spatial Data, from Wherobots Labs URL: https://wherobots.com/blog/spatial-sql-qgis/ Updated: 2026-10-19 Wherobots for QGIS is a new plugin that connects QGIS to Wherobots Cloud. From a panel inside QGIS, an analyst can run spatial SQL against WherobotsDB, load the results as a map layer, push a local layer up to a Wherobots Iceberg table, and pull raster data into the canvas.  Key takeawaysWherobots for QGIS connects QGIS to Wherobots Cloud, so an analyst runs spatial SQL against WherobotsDB without leaving the map.The compute runs in the cloud, and QGIS stays the place to view the answer. One copy of the data, no exports.Three tabs: SQL Query, Upload, and Raster. The plugin runs on QGIS 3.22 through QGIS 4.0, on both Qt5 and Qt6.The same WherobotsDB tables reach Python notebooks, SQL clients, the Wherobots CLI, and AI coding tools through MCP. QGIS joins that list.It is available today from the QGIS Plugin Repository and needs a Wherobots Cloud account, with a free trial. It is the first release from Wherobots Labs. Why Wherobots for QGIS: Eliminating the partitioning tax GIS analysts hit the same wall in city after city. A workflow that runs fine on a neighborhood runs fine on a district. At state scale, it crashes or runs for hours. At country scale, the analyst has to write a loop, tile the data by county, process each tile, handle the features that fall on the boundary, reassemble the output, and discover the seam artifacts two days later. That loop is not the analysis. It is overhead that the existing tools and databases impose. This is the partitioning tax. It is not a performance problem. It is an architectural one. Desktop GIS and single-node databases process data on one machine. When the data outgrows that machine, the analyst absorbs the cost: split the extent, manage the tiles, merge the results, debug the edges. Every time a parameter changes, run it again. Testing at city scale and assuming it generalizes is not a workflow, it is a bet. The same constraint blocks AI coding assistants. Tools like Claude Code and Cursor are fluent at writing spatial SQL for a single-pass query. Ask one to scale a workflow from a county to a state and it generates a partition loop with no overlap buffer and no dedupe logic. The model does not know about edge effects. The developer still has to do the work. Wherobots for QGIS is a new plugin that removes the wall on the QGIS side of the stack. An analyst writes spatial SQL in a panel inside QGIS. WherobotsDB executes it in the cloud across the full extent, whether that extent is a city block or a continent, with no partition logic in the query and no tile management by the analyst. The result loads as a map layer. What the Wherobots QGIS plugin does The panel has three tabs, plus a connection screen where you enter an API key and pick a region and runtime. SQL Query Write spatial SQL in a free-form editor, or switch to Browse Tables and pick a table from the catalog. Set a row limit. Check one box to restrict results to the current map extent. Results land in the QGIS project as a layer, ready for styling, joins, or export. Upload Select a vector layer in your project, give it a destination table name, and send it to Wherobots. The plugin creates the table and inserts the features in batches while QGIS stays responsive. Raster Run raster SQL with RS_ functions against raster tables. Use the current map extent as the bounding box. A query that returns RS_AsGeoTiff loads as a raster layer. A query that returns RS_Values gives you pixel values as a table. The plugin runs on QGIS 3.22 through QGIS 4.0, covering both Qt5 and Qt6 builds. One copy of the data across QGIS, notebooks, and AI coding assistants Wherobots has one job in this picture: hold the data and run the compute. The interface should follow the person doing the work. Today the same WherobotsDB tables are reachable from a Python notebook, a SQL client, a Python Job, the Wherobots CLI, and from AI coding assistants like VS Code, Cursor, and Claude Code through the Wherobots MCP Server. QGIS joins that list. The tables an analyst opens on the canvas are the same tables an agent queries through MCP. One copy of the data. No exports. This is what making spatial accessible means in practice. An analyst who knows QGIS and knows SQL can now run a spatial join across hundreds of millions of records and see the result on a map, without standing up a cluster or learning a new interface. WherobotsDB, built by the original creators of Apache Sedona, handles the distribution, indexing, and coordinate systems underneath. How to install the Wherobots plugin in QGIS Download the plugin zip from the Releases page and install it in QGIS under Plugins → Manage and Install Plugins → Install from ZIP. Install the wherobots-python-dbapi package into QGIS’s bundled Python. The README has a two-line snippet for the QGIS Python Console that works on every platform. Open the Wherobots panel from the toolbar or Web → Wherobots, paste your API key, and connect. You need a Wherobots Cloud account. Start a free trial if you do not have one. The wherobots_open_data catalog, including Overture Maps, is a good first query. Introducing Wherobots Labs Wherobots for QGIS is the first project published under Wherobots Labs. Labs is where Wherobots ships the projects that live at the edge of the platform: connectors, plugins, adapters, example pipelines, and skills for AI coding assistants. They are built by the solutions architects and customer engineers who work with Wherobots customers every day, and by community contributors. Every Labs repository follows the same rules. It is public on GitHub under the wherobots organization with a labs- prefix. It is Apache 2.0 licensed unless noted otherwise. It has a README with a plain statement of support expectations, a CONTRIBUTING.md, and GitHub Issues enabled. It gets a security review before first release, and security fixes continue under the standard Wherobots security policy. What a Labs project does not carry is a production SLA. You are responsible for confirming a project fits your use case before you rely on it, and you are free to fork it. A Labs project that earns adoption can graduate to a supported product surface. More Labs projects are on the way. Browse them at here and open an issue or a pull request on any of them. If you use QGIS and you have a dataset that stopped fitting on your machine, install the plugin and tell us what you build. Get Started with Wherobots Try Now Frequently Asked Questions What is Wherobots for QGIS? Wherobots for QGIS is a plugin that connects QGIS to Wherobots Cloud. From a panel inside QGIS, an analyst runs spatial SQL against WherobotsDB and loads results as a map layer. The analyst can also push a local layer up to a Wherobots table and pull raster data into the canvas. How do I run spatial SQL in QGIS? Open the Wherobots panel, enter your API key, and pick a region and runtime. In the SQL Query tab, write spatial SQL in a free-form editor or switch to Browse Tables and pick a table from the catalog. Results land in the QGIS project as a layer, ready for styling, joins, or export. Is the Wherobots QGIS plugin free? Wherobots for QGIS is available from the QGIS Plugin Repository. As a Wherobots Labs project, its repository is public on GitHub and Apache 2.0 licensed unless noted otherwise. You need a Wherobots Cloud account to run queries, and a free trial is available. Which QGIS versions does the plugin support? The plugin runs on QGIS 3.22 through QGIS 4.0, covering both Qt5 and Qt6 builds. Do I need to export my data to use it? No. WherobotsDB holds one copy of the data. The tables an analyst opens on the canvas are the same tables reached from a Python notebook, a SQL client, the Wherobots CLI, and AI coding tools through MCP. What is Wherobots Labs? Wherobots Labs is the home for projects at the edge of the platform: connectors, plugins, adapters, example pipelines, and skills for AI coding assistants. Every Labs repository is public on GitHub with a labs- prefix, Apache 2.0 licensed unless noted otherwise, and gets a security review before first release. Labs projects do not carry a production SLA. --- ## Wherobots Labs URL: https://wherobots.com/labs/ Updated: 2026-10-01 Open source Wherobots Labs: open-source projects at the edge of Wherobots Connectors, plugins and reference implementations built by Wherobots solutions architects, customer engineers and the community. Free to use, fork and improve. See the projects How to contribute Projects Active Wherobots for QGIS Run spatial SQL on Wherobots from QGIS and see the results as map layers. Upload local layers to Wherobots tables and query raster data into the map canvas. QGIS plugin Python Apache 2.0 View on GitHub Download a release Active Wherobots job runs from AWS Step Functions Submit and monitor Wherobots job runs from an AWS Step Functions pipeline with the Wherobots Python SDK. Uses the callback pattern with heartbeats and a poller fallback, plus a guided dashboard from deploy to teardown. Reference implementation Python Apache 2.0 View on GitHub Read the blog post Incubating SedonaDB in the browser SedonaDB, a subproject of Apache Sedona, compiled to WebAssembly (WASM), so spatial SQL runs entirely in the browser with no server. Queries Overture Maps GeoParquet on S3 and draws the results on a map. Rust WebAssembly Repository opens soon How Labs works Owned by its authors Each project is maintained by the team that built it, on a best-effort basis with no production SLA. Security issues are the exception and are fixed under the Wherobots security policy. Open by default Labs projects are public on GitHub under the wherobots organization, with a labs- prefix and an Apache 2.0 license. Room to graduate A Labs project with enough adoption can become a supported part of the Wherobots product. Contribute to Labs Teams and organizations contribute through standard GitHub pull requests. 01 Start with an issue Report a bug or propose a change in the project's GitHub Issues before starting large work. 02 Send a pull request Fork the repo, follow its CONTRIBUTING.md and open a pull request. Every change goes through the same review and automated tests as internal work. 03 Propose a new project Labs is for connectors, plugins, example pipelines and tooling that connect to Wherobots without changing it. Talk to us Contributions are licensed under Apache 2.0, and contributing gives no access to core Wherobots repositories. Report security issues privately to security@wherobots.com, not in a public issue. --- ## How Wherobots builds with NVIDIA to let AI see the physical world URL: https://wherobots.com/blog/wherobots-nvidia-geospatial-ai-physical-world/ Updated: 2026-10-19 AI was blind to the physical world, but Wherobots is giving AI the ability to understand it using data, compute, and NVIDIA GPUs Key takeawaysWherobots gives AI the ability to operate on and understand raw physical-world data, and NVIDIA GPUs are core to it. Wherobots deploys NVIDIA GPUs and libraries on tasks they are optimized for.RasterFlow processes pixels with a distributed fleet of NVIDIA G7e AWS instances, accelerated by RTX PRO 6000 Blackwell GPUs. CUDA streams keep three batches in flight at once.That drives mosaicking and inference costs to typically 2-3x less than the next best option at scale. SAM3 on 30cm imagery runs for under $25 per 1,000 square kilometers.SedonaDB runs spatial joins directly on the ray tracing cores inside NVIDIA GPUs. In SedonaDB 0.4, Wherobots shipped a GPU-accelerated spatial join that delivers up to a 5.9x speedup and a 59% cost reduction on the standard spatial benchmark.The research paper, RayBooster: A Ray Tracing Engine to Accelerate SedonaDB, was accepted to VLDB 2026 in the Industry Track.RasterFlow is validated in production with Taylor Geospatial, Microsoft AI for Good Lab, and NASA Harvest (Fields of the World). It is actively supporting the US Forest Service (FireCon) to deliver daily wildfire containment suitability mapping across the Western US in H2 2026. The world and what happens in it is digitized by petabytes of raw and derivative spatial datasets of various data types and scales, and the potential for applying AI to it is immense. But the AI models and agents we use every day need connectivity to tools that turn this data into usable insights and relationships. Wherobots gives AI the ability operate on and understand raw physical-world data, and NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs are core to it. Architecturally here’s how this works at a high level. Wherobots: Integrates with your open data architecture: by utilizing data lakes like Amazon S3 and Iceberg catalogs such as Databricks Unity Catalog and AWS Glue Data Catalog as the center of truth, you can integrate Wherobots into your existing data architecture. Brings the spatial capability: data teams and their agents have the capability to solve the most challenging physical world problems by directing Wherobots to extract insights from multi-dimensional, raster, vector, and tabular datasets of various formats and scales. Is plug-and-play: in minutes, you can enable AI coding tools like VS Code, Claude Code, and Cursor to direct Wherobots operations on this data and build innovations with AI. Under the hood, we deploy RTX PRO 6000 Blackwell GPUs and libraries on tasks they are optimized for. RTX PRO 6000 Blackwell GPUs run at the core of RasterFlow, which is the preprocessing and inference solution designed to make insight extraction from satellite and aerial sensor datasets easy. We also leverage NVIDIA CUDA™ streams to optimize performance. RasterFlow crunches pixels with a distributed fleet of NVIDIA G7e Amazon Web Services (AWS) instances, accelerated by RTX PRO 6000 Blackwell GPUs. These GPUs, built on the groundbreaking Blackwell architecture, feature the second-generation Transformer Engine to deliver unprecedented performance, efficiency, and scale for generative AI and accelerated computing. SedonaDB, which WherobotsDB utilizes in a distributed mode, can run spatial joins directly on the ray tracing cores inside RTX PRO 6000 Blackwell GPUs to deliver the best price-performance for a class of spatial join types. Let’s dig in. RasterFlow on NVIDIA RasterFlow prepares large scale imagery data for inference and runs computer vision models on a distributed inference architectureIts goal is to give customers the ability to generate insights from this data across physical areas of interest of any scale, enabling real-world applications such as: Last-Mile Delivery Routing: Identifies sidewalks (using models like Tile2Net) which can help determine viable navigational routes for both manual and autonomous delivery systems. Property Risk Analytics: Can aid in quantifying the number of properties facing flood risk across coastal cities by embedding FEMA flood zone designations into parcel-level data, helping insurers, reinsurers, and real estate developers evaluate policy and property portfolios. Since its introduction in private preview, we continue to optimize the RasterFlow architecture, reaching a point where mosaicking and inference tasks cost 2–3x less than the next best option at scale. For instance, RasterFlow supports Meta’s Segment Anything Model (SAM3) for general-purpose object detection on Earth Observation imagery. With the efficiencies we’ve achieved, you can use SAM3 to detect objects from high-resolution 30cm imagery for less than $25 per 1,000 square kilometers. Example of roof detections on 30cm imagery using Meta’s Segment Anything Model (SAM3) RasterFlow uses CUDA™ streams to keep GPUs busy Data movement can kill inference performance, so we use NVIDIA CUDA™ streams and RTX PRO 6000 Blackwell GPUs to address this bottleneck. Every batch of satellite imagery patches travels from host memory to the GPU before the model can run, and every batch of prediction patches travels back before RasterFlow can merge it into a seamless output mosaic. If we ran these steps serially one after another, our GPUs would idle on PCIe transfers with every forward pass. CUDA™ streams remove that idle time. A stream is an ordered queue of GPU work, where different kinds of work in different streams can execute concurrently. . RTX PRO 6000 Blackwell GPUs include dedicated copy engines that move data across PCIe independently of the compute cores, which means a transfer in one stream proceeds while a model forward pass runs in another. RasterFlow drives this through PyTorch’s torch.cuda.Stream API. This inference loop has separate upload and download streams feeding two reusable buffer slots. While the model runs batch N on the first stream, a second stream copies the next batch to the GPU, and a download stream drains the predictions from batch N-1 back to host memory, where the CPU merges patches in the mosaic accumulator. At steady state three batches are in flight at once: one uploading, one computing, one landing in the output. RasterFlow allocates these buffers once and reuses them for every batch. CUDA™ events sequence the handoff between streams, so data movement never starts before the forward pass that produced it finishes. This allows the GPU to stay busy from the first patch to the last. What’s next: GPU-native decompression with NVIDIA nvCOMP™ and Zarr RasterFlow stores every analysis-ready mosaic as a Zarr store of compressed chunks on Amazon S3, and today those chunks decode on the CPU. nvCOMP™, NVIDIA’s library of GPU-accelerated compression codecs, can move that decode step onto the GPU itself, and we are looking forward to nvCOMP™-backed codec support landing in Zarr. The payoff of this feature is three-fold. First, compressed chunks cross PCIe instead of raw pixels, so each transfer carries fewer bytes. Second, decompression runs at GPU memory bandwidth (which is higher than CPU) and the decoded array materializes directly in GPU memory where the model needs it. Finally, CPU cores are free for the work only they can do: assembling patches and merging predictions into the mosaic. RasterFlow use cases RasterFlow continues to unblock customers who need to extract insights from global-scale imagery datasets. We are actively working with customers across multiple industries, and utilizing RasterFlow to deliver results like these: The Fields of the World global run produced globally consistent agricultural field-boundary data for land-use monitoring, food-system analysis, and model development. We executed this run using RasterFlow, and led it in partnership with Taylor Geospatial, Microsoft AI for Good Lab, and Nasa Harvest. With RasterFlow you can run this same model with 10m Sentinel-2 imagery, including cloud-free mosaic generation and model inference, for less than $1 per 10,000 square kilometers. Agricultural field boundaries predicted by Taylor Geospatial’s Fields of the World model running on RasterFlow. We are actively supporting the US Forest Service in their research, and our joint goal is to bring their new FireCon model online in the second half of this calendar year. This initiative is key to delivering far more accurate daily wildfire containment suitability mapping system for active wildfires of the Western US, enabling better planning, management, and response to wildfires. FireCon model predictions for the best fire control points generated across the western United States by RasterFlow. SedonaDB on NVIDIA WherobotsDB runs a distributed version of SedonaDB, which customers use to efficiently process and join two dimensional raster and vector data. In SedonaDB 0.4, we shipped a GPU-accelerated spatial join as an extension that runs on RTX PRO 6000 Blackwell GPU ray tracing cores. In practice, almost all spatial analyses are powered by one or more spatial joins, which are computationally intensive and frequently a bottleneck in spatial queries. But SedonaDB with GPU acceleration provides relief, and delivers up to a 5.93x speedup and a 59.02% cost reduction on our standard spatial benchmark. The research behind it, RayBooster: A Ray Tracing Engine to Accelerate SedonaDB, was accepted to VLDB 2026 in the Industry Track, and we developed it with The Ohio State University. Attempts to accelerate traditional analytical database workflows using GPUs have typically required utmost care and/or rethinking of a workflow to minimize data transfer between the existing workflow (on the CPU) and the accelerated implementation (on the GPU). The spatial join is an ideal candidate for this type of acceleration because it is computationally intensive, and relatively small amounts of data transfer can result in large numbers of computations. Furthermore, the required data transfer is only a single direction; geometries must be transferred to the GPU but need not be transferred back. Another limitation to GPU acceleration of traditional database workflows has been a requirement for a potentially large amount of GPU memory to avoid completely rewriting a workflow with careful attention to the sizes of the inputs. SedonaDB’s join implementation was built to partition large joins into smaller ones that can be run with limited memory with its CPU-based join, and while this heuristic needs to be tuned differently for GPUs, we did not need to rewrite our GPU implementation to support arbitrarily large joins. This extends the acceleration we observed to a wider range of GPUs that customers may have available. Deploying AI on physical world data with NVIDIA High complexity, scale, and costs have limited the utilization of spatial data, resulting in a significant gap between AI and physical world data. This gap is closing fast and as it closes, humans are more capable of directing AI towards solutions that drive top, bottom, and the sustainability lines of their business. Through our investments in Apache Sedona and Wherobots, and by building on NVIDIA technology, data teams and their agents are becoming increasingly capable of innovating and operating solutions with physical world data, under budget, with the talent and AI tools they already have, regardless of spatial data type and degree of complexity. Get Started with Wherobots Try Now Frequently Asked Questions How does Wherobots use NVIDIA GPUs? Wherobots deploys NVIDIA GPUs and libraries on tasks they are optimized for. NVIDIA GPUs run at the core of RasterFlow, the preprocessing and inference solution designed to make insight extraction from satellite and aerial sensor datasets easy.SedonaDB, which WherobotsDB runs in a distributed mode, runs spatial joins directly on the ray tracing cores inside NVIDIA GPUs. That delivers the best price-performance for a class of spatial join types. How much does it cost to run object detection on satellite imagery with RasterFlow? RasterFlow supports Meta’s Segment Anything Model (SAM3) for general purpose object detection on Earth Observation imagery. With the efficiencies Wherobots has achieved, teams can use SAM3 to detect objects from high resolution 30cm imagery for less than $25 per 1,000 square kilometers. RasterFlow sells mosaicking and inference tasks at a cost that is typically 2-3x less than the next best option, at scale. How much faster is the SedonaDB GPU spatial join? In SedonaDB 0.4, Wherobots shipped a GPU-accelerated spatial join as an extension that runs on NVIDIA GPU ray tracing cores. SedonaDB with GPU acceleration delivers up to a 5.93x speedup and a 59.02% cost reduction on Wherobots’ standard spatial benchmark. Almost all spatial analyses are powered by one or more spatial joins, which are computationally intensive and frequently a bottleneck in spatial queries. Who uses RasterFlow in production? Wherobots is actively working with customers across multiple industries. The Fields of the World global run produced globally consistent agricultural field-boundary data, executed with RasterFlow in partnership with Taylor Geospatial, Microsoft AI for Good Lab, and NASA Harvest. Wherobots is also actively supporting the US Forest Service, with the joint goal of bringing the FireCon wildfire containment model online in H2 2026. --- ## Havasu URL: https://wherobots.com/havasu/ Updated: 2026-10-04 Havasu Catalog. The knowledge lake for the physical world. Havasu streamlines discovery, access, and semantic understanding of physical-world data, models, jobs, and apps. Start from what Wherobots publishes in the open to what you and your team build in your own data lake. Explore the catalog Start for free The history of HavasuRead the story → From GeoSpark to the Havasu catalog GeoSparkApache SedonaHavasu formatIceberg GEOToday AI coding toolsSet up → Query Havasu from Claude, Cursor, or VS Code The Wherobots MCP server connects your AI coding tool to the catalog. Ask for a dataset and the agent writes and runs the spatial SQL. Open data and RasterFlow output on one map Parker Valley fields Lake Havasu City NAIP imagery 0.3 m, USDA Field boundaries RasterFlow · Fields of the World Labels field area, hectares NAIP imagery 0.3 m, USDA Buildings Overture Maps Roads Overture Maps Places Overture Maps 229 fields detected by RasterFlow on NAIP imagery, 25 km south of Lake Havasu 1,072 buildings, 956 roads and 682 places from Overture over NAIP NAIP · June 2023 The open catalog Datasets42 Models6 Solution notebooks9 Demo apps6 All providers All notebook topics Any format Vector Raster Tabular 63 results Open geospatial datasets 42 USDA NAIPRaster USDA NAIP aerial imagery High-resolution aerial imagery (30 cm to 1 m) of the continental United States from the USDA National Agriculture Imagery Program, flown state by state on a two-year cycle. Wherobots manages it as a RasterFlow built-in dataset: build red, green, blue, and near-infrared mosaics for any area of interest without staging imagery yourself. RasterFlow built-in dataset What is Earth observation data? → ESA Copernicus Sentinel-2Raster Sentinel-2 seasonal mosaics Cloud-filtered median composites of Sentinel-2 L2A imagery at 10 m, built on demand for any area of interest. Wherobots manages it as a RasterFlow built-in dataset: pick a planting season, harvest season, or custom date window, and RasterFlow selects scenes, masks clouds and shadows, and writes an analysis-ready mosaic without staging imagery yourself. RasterFlow built-in dataset What is change detection in satellite imagery? → CopernicusRaster Copernicus DEM GLO-30 Global 30 m digital surface model from the Copernicus programme, stored as raster tiles with footprints. wherobots_open_data.copernicus_dem.glo_30m 6 columnsApache Iceberg What is a digital elevation model? → ESA Copernicus Sentinel-2Imagery index Sentinel-2 L2A scene index STAC items for Sentinel-2 Level-2A scenes with footprints, acquisition times, cloud cover, and links to Cloud Optimized GeoTIFF bands. wherobots_open_data.sentinel2.l2a_source_items 20 columnsApache Iceberg What is a GeoTIFF? → OpenStreetMapVector OpenStreetMap nodes OpenStreetMap node features with tags. wherobots_pro_data.osm.nodes 9 columnsApache Iceberg OpenStreetMapVector OpenStreetMap ways OpenStreetMap way features such as roads, rivers, and building outlines, with tags. wherobots_pro_data.osm.ways 8 columnsApache Iceberg Overture Maps FoundationVector Overture buildings Global building footprints with height, floor count, and class where available. wherobots_open_data.overture_maps_foundation.buildings_building 24 columnsApache Iceberg What is a flood risk map? → Overture Maps FoundationVector Overture division areas Polygons for administrative divisions such as countries, regions, and localities. wherobots_open_data.overture_maps_foundation.divisions_division_area 14 columnsApache Iceberg Overture Maps FoundationVector Overture infrastructure Infrastructure features such as towers, bridges, and power lines from the Overture Maps base theme. wherobots_open_data.overture_maps_foundation.base_infrastructure 13 columnsApache Iceberg Data center site selection criteria → Overture Maps FoundationVector Overture transportation segments Road, rail, and water transportation segments with class, speed limits, and access rules. wherobots_open_data.overture_maps_foundation.transportation_segment 21 columnsApache Iceberg US Census BureauVector TIGER counties US county boundaries from TIGER/Line. wherobots_open_data.us_census.tiger_county 19 columnsApache Iceberg Allen Institute for AI (Satlas)Raster Satlas offshore infrastructure Sentinel-2 image tiles from Allen AI's Satlas project over coastal and offshore areas used to map wind turbines and platforms, stored as multiband rasters with footprints. wherobots_pro_data.satlas.offshore_satlas 4 columnsApache Iceberg What is geospatial AI? → Allen Institute for AI (Satlas)Raster Satlas solar farms Sentinel-2 image tiles from Allen AI's Satlas project over solar farm areas in Arizona and southern Nevada, stored as multiband rasters with footprints. wherobots_pro_data.satlas.solar_satlas 4 columnsApache Iceberg What is geospatial AI? → Google and MicrosoftVector Google and Microsoft Open Buildings Combined building footprints from the Google Open Buildings and Microsoft Building Footprints datasets. wherobots_pro_data.google_microsoft.open_buildings 6 columnsApache Iceberg What is catastrophe modeling? → NASA and METIRaster ASTER Global DEM v3 (30 m) Global digital elevation model at 30 m resolution, stored as raster tiles with a footprint for each tile. wherobots_open_data.aster_gdem.v3_30m 6 columnsApache Iceberg What is a digital elevation model? → Meta and WRIRaster Meta Global Canopy Height v2 Global tree canopy height map (CHMv2) from Meta and the World Resources Institute, made with machine learning on high-resolution satellite imagery and stored as raster tiles with a footprint for each tile. wherobots_open_data.meta_canopy_height.global_v2 6 columnsApache Iceberg NOAA National Weather ServiceVector NWS watches and warnings National Weather Service watch and warning polygons with event type, severity, and effective times. wherobots_open_data.noaa.nws_watch_warnings 26 columnsApache Iceberg What is the HRRR model? → NYC Taxi and Limousine CommissionVector NYC yellow taxi trips 2009 to 2010 New York City yellow taxi trip records with pickup and dropoff points, times, and fares. wherobots_pro_data.nyc_taxi.yellow_2009_2010 20 columnsApache Iceberg OpenStreetMapVector OpenStreetMap postal codes Postal code areas from OpenStreetMap. wherobots_pro_data.osm.postal_codes 3 columnsApache Iceberg Overture Maps FoundationVector Overture addresses Address points from the Overture Maps addresses theme. wherobots_open_data.overture_maps_foundation.addresses_address 12 columnsApache Iceberg Overture Maps FoundationVector Overture bathymetry Ocean depth polygons from the Overture Maps base theme. wherobots_open_data.overture_maps_foundation.base_bathymetry 7 columnsApache Iceberg Overture Maps FoundationVector Overture building parts Parts of buildings with their own height and shape, linked to a parent building. wherobots_open_data.overture_maps_foundation.buildings_building_part 22 columnsApache Iceberg Overture Maps FoundationVector Overture division boundaries Boundary lines between administrative divisions. wherobots_open_data.overture_maps_foundation.divisions_division_boundary 15 columnsApache Iceberg Overture Maps FoundationVector Overture divisions Administrative and named places from countries to neighborhoods, as points with hierarchy. wherobots_open_data.overture_maps_foundation.divisions_division 21 columnsApache Iceberg Overture Maps FoundationVector Overture geocodes Geocoding table built by Wherobots from Overture Maps addresses and places. wherobots_open_data.overture_maps_foundation.geocodes 4 columnsApache Iceberg Overture Maps FoundationVector Overture land Land features such as islands, peaks, and cliffs from the Overture Maps base theme. wherobots_open_data.overture_maps_foundation.base_land 13 columnsApache Iceberg Overture Maps FoundationVector Overture land cover Global land cover polygons from the Overture Maps base theme. wherobots_open_data.overture_maps_foundation.base_land_cover 7 columnsApache Iceberg What is land cover classification? → Overture Maps FoundationVector Overture land use Land use polygons such as residential, agricultural, and protected areas from the Overture Maps base theme. wherobots_open_data.overture_maps_foundation.base_land_use 13 columnsApache Iceberg Land cover vs land use → Overture Maps FoundationVector Overture places Global points of interest with names, categories, and confidence scores. wherobots_open_data.overture_maps_foundation.places_place 16 columnsApache Iceberg What is POI data? → Overture Maps FoundationVector Overture places with drive-time isochrones Overture places with 5, 10, 15, and 20 minute isochrone polygons computed by Wherobots. wherobots_pro_data.overture_maps_foundation.overture_places_with_isochrones 18 columnsApache Iceberg What is POI data? → Overture Maps FoundationVector Overture road network graph Routable road network edge list built by Wherobots from Overture transportation data. wherobots_pro_data.overture_maps_foundation.road_network 8 columnsApache Iceberg Overture Maps FoundationVector Overture transportation connectors Points where transportation segments join, for building routable networks. wherobots_open_data.overture_maps_foundation.transportation_connector 5 columnsApache Iceberg Overture Maps FoundationVector Overture water Oceans, lakes, rivers, and other water features from the Overture Maps base theme. wherobots_open_data.overture_maps_foundation.base_water 13 columnsApache Iceberg US Census BureauTabular ACS 5-year estimates American Community Survey 5-year estimates by geography and variable. wherobots_open_data.us_census.acs_5yr_estimates 7 columnsApache Iceberg US Census BureauTabular ACS 5-year variables Variable definitions for the American Community Survey 5-year estimates. wherobots_open_data.us_census.acs_5yr_variables 4 columnsApache Iceberg US Census BureauVector TIGER block groups US Census block group boundaries from TIGER/Line. wherobots_open_data.us_census.tiger_blockgroup 14 columnsApache Iceberg US Census BureauVector TIGER census tracts US census tract boundaries from TIGER/Line. wherobots_open_data.us_census.tiger_tract 14 columnsApache Iceberg US Census BureauVector TIGER states US state boundaries from TIGER/Line. wherobots_open_data.us_census.tiger_state 16 columnsApache Iceberg US Census BureauVector TIGER ZIP Code Tabulation Areas US ZIP Code Tabulation Area boundaries from TIGER/Line. wherobots_open_data.us_census.tiger_zcta 11 columnsApache Iceberg US weather recordsVector US weather events Weather event records by airport weather station. wherobots_pro_data.weather.weather_events 15 columnsApache Iceberg What is the HRRR model? → US weather recordsVector US wildfires US wildfire records with discovery dates, causes, sizes, and locations. wherobots_pro_data.weather.wild_fires 39 columnsApache Iceberg What is catastrophe modeling? → USGS LandsatRaster Landsat surface temperature Landsat 8 and 9 Collection 2 surface temperature scenes, tiled at 1024 x 1024 pixels for fast spatial filtering. wherobots_pro_data.landsat.landsat_surface_temperature_1024x1024_outdb 11 columnsApache Iceberg What is Landsat? → RasterFlow models 6 Wherobots RasterFlowModel Fields of the World Detect agricultural field boundaries from Sentinel-2 imagery and segment crop fields across counties and regions, then convert predictions to vector geometries. Agricultural field boundary segmentationOutput table What is satellite imagery analysis? → Wherobots RasterFlowModel Tile2Net Identify sidewalks, crosswalks, and pedestrian pathways from high-resolution aerial imagery for urban planning and accessibility analysis. Sidewalk and crosswalk segmentationOutput table What is satellite imagery analysis? → Wherobots RasterFlowModel Meta CHM v1 (canopy height) Predict tree canopy heights from aerial imagery to monitor forest health and vegetation structure and support conservation and urban forestry. Tree canopy height estimationOutput table What is LiDAR data? → Wherobots RasterFlowModel ChesapeakeRSC Identify roads, especially in rural environments, to map road networks and detect changes that keep maps current. Road segmentation, including roads under tree coverOutput table What is satellite imagery analysis? → Wherobots RasterFlowModel SAM3 (text-prompted detection) Detect objects from a text prompt with Meta's Segment Anything Model 3 and return georeferenced geometries, with no separate vectorization step. Object detection from a natural language promptOutput table What is satellite imagery analysis? → Wherobots RasterFlowModel Bring your own model Export a custom PyTorch model to a RasterFlow-compatible format, register it, and run it as an inference task over large mosaics alongside the built-in models. Run a custom PyTorch model at scale Solution notebooks 9 WherobotsNotebook Detecting field boundaries with RasterFlow Detect agricultural field boundaries from satellite imagery with RasterFlow and the Fields of the World model, then vectorize the results for your area of interest. Analyzing Data WherobotsNotebook Detecting roads with RasterFlow Detect roads from aerial imagery with RasterFlow and the ChesapeakeRSC model, then vectorize the results for your area of interest. Analyzing Data WherobotsNotebook Detecting sidewalks with RasterFlow Detect sidewalks from aerial imagery with RasterFlow and the Tile2Net model, then vectorize the results for your area of interest. Analyzing Data WherobotsNotebook Estimating canopy height with RasterFlow Estimate canopy height from aerial imagery with RasterFlow and the Meta and World Resources Institute Canopy Height model (Meta CHM v1). Analyzing Data WherobotsNotebook Part 1: Loading Data Getting started, part 1: hands-on geospatial analysis in Wherobots, combining SQL, Python, and cloud-native data integration. Getting Started WherobotsNotebook Part 2: Reading Spatial Files Getting started, part 2: load raster and vector data in a variety of formats from cloud storage and Wherobots managed storage. Getting Started WherobotsNotebook Part 3: Accelerating Geospatial Datasets Getting started, part 3: manage, cluster, and export large geospatial datasets for high-performance analysis and downstream use. Getting Started WherobotsNotebook Part 4: Spatial Joins Getting started, part 4: combine datasets by their spatial relationships with spatial joins, using Python and the DataFrame API. Getting Started WherobotsNotebook Reading STAC data Load SpatioTemporal Asset Catalog (STAC) collections into WherobotsDB with the STAC reader and API. Reading and Writing Data Demo apps 6 Demo built with AI coding toolsDemo app California grid wildfire exposure Screens every high-voltage transmission span in California for environmental wildfire exposure from fuels, vegetation vigor, canopy, slope, and nearby structures, on a 0 to 9 score. Live demo Demo built with AI coding toolsDemo app Texas drone-delivery nest siting Shortlists candidate drone-delivery nest sites across Texas by weighing the people each site reaches within 10 km against FAA LAANC airspace ceilings and obstacles. Live demo Demo built with AI coding toolsDemo app Colorado property risk explorer Property-and-casualty exposure to five perils across every building and parcel in Colorado, from statewide hexes down to individual buildings. Live demo What is probable maximum loss? → Demo built with AI coding toolsDemo app California signal quality explorer Statewide map of California mobile signal quality that separates capacity-limited areas from coverage gaps, with population and income lenses. Live demo Demo built with AI coding toolsDemo app Pacific Northwest corridor resilience A gorge-fire scenario played out on real Pacific Northwest road and rail geometry, showing which freight corridors degrade and which communities lose every way in. Work in progress Community demoDemo app Australia AI data center siting A national suitability screen for AI data center siting across Australia, with a ranked shortlist of candidate sites and a what-if weighting sandbox. Live demo Nothing matches. Clear the search or filters. The history of HavasuFrom GeoSpark and Apache Sedona to the Havasu catalog Arizona State UniversityGeoSparkResearch by Jia Yu and Mo Sarwat on distributed spatial processing for Apache Spark. Apache Software FoundationApache SedonaGeoSpark becomes Apache Sedona, now a top-level Apache project. 2023Havasu table formatWherobots extends Apache Iceberg with geometry and raster types, spatial statistics, and filter push-down. 2024Iceberg GEOSpatial types become part of the Apache Iceberg spec, with contributors from Wherobots, CARTO, Planet, Apple, Databricks, Snowflake, and others. TodayHavasu knowledge lakeThe name returns as the knowledge lake for the physical world: one catalog for the data, models, jobs, and apps that Wherobots and its customers build. × Havasu Catalog FAQ The Havasu Catalog What is the Havasu Catalog? The Havasu Catalog is an open data catalog of geospatial datasets, RasterFlow models, solution notebooks, and demo apps from Wherobots. Each dataset lists its schema and sample SQL, so a team can query it in Wherobots right away. Learn more about the Havasu Catalog. What is geospatial data? Geospatial data records where things are on Earth. Vector data covers features such as buildings, roads, and boundaries, and raster data covers grids such as satellite and aerial imagery. The Havasu Catalog holds both. Read the introduction to spatial data. Which geospatial data sources does the catalog include? The Havasu Catalog holds 63 entries, including 42 geospatial datasets. Sources include the Overture Maps Foundation, the US Census Bureau, OpenStreetMap, ESA Copernicus Sentinel-2, USDA NAIP aerial imagery, and USGS Landsat. Do I need to download data to use the catalog? No. Every Open Data table in Havasu is queryable in place with spatial SQL in WherobotsDB, so a first analysis starts without a download. Can my own tables sit next to the open datasets? Yes. Your own spatial tables and the open geospatial datasets share one catalog, connected through Unity Catalog, AWS Glue, or any Apache Iceberg catalog. What is Apache Iceberg, and how does Havasu relate to it? Apache Iceberg is an open table format for large analytic tables in cloud object storage. Havasu began in 2023 as the Wherobots spatial table format that extended Iceberg with geometry and raster types, and Iceberg v3 now includes native geometry and geography types. Read about Iceberg geospatial types. How is Havasu related to Apache Sedona? Wherobots was founded by the original creators of Apache Sedona, which began as GeoSpark research at Arizona State University. The Havasu Catalog continues that lineage for data, models, and apps. Read the history of the Havasu Catalog. How do I start using the Havasu Catalog? Start a Wherobots free trial at login.cloud.wherobots.com and query any Open Data table in Havasu. Continued access after the trial requires the Professional tier or above. The solution notebooks in the catalog and the Wherobots developer docs give worked starting points. Datasets in the Havasu Catalog What is Overture Maps? Overture Maps is open map data published by the Overture Maps Foundation, a Linux Foundation project founded by Amazon Web Services, Meta, Microsoft, and TomTom. It covers buildings, places, transportation, addresses, administrative divisions, and base layers such as land and water. The Havasu Catalog lists each Overture theme as its own table, from buildings and places to the road network graph. What is NAIP imagery? NAIP is the National Agriculture Imagery Program, run by the USDA Farm Service Agency. It captures aerial imagery of the continental United States during the agricultural growing season, typically at 60 cm to 1 m resolution with red, green, blue, and near-infrared bands. In the Havasu Catalog, NAIP is a RasterFlow managed dataset that models such as Fields of the World run on. What is Sentinel-2, and what is its resolution? Sentinel-2 is the European Space Agency Copernicus mission for multispectral Earth imagery. It records 13 spectral bands at 10 m, 20 m, and 60 m resolution and revisits each location about every five days. The Havasu Catalog includes Sentinel-2 seasonal mosaics and an index of Level-2A surface reflectance scenes. What is OpenStreetMap? OpenStreetMap is a free, editable map of the world built by volunteer contributors and published under the Open Database License. The Havasu Catalog includes OpenStreetMap nodes, ways, and postal codes as tables. What is a census tract? A census tract is a small statistical subdivision of a US county, defined by the Census Bureau and usually home to 1,200 to 8,000 people. The Havasu Catalog includes TIGER boundaries for states, counties, census tracts, block groups, and ZIP Code Tabulation Areas. What is the American Community Survey? The American Community Survey (ACS) is an ongoing US Census Bureau survey of population, housing, income, and commuting. Its 5-year estimates cover every census tract and block group. The Havasu Catalog includes ACS 5-year estimates with a variables table that explains each column. What is a digital elevation model (DEM)? A digital elevation model is a raster grid in which each cell stores the height of the Earth surface. The Havasu Catalog includes two global DEMs at 30 m resolution: Copernicus DEM GLO-30 and NASA and METI ASTER Global DEM v3. What are Google and Microsoft Open Buildings? Google Open Buildings and Microsoft Global ML Building Footprints are building outlines detected from satellite imagery with machine learning. The Havasu Catalog combines both into one building footprint table. What is Landsat? Landsat is the joint NASA and USGS Earth observation program, which has imaged the planet since 1972. The Havasu Catalog includes Landsat surface temperature, derived from the thermal infrared bands. RasterFlow and models What is RasterFlow? RasterFlow is the Wherobots image preparation and inference engine for large-scale raster processing and geospatial machine learning. It builds mosaics from satellite and aerial imagery, runs computer vision models over them for semantic segmentation, regression, and change detection, and vectorizes the results. RasterFlow is in Public Preview for Professional, Innovation, and Enterprise organizations. Get started with RasterFlow. Which models does RasterFlow include? RasterFlow includes five pre-trained, open-source models: SAM3 for text-prompted object detection, Fields of the World for agricultural field boundaries from Sentinel-2, Tile2Net for sidewalks and crosswalks, Meta CHM v1 for tree canopy height, and ChesapeakeRSC for rural roads. Each model in the Havasu Catalog links to a sample output table. See the RasterFlow models. What is SAM3, and how does RasterFlow use it? SAM3 is Meta’s Segment Anything Model 3, which detects and segments objects from a text prompt such as “roofs”. RasterFlow runs SAM3 over aerial imagery such as 30 cm NAIP and returns georeferenced polygons or bounding boxes with confidence scores, with no separate vectorization step. Read how SAM3 maps building footprints. Can I run my own PyTorch model in RasterFlow? Yes. Export the model with torch.export to a PT2 file, register it, and RasterFlow runs it as an inference task over a mosaic at scale, alongside the built-in models. Follow the bring-your-own-model notebook. What is a PT2 file? A PT2 file is a PyTorch 2 archive created with torch.export. One file holds the exported model, and it can also carry configuration, hyperparameters, and preprocessing transforms. RasterFlow loads PT2 models from Amazon S3 or Hugging Face, and the built-in models are published as PT2 files in the Wherobots Hugging Face collection. Why does RasterFlow use the PT2 model format? A PT2 archive can be exported on a CPU and loaded onto a GPU at runtime. It can be compiled for faster execution on CUDA, AMD, or Intel GPUs, and it stores the model metadata and transforms in a standard place, so one file moves from training to large-scale inference. Can I use my own imagery with RasterFlow? Yes. RasterFlow builds mosaics from your own Cloud Optimized GeoTIFFs through a GDAL Raster Tile Index, including imagery found through a STAC catalog, in addition to the built-in NAIP and Sentinel-2 datasets. Follow the bring-your-own-rasters notebook. What formats does RasterFlow output? RasterFlow writes mosaics and model predictions as Zarr stores and writes vectorized results as GeoParquet, which joins with vector data in WherobotsDB. Wherobots-GL shows mosaics, prediction stores, and vectorized results on one map in Wherobots Cloud or a notebook. How is RasterFlow priced? RasterFlow bills four tasks, mosaicking, inference, building multiscales, and vectorization, in RasterFlow Spatial Units. Mosaicking and inference apply a complexity factor that varies by dataset and by model. See Wherobots pricing. Start in minutes Run your first spatial query. Start a free trial and query every Open Data table in Havasu, with nothing to download. Continued access after the trial is included in the Professional tier and above. Start for free Talk to our team --- ## Discover URL: https://wherobots.com/discover/ Updated: 2026-10-06 Discover Guides: spatial data and physical AI, explained Plain-language guides to the data, formats, and methods behind context engineering for physical world data, from LiDAR and Landsat to change detection, catastrophe modeling and more. Sort By Most Recent Most Recent Oldest Categories View All View All AI Infrastructure World Models Context Engineering Classification Segmentation Change Detection Stochastic Modeling Site Selection Risk Modeling Earth Observation What is? Physical AI Tabular Joins Vector Raster Tutorials Sort By Most Recent Oldest Categories View All AI Infrastructure World Models Context Engineering Classification Segmentation Change Detection Stochastic Modeling Site Selection Risk Modeling Earth Observation What is? Physical AI Tabular Joins Vector Raster Tutorials 18 Mins Read 6 Oct 2026 What is a Context Engine? Why Physical World Data Needs One A context engine is the system that computes, stores, and serves the context AI models and agents receive. How it works, examples, and why physical world data needs one that computes spatial relations. Authors Ben Pruden 18 Mins Read 6 Oct 2026 What is a Context Engine? Why Physical World Data Needs One A context engine is the system that computes, stores, and serves the context AI models and agents receive. How it works, examples, and why physical world data needs one that computes spatial relations. Context Engineering + 5 18 Mins Read 2 Oct 2026 What is Physical AI? Definition, Examples, How It Works Physical AI is artificial intelligence that perceives, reasons about, and acts in the physical world: robots, autonomous vehicles, drones, world models, and Earth-scale models. Earth Observation + 4 17 Mins Read 19 Oct 2026 What is a Geofence? How Geofencing Works, With Examples A geofence is a virtual boundary that triggers an action when a device enters or leaves it. How geofencing works, its uses and limits, and a test on ship data. Joins + 2 21 Mins Read 15 Oct 2026 What is Map Matching? GPS Traces, Methods and Examples Map matching places each GPS record on the road a vehicle drove. How it works, nearest-road snapping vs hidden Markov models, and a test on Ann Arbor drives. AI Infrastructure + 6 18 Mins Read 12 Oct 2026 Geospatial Big Data: Why Analytics Is Hard to Scale Teams struggle to scale geospatial analytics for five reasons: data volume, mixed formats, many coordinate systems, spatial joins and pipeline upkeep. Joins + 3 18 Mins Read 12 Oct 2026 What is an Isochrone? Isochrone Maps and Travel Time An isochrone is the area reachable from a place within a set travel time. How isochrones are computed, isochrone vs radius, and a King County test. Site Selection + 3 17 Mins Read 12 Oct 2026 What is a Geospatial Database? Definition, Examples A geospatial database stores geometry, indexes it by location and runs spatial SQL queries. The definition, examples, and how to choose one by workload. Joins + 3 16 Mins Read 12 Oct 2026 What is a Map Projection? Types, Distortion, Examples A map projection flattens the Earth onto a map and distorts area, shape, distance or direction. Projection types, examples, and how to choose one. Tutorials + 2 1 2 3 … 7 Next » Sign up for our newsletter Be the first to know about releases and industry news. We care about your data; read our privacy policy. SUBSCRIBEΔ --- ## El Niño 2026, atmospheric rivers, and California’s burn scars: one SQL engine, two data models URL: https://wherobots.com/blog/raster-vector-join-high-hazard-basins/ Updated: 2026-10-19 Governor Gavin Newsom proclaimed a state of emergency on 21 September 2026 to prepare California for El Niño 2026. It names recent wildfire areas as particularly susceptible to mud and debris flows. Above Altadena, the Eaton fire left 42 basins that the US Geological Survey (USGS) rates high hazard for debris flows. USGS computes the rating for a 15-minute burst of 40 mm/h of rain (1.57 in/hour), and an atmospheric river can deliver that kind of deluge. The rating covers the basins on the hillside. The homes and roads downslope of the basins fall outside the rating, and the queries here count them. Key takeawaysA raster vector join matches raster pixels to vector geometry by location. It is the case of a spatial join where one side is raster (elevation) and the other is vector (building and road geometry).WherobotsDB runs both joins in SQL. It reads Overture buildings and roads, the ASTER GDEM elevation model, Regrid parcels and the USGS hazard basins in place, as vector and raster, with no data movement.7,713 building footprints sit inside the 42 Eaton high-hazard basins or within 500 m (1,640 ft).696 sit inside a basin, and 16,748 sit within 1 km (0.6 mi).388 km (241 mi) of road and path sit in the 16.8 km² (6.5 sq mi) of ground below the scar’s lowest point. 305 km (190 mi) is drivable and 24 km (15 mi) is motorway.Joined to Regrid parcels, the footprints near the basins sit on 5,934 parcels assessed at $4.8 billion on the 2023 tax roll.A bounding-box filter before the spatial test cut the first building count to 22.8 seconds. Without it, the run was cancelled at 7% after three minutes.The same queries extend to every recent burn scar in California and across the western United States, where USGS publishes debris-flow hazard assessments after major fires. WherobotsDB does the counting in SQL, reading every dataset in place. A join to the USGS basins returns 7,713 mapped building footprints inside the high-hazard basins or within 500 m (1,640 ft) of them. A raster vector join over elevation returns 388 km (241 mi) of mapped road and path. Start with elevation, buildings and roads in the catalog All four datasets sit in wherobots_open_data: the ASTER GDEM 30 m (98 ft) elevation model, Overture’s buildings and roads, and Regrid’s parcel sample. The companion notebook fetches the CAL FIRE perimeter and USGS basins. It also registers every shared view, so each query below runs as written, with no setup of its own. Each elevation row stores a footprint polygon, so WherobotsDB selects rows by location before it reads any pixel. Ten rasters cover the Eaton area. Filter on the bounding box before the spatial test Overture features carry a bbox struct beside the geometry. With a range filter on it before ST_Intersects, the first building count finished in 22.8 seconds. Without it, the run was cancelled at 7% after three minutes. The range check on four numbers is cheap, so the costly geometry test runs only on the rows that pass. Show the code -- scar holds the Eaton perimeter; the notebook fetches it from CAL FIRE and registers it as a view WITH aoi AS ( SELECT ST_Transform( ST_Buffer(ST_Transform(g, 'EPSG:4326', 'EPSG:32611'), 3000), 'EPSG:32611', 'EPSG:4326') AS g FROM scar ), bld AS ( SELECT t.id, t.geometry AS geom FROM wherobots_open_data.overture_maps_foundation.buildings_building t WHERE t.bbox.xmin BETWEEN -118.20 AND -117.97 -- range scan first AND t.bbox.ymin BETWEEN 34.13 AND 34.27 ) SELECT count(*) FROM bld b JOIN aoi ON ST_Intersects(b.geom, aoi.g); 118,746 footprints pass the bounding box, 83,930 fall within 3 km (1.9 mi) of the perimeter, and 10,652 sit inside the scar. Each of two questions below gets its own raster vector join. For buildings the answer is one elevation per footprint, so the first join reads the raster under every footprint. For roads, however, the answer is a length. So the second join turns the raster into a zone polygon first, then clips each road segment against it. Buildings read the elevation under each footprint a b c elevation + building footprints RS_ZonalStats building elevation a 222 m b 285 m c 201 m one value per building, kept if below 230 m Roads turn the elevation into a zone, then clip each road 1 2 elevation below 230 m zone + roads 1 RS_MapAlgebra marks the cells below the line 2 RS_Polygonize turns them into polygons, ST_Union_Aggr merges them into one zone, and ST_Intersection measures the part of each road inside it The two joins used below, drawn on a toy elevation grid with a 230 m (755 ft) line. Buildings: read the elevation under each footprint Which building footprints sit below the burn scar’s lowest point? 15,233 of the 83,930 footprints sit below that point, 223 m (732 ft). RS_ZonalStats runs the raster vector join per building, so every footprint gets one elevation value of its own. That value becomes one more column beside the building’s other attributes. Show the code -- scar, dem and inaoi (the 83,930 footprints within 3 km) are views from the notebook's setup cell WITH scar_floor AS ( SELECT min(RS_ZonalStats(d.rast, s.g, 1, 'min', true)) AS m FROM dem d, scar s ), be AS ( -- pool pixels across every raster a footprint touches: total value over pixel count SELECT i.id, sum(RS_ZonalStats(d.rast, i.geom, 1, 'sum', true)) / NULLIF(sum(RS_ZonalStats(d.rast, i.geom, 1, 'count', true)), 0) AS elev FROM inaoi i JOIN dem d ON RS_Intersects(d.rast, i.geom) GROUP BY i.id ) SELECT count(*) AS below_scar_floor FROM be, scar_floor WHERE be.elev < scar_floor.m; Footprints that straddle two rasters have their pixels pooled before averaging, since the rasters meet under them. 380 of the 384 stay on the same side of the line. A 30 m (98 ft) pixel is wider than many houses, but every footprint still got an elevation value from the query. 2026-09-24T20:53:29.930329 image/svg+xml Matplotlib v3.11.2, https://matplotlib.org/ 500 750 1,000 1,250 1,500 1,750 2,000 2,250 feet 200 300 400 500 600 700 mean elevation under the footprint (m) 0 2,000 4,000 6,000 8,000 10,000 buildings per 20 m (66 ft) band scar’s lowest point, 223 m (732 ft) 15,233 below it 146 more sit above 700 m (2,297 ft), up to 1,809 m (5,935 ft), off the chart Mean elevation under each of the 83,930 footprints within 3 km (1.9 mi) of the perimeter, in 20 m (66 ft) bands. Blue marks the buildings below the scar’s lowest point. Roads: a raster vector join through a low-ground zone Why do roads need a different join than buildings? Roads need a different join because length, not a single point, decides the answer. A building gets one average elevation, and that single value places it above or below the line. A 1 km (0.6 mi) road dips below the line for a short stretch and stays above it for the rest. An average across the whole road would place it on one side, and the low stretch would go uncounted. The query takes three steps instead. RS_MapAlgebra marks every elevation pixel below 223 m (732 ft). RS_Polygonize turns the marked pixels into polygons, and ST_Union_Aggr merges them into one shape of low ground. ST_Intersection then cuts each road at the polygon’s edge, and the query adds up the length inside it. WherobotsDB builds the polygon once and tests every road against that same shape. Show the code -- aoi, dem and roads are views from the notebook's setup cell WITH masked AS ( SELECT RS_MapAlgebra(rast, 'D', 'out[0] = rast[0] < 223 ? 1 : 0;') AS m FROM dem ), polys AS ( SELECT t.p.geom AS g FROM masked LATERAL VIEW explode(RS_Polygonize(m, 1)) t AS p WHERE t.p.value = 1.0 ), low AS ( SELECT ST_Intersection(u.g, a.g) AS g FROM (SELECT ST_Union_Aggr(ST_MakeValid(g)) AS g FROM polys) u, aoi a ) SELECT r.class, sum(ST_Length(ST_Transform(ST_Intersection(r.geom, low.g), 'EPSG:4326', 'EPSG:32611'))) / 1000 AS km FROM roads r JOIN low ON ST_Intersects(r.geom, low.g) GROUP BY r.class ORDER BY km DESC; 2026-09-24T20:53:30.030379 image/svg+xml Matplotlib v3.11.2, https://matplotlib.org/ 0 20 40 60 80 100 120 140 160 kilometres inside the low zone Residential Service Footway Motorway Primary Tertiary Secondary Other 121.0 km (75.2 mi) 97.6 km (60.6 mi) 60.2 km (37.4 mi) 24.0 km (14.9 mi) 22.1 km (13.7 mi) 20.1 km (12.5 mi) 19.8 km (12.3 mi) 23.0 km (14.3 mi) Kilometres of Overture road and path inside the 16.8 km² (6.5 sq mi) of ground below the scar’s lowest point, within 3 km (1.9 mi) of the perimeter. The low ground covers 16.8 km² (6.5 sq mi) and holds 388 km (241 mi) of road and path within 3 km (1.9 mi) of the scar. Of that, 305 km (190 mi) is drivable and 24 km (15 mi) is motorway. Lengths follow each mapped segment, so both carriageways of every divided road are counted in full. Joining to what USGS already modelled An elevation line is only a screen. USGS publishes the basins as a live feature service, so they join in as one more vector layer. Each building counts once per distance, however many basins it touches. Show the code -- high holds the 42 dissolved high-hazard basins; the notebook fetches them from USGS WITH z AS ( SELECT g AS inside, ST_Transform(ST_Buffer(ST_Transform(g, 'EPSG:4326', 'EPSG:32611'), 500), 'EPSG:32611', 'EPSG:4326') AS b500, ST_Transform(ST_Buffer(ST_Transform(g, 'EPSG:4326', 'EPSG:32611'), 1000), 'EPSG:32611', 'EPSG:4326') AS b1k FROM high ) SELECT sum(CASE WHEN ST_Intersects(b.geom, z.inside) THEN 1 ELSE 0 END) AS inside, sum(CASE WHEN ST_Intersects(b.geom, z.b500) THEN 1 ELSE 0 END) AS inside_or_500m, sum(CASE WHEN ST_Intersects(b.geom, z.b1k) THEN 1 ELSE 0 END) AS inside_or_1km FROM bld b, z WHERE ST_Intersects(b.geom, z.b1k); 2026-09-24T20:53:30.095776 image/svg+xml Matplotlib v3.11.2, https://matplotlib.org/ 0 2,500 5,000 7,500 10,000 12,500 15,000 17,500 20,000 Overture building footprints Inside a high-hazard basin Inside or within 500 m (1,640 ft) Inside or within 1 km (0.6 mi) 696 7,713 16,748 Overture building footprints inside, or within 500 m (1,640 ft) and 1 km (0.6 mi) of, the 42 Eaton basins that USGS rates high combined hazard. 696 footprints sit inside a high-hazard basin, 7,713 inside or within 500 m (1,640 ft), and 16,748 within 1 km (0.6 mi). The map below plots the 7,713 on Sentinel-2 imagery from 5 August 2026. They form a solid band along the scar’s lower edge, where the basins drain onto the valley floor. Nineteen months on, the scar is still bare. The 7,713 footprints (cyan) inside or within 500 m (1,640 ft) of the 42 high-hazard basins (red), on Sentinel-2 imagery from 5 August 2026. Joining parcels to put a value on the screen Building counts measure how many structures sit in each screen, not what they are worth. Regrid’s parcel sample in wherobots_open_data.partner_samples adds use codes, acreage and assessed values, and a join to the exposed footprints carries those onto both screens. The join runs in two steps so nothing is counted twice: first the distinct parcel and footprint pairs, keyed on Regrid’s stable ll_uuid, then one row per parcel for its use code, acreage and assessed value. A footprint that crosses a parcel line counts once in the total and once in each use it touches, so the rows sum slightly above the total. Show the code -- exposed holds the footprints from either screen; parcels is Regrid's sample with the same bbox filter as bld WITH pairs AS ( SELECT DISTINCT p.ll_uuid, p.usedesc, e.id AS bid FROM parcels p JOIN exposed e ON ST_Intersects(p.geometry, e.geom) ), parcel AS ( -- one row per parcel, so acres and value are counted once SELECT ll_uuid, first(usedesc) AS usedesc, first(ll_gisacre) AS acres, first(parval) AS parval FROM parcels WHERE ll_uuid IN (SELECT ll_uuid FROM pairs) GROUP BY ll_uuid ), by_use AS ( SELECT usedesc, count(*) AS parcels, round(sum(acres)) AS acres, round(sum(parval) / 1e6, 1) AS assessed_musd FROM parcel GROUP BY usedesc ), bld_use AS (SELECT usedesc, count(distinct bid) AS buildings FROM pairs GROUP BY usedesc) SELECT u.usedesc, u.parcels, b.buildings, u.acres, u.assessed_musd FROM by_use u JOIN bld_use b USING (usedesc) ORDER BY u.parcels DESC; Inside or within 500 m (1,640 ft) of a high-hazard basin: 5,934 parcels, 7,709 footprints Use Parcels Buildings Acres Assessed value Residential single 5,686 7,157 2,910 $4.69 B Residential two units 72 186 34 $51 M Government parcel 67 175 944 $4 M Residential three units 29 86 14 $24 M Utility pumping plants 15 33 25 $0.1 M Apartments, five or more 14 82 10 $13 M Miscellaneous 10 48 3,383 $0 Motion picture, radio, TV 8 52 868 $12 M Below the scar’s lowest point, 223 m (732 ft): 10,513 parcels, 15,227 footprints Use Parcels Buildings Acres Assessed value Residential single 9,032 12,791 3,013 $8.49 B Residential two units 373 988 77 $210 M Apartments, five or more 172 498 72 $499 M Commercial stores 129 187 50 $222 M Commercial office buildings 105 184 62 $511 M Residential three units 86 233 17 $56 M Light manufacturing 84 123 27 $119 M Residential four units 81 210 18 $66 M The 7,713 footprints inside or within 500 m (1,640 ft) of a high-hazard basin sit on 5,934 parcels with a combined assessed value of $4.8 billion. Single-family homes account for $4.7 billion of it. The downhill screen is larger: the 15,233 footprints below the scar’s lowest point sit on 10,513 parcels assessed at $11.1 billion, and here the mix changes. Single-family homes are $8.5 billion of that total, and the remaining $2.6 billion is the commercial and apartment stock along the valley floor, led by $511 million in office buildings, $499 million in apartments and $222 million in stores. The two screens overlap, so the totals do not add. Every value comes from the assessor’s 2023 tax roll, so it describes the neighbourhood before the fire and before any rebuilding. Proposition 13 holds California assessed values well below market value, so these totals are a floor. RS_Value reads the elevation under a point, so a cross-section is a line of generated points. Show the code -- a point every 0.00025 degrees, about 28 m, along 118.125° W, and the elevation under each WITH pts AS ( SELECT i, ST_SetSRID(ST_Point(-118.125, 34.265 - i * 0.00025), 4326) AS pt FROM (SELECT explode(sequence(0, 460)) AS i) ) SELECT p.i, ST_Y(p.pt) AS lat, RS_Value(d.rast, p.pt, 1) AS elev FROM pts p JOIN wherobots_open_data.aster_gdem.v3_30m d ON ST_Intersects(d.footprint, p.pt) ORDER BY p.i; 2026-09-24T20:53:30.305805 image/svg+xml Matplotlib v3.11.2, https://matplotlib.org/ 0 1 2 3 4 5 6 7 miles 0 1,000 2,000 3,000 4,000 5,000 feet 0 2 4 6 8 10 12 distance south along 118.125° W (km) 0 200 400 600 800 1000 1200 1400 1600 elevation (m) burn scar high-hazard basins 1,112 buildings within 60 m (197 ft) of the line north south Terrain sampled every 28 m (92 ft) along 118.125° W, from the ridge north of the scar to the valley floor. Red bands mark the burn scar and the basins USGS rates high; cyan ticks mark buildings within 60 m (197 ft) of the line. The line climbs to 1,577 m (5,174 ft) on the ridge. Then it crosses 2.4 km (1.5 mi) of high-hazard basin and 4.5 km (2.8 mi) of scar, down to 248 m (814 ft). 1,112 footprints lie within 60 m (197 ft) of it. The first of those buildings already sit inside the lower end of the high-hazard stretch. Scope and limits of the exposure screen These counts are an exposure screen. Neither they nor the USGS assessment predict where a debris flow travels or what it buries. USGS notes that most come within two years of a fire. So this winter falls near the end of that window, while the burned slopes are still recovering. Three limits carry over. The elevation model is a surface model, so rooftops and treetops count as ground. Proximity is straight-line distance rather than flow path. Finally, the perimeter is simplified to 47 vertices, which changes its area by 0.4%. Flow routing would turn distance bands into runout paths. However, WherobotsDB has no built-in flow-direction function, so that takes a custom function over the rasters. It is the natural next step. From one burn scar to the western United States This screen covers one burn scar: the Eaton fire above Altadena. The same queries extend to every recent burn scar in California, and across the western United States, where USGS publishes debris-flow hazard assessments after major fires. Overture buildings and roads and the ASTER elevation model in wherobots_open_data already cover that whole region. Each new fire adds a perimeter and a set of basins to the same joins, once the study-area bounding box and UTM zone are updated to match. Governor Newsom declared the emergency ahead of El Niño rain this winter. The open question for every recently burned community is how many homes and roads sit below a high-hazard basin when that rain arrives. One engine processed buildings, roads, elevation, and USGS hazard polygons, as vector and raster, with every file left where it sits. An AI agent grounded only in text, documents, databases, and the internet holds none of those layers, so it cannot say what sits below a basin. WherobotsDB supplies that physical-world context by joining them in place. Imagery: Copernicus Sentinel data 2026. Elevation: ASTER GDEM is a product of METI and NASA. Buildings and roads: Overture Maps Foundation. Parcels: Regrid parcel sample. Fire perimeter: CAL FIRE FRAP, CC BY. Hazard basins: USGS Landslide Hazards Program, public domain. Get Started with Wherobots Try Now Frequently Asked Questions What is a raster vector join? A raster vector join is a spatial join where one dataset is raster and the other is vector. Here the raster is the ASTER GDEM elevation model and the vectors are Overture building footprints and road segments. RS_ZonalStats reads one elevation value under each footprint, and RS_MapAlgebra with RS_Polygonize turns low-elevation pixels into a polygon that roads clip against. What is a spatial join? A spatial join matches records from two datasets by their location instead of a shared key column. It answers questions like which buildings fall inside a hazard basin, or which roads cross a zone of low ground. A raster vector join is the case where one side is raster. How many buildings sit below the Eaton burn scar's high-hazard basins? About 7,700 building footprints sit inside the 42 high-hazard basins or within 500 m (1,640 ft) of them. About 700 sit inside a basin, and about 16,700 sit within 1 km (0.6 mi). Why filter on a bounding box before a raster vector join? A bounding-box range check tests four numbers per row and is cheap, so the costly geometry test runs only on rows that pass. With the filter, the first building count finished in 22.8 seconds. Without it, the run was cancelled at 7% after three minutes. Does this screen predict where a debris flow will go? No. It is an exposure screen. Neither it nor the USGS assessment predicts where a debris flow travels or what it buries.Flow routing would turn straight-line distance bands into runout paths, which takes a custom function over the rasters. --- ## Orchestrating Wherobots Jobs from AWS Step Functions: A Reference Architecture URL: https://wherobots.com/blog/orchestrate-jobs-from-aws-step-functions-a-reference-architecture/ Updated: 2026-10-19 When the execution engine is loosely coupled with orchestration, the pipeline is blind while waiting for one fact: did the job finish, fail, or die? This was the case with jobs running inside Wherobots Cloud and the AWS pipeline launching it… That was not cool with me, so we designed a reference implementation using AWS Step Functions, their callback pattern, and the Wherobots Python SDK. Key takeawaysThe pipeline submits a Wherobots job through the wherobots-python-sdk, pauses for the callback, and resumes the moment the job reports its result. No polling loop on the happy path.The single-use task token is the security capability. A request without a live token does nothing, which makes a public API Gateway endpoint acceptable for a reference implementation.Two failure modes, two mechanisms. A try/except block posts the full traceback for soft failures; a 60-second heartbeat plus a fallback poller catch a hard death like a driver OOM or cluster kill.Live verification: a forced RuntimeError surfaces the exact line that raised it within seconds. A simulated OOM (os._exit(137), no callback) reaches a confirmed FAILED verdict in 4 minutes and 46 seconds.Four design decisions transfer to production directly: deterministic job names, a reusable two-field poller, failure evidence over failure flags, and symmetric teardown.The demo job counts Overture Maps buildings within one kilometer of downtown Seattle (geodesic buffer, EPSG:4326) and returns 1,084. The reference implementation is intentionally small and the accompanying (vibe coded) interactive app is designed to walk you through the implementation for learning purposes. There are four Lambda functions, two state machines, one API Gateway endpoint, and a simple Wherobots job script. Every AWS resource is created by plain CLI calls you can read, and a guided app drives the whole lifecycle: upload, deploy, run, teardown. The demo job counts Overture Maps buildings within one kilometer of downtown Seattle (geodesic buffer, EPSG:4326) and returns 1,084. What the Reference Architecture Does The pipeline submits a Wherobots job to our distributed engine through the wherobots-python-sdk, pauses for the callback, and resumes the moment the job reports its own result. The submit handler Lambda calls WherobotsJob(...).submit() with the task token passed as plain job arguments. The state machine then waits. There is no polling loop on this happy path. When the job finishes, the state machine wakes within seconds and the next state receives the job’s output as its input. Authentication stays minimal on both sides. The Lambdas hold one Wherobots API key. The SDK uploads the job script to managed storage over short-lived STS credentials, so no long-lived AWS keys appear anywhere. Wherobots runs the job on a managed Apache Sedona runtime, built by the original creators of Apache Sedona and 100% code compatible across all spatial functions. How the Callback Pattern Works Step Functions supports a task type that pauses until something calls SendTaskSuccess or SendTaskFailure with a one-time task token. The catch: the job runs in Wherobots’ AWS account and cannot sign calls to your Step Functions API. The reference bridges that gap with a relay. The job POSTs plain JSON over HTTPS to an API Gateway endpoint, and a small Lambda behind it relays the payload into the Step Functions API. The single-use task token is the security capability. A request without a live token can do nothing, which is what makes a public endpoint acceptable for a reference implementation. Production hardening adds an API key or IAM auth at the gateway. The reference uses API Gateway instead of a Lambda Function URL as blocking anonymous Function URL invocation by service control policy is a general best practice, and API Gateway is the sanctioned front door. Failure Mode Drives the Design In a decoupled orchestration and compute engine system, one major question to consider is “What happens when the job fails?”. How the job fails drives the resolution and code path, one layer cannot cover all cases. Soft failures report themselves The Wherobots job logic is wrapped in a typical try/except loop so the Python-level failures, from bad SQL to bad data, are caught and posted as a failure callback carrying the full traceback. The execution fails and within seconds the traceback appears in the AWS console with the trace. In live verification, a forced RuntimeError is surfaced in the execution history with the exact line that raised it. A Heartbeat catches the hard death A driver OOM or a cluster kill ends the Python process mid-instruction. No except or finally runs and no callback is ever sent. There are no silver bullets to report a death like this, which is why the job also runs a daemon thread that posts a heartbeat every 60 seconds. The task sets HeartbeatSeconds: 240; the window counts from task entry, and the job’s first heartbeat cannot arrive until the runtime finishes provisioning, so the window sits above typical provisioning time. On a rare slower cold start the timeout routes to the fallback poller, which finds the run healthy and still delivers COMPLETED. When the process dies, heartbeats stop with it, and the timeout fires within four minutes initiating the failure tracing process. The fallback poller finds the truth The heartbeat timeout routes to a recovery path. A FindRun Lambda recovers the run ID from the deterministic job name using WherobotsJob.list_runs, then a reusable poller state machine checks the run every 30 seconds until Wherobots returns a terminal status. The poller takes {run_id, poll_seconds} as input and carries no reference to the pipeline that submitted the job, so any other pipeline can reuse it as-is. In live verification, the simulated OOM (os._exit(137), no callback, no goodbye) reached a confirmed FAILED verdict in 4 minutes and 46 seconds, end to end: the heartbeat window plus one poll cycle (adjust HeartbeatSeconds and the polling interval to your desired detection latency). The Guided Dashboard The repository ships a local app to walk you through the architecture. Five stages build on each other in order: PREFLIGHT: reads a masked .env UPLOAD: pushes the job script to Wherobots storage BUILD streams every AWS CLI call as it creates the infrastructure RUN: kicks off the step function chain TEARDOWN: removes resources created in step 3 The test-mode dropdown makes the failure contract demonstrable through the live execution graph: How to Run It Minimal setup required to play with the dashboard and implementation. Currently the repo is private, but if you wan to run it contact us and we can give you access. We expect this to be live as an open repo very soon in Wherobots Labs. git clone https://github.com/wherobots/labs-reference-implementations.git cd labs-reference-implementations/aws-step-functions-python-sdk python3 -m venv .venv && source .venv/bin/activate pip install -r requirements.txt cp .env.example .env # set WHEROBOTS_API_KEY; blank AWS keys use your default chain python3 dashboard/server.py Open the dashboard, click through the five stages, and run the three test modes. The demo costs a few cents of Lambda and Step Functions time plus one tiny Wherobots runtime per run. Don’t forget to run (and confirm) the Teardown cell, it removes every AWS resource the build created, (each resource carries ManagedBy and TeardownBy tags for auditing) . Design Decisions Worth Stealing Four steps in this reference transfer to production systems directly. Deterministic job names. The execution input carries the job name, so the fallback path can recover the run ID after the callback path dies. Recovery depends on nothing the failed job was supposed to send. A reusable poller. Polling logic lives in its own state machine with a two-field input contract. The callback version of the pipeline demoted it to a fallback without changing a line of it. Failure evidence over failure flags. The soft-failure callback carries the traceback, and the fallback poller reports the run’s terminal status from the Wherobots API. Whoever reads the failed execution reads the cause. Symmetric teardown. Every create call in the deploy script has a delete call in the teardown script, and both are readable CLI commands. Reference infrastructure that cannot be removed cleanly teaches the wrong habit. Where It Fits This reference covers job runs: script-shaped and batch-shaped work submitted to Wherobots compute. Interactive SQL over the Spatial SQL API and Airflow-based orchestration with the Wherobots provider are separate surfaces with their own patterns. If your pipelines live in Step Functions today and your spatial workloads need managed jobs at scale, this architecture is the shortest path between them. Get Started with Wherobots Try Now Frequently Asked Questions How does the AWS Step Functions callback pattern work with a Wherobots job? Step Functions uses a task type that pauses until something calls SendTaskSuccess or SendTaskFailure with a one-time task token. The Wherobots job runs in Wherobots’ AWS account and has no way to sign calls to your Step Functions API.So it POSTs plain JSON over HTTPS to an API Gateway endpoint, and a small Lambda behind the gateway relays the payload into the Step Functions API. The state machine waits with no polling loop on the happy path. How does the reference architecture detect a failed Wherobots job? The design covers two failure modes with two mechanisms. A try/except block around the job logic catches Python-level failures, from bad SQL to bad data, and posts them as a failure callback carrying the full traceback.For a hard death like a driver OOM or cluster kill, where no callback is ever sent, the job runs a daemon thread that posts a heartbeat every 60 seconds. When the process dies, heartbeats stop, and the task timeout fires within four minutes. Why is a public API Gateway endpoint safe in this architecture? The single-use task token is the security capability. A request without a live token does nothing, which makes a public API Gateway endpoint acceptable for a reference implementation.Production hardening adds an API key or IAM auth at the gateway. The reference uses API Gateway rather than a Lambda Function URL because blocking anonymous Function URL invocation by service control policy is a general best practice. When should you use this Step Functions reference architecture? Use it when your pipelines live in AWS Step Functions and your spatial workloads need managed jobs at scale. The reference covers job runs, meaning script-shaped and batch-shaped work submitted to Wherobots compute.Interactive SQL over the Spatial SQL API and Airflow-based orchestration with the Wherobots provider are separate surfaces with their own patterns. The demo builds four Lambda functions, two state machines, one API Gateway endpoint, and one Wherobots job script, all created by plain AWS CLI calls. --- ## Measuring the Strait of Hormuz shutdown with Sentinel-2, WherobotsDB and Overture Maps URL: https://wherobots.com/blog/hormuz-vessel-detection/ Updated: 2026-10-19 Iran closed the Strait of Hormuz to commercial shipping on 28 February 2026. To measure what stopped moving, WherobotsDB read 719 Sentinel-2 scenes, 151 GB in total, straight from the public archive and fetched only about 1.5 GB covering three areas of interest. A near-infrared threshold found the hulls with no trained model, and a join against Overture Maps land polygons removed rocks and coastline. Traffic through the surveyed corridor fell 95% while loading and anchorage traffic held at 2025 levels, and the whole analysis cost about $63. Key takeawaysIran closed the Strait of Hormuz to commercial shipping on 28 February 2026. Vessel counts from Sentinel-2 imagery show traffic through the surveyed corridor fell 95%.Loading and anchorage traffic held at 2025 levels: the Fujairah anchorage rose 10% and the Kharg Island export terminal rose 35%.WherobotsDB read 719 Sentinel-2 scenes, 151 GB in total, straight from the public archive. It fetched only about 1.5 GB covering three areas of interest.A near-infrared threshold found the hulls with no trained model. A join against Overture Maps land polygons removed rocks and coastline.Ship traffic is normally tracked through AIS, the transponder every large vessel carries. In this crisis those transponders are being switched off or falsified, so the count uses optical imagery.The whole analysis cost about $63. Pointing the same job at another chokepoint takes two edited arguments.The 95% decline describes the surveyed corridor, which is 25 km wide within a strait roughly 40 km across. Sentinel-2 imagery is free and covers the planet every five days. Pointing the same job at another chokepoint takes two edited arguments. What the satellites saw We counted vessel hulls in Sentinel-2 imagery over three areas from January 2025 to August 2026 using a pixel-based reflectance method, while accounting for the sun’s angle over time: area 2025 2026 change Hormuz transit corridor 10.3 vessels 0.5 −95% Fujairah anchorage, outside the strait 63.5 70.0 +10% Kharg Island export terminal, inside the Gulf 7.3 9.9 +35% Those figures are per satellite pass, averaged over the passes clear enough to cover the whole area. We used imagery because the usual source cannot be trusted here. Ship traffic is normally tracked through AIS, which is the transponder every large vessel carries. In this crisis those transponders are being switched off or falsified. Near Fujairah and Khor Fakkan, roughly 470 vessels broadcast garbled or impossible positions inside a single 24-hour window. Windward counted 146 of 167 vessels in the strait area running dark on 5 May, and IMF PortWatch warns that its own numbers understate traffic. The optical imagery provides a signal (the hull) that is always on. Vessel detections per satellite pass across the three areas, January 2025 to August 2026. The corridor line falls to near zero after the closure while the anchorage and the loading terminal return to 2025 levels. How to count ships from space Water absorbs almost all near-infrared light, so in Sentinel-2’s B08 band the sea is nearly black. Painted steel reflects it strongly. Over the Fujairah anchorage on August 7th, 2026 the water sat at 0.09 reflectance and the brightest pixel in the area read 0.87, so a vessel stands out by a wide margin. This means you don’t need a machine-learning model to identify a ship. Wherobots queries the Sentinel-2 files directly in the public archive. The raster data source opens each scene in place and fetches only the necessary pixels. The code below is an excerpt from the job script but the whole pipeline is available as a runnable notebook that opens in Wherobots Cloud, with every constant in one cell so you can point it at your own area of interest. Show the code AOI = ("POLYGON((56.42 25.10, 56.62 25.10, 56.62 25.30, " "56.42 25.30, 56.42 25.10))") AOI_SQL = f"ST_SetSRID(ST_GeomFromWKT('{AOI}'), 4326)" (sedona.read.format("raster") .option("tileWidth", "512").option("tileHeight", "512") .option("autoRescale", "true") # off by default: without it you get raw DN .load(paths) .createOrReplaceTempView("tiles")) # Background statistics on water only. The median centre ignores a bright # minority of pixels. Pooling the per-tile standard deviations by their median # discards a tile spoiled by cloud or land, but bright pixels inside a tile # still inflate that tile's spread, so a crowded anchorage lifts the cutoff # somewhat. That bias is conservative and falls on both years alike. r = sedona.sql(f""" WITH s AS ( SELECT zs.median AS med, zs.stddev AS sd FROM (SELECT RS_ZonalStatsAll(rast, {WATER_G}) AS zs FROM tiles) WHERE zs.count > 0 ) SELECT percentile_approx(med, 0.5) AS med, percentile_approx(sd, 0.5) AS sd FROM s """).collect()[0] threshold = r["med"] + max(SIGMA_K * r["sd"], 0.03) 2026-08-07 cov=100.0% cloud= 2.67% med=0.0915 sd=0.0097 thr=0.1687 \ brightpx= 5636 vessels= 84 >=200m= 39 RS_ZonalStatsAll reports statistics for the pixels inside a shape. Using the median prevents a small number of bright pixels from raising the threshold; an average would be pulled upward by every ship in the frame. Adding a multiple of the spread gives a cutoff for that scene. The spread is pooled the same way, by taking the median of each tile’s standard deviation, which discards a tile spoiled by clouds. It is only a partial defense: ships inside a tile raise that tile’s spread, and with it the cutoff, so the count runs slightly conservative in a crowded anchorage. The sea is brighter in July than in January, so the cutoff has to move with it, which we account for in the analysis. A short Python function applies that cutoff, and RS_Polygonize traces the outline of every bright patch. Show the code @sedona_vectorized_udf(return_type=RasterType()) def threshold_udf(rast: SedonaRaster) -> SedonaRaster: a = rast.as_numpy_masked()[0] out = np.zeros(a.shape, dtype=np.float64) with np.errstate(invalid="ignore"): out[np.isfinite(a) & (a >= threshold)] = 1.0 return rast.with_bands(out[np.newaxis]) # with_bands() needs real pixels; the reader returns out-db references. (sedona.sql("SELECT RS_AsInDB(rast) AS rast FROM tiles") .withColumn("mask", threshold_udf("rast")) .createOrReplaceTempView("masked")) # RS_Polygonize returns every connected region in ONE array, so running it on a # whole scene OOMs an executor -- per tile it is cheap and parallel. sedona.sql(f""" SELECT t.p.geom AS g FROM masked LATERAL VIEW explode(RS_Polygonize(mask, 1)) t AS p WHERE t.p.value = 1.0 AND ST_Area(t.p.geom) BETWEEN 2000 AND 200000 """).createOrReplaceTempView("raw_blobs") # A vessel lying on a tile seam is polygonized twice, once either side of the # cut. Union everything, then split it back apart: the halves become one # polygon, while vessels that never touched stay separate. The area floor above # runs before this merge, which has a cost the last section spells out. sedona.sql(""" WITH dissolved AS ( SELECT explode(ST_Dump(ST_Union_Aggr(ST_MakeValid(g)))) AS g FROM raw_blobs ), sized AS ( SELECT g, ST_Area(g) AS area_m2, 2 * ST_MinimumBoundingRadius(g).radius AS length_m, ST_MinimumWidth(g) AS width_m FROM dissolved WHERE ST_Area(g) BETWEEN 2000 AND 200000 ) SELECT g AS geometry, area_m2, length_m, width_m FROM sized WHERE width_m >= 20 AND length_m / width_m BETWEEN 2 AND 15 """).createOrReplaceTempView("candidates") Sentinel-2 true color over the Fujairah anchorage on August 7th, 2026. A detected 280 m hull covers about 12,600 m², which is roughly two football pitches and matches the deck of a Suezmax tanker. Ruling out rocks, land and glint Rocky islets also reflect near-infrared light. The Quoin Islands sit directly in the shipping lane, and in an early run three of our first four detections turned out to be those rocks. Wherobots holds imagery and map data in one engine, so checking detections against an independent source takes one query. Overture Maps publishes global land polygons. They already sit in the Wherobots open data catalog, and one join drops any detection that touches land. Show the code sedona.sql(f""" SELECT ST_Buffer(ST_Transform(geometry, 'EPSG:4326', 'EPSG:{epsg}'), 60) AS g FROM wherobots_open_data.overture_maps_foundation.base_land WHERE ST_Intersects(geometry, {AOI_SQL}) """).createOrReplaceTempView("land") detections = sedona.sql(""" SELECT d.geometry, d.area_m2, d.length_m FROM candidates d LEFT ANTI JOIN land l ON ST_Intersects(d.geometry, l.g) """) Two further checks run alongside it. Sun glint can brighten patches of open water, so we keep only detections shaped like ships, which filters out glint using the near-infrared band alone. A hull is typically four to eight times longer than it is wide and a glint patch is round, so the filter accepts anything between 2:1 and 15:1 and at least 20 m across. Those bounds are deliberately loose, wide enough that an unusual hull still passes while a round blob cannot. And a satellite pass sometimes covers only part of an area, so any date where less than 95% of the area was photographed is dropped. Counting a partly covered area would look like a decline in traffic that never happened. In practice nothing landed in between: every date behind the figures came in at 100% coverage, and the rest were dropped outright. A study fusing Sentinel-1 radar with AIS measured a 97% decline across the two weeks either side of the closure. We measured 95% from optical imagery over a longer window, with no AIS involved. Oversized shapes and the size bound About one detection in forty measures longer than 400 m, a length no ship afloat reaches. The longest spans 1,310 m. These shapes cluster by date: at Fujairah, 15 of the 21 fall on a single date, and in the corridor, 13 of 24 fall on two, which fits cloud or sun glint on those passes. At Kharg, a shape about 1,120 m long recurs at the same spot on five dates, which points to a fixed terminal structure missing from the land polygons. An upper bound alongside the existing area floor removes all of them: WHERE length_m BETWEEN 50 AND 400 The correction tightens the result. The corridor returned nine detections on 18 March 2026, one of the two clustered dates, and five of those exceed 400 m. Four hulls survive the bound, so the corridor reads emptier after the closure. Every vessel we found The job writes its detections as GeoParquet and then as PMTiles, a single file a browser can read directly from cloud storage without a tile server. Each month becomes its own layer, so a before-and-after comparison means publishing the two months that matter. Show the code from wherobots import vtiles feats = sedona.sql(""" SELECT geometry, aoi, obs_date, length_m, area_m2, date_format(to_date(obs_date), 'yyyy-MM') AS layer FROM det """) vtiles.generate_pmtiles(feats, f"{base}/hormuz_monthly.pmtiles") The three maps below show one area each, with the 2025 month in blue and the 2026 month in red. Each caption gives the month’s total and a per-pass rate, which divides that total by the number of usable passes. The corridor. May 2025 in blue against May 2026 in red. 46 detections across four clear passes in 2025, then two across one pass: about 11 vessels a pass, down to two. Open fullscreen. The anchorage outside. April 2025 in blue against April 2026 in red. 200 detections over three passes, then 122 over two, which is roughly 67 a pass and then 61. April appears here because no May 2026 pass covered the anchorage. Open fullscreen. The loading terminal inside the Gulf, May 2025 in blue against May 2026 in red. Loading held: 22 detections over two passes in 2025 and 29 over three in 2026, or 11 a pass then about 10. Open fullscreen. All three areas at once, with every month switched on: 3,117 detections in 20 layers, one per month from January 2025 to August 2026. Kharg sits to the north-west, the strait and Fujairah to the south-east. Step through the months in the sidebar to see the corridor empty while the anchorage and the terminal keep their traffic. Open fullscreen. Compute cost and data read 719 Sentinel-2 scenes cross these three areas over 20 months, which is 151 GB of imagery. The analysis read about 1.5 GB of that, because RS_Clip fetches only the parts of each file that overlap the three areas. The scenes stay in the public archive throughout. The 20-month run took 26.8 minutes on a MEDIUM runtime, roughly 25 Spatial Units at $1.50 each in us-west-2, or about $37. Widening the same job to the whole Gulf of Oman and lower Persian Gulf, 368,875 km² at full coverage, added $23 and seven minutes of wall clock. Calibration and tiling took it to about $63. Wherobots Cloud reports the exact figure for every run in Workload History. The coordinates and date range are parameters, so pointing the job at another chokepoint is an edit to two arguments. The notebook has them in its configuration cell, alongside the size and shape limits. Sentinel-2 passes overhead every five days, and a scheduled run keeps the count current independent of AIS broadcasts. The surveyed corridor is 25 km wide within a strait roughly 40 km across, so the 95% decline describes that corridor. Whether some vessels shifted to routes outside it cannot be settled from these three areas. A second limit sits in the detector. The 2,000 m² area floor runs before the seam merge, so a small hull lying on a tile boundary can split into two pieces that each fall under the floor and go uncounted. A hull touches a seam on roughly 2% of passes, the loss bites only near the size floor, and it applies to every date equally, so the year on year comparisons survive it. The downloadable notebook applies the area floor after the merge instead. Get Started with Wherobots Try Now Frequently Asked Questions How much did ship traffic through the Strait of Hormuz fall? Vessel detections in the surveyed Hormuz transit corridor fell from 10.3 per satellite pass in 2025 to 0.5 in 2026, a 95% decline. Over the same period the Fujairah anchorage rose 10% and the Kharg Island export terminal rose 35%. The figures are averaged over the passes clear enough to cover the whole area. How do you detect ships in Sentinel-2 imagery without a trained model? Water absorbs almost all near-infrared light, so in Sentinel-2’s B08 band the sea is nearly black, while painted steel reflects it strongly. A cutoff for each scene, set from RS_ZonalStatsAll statistics, separates the bright pixels, and RS_Polygonize traces the outline of every bright patch.Over the Fujairah anchorage on August 7th, 2026, the water sat at 0.09 reflectance and the brightest pixel read 0.87. How were rocks, land and sun glint ruled out? A join against Overture Maps land polygons drops any detection that touches land, which removed rocks such as the Quoin Islands. A shape filter keeps detections between 2:1 and 15:1 in length to width and at least 20 m across, which removes round glint patches.Dates where less than 95% of an area was photographed are dropped. An upper bound removes shapes longer than 400 m, a length no ship afloat reaches. Why use satellite imagery instead of AIS? AIS is the transponder every large vessel carries, and in this crisis those transponders are being switched off or falsified. Near Fujairah and Khor Fakkan, roughly 470 vessels broadcast garbled or impossible positions inside a single 24-hour window. The hull in optical imagery is a signal that is always on. What did the analysis cost? The 20-month run took 26.8 minutes on a MEDIUM runtime, roughly 25 Spatial Units at $1.50 each in us-west-2, or about $37. Widening the job to the whole Gulf of Oman and lower Persian Gulf added $23 and seven minutes of wall clock. Calibration and tiling took the total to about $63. --- ## RasterFlow is now available in Public Preview URL: https://wherobots.com/blog/rasterflow-public-preview-planetary-scale-earth-intelligence/ Updated: 2026-10-19 RasterFlow makes planetary-scale earth intelligence workflows easy and costs predictable. We are excited to announce that RasterFlow is now in Public Preview, opening up the power of planetary scale Earth Intelligence to all Wherobots Professional Edition customers! Key takeawaysRasterFlow is now in Public Preview, opening up the power of planetary-scale Earth observation to all Wherobots customers, available today to Wherobots Cloud Professional Edition users.Predictable, pre-execution pricing. Pricing is based on data volume processed: Area in km² × Pixels per km² × Bands × Time periods × task-specific rate.So you can accurately estimate the cost of any task before execution and extrapolate from smaller test runs to planetary scale.An alternative to Google Earth Engine. Unlike Earth Engine’s EECU-hour billing that reveals cost only after a job finishes, RasterFlow lets you calculate costs up front and keeps results in your own storage.A 150,000 km² Sentinel-2 mosaic with all 12 bands costs about $50 in Earth Engine vs. $13.50 for RasterFlow.Proven at planetary scale with built-in models. RasterFlow ships with Meta’s SAM3, Taylor Geospatial’s Fields of the World, and Meta’s CHM v1.RasterFlow powers wildfire containment predictions for the USDA Forest Service and field-boundary work for Miraterra Soil. It also powers the 8.2 billion global field boundaries Taylor Geospatial produced for Fields of the World. RasterFlow let’s you solve complex monitoring challenges with vision-language models or tailored models for specific use cases, without needing to manage complex raster preparation and inference infrastructure. Teams are already running RasterFlow at planetary scale: The USDA Forest Service uses RasterFlow to deliver wildfire containment predictions to its Wildfire Risk Management Division at an operational cadence. Miraterra uses RasterFlow to predict agricultural field boundaries across the U.S. Midwest and Canada’s Prairie Provinces, then joins detailed microbial samples and geospatial embeddings to those boundaries. Taylor Geospatial worked with Wherobots to produce 8.2 billion global field boundaries for the Fields of the World program. Join our Public Preview virtual event, Pixels to Predictions: Planetary-Scale Earth Observation with RasterFlow, for a live walkthrough of built-in models, predictable pricing, and real customer pipelines. Register Here → Join Public Preview Event: Pixels to Predictions with RasterFlow. Register HERE RasterFlow is a serverless image preparation and computer vision engine that makes it easy to extract insights from large scale raster datasets. It builds mosaics from multiple raster data sources, runs inference with computer vision models, and vectorizes the results, through a high-level API that simplifies the complexity of raster pipelines and distributed computing. You pay RasterFlow usage using a predictable, low cost pricing model that scales with your area of interest. With RasterFlow’s built-in models, users can instantly launch tasks for common Earth Intelligence use cases. For instance, RasterFlow includes Meta’s SAM3 model for text-prompted object detection, Taylor Geospatial’s Fields of the World model for agricultural field boundaries, Meta’s CHM v1 for estimating tree canopy height. You can also bring your own, and we are expanding the set of open models we offer out-of-the box (let us know which open models you want offered and we can add them). Market leading pricing that you can predict RasterFlow’s predictable pricing allows you to estimate the cost of your tasks before they run. The price for each task is based on the data volume processed, so you can accurately estimate the cost of any task before execution. And pricing scales linearly with the size of your area of interest, so you can extrapolate the costs from smaller test runs to planetary scale. Data volume = Area in km² × Pixels per km² × Bands × Time periods The four inputs are: Area: Size of your AOI in km² Pixels per km²: Determined by input resolution; finer imagery means more pixels Bands: For example, 4 for RGB + NIR Time periods: For example, 3 annual observations Let’s walk through a concrete example. If you wanted to find every solar panel array across a 500 km² county, you could use the built-in SAM3 model and a simple text prompt (“solar panel”) to generate detections. Here’s the code to launch this task across your area of interest using RasterFlow’s built-in support for 30cm imagery from USDA’s National Agriculture Imagery Program (NAIP): Pythonfrom rasterflow_remote import RasterflowClient from rasterflow_remote.data_models import GeometryModelRecipes rf = RasterflowClient() detections = rf.predict_mosaic_geometries_recipe( aoi="s3://your-bucket/county.parquet", start=datetime(2022, 1, 1), end=datetime(2023, 1, 1), model_recipe=GeometryModelRecipes.SAM3_TEXT_GEOMETRY, text_prompt="solar panel", confidence_threshold=0.5, ) print(detections.uri) # GeoParquet containing detected solar-panel polygons To calculate the price for this task, we first determine the number of input pixel values based on the size of the AOI (500 km²), the resolution of the dataset (30cm NAIP), the number of bands (4), and the number of time periods (1). Price = Data volume × Task-specific rate Then, for mosaic generation and inferencing tasks, we apply a “complexity factor” to account for differences in task processing. For instance, building a mosaic from NAIP imagery is simpler than creating a cloud-free composite from Sentinel-2 imagery, so we apply a 0.1× multiplier. Similarly, different models have different complexity factors, so we apply the relevant inference complexity factor (in this case, 1.0× for SAM3). Finally, each RasterFlow task has a specific price that may vary by compute region. Combining these factors, we arrive at our total costs for these tasks: TaskComplexity factorRasterFlow Spatial Units (SU)Price per SUCostMosaic generation (NAIP)0.1×2.22$0.75$1.67Inference (SAM3)1.0×22.22$1.50$33.33Total$35.00 For more details on RasterFlow pricing, see our pricing page and documentation. To see some example solar panel detections for Marion County, Oregon, here is an interactive visualization: Check out our viewer to explore these results further. Or, for more details about our Text to Detections support with SAM3, see this blog post: Detecting Objects From Text Prompts with RasterFlow and SAM3. Your mosaics, predictions, and vectors in your storage Wherobots storage integrations connect RasterFlow directly to your own S3 buckets. Tasks can read your areas of interest and proprietary imagery from your buckets, then write mosaics, predictions, and vectorized results back to them. Wherobots securely manages the required roles and credentials, so you can focus on your workflows instead of wrangling permissions. Pythonfrom rasterflow_remote import RasterflowClient, DatasetEnum client = RasterflowClient() result = client.build_mosaics( datasets=[DatasetEnum.S2_MED_HARVEST], aoi="s3://my-company-data/aois/project.parquet", # one or multiple geometries start=datetime(2024, 1, 1), end=datetime(2025, 1, 1), bucket="s3://my-company-data/rasterflow/results", ) print(result.first_row_mosaic) "s3://my-company-data/rasterflow/results/mosaics//mosaic_index.parquet" Outputs remain in open, interoperable formats: Zarr for mosaics and predictions, GeoParquet for vectorized results, and Iceberg tables through managed catalogs. Your data and results remain in the storage your applications already use, without a separate migration or export workflow. Built-in visualization to inspect your Earth observation insights Visual inspection is essential for validating inference results at scale, but large raster outputs are difficult to explore in their raw form. Wherobots lets users instantly layer mosaics, model predictions, and vectorized results on an interactive map, making it easy to assess quality, tune thresholds, and spot misaligned or spurious detections. Every completed RasterFlow task includes a one-click link to view its results in the Workload History. RasterFlow also includes tasks that optimize existing Zarr stores for interactive viewing by adding image pyramids, downsampled overviews, and histogram statistics. The built-in map client then streams coarse tiles when zoomed out and full-resolution pixels when zoomed in, delivering responsive exploration at any scale. For example, see this interactive visualization of model outputs from SAM3: How RasterFlow compares to Google Earth Engine Google Earth Engine provides a deep planetary imagery catalog and a strong environment for exploratory analysis. But for planetary scale workflows, Google Earth Engine has some significant limitations: Limited cost predictability. Earth Engine bills in EECU-hours, so you only learn the total cost after the job finishes. With RasterFlow, you can calculate the cost of your tasks before you run them, eliminating uncertainty and potential billing surprises. Build your own inference pipelines. Building a planetary scale earth observation pipelines with computer vision models requires integration with Vertex AI and custom pipeline development. Workflows that integrate with imagery data sources, patch tiles, handle seams, and maintains georeferences are costly to develop and maintain. RasterFlow packages mosaicking, inference, and vectorization as built-in tasks with a simple API. Results are siloed in Earth Engine. Analysis results are stored in Earth Engine, which is separate from Google Cloud Platform or Google Cloud Storage. Using them elsewhere requires queuing export jobs, so a team building on AWS pays both export and egress costs. Mosaicking cost. Because of these export costs, mosaicking costs on Earth Engine can be significantly higher for developers in AWS. For instance, generating and exporting a Sentinel-2 mosaic with all 12 bands for 150,000 km² costs about $50 in Earth Engine vs. $13.50 for RasterFlow. Customer impact at planetary scale Fields of the World: a global field-boundary layer Fields of the World is a Taylor Geospatial effort to produce globally consistent agricultural field-boundary data for land-use monitoring, food-system analysis, and model development. Taylor Geospatial partnered with Wherobots to run their PRUE model on RasterFlow for the 2024 to 2025 global release. Read about the Fields Of The World (FTW) Project. We achieved this with three tasks that you can run today: Building mosaics to create the seasonal Sentinel-2 composites Model inference to run the PRUE model globally Vectorization to convert the per-pixel predictions into field boundaries in GeoParquet. StageArtifactSizeFeature COGs90,918 objects153 TBFeature Zarr mosaic363,999 objects, 7,499,140 logical chunks150 TBPrediction Zarr mosaic84,877 objects, 8,982,630 logical chunks45 TBVector output, GeoParquet1,000 objects, 8,217,195,679 rows675 GB In total, we generated 348.7 TB across 540,794 objects, to produce 8.2 billion field boundaries. The full pipeline write-up is in Fields of the World: a GeoAI pipeline on RasterFlow. Daily wildfire containment mapping with the USDA Forest Service FireCon model predictions for the best fire control points, generated across the western United States by RasterFlow. The USDA Forest Service FireCon model produces containment-suitability maps for active wildfires across the Western United States. Because fuel, terrain, weather, and fire conditions change continuously, yesterday’s map may not reflect the conditions crews face today. Previously, the cost and complexity of running the full pipeline limited how frequently the team could update these maps. RasterFlow changes that by ingesting potential control location data, terrain characteristics, weather forecasts, and daily soil moisture readings, normalizing the data and running the full inference pipeline end-to-end in a matter of hours rather than a full day. That dramatic reduction in both runtime and cost means the team can afford to run the pipeline multiple times per day, giving frontline response teams a current view of the fire landscape. The results are also delivered as multi-resolution raster layers, so they render smoothly whether crews are looking at a broad regional view or zooming in on a specific fire line. In practice, this translates directly into better-informed containment and resource decisions on the ground, especially during fast-changing fire conditions where yesterday’s map simply isn’t good enough. Get started today RasterFlow is available now to Wherobots Cloud Professional Edition users: Sign in to Wherobots Cloud. Build a mosaic or run a built-in model by starting with one of these notebooks: Detect objects with SAM3. Build a cloud-free Sentinel-2 mosaic. Find agricultural field boundaries. Estimate canopy height with Meta CHM v1. Register for the Public Preview webinar. See a live walkthrough of Rasterflow. Save Your Spot Frequently Asked Questions What is RasterFlow used for? RasterFlow lets you solve complex monitoring challenges with vision-language models or tailored models for specific use cases, without needing to manage complex inference infrastructure. It’s used for planetary-scale Earth observation workflows including: Wildfire containment mapping: The USDA Forest Service uses RasterFlow to deliver wildfire containment predictions to its Wildfire Risk Management Division at an operational cadence. Agricultural field boundary detection: Miraterra Soil uses RasterFlow to predict agricultural field boundaries across Minnesota and Nebraska, then joins detailed microbial samples and geospatial embeddings to those boundaries. Taylor Geospatial worked with Wherobots to produce 8.2 billion global field boundaries for the Fields of the World program. Text-prompted object detection: With RasterFlow’s built-in SAM3 model, you can find features like solar panel arrays across a county using a simple text prompt. Canopy height estimation: Meta’s CHM v1 model is built in for tree canopy height across large areas. How do I estimate the cost of a RasterFlow task before running it? RasterFlow’s pricing lets you estimate the cost of any task before execution because it’s based on the data volume processed. Calculate data volume as: Area in km² × Pixels per km² × Bands × Time periods, then multiply by the task-specific rate.Because pricing scales linearly with the size of your area of interest, you can extrapolate costs from smaller test runs to planetary scale. Every RasterFlow execution also appears in Workload History, including the Raster Units consumed and the resulting charge, so you can reconcile your estimate against actual usage after it completes. How does RasterFlow compare to Google Earth Engine? Google Earth Engine provides a deep planetary imagery catalog and a strong environment for exploratory analysis, but has significant limitations for planetary-scale workflows: Cost predictability: Earth Engine bills in EECU-hours, so you only learn the total cost after the job finishes. With RasterFlow, you can calculate the cost of your tasks before you run them. Pipeline complexity: Building a planetary-scale Earth observation pipeline with computer vision models on Earth Engine requires integration with Vertex AI and custom pipeline development. RasterFlow packages mosaicking, inference, and vectorization as built-in tasks with a simple API. Siloed results: Analysis results are stored in Earth Engine, separate from Google Cloud Platform or Google Cloud Storage. Using them elsewhere requires queuing export jobs, so a team building on AWS pays both export and egress costs. Mosaicking cost: Generating and exporting a Sentinel-2 mosaic with all 12 bands for 150,000 km² costs about $50 in Earth Engine vs. $13.50 for RasterFlow. Which built-in models does RasterFlow include? RasterFlow includes Meta’s SAM3 model for text-prompted object detection, Taylor Geospatial’s Fields of the World model for agricultural field boundaries, and Meta’s CHM v1 for estimating tree canopy height. With these built-in models, users can instantly launch tasks for common Earth observation use cases. Where are my mosaics, predictions, and vectors stored? Wherobots storage integrations connect RasterFlow directly to your own S3 buckets. Tasks can read your areas of interest and proprietary imagery from your buckets, then write mosaics, predictions, and vectorized results back to them.Wherobots securely manages the required roles and credentials, so you can focus on your workflows instead of wrangling permissions. Outputs remain in open, interoperable formats: Zarr for mosaics and predictions, GeoParquet for vectorized results, and Iceberg tables through managed catalogs. --- ## How to score every building in a state for catastrophe risk: an exploration project URL: https://wherobots.com/blog/how-to-score-every-building-in-a-state-for-catastrophe-risk/ Updated: 2026-10-19 Part 1 of a series: What’s possible? I didn’t start this project to build a real risk model, not one that can be used by an insurer tomorrow. But it is a workflow that an insurer can put into practice to create their own risk scores with Wherobots and their own expertise. The idea was simple: what can be done in a day with Wherobots MCP for Claude and the VSCode plugin? It turns out quite a lot, and the barrier to entry is a Claude (or other coding agent) Account and VS Code running on a laptop with access to a Wherobots pro tier connected. Key takeawaysThe whole build took a day on a laptop with Claude and VS Code. The barrier to entry is a Claude account, VS Code, and a Wherobots Professional tier account.This post is part 1 of a series on what one person can build in a day on this stack. Drone delivery and telecom examples come next.The project builds a scoring workflow an insurer would put into practice, not a calibrated risk model. An insurer runs it to create their own risk scores with Wherobots and their own expertise.The five scores screen where to look. They do not determine insurability.The layers already exist: wildfire rasters, hail radar, flood layers, parcels, and road networks. Getting them into one scored, queryable form is the hard part.WherobotsDB combines them in one query. It runs spatial SQL over raster and vector, pushes spatial predicates down at read, and builds PMTiles it ships to the browser.The Colorado build is a template for any state or portfolio. Swap the boundary for your state and the peril rasters for the ones on your portfolio. Total costs across tokens and data processing was about $300. This example looks at the Insurance industry and scoring risk on a property and building level. I’ll be following up with additional examples on Drone Delivery hub / nest site selection as well as communication services network connectivity in the coming weeks. Lets start with the concept. Build a Risk Explorer Data Pipeline with AWS & Wherobots Start Now What does an insurer need to understand when evaluating the risk of a location? Insurance works on a basic idea: what is the risk at a given location, and how should it be priced? For a property and casualty carrier that question repeats across every building and property asset in its portfolio. The data to answer it, in many cases, already exists spread across wildfire rasters, hail radar, flood layers, parcels, and road networks. Getting it into one scored, queryable, mappable form, updated on a recurring schedule is usually the hard part, because handling these data types is unsupported and often impossible in other compute environments. This post walks that process end to end: every Overture building in Colorado, 2,771,126 of them, joined against the Parcels they sit upon from Regrid, and scored across five perils, from a statewide view down to a single rooftop. The data processing engine used is WherobotsDB on Wherobots Cloud in AWS. Our team at Wherobots maintains Apache Sedona, and WherobotsDB is 100% code compatible the OSS, but fully managed with more spatial functions and capabilities, grater performance, and enterprise support options. Three capabilities carry this data pipeline: spatial SQL over raster and vector datasets combined, a spatial operation that prunes on reads time, and PMTiles that WherobotsDB can deliver to enable a snappy browser experience on MapLibre. The finished map is live on the Wherobots Website here. You can play with it inline below: The Colorado catastrophe-risk explorer, built with WherobotsDB, Claude Opus 5 & VSCode via agentic app development. The data fed into the application layer Seven sources feed the app and the data pipeline: LayerSourceBuilding footprintsOverture MapsWildfire hazardUSFS Wildfire Risk to Communities (30 m raster)HailNOAA radar, 403M observations since 2016FloodFEMA National Flood Hazard LayerTornado / windFEMA National Risk Index (tract)Parcels, land useRegridFire-station accessOverture places (road-network distance computed in the pipeline) Two structural decisions: A count is a floor. No measurement means no record, so a building with no hail observation is not a building at zero hail risk. Every count reads as “at least“. The ranking: by building count, not by dollars. Assessor value coverage runs near 63% and is county dependent. El Paso, the largest county at 290,630 buildings, with $0 reported by the county. A dollar ranking would identify who reports property values, not where actual risk value is identified. A P&C insurer would have a clear understanding of building / parcel / asset value, so this diverts from what would be the likely standard they would want. These values could easily be added to this data pipeline, however. The data pipeline: a medallion architecture for catastrophe risk scoring The pipeline is a medallion architecture, and every layer is an Iceberg catalog table you can query on its own. Bronze, raw as it lands, one table per source: TableWhat lands in itoverture_buildingsOverture footprints (2.77M)noaa_hailNOAA radar hail, 403M observations since 2016usfs_wildfireUSFS Wildfire Risk to Communities, 30 m raster (COG)fema_nfhlFEMA National Flood Hazard Layer (flood zones)fema_nriFEMA National Risk Index, tract (tornado, wind)regrid_parcelsRegrid parcels: reported parcel value, land useoverture_placesOverture fire-station locations Silver, conformed: clipped to the Colorado boundary, coordinate systems reconciled, geometries validated: buildings, hail_grid, flood_zones, parcels, fire_stations, nri_tracts. Gold, scored and tile-ready: building_perils (five peril scores per building), hex_rollup (H3 exposure and composite), parcels_scored. Update frequency. Hail accumulation and Regrid parcels refresh monthly, so a monthly run keeps the map current. USFS wildfire and the FEMA National Risk Index refresh annually. The pipeline is defined with the Wherobots Python SDK and scheduled with Apache Airflow, one run per medallion stage. Reading and clipping at scale with spatial predicate pushdown The buildings layer is continental but the analysis is for Colorado. A spatial predicate filter pushdown on the read keeps makes it easy and cheap to run that state only: -- Silver: every Colorado building footprint, clipped with a pushed-down spatial predicate CREATE TABLE org_catalog.co_pc_risk_silver.buildings AS SELECT b.id, b.geometry FROM wherobots_open_data.overture_maps_foundation.buildings_building b JOIN org_catalog.co_pc_risk_bronze.co_boundary aoi ON ST_Intersects(b.geometry, aoi.geometry); WherobotsDB pushes ST_Intersects down to the GeoParquet files, reads each file’s bounding-box metadata, and skips the files that fall outside Colorado. Because WherobotsDB can easily index a dataset by proximity using say a Hilbert Curve index, this makes this type of operation even easier. Fusing raster and vector in one query This is a core WherobotsDB capability that this and many other use cases leverage. Wildfire hazard is a 30 m raster. Hail is millions of radar points. Flood is polygons. Buildings are polygons. One set-based query samples and joins all of them, per building: -- Gold: score each building against the wildfire raster and the hazard vectors. WITH wf AS ( SELECT b.id, MAX(RS_ZonalStats(w.rast, b.geometry, 'max')) AS wildfire_score FROM org_catalog.co_pc_risk_silver.buildings b JOIN org_catalog.co_pc_risk_silver.wildfire w ON RS_Intersects(w.rast, b.geometry) GROUP BY b.id ), hail AS ( SELECT b.id, COUNT(*) AS hail_events, MAX(h.size_in) AS max_hail_in FROM org_catalog.co_pc_risk_silver.buildings b LEFT JOIN org_catalog.co_pc_risk_silver.hail_obs h ON ST_Intersects(b.geometry, h.geometry) GROUP BY b.id ), flood AS ( SELECT b.id, ANY_VALUE(f.zone) AS flood_zone FROM org_catalog.co_pc_risk_silver.buildings b LEFT JOIN org_catalog.co_pc_risk_silver.flood_zones f ON ST_Intersects(b.geometry, f.geometry) GROUP BY b.id ) SELECT b.id, b.geometry, wf.wildfire_score, hail.hail_events, hail.max_hail_in, flood.flood_zone FROM org_catalog.co_pc_risk_silver.buildings b LEFT JOIN wf ON b.id = wf.id LEFT JOIN hail ON b.id = hail.id LEFT JOIN flood ON b.id = flood.id; RS_ZonalStats reads the raster values under each footprint and returns key statistics. Each peril is computed in its own CTE so the joins stay one-to-many and the counts are exact. WherobotsDB executes RS_Intersects and ST_Intersects as spatial range joins, so the raster-to-building and point-to-building matches avoid a cross product. The run scores the full state in just a few minutes on one WherobotsDB medium runtime. Five catastrophe risk scores per building The fused query gives each building a raw hazard value per peril. Scoring turns those into five small integers on one row, so a building is one comparable object across every hazard. Each peril is scored on its own scale and the five sum to a 0-to-7 composite: PerilRangeWhat sets the top scoreWildfire0-2USFS hazard sampled under the footprint, banded high / moderate / lowHail0-2Largest radar-detected hail size over the building: 2 at 2 inches or greaterFlood0-1Inside a FEMA Special Flood Hazard AreaWind / tornado0-1FEMA National Risk Index rating for the tractAccess0-1Greater than five road miles of the nearest fire station The perils are scored individually. A single blended number would reads like a hazard map while hail dominates the sum, because hail is Colorado’s most costly regular peril. Keeping five columns lets the map user and the copilot switch to one peril at a time and understand them specifically. The assignment is set-based, one CASE per peril over the fused hazard values: -- Gold: turn raw hazard values into five 0-based peril scores per building SELECT id, geometry, -- wildfire: USFS hazard under the footprint, banded 0 / 1 / 2 CASE WHEN wildfire_hazard >= hi_break THEN 2 WHEN wildfire_hazard >= lo_break THEN 1 ELSE 0 END AS wf_score, -- hail: largest radar-detected hail size over the building, in inches CASE WHEN max_hail_in >= 2.0 THEN 2 WHEN max_hail_in >= 1.0 THEN 1 ELSE 0 END AS hail_score, -- flood: inside a FEMA Special Flood Hazard Area CASE WHEN in_sfha THEN 1 ELSE 0 END AS flood_score, -- wind / tornado: FEMA National Risk Index rating for the tract CASE WHEN nri_wind_elevated THEN 1 ELSE 0 END AS wind_score, -- access: beyond five road miles (8047 m) of the nearest fire station CASE WHEN road_m IS NULL OR road_m > 8047 THEN 1 ELSE 0 END AS access_score, -- composite: the five summed, domain 0-7 ( CASE WHEN wildfire_hazard >= hi_break THEN 2 WHEN wildfire_hazard >= lo_break THEN 1 ELSE 0 END + CASE WHEN max_hail_in >= 2.0 THEN 2 WHEN max_hail_in >= 1.0 THEN 1 ELSE 0 END + CASE WHEN in_sfha THEN 1 ELSE 0 END + CASE WHEN nri_wind_elevated THEN 1 ELSE 0 END + CASE WHEN road_m IS NULL OR road_m > 8047 THEN 1 ELSE 0 END ) AS composite FROM org_catalog.co_pc_risk_gold.building_hazards; Two of these bands are exposed in a way worth highlighting. Wildfire and hail are measured under each footprint; wind and flood are inherited. wf_score reads the USFS raster at the building, and hail_score reads the radar accumulation over it. wind_score comes from a FEMA National Risk Index rating at census-tract resolution, and flood_score from a FEMA zone polygon. A tract or a zone is far coarser than a rooftop, so those two scores are derived from an area where the detections exist, and that coarser grain is labeled in the schema, not intended to represent as a per-structure reading. On access, a NULL distance means furthest, not missing. The access score flags every building beyond five road miles of a fire station. The nearest-station search runs to a 25 km radius; a building with no station inside that radius has a NULL distance and is the most remote in the state, so the rule scores NULL as 1. Writing road_m > 8047 alone drops exactly the worst-access cohort. That is why the score, not the raw distance, drives the map. Run over all 2.77M buildings, the top wildfire band holds 307,679 buildings and the 2 in-and-up hail band holds 790,889. Both counts are floors: a building with no observation for a peril scores 0 for it, and reads as at least that exposed. The accumulation view The per-building table has fine grained details. A reinsurer often is concerned with concentration risk, and it’s easier to visualize when aggregated, so its helpful to roll the same scores up to an H3 grid: -- Gold: roll per-building scores up to H3 for the accumulation view SELECT ST_H3CellIDs(geometry, 7, false)[1] AS h3, COUNT(*) AS buildings, SUM(wildfire_score) AS wildfire_exposure, AVG(composite) AS mean_composite FROM org_catalog.co_pc_risk_gold.building_perils GROUP BY ST_H3CellIDs(geometry, 7, false)[1]; The same gold tables drive both the statewide hex view and the street-level building view. Nothing recomputes between zoom levels. From a gold table to a map anyone can interact iwth WherobotsDB builds the PMTiles as vector tiles and ships them to object storage, so a hand-written MapLibre GL JS page reads them by their S3 URL. No separate tiling tool, no tile server, no build step in the app. # WherobotsDB builds and ships the PMTiles for the web app from wherobots import WherobotsJob WherobotsJob(script="s3://.../export_pmtiles.py", name="co-risk-export", runtime="small").submit() The build-to-browser toolchain The whole build was authored and shipped with one repeatable stack: Build and version: Claude Code (Opus 5) inside VS Code, with the pipeline and the app committed to GitHub. Compute and data: WherobotsDB on Wherobots Cloud runs the medallion pipeline; the Wherobots Python SDK defines each job and it is scheduled with Apache Airflow. Tiles and hosting: WherobotsDB builds the PMTiles and ships them to Amazon S3; Vercel serves the static MapLibre GL JS page from its CDN. Ask the map: the app includes a Claude copilot. Ask where is the worst wildfire exposure in El Paso County, and Claude switches the peril, recolors the map, and moves to show you the answer. It runs as a Vercel serverless function that calls the Anthropic API, with the analysis rules in its system prompt and the key held server-side. What these catastrophe risk scores are, and what they are not The five scores screen where to look. They are not a calibrated loss model, and nothing here is a determination of insurability. The bands, the floors, and the inherited-grain labels live in the pipeline and again in the copilot’s system prompt, so the map view and the copilot’s answers stay inside the same limits. What the map surfaces Hail is Colorado’s dominant peril, ahead of wildfire. In the top wildfire tier alone, 307,679 buildings screen as elevated: a starting list for where to focus. The access-to-services peril, powered by road-network distance to the nearest fire station, marks the insurability boundary, the cohort beyond a fire department’s reach. A P&C analyst can review all of it by toggling the map. How to port this catastrophe risk scoring pipeline to any state or portfolio The Colorado build is a template. Swap the boundary for your state or the whole country, swap the peril rasters and point clouds for the ones on your portfolio, and the pipeline holds: push the spatial predicate on the read, fuse raster and vector in one query, roll up to H3, let WherobotsDB build and ship the tiles down to the property parcel and building layer. That is the point of an Context Engine for Physical World Data: the physical-world data, prepared and scored at the scale a portfolio spans, in a form an analyst and an agent can both query. Start on Wherobots Cloud, connect to the Wherobots Claude MCP, or open the Colorado risk explorer to see what I built, or check out the docs at docs.wherobots.com. Get Started with Wherobots Access Now Frequently Asked Questions What is catastrophe risk scoring at building level? Building-level catastrophe risk scoring assigns each building in a portfolio a small integer score for each peril, plus a composite sum. The perils here are wildfire, hail, flood, wind or tornado, and access to a fire station. In this build, every building in Colorado, 2,771,126 of them, is scored across five perils, from a statewide view down to a single rooftop. How do you use Wherobots for catastrophe risk scoring? Three WherobotsDB capabilities carry this build. First, spatial SQL over raster and vector in one query. Second, spatial predicate pushdown at read time, so the scan touches a fraction of the planetary layer.Third, WherobotsDB builds PMTiles and ships them to the browser without a tile server. The pipeline is defined with the Wherobots Python SDK and scheduled with Apache Airflow, one run per medallion stage. Its Bronze, Silver, and Gold Iceberg catalog tables are queryable on their own. Is this a calibrated cat risk model, like the ones from Verisk or Moody's? No. The five scores screen where to look. They are not a calibrated loss model, and nothing here is a determination of insurability.The workflow is one an insurer runs to create their own risk scores with Wherobots and their own expertise. What data sources feed a catastrophe risk scoring pipeline? Seven layers feed the pipeline. Overture Maps building footprints, USFS Wildfire Risk to Communities (30 m raster), and NOAA radar hail (403M observations since 2016). FEMA National Flood Hazard Layer, and FEMA National Risk Index at tract level for tornado and wind.Regrid parcels supply value and land use. Overture places supply fire station locations, and the pipeline computes road-network distance to them. --- ## Learning Wherobots by Building a National AI Data Center Suitability Report URL: https://wherobots.com/blog/ai-data-center-site-suitability-wherobots/ Updated: 2026-10-19 This guest post is from a Wherobots user George Chandeep Corea, which covers an exploration of how he used Wherobots MCP with his preferred AI coding tools to build the interactive AI data center site suitability analysis tool below. The following quote is from his own biography. Key takeawaysWherobots computed a national suitability model over 15.91 million authoritative geometries from 16 national and state portals. The result is a zero-dependency interactive document that opens in any browser with no compute environment behind it.Cloud-native GeoParquet inside Wherobots Havasu (Spatially Aware Apache Iceberg) tables compressed the storage footprint from ~2.9 GB raw equivalent to ~430.7 MB, an 85.2% reduction.At national scale, the spatial SQL join executes in 2.4 s. Hilbert space-filling curve partitioning cuts the national scan across 15.91M geometries from 18.4 s to 3.2 s.The cold end-to-end batch ETL takes 200.6 s. The client-side What-If recalculation in the browser takes under 1 ms.Total cloud batch compute spend across dozens of iterative development, benchmark, and QA runs was ~$36 AUD (US$24.13), roughly $1.03 per run across ~35 automated batch runs.The model covers 17 candidate industrial sites across all 8 Australian states and territories, scored on the formula Suitability = 0.40·S_power + 0.25·S_sensitive + 0.20·S_water + 0.15·S_size. Learning by Doing Below is a working national suitability report for AI data centers. Move the weight sliders and the ranking reorders. Toggle the tailings-dam scenario and the buildable area changes. Everything in it was computed on Wherobots over 15.91 million authoritative geometries drawn from 16 national and state portals, then published as a zero-dependency interactive document that opens in any browser with no compute environment behind it. Have a look first. The rest of this post explains how it was built and how I shaped it, as well as where I plan to go next. Open the full report in a new tab → I learn by doing. I built this on a private basis to contribute to the community discourse. For me it is all about the data; any opinions, perceived or intentional, are my own and have nothing to do with my official job roles. All data is from public sources. It covers 17 candidate industrial sites across all 8 Australian states and territories, spanning the National Electricity Market and the SWIS grid. Why I built this AI data center suitability model For me, this is a community and conservation-minded project: not about saying no to development, but about helping identify where development can create the most value with the least harm. The point is to make siting decisions more transparent, more constructive, and easier to discuss across stakeholders. AI data centers are resource-intensive. They depend on power, water, land, and supporting infrastructure, and they can also create real pressures on ecosystems and communities. I wanted to build something that makes those tradeoffs visible instead of hiding them behind a single score or reports that sit on shelves and don’t let users see it through there lenses. Why I used Wherobots for spatial suitability at scale I wanted a platform that could handle real spatial scale without forcing me into a slow, fragile workflow. I had been hearing about it on LinkedIn and Youtube by following Matt Forrest and wanted to learn by doing. This project queried 15.91 million authoritative geometries across 16 national and state/territory spatial datasets. At the regional modeling scale, the underlying NSW stack ingested 1,751,315 geometries across multiple cloud spatial tables, evaluating 4.92 million spatial join combinations. Using cloud-native GeoParquet inside Wherobots Havasu (Spatially Aware Apache Iceberg) tables, the storage footprint compressed from ~2.9 GB raw equivalent to ~430.7 MB — an 85.2% reduction. That scale matters because suitability analysis only becomes useful when it can be rerun quickly as assumptions change. Verified runtime breakdown across 15.9M geometrics Four different operations, four different numbers. They are not alternatives to each other: 2.4 s for the spatial SQL join execution (distributed joins + net developable area overlays across 1.75M+ geometries); 18.4 s → 3.2 s for the national scan across 15.91M geometries using Hilbert space-filling curve partitioning; 200.6 s for the cold end-to-end batch ETL (uncached ingest, GDA2020 reprojection, ST_MakeValid topology repair, Iceberg writes); and < 1 ms for the client-side What-If recalculation in the browser. What I was trying to learn I wanted to understand how far I could push a cloud spatial workflow while still producing something that a non-technical audience could review. The answer was to combine Wherobots for the heavy computation with a document-style HTML report for presentation. The report is the public-facing layer of the analysis. It includes an interactive map, a ranked candidate leaderboard, benchmarking tables, provenance, methodology, and a what-if sandbox for changing ranking weights. My recent work covers GDA2020 cadastral modernization at an enterprise level, environmental monitoring at a state level, and disaster modeling and high level coordination with FEMA. As the creator of *AuraSiting Crafter* (currently hunter_spatial crafter), I built an open-source multi-criteria engine benchmarking clean energy, water security, acoustic buffers, and developable land across 15.91 million Australian geometries using Wherobots MCP as the critical foundation. George Chandeep Corea Builder, Learner, Public Sector Why the interactive suitability report matters The HTML report is where the analysis becomes useful for public review. It is not just a visualization — it is a way to interrogate the assumptions behind the ranking. The map is interactive, searchable, and configurable. Readers can change basemaps, add WMS/WFS services, and bring in external layers to compare candidate sites against their own data or public reference layers (some functionality coming soon!). That matters because spatial decisions are rarely made from one dataset alone. Adding data will make the report more useful for collaboration, because different stakeholders can overlay the information that matters to them: local context, community knowledge, infrastructure plans, environmental constraints, or jurisdictional boundaries. The sandbox (already available) is especially valuable because readers can adjust the ranking weights and immediately see how the candidate ordering changes. That makes the tradeoffs tangible instead of theoretical. Suitability report overview The report overview combines summary KPI cards, an interactive What-If simulation sandbox, an interactive siting map with layer controls, and a ranked candidate leaderboard into a single reviewable spatial document. How the suitability workflow works The pipeline is straightforward: Ingest authoritative layers — harvest from live government WFS/REST portals and national registers into cloud object storage Apply exclusions and setbacks — deduct 30 m riparian corridors, 20 m high-pressure gas/water pipeline easements, high-value biodiversity zones, slope >5%, and tailings dam hazards for example. Calculate network distances — topological winding distances (1.32× factor) to ≥132kV substations and wastewater outfalls for example Evaluate sensitive receptors — continuous sigmoidal buffer penalty around schools, hospitals, and residential meshblocks for example Benchmark against regional baselines — compare candidates against simulated baselines across interstate transition hubs (Latrobe Valley, Collie, Gladstone) for example. Only the hunter has detailed data. Sites outside the Development Application (DA) in LMCC has data simulated (not mocked or made up though) through analysing relevant real spatial data. Publish a zero-dependency report — compile layers, audits, and metadata into a standalone interactive HTML document The scoring model uses many weights: Power grid proximity: 50% Recycled water proximity: 30% Parcel size: 20% Others added/will be added as the project develops and Those weights reflect the practical requirements of AI infrastructure while keeping environmental and resource considerations visible. How the suitability score is calculated Suitability = 0.40·S_power + 0.25·S_sensitive + 0.20·S_water + 0.15·S_size Power grid proximity (40%). Proximity to ≥132kV transmission substations. Full points between 100 m and 500 m; linear decay to 0.0 at 5 km; a 0.7 penalty under 100 m for EMF safety and acoustic isolation. Sensitive receptor buffer (25%). A continuous sigmoidal decay around a 500 m compliance threshold: S_sensitive(d) = 1 / (1 + e^(-0.01·(d - 500))). Hard exclusion under 300 m; acoustic-barrier buffer penalty 300–500 m (0.10–0.50); compliant 500 m–1.5 km (0.50–1.0); optimal workforce balance 1.5–5 km (1.0); linear commute decay beyond 5 km. Recycled water proximity (20%). Distance to wastewater treatment plants for sustainable evaporative cooling, decaying linearly from 1.0 at ≤1 km to 0.0 at ≥10 km. Developable parcel size (15%). Contiguous flat buildable land. Parcels ≥15 ha score 1.0; parcels under 3 ha get a 0.1 baseline, with linear interpolation between. Slope calculations exclude land above 5% grade to avoid excessive earthworks. What the analysis is based on National input layers The national model integrates 16 authoritative datasets across all 8 Australian jurisdictions: Geoscape National Cadastre & G-NAF (15,420,800), ABS 2021 Meshblocks & UCL (368,290), National Sensitive Receptors from ACARA / NHSD / OSM (47,510), Geoscience Australia electricity grid (4,820), BoM & GA surface water and outfalls (42,100), and state planning/cadastral portals — NSW SEED, QLD QSpatial, Vicmap, Landgate (27,725). Total: 15,911,245 geometries. Those totals are the available universe published across the portals — 47,510 POIs and 15.4M cadastral parcels are what ACARA, NHSD, OpenStreetMap and Geoscape publish, not what this pipeline processed. The ingested and audited cohort is 1.75M regional features in the Hunter deep-dive, 368,290 ABS meshblocks partitioned nationally, 17 indexed candidate sites, and a ground-truth QA sample of 33 sensitive receptors (19 schools via ACARA, 14 hospitals via NHSD) sitting inside the candidate industrial zones across all 8 states, used to calibrate the sigmoidal buffer decay curve. Of the 17 candidates, 4 are micro-sited in detail in the NSW Hunter; the remaining 13 are simulated baselines across interstate transition hubs (Latrobe Valley VIC, Collie WA, Gladstone QLD). The earlier NSW regional stack: still the measured layer DatasetFeature countNotesNSW Transport Network (Rail)275,421Transport contextNSW Biodiversity Constraint Zones262,258Environmental exclusionNSW Energy Grid Infrastructure241,573Power proximityABS Census Meshblocks223,238Demographic contextNSW Pipeline Corridors197,247Setback constraintsTfNSW Active Transport Pathways188,576Access and corridor contextNSW Hydrography & Waterways181,501Water and riparian contextABS Regional Demographics1,160Regional benchmarking Storage and compression on Havasu Iceberg All spatial tables are cataloged under org_catalog.fgsdb.* on Wherobots Cloud and persisted in cloud object storage, in GDA2020 / MGA Zone 56 (EPSG:7856). TableGeometriesUncompressed rawGeoParquet footprintSavingsmacquarie_biodiversity_constraints262,258~580.0 MB84.2 MB85.5%macquarie_energy_infrastructure241,573~420.0 MB62.5 MB85.1%macquarie_transport_rail275,421~390.0 MB58.1 MB85.1%macquarie_pipeline_corridors197,247~280.0 MB41.8 MB85.1%macquarie_abs_meshblocks223,238~650.0 MB98.4 MB84.9%macquarie_water_hydrography181,501~310.0 MB44.6 MB85.6%macquarie_active_transport188,576~260.0 MB39.2 MB84.9%abs_demographics1,160~12.0 MB1.8 MB85.0%Total (8 tables)1,751,315~2.9 GB~430.7 MB85.2% To avoid real-time WFS/FeatureServer REST API timeouts during Spark runs, every dataset is ingested and hosted as an optimized cloud spatial Iceberg table rather than fetched live. The spatial SQL underneath Building the net developable area mask — unioning riparian, pipeline, and rail buffers and subtracting them from the sub-precinct boundaries: SELECT p.precinct_key, ST_Difference(p.geom, ST_Union_Aggr(c.geom)) AS net_developable_geom FROM precinct_transform p LEFT JOIN constraints c ON ST_Intersects(p.geom, c.geom) GROUP BY p.precinct_key, p.geom Computing nearest distances to transmission substations and wastewater treatment outfalls: SELECT mb.mb_code21, MIN(ST_Distance(mb.mb_geom, ST_Transform(p.geometry, 'EPSG:4326', 'EPSG:7856'))) / 1000.0 AS dist_to_substation_km, MIN(ST_Distance(mb.mb_geom, ST_Transform(w.geometry, 'EPSG:4326', 'EPSG:7856'))) / 1000.0 AS dist_to_wwtw_km FROM industrial_meshblocks mb CROSS JOIN org_catalog.fgsdb.macquarie_energy_infrastructure p CROSS JOIN org_catalog.fgsdb.macquarie_water_hydrography w GROUP BY mb.mb_code21 How I think about the planning question My background in conservation shaped this project. I’m not trying to use technology to say “no” to development. I’m trying to use it to ask better questions about where development belongs, where it creates value, and how to reduce unnecessary conflict between infrastructure, ecosystems, and communities. That is why the report includes explicit constraint layers, benchmarking, and scenario controls. The aim is to support better judgment, not replace it. Benchmarking and query speed mechanics Benchmarking and speed mechanics breakdown detailing how spatial SQL queries execute across 1.75M+ geometries via metadata envelope pruning, Hilbert curve clustering, vectorized memory execution, and parallel distributed spatial joins. Four things account for the query speed: Metadata envelope pruning. Havasu Iceberg stores 2D bounding box envelopes directly inside Iceberg AVRO manifest files. Queries with spatial predicates such as ST_Intersects prune the large majority of irrelevant Parquet files at the metadata layer, before any raw disk bytes are scanned. Hilbert curve spatial clustering. Geometries are sorted with 2D Hilbert space-filling curves during ingestion, so geographically adjacent features land in the same Parquet row groups and storage partitions. That removes random disk I/O seek overhead. Vectorized memory execution. Apache Sedona operates directly on columnar GeoParquet WKB geometry buffers, avoiding serialization costs between Python, the Spark JVM, and native spatial drivers. Parallel distributed spatial joins. Quad-tree and R-tree spatial indexes partition the query space across worker nodes, turning expensive O(N × M) cross-joins into O(N log M) parallel bucket joins. Candidates are benchmarked against simulated local and regional baselines — Latrobe Valley in VIC, Collie in WA, Gladstone in QLD — to position NSW development opportunities within the wider national energy market transition. How the what-if sandbox runs with no server The simulation sandbox runs entirely in the browser: no server calls, no network latency, no cloud API charges during a slider session. The heavy spatial work — topological winding distances, buffer overlaps, elevation head drops, thermodynamic decay rates — is computed at build time on Wherobots and embedded in the report’s JSON payload. Moving a weight slider then normalizes the raw values so the weights sum to 1.0 and recalculates suitability across every candidate record in JavaScript, in under a millisecond. Toggling the tailings dam safety switch swaps pad areas between the declared and de-declared cases (+15.2 ha unlocked) and updates map polygons and audit cards without refetching any GeoJSON. Candidates re-sort by active score, updating the leaderboard, marker radii, and popup badges. The payoff is threefold: no per-query cloud compute cost during interactive sessions, full interactivity when the HTML report is emailed or opened offline, and slider manipulation that stays smooth without waiting on network round-trips. What’s next for the suitability model The following describes the author’s planned work, not shipped functionality. Sensitive receptor scoring. The next version will score candidates against sensitive community receptors — schools and early childhood centers, hospitals and aged care, residential meshblocks, and workforce commute bands — to prevent acoustic, thermal, electromagnetic, and visual conflicts. The model uses a continuous sigmoidal penalty around a 500m critical setback threshold, with a workforce accessibility modifier that’s neutral in the 1.5km–5.0km commute band. In practice: under 300m is a critical exclusion, 300–500m carries a buffer penalty requiring an acoustic barrier, 500m–1.5km is compliant, 1.5–5.0km is the optimal community-and-workforce balance, and beyond 5km the score falls off for commute burden. Grid and water policy analysis. Following the National Cabinet debate on AI data center power demand and regional grid security, the framework will evaluate proximity to 132kV, 330kV, and 500kV bulk transmission, flag candidates adjacent to retiring coal-fired stations that can reuse existing heavy transmission without expensive grid upgrades, map candidates against Renewable Energy Zones and firming assets for 24/7 clean energy matching, and restrict cooling supply strictly to recycled and wastewater sources — scoring zero for any site dependent on potable drinking water reserves or vulnerable aquifers. Candidates then sort into three tiers: grid-ready and fast-track eligible, conditional pending firming storage, or constrained by congestion and potable water reliance. Open platform integration. To let the public explore these models interactively, hunter_spatial_crafter will integrate with opengeos/GeoLibre. The design point worth noting is zero duplication: Wherobots writes suitability layers to a central cloud bucket as GeoParquet and PMTiles, and GeoLibre’s in-browser DuckDB-WASM engine reads those exact same files over HTTP range requests — fetching only the row groups it needs, with no dataset conversion, no server-side copy, and no large client download. Engineering efficiencies: reducing compute spend Total cloud batch compute spend across dozens of iterative development, benchmark, and QA runs was ~$36 AUD (US$24.13) — roughly $1.03 per run across ~35 automated batch runs. Analyzing the execution profile shows how a production pipeline could cut that further: Decouple heavy geometry joins from lightweight scoring. The pipeline splits into a compute-intensive geometric tier (ingest, GDA2020 reprojection, ST_MakeValid repair, 30 m/20 m buffers, ST_Difference overlays across millions of polygons) and a compute-light scoring tier (decay curves and weighted composites over precomputed distance attributes). Structured as a DAG with intermediate materialised GeoParquet stages, tuning a weight or the sigmoidal threshold never re-runs the heavy joins — only the downstream matrix recalculates. Fingerprint sources and memoize snapshots. Baseline layers change infrequently. Content hashing (ETags, GeoParquet file hashes, Iceberg snapshot manifest IDs) lets untouched tables be skipped, reading straight from cached Havasu Iceberg partitions. Process delta partitions. When state portals publish quarterly cadastral updates, Iceberg’s ACID snapshot metadata lets WherobotsDB (optimized and managed Apache Sedona) isolate only modified parcel geometries instead of full continental scans. Offload interactive compute to the client. Compiling precomputed distance topologies into the standalone report puts millions of interactive public scenario evaluations at $0.00 cloud compute cost. Applied together, these reduce continuous CI/CD pipeline cost from ~$36 AUD to under $5 AUD. Why I think this is useful This project taught me that Wherobots is more than a faster way to run spatial SQL. It is a way to make large-scale spatial analysis practical for real decision support. It gave me a path from raw geodata to a polished, reviewable spatial document — one that can be opened by a stakeholder, examined by a technical reviewer, and discussed in public. For a personal project, that was the goal: learn the platform, test it at real scale, create something useful, and contribute to the broader discussion about responsible AI infrastructure. If you’re interested in spatial analysis, cloud geospatial workflows, or responsible AI infrastructure, feel free to connect with me on LinkedIn. Get Started with Wherobots Try Now Frequently Asked Questions How does Wherobots perform at national-scale spatial analysis? This project queried 15.91 million authoritative geometries across 16 national and state/territory spatial datasets. At the regional modeling scale, the underlying NSW stack ingested 1,751,315 geometries across multiple cloud spatial tables, evaluating 4.92 million spatial join combinations. The national scan across 15.91M geometries runs from 18.4 s down to 3.2 s using Hilbert space-filling curve partitioning. What accounts for query speed at scale on Wherobots? Four things. Metadata envelope pruning: Havasu Iceberg stores 2D bounding box envelopes inside Iceberg AVRO manifest files, so queries prune irrelevant Parquet files before any disk read. Hilbert curve spatial clustering: geographically adjacent features land in the same Parquet row groups.Vectorized memory execution: Apache Sedona operates directly on columnar GeoParquet WKB geometry buffers. Parallel distributed spatial joins: quad-tree and R-tree indexes turn O(N × M) cross-joins into O(N log M) parallel bucket joins. How much does it cost to run a national geospatial pipeline on Wherobots? Total cloud batch compute spend across dozens of iterative development, benchmark, and QA runs was ~$36 AUD (US$24.13), roughly $1.03 per run across ~35 automated batch runs. How do you publish an interactive geospatial report from Wherobots with no backend? The heavy spatial work is computed at build time on Wherobots and embedded in the report’s JSON payload. Moving a weight slider normalizes the raw values so the weights sum to 1.0 and recalculates suitability across every candidate record in JavaScript, in under a millisecond. Toggling the tailings dam safety switch swaps pad areas between the declared and de-declared cases (+15.2 ha unlocked) and updates map polygons and audit cards without refetching any GeoJSON. How is AI data center site suitability calculated? Suitability = 0.40·S_power + 0.25·S_sensitive + 0.20·S_water + 0.15·S_size. Power grid proximity is 40%, sensitive receptor buffer is 25%, recycled water proximity is 20%, and developable parcel size is 15%. Slope calculations exclude land above 5% grade to avoid excessive earthworks. --- ## The Wherobots Spatial AI Assistant is now in the Anthropic Connectors Directory URL: https://wherobots.com/blog/spatial-ai-assistant-anthropic-connectors/ Updated: 2026-10-19 You can now ask Claude questions about the physical world and get answers grounded in real spatial data.  Which facilities sit in the path of today’s storms? Which county west of the Mississippi has the fewest pharmacies per person? How much of Austin’s rooftop area sits under canopy? The Wherobots Spatial AI Assistant, now available in the Anthropic Connectors Directory, answers these questions in plain language and returns results, maps, and reports directly in your Claude conversation. Key takeawaysThe Wherobots Spatial AI Assistant is now in the Anthropic Connectors Directory. You can ask Claude questions about the physical world and get results, maps, and reports in the conversation.Getting started is two steps: install the connector and sign in to your Wherobots organization. Out of the box Claude can use Overture buildings, transportation, and places; Foursquare Open Places; NWS watches and warnings (hourly); GLO-30/90 DEM; and a Regrid parcels sample.The assistant plugs into the Wherobots Spatial SQL API and uses packaged skills so Claude writes valid spatial SQL. You don’t need a GIS team in the loop to get an answer.First-time users get a 14 day / $95 free trial. Tell Wherobots you connected the Spatial AI Assistant and you can qualify for an additional $250 in credits. Spatial AI Assistant by Wherobots on Anthropic Marketplace Wherobots is the context engine for physical world data. It gives AI the spatial intelligence it needs to reason about where things are, how they relate, and what has happened on the ground.  Here is an example of an insurance risk analysis of all of Colorado that we initially built with Claude Opus 5 and the Spatial AI Assistant, then expanded on with the VSCode Spatial AI Coding Assistant to be a complete hosted application. The challenge with traditional data systems for building an application like this is both the skills and the data processing cost. We were able to easily join Regrid parcels with Overtures buildings, build hexes that show various layers of risk derived from open raster data, along with the underlying geometry scored on each parcel in a matter of minutes with a Wherobots large runtime. Having the infrastructure and processing capability at you and your AI’s “fingertips” to build with makes moving from idea to production application far easier and faster than without. Screening indicators from modelled and tract-resolution inputs — not underwriting. Counts are floors. Imagery is locational context only. Open full screen ↗ Getting started with the Spatial AI Assistant takes two steps: install the connector, and sign in to your Wherobots organization, and then begin to prompt Claude. With zero additional setup, Claude can begin to utilize datasets including:  Overture: Buildings, Transportation, Places Foursquare: Open Places  NWS Watch/Warnings, updated hourly GLO-30/90 DEM Elevation Rasters Regrid Parcels (sample)  See it in action here: Interacting with Claude Chat to create an analysis about coastal flood risk in California. Analyzing open datasetsThe Wherobots Global Hub continues to expand the open datasets it offers out of the box. In the near future we plan to add wildfire risk models to the hub in partnership with the USDA Forest Service as well as the national hydrography dataset (NHD). You can also connect to STAC collections for additional raster datasets. If there is open or proprietary data that you are interested in having access to fully supported and maintained by Wherobots while iterating with Claude’s models, reach out to us about it. Analyzing proprietary datasetsIn a few steps, customers can easily attach Wherobots to their S3 storage buckets, catalog systems like Databricks Unity Catalog and AWS Glue Data Catalog, and authoritative 3rd party datasets like Regrid’s Parcels. These integrations enable Wherobots to query proprietary mobility, customer, and asset data with Claude.Once you’ve connected Wherobots every Claude conversation can query the data Wherobots has access to, so you can test your ideas and drive progress with physical world data. How the Spatial AI Assistant Works The Spatial AI Assistant plugs into the Wherobots Spatial SQL API and uses skills for accessing the Wherobots documentation, as well as the datasets registered in the Wherobots Global Hub. Claude uses Wherobots skills packaged with the connector to write strong, valid spatial SQL with (generally) correct functions, syntax, and joins. Results come back into your Claude conversation, ready to work with, and you don’t need to interact with a roadmap or a team of spatial experts to get it.  Try It Today There’s a 14 day/$95 free trial available to all first time users to Wherobots that you can utilize to test your ideas. After the trial expires, customers pay a low on-demand rate for Wherobots spatial units consumed through the Spatial SQL API. When you start your trial let us know you have connected the Spatial AI Assistant and you can qualify for an additional $250 in Wherobots credits. Getting started is easy. Install Wherobots Spatial AI Assistant for Claude, connect your Wherobots organization, and ask your first question like: How much of Austin’s rooftop area sits under canopy? Want to see what this looks like in practice before you install? Watch the MCP demos in the videos below. The workflows shown there, from natural language questions to working spatial SQL to results on a map, are the same workflows the Spatial AI Assistant puts in front of your entire organization.  Frequently Asked Questions What is the Wherobots Spatial AI Assistant? It is a Claude connector that answers questions about the physical world with real spatial data and returns results, maps, and reports in the conversation. Wherobots is the AI context engine for the physical world. How do I install the Wherobots Spatial AI Assistant in Claude? Install the connector from the Anthropic Connectors Directory and sign in to your Wherobots organization. Then prompt Claude. An example: How much of Austin’s rooftop area sits under canopy? What datasets can Claude query through Wherobots? With zero additional setup: Overture buildings, transportation, and places; Foursquare Open Places; NWS Watch/Warnings updated hourly; GLO-30/90 DEM elevation rasters; and a Regrid parcels sample. You can also attach S3, Databricks Unity Catalog, AWS Glue Data Catalog, and third-party datasets like Regrid parcels. How does the Spatial AI Assistant work? It plugs into the Wherobots Spatial SQL API and uses skills for Wherobots documentation and Global Hub datasets. Claude uses those skills to write spatial SQL, and results come back into the Claude conversation. --- ## From the Spokane firestorm to all of Washington: real-time wildfire monitoring for under $50 a pass URL: https://wherobots.com/blog/spokane-fire-dnbr/ Updated: 2026-10-19 On August 1, 2026, the most destructive fire event in Washington’s history swept into the Spokane area, driving 65,000 people from their homes. Wildfire response runs on one thing: knowing where the fire has burned and where it is growing. Every hour sooner that map exists, the better every decision downstream, from evacuation zones and containment lines to protecting homes, utilities, and insured assets. Key takeawaysOn August 1, 2026, the Spokane firestorm drove 65,000 people from their homes. The pipeline turns a new Sentinel-2 pass into a burn-severity map in about 14 minutes for about $20 of compute.It is one Python job on WherobotsDB, with no downloads, no ingest, and no GIS backlog.Input is 56 cloud-optimized GeoTIFFs (~2.6 GB) in the public Sentinel-2 archive on S3. WherobotsDB out-of-database rasters resolve lazily, so only about 9% of pixels inside the area of interest ever cross the wire.End to end on a MEDIUM runtime costs about $20, roughly 13 Spatial Units at $1.50 each in us-west-2.The same job pointed at Washington plus the Idaho panhandle (42 Sentinel-2 tiles, 690 candidate scenes, three UTM zones) finished in 14 minutes. It ran on a LARGE runtime for about $45 (30 Spatial Units).It produced 457 detections, and ESA WorldCover marked 403 as cropland-majority. The remaining 54 fire candidates included every news-confirmed fire in the window.dNBR uses USGS thresholds (low ≥ 0.10, moderate-low ≥ 0.27, moderate-high ≥ 0.44, high ≥ 0.66). Five days after ignition, tile T11TMN showed 5,627 acres at moderate-and-worse.The low class also picks up harvest and irrigation change. That is why the post quotes moderate-and-worse rather than summing all classes. The satellites already see every fire. What has been missing is real-time analysis: the moment a new pass lands in the archive, this pipeline turns it into a burn-severity map in 14 minutes, for about $20 of compute. One Python job on WherobotsDB, no downloads, no ingest, no GIS backlog. We built it on the Spokane firestorm, then pointed the same job at the entire state, and it found Washington’s other major fires (Sinlahekin, Modrite, Kaiser Canyon) by itself, while they were still burning. The pipeline keeps up with whatever imagery you feed it: the free Sentinel-2 constellation delivers a fresh statewide look every few days, and higher-cadence sources slot into the same job. Every number below comes from the production runs. Burn severity of the Spokane firestorm: Sentinel-2 dNBR, August 6 2026 The technique is dNBR (differenced Normalized Burn Ratio), the standard used by USGS and the EU’s Copernicus Emergency Management Service for burn severity mapping. Healthy vegetation is bright in near-infrared (Sentinel-2 band B8A) and dark in shortwave-infrared (B12); burned ground flips that. So: NBR = (B8A − B12) / (B8A + B12), per pixel, per scene dNBR = NBRpre-fire − NBRpost-fire; big positive values mean severe burn The input is 56 cloud-optimized GeoTIFFs (~2.6 GB) in the public Sentinel-2 archive on S3, and none of it is downloaded or ingested. WherobotsDB’s out-of-database rasters resolve lazily, so only the ~9% of pixels inside our area of interest ever cross the wire. Which scenes detected the fire? WherobotsDB’s STAC reader loads a STAC collection as a DataFrame, with spatial and temporal filter pushdown. We point it at Element84’s Earth Search catalog and filter to a bounding box covering all three fires, a pre-fire window (July 10–31) and a post-fire window (August 2 onward). Each STAC asset comes with a ready-to-use out-db raster column. Show the code AOI = "POLYGON((-117.75 47.55, -117.20 47.55, -117.20 47.95, -117.75 47.95, -117.75 47.55))" AOI_SQL = f"ST_SetSRID(ST_GeomFromWKT('{AOI}'), 4326)" raw = ( sedona.read.format("stac") .option("itemsLimitMax", "1000") .load("https://earth-search.aws.element84.com/v1/collections/sentinel-2-c1-l2a") ) raw.createOrReplaceTempView("stac_items") scenes = sedona.sql(f""" SELECT id, element_at(split(id, '_'), 2) AS tile, datetime, CASE WHEN datetime <= TIMESTAMP '2026-07-31 23:59:59' THEN 'pre' ELSE 'post' END AS phase, `eo:cloud_cover` AS cloud_cover, assets['nir08'].rast AS nir, -- B8A, 20 m assets['swir22'].rast AS swir -- B12, 20 m FROM stac_items WHERE ST_Intersects(geometry, {AOI_SQL}) AND datetime >= TIMESTAMP '2026-07-10 00:00:00' AND datetime <= TIMESTAMP '2026-08-07 23:59:59' AND (datetime <= TIMESTAMP '2026-07-31 23:59:59' OR datetime >= TIMESTAMP '2026-08-02 00:00:00') """) scenes.createOrReplaceTempView("scenes") scenes.select("id", "tile", "datetime", "phase", "cloud_cover").orderBy("tile", "datetime").show(5) +------------------------------+------+-----------------------+-----+-----------+ |id |tile |datetime |phase|cloud_cover| +------------------------------+------+-----------------------+-----+-----------+ |S2C_T11TMN_20260712T185514_L2A|T11TMN|2026-07-12 19:01:16.775|pre |99.997228 | |S2B_T11TMN_20260714T184425_L2A|T11TMN|2026-07-14 18:51:18.916|pre |88.490695 | |S2A_T11TMN_20260714T190034_L2A|T11TMN|2026-07-14 19:01:32.559|pre |89.065939 | |S2B_T11TMN_20260717T185644_L2A|T11TMN|2026-07-17 19:01:16.249|pre |12.527606 | |S2C_T11TMN_20260719T184029_L2A|T11TMN|2026-07-19 18:51:20.68 |pre |3.3E-4 | +------------------------------+------+-----------------------+-----+-----------+ only showing top 5 rows 28 scenes match, across two MGRS tiles (T11TMN to the south, T11UMP to the north). With Sentinel-2A, -2B, and -2C all flying, Spokane is revisited every two to three days. That cadence is what lets the pipeline track a fire’s status over time. How burned is a pixel? Each scene’s B8A and B12 arrive as separate single-band rasters. We clip both to the AOI with RS_Clip, which keeps every downstream operation working on a ~4 M-pixel window instead of a full 30 M-pixel tile. The band math itself is a vectorized Python UDF: the function takes one SedonaRaster argument per raster column, reads pixels as NumPy arrays with nodata masked to NaN, and returns a new raster with with_bands, which keeps the CRS and transform intact (a follow-up RS_SetBandNoDataValue marks the sentinel for the statistics downstream). WherobotsDB feeds the UDF through Apache Arrow in batches, so plain NumPy runs at cluster scale, and everything in the SciPy ecosystem is available inside the function when an analysis needs it. The raster reader already applies the COG’s raster:bands scale and offset, so pixel values arrive as surface reflectance (≈0–1). Use them directly; no DN conversion is needed. If an index map ever looks suspiciously flat, a one-second RS_Value probe at a known point tells you why. Show the code import numpy as np from pyspark.sql.functions import col, expr from sedona.spark.raster import SedonaRaster from sedona.spark.sql.functions import sedona_vectorized_udf from sedona.spark.sql.types import RasterType NODATA = -9999.0 @sedona_vectorized_udf(return_type=RasterType()) def nbr_udf(nir: SedonaRaster, swir: SedonaRaster) -> SedonaRaster: """NBR = (B8A - B12) / (B8A + B12). as_numpy_masked() turns nodata into NaN, so invalid pixels ride through the arithmetic; values <= 0 (clip fill, dark pixels) join them. """ n = nir.as_numpy_masked()[0] s = swir.as_numpy_masked()[0] with np.errstate(divide="ignore", invalid="ignore"): nbr = np.where((n <= 0) | (s <= 0), np.nan, (n - s) / (n + s)) return nir.with_bands(np.where(np.isnan(nbr), NODATA, nbr)[np.newaxis]) clipped = sedona.sql(f""" SELECT id, tile, datetime, phase, cloud_cover, RS_Clip(nir, 1, {AOI_SQL}, false, 0.0) AS nir_aoi, RS_Clip(swir, 1, {AOI_SQL}, false, 0.0) AS swir_aoi FROM scenes """).filter("nir_aoi IS NOT NULL AND swir_aoi IS NOT NULL") nbr = clipped.select( "id", "tile", "datetime", "phase", "cloud_cover", nbr_udf(col("nir_aoi"), col("swir_aoi")).alias("nbr_raw"), ).withColumn( "nbr", expr(f"RS_SetBandNoDataValue(nbr_raw, {NODATA}d)") ).drop("nbr_raw") nbr.persist() nbr.createOrReplaceTempView("nbr") The value <= 0 guard handles nodata, clip fill, and the offset-negative dark pixels (water, deep shadow) in one condition. From here, one RS_ZonalStatsAll per scene gives a mean-NBR time series over the AOI: a quick health check on the imagery now, and a recovery tracker later. Show the code timeseries = sedona.sql(f""" SELECT id, tile, date(datetime) AS date, phase, cloud_cover, zs.mean AS mean_nbr, zs.count AS valid_px FROM (SELECT *, RS_ZonalStatsAll(nbr, {AOI_SQL}) AS zs FROM nbr) ORDER BY tile, date """).localCheckpoint() # materialize the 28-row table and cut its lineage timeseries.createOrReplaceTempView("nbr_ts") Mean NBR per clear scene, July 17 to August 6, with ignition marked. Eight clear scenes in three weeks: that revisit rate is what turns a one-off map into a monitor. Which two scenes? (the boring part that matters) dNBR needs one pre-fire and one post-fire scene per tile, and the naive choice (“latest scene on each side”) bit us: Sentinel-2 sometimes acquires two overlapping products on the same day, and the latest pre-fire scene for T11TMN was a partial swath covering only a third of the tile. The result was a nodata band right through the Old Trails burn scar. The selection rule: (1) drop scenes with 20% cloud or more, (2) gate on near-full swath coverage using the zonal pixel counts we already computed, and (3) only then prefer recency. Two window functions express the whole rule in SQL: max(valid_px) OVER each tile and phase sets the coverage bar, and row_number() takes the best-ranked scene on each side. The localCheckpoint() above matters here; it hands the planner a small, static table for this self-join while the raster work stays lazy. Show the code pairs = sedona.sql(""" WITH scored AS ( SELECT tile, phase, id, date, valid_px, max(valid_px) OVER (PARTITION BY tile, phase) AS max_px FROM nbr_ts WHERE cloud_cover IS NULL OR cloud_cover < 20 ), ranked AS ( SELECT *, row_number() OVER ( PARTITION BY tile, phase ORDER BY (valid_px >= 0.95 * max_px) DESC, date DESC, valid_px DESC, id DESC) AS rn FROM scored ) SELECT pre.tile, pre.id AS pre_id, pre.date AS pre_date, post.id AS post_id, post.date AS post_date FROM ranked pre JOIN ranked post ON pre.tile = post.tile AND pre.phase = 'pre' AND post.phase = 'post' AND pre.rn = 1 AND post.rn = 1 """) pairs.createOrReplaceTempView("pairs") if pairs.count() == 0: raise ValueError("no usable scene pairs: every candidate was cloud- or coverage-filtered") @sedona_vectorized_udf(return_type=RasterType()) def dnbr_udf(pre: SedonaRaster, post: SedonaRaster) -> SedonaRaster: """dNBR = pre-fire NBR - post-fire NBR; NaN stays NaN through the subtraction.""" diff = pre.as_numpy_masked()[0] - post.as_numpy_masked()[0] return pre.with_bands(np.where(np.isnan(diff), NODATA, diff)[np.newaxis]) dnbr = sedona.sql(""" SELECT p.tile, p.pre_date, p.post_date, pre.nbr AS pre_nbr, post.nbr AS post_nbr FROM pairs p JOIN nbr pre ON pre.id = p.pre_id JOIN nbr post ON post.id = p.post_id """).select("tile", "pre_date", "post_date", dnbr_udf(col("pre_nbr"), col("post_nbr")).alias("dnbr_raw")) dnbr = dnbr.withColumn("dnbr", expr(f"RS_SetBandNoDataValue(dnbr_raw, {NODATA}d)")).drop("dnbr_raw") dnbr.persist() dnbr.createOrReplaceTempView("dnbr") How bad, and over how many acres? USGS thresholds turn dNBR into severity classes (low ≥ 0.10, moderate-low ≥ 0.27, moderate-high ≥ 0.44, high ≥ 0.66). One more UDF pass classifies the raster, and RS_CountValue turns class pixel counts into acres. At 20 m resolution each pixel is 400 m², about a tenth of an acre: Show the code @sedona_vectorized_udf(return_type=RasterType()) def classify_udf(dnbr: SedonaRaster) -> SedonaRaster: """USGS dNBR classes: 1 low, 2 moderate-low, 3 moderate-high, 4 high. NaN compares False against every threshold, so nodata lands in class 0. """ v = dnbr.as_numpy_masked()[0] with np.errstate(invalid="ignore"): out = np.select( [v >= 0.66, v >= 0.44, v >= 0.27, v >= 0.10], [4, 3, 2, 1], default=0) return dnbr.with_bands(out.astype(np.float64)[np.newaxis]) classified = dnbr.withColumn("classified", classify_udf(col("dnbr"))) classified.createOrReplaceTempView("classified") ACRES = 400.0 / 4046.8564224 severity = sedona.sql(f""" SELECT tile, pre_date, post_date, ROUND(RS_CountValue(arr, 1) * {ACRES}, 1) AS low_acres, ROUND(RS_CountValue(arr, 2) * {ACRES}, 1) AS mod_low_acres, ROUND(RS_CountValue(arr, 3) * {ACRES}, 1) AS mod_high_acres, ROUND(RS_CountValue(arr, 4) * {ACRES}, 1) AS high_acres FROM ( SELECT tile, pre_date, post_date, RS_BandAsArray(classified, 1) AS arr FROM classified ) """) severity.show(truncate=False) +------+----------+----------+---------+-------------+--------------+----------+ |tile |pre_date |post_date |low_acres|mod_low_acres|mod_high_acres|high_acres| +------+----------+----------+---------+-------------+--------------+----------+ |T11TMN|2026-07-29|2026-08-06|6017.8 |3335.0 |1788.9 |502.9 | |T11UMP|2026-07-29|2026-08-06|4372.5 |1663.2 |677.6 |193.8 | +------+----------+----------+---------+-------------+--------------+----------+ Five days after ignition, the burn reads like this (the two tiles overlap in the 47.7–47.9°N band where the fires sit, so the rows must not be summed): Tile Pair Low Mod-low Mod-high High Moderate+ T11TMN (south: NW Spokane, Nine Mile, Airway Heights) Jul 29 → Aug 6 6,018 3,335 1,789 503 5,627 T11UMP (north: Suncrest, Mead) Jul 29 → Aug 6 4,373 1,663 678 194 2,535 The map at the top of this post is the dNBR raster classified with these thresholds. The job also writes it out as GeoTIFFs with RS_AsGeoTiff and the raster writer, so the same output drops straight into QGIS. The main scar straddles the Spokane River around Nine Mile Falls and the Indian Trail bluffs, with the high-severity core on the slopes above the river. The low class (0.10–0.27) is the noisiest; at these thresholds it also picks up harvest and irrigation changes in cropland, so the moderate-and-worse figure is the one to quote. Official incident reports put the combined fires at ~10,000 acres of perimeter, which is expected to exceed spectrally-burned pixel area. Burned acres by severity class, five days after ignition, per Sentinel-2 tile. The same statements, one hundred times the area Nothing in the pipeline knows it is about Spokane; the AOI is a WKT string. We swapped the 30 km box for all of Washington plus the Idaho panhandle (42 Sentinel-2 tiles, 690 candidate scenes, three UTM zones) and let the engine do what engines do: SCL-masked dNBR wall-clock: region scale is a parameter. RS_TileExplode splits each scene into 512-pixel sub-tiles, so thousands of small tasks fill the cluster. That pattern is what keeps the statewide run this fast. 457 detections in one run: the big ones are all named fires. Dot area scales with detected acres (Jul 27 to Aug 6 change). Gray dashed dots are cropland-flagged by ESA WorldCover, 403 of 457; the 54 survivors are the fire candidates, and every news-confirmed fire is among them. The dashed box is the query AOI. Explore every detection, live The map below is the real output of the statewide run. Our production monitoring job, the same pipeline described above extended with burn-cluster detection and the cropland flag, ends by writing its detections as a single PMTiles archive with one call, vtiles.generate_pmtiles(detections, s3_path). A browser reads that file directly from S3 with HTTP range requests, no tile server, no export pipeline, rendered here in the Wherobots visualization tool. Click any polygon for its properties. If the viewer below is not working, try fullscreen mode here. Did it work? Check the news A detector is only as good as its false-positive rate, so we cross-checked the largest region-wide detections against news coverage of Washington’s August 2026 fire outbreak, the one that triggered the state’s first-ever “particularly dangerous situation” fire-weather warning. Detection (Aug 6 imagery) Identity Cropland flag 69,022 ac near Tonasket Sinlahekin Fire: 141,411 ac by Aug 10; ours is the Jul 27 → Aug 6 growth slice clear: fire candidate 40,485 ac near Inchelium Modrite Fire: “over 40,000 acres” in the same window clear: fire candidate Two clusters near Nespelem Kaiser Canyon Fire flanks: ignited Jul 16, before our baseline, so only fresh growth appears clear: fire candidate 4,512 ac northwest of Spokane The Spokane complex this post began with, rediscovered without being told it exists clear: fire candidate 46,947 ac in the Palouse No fire in the news; wheat harvest between the two dates flagged: cropland 11,073 ac Skagit delta · 6,219 ac Columbia Basin No fires in the news; farmland and irrigation change flagged: cropland Every news-confirmed fire lands in the clear column; every no-news detection lands in the flagged column. At region scale the flag does serious work: 403 of 457 raw detections are cropland-majority, leaving 54 fire candidates from one extra join against ESA WorldCover, in the same engine that did everything else. What didn’t happen here Most remote-sensing pipelines spend their time and money on steps this analysis skipped: No ingest. The STAC catalog was queried live and the COGs stayed where ESA/Element84 publish them. There is no “download the scenes” step, no staging bucket of copies to manage, and adding the next satellite pass to the analysis costs nothing but a date-range change. No raster database to load. The out-db raster model means RS_Clip, the NBR UDF, and RS_ZonalStatsAll executed against windowed range-reads of the source files: ~2.6 GB of input resolved to only the ~9% of pixels inside the AOI. Open formats on both ends. Results landed back in the lakehouse as GeoParquet and GeoTIFF. The severity table is queryable by any engine that reads Parquet, and the dNBR map opens directly in QGIS. Nothing is locked in a proprietary store. One engine for rasters and vectors. The same SQL session can join these burn pixels against Iceberg/Havasu tables, like Overture Maps buildings in the Wherobots Open Data catalog, which is where this analysis goes next. That combination (query-in-place over open cloud archives, spatial SQL over both raster and vector, and open outputs) is the lakehouse difference: the time from “a fire happened” to “a severity map exists” is measured in minutes of compute, not days of data wrangling. From one-off analysis to standing watch The analysis lives in one Python job script submitted with the Wherobots Airflow provider. New Sentinel-2 scenes land every two to three days, so a scheduled DAG keeps the severity map and the recovery time series current with zero manual steps: run = WherobotsRunOperator( task_id="run_dnbr_job", name="spokane_fire_dnbr_{{ ds_nodash }}", region=Region.AWS_US_WEST_2, # same region as the Sentinel-2 COGs runtime=Runtime.MEDIUM, run_python={"uri": f"{SCRIPT_S3}", "args": ["--post-end", "{{ ds }}"]}, poll_logs=True, ) End to end (STAC discovery, 28 NBR rasters, pair selection, dNBR, classification, acreage, Parquet + GeoTIFF outputs) takes about 14 minutes on a MEDIUM runtime and costs about $20: roughly 13 Spatial Units at $1.50 each in us-west-2. Wherobots Cloud reports the exact cost and Spatial Unit consumption of every run in Workload History, so the price of a standing watch is a line item you can read, per run, per day. The statewide watch is the same arithmetic: the Washington plus North Idaho detection run behind the live map above came to about $45 (30 Spatial Units on a LARGE runtime, 14 minutes for 42 tiles across three UTM zones). Where to take it Mask smoke and cloud per-pixel with the SCL band instead of scene-level metadata. Vectorize the burn perimeter with RS_Polygonize on the classified raster. Count affected structures by joining the perimeter against Overture Maps buildings, already hosted in the Wherobots Open Data catalog. Track recovery: the same NBR time series that found the drop will show vegetation green-up over the coming seasons. Everything here runs on any Wherobots organization. The imagery is public, and the code above is the entire method. If you want to try it on a fire (or flood, or storm) near you, create a Wherobots Cloud organization and point the STAC reader at your own AOI. Frequently Asked Questions How do you map burn severity from Sentinel-2 in Wherobots? The technique is dNBR (differenced Normalized Burn Ratio), the standard used by USGS and Copernicus EMS. NBR = (B8A − B12) / (B8A + B12) per pixel; dNBR = NBRpre-fire − NBRpost-fire. WherobotsDB’s STAC reader loads Element84’s Earth Search catalog with spatial and temporal filter pushdown, clips to the AOI with RS_Clip, and runs band math as a vectorized Python UDF. How much does statewide wildfire monitoring cost on Wherobots? The Spokane-area run (STAC discovery, 28 NBR rasters, pair selection, dNBR, classification, acreage, Parquet + GeoTIFF) takes about 14 minutes on a MEDIUM runtime and costs about $20. The Washington plus North Idaho detection run came to about $45: 30 Spatial Units on a LARGE runtime, 14 minutes for 42 tiles across three UTM zones. Do you have to download Sentinel-2 scenes to run dNBR? No. The STAC catalog is queried live, and the COGs stay where ESA/Element84 publish them. There is no download step and no staging bucket.Adding the next satellite pass is a date-range change. Out-of-database rasters mean RS_Clip, the NBR UDF, and RS_ZonalStatsAll execute against windowed range-reads of the source files. How do you filter false-positive burn detections from cropland? At region scale, 403 of 457 raw detections were cropland-majority. One extra join against ESA WorldCover left 54 fire candidates.Every news-confirmed fire in the August 2026 outbreak landed in the clear column: Sinlahekin, Modrite, Kaiser Canyon, and the Spokane complex. Detections with no news, such as Palouse wheat harvest, landed in the flagged column. --- ## Wherobots Now Federates with the AWS Glue Data Catalog URL: https://wherobots.com/blog/aws-glue-data-catalog-spatial-workloads/ Updated: 2026-10-19 AWS customers can now bring Wherobots’ best-in-class spatial intelligence capabilities to any dataset managed by AWS Glue Data Catalog. AWS Glue Data Catalog (GDC) customers use it to manage structured data, like user activity and revenue reports, and complex geospatial data, like parcels, buildings, and mobility datasets. AWS services like EMR, Redshift, and Athena excel at processing the former, while Wherobots is purpose-built for the latter. AWS customers have standardized tooling, governance, and processes around the GDC, which they do not want to replicate on another catalog. Having to manage two catalogs introduces friction and slows down innovation. Key takeawaysAWS Glue Data Catalog customers can now federate access to Wherobots using IAM policies. Wherobots reads geospatial data from the catalog, processes it, and writes it back, while Glue remains the central catalog.Customers keep existing GDC governance, tooling, and processes instead of running a second catalog.WherobotsDB is built by the original creators of Apache Sedona and is 100% code compatible across spatial functions. It handles CRS, mixed raster and vector formats, and joins across billions of geometries that stall on general-purpose engines such as Trino, Postgres, and Spark.A national e-commerce restocking example joins Sentinel-1 SAR imagery, NOAA HRRR precipitation forecast rasters, and the Overture Roads network. It buffers affected segments, runs zonal statistics, and writes a route disruption score to a federated Glue table for EMR restocking pipelines.Regrid standardized on AWS and used Wherobots to help architect the transition of 4,000+ geospatial pipelines to cloud-native processing. Integration uses AWS IAM and can be stood up in a few minutes on the Professional free trial: 14 days or $95 in credits, whichever comes first. How Wherobots Connects to the AWS Glue Data Catalog Today, Wherobots addresses this friction by making it easier for customers to use the best spatial data tool for the job while maintaining their governance layer in the AWS GDC. Using IAM policies, customers can now federate access between the AWS Glue Data Catalog and Wherobots. Wherobots will handle reading geospatial data from that catalog, processing it and writing it back to it, while Glue continues to act as the central catalog. For instance, consider a national e-commerce retailer coordinating just-in-time restocking across regional distribution centers. The workflow: Wherobots can ingest Sentinel-1 SAR imagery, which sees through cloud cover And ingest NOAA’s High-Resolution Rapid Refresh (HRRR) precipitation forecast raster Join both to the Overture Roads network connecting each center to its delivery routes Buffering the affected road segments and running zonal statistics against the flood and precipitation layers, the retail team can use Wherobots to calculate a route disruption score for each corridor and writes it to a federated Glue table. Supply chain teams at the retailer can then pull that score into their EMR restocking pipelines to trigger early shipments or reroute orders before a corridor goes down. Risk scores along road segments in Europe. Spatial Compute Built for Physical-World Data Trino, Postgres, and Spark are battle-tested engines, but they were not designed for what spatial data demands, such as coordinate reference systems (CRS), mixed raster and vector formats, and joins across billions of geometries. Built by the original creators of Apache Sedona and 100% code compatible across all spatial functions, WherobotsDB handles the spatial workloads that stall on general-purpose engines. With RasterFlow, this power extends to Earth Observation, enabling planetary-scale mosaicking and AI inference pipelines alongside high-performance vector analytics. Customers can also take advantage of Wherobots’ Spatial AI tools to get insights from spatial data in minutes using natural language, with little to no prior geospatial expertise. Open table formats and catalog services like AWS Glue Data Catalog remove the tradeoff: your governance, tooling, and data stay in Glue, while the engine built for spatial data does the spatial work. Regrid, uses Wherobots to provide comprehensive parcel data with boundaries, buildings, addresses, and geographic enrichments for all your location decisions. "We made a deliberate decision to standardize on AWS. The expertise and experience Wherobots bring to helping us navigate and architect the transition of 4,000+ geospatial pipelines to a highly scalable and efficient cloud native processing workflow has been invaluable to the success of our project. Wherobots is creating the future of cloud geospatial processing." Blake Girardot Senior Data Engineer at Regrid Get started with Wherobots and the AWS Glue Data Catalog Integrate Wherobots with your AWS Glue Data Catalog securely using AWS IAM in a few minutes, and run your first workloads on the Professional free trial: 14 days or $95 in credits, whichever comes first. We also offer hands-on spatial expertise to help you move your ideas and initiatives into production faster. We deliver this through the Wherobots Innovation Edition, which you can subscribe to by reaching out to us. Frequently Asked Questions How does Wherobots connect to the AWS Glue Data Catalog? Customers federate access between Glue Data Catalog and Wherobots using IAM policies. Wherobots handles reading geospatial data from that catalog, processing it, and writing it back. Glue continues to act as the central catalog, so AWS-standard tooling, governance, and processes stay in place. Why use Wherobots instead of EMR, Redshift, or Athena for geospatial data? EMR, Redshift, and Athena excel at structured data such as user activity and revenue reports. Wherobots is purpose-built for geospatial data such as parcels, buildings, and mobility datasets. Trino, Postgres, and Spark were not designed for CRS, mixed raster and vector formats, and joins across billions of geometries. Can Wherobots write spatial results back to Glue tables? Yes. In the retail restocking example, Wherobots calculates a route disruption score for each corridor and writes it to a federated Glue table. Supply-chain teams then pull that score into EMR restocking pipelines to trigger early shipments or reroute orders. How do I get started with Wherobots and Glue? Integrate Wherobots with your AWS Glue Data Catalog using AWS IAM in a few minutes. Run first workloads on the Professional free trial: 14 days or $95 in credits, whichever comes first. Hands-on spatial expertise is also available through the Wherobots Innovation Edition. --- ## How Bad Telemetry Data Sabotages Modern Fleets URL: https://wherobots.com/blog/bad-telemetry-data-fleet-observability/ Updated: 2026-10-19 By the Teams at Action Engine & Wherobots Fleet monitoring is undergoing a generational shift. Fleet monitoring, the systems that ingest and analyze vehicle telemetry to track fleet health, performance, and safety, has become the foundation of how operators run vehicles, not just track them. Modern vehicles generate orders of magnitude more telemetry than even five years ago – GPS, fuel and battery signals, sensor and event streams, on-board diagnostics; that data is no longer just a record of where the fleet has been. It’s the data layer operators use to make fleets more cost-effective, more sustainable, and increasingly more autonomous. Key takeawaysGeneric fleet platforms apply global thresholds, treat each ping in isolation, and miss anomalies hidden in geographic and temporal context. Action Engine built Aspen Fleet, an anomaly detection system powered by Wherobots distributed spatial compute, to catch those patterns against historical and near-real-time telemetry.Aspen ships a library of over 100 pre-built detection rules. They cover location validity, signal integrity, operational behavior, sensor envelopes, and computer vision / perception outputs.Location validity rules catch GPS teleportation (such as 500 km in two minutes), coordinates on water, and 80-meter GPS drift off a drivable surface.None of the checks rely on uniform thresholds. They reason about geography, route segment, device history, and temporal pattern at once.Customers can also author custom checks on the same engine when the pre-built library does not cover their operational logic.Aspen runs in two modes. Historical scans process years of stored telemetry at scale to label bad records and produce a clean baseline; near-real-time checks surface anomalies within minutes of the event.Integration can use Geotab and other telematics platforms, custom REST endpoints, batch dumps to object storage, or live gRPC feeds from on-board systems. This trajectory points in one direction: vehicles are now navigating by data. Autonomous and semi-autonomous fleets sit at the intersection of GIS, computer vision, and vision-language models – systems where the quality of the underlying data directly determines whether the vehicle stops at the right time, takes the right route, or correctly perceives the world around it. Generic fleet management platforms were built for an earlier era. They tell you where your fleet is. They struggle with the harder question of where your fleet is going wrong. Fleet management platforms apply global thresholds, treat each ping in isolation, and miss anomalies hidden in the geographic and temporal context around a record.Equipment doesn’t fail without warning. Vehicles don’t break down without prior warning signs. Fleets aren’t underutilized by accident. But the anomalies that precede these outcomes are almost always invisible inside generic fleet dashboards.They hide inside telemetry that looks fine in a table – GPS, fuel consumption, temperatures, pressures, sensor readings – until they aggregate into an incident. To close this gap, Action Engine built Aspen Fleet: an anomaly detection system engineered specifically for the future of fleet operations. Powered under the hood by Wherobots, the industry standard for distributed spatial compute, Aspen Fleet catches the patterns that generic platforms miss. By running against both historical and near-real-time telemetry, it uses spatial context as a first-class signal to surface anomalies earlier than previously possible. Aspen finds fuel-consumption outliers across thousands of transit vehicles by checking each unit against its own baseline, and maps the deviations onto the specific Portland segments where they occurred. What Generic Fleet Platforms Miss Traditional fleet management platforms work well for basic visibility – locations, statuses, and last-known positions. However, they struggle as true anomaly detectors for three specific reasons. They apply global thresholds A fuel consumption value that’s anomalous on a flat highway is completely normal on a mountain pass. An idle event in a depot is operational; the same event at an intersection in a residential block is suspicious. When a platform alerts on a single threshold for the entire fleet, it either generates false positives that operators learn to ignore or it misses real anomalies entirely. They treat each telemetry ping in isolation A single GPS coordinate that places a delivery truck in the middle of a lake looks like one slightly weird record. A single fuel reading that drops three percent looks like noise. But each of these is part of a sequence – what happened before, what’s happening around it geographically, and what the same vehicle was doing on the same route last week. Without that spatial and temporal context, the signal that matters may never surface. They don’t see the new data layer at all Connected and autonomous fleets generate streams that legacy platforms were never designed to validate – computer vision detection logs, model outputs, and perception confidence scores. These streams need their own quality logic: how many objects of a given class the computer vision (CV) stack detected on a route segment today versus yesterday, whether two cameras are producing duplicate detections of the same physical object, or whether model v2.1 has regressed against model v2.0 on a specific stretch of road. Generic platforms don’t ask these questions because they aren’t built to. This is a gap that Action Engine and Wherobots came together to close. Segment-level CV regression caught: model v2.1 reports 39 objects against a baseline of 25, driven by duplicate utility-pole detections. What Aspen Fleet Detects Aspen Fleet ships with a library of over 100 pre-built detection rules tuned specifically for fleet telemetry. Some catch errors in the data itself, while others catch operational anomalies that traditional platforms miss because they lack spatial reasoning. The rules group into a handful of core categories: Location validity: GPS teleportation (a vehicle moving 500 km in two minutes), impossible coordinates (a car “on water” or in a region it was never dispatched to), distance-to-road violations, and GPS drift (a vehicle 80 meters off any drivable surface). Signal integrity: Coordinate freezes, signal loss in tunnels and dead zones, out-of-order timestamps after backfilled resumptions, and hung trackers reporting identical points sequentially. Operational behavior: Idle outliers in unexpected geographies, dwell-time anomalies on familiar routes, and route deviations that only register when historical patterns are known. Sensor envelopes: Fuel consumption, coolant and oil temperature, tire pressure, EV battery state of charge, and signal strength – each validated against expected envelopes per vehicle, per route segment, and per device class. Computer vision and perception outputs: Detection counts per route segment, duplicate detections across cameras, and model performance comparisons between deployed software versions on the same physical road segment. The unifying capability is that none of these checks rely on uniform thresholds. They reason about the geography, the route segment, the device history, and the temporal pattern simultaneously. Uniform thresholds are where generic platforms produce false positives and noisy dashboards, while Aspen prioritizes accuracy. Furthermore, when a fleet has its own operational logic that the pre-built library doesn’t cover, customers can easily author custom checks using the same engine. Two Modes: Historical and Near-Real-Time Fleet Observability Aspen Fleet runs in two complementary modes Historical Anomaly Detection Historical anomaly detection can process years of stored fleet telemetry at scale to find systematic anomalies, retroactively label bad records, and produce a clean baseline that analytics and downstream models can stand on. This is where Aspen is unusually strong. Fleet operators sit on years of telemetry that nobody fully trusts the time or compute to validate it at scale was previoulsy unreachable. Analytics built on that data inherit its noise: KPIs drift, utilization metrics misrepresent reality, maintenance forecasts are anchored on contaminated baselines, and any machine learning model trained on the data inherits whatever errors were hidden within it. Aspen processes historical datasets at scale with Wherobots distributed spaital compute to find systematic anomalies, retroactively label bad records, and produce a clean baseline that analytics and downstream models can actually stand on. The output isn’t just a list of errors – it’s a measurably more accurate version of the fleet’s own history. Near-Real-Time Anomaly Detection Near real-time anomaly detection runs continuously on streaming telemetry, surfacing anomalies within minutes so fleet operations can act before slow-developing patterns become incidents. This mode runs continuously as telemetry streams in. Aspen sees ping sequences in near-real time, applies the same spatial-context-aware checks to streaming data, and surfaces anomalies within minutes of the event that caused them. Fleet operations teams can act on these alerts before a slow-developing pattern – a fuel system slowly degrading, a sensor drifting out of calibration, a route consistently underperforming, or a CV model regressing on a specific stretch of road – turns into a vehicle off the road or a bad decision in production. The combination matters. Historical analysis tells the team what they’ve been missing, while real-time analysis makes sure they stop missing it going forward. Surfacing issues earlier, helping teams understand what actually requires action The practical consequence of spatial-context-aware detection is that Aspen catches anomalies that classical fleet tools surface days or weeks later – if at all. For example: Fuel System Degradation: A fuel system degrading over weeks shows up as a small, slowly widening gap between expected and observed consumption on specific route segments. A global threshold misses it. Aspen sees the drift early because its baseline is segment-specific. Brake-System Issues: This shows up as a subtle change in deceleration patterns at specific intersections the vehicle drives repeatedly. A generic “harsh braking” alert miscalibrated for the fleet either fires constantly or never fires at all. Aspen flags the change because it knows what normal looks like at this specific intersection for this specific vehicle. Perception Stack Decay: A computer vision model degrading shows up as a gradual drop in detection counts or confidence on familiar route segments, often caused by sensor obstruction, a degrading camera, or environmental shifts. Generic fleet platforms don’t see this at all because they don’t process perception outputs. Aspen flags it by comparing detections segment-by-segment and day-over-day. Underutilization: An underutilized vehicle shows up as a pattern of idle outliers in non-operational geofences combined with reduced route variation. Most fleet platforms surface neither signal cleanly. Aspen combines them into a single readable indicator. This is what “surfacing issues earlier” actually means in practice: anomalies that mature into equipment failure, vehicle breakdown, inefficient utilization, or a degraded perception stack get caught while they’re still “drifts” – not after they’ve become costly incidents. How Aspen Fleet Runs at Scale The Infrastructure Behind the Insight To analyze complex spatial and temporal data at scale, you need a new kind of architecture. Aspen Fleet is cloud-native, utilizing the high-performance distributed spatial compute platform provided by Wherobots. Wherobots provides the underlying engine that makes spatial data a first-class citizen. Because of this powerful foundation, historical scans across billions of telemetry records are complete in minutes, while streaming checks seamlessly keep pace with the highest-volume fleets in production today. Data integration is built to be frictionless. Customers can connect their data through whatever channel best suits their architecture – whether that means leveraging existing Geotab and telematics platforms, custom REST endpoints, batch dumps to cloud object storage, or live gRPC feeds directly from on-board vehicle systems. Aspen Fleet and Wherobots handle the ingestion, normalization, and processing automatically. The Takeaway: Fleet Observability Needs Spatial Context The fleets that will win the next decade – the ones that are measurably more cost-effective, more sustainable, and increasingly autonomous – are the ones that can read and act on their own data accurately. Most fleet management platforms answer the basic question: “Where is the fleet?” Aspen Fleet answers a much harder, more valuable question: “What is going wrong, and how early can we catch it?” The combination of deep spatial context, dual historical and real-time processing modes, a validation library tuned for modern perception outputs, and an engine built for massive scale changes the paradigm of fleet operations. Don’t run a fleet you only hope is healthy, run one you can prove is. Live demo with the teams behind Aspen Fleet and Wherobots Join us on Tuesday, August 18 at 9AM PT / 12PM ET. See Fleet Observability in Action Save Your Seat Frequently Asked Questions Why do generic fleet management platforms miss telemetry anomalies? They apply a single threshold for the entire fleet and treat each ping in isolation. They were not built to validate computer vision detection logs, model outputs, or perception confidence scores.A fuel value that is anomalous on a flat highway can be normal on a mountain pass. A single lake-coordinate GPS ping looks like noise until it is seen as a sequence with spatial and temporal context. What does Aspen Fleet detect? More than 100 pre-built rules. They cover location validity, signal integrity, operational behavior, sensor envelopes (fuel, coolant and oil temperature, tire pressure, EV battery state of charge), and CV/perception outputs.CV/perception checks include detection counts per route segment, duplicate detections across cameras, and model-version comparisons on the same road segment. One example: model v2.1 reported 39 objects against a baseline of 25, driven by duplicate utility-pole detections. What is the difference between historical and near-real-time fleet observability? Historical detection processes years of stored telemetry to find systematic anomalies, retroactively label bad records, and produce a clean baseline for analytics and models. Near-real-time detection runs continuously on streaming telemetry and surfaces anomalies within minutes so operations can act before a slow-developing pattern becomes an incident. How does Aspen Fleet use Wherobots? Aspen is cloud-native on Wherobots distributed spatial compute. Historical scans across billions of telemetry records complete in minutes, and streaming checks keep pace with high-volume production fleets. Wherobots makes spatial context a first-class signal rather than a post-hoc join. --- ## Introducing the Wherobots Innovation Edition, designed to accelerate your physical world objectives  URL: https://wherobots.com/blog/introducing-the-innovation-edition/ Updated: 2026-10-19 The Wherobots Innovation Edition helps you deliver outcomes on top of spatial data that propel your organization forward, and make this data AI-ready.Today we are announcing the Wherobots Innovation Edition. This is an annual partnership that pairs the full Wherobots Cloud platform with our forward deployed spatial engineering expertise, developed over years of delivering solutions, supporting production workloads, and leading the Apache Sedona project. Key takeawaysThe Innovation Edition is an annual partnership that pairs the full Wherobots Cloud platform with forward-deployed spatial engineering expertise. That expertise comes from years of production workloads and leading the Apache Sedona project.The offering exists because private arrangements combining that expertise with the product have repeatedly delivered for customers. It gives a direct, on-demand way to access distinguished spatial data experts to accelerate outcomes and make spatial data AI-ready.Wherobots is not opinionated about which cloud you run: the post states solutions can thrive in AWS, GCP, Azure, Databricks, and Snowflake. Action Engine CEO Sergey Sukov is quoted on using the innovation tier to treat spatial context as a first-class signal in production against high-volume Aspen Fleet workloads.Engagement is a lightweight qualification: a 30-minute call, alignment on path (guide, ship insights, or both) with timelines, milestones, proof of value, and architecture, then subscribe. Progress is reviewed weekly or bi-weekly, with quarterly business reviews. We are announcing the Innovation Edition out of ongoing demand. The combination of our expertise in building geospatial data pipelines for production environments, and the Wherobots product has repeatedly delivered success for companies in private arrangements. It gives you a direct way to access our team of distinguished spatial data experts, on demand, to accelerate the realization of your goals. The Innovation Edition is built for one job, which is helping you ship outcomes while making spatial data ready for AI. As a result:  Risk models are fresh, have more coverage, are more precise, and drive more of the right actions Services, supply chains, and logistical operations can improve continuously Threats to physical ecosystems and supply chains can be mitigated before they cause harm World models improve on the back of higher quality, more complete context CapEx heavy investments can produce higher returns Agriculture and forest management practices are more efficient We have proven to customers that AI is already capable of co-piloting these and other innovative, physical-world solutions when it has access to the right context. We have successfully delivered on multiple mission-critical engagements where customers relied on our team to remove roadblocks and deliver outcomes on schedule, and relied on our product to deliver outcomes with data. We are not opinionated on what cloud offering you’re using. Need solutions to thrive in AWS, GCP, Azure, Databricks, and Snowflake? No problem. Wherobots is designed to bring its capabilities into these environments.  Here is what one of our customers, Sergey Sukov at Action Engine has said about working with Wherobots and leveraging the innovation tier. We made this offering public due to customers and partners like Action Engine. Wherobots has been more than infrastructure for us. Their team helped us design a system that treats spatial context as a first-class signal, and their engine runs it reliably in production against the highest-volume fleets running with Aspen Fleet. That combination of product and expertise is why our fleet data is ready for the AI stack our customers depend on. Sergey Sukov CEO, Action Engine Is the Innovation Edition right for you? The Innovation Edition fits your team if you: Have widespread interest and investment in the physical world, and need data driven approaches to understand risk and opportunities Want to unleash the potential of AI on spatial data, using the existing data estate you have hosted on Databricks, AWS, Google, Azure, or Snowflake  Want to build competency and ownership of your spatial data workflows rather than outsource them Need solutions fast, regardless of data scale, complexity, and data type How engagement works Qualification for the Innovation Edition is a lightweight, no-risk process. It is designed to quickly assess whether we are the right partner for your objectives.  1. Reach out. We will schedule a 30-minute call to learn about your objectives and technical requirements. 2. Align on the path forward. We can guide your team, ship insights into your environment, or both. We will respond with the path forward, including timelines, milestones, a proof of value, and architecture. A follow-up call or POC can follow, as required. 3. Subscribe. Once there is mutual alignment, you subscribe to the Innovation Edition and the engagement begins. We will co-build the engagement plan with you and how it will grow over time.  4. Innovate Together. We help you define the objectives and key results that we are achieving together, the technical path to bring results into production, and co-build with you. We will review progress with your team regularly on a weekly or bi-weekly basis, and conduct quarterly business reviews to ensure you are successful. If you want to get started with an initial discovery call, reach out to us to discuss next steps and building together as a team.  Frequently Asked Questions What is the Wherobots Innovation Edition? An annual partnership that pairs the full Wherobots Cloud platform with forward-deployed spatial engineering expertise. The job of the edition is helping customers ship outcomes while making spatial data ready for AI. Who is the Innovation Edition for? Teams with investment in the physical world who need data-driven approaches to risk and opportunity. Teams that want to use AI on spatial data already hosted on Databricks, AWS, Google, Azure, or Snowflake.Teams that want to build competency and ownership of spatial workflows rather than outsource them. Teams that need solutions fast regardless of data scale, complexity, and type. Does Innovation Edition require a specific cloud? No. The post states Wherobots is not opinionated on cloud offering. Solutions can thrive in AWS, GCP, Azure, Databricks, and Snowflake, bringing Wherobots capabilities into those environments. How does an Innovation Edition engagement start? Qualification is a lightweight, no-risk process. Reach out for a 30-minute call on objectives and technical requirements, then align on timelines, milestones, a proof of value, and architecture.Subscribe once there is mutual alignment. Then co-build OKRs and the path to production, with weekly or bi-weekly reviews and quarterly business reviews. --- ## Spatial Data in Apache Iceberg: Optimizations and Management That Matter URL: https://wherobots.com/blog/apache-iceberg-spatial-data/ Updated: 2026-10-19 Spatial data in Apache Iceberg needs different optimization than tabular data. A geometry column has no natural sort order, so unsorted files carry wide, overlapping bounding boxes and query planners cannot prune them… At all… This behaviour turns a selective spatial filter into a full table scan. A second problem compounds it: one oversized geometry inflates a whole file’s bounding box, so even well-sorted tables lose pruning when large and small shapes share a file. Optimizing Iceberg for spatial data means addressing both, then tuning file size, partitioning, and snapshot retention to the realities of geometry. Key takeawaysA geometry column has no natural sort order. Unsorted files carry wide, overlapping bounding boxes, so a selective ST_Intersects filter becomes a full table scan at the data-file level.Iceberg geometry support arrived in v3. Optimizing spatial Iceberg means addressing sort order and oversized-geometry bbox inflation, then tuning file size, partitioning, and snapshot retention.Hilbert on the geometry column is the recommended default when spatial range queries dominate. Neighboring points stay neighbors, so per-file bounding boxes are tighter, and resolution 10–14 covers most national-scale use cases.Z-order is lowest-friction (no schema change) but has quadrant-boundary discontinuities. Pre-computed S2 or H3 integer columns let stage-3 min/max pruning work without geometry-specific logic.Standard Iceberg file sizing (128–512 MB) assumes uniform row sizes. GPS points are roughly 21–28 bytes, building footprints might average 500 bytes, and mixed types can vary by three orders of magnitude.For dense polygon datasets, 128–256 MB is more appropriate than 512 MB. Coarse spatial partitioning (H3 r3–r4, state, UTM zone) plus fine sort within partitions outperforms fine-grained partitioning alone.One large geometry can inflate a whole file’s bounding box and destroy pruning. Isolate Big Freaking Geometries with an is_bfg partition flag rather than UNION ALL across two tables.Snapshot retention should match change rate: 7–30 days for GPS/streaming, ~60 days for weekly POI, and 1–2 years with named tags for quarterly road networks. Jonathan Saring recently published an excellent guide on optimizing Apache Iceberg for analytics workloads covering the four-stage query planning pipeline, file sizing, compaction sequencing, delete-file economics, and metadata lifecycle management. It’s outstanding and if you’ve not read it, start there. It’s one of the more complete discussions of the subject I’ve come across, I’m gonna build directly on that foundation for the rest of this post, so again start here. Now, what it doesn’t cover (because it isn’t its focus) is what happens when your data has a geometry column (Iceberg got geometry support as of v3!!). Geospatial data breaks several of the assumptions that make standard Iceberg optimization work (as others for typical data science, but that’s for a future post), introduces failure paths that don’t exist in the tabular world, and requires a few decisions that have no equivalent in conventional Iceberg guidance. That’s what this post is about. How Iceberg Plans a Query (and Why Geometry Breaks It) To understand why geometry requires different treatment, it helps to have the query planning pipeline clearly in mind. Saring’s article lays this out well, so I’ll regurgitate and summarize the stage, then focus on where spatial data diverges. Before your query engine reads a single Parquet byte, Iceberg executes a metadata-only pipeline: Stage 1: Snapshot resolution. The engine contacts the catalog to locate the current metadata file and resolve the active snapshot. Constant-time, O(1) catalog calls regardless of table size. If you are using a catalog service (Glue, REST (This is what we use at Wherobots), Nessie, etc) this process is handled at that layer. If you are using Hadoop or a file system approach, this step simply evaluates the version-hint.txt file to resolve the snapshot. Stage 2: Manifest-list pruning. The snapshot points to a manifest list. Each entry carries partition-level summary statistics—min and max values—that let the engine skip entire manifest files before reading any data. This is the highest-leverage pruning stage; production measurements show it eliminating 99%+ of partitions before any per-file work begins. Stage 3: Per-file data skipping. For surviving manifests, the planner reads per-file column statistics—min, max, null count—for each data file. Files whose column ranges can’t overlap the query predicate are skipped. This is where sort order pays off: sorted files have tight bounds, unsorted files have wide overlapping ranges that can’t be pruned. Stage 4: Row-group filtering. Inside each surviving Parquet file, row-group statistics and Bloom filters perform one final pass. Tight sort order within files makes row-group boundaries meaningful. Geometry breaks stages 2 and 3. A geometry column doesn’t have a natural total ordering. There’s no inherent way to sort shapes in two-dimensional space the way you sort integers or timestamps. An unsorted file containing geometries spread across a region has a bounding box spanning that entire region. A WHERE ST_Intersects(geom, ...) predicate for any subregion cannot eliminate files or rows. Without spatial ordering, the planner touches every file. Every query becomes a full table scan at the data-file level regardless of how selective your spatial filter is. Several options for spatial sorting are discussed below. Spatial Sorting in Apache Iceberg: Z-Order, Hilbert, S2, and H3 Z-Order on the Geometry Column Iceberg’s native ZORDER BY applies a Morton code (Z-order) curve by interleaving the binary representations of latitude and longitude. It’s the lowest-friction option—no schema changes and no pre-computed columns since IcebergV3 already stores the geometry in the WKB (Well Known Binary)… Just a compaction call. CALL wherobots.system.rewrite_data_files( table => 'wherobots.basemap.roads', strategy => 'sort', sort_order => 'zorder(geom)' ); Z-order’s weakness is boundary discontinuities: geometries that are physically adjacent can end up far apart in Z-order if they straddle a quadrant boundary. For continental or global datasets, this meaningfully reduces pruning effectiveness in certain regions. As Saring notes for tabular Z-order, it provides balanced multi-dimensional skipping but is less tight per axis than a pure single-column sort—the same tradeoff applies spatially. For spatial data with a dominant query window, prefer Hilbert. Hilbert Curve on the Geometry Column The Hilbert curve doesn’t have Z-order’s boundary problem, and is why Wherobots implements this directly with easy to use syntax). Neighboring points on the earth stay neighbors along the Hilbert index, which means per-file bounding boxes are tighter and pruning is more effective for range queries, bounding box filters, and point-in-polygon lookups. -- Havasu / WherobotsDB spatial index syntax CREATE SPATIAL INDEX FOR wherobots.basemap.buildings USING hilbert(geom, 12); The resolution parameter controls the trade-off between locality preservation and index cardinality. For national-scale datasets, resolution 10–14 covers most practical use cases. Below 10 you lose locality within cells; above 14 you hit diminishing returns. For datasets where spatial range queries dominate, Hilbert on the geometry column is the right default—the spatial equivalent of sorting a fact table on its primary filter column. S2 and H3 Index Columns S2 (Google’s spherical geometry library) and H3 (Uber’s hexagonal grid) take a different approach: pre-compute a discrete cell identifier and sort or partition on that integer column. This has a meaningful advantage over sorting on geometry directly since the column statistics work perfectly on integers, so min/max pruning at stage 3 functions without any geometry-specific logic. I frequently see these tessellation used as mapping or reporting units, prefect for analytic workloads. from sedona.sql.st_functions import ST_S2CellIDs, ST_H3CellIDs # Add an S2 index column at level 13 (~1km cells) df = df.withColumn("s2_index", ST_S2CellIDs("geom", 13).getItem(0)) df.sortWithinPartitions("s2_index") \ .writeTo("wherobots.basemap.poi") \ .tableProperty("write.distribution-mode", "range") \ .createOrReplace() H3 has additional advantages: uniform cell area at each resolution and a clean hierarchy, which makes it well-suited for zoom-level-aware queries and aggregation pipelines. If downstream consumers already work with H3 for analytics or ML feature extraction, sorting on H3 gives you alignment between storage layout and query patterns at no extra cost. Practical choice: If you’re doing heavy H3 analytics, add an H3 column and sort on it. If you want zero-configuration improvement with no schema changes, Hilbert on the geometry column is a strong default. Z-order is appropriate when your spatial access patterns span multiple dimensions simultaneously—similar to the tabular case where Z-order beats single-column sort when two dimensions are equally important in predicates. The Cost of Re-Sorting a Spatial Iceberg Table: Treat It Like Schema Design Here’s something the general Iceberg optimization literature glosses over because it matters less for tabular data: changing your sort order is expensive, and for spatial tables it’s very expensive. For a tabular fact table, resorting on a new column is a full data rewrite—costly, but tractable. You compact the table with the new sort order and the old layout is gone. The only real question is whether you can afford the compute time and the brief period of stale statistics. For a spatial table, resorting is functionally equivalent to rebuilding a spatial index from scratch. Every geometry is re-evaluated, re-projected onto the new curve, and re-sorted. For a national-scale polygon dataset—say, a building footprint table with 500 million rows and non-trivial geometry complexity—a full resort can take hours and cost real money. If you chose H3 resolution 7 as your sort key and your access patterns turn out to favor resolution 5, fixing that is not a quick compaction job. This has a practical implication: choose your spatial sort strategy the same way you choose a schema—deliberately, with input from downstream consumers, and with the expectation that changing it later is a significant operation. Before committing, run the analysis recommended for tabular sort keys: pull representative query patterns, understand the dominant spatial filter resolution, and prototype. With Iceberg’s branch support, you can test a resort on a table branch before committing to the full rewrite: -- Create a branch for testing ALTER TABLE wherobots.basemap.buildings CREATE BRANCH hilbert_test; -- Resort a sample partition on the branch CALL wherobots.system.rewrite_data_files( table => 'wherobots.basemap.buildings', branch => 'hilbert_test', where => 'h3_region = 617700169518678015', -- single partition strategy => 'sort', sort_order => 'hilbert(geom, 12)' ); -- Compare bytes scanned and planning time against production branch -- before committing to the full table rewrite A few additional realities: Resolution changes require full rewrites. Switching from H3 resolution 7 to resolution 5 isn’t an incremental operation—every row needs a new cell ID computed and re-sorted. If you’re using an H3 column as your sort key, make sure the resolution is appropriate for your finest-grained query window before you write the first row. Mixed sort strategies don’t compact cleanly. If you have some partitions sorted by H3 and others by Hilbert (from a strategy migration), compaction across partitions won’t produce a coherent global sort order. A full resort is the only clean path. Compaction cadence affects sort decay. Streaming ingest writes small, unsorted files. Even after initial sorting, continuous ingest degrades the spatial locality of files over time as new micro-batch files land with arbitrary geometry ordering. Budget for regular spatial sort compaction—not just binpack compaction—on tables that receive continuous updates. -- Schedule sort compaction for streaming-ingest spatial tables -- more frequently than you would for tabular tables CALL wherobots.system.rewrite_data_files( table => 'wherobots.analytics.gps_events', strategy => 'sort', sort_order => 'zorder(geom)', options => map( 'rewrite-all', 'false', -- only rewrite files below size target 'target-file-size-bytes', '134217728' -- 128 MB ) ); File Size for Spatial Iceberg Tables: Where Geometry Breaks Standard Guidance The standard Iceberg file sizing guidance targets 128–512 MB per Parquet file. That guidance assumes relatively uniform row sizes. Geometry columns violate this assumption dramatically. A table of GPS points has geometry values of roughly 21–28 bytes per row. Building footprints might average 500 bytes per polygon. A table with mixed geometry types—parcel boundaries, road centerlines, administrative areas—can have row sizes varying by three orders of magnitude. A file that “should” be 256 MB by row count might actually be 2 GB if those rows contain dense multi-polygons. The same principle that makes small files expensive for tabular analytics—each file requires at least one GET to read its Parquet footer during planning, plus additional GETs for column chunks—applies here. But the inverse problem is also real for spatial: oversized files from complex geometry reduce parallelism and create memory pressure during spatial joins. In practice: Profile your geometry complexity distribution before setting compaction targets. ST_NumPoints gives you vertex counts; use percentiles to understand your tail: sedona.sql(""" SELECT PERCENTILE(ST_NumPoints(geom), 0.5) AS p50_vertices, PERCENTILE(ST_NumPoints(geom), 0.95) AS p95_vertices, PERCENTILE(ST_NumPoints(geom), 0.99) AS p99_vertices, AVG(ST_NumPoints(geom)) AS avg_vertices FROM wherobots.basemap.parcels """).show() Reduce the byte target from the Iceberg default for tables with complex or heterogeneous geometry—128–256 MB is more appropriate than 512 MB for dense polygon datasets. Monitor actual Parquet file sizes post-write rather than relying on Spark’s write estimates, which don’t account for geometry serialization overhead. For raster tables, tile size via RS_TileExplode is the equivalent decision: it determines the granularity at which spatial filter pushdown operates and the parallelism available during processing. Partitioning Spatial Data in Apache Iceberg The core partitioning principle from the general Iceberg playbook applies directly: partition by the column that appears in the WHERE clause of the majority of your queries. For spatial data, that is almost always some form of spatial or thematic bucket, e.g. a coarse S2 cell, an H3 region, a country or state code, or a UTM zone identifier. Remember it’s best to use low cardinality columns as too many partitions can have negative impacts. # Partition a national POI table by H3 resolution 3 (~regional level) df.withColumn("h3_region", ST_H3CellIDs("geom", 3).getItem(0)) \ .writeTo("wherobots.analytics.poi") \ .partitionedBy("h3_region") \ .createOrReplace() For data that is both spatially and temporally filtered, like satellite-derived products, observation data, and event telemetry with coordinates for example, compound partitioning on time and space is the right call: CREATE TABLE wherobots.analytics.ndvi_observations ( observation_date DATE, geom GEOMETRY, ndvi DOUBLE, h3_region BIGINT ) USING iceberg PARTITIONED BY (months(observation_date), h3_region); The over-partitioning trap is especially acute for spatial data. Fine-grained spatial partitioning—H3 resolution 8 instead of 3—produces enormous partition counts with very few files per partition, increasing manifest scanning overhead without proportional pruning benefit. Prefer coarse partitioning with fine-grained sort within partitions over fine-grained partitioning alone. Why Large Geometries Break Bounding Box Pruning This is the failure mode that breaks stage 3 pruning most severely, and the one that has no parallel in tabular data. Iceberg stores per-column min/max statistics in each data file’s manifest entry. For a geometry column, this translates to a bounding box—the minimum and maximum X and Y coordinates across all geometries in that file. The query planner uses this to skip files whose bounding box doesn’t intersect the query’s spatial filter. The problem: a single large geometry can inflate the bounding box of an entire file. A national boundary polygon, a major river system, a large administrative region—any of these has a bounding box spanning hundreds or thousands of kilometers. If that geometry lands in a file alongside small, local geometries, the file can no longer be skipped for almost any spatial query over the region. The planner sees a file with a bounding box covering six states and has to open it for every query touching those states, even queries looking for points in a single city. This is not a theoretical edge case. The Fix: Isolate Large Geometries with a BFG Partition Flag A simple approach is to write large and small geometries to separate tables and union them at query time. Don’t. A UNION ALL across two differently-partitioned tables causes Spark to reconcile partition counts across both sides, which either triggers an expensive shuffle or produces a badly skewed stage depending on how your engine handles it. Keep everything in one table. Instead, classify geometries by bounding box extent before writing and add an is_bfg partition column—a simple integer flag that segregates Big Freaking Geometries into their own partition. The BFG partition loses pruning effectiveness at the file level, but it’s small, fast to full-scan, and critically, it contains the bbox metadata damage so normal geometry partitions stay clean. from sedona.sql.st_functions import ST_Area, ST_Envelope from pyspark.sql.functions import col, lit, when # BFG_THRESHOLD is relative to your typical query window, not an absolute value. # For a national dataset queried at city scale, 0.01 degrees² is a reasonable start. # Document this as a table-level constant — don't let it become a magic number. BFG_THRESHOLD = 0.01 # degrees² df = df.withColumn("bbox_area", ST_Area(ST_Envelope("geom"))) \ .withColumn( "is_bfg", when(col("bbox_area") >= lit(BFG_THRESHOLD), lit(1)).otherwise(lit(0)) ) # Sort within partitions by spatial index — apply to both partitions. # BFG sort still helps at stage 4 row-group level even if stage 3 file pruning is weak. df.sortWithinPartitions("is_bfg", "s2_index") \ .writeTo("wherobots.basemap.admin") \ .partitionedBy("is_bfg", "h3_region") \ .createOrReplace() At query time, nothing special is required. The query planner handles both partitions transparently—spatial predicates that eliminate the BFG partition entirely will do so via partition pruning, and queries that touch it will full-scan a small, bounded set of files. SELECT * FROM wherobots.basemap.admin WHERE ST_Intersects(geom, ST_GeomFromText('POLYGON ((...))')) A few things to keep in mind once is_bfg is in production:The threshold is load-bearing and should be defined relative to your typical query window. A geometry that qualifies as BFG in a city-scale dataset is completely normal in a continental one. If the threshold is wrong for a given dataset, geometries get miscategorized silently and pruning degrades without any obvious error signal. Make it a documented constant at minimum; a table property if your pipeline supports it. The flag is sticky through compaction and updates. If geometries change over time—administrative boundaries being simplified, coastlines refined—a shape that started as BFG may no longer qualify after an edit. Budget for a periodic reclassification job that uses MERGE INTO to move geometries between partitions when their bbox area crosses the threshold in either direction. The BFG partition still needs a spatial sort. It’s tempting to skip it since file-level pruning is already compromised there, but for global datasets where the BFG partition can grow to include every national boundary, major river system, and ocean polygon, an unsorted BFG partition becomes a meaningful full scan. Hilbert or S2 sort within the BFG partition still tightens row-group statistics at stage 4 and is worth the compaction cost. The principle throughout: any geometry whose bounding box spans more than a few percent of your typical query window is a pruning liability—isolate it, don’t let it contaminate the metadata of the geometries around it. Snapshot Retention: Matching Policy to Data Change Rate Every Iceberg table operation creates a new snapshot. Every. Single. One. Just like traditional RDBMS where we periodically manage our tables, we need to do the same for our snapshots. Saring’s article recommends retaining snapshots for your audit and time-travel SLA—typically 7–30 days for analytics tables, then expiring aggressively. That’s the right default for event-driven data. But geospatial tables span a much wider range of change rates, and the right retention policy differs significantly between them. It helps to think in three categories. Fast-Changing Layers: Streaming and Event Data GPS telemetry, real-time traffic observations, sensor feeds, and other continuously-updated spatial tables behave like any high-ingest tabular table. Default Iceberg retention (7–30 days) is appropriate. The priority here is aggressive snapshot expiration to prevent manifest list bloat and unblock garbage collection of old data files. -- GPS telemetry: expire quickly, keep only operational window ALTER TABLE wherobots.analytics.gps_events SET TBLPROPERTIES ( 'history.expire.max-snapshot-age-ms' = '604800000', -- 7 days 'history.expire.min-snapshots-to-keep' = '5' ); The compaction concern for fast-changing spatial tables is sort decay. Streaming ingest writes small, unsorted files. Even if the table was initially sorted by Hilbert or H3, continuous micro-batch appends degrade spatial locality over time. Fast-changing spatial tables need more frequent sort compaction than their tabular equivalents—not just binpack consolidation. Moderate-Cadence Layers: POI, Addresses, Administrative Units Point-of-interest datasets, address databases, and delivery zone boundaries typically update weekly to monthly. These warrant a medium retention window—enough to support rollback and short-horizon time travel, but not indefinite. -- Weekly-updated POI layer: 60-day retention ALTER TABLE wherobots.analytics.poi SET TBLPROPERTIES ( 'history.expire.max-snapshot-age-ms' = '5184000000', -- 60 days 'history.expire.min-snapshots-to-keep' = '12' -- ~3 months of weekly updates ); Slow-Changing Base Layers: Road Networks, Land Cover, Imagery Products Road networks update quarterly. Administrative boundaries update annually, sometimes less. Land cover classifications might be refreshed once per product release cycle. And their historical versions remain analytically relevant far longer than their update frequency suggests. A transportation analyst querying 2022 road data against 2024 trip records needs the 2022 snapshot to still exist. Default expiration will quietly delete it. -- Road network updated quarterly: retain at least 2 years ALTER TABLE wherobots.basemap.road_network SET TBLPROPERTIES ( 'history.expire.max-snapshot-age-ms' = '63072000000', -- 2 years 'history.expire.min-snapshots-to-keep' = '8' -- ~2 years of quarterly updates ); For base layers, named snapshot tags are essential. Age-based expiration and named references are independent—a tagged snapshot won’t be deleted by expiration policy. Tag releases at the time of publication: ALTER TABLE wherobots.basemap.road_network CREATE TAG `2024-Q4-release` AS OF VERSION 42; This lets analysts and pipelines refer to a specific basemap vintage by name rather than timestamp, without depending on a snapshot being young enough to survive the expiration window. Decouple compaction from expiration, and sequence them correctly. As Saring’s maintenance ordering makes clear: expire snapshots first, remove orphan files, then compact, then rewrite manifests, then compute statistics. Compacting before expiration wastes compute on files about to be garbage-collected. For slow-changing base layers, this sequence is especially important because the update windows are so infrequent—a mis-sequenced maintenance run on a quarterly table has a three-month blast radius. Consider separating canonical from delta for frequently-edited layers. If your basemap has an infrequently-updated authoritative version plus a more rapidly-updated change layer (new construction, edit accumulation, QA outputs), store them in separate tables with separate retention policies. The canonical base gets long retention; the delta layer gets standard retention. Queries union at read time. This approach also alleviates the large geometry problem: large administrative geometries in the canonical base are isolated from point and line edits in the delta. Apache Iceberg Spatial Data: Configuration Reference ConcernRecommendationNotesSort orderHilbert on geom, or H3/S2 integer columnH3/S2 if downstream analytics already uses those indexes; Z-order for multi-dimensional access patternsResortingTreat like schema redesign; prototype on a branch firstResolution changes require full rewrites; budget accordinglyFile size targetProfile geometry complexity; reduce byte target for complex polygons128–256 MB for dense polygon datasets; monitor actual Parquet sizes post-writePartitioningCoarse spatial bucket (H3 r3–r4, state, UTM zone) + temporal if applicableDon’t over-partition; coarse partition + fine sort outperforms fine-grained partitioning aloneLarge geometriesSeparate file or separate table; never mix with small geometriesThreshold is relative to your typical query windowRetention: fast-changing7–30 days; expire aggressively; prioritize sort compaction frequencySort decay from streaming ingest is the primary spatial concernRetention: moderate60–90 days; keep enough for rollback and short time-travelWeekly-to-monthly update cadenceRetention: slow-changing1–2 years; use named tags for versioned releasesDecouple compaction and expiration schedules per tableMaintenance orderExpire → orphan cleanup → compact → rewrite manifests → compute statsSame sequence as tabular; cadences differ sharply by layer type Spatial Layout Sets the Performance Ceiling The performance ceiling of a spatial Iceberg lake is not the query engine—it’s the physical state of the tables. That’s true for tabular data too, but spatial adds a dimension that makes the penalties for getting it wrong steeper and less visible. A poorly-sorted tabular table is slow. A spatial table with unsorted geometry and mixed large geometries produces full-scan behavior even for highly selective spatial filters, and does it silently—the query doesn’t fail, it just reads everything. Choose your spatial sort strategy deliberately, because resorting at scale is expensive. Profile geometry complexity before setting file size targets. Isolate large geometries before they poison your pruning metadata. And set snapshot retention per table type—because the data that barely changes is often the data someone needs most when querying the past. This post builds on Jonathan Saring’s Iceberg Lake for Analytics Data: A Guide, published in ITNEXT. The four-stage planning pipeline, file sizing principles, and maintenance sequencing described there are the foundation for the spatial-specific extensions covered here. Spatial implementations use Wherobots’ Havasu spatial lakehouse, built on Apache Iceberg and Apache Sedona. Try Wherobots for Free START BUILDING Frequently Asked Questions Why does spatial data break Apache Iceberg query planning? Iceberg’s four-stage planner relies on min/max statistics. Geometry has no total order, so an unsorted file’s bounding box spans the whole region and ST_Intersects cannot skip files. A second failure mode: one oversized geometry inflates a file’s bbox, so even a well-sorted table loses pruning when large and small shapes share a file. Should I use Z-order, Hilbert, H3, or S2 to sort Iceberg geometry? Hilbert on the geometry column is the right default for spatial range queries, bounding-box filters, and point-in-polygon lookups; Wherobots implements it with CREATE SPATIAL INDEX … USING hilbert(geom, 12). Use an H3 or S2 integer column if downstream analytics already use those indexes, because integer min/max pruning works at stage 3 with no geometry-specific logic. Z-order is the lowest-friction option when you cannot change schema, but quadrant-boundary discontinuities reduce pruning on continental datasets. How do large geometries break Iceberg bounding-box pruning? Iceberg stores per-file min/max as a bounding box. A national boundary, major river, or large admin region can span hundreds or thousands of kilometers. If it lands in a file with small local geometries, the planner cannot skip that file for almost any query over the region.The fix is an is_bfg partition flag that isolates those shapes so normal partitions stay clean. Do not UNION ALL two differently partitioned tables. What snapshot retention should I use for geospatial Iceberg tables? Match policy to change rate. Fast-changing GPS/sensor tables: 7–30 days, expire aggressively, and budget extra sort compaction because streaming ingest degrades spatial locality. Moderate POI/address layers: about 60 days.Slow-changing road networks and land cover: 1–2 years, with named snapshot tags so a 2022 basemap still exists when analysts need it. Expire snapshots before compacting. Is changing spatial sort order expensive on Iceberg? Yes. For a spatial table, resorting is functionally equivalent to rebuilding a spatial index. A national building-footprint table with 500 million rows can take hours.Treat sort strategy like schema design, and prototype on an Iceberg branch before a full rewrite. Switching H3 resolution requires computing a new cell ID for every row. --- ## Spatial Graph RAG for the Physical World URL: https://wherobots.com/blog/spatial-graph-rag/ Updated: 2026-10-19 Introduction RAG (Retrieval Augmented Generation) has addressed one of AI’s biggest challenges for enterprise users: missing or hallucinating empirical business and real world context . Instead of generating answers from nothing, RAG retrieves relevant documents and feeds them to the model as context. It works. Ask an AI about your company’s Q4 revenue, and RAG pulls the earnings report before answering. Key takeawaysStandard Graph RAG builds knowledge graphs from text. Spatial Graph RAG builds them from the physical world: containment, proximity, adjacency, and intersection, using spatial SQL instead of NLP.The most consequential physical-world relationships are often not written down.The pipeline is two layers in one WherobotsDB session: distributed spatial SQL materializes node and edge tables into Apache Iceberg, then GraphFrames traverses them (connected components, motif finding, neighborhood expansion). No separate graph database is required.Microsoft Research's GraphRAG paper (Edge et al., 2024) reported 72–83% comprehensiveness win rates versus standard RAG on questions requiring synthesis across entire datasets. GeoLLM (Manvi et al., ICLR 2024) showed that querying an LLM with coordinates alone consistently fails unless structured, map-derived context is provided.You cannot load 2.6 billion Overture building geometries into Neo4j and compute containment with 1.2 billion places. Edge generation at that scale is what WherobotsDB and Apache Sedona are built for.The Overture Maps Foundation itself uses them for monthly global releases. Even in a dense urban area, a retrieved subgraph is typically 10–50 nodes. But RAG has a blind spot. It retrieves documents, flat chunks of text ranked by semantic similarity. It doesn’t understand relationships between assets. It doesn’t know that your VP of Sales reports to the CRO, or that Product A competes with Product B, or that the supplier in Shenzhen feeds the factory in Guadalajara that ships to the warehouse in Memphis. You can leave the connections to be made by the LLM, but seeding control over simple facts to a nondeterministic process is not the best business decision. Graph RAG fixes this by building a knowledge graph of entities and their relationships, then retrieving compact subgraphs, not just documents, as context for the model. It’s one of the fastest-growing concepts in AI infrastructure, and for good reason: it makes AI dramatically better at reasoning about connected information. There’s just one problem. Every Graph RAG implementation today builds knowledge graphs from text, semantics, and ontologies. Documents, wikis, databases, web pages. The relationships are extracted from language. But the most consequential relationships in the physical world aren’t always written down. They’re spatial. Which building contains which addresses . Which buildings area accessible by which road. Which facilities sit inside which flood zone. Which agriculture fields are adjacent to which water sources and who owns those water rights. These relationships exist in geometry, not in sentences… No amount of document retrieval will surface them. This is the case for Spatial Graph RAG: building knowledge graphs from the physical world, using spatial operations instead of NLP, and retrieving spatial relation-anchored subgraphs that ground AI in physical reality. What is Graph RAG? Graph RAG (also written GraphRAG) is a retrieval-augmented generation method that retrieves connected entities and relationships from a knowledge graph and passes them to a large language model as context. It extends standard RAG by adding a knowledge graph layer (nodes and edges) between the raw data and the language model. Standard RAG: User asks a question System searches a vector database for semantically similar text chunks Top-K chunks are injected into the LLM prompt as context LLM generates an answer grounded in those chunks Graph RAG User asks a question System identifies relevant entities (nodes) in a knowledge graph System traverses the graph’s edges and nodes to retrieve a compact subgraph of connected entities, relationships, and provenance Subgraph (entities (the nodes) + relationships (the edges) + evidence (relationship provenance) is injected into the LLM prompt LLM generates an answer grounded in structured, relational context The difference matters. Standard RAG might retrieve three paragraphs that each mention a company name. Graph RAG retrieves the company node, its relationships to subsidiaries, suppliers, competitors, and executives, and the evidence supporting each relationship. The model doesn’t just get text fragments, it gets structured understanding. Microsoft Research’s GraphRAG paper (Edge et al., 2024) demonstrated this dramatically: on questions requiring synthesis across entire datasets, Graph RAG achieved 72-83% comprehensiveness win rates versus standard RAG. Reference: From Local to Global: A Graph RAG Approach to Query-Focused Summarization — Microsoft Research, 2024 The Problem: Why AI Gets Spatial Relationships Wrong Ask a language model “What’s at this address?” or “Is this restaurant inside that building?” or “Which of these two locations is closer to the highway?” and you’ll often get confident, specific, wrong answers. This isn’t a model intelligence problem. It’s a context problem. The model has no spatial context, no understanding of physical relationships between real-world entities. Research bears this out directly. GeoLLM (Manvi et al., ICLR 2024) demonstrated that querying an LLM with geographic coordinates alone consistently fails, even when the model contains relevant geographic knowledge internally. Performance improves substantially only when structured, map-derived context is provided alongside the query. In other words: the problem isn’t that LLMs don’t know about geography , it’s that they can’t use that knowledge without grounded relational structure to anchor it. The root cause goes deeper than missing map data. Place understanding is fundamentally relational: A business is inside a building, which is on a street, which connects to a road network, which is in an administrative boundary An address might match multiple buildings, and the correct assignment depends on access points and proximity to road segments Two POI records might be duplicates, a brand and a venue, or distinct businesses in the same building, and the evidence for each interpretation is spatial A business is accessible via a building that is accessible via a the transportation network who’s navigation is weighted by current traffic load These relationships can be ambiguous, inconsistent across data sources, and impossible to resolve from text alone. This is exactly the problem knowledge graphs solve in the document world and it’s exactly the problem spatial knowledge graphs solve for the physical world. From Graph RAG to Spatial Graph RAG Spatial Graph RAG applies the Graph RAG architecture to physical-world data, using spatial operations instead of NLP to construct the knowledge graph, and location-anchored queries instead of text queries to retrieve subgraphs. The pipeline has three stages. The first two are distinct engineering layers that work in sequence: distributed, transformations, aggregations, data generation, and spatial joins generate the nodes and edges, then graph operations traverse them. Step 1: Generate graph edges with spatial SQL Spark and Spatial SQL comprise the graph creation factory. Using WherobotsDB‘s spatial functions on Overture Maps data, we materialize node and edge tables into Apache Iceberg. Each edge carries provenance whether it was asserted by a source dataset, derived by a spatial join, or scored based on multiple signals . Containment edges (place → in building): containment_edges = sedona.sql(""" SELECT p.id AS src, b.id AS dst, 'CONTAINED_IN' AS relationship, ST_Area(ST_Intersection(p.geometry, b.geometry)) / ST_Area(p.geometry) AS overlap_pct, 'spatial_join' AS provenance FROM wherobots_open_data.overture_maps_foundation.places_place p JOIN wherobots_open_data.overture_maps_foundation.buildings_building b ON ST_Contains(b.geometry, p.geometry) """) Proximity edges (place → near road access point), using WherobotsDB’s native ST_KNN for nearest-neighbor joins at scale: # ST_KNN is WherobotsDB's distributed k-nearest-neighbor join # (available in WherobotsDB and Apache Sedona 1.7+) access_edges = sedona.sql(""" SELECT p.id AS src, s.id AS dst, 'ACCESSED_VIA' AS relationship, ST_Distance(p.geometry, s.geometry) AS distance, 'knn_join' AS provenance FROM wherobots_open_data.overture_maps_foundation.places_place p INNER JOIN wherobots_open_data.overture_maps_foundation.transportation_segment s ON ST_KNN(p.geometry, s.geometry, 1, false) """) Admin containment edges (building → in administrative boundary): admin_edges = sedona.sql(""" SELECT b.id AS src, d.id AS dst, 'IN_BOUNDARY' AS relationship, d.subtype AS boundary_type, 'spatial_join' AS provenance FROM wherobots_open_data.overture_maps_foundation.buildings_building b JOIN wherobots_open_data.overture_maps_foundation.divisions_division_area d ON ST_Within(b.geometry, d.geometry) WHERE d.subtype IN ('locality', 'county', 'region') """) All edge tables are unioned and written to Iceberg for durability and incremental updates: unified_edges = ( containment_edges.withColumn("edge_type", lit("contained_in")) .union(access_edges.withColumn("edge_type", lit("accessed_via"))) .union(conflation_edges.withColumn("edge_type", lit("likely_same_as"))) .union(admin_edges.withColumn("edge_type", lit("in_boundary"))) ) unified_edges.writeTo("my_catalog.spatial_graph.edges").createOrReplace() Step 2: Run graph operations with GraphFrames Node and Edge tables are not a graph, they’re raw material. GraphFrames, the DataFrame-native graph library for Apache Spark, turns those tables into a traversable graph inside the same WherobotsDB session. No separate graph database required. Construct the GraphFrame: from graphframes import GraphFrame from pyspark.sql import functions as F # Vertex table: union all entity types with a common schema nodes = sedona.sql(""" SELECT * FROM wherobots_open_data.overture_maps_foundation.nodes """) # Edge table: union all relationship types edges = sedona.sql(""" SELECT * FROM my_catalog.spatial_graph.edges """) g = GraphFrame(vertices, edges) Connected components for conflation clustering: # Find clusters of likely-same-entity candidates — each component # represents a set of records that may refer to the same real-world place sc.setCheckpointDir("/tmp/graphframes-checkpoints") components = g.connectedComponents() # Records sharing a component_id are conflation candidates components.filter(F.col("entity_type") == "place") \\ .groupBy("component") \\ .count() \\ .filter("count > 1") \\ .show() Motif finding for multi-hop subgraph extraction: GraphFrames’ motif syntax lets you query for structural patterns — the same way you’d write a path query in a graph database, but natively in Spark: # Find: place → contained_in → building → in_boundary → admin_area # This is the "what's here?" retrieval pattern for LLM context place_context = g.find("(place)-[e1]->(building); (building)-[e2]->(admin)") \\ .filter("e1.relationship = 'CONTAINED_IN' AND e2.relationship = 'IN_BOUNDARY'") \\ .select("place", "e1", "building", "e2", "admin") Subgraph extraction anchored to a location (the RAG retrieval step): def retrieve_subgraph(anchor_id: str, hop_depth: int = 2): """ Given an entity ID (building, place, or address), retrieve the connected subgraph up to hop_depth hops — this is the context bundle that gets passed to the LLM. """ # Breadth-first expansion from the anchor node frontier = {anchor_id} subgraph_edges = [] for _ in range(hop_depth): neighbors = g.edges.filter( F.col("src").isin(frontier) | F.col("dst").isin(frontier) ) subgraph_edges.append(neighbors) new_nodes = neighbors.select("src").union( neighbors.select(F.col("dst").alias("src")) ).distinct() frontier = {row["src"] for row in new_nodes.collect()} from functools import reduce all_edges = reduce(lambda a, b: a.union(b), subgraph_edges).distinct() subgraph_vertices = g.vertices.filter(F.col("id").isin(frontier)) return GraphFrame(subgraph_vertices, all_edges) # Usage: retrieve context for a specific building context_graph = retrieve_subgraph("building_id_4821", hop_depth=2) Even in a dense urban area with thousands of entities, the relevant subgraph is small, typically 10–50 nodes with their connecting edges. Step 3: Ground the LLM in spatial evidence The extracted subgraph replaces the flat text chunks that standard RAG provides. Instead of a paragraph about a restaurant, the model receives structured spatial evidence: Entity: Joe's Pizza (place, confidence: 0.95) → CONTAINED_IN: Building #4821 (overlap: 99.2%, provenance: spatial_join) → ACCESSED_VIA: Carmine St segment (distance: 4.1m, provenance: knn_join) → LIKELY_SAME_AS: Joe's Pizza [OSM] (name_score: 0.94, distance: 3.2m) → IN_BOUNDARY: Greenwich Village → Manhattan → New York County Now the model can answer “Is Joe’s Pizza inside that building?” with evidence, not guessing. Standard Graph RAG vs. Spatial Graph RAG DimensionStandard Graph RAGSpatial Graph RAGData sourceDocuments, wikis, databasesPhysical-world datasets (map data, imagery, sensor data)Entity extractionNLP (named entity recognition)Spatial data themes (buildings, places, addresses, roads)Relationship extractionText parsing, co-occurrenceSpatial operations (containment, proximity, adjacency, intersection)Edge generationNLP pipelines (spaCy, OpenIE)Distributed spatial joins (Apache Sedona / WherobotsDB)Graph operationsGraph databases (Neo4j, Neptune)GraphFrames on Spark — same cluster, no separate DBQuery anchorText query, entity nameCoordinate, building ID, place, addressSubgraph retrievalEntity traversal, community detectionSpatial neighborhood + motif queries (GraphFrames)ProvenanceSource document, page, paragraphSource dataset, spatial operation, confidence scoreHallucination reducedFactual claims about documentsPlace claims, spatial relationships, address assignmentsScale challengeMillions of documentsBillions of spatial features (planetary scale) Inside the Stack: Why Spatial Graph RAG Needs Two Layers The compute layer runs on WherobotsDB, built for native spatial execution at scale. Standard graph databases (Neo4j, Amazon Neptune, TigerGraph) are built for entity-relationship traversal on pre-loaded graphs. They have no native ability to perform the distributed spatial joins needed to construct edges at planetary scale. You can’t load 2.6 billion Overture building geometries into Neo4j and ask it to compute containment relationships with 1.2 billion places. Spatial Graph RAG needs two distinct capabilities in the same session: Edge and Node generation: distributed spatial joins across billions of features stored as different geometry types. This is what WherobotsDB and Apache Sedona are built for. The Overture Maps Foundation itself uses Wherobots and Apache Sedona to generate its monthly global data releases at scale. Graph operations: connected components, shortest paths, motif queries, iterative traversal. This is what GraphFrames provides, natively on the same Spark session, treating graphs as DataFrames. Running both inside WherobotsDB means the edge tables generated in Step 1 are immediately available to GraphFrames in Step 2 — no data movement, no format conversion, no separate system to operate. Why GraphFrames for Spatial Graph RAG GraphFrames extends Spark DataFrames with graph-parallel primitives: connected components, PageRank, triangle count, shortest paths, and motif finding. For Spatial Graph RAG, the most important capabilities are: Connected components : for identifying conflation clusters (which records likely refer to the same real-world entity) Motif finding: for multi-hop structural queries like (place)→(building)→(admin_area) that power context retrieval BFS/neighborhood expansion: for bounded subgraph extraction anchored to a query location The “graphs as tables” design (vertices and edges as DataFrames) maps directly onto the Iceberg edge tables generated by spatial SQL, which is why the two layers compose cleanly. Spatial Graph RAG Use Cases Place Q&A for AI Assistants “What’s at this location?” “Is this business still open?”, questions AI handles poorly today. A spatial knowledge graph provides evidence-bearing subgraphs that make answers accurate and traceable. Conflation and Data Quality Determining whether two records from different sources represent the same real-world entity. Spatial Graph RAG turns conflation from an irreversible merge into an inspectable, evidence-driven process, connected components expose the clusters, motif queries explain the evidence. Insurance Risk Assessment Which properties are in flood zones, which are adjacent to wildfire-prone vegetation, which are accessed by roads that become impassable in storms. Autonomous Systems and HD Maps Which lane connects to which intersection, which signs apply to which road segment. Graph-structured map data provides the relational context. Supply Chain Risk Intelligence Facilities → nearby hazard zones, suppliers → upstream of disruption, routes → through chokepoints. Building Spatial Graph RAG From Overture Maps Data The Overture Maps Foundation provides the ideal source data, available directly in The Wherobots Hub. The pipeline: Load Overture themes from the Wherobots Open Data Catalog (wherobots_open_data.overture_maps_foundation.*) Generate edges via distributed spatial joins (WherobotsDB spatial SQL) Store vertex and edge tables in Apache Iceberg (Havasu format) Construct graph with GraphFrames — same Spark session, no separate DB Run graph operations — connected components for conflation, motifs for context retrieval Serve subgraphs as LLM context through the Spatial AI Assistant or MCP integration Every build enriches The Global Hub. Graph RAG FAQ What is Graph RAG? Graph RAG, also written GraphRAG, is a retrieval-augmented generation method that retrieves connected entities and relationships from a knowledge graph and passes them to a large language model as context. The model receives the entities, the edges between them, and the evidence for each edge, so it can answer questions that depend on how facts connect. What is the difference between RAG and Graph RAG? Standard RAG retrieves text chunks from a vector database, ranked by semantic similarity to the question. Graph RAG retrieves a subgraph: entities, their relationships, and the provenance of each relationship. Graph RAG suits multi-hop questions, such as which facilities depend on a supplier located inside a flood zone. What is Microsoft GraphRAG? GraphRAG is an open-source library from Microsoft Research. It uses a language model to extract entities and relationships from text, groups them into communities, and summarizes each community. The 2024 paper by Edge et al. reported 72 to 83 percent comprehensiveness win rates over standard RAG on questions that span an entire dataset. What is Spatial Graph RAG? Spatial Graph RAG builds the knowledge graph from physical-world data such as buildings, places, addresses, and roads. Spatial SQL generates the edges through containment, proximity, adjacency, and intersection joins. The language model then receives a subgraph that describes where things are and how they connect. Do you need a graph database for Graph RAG? A graph database such as Neo4j or Amazon Neptune works for graphs that fit on one system. For graphs built from billions of spatial features, WherobotsDB generates node and edge tables with distributed spatial joins, and GraphFrames runs graph operations in the same Spark session. When should you use Graph RAG? Use Graph RAG when answers depend on relationships across entities: supply chains, ownership, network topology, or physical containment and proximity. Standard RAG costs less for lookups that a single passage answers. The next section summarizes the pipeline and the research behind it. Spatial Graph RAG: Key Points Graph RAG adds knowledge graph context to LLM reasoning Standard Graph RAG builds knowledge graphs from text. Spatial Graph RAG builds them from the physical world AI gets spatial relationships wrong because it has no structured spatial context — even when the model contains relevant geographic knowledge (GeoLLM, 2024) The pipeline is two layers: distributed spatial SQL generates edges; GraphFrames traverses them — both in the same WherobotsDB session Provenance makes it auditable — every edge carries evidence, every conflation candidate is inspectable The physical world is fundamentally relational. Spatial Graph RAG gives AI the relationships it needs to reason about place. References From Local to Global: A Graph RAG Approach to Query-Focused Summarization — Edge et al., Microsoft Research, 2024 GeoLLM: Extracting Geospatial Knowledge from Large Language Models — Manvi et al., ICLR 2024 An Integrated API for Mixing Graph and Relational Queries — Dave et al., GraphFrames / GRADES 2016 A Semantic-Spatial Aware Data Conflation Approach for Place Knowledge Graphs — He et al., IJGI 2024 Overture Maps Foundation Apache Sedona — 80M+ downloads GraphFrames GitHub Start Building with WherobotsDB Get Started --- ## Building the Wherobots Mobility Solution Accelerator: A Technical Deep Dive URL: https://wherobots.com/blog/mobility-solution-accelerator-gps-trajectory-processing/ Updated: 2026-10-19 From Raw GPS Pings to Spatial Intelligence In Part 1, we explored why mobility data breaks traditional spatial systems and what a modern processing architecture should look like. Now we get into the implementation. Key takeawaysThe accelerator is a three-notebook medallion pipeline on Wherobots that processes Microsoft Research GeoLife: 182 users, 17,621 trajectories, and millions of GPS points collected in Beijing between 2007 and 2012. GeoLife includes altitude, which lets the pipeline demonstrate full XYZM (4D) geometry processing.Never trust Spark schema inference for temporal columns in mobility data: inferSchema treated time as TimestampType and silently prepended today’s date. The fix is DATE_FORMAT() with explicit casts, plus ST_MakePoint so the data is a spatial type from Bronze onward.The dataset uses -777 as a sentinel for missing altitude.Trip segmentation uses a 20-minute (1,200-second) gap threshold, adjustable for other domains. COLLECT_LIST does not preserve order in Spark, so ST_IsValidTrajectory() rejected every trajectory; the pipeline uses a point_count >= 2 quality gate instead.Map matching is native in Wherobots via matcher.load_osm and matcher.match, not an external rate-limited API.Gold views include H3 density at resolution 9 (~105 m cells) and GeoHash precision 7 (~150 m). They also include ST_DBSCAN stop clustering (100 m epsilon, min 5 points, geodesic) and anomaly flags at mean + 3 standard deviations.Outputs are GeoParquet on S3, consumable in Felt, Kepler.gl, QGIS, DuckDB Spatial, and Foursquare Studio. This solution accelerator is a three-notebook pipeline built on Wherobots that processes the Microsoft Research GeoLife GPS Trajectories dataset, 182 users, 17,621 trajectories, and millions of GPS points collected in Beijing between 2007 and 2012. We chose this dataset specifically because it includes altitude data, which lets us demonstrate full XYZM (4D) geometry processing, something most spatial tutorials skip entirely because their data (or their platform) does not support it. A Python preparation script (prepare_geolife.py) converts thousands of raw .plt files into a single CSV for cloud ingestion. From there, the three notebooks handle everything: ingestion, profiling, cleaning, enrichment, trajectory construction, map matching, spatial indexing, clustering, anomaly detection, and the creation of GeoParquet-backed analytical views that flow directly into Felt for interactive, collaborative visualization. Notebook 1: Bronze Layer for Ingestion and Spatial Profiling The Bronze layer loads the combined CSV from S3 into WherobotsDB (optimized Apache Sedona) and establishes the spatial foundation for everything downstream. You can access the notebook here. Geometry Construction and Parsing The first operation converts raw latitude and longitude columns into proper 2D point geometries. But even before that, we hit our first real-world challenge. Spark’s inferSchema option inferred the time column as a TimestampType, silently prepending today’s date to raw time values. The dates looked plausible in isolation but were completely wrong. The fix uses DATE_FORMAT() to safely extract date and time parts regardless of the inferred type, while simultaneously constructing point geometries: bronze_df = sedona.sql("""     SELECT         user_id,         CAST(latitude AS DOUBLE) AS latitude,         CAST(longitude AS DOUBLE) AS longitude,         CAST(altitude_ft AS DOUBLE) AS altitude_ft,         DATE_FORMAT(date_str, 'yyyy-MM-dd') AS date_str,         DATE_FORMAT(time_str, 'HH:mm:ss') AS time_str,         ST_MakePoint(             CAST(longitude AS DOUBLE),             CAST(latitude AS DOUBLE)         ) AS geometry     FROM raw_gps """) This is not just a formatting step, calling ST_MakePoint registers the data as a spatial type, enabling WherobotsDB’s spatial indexing and query optimization for all subsequent operations. Lesson: Never trust Spark’s schema inference for temporal columns in mobility data. Explicitly cast and parse time values to avoid silent data corruption. Data Quality Profiling Before any transformation, we profile the raw data comprehensively. The dataset uses -777 as a sentinel value for missing altitude, so we quantify what percentage of records are affected, check coordinate bounds for points outside the expected Beijing-area extent, and analyze per-user distribution to understand data balance: sedona.sql("""     SELECT         COUNT(*) AS total,         SUM(CASE WHEN altitude_ft = -777 THEN 1 ELSE 0 END) AS invalid_altitude,         ROUND(100.0 * SUM(CASE WHEN altitude_ft = -777 THEN 1 ELSE 0 END)               / COUNT(*), 2) AS pct_invalid,         ROUND(MIN(CASE WHEN altitude_ft != -777 THEN altitude_ft END), 1)             AS min_valid_alt_ft,         ROUND(MAX(CASE WHEN altitude_ft != -777 THEN altitude_ft END), 1)             AS max_valid_alt_ft,         ROUND(AVG(CASE WHEN altitude_ft != -777 THEN altitude_ft END), 1)             AS avg_valid_alt_ft     FROM bronze """) We also use SedonaKepler to visualize a 1% sample of points, confirming that the spatial extent covers the expected Beijing area. This visual validation catches problems that statistical profiling misses, sparse coverage zones, spatial outliers, and artifacts that only become apparent on a map. The Bronze layer outputs raw GeoParquet to S3, giving us a spatially-typed, columnar, compressed foundation for all downstream processing. Notebook 2: Silver Layer for The Transformation Engine The Silver layer is where the pipeline earns its keep. This notebook handles cleaning, 4D geometry construction, trip segmentation, trajectory building, movement metric derivation, spatial indexing, and map matching. Each step has meaningful technical nuance worth examining. 4D XYZM Geometry Construction After filtering invalid records and converting altitude from feet to meters, we construct 4D XYZM point geometries that encode position, elevation, and time into a single geometric object: points_4d_df = sedona.sql("""     SELECT         user_id,         latitude,         longitude,         altitude_m,         epoch_seconds,         date_str,         time_str,         ST_MakePoint(             longitude,             latitude,             altitude_m,             CAST(epoch_seconds AS DOUBLE)         ) AS geometry_4d     FROM cleaned     WHERE epoch_seconds IS NOT NULL """) In this encoding, X = longitude, Y = latitude, Z = elevation in meters, M = Unix epoch timestamp as a measure value. We verify the construction with Sedona's dimension inspection functions: sedona.sql("""     SELECT         ST_HasZ(geometry_4d) AS has_z,         ST_HasM(geometry_4d) AS has_m,         ST_CoordDim(geometry_4d) AS coord_dim,         ST_Is3D(geometry_4d) AS is_3d     FROM points_4d     LIMIT 1 """) These checks are not optional—they confirm that downstream operations like ST_ZMin(), ST_ZMax(), and ST_3DDistance() will have the dimensional data they need. Trip Segmentation with PySpark Window Functions Continuous GPS streams must be split into discrete trips. We use PySpark window functions to compute the time difference between consecutive GPS points for each user, flag gaps exceeding 20 minutes as trip boundaries, and assign composite trip IDs: window_user = Window.partitionBy("user_id").orderBy("epoch_seconds") segmented_df = (     points_4d_df     .withColumn("prev_epoch", F.lag("epoch_seconds").over(window_user))     .withColumn("time_delta_s", F.col("epoch_seconds") - F.col("prev_epoch"))     .withColumn(         "is_new_trip",         F.when(             F.col("time_delta_s").isNull()             | (F.col("time_delta_s") > TIME_GAP_THRESHOLD_SECONDS),             F.lit(1)         ).otherwise(F.lit(0))     )     .withColumn(         "trip_segment",         F.sum("is_new_trip").over(window_user)     )     # Create composite trip ID: user_id + segment number     .withColumn(         "trip_id",         F.concat(F.col("user_id"), F.lit("_"), F.col("trip_segment"))     ) ) This approach is clean, declarative, and executes efficiently in Spark’s distributed computation model. The TIME_GAP_THRESHOLD_SECONDS parameter (set to 1,200 seconds / 20 minutes) is easily adjustable for different use cases, delivery fleets might use 5 minutes, while long-haul trucking might use 60. Trajectory Construction and the Ordering Problem Once trips are defined, we build XYZM LineString trajectories per trip. This is where we hit one of the most important challenges in distributed trajectory processing: COLLECT_LIST in Spark does not guarantee order. The spatial geometry, the actual XY path, may be correct, but M values (timestamps) can be scrambled. The solution requires a CTE-based approach that also handles the single-point edge case (ST_MakeLine requires at least 2 points, and Spark evaluates SELECT before HAVING): trajectories_df = sedona.sql("""     WITH trip_counts AS (         SELECT trip_id         FROM segmented         GROUP BY trip_id         HAVING COUNT(*) >= 2     ),     valid_points AS (         SELECT s.*         FROM segmented s         INNER JOIN trip_counts tc ON s.trip_id = tc.trip_id         ORDER BY s.user_id, s.trip_id, s.epoch_seconds     )     SELECT         user_id,         trip_id,         ST_MakeLine(COLLECT_LIST(geometry_4d)) AS trajectory,         COUNT(*) AS point_count,         MIN(epoch_seconds) AS start_time,         MAX(epoch_seconds) AS end_time,         MIN(date_str) AS start_date,         MAX(date_str) AS end_date     FROM valid_points     GROUP BY user_id, trip_id """) Sedona provides ST_IsValidTrajectory() to validate M-value ordering. When we applied it, every single trajectory was rejected due to the distributed collect ordering issue. Our pragmatic solution: use point_count filters instead of ST_IsValidTrajectory() as the quality gate, acknowledging that the spatial geometry is correct regardless of M ordering. Lesson: In any distributed system, aggregation functions that collect values into arrays or lists may not preserve insertion order. Design your pipeline to tolerate this, or implement explicit sorting within the aggregation. Movement Metrics With trajectories constructed, we derive per-trip metrics using Sedona’s elevation and measurement functions: trip_metrics_df = sedona.sql("""     SELECT         user_id,         trip_id,         trajectory,         point_count,         start_time,         end_time,         (end_time - start_time) AS duration_s,         ROUND(ST_Length(trajectory), 6) AS distance_deg,         ROUND(ST_ZMin(trajectory), 2) AS min_elevation_m,         ROUND(ST_ZMax(trajectory), 2) AS max_elevation_m,         ROUND(ST_ZMax(trajectory) - ST_ZMin(trajectory), 2) AS elevation_range_m     FROM trajectories     WHERE point_count >= 2 """) Per-point metrics like speed, elevation delta, distance between consecutive points are computed separately using window functions over the segmented DataFrame with ST_Distance(). Spatial Indexing: H3 and GeoHash We assign both H3 hexagon cell IDs and GeoHash values in a single pass, giving downstream Gold-layer analytics flexibility in how they aggregate spatial data: indexed_points = sedona.sql("""     SELECT         *,         EXPLODE(ST_H3CellIDs(geometry_4d, 9, false)) AS h3_cell_id,         ST_GeoHash(geometry_4d, 7) AS geohash     FROM enriched """) H3 at resolution 9 provides hexagonal cells roughly 105 meters across, ideal for urban mobility density analysis. GeoHash at precision 7 gives approximately 150-meter cells useful for range queries and segment identification. Map Matching with Wherobots The Silver layer’s final major operation is map matching, snapping noisy GPS traces to the actual road network. The matcher expects a simple DataFrame with IDs and geometry: from wherobots import matcher # Load Beijing OSM road network roads_df = matcher.load_osm(OSM_DATA_PATH, "[car]") # Prepare trajectories for matching paths_df = trip_metrics_df.select(     col("trip_id").alias("ids"),     col("trajectory").alias("geometry") ) # Run map matching matched_df = matcher.match(     roads_df,       # Road network edges     paths_df,       # GPS trajectory LineStrings     "geometry",     # Road geometry column name     "geometry"      # Path geometry column name ) The matcher produces three outputs per trajectory: observed_points (the raw GPS trace), matched_points (the road-snapped route), and matched_nodes (OSM node IDs along the matched path). Having this as a native operation within Wherobots, rather than calling an external API with rate limits and per-request pricing, eliminates an entire category of infrastructure complexity. Notebook 3: Gold Layer for Analytics, Exploration, and Deep Dives The Gold layer transforms Silver-layer trajectories into purpose-built analytical views. We structured these into three tiers: analytical, exploratory, and deep dive. Analytical Views H3 Hexbin Activity Density Heatmap. We aggregate GPS points by H3 cell and convert cell IDs back to hexagon polygons, enriching each cell with multi-dimensional metrics: h3_density = sedona.sql("""     SELECT         h3_cell_id,         ST_H3ToGeom(ARRAY(h3_cell_id))[0] AS geometry,         COUNT(*) AS point_count,         COUNT(DISTINCT user_id) AS unique_users,         COUNT(DISTINCT trip_id) AS unique_trips,         ROUND(AVG(speed_mps), 2) AS avg_speed_mps,         ROUND(AVG(altitude_m), 2) AS avg_elevation_m,         ROUND(MIN(altitude_m), 2) AS min_elevation_m,         ROUND(MAX(altitude_m), 2) AS max_elevation_m     FROM silver_points     WHERE speed_mps IS NOT NULL     GROUP BY h3_cell_id     ORDER BY point_count DESC """) This view is the foundation for understanding spatial activity patterns, where movement concentrates, where it is sparse, and how intensity varies across the study area. Temporal Patterns. Hourly and day-of-week aggregations reveal when mobility peaks and troughs occur: temporal_patterns = sedona.sql("""     SELECT         HOUR(FROM_UNIXTIME(epoch_seconds)) AS hour_of_day,         DAYOFWEEK(FROM_UNIXTIME(epoch_seconds)) AS day_of_week,         COUNT(*) AS point_count,         COUNT(DISTINCT user_id) AS active_users,         COUNT(DISTINCT trip_id) AS active_trips,         ROUND(AVG(speed_mps), 2) AS avg_speed_mps     FROM silver_points     WHERE speed_mps IS NOT NULL     GROUP BY         HOUR(FROM_UNIXTIME(epoch_seconds)),         DAYOFWEEK(FROM_UNIXTIME(epoch_seconds))     ORDER BY day_of_week, hour_of_day """) Trip Statistics and Map Matching Coverage. Distribution summaries characterize mobility behavior, while the ratio of successfully matched trajectories provides a quality metric for both the GPS data and the road network. Exploratory Views Elevation Profiles. We sample points at 5% intervals along the longest trajectories using ST_LineInterpolatePoint, then extract elevation and timestamps. This required splitting operations into separate CTEs because Spark does not allow EXPLODE() nested inside other expressions: elevation_profiles = sedona.sql("""     WITH top_trips AS (         SELECT trip_id, trajectory, point_count         FROM silver_trajectories         WHERE point_count >= 10         ORDER BY point_count DESC         LIMIT 10     ),     raw_steps AS (         SELECT EXPLODE(SEQUENCE(0, 100, 5)) AS step     ),     fractions AS (         SELECT step / 100.0 AS fraction FROM raw_steps     )     SELECT         t.trip_id,         f.fraction,         ST_LineInterpolatePoint(t.trajectory, f.fraction) AS point_along_route,         ROUND(ST_Z(ST_LineInterpolatePoint(t.trajectory, f.fraction)), 2)             AS elevation_m,         ROUND(ST_M(ST_LineInterpolatePoint(t.trajectory, f.fraction)), 0)             AS epoch_seconds     FROM top_trips t     CROSS JOIN fractions f     ORDER BY t.trip_id, f.fraction """) 2D vs 3D Distance Comparison. By comparing ST_Length() with ST_3DDistance(), we quantify the impact of terrain on distance calculations. In hilly areas, the difference can be significant enough to affect route planning, fuel modeling, and ETAs: distance_comparison = sedona.sql("""     SELECT         trip_id,         point_count,         elevation_range_m,         ROUND(ST_Length(trajectory) * 111320, 0) AS distance_2d_m,         ROUND(             ST_3DDistance(                 ST_StartPoint(trajectory),                 ST_EndPoint(trajectory)             ) * 111320, 0         ) AS straight_line_3d_m,         ROUND(             ST_Distance(                 ST_StartPoint(trajectory),                 ST_EndPoint(trajectory)             ) * 111320, 0         ) AS straight_line_2d_m     FROM silver_trajectories     WHERE elevation_range_m > 50     ORDER BY elevation_range_m DESC     LIMIT 20 """) Map Matched vs Raw Comparison. Side-by-side SedonaKepler layers showing the original noisy GPS trace against the road-snapped route make the value of map matching immediately visible to any stakeholder. Deep Dive Views DBSCAN Stop Point Clustering. We filter points with speed below 0.5 m/s, then cluster using ST_DBSCAN with geodesic distance. An important implementation detail: ST_DBSCAN requires a physical column reference, not a computed expression: # Filter to stationary points stop_points = points_df.filter("speed_mps IS NOT NULL AND speed_mps < 0.5") # ST_DBSCAN requires a named reference to a physical column. # useSpheroid=true so epsilon is in meters (geodesic distance). clusters_raw = sedona.sql("""     SELECT         *,         ST_DBSCAN(geometry_4d, 100, 5, true) AS cluster_result     FROM stop_points """) The 100-meter epsilon is appropriate for identifying distinct stop locations, buildings, intersections, transit stops, in an urban environment. Clusters with 10+ stop points are then aggregated into hotspots: hotspots = sedona.sql("""     SELECT         cluster AS hotspot_id,         COUNT(*) AS total_stops,         COUNT(DISTINCT user_id) AS unique_visitors,         COUNT(DISTINCT trip_id) AS unique_trips,         ST_MakePoint(AVG(longitude), AVG(latitude)) AS geometry,         ROUND(AVG(altitude_m), 1) AS avg_elevation_m     FROM clusters     WHERE cluster != -1 AND isCore = true     GROUP BY cluster     HAVING COUNT(*) >= 10     ORDER BY total_stops DESC """) Trajectory Anomaly Detection. We flag trips with extreme values using a CTE pattern that avoids Spark’s “HAVING without GROUP BY” error: anomalies = sedona.sql("""     WITH trip_stats AS (         SELECT             AVG(duration_s) AS mean_duration,             STDDEV(duration_s) AS std_duration,             AVG(distance_deg * 111320) AS mean_distance,             STDDEV(distance_deg * 111320) AS std_distance,             AVG(elevation_range_m) AS mean_elev_range,             STDDEV(elevation_range_m) AS std_elev_range         FROM silver_trajectories         WHERE duration_s > 0     ),     classified AS (         SELECT             t.trip_id,             t.user_id,             t.trajectory,             t.duration_s,             ROUND(t.distance_deg * 111320, 0) AS distance_m,             t.elevation_range_m,             CASE                 WHEN t.elevation_range_m                     > (s.mean_elev_range + 3 * s.std_elev_range)                     THEN 'extreme_elevation'                 WHEN t.duration_s                     > (s.mean_duration + 3 * s.std_duration)                     THEN 'extreme_duration'                 WHEN t.distance_deg * 111320                     > (s.mean_distance + 3 * s.std_distance)                     THEN 'extreme_distance'                 ELSE NULL             END AS anomaly_type         FROM silver_trajectories t         CROSS JOIN trip_stats s     )     SELECT * FROM classified     WHERE anomaly_type IS NOT NULL """) Road Segment Speed Analysis. By joining matched routes with trajectory metrics and decomposing routes into individual segments using GeoHash pairs, we calculate average speed per road segment and classify by congestion: matched_with_metrics = sedona.sql("""     SELECT         m.ids AS trip_id,         t.user_id,         m.matched_points AS geometry,         t.duration_s,         ROUND(ST_Length(m.matched_points) * 111320, 0) AS matched_distance_m,         CASE WHEN t.duration_s > 0             THEN ROUND(                 ST_Length(m.matched_points) * 111320 / t.duration_s * 3.6, 1)             ELSE 0         END AS avg_speed_kmh,         CASE WHEN t.duration_s > 0 THEN             CASE                 WHEN (ST_Length(m.matched_points) * 111320                       / t.duration_s * 3.6) < 15 THEN 'congested'                 WHEN (ST_Length(m.matched_points) * 111320                       / t.duration_s * 3.6) < 40 THEN 'urban'                 WHEN (ST_Length(m.matched_points) * 111320                       / t.duration_s * 3.6) < 80 THEN 'arterial'                 ELSE 'highway'             END             ELSE 'unknown'         END AS road_class     FROM silver_matched m     INNER JOIN silver_trajectories t ON m.ids = t.trip_id """) This visualization uses the actual road LineString geometries from map matching, not H3 hexagons, providing road-level granularity that is directly actionable for traffic engineering and route optimization. From Notebooks to Dashboards: The Wherobots + Felt Connection Processing mobility data at scale is only half the equation. The other half is getting the results into the hands of decision-makers (operations teams, urban planners, fleet managers, logistics analysts) who need interactive, shareable maps, not Jupyter notebooks. This is where the Wherobots and Felt integration completes the picture. Wherobots and Felt recently announced a strategic partnership that connects Wherobots’ spatial intelligence lakehouse directly with Felt’s collaborative, browser-based mapping platform. The integration lets organizations go from processing petabyte-scale geospatial datasets in the cloud to exploring insights in interactive maps, without moving large datasets between systems. For this mobility accelerator, the workflow is straightforward. Every Gold-layer view we produce, H3 density heatmaps, hotspot clusters, road segment speed classifications, trajectory anomaly maps, is written as GeoParquet to S3. Through the native Wherobots-Felt integration, these datasets are directly accessible in Felt, where they become live, interactive, collaborative map layers. There is no export step, no format conversion, and no data movement friction. What this means in practice: Shareable analysis, not static screenshots. Instead of exporting a Kepler.gl map as an image or HTML file, the H3 activity density view becomes a live Felt map that operations teams can explore, filter, annotate, and share via a link, viewable from any device, no GIS software required. Collaborative investigation. When the anomaly detection pipeline flags suspicious trajectories, an analyst does not need to walk a fleet manager through a notebook. They share a Felt map where the flagged routes are overlaid on the road speed classification layer, and the fleet manager can pan, zoom, and query the data themselves. Operational dashboards from analytical views. The road segment speed analysis, with its congested/urban/arterial/highway classification, becomes a traffic conditions dashboard. The hotspot identification layer becomes a POI and dwell-time analysis tool. These are not one-off visualizations—they are reusable, updatable artifacts that stay connected to the processed data. AI-assisted map creation. Felt’s AI-driven interface lets users interact with spatial data using natural language prompts, lowering the barrier for non-GIS teams to extract insights. Combined with Wherobots’ processing power, this creates what both companies describe as the “SQL-to-map” workflow, from Spatial SQL query to interactive, shareable map in seconds. This combination is already in production. Leaf Agriculture uses Wherobots and Felt together to process millions of acres of tractor telemetry and imagery data, turning their agricultural data lake into interactive maps and dashboards distributed via links instead of in-person screen-sharings. The mobility use case follows the same pattern: process at scale with Wherobots, visualize and collaborate in Felt. Challenges and Solutions: A Practitioner’s Reference Every mobility data pipeline encounters edge cases. Here are the ones we solved in this accelerator, documented so you can avoid them: 1. Spark inferSchema corrupting time values. Spark silently prepended today’s date to inferred TimestampType columns. Fix: Use DATE_FORMAT() to extract date and time parts explicitly. 2. ST_MakeLine failing on single-point groups. A LineString requires at least two points, but Spark evaluates SELECT before HAVING. Fix: Use a CTE to pre-filter trips with >= 2 points before the aggregation query. 3. COLLECT_LIST not preserving order. Distributed aggregation does not guarantee array ordering. Fix: Accept unordered M values in trajectories and use point_count filters instead of ST_IsValidTrajectory() as a quality gate. 4. EXPLODE nested in expressions. Spark does not allow EXPLODE() inside other SQL expressions. Fix: Split the operation into separate CTEs. 5. ST_DBSCAN requiring physical column references. The function does not accept computed expressions as geometry input. Fix: Use the persisted GeoParquet column. 6. HAVING without GROUP BY. Applying aggregate thresholds without a GROUP BY clause. Fix: Use a CTE to compute thresholds, then apply as WHERE conditions. Apache Sedona Spatial SQL Functions Used This accelerator demonstrates a broad cross-section of Sedona’s spatial SQL capabilities: CategoryFunctions4D Point ConstructionST_MakePoint(x, y, z, m)Dimension InspectionST_Z(), ST_M(), ST_HasZ(), ST_HasM(), ST_CoordDim(), ST_Is3D()Elevation AnalysisST_ZMin(), ST_ZMax(), ST_3DDistance()Trajectory BuildingST_MakeLine(), ST_IsValidTrajectory()Trajectory SamplingST_LineInterpolatePoint()Spatial IndexingST_H3CellIDs(), ST_H3ToGeom(), ST_GeoHash()Spatial MeasurementST_Length(), ST_Distance(), ST_StartPoint(), ST_EndPoint()ClusteringST_DBSCAN()Map Matchingmatcher.load_osm(), matcher.match()Geometry ConstructionST_MakePoint(), ST_Buffer()VisualizationSedonaKepler.create_map(), SedonaKepler.add_df() GeoParquet Output and Tool Interoperability All Gold-layer views are persisted as GeoParquet files. GeoParquet has emerged as the standard columnar format for geospatial data in the cloud-native ecosystem, offering efficient compression, predicate pushdown for spatial filters, and broad tool compatibility. The analytical views produced by this accelerator are immediately consumable in Felt, Kepler.gl, QGIS, Foursquare Studio, DuckDB Spatial, and any other tool that reads GeoParquet, no export step, no format conversion, no data loss. With the Wherobots-Felt integration, GeoParquet outputs in S3 become live data sources for interactive maps. This closes the loop from raw GPS pings to collaborative dashboards in a single, end-to-end spatial data stack. Get Started with GPS Trajectory Processing on Wherobots The Wherobots Mobility Solution Accelerator is designed to be a starting point, not a black box. The three notebooks are fully documented, the Spatial SQL is readable and modifiable, and every intermediate result is inspectable as a Spark DataFrame or visualizable in SedonaKepler, and from there, publishable as an interactive Felt map. Whether you are processing fleet telematics, rideshare trajectories, maritime AIS data, or drone flight logs, the patterns demonstrated here—medallion architecture, 4D geometry processing, distributed trip segmentation, integrated map matching, GeoParquet output, and collaborative visualization through Felt—translate directly to your use case. To explore the accelerator, visit Wherobots and get started with a notebook environment and connect your favorite IDE to the Wherobots MCP Server and Spatial AI Coding Tools. To see how the Wherobots + Felt stack works together, check out the integration documentation. If you have questions about applying these patterns to your mobility data, reach out to the Wherobots team or join the Apache Sedona community on Discord. Get Started with the Spatial AI Coding Tools Try Now Frequently Asked Questions What is the Wherobots Mobility Solution Accelerator? A three-notebook pipeline on Wherobots that takes raw GPS pings through Bronze ingestion and profiling, Silver cleaning, 4D geometry, trip segmentation, trajectory construction, map matching, and Gold analytical views. It is demonstrated on GeoLife (182 users, 17,621 trajectories, Beijing 2007–2012) and is meant as a starting point for fleet telematics, rideshare, AIS, or drone logs. How do you build 4D GPS trajectories in Apache Sedona? After converting altitude from feet to meters, construct points with ST_MakePoint(longitude, latitude, altitude_m, epoch_seconds) so X/Y/Z/M live in one geometry. Verify with ST_HasZ, ST_HasM, ST_CoordDim, and ST_Is3D. Build LineStrings with ST_MakeLine after a CTE that keeps only trips with at least two points, because Spark evaluates SELECT before HAVING and ST_MakeLine requires two points. How does map matching work in the accelerator? The Silver notebook loads a Beijing OSM road network with matcher.load_osm(…, “[car]”) and snaps GPS LineStrings with matcher.match. Each trajectory returns observed_points, matched_points, and matched_nodes (OSM node IDs). Running this inside Wherobots avoids external API rate limits and per-request pricing. How do you visualize mobility pipeline output in Felt? Every Gold-layer view is written as GeoParquet to S3. Through the native Wherobots–Felt integration those datasets become live, interactive map layers with no export step or format conversion. The post cites Leaf Agriculture using the same pattern on millions of acres of tractor telemetry. --- ## How well does SAM3 detect building footprints? We asked the Wherobots Spatial AI Coding Assistant URL: https://wherobots.com/blog/sam3-aerial-imagery-building-footprints/ Updated: 2026-10-19 In a recent post, we showed how easy it is to use RasterFlow and Meta’s Segment Anything 3 Model (SAM3) to detect features in the physical world. A single end-to-end pipeline built a 133 GB NAIP mosaic of Marion County, Oregon, ran SAM3 against it with text prompts spanning eight classes, and produced approximately one million detection polygons in a Wherobots table including roughly 312,000 building roofs. Key takeawaysA prior RasterFlow + SAM3 job built a 133 GB NAIP mosaic of Marion County, Oregon, and ran text prompts across eight classes. It produced about one million detection polygons, including roughly 312,000 building roofs.This post evaluates those roof detections against Overture Maps buildings in the Wherobots Hub. The evaluation was designed and executed in four prompts with the Spatial AI Assistant inside Claude, using the Wherobots MCP server.The assistant returned a 24-cell notebook. Area math uses UTM zone 10N (EPSG:32610), not EPSG:4326, and the AOI is the official Marion County admin boundary from wkls, not a bounding box.Inside the official county polygon: 261,414 SAM3 roofs vs 146,642 Overture buildings. The spatial join produced 207,109 candidate matched pairs, and SAM3 and Overture total roof area agree within 7%.Caveats: roofs are not footprints, and Overture is not ground truth in rural areas and likely misses buildings. The 0.5 confidence cutoff was already applied in SAM3 outputs, limiting precision-recall to the upper half of the confidence range.Many SAM3 ‘false positives’ are real rural buildings Overture missed, so real precision is likely higher than 75%. That is an impressive result on its own. But once the inference job finished, the obvious next question was: are these detections any good? Specifically, how well do they agree with an independent reference dataset of building footprints? The Overture Maps Foundation publishes a global buildings dataset that is freely available in the Wherobots Hub. If I could compare the SAM3 roof detections against Overture for the same county, I would have a first-pass evaluation of whether SAM3 is finding the right things in roughly the right places. The catch: I am a product manager, not a data scientist, and I am not well-versed in the standard techniques used to evaluate the output of remote-sensing models. Intersection-over-union, recall and precision curves, confidence calibration, the right metric coordinate reference system… I knew the terms, but I had not performed an evaluation like this from scratch before. That is exactly where the Wherobots Spatial AI Assistant comes in. Upcoming Session: See an AI agent take plain-language question and orchestrating pipelines to end results using RasterFlow and the Wherobots MCP server. Evaluating SAM3 on Aerial Imagery in Four Prompts I opened a conversation with the assistant inside Claude, using the Wherobots MCP server. I described what I had: a fresh SAM3 detection table in org_catalog.sam3_marion_db.sam3_outputs, and a goal of comparing it to Overture buildings. The full session took four prompts. Prompt 1: Describe the data. “can you see SAM3 results in org_catalog.sam3_marion_db.sam3_outputs? can you tell me more about this dataset of SAM3 detections for Marion County OR?” Within seconds, the assistant had walked the catalog, run summary statistics, and returned a complete profile: eight detection classes (layers), around one million total rows, 312k roofs, confidence scores ranging from 0.50 to 0.96, the table’s spatial extent, and the source mosaic. One of the queries it ran was a simple breakdown of the detections by class (layer): SELECT layer, COUNT(*) AS n, AVG(bbox_score) AS avg_score FROM org_catalog.sam3_marion_db.sam3_outputs GROUP BY layer ORDER BY n DESC A sample of SAM3 roof detections (blue) over NAIP imagery in Marion County, Oregon. Each polygon is a segmentation mask, not a bounding box. Prompt 2: Design the comparison. “if I wanted to compare the buildings (roofs) detecting with SAM3 against the building footprints in the overture dataset in wherobots_open_data.overture_maps_foundation, how would I do that?” The assistant designed a four-stage approach: clip both datasets to a Marion County area of interest; spatial-join them on intersection; compute intersection-over-union per pair; and aggregate to recall, precision, and calibration metrics. It also surfaced a set of caveats: Roofs are not footprints, since overhangs and occlusion mean the shapes will never match exactly. Overture is not ground truth in rural areas and is likely to miss buildings. The 0.5 confidence cutoff was already baked into the SAM3 outputs, which limits any precision-recall analysis to the upper half of the confidence range. Area math must be performed in UTM zone 10N rather than EPSG:4326. These considerations gave me confidence that the analysis was well thought through and likely accurate. Prompt 3: Use the right area of interest. Rather than a rough bounding box, I wanted the comparison clipped to the actual Marion County admin boundary, fetched from a trustworthy source. “can you use wkls to get the official admin boundary from Overture for Marion County, like this: gdf = gpd.read_file(wkls['us']['or']['Marion County'].geojson())” The assistant rebuilt the join strategy around the admin polygon generated using wkls. It pulled the boundary as a single-row Spark view that could be broadcast into the spatial joins, and combined an Iceberg bounding-box prefilter on Overture with an exact ST_Intersects predicate against the real Marion County shape. The generated code was straightforward: import wkls import geopandas as gpd gdf = gpd.read_file(wkls['us']['or']['Marion County'].geojson()) aoi_geom = gdf.geometry.iloc[0] aoi_wkt = aoi_geom.wkt sedona.sql(f""" CREATE OR REPLACE TEMP VIEW aoi AS SELECT ST_GeomFromWKT('{aoi_wkt}') AS geom """) Prompt 4: Let’s do the analysis in a notebook. “can you create this analysis in a Jupyter notebook that I can run with Wherobots?” The assistant returned a 24-cell notebook covering everything from SedonaContext setup through the final visualization. I ran it in VS Code using a Wherobots cloud runtime. The rest of this post walks through the code and the results. Comparing SAM3 Building Detections to Overture Footprints Here’s the notebook: sam3_vs_overture_marion.ipynb The notebook has four sections: Setup and constants. Setting up imports, initializing the SedonaContext, defining the target CRS (EPSG:32610, UTM zone 10N), IoU thresholds, and table names. It’s worth noting out that the assistant chose UTM zone 10N automatically (the right metric CRS for western Oregon) without me having to ask. Fetch the AOI from wkls. The notebook calls wkls['us']['or']['Marion County'].geojson(), reads the result into a GeoPandas frame, extracts the polygon’s WKT and bounding box, and registers a one-row aoi Spark view. It then renders the boundary on a SedonaKepler map so I could visually confirm I had the right AOI before running anything expensive. Sanity counts. Two COUNT(*) queries over the SAM3 and Overture tables, both clipped to the admin boundary: SAM3 roofs inside Marion County: 261,414 (the full dataset has 312k; the remainder fell outside the official admin polygon). Overture buildings inside Marion County: 146,642. SAM3 finds notably more candidate roof shapes than Overture has buildings. Filtered AOI views. Two temporary views, sam3_roofs and overture_bldgs, each with the lon/lat geometry and a UTM-projected geometry. The Overture view uses a two-stage filter: a bounding-box prefilter that takes advantage of Iceberg column statistics and an exact ST_Intersects predicate against the admin polygon for Marion County. Spatial join. This step matches candidate buildings. For every pair of SAM3 roof and Overture building whose geometries intersect, the query computes the intersection area, the two source areas, and the IoU: SELECT s.sam3_id, s.bbox_score, o.overture_id, ST_Area(ST_Intersection(s.geom_m, o.geom_m)) AS inter_m2, ST_Area(s.geom_m) AS sam3_m2, ST_Area(o.geom_m) AS overture_m2, ST_Area(ST_Intersection(s.geom_m, o.geom_m)) / NULLIF(ST_Area(s.geom_m) + ST_Area(o.geom_m) - ST_Area(ST_Intersection(s.geom_m, o.geom_m)), 0) AS iou FROM sam3_roofs s JOIN overture_bldgs o ON ST_Intersects(s.geom_4326, o.geom_4326) Intersection-over-union (IoU) is the area shared by two polygons divided by their combined area. A value of 1.0 is a perfect match; 0.0 means no overlap. The ST_Intersects predicate runs on the lon/lat geometries, where Sedona’s spatial join planner has the column statistics it needs to be efficient; the ST_Area and ST_Intersection calls run on the UTM-projected geometries, where the resulting numbers are in square meters and meaningful. The query returns 207,109 candidate matched pairs and is cached for the rest of the analysis. Resolution and metrics. Sometimes a single SAM3 polygon covers several Overture buildings, for example when SAM3 segments a multi-roof complex as one shape. Other times, several SAM3 polygons land on the same Overture building. To keep the comparison clean, the notebook keeps only the best-matching pair on each side. The remaining cells then compute the numbers the rest of the post relies on: Recall. What fraction of Overture buildings has a matching SAM3 detection of roughly the right shape. Precision. What fraction of SAM3 detections lines up with a known Overture building. Calibration. Whether SAM3’s confidence score is a reliable signal of how well-shaped each detection actually is. Aggregate area. How the total roof area SAM3 found across the county compares to the total building footprint area Overture has. A final cell renders five high-IoU and five low-IoU matched pairs on aerial imagery for visual spot-checking, so I could see with my own eyes where SAM3 and Overture agree and where they don’t. Example results comparing Overture building footprints (yellow) and SAM3 roof detections (blue). Top: a high quality result. Center: SAM3 failed to segment the roof in this building. Bottom: SAM3 segments part of the roof, but not the whole footprint. SAM3 Building Detection Accuracy: Recall, Precision, and IoU Results I wasn’t sure how best to assess the results. So I asked Claude to help with the analysis and here is a summary: The overall correlation is very high. SAM3 and Overture report total roof area within 7% of each other across this county. That level of agreement says they are measuring the same physical objects, not coincidentally landing on the same total. SAM3’s confidence score correlates to the accuracy of the polygon. SAM3 detections with high confidence scores have polygons that line up well with the real buildings, while lower confidence detections have less accurate shapes. That means we can use the confidence score as a reliable filter. Many of SAM3’s “false positives” are real buildings Overture missed. The assistant pointed out that many of the SAM3 detections without an Overture match are actual rural houses and outbuildings visible on aerial imagery. So the real precision is likely higher than 75%. When SAM3 finds a building, it usually gets the shape right. Only about 12 percentage points separate “found something on this building” from “found roughly the right shape on this building.” That means SAM3 is not just placing a point on the map, it is accurately outlining the building roofs. These results are impressive! With a single text prompt (”roofs”), I was able to produce detections that match a curated, multi-source reference dataset to within 7% on total roof area, found the right shape on three-quarters of known buildings, and carried a confidence score an application can actually trust. Even though SAM3 was not fine-tuned for roof detection, the resulting output would be operationally useful for many use cases. Using the Spatial AI Coding Assistant to Evaluate Computer Vision ML Models A few hours after I started, I had an initial assessment on the quality of the SAM3 detections. And I had a notebook with reproducible results that anyone can rerun in minutes. The assistant does not replace the role of the data scientist, but accelerates initial spatial and statistical analysis. And it did it while surfacing important caveats from the start. Try It Yourself Sign up for Wherobots Cloud and connect the Spatial AI Assistant to your own data. Read the prior RasterFlow + SAM3 post for the upstream half of this workflow. Sign up for the RasterFlow private preview to try out SAM3 today! Try the Spatial AI Coding Assistant GET STARTED Frequently Asked Questions How well does SAM3 detect building footprints compared to Overture? On Marion County, Oregon NAIP, SAM3 and Overture total roof area agree within 7%. SAM3 found the right shape on about three-quarters of known Overture buildings.Only about 12 percentage points separate ‘found something on this building’ from ‘found roughly the right shape.’ SAM3 was not fine-tuned for roof detection. How do you compare SAM3 detections to Overture buildings in Wherobots? Clip both datasets to the Marion County admin boundary and spatial-join on intersection. Compute IoU per pair in UTM zone 10N, and keep the best-matching pair on each side. Then aggregate recall, precision, calibration, and total area.The assistant used an Iceberg bounding-box prefilter on Overture plus an exact ST_Intersects predicate against the real county polygon. Can a non-data-scientist evaluate remote-sensing model output with Wherobots? The author is a product manager and had not run this evaluation from scratch. Four prompts with the Spatial AI Assistant produced a complete profile of the detection table, a comparison design with caveats, an official AOI, and a runnable 24-cell notebook. The assistant does not replace a data scientist, but it accelerated the first-pass analysis. Why is SAM3 precision against Overture not the true precision? Overture is not ground truth in rural areas and is likely to miss buildings. The assistant noted that many SAM3 detections without an Overture match are actual rural houses and outbuildings visible on aerial imagery, so real precision is likely higher than 75%. Roofs also are not footprints: overhangs and occlusion mean shapes will never match exactly. --- ## Wherobots MCP Server: Building GEOINT Spatial Pipelines with AI Agents URL: https://wherobots.com/blog/wherobots-mcp-server-geoint-spatial-pipelines-ai-agents/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. I built three national-security GEOINT use cases on the Wherobots stack in days instead of weeks. A Critical Infrastructure Vulnerability (CIV) pipeline with two regional variants, plus a border-corridor analysis on real transportation segments. The Wherobots geospatial MCP server is what made that timeline possible. Key takeawaysThree national-security GEOINT use cases were built on Wherobots in days instead of weeks. They are a Critical Infrastructure Vulnerability pipeline with two regional variants, plus a border-corridor analysis on real transportation segments.The slow part was never the analysis. It was catalog discovery, schema, and anchoring synthetic operational data to real geometries.The MCP server walks the live Wherobots catalog (and connected Databricks Unity, AWS Glue, or S3 catalogs) intra-session. After critical_assets_civ was created in step 2, a follow-up prompt could find it via a fresh catalog walk.The agent reads the catalog as it exists at that moment, not a schema pasted into a system prompt.A catalog walk warned off power_pole (18.3M rows) and power_tower (18.0M rows), 36M rows together, before a spatial join. The discover, describe, generate, test (limit=10), refine loop let the author test 500 m, 1 km, and 2 km flood buffers in the time the first query normally takes.The CIV score is a 10-step pipeline ending in a 5-component formula. The formula is 0.25 flood_count + 0.25 wildfire_count + 0.15 (facility_count + 0.01 building_count) + 0.20 criticality_tier * 100 + 0.15 (negative_tweet_count * 2 + 0.5 neutral_tweet_count).Deliverables: two regional CIV notebooks, a border-corridor notebook, and an MCP scenario notebook with 10+ analyst prompts. They persist as wherobots.geoint.* Iceberg tables. Most of the work in standing up a credible use case isn’t the analysis. It’s the plumbing. Finding the right data within the organization. Understanding the schema. Anchoring synthetic operational data to real geometries so the joins represent reality. That’s where the weeks go, and anyone who’s built a multi-table spatial pipeline on real data knows the shape of it. About a dozen joined results, multiple Overture Maps Foundation themes, notional mission overlays, and an scenario-based MCP server evaluation notebook driving the whole thing. The build took days instead of weeks thanks to the Wherobots Spatial AI Coding Tools. What used to be the slow part of this kind of build was never the analysis. It was the getting to the analysis. Finding the right Overture tables. Learning their column shapes. Remembering whether class lived on base_infrastructure or places_place. Figuring out that categories was structured as a STRUCT vs. a flat field. Discovering the hard way that power_pole and power_tower collectively contain 36M rows and could have consumed tons of unnecessary resources. The Wherobots MCP collapsed every one of those build time consuming events into a tool call. Designing the CIV Pipeline Schema The end state for the CIV use case is a 10-step pipeline ending in a 5-component scoring formula: vulnerability_score = 0.25 * flood_count + 0.25 * wildfire_count + 0.15 * (facility_count + 0.01 * building_count) + 0.20 * criticality_tier * 100 + 0.15 * (negative_tweet_count * 2 + neutral_tweet_count * 0.5) Sitting underneath that score: an AOI layer, an asset layer, flood and wildfire proximity buffers, settlement/facility proximity, building density, a criticality tier table, seasonal hazard windows, social-media sentiment proximity, and a geofence overlay. About a dozen tables in wherobots.geoint.*_civ, each with a clear FK relationship back to critical_assets_civ.asset_id. Overture thematic geometries underneath, synthetic operational signal layered on top. That’s a lot of schema. Designing it is the interesting part. Creating the plumbing without agentic support can extend the timeline significantly. Direct Access to Your Spatial Catalog The real paradigm shift isn’t any single tool call. It’s that the agent can reach for my Wherobots organization’s current catalog, and any of the catalogs connections it has (Databricks Unity, AWS Glue, S3) whenever it needs to, intra-session. Not a snapshot from when the analysis was developed. Not a schema description I pasted into a system prompt three turns ago. When the agent invokes the MCP, the response reflects the catalog as it exists at that moment, which means: After I created critical_assets_civ in Step 2, a follow-up prompt could find it via a fresh catalog walk. No need to tell the agent anything. When I added a negative_tweet_count column further down the pipeline, the next describe_table call against that table reflected the new column. When I joined two of my own tables and persisted the result as a new Iceberg table, the agent could discover and reason about it on a subsequent prompt as easily as any Overture table. The catalog and the agent’s understanding don’t have to drift apart. That sounds like a small thing. In practice though, it is a BIG deal, because the work of building a multi-table use case is a sequence of “I just created this, now use it to build the next thing.” Whenever the agent reaches for the catalog, it can see what I’ve built so far, what’s in the open data catalog, and what fields are queryable. I’m never re-explaining my own schema. This is what an context engine for physical world data looks like in practice. The agent isn’t reasoning about geography from training data. It’s reading the live state of a interconnected and extensible Wherobots spatial catalog and writing SQL grounded in it. The same catalog can feed graph RAG, where spatial joins generate the knowledge graph an agent retrieves from. The loop that emerged on top of that capability looked the same across both builds: Discover. “What Overture tables describe critical infrastructure in this AOI?” The MCP catalog walk surfaced base_infrastructure, base_water, base_land_cover, places_place, and buildings_building, including the row counts that warned me off power_pole and power_tower before I computed a spatial join on them. -- Catalog walk: filter base_infrastructure to classes worth joining on, -- excluding power_pole (18.3M rows) and power_tower (18.0M rows) once -- list_tables_tool surfaced their volume. SELECT class, COUNT(*) AS row_count FROM wherobots_open_data.overture_maps_foundation.base_infrastructure GROUP BY class ORDER BY row_count DESC; Describe. Before any SQL got written, describe_table returned the actual columns. No guessing whether categories.primary was a STRUCT field or a flat string. No discovering at runtime that subtype and class were different axes. Generate with grounded context. Schema-aware SQL generation produced queries that ran on the first or second attempt because the agent had already seen the column shape, including the tables I’d just created moments earlier. -- Step 3: Flood Hazard Proximity -- Counts water features within 1 km of each critical infrastructure asset. -- Pre-filters water to Ukraine AOI to reduce spatial join volume. SELECT a.asset_id, COUNT(w.id) AS flood_water_count FROM critical_assets a JOIN wherobots_open_data.overture_maps_foundation.base_water w ON ST_DWithin(a.geometry, w.geometry, 1000, true) CROSS JOIN ukraine_aoi ua WHERE w.class IN ('river', 'stream', 'lake', 'reservoir', 'canal') AND ST_Intersects(ua.geometry, w.geometry) GROUP BY a.asset_id ORDER BY flood_water_count DESC; Execute with limit=10. Every query got tested on a small slice before it ran across the full AOI. The cost of being wrong dropped to near zero, which meant I iterated on scoring weights, distance thresholds, and asset-class filters far more aggressively than I would have otherwise. The result: I spent my time on the parts that required judgment. Where should the flood buffer be: 500m, 1km, 2km? 500m is too tight in dense urban terrain. 2km swallows half the AOI. The MCP let me test all three in the time it would normally take to write the first query. What’s the right tier-weighting for a substation vs. a generator? Does negative sentiment matter 2x or 4x more than neutral sentiment in the composite score? How do I express a seasonal vulnerability window so the downstream MCP scenarios can filter on it cleanly? Here’s what the scoring formula above looks like as the actual SQL that runs against the persisted views. Every *_proximity table shares the same asset_id grain, so the composite score is a single set of LEFT JOINs back to the asset layer: -- Step 10: Enhanced Vulnerability Score (5-component composite) SELECT ca.asset_id, ca.class, ac.criticality_tier, COALESCE(fp.flood_water_count, 0) AS flood_count, COALESCE(wp.wildfire_landcover_count, 0) AS wildfire_count, COALESCE(sp.facility_count, 0) AS facility_count, COALESCE(bd.building_count, 0) AS building_count, COALESCE(sm.negative_tweet_count, 0) AS negative_tweet_count, ( 0.25 * COALESCE(fp.flood_water_count, 0) + 0.25 * COALESCE(wp.wildfire_landcover_count, 0) + 0.15 * (COALESCE(sp.facility_count, 0) + 0.01 * COALESCE(bd.building_count, 0)) + 0.20 * ac.criticality_tier * 100 + 0.15 * (COALESCE(sm.negative_tweet_count, 0) * 2 + COALESCE(sm.neutral_tweet_count, 0) * 0.5) ) AS vulnerability_score, CASE WHEN COALESCE(fp.flood_water_count, 0) > 0 AND COALESCE(wp.wildfire_landcover_count, 0) > 0 THEN TRUE ELSE FALSE END AS multi_hazard_flag FROM critical_assets ca JOIN asset_criticality ac ON ca.asset_id = ac.asset_id LEFT JOIN flood_proximity fp ON ca.asset_id = fp.asset_id LEFT JOIN wildfire_proximity wp ON ca.asset_id = wp.asset_id LEFT JOIN settlement_proximity sp ON ca.asset_id = sp.asset_id LEFT JOIN building_density bd ON ca.asset_id = bd.asset_id LEFT JOIN social_media_proximity sm ON ca.asset_id = sm.asset_id ORDER BY vulnerability_score DESC; The Same Pattern Works for Retail, Insurance, and Supply Chain Strip the national-security framing off the build and the underlying loop is domain-agnostic. Swap critical_assets_civ for store locations and the proximity layers for foot-traffic decay and competitor density, and the same pipeline becomes a retail expansion analysis. Swap them for policy-in-force locations and named-storm tracks, and it’s catastrophe exposure modeling for an insurance carrier. Swap them for distribution centers and port-congestion signal, and it’s a supply-chain resilience build. Swap them for parcels and zoning and hazard layers, and it’s a municipal planning workflow. The paradigm generalizes: a live catalog the agent re-reads every turn if needed, layered data anchored to real datasets and foundational Overture data, and an iterative discover → describe → generate → test → refine loop. It works anywhere you have a catalog of geospatial or tabular data you’re actively building on top of. The schema work is the same shape regardless of whether the bottom layer is Overture infrastructure, OpenStreetMap, NAIP rasters, parcel records, or a customer’s own warehoused operational data. What changes is the vocabulary on top. What You Ship: Notebooks, Schemas, and a Reusable GEOINT Pipeline Two regional CIV setup notebooks, a third for border-corridor segments, and an MCP scenario notebook with 10+ analyst prompts that exercise the full schema. All on real Overture geometry. All synthetic where it needs to be. All persisted to our managed Iceberg catalog as wherobots.geoint.* so the next analyst can pick it up where I left off. The deliverable looks like weeks of work. The MCP server and spatial AI coding tools made it days. The schema is where the value lives, and the AI coding tools let me spend my time there. Here is a link to the use case setup notebook Get Started with the Spatial AI Coding Assistant Access Now Frequently Asked Questions How does the Wherobots MCP server speed up spatial pipeline development? It collapses catalog discovery, schema inspection, and SQL generation into tool calls against the live catalog. The author did not have to remember whether class lived on base_infrastructure or places_place, or that categories was a STRUCT. Queries were tested with limit=10 before full-AOI runs, so the cost of being wrong dropped and iteration on weights and buffers became aggressive. Can an AI agent see tables I just created in Wherobots? Yes. The agent reaches the organization’s current catalog, plus connected Databricks Unity, AWS Glue, or S3 catalogs, whenever it needs to. Newly created Iceberg tables and newly added columns show up on the next describe_table or catalog walk without re-explaining the schema. Does the GEOINT MCP pattern work outside national security? The post says the loop is domain-agnostic. Swap critical assets for store locations and the same pipeline becomes retail expansion. Swap in policy-in-force locations and storm tracks for catastrophe exposure.Swap in distribution centers and port congestion for supply-chain resilience. Swap in parcels, zoning, and hazard layers for municipal planning. What did the CIV vulnerability score include? A 10-step pipeline on about a dozen tables in wherobots.geoint.*_civ, each with a foreign key back to critical_assets_civ.asset_id. The composite combines flood and wildfire proximity, settlement/facility proximity, building density, a criticality tier, and social-media sentiment proximity.A multi_hazard_flag is set when both flood and wildfire counts are positive. Overture geometries are the base; operational signal is synthetic. --- ## Wherobots Pro Free Trial URL: https://wherobots.com/free-trial/ Updated: 2026-10-09 WHEROBOTS PRO FREE TRIAL Run planetary-scale spatial workloads. Free for 14 days. Full access to Wherobots, the Context Engine for Physical World Data. $95 in compute credits when you sign up. Get an additional $250 in credits when you start using Spatial AI Coding Tools. Contact us after you start your free trial to receive your additional credits. Start free trial Talk to the team $95 in credits Use across any runtime. Compute, storage, and queries included. 14 days, full Pro access Every feature, every dataset, every spatial function. Sign up with email Upgrade only when you’re ready. Full Pro Access WherobotsDB Planetary-scale spatial compute engine with 300+ vector and raster functions. 100% Apache Sedona compatible. Spatial AI Coding Assistant Agentic interface for spatial workflows. Build and execute queries through VS Code and MCP in natural language. Contact for $250 in credits Global Hub Organizational memory for the physical world. Central home for notebooks, repos, jobs, models, and workflows. Jobs and API Access Schedule and automate spatial workloads. Full API access for programmatic control of your compute pipelines. Enterprise Security Up to 10 users. SSO, SAML, and MFA included. 8×5 support from the team behind Apache Sedona. RasterFlow Inference Engine for planetary scale perception as a service. RasterFlow Preview How to Get Started Your trial runs for 14 days or until your $95 in credits is used, whichever comes first. Contact us after you activate your free trial to get an additional $250 in credits when you enable our Spatial AI Coding tools. 1. Sign up Create your Wherobots account. 2. Start your 14-day trial Unlock $95 in free credits. No credit card required to get started. 3. Get building Immediate access to the all capabilities, no waiting. Low Cost + High Performance Spatial Operations WherobotsDB delivers fast, cost-efficient performance across spatial SQL and python workloads*. WherobotsDB benchmarks at 3x faster with up to 45% better price-performance than comparable engines, and at lower cost than PostGIS at scale. *This represents actual cost benchmarking results for SpatialBench queries 7-12 with a scale factor of 1000 across three of the most comparable deployment options. WherobotsDB Lowest Proprietary SQL Serverless Engine x2.92 higher Apache Sedona on Serverless Spark x2.03 higher Proprietary Cloud Managed Spark x2.52 higher Benchmark Results SpatialBench Scale Factor 1000 query capability matrix. WherobotsDB completes all 12 queries; competing platforms fail on heavy spatial joins, distance joins, multi-way joins, and KNN joins. SpatialBench Query WherobotsDB Sedona on Serverless Spark Proprietary SQL Serverless Proprietary Spark Clusters with Spatial SQL Sedona on Managed Spark Clusters 1: Spatial filter, aggregation, sorting ✅ ✅ ✅ ✅ ✅ 2: Spatial filter, aggregation, sorting ✅ ✅ ✅ ✅ ✅ 3: Spatial filter, aggregation, sorting ✅ ✅ ✅ ✅ ✅ 4: Lightweight spatial join and aggregation ✅ ✅ ✅ ✅ ✅ 5: Spatial aggregation ✅ ✅ ✅ ✅ ✅ 6: Heavy spatial join ✅ ❌ ✅ ❌ ❌ 7: Geometry construction and access ✅ ❌ ✅ ✅ ✅ 8: Heavy distance join ✅ ❌ ❌ ❌ ❌ 9: Heavy polygon self spatial join ✅ ✅ ❌ ❌ ✅ 10: Heavy spatial left join ✅ ❌ ❌ ❌ ❌ 11: Multi-way spatial join ✅ ❌ ❌ ❌ ❌ 12: KNN join ✅ ❌ ❌ ❌ ❌ “We were able to merge 15+ complex vector datasets in minutes and run high-resolution ML inference at a fraction of the cost of our legacy stack. The combination of speed, scalability, and ease of integration has boosted our engineering productivity and accelerated how quickly we can deliver new geospatial data products.” Rashmit Singh CTO at SatSure “With Wherobots on AWS, we can now scale to millions of acres reliably and cost-effectively, delivering faster results and more value to our customers.” Bailey Stockdale CEO at Leaf Agriculture “Overture’s 2.6B-building dataset now runs up to 20x faster on Wherobots, with a simple code redirect that kept Sedona compatibility and made our team more productive.” Jennings Anderson Software Engineer with Meta for Overture Maps Foundation GET STARTED Start running spatial workloads today. $95 in credits. 14 days. Full Pro access. Enable Spatial AI Coding Tools to get an additional $250 in credits. Start free trial --- ## Change Detection Using AlphaEarth Foundations (Part 2) URL: https://wherobots.com/blog/alphaearth-foundations-change-detection-part-2/ Updated: 2026-10-19 Author: Len Strnad AlphaEarth Foundations embeddings gave us an initial view of temporal change in our earlier post on agricultural dynamics, but that first pass also exposed a limitation: raw embedding distances do not live on a consistent scale across pixels or land-cover types. As a result, it is hard to compare how unusual a given year looks from place to place, even when the relative signal is informative. Key takeawaysRaw AlphaEarth Foundations embedding distances do not live on a consistent scale across pixels or land-cover types. This follow-up scores each annual embedding by how much it stands out from the rest of its local time series.The scores are leave-one-out (LOO) medoid scores in embedding space, then robust z-score scaling through time per pixel.The workflow reads the global AEF Zarr mosaic on Source Cooperative: annual 64-band embeddings at 10-meter resolution in EPSG:4326, nine snapshots from 2017 through 2025.The global store is 3.81 PiB with about 1.02 billion chunks. The demo subsets Colorado rather than the full mosaic, and only land-intersecting chunks are present.RasterFlow’s run_mosaics_change computed both difference-over-time and LOO medoid scores with AlphaEarth cosine distance and robust_time_zscore=True. The Colorado result is a ~235 GB Zarr (9 time steps × 2 score bands).build_zarr_multiscales produced a public multiscale mosaic at s3://wherobots-examples/rasterflow/mosaics/co-aef-change.zarr.The post is a practical workflow, not a definitive change-detection benchmark. Examples around Boulder are qualitative.LOO medoid plus robust time-wise normalization makes change magnitude more comparable across pixels. It highlights anomalous years across the full nine-year window, not only between adjacent years. In this follow-up, we ask a more targeted question: can we score each annual embedding by how much it stands out from the rest of its local time series? To do that, we compute leave-one-out (LOO) medoid scores in embedding space and apply robust z-score scaling through time for each pixel. This gives us a more stable and interpretable way to identify unusual years across a short annual record. As in the earlier AlphaEarth Foundations agriculture post, the goal is not to present a definitive change-detection benchmark. Instead, we show a practical workflow for surfacing unusual temporal states in AEF embeddings. We run that workflow against the global AEF Zarr mosaic hosted on Source Cooperative, build a multiscale output for exploration, and inspect several examples around Boulder, Colorado. Global Zarr AEF Mosaic For this follow-up we use the global AlphaEarth Foundations Zarr mosaic hosted on Source Cooperative. Thanks to Taylor Geospatial and Source Cooperative for making the dataset available in a form that is easy to access lazily in a single python function call! The mosaic stores annual AEF embeddings at 10-meter resolution in EPSG:4326, with nine temporal snapshots from 2017 through 2025. Working from one global store keeps the workflow simple: we can subset the region of interest, compute scores, and publish a derived multiscale product without assembling separate local inputs. import xarray as xr ds = xr.open_zarr( "s3://us-west-2.opendata.source.coop/tge-labs/aef-mosaic/", consolidated=False, storage_options={"anon": True}, ) ds /Users/len/code/wherobots-notebook-blogs/.pixi/envs/default/lib/python3.14/site-packages/zarr/core/group.py:3559: ZarrUserWarning: Object at README.md is not recognized as a component of a Zarr hierarchy. warnings.warn( /Users/len/code/wherobots-notebook-blogs/.pixi/envs/default/lib/python3.14/site-packages/zarr/core/group.py:3559: ZarrUserWarning: Object at .checkpoint is not recognized as a component of a Zarr hierarchy. warnings.warn( Size: 4PB Dimensions: (time: 9, band: 64, y: 1859584, x: 4009984) Coordinates: * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 * band (band) object 512B 'A00' 'A01' 'A02' 'A03' ... 'A61' 'A62' 'A63' * y (y) float64 15MB 83.69 83.69 83.69 ... -83.36 -83.36 -83.36 * x (x) float64 32MB -180.0 -180.0 -180.0 ... 180.2 180.2 180.2 Data variables: embeddings (time, band, y, x) int8 4PB dask.array Attributes: (12/15) proj:code: EPSG:4326 spatial:dimensions: ['y', 'x'] spatial:transform: [8.983111749910169e-05, 0.0, -180.0, 0.0, -8.983... spatial:transform_type: affine spatial:bbox: [-180.0, -83.36280346631479, 180.2213438735178, ... spatial:shape: [1859584, 4009984] ... ... geoemb:model: https://developers.google.com/earth-engine/datas... geoemb:source_data: https://source.coop/tge-labs/aef/v1/annual/ geoemb:data_type: int8 geoemb:gsd: 8.983111749910169e-05 geoemb:quantization: {'method': 'signed_square', 'original_dtype': 'f... zarr_conventions: [{'uuid': 'f17cb550-5864-4468-aeb7-f3180cfb622f'...xarray.DatasetDimensions:time: 9band: 64y: 1859584x: 4009984Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)object‘A00’ ‘A01’ ‘A02’ … ‘A62’ ‘A63’_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array(['A00', 'A01', 'A02', 'A03', 'A04', 'A05', 'A06', 'A07', 'A08', 'A09', 'A10', 'A11', 'A12', 'A13', 'A14', 'A15', 'A16', 'A17', 'A18', 'A19', 'A20', 'A21', 'A22', 'A23', 'A24', 'A25', 'A26', 'A27', 'A28', 'A29', 'A30', 'A31', 'A32', 'A33', 'A34', 'A35', 'A36', 'A37', 'A38', 'A39', 'A40', 'A41', 'A42', 'A43', 'A44', 'A45', 'A46', 'A47', 'A48', 'A49', 'A50', 'A51', 'A52', 'A53', 'A54', 'A55', 'A56', 'A57', 'A58', 'A59', 'A60', 'A61', 'A62', 'A63'], dtype=object)y(y)float6483.69 83.69 83.69 … -83.36 -83.36_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([ 83.68566 , 83.685571, 83.685481, ..., -83.362579, -83.362669, -83.362759], shape=(1859584,))x(x)float64-180.0 -180.0 … 180.2 180.2_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([-179.999955, -179.999865, -179.999775, ..., 180.221119, 180.221209, 180.221299], shape=(4009984,))Data variables: (1)embeddings(time, band, y, x)int8dask.array_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’} Array Chunk Bytes 3.81 PiB 4.00 MiB Shape (9, 64, 1859584, 4009984) (1, 64, 256, 256) Dask graph 1024049664 chunks in 2 graph layers Data type int8 numpy.ndarray 9 1 4009984 1859584 64 Attributes: (15)proj:code :EPSG:4326spatial:dimensions :[‘y’, ‘x’]spatial:transform :[8.983111749910169e-05, 0.0, -180.0, 0.0, -8.983111749910169e-05, 83.68570533713473]spatial:transform_type :affinespatial:bbox :[-180.0, -83.36280346631479, 180.2213438735178, 83.68570533713473]spatial:shape :[1859584, 4009984]spatial:registration :pixelgeoemb:type :pixelgeoemb:dimensions :64geoemb:model :https://developers.google.com/earth-engine/datasets/catalog/GOOGLE_SATELLITE_EMBEDDING_V1_ANNUALgeoemb:source_data :https://source.coop/tge-labs/aef/v1/annual/geoemb:data_type :int8geoemb:gsd :8.983111749910169e-05geoemb:quantization :{‘method’: ‘signed_square’, ‘original_dtype’: ‘float32’, ‘quantized_dtype’: ‘int8’, ‘formula’: ‘(x / 127.5) ** 2 * sign(x)’, ‘valid_range’: [-127, 127], ‘nodata’: -128}zarr_conventions :[{‘uuid’: ‘f17cb550-5864-4468-aeb7-f3180cfb622f’, ‘name’: ‘proj:’, ‘description’: ‘Coordinate reference system information for geospatial data’, ‘spec_url’: ‘https://github.com/zarr-experimental/geo-proj/blob/v1/README.md’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-experimental/geo-proj/refs/tags/v1/schema.json’}, {‘uuid’: ‘689b58e2-cf7b-45e0-9fff-9cfc0883d6b4’, ‘name’: ‘spatial:’, ‘description’: ‘Spatial coordinate information’, ‘spec_url’: ‘https://github.com/zarr-conventions/spatial/blob/v1/README.md’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-conventions/spatial/refs/tags/v1/schema.json’}, {‘uuid’: ’61c12cc5-0e28-4056-999a-480cf3fb7e4c’, ‘name’: ‘geoemb:’, ‘description’: ‘Geo-embeddings metadata for machine learning embeddings stored in Zarr’, ‘spec_url’: ‘https://github.com/geo-embeddings/embeddings-zarr-convention/tree/add-convention’}] At first glance, 3.81 PiB and 1,024,049,664 chunks in S3 sounds impractically large. For this demo, though, a few details keep the workflow manageable: only chunks that intersect land are present the dataset is sharded into nine spatial chunks, which reduces the effective object count we subset Colorado rather than operating on the full global mosaic RasterFlow Tools Used RasterFlow is Wherobots’ serverless inference engine for Earth Observation data. It builds inference-ready mosaics from remote sensing data and runs distributed workflows at scale. This notebook uses two RasterFlow capabilities: run_mosaics_change on the RasterFlow Remote client for computing difference and LOO medoid scores over time build_zarr_multiscales for producing a visualization-ready Zarr mosaic Change Detection with RasterFlow Remote For this run, we call run_mosaics_change on the RasterFlow Remote client. The method takes an input Zarr mosaic and writes out a derived Zarr mosaic containing one or more temporal change scores. Here we compute both difference-over-time and LOO medoid scores in AEF embedding space, with robust z-score normalization applied across time for each pixel. The snippet below matches the current remote-client API used for this Colorado example. from affine import Affine from rasterio.transform import rowcol # construct a bounding box selector for Colorado transform = Affine(*ds.attrs["spatial:transform"]) row_min, col_min = rowcol(transform, -109.060253, 41.003444) row_max, col_max = rowcol(transform, -102.041524, 37.000232) selector = {"x": [col_min, col_max], "y": [row_min, row_max]} selector {'x': [np.int32(789701), np.int32(867833)], 'y': [np.int32(475138), np.int32(519702)]} from rasterflow_remote import DistanceMetricEnum, RasterflowClient, TemporalScoreMethodEnum client = RasterflowClient() result = client.run_mosaics_change( store="s3://us-west-2.opendata.source.coop/tge-labs/aef-mosaic/", score_methods=[ TemporalScoreMethodEnum.DIFFERENCE, TemporalScoreMethodEnum.LOO_MEDOID, ], distance_metric=DistanceMetricEnum.ALPHA_EARTH_COSINE, data_var="embeddings", robust_time_zscore=True, selector=selector, ) LOO Medoid Scores for Small Samples To measure how unusual a given annual embedding is relative to its temporal context, we use a leave-one-out medoid (LOO medoid) score in embedding space. This is well suited to the AEF setting here, where we only have nine annual observations and want a reference that is less sensitive to outliers than a simple average. Given a time series of embeddings {e1,…,eT}\{e_1, \dots, e_T\}, the LOO medoid score at time tkt_k compares eke_k to a representative embedding computed from the remaining observations: E−k={ej∣j≠k}. E_{-k} = \{e_j \mid j \neq k\}. We define that representative as the medoid of E−kE_{-k}, i.e. the embedding that minimizes total distance to all others: emedoid(−k)=arg⁡minei∈E−k∑ej∈E−kd(ei,ej). e_{\text{medoid}}^{(-k)} = \arg\min_{e_i \in E_{-k}} \sum_{e_j \in E_{-k}} d(e_i, e_j). The LOO medoid score is then: LOOmedoid(tk)=d(ek,emedoid(−k)), \mathrm{LOO}_{\mathrm{medoid}}(t_k) = d\left(e_k, e_{\text{medoid}}^{(-k)}\right), where d(⋅,⋅)d(\cdot, \cdot) is a distance metric (e.g., Euclidean or cosine distance). Interpretation: LOOmedoid(tk)\mathrm{LOO}_{\mathrm{medoid}}(t_k) measures how far the embedding at time tkt_k is from the medoid of the remaining time series. Larger values indicate that the year-specific embedding is less consistent with the rest of the temporal sequence, suggesting a potential change or anomalous state with respect to all other years. Results Using the workflow above, we compute two normalized change layers across the nine-year Colorado subset of the AEF mosaic: a difference-over-time score and a LOO medoid score. The intermediate result below is a Zarr dataset. You may notice: 9 time steps, corresponding to the annual AEF embeddings from 2017 through 2025 2 score bands, one for consecutive difference and one for LOO medoid deviation ~235Gb of data ds = xr.open_zarr( "s3://sandbox-wherobots-mosaics-tmp/rasterflow/rasterflow/development/rbz2h49wvpjt7h4nzq5g/76e986b947cc.zarr" ) ds Size: 253GB Dimensions: (time: 9, band: 2, y: 44800, x: 78336) Coordinates: * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 * band (band) object 16B 'difference_alpha_earth_cosine_distance_rob... * y (y) float64 358kB 41.0 41.0 41.0 41.0 ... 36.98 36.98 36.98 * x (x) float64 627kB -109.1 -109.1 -109.1 ... -102.0 -102.0 -102.0 Data variables: embeddings (time, band, y, x) float32 253GB dask.array Attributes: (12/15) proj:code: EPSG:4326 spatial:dimensions: ['y', 'x'] spatial:transform: [8.983111749910169e-05, 0.0, -180.0, 0.0, -8.983... spatial:transform_type: affine spatial:bbox: [-180.0, -83.36280346631479, 180.2213438735178, ... spatial:shape: [1859584, 4009984] ... ... geoemb:model: https://developers.google.com/earth-engine/datas... geoemb:source_data: https://source.coop/tge-labs/aef/v1/annual/ geoemb:data_type: int8 geoemb:gsd: 8.983111749910169e-05 geoemb:quantization: {'method': 'signed_square', 'original_dtype': 'f... zarr_conventions: [{'uuid': 'f17cb550-5864-4468-aeb7-f3180cfb622f'...xarray.DatasetDimensions:time: 9band: 2y: 44800x: 78336Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)object‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore', 'loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'], dtype=object)y(y)float6441.0 41.0 41.0 … 36.98 36.98_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([41.003663, 41.003573, 41.003483, ..., 36.979498, 36.979408, 36.979318], shape=(44800,))x(x)float64-109.1 -109.1 … -102.0 -102.0_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([-109.077928, -109.077839, -109.077749, ..., -102.041188, -102.041098, -102.041008], shape=(78336,))Data variables: (1)embeddings(time, band, y, x)float32dask.array_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’} Array Chunk Bytes 235.33 GiB 256.00 kiB Shape (9, 2, 44800, 78336) (1, 1, 256, 256) Dask graph 963900 chunks in 2 graph layers Data type float32 numpy.ndarray 9 1 78336 44800 2 Attributes: (15)proj:code :EPSG:4326spatial:dimensions :[‘y’, ‘x’]spatial:transform :[8.983111749910169e-05, 0.0, -180.0, 0.0, -8.983111749910169e-05, 83.68570533713473]spatial:transform_type :affinespatial:bbox :[-180.0, -83.36280346631479, 180.2213438735178, 83.68570533713473]spatial:shape :[1859584, 4009984]spatial:registration :pixelgeoemb:type :pixelgeoemb:dimensions :64geoemb:model :https://developers.google.com/earth-engine/datasets/catalog/GOOGLE_SATELLITE_EMBEDDING_V1_ANNUALgeoemb:source_data :https://source.coop/tge-labs/aef/v1/annual/geoemb:data_type :int8geoemb:gsd :8.983111749910169e-05geoemb:quantization :{‘method’: ‘signed_square’, ‘original_dtype’: ‘float32’, ‘quantized_dtype’: ‘int8’, ‘formula’: ‘(x / 127.5) ** 2 * sign(x)’, ‘valid_range’: [-127, 127], ‘nodata’: -128}zarr_conventions :[{‘uuid’: ‘f17cb550-5864-4468-aeb7-f3180cfb622f’, ‘name’: ‘proj:’, ‘description’: ‘Coordinate reference system information for geospatial data’, ‘spec_url’: ‘https://github.com/zarr-experimental/geo-proj/blob/v1/README.md’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-experimental/geo-proj/refs/tags/v1/schema.json’}, {‘uuid’: ‘689b58e2-cf7b-45e0-9fff-9cfc0883d6b4’, ‘name’: ‘spatial:’, ‘description’: ‘Spatial coordinate information’, ‘spec_url’: ‘https://github.com/zarr-conventions/spatial/blob/v1/README.md’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-conventions/spatial/refs/tags/v1/schema.json’}, {‘uuid’: ’61c12cc5-0e28-4056-999a-480cf3fb7e4c’, ‘name’: ‘geoemb:’, ‘description’: ‘Geo-embeddings metadata for machine learning embeddings stored in Zarr’, ‘spec_url’: ‘https://github.com/geo-embeddings/embeddings-zarr-convention/tree/add-convention’}] Visualization To make the result easier to explore, we run the build_zarr_multiscales function to create a multiscale Zarr mosaic optimized for interactive viewing and analysis, then publish it to a public bucket for anyone to explore. xr.open_datatree("s3://wherobots-examples/rasterflow/mosaics/co-aef-change.zarr") Group: / │ Attributes: │ zarr_conventions: [{'uuid': 'd35379db-88df-4056-af3a-620245f8e347'... │ multiscales: {'layout': [{'asset': '0', 'transform': {'scale'... │ proj:code: EPSG:4326 │ proj:wkt2: GEOGCRS["WGS 84",ENSEMBLE["World Geodetic System... │ spatial:dimensions: ['y', 'x'] │ spatial:registration: pixel │ spatial:transform_type: affine │ spatial:shape: [44800, 78336] │ spatial:transform: [8.983111749216732e-05, 0.0, -109.07797340998921... │ spatial:bbox: [-109.07797340998921, 36.97927342911413, -102.04... ├── Group: /0 │ Dimensions: (time: 9, band: 2, y: 44800, x: 78336) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 358kB 41.0 41.0 41.0 41.0 ... 36.98 36.98 36.98 │ * x (x) float64 627kB -109.1 -109.1 -109.1 ... -102.0 -102.0 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 253GB ... │ spatial_ref int32 4B ... ├── Group: /1 │ Dimensions: (time: 9, band: 2, y: 22400, x: 39168) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 179kB 41.0 41.0 41.0 41.0 ... 36.98 36.98 36.98 │ * x (x) float64 313kB -109.1 -109.1 -109.1 ... -102.0 -102.0 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 63GB ... │ spatial_ref int32 4B ... ├── Group: /2 │ Dimensions: (time: 9, band: 2, y: 11200, x: 19584) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 90kB 41.0 41.0 41.0 41.0 ... 36.98 36.98 36.98 │ * x (x) float64 157kB -109.1 -109.1 -109.1 ... -102.0 -102.0 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 16GB ... │ spatial_ref int32 4B ... ├── Group: /3 │ Dimensions: (time: 9, band: 2, y: 5600, x: 9792) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 45kB 41.0 41.0 41.0 41.0 ... 36.98 36.98 36.98 │ * x (x) float64 78kB -109.1 -109.1 -109.1 ... -102.0 -102.0 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 4GB ... │ spatial_ref int32 4B ... ├── Group: /4 │ Dimensions: (time: 9, band: 2, y: 2800, x: 4896) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 22kB 41.0 41.0 41.0 41.0 ... 36.98 36.98 36.98 │ * x (x) float64 39kB -109.1 -109.1 -109.1 ... -102.0 -102.0 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 987MB ... │ spatial_ref int32 4B ... ├── Group: /5 │ Dimensions: (time: 9, band: 2, y: 1400, x: 2448) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 11kB 41.0 41.0 41.0 40.99 ... 36.99 36.98 36.98 │ * x (x) float64 20kB -109.1 -109.1 -109.1 ... -102.0 -102.0 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 247MB ... │ spatial_ref int32 4B ... ├── Group: /6 │ Dimensions: (time: 9, band: 2, y: 700, x: 1224) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 6kB 41.0 41.0 40.99 40.98 ... 36.99 36.99 36.98 │ * x (x) float64 10kB -109.1 -109.1 -109.1 ... -102.1 -102.0 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 62MB ... │ spatial_ref int32 4B ... ├── Group: /7 │ Dimensions: (time: 9, band: 2, y: 350, x: 612) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 3kB 41.0 40.99 40.97 40.96 ... 37.01 37.0 36.99 │ * x (x) float64 5kB -109.1 -109.1 -109.0 ... -102.1 -102.1 -102.0 │ Data variables: │ embeddings (time, band, y, x) float32 15MB ... │ spatial_ref int32 4B ... ├── Group: /8 │ Dimensions: (time: 9, band: 2, y: 175, x: 306) │ Coordinates: │ * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 │ * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... │ * y (y) float64 1kB 40.99 40.97 40.95 40.92 ... 37.04 37.01 36.99 │ * x (x) float64 2kB -109.1 -109.0 -109.0 ... -102.1 -102.1 -102.1 │ Data variables: │ embeddings (time, band, y, x) float32 4MB ... │ spatial_ref int32 4B ... └── Group: /9 Dimensions: (time: 9, band: 2, y: 88, x: 153) Coordinates: * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 * band (band) StringDType() 32B 'difference_alpha_earth_cosine_dist... * y (y) float64 704B 40.98 40.93 40.89 40.84 ... 37.07 37.03 36.98 * x (x) float64 1kB -109.1 -109.0 -109.0 ... -102.2 -102.1 -102.1 Data variables: embeddings (time, band, y, x) float32 969kB ... spatial_ref int32 4B ...xarray.DataTree/0(6)Dimensions:time: 9band: 2y: 44800x: 78336Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 41.0 41.0 … 36.98 36.98units :metersstandard_name :projection_y_coordinatearray([41.003663, 41.003573, 41.003483, ..., 36.979498, 36.979408, 36.979318],shape=(44800,))x(x)float64-109.1 -109.1 … -102.0 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.077928, -109.077839, -109.077749, ..., -102.041188, -102.041098,-102.041008], shape=(78336,))Data variables: (2)embeddings(time, band, y, x)float32…raster:histogram :[{‘count’: 256, ‘min’: -453.6422424316406, ‘max’: 1552.254150390625, ‘buckets’: [1, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 1, 1, 0, 0, 3, 0, 4, 5, 7, 2, 4, 5, 2, 9, 12, 19, 15, 23, 24, 28, 45, 67, 80, 103, 167, 301, 411, 731, 1247, 2265, 4825, 10898, 30131, 105677, 586428, 9241259, 21155882067, 6458720426, 141842195, 20581637, 6126534, 2475655, 1188362, 635136, 369947, 226262, 143658, 92272, 62053, 42110, 30694, 21947, 16372, 12457, 9650, 7272, 5705, 4679, 3559, 2871, 2342, 1962, 1666, 1430, 1127, 903, 790, 680, 636, 482, 432, 339, 332, 295, 258, 210, 170, 135, 170, 165, 124, 93, 89, 63, 81, 76, 55, 76, 63, 38, 53, 44, 31, 28, 19, 40, 24, 17, 25, 27, 19, 15, 17, 19, 18, 10, 10, 10, 4, 10, 7, 7, 4, 5, 8, 3, 6, 3, 1, 3, 6, 1, 4, 4, 0, 4, 2, 9, 3, 0, 3, 1, 2, 0, 8, 3, 1, 1, 0, 8, 0, 3, 4, 5, 0, 0, 0, 3, 2, 2, 2, 1, 3, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 2, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1], ‘index’: {‘band’: 0}}, {‘count’: 256, ‘min’: -2419.623046875, ‘max’: 16685.6171875, ‘buckets’: [2, 0, 0, 0, 3, 0, 2, 0, 1, 3, 4, 2, 1, 1, 2, 1, 2, 6, 2, 6, 7, 10, 11, 12, 21, 53, 83, 165, 461, 1381, 7820, 331440, 31261242551, 10735198, 734657, 158052, 53459, 22328, 11132, 6140, 3758, 2266, 1447, 1093, 731, 612, 434, 326, 236, 189, 171, 139, 93, 106, 91, 63, 54, 53, 33, 21, 16, 15, 25, 14, 18, 22, 15, 5, 17, 14, 14, 11, 5, 6, 11, 1, 12, 3, 5, 0, 2, 3, 1, 3, 0, 0, 2, 7, 1, 0, 5, 0, 2, 0, 0, 1, 3, 0, 2, 3, 0, 0, 1, 0, 0, 0, 0, 1, 2, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1], ‘index’: {‘band’: 1}}][63170150400 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 8.983111749216732e-05 0.0 41.00370749308155 0.0 -8.983111749927275e-05[1 values with dtype=int32]/1(6)Dimensions:time: 9band: 2y: 22400x: 39168Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 41.0 41.0 … 36.98 36.98units :metersstandard_name :projection_y_coordinatearray([41.003618, 41.003438, 41.003258, ..., 36.979723, 36.979543, 36.979363],shape=(22400,))x(x)float64-109.1 -109.1 … -102.0 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.077884, -109.077704, -109.077524, ..., -102.041412, -102.041232,-102.041053], shape=(39168,))Data variables: (2)embeddings(time, band, y, x)float32…[15792537600 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.00017966223498433465 0.0 41.00370749308155 0.0 -0.0001796622349985455[1 values with dtype=int32]/2(6)Dimensions:time: 9band: 2y: 11200x: 19584Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 41.0 41.0 … 36.98 36.98units :metersstandard_name :projection_y_coordinatearray([41.003528, 41.003169, 41.002809, ..., 36.980172, 36.979812, 36.979453],shape=(11200,))x(x)float64-109.1 -109.1 … -102.0 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.077794, -109.077434, -109.077075, ..., -102.041861, -102.041502,-102.041143], shape=(19584,))Data variables: (2)embeddings(time, band, y, x)float32…[3948134400 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.0003593244699686693 0.0 41.00370749308155 0.0 -0.000359324469997091[1 values with dtype=int32]/3(6)Dimensions:time: 9band: 2y: 5600x: 9792Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 41.0 41.0 … 36.98 36.98units :metersstandard_name :projection_y_coordinatearray([41.003348, 41.00263 , 41.001911, ..., 36.98107 , 36.980351, 36.979633],shape=(5600,))x(x)float64-109.1 -109.1 … -102.0 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.077614, -109.076895, -109.076177, ..., -102.04276 , -102.042041,-102.041322], shape=(9792,))Data variables: (2)embeddings(time, band, y, x)float32…[987033600 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.0007186489399373386 0.0 41.00370749308155 0.0 -0.000718648939994182[1 values with dtype=int32]/4(6)Dimensions:time: 9band: 2y: 2800x: 4896Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 41.0 41.0 … 36.98 36.98units :metersstandard_name :projection_y_coordinatearray([41.002989, 41.001552, 41.000114, ..., 36.982867, 36.981429, 36.979992],shape=(2800,))x(x)float64-109.1 -109.1 … -102.0 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.077255, -109.075817, -109.07438 , ..., -102.044556, -102.043119,-102.041682], shape=(4896,))Data variables: (2)embeddings(time, band, y, x)float32…[246758400 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.0014372978798746772 0.0 41.00370749308155 0.0 -0.001437297879988364[1 values with dtype=int32]/5(6)Dimensions:time: 9band: 2y: 1400x: 2448Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 41.0 41.0 … 36.98 36.98units :metersstandard_name :projection_y_coordinatearray([41.00227 , 40.999396, 40.996521, ..., 36.98646 , 36.983585, 36.980711],shape=(1400,))x(x)float64-109.1 -109.1 … -102.0 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.076536, -109.073662, -109.070787, ..., -102.048149, -102.045275,-102.0424 ], shape=(2448,))Data variables: (2)embeddings(time, band, y, x)float32…[61689600 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.0028745957597493543 0.0 41.00370749308155 0.0 -0.002874595759976728[1 values with dtype=int32]/6(6)Dimensions:time: 9band: 2y: 700x: 1224Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 41.0 40.99 … 36.99 36.98units :metersstandard_name :projection_y_coordinatearray([41.000833, 40.995084, 40.989335, ..., 36.993646, 36.987897, 36.982148],shape=(700,))x(x)float64-109.1 -109.1 … -102.0 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.075099, -109.06935 , -109.0636 , ..., -102.055336, -102.049587,-102.043838], shape=(1224,))Data variables: (2)embeddings(time, band, y, x)float32…[15422400 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.005749191519498709 0.0 41.00370749308155 0.0 -0.005749191519953456[1 values with dtype=int32]/7(6)Dimensions:time: 9band: 2y: 350x: 612Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6441.0 40.99 40.97 … 37.0 36.99units :metersstandard_name :projection_y_coordinatearray([40.997958, 40.98646 , 40.974962, ..., 37.008019, 36.996521, 36.985023],shape=(350,))x(x)float64-109.1 -109.1 … -102.1 -102.0units :metersstandard_name :projection_x_coordinatearray([-109.072224, -109.060726, -109.049227, ..., -102.069709, -102.058211,-102.046712], shape=(612,))Data variables: (2)embeddings(time, band, y, x)float32…[3855600 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.011498383038997417 0.0 41.00370749308155 0.0 -0.011498383039906912[1 values with dtype=int32]/8(6)Dimensions:time: 9band: 2y: 175x: 306Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6440.99 40.97 40.95 … 37.01 36.99units :metersstandard_name :projection_y_coordinatearray([40.992209, 40.969212, 40.946216, 40.923219, 40.900222, 40.877225,40.854229, 40.831232, 40.808235, 40.785238, 40.762241, 40.739245,40.716248, 40.693251, 40.670254, 40.647258, 40.624261, 40.601264,40.578267, 40.555271, 40.532274, 40.509277, 40.48628 , 40.463283,40.440287, 40.41729 , 40.394293, 40.371296, 40.3483 , 40.325303,40.302306, 40.279309, 40.256313, 40.233316, 40.210319, 40.187322,40.164326, 40.141329, 40.118332, 40.095335, 40.072338, 40.049342,40.026345, 40.003348, 39.980351, 39.957355, 39.934358, 39.911361,39.888364, 39.865368, 39.842371, 39.819374, 39.796377, 39.773381,39.750384, 39.727387, 39.70439 , 39.681393, 39.658397, 39.6354 ,39.612403, 39.589406, 39.56641 , 39.543413, 39.520416, 39.497419,39.474423, 39.451426, 39.428429, 39.405432, 39.382435, 39.359439,39.336442, 39.313445, 39.290448, 39.267452, 39.244455, 39.221458,39.198461, 39.175465, 39.152468, 39.129471, 39.106474, 39.083478,39.060481, 39.037484, 39.014487, 38.99149 , 38.968494, 38.945497,38.9225 , 38.899503, 38.876507, 38.85351 , 38.830513, 38.807516,38.78452 , 38.761523, 38.738526, 38.715529, 38.692533, 38.669536,38.646539, 38.623542, 38.600545, 38.577549, 38.554552, 38.531555,38.508558, 38.485562, 38.462565, 38.439568, 38.416571, 38.393575,38.370578, 38.347581, 38.324584, 38.301587, 38.278591, 38.255594,38.232597, 38.2096 , 38.186604, 38.163607, 38.14061 , 38.117613,38.094617, 38.07162 , 38.048623, 38.025626, 38.00263 , 37.979633,37.956636, 37.933639, 37.910642, 37.887646, 37.864649, 37.841652,37.818655, 37.795659, 37.772662, 37.749665, 37.726668, 37.703672,37.680675, 37.657678, 37.634681, 37.611684, 37.588688, 37.565691,37.542694, 37.519697, 37.496701, 37.473704, 37.450707, 37.42771 ,37.404714, 37.381717, 37.35872 , 37.335723, 37.312727, 37.28973 ,37.266733, 37.243736, 37.220739, 37.197743, 37.174746, 37.151749,37.128752, 37.105756, 37.082759, 37.059762, 37.036765, 37.013769,36.990772])x(x)float64-109.1 -109.0 … -102.1 -102.1units :metersstandard_name :projection_x_coordinatearray([-109.066475, -109.043478, -109.020481, ..., -102.098455, -102.075458,-102.052461], shape=(306,))Data variables: (2)embeddings(time, band, y, x)float32…[963900 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.022996766077994835 0.0 41.00370749308155 0.0 -0.022996766079813824[1 values with dtype=int32]/9(6)Dimensions:time: 9band: 2y: 88x: 153Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)StringDType()‘difference_alpha_earth_cosine_d…array(['difference_alpha_earth_cosine_distance_robust_time_zscore','loo_medoid_alpha_earth_cosine_distance_robust_time_zscore'],dtype=StringDType())y(y)float6440.98 40.93 40.89 … 37.03 36.98units :metersstandard_name :projection_y_coordinatearray([40.980711, 40.934717, 40.888724, 40.84273 , 40.796737, 40.750743,40.70475 , 40.658756, 40.612762, 40.566769, 40.520775, 40.474782,40.428788, 40.382795, 40.336801, 40.290808, 40.244814, 40.198821,40.152827, 40.106834, 40.06084 , 40.014847, 39.968853, 39.922859,39.876866, 39.830872, 39.784879, 39.738885, 39.692892, 39.646898,39.600905, 39.554911, 39.508918, 39.462924, 39.416931, 39.370937,39.324944, 39.27895 , 39.232957, 39.186963, 39.140969, 39.094976,39.048982, 39.002989, 38.956995, 38.911002, 38.865008, 38.819015,38.773021, 38.727028, 38.681034, 38.635041, 38.589047, 38.543054,38.49706 , 38.451066, 38.405073, 38.359079, 38.313086, 38.267092,38.221099, 38.175105, 38.129112, 38.083118, 38.037125, 37.991131,37.945138, 37.899144, 37.853151, 37.807157, 37.761163, 37.71517 ,37.669176, 37.623183, 37.577189, 37.531196, 37.485202, 37.439209,37.393215, 37.347222, 37.301228, 37.255235, 37.209241, 37.163248,37.117254, 37.07126 , 37.025267, 36.979273])x(x)float64-109.1 -109.0 … -102.1 -102.1units :metersstandard_name :projection_x_coordinatearray([-109.054977, -109.008983, -108.96299 , -108.916996, -108.871003,-108.825009, -108.779015, -108.733022, -108.687028, -108.641035,-108.595041, -108.549048, -108.503054, -108.457061, -108.411067,-108.365074, -108.31908 , -108.273087, -108.227093, -108.1811 ,-108.135106, -108.089112, -108.043119, -107.997125, -107.951132,-107.905138, -107.859145, -107.813151, -107.767158, -107.721164,-107.675171, -107.629177, -107.583184, -107.53719 , -107.491197,-107.445203, -107.399209, -107.353216, -107.307222, -107.261229,-107.215235, -107.169242, -107.123248, -107.077255, -107.031261,-106.985268, -106.939274, -106.893281, -106.847287, -106.801294,-106.7553 , -106.709307, -106.663313, -106.617319, -106.571326,-106.525332, -106.479339, -106.433345, -106.387352, -106.341358,-106.295365, -106.249371, -106.203378, -106.157384, -106.111391,-106.065397, -106.019404, -105.97341 , -105.927416, -105.881423,-105.835429, -105.789436, -105.743442, -105.697449, -105.651455,-105.605462, -105.559468, -105.513475, -105.467481, -105.421488,-105.375494, -105.329501, -105.283507, -105.237513, -105.19152 ,-105.145526, -105.099533, -105.053539, -105.007546, -104.961552,-104.915559, -104.869565, -104.823572, -104.777578, -104.731585,-104.685591, -104.639598, -104.593604, -104.54761 , -104.501617,-104.455623, -104.40963 , -104.363636, -104.317643, -104.271649,-104.225656, -104.179662, -104.133669, -104.087675, -104.041682,-103.995688, -103.949695, -103.903701, -103.857708, -103.811714,-103.76572 , -103.719727, -103.673733, -103.62774 , -103.581746,-103.535753, -103.489759, -103.443766, -103.397772, -103.351779,-103.305785, -103.259792, -103.213798, -103.167805, -103.121811,-103.075817, -103.029824, -102.98383 , -102.937837, -102.891843,-102.84585 , -102.799856, -102.753863, -102.707869, -102.661876,-102.615882, -102.569889, -102.523895, -102.477902, -102.431908,-102.385914, -102.339921, -102.293927, -102.247934, -102.20194 ,-102.155947, -102.109953, -102.06396 ])Data variables: (2)embeddings(time, band, y, x)float32…[242352 values with dtype=float32]spatial_ref()int32…crs_wkt :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]GeoTransform :-109.07797340998921 0.04599353215598967 0.0 41.00370749308155 0.0 -0.04599353215962765[1 values with dtype=int32]Attributes: (10)zarr_conventions :[{‘uuid’: ‘d35379db-88df-4056-af3a-620245f8e347’, ‘name’: ‘multiscales’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-conventions/multiscales/refs/tags/v1/schema.json’}, {‘uuid’: ‘f17cb550-5864-4468-aeb7-f3180cfb622f’, ‘name’: ‘proj:’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-experimental/geo-proj/refs/tags/v1/schema.json’}, {‘uuid’: ‘689b58e2-cf7b-45e0-9fff-9cfc0883d6b4’, ‘name’: ‘spatial:’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-conventions/spatial/refs/tags/v1/schema.json’}]multiscales :{‘layout’: [{‘asset’: ‘0’, ‘transform’: {‘scale’: [1.0, 1.0], ‘translation’: [0.0, 0.0]}, ‘spatial:shape’: [44800, 78336], ‘spatial:transform’: [8.983111749216732e-05, 0.0, -109.07797340998921, 0.0, -8.983111749927275e-05, 41.00370749308155]}, {‘asset’: ‘1’, ‘transform’: {‘scale’: [2.0, 2.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘0’, ‘spatial:shape’: [22400, 39168], ‘spatial:transform’: [0.00017966223498433465, 0.0, -109.07797340998921, 0.0, -0.0001796622349985455, 41.00370749308155]}, {‘asset’: ‘2’, ‘transform’: {‘scale’: [4.0, 4.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘1’, ‘spatial:shape’: [11200, 19584], ‘spatial:transform’: [0.0003593244699686693, 0.0, -109.07797340998921, 0.0, -0.000359324469997091, 41.00370749308155]}, {‘asset’: ‘3’, ‘transform’: {‘scale’: [8.0, 8.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘2’, ‘spatial:shape’: [5600, 9792], ‘spatial:transform’: [0.0007186489399373386, 0.0, -109.07797340998921, 0.0, -0.000718648939994182, 41.00370749308155]}, {‘asset’: ‘4’, ‘transform’: {‘scale’: [16.0, 16.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘3’, ‘spatial:shape’: [2800, 4896], ‘spatial:transform’: [0.0014372978798746772, 0.0, -109.07797340998921, 0.0, -0.001437297879988364, 41.00370749308155]}, {‘asset’: ‘5’, ‘transform’: {‘scale’: [32.0, 32.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘4’, ‘spatial:shape’: [1400, 2448], ‘spatial:transform’: [0.0028745957597493543, 0.0, -109.07797340998921, 0.0, -0.002874595759976728, 41.00370749308155]}, {‘asset’: ‘6’, ‘transform’: {‘scale’: [64.0, 64.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘5’, ‘spatial:shape’: [700, 1224], ‘spatial:transform’: [0.005749191519498709, 0.0, -109.07797340998921, 0.0, -0.005749191519953456, 41.00370749308155]}, {‘asset’: ‘7’, ‘transform’: {‘scale’: [128.0, 128.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘6’, ‘spatial:shape’: [350, 612], ‘spatial:transform’: [0.011498383038997417, 0.0, -109.07797340998921, 0.0, -0.011498383039906912, 41.00370749308155]}, {‘asset’: ‘8’, ‘transform’: {‘scale’: [256.0, 256.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘7’, ‘spatial:shape’: [175, 306], ‘spatial:transform’: [0.022996766077994835, 0.0, -109.07797340998921, 0.0, -0.022996766079813824, 41.00370749308155]}, {‘asset’: ‘9’, ‘transform’: {‘scale’: [512.0, 512.0], ‘translation’: [0.0, 0.0]}, ‘derived_from’: ‘8’, ‘spatial:shape’: [88, 153], ‘spatial:transform’: [0.04599353215598967, 0.0, -109.07797340998921, 0.0, -0.04599353215962765, 41.00370749308155]}], ‘resampling_method’: ‘average’}proj:code :EPSG:4326proj:wkt2 :GEOGCRS[“WGS 84”,ENSEMBLE[“World Geodetic System 1984 ensemble”,MEMBER[“World Geodetic System 1984 (Transit)”],MEMBER[“World Geodetic System 1984 (G730)”],MEMBER[“World Geodetic System 1984 (G873)”],MEMBER[“World Geodetic System 1984 (G1150)”],MEMBER[“World Geodetic System 1984 (G1674)”],MEMBER[“World Geodetic System 1984 (G1762)”],MEMBER[“World Geodetic System 1984 (G2139)”],MEMBER[“World Geodetic System 1984 (G2296)”],ELLIPSOID[“WGS 84”,6378137,298.257223563,LENGTHUNIT[“metre”,1]],ENSEMBLEACCURACY[2.0]],PRIMEM[“Greenwich”,0,ANGLEUNIT[“degree”,0.0174532925199433]],CS[ellipsoidal,2],AXIS[“geodetic latitude (Lat)”,north,ORDER[1],ANGLEUNIT[“degree”,0.0174532925199433]],AXIS[“geodetic longitude (Lon)”,east,ORDER[2],ANGLEUNIT[“degree”,0.0174532925199433]],USAGE[SCOPE[“Horizontal component of 3D system.”],AREA[“World.”],BBOX[-90,-180,90,180]],ID[“EPSG”,4326]]spatial:dimensions :[‘y’, ‘x’]spatial:registration :pixelspatial:transform_type :affinespatial:shape :[44800, 78336]spatial:transform :[8.983111749216732e-05, 0.0, -109.07797340998921, 0.0, -8.983111749927275e-05, 41.00370749308155]spatial:bbox :[-109.07797340998921, 36.97927342911413, -102.0409629901228, 41.00370749308155] Using the multiscales convention and building on carbonplan’s zarr-layer, we can visualize the nine-year mosaic. If the viewer below is not working, try fullscreen mode here. Examples of Changes in Boulder, Colorado The video below shows the normalized change scores around Boulder, Colorado. It is a quick qualitative pass rather than a formal validation exercise, but several patterns stand out more clearly once the scores are viewed over time. Takeaways and Next Steps This follow-up suggests that leave-one-out medoid scoring, combined with robust time-wise normalization, is more useful for inspecting AEF change signal than raw distance alone. The normalization makes change magnitude more comparable across pixels, while the leave-one-out medoid highlights anomalous signal across the full observation window rather than only between adjacent time steps. This does not make AEF embeddings a complete change-detection product, but it does provide a clearer and more consistent way to identify which years look unusual at each pixel. That matters because AEF operates at a spatial and temporal resolution where many changes are subtle, cumulative, or mixed with recurring seasonal variation. A normalized score does not solve interpretation by itself, but it makes the first-pass search for interesting change much more practical. In this notebook, we used run_mosaics_change on the RasterFlow Remote client to compute change scores from the global AEF mosaic, built a multiscales derivative for browser-based exploration, and reviewed several examples around Boulder. Followup work may include using the embeddings to also help filter the object types of interest for taking yet another step closer towards a more complete change-detection product, especially where we have external labels or stronger domain priors. If you are interested in this approach, reach out to the Wherobots team at support@wherobots.com. For a complementary approach aggregating embeddings at the field level, see Zonal Statistics on AlphaEarth Embeddings. Get Started with RasterFlow START BUILDING Frequently Asked Questions What is leave-one-out medoid scoring for AlphaEarth embeddings? For a pixel’s time series of embeddings, the LOO medoid at time tk is the distance from that year’s embedding to the medoid of all other years. The medoid is the remaining embedding that minimizes total distance to the others.Larger scores mean that year is less consistent with the rest of the series. It is less sensitive to outliers than a simple average, which matters with only nine annual observations. How do you run AEF change detection in RasterFlow? Call run_mosaics_change on the RasterFlow Remote client with the Source Cooperative AEF mosaic URI and a bounding-box selector for the region (Colorado in this post). Set score_methods DIFFERENCE and LOO_MEDOID, distance_metric ALPHA_EARTH_COSINE, and robust_time_zscore=True. Then build_zarr_multiscales for browser exploration. How large is the global AlphaEarth Foundations Zarr mosaic? xarray reports 3.81 PiB with dimensions time=9, band=64, y=1,859,584, x=4,009,984, in about 1.02 billion chunks. For this demo, only land-intersecting chunks are present, the dataset is sharded into nine spatial chunks, and the analysis subsets Colorado. Is this a production change-detection product? No. The author states it is not a definitive benchmark. The goal is a clearer first-pass search for unusual years at each pixel.Follow-up work mentioned includes using embeddings to filter object types of interest where external labels or domain priors exist. --- ## AlphaEarth Embeddings, Zonal Statistics, and PCA URL: https://wherobots.com/blog/alphaearth-embeddings-zonal-statistics/ Updated: 2026-10-19 Author: Len Strnad AlphaEarth Foundations embeddings can be useful at the pixel level when the task is tightly local, such as inspecting boundaries, fine-scale heterogeneity, or small spatial disturbances. But many practical workflows need signals that stay meaningful after aggregation, whether to fields, parcels, patches, or other management units. Zonal statistics provide a simple way to test that idea: aggregate embeddings within field polygons and ask whether the field-level vectors still preserve interpretable structure. Key takeawaysMean AlphaEarth Foundations embeddings were computed for about 3.5 million Iowa fields (3,516,044 rows) across 2023–2025, then projected to RGB using the first three PCA components. The result is a GeoParquet dataset at s3://wherobots-examples/rasterflow/vectors/iowa_aef_zonal_stats/.The experimental zonal-statistics workflow (rayzon) computed zonal stats for about 3 million Iowa fields across three years in roughly five minutes. It ran without tuning on a Ray cluster with eight workers and 16 cores per worker.Each row has a field geometry, a 64-element mean embedding, and a 3-element pca_components list used as RGB. The dataset is Hive-partitioned on time (2023-01-01, 2024-01-01, 2025-01-01) and label (field).Field polygons come from Fields of the World predictions vectorized at a 0.5 threshold.PCA scatter of 20,000 sampled fields shows three broad clusters (purples, yellow-greens, blues) that may correspond to crop type or management practice. That is encouraging evidence for lightweight field-level analysis with simple models, not proof a downstream classifier will work. In this notebook, we compute mean AlphaEarth Foundations (AEF) embeddings for about 3.5 million Iowa fields across 2023-2025, then project those field-level vectors into RGB using the first three PCA components. The result is a GeoParquet dataset we can inspect spatially and compare across fields. The main takeaway is straightforward: the aggregated embeddings form visible clusters that may correspond to crop type or management practice. That does not prove a downstream classifier will work, but it is encouraging evidence that zonal AEF summaries could support lightweight field-level analysis with simple models rather than per-pixel inference. RasterFlow Tools Used RasterFlow is Wherobots’ serverless inference engine for Earth Observation data. It builds inference-ready mosaics from remote sensing data and runs distributed workflows at scale. This notebook uses four capabilities: build_and_predict_mosaic_recipe on the RasterFlow Remote client for building a mosaic and running inference using the Fields of the World model. vectorize_mosaic on the RasterFlow Remote client for converting field predictions from raster mosaics into GeoParquet. An experimental zonal-statistics workflow for aggregating AEF embeddings over field geometries. An experimental PCA workflow for appending the first three components for visualization. Global Zarr AEF Mosaic For this analysis, we use the global AlphaEarth Foundations Zarr mosaic hosted on Source Cooperative. Thanks to Taylor Geospatial and Source Cooperative for publishing the dataset in a form that can be accessed lazily with standard Python tooling. The mosaic stores annual AEF embeddings at 10-meter resolution in EPSG:4326, with nine temporal snapshots from 2017 through 2025. Working from one global store keeps the workflow simple: we can subset Iowa, compute field-level summaries, and publish a derived product without assembling local inputs. import xarray as xr ds = xr.open_zarr("s3://us-west-2.opendata.source.coop/tge-labs/aef-mosaic/", consolidated=False) ds Size: 4PB Dimensions: (time: 9, band: 64, y: 1859584, x: 4009984) Coordinates: * time (time) int32 36B 2017 2018 2019 2020 2021 2022 2023 2024 2025 * band (band) object 512B 'A00' 'A01' 'A02' 'A03' ... 'A61' 'A62' 'A63' * y (y) float64 15MB 83.69 83.69 83.69 ... -83.36 -83.36 -83.36 * x (x) float64 32MB -180.0 -180.0 -180.0 ... 180.2 180.2 180.2 Data variables: embeddings (time, band, y, x) int8 4PB dask.array Attributes: (12/15) proj:code: EPSG:4326 spatial:dimensions: ['y', 'x'] spatial:transform: [8.983111749910169e-05, 0.0, -180.0, 0.0, -8.983... spatial:transform_type: affine spatial:bbox: [-180.0, -83.36280346631479, 180.2213438735178, ... spatial:shape: [1859584, 4009984] ... ... geoemb:model: https://developers.google.com/earth-engine/datas... geoemb:source_data: https://source.coop/tge-labs/aef/v1/annual/ geoemb:data_type: int8 geoemb:gsd: 8.983111749910169e-05 geoemb:quantization: {'method': 'signed_square', 'original_dtype': 'f... zarr_conventions: [{'uuid': 'f17cb550-5864-4468-aeb7-f3180cfb622f'...xarray.DatasetDimensions:time: 9band: 64y: 1859584x: 4009984Coordinates: (4)time(time)int322017 2018 2019 … 2023 2024 2025_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025], dtype=int32)band(band)object‘A00’ ‘A01’ ‘A02’ … ‘A62’ ‘A63’_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array(['A00', 'A01', 'A02', 'A03', 'A04', 'A05', 'A06', 'A07', 'A08', 'A09', 'A10', 'A11', 'A12', 'A13', 'A14', 'A15', 'A16', 'A17', 'A18', 'A19', 'A20', 'A21', 'A22', 'A23', 'A24', 'A25', 'A26', 'A27', 'A28', 'A29', 'A30', 'A31', 'A32', 'A33', 'A34', 'A35', 'A36', 'A37', 'A38', 'A39', 'A40', 'A41', 'A42', 'A43', 'A44', 'A45', 'A46', 'A47', 'A48', 'A49', 'A50', 'A51', 'A52', 'A53', 'A54', 'A55', 'A56', 'A57', 'A58', 'A59', 'A60', 'A61', 'A62', 'A63'], dtype=object)y(y)float6483.69 83.69 83.69 … -83.36 -83.36_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([ 83.68566 , 83.685571, 83.685481, ..., -83.362579, -83.362669, -83.362759], shape=(1859584,))x(x)float64-180.0 -180.0 … 180.2 180.2_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’}array([-179.999955, -179.999865, -179.999775, ..., 180.221119, 180.221209, 180.221299], shape=(4009984,))Data variables: (1)embeddings(time, band, y, x)int8dask.array_zarrs :{‘description’: ‘This array was created with zarrs’, ‘repository’: ‘https://github.com/zarrs/zarrs’, ‘version’: ‘0.23.0’} Array Chunk Bytes 3.81 PiB 4.00 MiB Shape (9, 64, 1859584, 4009984) (1, 64, 256, 256) Dask graph 1024049664 chunks in 2 graph layers Data type int8 numpy.ndarray 9 1 4009984 1859584 64 Attributes: (15)proj:code :EPSG:4326spatial:dimensions :[‘y’, ‘x’]spatial:transform :[8.983111749910169e-05, 0.0, -180.0, 0.0, -8.983111749910169e-05, 83.68570533713473]spatial:transform_type :affinespatial:bbox :[-180.0, -83.36280346631479, 180.2213438735178, 83.68570533713473]spatial:shape :[1859584, 4009984]spatial:registration :pixelgeoemb:type :pixelgeoemb:dimensions :64geoemb:model :https://developers.google.com/earth-engine/datasets/catalog/GOOGLE_SATELLITE_EMBEDDING_V1_ANNUALgeoemb:source_data :https://source.coop/tge-labs/aef/v1/annual/geoemb:data_type :int8geoemb:gsd :8.983111749910169e-05geoemb:quantization :{‘method’: ‘signed_square’, ‘original_dtype’: ‘float32’, ‘quantized_dtype’: ‘int8’, ‘formula’: ‘(x / 127.5) ** 2 * sign(x)’, ‘valid_range’: [-127, 127], ‘nodata’: -128}zarr_conventions :[{‘uuid’: ‘f17cb550-5864-4468-aeb7-f3180cfb622f’, ‘name’: ‘proj:’, ‘description’: ‘Coordinate reference system information for geospatial data’, ‘spec_url’: ‘https://github.com/zarr-experimental/geo-proj/blob/v1/README.md’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-experimental/geo-proj/refs/tags/v1/schema.json’}, {‘uuid’: ‘689b58e2-cf7b-45e0-9fff-9cfc0883d6b4’, ‘name’: ‘spatial:’, ‘description’: ‘Spatial coordinate information’, ‘spec_url’: ‘https://github.com/zarr-conventions/spatial/blob/v1/README.md’, ‘schema_url’: ‘https://raw.githubusercontent.com/zarr-conventions/spatial/refs/tags/v1/schema.json’}, {‘uuid’: ’61c12cc5-0e28-4056-999a-480cf3fb7e4c’, ‘name’: ‘geoemb:’, ‘description’: ‘Geo-embeddings metadata for machine learning embeddings stored in Zarr’, ‘spec_url’: ‘https://github.com/geo-embeddings/embeddings-zarr-convention/tree/add-convention’}] At first glance, 3.81 PiB and 1,024,049,664 chunks in S3 sound impractically large. For this demo, a few details keep the workflow manageable: only land-intersecting chunks are present the dataset is sharded into nine spatial chunks, which lowers the effective object count we subset Iowa rather than operating on the full global mosaic This mosaic is the same one used in Change Detection Using AlphaEarth Foundations (Part 2). Zonal Statistics Experimental Workflow We use rayzon, a side project I built to compute zonal statistics using Ray. Without tuning, it computes zonal statistics for about 3 million Iowa fields across three years in roughly five minutes on a Ray cluster with eight workers and 16 cores per worker. It also supports t-digest-backed quantile estimation for statistics beyond mean, min, and max, though that path is still experimental. If this workflow is relevant to your team, let us know so we can prioritize productizing this type of analysis in RasterFlow. Zonal Statistics Results Using that workflow, we compute mean zonal statistics for Iowa fields across three years of the global AEF Zarr mosaic. The resulting GeoParquet is published at s3://wherobots-examples/rasterflow/vectors/iowa_aef_zonal_stats/ for anyone who wants to inspect it. import pyarrow.parquet as pq ds = pq.ParquetDataset("s3://wherobots-examples/rasterflow/vectors/iowa_aef_zonal_stats/") ds.schema geometry: binary score_mean: float score_std: float source_store: string local_x_offset: int64 local_y_offset: int64 global_x_offset: int64 global_y_offset: int64 path: string feature_id: int64 bbox: struct child 0, xmax: double child 1, xmin: double child 2, ymax: double child 3, ymin: double mean: list child 0, element: double pca_components: list child 0, element: float hilbert_key: int64 time: dictionary label: dictionary -- schema metadata -- geo: '{"version": "1.1.0", "primary_column": "geometry", "columns": {"geo' + 1808 The schema exposes three columns of interest: geometry: the geometry of each field, with one row per field mean: a 64-element list containing the mean value for each AEF embedding dimension within the field pca_components: a 3-element list containing the first three PCA components of each mean embedding, used here as RGB channels for visualization We also partition the dataset using a Hive-style layout on time and label. In this example, label is always field; the model also produces field_boundaries and non_field, but those classes are not the focus here. # what are the partitioning keys? ds.partitioning.dictionaries [ [ "2023-01-01", "2024-01-01", "2025-01-01" ], [ "field" ]] The output contains about 3.5 million Iowa fields across the 2023-2025 period. sum([fragment.count_rows() for fragment in ds.fragments]) 3516044 Visualizing Confidences The dataset also includes score_mean, the mean model confidence over each polygonized field. Because fields are formed from contiguous pixels above the vectorization threshold, this gives us a compact way to inspect how confident the model was within each extracted geometry. Here we use the 0.5 threshold from vectorize_mosaic. If the viewer below is not working, try fullscreen mode here. We can see a great deal of variance in the confidence scores between fields, which can provide some critical feedback for modeling efforts and help guide stratefied sampling for well-balaned training sets. Visualizing Zonal Statistics of Mean Embeddings with PCA We also visualize each field’s mean AEF embedding by mapping the first three PCA components to RGB in GeoParquet. If the viewer below is not working, try fullscreen mode here. The map shows clear color clustering, especially purples, yellow-greens, and blues. To check whether that spatial pattern is reflected numerically, we next plot the first two PCA components in a scatter plot. import pandas as pd import matplotlib.pyplot as plt df = pd.read_parquet( "s3://wherobots-examples/rasterflow/vectors/iowa_aef_zonal_stats/", columns=["pca_components"], ) sample = df.sample(n=20000) sample["pca_1"] = sample["pca_components"].apply(lambda x: x[0]) sample["pca_2"] = sample["pca_components"].apply(lambda x: x[1]) sample["pca_3"] = sample["pca_components"].apply(lambda x: x[2]) sample.plot.scatter( x="pca_1", y="pca_2", c=sample["pca_components"].tolist(), alpha=0.5, figsize=(10, 8) ) # overlay 2d density plot plt.hexbin(sample["pca_1"], sample["pca_2"], gridsize=50, cmap='Greys', alpha=0.2, marginals=True) # add normalized density to plt.title("PCA Components Colored by (3) PCA Components") plt.xlabel("PCA Component 1") plt.ylabel("PCA Component 2") plt.show() We see three broad clusters in the 2D PCA scatter plot, and the cluster colors align with the RGB visualization above. The purple and green groups appear tighter than the yellow group, but the overall separation is still encouraging. That suggests a simple linear probe on top of the AEF embeddings may be able to distinguish field types or management patterns without manual feature engineering or complex models. Beyond classification, AEF may also be useful for stratified sampling, supervised training set design, or in situ analysis of field management practices. Takeaways and Next Steps Aggregated AEF embeddings remain informative at field scale, not just pixel scale. The zonal-statistics workflow scales to millions of fields and hundreds of millions of pixels on a modest Ray cluster. GeoParquet and a single global Zarr mosaic work well together for this style of analysis. Field-level confidence scores provide an additional quality signal alongside the embeddings. The PCA visualization shows clear clustering that may relate to crop type or management practice and is worth testing with labeled data. For change detection applications using the same embeddings, see Change Detection Using AlphaEarth Foundations (Part 2) and How Agricultural Fields Change in AlphaEarth Foundations. If you are interested in this approach, reach out to the Wherobots team at support@wherobots.com. Sign up for RasterFlow Preview Get Started Frequently Asked Questions Can you aggregate AlphaEarth embeddings to agricultural fields? Yes. This notebook computes the mean 64-dimension AEF embedding inside each field polygon. Aggregated embeddings still form visible clusters at field scale, which is the main takeaway: zonal AEF summaries can stay informative after aggregation, not only at the pixel level. How fast is zonal statistics on millions of Iowa fields? Without tuning, rayzon computed zonal statistics for about 3 million Iowa fields across three years in roughly five minutes. It ran on a Ray cluster with eight workers and 16 cores per worker. The published GeoParquet contains 3,516,044 rows for 2023–2025. How are AEF field embeddings visualized? The first three PCA components of each field’s mean embedding are mapped to RGB in GeoParquet and shown on a map. A 20,000-point scatter of PCA 1 vs PCA 2, colored by those three components, shows three broad clusters whose colors align with the map. Where can I download the Iowa AEF zonal statistics? The GeoParquet is published at s3://wherobots-examples/rasterflow/vectors/iowa_aef_zonal_stats/. Schema highlights: geometry, mean (64-element list), pca_components (3-element list), score_mean (mean Fields of the World model confidence), partitioned by time and label. --- ## Introducing the Wherobots Python SDK URL: https://wherobots.com/blog/wherobots-python-sdk/ Updated: 2026-10-19 What is the Wherobots Python SDK? The Wherobots Python SDK is a typed Python client for submitting, monitoring, and managing Wherobots job runs. It ships on PyPI as wherobots-python-sdk. One install, one API key, and you’re running spatial jobs from any Python environment: CI/CD pipelines, notebooks, a local shell. Key takeawaysThe Wherobots Python SDK is a typed Python client for submitting, monitoring, and managing Wherobots job runs. It ships on PyPI as wherobots-python-sdk.One install and one API key let jobs run from CI/CD, notebooks, Step Functions, or a local shell.The only runtime dependency is requests, and user code needs no AWS credentials and no bucket configuration. Local scripts upload through Wherobots API presigned URLs.Scripts that already live in an S3 Storage Integration can be referenced by S3 URI with auto_upload=False.WherobotsJob is the single class today: point it at a script, give it a name and runtime, call submit(), then wait_for_completion(stream_logs=True). Status is COMPLETED, FAILED, or CANCELLED, and constructor validation raises WherobotsValidationError before any network call.Design constraints: HTTPS only (HTTP rejected at init), no redirect following, API keys masked in repr(), path-traversal defense on uploads, and POST requests are never retried. Typed dataclass models, JobStatus and Runtime enums, and a PEP 561 py.typed marker are included. The SDK is built for three workflows. Engineers wiring spatial jobs into production pipelines. Data scientists iterating on a Wherobots script and streaming logs back to the terminal. Ops leads watching what’s running across the organization. Wherobots Python SDK Use Cases Wherobots customers run spatial workloads on a cadence: mapping platformsrefreshes OSM-derived road networks every morning before downstream pipelines fire. Ag-tech teams pull Sentinel-2, compute NDVI, and join it to millions of crop boundaries every five days. Each of these is a Wherobots job that requires uploading scripts to shared storage, wiring up an Airflow DAG, and managing the operator that called the Runs REST API. The Wherobots Python SDK is the shorter path. One install, one API key, and three lines of Python submit a job from any environment that runs Python: a CI/CD pipeline, AWS Step Functions, a notebook, a local shell. The jobs module of the SDK assembles three workflows customers were already trying to assemble by hand. Scheduled spatial data products Mapping and data-provider customers refresh Overture, OSM, or Sentinel-derived datasets on a fixed cadence. The output is a versioned Iceberg or GeoParquet table that downstream teams query directly. With the SDK, the entire refresh is a Python function that runs on cron, GitHub Actions, or AWS EventBridge. No Airflow cluster to host. No operator package to install. Orchestrator-invoked jobs from Step Functions, Prefect, or Dagster Several Wherobots customers run their broader ETL in AWS Step Functions or Prefect and treat Wherobots as one task in a longer chain. The SDK gives those orchestrators a clean Python interface to submit a Wherobots job, wait for completion, and pass the output URI to the next step. A single call replaces the boilerplate of presigned uploads, polling, and log retrieval. CI/CD-driven analytics for production spatial pipelines Engineers maintaining property climate risk pipelines, mobility joins, or agricultural monitoring jobs want their spatial code to ship through the same review and deploy path as the rest of the codebase. The SDK fits a standard pattern: commit a script to GitHub, run tests in CI, deploy by submitting a job from the runner with WherobotsJob.submit(). Logs stream back to the build output. Failed jobs fail the build. The rest of this post walks through install, the WherobotsJob API, dependency management, and the security model. Install the Wherobots Python SDK pip install wherobots-python-sdk export WHEROBOTS_API_KEY="your-api-key" The only runtime dependency is requests. No AWS credentials, no bucket configuration. The WherobotsJob class The SDK exposes a single class today: WherobotsJob. Point it at a script, give the job a name, and call .submit(). Submit a job and stream logs from wherobots import WherobotsJob job = WherobotsJob( script="etl_pipeline.py", name="nightly-etl", runtime="large", ) job.submit() status = job.wait_for_completion(stream_logs=True) print(f"Finished with status: {status.value}") That’s the full lifecycle. The SDK uploads local scripts to Wherobots-managed storage via presigned URLs, polls for completion, and streams logs back to your terminal. When wait_for_completion returns, you get a JobStatus enum: COMPLETED, FAILED, or CANCELLED. Only an API key. No AWS credentials, no bucket setup. Pass arguments and configuration Real jobs need arguments, Spark configuration, and dependencies. Pass them through the constructor: job = WherobotsJob( script="spatial_join.py", name="q4-spatial-join", runtime="x-large-himem", timeout_seconds=7200, args=["--input", "s3://bucket/parcels/", "--output", "s3://bucket/results/"], spark_configs={ "spark.sql.shuffle.partitions": "200", "spark.executor.memory": "8g", }, dependencies=[ WherobotsJob.add_pypi_dependency("geopandas", "0.14.0"), WherobotsJob.add_file_dependency("s3://bucket/libs/custom_udfs.whl"), ], ) The SDK validates inputs at construction time. Bad runtime names, missing JAR main classes, negative disk sizes, and empty scripts all raise WherobotsValidationError before a single network call leaves the client. List and filter runs A WherobotsJob instance isn’t required to query your organization’s job runs: from wherobots import WherobotsJob, JobStatus page = WherobotsJob.list_runs( status=[JobStatus.FAILED], name_pattern="etl-*", size=10, ) for run in page.items: print(f"{run.id} {run.name} {run.status}") Cancel jobs and handle errors from wherobots import WherobotsJob, WherobotsTimeoutError job = WherobotsJob(script="long_running.py", name="cancellable-job") job.submit() try: status = job.wait_for_completion(max_wait_seconds=600) except WherobotsTimeoutError: job.cancel() print("Job cancelled after timeout") The exception hierarchy is flat. WherobotsAPIError carries the HTTP status code and request ID for debugging. WherobotsValidationError catches bad inputs at construction time. WherobotsTimeoutError fires when max_wait_seconds is exceeded. All three inherit from WherobotsJobError, so a single except block catches everything when you need it to. Run scripts from your S3 storage integrations If your script already lives in a Wherobots S3 Storage Integration, reference it directly by S3 URI and skip the upload step: job = WherobotsJob( script="s3://my-integration-bucket/scripts/pipeline.py", name="pipeline-job-001", runtime="small", auto_upload=False, ) Discover your integration paths programmatically: from wherobots.api.files import FilesAPI from wherobots.config import WherobotsConfig config = WherobotsConfig.from_env() with FilesAPI.from_config(config) as files_api: for si in files_api.list_integrations(): print(f"{si.name}: {si.path} ({si.region})") Design Principles The SDK is opinionated in four ways: requests is the only runtime dependency. No Pydantic, no boto3, no heavy frameworks. Install footprint stays small. Presigned uploads only. Local scripts go up through Wherobots API presigned URLs. No AWS credentials in user code, ever. Type-safe throughout. Typed dataclass models for every API response, JobStatus and Runtime enums, and a PEP 561 py.typed marker for downstream mypy users. Security-first defaults. HTTPS only (HTTP rejected at init). No redirect following, which prevents auth header leaks. API keys masked in repr(). Path traversal defense on uploads. POST requests are never retried. Getting Started pip install wherobots-python-sdk export WHEROBOTS_API_KEY="your-api-key" # Submit a job and watch it run python -c " from wherobots import WherobotsJob job = WherobotsJob(script='my_script.py', name='first-job', runtime='tiny') job.submit() job.wait_for_completion(stream_logs=True) " Source: github.com/wherobots/wherobots-python-sdk. Available now on PyPI: pip install wherobots-python-sdk. Start Building with Wherobots Get Started Frequently Asked Questions What is the Wherobots Python SDK? A typed Python client, published as wherobots-python-sdk, for submitting, monitoring, and managing Wherobots job runs. It is built for engineers wiring spatial jobs into production pipelines, data scientists iterating on a script with streamed logs, and ops leads listing runs across the organization. How do I submit a Wherobots job from Python? pip install wherobots-python-sdk, export WHEROBOTS_API_KEY, then construct WherobotsJob(script=…, name=…, runtime=…), call submit(), and wait_for_completion(stream_logs=True). You can pass args, spark_configs, timeout_seconds, and dependencies (PyPI packages or S3 wheels). Do I need AWS credentials to use the Wherobots Python SDK? No. The only runtime dependency is requests, and local scripts go up through Wherobots API presigned URLs. If the script already lives in a Wherobots S3 Storage Integration, pass the S3 URI and set auto_upload=False. Can I replace Airflow with the Wherobots Python SDK? For scheduled spatial data products, the post describes the SDK as the shorter path: a Python function on cron, GitHub Actions, or EventBridge, with no Airflow cluster or operator package. Customers who already orchestrate in Step Functions, Prefect, or Dagster can submit a Wherobots job, wait, and pass the output URI to the next step. --- ## Detecting Objects From Text Prompts with RasterFlow and Segment Anything 3 URL: https://wherobots.com/blog/sam3-earth-observation-rasterflow/ Updated: 2026-10-19 RasterFlow now Supports Detections from Text! RasterFlow now makes it simple to run promptable geospatial vision models across large aerial and satellite imagery collections, removing the need to build bespoke inference pipelines. With our new SAM 3 support, you can prompt for concepts like “roofs”, “roads”, or “shipping containers” and turn those detections into vector outputs ready for analysis in Wherobots, from city scale to country scale. Key takeawaysRasterFlow now supports SAM 3 promptable concept segmentation: text prompts such as ‘roofs’, ‘roads’, or ‘shipping containers’ produce vector outputs from aerial and satellite mosaics. SAM 3 accepts spatial prompts or text, and it was pretrained on overhead imagery, unlike SAM 1/2.On Marion County NAIP 30 cm, build_gti_mosaic billed 11 minutes 47 seconds and wrote a 133.08 GB Zarr mosaic (~114.15 km × 66.81 km). The predict_mosaic_geometries step billed 39 minutes 51 seconds and wrote 263.85 MB of GeoParquet.Eight labels were prompted in one pass at confidence_threshold 0.5.SAM 3 localizes roofs well on the NAIP basemap and segments roads reasonably, with room for improvement. Niche classes such as tractors and shipping containers show clear precision and recall gaps, including rectangular roofs labeled as shipping containers.What used to take a mix of imagery ETL, bespoke inference pipelines, and self-provisioned infrastructure now takes under an hour and two Python functions: build_gti_mosaic then predict_mosaic_geometries. Detections load into WherobotsDB as GeoParquet for ST_AreaSpheroid, counts, and PMTiles via vtiles.generate_pmtiles. Here we see SAM 3 localize and capture roofs really well. It also segments roads pretty cleanly, though there is still room for improvement. Results are shown on the inference input, a NAIP 30 centimeter basemap, and include all instance pixels above 50% confidence. In this post, we put SAM 3 to the test detecting roofs in suburban neighborhoods, shipping containers in crowded loading docks, and tractors across agricultural landscapes. Throughout, we comment on where it succeeds, where it falls short, and how results compare to previous SAM models. Finally, we discuss what’s next for computer vision in Earth observation (EO) and how the community can build on models like SAM to create more promptable, flexible applications that handle the scale and diversity of remote sensing imagery. How Segment Anything Model 3 Improves on SAM 1 and SAM 2 for Remote Sensing In 2023, the Segment Anything Model (SAM) set a new paradigm for computer vision. While most models were trained to address one task at a time, SAM demonstrated that a single model could reliably classify, localize, and segment many kinds of objects in complex natural scenes. SAM set a new standard task for computer vision models that went beyond classification or semantic segmentation: Promptable Visual Segmentation (PVS), which takes spatial prompts such as boxes, points, or masks as input and predicts masks. However, SAM 1’s performance on out-of-distribution imagery domains had issues. Back in 2023, while I was working on detection projects with 10 meter resolution imagery, I found it often took multiple rounds of prompting to get useful segments, and many results still needed manual cleanup. For example, in a rural town, SAM 1 can segment many features across different spatial scales, but it still misses all roads. SAM 1 segments many features across different spatial scales in Dikwa, Nigeria, but still misses roads. SAM 2 improved accuracy and added video support, but both SAM 1 and SAM 2 were limited to making predictions without associated labels. The masks they produced were not grounded in categories useful for deriving insights. Fast forward to today: SAM 3 addresses Promptable Concept Segmentation (PCS), a task where a model can accept either spatial prompts (masks, boxes, pixels) or text prompts like “cat”, “dog”, even “roofs”! The SAM 3 architecture supports Promptable Concept Segmentation, accepting text and image exemplars in addition to spatial prompts to produce masks with labeled concepts. It also benefits from pretraining on overhead imagery. Source: YouTube. This opens up new possibilities for detecting objects in imagery. Because SAM 3’s training data spans many imaging domains, including overhead aerial imagery, it can succeed in many Earth observation contexts where previous model generations struggled. For example, one can use SAM 3 to predict “roofs” in NAIP imagery simply by asking, with no model training or ad hoc labeling needed, and get pretty stellar results. With RasterFlow, we can create imagery mosaics and predict roofs simply by prompting SAM 3 with short noun phrases like “roofs”. To put SAM 3 to the test on Earth observation imagery, we generated many more SAM 3 predictions on top of National Agriculture Program 30 centimeter imagery using RasterFlow, our scalable mosaic building and inference engine. Below details the performance of RasterFlow on this high resolution detection task. RasterFlow TaskBilled RuntimeOutputTotal Output SizeSpatial Scale of Outputbuild_gti_mosaic11m 47sNAIP Zarr mosaic133.08 GB (123.94 GiB)~114.15 km × 66.81 kmpredict_mosaic_geometries39m 51sGeoParquet geometry results263.85 MB (251.63 MiB)~111.02 km × 66.81 km See an AI agent take plain-language question and orchestrating pipelines to end results using RasterFlow and the Wherobots MCP server, check out the upcoming live session. See it in action Join us live How to Run SAM 3 on Aerial and Satellite Imagery with RasterFlow What used to take a complex mix of imagery ETL, bespoke inference pipelines, and self-provisioned infrastructure for large Earth observation processing now takes under an hour and two simple Python functions. Let’s check it out below. Build an Aerial Imagery Mosaic from NAIP First, we will generate a mosaic: a seamless, stitched-together image from many independent remote sensing scenes. RasterFlow handles all the data sourcing, loading, cleaning, and partitioning into a data asset optimized for inference for a particular model. from rasterflow_remote import RasterflowClient rf_client = RasterflowClient() mosaic_output = rf_client.build_gti_mosaic( gti="s3://wherobots-examples/rasterflow/indexes/naip_index.parquet", aoi="s3://wherobots-examples/rasterflow/aois/marion_county.parquet", bands=["red", "green", "blue", "nir"], location_field="url", crs_epsg=3857, time_column="year", skip_xy_coords=False, xy_chunksize=1024, query="res == 0.3 and time >= '2022-01-01' and time <= '2023-01-01'", requester_pays=True, sort_field="time", ) print(mosaic_output.uri) Run the SAM 3 Inference on the Mosaic With our mosaic built, we can now run inference with SAM 3. Unlike more rigid models which only predict one category, SAM 3 can accept one or more text prompts and detect all matching objects in a single pass. The runtime for a given batch of imagery scales linearly with the number of detections. More prompts tends to mean more detections, so keep in mind that the more prompts you add, the longer you can expect an inference run to take. from rasterflow_remote.data_models import GeometryActorEnum, MergeModeEnum model_output = rf_client.predict_mosaic_geometries( store="s3://wherobots-examples/rasterflow/mosaics/marion_county.zarr", model_path="https://huggingface.co/wherobots/sam3-text-geometry-pt2/resolve/main/full_sam3_pipeline.pt2", patch_size=1008, clip_size=0, device="cuda", features=["red", "green", "blue"], labels=["roads", "airplanes", "airports", "roofs", "solar panels", "swimming pools", "shipping containers", "tractors"], actor=GeometryActorEnum.TEXT_TO_VECTOR_GEOMETRIES, max_batch_size=1, confidence_threshold=0.5, merge_mode=MergeModeEnum.NONE, xy_block_multiplier=1, ) Analyze the SAM 3 Detections with WherobotsDB We can visualize both the mosaic and detections directly in the notebook with an embedded RasterFlow map. The RGB imagery mosaic and the SAM 3 detections have been web-optimized with RasterFlow for fast and fluid browsing. If the embed does not load in your environment, open it in a new tab here. After visually exploring detections, we can load the results into WherobotsDB for quantitative analysis. WherobotsDB lets us post-process geometries, calculate zonal statistics on other rasters, count objects, measure clustering, and much more. import os from sedona.spark import * from pyspark.sql.functions import * from wherobots import vtiles config = ( SedonaContext.builder() .getOrCreate() ) sedona = SedonaContext.create(config) parquet_path = "s3://wherobots-examples/rasterflow/model-outputs/marion_county_sam3/" df = sedona.read.format("geoparquet").load(parquet_path) df.printSchema() df.show(10) Here we’ll use ST_Area to estimate the total square km area of all roofs in Marion County. roofs_df = df.filter(col("label") == "roofs") source_srid = roofs_df.selectExpr("ST_SRID(geometry) AS srid").first()["srid"] source_crs = f"EPSG:{source_srid}" print(source_crs) # Run the SRID inspection cell above first so source_crs reflects the data's actual CRS. roof_areas = roofs_df.withColumn( "area_sq_m", expr(f"ST_AreaSpheroid(ST_Transform(geometry, '{source_crs}', 'EPSG:4326'))"), ).cache() roof_areas_agg = roof_areas.agg( sum("area_sq_m").alias("total_area_sq_m"), (sum("area_sq_m") / lit(1_000_000.0)).alias("total_area_sq_km"), ) roof_areas_agg.show(truncate=False) roof_size_stats = roof_areas.agg( count("*").alias("roof_count"), avg("area_sq_m").alias("avg_roof_sq_m"), expr("percentile_approx(area_sq_m, 0.5)").alias("median_roof_sq_m"), (avg("area_sq_m") * lit(10.7639)).alias("avg_roof_sq_ft"), ) stats = roof_size_stats.first() print(f"roof_count: {stats['roof_count']:,}") print(f"avg_roof_sq_m: {stats['avg_roof_sq_m']:.2f}") print(f"median_roof_sq_m: {stats['median_roof_sq_m']:.2f}") label_counts = df.groupBy("label").count().orderBy(col("count").desc(), col("label")) label_counts.show(truncate=False) We can also generate web-optimized vectors in PMTiles format. PMTiles are easily shareable and plug directly into geospatial visualization applications, making them a great choice for distributing detection results. df_tiles = df.withColumn("layer", col("label")) output_path = 's3://wherobots-examples/rasterflow/model-outputs/marion_county_sam3.pmtiles' vtiles.generate_pmtiles(df_tiles, output_path) SAM 3 Accuracy on Earth Observation: Where It Succeeds and Where It Falls Short After experimenting with SAM 3 on NAIP, I’m impressed with the range of categories that SAM 3 can positively identify. At the same time, the model still has clear precision and recall gaps for more niche semantic categories, like “tractors” or “shipping containers”. SAM 3 correctly detects tractors in a harvested field. In an agricultural context, SAM 3 finds some tractors but also misses some. SAM 3 correctly identifies shipping containers in a storage yard. False positives: SAM 3 labels rectangular roofs as “shipping containers”. These examples illustrate the gap between SAM 3’s strengths on common categories and its current limitations on more niche ones. I’m bullish that if SAM 3 were fine-tuned on a larger corpus of mixed high-resolution imagery and high-quality labels, it would perform even better outside of its primary domain of natural imagery. Even so, I think the potential for SAM 3 for simpler categories like “roofs” is underutilized. SAM 3 could potentially improve many existing datasets we rely on to make decisions, like Overture Buildings and detections of other kinds of structures. What to Try Next with SAM 3 on Wherobots Some things we didn’t showcase but I recommend trying in your experiments: Can you find and count vehicles that are a certain color? Can you use SAM 3 to segment city streets? What about rural roads? Try to map forest canopy! SAM 3 can do a pretty great job at segmenting concepts that don’t map cleanly to individual objects, but are more textural. For a larger-scale example of RasterFlow in production, see how RasterFlow processed 2.3B Overture Maps features for Fields of the World. If you’re excited to try SAM 3 on Wherobots, sign up for RasterFlow Private Preview. You can also get in touch at ryan@wherobots.com or talk to us here. I’d love to hear about what you’re looking to build and how SAM 3 could fit into your detection workflows. Try SAM3 on Wherobots START BUILDING Frequently Asked Questions How do you run SAM 3 on aerial imagery with RasterFlow? Build a mosaic with RasterflowClient.build_gti_mosaic (here, a NAIP index clipped to Marion County, RGB+NIR, EPSG:3857, 0.3 m, 2022–2023). Then call predict_mosaic_geometries with the SAM 3 text-to-vector model, patch_size 1008, CUDA, a list of text labels, confidence_threshold 0.5, and merge_mode NONE. Runtime for a batch scales linearly with the number of detections. How is SAM 3 different from SAM 1 and SAM 2 for remote sensing? SAM 1 and 2 did Promptable Visual Segmentation from boxes, points, or masks, and produced unlabeled masks. SAM 1 often needed multiple prompt rounds on 10 m imagery and still missed roads in the Dikwa, Nigeria example. SAM 3 does Promptable Concept Segmentation: text prompts like ‘roofs’ plus spatial prompts, with pretraining that includes overhead imagery. How long does county-scale SAM 3 inference take on RasterFlow? For this Marion County NAIP example, mosaic build billed 11m 47s (133.08 GB) and inference billed 39m 51s (263.85 MB GeoParquet). Combined, the two steps are under an hour. Where does SAM 3 fail on Earth observation imagery? The author is impressed with the range of categories SAM 3 can identify, but notes precision and recall gaps on niche classes. Examples: some tractors missed in agricultural scenes; rectangular roofs false-positive as shipping containers. Fine-tuning on mixed high-resolution imagery and labels is suggested as a path to improve those categories. --- ## Spatial Data Processing Platforms: A Comparison of Enterprise and Cloud-Native Options URL: https://wherobots.com/blog/spatial-data-processing-platforms/ Updated: 2026-10-19 For Data Engineers and Architects Evaluating Spatial Workloads on Snowflake, Databricks, and PostGIS Six platforms dominate spatial data processing today: PostGIS  for transactional workloads under 100GB, Snowflake and BigQuery GIS for light spatial enrichment inside a broader analytics platform, Databricks  for vector spatial joins on the Lakehouse, Apache Sedona for self-managed open-source distributed spatial compute, and Wherobots for production raster and vector workflows at scale. The right choice depends on whether spatial is a side feature of your data work or the foundation of your product. Key takeawaysSix platforms dominate the comparison. PostGIS fits transactional workloads under 100 GB, and Snowflake and BigQuery GIS fit light spatial enrichment inside a broader analytics platform.Databricks fits vector spatial joins on the Lakehouse, self-managed Apache Sedona gives full control, and Wherobots fits production raster and vector workflows at scale.PostGIS is the two-decade industry standard but vertically scales only. A utility processing 500 GB of infrastructure data with frequent spatial joins will hit memory limits.Snowflake has ~80 spatial functions and weak raster support. Databricks Native Spatial SQL has 80+ functions and is serverless for vector, but production-grade raster is not in the native product today (Mosaic is deprecated).BigQuery GIS is geography-only on a WGS84 sphere (~50 functions), with no R-tree indexes and weak raster.WherobotsDB plus RasterFlow process satellite imagery, zonal statistics, and raster algebra in the same query engine, with 300+ spatial functions. SpatialBench SF1000 results cited: 3x faster spatial query performance and 46% lower cost than general-purpose cloud data warehouses.Treating PostGIS as a scalable cloud analytics layer is described as the most common mistake teams make with it.Wherobots is Apache Sedona, managed, serverless, and optimized, so Sedona APIs lift and shift without rewriting code. BYOS is offered in Enterprise. If you’re processing billions of spatial records, running expensive zonal statistics, or optimizing complex spatial joins in Snowflake and watching bills climb while performance stalls, this comparison is for you. Spatial data processing has fundamentally changed. Traditional approaches (PostGIS, desktop GIS) do not scale. Modern data warehouses (Snowflake, BigQuery) added spatial as a feature, not a foundation. The cost-performance gap is wider than most teams realize Three Architectures for Spatial Data Processing Three architectural approaches dominate: Traditional Spatial Databases (PostGIS, SQL Server Spatial) General-Purpose Cloud Data Platforms (Snowflake, Databricks, BigQuery) Purpose-Built Spatial Compute (Wherobots, Apache Sedona) Each has a place. The right system depends on your workload, data volume, and whether spatial analysis is central to your business or a side feature. How to Choose a Spatial Data Processing Platform Use this table as a starting point. The detailed comparison for each platform follows below. For each platform’s documented raster, vector, Python and MCP support, see the cloud geospatial platform comparison. PlatformBest ForAvoid ifPostGISDatasets under 100GBYou need distributed scaleSnowflakeSpatial as a minor enrichment step (<5% of workload)Spatial is core to your productDatabricksVector spatial joins on the LakehouseYou need production raster processingBigQuery GISSimple spatial queries on GCPYou need precision coordinate systemsApache SedonaFull control, on-premises deploymentYou lack dedicated Spark engineersWherobotsRaster and vector at scale, serverlessSpatial is incidental to your workload PostGIS (Traditional Spatial Database): Best for datasets under 100GB What it is: PostgreSQL extension for spatial operations. The industry standard for two decades. Best for: Teams already on PostgreSQL Transactional spatial applications (routing, geocoding services) Datasets under 100GB Organizations with strong Postgres DBA expertise Tradeoffs: Vertical scaling only. Distributing PostGIS across a cluster requires third-party tools (Citus, etc.). No native cloud-native format support. Reading GeoParquet or Cloud Optimized GeoTIFFs requires extensions or ETL. Raster processing is limited. PostGIS Raster exists but isn’t designed for large-scale raster analytics. Cost grows linearly. More performance requires bigger instances. A utility company processing 500GB of infrastructure data with frequent spatial joins will hit memory limits. You’ll end up partitioning manually, managing indexes carefully, and eventually looking for distributed alternatives. That is the ceiling. Most teams reach this limit sooner than they planned for. PostGIS is rock-solid for traditional GIS applications but wasn’t architected for cloud-scale distributed spatial analytics. PostGIS is not going anywhere, and it should not. Treating PostGIS as a scalable cloud analytics layer is the most common mistake teams make with it. Snowflake with Geospatial Support: Good for Casual Spatial Queries What it is: Cloud data warehouse with geometry/geography types and ~80 spatial functions. Best for: Organizations already standardized on Snowflake Spatial operations as 5-10% of total workload Point-in-polygon lookups, geocoding enrichment Teams prioritizing unified data platform over spatial performance Tradeoffs: Cost grows quickly on heavy spatial workloads. Spatial joins in Snowflake are expensive. A medium warehouse running complex polygon overlays or zonal statistics consumes thousands of credits. Limited spatial optimization. Snowflake’s architecture wasn’t designed for spatial partitioning or distributed spatial indexing. Weak raster support. No native raster data types or analysis functions. You’re on your own for satellite imagery or elevation analysis. Performance vs. specialized engines. Snowflake’s columnar architecture is not optimized for spatial predicates, so heavy spatial SQL workloads run materially slower than on purpose-built engines. A logistics company enriching 10M shipment records with census tract data (point-in-polygon join) will see reasonable performance. Daily overlay analysis on 100M parcels against zoning boundaries spirals in cost fast. The point-in-polygon job works. The moment you scale it, the bill shows up. Snowflake spatial works for casual spatial queries in a broader analytics platform. If spatial is core to your workload, you’re paying general-purpose pricing for a workload that benefits from purpose-built optimization. Databricks with Native Spatial SQL: Strong for Vector, Not Yet for Raster What it is: Native spatial support built into Databricks Runtime and SQL Serverless with GEOMETRY and GEOGRAPHY data types and 80+ spatial functions. Databricks Mosaic, the earlier open-source library, is deprecated. Native Spatial SQL is the current recommended approach. Best for: Teams already on Databricks Lakehouse Vector spatial processing at scale with serverless execution Organizations wanting distributed spatial joins without managing Spark clusters Data science workflows requiring spatial features alongside ML pipelines Key capabilities: Native GEOMETRY/GEOGRAPHY types with automatic bounding box statistics 80+ spatial SQL functions for constructing, transforming, measuring, and analyzing geometries Serverless execution available in Databricks SQL (no cluster management) Tradeoffs: Raster support is limited. Native Spatial SQL excels at vector processing, but production-grade raster analysis (satellite imagery, zonal statistics on elevation data, raster algebra) is not available in the native product today. Databricks is still gathering requirements for raster capabilities. Complexity for non-Databricks shops. If you’re not already invested in the Databricks ecosystem, onboarding requires understanding Delta Lake, Unity Catalog, and Lakehouse architecture. Cost for light spatial users. Like Snowflake, if spatial represents <5% of your workload, Databricks’ full platform might be overkill. A real estate analytics team processing 200M parcel boundaries against flood zones, zoning maps, and census tracts runs distributed spatial joins in Databricks SQL Serverless with automatic optimization. Performance is strong for vector-only workflows. Teams that need to overlay satellite imagery for vegetation analysis or run zonal statistics on elevation rasters wait for native raster support or build workarounds. Databricks native Spatial SQL is a major step forward for vector spatial processing on the Lakehouse. It is serverless and eliminates the operational complexity of managing Spark clusters. For workflows where raster analysis is central, it is not production-ready today. BigQuery GIS: A Fit for Simple Spatial Queries in GCP What it is: Google’s spatial extension for BigQuery with geography types and ~50 spatial functions. Best for: Organizations on Google Cloud Simple spatial queries at scale (geocoding, distance calculations) Integration with Earth Engine or Google Maps Platform Tradeoffs: Geography-only model (spherical geometry). No projected coordinate systems. All calculations happen on WGS84 sphere, problematic for local coordinate systems or precision work. Limited spatial indexing. BigQuery doesn’t support R-trees or spatial indexes like PostGIS. Performance depends on BigQuery’s columnar architecture, which isn’t optimized for spatial predicates. Weak raster support. Like Snowflake, no native raster data types. You can use Google EarthEngine connected to BigQuery for Zonal Stats on Raster data, but beyond this you need to customize heavily with bespoke services. A GCP-native team geocoding 50 million addresses or running distance calculations between delivery points will get the job done. The moment you need precision coordinate systems, complex polygon overlays at volume, or anything raster-related, you will start looking for alternatives. GCP teams running heavy raster or precision-coordinate work often pair BigQuery with a specialized engine for those workloads. BigQuery GIS handles simple spatial enrichment well within a GCP data warehouse. Heavy or precision spatial workloads usually move to a specialized engine. Apache Sedona Self-Managed: The Deepest Open-Source Spatial Engine What it is: Open-source distributed spatial engine built on Apache Spark. The foundation that powers Wherobots and formerly powered Databricks Mosaic. Best for: Teams with Spark expertise who want full control Organizations requiring on-premises deployment Custom spatial algorithm development Tradeoffs: You manage everything. Cluster provisioning, version upgrades, performance tuning, dependency management. No serverless execution. Cold starts, idle cluster costs, and manual scaling. Operational burden. Unless you have dedicated Spark platform engineers, operational overhead is real. Performance gap vs. managed offerings. Self-managed Sedona lacks the query optimizations (Photon-style vectorization, R-tree indexing tuned for spatial predicates) that managed platforms ship by default. Community support only: there is a great Apache Sedona community that we support and encourage grwoth, but if you want Enterprise support it’s best to come to Wherobots directly. Apache Sedona is the deepest open-source spatial engine available. Self-managing it makes sense only when you have the team and infrastructure already in place, and even then, managed alternatives deliver real performance advantages. Note that if you are a heavy Spark team but want full Enterprise support with advanced capabilities beyond Apache Sedona, but 100% API compatibility, we offer WherobotsDB Bring Your Own Spark (BYOS) as an option within our Enterprise tier at Wherobots. Note: Wherobots offers a drop in replacement for Apache Sedona that can run in any spark infrastructure, WherobotsDB “Bring Your Own Spark”. This option sits between the Managed Compute version of Wherobots Cloud (below) and Apache Sedona. For customers who want to bring their Apache Sedona pipelines to Enterprise Support, this option is a great way to get started with us. You can learn more about it here and explore all that it has to offer, and contact us if you would like access to it. Wherobots: Purpose-Built Spatial Compute for Raster and Vector at Scale What it is: The Context Engine for Physical World Data. A fully managed, serverless spatial compute platform built by the original creators of Apache Sedona, the most widely deployed distributed spatial engine in the world. Why it exists: General-purpose platforms treat spatial as a feature, not a foundation. Wherobots architects every layer, from storage to compute to query optimization, specifically for spatial workflows across both vector and raster data. Best for: Heavy spatial ETL and analytics workloads combining vector, raster and tabular data Organizations processing hundreds of millions or billions of spatial records Teams running complex spatial joins, overlay analysis, and zonal statistics regularly Companies hitting cost or performance walls in Snowflake or need raster capabilities missing in Databricks Production-grade raster and vector processing at scale Key capabilities: Full vector and raster support. WherobotsDB and RasterFlow process satellite imagery, run zonal statistics, and perform raster algebra in the same query engine. 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations, compared to roughly one raster function in BigQuery GIS. Production-ready today for both vector and raster workflows. Benchmark-validated performance. SpatialBench SF1000 results: 3x faster spatial query performance and 46% lower cost than general-purpose cloud data warehouses. Purpose-built spatial optimization. Distributed spatial indexing, spatial partitioning, and query optimization designed specifically for geometry and raster operations. Built by the Apache Sedona creators who understand spatial at the engine level. True serverless spatial compute. No cluster management, instant cold starts, scale-to-zero billing. You write Spatial SQL, Wherobots handles execution. Cloud-native format optimized. Reads GeoParquet, Cloud Optimized GeoTIFFs, Zarr, PMTiles natively. No ETL overhead. Apache Sedona compatibility. Wherobots is Apache Sedona, but managed, serverless, and optimized with performance enhancements. Use familiar APIs without operational overhead. Wherobots vs. Apache Sedona: What is the Difference? Apache Sedona is the open-source engine. Wherobots is Sedona managed, serverless, and performance-optimized. The core spatial APIs are identical. Wherobots adds the infrastructure layer: no cluster provisioning, instant scaling, and query optimizations the team built specifically for production spatial workflows. Teams already running Sedona lift and shift their workloads to Wherobots without rewriting code. A climate analytics company processing daily satellite imagery updates (50GB+ of COGs) with vector boundaries for wildfire risk zones. The team needs both raster analysis (vegetation indices, temperature anomalies) and vector operations (overlay analysis, zonal statistics). Wherobots handles both in a single serverless workflow. Most general-purpose platforms require custom raster solutions or have no native raster support. Snowflake has no raster capabilities. That is not a workaround. That is the workflow running as designed. Wherobots is the only serverless, purpose-built spatial compute platform  with production-grade raster and vector support. If your workflows combine raster and vector and you are running them at volume, few platforms today handle both vector and raster in a single query engine without integration work. Decision Framework: Choosing Your Spatial Stack Use PostGIS if: You’re building a transactional spatial application Datasets are <100GB You need fine-grained control over indexes and query plans Use Snowflake/BigQuery if: Spatial is a minor enrichment step (<5% of workload) You’re already standardized on these platforms Queries are simple (geocoding, point-in-polygon lookups) Use Databricks if: You’re already on Databricks Lakehouse Vector spatial joins are your primary workload You want serverless spatial SQL with automatic optimization Raster processing is not required for your use cases Use Wherobots if: Raster and vector processing are both essential Spatial processing is core to your business (>20% of workload) You’re running complex spatial joins, overlay analysis, or zonal statistics You need production-grade raster analysis (satellite, climate, elevation) Cost or performance in current platforms is a pain point You want serverless spatial SQL optimized at every architectural layer How to Benchmark Spatial Performance Yourself Vendor performance claims are easy to make and hard to verify. SpatialBench is the open standard for benchmarking spatial query engines. It runs reproducible workloads (point-in-polygon, range queries, spatial joins, K-nearest neighbors) at multiple scale factors so you can compare engines on your own infrastructure. If you’re evaluating two or more platforms in this list, run SpatialBench on each before committing. Tell us what you’re building. We’ll show you what spatial processing at scale actually looks like for your workload. Talk to our team. Start Building with Wherobots Get Started Frequently Asked Questions PostGIS vs Snowflake vs Databricks vs Wherobots: which spatial platform should I use? Use PostGIS for transactional apps and datasets under 100 GB. Use Snowflake or BigQuery when spatial is a minor enrichment step (the post uses 20% of workload), or cost/performance in current platforms is a pain point. Does Databricks support raster processing? Native Spatial SQL excels at vector processing. Production-grade raster analysis (satellite imagery, zonal statistics on elevation, raster algebra) is not available in the native product today.Databricks is still gathering requirements for raster capabilities. Databricks Mosaic, the earlier library, is deprecated. What is the difference between Wherobots and Apache Sedona? Apache Sedona is the open-source engine. Wherobots is Sedona managed, serverless, and performance-optimized. Core spatial APIs are identical, so existing Sedona workloads lift and shift without rewriting code.Self-managed Sedona means you provision clusters, tune, and upgrade yourself, with community support and enterprise support via Wherobots. WherobotsDB Bring Your Own Spark sits between managed Wherobots Cloud and OSS Sedona. How should I benchmark spatial engines myself? SpatialBench is the open standard cited in the post. It runs reproducible workloads (point-in-polygon, range queries, spatial joins, K-nearest neighbors) at multiple scale factors. The post advises running SpatialBench on each candidate platform before committing. --- ## How We Delivered “Fields of The World” with RasterFlow: A Planetary-Scale GeoAI Pipeline URL: https://wherobots.com/blog/fields-of-the-world-rasterflow-geoai-pipeline/ Updated: 2026-10-19 Author: Len Strnad Fields of the World (FTW) is a Taylor Geospatial effort to produce globally consistent agricultural field-boundary data for land-use monitoring, food-system analysis, and model development. For the 2024-2025 global release, Taylor Geospatial partnered with Wherobots to run their latest FTW model, PRUE, on Wherobots RasterFlow; see the PRUE paper. Key takeawaysTaylor Geospatial partnered with Wherobots to run the PRUE model on RasterFlow for the 2024–2025 Fields of the World global release. PRUE turns seasonal Sentinel-2 composites into field and field_boundaries predictions; RasterFlow runs data access, compositing, inference, and vectorization as one workflow.The pipeline is three API calls: build_mosaic (planting and harvest Sentinel-2 median composites, 2023-01-01 to 2025-01-01, EPSG:4326), predict_mosaic, and vectorize_mosaic (field band, threshold 0.5). RasterFlow is backed by Flyte V2 and Ray, running in each organization's isolated namespace.Scale profile: feature COGs 153 TB (90,918 objects); feature Zarr mosaic 150 TB (363,999 objects, 7,499,140 logical chunks); prediction Zarr 45 TB (84,877 objects, 8,982,630 logical chunks).Vector GeoParquet is 675 GB (1,000 objects, 8,217,195,679 rows). Aggregate output is ~348.7 TB across 540,794 objects.The Zarr layout splits logical chunks from shards on purpose. Feature logical chunks (1, 1, 4096, 4096) are packed into (1, 1, 12288, 12288) shards.Prediction logical chunks (1, 1, 2048, 2048) are packed into (1, 3, 8192, 8192) shards covering all three class bands. That keeps regional reads precise without exploding object count. In this notebook, we walk through the production pipeline behind that release. The PRUE model turns seasonal Sentinel-2 composites into global field and field_boundaries predictions, and RasterFlow handles the larger systems problem: running data access, compositing, inference, and vectorization as one coordinated workflow and publishing the results as analysis-ready raster and vector products. The focus here is practical architecture rather than model internals. We cover how the pipeline is structured, what it produced at global scale, and the implementation choices that made the run reproducible. What we cover: RasterFlow and why it is designed for reproducible, scalable global runs. A Scale Profile with artifact sizes/object counts for this dataset. The RasterFlow workflow stages and resulting outputs: build_mosaic predict_mosaic vectorize_mosaic. Implementation notes in Appendix — Technical Notes. RasterFlow Execution Model for a Global-Scale GeoAI Pipeline This pipeline runs on RasterFlow, Wherobots’ planetary-scale inference engine for Earth Intelligence. RasterFlow provides a reproducible way to run a global-scale GeoAI pipeline. It is a geospatial workflow system backed by Flyte V2 and Ray. We chose Flyte because long-running global jobs need strong workflow semantics: versioned executions, retries, lineage, and reproducible reruns. We chose Ray Datasets because raster inference and vectorization are naturally blockwise workloads, and Ray gives us elastic parallelism and task streaming support to support the many small task problem. The rasterflow_remote client exposes common GeoAI workflow steps while running in each organization’s isolated namespace. As a result, resource controls, failure containment, and reruns stay scoped to that organization. We construct the client and load the model config for the PRUE model: from rasterflow_remote.model_registry import get_model_registry_config, ModelRegistryEnum from rasterflow_remote import RasterflowClient client = RasterflowClient() # see https://huggingface.co/wherobots/prue-pt2 for model details cfg = get_model_registry_config(ModelRegistryEnum.HUGGINGFACE, "wherobots/prue-pt2") Build Mosaic build_mosaic converts raw satellite scenes into analysis-ready feature mosaics on a shared grid. For the FTW production run, this stage computes planting and harvest composites, writes feature COGs, and then materializes a global feature mosaic that can be stacked with model outputs. We persist that global feature product in Zarr because chunked, cloud-native storage lets us read small spatial windows directly from object storage during validation, inference, and downstream analytics. from rasterflow_remote import DatasetEnum from datetime import datetime mosaic = client.build_mosaic( datasets=[DatasetEnum.S2_MED_PLANTING, DatasetEnum.S2_MED_HARVEST], aoi="https://github.com/fieldsoftheworld/ftw-inference-app/blob/main/src/data/s2-grid.json", start=datetime(2023, 1, 1), end=datetime(2025, 1, 1), crs_epsg=4326, ) For implementation details, see Appendix: Feature COG and Appendix: GDAL notes. Inspect the published feature mosaic The produced feature mosaic is published as a Zarr store on Source Cooperative. Therefore, we can inspect structure, bands, and a spatial subset directly. import xarray as xr import rasterix mosaic_ds = xr.open_zarr( "https://data.source.coop/ftw/global-data/features/zarr/alpha/global.zarr" ).pipe(rasterix.assign_index) mosaic_ds Size: 502TB Dimensions: (time: 2, band: 10, y: 1566049, x: 4007517) Coordinates: * time (time) datetime64[ns] 16B 2024-01-01 2025-01-01 * band (band) object 80B 's2med_harvest:B02' ... 's2med_planting:N_... * y (y) float64 13MB 83.75 83.75 83.75 ... -56.93 -56.93 -56.93 * x (x) float64 32MB -180.0 -180.0 -180.0 ... 180.0 180.0 180.0 spatial_ref int64 8B ... Data variables: variables (time, band, y, x) float32 502TB dask.array Indexes: ┌ x RasterIndex (crs=None) └ yxarray.DatasetDimensions:time: 2band: 10y: 1566049x: 4007517Coordinates: (5)time(time)datetime64[ns]2024-01-01 2025-01-01array(['2024-01-01T00:00:00.000000000', '2025-01-01T00:00:00.000000000'], dtype='datetime64[ns]')band(band)object‘s2med_harvest:B02’ … ‘s2med_p…array(['s2med_harvest:B02', 's2med_harvest:B03', 's2med_harvest:B04', 's2med_harvest:B08', 's2med_harvest:N_VALID_PIXELS', 's2med_planting:B02', 's2med_planting:B03', 's2med_planting:B04', 's2med_planting:B08', 's2med_planting:N_VALID_PIXELS'], dtype=object)y(y)float6483.75 83.75 83.75 … -56.93 -56.93[1566049 values with dtype=float64]x(x)float64-180.0 -180.0 … 180.0 180.0[4007517 values with dtype=float64]spatial_ref()int64…crs_wkt :GEOGCS[“WGS 84”,DATUM[“WGS_1984”,SPHEROID[“WGS 84”,6378137,298.257223563,AUTHORITY[“EPSG”,”7030″]],AUTHORITY[“EPSG”,”6326″]],PRIMEM[“Greenwich”,0,AUTHORITY[“EPSG”,”8901″]],UNIT[“degree”,0.0174532925199433,AUTHORITY[“EPSG”,”9122″]],AXIS[“Latitude”,NORTH],AXIS[“Longitude”,EAST],AUTHORITY[“EPSG”,”4326″]]semi_major_axis :6378137.0semi_minor_axis :6356752.314245179inverse_flattening :298.257223563reference_ellipsoid_name :WGS 84longitude_of_prime_meridian :0.0prime_meridian_name :Greenwichgeographic_crs_name :WGS 84horizontal_datum_name :World Geodetic System 1984grid_mapping_name :latitude_longitudespatial_ref :GEOGCS[“WGS 84”,DATUM[“WGS_1984”,SPHEROID[“WGS 84”,6378137,298.257223563,AUTHORITY[“EPSG”,”7030″]],AUTHORITY[“EPSG”,”6326″]],PRIMEM[“Greenwich”,0,AUTHORITY[“EPSG”,”8901″]],UNIT[“degree”,0.0174532925199433,AUTHORITY[“EPSG”,”9122″]],AXIS[“Latitude”,NORTH],AXIS[“Longitude”,EAST],AUTHORITY[“EPSG”,”4326″]][1 values with dtype=int64]Data variables: (1)variables(time, band, y, x)float32dask.array Array Chunk Bytes 456.64 TiB 64.00 MiB Shape (2, 10, 1566049, 4007517) (1, 1, 4096, 4096) Dask graph 7499140 chunks in 2 graph layers Data type float32 numpy.ndarray 2 1 4007517 1566049 10 Indexes: (1)xyRasterIndex (crs=None)RasterIndex(crs=None) AxisAffineTransformIndex(AxisAffineTransform(a=8.983e-05, b=0, c=-180, d=0, e=-8.983e-05, f=83.75, axis=X, dim='x')) AxisAffineTransformIndex(AxisAffineTransform(a=8.983e-05, b=0, c=-180, d=0, e=-8.983e-05, f=83.75, axis=Y, dim='y')) Persisting an intermediate global Zarr mosaic lets us query any region without reprojecting or resampling. Training data for the PRUE model is also aligned to EPSG:4326, so feature and prediction stores remain grid-compatible for side-by-side analysis. For data layout details, see Appendix: Zarr internals. For the examples below, we use the same Japan AOI shown later in the PMTiles preview so the raster and vector artifacts are easy to compare. For more information on xarray, see Appendix: Xarray notes. import matplotlib.pyplot as plt import numpy as np bbox = { "x": slice(140.24, 140.34), "y": slice(37.36, 37.26), } subset = mosaic_ds.sel(x=bbox["x"], y=bbox["y"]) geo_aspect = 1 / np.cos(np.deg2rad(float(subset.y.mean()))) fig, axes = plt.subplots(1, 2, figsize=(9, 9), constrained_layout=True) for ax, band_prefix, title in [ (axes[0], "s2med_planting", "Planting RGB (PMTiles AOI, 2025)"), (axes[1], "s2med_harvest", "Harvest RGB (PMTiles AOI, 2025)"), ]: subset["variables"].sel( time="2025-01-01", band=[f"{band_prefix}:B04", f"{band_prefix}:B03", f"{band_prefix}:B02"], ).plot.imshow(ax=ax, robust=True) ax.set_aspect(geo_aspect) ax.set_title(title) plt.show() See additional information in Appendix: Zarr internals and Appendix: Xarray notes. Predict Mosaic predict_mosaic runs global model inference over the feature mosaic and writes one prediction Zarr store. You provide the model config, and the workflow executes inference across the global grid. Keeping the result in Zarr preserves the same chunked access pattern as the feature store, so validation and downstream vectorization can stay blockwise and cloud-native instead of stitching regional outputs back together later. predictions = client.predict_mosaic( store="https://data.source.coop/ftw/global-data/features/zarr/alpha/global.zarr", model_path=cfg.model_path, patch_size=cfg.patch_size, clip_size=cfg.clip_size, device=cfg.device, features=cfg.features, labels=cfg.labels, actor=cfg.actor, max_batch_size=cfg.max_batch_size, merge_mode=cfg.merge_mode, ) For internals and scheduling details, see Appendix: config, Appendix: Ray usage, and Appendix: distributed inference. For a similar inference step using text-prompted detection instead of segmentation models, see how Segment Anything 3 runs on aerial imagery with RasterFlow. Inspect the published prediction mosaic The prediction Zarr is also published on Source Cooperative. Let’s verify shape, bands, and value ranges. The shape, bounds, and time remain aligned with the feature mosaic; however, the bands now represent predicted classes. pred_ds = xr.open_zarr( "https://data.source.coop/ftw/global-data/predictions/zarr/alpha/global.zarr" ).pipe(rasterix.assign_index) pred_ds Size: 151TB Dimensions: (time: 2, band: 3, y: 1566049, x: 4007517) Coordinates: * time (time) datetime64[ns] 16B 2024-01-01 2025-01-01 * band (band) Indexes: ┌ x RasterIndex (crs=None) └ yxarray.DatasetDimensions:time: 2band: 3y: 1566049x: 4007517Coordinates: (5)time(time)datetime64[ns]2024-01-01 2025-01-01array(['2024-01-01T00:00:00.000000000', '2025-01-01T00:00:00.000000000'], dtype='datetime64[ns]')band(band) Array Chunk Bytes 136.99 TiB 16.00 MiB Shape (2, 3, 1566049, 4007517) (1, 1, 2048, 2048) Dask graph 8982630 chunks in 2 graph layers Data type float32 numpy.ndarray 2 1 4007517 1566049 3 Indexes: (1)xyRasterIndex (crs=None)RasterIndex(crs=None) AxisAffineTransformIndex(AxisAffineTransform(a=8.983e-05, b=0, c=-180, d=0, e=-8.983e-05, f=83.75, axis=X, dim='x')) AxisAffineTransformIndex(AxisAffineTransform(a=8.983e-05, b=0, c=-180, d=0, e=-8.983e-05, f=83.75, axis=Y, dim='y')) Let’s plot the three labels for the same PMTiles-area AOI so the raster predictions line up with the vector preview later in the post: import numpy as np bbox = { "x": slice(140.24, 140.34), "y": slice(37.36, 37.26), } pred_subset = pred_ds.sel(x=bbox["x"], y=bbox["y"]) geo_aspect = 1 / np.cos(np.deg2rad(float(pred_subset.y.mean()))) grid = pred_subset["variables"].plot.imshow(col="band", row="time", figsize=(12, 8)) for ax in grid.axes.flat: ax.set_aspect(geo_aspect) plt.show() Zarr metadata for those curious is available in Appendix: Zarr internals. Vectorize Mosaic vectorize_mosaic converts prediction rasters into field-boundary GeoParquet outputs. You specify feature bands, threshold, and method. Then the workflow writes distributed vector outputs for analytics and downstream publishing. We write GeoParquet because it keeps the result columnar, splittable, and easy to consume from batch analytics systems. Conceptually, this output is a distributed geospatial table rather than an array: each row is a polygonized field candidate, the geometry column holds the boundary, and the remaining columns carry the scalar attributes you want to inspect in GeoPandas or query later in SedonaDB and WherobotsDB. For distributed implementation details, see Appendix: vectorization. from rasterflow_remote.data_models import VectorizeMethodEnum, SemSegRasterioConfig vectors = client.vectorize_mosaic( store="https://data.source.coop/ftw/global-data/predictions/zarr/alpha/global.zarr", features=["field"], threshold=0.5, vectorize_method=VectorizeMethodEnum.SEMANTIC_SEGMENTATION_RASTERIO, vectorize_config=SemSegRasterioConfig(stats=False, medial_skeletonize=False), ) A lightweight way to inspect that schema locally is: import geopandas as gpd vector_preview = gpd.read_parquet(vectors.uri) vector_preview.head(3) That gives you a normal GeoDataFrame view of the vector output: one geometry column plus the per-row attributes emitted by the vectorization stage. Implementation details for distributed/blockwise vectorization are in Appendix: vectorization. PMTiles PMTiles packages vector outputs for fast, interactive map delivery. We use it here because a single archive is easy to publish, cache, and stream into browser maps without standing up a tile service. We also support generating PMTiles from large GeoParquet outputs directly in WherobotsDB using our scalable PMTiles generator workflow, as described here: How to Generate PMTiles for Overture Maps with WherobotsDB VTiles. Scale Profile This section summarizes the scale of each pipeline step and the size of the generated outputs. Understanding the scale of this production run will help when we discuss design choices later in this blog post. ArtifactPipeline StepS3 LocationSizeObject CountAdditional Scale SignalFeature COGsbuild_mosaics3://us-west-2.opendata.source.coop/tge-labs/ftw-global-data/features/cogs/153 TB90,918Each COG is a median composite from ~5-10 Sentinel-2 scenes per pixelFeature Zarr mosaicbuild_mosaics3://us-west-2.opendata.source.coop/tge-labs/ftw-global-data/features/zarr/alpha/global.zarr150 TB363,9997,499,140 logical chunks (sharded to keep object count manageable)Prediction Zarr mosaicpredict_mosaics3://us-west-2.opendata.source.coop/tge-labs/ftw-global-data/predictions/zarr/alpha/global.zarr45 TB84,8778,982,630 logical chunks (also sharded)Vector outputs (GeoParquet)vectorize_mosaics3://us-west-2.opendata.source.coop/tge-labs/ftw-global-data/predictions/vectors/alpha/results/675 GB1,0008,217,195,679 rows Aggregate data output (above artifacts): ~348.7 TB across 540,794 objects. RasterFlow summary You can reproduce this end-to-end global-scale GeoAI pipeline with three API calls: from datetime import datetime from rasterflow_remote import RasterflowClient, DatasetEnum from rasterflow_remote.model_registry import get_model_registry_config, ModelRegistryEnum from rasterflow_remote.data_models import VectorizeMethodEnum, SemSegRasterioConfig client = RasterflowClient() cfg = get_model_registry_config(ModelRegistryEnum.HUGGINGFACE, "wherobots/prue-pt2") mosaic = client.build_mosaic( datasets=[DatasetEnum.S2_MED_PLANTING, DatasetEnum.S2_MED_HARVEST], aoi="https://github.com/fieldsoftheworld/ftw-inference-app/blob/main/src/data/s2-grid.json", start=datetime(2023, 1, 1), end=datetime(2025, 1, 1), crs_epsg=4326, ) predictions = client.predict_mosaic( store=mosaic.uri, model_path=cfg.model_path, patch_size=cfg.patch_size, clip_size=cfg.clip_size, device=cfg.device, features=cfg.features, labels=cfg.labels, actor=cfg.actor, max_batch_size=cfg.max_batch_size, merge_mode=cfg.merge_mode, ) vectors = client.vectorize_mosaic( store=predictions.uri, features=["field"], threshold=0.5, vectorize_method=VectorizeMethodEnum.SEMANTIC_SEGMENTATION_RASTERIO, vectorize_config=SemSegRasterioConfig(stats=False, medial_skeletonize=False), ) In short, this global-scale GeoAI pipeline with RasterFlow starts from global feature mosaics, runs one global inference workflow, and publishes both analytics-ready and map-ready outputs. If you want a hands-on starting point, sign up for the RasterFlow Private Preview today and try the FTW notebook in the Solution Gallery. If your team is evaluating global-scale raster + vector production workflows, this is exactly what RasterFlow private preview is for. For API details and additional examples, see the Rasterflow documentation. Appendix — Technical Notes Building Feature COGs Internally, build_mosaic orchestrates four key steps: Seasonal DOY filtering — candidate scenes are filtered by day-of-year windows derived from latitude-aware seasonal heuristics. Quality masking — cloud/quality masks suppress invalid observations. Greedy scene selection — we iteratively pick scenes that maximize uncovered valid area so we reach broad coverage with a bounded scene count. Temporal compositing — selected scenes are collapsed into median composites for downstream model features. The current DOY heuristic and greedy objective are intentionally conservative and production-stable, but there is room for improvement (for example, region-specific phenology priors, dynamic cloud climatology, and cost-aware objective tuning). We also produce a COG index, which is used with GDAL’s GTI driver to build the underlying global mosaic. import geopandas as gpd import fsspec with fsspec.open("https://data.source.coop/ftw/global-data/features/cogs/alpha/index.parquet") as f: index = gpd.read_parquet(f) index.head(3) tile_id geometry time dataset url 0 01FBE POLYGON ((180 -50.59941, 178.76332 -50.5626, 1… 2024-01-01 00:00:00+00:00 s2med_planting s3://us-west-2.opendata.source.coop/tge-labs/f… 1 01FBE POLYGON ((180 -50.59941, 178.76332 -50.5626, 1… 2025-01-01 00:00:00+00:00 s2med_planting s3://us-west-2.opendata.source.coop/tge-labs/f… 2 01FBF POLYGON ((180 -49.70001, 178.84184 -49.66599, … 2024-01-01 00:00:00+00:00 s2med_planting s3://us-west-2.opendata.source.coop/tge-labs/f… Mosaicking notes (GTI + Ray) After feature COGs are written, we build a global virtual mosaic index and then materialize aligned arrays on the target grid. This relies on GDAL’s GTI driver as the index layer and mosaicking. Grid configuration for this run: CRS: EPSG:4326 Resolution: 8.983119e-5 degrees (~10 m at equator) Resampling: cubic The GTI-backed approach keeps COG indexing separate from downstream chunk/block execution and maps cleanly to distributed scheduling. Zarr internals Zarr is the storage layer that makes the global feature and prediction mosaics usable as products rather than just intermediate files. Two layout choices matter here: Logical chunks are the units we want readers and compute stages to address. Shards are the larger storage objects we actually write to object storage. We split them on purpose. Small logical chunks keep regional reads and retry boundaries precise, while larger shards prevent the store from exploding into billions of tiny objects. Larger shards also lower overall S3 PUT and LIST costs and reduce request-rate pressure. For the feature store, the logical chunk is (1, 1, 4096, 4096) and shards are written at (1, 1, 12288, 12288), so each object packs a 3 x 3 tile of logical chunks. For the prediction store, the logical chunk is (1, 1, 2048, 2048) and shards are written at (1, 3, 8192, 8192), so each object packs all three class bands across a 4 x 4 spatial tile of logical chunks. The tradeoff is deliberate: larger shards improve object-store efficiency and reduce listing overhead, but smaller logical chunks still give us better partial reads, safer retries, and more control over Ray execution geometry. The feature Zarr mosaic metadata is as follows: import zarr group = zarr.open("https://data.source.coop/ftw/global-data/features/zarr/alpha/global.zarr") group["variables"].metadata.__dict__ {'shape': (2, 10, 1566049, 4007517), 'data_type': Float32(endianness='little'), 'chunk_grid': RegularChunkGrid(chunk_shape=(1, 1, 12288, 12288)), 'chunk_key_encoding': DefaultChunkKeyEncoding(separator='/'), 'codecs': (ShardingCodec(chunk_shape=(1, 1, 4096, 4096), codecs=(BytesCodec(endian=), ZstdCodec(level=0, checksum=False)), index_codecs=(BytesCodec(endian=), Crc32cCodec()), index_location=),), 'dimension_names': ('time', 'band', 'y', 'x'), 'fill_value': np.float32(nan), 'attributes': {'coordinates': 'spatial_ref', '_FillValue': 'AAAAAAAA+H8='}, 'storage_transformers': (), 'extra_fields': {}} The prediction zarr mosaic metadata is as follows: group = zarr.open("https://data.source.coop/ftw/global-data/predictions/zarr/alpha/global.zarr") group["variables"].metadata.__dict__ {'shape': (2, 3, 1566049, 4007517), 'data_type': Float32(endianness='little'), 'chunk_grid': RegularChunkGrid(chunk_shape=(1, 3, 8192, 8192)), 'chunk_key_encoding': DefaultChunkKeyEncoding(separator='/'), 'codecs': (ShardingCodec(chunk_shape=(1, 1, 2048, 2048), codecs=(BytesCodec(endian=), ZstdCodec(level=0, checksum=False)), index_codecs=(BytesCodec(endian=), Crc32cCodec()), index_location=),), 'dimension_names': ('time', 'band', 'y', 'x'), 'fill_value': np.float32(nan), 'attributes': {'coordinates': 'spatial_ref', '_FillValue': 'AAAAAAAA+H8='}, 'storage_transformers': (), 'extra_fields': {}} Xarray notes We use rasterix to attach analytical coordinates lazily so opening the global feature store does not require eagerly reading large coordinate vectors every time. Why this matters: x length: 1,566,049 y length: 4,007,517 At float64 precision, coordinates alone are roughly (1,566,049 + 4,007,517) * 8 ~= 45 MB before reading any model features. Operationally, our xarray pattern is: Open lazily from object storage. Slice first (.sel) to bound I/O. Materialize only when plotting/validating. This keeps exploratory analysis responsive while preserving direct comparability between feature and prediction stores on the same grid. The Inference Config The InferenceConfig is the contract between model packaging and distributed execution. It tells RasterFlow how to read features, how large each inference window should be, what runtime to launch, and how overlapping predictions should be merged back into the output mosaic. In practice, the fields fall into a few groups: model_path and actor select the model artifact and the inference runtime implementation. patch_size and clip_size define the read window and how much border area is discarded to suppress edge artifacts. features and labels define the exact tensor interface between the Zarr store and the model. device and max_batch_size control throughput versus memory pressure on the target worker. merge_mode defines how overlapping patch predictions are blended into the final raster. from rasterflow_remote.data_models import MergeModeEnum, InferenceActorEnum { # path to the pt2 archive on hugging face 'model_path': 'https://huggingface.co/wherobots/prue-pt2/resolve/main/prue-efnetb7.pt2', # an enum used to specify how to handle the model for inference 'actor': InferenceActorEnum.SEMANTIC_SEGMENTATION_PYTORCH, # patch size determines the size of the inputs provided to the model 'patch_size': 256, # clip size determines the size we clip off the borders to reduce edge effects during inference 'clip_size': 32, # device to run inference on, e.g. 'cuda' or 'cpu' 'device': 'cuda', # list of features in order as required by the model. These names map to the input Zarr band labels. 'features': ['s2med_harvest:B04', 's2med_harvest:B03', 's2med_harvest:B02', 's2med_harvest:B08', 's2med_planting:B04', 's2med_planting:B03', 's2med_planting:B02', 's2med_planting:B08'], # the named labels for the predicted classes. These will be the output band labels in the output Zarr. 'labels': ['non_field_background', 'field', 'field_boundaries'], # the maximum batch size assuming our default A10 GPU with 24GB of memory. 'max_batch_size': 128, # the method to use when merging overlapping predictions to reduce edge effects at the patch level 'merge_mode': MergeModeEnum.WEIGHTED_AVERAGE } How Ray is used for inference We chose Ray as the data-plane engine because the workload is embarrassingly parallel at block level, but still needs data-aware scheduling and actor pools for GPU inference. Ray is used as a bounded block-processing engine over sharded Zarr storage. Key mapping model: Logical chunks define storage math and indexability. Shards reduce object count by packing multiple chunks per object. Ray blocks define execution granularity and may span multiple chunks. This decoupling lets us tune compute batch shape without rewriting storage layout. In the data pipeline, Ray Data uses Arrow-backed transport so tabular metadata/state can move across stages with minimal copying. Practical takeaway: throughput scales with actor parallelism while per-task memory remains tied to block geometry, not global mosaic size. Distributed inference (wherobots-rasterflow) The InferenceConfig above feeds directly into block planning, actor setup, and overlap-aware merging. Internally, predict_mosaic orchestrates three phases: Block planning — derive execution blocks from chunk metadata and resource limits. Read/Infer/Write pipeline — execute overlap-aware reads, actor inference, and deterministic writes. Retry-safe commit — persist block outputs with stable target regions. # conceptual : chunk/shard metadata -> Ray blocks chunk_meta = read_zarr_chunk_metadata(store) blocks = plan_ray_blocks(chunk_meta, target_rows_per_block) ray_ds = ray.data.from_items(blocks) result = ( ray_ds .map(read_zarr_block_with_overlap) .map(run_inference_actor_pool) .map(clip_and_write_block) ) Our distributed approach to vectorizing vectorize_mosaic operates at block level so geometry generation scales linearly with partition count rather than requiring one global polygonization pass. High-level flow: Read prediction blocks from Zarr. Apply thresholding per block. Polygonize per block. Emit GeoParquet partitions and merge metadata. This keeps memory bounded and allows retries/reprocessing for individual partitions. Sign up for RasterFlow Private Preview Get Started Frequently Asked Questions How did Wherobots deliver Fields of the World at global scale? RasterFlow ran the PRUE model over global Sentinel-2 planting and harvest median composites, wrote feature and prediction Zarr mosaics, then vectorized the field class to GeoParquet. The end-to-end pipeline is three RasterflowClient calls: build_mosaic, predict_mosaic, and vectorize_mosaic. How big are the Fields of the World RasterFlow outputs? Feature COGs 153 TB, feature Zarr 150 TB, prediction Zarr 45 TB, and vector GeoParquet 675 GB with 8,217,195,679 rows. Combined, about 348.7 TB across 540,794 objects, published on Source Cooperative. Why store global GeoAI mosaics in Zarr instead of COGs only? Chunked, cloud-native Zarr lets you read small spatial windows directly from object storage during validation, inference, and analytics without reprojecting or resampling. Feature and prediction stores stay on the same EPSG:4326 grid as PRUE training data. Sharding packs multiple logical chunks per object so the store does not explode into billions of tiny files. What model does Fields of the World use in RasterFlow? PRUE, loaded from the Hugging Face registry as wherobots/prue-pt2 (prue-efnetb7.pt2). Inference uses 256-pixel patches, 32-pixel clip to suppress edge effects, CUDA, max_batch_size 128 on a default A10 24 GB GPU, and WEIGHTED_AVERAGE merge of overlapping patches. Output bands are non_field_background, field, and field_boundaries. --- ## Spatial Data Pipeline Architecture: PostGIS and Wherobots Together URL: https://wherobots.com/blog/spatial-data-pipeline-architecture-postgis-wherobots/ Updated: 2026-10-19 In the world of data architecture, there is a dangerous myth that you have to choose “one tool to rule them all.” We often see organizations paralyzed by the debate: “Should we use a Database or a Data Lake?” Key takeawaysThe post argues you do not choose one tool to rule them all. A spatial pipeline built for both large-scale analytics and operational queries uses both Wherobots and PostGIS in a defined sequence: the Geospatial Medallion Architecture (Bronze, Silver, Gold).Bronze is raw ingestion into cheap object storage (S3, Azure Blob, GCS) with no transformation. Silver is the refinery: Wherobots validates geometries, enriches records, and writes GeoParquet or Iceberg via Havasu.Gold is aggregated, query-ready data served by PostGIS to BI tools and apps with sub-second response times.AddressCloud’s John Powell is quoted on moving property-level perils models (flood, fire, climate risk across millions of addresses) into the Silver layer. Data, algorithms, and compute sit in one Spark/Sedona notebook, comparable to Google Earth Engine but with greater control over job completion.Operations that previously took hours or days now complete in minutes, with no preprocessing step to combine raster and vector.The payoff of the split: raw junk stays in cheap Bronze instead of an expensive database. Heavy jobs run in Wherobots so they cannot slow customer-facing PostGIS, and data scientists work on Silver without begging for database access.This is part three of a series after the lakehouse guide and cost comparison. A spatial data pipeline architecture built for both large-scale analytics and operational queries is one of the harder infrastructure decisions a geospatial team makes. Most organizations try to solve it with a single tool. That is where the problems start. The teams that get this right do not choose between a data lake and a spatial database. They use both, in a defined sequence known as the Geospatial Medallion Architecture. The medallion architecture, a data pipeline pattern established in the data lakehouse ecosystem, organizes data into three progressive quality layers: Bronze, Silver, and Gold. Wherobots and PostGIS each own a distinct role in that pipeline. Wherobots is a cloud-native spatial analytics platform, built by the original creators of Apache Sedona, that processes large-scale geospatial datasets using distributed compute. PostGIS is an open-source spatial extension for PostgreSQL that adds support for geographic objects and enables location-based queries in SQL.  The spatial medallion architecture organizes geospatial data into three layers: Bronze: Raw ingestion. All incoming data (GPS feeds, satellite imagery, shapefiles) lands in cloud object storage (S3, Azure Blob, GCS) without transformation. The goal is preservation and speed of capture. Silver: Refinement. A distributed compute platform like Wherobots validates geometries, enriches records with spatial attributes, and converts raw formats to optimized columnar formats like GeoParquet. This layer is what data scientists use to train spatial AI models. Gold: Delivery. Aggregated, query-ready data served by PostGIS to BI tools and applications. Volume is low because the data is pre-aggregated. Response times are sub-second. Think of your data not as static files, but as raw material (like crude oil or iron ore) that must be refined through a series of stages before it is valuable to your business. Why Spatial Data Teams End Up with Swamps or Silos Before we look at the solution, let’s look at the problem. The “Data Swamp”: You dump all your raw files (CSV, Shapefiles, GeoJSON) into cloud storage. It’s cheap, but nobody can find anything. It’s a mess. The “Database Silo”: You try to force everything into your operational database (PostGIS). The data is clean, but the database becomes slow, and expensive. Your analysts crash the system with heavy queries, and your app users complain about speed. The Spatial Data Pipeline Medallion Architecture The Medallion Architecture solves this by organizing your data into three distinct layers of quality: Bronze, Silver, and Gold. This approach allows you to use the right tool for the right job: Wherobots for heavy industrial refining, and PostGIS for precision delivery. Wherobots is a cloud-native spatial analytics platform, built by the original creators of Apache Sedona, that processes large-scale geospatial datasets using distributed compute. PostGIS is an open-source spatial extension for PostgreSQL that adds support for geographic objects and enables location-based queries in SQL. 1. Bronze Layer: Raw Ingestion into Cloud Object Storage The “Landing Zone” In the spatial medallion architecture, the Bronze layer is the raw ingestion zone where all incoming data lands without transformation. This is the entry point for all your data. Whether its real-time telemetry from 10,000 delivery trucks, daily dumps of satellite imagery, or messy spreadsheets from a partner, it all lands here first. The Goal: Speed and Preservation. We don’t change the data here; we just capture it so we never lose the original source. The Technology: Cloud Object Storage (S3, Azure Blob, GCS). Why: It is incredibly cheap and infinite. You can dump petabytes here without breaking the bank. 2. The Silver Layer: The Refinery Clean, Standardize, & Enrich This is where the magic happens and where the heavy lifting is required. Raw data is rarely ready for business. It has duplicates, missing fields, or invalid geometries (like a building polygon that twists into itself). The Task: Validation: Checking if GPS points are actually on land. Enrichment: Taking a raw coordinate and adding “City,” “State,” and “Flood Risk Score” columns. Optimization: Converting raw formats like CSV and Shapefile into columnar formats like GeoParquet or Apache Iceberg tables, which Wherobots stores natively through its Havasu spatial lakehouse catalog. The Technology: Wherobots. Why: This “refining” process requires massive computing power. You might be processing billions of records. Wherobots can spin up 1,000 nodes to crunch this data in minutes, clean it, and write it back to the lake as a trusted, high-quality “Silver” dataset. This is the layer your Data Scientists love because it’s clean enough to train AI models but detailed enough to find deep patterns. ​​AddressCloud runs property-level perils models for insurers, processing flood, fire, and climate risk data across millions of addresses. John Powell, Senior Geospatial Data Engineer at AddressCloud, describes what changed when they moved that workload into the Silver layer: “From a developer perspective, having data, algorithms and compute (and to be presented with a Spark/Sedona context in a Jupiter notebook on startup) combined in one platform is extremely powerful, comparable in many respects to Google Earth Engine, but with much greater guarantees of, and control over, job completion.” The result: operations that previously took hours or days now complete in minutes, with no preprocessing step required to combine raster and vector data. 3. Gold Layer: Optimized Data for BI Tools and Applications Aggregated & Ready for Business This is the “Showroom” layer. This data is highly polished, aggregated, and formatted for specific business questions. For example: “Total Sales by Zip Code” or “Active Drivers by City.” The Task: Serving answers to users instantly. When a CEO opens a dashboard or a customer opens an app, they can’t wait 10 seconds for a query to run. They need sub-second speed. The Technology: PostGIS. Why: By the time data reaches the “Gold” layer, the volume is much smaller because we have aggregated it. PostGIS is the perfect tool here. It is optimized for high-speed retrieval. It serves this “Gold” data to your BI tools (Tableau, Looker) and your web applications instantly. How the Three Layers Work Together: The “Better Together” Workflow By adopting this strategy, you create a data supply chain that maximizes the strengths of every tool: Lower Costs: You stop using your expensive database to store terabytes of raw, messy junk. That stays in the cheap Bronze layer. Higher Stability: Your heavy analytical jobs run in Wherobots (Silver Layer), completely separate from your operational database. Your analysts can crunch numbers all day without ever slowing down the app for your customers. Faster Innovation: Your data scientists don’t have to beg for database access. They can work directly with the Silver data in Wherobots to build advanced AI models, while the business teams continue to use the Gold data in PostGIS. Summary: A Blueprint for Success The spatial medallion architecture is not a tool choice. It is a pipeline pattern that assigns the right tool to the right job. If you are a leader looking to modernize your geospatial stack, don’t look for a “PostGIS replacement.” Look for a partner. Use Wherobots to act as your heavy-lifting factory: ingesting, cleaning, and crunching massive scale data. Use PostGIS to act as your high-speed storefront: delivering those insights to users the moment they need them. This hybrid approach, the Spatial Medallion Architecture, is how modern organizations turn location data into competitive advantage.This is part three of a series. The prior posts cover PostGIS vs Wherobots for spatial data lakehouses and spatial database cost comparisons. Start Building with Wherobots Get Started Frequently Asked Questions Should I replace PostGIS with Wherobots? The post says no: do not look for a PostGIS replacement. Use Wherobots as the heavy-lifting factory for ingesting, cleaning, and crunching massive-scale data, and PostGIS as the high-speed storefront that delivers Gold insights to users the moment they need them. What is the geospatial medallion architecture? A lakehouse pipeline pattern with three quality layers. Bronze: raw GPS, imagery, and shapefiles land in object storage unchanged.Silver: a distributed engine such as Wherobots validates, enriches, and converts to GeoParquet/Iceberg. Gold: aggregated, query-ready data served by PostGIS to BI tools and applications at sub-second latency because volume is already reduced. Why not put all spatial data in PostGIS? That is the ‘Database Silo’: data is clean, but the database becomes slow and expensive. Analysts crash the system with heavy queries, and app users complain about speed. The architecture isolates heavy Silver jobs in Wherobots so they never compete with operational PostGIS. What runs in the Silver layer vs Gold? Silver is validation, enrichment (city, state, flood risk score), and conversion to columnar formats using Wherobots distributed compute over billions of records. Gold is highly polished aggregates such as total sales by zip code or active drivers by city, served instantly by PostGIS to Tableau, Looker, and web apps. --- ## Iceberg v3 Gets Native Geo Types. It’s More Than a Format Upgrade URL: https://wherobots.com/blog/iceberg-geospatial-types-v3/ Updated: 2026-10-19 Introduction Geospatial data touches nearly every industry, and until recently, the open lakehouse had no native way to handle it. Snowflake recently announced Iceberg v3 support with native geometry and geography types. It’s the first major engine to ship the geospatial extensions to the Iceberg spec. These types are now part of the open standard, available to every engine in the ecosystem. Key takeawaysUntil Iceberg v3, geospatial columns did not exist in the table format. Engineers stored geometry as WKB in a binary column, with no CRS in the schema, no bounding-box statistics, and no cross-engine portability.v3 adds native geometry and geography types; Snowflake was the first major engine to ship them.Snowflake’s Iceberg v3 post called out the Wherobots team for implementing geospatial support on its own Iceberg fork before contributing the feature to the Iceberg project.That work started in 2022, the year Wherobots was founded, in Havasu: a production spatial lakehouse extension, not a proof of concept.The Parquet PR for GEOMETRY and GEOGRAPHY logical types drew over 400 comments, and the Iceberg geo type spec had another 240+. Jia Yu and Kristin Cowalcijk drove core design.After v3, a column is geometry(srid:4326) rather than binary, and manifest bbox stats can skip file groups before any geometry is read.AWS Glue shipped Iceberg v3 support at re:Invent 2025; Dremio followed with GA in their cloud platform. Apache Sedona already reads and writes Iceberg geospatial columns using the Havasu encoding that preceded the spec.WherobotsDB and Sedona also compute with CRS at scale (WKT, PROJ strings, grid-based datum shifts), beyond reading an SRID tag. In their Iceberg v3 post, the Snowflake team called out where the geo work came from: “A special mention to the entire Wherobots team, which implemented geospatial support on its own fork of Iceberg before offering its expertise to the Iceberg community, providing leadership and implementing the feature for the Iceberg project.” The work started in 2022, the year Wherobots was founded. This post is the story behind it: how production experience became an open standard, and what it means for the teams and tools building on spatial data. How Geospatial Data Worked in Iceberg Before v3 Until Iceberg v3, geospatial columns did not exist as a concept in the table format. Engineers stored geometry as opaque binary blobs: Well-Known Binary (WKB) bytes in a binary column. The Iceberg catalog had no way to know the column contained spatial data. The practical consequences: No CRS metadata. The coordinate reference system did not live in the column. Engineers tracked it in documentation or external conventions. No bounding-box statistics. A query engine had no way to skip files based on spatial predicates without reading the geometry itself. No cross-engine portability. Every team needing spatial analytics on a lakehouse built custom encoding pipelines, engine-specific readers, and schema conventions living outside the format. It worked, but it was fragile. And it did not travel across engines. Havasu: Production System First Havasu was our answer to that problem: a spatial lakehouse extension built on an Iceberg fork. Not a proof of concept. A production system, running real customer workloads since 2022, where we could pressure-test the design decisions that would eventually become a standard: Spatial indexing integrated into table metadata Bounding-box statistics at the manifest level, enabling file-group pruning on spatial predicates CRS propagation through the schema, so coordinate reference systems traveled with the data Geometry column encoding with explicit format annotations (WKB, EWKB, WKT, GeoJSON) That production experience shaped our GeoLake research, which formalized the core design principles: unambiguous CRS representation, efficient geometry encoding in columnar storage, and bounding-box statistics that let spatial predicates be evaluated before any geometry data is read. Then we contributed the design, the implementation experience, and the lessons learned upstream to Apache Parquet and Apache Iceberg, so the broader ecosystem could build on it. Many of the design decisions validated in Havasu are now part of the Iceberg v3 spec. Bounding-box statistics, CRS propagation, and geometry encoding all made the transition from production system to open standard. Before and After: Geometry in the Iceberg Schema To understand why this matters, consider the difference concretely. Before (Iceberg v1/v2): A geometry column in the Iceberg schema looks like this: { "id": 5, "name": "geom", "type": "binary" } The catalog sees raw bytes. No spatial semantics. An engine reading this table has no way to know this column contains geometries, what CRS they’re in, or how to prune files spatially, unless it relies on out-of-band conventions like GeoParquet file-level metadata. After (Iceberg v3): The same column becomes: { "id": 5, "name": "geom", "type": "geometry(srid:4326)" } Now the CRS is a property of the type. The Parquet files carry GEOMETRY logical type annotations that any conforming engine can recognize. Bounding-box statistics in the manifest use a compact coordinate encoding, so engines can skip entire file groups that fall outside a query’s spatial bounds, before reading a single geometry value. Spatial pruning moves to the format level. This is the architecture we designed and validated in Havasu, now available to any engine that reads Iceberg v3. Making It Native: Apache Parquet and Iceberg Making geospatial a first-class type in the open lakehouse required coordinated changes to two foundational Apache projects. On the Parquet side, the PR to add GEOMETRY and GEOGRAPHY logical types to the format spec drew over 400 comments across months of design review: encoding formats, CRS semantics, edge-interpolation behavior, edge-case handling. Jia Yu (Wherobots Co-Founder and Apache Sedona PMC Chair) and Kristin Cowalcijk (Apache Sedona PMC member) drove core design decisions from the start. On the Iceberg side, the geo type spec defined how Iceberg catalogs spatial columns, stores bounding-box metadata, and handles spatial partitioning, with another 240+ comments of cross-community design work. The core API and implementation, authored by Kristin, followed with bounding-box types, geospatial predicates, and Parquet geo read/write. Over a year of coordinated work across both Apache communities. The result: geometry and geography as native primitive types, from the storage format through the table format – with the same level of spec support that timestamps, decimals, and every other type have always had. The First Wave of Adoption Snowflake’s announcement is a milestone, not the finish line. It’s the first major engine to ship v3 geo types. It won’t be the last. Iceberg v3 adoption is accelerating broadly. AWS Glue shipped v3 support at re:Invent 2025. Dremio followed with GA support in their cloud platform. As more engines adopt v3, spatial columns will interoperate the same way every other column type already does. The infrastructure barrier that kept geospatial data siloed from mainstream analytics is coming down. The end-to-end Parquet geo read/write path for Iceberg is under active review in the Apache Iceberg project. It connects v3 schema types to properly annotated Parquet files with GEOMETRY logical types. Once merged, any Iceberg-compatible engine will produce and consume fully v3-native geo tables. What This Means for Spatial Data Interoperability Apache Iceberg is increasingly how organizations query data across engines, and native geo types mean spatial data now travels the same way every other column type does. A geo-typed table written from one engine is readable by another with correct CRS, bounding-box stats, and spatial pruning intact. No proprietary connectors. No out-of-band conventions. Cross-engine portability also makes spatial data accessible to AI. Tools and agents working with physical-world data need consistent access across engines and catalogs. When the type contract lives in the format, access does not require per-system special-casing. Ahead of the Standard Wherobots Cloud is where teams run spatial ETL, large-scale analytics, and geospatial data engineering on Iceberg today, fully managed. As the upstream v3 pipeline completes, Wherobots Cloud will be the first to produce fully v3-native geo tables. The natural result of being the team that designed the spec and has the longest production track record on it. Apache Sedona reads and writes Iceberg tables with geospatial columns today, using the Havasu encoding that preceded the v3 spec. This means Sedona users have had production-grade spatial lakehouse capabilities since before the standard was finalized, and the migration path to v3-native types is straightforward as upstream support matures. WherobotsDB and Sedona also go beyond what the spec requires: distributed CRS-aware computation, automatic transformation across datasets in different projections, and support for CRS formats beyond SRID integers (WKT, PROJ strings, grid-based datum shifts). Most engines that adopt v3 will read the CRS tag. WherobotsDB and Sedona compute with it at scale. The end-to-end Parquet geo read/write path for Iceberg is under active review in the Apache Iceberg project. It’s the final piece connecting v3 schema types to properly annotated Parquet files with GEOMETRY logical types. Once merged, any Iceberg-compatible engine will be able to produce and consume fully v3-native geo tables. Where Wherobots Goes Beyond the v3 Spec The v3 geo types are the foundation. The next layer is making the full pipeline seamless: spatial partitioning strategies, advanced spatial indexing beyond bounding boxes, and tighter integration between spatial predicates and query planning across engines. These are problems we’ve been working on in Havasu for years. Now that the standard exists, that work can happen in the open, and the entire ecosystem benefits. The Spatial AI Coding Assistant, including the Wherobots MCP Server, VS Code Extension, and CLI, lets developers and AI agents work with spatial data through natural language. A developer describes an analysis problem, and the tools find relevant datasets, generate spatial queries, and execute them on Wherobots Cloud. Native geo types in Iceberg make this work cleanly: when the type, CRS, and spatial statistics live in the format, an agent queries physical-world data the same way it queries any other column, across any engine reading Iceberg. If you’re building your spatial data architecture on Iceberg, we’d like to talk. Frequently Asked Questions What geospatial types does Apache Iceberg v3 add? Native geometry and geography primitive types, with CRS as a property of the type (for example geometry(srid:4326)). Parquet files carry GEOMETRY logical type annotations, and bounding-box statistics in the manifest use a compact coordinate encoding so engines can skip file groups outside a query’s spatial bounds. How was geospatial data stored in Iceberg before v3? As opaque WKB bytes in a binary column. The catalog could not know the column contained spatial data. CRS lived in documentation or external conventions, there were no bbox statistics for file skipping, and every team built custom encoding pipelines and schema conventions outside the format. Did Wherobots contribute Iceberg geospatial types? Yes. Snowflake’s Iceberg v3 announcement gave special mention to the Wherobots team for implementing geospatial support on its own Iceberg fork and then providing leadership and implementation for the Iceberg project.Havasu ran customer workloads from 2022 with spatial indexing, manifest bbox stats, CRS propagation, and explicit geometry encodings. Jia Yu and Kristin Cowalcijk drove core Parquet and Iceberg design. Which engines support Iceberg v3 geometry today? Snowflake was the first major engine to ship v3 geo types. AWS Glue shipped v3 support at re:Invent 2025, and Dremio followed with GA support in their cloud platform.The end-to-end Parquet geo read/write path for Iceberg was still under active review when this post was published. Apache Sedona reads and writes Iceberg geospatial columns today using the Havasu encoding that preceded v3. --- ## Take-aways from the 2026 Geospatial Embeddings Workshop at Clark University URL: https://wherobots.com/blog/clark-embeddings-workshop/ Updated: 2026-10-19 EO Embeddings have a lot of excitement (and hype) around them. My social media is filled with content about EO embeddings and GeoML communities like the TorchGeo Slack and GitHub are focused on onboarding “foundation models” and associated assets like training datasets. Indie hackers like Christopher Ren are building useful applications for exploring and comparing embeddings, see GeoVibes. Key takeawaysIn early March 2026, industry and academic experts met at Clark University to work on EO embedding standards for storage, documentation, and cataloging.Outcomes live at geoembeddings.org and github.com/geo-embeddings. They include collection-format guidance, a STAC embedding spec, a Model Card example, and an AEF-with-Xarray tutorial.Selected recommendations: Zarr v3 for regularly gridded embeddings, GeoParquet for sparsely collected embeddings, and the new embedding STAC spec for how embeddings were produced, fitness for use, and search metadata. A sibling Zarr convention is in the works.Embedding storage can exceed input size: OlmoEarth Nano always emits 128 dimensions, and Base emits 768. Base (0.750 GiB) is larger than the raw input in every scenario in the table.For a 512×512 block at 10 m with 12 monthly timesteps in float32, Nano is 9.6× larger than a single Sentinel-2 scene. It only becomes smaller than the input with a full 12-scene time series.Three barriers remain: storage cost, undocumented fitness for use, and a lack of publicized, remembered benchmarks compared with LLM leaderboards. Most EO embeddings come from medium-resolution imagery and often fail high-res detection or some regions.Wherobots onboarded OlmoEarth Nano to the Model Hub in PyTorch 2 Archive format and points to RasterFlow for scale-out. This work is all fantastic. At the same time, I’m still left with a sense that fundamental issues around access and enablement have not been addressed, and that the performance and fitness for use of EO embedding products has not been adequately communicated. In early March, I got together with industry and academic experts at the Geospatial Embeddings Workshop at Clark University to start addressing this. We discussed standards for storage, documentation, and cataloging and implemented some of these ideas, which can be found at github.com/geo-embeddings. Workshop Outcomes We now have a site to collect best practices, document standards, and showcase tutorials for EO Embeddings. Check it out at geoembeddings.org! Some selected recommendations: use collection formats for storing embeddings, Zarr v3 for regularly gridded data, GeoParquet for embeddings of sparsely collected data use the new embedding STAC spec which communicate how embeddings were produced, fitness for use, and search and discovery metadata. A sibling convention for storing this same info within a Zarr is in the works. take a look at an example Model Card that compiles metadata to document the model that produces embeddings: geoembeddings.org/model-card.html Check out this tutorial for inspecting AEF embeddings with Xarray! Feel free to make your own tutorials and contribute them here. We’d love to collate examples of workflows on top of embeddings for similarity search, change detection, and fine-tuning, as well as showcase other embedding models and products. Sources: Technical Debt of Earth Embedding Products, Isaac Corley; Falk, H. zarr-developers/zarr-illustrations-falk-2022 | Zenodo, 2022. These resources are a start, but they don’t solve everything. In the rest of this post, I want to highlight three barriers I think we still need to address to make geo embeddings truly impactful: the surprising cost of storing embeddings, unclear fitness for use, and the lack of publicized benchmarks. Embedding storage can be expensive, take advantage of compression! The first barrier to using embeddings is practical: storing embeddings can cost more than you might expect. While EO data can be really large, the embeddings generated can be even larger than the input. I didn’t really appreciate this simple fact given my background in detection and segmentation, where typically the model result is smaller than the input. In recent model releases, EO models are trending towards flexibly accepting, but not requiring, multi modal inputs. If you have only Sentinel-2 imagery, you can generate embeddings for just Sentinel-2. But this wastes some capacity of the embedding generation model. For example, OlmoEarth Nano generates 128 embedding dimensions regardless of how many sensors or timesteps you feed in. That means adding more sensors makes the embedding progressively smaller relative to the input. The table below compares embedding size to input size for a 512 × 512 block at 10 m resolution with 12 monthly timesteps, in float32 (values show the ratio of embedding size to input size): Input stackBandsInput sizeNano Output (128-dim)Base Output (768-dim)S2 only, 1 scene130.013 GiB9.6× larger57× largerS2 only, 12 scenes130.152 GiB0.82×4.9× largerS2 + S1 VV/VH, 12 scenes150.176 GiB0.71×4.3× largerS2 + S1 VV/VH + Landsat, 12 scenes260.305 GiB0.41×2.5× larger The Nano embedding only becomes smaller than the input once you have a full 12-scene time series. The Base model (768-dim, 0.750 GiB) is larger than the raw input in every scenario, so it is worth factoring this storage cost in and weighing it against the performance of the embeddings prior to scaling out and committing resources to a big run. Fitness for use is often unknown Even if you can afford to store embeddings, do you know if they’ll work for your problem? EO Embeddings are often described as products of “foundation models”. Yet unlike foundation LLM models, which can carry out agentic tasks in thousands of different contexts at expert level, EO embedding models are much more restricted in the domains they can be successfully applied. For example, today most EO embeddings are derived from medium resolution satellite imagery. Practitioners curious about embeddings are often disappointed to find that they are not able to use embeddings with high resolution imagery for detection tasks. Or, they may be limited to agricultural use cases, not be applicable to some geographic regions, etc. Documenting and describing this fitness for use is often done in the research paper, but not clearly in the catalogue where the embeddings are hosted. And papers often leave out details on the sampling regime and how embeddings were tested. To address this, check out the resources linked above to better document your embedding model or an existing embedding product! Lack of publicized benchmarks is a barrier to adoption And we don’t yet have a shared way to answer questions about fitness for use. Model benchmarks, while imperfect and easily gamed, are essential for communicating what is worth the effort to try. In the LLM space, benchmarks like MMLU and SWE-Bench have been useful signals for indicating which models are best. As they become saturated or too easy, new benchmarks arise to fill the gap. I don’t see a similar pattern happening with EO embeddings or EO models in general. Benchmarks are typically done within a paper and how comprehensive it is governed by how much time, compute, and expertise the author had. I don’t think we as a community of researchers, practitioners, and end-users have much memory for these paper benchmarks. I’d like to contribute to an effort toward a leaderboard for EO foundation models, which can host multiple benchmarks, aligning the community on which models, and which benchmark datasets, are useful and important. To address this, get in touch if you’d like to compare embedding models to each other at useful scale so we can more effectively communicate performance of these models for specific use cases! What’s Wherobots doing with embeddings and foundation models? At the core of it, I think experimenting with embeddings can often feel difficult, and we’re trying to change that at Wherobots. Wherobots has applied AlphaEarth Foundations embeddings to change detection, agricultural monitoring, and field-level zonal statistics. Before the workshop, we’d been hearing from many that they were curious to try foundation models on their specific problem, in order to increase price/performance of their workloads, improve model accuracy, and more easily solve more problems with less complicated workflows and expensive model fine-tuning. To help here, we’ve onboarded a foundation model to our Model Hub, OlmoEarth Nano for embedding multi-spectral optical and radar imagery. We publish our models on Huggingface in Pytorch 2 Archive format so that you can load and run these models using only Pytorch as a dependency. This can be helpful for testing and comparing embeddings outside of a larger ML pipeline. If you need to scale out these models, check out RasterFlow. It’s a batch processing engine built for any scale of imagery you need to run inference on, from city scale, high resolution imagery to global, petabyte scale collections. I think RasterFlow could be a key enabler to comparing embeddings at the large spatial scale they are typically generated at. If you’re experimenting with EO embeddings, contribute a tutorial to geoembeddings.org, contribute a Model Card for your cool new model, or just share what’s working and what’s not. We’re looking forward to lowering these barriers to EO derived insights with the community! Frequently Asked Questions How should Earth observation embeddings be stored? Workshop recommendations: collection formats, specifically Zarr v3 for regularly gridded embeddings and GeoParquet for embeddings of sparsely collected data. Use the embedding STAC spec to document production method, fitness for use, and discovery metadata. A sibling convention for the same info inside Zarr is in progress. Why are geospatial embeddings expensive to store? Unlike detection/segmentation outputs, embeddings can be larger than the input. OlmoEarth Nano produces 128 dims regardless of how many sensors or timesteps you feed, so adding sensors makes the embedding smaller relative to input.A single Sentinel-2 scene still yields a Nano embedding 9.6× larger than the input. The 768-dim Base model is larger than the raw input in every stacked scenario in the post. Are EO foundation model embeddings usable on high-resolution imagery? The post says practitioners are often disappointed. Most EO embeddings are derived from medium-resolution satellite imagery and are not usable with high-resolution imagery for detection tasks. They may also be limited to agricultural use cases or some geographic regions.Fitness for use is often in the paper, not in the catalog where embeddings are hosted. What is Wherobots doing with EO embeddings? Wherobots has applied AlphaEarth Foundations embeddings to change detection, agricultural monitoring, and field-level zonal statistics. OlmoEarth Nano is on the Model Hub for embedding multi-spectral optical and radar imagery.It is published on Hugging Face in PyTorch 2 Archive format, so you can load it with only PyTorch. RasterFlow is the batch engine cited for city-scale high-res through global petabyte collections. --- ## Introducing developer tools that let AI build with physical world data URL: https://wherobots.com/blog/spatial-ai-coding-tools/ Updated: 2026-10-20 Your AI can now understand and query spatial data using the Wherobots MCP server, VS Code extension, and CLI. The physical world is a new frontier for AI, but modern AI-driven tools are limited by what they can do with this type of data. LLMs don’t understand how to use physical world data for analytical purposes. For example, when we asked ChatGPT to compute the flood risk from sea level rise for all homes along the California coastline, it came back claiming that “no one can give you a single exact number”, plus some unverifiable numbers: Key takeawaysWherobots launched three tools that let AI understand and drive spatial analysis: an MCP server, a CLI, and a VS Code extension. They are designed for IDEs including VS Code, Claude Code, OpenCode, Cursor, Windsurf, and Kiro.A Wherobots connector for Claude and ChatGPT marketplaces is described as coming soon.Using VS Code and Claude Opus 4.6 harnessed to Wherobots, the authors completed the California coastal flood-risk analysis that ChatGPT declined to quantify as a single number. It took under 30 minutes and less than $5 of Wherobots usage, and the notebook is linked from the post.Free trial stated here: Wherobots Pro for 30 days and up to $95, with an additional $250 credit if you activate spatial AI coding tools. Create an API key, install the VS Code extension, and optionally integrate S3, Databricks Unity Catalog, or AWS Glue.Wherobots integrates with AWS S3, Databricks Unity Catalog, and AWS Glue so agents work against existing lakes. RasterFlow-driven agent workflows are described as coming soon.Roadmap items: marketplace connectors, OAuth for MCP, more Hub datasets, and additional catalogs. That may have been true, until now! In the past, it would take highly skilled developers who are familiar with spatial data and its query patterns, weeks to prototype this type of analysis. Now, developers and analysts, irrespective of their geospatial skills, can build it on-demand using natural language. Using your AI agent connected to Wherobots, they can build working solutions with small to very large scale geospatial data in minutes. Wherobots now offers your AI the capability to understand spatial data to generate quality code. The pairing includes direct access to WherobotsDB, a cloud-based, secure, and distributed execution environment purpose-built to generate results efficiently at scale. Soon, the same AI will be capable of driving RasterFlow, the planetary-scale inference engine for Earth Intelligence to extract machine-generated insights from satellite, drone, and sensor datasets. Enabling AI to Work with Physical World Data We are launching three new tools that let AI understand and drive the analysis of spatial data; an MCP server, a CLI, and a VS Code extension. These tools are designed to bring geospatial development into IDEs like VS Code, Claude Code, OpenCode, Cursor, Windsurf, Kiro and others. And soon the Wherobots connector will make it easy to use the same analytical capability in Claude and ChatGPT from respective marketplaces. With these tools, LLMs and agents can discover and understand spatial data, generate and debug code, and build solutions considerably faster using natural language as an interface. As a result, developers and analysts immediately become more productive with geospatial data, enabling them to solve more problems, and shorten the development cycle from weeks down to potentially minutes. Wherobots integrates with data lakes and lakehouses including AWS S3, Databricks Unity Catalog, and AWS Glue, allowing teams to realize massive gains using their existing data. Getting Started Sign up for a free trial of Wherobots Pro. Use Wherobots for free for 30 days and up to $95, with an additional $250 credit if you activate your spatial AI coding tools. Create a Wherobots API key. Install the Wherobots extension for VS Code. Optionally, establish secure integrations with datasets in Amazon S3, Databricks Unity Catalog, or AWS Glue. Wherobots will utilize these integrated datasets, along with hosted datasets within its catalog. You can also install Wherobots on other IDEs, work with the MCP server, utilize the CLI and agent skills. Start using the extension by typing a prompt into the chat window: “Using NDVI datasets and field boundaries for California, what kind of field-level crop health insights can I compute?” “Write a notebook for me to ingest the latest American Community Survey data from US Census.” “I need to know how many properties in California coastal cities are facing flooding risk. I want you to come up with an analysis framework for this, help me identify the right datasets to help me solve this problem, generate some initial insights from those for me to validate, and finally (once I approve) write a notebook for me to run this analysis independently.” Using VS Code and Claude Opus 4.6 harnessed to Wherobots, we were able to complete the California flood risk analysis that ChatGPT couldn’t in under 30 minutes and for less than $5 of Wherobots usage. The California Coastal Flood Risk notebook we built is here. Here is a quick video interacting with a generated notebook via VSCode. Enabling Agents to Understand the Physical World What we announced today enables people to use AI to build solutions with physical world data, at a fraction of the time and cost. Agents are now capable of developing production-grade geospatial data applications, autonomously or semi-autonomously with a human in the loop with Wherobots acting as the natural language interface and the context engine between the two. What’s Possible Now Here are a few example prompts that can drive prototypes and working solutions. To build prototypes or solutions, you will need to ensure the right data is integrated with Wherobots such that your AI can use Wherobots to understand it, and execute effectively based on your directions. For many organizations, this data is already available either in their private data lake (Amazon S3, Databricks Unity Catalog, AWS Glue Data Catalog) or in the public domain (STAC, public datasets, purchased datasets). Mobility, fleet management, and logistics: “Use Wherobots to transform the raw GPS data for the month of March [located in Databricks Unity Catalog Table X] into trips, and match it to the Overture transportation network using Wherobots map matching. Tell me which segments of road in the state of California were the most constraining for my trips. Define constrained as the speed traveled was less than 50% of the advertised speed limit, rank these segments by trips taken, and also eliminate road segments that were within 1/4 mile of an intersection.” Marketing and advertising: “Using the fields of the world dataset generated by Wherobots RasterFlow, join fields to Regrid parcels. Also join this result with my customer database located in [S3 location]. I want to identify unique farm owners who are not customers and sell to them.”Insurance: “Compute the flood risk score using the [flood plane raster] for all properties under general home insurance located in my [S3 bucket path]. Identify which properties have flood insurance and are at the most risk, based on [criteria X]. Separately tell me which properties are at risk, but not insured so I can target them for insurance offerings.” Agriculture: “Use the fields of the world dataset as a filter. Use RasterFlow and the latest Sentinel 2 data in the AWS data exchange to compute NDVI for the state of California. Join these results with the fields to produce NDVI statistics in the month of July for all fields in California.” (This example will be AI-driven soon, but is feasible today with RasterFlow in private preview) What’s Coming Next In the coming months you can expect: Wherobots Connector on the Claude and OpenAI Marketplaces OAuth support for the MCP Server Additional hosted datasets in the Wherobots Hub New integrations with additional data sources and catalogs Here’s a sneak peek of the experience we are planning to enable via Claude, including notebook generation and insights provided directly inside Claude Chat: Please reach out to us at product@wherobots.com or support@wherobots.com if you have feedback, requests, or questions. Start your free trial below and start using the spatial AI coding tools. Start your free trial. Try Now Frequently Asked Questions What are the Wherobots spatial AI coding tools? An MCP server, a CLI, and a VS Code extension that let LLMs and agents discover spatial data, generate and debug code, and run analysis on WherobotsDB. They bring geospatial development into IDEs such as VS Code, Claude Code, OpenCode, Cursor, Windsurf, and Kiro. How do I get started with the Wherobots VS Code extension? Sign up for a Wherobots Pro free trial (30 days and up to $95, plus $250 if you activate spatial AI coding tools). Create a Wherobots API key, and install the VS Code extension. Optionally connect S3, Unity Catalog, or Glue.Then prompt the chat, for example to ingest ACS census data or to frame a California coastal flood analysis. Can ChatGPT compute California coastal flood risk? The authors asked ChatGPT to compute flood risk from sea level rise for all homes along the California coastline. It claimed no one could give a single exact number, plus unverifiable figures. With VS Code and Claude Opus 4.6 connected to Wherobots, they completed the analysis in under 30 minutes for less than $5 of Wherobots usage. What spatial AI coding tools are coming next? The post lists a Wherobots Connector on the Claude and OpenAI Marketplaces, OAuth support for the MCP Server, and additional hosted datasets in the Wherobots Hub. It also lists new integrations with additional data sources and catalogs. Driving RasterFlow from the same AI is described as coming soon. --- ## How Agricultural Fields Change in AlphaEarth Foundations URL: https://wherobots.com/blog/alphaearth-foundations-agriculture-change-detection/ Updated: 2026-10-19 Author: Len Strnad AlphaEarth Foundations is a geospatial AI model from Google DeepMind. It compresses a year of satellite observations into 64-dimensional embedding vectors for every 10-meter pixel on Earth’s land surfaces and shallow coastal waters annually. In this notebook, we use AEF to examine how agricultural fields evolve across several regions and ask a practical question: what kinds of field-level change become visible when we inspect the embeddings directly rather than relying only on imagery? Key takeawaysAlphaEarth Foundations (Google DeepMind) compresses a year of satellite observations into 64-dimensional embedding vectors for every 10-meter pixel on Earth's land surfaces and shallow coastal waters, annually. This notebook inspects field-level change in embedding space rather than relying only on imagery.Three agricultural AOIs are used: Iowa, California, and Japan. RasterFlow build_gti_mosaic builds a Zarr mosaic per AOI from AlphaEarth Foundations COGs on Source Cooperative.An example Iowa mosaic is 38 GB (9 time steps, 64 bands, 2017–2025).Three views of temporal change: the first three embedding bands as RGB, a PCA projection of all 64 bands into three components, and an experimental cosine-distance-over-time workflow. PCA is described as making field-level seasonal structure easier to see than raw RGB bands.The goal is not a single definitive interpretation of AEF. It is a practical workflow for exploring seasonal cycles, repeated interventions, and other field-scale dynamics in embedding space, using experimental RasterFlow PCA and distance-over-time tools. We begin by defining a few agricultural areas of interest and building Zarr mosaics over each one from COGs available in Source Cooperative. From there, we compare several views of temporal change: the first three embedding bands rendered as RGB, a Principal Component Analysis (PCA) projection that makes broader structure easier to interpret, and an experimental distance-over-time workflow that highlights where embedding values remain stable or shift over time. The goal is not to claim a single definitive interpretation of AEF. Instead, this notebook shows a practical workflow for exploring seasonal cycles, repeated interventions, and other field-scale dynamics in embedding space. RasterFlow Tools Used RasterFlow is Wherobots’ serverless inference engine for Earth Observation data. It builds inference-ready mosaics from satellite imagery and runs distributed workflows at scale. This notebook uses three RasterFlow capabilities: build_gti_mosaic for constructing Zarr mosaics from AlphaEarth Foundations data an experimental PCA workflow for dimensionality reduction and an experimental distance-over-time workflow for measuring embedding change between timesteps. Selecting Agricultural AOIs Across Iowa, California, and Japan We start with three small AOIs that contain agricultural fields in different regions. This gives us a compact but varied set of examples for exploring how AlphaEarth Foundations embeddings change over time. import geopandas as gpd from shapely.geometry import box from folium import Map iowa1 = [-94.732361, 41.911475, -94.237289, 42.112996] california1 = [-120.11095, 36.63082, -120.018082, 36.683839] japan1 = [141.018019, 39.226668, 141.067801, 39.249803] aois = [iowa1, california1, japan1] gdf = gpd.GeoDataFrame({"geometry": [box(*aoi) for aoi in aois]}, crs="EPSG:4326") # start on the first AOI m = Map(location=gdf.iloc[0].geometry.centroid.coords[0][::-1], zoom_start=8) gdf.explore(height="120%", width="120%", m=m) Make this Notebook Trusted to load map: File -> Trust Notebook # store this out to parameterize which Zarr mosaics we want to build for AEF gdf.to_parquet("s3://union-sandbox-unionai-wherobots/aois/field_change_aef.parquet") AlphaEarth Foundations Zarr Mosaics by AOI The next step is to create an AlphaEarth Foundations embeddings Zarr mosaic for each AOI. This gives us a time-indexed raster store that we can query efficiently for visualization and downstream analysis. The output here is from the build_gti_mosaic RasterFlow workflow. import geopandas as gpd mosaic_index = gpd.read_parquet( "s3://union-sandbox-unionai-wherobots/ha/wherobots/wherobots-mosaics/development/rnmkrr4sbxsdf24t288p/d8cq2y2k3b1r4p9gr0k5n1ldh/1/7q/fdjxpi5q/61a6e8f637cce7ddf177ff7a6637aceb/" ) mosaic_index geometry location 0 POLYGON ((-94.23729 41.91148, -94.23729 42.113… s3://sandbox-wherobots-mosaics-tmp/mosaics/rnm… 1 POLYGON ((-120.01808 36.63082, -120.01808 36.6… s3://sandbox-wherobots-mosaics-tmp/mosaics/rnm… 2 POLYGON ((141.0678 39.22667, 141.0678 39.2498,… s3://sandbox-wherobots-mosaics-tmp/mosaics/rnm… The result is one Zarr mosaic per AOI, which we can load independently for inspection and comparison. Inspect an Example AEF Zarr Mosaic import xarray as xr ds = xr.open_zarr(mosaic_index.iloc[0]["location"]) ds Size: 38GB Dimensions: (time: 9, band: 64, y: 3020, x: 5512) Coordinates: * time (time) datetime64[ns] 72B 2017-01-01 2018-01-01 ... 2025-01-01 * band (band) object 512B 'band_0' 'band_1' ... 'band_62' 'band_63' * y (y) float64 24kB 5.178e+06 5.178e+06 ... 5.148e+06 5.148e+06 * x (x) float64 44kB -1.055e+07 -1.055e+07 ... -1.049e+07 spatial_ref int64 8B ... Data variables: variables (time, band, y, x) float32 38GB dask.arrayxarray.DatasetDimensions:time: 9band: 64y: 3020x: 5512Coordinates: (5)time(time)datetime64[ns]2017-01-01 … 2025-01-01array(['2017-01-01T00:00:00.000000000', '2018-01-01T00:00:00.000000000', '2019-01-01T00:00:00.000000000', '2020-01-01T00:00:00.000000000', '2021-01-01T00:00:00.000000000', '2022-01-01T00:00:00.000000000', '2023-01-01T00:00:00.000000000', '2024-01-01T00:00:00.000000000', '2025-01-01T00:00:00.000000000'], dtype='datetime64[ns]')band(band)object‘band_0’ ‘band_1’ … ‘band_63’array(['band_0', 'band_1', 'band_2', 'band_3', 'band_4', 'band_5', 'band_6', 'band_7', 'band_8', 'band_9', 'band_10', 'band_11', 'band_12', 'band_13', 'band_14', 'band_15', 'band_16', 'band_17', 'band_18', 'band_19', 'band_20', 'band_21', 'band_22', 'band_23', 'band_24', 'band_25', 'band_26', 'band_27', 'band_28', 'band_29', 'band_30', 'band_31', 'band_32', 'band_33', 'band_34', 'band_35', 'band_36', 'band_37', 'band_38', 'band_39', 'band_40', 'band_41', 'band_42', 'band_43', 'band_44', 'band_45', 'band_46', 'band_47', 'band_48', 'band_49', 'band_50', 'band_51', 'band_52', 'band_53', 'band_54', 'band_55', 'band_56', 'band_57', 'band_58', 'band_59', 'band_60', 'band_61', 'band_62', 'band_63'], dtype=object)y(y)float645.178e+06 5.178e+06 … 5.148e+06array([5177915.753919, 5177905.753919, 5177895.753919, ..., 5147745.753919, 5147735.753919, 5147725.753919], shape=(3020,))x(x)float64-1.055e+07 … -1.049e+07array([-10545553.188165, -10545543.188165, -10545533.188165, ..., -10490463.188165, -10490453.188165, -10490443.188165], shape=(5512,))spatial_ref()int64…crs_wkt :PROJCS[“WGS 84 / Pseudo-Mercator”,GEOGCS[“WGS 84”,DATUM[“WGS_1984”,SPHEROID[“WGS 84”,6378137,298.257223563,AUTHORITY[“EPSG”,”7030″]],AUTHORITY[“EPSG”,”6326″]],PRIMEM[“Greenwich”,0,AUTHORITY[“EPSG”,”8901″]],UNIT[“degree”,0.0174532925199433,AUTHORITY[“EPSG”,”9122″]],AUTHORITY[“EPSG”,”4326″]],PROJECTION[“Mercator_1SP”],PARAMETER[“central_meridian”,0],PARAMETER[“scale_factor”,1],PARAMETER[“false_easting”,0],PARAMETER[“false_northing”,0],UNIT[“metre”,1,AUTHORITY[“EPSG”,”9001″]],AXIS[“Easting”,EAST],AXIS[“Northing”,NORTH],EXTENSION[“PROJ4″,”+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs”],AUTHORITY[“EPSG”,”3857″]]spatial_ref :PROJCS[“WGS 84 / Pseudo-Mercator”,GEOGCS[“WGS 84”,DATUM[“WGS_1984”,SPHEROID[“WGS 84”,6378137,298.257223563,AUTHORITY[“EPSG”,”7030″]],AUTHORITY[“EPSG”,”6326″]],PRIMEM[“Greenwich”,0,AUTHORITY[“EPSG”,”8901″]],UNIT[“degree”,0.0174532925199433,AUTHORITY[“EPSG”,”9122″]],AUTHORITY[“EPSG”,”4326″]],PROJECTION[“Mercator_1SP”],PARAMETER[“central_meridian”,0],PARAMETER[“scale_factor”,1],PARAMETER[“false_easting”,0],PARAMETER[“false_northing”,0],UNIT[“metre”,1,AUTHORITY[“EPSG”,”9001″]],AXIS[“Easting”,EAST],AXIS[“Northing”,NORTH],EXTENSION[“PROJ4″,”+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs”],AUTHORITY[“EPSG”,”3857″]]GeoTransform :-10545558.188164568 10.0 0.0 5177920.753919057 0.0 -10.0[1 values with dtype=int64]Data variables: (1)variables(time, band, y, x)float32dask.array Array Chunk Bytes 35.72 GiB 4.00 MiB Shape (9, 64, 3020, 5512) (1, 1, 1024, 1024) Dask graph 10368 chunks in 2 graph layers Data type float32 numpy.ndarray 9 1 5512 3020 64 # pull this into memory once to reuse subset = ds["variables"][:, :3, :, :].compute() import imageio.v3 as iio import numpy as np def to_uint8_robust(array: xr.DataArray, low: xr.DataArray, high: xr.DataArray) -> np.ndarray: arr = array.transpose("y", "x", ...).astype("float32") scale = np.where((high - low) == 0, 1.0, (high - low)) arr = (arr - low) / scale arr = np.clip(arr, 0, 1) return (arr * 255).astype(np.uint8) def robust_params(da: xr.DataArray) -> tuple[xr.DataArray, xr.DataArray]: q_low, q_high = 1, 99 lo = da.quantile(q_low / 100, dim=("time", "y", "x")) hi = da.quantile(q_high / 100, dim=("time", "y", "x")) return lo, hi low, high = robust_params(subset) frames = [to_uint8_robust(subset.sel(time=t), low, high) for t in subset.time] iio.imwrite("assets/rgb_animation.gif", frames, duration=1000, loop=0) To establish a baseline view, we render the first three embedding bands as an RGB animation over time. The color mapping is not directly semantic, but it provides a quick way to spot recurring seasonal patterns and abrupt changes. Using PCA to Identify Seasonal Patterns in Embeddings A more interpretable view comes from projecting the 64-dimensional embeddings into their first three principal components. PCA concentrates the dominant variance into three channels, which often makes field-level change easier to see. # training sample for PCA using just the first year and a spatial slice sample = ds["variables"][:, :, :1024, :1024].compute() sample = sample.transpose("band","time","y","x").data.reshape(64, -1) sample = sample[:, ~np.isnan(sample).any(axis=0)] from sklearn.decomposition import PCA model = PCA(n_components=3) model.fit(sample.T) PCA(n_components=3)In a Jupyter environment, please rerun this cell to show the HTML representation or trust the notebook. On GitHub, the HTML representation is unable to render, please try loading this page with nbviewer.org.PCA?Documentation for PCAiFitted Parameters n_components n_components: int, float or ‘mle’, default=None Number of components to keep. if n_components is not set all components are kept:: n_components == min(n_samples, n_features) If “n_components == ‘mle’“ and “svd_solver == ‘full’“, Minka’s MLE is used to guess the dimension. Use of “n_components == ‘mle’“ will interpret “svd_solver == ‘auto’“ as “svd_solver == ‘full’“. If “0 < n_components < 1“ and “svd_solver == ‘full’“, select the number of components such that the amount of variance that needs to be explained is greater than the percentage specified by n_components. If “svd_solver == ‘arpack’“, the number of components must be strictly less than the minimum of n_features and n_samples. Hence, the None case results in:: n_components == min(n_samples, n_features) – 1 3 copy copy: bool, default=True If False, data passed to fit are overwritten and running fit(X).transform(X) will not yield the expected results, use fit_transform(X) instead. True whiten whiten: bool, default=False When True (False by default) the `components_` vectors are multiplied by the square root of n_samples and then divided by the singular values to ensure uncorrelated outputs with unit component-wise variances. Whitening will remove some information from the transformed signal (the relative variance scales of the components) but can sometime improve the predictive accuracy of the downstream estimators by making their data respect some hard-wired assumptions. False svd_solver svd_solver: {‘auto’, ‘full’, ‘covariance_eigh’, ‘arpack’, ‘randomized’}, default=’auto’ “auto” : The solver is selected by a default ‘auto’ policy is based on `X.shape` and `n_components`: if the input data has fewer than 1000 features and more than 10 times as many samples, then the “covariance_eigh” solver is used. Otherwise, if the input data is larger than 500×500 and the number of components to extract is lower than 80% of the smallest dimension of the data, then the more efficient “randomized” method is selected. Otherwise the exact “full” SVD is computed and optionally truncated afterwards. “full” : Run exact full SVD calling the standard LAPACK solver via `scipy.linalg.svd` and select the components by postprocessing “covariance_eigh” : Precompute the covariance matrix (on centered data), run a classical eigenvalue decomposition on the covariance matrix typically using LAPACK and select the components by postprocessing. This solver is very efficient for n_samples >> n_features and small n_features. It is, however, not tractable otherwise for large n_features (large memory footprint required to materialize the covariance matrix). Also note that compared to the “full” solver, this solver effectively doubles the condition number and is therefore less numerical stable (e.g. on input data with a large range of singular values). “arpack” : Run SVD truncated to `n_components` calling ARPACK solver via `scipy.sparse.linalg.svds`. It requires strictly `0 < n_components < min(X.shape)` “randomized” : Run randomized SVD by the method of Halko et al. .. versionadded:: 0.18.0 .. versionchanged:: 1.5 Added the ‘covariance_eigh’ solver. ‘auto’ tol tol: float, default=0.0 Tolerance for singular values computed by svd_solver == ‘arpack’. Must be of range [0.0, infinity). .. versionadded:: 0.18.0 0.0 iterated_power iterated_power: int or ‘auto’, default=’auto’ Number of iterations for the power method computed by svd_solver == ‘randomized’. Must be of range [0, infinity). .. versionadded:: 0.18.0 ‘auto’ n_oversamples n_oversamples: int, default=10 This parameter is only relevant when `svd_solver=”randomized”`. It corresponds to the additional number of random vectors to sample the range of `X` so as to ensure proper conditioning. See :func:`~sklearn.utils.extmath.randomized_svd` for more details. .. versionadded:: 1.1 10 power_iteration_normalizer power_iteration_normalizer: {‘auto’, ‘QR’, ‘LU’, ‘none’}, default=’auto’ Power iteration normalizer for randomized SVD solver. Not used by ARPACK. See :func:`~sklearn.utils.extmath.randomized_svd` for more details. .. versionadded:: 1.1 ‘auto’ random_state random_state: int, RandomState instance or None, default=None Used when the ‘arpack’ or ‘randomized’ solvers are used. Pass an int for reproducible results across multiple function calls. See :term:`Glossary `. .. versionadded:: 0.18.0 None To keep the notebook lightweight, we pull all time steps and bands for a small spatial subset rather than the full mosaic. AlphaEarth Foundations embeddings contain 64 bands, so this smaller window reduces data transfer while still preserving the temporal behavior we want to inspect. The same workflow can be scaled up for larger analyses. # can take 30+ seconds subset = ds["variables"][:, :, :1024, :2048].compute() # Transform with PCA flattened = subset.transpose("band", "time", "y", "x").data.reshape(64, -1).T transformed = model.transform(flattened) img = transformed.T.reshape(3, subset.shape[0], subset.shape[2], subset.shape[3]).transpose( 1, 0, 2, 3 ) # Use the existing xarray data structure to build a nice home for PCA data. subset_copy = subset.copy() array = subset_copy.isel(band=slice(0, 3)) # insert the transformed PCA data array.data = img array["band"] = ["pca1", "pca2", "pca3"] # we chunk only to get a better view of the dataset array.to_dataset(name='variables') Size: 227MB Dimensions: (time: 9, x: 2048, y: 1024, band: 3) Coordinates: * time (time) datetime64[ns] 72B 2017-01-01 2018-01-01 ... 2025-01-01 * x (x) float64 16kB -1.055e+07 -1.055e+07 ... -1.053e+07 * y (y) float64 8kB 5.178e+06 5.178e+06 ... 5.168e+06 5.168e+06 * band (band) Size: 533MB Dimensions: (time: 8, band: 1, y: 3020, x: 5512) Coordinates: * time (time) datetime64[ns] 64B 2018-01-01 2019-01-01 ... 2025-01-01 * band (band) object 8B 'cosine_distance' * y (y) float64 24kB 5.178e+06 5.178e+06 ... 5.148e+06 5.148e+06 * x (x) float64 44kB -1.055e+07 -1.055e+07 ... -1.049e+07 spatial_ref int64 8B 0 Data variables: variables (time, band, y, x) float32 533MB 0.188 0.1655 ... 0.02265xarray.DatasetDimensions:time: 8band: 1y: 3020x: 5512Coordinates: (5)time(time)datetime64[ns]2018-01-01 ... 2025-01-01array(['2018-01-01T00:00:00.000000000', '2019-01-01T00:00:00.000000000', '2020-01-01T00:00:00.000000000', '2021-01-01T00:00:00.000000000', '2022-01-01T00:00:00.000000000', '2023-01-01T00:00:00.000000000', '2024-01-01T00:00:00.000000000', '2025-01-01T00:00:00.000000000'], dtype='datetime64[ns]')band(band)object'cosine_distance'array(['cosine_distance'], dtype=object)y(y)float645.178e+06 5.178e+06 ... 5.148e+06array([5177915.753919, 5177905.753919, 5177895.753919, ..., 5147745.753919, 5147735.753919, 5147725.753919], shape=(3020,))x(x)float64-1.055e+07 ... -1.049e+07array([-10545553.188165, -10545543.188165, -10545533.188165, ..., -10490463.188165, -10490453.188165, -10490443.188165], shape=(5512,))spatial_ref()int640crs_wkt :PROJCS["WGS 84 / Pseudo-Mercator",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Mercator_1SP"],PARAMETER["central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs"],AUTHORITY["EPSG","3857"]]spatial_ref :PROJCS["WGS 84 / Pseudo-Mercator",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Mercator_1SP"],PARAMETER["central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs"],AUTHORITY["EPSG","3857"]]GeoTransform :-10545558.188164568 10.0 0.0 5177920.753919057 0.0 -10.0array(0)Data variables: (1)variables(time, band, y, x)float320.188 0.1655 ... 0.01864 0.02265array([[[[0.18804508, 0.16548318, 0.1549539 , ..., 0.6547667 , 0.6600232 , 0.6827302 ], [0.09239805, 0.08352977, 0.07957667, ..., 0.65431345, 0.6571518 , 0.6796979 ], [0.07838935, 0.07207382, 0.07041121, ..., 0.64434373, 0.643643 , 0.67302835], ..., [0.0281769 , 0.02823567, 0.02864486, ..., 0.32737243, 0.3262853 , 0.30775493], [0.04068887, 0.04150879, 0.03881335, ..., 0.3269202 , 0.3267812 , 0.31013072], [0.04347068, 0.04405069, 0.04101866, ..., 0.3367141 , 0.33538705, 0.3183689 ]]], [[[0.20149559, 0.17581868, 0.16398937, ..., 0.4470787 , 0.448758 , 0.45887315], [0.09369123, 0.08462119, 0.07994598, ..., 0.44638008, 0.44314015, 0.45811075], [0.08294475, 0.07634479, 0.07309014, ..., 0.44814014, ... [0.04521638, 0.04491764, 0.04381305, ..., 0.46263814, 0.45893395, 0.4046142 ], [0.04455835, 0.04325521, 0.04292834, ..., 0.46341467, 0.4581054 , 0.40957177]]], [[[0.49459922, 0.46871775, 0.4611882 , ..., 0.1296547 , 0.12676072, 0.12663496], [0.4966467 , 0.4909042 , 0.4853648 , ..., 0.1275351 , 0.1253922 , 0.1257289 ], [0.4927944 , 0.4910075 , 0.48507315, ..., 0.12276459, 0.11952102, 0.12123233], ..., [0.08114195, 0.08070195, 0.08397031, ..., 0.01797432, 0.01881957, 0.02318203], [0.08387047, 0.0837459 , 0.08279037, ..., 0.01825058, 0.01814717, 0.02346212], [0.08379203, 0.08498359, 0.08619195, ..., 0.01759416, 0.01863509, 0.02264881]]]], shape=(8, 1, 3020, 5512), dtype=float32) array = ds["variables"][:, :, :, :] low = np.nanpercentile(array[0].values, 0) high = np.nanpercentile(array[0].values, 50) frames = [to_uint8_robust(array.sel(time=t)[0], low, high)[:, :] for t in array.time] iio.imwrite("assets/distance_over_time_50p.gif", frames, duration=1000, loop=0) In the animation above, darker pixels indicate embeddings that remain more similar over time, while lighter pixels indicate larger temporal differences. Interpretation is still evolving, but the visualization suggests several useful patterns. Persistent bright pixels may mark locations with repeated or abrupt change. Alternating light-dark cycles may indicate recurring agricultural activity such as planting, harvest, or irrigation. This does not replace domain knowledge, but it provides another lens for understanding how field-scale practices appear in AlphaEarth Foundations embeddings. What AlphaEarth Foundations Embeddings Show About Field-Level Dynamics AlphaEarth Foundations embeddings make it possible to examine agricultural change as a time series in embedding space rather than only as raw imagery. In this notebook, we built Zarr mosaics for several AOIs, visualized temporal variation in the first three embedding bands, projected the embeddings with PCA, and then compared that view with a distance-over-time workflow. Together, these helped draw insight into a few of the many ways AlphaEarth Foundations embeddings (and others) can provide insight into field-level dynamics. Check out Change Detection Using AlphaEarth Foundations (Part 2). Get Started with RasterFlow Start Building Frequently Asked Questions What is AlphaEarth Foundations? A geospatial AI model from Google DeepMind. It compresses a year of satellite observations into 64-dimensional embedding vectors for every 10-meter pixel on Earth’s land surfaces and shallow coastal waters, produced annually. How do you visualize agricultural change in AEF embeddings? This notebook compares three views: the first three embedding bands rendered as RGB over 2017–2025, a PCA projection of the 64-d vectors into three components, and an experimental cosine-distance-over-time raster. PCA is presented as the more interpretable view for field-level seasonal patterns. Which regions are used in the AEF agriculture notebook? Three small AOIs with agricultural fields: one in Iowa, one in California, and one in Japan. Each gets its own Zarr mosaic from RasterFlow build_gti_mosaic so they can be inspected independently. Does this notebook claim to detect crop type from AlphaEarth? No. The author states the goal is not a definitive interpretation of AEF. The notebook shows a workflow for exploring seasonal cycles and field-scale dynamics in embedding space.Complementary posts cover zonal statistics on field polygons and LOO-medoid change scoring. --- ## Mobility Data Processing at Scale: Why Traditional Spatial Systems Break Down URL: https://wherobots.com/blog/mobility-data-processing-traditional-systems/ Updated: 2026-10-19 Mobility data is the continuous stream of GPS location records capturing how people, vehicles, and assets move through the world. Processing it at scale is fundamentally different from standard spatial data work because it carries temporal dependencies: the order and timing of observations define movement, not just position. Most organizations have discovered, often painfully, that the tools they already use were not designed with that in mind. In Part 2, we walk through the technical implementation: a three-notebook medallion architecture built on Wherobots and Apache Sedona that takes raw GPS pings and transforms them into analysis-ready, GeoParquet-backed analytical views. Key takeawaysMobility data is not spatial data with timestamps attached: order and timing define movement.ACM researchers characterize the field as requiring its own science, because general-purpose pipelines consistently produce suboptimal results on movement data.Volume: a vehicle pinging at one-second intervals produces roughly 86,400 records per day. A 10,000-vehicle fleet generates over 860 million points daily.Median GPS error of 7 meters with standard deviations exceeding 23 meters has been documented in urban environments. Different but reasonable preprocessing choices on the same GPS dataset led to substantially different COVID-19 modeling conclusions (UPenn CSSLab).Most spatial systems are 2D. Elevation and XYZM (time as M) matter for fuel modeling, mountainous routing, aviation/drones, and trajectory validation, but 4D support is rare.Trip-gap thresholds (5 vs 20 vs 60 minutes) change trajectory structure and every derived metric. Distributed collect operations can scramble M-ordering.Desktop GIS hits a single-machine ceiling, and PostGIS is single-node. Snowflake/BigQuery spatial support is described as shallow for XYZM and map matching, and vanilla Spark has no native spatial types.Map matching as an external API hits rate limits and per-request pricing. Part 2 implements a three-notebook medallion pipeline on Wherobots/Sedona using GeoLife (17,621 trajectories, 182 users, Beijing 2007–2012). Why Mobility Data Is Harder to Process Than It Looks Every second, billions of GPS-equipped devices generate spatiotemporal data capturing how people, goods, and vehicles move through the physical world. The market reflects how seriously organizations are treating this: the global fleet management market is valued at approximately $27 billion in 2025 and projected to exceed $122 billion by 2035. Mobility data analytics platforms are on a similar trajectory, from $2.5 billion to over $11 billion by 2034. But collecting this data and actually extracting reliable intelligence from it are two very different things. Most organizations have discovered, often painfully, that the tools they already use were not designed with GPS mobility data in mind. The result is brittle pipelines, inconsistent methodologies, and analyses that quietly produce misleading conclusions. Researchers at ACM have characterized the field as requiring its own dedicated science because general-purpose data science pipelines consistently produce suboptimal results when applied to movement data. Understanding why requires looking at the specific properties that make mobility data uniquely difficult to process correctly. What Makes Mobility Data Different From Standard Spatial Data Mobility data is not just spatial data with timestamps attached. It is a distinct category of data that violates assumptions built into most data processing systems. Researchers at ACM have characterized the field as requiring its own dedicated science—Mobility Data Science—because general-purpose data science pipelines consistently produce suboptimal results when applied to movement data. Understanding why requires examining the specific properties that make trajectory data uniquely challenging. Why GPS Data Volume Overwhelms Traditional Databases The volume and velocity problem is the recognition that GPS data generation at fleet scale is not a batch analytics challenge, it is a continuous, high-throughput data engineering problem that demands distributed processing from the start. A single connected vehicle generating GPS pings at one-second intervals produces roughly 86,400 records per day. A fleet of 10,000 vehicles generates over 860 million data points daily. Multiply this across the millions of connected vehicles, delivery drones, rideshare fleets, and maritime vessels operating globally, and the scale becomes staggering.  Traditional spatial databases like PostGIS, which excel at transactional workloads and moderate-scale analytics, were not designed for this volume. Loading hundreds of millions of GPS points into PostgreSQL, constructing geometries, and running spatial joins or trajectory reconstruction queries can take hours or days on a single node. Adding more hardware does not solve the fundamental problem: PostGIS was not built for distributed, parallel spatial computation. How GPS Signal Noise Corrupts Downstream Analysis GPS noise is error in raw location readings caused by signal reflection, satellite loss in tunnels and urban canyons, and atmospheric interference and it cascades through every downstream analysis built on top of it. Signals bounce off buildings, lose satellites in tunnels and urban canyons, and suffer from atmospheric interference. Studies have documented median GPS errors of 7 meters with standard deviations exceeding 23 meters in urban environments. Points can appear on the wrong side of a street, inside buildings, or kilometers from the actual position when signal quality degrades. Speed calculations between consecutive points can spike to physically impossible values. Distance measurements accumulate systematic errors. Clustering algorithms identify phantom stop locations. Without rigorous cleaning and validation at the earliest stages of the pipeline, every subsequent insight is built on a compromised foundation. Researchers at the University of Pennsylvania’s Computational Social Science Lab studied exactly this problem in the context of COVID-19 epidemic modeling. Using the same GPS mobility dataset, they found that different but individually reasonable preprocessing choices led to substantially different conclusions. a methodological “garden of forking paths” where reproducibility became nearly impossible. The root causes: data sparsity, sampling bias, and inconsistent algorithmic choices at the preprocessing stage. Why Temporal Ordering Is Critical in Mobility Data Processing Trip segmentation is the process of splitting a continuous GPS stream into discrete trips by detecting temporal gaps, periods where no data was recorded or the device was stationary. Mobility data is not simply geospatial—it is spatiotemporal. Every GPS point has a position and a timestamp, and the relationship between consecutive observations is what defines movement. This trip segmentation step alone introduces significant methodological complexity, because the threshold you choose (5 minutes? 20 minutes? 60 minutes?) fundamentally changes the structure of your resulting trajectories and all metrics derived from them. Beyond segmentation, ordering matters. Trajectories are sequences, not sets. Every analytical operation—speed calculation, direction changes, stop detection, map matching—depends on correct chronological ordering within each trip. Systems that do not preserve or guarantee ordering (a common challenge in distributed frameworks) can produce geometries that appear valid but contain scrambled temporal information. Why 2D Spatial Systems Fail for Mobility Analytics The dimensionality problem is the gap between how most spatial systems model location, latitude and longitude only and what mobility analysis increasingly requires: 3D and 4D geometry that encodes elevation and time directly into the geometry itself. Most spatial systems treat location as a 2D construct: latitude and longitude. But mobility analysis increasingly demands 3D and 4D processing. Elevation matters for fuel consumption modeling, route optimization in mountainous terrain, aviation and drone trajectories, and any analysis where the difference between 2D and 3D distance is materially significant. Adding a temporal measure dimension (the “M” in XYZM geometries) enables encoding timestamps directly into the geometry itself, supporting trajectory validation and interpolation operations that are impossible with 2D points. Yet 4D geometry support—constructing XYZM points, building trajectories from them, and performing analytical operations that respect all four dimensions—is rare. Most spatial SQL implementations either lack these functions entirely or implement them inconsistently. This forces practitioners to maintain separate columns for elevation and time, losing the computational advantages of integrated 4D geometry processing. Where Traditional Spatial Systems Fail for Mobility Data SystemPrimary Limitation for Mobility DataDesktop GIS (QGIS, ArcGIS Pro)Single-machine ceiling, no distributed processingPostGISSingle-node, not built for hundreds of millions of GPS pointsCloud data warehouses (Snowflake, BigQuery)Shallow spatial support, cannot handle XYZM or map matchingVanilla Apache SparkNo native spatial types, no spatial indexingExternal map matching APIsRate limits and per-request pricing make batch processing prohibitive Desktop GIS: The Single-Machine Ceiling Tools like QGIS and ArcGIS Pro are extraordinarily capable for visualization, manual analysis, and working with datasets that fit in memory. But they hit a hard wall with mobility data at scale. Loading millions of GPS trajectories, performing trip segmentation with window functions, running DBSCAN clustering on stop points, and executing map matching against a road network are not operations that desktop GIS was designed to handle. Analysts working with fleet-scale data routinely encounter out-of-memory errors, multi-hour processing times, and the inability to iterate quickly on analytical parameters. Spatial Databases: Scale Without Spatial Intelligence PostGIS remains the gold standard for spatial SQL and is an excellent choice for many use cases. However, it is fundamentally a single-node system. Scaling PostGIS to handle hundreds of millions of GPS points requires expensive vertical scaling, and even then, operations like trajectory construction across thousands of users, spatial indexing with H3 or GeoHash, and DBSCAN clustering at urban scale can exhaust available resources. Cloud data warehouses like Snowflake, BigQuery, and Redshift have added spatial capabilities, but these tend to be shallow implementations optimized for simple point-in-polygon or distance queries. Constructing XYZM trajectories from ordered GPS points, performing spatial clustering, computing 3D distances, or running map matching against a road network are either unsupported or require convoluted workarounds that sacrifice performance and maintainability. General-Purpose Distributed Frameworks: Power Without Spatial Awareness Apache Spark provides the distributed computing muscle needed for mobility-scale data, but vanilla Spark has no concept of spatial data types, spatial indexing, or geometric operations. Running a spatial join in pure Spark requires broadcasting datasets or implementing custom partitioning strategies—both of which are error-prone and perform poorly at scale compared to purpose-built spatial engines. This is precisely the gap that Apache Sedona and Wherobots were designed to fill. Sedona extends Spark (and other distributed frameworks) with native spatial data types, over 290 spatial SQL functions, spatial indexing, and optimized query planning that understands geometric predicates. Wherobots builds on Sedona to provide a fully managed, cloud-native spatial intelligence platform where teams can process GPS-scale data without managing infrastructure, configuring clusters, or bolting together fragmented toolchains. Map Matching: The Unsolved Infrastructure Problem Map matching—the process of snapping noisy GPS traces to the actual road network—is one of the most computationally demanding and methodologically complex steps in any mobility pipeline. It requires loading a complete road network graph, computing probabilistic alignments between GPS observations and candidate road segments, and resolving ambiguities at intersections, parallel roads, and complex interchanges. Most map matching solutions are either commercial APIs with strict rate limits and per-request pricing that make batch processing of historical data prohibitively expensive, or open-source tools that require significant infrastructure setup and do not scale to city-wide or fleet-wide datasets. Researchers have consistently identified scalability as the primary bottleneck: algorithms that produce accurate matches on small datasets fail to perform when confronted with millions of trajectories. Having map matching available as an integrated capability within the same distributed environment where you are already processing and analyzing your trajectory data—rather than as an external API call or a separate system—eliminates an entire category of infrastructure complexity and data movement overhead. The Real Cost of a Fragmented Mobility Data Pipeline In practice, most organizations processing mobility data have assembled a patchwork of tools: Python scripts for data cleaning, PostGIS for spatial operations, custom code for trip segmentation, an external API for map matching, a separate clustering library, and a visualization tool at the end. Each transition between tools introduces data serialization overhead, potential for schema drift, and opportunities for subtle bugs. This fragmentation carries real costs beyond engineering time. When a researcher needs to change the trip segmentation threshold from 20 minutes to 30 minutes, the entire pipeline must be re-executed across multiple systems. When a new data source arrives with a slightly different schema, adapters must be updated at each integration point. When results need to be reproduced for regulatory or academic review, reconstructing the exact sequence of operations across disparate tools is often impractical. The ideal mobility data pipeline processes GPS pings through ingestion, cleaning, enrichment, trajectory construction, map matching, spatial indexing, clustering, and analytical aggregation—all within a single, distributed, spatially-aware environment where every step is expressed in SQL or Python, every intermediate result is inspectable, and the entire pipeline can be reproduced with a single execution. What a Modern Mobility Data Architecture Looks Like The medallion architecture—Bronze, Silver, Gold—has become the standard pattern for progressive data refinement in the data lakehouse world. But applying it to mobility data requires rethinking what each layer does, because spatial data introduces transformations and enrichment steps that have no analog in conventional data engineering. Bronze is not just ingestion—it is spatial profiling. You are not only loading CSV or Parquet files; you are constructing point geometries, validating coordinate bounds, assessing data quality metrics like altitude validity and temporal coverage, and establishing the spatial extent of your dataset. Silver is where the heavy lifting happens. This is trip segmentation, 4D geometry construction, trajectory building, movement metric derivation, spatial indexing, and map matching. Each of these operations is computationally intensive, order-dependent, and requires spatial functions that most data platforms simply do not have. Gold produces the analytical views that power downstream consumption: H3 hexbin density heatmaps, temporal activity patterns, stop detection via spatial clustering, trajectory anomaly flagging, and road segment speed analysis. These views are written as GeoParquet files—compatible with Kepler.gl, QGIS, Felt, Foursquare Studio, and DuckDB Spatial—ensuring that the output of the pipeline is immediately consumable by any modern geospatial visualization or analytics tool. How Wherobots Handles Mobility Data Processing: What We Built To demonstrate this architecture in practice, we built a three-notebook Wherobots Mobility Solution Accelerator using the Microsoft Research GeoLife GPS Trajectories dataset—one of the few open mobility datasets that includes elevation data, enabling full 4D geometry processing. The dataset contains 17,621 trajectories from 182 users in Beijing, with latitude, longitude, altitude, and timestamps spanning 2007–2012. In Part 2, we walk through every notebook in detail: the Bronze layer’s ingestion and profiling pipeline, the Silver layer’s 4D trajectory construction and map matching workflow, and the Gold layer’s analytical and exploratory views. We cover the specific Apache Sedona spatial SQL functions used at each step, the PySpark window function patterns for trip segmentation and movement metrics, and the real-world challenges we encountered and solved—from Spark’s schema inference corrupting timestamp values, to COLLECT_LIST not preserving order in trajectory construction, to DBSCAN requiring physical column references. If you are building mobility analytics pipelines and hitting the limitations of your current toolchain, Part 2 will give you a concrete, reproducible blueprint for how to do it on Wherobots. Get Started with Wherobots Access Now Frequently Asked Questions What is mobility data? Mobility data is the continuous stream of GPS location records capturing how people, vehicles, and assets move through the world. Unlike standard spatial data, it carries temporal dependencies: the order and timing of observations define movement, making position and time equally important for analysis.Fleet management platforms, rideshare services, logistics companies, and urban planners all work with mobility data to understand movement patterns, optimize routes, and model demand. Why does PostGIS fail for large-scale GPS data processing? PostGIS runs on a single node. At fleet scale, a single vehicle generating pings every second produces roughly 86,400 records per day. A fleet of 10,000 vehicles generates over 860 million points daily.Loading, indexing, and running trajectory reconstruction or spatial join queries against that volume on a single PostgreSQL node takes hours or fails entirely. The core issue is architectural: PostGIS was built for transactional workloads and moderate-scale analytics, not distributed parallel computation at GPS scale. What is the medallion architecture for mobility data? The medallion architecture organizes data processing into three layers: Bronze, Silver, and Gold. For mobility data, Bronze handles ingestion and spatial profiling, including constructing point geometries, validating coordinate bounds, and assessing data quality.Silver handles the computationally intensive work: trip segmentation, 4D geometry construction, trajectory building, spatial indexing, and map matching. Gold produces analysis-ready views used downstream, including H3 hexbin density maps, stop detection clusters, and road segment speed analysis. Each layer builds on the previous one, and the full pipeline is reproducible from a single execution. What is map matching and why is it hard to scale? Map matching snaps noisy GPS traces to the actual road network so that scattered coordinates become paths following real streets. It requires loading a complete road network graph and computing probabilistic alignments between GPS observations and candidate road segments. It also has to resolve ambiguities at intersections and parallel roads.Commercial API solutions impose rate limits and per-request pricing that make batch processing of historical data expensive. Open-source tools require significant infrastructure setup and consistently underperform when processing millions of trajectories. --- ## PostGIS vs Wherobots: What It Actually Costs You to Choose Wrong URL: https://wherobots.com/blog/spatial-database-cost-comparison-postgis-vs-wherobots/ Updated: 2026-10-19 When building a geospatial platform, technical decisions are never just technical, they are financial. Choosing the wrong architecture for your spatial data doesn’t just frustrate your data team; it directly impacts your bottom line through large cloud infrastructure bills and, perhaps more dangerously, delayed business insights. Key takeawaysPostGIS is optimized for low-latency lookups. Wherobots is optimized for high-throughput analytics and data processing.Using the wrong one for the wrong job costs you both time and money.A PostGIS server must be provisioned for peak load, so you pay for maximum capacity even when usage is low. Wherobots is designed to charge primarily for active compute time, so you are not paying for idle capacity.For industries like insurance, logistics, and urban planning, the right architecture choice can dramatically reduce query time for large-scale spatial analysis. In some cases it drops from hours or days down to minutes.PostGIS and Wherobots are not mutually exclusive. Many enterprises use Wherobots to process data at scale, then serve results through PostGIS for live application access. Use the checklist in this post as a fast diagnostic. If you are waiting hours for spatial queries or your cloud bill is outpacing your revenue growth, you have a strong case for cloud-native spatial compute. For decision-makers, the choice between a traditional spatial database (like PostGIS, an open-source extension of PostgreSQL that adds support for storing and querying location data) and a cloud-native geospatial analytics platform (like Wherobots, built with distributed computing including Apache Spark to process massive spatial datasets in parallel across compute clusters) comes down to two fundamental metrics: Time to Insight and Total Cost of Ownership (TCO). To understand where to invest your budget, we need to look beyond the software labels and understand the economics of how these systems handle data. If you are new to the PostGIS vs Wherobots discussion, start with [Part 1: PostGIS, Wherobots, and the Spatial Data Lakehouse: A Strategic Guide for Leaders]. This post assumes you understand the architectural difference and focuses on what it actually costs you to choose wrong. Why Slow Spatial Queries Cost More Than You Think In the modern enterprise, the value of data decays over time. An answer delivered in 5 seconds is actionable; an answer delivered in 5 days is a post-mortem. The architecture you choose dictates how fast you can answer complex questions. Low Latency vs High Throughput: What Speed Actually Means for Each Tool It is crucial to understand the difference between “speed” for an app and “speed” for analytics. Low Latency (PostGIS): This is the speed of retrieval. When a customer opens your delivery app and asks, “Where is my driver?”, they need an answer in milliseconds. PostGIS is optimized for this. It uses heavy indexing to find a single “needle in a haystack” instantly. High Throughput (Wherobots): This is the speed of processing. When your risk analyst asks, “Which of our 50,000 retail locations are at risk of flooding based on the new 100-year climate models?”, they are not looking for a needle; they are looking for patterns across the whole haystack. The Bottleneck: If you try to run that massive climate model analysis in PostGIS, the database has to check every single location against every single flood zone, even with optimizations for search like spatial indexing. Because PostGIS typically runs on a single server, running that analysis forces your app and your analytics to compete for the same resources. The query might take 24 hours, and your customer-facing app slows down the whole time. The Solution: Wherobots breaks that same job into parallel tasks across a cluster of worker nodes, each handling a partitioned geographic slice. Because the work happens simultaneously, the job finishes in minutes instead of hours.  Business Impact: Your analysts get answers before lunch, not next week. Your operational apps remain fast for customers because the heavy lifting happened elsewhere. PostGIS vs Wherobots: Why the Pricing Models Are Fundamentally Different The second major factor is how you pay for these capabilities. Query speed is only half the cost story. The other half is how each system charges you. The pricing models for databases and cloud-native engines are fundamentally different. Why PostGIS Forces You to Pay for Peak Capacity Around the Clock A high-performance database like PostGIS requires expensive hardware specifically, high-speed RAM and fast CPUs, to keep your data accessible. The Lease Model: PostGIS requires provisioning a server for peak load, which means you pay for maximum capacity even when usage is low. Think of it like leasing a Ferrari just to drive to the grocery store on Sundays. You have to provision this server for your peak usage. If you need to run a heavy report once a week that requires 64 cores of CPU, you must pay for a 64-core server 24 hours a day, 7 days a week.  The Waste: For the other 6 days and 23 hours, that expensive server sits idle, burning budget. It is analogous to leasing a Ferrari just to drive to the grocery store on Sundays. How Wherobots Charges Only for Active Compute Time Wherobots uses an elastic, on-demand pricing model: you consume compute while an operation is actively running, then billing stops when it finishes. Storage and compute are decoupled, meaning your data sits in low-cost object storage and you rent processing power only when you need it. Storage is Cheap: You keep your massive datasets in low-cost Object Storage (like Amazon S3), which costs pennies per gigabyte. Compute is On-Demand: When you need to run that heavy climate model, you rent the 1,000 computers for exactly 15 minutes. The moment the job is done, the machines turn off, and the billing stops. The Savings: You convert a massive fixed Capital Expenditure (CapEx) into a lean, manageable Operational Expenditure (OpEx). Create your Wherobots account Get Started PostGIS vs Wherobots: Which One Is Right for Your Use Case? To make this concrete, let’s look at three distinct industry examples and which tool provides the best ROI for each. 1. Logistics and Delivery: Why Real-Time Tracking Needs PostGIS Scenario: You need to route drivers in real-time and show customers where their package is. The Choice: PostGIS. Why: You need transactional guarantees. If a driver marks a package as “Delivered,” that data must be instantly saved and visible. You are doing millions of tiny, fast lookups. 2. Insurance and Real Estate: Why Portfolio-Scale Risk Analysis Needs Wherobots Scenario: You need to calculate risk premiums for 10 million homes based on historical wildfire data, distance to fire stations, and vegetation density indices. The Choice: Wherobots. Why: This is a “Global Join.” You are comparing massive datasets against each other. PostGIS would take weeks to process this at a national scale. Wherobots can recalculate the entire portfolio every night, allowing you to adjust pricing dynamically. 3. Urban Planning: Why Time-Series Sensor Data Overwhelms a Standard Database Scenario: You are ingesting telemetry data from 50,000 connected traffic lights and sensors to analyze traffic congestion trends over the last 5 years. The Choice: Wherobots. Why: The volume of data (Time-Series) is too large for a standard database. A database would bloat, slow down, and become expensive to back up. Wherobots can read this data directly from cheap storage, aggregate it into trends, and output the results. PostGIS vs Wherobots: Decision Checklist PostGIS is a good choice when your primary use case is powering a user-facing application that needs fast, transactional lookups on a relatively stable dataset. Wherobots is the better choice when you are running analytical queries across complex datasets, processing historical data at scale, or need compute costs that flex with actual usage rather than peak capacity. If you are currently evaluating your data stack, use this simple checklist to guide your architecture decision. Stick with PostGIS if: [ ] Your primary goal is powering a user-facing application. [ ] You need to edit data manually (e.g., fixing property boundaries). [ ] Your dataset is relatively stable and fits comfortably on one large server. [ ] You require strict “ACID” transactions (meaning every write is confirmed and visible before the next read — no partial updates, no stale reads) Move to Wherobots if: [ ] You are waiting hours or days for analytical queries to finish. [ ] Your cloud database bill is growing faster than your revenue. [ ] You need to join two massive datasets (e.g., “All Buildings” + “All Parcels”). [ ] You are building AI/Machine Learning models that need to “learn” from all your historical data. The most competitive organizations today realize they don’t have to choose just one. They use Wherobots to crunch the data cheaply and efficiently, and then move the polished results into PostGIS for instant access—a strategy we will cover in our next post on the “Medallion Architecture”, a data design pattern where raw, refined, and production-ready data are stored in separate layers, each optimized for different workloads (covered in Medallion Architecture for Geospatial Data) Ready to see what this looks like for your workload? Contact us and get a cost comparison built around your actual data volume. Frequently Asked Questions Is PostGIS cheaper than Wherobots? The post says the pricing models are different, not that one sticker price wins. PostGIS requires provisioning a server for peak load, so a weekly 64-core report means paying for 64 cores 24/7.Wherobots keeps data in low-cost object storage and rents compute while a job runs. The climate-model example is renting 1,000 machines for 15 minutes, then billing stops. When should I use PostGIS vs Wherobots? PostGIS fits user-facing apps, manual edits, datasets that fit on one large server, and strict ACID transactions (for example real-time ‘where is my driver?’).Use Wherobots for analytical queries that take hours or days, or a database bill growing faster than revenue. It also fits joins of two massive datasets (all buildings + all parcels) or ML that needs historical spatial data.Logistics tracking is the PostGIS example; 10 million home wildfire premiums and 50,000-sensor traffic time series are the Wherobots examples. What is the difference between low latency and high throughput for spatial databases? Low latency (PostGIS) is retrieval speed: milliseconds to find a needle in a haystack for an app. High throughput (Wherobots) is processing speed: partitioning a ‘which of 50,000 locations flood under the new 100-year model’ job across worker nodes.That lets the job finish in minutes instead of competing with the app on one server for 24 hours. Can I use PostGIS and Wherobots together? Yes. The post says the most competitive organizations use Wherobots to crunch data cheaply, then move polished results into PostGIS for instant access. This is the Medallion Architecture covered in the next post of the series. --- ## Streaming Spatial Data into Wherobots with Spark Structured Streaming URL: https://wherobots.com/blog/streaming-spatial-data-into-wherobots-with-spark-structured-streaming/ Updated: 2026-10-19 Real-time Spatial Pipelines Shouldn’t Be This Hard (But They Were) I’ve been doing geospatial work for over twenty years now. I’ve hand-rolled ETL pipelines, babysat cron jobs, and debugged more coordinate system mismatches than a person should reasonably endure in one lifetime. So when someone says “streaming spatial data,” my first reaction used to be something between a deep sigh and a nervous laugh. Key takeawaysSpark Structured Streaming works natively on Wherobots. You can use readStream / writeStream with foreachBatch as you would in any Spark environment, with Sedona spatial functions and Iceberg tables available out of the box.Convert coordinates to geometry at ingest time. Use ST_PointZM (or ST_Point, ST_PointZ depending on your data) with ST_SetSRID to create proper geometry objects, so no downstream consumer has to do it.Apply business rules during ingest. Compute flags like is_speeding, geofence containment and proximity alerts once and store them as columns: the silver layer principle applied to streaming.Capture lineage in the stream. input_file_name() for file-level tracing, batch_id from foreachBatch, and WBC_LABEL_product_instance_id for job-run-level tracing. Three columns, zero additional infrastructure.Write with .writeTo().append(), not .write.format().save(). Use the catalog-managed write pattern and let Wherobots handle the storage details. Here’s the thing: streaming tabular data with Spark Structured Streaming is a well-trodden path. There are tutorials everywhere. But streaming spatial data where you need to create geometry objects, apply spatial business rules, and land the results in a format that actually understands what a Point is (pun definitely intended); that’s where most guides quietly end. This post walks through a complete, working pipeline that takes raw telemetry data (fleet tracking, asset monitoring, IoT sensors, etc.) and streams it into a Wherobots managed Iceberg tables with full Sedona geometry support. No hand-waving… Real code… The kind of thing you can run on Wherobots Cloud this afternoon. What We’re Building The architecture is intentionally straightforward. Three components, one direction, no backflips required: Data Source — Parquet files landing in an S3 bucket. Each file contains asset tracking events: lat/lon/altitude, speed, heading, operator, asset ID, and status. Think of this as the output from any fleet management system, IoT gateway, or sensor network. Streaming Ingest Job — A Spark Structured Streaming job running on Wherobots that watches the S3 path, picks up new Parquet files as they arrive, converts raw coordinates into Sedona geometry objects, applies business rules (like a speeding flag), and writes each micro-batch to an Iceberg table in the Wherobots catalog. Viewer Notebook — A Wherobots notebook that reads the catalog table and gives you stats, batch-level detail, a bar chart, and an interactive map colored by speeding status. The “so what” layer. A Downstream Application Layer — Once the data is prepared and ready for consumption, it can be fed into a downstream application or database that can serve the data to other consumers: a map, or another data processing system. The generator that produces the Parquet files is a separate concern; any system that drops Parquet into S3 works. We’re focused on the Wherobots side: how you consume, transform, and catalog streaming spatial data. The Source Schema The source data uses a flat schema — no geometry column yet. That’s deliberate. Most real-world telemetry arrives as plain numbers (latitude, longitude, altitude), not as WKB or WKT geometry strings. The spatial enrichment happens during ingest. ColumnTypeDescriptionevent_idSTRINGUnique event identifiertimestampTIMESTAMPEvent timexDOUBLELongitudeyDOUBLELatitudezDOUBLEAltitude (meters)speed_mphDOUBLESpeed in miles per hourheadingDOUBLECompass heading (degrees)operator_nameSTRINGFleet operatorasset_idSTRINGIndividual asset identifierasset_typeSTRINGAsset category (e.g., truck, drone)statusSTRINGOperational status Eleven columns. No geometry. That’s what Sedona is for. Setting Up the Streaming Ingest SedonaContext Initialization The first thing the ingest job does is create a SedonaContext. On Wherobots Cloud, Spark is already pre-initialized — you just need to wrap it with Sedona capabilities: from sedona.spark import * config = SedonaContext.builder().getOrCreate() sedona = SedonaContext.create(config) Ensuring the Catalog Schema and Table Exist Before the stream starts, we make sure the target schema and table exist. This is idempotent — safe to run every time the job starts: sedona.sql("CREATE SCHEMA IF NOT EXISTS wherobots.streaming_demo") sedona.sql(""" CREATE TABLE IF NOT EXISTS wherobots.streaming_demo.asset_tracks ( event_id STRING, timestamp TIMESTAMP, x DOUBLE, y DOUBLE, z DOUBLE, speed_mph DOUBLE, heading DOUBLE, operator_name STRING, asset_id STRING, asset_type STRING, status STRING, geometry GEOMETRY, is_speeding BOOLEAN, source_file STRING, batch_id LONG, job_run_id STRING ) """) One thing to call out here: The table has more columns than the source. The source Parquet has 11 fields. The table has 16. The extra five (geometry, is_speeding, source_file, batch_id, job_run_id) are all derived during the ingest process. This is the whole point; we’re enriching raw telemetry into spatially-aware, business-rule-tagged, lineage-tracked records. The Spatial Transform This is where the real work happens, and honestly it’s surprisingly compact. Here’s the transform that runs on every micro-batch: transformed = raw.selectExpr( "event_id", "timestamp", "x", "y", "z", "speed_mph", "heading", "operator_name", "asset_id", "asset_type", "status", "ST_SetSRID(ST_PointZM(x, y, z, unix_timestamp(timestamp)), 4326) AS geometry", "CASE WHEN speed_mph > 65 THEN true ELSE false END AS is_speeding", "input_file_name() AS source_file", ) Three derived columns in one selectExpr. Let’s break them down. Creating Geometry with ST_PointZM ST_SetSRID(ST_PointZM(x, y, z, unix_timestamp(timestamp)), 4326) AS geometry ST_PointZM creates a 4D point geometry: X = longitude Y = latitude Z = altitude in meters M = the “measure” dimension — here we encode the unix timestamp This is a pattern I’ve come to appreciate. By encoding time as the M value, each point carries its full spatiotemporal context in the geometry itself. If you later need to compute distances or trajectories, the temporal ordering is baked right into the geometry. We wrap the whole thing in ST_SetSRID(..., 4326) to declare it’s in WGS 84. Business Rule: The Speeding Flag CASE WHEN speed_mph > 65 THEN true ELSE false END AS is_speeding Nothing fancy. Speed over 65 mph? You’re speeding. This is computed once, during ingest, and stored in the catalog. Downstream consumers (dashboards, notebooks, APIs) read it directly — no need to recompute. This is the “silver layer” principle applied to streaming: apply your business rules at ingest time so the data is analysis-ready when it lands. Business Rule: Geofence Violation Detection Here’s where things get spatial. The is_speeding flag is a simple column-level rule — no external data needed. But what about spatial business rules that depend on other geometry? Things like: “is this asset inside a school zone buffer?” or “did this truck enter a restricted area?” That’s where Wherobots  in_fence column. During each micro-batch, we left-join the asset points against a table of geofence buffer polygons using ST_Intersects. If a point intersects any buffer, in_fence = true. Why This Has to Happen Inside foreachBatch Your first instinct might be to add the geofence check in the selectExpr alongside the spatial transform. I tried that. Spark won’t let you join a streaming DataFrame against a catalog table directly — the streaming DF is “unresolved” and the join planner doesn’t know what to do with it. The foreachBatch callback is the escape hatch: by the time your function is called, the DataFrame is fully materialized (static), so you can join it against anything. You might also try createOrReplaceTempView so you can write the join as SQL. That works locally, but on Wherobots Cloud it fails with TABLE_OR_VIEW_NOT_FOUND because the internal DROP that precedes the CREATE hits the catalog resolver. DataFrame API join avoids this entirely. Loading the Geofence Table: Broadcast + Cache The geofence table is small (typically dozens to a few hundred buffer polygons) and it rarely changes while the stream is running. Re-reading it from the catalog on every micro-batch would be wasteful. Instead, we load it once at startup, broadcast it so every executor gets a local copy, and cache it so Spark doesn’t re-evaluate it: geofence_df = ( spark.table(GEOFENCE_TABLE) .select(F.col("geometry").alias("fence_geom")) .cache() ) geofence_df.count() # materialize the cache F.broadcast() tells Spark to use a broadcast hash join instead of a shuffle join and the small geofence DataFrame gets shipped to every executor and held in memory, so the join against each micro-batch is local and fast. The .cache() ensures the table read only happens once. The .count() call forces materialization so the cache is warm before the first batch arrives. One tradeoff: if you update the geofence table while the stream is running, the stream won’t see the changes until you restart. For a table that changes rarely (new school zones don’t appear every 30 seconds), that’s a fine deal. The Spatial Join Pattern # geofence_df is the cached DataFrame loaded at startup. # F.broadcast() here — at the join site — so Spark sees it as # part of the join plan and uses a broadcast hash join (no shuffle). df = ( df.alias("a") .join( F.broadcast(geofence_df).alias("b"), F.expr("ST_Intersects(a.geometry, b.fence_geom)"), "left", ) .select("a.*", F.expr("b.fence_geom IS NOT NULL AS in_fence")) ) A few things to note: Alias the geometry column on the geofence side to fence_geom. Both tables have a geometry column; without the alias, Spark can’t resolve the join condition. Left join ensures every asset point survives, even if it doesn’t intersect any fence. Non-matching points get in_fence = false. The IS NOT NULL check on fence_geom is what converts the join result into a boolean flag. File-Level Lineage with input_file_name() input_file_name() AS source_file input_file_name() is a Spark SQL function that resolves to the path of the source file for each row. It has to be called in the selectExpr during the read phase — before foreachBatch materializes the DataFrame — because the file metadata is lost after materialization. This gives you row-level lineage back to the exact Parquet file that produced each record. Useful for debugging, auditing, and answering the question “where did this data come from?” The foreachBatch Writer The write side uses Spark’s foreachBatch pattern, which gives you a regular DataFrame and a batch ID for each micro-batch: def write_batch(df, batch_id): count = df.count() if count > 0: df = ( df.withColumn("batch_id", F.lit(batch_id).cast("long")) .withColumn("job_run_id", F.lit(JOB_RUN_ID)) ) df.writeTo(CATALOG_TABLE).append() Adding Batch and Job Run Lineage Two columns are added inside foreachBatch because they can’t be computed earlier: batch_id — Spark’s micro-batch identifier. Resets to 0 on each job run. job_run_id — Pulled from the Wherobots environment variable WBC_LABEL_product_instance_id. This is the unique ID for each Wherobots Job Run, which means you can trace every record back to the specific job execution that produced it. Together, batch_id + job_run_id give you globally unique batch identification across job runs. Since batch_id resets to 0 on every restart, job_run_id is what makes cross-run analysis possible. The Wherobots-Idiomatic Write Pattern df.writeTo(CATALOG_TABLE).append() Not df.write.format("iceberg").mode("append").save(path). The .writeTo().append() pattern uses the catalog-managed table reference, which means Wherobots handles the underlying storage location, metadata, and Iceberg commit lifecycle. It’s cleaner, and it’s how catalog-native writes are meant to work. Wiring It All Together The streaming query connects the read, transform, and write stages: query = ( transformed.writeStream .foreachBatch(write_batch) .option("checkpointLocation", CHECKPOINT_PATH) .trigger(processingTime="30 seconds") .start() ) The checkpoint location (an S3 path) tracks which files have already been processed. If the job restarts, it picks up exactly where it left off — no duplicate processing, no missed files. The trigger interval of 30 seconds means Spark checks for new files twice a minute. Viewing the Results Once data starts landing in the catalog, a Wherobots notebook can read it directly: df = sedona.table("wherobots.streaming_demo.asset_tracks") That’s it. No path management, no format specification, no schema declaration. The catalog knows what the table is, where it lives, and what the schema looks like. Ingest Stats and Lineage The viewer notebook computes summary statistics including lineage metrics: stats = df.agg( F.count("*").alias("total_records"), F.countDistinct("asset_id").alias("unique_assets"), F.countDistinct("batch_id").alias("unique_batches"), F.countDistinct("job_run_id").alias("unique_job_runs"), F.countDistinct("source_file").alias("unique_source_files"), F.min("timestamp").alias("earliest_event"), F.max("timestamp").alias("latest_event"), F.round(F.avg("speed_mph"), 1).alias("avg_speed_mph"), ) Batch-Level Detail Because we captured batch_id, job_run_id, and source_file during ingest, we can inspect exactly what landed in each batch: df.groupBy("job_run_id", "batch_id").agg( F.count("*").alias("records"), F.countDistinct("source_file").alias("files_in_batch"), F.min("timestamp").alias("first_event"), F.max("timestamp").alias("last_event"), ).orderBy("job_run_id", "batch_id").show(50, truncate=False) Records per Batch — Bar Chart A quick matplotlib chart shows the volume of each micro-batch, which is useful for understanding whether your trigger interval and maxFilesPerTrigger settings are well-tuned: import matplotlib.pyplot as plt batch_pdf = ( df.groupBy("batch_id") .agg(F.count("*").alias("records")) .orderBy("batch_id") .toPandas() ) fig, ax = plt.subplots(figsize=(12, 4)) ax.bar(batch_pdf["batch_id"], batch_pdf["records"], color="steelblue") ax.set_xlabel("Batch ID") ax.set_ylabel("Records") ax.set_title("Records per Batch") plt.tight_layout() plt.show() The Map: PyDeck with Speeding Visualization The payoff. A PyDeck map over Iowa with CARTO’s dark-matter basemap, two stacked layers, and a four-color scheme that encodes both is_speeding and in_fence at a glance: Blue — normal: not speeding, not in a geofence Red  — speeding only Orange  — geofence violation only Magenta  — speeding and in a geofence Points that hit a geofence get a larger radius (24px, or 30px if also speeding) so they pop out of the sea of blue dots. def assign_color(row): if row["is_speeding"] and row["in_fence"]: return (200, 30, 200) # magenta — both violations elif row["in_fence"]: return (255, 140, 0) # orange — geofence only elif row["is_speeding"]: return (220, 50, 50) # red — speeding only else: return (30, 100, 220) # blue — normal sample_pdf["radius"] = sample_pdf.apply( lambda r: 30 if (r["is_speeding"] and r["in_fence"]) else 24 if r["in_fence"] else 12, axis=1, ) The map itself uses two layers stacked together. Underneath, a PolygonLayer renders the geofence buffer polygons as semi-transparent orange regions, so you can see the zones that triggered violations. On top, the ScatterplotLayer plots every asset point with the four-color scheme: import pydeck as pdk geofence_layer = pdk.Layer( "PolygonLayer", data=geofence_pdf, get_polygon="coordinates", get_fill_color=[255, 140, 0, 40], get_line_color=[255, 140, 0, 160], get_line_width=2, pickable=True, ) points_layer = pdk.Layer( "ScatterplotLayer", data=sample_pdf, get_position=["x", "y"], get_fill_color=["color_r", "color_g", "color_b", 180], get_radius="radius", pickable=True, auto_highlight=True, ) deck = pdk.Deck( layers=[geofence_layer, points_layer], initial_view_state=pdk.ViewState(latitude=41.9, longitude=-93.4, zoom=6.5), tooltip={ "text": "{asset_id} ({asset_type})\\n{operator_name}\\nSpeed: {speed_mph} mph\\nSpeeding: {is_speeding}\\nIn Fence: {in_fence}\\nBatch: {batch_id}" }, map_style="", ) deck.show() The sample is capped at 50,000 points for rendering performance. And because both is_speeding and in_fence are already in the catalog, we’re just reading them — not recomputing anything in the notebook. That’s the whole point of doing the enrichment at ingest time. Why This Pattern Matters Let me step back and talk about why this approach is worth your time, beyond the “hey, cool map” factor. Spatial Enrichment at Ingest, Not at Query Time In a lot of organizations, raw coordinates sit in tables as plain doubles, and every analyst who needs geometry has to create it themselves. That means everyone is writing their own ST_Point calls, hoping they got the coordinate order right, and probably not setting the SRID. Baking the geometry creation into the ingest pipeline means it’s done once, correctly, and everyone downstream gets a proper GEOMETRY column with SRID 4326. Business Rules as First-Class Columns The is_speeding flag is one example, but we went further. The in_fence column demonstrates the same principle with a spatial join: during each micro-batch, every point is checked against a table of geofence buffer polygons using ST_Intersects. Speed violations, geofence containment, proximity to restricted areas are all computed during ingest using Sedona on Wherobots and stored as columns in the Iceberg table. Downstream consumers don’t need to know the logic. They just filter on a boolean. Lineage Without Extra Infrastructure source_file, batch_id, and job_run_id give you three levels of traceability — file, batch, and job run — without deploying a separate lineage system. When someone asks “where did this record come from?”, you can answer with a SQL query against the same table. Iceberg: Geometry as a Native Type This is the part that would have made 2010-me cry tears of joy. The GEOMETRY column in a Iceberg table is a native type (as of Iceberg v3), not a serialized blob or a WKT string. Spatial predicates can push down to the storage layer. You can query the table with ST_Contains, ST_DWithin, ST_Intersects — the full Sedona function catalog — and the Iceberg metadata helps prune partitions that can’t possibly match. That’s not something you get from storing WKT in a STRING column in a regular Parquet table. Catalog-Managed Tables, Not Path-Managed Files sedona.table("wherobots.streaming_demo.asset_tracks") is all a downstream consumer needs. No S3 paths, no Parquet glob patterns, no format hints. The Wherobots catalog manages the table lifecycle: schema evolution, ACID transactions, snapshot isolation, time travel. If you’ve ever debugged a pipeline that broke because someone renamed an S3 prefix, you understand why this matters. About the Author Daniel Smith is a Solution Architect at Wherobots with over two decades of experience in geospatial technology. He builds demos, helps customers, breaks things, fixes them, and writes about what he learns from time to time. When he’s not wrestling with coordinate reference systems or touching things he shouldn’t, he’s probably skating or convincing his kids that geography is, in fact, the coolest subject. You can find him on LinkedIn. Ready to stream spatial data into your own Wherobots catalog? Get Started with Wherobots Frequently Asked Questions How do you stream GPS telemetry into Wherobots? A Spark Structured Streaming job on Wherobots watches an S3 path for new Parquet files and converts lat/lon/altitude into Sedona geometry. It applies business rules and appends each micro-batch to a managed Iceberg table with writeTo().append(). The demo uses a 30-second trigger and an S3 checkpoint so restarts neither duplicate nor skip files. Why create ST_PointZM geometry during streaming ingest? Most telemetry arrives as plain numbers, not WKB. ST_PointZM(x, y, z, unix_timestamp) plus ST_SetSRID(…, 4326) encodes longitude, latitude, altitude, and time in one GEOMETRY value. Downstream consumers then get a proper spatial column with SRID 4326 instead of each analyst writing their own ST_Point. How do you join a stream against a geofence table in Spark? You cannot join a streaming DataFrame to a catalog table in selectExpr; the planner sees the stream as unresolved. Do the ST_Intersects left-join inside foreachBatch, after the micro-batch is a static DataFrame.Load the small geofence table once at startup, cache it, and broadcast it. Updates to the geofence table are not seen until the stream restarts. Is Iceberg geometry a native type in this streaming pipeline? Yes. The post states the GEOMETRY column in the Iceberg table is a native type as of Iceberg v3, not a WKT string. Spatial predicates can push down, and Sedona functions such as ST_Contains, ST_DWithin, and ST_Intersects work with Iceberg metadata pruning. --- ## WherobotsDB is 3x faster with up to 45% better price performance URL: https://wherobots.com/blog/wherobotsdb-is-3x-faster-with-up-to-45-better-price-performance/ Updated: 2026-10-19 Today we are announcing the next generation of WherobotsDB, the Apache Sedona and Spark 4 compatible engine, is now generally available. Compared to the the previous generation of WherobotsDB, this next gen (now the current) architecture and version accelerates queries by up to 3x, with up to 45% better price-performance. Previously in preview, it is now offered through the latest version of WherobotsDB. Key takeawaysThe next generation of WherobotsDB (Apache Sedona and Spark 4 compatible) is generally available. Versus the previous generation, it reaches up to 3x peak acceleration on TPC-H at SF1000 (mean 1.7x).It also reaches up to 2.5x on SpatialBench spatial queries and joins at SF1000 (mean 1.9x), and up to 45% better price-performance (average 25%).On SpatialBench SF1000 cost, the current engine is 46% lower cost than the next-best engine, described as a popular Spark-based serverless engine with Spatial SQL support.That comparison includes only queries the other engine finished under a 10-hour timeout (Q1–Q5 and Q7). Q6 and Q8–Q12 were excluded because the other engine could not complete them.Architecture change: the JVM-based, row-oriented execution layer is replaced with a Rust-native, Arrow-columnar engine. Spatial logic runs through SedonaDB on the native layer, and Apache DataFusion provides native processing on Arrow.A GeoArrow-based native geometry type enables zero-copy handling. Existing SQL and Python notebooks continue to work.WherobotsDB is described as the only engine in the compared set with raster capabilities, plus vector and tabular ops in one query environment. It also has Spark 4 and Sedona compatibility, zero-copy lakehouse interoperability, and unification with RasterFlow.The latest version is the default for all new Wherobots Cloud runtimes. New users get a 30-day, $95 Professional trial.ANSI SQL is enforced, so existing customers should test workloads before upgrading. How Customers Use WherobotsDB Our customers are using WherobotsDB to create insights from spatial data at scale that result in improved products, services, and decision making in the physical world. They are realizing breakthroughs in fleet operations, improving their risk projections, increasing the accuracy of vegetative forecasts, analyzing change, and overall are more capable of innovating against physical world interests. With Wherobots on AWS, not only can we easily scale to millions of acres and continuous tractor telemetry normalization within LeafLake, but also we can rest assured that our costs won’t spiral out of control. — G. Bailey Stockdale CEO, Leaf Agriculture The workloads customers run or want to run, are becoming more ambitious too. Customers and AI alike demand better/faster/cheaper solutions for working a wide variety of raster and vector spatial datasets, and they need to fuse this data with valuable business context as well. And of course, they want to do it without scale and function limitations. WherobotsDB was always designed from the ground up to meet these needs. But solutions are now even easier to realize, because the latest version of WherobotsDB allows you to do more, faster, at a lower cost. WherobotsDB Benchmark Results: TPC-H and SpatialBench Performance The next generation of WherobotsDB delivers a substantial performance increase for both spatial and non-spatial queries. Compared to the previous engine, our benchmarking runs for of TPC-H and SpatialBench both show significant performance improvements across scale factors of 100 and 1000. Up to a 3x peak acceleration for analytical queries based on TPC-H at a scale factor of 1000. Workloads can see a nearly threefold increase in throughput. The mean observed acceleration was 1.7x. Up to a 2.5x acceleration for spatial queries and joins based on SpatialBench at a scale factor of 1000. Spatial operations, such as intersects and joins, complete significantly faster on small to massive datasets. The mean observed acceleration was 1.9x. Up to a 45% improvement in price performance. Customers can achieve more with less cost, and the added performance makes it possible for interactive workloads to downscale into smaller runtimes. Compared to the previous version of WherobotsDB, the average improvement in price performance was 25%. Price Performance vs Next Best Engine This shows the total cost of all SpatialBench queries at SF 1000 that the next best engine could finish under a timeout of 10 hours, which limited the comparison to Q1-Q5 and Q7. The remainder of the queries (Q6, Q8-Q12) could not be completed by that engine and were excluded from this analysis. The current generation of WherobotsDB is more capable and 46% lower cost than the next best engine, which is a popular Spark based serverless engine with Spatial SQL support. How the current version of WherobotsDB compares on cost to the previous, as well as the next best engine. WherobotsDB Capabilities: What No Other Engine Offers WherobotsDB is the only engine capable of meeting the following spatial data requirements that customers have. These capabilities power lakehouse architectures like the one described in The Medallion Architecture for Geospatial Data. You get: ✅ high performance, cost efficient, and scalable vector, raster, tabular data operations in a unified query environment ✅ compatibility with Spark 4 and Sedona ✅ interoperability with zero-copy on lakehouses and data lakes to keep data in your control ✅ unification with RasterFlow, to easily orchestrate planetary scale inference and analytics workflows starting with raw imagery datasets The following matrix isolates the vector data processing capabilities of the next best alternatives to WherobotsDB using SpatialBench runs at a scale factor of 1000. Raster data capabilities were not compared, because WherobotsDB was the only engine in the set that supports raster data capabilities. Apache Sedona SpatialBench query capability matrix running on WherobotsDB in comparison to multiple other spark based engines. Contact us and we can share additional details, or rerun these benchmarks on an engine of your choice. WherobotsDB Architecture: Rust-Native, Arrow-Columnar Execution The original architecture for WherobotsDB was built on a JVM-based execution model. It is an extraordinary platform for distributed computing, but its row-oriented execution model and JVM memory management introduce overhead that compounds at scale, especially for spatial-heavy workloads where every row carries complex spatial objects that must be serialized, deserialized, and processed one at a time. The new WherobotsDB version is built on a new architecture that addresses these bottlenecks by replacing the JVM-based execution layer with a Rust-native, Arrow-columnar engine, optimized for spatial data executions. This architecture builds on native geospatial support in Apache Iceberg and Parquet. Native Spatial Execution with SedonaDB The latest version of WherobotsDB takes advantage of SedonaDB, an open-source, blazing-fast analytical database engine where geospatial data is the first-class citizen. The use of Rust and SedonaDB allowed us to move spatial logic out of the JVM and directly onto the native execution layer. It provides a unified execution model that supports everything from scalar and window functions to complex spatial joins, aggregations, and geometry operations. Apache DataFusion Integration Apache DataFusion is a Rust-native query engine built from the ground up on the Apache Arrow in-memory columnar format. By integrating DataFusion’s native execution with WherobotsDB’s distributed engine, you get the best of both worlds: WherobotsDB’ battle-tested scheduling and DataFusion’s high-performance native processing. This means your existing WherobotsDB-based workflows, SQL queries, and Python notebooks continue to work exactly as before, but the actual computation accelerates from optimized native code rather than in the JVM. Zero-Copy Efficiency To remove the significant overhead of data conversion, we implemented a high-performance native geometry type based on the GeoArrow specification. This allows for “Zero-Copy” data handling, utilizing Arrow’s nested memory layout to represent geometries and geographies without the costly serialization and deserialization steps typically found in spatial databases. Spark 4 Compatability WherobotsDB is now compatible with the latest features of Spark 4 to provide a modern, robust environment that enforces ANSI SQL by default. This upgrade integrates the Wherobots engine with the newest advancements in distributed computing, including improved query planning and execution protocols. Try WherobotsDB Free: 30-Day Trial Get started now using a 30 day, $95 free trial available for the Professional Edition of Wherobots. The latest version of WherobotsDB is generally available today and is the default version for all new runtimes on Wherobots Cloud. Due to the enforcement of ANSI SQL, if you’re an existing customer we recommend testing your workloads on the latest version of WherobotsDB in a notebook, SQL session, or job run. For most workloads, the upgrade should be seamless. If you have questions about the upgrade, experience unexpected behavior, want a custom benchmark, or would like to discuss how Wherobots can benefit your business, reach out to the Wherobots team at support@wherobots.com, sales@wherobots.com, or by filling out our contact us form. Frequently Asked Questions How does WherobotsDB compare to Apache Sedona? WherobotsDB is built on Apache Sedona (we’re the same creators!) and extends it rather than competing with it directly. Under the hood, WherobotsDB uses SedonaDB, an open-source analytical database engine where geospatial data is a first-class citizen, as part of its native execution layer.On SpatialBench at a scale factor of 1000, WherobotsDB completed all queries. These include heavy spatial join, heavy distance join, heavy polygon self spatial join, heavy spatial left join, multi-way spatial join, and KNN join. The next best Spark-based engine with Spatial SQL support could not finish them within a 10-hour timeout.WherobotsDB also comes in 46% lower cost than that next best alternative. What is the WherobotsDB architecture built on? The current generation of WherobotsDB replaces the previous JVM-based execution layer with a Rust-native, Arrow-columnar engine optimized for spatial data. It integrates Apache DataFusion, a Rust-native query engine built on the Apache Arrow in-memory columnar format, for high-performance native processing.Spatial logic runs through SedonaDB directly on the native execution layer rather than inside the JVM. To eliminate serialization overhead, WherobotsDB implements a native geometry type based on the GeoArrow specification, enabling zero-copy data handling. It is also fully compatible with Apache Sedona and Spark 4. How do I get started with WherobotsDB? The latest version of WherobotsDB is generally available today and is the default version for all new runtimes on Wherobots Cloud. New users can get started with a 30-day, $95 free trial for the Professional edition.To discuss a custom benchmark, ask about upgrading, or explore how WherobotsDB fits your use case, reach out to us through the contact us form. How much faster is the new WherobotsDB than the previous generation? Up to 3x peak acceleration on TPC-H at SF1000 (mean 1.7x), and up to 2.5x on SpatialBench spatial queries and joins at SF1000 (mean 1.9x). Price-performance is up to 45% better (average 25%). --- ## Raster Processing at Scale: The Out-of-Database Architecture Behind WherobotsDB URL: https://wherobots.com/blog/raster-processing-at-scale-out-of-database-architecture-wherobotsdb/ Updated: 2026-10-19 Introduction Raster data (satellite imagery, elevation models, sensor grids) is critical to understanding the physical world and increasingly to powering AI. The challenge most data teams face is processing it at scale. Key takeawaysWherobotsDB uses an out-of-database raster architecture: only metadata is stored, and pixel data is fetched on demand. Existing Apache Sedona workloads run without code changes.That enables terabyte-scale processing (statewide mosaics, multi-year archives, continental elevation models) without loading entire files into memory.Shuffles serialize only metadata (~KB vs GB of pixels). Tiles share file references with different spatial bounds, and zonal statistics materialize only zonal pixels.Spatial filter push-down skips irrelevant raster files using bounding boxes. Cloud-Optimized GeoTIFFs allow tile-based partial reads from cloud storage, and an intelligent caching layer minimizes repeated remote reads.Capabilities called out beyond OSS Sedona include raster-to-vector conversion, multi-band tile processing, custom raster algebra with near-native performance, and spatial filter push-down for rasters. Multi-band tile processing aligns, stacks, and tiles rasters from different CRS and resolutions in one operation.Both engines support zonal statistics; the differentiator is out-DB scale across millions of zones.RasterFlow extends the raster lifecycle into inference: mosaicking, edge-effect handling, distributed model inference, and converting predictions to vectors, stored as Iceberg tables, Zarr, or COGs. It supports open geospatial AI models, custom PyTorch models, and embeddings from foundation models, and was in private preview at time of writing.SatSure's CTO is quoted on merging 15+ vector datasets in minutes and running high-resolution ML inference at a fraction of legacy cost. Processing raster data at scale requires an architecture that avoids loading entire files into memory. WherobotsDB solves this with an out-of-database approach that fetches pixel data on demand, enabling terabyte-scale processing without the memory overhead of traditional raster engines. WherobotsDB extends open-source Apache Sedona with capabilities and performance optimizations purpose-built for preparing physical-world data for AI at scale, while maintaining full API compatibility. Existing Sedona workloads run without code changes. This post covers how WherobotsDB handles the full raster lifecycle: scalable processing architecture, raster math, coordinate reference systems, vector-raster hybrid workflows, and planetary-scale inference. “With Wherobots, we were able to merge 15+ complex vector datasets in minutes and run high-resolution ML inference on raster imagery at a fraction of the cost of our legacy stack. The combination of speed, scalability, and ease of integration has boosted our engineering productivity and will accelerate how quickly we can deliver new geospatial data products to market.” — Rashmit Singh, CTO, SatSure What Is Out-of-Database Raster Architecture? At the foundation of Wherobots raster capabilities is an out-of-database raster architecture – which makes it far easier to process raster imagery in an embarrassingly parallel fashion. Instead of loading entire raster files into memory, only metadata is stored and pixel data is fetched on-demand. This means teams can process terabyte-scale imagery collections — statewide mosaics, multi-year satellite archives, continental elevation models — with the same interface they use for vector data. Operations like zonal statistics, clipping, masking, filtering, and raster algebra scale to datasets that would overwhelm in-memory approaches. Capability Apache Sedona WherobotsDB Notes Out-DB Raster Support ◔ ● Creates lightweight raster references; pixel data loaded only when needed Intelligent Caching Layer ○ ● Minimizes repeated remote reads for frequently-accessed rasters Optimized Shuffle Operations ○ ● Data movement handles only metadata — orders of magnitude faster than full rasters On-Demand Materialization ○ ● Selectively convert external rasters to in-database format when needed Automatic Metadata Optimization ○ ● Pre-loads metadata and intelligently repartitions for optimal parallelism Cloud-Optimized GeoTIFF Support ◐ ● Native COG support with tile-based partial reads from cloud storage How Out-DB Architecture Transforms Raster Operations The out-of-database architecture fundamentally changes how raster operations execute: Operation Apache Sedona (In-DB Only) WherobotsDB Data Movement (Shuffle) Serializes all pixel data across executors Serializes only metadata (~KB vs GB) Tiling Operations Copies pixel data into each tile Memory-efficient tiling without data duplication Clipping Full pixel-by-pixel processing Optimized processing paths for common operations Zonal Statistics Processes entire raster regardless of region size Materializes only zonal pixels, optimizing I/O based on region of interest Raster Loading Loads entire raster into memory at read time Lazy loading: metadata on-demand, pixels only when accessed Resource Management Standard memory lifecycle Intelligent caching layer with disk caching for remote files Key benefits: On-Demand Data Access: Instead of loading entire raster files into memory, WherobotsDB fetches pixel data only when an operation requires it, reducing memory overhead and enabling processing at terabyte scale. Memory-Efficient Tiling: Tiles share references to the underlying file with different spatial bounds — enabling massive parallelism without memory overhead. Smart I/O Reduction: Operations optimize I/O based on the region of interest, and spatial filter push-down skips irrelevant raster files entirely. Cloud-Optimized GeoTIFFs (COGs) are GeoTIFF files structured so that only the specific byte ranges needed for a given operation are fetched from remote storage, rather than downloading the entire file. Combined with on-demand loading, this architecture minimizes both memory footprint and network I/O. What Raster Capabilities Does WherobotsDB Include? Building on this foundation, WherobotsDB includes enhanced raster functions that enable satellite imagery, elevation models, and sensor data analysis directly in SQL alongside traditional vector operations. Capability Apache Sedona WherobotsDB Notes Raster to Vector Conversion ○ ● Convert raster regions to vector polygons for hybrid vector-raster analysis workflows Multi-Band Tile Processing ○ ● Align, stack, and tile rasters from different sources, CRS, and resolutions for distributed multi-source analysis Zonal Statistics ◕ ● Both support the full statistics suite; WherobotsDB’s Out-DB architecture materializes only zonal pixels, enabling scalability across millions of zones Custom Raster Algebra ◕ ● Flexible map algebra expressions with near-native execution performance Spatial Filter Push-down for Rasters ○ ● Uses bounding boxes to skip irrelevant raster files, dramatically reducing I/O for selective queries These capabilities fall into two categories:  Transforming raster data for hybrid workflows – Raster to Vector Conversion, Multi-Band Tile Processing. Analyzing raster data in place – Zonal Statistics, Custom Raster Algebra, Spatial Filter Push-down. Raster to Vector Conversion converts contiguous raster regions with the same pixel value into vector polygons. Essential for workflows that need to analyze raster-derived features (flood extents, land cover classifications, building footprints from DSM) using vector spatial operations like overlay, buffering, or spatial joins. Multi-Band Tile Processing solves one of the most common friction points in raster analysis: combining data from different sources. Satellite imagery from different sensors, time periods, or providers typically arrives in different coordinate reference systems, resolutions, and data types. WherobotsDB aligns and stacks these into a unified multi-band raster, then tiles it into spatial chunks for distributed processing — all in a single operation. This enables workflows like change detection across multi-temporal composites, fusing Sentinel-2 optical bands with elevation data, or building analysis-ready multi-spectral stacks, without manual reprojection or resampling steps. Zonal Statistics computes aggregate statistics (count, sum, mean, median, mode, stddev, variance, min, max) for raster pixels falling within vector zones. Both Apache Sedona and WherobotsDB support zonal statistics — the differentiator is scale. WherobotsDB’s out-of-database architecture materializes only the pixels within each zone rather than processing the entire raster, making it practical to run zonal statistics across millions of zones on terabyte-scale imagery. Custom Raster Algebra executes user-defined raster algebra expressions with near-native execution performance. It supports complex multi-band calculations, conditional logic, and neighborhood operations — enabling workflows like computing NDVI (Normalized Difference Vegetation Index, a measure of vegetation density derived from red and near-infrared bands) from satellite imagery, or applying threshold-based classification across large imagery collections. Spatial Filter Push-down for Rasters uses bounding boxes to skip irrelevant raster files, dramatically reducing I/O for selective queries. When a catalog contains thousands of scenes but only a few intersect your area of interest, irrelevant files are eliminated before any processing begins. Because all of these functions are built on the out-of-database architecture, they inherit the same scalability characteristics described above — lazy loading, selective pixel materialization, and intelligent caching, without additional configuration. What Is RasterFlow and How Does It Work? Recently, Wherobots has added an entirely new inference and perception engine for planetary-scale image processing – extending the raster lifecycle beyond analysis into AI. RasterFlow enables teams to run computer vision models against large-scale raster datasets. From preparing imagery, mosaicking, removing edge effects across tiles, executing distributed model inference, and converting predictions into vector geometries, all within Wherobots Cloud. RasterFlow’s outputs are stored as vectorized results in Apache Iceberg tables — an open table format for large-scale analytic datasets — or as predictions within ZARR (a cloud-native format for chunked, compressed multi-dimensional arrays) or COGs, which can be seamlessly analyzed using the full suite of spatial operations in WherobotsDB. This creates end-to-end raster workflows — from raw imagery through model inference to spatial analytics, without moving data between systems or building custom infrastructure. RasterFlow supports both popular open-source geospatial AI models and custom PyTorch models, and can generate embeddings from geospatial foundation models. It is currently available to select customers in private preview. If you’re interested in RasterFlow, join our upcoming session to see it in action. What Comes Next: Query Performance and Spatial Analytics Raster processing is not only a first-class capability in WherobotsDB, but also it’s one part of a broader set of spatial data processing advances we’ve built beyond open-source Sedona. Vector and raster workloads both benefit from the same query performance optimizations under the hood: spatial relationship acceleration, automatic join optimization, dynamic data redistribution, and a vectorized GeoParquet reader. Queries that require careful tuning with self-managed Sedona run optimally out-of-the-box with WherobotsDB. In the next post in this series, we’ll go deep on query performance and spatial analytics, how WherobotsDB accelerates spatial joins, range queries, and analytical functions across both vector and raster data types. Start Building with Wherobots Access Now Frequently Asked Questions What is out-of-database raster architecture? Out-of-database raster architecture stores only metadata in the database while fetching pixel data on demand from remote storage. Instead of loading entire raster files into memory, only the pixels required for a specific operation are materialized.This enables teams to process terabyte-scale imagery collections, including statewide mosaics, multi-year satellite archives, and continental elevation models, without the memory overhead of traditional in-memory approaches. How does WherobotsDB differ from open-source Apache Sedona for raster processing? WherobotsDB extends open-source Apache Sedona with additional capabilities and performance optimizations purpose-built for large-scale physical-world data processing. Both support raster operations like zonal statistics.WherobotsDB’s out-of-database architecture materializes only the pixels within each zone rather than processing the entire raster. That makes it practical to run zonal statistics across millions of zones on terabyte-scale imagery. Existing Apache Sedona workloads run on WherobotsDB without code changes. What raster operations does WherobotsDB support? WherobotsDB supports raster-to-vector conversion, multi-band tile processing, zonal statistics, custom raster algebra, and spatial filter push-down. These capabilities cover both transforming raster data for hybrid workflows and analyzing raster data in place. All functions are built on the out-of-database architecture, inheriting lazy loading, selective pixel materialization, and intelligent caching without additional configuration. What is RasterFlow? RasterFlow is an inference and perception engine for large-scale image processing built into Wherobots Cloud. It enables teams to run computer vision models against large-scale raster datasets, handling imagery preparation, mosaicking, edge effect removal, distributed model inference, and conversion of predictions into vector geometries.RasterFlow supports open-source geospatial AI models and custom PyTorch models, and can generate embeddings from geospatial foundation models. It is currently available to select customers in private preview. Do existing Apache Sedona workloads run on WherobotsDB without code changes? Yes. WherobotsDB maintains full API compatibility with open-source Apache Sedona. Existing Sedona workloads run without code changes. --- ## PostGIS, Wherobots, and the Spatial Data Lakehouse: A Strategic Guide for Leaders URL: https://wherobots.com/blog/postgis-wherobots-spatial-data-lakehouse-guide/ Updated: 2026-10-19 For nearly two decades, the answer to the question “Where should we store our location data?” was simple and singular: The Database. Specifically, the industry-standard PostgreSQL database extended with PostGIS. It was reliable, powerful, and sufficient for the era of web maps and queries. Key takeawaysFor nearly two decades the default place to store location data was PostGIS. Organizations now ingest high-velocity fleet telemetry, terabytes of daily satellite imagery, and global building/flood/mobility datasets that a one-size-fits-all database cannot handle.Leaders choose among three interrelated approaches: PostGIS, Wherobots, and a Spatial Data Lakehouse.PostGIS is a scale-up, single-server engine optimized for millisecond row-level access and ACID integrity. It was built for fast transactions, not big-data analytics.The limitation is physics: analyzing five years of GPS for 10 million vehicles will likely slow or fail.Wherobots is a scale-out cloud-native engine built on Apache Sedona by its original creators. It spins up hundreds or thousands of worker nodes and keeps data in cheap object storage.It is native to Python/notebooks for ML on geospatial data, and you pay for compute while a job runs.A Spatial Data Lakehouse stores geospatial data in open formats such as Iceberg or Parquet in object storage so multiple tools query one copy. Catalogs cited: Wherobots Hub, Databricks Unity Catalog, Snowflake Polaris.The successful pattern is a supply chain: Wherobots refines the lake, then ships high-value insights to PostGIS for operational serving. But the world has changed. Organizations today aren’t just managing fixed assets like utility poles or land parcels. They are ingesting high-velocity telemetry from delivery fleets, processing terabytes of daily satellite imagery, and analyzing global datasets from building footprints to flood analysis to human mobility data. The “one-size-fits-all” database can no longer handle this diversity of scale. As a result, modern data leaders face an architectural choice among three interrelated approaches: The Database (PostGIS): The operational gold standard for high-speed transactions. The Processing Engine (Wherobots): The cloud-native engine built for massive-scale geospatial analytics and AI. The Spatial Data Lakehouse: A unified architecture that combines the low cost of a data lake with the governance of a warehouse. Understanding the specific role of each and how they fit together can help create a nimble, cost-effective data strategy for spatial data and analytics.  What Is PostGIS and When Should You Use It? PostGIS is an open-source extension for PostgreSQL that adds support for geographic objects, enabling location queries directly inside a relational database.Think of PostGIS as the high-precision engine that powers your day-to-day business operations. It is a “Scale-Up” technology, meaning it lives on a single server that you make larger as your needs grow. PostGIS Strengths: Speed, Transactions, and Precision Instant Precision: PostGIS is optimized for “row-level” access. If your mobile app needs to tell a user, “Find the five closest drivers to my current location right now,” PostGIS is the perfect tool. It uses sophisticated indexing to find that needle in the haystack in milliseconds. Data Integrity (ACID): In industries like government, banking, or real estate, you cannot afford to lose data or have “eventual consistency.” PostGIS guarantees that when a record is written, it is saved instantly and correctly.  The “Vertical” Ceiling: The limitation of PostGIS is physics. Because it runs on one server, there is a hard limit to how much it can process. If you ask it to analyze five years of historical GPS data for 10 million vehicles, the server will likely slow down or fail. It wasn’t built for “Big Data” analytics; it was built for fast transactions. What Is Wherobots and When Does It Outperform PostGIS? Wherobots is a cloud-native spatial analytics platform built on Apache Sedona. Unlike traditional databases that run on a single server, it distributes workloads across hundreds of machines simultaneously. If PostGIS is a sports car designed for speed and agility, Wherobots is a freight train designed for massive hauling capacity. It represents a “Scale-Out” architecture, built specifically for the era of Cloud and AI. Built by the original creators of Apache Sedona, which delivers the same types of spatial SQL functions that PostGIS delivers, but in a Spark based architecture, it enables the heavy distributed computing and processing that Spark has unleashed in preparing data for Cloud and AI workloads. Wherobots Strengths: Scale, AI Pipelines, and Cost Control Unlimited Scalability: Wherobots doesn’t run on one computer. When you send it a job, it spins up a cluster of hundreds or thousands of worker nodes to tackle the problem in parallel. This allows it to process planetary-scale datasets like “All Buildings in the World” or “Global Weather Patterns” in minutes rather than weeks. Separation of Compute & Storage: This is a critical cost factor. With Wherobots, your data lives in cheap object storage (like Amazon S3), and you only pay for the computing power when you are actually running a query or a join. You can stop paying for the compute the moment the job finishes. AI & Data Science Native: Modern data science teams work in Python and notebooks, not just SQL. Wherobots is native to this ecosystem (built on Apache Sedona), making it the primary engine for training Machine Learning models on geospatial data, such as generating embeddings, predicting crop yields from satellite photos or forecasting traffic congestion. What Is a Spatial Data Lakehouse and Why Does It Matter? A Spatial Data Lakehouse is an architectural pattern that stores geospatial data in open formats like Apache Iceberg or Parquet in cloud object storage, then allows multiple tools, from BI platforms to AI engines, to query that same data without duplication. It emerged as a solution to a longstanding problem: companies were forced to maintain two separate worlds, a data warehouse for structured reports and a data lake for raw files, creating silos where data was either too expensive to store or too messy to query. The Spatial Data Lakehouse is the modern solution that bridges this gap. Spatial Data Lakehouse Benefits: One Copy, Flexible Access, Lower Cost One Copy of Data: Instead of copying data back and forth between systems (which creates errors and version conflicts), data stays in one place, usually cloud object storage, in open formats like Apache Iceberg or Parquet. Flexible Access: The Lakehouse allows different engines to access the same data leveraging open table formats like Apache Iceberg or Delta Tables, governed by catalog system like the Wherobots hub, Databricks Unity Catalog or Snowflake Polaris Catalog. Your data scientists can use Wherobots to run heavy AI models on the data, while your business analysts use a BI tool to view the same data, without needing to move it. Governance & Cost Control: It brings the “grown-up” features of a database (like security, version history, and transaction safety) to the low-cost environment of the data lake. You get the structure of a warehouse with the low price tag of a lake. The Decision Matrix: What to Use When? To help you navigate this landscape, we’ve broken down the best use cases for each technology. Use PostGIS When: The Mission is “Now”: You are powering a live application where sub-second response times are critical for user experience. Transactional Safety is Paramount: You are managing a system of record (e.g., a Land Registry or Utility Network) where complex edits happen frequently. Data Volume is Manageable: Your active dataset is in the Gigabytes up to low Terabytes range. Use Wherobots When: The Mission is “Insight”: You are analyzing trends, patterns, or aggregates over time (e.g., “Show me the 5-year flood risk for our entire real estate portfolio”). Data Volume is Massive: You are dealing with High-Velocity Telemetry, Raster images, or datasets in the Terabytes or Petabytes range. Cost Efficiency is Critical: You want to avoid paying for idle servers or prefer a “pay-as-you-use” model for heavy workloads (available in the Wherobots Pro tier). You are building for AI: Your team needs to feed massive geospatial datasets into Machine Learning or embedding generation pipelines. How PostGIS, Wherobots, and the Lakehouse Work Together The market is moving away from binary choices. The most successful organizations do not view this as “PostGIS vs. Wherobots.” Instead, they view it as a supply chain. They use Wherobots as the heavy industrial refinery for ingesting, cleaning, and analyzing the massive raw materials of the data lake. They then ship the refined, high-value insights to PostGIS, which serves as the high-speed distribution center for the business. By understanding the unique strengths of each player in this landscape, you can build a data architecture that is not only powerful enough for today’s AI demands but sustainable for tomorrow’s budget. Start Building with Wherobots Get Started Frequently Asked Questions When should I use PostGIS vs Wherobots? Use PostGIS when the mission is ‘now’. That covers live apps that need sub-second response and systems of record (land registry, utility network) with frequent complex edits. It also covers active datasets in gigabytes to low terabytes.Use Wherobots when the mission is insight: trends and aggregates over time, high-velocity telemetry or rasters in terabytes or petabytes, and pay-as-you-use compute (Pro tier). It also fits feeding massive geospatial datasets into ML and embedding pipelines. What is a spatial data lakehouse? An architectural pattern that stores geospatial data in open formats like Apache Iceberg or Parquet in cloud object storage. Multiple tools, such as BI platforms and AI engines, then query that same data without duplication. It brings warehouse-style governance (security, version history, transactions) to the low-cost data lake. How do PostGIS and Wherobots work together? The post says the market is moving away from binary choices. Successful organizations use Wherobots as the industrial refinery for ingesting, cleaning, and analyzing raw lake data, then ship refined insights to PostGIS as the high-speed distribution center for the business. Is PostGIS still the right default for location data? It remains the operational gold standard for high-speed transactions. It is no longer the default for every location-data problem. High-velocity telemetry, daily satellite imagery, and planetary-scale datasets exceed what a single-server database was built to analyze. --- ## It takes 15 minutes for the Caltrain to get from Sunnyvale to SAP Center URL: https://wherobots.com/blog/ai-agents-spatial-analytics-15-minute-train-ride/ Updated: 2026-10-19 That’s how long it took our MCP server to go from “how many bus stops are in Maryland” to an answer I’ve been doing a lot of reading lately on how AI is going to transform spatial workloads and that curiosity led me to this post on geoMusings. Here, Bill is demonstrating how Claude Code and agent skills capabilities can be used to wire up a chat-to-query-results interface in a few hours. He showcased the new skill by getting the agent to query his local Postgres instance for the number of Metro bus stops in Maryland, which returned a precise 4,563. Key takeawaysOn a Caltrain ride from Sunnyvale to San Jose Diridon (~15 minutes), the author asked the Wherobots MCP server in VS Code: 'How many bus stops are in Maryland?'The author had no prior knowledge of whether the catalog had bus-stop data or a Maryland boundary.In about five minutes (around Lawrence Station), the MCP server identified places_place under Overture Maps in the Wherobots Open Catalog. It did so by exploring the catalog and running sample queries, with zero human intervention.In the next five minutes it self-identified errors (including 0-result queries), adjusted SQL, switched tables, and produced 19,740 bus stops in Maryland. That is about 5× the 4,563 Metro bus stops in Bill Dollins' geoMusings Claude Code post.When challenged with that post, it diagnosed that Bill's query was Metro-only.In the last five minutes, constrained to WMATA, it returned 6,224 Metro bus stops in Maryland. The author states those counts still need validation by people who know buses.The point is natural-language to insight in minutes. A notebook for validation is described as what they would do in a real workflow. I need to count the number of records in the metro_bus_stops table that are inside Maryland.The database is at localhost:5432, database name is “dev”,user “postgres” with password “postgres”.Points table: public.metro_bus_stops (geometry column: geom, id column: id)Polygons table: public.maryland_boundary (geometry column: geom, name column: name) As a dabbler of AI agents and a minor contributor to Wherobots’ very own MCP server, I immediately wondered how our MCP server would do against such a challenge. So I fired up my VS Code and just straight up asked: “How many bus stops are in Maryland?” Bear in mind, at the time I did not know if we have any data with bus stops in it in Wherobots’ data catalogs, I did not know what shape that data was in, I did not know if the MCP server could come up with a reasonable administrative boundary for Maryland, etc. And I fired off this query just as my CalTrain was departing Sunnyvale station. In about 5 minutes, the MCP server already identified two tables with bus stop information called places_place under the Overture Maps Foundation database in Wherobots Open Catalog. It achieved that by exploring our catalog and running sample queries against those tables to find the right data; all with zero human intervention. We are right about Lawrence Station at the point. In the next 5 minutes, the MCP server ran a series of queries against that table, self-identified errors (i.e., got 0 results and understood it was not expected), adjusted the query, switched tables, changed approaches until it was able to produce actual results. Our MCP server believes there are 19,740 bus stops in Maryland which is ~5 times as many as Bill’s post suggests. We just got to Santa Clara station, by the way, for those of you who are still following. So being a good aspiring data engineer, I challenged the MCP server: Why does this blog think there are only 4563 then?https://blog.geomusings.com/2026/01/14/spatial-analysis-with-claude-code/  The MCP server went back to work and gave me the diagnosis; Bill’s query is focused on Metro bus stops and my original question did not specify that: So in the last 5 minutes of this journey, I asked it to focus on Washington Metropolitan Area Transit Authority (WMATA) bus stops only and see what it comes up with! And just as we were about to pull into San Jose Diridon Station, the MCP server told me that there are 6,224 Metro bus stops in Maryland.  Now, whether there are 4,563 Metro bus stops in Maryland or 6,224 ones, is a matter that shall be validated with people far more knowledgeable than myself on buses and their stops. The main point is that AI is making it possible for non-experts like myself to go from a question (expressed in natural language) to real insights in minutes (well a 15-minute train ride to be precise). Wherobots MCP is giving the AI the ability to answer questions about the real-world.  In the real world, I would have asked the MCP server to generate a Notebook for me to reproduce this output and plot it on a map. I would then share that with my colleague to help me validate, correct and optimize my findings. What would have taken days to weeks (to go from theory to some early explorations to a shareable PoC and, finally, to production-quality code) can now be achieved in a matter of hours.  The Caltrain experiment was just one question. In our recent office hours, we walked through the MCP server end to end, showing how it explores catalogs, generates spatial queries, debugs errors, and produces reproducible outputs. See the full workflow in action. Want to get started with our MCP server? Check out our getting started guide. It takes less than 5 minutes to configure the server and start chatting with the physical world!  Create your account to get started START BUILDING Frequently Asked Questions Can the Wherobots MCP server answer spatial questions without knowing the catalog? In this experiment, yes. The author did not know if Wherobots had bus-stop data or a Maryland boundary. The MCP server explored the Open Catalog, found Overture places_place, ran sample queries, recovered from 0-result errors, and produced an answer during a 15-minute train ride. How many bus stops are in Maryland according to this post? The MCP server first returned 19,740 bus stops in Maryland from Overture places. After the author pointed it at a geoMusings post that counted 4,563 Metro bus stops, it diagnosed the filter difference and, asked to focus on WMATA only, returned 6,224. The author says which number is ‘right’ should be validated by people more knowledgeable about buses; the post is about time-to-insight, not a definitive stop inventory. How long does it take to set up the Wherobots MCP server? The post says the getting-started guide takes less than 5 minutes to configure the server and start chatting with the physical world. What would a production version of this MCP experiment look like? The author would have asked the MCP server to generate a notebook, plot results on a map, and share it with a colleague to validate, correct, and optimize. Work that would have taken days to weeks (theory to PoC to production-quality code) is described as achievable in hours. --- ## Wherobots and Felt Partner to Modernize Spatial Intelligence URL: https://wherobots.com/blog/modern-spatial-intelligence-stack-wherobots-felt/ Updated: 2026-10-19 We’re excited to announce Wherobots and Felt are partnering to enable data teams to innovate with physical world data and move beyond legacy GIS, using the modern spatial intelligence stack. Key takeawaysWherobots and Felt are partnering on a cloud-native stack. Wherobots is the spatial query and inference engine for raster, vector, and structured data of any scale.Felt is the browser-based collaborative mapping layer (often described as 'the Google Docs of GIS').The pitch versus legacy GIS: desktop-bound tools, restrictive licensing, and unscalable workarounds that copy data in and out of bespoke GIS. The combined stack is lakehouse-based, AI-first (inference, MCP, natural-language maps), fully managed, pay-as-you-go, and open-standards based.Queries against Felt-visualized data run on WherobotsDB, with 3x faster performance than previous-generation engines (as stated in this post).Joint customer Leaf Agriculture uses the stack for LeafLake and the Leaf Unified API, serving customers including Syngenta, Bayer, and Farmers Edge.Wherobots runs distributed spatial SQL on millions of acres of machine data and imagery at 5–20x the speed and a fraction of the cost of traditional solutions. It turns telemetry into structured insights in seconds.Felt is the collaborative window; the workflow is described as SQL-to-map. The stack with Wherobots and Felt provides a cloud-native, spatial processing and collaborative mapping solution that accelerates innovation and time-to-insight across an organization. Wherobots delivers the most capable spatial query and inference engine for creating insights from physical world data (raster, vector, structured) of any scale.  Felt delivers an intuitive, browser-based experience that enables business teams to explore this data, ask questions, and share insights collaboratively. The combination provides a new path to move forward for teams that are innovation-limited by their desktop-bound GIS tools, restrictive licensing arrangements, and unscalable workflows. What is Felt? Felt is the new standard for collaborative mapping, and their product is often described as “the Google Docs of GIS.” It is a cloud-native platform designed to turn complex geospatial data into actionable insights through its unique collaborative map development capabilities. Unlike traditional Geographic Information Systems (GIS) that are often desktop-bound, Felt lives entirely in the browser, allowing teams to create, analyze, and share interactive maps with the speed and ease of a modern productivity tool. Why Legacy GIS is Limiting Spatial Data Innovation Spatial data comes in various formats and sizes, and it needs to be processed and combined with other datasets for people, systems, and AI to innovate with it. Because few systems were developed to handle this wide spectrum of data complexity, format, and scale in a graceful way, users have been forced to create cumbersome, time consuming workarounds. In turn, this has led to a high degree of specialization, and a special category of GIS tools that simply can’t keep up with demand. Buyers, faced with few options, have been limited to old-guard licensing arrangements for lagging technology solutions. Such engagements plant a thorn in the side of many organizations who end up constrained in their ability to innovate unless they hire more specialized staff or contractors to develop workarounds that copy data to and from bespoke GIS tools or databases. What buyers want is to deploy modern tooling and AI that “just absorbs the complexity” such that their data practitioners can just work with this data and achieve their goals. They also want more flexibility to take the best tools over time and demand data sovereignty. If you’re working on a small yet nimble team of data scientists and engineers solving world-level problems, you want the capability to easily crunch terabytes of vector, raster, and structured data using familiar tools. Data interactivity is key because the easiest way to understand spatial data quality at scale is to inspect relationships visually with performance, and you can iterate faster towards the shared objective when in-team collaboration is seamless. Historically teams relied on piecemeal operations that extended the innovation cycles because of data and work siloes, or limited tooling support.  Similarly, analysts, planners, and stakeholders want simple, AI enabled, visual-first tools to understand and ask their questions about spatial data so they can make decisions from it. Their ability to tailor analytics from a visual-first tool, was limited by the capabilities of the underlying query engine and the data available to it. Moving from Legacy GIS to a Modern Spatial Intelligence Stack Our partnership with Felt directly addresses this friction with a seamless integration between platforms to deliver the spatial intelligence stack.  Using Felt’s AI-assisted and collaborative map development experience, customers can easily query, interrogate, and build insightful visualizations from multiple sources of spatial and non spatial data in their private data lakes or open repositories. This is done using Wherobots as the query engine that absorbs the heavy lifting associated with multi-modal spatial data processing and cataloging. Developers can also build directly against this stack using Wherobots’ Spatial AI Coding Tools. Key Benefits of the Wherobots and Felt Integration Easy for everyone: No user is left behind. Wherobots supports data engineers, scientists, and developers who need speed and performance, while Felt enables front end developers, GIS users, and business teams to get insight, instantly from the analysis. AI first: from inference, MCP tools, to collaborative maps driven by AI and natural language prompts, users have the modern AI tools to generate insights quickly at scale.  Built for the lakehouse: The lakehouse architecture maximizes data sovereignty and agility by giving you the freedom to choose the best tools for the job over time.  Spatially optimized: World class spatial capability and performance is ready out of the box. Wherobots provides the scale, performance, and capability to crunch and perform inference on multi-modal spatial data than any other cloud platform.  A fully managed, friendly, open standards based deployment: on-demand deployment and pay as you go pricing lets you reach your goals through open, well understood standards and architecture. Queries against Felt-visualized data run on WherobotsDB, with 3x faster performance than previous-generation engines. Customer Example: How Leaf Agriculture Uses Wherobots and Felt The partnership started with a joint customer request from Leaf Agriculture, who has been using Wherobots and Felt for productionizing their LeafLake offering over this past year, and to harmonize large scale tractor data for their Leaf Unified API. Leaf serves customers and partners like Syngenta, Bayer and Farmers Edge, and many others in the agricultural economy.  The delivery of LeafLake, supported by Wherobots and Felt, creates a high-velocity data fabric that turns fragmented agronomic data into planetary-scale intelligence. Wherobots serves as the query engine, running distributed spatial SQL operations to create insight-ready datasets from millions of acres of machine data and imagery at 5–20x the speed and at a fraction of the cost of traditional solutions. By running directly on Leaf’s unified data lake, Wherobots transforms raw telemetry into structured, “AI-ready” insights in seconds. Felt acts as the collaborative “window” into this data, providing a high-performance mapping interface that lives entirely in the browser. Through a native integration, data processed in Wherobots is made directly to Felt. This “SQL-to-map” workflow allows agronomists and decision-makers to interact with LeafLake data in real-time in Felt, enabling a “Google Docs” style of collaboration over complex agricultural insights. This map showcases farm data from Leaf Agriculture’s LeafLake platform through Felt’s interface for the purpose of precision farming based on tractor telemetry and soil data. Get Started Today This integration marks a major step forward making the creation of spatial intelligence accessible to entire organizations. We can’t wait to see what you build with the combined power of Wherobots and Felt.  To learn more:  Check out the documentation to get started in minutes. Join us in this upcoming session to see how Wherobots and Felt work together to build the foundation for spatial AI. Talk to our team to explore options. Frequently Asked Questions What is the Wherobots and Felt partnership? A product integration so data teams can process spatial data in Wherobots and explore, question, and share it in Felt’s browser-based collaborative maps, without remaining on desktop GIS. Wherobots absorbs multi-modal spatial processing and cataloging; Felt is the visual, AI-assisted front end. How does Leaf Agriculture use Wherobots and Felt? The partnership started from a joint customer request. Leaf uses both to productionize LeafLake and harmonize large-scale tractor data for the Leaf Unified API, for customers and partners such as Syngenta, Bayer, and Farmers Edge.Wherobots is the query engine on Leaf’s unified data lake; Felt is the high-performance mapping interface. The post cites 5–20x the speed and a fraction of the cost of traditional solutions, with insights in seconds. Do Felt map queries run on Wherobots? Yes. The post states queries against Felt-visualized data run on WherobotsDB, with 3x faster performance than previous-generation engines. Data processed in Wherobots is made available directly to Felt through a native integration. Why replace legacy GIS with a lakehouse mapping stack? The post argues few systems handle mixed format, complexity, and scale, so teams build workarounds and hire specialists. Buyers want tooling that absorbs that complexity, plus data sovereignty and the freedom to choose tools over time. Felt lives entirely in the browser; Wherobots provides the scale for terabytes of vector, raster, and structured data. --- ## Scaling Spatial Analysis: How KNN Solves the Spatial Density Problem for Large-Scale Proximity Analysis URL: https://wherobots.com/blog/scaling-spatial-analysis-how-knn-solves-the-spatial-density-problem-for-large-scale-proximity-analysis/ Updated: 2026-10-19 How we processed 44 million geometries across 5 US states by solving the spatial density problem that breaks traditional spatial proximity analysis When scaling spatial proximity analysis from city to state to national level, the hidden challenge isn’t computational power—it’s spatial density. The techniques that work perfectly for urban neighborhoods fail dramatically when applied across heterogeneous landscapes. Key takeawaysDensity-Invariant Selection: KNN’s bounded cardinality constraint naturally accommodates varying feature density, with no manual threshold tuning required.Predictable Performance: Consistent throughput and cost across heterogeneous spatial data, enabling reliable budgeting and planning.Two-Stage Pattern: Combine KNN’s fast candidate selection with precise geometric calculations for both speed and accuracy. The standard professional approach—using ST_DWithin with a fixed search radius—breaks down when spatial density varies. A 500-meter radius might capture 20 candidate features in Manhattan but zero in rural Wyoming. No single distance works for both. This article demonstrates how k-nearest neighbors (ST_KNN) solves this problem. Unlike fixed-radius predicates that yield density-dependent result sets, KNN applies a top-k constraint—guaranteeing bounded cardinality regardless of local feature distribution. No distance threshold tuning required. To validate this approach, we ran a buildings-to-roads proximity analysis across five US states on Wherobots Cloud: 44.4 million buildings against 535,000 road segments in 2.3 hours for $157—less than half a cent per geometry. The technique applies equally to any spatial proximity problem: customers to stores, facilities to services, properties to amenities. The Professional’s Dilemma: Static vs Adaptive Search The ST_DWithin Approach For any GIS professional, the standard approach to spatial proximity analysis is `ST_DWithin` with a fixed radius: sedona.sql(''' SELECT a.*, b.*, ST_Distance(a.geometry, b.geometry) as distance FROM query_geometries a JOIN target_geometries b ON ST_DWithin(a.geometry, b.geometry, 500, true) -- Fixed 500m radius ORDER BY distance ''') This works beautifully for spatially homogeneous regions. But scale it to a state or nation, and you hit the spatial density problem—where non-uniform feature distribution causes query behavior to become unpredictable. The Spatial Density Problem Consider the same ST_DWithin(geometry, 500m) query across different spatial contexts: Figure 1: The same ST_DWithin query produces many candidates in dense urban areas but 0 candidates in sparse rural areas The same query produces wildly different result set cardinalities based on local feature density. The Radius Paradox Attempting to solve this with radius adjustment creates new problems: Radius Urban Result Rural Result Problem 500m 20 candidates 0 candidates Rural queries fail 2km 200 candidates 3 candidates Urban over-processing 10km 2000+ candidates 10 candidates Urban becomes intractable No single radius value works for heterogeneous spatial data: increase it to capture sparse regions, and dense regions become intractable with combinatorial explosion in candidate counts. This isn’t a theoretical problem—it’s the practical limitation that prevents reliable large-scale spatial analysis using traditional methods. KNN Spatial Analysis: Solving the Density Problem at Scale K-nearest neighbors elegantly solves the spatial density problem by enforcing a cardinality constraint rather than a distance constraint—always returning exactly k candidates regardless of local feature density. A useful mental model: ST_DWithin applies a distance predicate (fixed radius, variable cardinality), while ST_KNN applies a rank-based predicate (fixed cardinality, variable distance). This produces the effect of a density-adaptive search area—though KNN doesn’t compute any radius internally. The Effect in Practice sedona.sql(''' SELECT a.*, b.*, ST_Distance(a.geometry, b.geometry) as distance FROM query_geometries a JOIN target_geometries b ON ST_KNN(a.geometry, b.geometry, 10) -- Always 10 candidates ORDER BY distance ''') The same query now produces consistent results across all spatial densities: Figure 2: KNN always returns exactly k candidates—nearby ones in dense areas, more distant ones in sparse areas. KNN doesn’t compute or adjust a radius. It simply finds the k nearest neighbors, wherever they are. In dense areas, those neighbors happen to be close; in sparse areas, they’re farther away. The “adaptive” behavior emerges naturally from asking “what’s nearest?” rather than “what’s within X meters?” The Adaptive Advantage Metric ST_DWithin ST_KNN Result cardinality Variable (0 to 1000+) Bounded (k) Time complexity Data-dependent Predictable O(n × k) Result quality Density-dependent Distribution-invariant Parameter tuning Manual, error-prone Not required The Key Insight: ST_DWithin asks “What’s within X meters?” (fixed radius, variable candidates). ST_KNN asks “What are the K nearest?” (fixed candidates, variable distance). This fundamental difference is why KNN handles heterogeneous density gracefully—no radius tuning required. Note: This “adaptive” behavior is conceptual—a way to understand why KNN outperforms fixed-radius approaches for heterogeneous data. It’s distinct from the optional distance bound parameter (see Practical Guidance), which imposes an actual maximum distance limit on candidates. The Two-Stage Pattern for Accurate Spatial Proximity KNN computes distances using geometry centroids (or bounding box representatives) for computational efficiency. For complex geometries like linestrings or large polygons, the centroid-to-centroid distance may diverge significantly from the true minimum Hausdorff distance. We address this with a two-stage refinement approach: Stage 1 (Candidate Generation): KNN selects k candidates using approximate centroid-based distance—O(nlog⁡k)O(n\log k) Stage 2 (Exact Refinement): Precise geometric calculation (ST_ClosestPoint, ST_DistanceSpheroid) on k candidates only—O(k)O(k) per query point This decomposition gives us both fast candidate pruning and geometrically precise results. KNN Implementation Pattern Here’s the complete two-stage pattern using Wherobots SQL: Stage 1 – Candidate Generation: knn_df = sedona.sql(''' SELECT query.id AS query_id, query.geometry AS query_geometry, target.id AS target_id, target.geometry AS target_geometry, -- Exact closest point calculation ST_ClosestPoint(target.geometry, query.geometry) AS closest_point, -- Precise spheroidal distance ST_DistanceSpheroid( ST_ClosestPoint(target.geometry, query.geometry), query.geometry ) AS distance_meters FROM query_geometries AS query JOIN target_geometries AS target ON ST_AKNN(query.geometry, target.geometry, 10, false) ''') knn_df.writeTo('wherobots.pranav.knn_candidates') Stage 2 – Exact refinement: sedona.sql(''' ranked AS ( SELECT *, ROW_NUMBER() OVER ( PARTITION BY query_id ORDER BY distance_meters ASC ) AS rank FROM wherobots.pranav.knn_candidates ) SELECT * FROM ranked WHERE rank = 1; ''') Key functions: ST_AKNN(..., 10, false): Approximate KNN with k=10 candidates, Euclidean distance Why ST_AKNN over ST_KNN?: When using KNN for candidate generation (followed by exact refinement via ST_ClosestPoint + ST_DistanceSpheroid), approximate KNN is preferred. The relaxed precision bounds of ST_AKNN enable faster index traversal, and the refinement stage replaces the approximate distances of the candidates with exact ones. ST_ClosestPoint: Precise closest point on target geometry ST_DistanceSpheroid: Accurate geodetic distance in meters ROW_NUMBER(): Rank candidates and select the true closest The pattern works for all large non-point geometries. Results: Consistent Performance Across Spatial Densities We validated this approach using a buildings-to-roads proximity analysis across five US states. Each state contains a mix of dense urban, suburban, and sparse rural areas—exactly the heterogeneous density that breaks traditional methods. State Buildings (Query Geometries) Roads (Target Features) Time (sec) Cost Throughput New York 6,447,782 75,329 1,374 $25.31 4,693/sec Texas 13,289,136 166,943 2,140 $41.60 6,208/sec Colorado 2,764,970 34,432 1,074 $21.35 2,574/sec California 13,648,296 135,247 2,086 $36.95 6,541/sec Florida 8,201,965 122,048 1,490 $30.35 5,504/sec Total 44,425,199 535,538 535,538 $157.08 5,301/sec Key Observations Consistent Throughput: Average of 5,300 geometries per second across all states, despite each containing vastly different urban/rural mixtures. This consistency is the adaptive search radius in action. Cost Predictability: $0.0035 per 1,000 geometries regardless of local spatial density. Budget with confidence. Linear Scaling: Processing time scales linearly with geometry count—no density-dependent surprises. Practical Guidance ST_KNN vs ST_AKNN for Proximity Analysis For the two-stage pattern described in this article, use ST_AKNN (approximate) rather than ST_KNN (exact): Function Speed Precision Best For ST_KNN Fast Exact When KNN result is the final answer ST_AKNN Faster Approximate Search space reduction before exact calculations Since we’re computing exact distances with ST_DistanceSpheroid on the candidates anyway, the approximate nature of ST_AKNN has no impact on final accuracy—only on speed. Using Distance Bounds with KNN If you know the maximum acceptable distance for your use case, add a distance bound parameter to further optimize performance: -- Only consider candidates within 5000 meters ST_AKNN(query.geometry, target.geometry, 10, true, 5000) Unlike the conceptual “adaptive search area” discussed earlier, this is an actual distance predicate pushed down to the spatial partitioning stage—not applied as post-hoc filtering. Candidates beyond this threshold are pruned during index traversal, reducing I/O and computation.This is useful when: Business logic requires a limit: e.g., “nearest hospital within 10km” Performance optimization: You know neighbors beyond X meters aren’t relevant Emergency response: Facilities must be within a critical response distance KNN Performance Optimization Tips Materialize intermediate results: Either cache or write to disk as Iceberg table, the KNN output before applying filters Process categories separately: Run KNN for each target type (e.g., motorways, then trunk roads) independently Use appropriate runtime: Medium runtime handled 13M geometries in ~35 minutes Applications of KNN-Based Spatial Proximity Analysis The adaptive search radius pattern applies to any spatial proximity problem with heterogeneous density: Infrastructure & Planning Properties → nearest utilities, transit, services Customers → nearest stores, facilities, competitors Environmental Analysis Development sites → nearest protected areas, water bodies Facilities → nearest residential areas, schools Business Intelligence Locations → nearest amenities, employment centers Assets → nearest maintenance facilities, resources General Pattern: For each query geometry A, find target geometry B that minimizes some expensive function f(A, B). Use KNN to reduce candidates, then apply exact calculation to the reduced set. Conclusion Large-scale spatial analysis requires solving the spatial density problem that causes traditional distance predicates to fail. KNN provides the solution: a cardinality-bounded query operator that delivers consistent result sets regardless of local feature distribution, with predictable computational complexity. At $0.0035 per 1,000 geometries, spatial proximity analysis at any scale becomes economically trivial. The technique that processed 44 million buildings in 2.3 hours works equally well for customer analytics, infrastructure planning, or environmental assessment. KNN’s density-invariant behavior isn’t just a performance optimization—it’s what makes heterogeneous spatial analysis reliable. Resources Wherobots Documentation: ST_AKNN, ST_KNN, spatial function reference Wherobots Cloud: Distributed spatial analytics platform Overture Maps Foundation: Open map data used in our validation Create your Wherobots account START BUILDING Frequently Asked Questions Why does ST_DWithin fail at statewide proximity analysis? ST_DWithin uses a fixed radius, so result cardinality depends on local density. A 500 m radius may capture 20 candidates in Manhattan and zero in rural Wyoming.Increasing the radius to 10 km can make urban candidate counts intractable (2,000+). No single radius works for heterogeneous landscapes. How does ST_KNN solve the spatial density problem? ST_KNN applies a top-k constraint instead of a distance constraint: always k candidates, wherever they are. In dense areas neighbors are close; in sparse areas they are farther away.Time complexity is described as predictable O(n × k) rather than data-dependent. An optional distance bound can still prune during index traversal when business logic requires a maximum (for example nearest hospital within 10 km). What is the two-stage KNN proximity pattern in Wherobots? Stage 1: ST_AKNN generates k candidates using approximate centroid-based distance (preferred over exact ST_KNN when a refinement stage follows). Stage 2: ST_ClosestPoint plus ST_DistanceSpheroid compute exact geodetic distance on those k candidates, then ROW_NUMBER() picks rank 1. AKNN is used for faster index traversal, and refinement replaces the approximate distances of those k candidates with exact ones. How much does large-scale KNN proximity analysis cost on Wherobots? Five-state buildings-to-roads: 44,425,199 buildings and 535,538 road segments, $157.08 total, about $0.0035 per 1,000 geometries, average 5,301/sec. Per-state examples include California 13.6M buildings in 2,086 seconds for $36.95, and New York 6.4M buildings in 1,374 seconds for $25.31. A medium runtime handled 13M geometries in about 35 minutes. --- ## Agriculture and Sustainability URL: https://wherobots.com/solutions/sustainability-agriculture/ Updated: 2026-10-06 Physical World Context for Sustainability & Agriculture AI systems built on documents and databases cannot see what is happening on the ground. Wherobots gives agriculture and sustainability teams the context layer to turn satellite crop monitoring, drone imagery, and sensor data into reliable crop, soil, and ecosystem intelligence, from field level to planetary scale. REQUEST A DEMO Why Agriculture Teams Build Physical World Context with Wherobots Crop health, soil conditions, water stress, carbon stocks: these signals live in satellite imagery, drone data, and sensor streams. Wherobots provides the spatial AI infrastructure to process this physical world data at scale, run remote sensing agriculture models, and deliver the intelligence your operations depend on. Satellite and Drone Data at Scale Scaling AI Inference on Satellite Imagery Change Detection Bottlenecks Fragmented Geospatial Workflows Specialized Teams and Costly Compute Satellite and Drone Data at Scale Industry Problem Why Traditional Pipelines Struggle with Multispectral Satellite and Drone Imagery Agricultural and environmental teams must process multispectral satellite, drone imagery, and IoT sensor data that grow daily and are expensive and slow to analyze with traditional pipelines. Wherobots solution Serverless, Planetary-Scale Raster and Vector Processing for Agricultural Data Pipelines Planetary-scale raster + vector processing with a Spatial Intelligence Cloud, enabling distributed ETL, mosaicking and analytics across petabytes without manual infrastructure ops. 100% Visibility Scaling AI Inference on Satellite Imagery Industry Problem Why Scaling Computer Vision Inference Across Satellite Imagery Collections Is Complex and Costly Running computer-vision inference across large imagery collections is complex and costly to scale and operate. Wherobots solution Production-Grade Raster Processing with RasterFlow RasterFlow handles the full pipeline: ingest satellite or drone imagery, build inference-ready mosaics, remove cloud cover, run PyTorch computer vision models at scale, and vectorize outputs for downstream joins. Satellite crop monitoring, field boundary detection, and land cover classification become production workflows, not research projects. PB+ Data Scale Change Detection Bottlenecks Industry Problem Time Series and Change Detection Bottlenecks in Traditional GIS and ETL Pipelines Tracking phenology, crop stress, or deforestation requires pixel-level comparisons over time — operations that overwhelm traditional GIS and ad hoc ETL. Wherobots solution Fast Temporal Analytics and Distributed Change Detection for Crop Stress, Phenology, and Deforestation Monitoring Fast temporal analytics and distributed change-detection via Spatial SQL or python and raster workflows so teams can compute seasonal indices, detect anomalies and produce operational alerts across millions of acres. Real-time Event Response Fragmented Geospatial Workflows Industry Problem Why Agricultural Data Teams Struggle Managing Separate Tools for Raster Processing, Vector Analytics, and Model Inference Teams juggle separate tools for raster preprocessing, vector analytics, model inference and cataloging. Integrations slow delivery. Wherobots solution A Unified Platform Combining RasterFlow, WherobotsDB, and Data and Model Hub for End-to-End Geospatial ML Workflows A unified platform combining RasterFlow, Data + Model Hub and WherobotsDB so you can prep imagery, run ML, and join predictions with farm/parcel or weather data all within a single environment. Zero Idle Costs Specialized Teams and Costly Compute Industry Problem Why Building and Maintaining Geospatial Pipelines Demands Specialized Teams and Costly Compute Building and maintaining geospatial pipelines typically demands specialized teams and costly compute. Wherobots solution A Managed Cloud Service with SQL and Python Notebooks That Delivers Predictable Economics for Geospatial Development at Scale Managed cloud service with SQL + Python notebooks and IDEs or jobs that reduce development time and deliver predictable economics for large-scale agricultural workloads. Customers report major reductions in processing time and cost as they scale to millions of acres. Managed Could Server Data teams using Wherobots and Apache Sedona for Sustainability & Agriculture “With Wherobots on AWS, not only can we easily scale to millions of acres, we also can rest assured that our costs won’t spiral out of control.” G. Bailey Stockdale CEO, Leaf Agriculture See How Agriculture Teams Build AI That Sees the Field Schedule a demo to see how agriculture and sustainability teams process petabytes of satellite imagery, run crop monitoring models at scale, and build the physical world context layer behind better field-level decisions. REQUEST A DEMO Geospatial Agriculture and Sustainability Resources: Notebooks, Templates, and Guides from Wherobots Our solution accelerators are ready-to-run notebooks and templates that get your team from data to product fast. Each card links to a notebook, blog, or resource to accelerate your ramp. Fields of the World (FTW): Planetary-Scale Field Boundary Production with Wherobots and Taylor Geospatial Engine Wherobots collaborates with Taylor Geospatial Engine on the Fields of the World (FTW) for planetary scale field boundary production. LEARN MORE RasterFlow: Wherobots' Planetary-Scale Inference Engine for Earth Observation and Agricultural AI RasterFlow is Wherobots’ planetary-scale inference engine for Earth Intelligence. Request access to the private preview to see it in action. LEARN MORE How to Run Zonal Statistics on ESA WorldCover Data Using WherobotsDB Run the RS_ZonalStatsAll using ESA WorldCover in WherobotsDB in a few simple steps. LEARN MORE Frequently Asked Questions How does Wherobots handle petabyte-scale satellite imagery for satellite crop monitoring? WherobotsDB runs distributed spatial SQL against cloud object storage directly, scanning imagery at planetary scale without moving data. Compute runs in serverless sessions or scheduled jobs and scales to workload size. Teams pay for compute when jobs run, not for idle infrastructure. Imagery, vector field boundaries, and sensor data participate in the same SQL and Python workflow, so satellite crop monitoring pipelines from raw ingest to field-level output run in one environment. How does Wherobots join satellite imagery with farm records, tractor telemetry, and weather data? WherobotsDB natively handles raster imagery (satellite bands, elevation models, precipitation grids), vector data (field boundaries, parcel records, land cover polygons), and tabular data (farm records, telemetry logs, weather observations) in the same query engine. A crop stress analysis can join NDVI-derived raster outputs with parcel boundaries and soil survey data in a single spatial SQL query. No separate pipeline stitching tools together. Outputs feed directly into your downstream models or reporting systems. How does Wherobots support sustainability reporting and carbon accounting? Wherobots processes multisensor satellite imagery, terrain data, soils datasets, and vegetation indices in production pipelines to generate repeatable, auditable spatial products for carbon project monitoring and sustainability reporting. RasterFlow handles imagery preprocessing and model inference. WherobotsDB joins outputs with field boundaries, land cover classifications, and ecosystem data in spatial SQL. The pipeline produces traceable, version-controlled outputs that meet the documentation requirements of carbon accounting frameworks. What deployment options does Wherobots offer for agricultural data workloads? Wherobots deploys as a managed cloud service, in your own cloud account (bring-your-own-cloud), or in a dedicated VPC. All three configurations connect to your existing cloud storage without data migration. Agriculture and sustainability teams with data governance or compliance requirements can run Wherobots within their own infrastructure perimeter. Wherobots is SOC 2 Type 2 attested. How does Wherobots support time series analysis and change detection for agriculture and sustainability? Wherobots provides fast temporal analytics and distributed change detection via Spatial SQL and Python raster workflows. Teams can compute seasonal indices, detect anomalies, and produce operational alerts across millions of acres. This makes it practical to track phenology, crop stress, and deforestation through pixel-level comparisons over time — operations that overwhelm traditional GIS and ad hoc ETL pipelines. How does Wherobots support time series analysis and change detection for agriculture and sustainability? WherobotsDB runs pixel-level temporal comparisons across satellite imagery archives using distributed Spatial SQL and Python raster workflows. Teams compute seasonal vegetation indices, detect crop stress anomalies, and generate deforestation alerts across millions of acres. Phenology tracking and change detection workflows that overwhelm traditional GIS run as scheduled Wherobots Jobs on a defined cadence. What is RasterFlow and how does it support remote sensing agriculture? RasterFlow is Wherobots’ serverless inference engine for Earth Observation datasets. It ingests satellite or drone imagery, builds inference-ready mosaics by removing cloud cover and edge effects, runs PyTorch computer vision models at scale, and vectorizes outputs as Apache Iceberg tables in your cloud storage. For remote sensing agriculture workflows, RasterFlow makes field boundary detection, satellite crop monitoring, land cover classification, and yield estimation production-grade at planetary scale. Results post-process directly in WherobotsDB for field-level joins and downstream reporting. Get started Ready to give your agriculture AI physical world context? REQUEST A DEMO START BUILDING --- ## Wherobots brought modern infrastructure to spatial data in 2025 URL: https://wherobots.com/blog/wherobots-brought-modern-infrastructure-to-spatial-data-in-2025/ Updated: 2026-10-19 In 2026 we’re bridging the gap between AI and data from the physical world. Entering 2025, we knew we needed to prove Wherobots is fundamentally the best place to create and run spatial data workloads at scale. Last year we directed the vast majority of our energy at strengthening the core fundamentals– ease of use, cost, performance, and reliability, knowing this focus would resonate with customers and value would be amplified through what we build later on. Key takeaways2025 focus was core fundamentals (ease of use, cost, performance, reliability) and bringing spatial data into the lakehouse.Wherobots led GEO type support in Iceberg and Parquet, which then flowed into Databricks Delta Lake. Spatial columns can now live in the common data estate instead of siloed GIS stores.Wherobots Cloud grew into a spatial intelligence platform with native S3 integration and a Unity Catalog integration so Databricks customers can run Wherobots on lakehouse spatial data. Wherobots Cloud had launched on AWS Marketplace in late 2024.The Apache Sedona community launched SedonaDB (single-node analytical database with spatial as a first-class citizen) and SpatialBench.WherobotsDB 2.x preview was announced with Rust and vectorized execution, accelerating spatial queries by up to 3.3x versus the first major version. It is described as TPC-H competitive with alternative managed Spark engines.RasterFlow launched in private preview as a serverless workflow to mosaic unprepared EO imagery and run custom or open PyTorch models, writing geometries to Iceberg in S3 or Unity Catalog. Late 2025: Wherobots MCP server so LLMs can design and run queries against S3 and Unity Catalog data.2026 plans listed: RasterFlow GA, more AI enablement, VS Code/Kiro, more compute environments, faster WherobotsDB, broader SedonaDB. We knew we needed to bring spatial data into the modern data architecture, which from our vantage point, is the data lakehouse. If we did nothing, much of this data would otherwise remain siloed, “special”, and out of reach of modern analytics engines that could put this data to work. This is why we led contributions of GEO type support to Iceberg and Parquet.  Off-platform through the open source Apache Sedona project, we saw an opportunity to develop a lightweight query engine that would appeal to developers because it would provide the support they need out of the box and accelerate iterations with spatial data. And so SedonaDB was born. This post is a high level summary of these and other accomplishments from our team in 2025. Now, we are actively building on top of this improved foundation, to enable AI and data practitioners across industries and use cases to operate with a heightened understanding of the physical world, for any area of interest. Customer success with scalable spatial data platforms This is what matters most. Everything else written here is just supporting evidence that shows how we made our customers more successful with spatial data this year. And what better proof than their own words? “Working with Wherobots let us focus on what matters – helping our clients make better land decisions. Their platform helps us scale efficiently while keeping our attention on real-world outcomes across energy, conservation, and development” Danan Margason Founder & CEO at Aarden.ai “The fact that Wherobots can mosaic imagery over millions of square kilometers, run AI models over those mosaics, and then organize the outputs in minutes, for 10 to hundreds of dollars is nothing short of incredible, making global scale analysis a routine pipeline instead of an enormous and extremely expensive endeavor, has the potential to change monitoring tasks far beyond field boundary analysis.” Caleb Robinson Principal Research Scientist, Microsoft AI for Good “With Wherobots, we were able to merge 15+ complex vector datasets in minutes and run high-resolution ML inference at a fraction of the cost of our legacy stack. The combination of speed, scalability, and ease of integration has boosted our engineering productivity and will accelerate how quickly we can deliver new geospatial data products to market.” Rashmit Singh CTO, SatSure “We’re helping to democratize large-scale spatial analytics for everyone. With Wherobots, we can move faster, scale bigger, and help more organizations make smarter decisions about the physical world.” Eric Pollard Founder and CEO, ParGo Elevating spatial data and AI capabilities for AWS customers It’s no surprise that many of these customers are AWS customers. In late 2024, we launched Wherobots Cloud as a product AWS customers could subscribe to directly through the AWS Marketplace. This activated a key value distribution channel between Wherobots and AWS customers. It also started our partnership in earnest with AWS. We continue to work closely with the AWS team to bring world-class spatial capabilities into the hands of their customers so they can better realize their objectives with physical world data. Leadership in the open data and lakehouse ecosystem We were the team that led the introduction of GEO type support to Iceberg and Parquet, which led to the incorporation of GEO types in the Databricks Delta Lake project. Because these projects form foundational components of the modern data architecture, with GEO type support, a significant portion of spatial data could now be interpreted and safely interoperated on by common compute engines. That also meant it no longer had to live in siloed architectures. It could thrive in the common data estate – the data lake, processed using engines like Spark, Snowflake, BigQuery, or Wherobots. If you squint, there is now a clear path for making spatial data look just like “data” in the eyes of developers and AI systems, particularly when capable engines like Wherobots can crunch it without a problem. Cloud and lakehouse integrations for spatial workflows Wherobots Cloud evolved into a full-fledged spatial intelligence platform designed not just for querying geospatial data very efficiently at scale, but for building production-grade workflows that integrate high value derivatives of physical world data into customers’ existing data architectures. Our native integration with Amazon S3 makes it possible for customers to run Wherobots on spatial data in their storage. In 2025 we announced our integration with Unity Catalog, enabling Databricks customers to activate the value of Wherobots on spatial data in their Databricks lakehouse. We will continue to add integrations such that our customers can just add Wherobots’ magic to the data infrastructure they already have. Apache Sedona appeals to a wider audience The Apache Sedona community developed and launched SedonaDB, the first open-source, single-node analytical database engine that treats spatial data as a first-class citizen. They also made it significantly easier to compare query performance across engines using SpatialBench, the first benchmarking framework for spatial queries. SedonaDB makes spatial data significantly more useful and analytically accessible for a wider range of use cases and personas. SpatialBench is there to streamline the decision making process for users looking to choose an engine based on spatial query price-performance and capability. Here’s a link to the announcement for both. WherobotsDB keeps getting better We’re continuously improving the WherobotsDB engine, raising the bar we’re self-setting for spatial query price-performance and capability. In 2025 we announced multiple new functions, tools, and compatibility with GeoPandas. We also announced a preview of a new runtime version, 2.x, which contains the latest optimizations for spatial range queries, spatial filtering, and spatial joins. Rust is at the core, and it leverages vectorized execution. Compared to the first major version, 2.x further accelerates spatial queries of up to 3.3x.  While Wherobots is generally known for its spatial data capability, 2.x is significantly more performant for general purpose query operations, to a degree in which it’s also TPC-H competitive to alternative managed Spark engines in the market.We will be sharing benchmarking results when we announce general availability for version 2 soon.  Making remote sensing and Earth sbservation data AI-ready We launched RasterFlow in private preview, the first serverless workflow purpose built to prepare and perform inference on large scale Earth observation (EO) datasets. RasterFlow is an Earth Intelligence solution, addressing the infrastructure challenges and high costs that prevented companies from utilizing raw EO data in the first place. We’ve packaged years of GeoAI expertise into a serverless, easy to use product. RasterFlow creates inference-ready mosaics after digesting large, unprepared imagery datasets, and runs model inference on these mosaics with custom or open PyTorch models to perform tasks such as change detection, classification, and segmentation. Results are delivered as geometries in Iceberg tables in a customer’s S3 bucket or as tables in Databricks Unity Catalog, to be processed by WherobotsDB or alternative engines.   Enabling AI on physical world data Physical world data is noisy, it’s large, and it’s generally semi-structured or unstructured. This data also needs more context in order for it to be useful, which requires spatial joins to other datasets. It can be publicly available, or reside as private assets within an organization’s data estate. Teams and AI systems alike need this data to be processed and contextualized with other data in order for it to be useful. At scale Wherobots provides arguably the best tools for spatial processing and contextualization at the most fundamental level, for the modern data architecture. Now Wherobots is ready to be wired up to AI systems. Late in 2025 we announced the availability of the Wherobots MCP server to give your LLM access to Wherobots’ tools. Now, LLMs can use the MCP server to efficiently design queries by understanding the spatial and non spatial data in your data estate (via the S3 and Unity Catalog integration), and run those queries on a high performance engine to answer questions about the physical world. Soon we’ll integrate the MCP server with RasterFlow. That way, an AI agent can design and trigger a workflow in Wherobots that starts with fresh EO data, prepares it for inference, generates predictions using a collection of PyTorch machine learning models, and perform additional enrichment or transforms if needed to produce the result. Join the upcoming office hour on MCP server to learn more. What’s next for Wherobots in 2026 You can reach out to the product team at product@wherobots.com, or me directly at damian@wherobots.com to share the challenges you’re facing and see how we can solve them now or with capabilities we’ll add. Here are a few discrete roadmap items we are working on, and categories of investment planned in 2026. Make RasterFlow generally available Enabling AI on physical world data Bringing Wherobots closer to developers (VS Code, Kiro, etc)  Providing support for Wherobots in the compute environment you need it to run in Making WherobotsDB even faster and cost effective Broaden the capabilities of SedonaDB Frequently Asked Questions What did Wherobots ship in 2025? Lakehouse integrations (S3, Unity Catalog), leadership on Iceberg/Parquet GEO types, and SedonaDB and SpatialBench in Apache Sedona. Also a WherobotsDB 2.x preview (up to 3.3x spatial query acceleration), RasterFlow private preview, and the Wherobots MCP server. Wherobots Cloud had become available on AWS Marketplace in late 2024. What is SedonaDB? The first open-source, single-node analytical database engine from the Apache Sedona community that treats spatial data as a first-class citizen. The same announcement included SpatialBench, a benchmarking framework for spatial queries. What is RasterFlow? As launched in 2025 private preview: a serverless workflow to prepare and run inference on large-scale Earth observation datasets. It creates inference-ready mosaics from unprepared imagery and runs custom or open PyTorch models for tasks such as change detection, classification, and segmentation. Results land as geometries in Iceberg tables in the customer’s S3 bucket or as tables in Databricks Unity Catalog. What is Wherobots building in 2026? The recap lists: make RasterFlow generally available; enable AI on physical-world data; and bring Wherobots closer to developers (VS Code, Kiro, and similar). It also lists: support running Wherobots in the compute environment customers need; make WherobotsDB faster and more cost effective; and broaden SedonaDB capabilities. --- ## The Medallion Architecture for Geospatial Data: Why Spatial Intelligence Demands a Different Approach URL: https://wherobots.com/blog/geospatial-medallion-architecture/ Updated: 2026-10-19 When most data engineers hear “medallion architecture,” they think of the traditional multi-hop layering pattern that powers countless analytics pipelines. The concept is sound: progressively refine raw data into analytical data and products. But geospatial data breaks conventional data engineering in ways that demand we rethink the entire pipeline. Key takeawaysBronze is raw: Get all your geospatial sources into cloud storage without transformation, leaving data at source where possibleSilver is structure: Standardize projections, validate geometries, enrich with spatial relationships, and convert to cloud-native formatsGold is analysis-ready: Aggregate, optimize, and prepare data for consumption across tools and applicationsIceberg is the glue: Use Apache Iceberg’s spatial extensions as your table format to manage schema evolution, lineage, and efficient spatial operationsEfficiency is existential: Geospatial data demands careful format choices and architectural decisions, and the medallion approach systematizes those choices This isn’t about just storing location data in your existing medallion setup. It’s about recognizing that spatial data introduces complexity in data structures, compute patterns, and efficiency requirements that traditional architectures simply cannot handle without significant compromise. The medallion (or multi-hop) architecture, when properly adapted for geospatial workloads, becomes something more powerful: a systematic approach to managing spatial intelligence at scale. In this post, I will outline how we have taught this in the Wherobots Geospatial Data Engineering Associate course to leverage this base design and group different spatial tasks, query patterns, and outputs into each step, leveraging both raster and vector datasets. What Is Medallion Architecture? Medallion architecture is a data design pattern that organizes a lakehouse into three layers of increasing quality: Bronze, Silver, and Gold. Bronze stores raw data as it arrives. Silver stores cleaned, validated, and conformed records that downstream jobs can trust. Gold stores aggregated, business-ready tables for analytics, dashboards, and machine learning. Databricks popularized the pattern, which is also called a multi-hop architecture because data moves through the layers in sequence. LayerWhat it storesGeospatial exampleBronzeRaw source data, unchangedShapefiles, GeoTIFFs, and GPS feeds, registered in place on cloud storageSilverValidated, standardized dataRepaired geometries, one coordinate reference system, GeoParquet and cloud-optimized GeoTIFF filesGoldAggregated, analysis-ready dataParcel risk scores, H3 aggregates, and PMTiles for web maps Each layer needs changes for geospatial data. Spatial sources mix vector and raster formats, span many coordinate reference systems, and require spatial joins that cost more than tabular joins. The sections below adapt Bronze, Silver, and Gold for those workloads. Why Geospatial Data Demands Architectural Rethinking Before diving into the medallion architecture itself, let’s acknowledge what makes geospatial data different. The Fragmentation Problem In most organizations, geospatial data doesn’t arrive nicely packaged. You might pull property boundaries from a municipal data portal in shapefiles, elevation data from AWS open data as cloud-optimized GeoTIFFs, satellite imagery from NASA, and local POI data from your internal systems. Each source has different formats, coordinate systems, refresh rates, and quality levels. Traditional data lakes aren’t equipped to handle this heterogeneity efficiently. Moving terabytes of raw geospatial data through your pipeline adds cost and latency. And then there’s the format problem: legacy formats like shapefiles and JPEG2000 can’t be partially queried. If you want Seattle property data from global shapefiles, the traditional approach is to download the entire file, unzip it, filter locally, then transfer what you need. The Scale-Complexity Tradeoff Geospatial scale isn’t just about row count. It’s about the combination of volume, global distribution, mixed data types (vectors, rasters, array-based formats, point clouds), conversion / interpolation between those data types, and the inherent cost of spatial operations. A simple point-in-polygon operation across a million properties and thousands of geographical features involves computation that traditional systems struggle with. This is why you see organizations either underutilizing their spatial data or building custom solutions that work for one specific problem but don’t generalize. The efficiency gap is real, and it’s expensive. The Medallion Architecture: Bronze, Silver, Gold The medallion architecture solves these challenges by enforcing structure while maintaining flexibility. Here’s how it works for geospatial data: Bronze Layer: Ingestion and Preservation The bronze layer is deceptively simple: get raw geospatial data into your system without transformation. For Data Engineers: This layer is your staging area. You’re ingesting data from disparate sources: APIs, files, databases, cloud storage without enforcing business logic. The goal is to preserve raw data fidelity while standardizing the container. For geospatial data specifically, this means several important decisions: Leave data at source when possible. If you have a global elevation dataset sitting on AWS S3, don’t download it into your local systems. Create a remote reference to it. This is one of the biggest efficiency gains in modern geospatial data pipelines. Convert to cloud-native formats. As data arrives in your bronze layer, immediately convert legacy formats (shapefiles, JPEG2000, uncompressed GeoTIFFs) into cloud-native equivalents (GeoParquet, cloud-optimized GeoTIFFs). This isn’t optimization but a prerequisite for efficient querying downstream. Preserve lineage and versioning. Geospatial data often changes such as when property boundaries get redrawn, satellite imagery updates, elevation models improve. You need to track when data arrived, from where, and what version you’re working with. Raster tiling and storage optimization. For raster data (imagery, DEMs), bronze handles tiling and creates remote references. Instead of loading massive rasters into memory, you tile them and access only what you need. For GIS Professionals: Think of bronze as your data repository. In traditional GIS workflows, you manage multiple datasets, each in its own format, living in different folders or databases. Bronze centralizes this but respects the raw nature of the data. You’re not making decisions about coordinate systems, geometry validation, or spatial relationships yet. This is also where automation becomes critical. Instead of manually downloading datasets monthly, bronze ingestion jobs run on schedules, automatically pulling new data and versioning it. This means your analyses always reflect current reality. Data table formats such as Apache Iceberg and Delta Lake provide several advantages here since you can easily append data to the table for records that have changed. They also use underlying cloud-native formats such as GeoParquet with the new V3 Iceberg specification and within Wherobots you can read out-of-database rasters (or a reference to a specific part of an image) without moving the source raster file saving massive amounts of I/O operations. How Wherobots Handles the Bronze Layer Wherobots Cloud simplifies bronze layer operations through WherobotsDB, its cloud-native spatial processing engine. When ingesting raw geospatial data, Wherobots immediately enables critical capabilities for you: Format conversion at ingestion: Wherobots automatically converts legacy spatial formats (shapefiles, JPEG2000, standard GeoTIFFs) into cloud-native formats during ingestion. This happens transparently—you connect to data in whatever format it arrives, and it’s can be optimized for cloud storage and querying. Remote reference handling: For massive open datasets, Wherobots manages remote references natively. Global elevation datasets sitting on AWS S3 don’t get duplicated into your systems. Instead, Wherobots creates efficient references to the original data, allowing you to query it as if it were local while paying only for what you access. Apache Iceberg storage with spatial extensions: Data in bronze is stored using Havasu, Wherobots’ Apache Iceberg-based spatial table format – which is the foundation of the Iceberg v3 spec. This provides built-in versioning, time travel, and ACID transactions from day one. You can rewind to yesterday’s data for audits or reprocessing without complex manual versioning schemes. Automatic metadata tracking: Wherobots tracks lineage, data arrival times, and schema information automatically, eliminating the need for manual data cataloging in bronze. The key to Wherobots’ approach to bronze is that it enforces good practices without requiring you to build them yourself. You’re getting schema evolution, ACID compliance, and spatial optimization automatically. Silver Layer: Enrichment and Standardization Silver is where the intelligence begins to emerge. This is where you clean, enrich, and structure data into a consistent, analysis-ready state. It’s also often where Data Science teams may want to work before “publishing” analysis ready data to end users (in gold tables). For Data Engineers: Silver involves: Coordinate system harmonization. Raw geospatial data arrives in dozens of different projections. Silver transforms everything into standard coordinate systems (typically WGS 84 for global work, or local UTM zones for regional analysis). Geometry validation and repair. Geospatial data is messy. Overlapping polygons, self-intersecting lines, invalid geometries from legacy systems all appears in silver transformation. You validate geometries and fix what’s repairable. Spatial enrichment operations. This is where you add geospatial relationships. Perform spatial joins to associate properties with neighborhoods. Buffer roads to identify nearby areas. Create 3D geometries by joining elevation and additional data attributes to 2D features. Calculate spatial statistics like area, perimeter, or distance to nearest feature. Advanced spatial operations. Often times we think of spatial relationships just as a spatial join. But performing analysis such as a K-Nearest Neighbor join, zonal statistics (or a raster to vector join), spatial aggregation, distance within (i.e. features within N distance), area weighted interpolation (such as weighted population statistics), shortest path analysis, line of sight analysis, space and time proximity analysis (i.e. near miss) and more. These require not only optimized spatial data but the right functions to make them work. The key architectural principle in silver is that you’re not making final analytical decisions you’re preparing the data so downstream consumers can make those decisions efficiently. For GIS Professionals: Silver is where your spatial data processing happens. This is the layer where you answer structural questions: What coordinate system makes sense for this analysis region? Are there geometry issues I need to resolve? What spatial relationships exist between datasets that I’ll need downstream? Should I enrich my vector data with elevation? Satellite indices? Population density? In traditional GIS, this work happens ad-hoc before each analysis. In the medallion architecture, you do it once, well, and capture the work in reusable transformations. This is efficiency multiplied across teams and projects. Another key note is that you will likely want different scales of compute to handle these processes. Easier process like spatial joins on vector basic geometries may only require a smaller compute instance whereas a large scale NDVI (or other vegetation indexes) would require a larger compute instance. The ability to mix and match your compute scales is a critical advantage in a spatial platform not only for speed but cost optimization. How Wherobots Handles the Silver Layer The silver layer is where WherobotsDB spatial optimization truly shines. Wherobots provides native spatial operations that make complex transformations not just possible but efficient at scale: Coordinate system transformations at speed: Wherobots includes optimized functions for reprojecting geometries across coordinate systems. What might take hours in desktop GIS or loose scripts in Python happens in seconds on Wherobots’ distributed architecture. This is critical because spatial efficiency compounds—faster transformations mean you can afford to enrich data more completely. Geometry validation and repair: Wherobots includes native geometry validation and repair functions. You can identify invalid geometries, split self-intersecting polygons, and fix common data quality issues in SQL. This work is parallelized across the cluster, not constrained by a single machine’s memory. Spatial enrichment operations: Silver transformations in Wherobots use Spatial SQL with 300+ functions for vector and raster operations. Spatial joins that would take hours in traditional systems execute in minutes. Buffer operations, intersection calculations, proximity analysis—all happen efficiently on distributed data. Wherobots handles both vector and raster data natively in the same query, meaning you can enrich vector property data with raster elevation or satellite imagery in a single operation. Raster tiling and remote storage: For raster data, Wherobots can tile and optimize imagery while keeping it remote on S3. You’re not loading massive datasets into memory. Instead, Wherobots’ raster functions work against remote tiles, accessing only what’s needed for each query. Reusable SQL transformations: Silver transformations are written in Spatial SQL and stored as views or jobs. These are version-controlled, reproducible, and can be re-run as new data arrives in bronze. Unlike one-off Python scripts, silver logic in Wherobots is production-grade from day one. The combination of Spatial SQL and WherobotsDB’s distributed architecture means silver layer work that once required deep geospatial expertise and careful optimization is now accessible to data engineers who know SQL. Wherobots handles the spatial complexity. Gold Layer: Analytical Readiness and Delivery Gold is your analytics-ready product layer. Data here is fully prepared, enriched, and available for immediate use in downstream applications and BI or GIS systems. For Data Engineers: Gold contains: Advanced aggregates and spatial statistics. Point-in-polygon counts (how many properties in each neighborhood), zonal statistics (average elevation by region), spatial clustering (identify hotspots) updated on a regular basis, ready to join by identifier to non spatial data. Optimized indices and pre-computed relationships. Store commonly-needed spatial joins and queries pre-computed, reducing downstream query time. Tiled and multi-format outputs. Generate PMTiles for web visualization, GeoParquet for analytics, and optionally push to PostGIS or SedonaDB/DuckDB for application serving. Quality-controlled data. Remove erroneous geometries that made it through silver, apply final business logic, and ensure consistency. AI ready data. Create language based data that is ready for an LLM or agentic applications to consume removing heavy geometries which can confuse an LLM. Gold is where you can afford to be opinionated because the work upstream ensures those opinions are well-informed. For GIS Professionals: Gold is your analysis starting point. Instead of wrestling with raw data, you access gold tables that are: Geometrically valid and properly projected Enriched with relevant spatial context (elevation, proximity to features, administrative boundaries) Pre-aggregated for common questions Formatted for direct use in your tools and custom applications (QGIS, Felt, BI dashboards, machine learning pipelines) You go from “I need to combine three datasets and fix projection issues” to “Here’s the enriched regional dataset, ready for analysis.” How Wherobots Handles the Gold Layer Gold layer queries run on WherobotsDB, which delivers 3x faster performance and 45% better price-performance on spatial workloads. Gold layer work in Wherobots focuses on making spatial data immediately useful across your entire organization: Pre-computed aggregates at scale: Wherobots can compute spatial aggregates—point-in-polygon counts, zonal statistics, spatial clustering—and store them efficiently. These pre-computed metrics are small enough to serve directly to applications but powerful enough to support complex analyses. A query that aggregates a billion point observations into regional summaries completes in seconds. Multiple output formats: Gold data can be materialized in multiple forms depending on consumer needs. Export as GeoParquet for analytics, create PMTiles for web visualization, push to PostGIS for application serving, or generate standard Parquet for BI tools. Wherobots’ native format support means you write once and consume many ways. Web tile generation at scale: Wherobots includes a scalable vector tile (VTiles) generator that’s optimized for producing map tiles from massive datasets. Instead of spending weeks generating tiles for a global dataset, Wherobots produces them in hours. These tiles feed directly into web applications, Felt, QGIS, or any tile-consuming tool. RasterFlow integration: Gold layer work in Wherobots increasingly includes AI-powered enrichment. RasterFlow raster inference allows you to extract insights from satellite imagery at scale—identifying buildings, roads, vegetation patterns—and embed those insights directly into your gold tables. Machine learning models that would require custom integration work in other systems are built into Wherobots’ gold workflow. Spatial SQL API for consumption: Instead of exporting and distributing files, gold data is served through Wherobots’ Spatial SQL API. Applications, dashboards, and downstream systems query gold data directly through Python SDK, Java JDBC driver, or standard SQL endpoints. This means gold data stays fresh and you don’t distribute copies. Gold in Wherobots is less about storing static snapshots and more about providing a live, queryable product layer that adapts to consumer needs. Why This Architecture Solves Geospatial Problems Efficiency Through Format Optimization Traditional systems treat geospatial data like regular tabular data. This is inefficient. A shapefile is a collection of files in a zip that requires downloading the entire dataset to access a subset. GeoParquet, by contrast, stores data in columnar format with spatial indexing built-in. You can query it over the internet by bounding box or geometry filter and only transfer what you need. The medallion architecture enforces this progression from legacy to cloud-native formats, reducing storage costs and query latency dramatically. A terabyte global elevation dataset stays on AWS S3 as a reference. You don’t duplicate it. Separation of Concerns Bronze, silver, and gold are separate databases with separate lineage. This means: Raw data safety. Your source data is never modified. If a transformation downstream goes wrong, you can reprocess from bronze without losing the original. Independent evolution. Teams can improve silver transformations without affecting gold. Applications consuming gold don’t care about silver changes as long as contracts remain stable. Governance simplicity. Access controls are straightforward. Grant different teams access to different layers based on their role. Automation and Scalability By encoding transformations into standardized layers, you enable automation. Data ingestion becomes scheduled jobs. Updates propagate automatically from bronze through silver to gold. You stop manually managing data and start managing logic. This scales to global datasets because you’re not moving data—you’re moving queries. Spatial predicates push down to where the data lives, reducing network transfer and computation. Real-World Application: Housing Analytics at Scale Consider a concrete example: analyzing housing market patterns across Seattle using a blend of property records, elevation, transportation networks, satellite imagery, and census data. Bronze Layer: Ingest property sales records from the county (updated monthly) Pull property boundaries from municipal GIS (shapefile, converted to GeoParquet) Reference global DEM (stays on AWS S3) Ingest road network (OpenStreetMap) Store satellite imagery references (Copernicus, AWS Open Data) Silver Layer: Transform property boundaries to WGS 84 and validate geometries Perform spatial join: properties to neighborhoods Enrich with elevation by querying DEM at property centroids Calculate proximity metrics: distance to nearest transit, nearest park Tile satellite imagery for efficient access Gold Layer: Aggregate: median price by neighborhood, price trends by elevation Pre-compute spatial clusters: identify hot markets Generate PMTiles for web visualization Export clean GeoParquet for ML pipelines Push refined data to PostGIS for application serving This progression from raw, fragmented sources to a unified, enriched analytical product is exactly what the medallion architecture enables. And the efficiency gains compound as more analyses build on the same gold layer. Comparison to Other Approaches Why Not Keep Everything in PostGIS? PostGIS is powerful for transactional spatial queries and operations, but it’s a database optimized for consistency and ACID transactions, not analytics at scale. As data volume grows, PostGIS becomes expensive to operate and scale. You’re paying for transactional guarantees you don’t need for analytics. The medallion approach uses cloud storage (S3) as the primary store, which scales cheaply, and can use PostGIS only for the final gold layer serving to applications that need it. This is typically more cost-effective and performant. Why Not Use a Specialized GIS Data Warehouse? Geospatial-specific data warehouses exist but are typically proprietary, expensive, and inflexible. They don’t integrate easily with your existing data infrastructure or machine learning pipelines. The medallion architecture is platform-agnostic—it works with Spark, Flink, DuckDB, or any distributed compute framework that understands spatial operations. Why Not Just Use Desktop GIS with Cloud Storage? Desktop GIS tools (QGIS, ArcGIS) can read cloud storage but aren’t designed for production pipelines. They require manual steps, don’t automate updates, and don’t scale to the volume and frequency of modern geospatial data. The medallion architecture automates what desktop GIS does manually. Implementation Considerations Technology Stack The medallion architecture for geospatial data typically uses: Storage: Cloud object storage (AWS S3, Google Cloud Storage, Azure Blob) Table Format: Apache Iceberg with spatial extensions (Havasu), which provides schema evolution, ACID transactions, time travel, and spatial indexing Compute: Apache Sedona or Wherobots (distributed geospatial framework) or SedonaDB (single-node spatial SQL) Orchestration: Workflow tools (Airflow) to manage bronze→silver→gold pipelines Visualization: Web tiles (PMTiles), GIS tools (QGIS, Felt), or BI platforms Iceberg: The Foundation Apache Iceberg is the table format that makes this all work efficiently. It’s a metadata layer over Parquet files that provides: Schema evolution: Add columns without breaking downstream queries ACID transactions: Reliable concurrent updates Time travel: Query historical snapshots (rewind to yesterday’s data) Partitioning: Automatic data organization for efficient queries Spatial indexing: Efficient spatial predicates and pushdown optimization With Iceberg’s spatial extensions, you get native geometry storage and spatial optimizations, making it the ideal foundation for medallion pipelines. Plus with many upstream data warehouses now accepting Iceberg V3 you have a zero ETL process to all of these systems from your gold tables. Data Lineage and Governance The medallion architecture inherently supports data governance. Each layer has clear ownership and lineage. Track which source datasets feed which analyses. Implement role-based access controls at layer boundaries. Maintain data catalogs describing bronze sources, silver transformations, and gold products. Putting this into practice with Wherobots From Theory to Practice The medallion architecture isn’t a theoretical concept—it’s proven across thousands of data engineering organizations. What makes it powerful for geospatial is that it acknowledges geospatial’s unique challenges: Format diversity: Enforced conversion to cloud-native formats Computation intensity: Spatial predicates pushed down to efficient compute Scale complexity: Remote references and tiling instead of data movement Governance needs: Clear layer separation for access control and lineage Integration requirements: Gold layer can feed into GIS tools, ML pipelines, or applications For teams managing geospatial data, whether you’re data engineers building analytics platforms or GIS professionals upgrading legacy workflows, the medallion architecture provides a systematic, scalable path forward. The alternative (managing spatial data ad-hoc) becomes increasingly untenable as volume, velocity, and complexity grow. The medallion architecture makes it possible to move at scale without moving data. The geospatial industry is shifting from moving data to moving queries. The medallion architecture is how you make that shift sustainable. The Geospatial Data Engineering Associate course covers each layer in depth. Try it on your own data START BUILDING Medallion Architecture FAQ What are the Bronze, Silver, and Gold layers? Bronze holds raw data as it arrives from source systems. Silver holds data that has been cleaned, validated, deduplicated, and conformed to shared schemas.Gold holds aggregated tables built for a specific use: reporting, dashboards, or model features. In a geospatial pipeline, Silver is where geometries are repaired and coordinate reference systems are standardized. Is medallion architecture ETL or ELT? Medallion architecture usually follows ELT. Raw data lands in Bronze first, and transformations run inside the lakehouse as data moves to Silver and Gold. For geospatial data, the heaviest transformations happen in Silver: geometry validation, reprojection, and conversion to GeoParquet or cloud-optimized GeoTIFF. Who came up with medallion architecture? Databricks introduced the term as part of its lakehouse guidance. The pattern builds on older staged data warehouse designs that separate raw, cleaned, and presentation layers. Does Snowflake use medallion architecture? Yes. Medallion architecture is a design pattern, so data teams apply it on Snowflake, BigQuery, Databricks, and open lakehouses built on Apache Iceberg. Each layer maps to a schema, a database, or a set of tables. What are the downsides of medallion architecture? Three layers mean more copies of data, more pipelines to maintain, and added latency between ingestion and analysis. Geospatial teams cut the copy cost by registering large rasters in place in Bronze and by storing Silver and Gold as Iceberg tables backed by GeoParquet files. How does medallion architecture work for geospatial data? Bronze registers raw vector and raster sources, often without moving them. Silver validates geometries, standardizes coordinate reference systems, and adds spatial relationships with spatial joins. Gold produces aggregated tables, map tiles, and model features.Apache Iceberg tables with native geometry types hold each layer, and WherobotsDB runs the spatial transformations between them. --- ## Mobility & Map Making URL: https://wherobots.com/solutions/mobility-and-map-making/ Updated: 2026-10-12 Live map app Physical World Context for Mobility & Map Making Wherobots gives mobility and mapping teams the context layer for location intelligence at planetary scale. The map scores 100 candidate drone delivery sites across Texas on the people within 10 km, FAA LAANC airspace and the obstacles nearby. Explore the drone map Request a demo 100 candidate nest sites 82 operable sites 5.07M people within 10 km of the top 21 Houston, Texas FAA LAANC airspace ceiling (ft above ground) 0 ft, no LAANC 50 ft 100 ft 150 ft 200 ft 250 ft 300 ft 350 ft 400 ft 7 of the top 21 sites have more than a quarter of their 10 km circle capped at 200 ft or lower. Airspace: FAA UAS Facility Maps. Towers: Overture Maps. Power lines: OpenStreetMap contributors. Population: US Census ACS. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. Companies Accelerating Outcomes with Wherobots and Apache Sedona Why Mobility Teams Build Physical World Context with Wherobots Mobility data is physical world data. Every GPS trace, every trajectory, every map feature exists in geography. Wherobots provides the geospatial AI infrastructure to process billions of location data points, execute spatial joins at scale, and deliver the location intelligence products your customers depend on. Expensive operations Inaccurate outputs Complex joins Siloed data Fixed Infrastructure Expensive operations Industry Problem Trajectory Processing Takes Hours or Days at Scale Trajectory processing takes hours or days when analyzing billions of GPS points across millions of devices, delaying location intelligence products and fleet optimization insights Wherobots solution Process GPS Trajectories Up to 20x Faster with Distributed Spatial Processing Wherobots processes trajectories up to 20x faster, handling billions of GPS points in minutes using distributed spatial processing. Wherobots turns raw GPS streams into structured location intelligence, giving your AI stack the physical world context it needs to reason about movement, routes, and geographic patterns. 20× faster Inaccurate outputs Industry Problem Raw GPS Traces Fail to Align Accurately to Road Networks Raw GPS traces contain positioning errors and signal drift that prevent accurate map alignment. Without proper map matching, mobility data products produce incorrect routes, unreliable turn-by-turn data, and flawed fleet tracking — directly impacting the quality of location intelligence delivered to customers. Wherobots solution Achieve 99.8% Route Accuracy with Distributed Map Matching Transform raw GPS traces into accurate routes with Wherobots’ distributed map matching processing millions of trajectories against road networks. 99.8% Route Accuracу Complex joins Industry Problem Complex Spatial Joins Across Millions of POIs Overwhelm Traditional Systems Foot traffic analysis across millions of POIs requires complex spatial joins that overwhelm traditional data systems and even modern warehouses Wherobots solution Run Spatial Joins Across Millions of POIs Simultaneously Wherobots processes movement patterns across millions of points of interest simultaneously using distributed spatial joins — operations that overwhelm traditional data systems and modern warehouses. What once required complex infrastructure workarounds runs natively at scale on the Wherobots spatial lakehouse. Processing efficiency Billions of POIs in seconds Siloed data Industry Problem Multi-Source Mobility Data Stays Siloed When Platforms Can’t Integrate GPS, Raster, and Vector Data at Scale Multi-source mobility data remains siloed when platforms can’t efficiently integrate GPS traces, road networks, building polygons, telematics data, raster data, and geospatial regional context at scale in a single platform. Wherobots solution Unify GPS, Vector, and Raster Data in a Single Spatial Lakehouse Wherobots unifies mobility data, including GPS traces, road networks, building polygons, telematics, and raster data — with native support for trajectories, vector data, and raster formats on a single lakehouse platform powered by Apache Sedona and Iceberg. 100% Unified Fixed Infrastructure Industry Problem Fixed Infrastructure Forces Mobility Teams to Over-Provision and Overpay Traditional spatial infrastructure requires fixed compute provisioning, forcing mobility data teams to size for peak workloads and pay for idle capacity. As data volumes grow, scaling requires costly re-architecture rather than elastic expansion, creating a ceiling on what teams can process and a floor on what they must spend. Wherobots solution Reduce Infrastructure Costs by Up to 70% with Serverless Spatial Computing Wherobots deploys as a serverless managed cloud service, scaling compute elastically with your workload. Mobility teams pay only for what they use, eliminating idle capacity costs and enabling up to 70% in infrastructure savings compared to fixed spatial computing environments. 70% In common savings “With Apache Sedona, we process millions of fleet-derived traffic signs, using scalable spatial joins and partitioning to automate map updates—enhancing Amazon Last Mile’s delivery networks for faster, more reliable routing.” Arka Pratim Das Sr. Manager, Software Development, Amazon Maps See How Mobility Teams Build AI That Understands Spatial Data Schedule a demo to see how leading mobility and mapping companies process billions of GPS points, build location intelligence at scale, and deliver fresh geospatial data products to market faster. REQUEST A DEMO Mobility & Map-Making Resources: Geospatial Analysis, Map Matching, and Spatial Data Processing Explore guides, webinars, and blog posts on geospatial data processing, map matching, and spatial analytics for mobility and map-making companies. Customer Story Accelerating Geospatial Analysis with Wherobots and GeoPostcodes Learn how Wherobots improves processing performance for postcode-based spatial analysis using distributed geospatial computing. LEARN MORE Map Matching Map Matching Webinar: GPS Trajectory Processing and Road Network Alignment Watch this webinar to learn how Wherobots processes millions of GPS trajectories against road networks for accurate route reconstruction and location intelligence. LEARN MORE Map Matching Map Matching for Telematics: How Wherobots Aligns GPS Data to Road Segments Read how Wherobots uses distributed map matching to transform raw telematics and GPS data into accurate road segment alignments for mobility data products. LEARN MORE Frequently Asked Questions: Wherobots for Mobility Data Companies How does Wherobots help mobility companies build location intelligence products? Wherobots processes billions of GPS points, trajectory datasets, and location data streams using distributed spatial SQL and Python. Teams build location intelligence products by joining movement data with road networks, points of interest, and administrative boundaries in a single query. Map freshness, route accuracy, and fleet analytics that previously required expensive batch pipelines run at scale in minutes. We already use H3 for spatial indexing. Does Wherobots add value on top of that? H3 indexing works well for discretizing spatial data and aggregating at fixed resolution. WherobotsDB extends that foundation by handling the spatial joins, trajectory analytics, and complex geometric operations that H3 alone cannot perform. Teams keep H3 for the indexing layer and use Wherobots for the full portfolio of mobility analytics: map matching, trajectory processing, POI analysis, and geospatial data mapping at scale. What types of mobility data does Wherobots support? WherobotsDB processes GPS traces, mobile device location data (bidstream and app-derived), IoT sensor streams from vehicles and infrastructure, vehicle telemetry, and trajectory datasets. Vector data (road networks, POI records, administrative boundaries, building footprints) and tabular data (fleet records, device identifiers, event logs) participate in the same spatial queries. No separate pipelines per data type. What deployment options does Wherobots offer for mobility companies? Wherobots connects to AWS cloud storage, Databricks, and any Apache Iceberg catalog. Your data stays in place. Wherobots runs compute against it without migration or format conversion. Managed cloud, bring-your-own-cloud, and VPC deployment options are available. Wherobots is SOC 2 Type 2 attested. How does Wherobots compare to traditional GIS tools and cloud data warehouses for mobility analytics? Traditional GIS tools were not built for billion-point GPS datasets or real-time trajectory processing. Cloud data warehouses handle tabular operations well but lack the spatial join performance and geometric precision that mobility analytics require. WherobotsDB runs distributed spatial SQL optimized for spatial operations, processing trajectory datasets and geospatial joins at a scale that general-purpose analytics platforms cannot match. Mobility teams write standard SQL and Python. Wherobots handles the distributed compute. How does Wherobots support location analytics and geospatial data mapping at scale? WherobotsDB provides 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations. Mobility and map-making teams use these for location analytics workflows: map conflation, spatial joins between GPS data and road networks, point-in-polygon analysis across millions of POIs, and geospatial data mapping pipelines that run on a defined schedule. Wherobots Jobs automate recurring location analytics runs without manual intervention. Get started Ready to build location intelligence at planetary scale? REQUEST A DEMO START BUILDING --- ## Financial Services URL: https://wherobots.com/solutions/financial-services/ Updated: 2026-10-17 Live map app Physical World Context for Financial Services & Insurance Wherobots is the context engine that gives financial services and insurance teams the physical world context for property risk and exposure analysis at portfolio scale. This example map application screens every building in Colorado for wildfire, hail, flood, wind and access to a fire department. Explore the risk map Request a demo 2,771,126 buildings screened 307,679 in the top wildfire tier 547,396 more than 5 road miles from a fire department Colorado Springs to Black Forest Highest wildfire score (0-2) per parcel 0, none detected 1, moderate 2, elevated 307,679 of the 2,771,126 buildings in Colorado (11.1%) are in the top wildfire tier. Buildings: Overture Maps. Wildfire: USFS Wildfire Risk to Communities. Parcels: Regrid. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. Why Financial Services Teams Build Physical World Context with Wherobots AI tools built on documents and structured data cannot see what geography does to risk. Wherobots closes that gap: climate risk modeling, property risk assessment, catastrophe exposure analysis, and portfolio-level geospatial intelligence, all on the physical world data behind your assets, your exposure, and your bottom line. Climate Risk Blind Spots Across Property Portfolios Limited alternative data insights Slow assessments Fragmented portfolio intelligence Inadequate retail location optimization Climate Risk Blind Spots Across Property Portfolios Industry Problem Incomplete Climate Risk Assessments Across Property Portfolios Financial institutions need to assess climate risk across millions of properties, but AI systems built on financial documents and market data have no visibility into the physical world conditions that drive loss. Flood zones, wildfire corridors, storm surge exposure: these risks live in geography, not spreadsheets. Wherobots solution Asset-Level Climate Risk Analytics at Portfolio Scale Wherobots processes satellite imagery, flood hazard maps, wildfire risk layers, and property records at planetary scale to deliver climate risk analytics across your entire portfolio. Spatial SQL joins physical world data with your asset records so underwriters and risk analysts see exposure before it becomes a claim. 30 000+ Assets assessed Limited alternative data insights Industry Problem Physical World Signals Missing from Investment Models Satellite imagery, weather data, and geospatial datasets hold signals that predict asset performance, supply chain disruption, and market shifts. Without spatial AI infrastructure, investment teams cannot integrate physical world data into their models. Wherobots solution Geospatial AI Infrastructure for Alternative Dataa Wherobots gives investment and risk teams the geospatial AI infrastructure to process satellite imagery, mobility data, and environmental datasets at scale. RasterFlow runs computer vision models on Earth observation data. WherobotsDB joins the results with financial records in standard SQL. Physical world context becomes a structured input to your models. 100% Data coverage Slow assessments Industry Problem Property Risk Assessment at Portfolio Scale Takes Days Property risk assessment at portfolio scale takes days or weeks when legacy tools process locations one at a time. Catastrophe modeling requires cross-referencing millions of addresses against flood, wind, seismic, and wildfire hazard layers. Traditional GIS cannot keep up. Wherobots solution Catastrophe Modeling in Minutes, Not Days Wherobots processes millions of property locations against multiple hazard layers in minutes, not days. Distributed spatial joins at scale turn catastrophe modeling from a batch process into a near-real-time capability. Underwriters and portfolio managers get exposure answers faster than the market moves. 95% Time saved Fragmented portfolio intelligence Industry Problem Fragmented Risk Data Across Disconnected Systems Risk data lives in disconnected systems: property records in one database, flood maps in a GIS, satellite imagery in cloud storage, weather data in a third-party API. No single platform joins these to give portfolio managers a unified view of geographic exposure. Wherobots solution Unified Geospatial Context for Portfolio Risk Intelligence Wherobots unifies physical world datasets on a single Apache Iceberg-based platform. Spatial SQL joins property records, hazard layers, satellite-derived insights, and environmental data in one query. The result: a complete geospatial context layer for portfolio-level risk intelligence. Thousands Of holdings analyzed Inadequate retail location optimization Industry Problem Site Selection Without Spatial AI Branch placement, retail expansion, and market analysis depend on understanding foot traffic, demographics, competitor proximity, and physical accessibility. Financial institutions making these decisions without spatial AI rely on outdated reports and manual analysis. Wherobots solution Data-Driven Site Selection at Scale Wherobots processes location intelligence datasets at scale: mobility data, demographic boundaries, competitor locations, and physical accessibility layers. Spatial SQL and Python workflows score and rank candidate locations against multiple geographic criteria simultaneously. Physical world context turns site selection from guesswork into data-driven decision-making. Millions Of locations analyzed Financial Institutions and Insurers Using Wherobots and Apache Sedona “Getting data, algorithms, and compute in one place with Spark/Sedona notebooks is a huge boost. Powerful like Earth Engine, but with the control developers need to get jobs done.” John Powell Sr. Geospatial Data Engineer, Addresscloud See How Financial Services Teams Build AI That Sees Risk Schedule a demo to see how leading insurers and financial institutions process millions of property records, model catastrophe exposure, and build the physical world context layer behind smarter risk decisions. REQUEST A DEMO Resources for Financial Services and Insurance Teams Use cases, examples, and reproducible notebooks for financial services & insurance teams. Aarden.ai: 300X Faster Landholding Analysis How Aarden.ai used Wherobots to accelerate landholding analysis 300X Learn more Wherobots vs Google Earth Engine and Big Query See how Wherobots compares to Google Earth Engine and Big Query for raster operations, spatial joins at scale, and running Earth observation models Learn more RasterFlow: Planetary Scale Earth Intelligence How RasterFlow works and why you should consider it for planetary-scale Earth observation models that you want to run instantly. RasterFlow Webinar Frequently Asked Questions: Geospatial Analytics for Financial Services and Insurance How does Wherobots support climate risk modeling and property risk assessment at portfolio scale? Wherobots processes satellite imagery, flood hazard maps, wildfire probability layers, and property records in a single distributed query. WherobotsDB’s 300+ spatial functions cover vector and raster data, with native Spark SQL for tabular operations, so risk analysts can join physical-world hazard data with asset records without moving data or switching tools. Climate risk modeling that previously required days of batch processing completes in minutes at portfolio scale. Insurers and portfolio managers use the platform to score flood and wildfire exposure at the address level, model catastrophe scenarios, and monitor accumulations across their full book. We already use H3 to analyze risk concentration. How would Wherobots extend that capability? H3 indexing works well for risk score aggregation and exposure summaries at the hexagonal cell level. WherobotsDB extends that foundation by joining H3 grids with higher-fidelity vector data (parcel boundaries, building footprints, road networks), raster layers (satellite imagery, elevation models, precipitation grids), and event footprints that H3 alone cannot represent. Custom spatial factors computed from that richer dataset feed back into your risk models. Portfolio-wide spatial queries and raster sampling run in parallel at any scale. H3 stays in your workflow. Wherobots handles what H3 cannot. What physical-world data does Wherobots support for property risk assessment? WherobotsDB processes three data categories in one platform. Vector data covers property boundaries, parcel records, building footprints, flood zones, road networks, and point inventories. Raster data covers satellite imagery, aerial photography, elevation models, climate grids, precipitation layers, wildfire probability grids, and weather event footprints. Tabular data covers policy tables, claims records, and third-party model scores, handled through native Spark SQL. All three are queryable in one platform, so property risk assessment workflows do not require separate pipelines per data format. How does Wherobots connect to existing data infrastructure? Wherobots connects to AWS cloud storage, Databricks, and any Apache Iceberg catalog. Your data stays in your cloud storage. Wherobots runs compute against it without migration or format conversion. Financial institutions with compliance requirements can deploy in a managed cloud, bring-your-own-cloud, or VPC configuration. Wherobots is SOC 2 Type 2 attested. How does Wherobots compare to traditional GIS tools for catastrophe modeling? Traditional desktop GIS and single-node spatial libraries process one location at a time. Catastrophe modeling that requires cross-referencing millions of property addresses against flood, wind, seismic, and wildfire hazard layers hits compute limits at that architecture. WherobotsDB runs distributed spatial SQL across billions of rows and terabytes of raster and vector data, processing millions of locations against multiple hazard layers in minutes. The platform handles spatial joins, raster sampling, and coordinate reference system reconciliation that takes days in legacy tools. Risk teams write standard SQL and Python. The distributed compute layer handles the scale. Get Started Know your exposure before the market does. REQUEST A DEMO START BUILDING --- ## Energy & Utilities URL: https://wherobots.com/solutions/energy-utilities/ Updated: 2026-10-12 Live map app Physical World Context for Energy and Utilities Wherobots gives energy and utility teams the context layer for grid analytics at scale. The map screens every high-voltage transmission span in California for the wildfire exposure of the land around it, on a 0 to 9 score. Explore the wildfire map Request a demo 357,554 spans screened statewide 329,303 spans scored 7.7% of scored spans score 6 or more San Diego County, El Cajon to Ramona Risk score (0-9) per transmission span 0-2 3-4 5 6-7, elevated 8-9 25,401 of the 329,303 scored spans in California (7.7%) score 6 or more. Fuels: USFS. Canopy: Meta. Greenness: Sentinel-2. Slope: Copernicus GLO-30. Lines and buildings: Overture Maps. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. Companies Accelerating Outcomes with Wherobots and Apache Sedona Why Energy Teams Build Physical World Context with Wherobots AI built on documents, databases, and operational logs cannot see what geography does to your infrastructure. Wherobots closes that gap: wildfire risk assessment, renewable energy site selection, vegetation management, and grid modernization analytics, powered by the physical world data behind every asset in your territory. Slow wildfire risk analysis Complex renewable siting Limited grid visibility Siloed infrastructure data Manual transmission planning Slow wildfire risk analysis Industry Problem Why Wildfire Risk Analysis Takes Days or Weeks Assessing wildfire ignition probability and vegetation encroachment across thousands of miles of transmission lines takes days or weeks with traditional GIS tools, delaying critical mitigation decisions during high risk seasons. Wherobots solution How to Analyze Wildfire Risk 90% Faster Wherobots analyzes vegetation proximity, weather patterns, historical ignition data, and infrastructure conditions across your entire infrastructure territory in minutes instead of days. The platform processes raster and vector data together to identify high-risk zones requiring immediate attention, delivering 90% faster risk identification than traditional approaches.. 90% Faster Risk ID Complex renewable siting Industry Problem Why Renewable Site Selection Delays Clean Energy Deployment Evaluating optimal locations for utility-scale solar and wind projects requires analyzing multiple factors including solar radiation, wind patterns, land use, topography, environmental constraints, and grid proximity—a time-intensive process that delays clean energy deployment. Wherobots solution Accelerated Solar Site Selection Wherobots processes terabytes of satellite imagery, solar radiation data, meteorological records, and environmental constraint layers to identify and rank optimal sites for utility-scale solar and wind projects. Solar site selection that evaluates thousands of potential locations simultaneously, considering transmission proximity and hosting capacity, in hours instead of months. Millions of Sites Analyzed/minute Limited grid visibility Industry Problem Why Inaccurate Asset Data Prevents Real-Time Grid Capacity Decisions Inaccurate asset locations, incomplete spatial data assets, and batch updates to network models prevent energy teams from making real-time decisions about grid capacity, DER integration, and infrastructure investments. Wherobots solution How to Create a Spatial Digital Twin of Grid Infrastructure Create a comprehensive spatial digital twin of your infrastructure. Process billions of asset records, network topology data, and real-time sensor feeds to maintain an always-current view of grid and field conditions and capacity across all capacity levels. 100% Real-time Grid View Siloed infrastructure data Industry Problem Why Disconnected GIS, SCADA, and AMI Systems Make Predictive Maintenance Difficult Critical asset information exists in disconnected systems including GIS, SCADA, AMI, and work management platforms—making it difficult to correlate spatial data with operational performance for predictive maintenance and capital planning. Wherobots solution How to Unify Spatial Data Using 300+ Spatial SQL Functions Unify spatial data from multiple sources in Wherobots Cloud. Join asset records with real-time operational data, outage history, and maintenance records using Spatial SQL. WherobotsDB’s 300+ spatial functions cover vector and raster data, with native Spark SQL for tabular operations. 300+ Spatial Functions Manual transmission planning Industry Problem Why Manual Transmission Corridor Planning Takes Months and Bottlenecks Grid Expansion Planning new transmission corridors requires analyzing right-of-way constraints, environmental impacts, population density, and existing infrastructure across vast geographic areas—a months-long process that bottlenecks grid expansion projects Wherobots solution How to Evaluate Thousands of Transmission Routes Simultaneously Evaluate thousands of potential transmission routes simultaneously by analyzing terrain, land use, environmental constraints, and cost factors. Wherobots processes multi-terabyte raster datasets representing elevation, land cover, protected areas, and infrastructure to identify optimal corridors. 90% Time Savings “We’ve added ten times more data than earlier versions of this concept, and we can now do things with AI and on-demand analytics that have never been done before.” Eric Pollard CEO, ParGo See How Energy Teams Build AI That Sees Their Infrastructure Schedule a demo to see how leading energy companies process billions of asset records, assess wildfire risk at scale, and build the physical world context layer behind smarter grid decisions. REQUEST A DEMO Energy & Utility Resources: Technical Examples and Case Studies Explore use cases, code examples, and webinars showing how energy companies solve wildfire risk, renewable siting, and infrastructure challenges with spatial analytics How to Detect Solar Panels in Satellite Imagery with Wherobots Learn how to extract solar panel locations from satellite and aerial imagery using SQL or Python with open-source machine learning models—useful for competitive analysis and renewable asset mapping. LEARN MORE Raster Data Processing Benchmark: Wherobots vs Google Earth Engine vs BigQuery Compare performance for raster operations, spatial joins at scale, and running Earth observation models across three leading geospatial platforms. READ MORE RasterFlow for Planetary-Scale Earth Intelligence See how RasterFlow bridges AI and physical world data to accelerate Earth observation analysis for energy and utility applications. WATCH NOW Frequently Asked Questions How does Wherobots handle billions of utility infrastructure data points at scale? WherobotsDB runs distributed spatial SQL across cloud clusters, processing petabytes of asset records, sensor data, and satellite imagery without moving data out of your cloud storage. Compute scales to workload size. Energy teams write spatial SQL and Python against their existing infrastructure data directly. Grid capacity analyses, vegetation proximity assessments, and transmission corridor evaluations that previously required overnight batch runs complete in minutes. What deployment options does Wherobots offer for energy and utility companies? Wherobots connects to AWS cloud storage, Databricks, and any Apache Iceberg catalog. Your data stays in place. Wherobots runs compute against it without migration or format conversion. Energy and utility companies with regulatory or data residency requirements can deploy as a managed cloud service, bring-your-own-cloud, or in a dedicated VPC. Wherobots is SOC 2 Type 2 attested. How much faster is Wherobots than traditional GIS for grid analytics and wildfire risk assessment? Traditional GIS platforms process spatial datasets on single machines and hit hard compute limits at the data volumes modern grid and wildfire analytics demand. WherobotsDB delivers up to 3x faster analytical queries and up to 2.5x faster spatial queries compared to the previous generation, with up to 45% better price performance. In practice, wildfire risk assessments across thousands of miles of transmission lines that previously took overnight complete in under an hour. Renewable site scoring that previously required days completes in hours. Can Wherobots process both vector and raster data for energy and utility applications? WherobotsDB processes vector data (asset locations, parcel boundaries, transmission corridors, land use polygons) and raster data (satellite imagery, elevation models, solar radiation grids, vegetation indices) in the same platform. RasterFlow runs computer vision models on satellite imagery at scale, enabling workflows like vegetation encroachment detection along transmission lines and land parcel classification for solar site selection. Both data types participate in the same spatial SQL queries, so energy teams do not need separate tools for different data formats. How quickly can energy teams see results from Wherobots? Most energy teams run a proof-of-concept in 2-4 weeks focused on a specific use case: wildfire risk mapping, renewable site scoring, or hosting capacity analysis. Wherobots is code-compatible with Apache Sedona, so existing Sedona SQL or Python workflows run on Wherobots without rewriting. WherobotsDB provides 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations, and a managed notebook environment for fast iteration. Is Wherobots suited for real-time utility data processing? Wherobots is optimized for analytical workloads: processing large volumes of spatial data for grid capacity modeling, wildfire risk assessment, and infrastructure planning. For operational systems requiring sub-second response times, Wherobots handles the computationally intensive spatial analytics and ETL pipelines that feed into those real-time systems. Daily vegetation monitoring, hourly hosting capacity updates, and scenario analysis for grid expansion are where Wherobots delivers the most value. Get started Ready to learn more about how Wherobots can transform your energy workflows? REQUEST A DEMO START BUILDING --- ## Communication Service Providers URL: https://wherobots.com/solutions/communication-service-providers/ Updated: 2026-10-12 Live map app Physical World Context for Communications Service Providers Wherobots gives communication service providers the physical world context layer for telecom analytics at scale. The map shows where mobile service in California is slow, and why: 79.9% of slow areas near a tower have a clear line of sight. Explore the signal map Request a demo 2,854 slow areas within 2 km of a tower 79.9% of those have a clear line of sight 1.51M people in capacity-limited areas San Francisco Bay Area, California Share of measured service that is underserved under 10% 10-25% 25-50% 50-75% 75% or more not measured Of 2,854 slow areas within 2 km of a tower, 2,281 (79.9%) have a clear line of sight: a capacity problem. Speed tests: Ookla Open Data. Towers and buildings: Overture Maps. Terrain: Copernicus. Canopy: Meta. Population: US Census ACS. Analysis: Wherobots. Basemap: OpenFreeMap, OpenMapTiles, OpenStreetMap contributors. Telecom Companies Trusting Wherobots and Apache Sedona Why Telecom Teams Build Physical World Context with Wherobots Your AI reads subscriber records and network logs. It does not understand how geography shapes coverage, capacity, and churn. Wherobots closes that gap with the spatial AI infrastructure to process billions of network events, score tower sites, and turn physical world data into competitive advantage. Network coverage blind spots IoT data explosion Infrastructure silos Site acquisition delays Regulatory reporting burden Network coverage blind spots Industry Challenge How Telecoms Lose Visibility Into Network Coverage Gaps Telecoms struggle to identify coverage gaps and quality issues when billions of call detail records exceed traditional GIS capabilities. AI systems reasoning over network logs alone miss the geographic patterns driving these failures. Wherobots Solution Geospatial AI for Coverage Gap Detection Wherobots gives network operations teams geospatial AI to detect coverage gaps, predict congestion hotspots, and optimize capacity using spatial SQL and Python, at a scale no traditional GIS or analytics tool matches. 10B+ Events Processed IoT data explosion Industry Challenge Why Legacy Systems Fail to Process Millions of IoT Device Streams Managing millions of connected devices—including 5G-connected vehicles, smart meters, and industrial sensors—generates continuous location streams and terabytes of location data hourly that legacy systems can’t process, limiting smart city and fleet management capabilities, preventing real-time network optimization and usage-based service offerings. Wherobots solution How Wherobots Processes Millions of IoT Streams for Connected Services Handle data streams from millions of IoT devices efficiently enabling instant insights for connected services. Millions of IoT Streams Processed Infrastructure silos Industry Challenge Why Disconnected Telecom Spatial Data Limits Network Performance Network asset data, customer locations, competitor sites, spectrum allocation, fiber routes, equipment inventory, and terrain models remain disconnected when platforms can’t efficiently integrate diverse spatial datasets at petabyte scale. This requires manual data reconciliation, wastes weeks on data preparation, and delays network planning decisions.. Wherobots solution How Wherobots Unifies Telecom Spatial Assets on a Single Apache Iceberg Platform Consolidate all geospatial assets, from network infrastructure and elevation data to customer locations and competitor sites, on a single Apache Iceberg-based platform. WherobotsDB provides 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations, creating a unified physical world context layer for network intelligence. 300+ Spatial Functions Site acquisition delays Industry Challenge Why Manual Tower Site Selection Takes Months for Telecoms Evaluating potential tower sites against zoning, terrain, population, and competitor locations involves manual workflows that stretch site selection to months. Wherobots solution How Wherobots Scores Thousands of 5G Tower Sites Against Spatial Criteria in Seconds Continuously evaluate thousands of candidate locations against multiple spatial criteria simultaneously, ranking sites by coverage potential and ROI in seconds. 99% Faster Selection Regulatory reporting burden Industry Challenge Why FCC Broadband Map Reporting Takes Weeks to Prepare Generating FCC broadband maps and coverage reports requires weeks of data preparation when combining network models with census blocks and address points. Wherobots solution How Wherobots Automates FCC Coverage Reporting with Demographic Boundary Processing Generate regulatory coverage reports automatically by processing network data against demographic boundaries in automated Wherobots Jobs. Automated Compliance “It’s not just about mapping—it’s about causation. Apache Sedona helps us identify whether spatial factors are actually driving customer issues. That difference completely changed how fast we could iterate” David Buchanan Data Engineer, Manager, Comcast See How Telecom Teams Build AI That Sees Their Network Schedule a demo to see how leading CSPs process billions of spatial data assets and build the physical world context layer that turns network data into competitive intelligence. REQUEST A DEMO Telecom Analytics Resources and Case Studies Get up to speed on the latest innovations in Telco. Telco Network Analysis Webinar: County to Country-Scale Bandwidth Optimization Learn how communication service providers analyze bandwidth constraints and network capacity across geographic regions, from county-level coverage gaps to nationwide 5G deployment planning. WATCH NOW Wherobots SOC 2 Type 1 & Type 2 Compliance Certification Wherobots achieved SOC 2 Type 1 and Type 2 attestation, demonstrating enterprise-grade security controls, data privacy protection, and compliance readiness for telecommunications companies with strict regulatory requirements. LEARN MORE From 5 Hours to 30 Minutes: Comcast's Apache Sedona Success Story Discover how Comcast, one of the largest communication service providers in the US, reduced spatial data processing time from 5 hours to 30 minutes using Apache Sedona. COMCAST STORY Frequently Asked Questions: Wherobots for Telecom and 5G Networks How does Wherobots process telecom data at the scale communication service providers require? WherobotsDB runs distributed spatial SQL across clusters, processing petabytes of network events against geographic boundaries, coverage polygons, and terrain data. Compute scales to workload size, so billion-record CDR queries complete in minutes. Data stays in your cloud storage. Wherobots runs queries against it without migration or movement. Can Wherobots connect to our existing network data infrastructure? Wherobots connects to AWS cloud storage, Databricks, and any Apache Iceberg catalog. Your data stays in place. Wherobots runs compute against it without migration or format conversion. For CSPs with compliance or data residency requirements, managed cloud, bring-your-own-cloud, and VPC deployment options are available. Wherobots is SOC 2 Type 2 attested. What makes Wherobots better suited for 5G network planning than traditional GIS? Traditional GIS tools were not designed for the data volumes that 5G network planning demands. AI systems built on network logs and subscriber records miss the geographic dimension entirely. Evaluating tower sites against population density, terrain, spectrum coverage, existing infrastructure, and competitor locations requires joining multiple large spatial datasets in one query. WherobotsDB handles those joins at scale with 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations. Network planning workflows that take hours in conventional tools complete in minutes. How quickly can telecom teams see results from Wherobots? Most teams run a proof-of-concept in 2-4 weeks focused on a specific use case: CDR analysis, coverage gap detection, or tower site scoring. Processing workflows that previously took days in legacy tools complete in minutes on Wherobots. WherobotsDB is 3x faster than the previous generation with up to 45% better price performance. Does Wherobots support both vector and raster data for network analysis? WherobotsDB processes vector data (network infrastructure, coverage polygons, customer locations, competitor sites) and raster data (satellite imagery, elevation models, signal strength grids) in one platform. RasterFlow runs computer vision models on aerial and satellite imagery at planetary scale. Both data types participate in the same spatial queries, so network operations teams do not need separate tools for different data formats. How does Wherobots support FCC broadband mapping and regulatory reporting? Wherobots processes network coverage data against census blocks, address points, and demographic boundaries in automated spatial SQL workflows. FCC broadband map generation, which requires cross-referencing network models with fabric data at national scale, runs as a scheduled Wherobots Job. Regulatory reporting that previously required weeks of manual data preparation runs on a defined schedule. Get started Ready to give your network AI physical world context? REQUEST A DEMO START BUILDING --- ## Aerospace URL: https://wherobots.com/solutions/aerospace/ Updated: 2026-10-06 Physical World Context for Aerospace & Earth Observation AI systems built on documents, databases, and the internet miss the physical world entirely. Wherobots gives aerospace teams the context layer for satellite imagery analysis at petabyte scale: process sensor data, run computer vision models, and turn Earth observation data into answers your AI stack can act on. Up to 20x faster than legacy pipelines. REQUEST A DEMO Companies Accelerating Outcomes with Wherobots and Apache Sedona Why Aerospace Teams Build Physical World Context with Wherobots Your AI reads documents, databases, and structured data. It does not see the physical world. Wherobots closes that gap for aerospace: satellite image analysis at petabyte scale, unified raster-vector processing, and AI inference that turns imagery into intelligence. Overwhelming data volumes Detection bottlenecks Preprocessing delays Fragmented analytics stack Multi-sensor data integration Overwhelming data volumes Industry Problem Overwhelming data volumes Aerospace teams manage 100+ petabyte satellite imagery archives growing by 80-100TB daily. Traditional satellite imagery processing pipelines bottleneck at scale, delaying insights by hours or days. AI systems that reason only over documents and databases cannot touch this data without a physical world context layer. Wherobots solution Planetary-scale processing Wherobots processes petabyte-scale satellite imagery archives with distributed geospatial analytics that scale automatically. Raster and vector datasets across entire satellite constellations, processed without infrastructure management, and ready to feed AI systems with physical world context. 100+ PB Processing Capacity Detection bottlenecks Industry Problem Change detection bottlenecks Monitoring environmental changes, infrastructure development, or disaster impacts from satellite imagery requires comparing billions of pixels across time. Traditional GIS and Earth observation platforms collapse under this load. Without spatial AI, these signals stay trapped in raw imagery. Wherobots solution Distributed change detection Wherobots executes pixel-level change detection and semantic segmentation across global satellite imagery stacks. Distributed geospatial AI identifies land cover changes, deforestation, and infrastructure development at continental or planetary scale, converting raw pixels into structured physical world context. 10× Faster Analysis Speed Preprocessing delays Industry Problem Preprocessing delays Raw satellite data requires atmospheric correction, orthorectification, radiometric calibration, and cloud masking before analysis, creating processing pipelines that take days to deliver analysis-ready data. Wherobots solution Streamlined data preparation Build efficient ETL pipelines for satellite imagery and Earth observation preprocessing using distributed Spatial SQL and Python. Transform raw imagery to analysis-ready geospatial datasets at scale with minimal configuration. ETL Time Days → Min Fragmented analytics stack Industry Problem Fragmented analytics stack Earth observation teams juggle separate tools for satellite imagery raster processing, vector analysis, ML inference, and geospatial data cataloging. No single platform provides the spatial AI infrastructure to unify these operations. Wherobots solution Unified geospatial platform Wherobots unifies raster and vector processing, spatial analytics, and ML inference in one environment. RasterFlow runs computer vision models on satellite imagery at scale. WherobotsDB’s 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations, give teams a single platform for every geospatial AI workflow. 1 Platform Tools Unified Multi-sensor data integration Industry Problem Multi-sensor data integration is difficult Aerospace systems generate diverse satellite data from aircraft sensors, navigation systems, and Earth observation satellite constellations in varying formats that are difficult to integrate and analyze together for geospatial intelligence. Wherobots solution Multi-format data integration made easy Process and join satellite imagery and Earth observation data from multiple satellites, sensors, and formats. Wherobots Global Hub provides a unified view of all geospatial datasets with Apache Iceberg-based data lakehouse architecture. 50+ Formats Unified “The combination of speed, scalability, and ease of integration has boosted our engineering productivity and will accelerate how quickly we can deliver new geospatial data products to market.” Rashmit Singh CTO & Co-founder, SatSure See How Aerospace Teams Build AI That Sees the Physical World Schedule a demo to see how aerospace and Earth observation teams process petabytes of satellite imagery, run AI inference at scale, and build the physical world context layer their AI systems need. TALK TO US Explore Our Resources for Aerospace & Earth Observation Learn about satellite imagery processing innovations, Earth observation best practices, and geospatial analytics advancements for aerospace companies. Raster Data Joins at Scale Compare Wherobots with Google Earth Engine and BigQuery for satellite imagery raster operations, geospatial joins at scale, and running Earth observation models. LEARN MORE Introducing RasterFlow: Satellite Imagery Processing Engine for Earth Observation RasterFlow is a serverless satellite imagery preparation and inference engine that makes it significantly easier to process and analyze planetary-scale Earth observation datasets and generate geospatial intelligence. LEARN MORE Webinar: RasterFlow for Planetary-Scale Satellite Imagery and Earth Observation How RasterFlow works and why you should consider it for planetary-scale Earth observation models that you want to run instantly. WATCH NOW Frequently Asked Questions About Satellite Imagery Processing for Aerospace and Earth Observation How does Wherobots handle petabyte-scale satellite imagery archives? Wherobots leverages a modern data lakehouse architecture built on Apache Iceberg and cloud object storage. Your satellite imagery stays in cost-effective cloud storage while WherobotsDB provides distributed query processing for geospatial operations. The platform scales automatically to handle queries across petabytes of satellite data, and you only pay for compute when processing jobs run. What are the typical deployment options for Wherobots for aerospace companies? We deploy as a managed cloud service. But we also have options for bring-your-own-cloud and VPC. Can Wherobots process both raster imagery and vector geospatial data? Yes. Wherobots provides unified support for both raster and vector geospatial data in a single platform. WherobotsDB includes over 300 spatial functions covering geometry operations, raster analytics, and spatial joins. You can combine vector map data with satellite imagery and Earth observation analysis in the same SQL query or Python workflow, eliminating the need for multiple specialized tools. How does RasterFlow help with satellite imagery analysis? RasterFlow is Wherobots’ serverless inference engine for Earth observation. It runs computer vision models, including semantic segmentation, object detection, and classification, on satellite imagery at scale. Write a SQL query or Python script to detect buildings, roads, or land cover types across millions of satellite images. RasterFlow handles distributed model inference, mosaicking, and vectorization automatically. What makes Wherobots faster than traditional aerospace and Earth observation processing pipelines? Wherobots incorporates multiple performance optimizations: proprietary spatial indexing techniques, query optimization for geospatial operations, distributed parallel processing, and efficient I/O with cloud storage. These deliver up to 20x faster execution compared to processing the same workloads with general-purpose data platforms. Faster satellite imagery processing means quicker time-to-insight and lower compute costs. Does Wherobots work with our existing aerospace data infrastructure? Yes. Wherobots integrates with cloud data platforms including AWS, and can connect to data warehouses like Snowflake and Databricks. The platform is built on Apache Sedona APIs, providing compatibility with standard geospatial workflows. You can start with a subset of your data for pilot projects while keeping existing systems operational. Get started Ready to give your AI physical world context? REQUEST A DEMO START BUILDING --- ## Introducing RasterFlow: a planetary scale inference engine for Earth Intelligence URL: https://wherobots.com/blog/rasterflow-earth-observation-inference-engine/ Updated: 2026-10-19 We’re very excited to announce RasterFlow is now available to select customers in a private preview. If you are interested in learning more or would like to request access to the preview, contact us here! Key takeawaysRasterFlow is a serverless imagery-preparation and inference engine, now in private preview. It turns planetary-scale Earth Observation datasets into Earth Intelligence without customers having to build their own mosaicking and model-serving stack.Working with the Taylor Geospatial Engine, RasterFlow ran Fields of the World inference across CONUS, Japan, Mexico, South Africa, Switzerland, and Rwanda. Those large-scale workflows completed in minutes to a few hours as compute autoscaled with area, time range, dataset density, and model complexity.It ingests Zarr and Cloud-Optimized GeoTIFF imagery. It hosts PyTorch models including FTW field boundaries, Meta/WRI tree canopy height, ChesapeakeRSC road segmentation, and Tile2Net pathway segmentation, and lets organizations import their own private PyTorch models.Predictions are vectorized into geometries and written as Parquet files in Apache Iceberg tables in the customer S3 bucket. They are then post-processed in WherobotsDB or other lakehouse engines such as Databricks, Snowflake, or BigQuery.Gartner projects that only 1% of AI models leverage physical-world data today versus 80% by 2029. AI agents are projected to generate 10 times more data from physical environments than from all digital AI applications combined.One of the largest RasterFlow deployments processed 348 TB of satellite imagery for a global release. RasterFlow is a serverless image preparation and inference engine that makes it significantly easier to generate Earth Intelligence from planetary scale Earth Observation (EO) datasets. With it, customers and their AI agents will be significantly more capable of innovating with EO data and integrating earth insights into their data infrastructure. Upcoming Session: See an AI agent take plain-language question and orchestrating pipelines to end results using RasterFlow and the Wherobots MCP server. See it in action Join us live How RasterFlow Powers Earth Intelligence at Scale A few weeks ago, we announced our collaboration with the Taylor Geospatial Engine to help them evaluate their Fields of the World (FTW) machine learning model that segments agricultural field boundaries. Using an early release of RasterFlow, we were able to quickly and cost-effectively run this model at scale. Here’s a breakdown of how this works in practice. RasterFlow ingests and assembles the source imagery – in this case Sentinel-2 – into an inference-ready mosaic, generating representative features using the FTW model for planting and harvest seasons, and removing cloud cover as needed (1, 2). The FTW model is run against this mosaic using RasterFlow’s distributed inference engine to predict fields and field boundaries (3). RasterFlow predictions are then vectorized into geometries and made available as an Iceberg table (4) that can be used in WherobotsDB or other downstream applications and data systems for field-level crop insights. RasterFlow’s applicability is much wider than Sentinel 2 and FTW. It supports Zarr and COG imagery datasets and PyTorch computer vision models for inference. RasterFlow at Scale The images above represent sample outputs for a small area in Kansas, but RasterFlow can be very attractive for larger scale runs.  In our collaboration with the Taylor Geospatial Engine, we executed larger scale runs including the Continental United States (CONUS), Japan, Mexico, South Africa, Switzerland and Rwanda.  RasterFlow’s efficient parallel processing enabled each of these large scale workflows to complete in minutes to a few hours.  RasterFlow autoscales compute resources based on expected compute and inference load, which is a function of area and time range, dataset density, and model complexity. Challenges using EO Data Most data teams do not have the expertise or the budget to build and operate the unique infrastructure and software stack required to extract insights from EO datasets using computer vision models. These barriers have prevented innovative ideas from getting off the ground. According to Gartner, only 1% of AI models today leverage physical world data, vs a projected 80% by 2029. Similarly, AI agents are projected to generate 10 times more data from physical environments than from all digital AI applications combined.1 However, AI agents can’t economically make sense of this raw data because it has to be prepared by the same costly, complex, and unique infrastructure the data teams need, but neither have access to. Here’s an example that underscores these challenges: if you or an AI agent are trying to analyze wildfire state and predicted spread to measure risk to infrastructure, developers typically need to build dedicated pipelines that: Ingest and prepare imagery for inference, minimizing noise such as cloud cover and edge effects Deploy a machine learning model on prepared imagery, trained to segment and classify fires Tune model inference for scale and efficiency, while minimizing edge and tiling effects from individual tasks Measure change over time using models that take into account wind direction, speed, vegetation, buildings and other infrastructure in the probable path of the fire Join model predictions with other important context including building footprints, land parcels and infrastructure such as powerlines and pipelines to calculate overall risk Forecast the spread of the fire In total, these steps require significant investments in both infrastructure development, operations, and talent that most businesses are unable to justify, much even accomplish. On-Demand Imagery Preparation and Inference for Earth Observation Workflows The inspiration for RasterFlow was to make it easy for any company to use large scale sensor datasets and computer vision models to unblock innovation and AI applications for the physical world. RasterFlow does this by combining decades of expertise with a fully managed, inference and mosaicking workflow and API designed for Earth Intelligence at any scale. Here are a few key capabilities: On-demand serverless operations for imagery ingestion, preparation (also known as mosaicking), and inference. Built-in support for popular open datasets and open models so you can get started quickly. Inference results that can be converted to vector geometries and integrated into a lakehouse architecture; in a customer’s cloud storage bucket as Parquet files in Apache Iceberg tables. Ability to easily postprocess these results with WherobotsDB or other lakehouse engines with support for spatial operations, such as Databricks, Snowflake, or Google BigQuery. Simple enough for any engineer, scientist, or analyst to use: just pick a model, an area of interest to deploy that model, and a time range. Advanced users can take advantage of lower-level APIs to customize their planetary-scale inference runs. RasterFlow Operators: Core Functions for Preparing Imagery, Model Inference, and Vectorization RasterFlow provides fully managed operations required for processing Earth Observation datasets, including: Imagery ingestion and preparation to remove cloud cover, edge effects, and build a high quality inference-ready mosaic Distributed inference for large scale computer vision, geospatial foundational and other PyTorch model runs Vectorization of model outputs into geometries or as analytics ready rasters For object detection workloads, RasterFlow pairs with models like Segment Anything 3, see how SAM 3 performs on aerial and satellite imagery for a full walkthrough. Ingesting and Preparing Satellite Imagery for Model Inference Satellites and drones capture imagery on a particular flight path. And it may take multiple drone flights, or days, weeks, or even months for the flight paths of a satellite constellation to capture clean imagery for a particular area of interest. Clouds and weather events may still block what you may be interested in. In these circumstances it’s important to understand the rate of coverage and define your time horizon accordingly, to build a mosaic. A mosaic is a composite image that is the result of composing high-quality pixels (e.g., cloud free) over a time range, and stitching them together for a particular area. Base satellite layers in your favorite map applications (Google Maps, Mapbox) are cloud-free mosaics composed from images over a wide time range. Many computer vision models are trained to find relatively durable things on Earth, like buildings, roads, and land cover. But when clouds, coverage, imagery edge effects, or other types of “noise” exist in the input imagery, the quality of inference suffers. The purpose of the mosaic is to correct for this noise and make imagery, inference-ready, so model inference produces the results you want. RasterFlow takes care of this heavy lifting for you, creating an inference-ready mosaic that maximizes the usefulness of today’s Earth Observation models. Distributed Geospatial Inference at Planetary Scale We’ve moved past the use of eyes to analyze imagery, and are now capable of letting machines do this work for us. With RasterFlow, today’s machine learning models can perform tasks such as object detection, segmentation, and classification, on a very large area of interest, with orders of magnitude more efficiency and scale than an analyst’s eyes can offer. The RasterFlow inference engine is designed for small to very large scale runs. It efficiently parallelizes across the input mosaic across a distributed and serverless inference architecture while minimizing tiling effects typically produced when inference pipelines operate on individual tiles. Running Hosted or Custom Geospatial AI Models with RasterFlow For convenience, RasterFlow currently hosts popular open source PyTorch geospatial computer vision models that are ready to use. These models currently include: Fields of the World (FTW) Field Boundary Delineation Meta and World Resource Institute Tree Canopy Height Prediction ChesapeakeRSC Road Segmentation Tile2Net Pathway Segmentation You can also import your own custom PyTorch model to your Wherobots Organization for private deployment. RasterFlow + TorchGeo: Simplifying PyTorch-Based Geospatial AI Wherobots actively supports the TorchGeo project which helps machine learning experts to more easily work with geospatial data within the PyTorch ecosystem.  We will continue to build out RasterFlow integrations with TorchGeo, including onboarding additional TorchGeo models and further simplifying the model lifecycle for PyTorch models. While we are starting with support for PyTorch focusing on TorchGeo models, we are open to adding support for other model frameworks. Calling Geospatial Model Developers: Contribute to RasterFlow We are continually adding new, open source geospatial computer vision models to the Wherobots Model Hub. And if you’re a model developer, we’re interested in speaking with you to onboard your model and distribute the value of your work to a wider audience using Wherobots RasterFlow. Vectorizing Model Outputs: From Raster Predictions to Geospatial Geometries Many computer vision models output rasters, where each pixel in the raster represents a predicted real-world value such as height of the tree canopy, or the confidence that the pixel represents a certain feature such as an agricultural field boundary or a sidewalk. RasterFlow provides built-in support for raster vectorization, turning pixel values into rich, concise geometries. These geometries represent features of interest that can be post-processed, conflated, and integrated into your workflows because they are yours, stored in open source file (Parquet) and table (Iceberg) formats in your S3 bucket. Using RasterFlow with Geospatial Foundation Models and Embeddings Recent developments in Geospatial Foundation Models have generated tremendous interest in the research community, potentially accelerating Earth Observation applications the same way that Large Language Models (LLMs) and embeddings have transformed AI’s ability to generate language. RasterFlow can generate embeddings from the latest open Geospatial Foundation Models, including OlmoEarth from the Allen Institute for AI (Ai2) and Clay.  With RasterFlow’s ability to cost-effectively generate embeddings at scale, researchers and practitioners can easily generate embeddings for their area of interest and evaluate their suitability and power. Customers and Partners Using RasterFlow for Scalable Earth Intelligence One highlight while developing RasterFlow has been our collaboration with customers and partners like SatSure, Taylor Geospatial Engine, and Spyrosoft. We’ve used feedback from these teams to ensure we are solving for customer needs. Before the Thanksgiving holiday we shared our recent learnings from working together with Taylor Geospatial Engine, who have been incredibly helpful in providing input on the types of ways their ecosystem of developers and ML engineers would want to interact with RasterFlow. SatSure is an existing Wherobots customer and an early adopter of RasterFlow, and we are excited to see what they build next with it. "RasterFlow meaningfully accelerates the work SatSure and Wherobots already do together. By automating mosaicking, preprocessing, and distributed inference into a single, on-demand workflow, it removes much of the engineering overhead required to operationalize our models at national and multi-season scale. This helps us move new geospatial AI models into production faster, iterate more quickly with customers, and deliver fresher, high-resolution insights across agriculture, banking and financial services, and infrastructure use cases." Rashmit Singh CTO and co-founder, SatSure One of the largest deployments to date processed 348 TB of satellite imagery for a global release, see how RasterFlow delivered Fields of the World at planetary scale RasterFlow Availability and Multi-Cloud Architecture Wherobots infrastructure runs natively on AWS and customers pay for use through the AWS marketplace. RasterFlow and WherobotsDB support hybrid architectures, where data is read from, and results are written to other environments such as GCP, Azure, Oracle, or on-premises. This is particularly useful when processing open datasets or using open models and the environment in which data is processed may not be a concern. On-demand pricing for RasterFlow will be announced at a later date, but can be discussed with customers participating in the private preview. Next Steps: Try RasterFlow and Explore the Wherobots Spatial Data Platform We invite anyone who wants to test out RasterFlow to request to join the private preview here. Get started building with the most capable and efficient spatial data platform using the Wherobots Professional Edition. Sign up for the newsletter to keep pace with what’s happening at Wherobots. Join the Private Preview Sign Up Frequently Asked Questions What is RasterFlow? RasterFlow is Wherobots serverless engine for ingesting and mosaicking Earth Observation imagery, running distributed PyTorch computer-vision inference, and vectorizing results into Iceberg tables. It is available to select customers in private preview. Which imagery formats and models does RasterFlow support? It supports Zarr and COG datasets and PyTorch geospatial models. Hosted models currently include Fields of the World field-boundary delineation, Meta and World Resources Institute tree canopy height, ChesapeakeRSC road segmentation, and Tile2Net pathway segmentation. You can also import a custom PyTorch model into your Wherobots organization. How are RasterFlow inference results stored? Model outputs can be vectorized into geometries or kept as analytics-ready rasters, and written as Parquet files in Apache Iceberg tables in your own S3 bucket. They can then be joined and analyzed with WherobotsDB or other spatial-capable lakehouse engines. How do I try RasterFlow? Request access to the private preview from Wherobots. On-demand pricing will be announced later and can be discussed with preview participants. Wherobots infrastructure runs natively on AWS via the AWS Marketplace, with hybrid read/write to GCP, Azure, Oracle, or on-premises. --- ## RasterFlow Preview URL: https://wherobots.com/rasterflow-preview/ Updated: 2026-07-13 Sign up for the RasterFlow Private Preview Looking to run geospatial ML models at scale on satellite and aerial imagery? We’re inviting select developers to try RasterFlow and shape the future of our product. With the Private Preview, you’ll be able to: Generate Inference-Ready Mosaics Seamlessly create mosaics from our built-in datasets (Sentinel-2, NAIP) or your own Cloud Optimized GeoTIFFs. Run Earth Observation Models at Scale Execute segmentation and regression models on imagery: Use leading open models including: Field Boundary Segmentation (Fields of the World) Canopy Height Estimation (Meta/WRI Canopy Height) Rural Road Segmentation (ChesapeakeRSC) Sidewalk Segmentation (Tile2Net) Or, bring your own PyTorch models Vectorize and Post-Process Convert model outputs to geometries for further analysis and refinement in WherobotsDB. Sign Up Today This is an early preview with limited availability. We’re looking for developers interested in inference at scale and willing to provide feedback and shape the future of this product. We’ll schedule onboarding sessions with our experts to ensure your success! --- ## Wherobots and Taylor Geospatial Engine Bring Fields-of-the-World Models to Production Scale URL: https://wherobots.com/blog/fields-of-the-world-taylor-geospatial-engine-agricultural-ai/ Updated: 2026-10-19 Agriculture depends on timely, reliable insight into what’s happening on the ground—what’s being planted, what’s being harvested, and how fields evolve over time. The Fields of The World (FTW) project was created to support exactly this mission, by building a fully open ecosystem of labeled data, software, standards and models to create a reliable global map of agricultural field boundaries using AI and Earth Observation (EO) data. Key takeawaysWherobots partnered with the Taylor Geospatial Engine to turn Fields of the World (FTW) Phase 2 research models into operational, production-scale agricultural field-boundary pipelines. The models are state-of-the-art computer vision on Sentinel-2 time-series imagery.The first public release includes cloud-free Sentinel-2 seasonal mosaics for planting and harvest seasons plus per-pixel FTW Phase 2 model predictions aligned with FTW agricultural labeling standards.Both datasets are openly available on Source Cooperative at source.coop/wherobots/fields-of-the-world.Microsoft AI for Good researcher Caleb Robinson notes that Wherobots can mosaic multi-season Sentinel-2 imagery over millions of square kilometers. It can run the models and organize outputs in minutes for a few hundred dollars.The Spatial Intelligence Cloud builds analysis-ready mosaics, runs distributed GPU inference, and writes results to cloud-native formats such as Zarr. Teams can then refine field geometries or calculate vegetative indices in WherobotsDB with Apache Sedona. Over the past several months, Wherobots has been working closely with the Taylor Geospatial Engine (TGE) team driving the FTW project to turn high-performing research models into operational, production-scale data products. This collaboration builds on TGE’s broader effort to accelerate AI & EO development through connecting cutting edge research to real world needs. Learn more about FTW at fieldsofthe.world and about TGE’s agricultural AI initiatives here. Turning Fields-of-the-World Research Models Into Operational Pipelines FTW Phase 2 surfaced state-of-the-art computer vision models for interpreting Sentinel-2 time-series imagery and predicting locations of agricultural fields. But, research models alone aren’t enough to deliver real agricultural insight. They must be reproducible at scale, compute-efficient, and aligned with downstream applications. This is where Wherobots focused its efforts: optimizing inference pipelines, distributing computation efficiently, and generating data products that can serve as reliable foundations for agricultural modeling, monitoring, and analysis. TGE’s objective was simple: transform breakthrough research into something developers, end-users, and organizations can actually use. "This project is a testament to what happens when the academic community, nonprofits, and industry all pull in the same direction… Wherobots' ability to run these open-source models at scale makes it possible for the community's work to reach a global audience, and open access to predictions and mosaics ensures that more researchers and innovators can build on top of it." Jennifer Marcus Executive Director, Taylor Geospatial Engine Open-Sourced Seasonal Mosaics and Model Predictions Today, we’re releasing the first production-scale outputs from this collaboration: Sentinel-2 Seasonal Mosaics Cloud-free, analysis-ready mosaics tailored to key agricultural seasons—planting and harvest—built from Sentinel-2 imagery. These mosaics provide a consistent, high-quality foundation for model training, monitoring workflows, and large-scale geospatial analysis. FTW Phase 2 Model Predictions Per-pixel prediction outputs generated by running the top-performing FTW Phase 2 model across these seasonal mosaics, aligned with FTW’s agricultural labeling standards. Expand for caption This is an example output of the field boundary model in a large scale AOI in Japan and Mexico. The comparison is between the 2023 predictions and 2023 + 2024 in predictions (2024 in bright green). Both datasets are openly available on Source Cooperative: https://source.coop/wherobots/fields-of-the-world These resources are designed to make advanced agricultural AI more accessible—supporting innovation in food security, sustainability, and data-driven farming. The Wherobots AI for Earth team were critical in scaling inference with the new field boundary delineation models to a multi-country scale. The fact that they can mosaic multi-season Sentinel-2 imagery over millions of square kilometers, then run models over those mosaics, and organize the outputs in minutes for a few hundred dollars is nothing short of incredible. Making global scale analysis a routine pipeline instead of an enormous one-off effort, has the potential to change monitoring tasks far beyond field boundary analysis. Caleb Robinson, Principal Research Scientist, Microsoft AI for Good Enabled by the Spatial Intelligence Cloud This release also highlights the underlying engine that made it possible. The Wherobots Spatial Intelligence Cloud is built specifically for large-scale geospatial machine learning workflows—constructing analysis-ready mosaics, executing distributed model inference, and writing results into modern, cloud-native formats like Zarr with exceptional efficiency. And model outputs can be further processed and analyzed within WherobotsDB, using the power of Apache Sedona to refine the field geometries or calculate vegetative indices at scale. These capabilities are part of our suite of tools within our AI for Earth product area. Under the hood, the platform uses state-of-the-art tooling for raster processing, GPU-accelerated inference, chunk-aligned storage, and aggressive cost optimization. These choices allow us to run continental-scale pipelines at speeds and costs that would have been unimaginable even a few years ago. As agricultural AI models continue to grow in scope and resolution, this kind of infrastructure becomes essential. Our goal is to make it straightforward for teams to experiment, scale, and operationalize geospatial ML without needing to reinvent the entire data stack. One of the most important parts about what the Wherobots’ team has done is to make it easy to see where and how the model is failing. For example, the model's poor performance in Nevada and the tiling artifacts from the previous model runs led to important changes in how we should be training models. Nathan Jacobs Assistant Vice Provost for Digital Transformation, Washington University in St. Louis What’s Next This is just the beginning. We’re continuing to work with the FTW and TGE teams to expand coverage, operationalize more models, and build richer analysis-ready layers for the agricultural AI ecosystem. If you’re exploring geospatial ML, agricultural monitoring, or large-scale satellite data processing, we’re excited to see what you build with these new open datasets—and with the Wherobots AI for Earth capabilities in your pipeline. Getting in Touch about Wherobots AI for Earth If you would like to continue to stay up to date about the Wherobots AI for Earth capabilities for solving real world problems, or speak to the Wherobots team about utilizing these capabilities in production, please reach out to us here. Frequently Asked Questions What is the Fields of the World project? FTW is an open ecosystem of labeled data, software, standards, and models that aims to create a reliable global map of agricultural field boundaries from AI and Earth Observation data. Taylor Geospatial Engine leads the project; Wherobots operationalized the Phase 2 models at production scale. What data did Wherobots and TGE release? Cloud-free Sentinel-2 seasonal mosaics tailored to planting and harvest, plus per-pixel prediction outputs from the top-performing FTW Phase 2 field-boundary model run across those mosaics. Where can I download the FTW mosaics and predictions? Both resources are openly available on Source Cooperative at https://source.coop/wherobots/fields-of-the-world. How expensive is continental-scale FTW inference on Wherobots? The post does not publish a full cost table. Microsoft’s Caleb Robinson describes mosaicking multi-season Sentinel-2 over millions of square kilometers, running models, and organizing outputs in minutes for a few hundred dollars. --- ## How Aarden.ai Scaled Spatial Intelligence 300× Faster for Land Investments with Wherobots URL: https://wherobots.com/blog/aarden-ai-geospatial-intelligence-wherobots-case-study/ Updated: 2026-10-19 When Aarden.ai emerged from stealth recently with $4M in funding to “empower landowners in data center and renewable energy deals,” the company joined a new wave of data and AI startups reimagining how physical-world data drives modern business. Their mission: help institutional land investors rapidly evaluate the value and  potential uses of land across the country. To do that, Aarden needed to process vast geospatial datasets such as parcels, forests, soil, endangered species, energy infrastructure, and turn them into actionable business intelligence. Key takeawaysAarden.ai uses Wherobots to help institutional land investors evaluate parcels for data centers, renewables, carbon capture, solar, and timber after raising $4M coming out of stealth.A statewide job that calculated distance from every parcel to the nearest water source took seven days on Aarden's early Python stack. It dropped to 30 minutes on a Wherobots medium compute instance, about 300x faster.Scripts that once took a week to run can now be developed in a day and executed in under an hour. That lets the team iterate daily and scale from a single state to a national view of land opportunity.GeoPandas, RasterIO, and GDAL worked for prototypes but not production. Wherobots gave them Spark-scale raster and vector processing without standing up a Spark team, plus Iceberg tables instead of large Postgres clusters.Founding engineer Steven Yee: we went from babysitting compute jobs for a week to getting results before lunch. The problem? Their early Python stack couldn’t keep up. Aarden.ai needed faster, scalable geospatial processing and Wherobots made it possible. Results First: From Seven Days to Thirty Minutes Before adopting Wherobots, a single statewide geospatial computation — like calculating the distance from every parcel in a state to the nearest water source — took seven days to complete. After moving their geospatial data pipelines to Wherobots, that same job ran in just 30 minutes on a medium compute instance. Scripts that once took a week to run could now be developed in a day and executed in under an hour. That acceleration unlocked a new rhythm for Aarden’s engineering team: iterate daily, explore new models, and scale from a single state to a national view of land opportunity. As founding staff engineer Steven Yee put it, “We went from babysitting compute jobs for a week to getting results before lunch.” Why Startups Like Aarden Choose Wherobots Why did Aarden.ai choose Wherobots? For scalability, ease of use, and integrated raster-vector support. For startups building data applications rooted in the physical world — agriculture, climate, energy, mobility, land, or infrastructure — data scale and spatial complexity are unavoidable. The Aarden team, led by geospatial scientist Ben Hudson, knew this well. Hudson’s background processing satellite imagery for Greenland’s ice sheet and building Zillow’s Zestimate engine gave him firsthand experience in the pain of scaling geospatial pipelines. When Aarden began, they tried the standard open-source stack: GeoPandas, RasterIO, GDAL. It worked for prototypes, but not for production. The choice came down to two questions: How do we scale spatial computation without building a Spark team? How do we avoid spending months managing infrastructure instead of shipping data products? The answer was Wherobots. “Spark is incredibly powerful — but it’s also a huge learning curve, Wherobots shortened the painful part of Spark and gave us production-grade scalability without having to babysit clusters.” Ben Hudson Co-Founder and Head of Applied Science, aarden.ai Wherobots’ full support for both rasters and vectors meant Aarden could seamlessly combine terrain, vegetation, and parcel data into unified models. They could also store and query data using Iceberg tables, eliminating the need for maintaining large Postgres clusters. The alternative platforms — like Google Earth Engine or Microsoft’s Planetary Computer — weren’t built for their hybrid vector-raster workflows or the flexibility needed to prototype and deploy quickly. “Wherobots is the most proven way to do it,” Hudson said. “It’s the reliable, full-featured, tried-and-true option.” Making Land Data Useful for Decision-Makers Aarden’s customers are institutional land investors evaluating large portfolios of property — for carbon capture, solar, timber, or data center opportunities. Wherobots powers the data engine behind Aarden’s platform, turning sprawling public datasets into clear, numeric insights. End users don’t see geotiffs or coordinate grids. They see a simple interface: Which land deals have the highest alpha potential? Behind that simplicity is Wherobots’ compute layer — transforming complex geospatial and environmental data into machine-learning-ready features and business metrics. “Our customers don’t need to be geospatial experts,” said Hudson. “They just need to make smart business decisions. Wherobots helps us turn a mountain of geospatial data into simple, singular, useful numbers and cash flow analyses.” Looking Ahead As Aarden scales, their focus is on robustness, repeatability, and rapid iteration. With Wherobots, they can run production-grade geospatial pipelines without worrying about cluster management or data scaling. And as they expand nationally, their confidence is simple: “It just works.” Aarden’s story reflects a broader trend. The next generation of data startups — those whose insights are grounded in the physical world — are choosing Wherobots to get from prototype to production faster. Because when your data is as big as the planet, you need compute that scales with it. Looking to get started for your spatial data pipelines and intelligence application? Get started today in community (free) or try out pro for your team. Or reach out to sales for a demo.  Frequently Asked Questions How much faster are Aarden geospatial jobs on Wherobots? A statewide parcel-to-nearest-water computation that took seven days now finishes in 30 minutes on a medium instance: the 300x speedup in the headline. Work that took a week to run can now be developed in a day and executed in under an hour. Why did Aarden.ai choose Wherobots over GeoPandas or Google Earth Engine? The open-source GeoPandas/RasterIO/GDAL stack could not scale to production. Earth Engine and Planetary Computer were not built for Aarden hybrid vector-raster workflows. Wherobots shortened the Spark learning curve and provided production-grade raster-vector compute without cluster babysitting. What land datasets does Aarden process? Parcels, forests, soil, endangered species, energy infrastructure, terrain, and vegetation. They are fused into machine-learning features and cash-flow metrics for institutional land investors. Do you need a Spark team to use Wherobots? Aarden co-founder Ben Hudson said Spark is powerful but a huge learning curve; Wherobots shortened the painful part of Spark so they could ship data products instead of managing infrastructure. --- ## Your Perfect Week for Geospatial at AWS re:Invent 2025 URL: https://wherobots.com/blog/your-perfect-week-geospatial-awsreinvent-2025/ Updated: 2026-10-19 December means it’s time for AWS re:Invent in Las Vegas! Thanks to our friends at Felt, we’ve mapped out what your perfect week for geospatial could look like — so you don’t miss a thing! Key takeawaysThis is an event roundup for AWS re:Invent 2025 in Las Vegas, mapped with Felt, not a product announcement.Find Wherobots at Expo Hall booth #1239 all week to talk Apache Sedona, spatial processing, GeoAI, satellite imagery, and raster/vector joins.Wherobots and Felt are hosting the Geo Party; RSVP is required because space is limited.Curated geospatial session picks run Monday, December 1 through Thursday, December 4 across the Wynn, Caesars Forum, Mandalay Bay, and MGM Grand.The sessions cover agentic AI, Caterpillar geospatial operations, Project Kuiper, ElastiCache data modeling, Bedrock emergency response, Valkey geofencing, and sustainable computing for climate.Use the post interactive map for the full location-organized agenda, or fill out the form in the post to book time with the Wherobots team on site. 📍Find Wherobots at booth #1239 in the Expo Hall Start your conference by visiting us in the Expo Hall — we’ll be there all week! Come talk geospatial with us. Ask us about Wherobots or Apache Sedona, spatial data processing, GeoAI, satellite imagery analysis, raster and vector joins, or any exciting spatial projects you’re working on. Have a challenge? We’d love to hear about it! 🎉 Kick off your week with the Geo Party We’re back with the Geo Party, hosted by Wherobots and Felt. This is a must-attend event for anyone in geospatial at re:Invent. You won’t want to miss it! Be sure to RSVP here as space is limited! ⭐ Top Geospatial Picks for re:Invent Here’s a curated list of sessions to help you make the most of the conference week. Check out the interactive map for the full agenda of recommendations, organized by location, and bookmark it for easy access! Monday, December 1 TimeSessionTitleSpeaker(s)11AM – WynnAgentic AI for geospatial modeling Agentic AI’s new generation of Industry and Line of Business solutions (PEX202)Michael Schmidt, Ryan Thomas5PM – Caesars ForumConstruction intelligence in action Redefining Operations: Caterpillar’s Geospatial Intelligence Solution (IND322)Steve Blackwell, Alan Doty, Ash Shah, Sriram Somasuntharam Tuesday, December 2 TimeSessionTitleSpeaker(s)5PM – Mandalay BayGlobal connectivity from spaceArchitecting resilient global networks with Project Kuiper (ARC320)Nick Matthews Wednesday, December 3 TimeSessionTitleSpeakers10AM – Mandalay BayData modeling deep diveAdvanced data modeling for Amazon ElastiCache (DAT438)Kevin McGehee, Yaron Sananes5PM – MGM GrandAI-powered emergency response Weather emergency advisor with Amazon Bedrock and Location Service (WPS311)Charlotte Fondren, Bradley Wyman Thursday, December 4 TimeSessionTitleSpeaker11AM – MGM GrandHands-on geofencing that actually worksGeo-fencing & real-time geospatial alerts with ElastiCache Valkey (DAT408)Gururaj S Bayari, Damon LaCaille, Kevin McGehee, Veerendra Nayak, Allen Samuels3PM – Mandalay BaySustainable computing for climate workSustainable computing for climate solutions (AIM417)Nitin Pathak, Guyu Ye If you’d like to find a time to connect at re:Invent, fill out the form below and we’ll be in touch to set something up! Frequently Asked Questions Where is Wherobots at AWS re:Invent 2025? Expo Hall booth #1239, all week. What is the Geo Party at re:Invent? A geospatial community event hosted by Wherobots and Felt. RSVP is required; space is limited. The RSVP link is in the post. Which geospatial sessions does Wherobots recommend? A short list spanning December 1-4. It includes PEX202 agentic AI, IND322 Caterpillar geospatial intelligence, ARC320 Project Kuiper, DAT438 ElastiCache data modeling, WPS311 Bedrock weather emergency advisor, DAT408 Valkey geofencing, and AIM417 sustainable computing for climate. The interactive map has the full agenda. How do I meet the Wherobots team at re:Invent? Visit booth #1239, attend the Geo Party, or submit the meeting form in the blog post. --- ## Discover URL: https://wherobots.com/products/discover/ Updated: 2026-10-09 Discover The Havasu Catalog is for physical-world data and AI Assets Your knowledge lake for every physical-world AI asset: geospatial datasets, AI models, notebooks, workflows, and solution recipes. The organizational memory that makes your team and your AI agents more productive with every build. START BUILDING Explore Havasu Catalog Curated datasets, ready to query Overture Maps Foundation, Foursquare, and hosted spatial datasets. Bring your own from S3, GCS, Azure, or Databricks Unity Catalog. Pre-trained AI models for Earth intelligence Object detection, segmentation, classification, and map matching. Bring your own PyTorch model or start with the built-in library. Recipes, not blank pages Solution notebooks for real-world use cases. Start from working code, deploy to production. Geospatial datasets, AI models, and solution notebooks in one hub Solution Notebooks Working code for insurance risk, agricultural field detection, mobility analytics, and infrastructure mapping. Start from a proven example. Overture Maps and Foursquare Datasets Places, buildings, transportation networks, and administrative boundaries from Overture Maps Foundation and Foursquare. Ready to query in WherobotsDB. Bring Your Own Data Connect S3, GCS, Azure, or Databricks Unity Catalog. Register STAC collections. RasterFlow Models Built-in models for field boundary detection, canopy height estimation, road detection, and urban infrastructure mapping. Or bring your own PyTorch model. Share Across Your Team Share notebooks, geospatial datasets, and model configurations across your organization. Build on each other’s work. RasterFlow Models for Satellite Imagery Analysis Pre-trained computer vision models for common Earth observation tasks. Run inference at any scale with RasterFlow, or bring your own PyTorch model. Object detection Detect buildings, solar panels, vehicles, and infrastructure in satellite or aerial imagery. LEARN MORE Segmentation Delineate boundaries for crop fields, water bodies, and vegetation areas from satellite imagery. LEARN MORE Classification Categorize land cover types, urban areas, and vegetation classes across regions or entire continents. LEARN MORE Map Matching Snap noisy GPS data to road segments to simplify analysis of mobility data. LEARN MORE Integrations & Catalogs Connect your geospatial datasets from anywhere Hosted geospatial datasets from Overture Maps and Foursquare, your own cloud storage, Databricks Unity Catalog, or any STAC catalog. The Havasu Catalog connects to all of them. Hosted Datasets Popular, curated datasets built-in to Wherobots for seamless use. High quality global datasets from Overture and Foursquare with places, buildings, transportation infrastructure and more. Learn More Your Cloud Storage Connect AWS S3, Google Cloud Storage, or Azure Blob Storage. Query geospatial datasets directly from WherobotsDB without migration. Learn More Databricks Unity Catalog Integrate with Databricks Unity Catalog. Register Unity as a catalog source. Browse schemas, tables, and views. Learn More STAC Collections Build references to Spatial Temporal Asset Catalog (STAC) collections Register STAC URLs to index imagery and metadata for search & inference. Learn More Learning Resources Course Free Geospatial Data Engineering Associate Certification Learn to build production spatial data pipelines with geospatial datasets in WherobotsDB. Free certification. LEARN MORE Course Free Wherobots Fundamentals Get started with WherobotsDB, spatial SQL, and the Wherobots platform. Free course. LEARN MORE VIEW MORE Next Steps Explore the Wherobots Platform Build Build spatial AI with SQL, Python, and the Spatial AI Coding Assistant. LEARN MORE Automate Take spatial data pipelines to production with Apache Airflow and Job Runs. LEARN MORE AI for Earth Run satellite imagery analysis at any scale with RasterFlow. LEARN MORE FAQ Which geospatial datasets are built into Wherobots? The Havasu Catalog includes geospatial datasets from Overture Maps Foundation and Foursquare, covering places, buildings, transportation networks, and administrative boundaries globally. These datasets are pre-loaded and ready to query in WherobotsDB. Teams can also connect their own geospatial datasets from S3, GCS, Azure, or Databricks Unity Catalog without migration. For more information, see the documentation. Which AI models are available in Wherobots? The Havasu Catalog provides pre-trained computer vision models with RasterFlow. Built-in models include Fields of the World for agricultural field boundary detection, Meta CHM v1 for canopy height estimation, Tile2Net for urban infrastructure detection, and ChesapeakeRSC for rural road detection. RasterFlow supports semantic segmentation, regression, and patch-based processing. You can also bring your own PyTorch model using the Machine Learning Model (MLM) standard. How do I connect my own cloud storage? Wherobots connects to AWS S3 buckets using cross-account IAM roles, maintaining your existing governance and permissions. Google Cloud Storage and Azure Blob Storage are also supported. Connect your buckets and query geospatial datasets directly from WherobotsDB without migration. The Havasu Catalog serves as the central geospatial data management layer for all connected data sources, including your own cloud storage, Databricks Unity Catalog, and STAC catalogs. How do I access aerial imagery available through a SpatioTemporal Asset Catalog (STAC)? WherobotsDB includes a built-in STAC reader that connects to any SpatioTemporal Asset Catalog. Load STAC items and collections directly into Sedona DataFrames using Python or Scala. Connect to STAC catalogs like Element84 Earth Search for Sentinel-2 imagery, or register your own STAC endpoints including private catalogs with API key authentication. Once loaded, process the data with WherobotsDB’s 300+ spatial functions or write results to GeoParquet for storage in your lakehouse. Get started Wherobots is the Context Engine for Physical World Data. TALK TO US START BUILDING --- ## Compute URL: https://wherobots.com/products/compute/ Updated: 2026-10-09 WherobotsDB The spatial compute engine built for physical-world data WherobotsDB is the distributed spatial engine with full geometric correctness at any scale. 300+ spatial functions for vector and raster data, with native Spark SQL for tabular operations. Built by the original creators of Apache Sedona. START BUILDING 300+ spatial functions Vector, raster, topology, and spatial indexing. 3x faster, 46% lower cost Spatial joins that run in minutes, not days. From city block to the entire globe Horizontally distributed on Apache Spark. Scales with your data. The benchmark leader in spatial compute WherobotsDB delivers the fastest and most capable engine for cost-efficient performance across general-purpose spatial SQL workloads. The following table was run across multiple compute engines using the Apache Sedona SpatialBench at Scale Factor 1000. In a separate test, WherobotsDB completed a Texas-statewide raster spatial join in 3 minutes 28 seconds. BigQuery timed out. Scale Factor 1000 Query Capability Matrix SpatialBench Query # WherobotsDB Sedona on Serverless Spark Proprietary SQL Serverless Proprietary Spark Clusters with Spatial SQL Sedona on Managed Spark Clusters 1: Spatial filter, aggregation, sorting 2: Spatial filter, aggregation, sorting 3: Spatial filter, aggregation, sorting 4: Lightweight spatial join and aggregation 5: Spatial aggregation 6: Heavy spatial join 7: Geometry construction and access 8: Heavy distance join 9: Heavy polygon self spatial join 10: Heavy spatial left join 11: Multi-way spatial join 12: KNN join SpatialBench for Apache Sedona Key capabilities Unlimited Scale Scale workloads seamlessly from small to a planetary scale. Apache Spark & Sedona Compatible Migrate existing Apache Spark and Sedona workloads without changing a single line of code. Compare Wherobots and Apache Sedona. Fully compatible out-of-the-box. Nothing to Manage But Your Code Serverless by default, or deploy securely in your own VPC. 300+ Spatial Functions for Vector and Raster Data High performance spatial joins with 300+ ST_ and RS_ functions built to accelerate productivity. Low Cost + High Performance Spatial Operations WherobotsDB delivers fast, cost-efficient performance across spatial SQL and python workloads*. WherobotsDB benchmarks at 3x faster with up to 45% better price-performance than comparable engines, and at lower cost than PostGIS at scale. *This represents actual cost benchmarking results for SpatialBench queries 7-12 with a scale factor of 1000 across three of the most comparable deployment options. Contact us to compare all benchmarks WherobotsDB Lowest Proprietary SQL Serverless Engine x2.92 higher Apache Sedona on Serverless Spark Engine x2.03 higher Proprietary Cloud Managed Spark x2.52 higher Relative cost across operations that completed Workload Flexibility From Small to Planetary Scale Workloads Perform city to global scale spatial data operations in a single solution. City Region Country Global Productivity Accelerate Innovation Economically SQL and Python 300+ ST_ and RS_ Functions Raster Vector Tabular SPATIAL JOIN Data Products “Spark is incredibly powerful — but it’s also a huge learning curve, Wherobots shortened the painful part of Spark and gave us production-grade scalability without having to babysit clusters.” Ben Hudson Co-founder and Head of Applied Science, aarden.ai Apache Spark & Sedona Compatible Lift and shift your existing Spark + Sedona workloads with the same APIs and code, now with improved performance and lower cost. Learn More scalaspark.read.format("csv") .option("header", "true") .load("cities.csv") .createOrReplaceTempView("cities"); val result = spark.sql( "SELECT * FROM cities WHERE ST_Contains(area, point)" ) result.show() Deployment & Compatibility Zero Migration. Total Flexibility. Keep your existing Apache Spark or Sedona code, run it serverless or in your VPC Serverless by Default Zero infrastructure to manage Auto-scaling, cost-efficient Works out-of-the-box Learn more Deploy in Your Cloud (BYOC) Full control in your VPC Enterprise-ready security Works behind your firewall Reach out to our team Go deeper WherobotsDB is 3x Faster with up to 45% Better Price Performance The next generation of WherobotsDB delivers measurable gains across spatial SQL workloads, with benchmarks to prove it. LEARN MORE Raster Processing at Scale: Out-of-Database Architecture How WherobotsDB processes terabyte-scale satellite imagery, elevation models, and sensor data without storing raster data inside the database. LEARN MORE Streaming Spatial Data with Spark Structured Streaming How to build real-time spatial pipelines that ingest and process GPS and IoT data as it arrives, without the workarounds traditional systems require. LEARN MORE Get Started with WherobotsDB Explore the platform, build powerful solutions, or automate your geospatial workflows. Discover Seamless access to the right datasets, AI models and solution accelerators for your use case. LEARN MORE Build Start using WherobotsDB with familiar Apache Spark/Sedona syntax. LEARN MORE Automate Orchestrate spatial data flows at scale with Apache AirFlow or our REST API. LEARN MORE FAQ How does WherobotsDB compare to other geospatial analytics engines? WherobotsDB is a distributed geospatial analytics engine with full geometric correctness at planetary scale. On the Apache Sedona SpatialBench at Scale Factor 1000, WherobotsDB completed all 12 spatial queries, including heavy spatial joins that the next best Spark-based engine with Spatial SQL could not finish within a 10-hour timeout. WherobotsDB benchmarks at 46% lower cost than that engine and delivers up to 3x faster performance on analytical queries. For raster-vector workloads, WherobotsDB completed a Texas-statewide raster spatial join in about 3.5 minutes. BigQuery timed out on the same test. Which spatial functions are supported in Wherobots? WherobotsDB includes 300+ spatial functions for vector and raster data, covering geometry processing, spatial predicates, coordinate reference systems, and large-scale spatial joins. Advanced functions include kNN joins for nearest neighbor queries, zonal statistics on raster layers, travel isochrones for accessibility analysis, GPS map matching for mobility data, and PMTiles generation for map visualization. Native Spark SQL handles tabular operations alongside the spatial functions. What raster data processing functions does WherobotsDB support? WherobotsDB includes 100+ raster RS_ functions for processing satellite imagery, elevation models, and sensor data at scale. These cover in-database and out-of-database raster loading, affine transformations (translation, scaling, rotation, shearing), union aggregation to combine multiple rasters into multi-band outputs, zonal statistics, map algebra, raster tiling, and output writers for GeoTIFF, ArcGrid, and PNG formats. WherobotsDB’s out-of-database raster architecture processes terabyte-scale imagery without moving data into the database, enabling planetary-scale inference and zonal statistics. Why is WherobotsDB faster than general-purpose engines for spatial data analysis? WherobotsDB is built from the ground up for spatial data workloads. The engine uses a Rust-native, Arrow-columnar execution layer with zero-copy geometry handling via GeoArrow, optimized at the compute, query planner, and function levels. Production teams report processing times dropping from 39 days to under one day (GeoPostcodes) and from 7 days to 30 minutes (Aarden.ai). WherobotsDB separates compute from storage, scales horizontally on Apache Spark, and maintains 100% code compatibility with open-source Apache Sedona. Get started WherobotsDB is part of Wherobots, the Context Engine for Physical World Data. TALK TO US START BUILDING --- ## Build URL: https://wherobots.com/products/build/ Updated: 2026-10-09 Build Build with the AI coding tools you already know, now spatially enabled. No new languages. No new tools. Write SQL and Python in you preferred AI enabled IDE: Cursor, VS Code, Windsurf, Claude Code, or through the Spatial AI Coding Assistant. WherobotsDB or RasterFlow enables the spatial data processing. START BUILDING Spatial AI coding tools Discover datasets, construct queries, and run production jobs through natural language. From notebook to production in one platform Explore in notebooks. Deploy with job runs and Airflow. SQL and Python, nothing else to learn Standard spatial SQL and Python APIs. The Spatial AI Coding Tools: Your AI copilot for physical-world data The Spatial AI Coding Tools connects AI agents to spatial data. Through VS Code, Wherobots Command Line Interface (CLI) and Model Context Protocol (MCP), agents can discover spatial datasets, construct spatial queries or notebooks, and execute production workflows in natural language. Available on the VS Code marketplace and compatible with Claude Code, Cursor, Windsurf, OpenCode, and other MCP-enabled coding tools. TRY IN VS CODE Build spatial AI from notebooks to production Four interfaces into the same spatial compute engine. Explore in notebooks, query with the SQL API, integrate with the Typescript SDK, or automate with Job Runs. Notebooks SQL API Typescript SDK Job Runs Serverless Compute and AI Join vector, raster, and structured data in one platform WherobotsDB processes vector geometries, satellite imagery, and structured tables in a single query. No separate tools for raster and vector. No export steps between systems. Spatial joins, ETL, and transformations run at planetary scale. Raster+Vector ETL & Joins Planetary scale TALK TO US 300+ spatial functions for vector and raster data 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations. Advanced spatial analytics include DBSCAN clustering, Getis-Ord Gi* for hot spot detection, and Local Outlier Factor for anomaly identification. All accessible through standard SQL and Python. DBSCAN Getis-Ord Gi* LOF 300+ fns LEARN MORE Start from real-world solutions Solution notebooks for insurance risk scoring, agricultural field detection, mobility analytics, and infrastructure mapping. Each notebook contains working code on real data. Start from a proven example and adapt it to your use case. BROWSE NOTEBOOKS Write spatial AI in the tools you already use Python, SQL, Scala, and Java in Jupyter notebooks. The Spatial AI Coding Tools in VS Code. MCP and CLI integration for Claude Code, OpenCode, or elsewhere. The same spatial functions, the same WherobotsDB or RasterFlow engine, in any interface. Python SQL VS Code LEARN MORE 100% Apache Sedona compatible Existing Apache Spark and Sedona workloads run on Wherobots Cloud 3X faster with zero code changes. GeoPandas workflows scale to planetary scale datasets through the Sedona API. Built by the original creators of Apache Sedona. Spark API Sedona API GeoPandas API LEARN MORE From notebook to production in one step The same code you write in notebooks run as automated jobs in Apache Airflow or other orchestration tools. No rewrite needed. No separate deployment pipeline. Airflow Scheduling LEARN MORE Dive Deeper AI Agents for Spatial Analytics: A 15-Minute Experiment with Our MCP Server A hands-on look at using the Wherobots MCP server to go from a natural language question to real spatial query results in minutes. READ MORE Scaling Spatial Analysis: How KNN Solves the Spatial Density Problem for Large-Scale Proximity Analysis A walkthrough of processing 44 million geometries across 5 US states using kNN joins to solve the spatial density problem that breaks traditional proximity analysis. READ MORE The Medallion Architecture for Geospatial Data: Why Spatial Intelligence Demands a Different Approach How to apply the bronze/silver/gold pipeline pattern to spatial data, and why geospatial workloads demand a different approach than standard analytics pipelines. READ MORE FREQUENTLY ASKED QUESTIONS What is the Spatial AI Coding Assistant? The Spatial AI Coding Assistant connects AI agents to spatial data through VS Code and Model Context Protocol (MCP). Agents discover spatial datasets, construct spatial queries, and execute production spatial AI workflows in natural language. It is available on the VS Code marketplace and compatible with Claude Code, OpenCode, and other MCP-enabled coding tools. How does Wherobots accelerate my spatial data workflows? WherobotsDB is a high-performance, cloud-native engine optimized for spatial data (vector and raster). The engine processes planetary-scale datasets up to 20x faster and at a fraction of the cost of general-purpose cloud engines. WherobotsDB uses standard SQL and Python, so data teams build spatial AI applications without learning new tools or languages. What languages and developer frameworks are supported in Wherobots? Wherobots supports the most common data and spatial development interfaces. You can develop using: Spatial SQL Python Scala Java The platform offers a seamless development experience through familiar Jupyter notebooks and integrates with existing data workflows through REST APIs, client SDKs (e.g., Python driver, Java JDBC driver), and an Apache Airflow provider for pipeline orchestration. Get started WherobotsDB is part of Wherobots, the Context Engine for Physical World Data. TALK TO US START BUILDING --- ## Automate URL: https://wherobots.com/products/automate/ Updated: 2026-10-09 AUTOMATE Take spatial data pipelines to production Orchestrate physical-world data pipelines with Apache Airflow or the Job Runs API. The same code you built in notebooks runs in production with full observability. START BUILDING Production-grade spatial pipelines Schedule and orchestrate continuous spatial workflows. Native Apache Airflow integration Drop WherobotsDB into your existing Airflow DAGs. Migrate and accelerate Existing Spark and Sedona pipelines run faster at lower cost. Orchestrate spatial data pipelines with Apache Airflow The Wherobots Airflow Provider drops spatial data pipeline jobs into your existing Airflow DAGs. Run WherobotsDB compute jobs or execute spatial SQL queries on a schedule. Install with pip install airflow-providers-wherobots. Available for Professional and Enterprise editions. LEARN MORE Or trigger spatial data pipelines with the Job Runs API The Job Runs REST API triggers WherobotsDB jobs programmatically. Submit Python or JAR workloads, specify runtime sizes, monitor status, and retrieve logs. Integrate spatial data pipeline automation into any CI/CD system, orchestrator, or custom application. LEARN MORE Migrate existing Spark and Sedona pipelines to WherobotsDB Existing Apache Spark and Sedona spatial data pipelines run on WherobotsDB with zero code changes. WherobotsDB benchmarks at up to 3x faster queries and 46% lower cost. Aarden.ai reduced core processing from 7 days to 30 minutes after migration. LEARN MORE Full observability for every spatial data pipeline Monitor every spatial data pipeline from submission to completion. Track job status, resource consumption, runtime logs, and performance metrics. Identify bottlenecks before they impact production. Job Runs Workload Usage Logs & Metrics Learn more about monitoring job runs Learn more about monitoring your workload usage FAQ How do I use Wherobots with Apache Airflow? Install the Wherobots Apache Airflow provider with pip install airflow-providers-wherobots. After configuring your Wherobots API key in Airflow, use WherobotsRunOperator to execute Python or JAR spatial data pipeline jobs, or WherobotsSqlOperator to execute spatial SQL queries. Available for Professional and Enterprise editions. What kinds of code can a Wherobots Run execute? A Wherobots Run can be configured to execute either a Python file or a JAR file stored on an accessible S3 path (via Managed Storage or Storage Integration). When creating a run, you must specify a required runtime (e.g., tiny, medium, x-large-himem). You can also specify custom dependencies to be included in the environment, such as PyPI packages or other dependency files. Note: Available for Wherobots Professional and Enterprise Editions What types of workloads can be migrated to Wherobots? Existing Apache Spark and Sedona spatial data pipelines run on WherobotsDB with zero code changes. WherobotsDB benchmarks at up to 3x faster queries and 46% lower cost than the previous generation. Aarden.ai reduced core processing from 7 days to 30 minutes after migrating their spatial data pipeline to WherobotsDB. Get started Wherobots is the Context Engine for Physical World Data. TALK TO US START BUILDING --- ## AI for Earth URL: https://wherobots.com/products/ai-for-earth/ Updated: 2026-10-09 RasterFlow run AI on satellite imagery at any scale RasterFlow is the production-grade inference engine for Earth intelligence. Bring your own PyTorch model or use the built-in models. Point it at any imagery source. RasterFlow returns structured spatial features, ready for spatial joins in WherobotsDB. The bridge between what satellites capture and what your AI reasons about. START BUILDING VIEW RASTERFLOW MODELS Run inference on satellite imagery at planetary scale No custom computer vision pipeline required. Combine raster and vector in one pipeline Satellite-derived features flow into spatial joins in WherobotsDB. From built-in models to bring-your-own Fields of the World, Tree Canopy Height, SAM3, or any PyTorch model. Unlock Geospatial Intelligence with AI From satellite imagery analysis to production spatial features, in one pipeline. AI for remote sensing imagery Hosted Models Raster and vector analysis Automate and scale Apply AI models to remote sensing imagery Use state of the art AI models on remote sensing imagery for object detection, segmentation and classification. Or bring your own model. Learn More Leverage out of the box models on your imagery See all the models that Wherobots supports on Hugging Face. Learn More Combine raster and vector analysis Seamlessly store model inference results in Wherobots for further analysis and enrichment with vector or tabular data. All within a single platform and single development experience through Python or Spatial SQL. Learn More Automate and scale Scale your analysis from small-scale prototyping to planetary-scale production workflows, only pay for what you use. Learn More Benefits of AI for Earth Built-in models, or bring your own Fields of the World, Tree Canopy Height, Road Segmentation, SAM3. Or bring any PyTorch model. Learn more Solution notebooks for real-world use cases Agriculture, land cover, and infrastructure detection. Start from working code. Learn More From a single tile to continental coverage Automatic mosaicking, cloud removal, and distributed processing. Scales with your data. Learn More Integrated with WherobotsDB Inference outputs flow into WherobotsDB as vector features for spatial joins and downstream analytics. Learn More Predictable pricing Priced in Spatial Units you calculate from your area, resolution, and bands.  Pricing scales linearly with size as you scale. Learn More Instant results in open formats Zarr, GeoParquet and Apache Iceberg output. Query outputs immediately in WherobotsDB or your lakehouse. Learn More Your buckets, your data Read imagery from and write results to the S3 buckets you already own. No migration in, no export job out. Learn More Integrated visualization Preview mosaics and predictions in the browser with no export step. Generate multiscale Zarr for fast interactive viewing, and share a link. Learn More Turn satellite imagery into structured spatial features RasterFlow detects buildings, roads, vegetation, water, and land cover from satellite imagery. No manual classification. No custom computer vision pipelines. Point RasterFlow at imagery, get analysis-ready vector features back. START BUILDING Satellite imagery analysis in action Object detection, field boundary extraction, land cover classification, and road segmentation, powered by RasterFlow. Detecting objects with a text prompt Find roofs from open aerial imagery using RasterFlow and the SAM3 model with a single text prompt Segmenting agricultural fields Find field boundaries from Sentinel-2 using RasterFlow and the Fields of the World model Getting started with RasterFlow Run GeoAI models with a few lines of Python. RasterFlow handles distributed inference, mosaicking, and vectorization. Post-process or join results in WherobotsDB. Python Mosaicking Inference Learn More model_output_index = rf_client.predict_mosaic_recipe( # Path to an AOI in GeoParquet or GeoJSON format aoi = aoi_path, # Date range for Sentinel-2 imagery start = datetime(2023, 1, 1), end = datetime(2024, 1, 1), # Coordinate Reference System for the output mosaic target_crs = "EPSG:3857", # Model recipe for inference (Fields of The World in this case) model_recipe = ModelRecipes.FTW ) Bring your own model Use your own PyTorch model with RasterFlow. Load your PyTorch PT2 model archive from Hugging Face or S3. Run distributed segmentation, detection, or regression against mosaics from satellite or aerial imagery at planetary scale. PyTorch Custom ML Models Hugging Face Learn More custom_inference_config = InferenceConfig( model_path = hugging_face_model_path, actor = MosaicToMosaicActorEnum.REGRESSION_PYTORCH, features = ["red", "green", "blue"], labels = ["canopy_height"], ... ) Build cloud free mosaics Build cloud free mosaics from Sentinel-2 in Zarr format.  Choose from different compositing options including median, best scene or pre-configured settings for planting season and harvest season. Mosaicking Sentinel-2 Zarr Learn More mosaic_result = rf_client.build_mosaics( # Dataset for harvest season datasets=[DatasetEnum.S2_MED_HARVEST], # Path to your AOI aoi=aoi_path, # Date range for Sentinel-2 imagery start=datetime(2024, 1, 1), end=datetime(2025, 1, 1), # Coordinate Reference System for the output mosaic target_crs="EPSG:3857" ) FAQ What is RasterFlow? RasterFlow is Wherobots’ serverless inference engine for satellite imagery analysis and Earth intelligence. It builds mosaics from multiple raster data sources, runs inference with PyTorch computer vision models, and vectorizes results into spatial features. RasterFlow supports semantic segmentation, instance segmentation, object detection and regression at planetary scale. The engine manages its own compute resources and autoscales based on area, time range, dataset density, and model complexity. What models does RasterFlow include? RasterFlow includes curated, open-source models for common Earth observation tasks. Built-in models include Fields of the World for agricultural field boundary detection from Sentinel-2 imagery, Meta CHM v1 for canopy height estimation, Tile2Net for urban infrastructure detection (sidewalks, crosswalks, pedestrian pathways), ChesapeakeRSC for rural road detection and Meta’s Segment Anything 3 (SAM3) for instance segmentation and object detection from text prompts. RasterFlow also supports bring-your-own-model: register your PyTorch PT2 model, upload it to your cloud storage, and run distributed inference through the RasterFlow API or as an automated Job Run. What imagery does RasterFlow work with? RasterFlow includes built-in satellite and aerial imagery datasets. Sentinel-2 provides worldwide coverage at 10m to 30m resolution with 5-day revisit rates. RasterFlow automatically applies cloud and quality filtering when building Sentinel-2 mosaics, masking out cloud pixels, shadows, and sensor anomalies. NAIP (National Agriculture Imagery Program) provides high-resolution imagery (30cm to 1m) across the continental United States. RasterFlow can also build mosaics and run inference on your own GeoTIFF imagery stored in cloud storage. Get started RasterFlow is part of Wherobots, the Context Engine for Physical World Data. TALK TO US START BUILDING --- ## Introducing wkls: A Python Library for Instantly Accessing Global Administrative Boundaries URL: https://wherobots.com/blog/wkls-python-global-administrative-boundaries/ Updated: 2026-10-19 Why Defining Administrative Boundaries in Spatial Data is Hard If you’ve ever worked with spatial data, you probably needed to define a geographic boundary within which to conduct your analysis. Most of the time, these are administrative boundaries such as cities, states, provinces, countries etc. For instance, if you want to scope your analysis to New York City, you’d need to look for the admin boundary online, find an authoritative source, figure out how to either download and hardcode the data into your code or build a pipeline that reads directly from their APIs (if they support it). In case of New York’s CSV file, doing this will give you a 14.5K characters long text mostly consisting of unreadable coordinates, a common challenge for developers before tools like the wkls Python library. Key takeawayswkls (pronounced Whickles) is a Python library that lets you reference about 625K global administrative boundaries, from countries to cities, by name. It uses chainable syntax instead of pasting giant WKT strings.A New York City boundary sourced as CSV is about 14.5K characters of coordinates. Typical admin polygons run 10K-1M points, which is why teams hardcode WKT, hit public APIs, or fall back to bounding boxes.The library reads Overture Maps Foundation GeoParquet from the AWS Open Data Registry and returns WKT, WKB, HexWKB, GeoJSON, or SVG. It ships in Wherobots core libraries with zero extra install or configuration.Access is up to three chained attributes: country (required ISO 3166-1 alpha-2, e.g. us), optional region ISO suffix (e.g. ny), and optional place. Place is matched against county, locality, or neighborhood subtypes, for example wkls.us.nyc.cityofnewyork.wkt().Name collisions can return multiple rows (for example two San Francisco representations, land-only vs. including shorelines). The project is open source and accepts issues and pull requests. Before wkls – 150 Lines of Unreadable Coordinates nyc = 'MULTIPOLYGON (((-74.046135 40.691125, -74.046176 40.691092,\ -74.047041 40.691041, -74.047149 40.690985, -74.047207 40.690893, \ -74.047196 40.690794, -74.047146 40.690714, -74.047026 40.690589, \ -74.047041 40.690482, -74.047183 40.690411, -74.046248 40.689319, \ [... 149 lines later!] -74.0400963 40.6989342, -74.0401502 40.6989014)))' After wkls – 1 Line Referencing the Hierarchical Admin Boundary nyc = 'MULTIPOLYGON (((-74.046135 40.691125, -74.046176 40.691092,\ -74.047041 40.691041, -74.047149 40.690985, -74.047207 40.690893, \ -74.047196 40.690794, -74.047146 40.690714, -74.047026 40.690589, \ -74.047041 40.690482, -74.047183 40.690411, -74.046248 40.689319, \ [... 149 lines later!] -74.0400963 40.6989342, -74.0401502 40.6989014)))' These boundaries are well-known and well-defined, but most geospatial tools do not include them natively. This is because getting geopolitically precise administrative boundaries is challenging and often results in very large datasets (e.g., 10K-1M points per boundary).  As stated above, oftentimes data practitioners are forced to find Shapefiles for these boundaries on the internet, write code to download them from the source and include them in their projects. Alternatively, developers sometimes hardcode these strings into their projects or use inaccurate bounding boxes instead of the actual administrative boundary. This is, at best, boilerplate code that needs to be written and maintained over and over again and a possible source of inconsistencies between projects.  We heard this feedback from our customers repeatedly and it lined up perfectly with our mission to make geospatial easy to work with. That is why we are very excited to introduce the Well Known Locations (wkls) library. The wkls library (pronounced “Whickles”) includes ~625K global administrative boundaries — from countries to cities — which can be referred to by name using clean, chainable Python syntax. The library reads directly from Overture Maps Foundation GeoParquet data hosted on the AWS Open Data Registry. The supported formats are WKT, WKB, HexWKB, GeoJSON, and SVG. The library is included in Wherobots core libraries and there is zero installation or configuration required to take advantage of it.  How to Use the wkls Python Library Start by importing the library into your code and reference the cities using Python’s objection notation: import wkls wkls.us.wkt() # country: United States wkls.us.ny.wkt() # state: New York wkls.us.nyc.cityofnewyork.wkt() # city: New York wkls["us"]["ny"]["cityofnewyork"].wkt() # dictionary-style access wkls supports up to 3 chained attributes: Country (required) – must be a 2-letter ISO 3166-1 alpha-2 code (e.g. us, de, fr) Region (optional) – must be a valid region ISO code suffix (e.g. ca for US-CA, ny for US-NY) Place (optional) – a name match against subtypes: county, locality, or neighborhood For instance, the chained expression wkls.us.ca.sanfrancisco returns a data frame object containing all the matches to the administrative boundary for San Francisco. In most cases, the call resolves to a single admin boundary object (i.e., row). If there are name collisions (e.g., two representations of city of San Francisco, one with just the land border and the other including shorelines as well), multiple rows may be returned. Once you have the administrative boundary object, it can be used like any other geometry within Wherobots. For instance, you can calculate intersections, reference the boundary in any raster function, etc.  For more information please read the wkls documentation. Want to contribute to the library? You can open issues, submit pull requests, improve documentation and more by following the instructions on this open source repository. Try Wherobots: Faster, Smarter Geospatial Queries Making administrative boundaries more accessible is not the only way we are making geospatial developers’ lives easier. Our platform runs spatial queries 5-20X faster and up to 60% more cost efficient to use compared to other industry leading solutions. We also have rich functionality that allows you to run vector and raster functions in the same query. Our Spatial AI capabilities are also industry leading. Finally, our Community tier is free to try!  Get Started Now Frequently Asked Questions What is the wkls Python library? Well Known Locations (pronounced Whickles) is a Python library with about 625K global administrative boundaries you can call by name. It reads Overture Maps GeoParquet hosted on the AWS Open Data Registry. How do I look up a city boundary with wkls? Import wkls and chain country, region, and place: e.g. wkls.us.ny.wkt() for New York state or wkls.us.nyc.cityofnewyork.wkt() for New York City. Dictionary-style access works too. Country must be a 2-letter ISO 3166-1 alpha-2 code. What geometry formats does wkls return? WKT, WKB, HexWKB, GeoJSON, and SVG. The resulting geometry can be used in Wherobots spatial functions, including intersections and raster operations. Do I need to install wkls in Wherobots? No. It is included in Wherobots core libraries, so there is zero installation or configuration inside Wherobots. Outside Wherobots, the open-source repository is linked from the post. --- ## How to Use PMTiles with the Esri JavaScript API (ArcGIS Maps SDK) URL: https://wherobots.com/blog/use-pmtiles-esri-javascript-api-arcgis/ Updated: 2026-10-19 The other day, a customer dropped a question in our inbox that made us pause: “Hey, can we use PMTiles with Esri’s JavaScript API?” Key takeawaysThe ArcGIS Maps SDK for JavaScript has no native PMTiles support, but Wherobots shows a workaround. A lightweight translator service reads PMTiles via HTTP range requests and serves classic Z/X/Y tiles to Esri VectorTileLayer.PMTiles packs an entire tile pyramid into one cloud-optimized file. The browser reads a small header directory, then fetches individual tiles with byte-range requests from object storage, with no tile server farm or millions of tiny files to sync.Wherobots distributed PMTiles generator turns large datasets into a web-ready file in three lines of code. Converting the entire TIGER railroad dataset (112,000 line-strings) took under 3.5 minutes and cost $0.42.A Jupyter notebook walks through generating the file in Wherobots; an open-source tile server on GitHub is the translator you clone to serve those tiles into an Esri map. Our first thought? Honestly, probably not. A quick scan of the ArcGIS Maps SDK for JavaScript documentation didn’t show any native support for the PMTiles format. It seemed like a technical dead end. But “probably not” isn’t really our style. We love a good challenge, so we rolled up our sleeves, fired up our code editors, and started experimenting. And you know what? It is possible. With a clever little workaround, you can get the slick, serverless power of PMTiles lighting up your Esri maps. This post is the story of how we cracked it—and how you can, too. Why We Love PMTiles (And You Should Too) To understand the workaround we used with the Esri Javascript API, it helps to first appreciate the core problem PMTiles was built to solve: managing millions of tiny map files in cloud storage. Uploading and synchronizing a massive directory of individual tiles is slow and incredibly difficult to manage. PMTiles elegantly solves that headache by consolidating everything into a single, cloud-optimized file. Here’s how it works: a browser first reads the small header of the PMTiles file. This header acts as an internal directory, telling the browser the exact byte-range location for every tile inside the larger file. From then on, the browser uses efficient HTTP Range Requests to ask the cloud storage, “Hey, give me the tile located at position X, Y, and Z.” The result is a truly serverless format. You get the simplicity of managing a single file with the power to serve it directly from any object storage, drastically simplifying deployment and lowering hosting costs. Making Your Own PMTiles, Supercharged So, how do you get your own data into this powerful format? We believe that part should be simple, too. We built our own PMTiles generator to transform massive geographic datasets into a web-ready file with just three lines of code. Our generator uses a distributed architecture to process your data in parallel for maximum speed, even on small hardware. As a quick test, we converted the entire TIGER railroad dataset—all 112,000 line-strings. The result? Time to generate: Under 3.5 minutes Total cost to generate: $0.42 This makes generating large-scale, web-ready PMTiles not just possible, but incredibly cheap and fast. The Plot Twist: What the Esri API Expects So, if PMTiles is so great, what’s the catch? The hiccup comes from how Esri’s VectorTileLayer expects to find its data. Out of the box, it’s looking for a classic tile server URL structure, something like .../Z/X/Y (zoom level, column, row). PMTiles, with its single-file, range-request approach, doesn’t speak that language. It’s a classic case of a mature technology that hasn’t yet caught up with the efficiencies of modern formats. To get them to talk to each other, we need to build a small translator. In this case, it’s a lightweight service that sits in the middle, fetches data from the PMTiles file using its native strengths, and then serves it up in the classic Z/X/Y format that the ArcGIS SDK loves. See It To Believe It Talk is cheap, right? Here’s a quick video showing what our PMTiles look like, rendered beautifully inside an Esri JavaScript API map. Get Your Hands Dirty: Your Turn to Build! Ready to stop reading and start coding? We’ve made it incredibly easy for you to get this up and running on your own. No complex setups, we promise. Step 1: Create Your PMTiles File Here’s a Jupyter notebook hosted in Wherobots that walks through the process, from grabbing geographic data to creating your own optimized .pmtiles file. ➡️ Click here to access the Jupyter notebook Step 2: Set Up the Tile Server Next, let’s start the “translator” service we discussed. We’ve open-sourced a lightweight tile server on our GitHub repository. Clone the repo, follow a few simple setup steps, and you’ll be serving your PMTiles to the Esri SDK in minutes. ➡️ Get the code on GitHub Dive in, play around with the code, and see for yourself how powerful this combination can be. We can’t wait to see what you build! If you have questions or ideas, feel free to open a new discussion thread on GitHub. Better yet, if you’d like to help improve the project, we welcome all contributions to the repo. Get started with Wherobots START BUILDING Frequently Asked Questions Does the Esri JavaScript API support PMTiles natively? No. ArcGIS Maps SDK VectorTileLayer expects a classic /Z/X/Y tile URL. PMTiles does not speak that protocol, so you need a small translator service in the middle. How does the PMTiles-plus-Esri workaround work? A lightweight tile server fetches tiles from the PMTiles file using HTTP range requests, then exposes them in the Z/X/Y structure VectorTileLayer expects. Wherobots open-sourced that server on GitHub. How fast can Wherobots generate PMTiles? In the post’s test, the full TIGER railroad dataset of 112,000 line-strings became a PMTiles file in under 3.5 minutes for $0.42. It used a distributed generator that runs in three lines of code. Where do I get the notebook and tile server? The post links a Wherobots Jupyter notebook for generating PMTiles and a GitHub repository for the open-source tile server that fronts Esri maps. Questions and contributions go to that repo. --- ## Introducing Scalability for GeoPandas in Apache Sedona URL: https://wherobots.com/blog/scaling-geopandas-apache-sedona/ Updated: 2026-10-19 Introduction Learn about the new GeoPandas API for Apache Sedona. This new API allows GeoPandas developers to seamlessly scale their analysis beyond the limitations of a single compute instance, unlocking insights from large-scale datasets. By combining the intuitive Pythonic GeoPandas API with Apache Sedona’s distributed processing capabilities, users get the best of both worlds: familiar syntax with planetary-scale performance. Key takeawaysApache Sedona 1.8.0 (and Wherobots) now ship a GeoPandas API, so you keep GeoPandas syntax while execution runs distributed on Spark. Migrating is typically an import change to sedona.spark.geopandas.On a Medium Wherobots cluster (20+ nodes), lazy loading beat GeoPandas eager Parquet reads for area calculations. 40 million geometries took 40.0 seconds end-to-end in GeoPandas versus 0.9 seconds in GeoPandas on Sedona.For dwithin spatial joins, GeoPandas was faster at 1,000 by 1,000 (0.5s vs 3.7s) but fell behind at 10,000 by 10,000 (60.7s vs 3.8s). It could not finish 20,000 or 100,000 joins that Sedona completed in 8.1s and 151.2s.Joining Overture buildings to postal codes: 1 million records 10.2s vs 8.7s; 10 million 87.1s vs 11.0s; 50 million did not complete in GeoPandas and took 12.5 seconds on Sedona.GeoPandas still wins on small in-memory work and has broader function coverage today; the Sedona API implements the most popular GeoPandas functions, with gaps tracked in a GitHub issue. Start on the Sedona API if analysis may grow. What is GeoPandas? Python developers have long relied on GeoPandas as a great starting point for their spatial intelligence needs. As an extension of Pandas DataFrames, GeoPandas adds support for geometries and geospatial functions, making the analysis of location data straightforward, efficient and familiar to Python developers. With a few lines of Pythonic code, developers can easily load various geospatial data formats into GeoPandas DataFrames and then apply powerful geospatial transformations or analyses. Here’s an example of how you can use GeoPandas to load data from a Parquet file and then filter the data using coordinate-based indexing: import geopandas import s3fs # Define the S3 file path to the NYC buildings dataset and a filesystem object s3_path = 's3://wherobots-examples/data/onboarding_1/nyc_buildings.parquet' s3 = s3fs.S3FileSystem(anon=True) # Load the GeoParquet file directly from S3 nyc_buildings = geopandas.read_parquet(s3_path, filesystem=s3) # Define a bounding box for Columbus Circle (approximate coordinates) columbus_circle_bbox = [ -73.983, 40.767, # bottom-left (longitude, latitude) -73.981, 40.769 # top-right (longitude, latitude) ] # Filter for buildings within the bounding box using coordinate-based indexing columbus_circle_buildings = nyc_buildings.cx[ columbus_circle_bbox[0]:columbus_circle_bbox[2], columbus_circle_bbox[1]:columbus_circle_bbox[3] ] # Print the ID, address, and height for the first five rows of the filtered data print(columbus_circle_buildings[["BUILD_ID", "PROP_ADDR", "height_val"]].head(5)) BUILD_ID PROP_ADDR height_val 5160 7734681 2 COLUMBUS CIRCLE 38.750000 5161 7734653 1775 BROADWAY 49.049999 5164 7734648 233 WEST 58 STREET 41.220001 5165 7734719 240 CENTRAL PARK SOUTH 58.410000 5166 7734834 892 9 AVENUE 43.849998 Scaling GeoPandas for Large Datasets However, Pandas and GeoPandas alone had fundamental limitations that limited their usage for large scale analytical processes. GeoPandas is limited to a single node and does not natively support distributed computation. It’s easy to get started and great for smaller scale data analysis on your laptop or a single machine. But, as soon as your data volume or compute needs grow, you may be forced to adopt a different approach. Queries may slow down or even fail to complete due to out-of-memory errors as data sizes grow. When GeoPandas hits this wall, Python developers currently turn to distributed frameworks like Dask, Dask DataFrames, and dask-geopandas. While effective, these solutions can introduce additional complexity and a different programming paradigm. And, as we will discuss in more detail later, they lack dedicated optimizations for distributed processing of geospatial data. This is the gap our new API is designed to fill. Apache Sedona GeoPandas API: Scalable Geospatial Processing Today, Wherobots announces a new GeoPandas API for Apache Sedona, available in Wherobots and Apache Sedona 1.8.0. It combines the familiarity and convenience of GeoPandas DataFrames and APIs with the distributed query performance of Apache Sedona on Apache Spark. You can continue to use the GeoPandas syntax you know and love, but your computations will be executed in a distributed, scalable environment so you no longer need to worry about hitting the single node ceiling. Geospatial processing tasks that can be parallelized will instantly benefit from distributed computation, reducing the time and cost required for complex analysis. Beyond parallelized processing, Apache Sedona also supports query planning and lazy execution to optimize complex analytical pipelines. By deferring execution as late as possible, Sedona maximizes parallelism and minimize costly data shuffling in distributed systems. For instance, with lazy execution, queries only need to read the relevant columns and sections of Parquet files once the specific query plan is understood. By comparison, GeoPandas typically reads the whole Parquet file at ingestion time, which can slow down the overall time to load and process larger datasets. For more details on the benefits of lazy loading, see “Eager vs. lazy data loading” below. Now, when you evaluate frameworks for geospatial processing, you don’t have to choose between GeoPandas or Apache Sedona, or move data between the two frameworks for different types of analysis. With the new GeoPandas API for Apache Sedona, a single API provides the familiarity of GeoPandas with the seamlessly ability to scale. How to Use the Geopandas API in Apache Sedona In most cases, migrating existing code is as simple as changing your import statements to reference sedona.spark.geopandas: import sedona.spark.geopandas as gpd or from sedona.spark.geopandas import GeoDataFrame, read_parquet # GeoPandas import geopandas as gpd df = gpd.read_parquet(path) # GeoPandas on Sedona import sedona.spark.geopandas as gpd df = gpd.read_parquet(path) # That's it! Same API, distributed execution GeoPandas vs. Apache Sedona Performance Comparison Let’s look at some examples that show the relevant performance and scale differences between using GeoPandas directly or the GeoPandas API for Apache Sedona. Note: The tests below were all conducted on a Medium Wherobots cluster with distributed compute across more than 20 nodes. Since GeoPandas is limited to a single node, it was only able to leverage the resources of the driver node of the cluster. Meanwhile, GeoPandas on Apache Sedona was able to parallelize operations across all of the nodes in the cluster. Eager vs. lazy data loading As mentioned above, GeoPandas will typically read the entire dataset into memory during a load operation. In contrast, Apache Sedona and Apache Spark implement lazy data loading and will defer reading the dataset until query time. As a result, Apache Sedona can minimize the amount of data read, only retrieving the data required to complete the query. Here’s an example that demonstrates this tradeoff when working with large datasets. We load a large Parquet file consisting of 10s of millions of geometries and then perform an area calculation. The data for this example was synthetically generated using the Apache Sedona Spider Spatial Data Generator and stored in S3 in Parquet format. Number of geometries GeoPandas GeoPandas on Sedona Load time Area calculation time Total time Load time Area calculation time Total time 10,000,000 10.2 s 0.4 s 10.5 s N/A 0.4 s 0.4 s 20,000,000 20.7 s 0.7 s 21.4 s N/A 0.6 s 0.6 s 40,000,000 38.6 s 1.4 s 40.0 s N/A 0.9 s 0.9 s Although GeoPandas and GeoPandas on Sedona have comparable performance calculating area in this example, we see the benefits of lazy loading. Instead of waiting tens of seconds to load the entire file, we can get instant sub second results! Admittedly, the data loading time is a one-time operation in GeoPandas that could be amortized across many queries. But, with lazy loading in GeoPandas on Sedona, your initial analysis of large datasets can be instantly accelerated and there’s little to no downside as you run subsequent queries. Spatial joins In this example, we perform spatial joins (with predicate dwithin) against two dataframes of varying sizes. The data for these queries was synthetically generated using the Apache Sedona Spider Spatial Data Generator and stored in S3 in Parquet format. Here’s the code used to perform the spatial join: left_df = read_parquet(left_data_path_in_s3) right_df = read_parquet(right_data_path_in_s3) result = left_df.sjoin(right_df, predicate="dwithin", distance=50) Left side geometries Right side geometries GeoPandas time GeoPandas on Sedona time 1000 1000 0.5 s 3.7 s 5,000 5,000 14.5 s 2.9 s 10,000 10,000 60.7 s 3.8 s 20,000 20,000 N/A, did not complete 8.1 s 100,000 100,000 N/A, did not complete 151.2 s Note: GeoPandas performs slightly better on the join of 1000 x 1000 geometries. But, as the dataset size increases, GeoPandas on Apache Sedona demonstrates the advantages of distributed computation and performs significantly better. GeoPandas was not able to complete the 20,000 x 20,000 join or the 100,000 x 100,000 join on the single driver node of our Medium Wherobots cluster. Real-World Example: Analyzing Overture Building Data In this example, we look at the Overture Building dataset and analyze buildings by postal code using a spatial join. Here’s the code used to perform the spatial join: from sedona.spark.geopandas import read_parquet DATA_DIR = f"s3://wherobots-examples/data/geopandas_blog/" overture_size = "1M" postal_codes_path = DATA_DIR + "postal-code/" overture_path = DATA_DIR + overture_size + '/' + "overture-buildings/" postal_codes_df = read_parquet(postal_codes_path) overture_buildings_df = read_parquet(overture_path) cnt = overture_buildings_df.sjoin(postal_codes_df, predicate="intersects").shape[0] Note: To run the same code in GeoPandas, you may need to add the storage_options parameter to read from a public bucket, as in: postal_codes_df = read_parquet(postal_codes_path, storage_options={'anon': True}) Now, let’s compare the performance of this query, including the data load, across increasing dataset sizes (1 million → 10 million → 50 million). Dataset size GeoPandas time Sedona time 1 million 10.2 s 8.7 s 10 million 87.1 s 11.0 s 50 million N/A, did not complete 12.5 s Note: In this query example, Apache Sedona consistently performed better than GeoPandas. Furthermore, GeoPandas was not able to load the entire 50M records on the single driver node of our Medium Wherobots cluster and was, therefore, unable to complete the query. Advantages of GeoPandas for Small-Scale Data Working with smaller datasets: GeoPandas consistently provides slightly better performance on simple operations and on smaller datasets. Especially when the dataset is relatively small and can be loaded quickly into memory, there is less penalty for GeoPandas lack of lazy loading and query planning. Complete functional coverage: GeoPandas is a mature framework with comprehensive geospatial functionality. By comparison, the initial release of GeoPandas API for Apache Sedona provides compatibility for the most popular GeoPandas functions, but some capabilities have not yet been implemented. For details on the current state of compatibility and opportunities to contribute to the open source project, see this GitHub issue. Advantages GeoPandas API with Apache Sedona for Large Datasets Working with larger datasets. With a distributed cluster, you will be able to load larger datasets that would exceed the memory of a single machine. And, with the power of lazy loading, you only need to load the subset of the data that’s actually required to complete each query. Large scale computations. Complex geospatial analyses will benefit from parallelism and Apache Sedona’s geospatial optimizations, such as: Computations that are heavily expensive to_crs (ST_Transform), buffer , is_simple , is_valid Joins with expensive predicates touches , overlaps , dwithin Recommendation If there’s a chance your geospatial analysis could potentially grow in size or complexity, we recommend starting with the GeoPandas API for Apache Sedona today. At smaller scales, performance is comparable to GeoPandas. But, as your needs grow, you will be able to reap the performance and scale benefits that are only possible with Apache Sedona. If you’d like a deeper dive into how Wherobots, Sedona, and GeoPandas complement each other, check out this blog post. When you’re ready, get started with Apache Sedona with Wherobots. You can use the Community Edition for free, which has initial scalability, or upgrade to Pro Edition today and no longer worry about limiting the scale of your geospatial analysis. Create your Wherobots account START BUILDING Frequently Asked Questions What is the GeoPandas API for Apache Sedona? A GeoPandas-compatible API, available in Wherobots and Apache Sedona 1.8.0, that executes GeoDataFrame operations on Sedona distributed Spark engine instead of a single node. In most cases you only change the import to sedona.spark.geopandas. When is GeoPandas on Sedona faster than GeoPandas? On the Medium-cluster tests in this post, Sedona pulled ahead as soon as joins left the tiny-data regime: 10k by 10k dwithin was 3.8s vs 60.7s. GeoPandas could not complete 20k joins or a 50-million-building postal-code join that Sedona finished in 12.5 seconds. Lazy Parquet reads also cut load-plus-area time from tens of seconds to under a second. Does the Sedona GeoPandas API cover every GeoPandas function? No. The initial release covers the most popular functions; some GeoPandas capabilities are not implemented yet. Compatibility status and contribution opportunities are in the GitHub issue linked from the post. Should I start new projects on GeoPandas or the Sedona API? Wherobots recommends the Sedona GeoPandas API if there is any chance the analysis will grow. At small scale performance is comparable; at large scale you get distributed memory, lazy loading, and Sedona spatial optimizations without rewriting code. --- ## Introducing SedonaDB and SpatialBench for Apache Sedona URL: https://wherobots.com/blog/sedonadb-spatialbench-spatial-query-engine-apache-sedona/ Updated: 2026-10-19 Our role at Wherobots and as leaders in the Apache Sedona community is to help more developers, organizations, and AI systems positively transform the physical world using spatial data. In order to make the scale of transformation we envision possible, we’ve had to address significant bottlenecks in how data is stored and queried. We’re excited to celebrate the availability of SedonaDB and SpatialBench for Apache Sedona. Together they represent the next phase in our plan to accelerate innovation with spatial data and bridge the intelligence gap between AI and the physical world.   Key takeawaysSedonaDB is the first open-source, single-node analytical database engine that treats spatial data as a first-class citizen rather than a bolt-on extension like PostGIS, DuckDB Spatial, or SedonaSpark.Written in Rust on Apache Arrow and Apache DataFusion, it ships spatial types, joins, CRS, functions, indexing, and data pruning. It has Python and SQL interfaces plus APIs for R and Rust, and runs on a laptop or a single VM against local files or a data lake.Apache Sedona was incubated in 2020 for distributed geospatial processing and is used by companies such as Uber and Amazon Last Mile Delivery on Spark, Flink, and Snowflake. SedonaDB covers the no-to-low-cost, single-machine side of that ecosystem.SpatialBench is introduced as the first standard for spatial query performance: 12 representative queries from simple to complex, plus a data generator at scale factors 1, 10, 100, and 1000.Wherobots used SpatialBench to compare SedonaDB, DuckDB with its spatial extension, and GeoPandas at scale factors 1 and 10. Those results are published on the linked Apache Sedona announcement, not in this post. Intro to SedonaDB: A modern query engine that gets spatial right SedonaDB is the first open-source, single-node analytical database engine that treats spatial data as a first-class citizen. Most analytical query engines already support general-purpose operations: filtering, joins, aggregations, and APIs for SQL or Python. But when it comes to operating on spatial data those same engines fall short: support for geometry and geography types, coordinate reference systems (CRS), spatial joins, and raster or vector operations is missing. The workaround is to bolt on an extension like PostGIS (PostgreSQL), DuckDB Spatial (DuckDB), or SedonaSpark (Spark). While powerful, extensions inherit the limits, costs, and complexities of their host systems, require extra setup and tuning, and can force builders to develop around performance and usability gaps instead of developing their ideas.  SedonaDB is different. It’s for builders solving problems with physical world data.    Written in Rust, it’s lightweight, blazing fast, and spatial-native. Out of the box, it provides: Full support for spatial types, joins, CRS, and functions on top of industry standard query operations. Query optimizations, indexing, and data pruning features under the hood that make spatial operations just work with high performance. Pythonic and SQL interfaces familiar to developers, plus APIs for R and Rust. Flexibility to run in single-machine environments on local files or data lakes.  SedonaDB uses Apache Arrow and Apache DataFusion, and provides everything you need from a modern vectorized query engine. But it delivers the unique ability to also run high performance spatial workloads easily, without requiring extensions. Read the announcement on the Apache Sedona blog to dive in and roll up your sleeves. What led to SedonaDB? In 2020, Apache Sedona was incubated to address a significant support gap in distributed geospatial data processing. Since then, Sedona has enabled companies like Uber, Amazon Last Mile Delivery, and thousands of others with geographically distributed operations or interests to build and run more efficient and effective physical operations at scale. It is widely used today to bring geospatial processing support to Apache Spark, Apache Flink, and also Snowflake. But distributed systems aren’t for everyone or the right fit for every use case, and we could do more to drive innovation in lower-scale scenarios. Accelerating innovation  Many ideas are bootstrapped in no-to-low cost environments where iteration cycles are fast and low risk. There’s a lot that a developer can do today using a laptop or a single virtual machine, with modern software and LLMs—without adding a dependency that adds unwanted cost and complexity to the innovation cycle. Once their ideas are viable, they may not even require a distributed compute environment in production like Spark, or one that is “fully managed” by a vendor.  So the next step was pretty clear. We had to make it easier for builders to use spatial data in no-to-low cost environments so they can iterate and positively transform the physical world, faster. We also decided to address these challenges through open-source software to maximize accessibility.  Making development easier If you look around the ecosystem, you’ll notice a pattern: to get the analytical support you need for geospatial data, you deploy an analytics engine without the spatial analytics support you want, and then you bolt on what you need via an extension. Extensions are great and they serve a purpose very well. After all, SedonaSpark is an extension! But that doesn’t mean the combination of engine + extension is ideal. It requires additional setup and management, can require tuning to achieve a reasonable performance, and the underlying engine may end up becoming a bottleneck. Additionally, the development experience around the engine may be overly complex or lack support for the language you prefer, and the engine itself might introduce compute, cost, and other overhead.   Working from the root causes of these challenges, along with the desire to drive more innovation, our next step became obvious. We needed to create a query engine that aids spatial data solutions development out of the box with popular pythonic and SQL interfaces and is optimized for single-machine environments. But was there enough value created by a spatial-first query engine compared to general purpose query engines with spatial extensions?  Optimizing for spatial data = a better future  Spatial data is no longer a minor class of data. It’s everywhere, the rate at which it’s being generated is growing every day, and its use cases span numerous industries. It streams from devices, vehicles, satellites, and drones, and derivatives from this data inform automation and decision-making across business, government, and research. The solutions being developed with it are transforming how organizations operate in the physical world.  Innovation is happening today with this data despite the friction above, but the pace of this innovation can be accelerated by a query engine with internals intentionally designed to help developers realize the full potential of this data.  This engine is SedonaDB, and it’s backed by an open-source community (Apache Sedona) that is committed to solving physical-world challenges through data and technology.  Intro to SpatialBench: The first standard for spatial query performance “Without standards, there can be no improvement” – Taiichi Ohno. This statement from the founder of the Toyota Production System is an analogy for why we built SpatialBench. There was no standard way of measuring spatial query performance, so progress couldn’t be easily quantified or query engines objectively compared on this dimension.  We built SpatialBench to establish first standards. The initial release supports 12 representative queries, ranging from simple to complex workloads, and includes a data generator for scale factors 1, 10, 100, and 1000. We hope this framework and its future versions will guide innovation that leads to a greater understanding of the physical world. We also used SpatialBench to benchmark SedonaDB, DuckDB (with its spatial extension), and GeoPandas at scale factors 1 and 10. Those results are published here. Next Steps  Get Started with SedonaDB: Try it out and contribute to the roadmap. Use SpatialBench: Measure spatial query performance using a consistent standard. Watch the webinar (hosted by CNG): We’ve walked through SedonaDB and SpatialBench, and introduced Wherobots’ Startup Accelerator Program. Frequently Asked Questions What is SedonaDB? An open-source, spatial-native, single-node analytical query engine for Apache Sedona. It is written in Rust, uses Arrow and DataFusion, and supports spatial types, joins, CRS, and functions without requiring a host database plus extension. How is SedonaDB different from PostGIS or DuckDB Spatial? Those products add spatial support onto a general-purpose engine. SedonaDB is built spatial-first, so you do not inherit the host system setup, tuning, and overhead. It targets single-machine environments; SedonaSpark remains the distributed extension for Spark. What is SpatialBench? An open benchmark for spatial query engines. The initial release includes 12 representative queries and a data generator for scale factors 1, 10, 100, and 1000 so engines can be compared on a consistent standard. Does this post publish SedonaDB benchmark numbers? No. It says SedonaDB, DuckDB Spatial, and GeoPandas were benchmarked at scale factors 1 and 10 and points to the results on the Apache Sedona blog. This post does not include those timings. --- ## Wherobots Spatial Intelligence Engine Integrates with Databricks Unity Catalog for Spatial Data URL: https://wherobots.com/blog/spatial-intelligence-engine-databricks/ Updated: 2026-10-19 TL;DR: Wherobots now integrates with Databricks Unity Catalog, enabling users to process spatial data up to 20x faster with 60% cost savings. This integration supports raster/vector data, 300+ spatial functions, and enterprise security—all while maintaining full compatibility with Apache Sedona and Spark. Key takeawaysWherobots now federates with Databricks Unity Catalog, so you can read and write Iceberg or Delta tables in place with no data migration. It uses a Databricks service principal with OAuth or a PAT token.Customers such as Dotlas, Leaf Agriculture, and Overture report typical spatial-query speedups of 5-20x and on-demand cost savings as high as 60% on Professional Edition (higher on Enterprise).Wherobots offers 300+ spatial SQL/Python/Scala functions and 100% Apache Sedona compatibility (zero code changes).Wherobots handles raster (GeoTIFF, Zarr, NetCDF; commonly GBs to TBs) and vector (GeoParquet, Shapefile, GeoJSON) plus tabular Spark-compatible workloads, including computer-vision inference on geo-imagery from local to continental scale.Use Databricks native Spatial SQL for exploratory joins, point-in-polygon, and simple aggregations with no raster needs. Use Wherobots for production-scale spatial intelligence, raster+vector pipelines, GeoAI, TB-PB datasets, and existing Sedona workloads.Wherobots was founded by the original creators of Apache Sedona, the most widely used geospatial extension for Spark and Databricks. It is serverless, or can run its compute plane in your AWS VPC. Databricks Geospatial Performance with Wherobots 5-20x faster spatial query performance 60% cost reduction on spatial workloads 300+ spatial SQL/Python/Scala functions 100% Apache Sedona compatibility (zero code changes) Databricks users can now enhance their geospatial analytics capabilities with Wherobots, a spatial intelligence engine purpose-built for processing data from the physical world. Wherobots brings advanced raster processing, computer vision ML inference, and industry-leading performance to your existing Databricks environment. With Wherobots Data Federation for Unity Catalog, you can: Expand spatial coverage to grow revenues, improve margins, and make better decisions with complete spatial intelligence Create innovative spatial data products that leverage aerial imagery, IoT sensors, and mobility data at planetary scale Build with raster, vector, and tabular data using familiar SQL, Python, or Scala interfaces Run computer vision ML models on geo-imagery and sensor datasets from local to continental scale Migrate existing workflows with zero code changes—WherobotsDB is fully compatible with Apache Sedona and Spark Customers like Dotlas, Leaf Agriculture, and Overture are achieving step-function improvements in performance, cost efficiency, and innovation by integrating Wherobots with their Databricks platforms. Wherobots Data Federation connects directly to Unity Catalog, allowing you to read from and write to Iceberg or Delta tables with Databricks service principal and OAuth or PAT token authentication—no data migration required. Get started | Schedule a demo What is Spatial Intelligence? Spatial intelligence is the understanding of features of interest, and their relationships across space and time in multi-dimensional environments. With it, bridges are formed between digital and physical worlds. Decision making can improve, and you can create better products or services with higher returns. Simple spatial intelligence: Customer visits grouped for a location or area. But simplified formats like aggregations inherently lack precision, and you need to make tradeoffs between cost and resolution, all of which limit their usefulness. These aggregations are typically grouped by cells in a grid (like H3) and most commonly used to create visualizations. While interesting to look at, visualizations can be used to support a decision, intuition, or analysis, but they are generally less actionable because precision or other context is missing.  Complete spatial intelligence: Forecast, or a composite risk, opportunity, or value score associated with potentially millions of specific assets or features across a continent derived from any valuable combination of IoT, location, building, weather, road network, terrain, crops, parcel, aerial imagery, BI, or mobility datasets. By processing perspectives about features of interest from multiple valued aspects, the complete picture forms, which becomes highly actionable, and extremely useful intelligence.  But even the most popular data platforms still don’t make it easy to create. Wherobots enables complete spatial intelligence at scale with Databricks Unity Catalog integration. Why Do Traditional Data Platforms Struggle with Geospatial Data? There are many cloud data engines and warehouses that support the simple form described above, including BigQuery, Snowflake, and now Databricks with its Spatial SQL support in preview. However they still lack feature and data type support, reasonable query price-performance at scale, and the solution expertise you may need to create a complete form of spatial intelligence. Here’s why. Shaped by demand, most data platforms were first designed to handle the structured data exhaust from the web and devices connected to it, not data collected from or about the physical world. Physical world data is inherently complex, unstructured, and doesn’t fit neatly into key-based joins. It takes a specialized compute engine to make it easy to create solutions from spatial data. Easy means it’s capable of fusing and transforming various spatial and non spatial data types with high accuracy, scale, performance, and low cost, while ensuring development is productive with the teams you have. The spatial extensions and APIs for today’s big data engines and warehouses provide limited support for simple workloads. But because of design bottlenecks, missing features, and limited technical support, spatial solutions on these platforms can be expensive and difficult to build, while ideas remain far-fetched. What Makes a Modern Spatial Intelligence Solution Effective? Ideally the solution for creating complete spatial intelligence just fits into your existing software development workflows, already supports your future needs and the data you want to utilize, is accessible to the teams you have, and just performs at the right scale — on-demand, at a cost that encourages innovation. It’s lakehouse ready, so you don’t need to move your data or utilize proprietary formats or data types to use it. You also have dedicated expertise in reach to unblock innovation. With this capability at your fingertips, ideas can flow and innovation takes place. Your business can reach higher levels of efficiency, reducing costs, carbon footprint, and risk. You can speed up deliveries or pickups, increase the effectiveness of CAPEX, improve consistency, grow revenue, and build in ways that were thought to be impossible. This capability is Wherobots, and it’s directly available to Databricks users via data federation with Databricks Unity Catalog. How Wherobots Solves Geospatial Data Challenges Using Wherobots you can easily build a complete picture of what’s happened, over space and time, and integrate this intelligence into your Databricks data platform to drive growth – faster and at a lower cost than ever. Our mission is to make spatial data easy to utilize, and it’s all we are focused on. The results of our focus speak for themselves. Databricks Unity Catalog Geospatial Integration: Key Wherobots Features Wherobots makes it easy and economical to produce local to planetary scale data solutions that rely on any combination of aerial and overhead imagery, IoT and mobility data, ground truth datasets, and your own business context. And using Wherobots Data Federation with Unity Catalog, you can easily integrate the data products you build with Wherobots, into your Databricks data platform while retaining custody and governance of data. What Types of Spatial Data Does Wherobots Support? (Raster & Vector) There are two main classes of spatial data supported by Wherobots: raster and vector data. You also get the support and scale you’d expect for tabular data operations from Wherobots’ Spark compatible engine. Raster data is typically a collection of sensor or imagery data, where each pixel in the image represents information about what is being captured, like temperature, elevation, infrared spectrum, etc. File formats include GeoTIFFs, Zarr, and NetCDF and more. Raster datasets are commonly GBs to TBs in scale. Vector data is a collection of multi-dimensional geometries or geographies that represent the trajectory, shape, elevation, and location of things. They can be trips, points, and outlines of features like buildings or parcel and crop boundaries. File formats include GeoParquet (soon to be Parquet), Shapefiles, and GeoJSON. Performance Benchmarks: Up to 20x faster queries, 60% cost savings Customers like Leaf Agriculture, Dotlas, Overture and others have compared the price-performance of using Wherobots for their spatial data workloads vs other managed Spark or other leading data platforms. Subscribed to the Professional Edition, they are self-reporting up to 20x better performance (5x-20x is typical) with on-demand savings reaching as high as 60%, with even higher savings from the Enterprise Edition. Data teams are equally less limited by scaling bottlenecks. This becomes apparent after workloads finish faster on smaller WherobotsDB runtimes, and after customers realize they have significant headroom to scale well past their existing needs. “Previously, our data volumes and processing requirements were increasing faster than we could keep up with, burdening our team with costly rebuilds. Now with Wherobots, not only can we easily scale to millions of acres, we also can rest assured that our costs won’t spiral out of control.” – G. Bailey Stockdale, CEO Leaf Agriculture These results are a function of specialization and a company-wide focus; WherobotsDB was built first for processing spatial data. This intentional design obviates the typical performance bottlenecks and complexities now alive in leading data platforms and warehouses, which were first designed for purposes unrelated to processing spatial data. While the quotes from our customers matter the most, we also know how important open performance benchmarks are. But currently there are no spatial query benchmarks (or at least reputable ones), which makes query performance hard to compare across platforms without trials. It’s also hard to claim progress was made on performance when standards have not been established. We’re working on this too, and soon we will release a new open source spatial query benchmarking framework for Apache Sedona, and we will release spatial query performance results for query engines, data warehouses, and data platforms.  We already have preliminary results that compare WherobotsDB to Apache Sedona on various managed Spark engines along with query performance from engines with Spatial SQL APIs. Feel free to reach out and we can share these results when you contact us. Security & Compliance: Enterprise Grade Data Protection Wherobots is serverless and built for data security first. There’s no infrastructure to manage, although customers can also choose to run Wherobots in their AWS VPC for maximum control. Apache Sedona Expertise: Built by the Original Creators Wherobots was founded by the original creators of Apache Sedona, and Sedona is the most widely used geospatial extension for Apache Spark and in Databricks. With decades of research and experience with spatial data, open source, and cloud-scale systems, our product and team are ready to support Databricks customers’ solutions on the lakehouse. We’re also a team leading geospatial modernization efforts in open source. Wherobots has supported GEO types for years with our Havasu table format. But rather than keeping this support in-house, we decided these types would better serve the physical world in the open so we proactively drove support for them in Apache Iceberg and Parquet. When to Use Databricks Native Spatial SQL vs. Wherobots Choose Databricks Native Spatial SQL when you need: Exploratory geospatial analysis Basic spatial joins (ST_Intersects, ST_Contains, ST_Distance) Standard point-in-polygon queries Simple location-based aggregations No raster or satellite imagery processing Choose Wherobots for Databricks when you need: Production spatial intelligence workloads at scale Advanced raster and vector data processing Computer vision ML inference on satellite/aerial imagery Performance optimization (5-20x faster queries) Cost reduction (up to 60% savings on spatial compute) Planetary-scale datasets (TB to PB range) Complex spatial ETL pipelines Apache Sedona compatibility for existing workflows Get Started with Wherobots x Databricks Geospatial Analytics The lakehouse gives you the ability to choose the product best suited for the job. Don’t settle for the simple form of spatial intelligence or what the default provider offers, when complete is in reach with better economics, scale, capability, performance, and support. By integrating Wherobots into your Databricks workflows, organizations can reduce costs, improve operations, and realize new innovations powered by data from the physical world. Ready to enhance your Databricks geospatial capabilities? Get Started Here – Schedule a meeting with experts Read Documentation – Integration guide and API reference Processing spatial data in Databricks? Check out this spatial query benchmark on Databricks with SpatialBench. Frequently Asked Questions What is the difference between simple and complete spatial intelligence? Simple spatial intelligence aggregates location data into grid-based summaries such as H3 cells. These are useful for visualization but limited in precision and actionability because simplification requires tradeoffs between cost and resolution.Complete spatial intelligence derives composite risk scores, forecasts, or opportunity scores for specific assets across a region. It fuses multiple data sources including imagery, IoT, mobility, weather, and parcel data. Wherobots is built to produce the complete form at scale inside your existing Databricks environment. Why do traditional data platforms struggle with geospatial data? Most data platforms were designed for structured web and device data, not physical world data. Spatial data is inherently complex and does not fit neatly into key-based joins.The spatial extensions in platforms like BigQuery, Snowflake, and Databricks cover basic spatial SQL. They lack the raster processing, advanced spatial functions, and query planner optimizations needed for production-scale spatial workloads. When should I use Databricks native spatial SQL instead of Wherobots? Databricks native spatial SQL is a good fit for exploratory analysis, basic spatial joins, standard point-in-polygon queries, and simple location-based aggregations where no raster or imagery processing is needed.Wherobots is the better choice for production spatial workloads at scale, raster and vector data processing, computer vision ML inference on satellite imagery, and complex spatial ETL pipelines. It also fits workloads where query performance and cost matter at the terabyte to petabyte range. What is Wherobots Data Federation with Unity Catalog? Wherobots Data Federation is the integration layer that connects Wherobots Cloud directly to Databricks Unity Catalog. It allows Wherobots to read from and write to Iceberg or Delta tables governed by Unity Catalog, using Databricks service principal and OAuth or PAT token authentication. No data migration or duplicated governance controls are required. Who built Wherobots and what is the connection to Apache Sedona? Wherobots was founded by the original creators of Apache Sedona, the most widely used geospatial extension for Apache Spark and Databricks. Wherobots is the managed cloud platform built on top of Apache Sedona, extending it with enterprise performance optimizations, raster processing, and GeoAI capabilities.It maintains full API compatibility, so existing Sedona workloads run on WherobotsDB without code changes. --- ## Tutorial: How to Use GERS IDs in Wherobots for Geospatial Data Integration URL: https://wherobots.com/blog/wherobots-gers-ids-tutorial-geospatial-integration/ Updated: 2026-10-19 Introduction In the world of geospatial data, entity matching and data integration are common challenges. In this blog post, we’ll explore how to use the Overture Maps Foundation GERS IDs within Wherobots to link information about the same physical location across different datasets. Key takeawaysGERS IDs are Overture Maps Foundation persistent, unique identifiers for physical places, so the same location keeps the same ID over time and can be joined across datasets.Overture data ships with GERS IDs; most other POI, commercial, and internal datasets do not. This tutorial shows how to match a non-GERS point dataset to Overture Places and assign IDs, or flag places that have no Overture match.Two helpers are provided: gersify() for a single WKT point plus a name search string, and gersify_dataframe() for bulk matching. Matches use ST_DWithin of 500 meters, a case-sensitive name filter, and the nearest Overture place per input row.The worked example GERSifies 16,820 U.S. Starbucks locations.On a Medium Wherobots cluster the 16,000-plus-row job finished in under a minute.Once IDs are attached you can join any other GERS-keyed dataset (including other Overture themes), pull extra Overture attributes, and visualize matched vs unmatched points in SedonaKepler. What are GERS IDs? GERS IDs (Global Entity Reference System identifiers) are persistent, unique identifiers for physical places and entities in the physical world. Created by the Overture Maps Foundation, these IDs serve as a universal reference system that allows different datasets to refer to the same physical location reliably. Attributes of GERS IDs include: Persistent identification: The same physical location maintains the same GERS ID over time Cross-dataset compatibility: Enable joining and enrichment across multiple data providers Standardized reference: Provide a common language for location data across the geospatial ecosystem The Challenge: Working with Non-GERS Datasets While Overture Maps data comes with GERS IDs built in, many other datasets–open source, commercial data products, and of course internal company datasets–don’t include these identifiers. This presents a challenge: how do you match your existing location data to GERS IDs to enable integration with the broader ecosystem? At the recent Cloud Native Geospatial Summit, I co-presented with the Overture Maps Foundation team in a workshop session on GERS. My presentation focused on how to take a non-GERSified Point of Interest (POI) dataset and join it to the Overture Places dataset to assign GERS IDs to those POIs that have one. This simple process also allows users to identify those POIs that do not appear in the Overture Places dataset and thus do not have GERS IDs associated with them. This blog post is a blogified version of that workshop, presented as a tutorial. If you’d like to follow along with this tutorial, you’ll need a Wherobots Cloud account. You can sign up for a free community edition here, or sign up for a paid plan through the AWS marketplace here. Tutorial Setting Up Our Environment First, let’s initialize our Wherobots environment with the necessary libraries: from sedona.spark import * from pyspark.sql import functions as f import os config = (SedonaContext.builder().getOrCreate()) sedona = SedonaContext.create(config) Creating a GERS Matching Function The heart of our solution is a pair of utility functions that perform GERS ID matching. The first of these, gersify(), is for finding a matching point and getting the GERS ID for a single point geometry stored as a WKT or well-known-text format. It takes as input a WKT point geometry and a search string that relates to the name of the POI. This is for if you need to process a one-off. However, if you have a dataframe with many points (say, 16,000), putting this function into a loop would be incredibly slow. That’s why we have the next function. The second function, gersify_dataframe(), is for doing this same GERS matching operation on a larger scale. It takes as input a dataframe of points and a search string that relates to those points (i.e. “park” or “stadium”). Let’s examine the code for these: def gersify(point_wkt, search_param): """ Uses a point and a search string to find the closest matching GERS ID. Returns a DataFrame with the GERS ID and other attributes from Overture Maps. """ # Create a point from WKT query = f""" WITH point AS ( SELECT ST_GeomFromWKT('{point_wkt}') as point ) SELECT p.id as gers_id, p.geometry as OMF_geom, p.names.primary, p.categories.main as category, p.websites.primary as website, p.phones.primary as phone, p.geometry FROM point, places p WHERE ST_DWithin(p.geometry, point, 500, true) ORDER BY ST_Distance(p.geometry, point) ASC """ return_df = sedona.sql(query).withColumn("distance_from_point", f.expr("ST_DistanceSpheroid(geometry, point)")).cache().where(f"names.primary like '%{search_param}%'") return return_df def gersify_dataframe(df, search_param): """ Matches and add GERS ID to any dataset. Returns all rows that have a GERS ID. """ # Register the input dataframe as a temporary view df.createOrReplaceTempView("_temp_df") # For each row in the dataframe, find the closest matching GERS ID inter_query = """ WITH points AS ( SELECT id, geometry FROM _temp_df ) SELECT p.id as gers_id, p.geometry as OMF_geom, df.*, ST_DistanceSpheroid(p.geometry, df.geometry) as distance_from_point FROM points df, places p WHERE ST_DWithin(p.geometry, df.geometry, 500, true) AND p.names.primary LIKE '%Starbucks%' QUALIFY ROW_NUMBER() OVER (PARTITION BY df.id ORDER BY ST_DistanceSpheroid(p.geometry, df.geometry)) = 1 """ # Execute the query to find matches inter_df = sedona.sql(inter_query) inter_df.createOrReplaceTempView("inter_df") # Find rows that didn't match and include them in the result remaining_rows = """ SELECT NULL as gers_id, NULL AS OMF_geom, df.*, NULL as distance_from_point FROM _temp_df df LEFT ANTI JOIN inter_df i_df ON df.id = i_df.id """ return_df = sedona.sql(remaining_rows) # Combine matched and unmatched rows final_df = inter_df.union(return_df) return final_df Loading Our Dataset For this example, we’ll work with a dataset of Starbucks locations across the United States: df.count() # 16820 locations df.show() Let’s take a look at our dataset. Here are the first few rows of the result: stateaddresscategorynamewebsitephoneidgeometryCO12027 E Lincoln Ave.coffee_shopStarbucks30369033000POINT (-104.84465…)CO6424 E Hampden Ave.coffee_shopStarbuckshttps://www.starb…+130375864621POINT (-104.91555…)CO4030 S Parker Rd.coffee_shopStarbuckshttps://www.starb…+130369033002POINT (-104.80830…) Visualizing the Original Dataset Before enrichment, let’s visualize our base dataset to get an idea of what we are working with. map = SedonaKepler.create_map(df, "Original Location Dataset") map Adding GERS IDs to Our Dataset Now for the exciting part, let’s enrich our dataset with GERS IDs: # NOTE: the string search is case sensitive df_gersified = gersify_dataframe(df, "Starbucks") Let’s examine the results: df_gersified.show(20, False) gers_idOMF_geomstateaddresscategorynamewebsitephoneidgeometrydistance_from_point2fbc782d-2f1e-4aed-8c9a-38b1e71cPOINT (-104.84465408325195 3…CO12027 E Lincoln Ave.coffee_shopStarbucks30369033000POINT (-104.84465408325195 39.59344482421875)13.1902190104314783e70a787-2e92-4224-d008-f6366a17POINT (-104.91578674316406 3…CO6424 E Hampden Ave.coffee_shopStarbuckshttps://www.starbucks.com/store-locator/store/8713/+130375864621POINT (-104.91555786132812 39.65428161621094)22.779467851622873dd60478c-562e-487f-e9ae-540aa5e0POINT (-104.80859375 39.631…CO4030 S Parker Rd.coffee_shopStarbuckshttps://www.starbucks.com/store-locator/store/16430/+130369033002POINT (-104.8083038330078 39.631256103515625)25.400139164709438 Visualizing Our GERS-Enriched Dataset Let’s visualize both datasets together to see what points matched and what points did not match to anything. SedonaKepler.add_df(map, df_gersified.drop("geometry"), "OMF enrichment locations") map Key Benefits of GERS ID Enrichment By enriching our dataset with GERS IDs, we’ve unlocked several powerful capabilities: Cross-dataset integration: We can now join this Starbucks dataset with any other dataset that uses GERS IDs, such as any Overture Maps dataset or other GERS-enriched datasets. Data enrichment workflows: The GERS IDs allow us to pull in additional attributes from the Overture Maps dataset or any other dataset sharing the same identification system. Scalable processing: Using Wherobots and Apache Sedona, we can process large datasets efficiently. Our example processed over 16,000 locations in under a minute on a Medium Wherobots cluster. Conclusion GERS IDs represent a powerful tool for geospatial data integration, and Wherobots makes it easy to incorporate them into your workflows. With the functions demonstrated in this blog post, you can enrich any location dataset with GERS IDs, enabling integration with the broader geospatial data ecosystem. Want to try it yourself? Sign up for a Wherobots account and explore the full capabilities of the platform for your spatial data processing needs. Start Building with Wherobots Get Started Frequently Asked Questions What are GERS IDs? Global Entity Reference System identifiers from the Overture Maps Foundation. They are persistent, unique IDs for physical places, designed so different datasets can refer to the same real-world entity. How does Wherobots match my POIs to GERS IDs? The tutorial gersify_dataframe() function spatially joins each input point to Overture Places within 500 meters, filters on a case-sensitive name search (e.g. Starbucks), and keeps the nearest match. Unmatched rows are returned with a null gers_id. How long did the Starbucks example take? The sample dataset has 16,820 U.S. Starbucks locations. Enriching more than 16,000 locations finished in under a minute on a Medium Wherobots cluster. What do I need to follow the GERS tutorial? A Wherobots Cloud account (free Community edition or a paid plan via AWS Marketplace) and the notebook/SQL in the post. Overture Places is available in the Wherobots catalog for the join. --- ## Wherobots x Databricks URL: https://wherobots.com/partners/databricks/ Updated: 2026-10-14 Databricks Geospatial Analytics at Scale Wherobots is a spatial analytics engine that runs on your Databricks data through Unity Catalog, with no data movement and no governance changes. 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations. Start for Free Connect to Unity Catalog Your Unity Catalog Governance Stays Intact Wherobots authenticates to Unity Catalog with a Databricks service principal (OAuth or PAT). Existing access controls, table permissions, and lineage carry over. No parallel governance, no data copy. See how Wherobots connects to Unity Catalog Read Delta and Iceberg Tables, Write Results Back, No Migration Required Wherobots reads Delta and Iceberg tables directly under Unity Catalog and writes results back to Unity Catalog or Wherobots Data Hub. No ETL into a separate spatial environment. Read the Delta and Iceberg integration docs Spatial query planning built for scale WherobotsDB is a Spark and Apache Sedona compatible engine with query planner optimizations built for spatial workloads. Overture Maps processed 2.6 billion building geometries up to 20x faster after redirecting Sedona jobs to WherobotsDB. GeoPostcodes cut 39 days of processing to under one day. Review WherobotsDB Benchmarks One Engine for Vector, Raster, and Tabular Data Wherobots runs 300+ spatial functions across vector and raster data, with native Spark SQL for tabular, in one engine. Join parcel boundaries against satellite imagery against a custom CRS without moving data between tools. See the GeoPostcodes case study Run Computer Vision Models on Satellite and Drone Imagery with RasterFlow RasterFlow, the Wherobots inference engine, runs computer vision models on satellite and drone imagery at any scale. Customers have detected airplanes in satellite imagery for $2.50 and processed millions of fleet-derived traffic signs for automated map updates. No separate ML stack required. Learn about SAM3 and Rasterflow Build in SQL, Python, or Scala, No New Toolchain Required Spatial SQL, Python, and Scala through the same notebook and API surface your team already uses. Existing Apache Sedona jobs run on WherobotsDB without code changes. New spatial capability, no new toolchain. Review Unity Catalog Overview “Overture’s 2.6B-building dataset now runs up to 20x faster on Wherobots, with a simple code redirect that kept Sedona compatibility and made our team more productive.” Jennings Anderson Software Engineer with Meta for Overture “With Wherobots on AWS, we can now scale to millions of acres reliably and cost-effectively—delivering faster results and more value to our customers.” G. Bailey Stockdale CEO Leaf Agriculture “With Apache Sedona, we process millions of fleet-derived traffic signs, using scalable spatial joins and partitioning to automate map updates—enhancing Amazon Last Mile’s delivery networks for faster, more reliable routing.” Arka Pratim Das Sr. Manager, Software Development, Amazon Maps “Getting data, algorithms, and compute in one place with Spark/Sedona notebooks is a huge boost—powerful like Earth Engine, but with the control developers need to get jobs done.” John Powell Sr. Geospatial Data Engineer, AddressCloud “39 days of processing reduced to <1 day—delivering faster, more accurate population insights to our logistics and supply chain customers worldwide.” Jerome Urbain Head of Products at GeoPostcodes Built On Apache Sedona, Trusted by Fortune 500 Companies Use cases Spatial Analytics Use CasesBuilt for Scale Spatial Joins on Millions of Records for Under 50 Cents Perform spatial joins on millions of records for less than 50¢ RUN THIS NOTEBOOK GPS Map Matching at Scale Match GPS points to roads for millions of records with no APIs RUN THIS NOTEBOOK Detect Airplanes from Satellite Imagery with AI Use text prompts and AI to find airplanes in satellie imagery for $2.50 RUN THIS NOTEBOOK Frequently Asked Questions Does Wherobots work with Databricks Unity Catalog? Yes. Wherobots connects directly to Databricks Unity Catalog so you can read from and write to your existing Iceberg or Delta tables without moving data or creating a parallel governance environment. Your existing access controls and data governance policies stay intact. Do I need to migrate my data to use Wherobots with Databricks? No. Wherobots uses data federation to query your data in place inside Unity Catalog. There is no data copy and no migration required before you can run spatial queries. Can I run my existing Apache Sedona jobs on Wherobots without rewriting them? Yes. WherobotsDB is fully compatible with Apache Sedona and Spark. You can redirect existing jobs to run on WherobotsDB with zero code changes. How does Wherobots handle large spatial workloads? WherobotsDB is a Spark and Apache Sedona compatible engine with a query planner built for spatial joins and raster operations. Overture Maps processed 2.6 billion building geometries up to 20x faster after moving existing Apache Sedona jobs to WherobotsDB with no code changes. What spatial data formats does Wherobots support? Wherobots supports raster formats including GeoTIFF, Zarr, and NetCDF for satellite and sensor data, and vector formats including GeoParquet, Shapefiles, and GeoJSON for spatial geometries. Both data types are processable alongside standard tabular data in a single engine. Is Wherobots available on AWS? Yes. Wherobots is available on AWS and on the AWS Marketplace. Enterprise customers can also run Wherobots in their own AWS VPC for maximum data control and security compliance. Start Running Spatial Analytics on Your Databricks Data Spin up a free Wherobots workspace, connect Unity Catalog in minutes, and run your first spatial query on Delta or Iceberg tables. TRY NOW --- ## Raster Spatial Joins at Scale: Google Earth Engine and BigQuery vs Apache Sedona and Wherobots URL: https://wherobots.com/blog/raster-spatial-joins-at-scale-google-earth-engine-bigquery-vs-apache-sedona-wherobots/ Updated: 2026-10-19 If you are deciding between Google Earth Engine + BigQuery and Apache Sedona + Wherobots for large-scale geospatial analysis, here is the short answer: Wherobots completed a statewide zonal statistics analysis across every building in Texas in 3 minutes 28 seconds. BigQuery timed out on the same query. For a Dallas metro area test using the same datasets, Apache Sedona finished in 37 seconds vs BigQuery’s 8 minutes 24 seconds, making it 13x faster. And before BigQuery could even run the spatial join, filtering the global dataset down to a single bounding box took 58 minutes and 50 seconds. Key takeawaysApache Sedona via Wherobots is 13x faster than BigQuery for large-scale zonal statistics on a metro-area datasetBigQuery with Google Earth Engine could not complete a state-scale spatial join without timing out; Wherobots finished the same job in under 4 minutesApache Sedona reads directly from cloud storage (S3, STAC) with no data migration required; BigQuery requires importing data into Google Cloud firstApache Sedona supports 300+ spatial functions; BigQuery offers 71, with ST_REGIONSTATS as the only raster-vector functionFor production pipelines at scale, Wherobots wins on speed, flexibility, and cost of data movement. Google Earth Engine remains useful for exploratory, one-off analysis within its own dataset catalog This post breaks down why that gap exists, what it means architecturally, and when each platform actually makes sense for your workload. What is Zonal Statistics Analysis and Why Does Scale Matter? A zonal statistics analysis is one kind of result of a spatial join between a raster dataset and a vector dataset. This analysis can return things like: sum: Sum of the pixel values in a zone mean: Arithmetic mean of those values min or max: Limit values of the pixels in the zones For example, we could use vector boundaries of postal codes to find the average elevation from a raster: Imagine that you want to take a study area, maybe a specific bounding box or metro area, and understand the dominant land classification in that area. In this case, each grid square in the raster might have a value like ”water” or “trees” and you want to find the classification with the maximum count in each of your vector areas. At a small scale this kind of analysis is relatively easy for one-off work. There are a few engines that allow you to do this. Shapely/GeoPandas and Rasterio are three commonly used Python libraries used together to do this. PostGIS, which includes spatial SQL functions to work with raster and vector data, extending PostgreSQL with spatial functionality. Google Earth Engine, which includes the ability to perform zonal statistics and now add support to perform calculations with vector data inside BigQuery. Apache Sedona, which provides a functional layer to perform distributed spatial queries using Apache Spark and other engines. However, there are plenty of use cases where you do want to do this at large scale: Understand the land classification across thousands, hundreds of thousands, or even millions of individual buildings or properties. Analyze climate or weather data in small or large scale areas over time. Get up to date fire risk using global or country specific data. Calculate and update flood risk across thousands of properties by analyzing the height above nearest drainage points. These data sets have the potential to add massive value to analytical workflows for many industries and sectors. Unfortunately, the Python and PostGIS approaches are difficult to scale effectively. While they work up to a point, they run on a single compute instance and therefore will only scale as far as the computing power and memory of that machine. So how can you do this at scale and without disrupting your existing architecture? Let’s look at the two cloud options, Apache Sedona and Google BigQuery. How Google Earth Engine + BigQuery Handles Large-Scale Spatial Joins (And Where It Struggles) Apache Sedona and Google Earth Engine both provide solutions when you need to process larger amounts of data. Google Earth Engine, originally created in 2009, generally stores its raster data in multi-resolution pyramids in data that is not directly exposed to the user via a proprietary library. Google Earth Engine does store some vector data and it’s distributed in a similar format via the libraries themselves. In Google Earth Engine you can access planetary scale data and analyze it for small and large scale problems without the need to download the data on your computer. In recent years, Google has started to expand the capabilities for Earth Engine to integrate with the Google Cloud Suite of products, most notably BigQuery. BigQuery is an online analytical processing (or OLAP) data warehouse that allows you to store massive amounts of long-form data and analyze it efficiently using distributed computing. It uses a proprietary storage format that allows it to quickly distribute workloads across data that’s stored in the Google Cloud architecture. The downside of this proprietary format is that you must import your data into BigQuery before leveraging the distributed computing resources that make it powerful. BigQuery makes it possible to calculate zonal statistics using Earth Engine data, but unfortunately that geospatial data does not reside in the same proprietary, fast format. (this differs from the approach with Wherobots and Apache Sedona outlined later in the post). Recently, BigQuery added the function ST_REGIONSTATS that allows you to directly integrate BigQuery SQL with datasets from Earth Engine. All in all, this workflow is great for traditional tabular analytics if you already have or are planning to migrate data into BigQuery. However, if you want to leverage open formats, Apache Sedona and Wherobots allow you do do that at scale with open core tooling. How Apache Sedona + Wherobots Handles the Same Problem Apache Sedona is a distributed computing framework that brings spatial functionality into the Apache Spark ecosystem. It allows you to work with large-scale datasets, both vector and raster, and combine them into new datasets using zonal statistical functions. It uses an underlying distributed computing framework that allows you to distribute work in parallel, allowing you to scale up to planetary scale computational workloads. A key to Sedona’s scalability is that it allows you to leave the data where it sits. Many exabytes of raster data are already in an accessible storage format on the web and Sedona lets you leave that data there without spending the time or money needed to copy it yourself. This means that there are no proprietary formats, no data ingestion, and no extra steps to actually start working with this data. Platform Comparison: Apache Sedona + Wherobots vs Google Earth Engine + BigQuery Here’s how the two approaches compare across key technical and operational dimensions: Apache Sedona & WherobotsGoogle Earth Engine & Big QueryOpen formats✅ Works with standard formats like Cloud-Optimized GeoTIFF; no vendor lock-in⚠️ Data needs to be ingested into BigQuery, internal proprietary storage for vector and raster dataNo ETL needed✅ Reads directly from remote raster sources like S3 or STAC endpoints without importing❌ Only works with supported Google Earth Engine datasets and data stored in Google Cloud StorageScalable✅ Distributed compute + open-source stack enables scaling from local to cloud✅ Good for one-off, small to mid-scale analysesSpatial function support✅ Over 300 raster and vector functions supported in Apache Sedona⚠️ ST_REGIONSTATS is the only raster/vector function; 71 total spatial functions in BigQueryCloud-native✅ Fully supported cloud environment in AWS (GCP coming soon)✅ Integrated with Google Cloud; Easy to use if your stack is already in GCP To scale zonal statistics queries even more, Wherobots only materializes the values or pixels of raster data it needs. Not only does this save time on the computational workload, but it also eliminates a significant amount of moving data back and forth, which adds time and cost in other systems. Benchmark Results: Wherobots vs Google Earth Engine + BigQuery Using ST_RegionStats in BigQuery via Google Earth Engine To compare the two systems I used a common open dataset to analyze land classification near buildings in Texas. This analysis can help determine if a building is in a built-up urban environment or if it is an area with different natural resources. I used the WorldCover dataset from the European Space Agency, which contains land cover data across the entire globe. The data is in AWS S3 storage as an open dataset here, as well as Google Earth Engine. For the buildings, I used the Overture Maps dataset, which contains building footprints for the entire globe. Overture data is in both the Wherobots Data Hub and the BigQuery Open Data project. Initially, I tried to compare the query speed for every building in Texas. Wherobots finished in about 3½ minutes, but BigQuery continued to time out after several attempts. To scale back my test, I focused on buildings in a small area around Dallas, Texas. Each building was buffered by 30 meters to ensure that we are looking at the area around the buildings, not just the footprint. To make this query work, I first needed to enable Earth Engine in BigQuery in the Google Cloud console, including: Activating the Earth Engine API Adding in required permissions for my project Locating and subscribing to the required Raster dataset via the Analytics Hub Below is the code that I used to run this for the Overture Maps data in BigQuery. WITH texas AS ( SELECT st_buffer(geometry, 30) as geometry, id FROM PROJECT.DATASET.overture_texas where st_intersects(geometry, st_geogfromtext('POLYGON((-97.000482 33.023937, -96.463632 33.023937, -96.463632 32.613222, -97.000482 32.613222, -97.000482 33.023937))')) ) SELECT t.geometry, t.id, ST_REGIONSTATS( t.geometry, (SELECT assets.image.href FROM PROJECT.DATASET.landcover ), 'Map' ).mean as mean FROM texas AS t ORDER BY mean DESC; You can use the existing Overture Maps data in BigQuery, however I recommend making a new table with just the data you need for the analysis. Using a WHERE statement to filter the global Overture Maps table to the small bounding box took 58 minutes and 50 seconds. You can view the complete guide for doing this in GCP here. Using Apache Sedona and Wherobots Using Apache Sedona and Wherobots we can efficiently load in both the ESA WorldCover data from AWS S3 open data using built-in functions to read a Spatio-Temporal Asset Catalog (or STAC) endpoint that has an API to read large collections of raster data. Click here to launch this interactive notebook Launch Notebook stac_df = sedona.read.format("stac").load( "" ) stac_df.printSchema() Alternatively, we can also load this directly from the S3 data source, as you can see here which is automatically retiled which sets up nicely to create our tiled out-of-database raster dataframe, which we can then turn into an Iceberg table to use in the future: esa = sedona.read.format("raster")\\ .option("retile", "true")\\ .load("s3://esa-worldcover/v200/2021/map/*.tif*") esa.createOrReplaceTempView("esa_outdb_rasters") YOUR_CATALOG_NAME = 'my_catalog' # Persist as a raster table in Iceberg sedona.sql(f""" CREATE OR REPLACE TABLE wherobots.{YOUR_CATALOG_NAME}.esa_world_cover AS SELECT * FROM esa_outdb_rasters """) # ✅ Out‑DB raster table created! From here I can set up my zonal stats query using the function RS_ZonalStatsAll which will actually return a STRUCT of all the stats instead of just the selected one as BigQuery does. The values included are: count: Count of the pixels. sum: Sum of the pixel values. mean: Arithmetic mean. median: Median. mode: Mode. stddev: Standard deviation. variance: Variance. min: Minimum value of the zone. max: Maximum value of the zone. zonal_stats_df = sedona.sql(f""" SELECT p.id, RS_ZonalStatsAll(r.rast, p.buffer, 1) AS stats FROM wherobots.{YOUR_CATALOG_NAME}.texas_buildings p JOIN wherobots.{YOUR_CATALOG_NAME}.esa_world_cover r ON RS_Intersects(r.rast, p.buffer) """) # ✅ Zonal stats computed! With this query, you could choose to write the results to an Iceberg table, or you could choose to persist them to files. In this case, I chose to persist these to files for our test. zonal_stats_df.write \\ .format("geoparquet") \\ .mode("overwrite") \\ .save(user_uri + "/results")") And that’s it. You don’t need to move any data, download anything, or spin up any additional services apart from the notebook to run this process. Results The performance gap between the two platforms was significant at both scales tested. Test 1: All of Texas The first test that I ran tried to intersect all of the Overture Maps buildings in the state of Texas against this global raster dataset. With Wherobots, I ran the iteration seven times, writing the complete dataset to disk each time. The results for the iterations were: 3 minutes 28 seconds (average for each iteration) ± 25.9 s per iteration (mean ± std. dev. of 7 runs, 1 loop each) BigQuery was unable to finish the test without timing out. Test 2: One city For this test, I limited the query to a bounding box in the area of Dallas shown below. POLYGON((-97.000482 33.023937, -96.463632 33.023937, -96.463632 32.613222, -97.000482 32.613222, -97.000482 33.023937)) For this smaller area, the BigQuery computation ran in 8 minutes and 24 seconds. Below are the results in Wherobots using the smaller area: 37.4 seconds (average over 7 iterations) ± 1.78 s per iteration (mean ± std. dev. of 7 runs, 1 loop each) Performance Summary AreaBigQueryWherobotsState of TexasN/A (timed out)3m 28sDallas, Texas metro area8m 24s37s When to Use Apache Sedona + Wherobots vs Google Earth Engine The benchmark results make the performance case clearly. But there are architectural reasons to consider Sedona and Wherobots beyond raw speed. Performance and scale Sedona scales horizontally using distributed compute across Apache Spark, with strategic partitioning and adjustable runtime size to handle metro, national, or global workloads. Apache Sedona supports 300+ raster and vector functions, compared to BigQuery’s single raster-vector function, ST_REGIONSTATS. That function coverage matters when building full analytical pipelines, not just one-off queries. Wherobots includes job management for scheduled, repeatable runs, which matters when your raster datasets change over time, such as fire risk, flood risk, or land cover updates. Architecture and flexibility Sedona reads directly from remote cloud storage like AWS S3 or STAC endpoints without copying data into a proprietary system. BigQuery requires data to live inside Google Cloud before its distributed compute kicks in. You are not limited to Earth Engine’s dataset catalog. Any open dataset accessible via cloud storage works with Sedona without ingestion or reformatting. The stack is open core. You can run Apache Sedona locally to prototype, then move to Wherobots for production without rewriting your analysis. For teams evaluating Google Earth Engine + BigQuery against Apache Sedona + Wherobots for production geospatial workloads, the benchmark is clear. At metro scale, Sedona is 13x faster. At state scale, BigQuery could not finish the job. If your data lives outside Google Cloud, or you need more than one raster-vector function, or you need repeatable scheduled pipelines, Wherobots is the stronger architectural choice. Google Earth Engine remains a capable tool for exploratory analysis within its own catalog. Try the interactive notebook Get Started Frequently Asked Questions How much faster is Wherobots than BigQuery for zonal statistics? On the Dallas metro test, Wherobots averaged 37 seconds versus BigQuery 8 minutes 24 seconds, about 13x faster. Statewide Texas completed in 3 minutes 28 seconds on Wherobots; BigQuery timed out. Why did BigQuery time out on the Texas-scale join? The post reports repeated timeouts on the full-state building-to-WorldCover join. The architecture also requires data in Google Cloud: filtering global Overture buildings to the Dallas bbox alone took 58 minutes 50 seconds before the spatial join ran. Do I have to ingest rasters into Wherobots before a zonal stats query? No. Apache Sedona reads Cloud-Optimized GeoTIFFs from S3 and STAC endpoints in place (the ESA WorldCover example uses a Terrascope STAC collection or s3://esa-worldcover). You can persist tiles as an out-DB Iceberg raster table if you want, but it is not required to start. When should I still use Google Earth Engine? The post positions Earth Engine as a capable tool for exploratory, one-off analysis within its own catalog. Choose Wherobots/Sedona when you need repeatable production pipelines, open formats, data that lives outside GCP, or more than BigQuery single raster-vector function. --- ## Security URL: https://wherobots.com/security/ Updated: 2026-05-12 Security, Privacy, and Compliance Spatial data can be some of the most sensitive in your organization. Data security is our top priority. Visit our Trust Center Private, secure, and compliant from day one. Built to meet enterprise data privacy standards Hosted on AWS, in our accounts or in yours Fully SOC2 and GDPR compliant Private, secure, and compliant from day one. Secure by design Security is not just a feature. It’s part of our engineering culture and infused into how we design and build our software, our internal systems, and our production environments. Wherobots is built from the ground up with the security of your data and your workloads in mind. Control-compute separation Wherobots’ cloud-native architecture provides strong separation between its control plane, and its multi-cloud and multi-region compute plane. The control plane is managed by Wherobots and runs in Wherobots’ AWS account, within a private Wherobots network. It is a cloud-hosted system that manages authentication, users, business logic, and access to the service via its web interface and APIs. Your data does not pass through nor is it stored in the control plane. The compute plane is serverless to users, fully managed by Wherobots, and is deployed to multiple cloud regions supported by Wherobots or a BYOC account. It powers customer workloads, each isolated from the cloud hypervisor up to create a trusted environment for your data, and privately connects to your cloud buckets and data sources. Saas Serverless BYOC Want to bring your own cloud account? Wherobots Cloud is serverless by default, but can also run its compute plane in your own cloud VPC in Bring-your-own-cloud-(account) deployments. If you’re interested, or have requirements for a BYOC deployment option, please contact us. Contact Us Infrastructure and network security Cloud providers Wherobots compute and control planes are currently hosted on AWS. By using AWS, Wherobots inherits all the physical and logical security and compliance features built into AWS’s datacenters, network, and infrastructure. The list of our current compute plane regions is available in our documentation. If you need compute presence close to your data in other cloud provider regions, please tell us by filling in this form. Networking The control plane and compute plane network infrastructure is managed by Wherobots. Wherobots maintains network isolation between customer workloads. Connectivity between a compute plane region and the control plane is secure, private, and encrypted. By default, Wherobots uses VPC Gateway endpoints to ensure connectivity between the compute plane and your Amazon S3 buckets is private and never leaves the AWS cloud network. Encryption All network traffic, including traffic between VMs within the compute plane1 and connections with private and public data sources, is encrypted in transit. Wherobots uses network attached storage with virtual machines and cloud object storage. When data is at rest, it is always encrypted using an encryption key provided and managed by a cloud provider (e.g. AMS KMS). Access control Wherobots prioritizes the security and integrity of customer data and security practices are integrated throughout all business operations. All employees and operators must use dedicated user accounts, and use Google SSO combined and MFA everywhere available. This reduces the risk of unauthorized access, prohibits credential sharing, limits elevated permissions effectively, and provides traceability of access. Only specific employees requiring data access for support purposes have such permissions, and all access is logged. User permissions and access are continuously reviewed to maintain alignment with current roles and access requirements. These reviews, conducted both manually and through automated compliance tools, swiftly identify and resolve any unnecessary or outdated access. Customers must follow robust password guidelines to ensure strong credentials are used to log into the Wherobots Cloud platform. Additionally, Wherobots offers SSO support via SAML, allowing customers to utilize their existing identity providers for secure, seamless authentication. Customers retain complete control over their configurations. Wherobots uses Identity and Access Management (IAM) cross-account roles to ensure granular, least privilege access to customer-owned cloud resources. Third-party audits Wherobots undergoes SOC 2 compliance audits and has obtained its SOC 2 Type 2 attestation. Penetration testing is performed regularly by an independent third-party. Any findings from the penetration testing are immediately investigated by Wherobots’ security and engineering teams, and remediated according to their severity. The latest penetration testing report can be shared on request. Email and DNS security Wherobots implements all currently available best practices for email security and spoofing prevention with DMARC and DKIM. Automated emails produced by Wherobots systems are sent via AWS SES or via Hubspot, both of which are explicitly authorized to send emails on our behalf. All domain name service zones for Wherobots domains are managed by AWS Route 53, inheriting the security and auditability capabilities of AWS services. Business continuity and disaster recovery Wherobots has an established Business Continuity and Disaster Recovery plan to ensure that both our business and our product offerings deliver high availability and resilience to our end users. All business data is securely stored and backed up by our service providers. All customer data and metadata is stored in version controlled S3 buckets with high availability and S3’s renowned extreme durability, and backed up in a separate AWS region. Backup and recovery procedures are frequently exercised to provide a sub-24h RTO. Wherobots runs regular business continuity and disaster recovery scenarios to plan for unforeseen events and test its disaster recovery procedures. These events include but are not limited to loss of key personnel, degradation of key infrastructure, and operational force majeure events. The remediations for these possible events are discussed annually. Corporate security Wherobots incorporates comprehensive technical and operational safeguards to protect your data and ensure uninterrupted service availability. We maintain transparency in our security practices, consistently aiming to surpass industry standards. All corporate devices are secured through Mobile Device Management (MDM), ensuring compliance with our security standards. Advanced malware and anti-virus software are deployed and regularly updated to counter evolving threats. Full disk encryption safeguards data stored on all corporate devices. Strong password policies and automatic screen locks further minimize unauthorized access risks. Employees complete security and privacy awareness training during onboarding and annually thereafter, ensuring adherence to current security best practices. All employees undergo thorough background checks. Our security team continuously monitors the cloud environment, supported by real-time threat protection tools and proactive incident response strategies. Cloud Security Posture Management (CSPM) tools continuously track for and respond to anomalies or unusual activities. Physical access to Wherobots offices is strictly controlled through a badge system, ensuring entry is limited to authorized personnel only. Responsible disclosure Security researchers are encouraged to responsibly disclose vulnerabilities and security issues to Wherobots’ security team at security@wherobots.com with a working proof of concept. Wherobots does not have a bug bounty program at this time. 1 In AWS, Wherobots uses Amazon EC2 Nitro instances that encrypt data in transit between VMs   Visit our Trust Center TABLE OF CONTENTS Infrastructure and network securityCloud providersNetworkingEncryptionAccess controlThird-party auditsEmail and DNS securityBusiness continuity and disaster recoveryCorporate securityResponsible disclosure --- ## Dekart Supports Wherobots as a Spatial SQL Engine URL: https://wherobots.com/blog/dekart-supports-wherobots-as-a-spatial-sql-engine/ Updated: 2026-10-19 We’re excited to announce that Dekart now supports WherobotsDB as a spatial SQL engine, enabling you to execute high performance spatial queries while rapidly visualizing query results on a map all within the Dekart platform. Key takeawaysDekart, a Kepler.gl-based geospatial analytics app (managed or self-hosted), now runs Spatial SQL against WherobotsDB and renders results as shareable interactive maps in the browser.Using Wherobots as the engine, teams can join, transform, and filter planetary-scale spatial data in S3 up to 20x faster and more efficiently than other cloud lakehouse engines. They then visualize without exporting files or standing up a GIS stack.The lakehouse pattern keeps data in your S3/Iceberg tables. Re-run the SQL when mobility traces, field boundaries, routes, or outage layers change daily or hourly, and the map updates with no ETL into a warehouse to draw it.A telco example joins call records to a hex grid and applies Getis-Ord Gi* hotspot analysis. It maps statistically significant dropped-call clusters in the San Francisco Bay Area from the Dekart SQL editor.Wherobots also embeds Kepler.gl/Deck.gl in notebooks, supports Apache Superset dashboards, has QGIS integration in alpha, and can emit VTiles/PMTiles for MapLibre, Leaflet, or other WebGL renderers. If you’d like to skip the blog post and jump right in, you can follow our Getting Started Guide here. What is Dekart? Dekart is a geospatial analytics application, available as a managed platform or self-hosted, that turns SQL queries into shareable, interactive maps. It glues a slim Golang backend onto the Kepler.gl library, letting analysts connect directly to their cloud data warehouse and visualize millions of rows without exporting files or writing code. Dekart gives data teams a fast path from SELECT… to a production-ready map, without the overhead of proprietary GIS stacks like ESRI or heavyweight desktop software. If your spatial analysis already lives in SQL, Dekart is a practical, lightweight way to visualize and share it, all from your browser. How the Wherobots-Dekart integration shines This integration allows customers to use Wherobots as the query engine to create visualizations in Dekart. Here’s why the combination matters. Price-performance: By using WherobotsDB as a spatial SQL engine to query data in S3, you can join, transform, and filter planetary-scale spatial datasets up to 20x faster and more efficiently than other lakehouse engines in the cloud. This efficiency boost improves performance and reduces compute costs. Easy visualization: Working from Dekart’s SQL editor, you can rapidly execute Spatial SQL queries against WherobotsDB, and visually interact with the results in Dekart’s interactive map experience. Modern lakehouse architecture: With the combination of Dekart and Wherobots, you can create powerful map-based visualizations from spatial data that sits securely in your S3 bucket. The Wherobots modern lakehouse architecture eliminates the need for ETL to a large data warehouse just to process or visualize location data. This architecture is especially powerful for teams who work with large, dynamic spatial datasets such as: Mobility traces from GPS or cell towers Field boundaries from drone or satellite imagery Delivery routes and transportation networks Infrastructure assets, outage zones, and signal maps These datasets can often change daily or hourly. With the integration between Wherobots and Dekart, you don’t need to rebuild maps from scratch. Just re-run your Spatial SQL query and get an updated visualization from the versioned data in your cloud lakehouse. This is what turns Kepler.gl from a static exploration tool into a repeatable, enterprise-grade intelligence system for the physical world. And because both Wherobots and Dekart are built on open standards and open source foundations (Sedona, Iceberg, Kepler), you’re not locked into a proprietary GIS ecosystem. Real-World Use Case: Telco Network Optimization Spatial data is the underpinning of the telecommunications industry. From cell tower coverage to network congestion to user demand mapping, telcos generate a continuous stream of location-rich telemetry. This data is used for maintaining quality of service, rolling out infrastructure, and responding to outages. But processing this much data at scale and making sense of it often presents a challenge. Many telcos already use Apache Sedona in data lakehouses like Databricks to process call records, analyze tower placement, and perform network optimization. These workloads can involve billions of records and highly complex spatial joins. Look no further than how Comcast is using Apache Sedona here. With Wherobots and Dekart, telco data teams can now take this one step further: Run complex spatial queries directly on cloud-native Iceberg tables, powered by Wherobots as your spatial SQL engine Visualize cell coverage, signal drop zones, or congestion patterns instantly in Dekart Layer in cluster analysis, such as Getis-Ord Gi* (G-star) statistics, to detect statistically significant hot spots and cold spots Iterate quickly, comparing performance before and after tower optimizations Share insights easily with planners, engineers, and execs—no GIS software required Here’s an example:A network operations team wants to analyze dropped call patterns across the San Francisco Bay Area. They write a Spatial SQL query in Wherobots that joins call records to a hex grid, then apply Getis-Ord Gi* to identify statistically significant clusters of poor performance. Within seconds, Dekart renders the output as an interactive map—highlighting not just where drop-offs occur, but where they represent systemic problems. No exporting data. No manual mapping. Just fast, repeatable insights from data about the physical world. Process data with Wherobots SQL Spatial Engine, and customize how its visualized Historically, you would use the same platform to both process and visualize spatial data. This often resulted in mediocre performance on both of those tasks. At Wherobots, we believe that the optimal workflow is having a dedicated spatial data processing platform (like Wherobots) that you can pair with the visualization tool that works best for your use case. That’s why we are particularly excited by this integration with Dekart. It gives our users yet another in our growing list of visualization tools they can layer on top of Wherobots to support their day-to-day spatial workflows. We believe that the modern spatial stack should use the best-in-class tool for each step in a spatial workflow. In this case, Wherobots for spatial data processing and querying, Dekart and other solutions for visualizing on a live map. That’s why we support: Kepler.gl and Deck.gl maps and visualizations embedded within our notebooks Apache Superset for building dashboards from spatial data QGIS for traditional desktop GIS users who want the processing power of Wherobots (coming soon, currently in Alpha) We also allow users to generate VTiles (a type of map tile from vector data) from any spatial dataset using SQL. Those tiles can be exported as PMTiles–a performant, portable, cloud-native tile format for serving map tiles. These PMTiles can be used with MapLibre, Leaflet, or any WebGL tile renderer. Ready to Level Up Your Spatial Intelligence? Start Today. Whether you’re optimizing communication networks, mapping field boundaries, analyzing human movement, or publishing public map layers, Wherobots and Dekart provide a fast path for converting spatial data into insights. Create your Wherobots account here. Getting Started To get started with Wherobots and Dekart, you can follow our Getting Started Guide here. Or for a quick view of what’s involved, take a look at this video where Dekart founder Volodymyr Bilonenko walks through connecting Dekart to Wherobots and running a query. Let’s build the next generation of intelligence for the physical world. Start Building with Wherobots Get Started Frequently Asked Questions What is Dekart? A geospatial analytics application, offered as a managed platform or self-hosted, that turns SQL into shareable Kepler.gl maps. A slim Golang backend lets analysts connect to a cloud warehouse or Wherobots and visualize millions of rows in the browser. What does the Wherobots-Dekart integration do? Dekart uses WherobotsDB as the spatial SQL engine. You write Spatial SQL in Dekart, Wherobots processes data in your S3 lakehouse, and Dekart maps the result. The post cites up to 20x faster joins/filters than other cloud lakehouse engines. Can I use this for telecom network optimization? Yes. The post walks through telco telemetry: cell coverage, congestion, dropped calls. An example analyzes Bay Area dropped-call patterns with a hex grid and Getis-Ord Gi* hotspots, then renders the map in Dekart without a GIS desktop. How do I connect Dekart to Wherobots? Follow the Getting Started Guide linked in the post, or watch the video of Dekart founder Volodymyr Bilonenko connecting Dekart and running a query. You will need a Wherobots account. --- ## Exploring the Foursquare Open Places Data with Wherobots URL: https://wherobots.com/blog/exploring-the-foursquare-open-places-data-with-wherobots/ Updated: 2026-10-19 Introduction At Wherobots, we’re excited to offer access to the Foursquare Open Places dataset through the Wherobots Global Hub. We maintain a pipeline to keep this dataset updated along with the Foursquare releases. In this tutorial, we’ll show you how to work with Foursquare’s Open Places dataset using Wherobots. We’ll demonstrate how to access, query, and visualize Points of Interest (POI) data, culminating in aggregating and visualizing the data as a choropleth map. Key takeawaysFoursquare Open Places is in the Wherobots Open Data Catalog as two tables, places and categories, kept current with Foursquare releases. You can pin a snapshot with VERSION AS OF (example: dt=2025-02-06) or read the latest by default.A catalog query in the tutorial counted 104,635,092 places; 67,380,672 had addresses, 92,959,858 had category labels, and 98,436,217 were still open (date_closed IS NULL).Filter with ordinary SQL (country = US) or with a spatial predicate such as ST_Contains against any polygon: census blocks, trade areas, or a San Francisco WKT. The same ST_Contains pattern scales to joining all 104 million places into many polygons.The worked example maps San Francisco coffee shops by neighborhood: Financial District 186, South of Market 119, Inner Richmond about 37, Presidio around 10. Top SF primary categories include Office (6,069) and Tech Startup (3,615).Places are community-updated through Foursquare Placemaker Tools. Follow along in the example notebook under the Wherobots Jupyter examples folder on a free instance. The overall process we will show is applicable to many different use cases; for this tutorial we will use it to analyze coffee shops across San Francisco and see how they are distributed by neighborhood. If you would like to follow along, you can spin up a free instance here and access this notebook for yourself in the Wherobots Jupyter Notebook environment under the examples folder. Let’s dive in. What is the Foursquare Places Dataset? Foursquare’s Places dataset is a comprehensive global collection of points of interest (POIs) containing over 100 million locations worldwide. What makes this dataset particularly valuable is that it’s continuously updated and verified through Foursquare’s Placemaker Tools, which enable community contributions to maintain accuracy. The dataset includes details such as: Business names and locations Categories and classifications Address information Social media links Opening dates and closure information Tutorial To follow along with this tutorial, you’ll need a Wherobots account. You can sign up for free at Wherobots.com. Setting Up the Environment First, let’s set up our Sedona context in Wherobots. This will start up our spark-based compute environment and give us access to the geospatial functions we need to work with the Foursquare dataset. from sedona.spark import * config = SedonaContext.builder().getOrCreate() sedona = SedonaContext.create(config) Exploring the Foursquare Data in Wherobots The Foursquare data is already accessible in the Wherobots Open Data Catalog, so there’s no need to download or import it separately. Let’s check what tables are available: sedona.sql("SHOW tables IN wherobots_open_data.foursquare").show(truncate=False) +----------+----------+-----------+ |namespace |tableName |isTemporary| +----------+----------+-----------+ |foursquare|categories|false | |foursquare|places |false | +----------+----------+-----------+ There are two tables: places which contain the actual locations, and categories which provide the classification system. Let’s look at the schema of the places table: sedona.table("wherobots_open_data.foursquare.places").printSchema() You’ll get a result that looks something like this: root |-- fsq_place_id: string (nullable = true) |-- name: string (nullable = true) |-- latitude: double (nullable = true) |-- longitude: double (nullable = true) |-- address: string (nullable = true) |-- locality: string (nullable = true) |-- region: string (nullable = true) |-- postcode: string (nullable = true) |-- admin_region: string (nullable = true) |-- post_town: string (nullable = true) |-- po_box: string (nullable = true) |-- country: string (nullable = true) |-- date_created: string (nullable = true) |-- date_refreshed: string (nullable = true) |-- date_closed: string (nullable = true) |-- tel: string (nullable = true) |-- website: string (nullable = true) |-- email: string (nullable = true) |-- facebook_id: long (nullable = true) |-- instagram: string (nullable = true) |-- twitter: string (nullable = true) |-- fsq_category_ids: array (nullable = true) | |-- element: string (containsNull = true) |-- fsq_category_labels: array (nullable = true) | |-- element: string (containsNull = true) |-- placemaker_url: string (nullable = true) |-- geometry: geometry (nullable = true) |-- bbox: struct (nullable = true) | |-- xmin: double (nullable = true) | |-- ymin: double (nullable = true) | |-- xmax: double (nullable = true) | |-- ymax: double (nullable = true) The schema includes fields like fsq_place_id, name, latitude, longitude, address, country, fsq_category_labels, and more. Importantly, it also includes a geometry field that we can use for spatial operations. Working with Versions Wherobots provides access to multiple versions of the Foursquare data. You can select a specific version using the VERSION AS OF clause: sedona.sql("SELECT * FROM wherobots_open_data.foursquare.places VERSION AS OF 'dt=2025-02-06'").show(5, truncate=True) If you don’t specify a version, you’ll get the latest one by default. Basic Analysis of the Dataset Let’s start by selecting the columns we’re interested in: places_df = sedona.sql(""" SELECT fsq_place_id, name, geometry, fsq_category_labels, country, date_refreshed, date_created FROM wherobots_open_data.foursquare.places WHERE date_closed IS NULL AND name IS NOT NULL AND geometry IS NOT NULL AND country IS NOT NULL """) places_df.createOrReplaceTempView("places") Now, let’s run a quick query to see what we’re working with and get some basic stats: sedona.sql(""" SELECT COUNT(*) as total_places, COUNT(CASE WHEN name IS NOT NULL THEN 1 END) as has_name, COUNT(CASE WHEN address IS NOT NULL THEN 1 END) as has_address, COUNT(CASE WHEN fsq_category_labels IS NOT NULL THEN 1 END) as has_categories, COUNT(CASE WHEN date_closed IS NULL THEN 1 END) as still_open FROM places """).show() When you run the above query, you’ll get a result like this: +------------+---------+-----------+--------------+----------+ |total_places| has_name|has_address|has_categories|still_open| +------------+---------+-----------+--------------+----------+ | 104635092|104635092| 67380672| 92959858| 98436217| +------------+---------+-----------+--------------+----------+ That’s over 104 million places in the dataset. About 67 million have addresses, and nearly 93 million have category labels. That’s an impressive dataset. Filtering by Region Let’s narrow our focus to a specific region. We can first use standard SQL to filter to the United States: us_df = sedona.sql(""" SELECT * FROM places WHERE country = 'US' """) This approach using standard SQL works well for cases where the region you want to filter for is already defined in the dataset. For example, the dataset has a country column, so we can filter by country. But what if we wanted to filter by a geographic region that isn’t already defined in the dataset? For example, maybe we want to filter by census block groups, cities, or internal company polygons that we have defined for trade areas. That’s where the power of spatial joins in Wherobots comes in. We can define any arbitrary polygon and use it to filter the data. Note that the actual polygon is a very long WKT string, so we truncate it here in the example code. But the full WKT polygon is defined in the notebook itself for you to access. As an alternative you could use other open boundary datasets, such as within the Overture Divisions dataset and join the Foursquare places against those divisions. # Define a polygon for San Francisco SF = "MULTIPOLYGON (((-122.4773830027518 37.8110279985324, ...))" # Filter to places within San Francisco sf_df = sedona.sql(f""" SELECT * FROM places WHERE ST_Contains( ST_GeomFromWKT('{SF}'), geometry) """) Now we have just the places located within San Francisco. I know that filtering the data for a single polygon may not be a huge task by itself, but where you really start to see the power of Wherobots is when this scales up. We could just as easily spatially join all 104 million places in the dataset into a million different polygons (buildings, cities, counties, senate districts, zip codes, etc…) based on which polygon a point falls within–and we could use that exact same ST_Contains function to do so. Visualizing the Data Wherobots includes built-in visualization capabilities through SedonaKepler. Let’s create a simple map of our San Francisco places: sf_map = SedonaKepler.create_map(sf_df, "Places") We can see from the image that there are POIs clear across San Francisco, with a dense concentration of places in the Financial District downtown. Searching for Specific Places Now say we want to search for specific places such as a brand or retail chain. For example, perhaps we want to find all Starbucks locations in San Francisco. To do so we can use the following query: sbux_df = sedona.sql(""" SELECT * FROM sf_places WHERE LOWER(name) = 'starbucks' """) sbux_map = SedonaKepler.create_map(sbux_df, "Starbucks in San Francisco") Exploring Categories The Foursquare data uses a hierarchical category system. Let’s see what categories are most common in our San Francisco dataset: sedona.sql(""" SELECT fsq_category_labels[0] as primary_category, COUNT(*) as count FROM sf_places GROUP BY fsq_category_labels[0] ORDER BY count DESC LIMIT 20 """).show(truncate=False) Here are the top categories in San Francisco by count: Primary CategoryCountNULL8597Business and Professional Services > Office6069Business and Professional Services > Office > Tech Startup3615Community and Government > Residential Building > Apartment or Condo2505Health and Medicine > Physician > Doctor’s Office2439Landmarks and Outdoors > Structure2048Business and Professional Services > Health and Beauty Service > Hair Salon1492Arts and Entertainment > Art Gallery1474Travel and Transportation > Transportation Service > Public Transportation > Bus Line1238Dining and Drinking > Restaurant1238 We can also filter to places that fall into a specific category. For example, instead of searching for Starbucks locations by name, let’s select all Points of Interest that are in the Coffee Shop category: category_places = sedona.sql(""" SELECT * FROM sf_places WHERE ARRAY_CONTAINS(fsq_category_labels, 'Dining and Drinking > Cafe, Coffee, and Tea House > Coffee Shop') """) Here’s a quick look at the table that we get after running that query. +--------------------+--------------------+--------------------+--------------------+-------+--------------+------------+ | fsq_place_id| name| geometry| fsq_category_labels|country|date_refreshed|date_created| +--------------------+--------------------+--------------------+--------------------+-------+--------------+------------+ |5622e819498ecbeed...|Four Barrel at TI...|POINT (-122.37331...|[Dining and Drink...| US| 2024-10-26| 2015-10-18| |49d6619ff964a520b...| Cafe deStijl|POINT (-122.40036...|[Dining and Drink...| US| 2022-07-29| 2009-04-03| |49dbc22af964a520f...|Battery Street Co...|POINT (-122.40133...|[Dining and Drink...| US| 2024-05-06| 2009-04-07| |5b1599d604d1ae002...| Good Mojo|POINT (-122.40049...|[Dining and Drink...| US| 2024-10-26| 2018-06-04| |4b02f2f9f964a5205...| Starbucks|POINT (-122.40102...|[Dining and Drink...| US| 2024-11-05| 2009-11-17| |49fa3e4ff964a520d...| Jackson Place Cafe|POINT (-122.40135...|[Dining and Drink...| US| 2024-07-17| 2009-05-01| |4d065736a26854819...|Réveille Coffee C...|POINT (-122.40035...|[Dining and Drink...| US| 2024-10-20| 2010-12-13| |4bafe772f964a5205...| om bucks|POINT (-122.40090...|[Dining and Drink...| US| 2023-04-04| 2010-03-28| |4ab317e7f964a5207...| Peet's Coffee|POINT (-122.40115...|[Dining and Drink...| US| 2023-09-20| 2009-09-18| |2af323a0d2d542feb...| Aroma Espresso Bar|POINT (-122.40102...|[Dining and Drink...| US| 2012-08-27| 2012-08-27| +--------------------+--------------------+--------------------+--------------------+-------+--------------+------------+ Creating a Choropleth Map: Coffee Shops by Neighborhood For a more advanced visualization, let’s create a choropleth map showing the number of coffee shops in each San Francisco neighborhood. First we will need a dataset of polygons for the SF neighborhoods. Luckily, we have one from the SF open data portal. We’ll load these from a CSV file: SF_NEIGHBORHOODS_URL = "s3://wherobots-examples/data/sf_neighborhoods.csv" neighborhoods = (sedona.read.format('csv') .option('header', 'true') .option('delimiter', ',') .option('inferSchema', 'true') .load(SF_NEIGHBORHOODS_URL) ) For context, here’s the table that results after we load those neighborhood polygon boundaries. +--------------------+--------------------+ | the_geom| neighborho| +--------------------+--------------------+ |MULTIPOLYGON (((-...| Seacliff| |MULTIPOLYGON (((-...| Haight Ashbury| |MULTIPOLYGON (((-...| Outer Mission| |MULTIPOLYGON (((-...| Inner Sunset| |MULTIPOLYGON (((-...|Downtown/Civic Ce...| |MULTIPOLYGON (((-...| Diamond Heights| |MULTIPOLYGON (((-...| Lakeshore| |MULTIPOLYGON (((-...| Russian Hill| |MULTIPOLYGON (((-...| Noe Valley| |MULTIPOLYGON (((-...| Treasure Island/YBI| +--------------------+--------------------+ As you can see, there are two columns, the geometry column that contains the multi-polygon that defines the boundaries of the neighborhood and the neighborhood column that contains the name. If you’ve spent any time in SF you’ll certainly recognize some of these names. Now that we have the boundaries we’ll use a spatial join to count coffee shops in each neighborhood: neighborhood_agg = sedona.sql(""" SELECT ST_GeomFromWKT(n.the_geom) AS geometry, n.neighborho AS neighborhood, COUNT(*) as location_count, collect_list(p.name) AS coffee_shops FROM category_places p JOIN neighborhoods n ON ST_CONTAINS(ST_GeomFromWKT(n.the_geom), p.geometry) GROUP BY n.the_geom, n.neighborho """) This gives us the following table where we can see the neighborhood name, its polygon geometry, the count of coffee shops contained in that neighborhood, and an array of the names of the coffee shops. +--------------------+--------------------+--------------+--------------------+ | geometry| neighborhood|location_count| coffee_shops| +--------------------+--------------------+--------------+--------------------+ |MULTIPOLYGON (((-...| Treasure Island/YBI| 1|[Four Barrel at T...| |MULTIPOLYGON (((-...| Potrero Hill| 25|[Starbucks, WFM C...| |MULTIPOLYGON (((-...| South of Market| 119|[W6 Coffee Bar, S...| |MULTIPOLYGON (((-...| Bayview| 20|[The Happy Vegan,...| |MULTIPOLYGON (((-...| Financial District| 186|[Starbucks, Jacks...| |MULTIPOLYGON (((-...| Visitacion Valley| 4|[Joe Leland, Miss...| |MULTIPOLYGON (((-...| Chinatown| 11|[Cafe Vivo, Latte...| |MULTIPOLYGON (((-...|Downtown/Civic Ce...| 98|[Chai Bar, Dignit...| |MULTIPOLYGON (((-...| North Beach| 30|[Cafe deStijl, Ba...| |MULTIPOLYGON (((-...| Nob Hill| 22|[Cafe Mozart, Gal...| +--------------------+--------------------+--------------+--------------------+ Finally we have what we need to create our visualization. Time to create our choropleth map. Note here that I am using a custom map config to set the color scale, style, and other properties. map = SedonaKepler.create_map(df=neighborhood_agg, name="Coffee Shop Count", config=map_config) The resulting visualization reveals interesting patterns. Downtown San Francisco (the Financial District) has the highest concentration with 186 coffee shops, while areas like the Presidio are relatively sparse with only around 10 options. The Inner Richmond neighborhood shows about 37 coffee shops. With these live Sedona Kepler maps, you can hover over the neighborhood you’re interested in to see the full list of coffee shops in that area. That wraps up our tutorial on working with Foursquare Places data in Wherobots. I hope you enjoyed learning about these powerful geospatial capabilities. Before we wrap up, let’s take a quick look at what makes this dataset from Foursquare unique. What Makes Foursquare’s Places Data Unique? Unlike some other POI datasets, Foursquare’s Places data is continually updated through their Placemaker Tools. These web-based tools allow community members to: Add new venues Update existing information Validate place data This community-driven approach helps ensure the data remains current and accurately reflects real-world changes. Conclusion The Foursquare Places dataset combined with Wherobots’ powerful geospatial capabilities offers an excellent foundation for location-based analytics. Whether you’re studying urban patterns, analyzing business distributions, or planning a coffee crawl through San Francisco, these tools make it easy to extract meaningful insights from spatial data. Ready to explore the Foursquare Places data for yourself? Sign up for a free Wherobots account and try out this notebook! Bonus: Video Walk Through By the way, a couple months ago I released this video where I walk through this exact use case in one of our Wherobots demo notebooks. Feel free to check it out. Get started for free Try Now Frequently Asked Questions How many places are in Foursquare Open Places on Wherobots? The tutorial stats query returned 104,635,092 total places, of which 98,436,217 were still open. About 67 million had addresses and nearly 93 million had category labels. The intro also describes the dataset as more than 100 million locations worldwide. How do I query Foursquare Places in Wherobots? The tables live at wherobots_open_data.foursquare.places and .categories. Select a version with VERSION AS OF dt=YYYY-MM-DD or omit it for the latest. Geometry is a native column for ST_Contains and other spatial functions. Which San Francisco neighborhood had the most coffee shops in the tutorial? The Financial District, with 186 coffee shops in the Coffee Shop category. South of Market had 119; Inner Richmond about 37; the Presidio around 10. Is Foursquare Places free to use in Wherobots? It is offered through the Wherobots Open Data Catalog / Global Hub, and the tutorial runs on a free Wherobots instance. Wherobots maintains a pipeline that tracks Foursquare releases. --- ## Advancing the Integration of Map Data via Overture’s Global Entity Reference System and Wherobots URL: https://wherobots.com/blog/overtures-global-entity-reference-system-generally-available/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. The general availability of the Overture Maps Foundation’s Global Entity Reference System (GERS) makes it a lot easier to build intelligence about features of our physical world.  Key takeawaysOverture Maps Foundation Global Entity Reference System (GERS) is generally available. It puts stable unique keys on millions of physical features (buildings, highways, countries, rivers, schools) so datasets can be joined and tracked over time.Wherobots has been an Overture member since 2024 and hosts recent Overture datasets in the Havasu Catalog at no additional cost. Community Edition can query them; Professional Edition joins them to data in your cloud storage.Wherobots supports the GERS schema so you can query, filter, and spatially join first-party parcels, retail sites, roads, or telemetry to Overture with SQL or Python.Overture produces a global buildings dataset of 2.6 billion geometries (and growing). After moving Spark/Sedona pipelines to Wherobots, with a simple code redirect and Airflow job-run support, those pipelines accelerated by up to 20x while staying Apache Sedona compatible.Wherobots also led GEO type support in Apache Iceberg and Parquet so GERS-backed features can live in an open, versioned lakehouse rather than a proprietary silo. What is GERS? You can think of a GERS as a system for applying a unique key to physical features in the world. Overture assigns GERS IDs to millions of features in their data products, such as office buildings, highways, countries, rivers, schools, and more. Using GERS IDs, you can more easily join datasets to build a more complete view of physical-world features in space and measure relationships over time.  Key benefits of GERS IDs include: Persistent identification: The same physical location maintains the same GERS ID over time Cross-dataset compatibility: Enable joining and enrichment across multiple datasets or providers Standardized reference: Provide a common language for location data across the geospatial ecosystem  You can read more about GERS IDs in Overture’s documentation.  Getting started with Overture in Wherobots At Wherobots, we’re proud to be a member of the Overture Maps Foundation, supporting the project since its formation, and as an official member since 2024. We also host and manage all of Overture’s recent datasets in the Wherobots Spatial Catalog, and they are offered at no additional cost to all customers. These datasets are production ready and at your fingertips. Select * from wherobots_open_data.overture.buildings_building New Wherobots customers can get started with Overture’s datasets in the free-to-use Community Edition, and graduate to the Professional edition when they want to join Overture data with their data in cloud storage. It’s Easy to use GERS in Wherobots A key design goal of GERS is to simplify how organizations can join and enrich their own datasets using canonical Overture datasets. Wherobots makes this vision real by providing built-in support for the GERS schema, enabling users to easily query, filter, and join to valuable geospatial datasets using GERS IDs, and through the use of spatial join predicates available in Apache Sedona and Wherobots. Whether data teams are working with parcel boundaries, retail site locations, road networks, or foot traffic telemetry, Wherobots makes it easy to enrich data using GERS with SQL or Python. Overture GERS Schema Extension Paths (not exhaustive)  Stay tuned for a new tutorial from Wherobots that shows you how to use GERS IDs with Overture Places. Overtures datasets are produced using Wherobots Wherobots was founded by the original creators of Apache Sedona, the open-source engine for distributed geospatial processing. Overture now runs many of their Apache Spark and Sedona based data pipelines on Wherobots because they run up to 20x faster, at a fraction of the cost, and the Overture team benefits from the spatial expertise we offer them as a customer. The Overture team uses Wherobots’ Apache Airflow support to trigger job runs that power production of their planetary scale datasets. This feature and Wherobots compatibility with Spark and Sedona, also made it very easy for Overture to redirect where their Airflow-orchestrated jobs ran. “Overture produces a building dataset covering all buildings in the world, with 2.6B geometries and growing, that’s updated frequently. There’s a lot of data, and compute that goes into producing it and keeping it up to date. We accelerated the pipelines that produce the buildings dataset by up to 20x after we moved them to Wherobots, which required a simple redirection of our code. We retained compatibility with Apache Sedona, and the move put us into a development experience that’s made us more productive.” – Jennings Anderson, Geoscientist at Overture and Data Engineer at Meta. Redefining Standards in Open Source We’re committed to improving open standards in the geospatial data ecosystem.  Wherobots is a leading contributor of spatial type support in Apache Iceberg and Parquet, the most popular open table and file formats for the cloud data lakehouse, to make it easier for companies to utilize geospatial data.We’ve partnered with Overture to improve the foundation for a scalable, versioned, and queryable world of features backed by GERS. By modernizing how geospatial data is accessed in the cloud via spatial data type support in Iceberg and Parquet, and improving accessibility and utility of open map data via GERS, we believe new use cases for spatial data will emerge to improve business operations, research, and our way of life.  Join us in Building the Spatial Data Stack of the Future The launch of GERS is a big step for advancing spatial intelligence, and a leap toward a more open, interoperable data ecosystem. Wherobots is proud to be part of this journey, and we’re excited to continue supporting the Overture mission through operational pipelines, open standards, and accessible tools.If you’re building with geospatial data, we invite you to explore how Wherobots can help you take full advantage of GERS by easily joining your first party data with the GERS ID system.  Next steps If you’d like a one-on-one demo from our team, you can request it here. Learn about our data mirror with Overture in their documentation. We will be publishing an example notebook that shows you how to use GERS IDs with Overture Places soon.  Start Building with Wherobots Access Now Frequently Asked Questions What is Overture GERS? The Global Entity Reference System assigns persistent unique IDs to physical-world features in Overture data products. Those IDs let you join and enrich datasets that refer to the same building, road, place, or other entity over time. Are Overture datasets free in Wherobots? Wherobots hosts and manages recent Overture datasets in the Havasu Catalog at no additional cost. New users can start on free Community Edition and move to Professional when they need to join Overture to their own cloud storage. Does Overture itself run on Wherobots? Yes. Jennings Anderson (Overture / Meta) says the global buildings pipeline (2.6 billion geometries, updated frequently) got up to 20x faster after jobs were redirected to Wherobots. It kept Apache Sedona compatibility and used Wherobots Airflow job runs. How do I attach GERS IDs to my own data? Use GERS IDs and spatial join predicates in Apache Sedona/Wherobots SQL or Python against Overture tables such as wherobots_open_data.overture.buildings_building. A follow-on Places tutorial is previewed in this post (later published separately). --- ## Wherobots received its SOC 2 Type 2 attestation URL: https://wherobots.com/blog/wherobots-received-its-soc-2-type-2-attestation/ Updated: 2026-10-19 We are thrilled to announce Wherobots has received its SOC 2 Type 2 attestation report, reinforcing our commitment to data security and data privacy for our customers. Key takeawaysWherobots has received a SOC 2 Type 2 attestation report, the industry-trusted audit of security and confidentiality controls over a period of time. It is not a Type 1 point-in-time snapshot of policies.The report is available from the Wherobots Trust Center or by emailing security@wherobots.com, and is intended to speed procurement, vendor, and security reviews.Wherobots Cloud isolates the control plane from the compute plane, and isolates each workload from the hypervisor up. The service is serverless by default and can also run its compute plane in the customer AWS VPC (BYOC).The lakehouse architecture brings spatial analytics and AI to data where it already lives, rather than requiring customers to surrender custody of sensitive trip, activity, satellite, or drone data.Docs cover service principles, audit logs, SAML SSO, and related security capabilities for teams going through enterprise review. SOC 2 (Systems and Organization Controls) is a standard trusted by industry leaders and a requirement for many enterprises engaging with software providers. It evaluates an organization’s information security practices, ensuring that controls are prompt and effective, and that data is kept secure and confidential. While a Type 1 attestation assesses policies and procedures at a single point in time, the Type 2 attestation we have received demands a rigorous, in-depth evaluation and audit of the effectiveness of the implemented controls over time. To view our SOC 2 Type 2 report, or more information on our security policies, please view our Trust Center or contact us at security@wherobots.com. Why this matters There are billions of devices roaming the world, logging petabytes of data from trips, activities, and events. Satellites and drones are scanning the world, capturing what’s happening on Earth, how its changing, and how humans terraforming it. This data can be highly sensitive and highly valued. With Wherobots, businesses can utilize this data from the physical world at a distinguished scale, price-performance, and ease, while keeping data secure and in their control. With Wherobots’ cloud-native Lakehouse architecture, you can bring Wherobots’ capabilities for spatial and non-spatial data analytics and AI at planetary scale – right to your data, wherever it lives. Security first Security is not just a feature, it’s part of our engineering culture and infused into how we design and build our software, our internal systems, and our production environments. Wherobots Cloud was developed from the ground up with best practices and secure-by-design principles that work backwards from data security first. In its architecture, the Wherobots Cloud control plane is isolated from its compute plane, and each workload is isolated from the cloud hypervisor up to create a trusted environment for your data. This architecture is serverless by default, but can also run its compute plane in your own cloud VPC (BYOC). Wherobots is the distinguished and obvious solution for spatial computation and AI on the lakehouse. Our SOC 2 Type 2 report, available on the Wherobots Trust Center, is now available to expedite procurement, vendor, and security reviews. Want to learn about more Wherobots security capabilities? Visit our docs on Getting Started with Wherobots to review service principles, audit logs, SAML SSO, and more. Get Started with Wherobots START BUILDING Frequently Asked Questions Did Wherobots achieve SOC 2 Type 2? Yes. The post announces that Wherobots has received its SOC 2 Type 2 attestation report. What is the difference between SOC 2 Type 1 and Type 2? Type 1 assesses policies and procedures at a single point in time. Type 2 audits whether those controls operated effectively over time. Wherobots received Type 2. Where can I read the SOC 2 report? View it in the Wherobots Trust Center, or contact security@wherobots.com. The post presents the report as a way to expedite procurement and security reviews. How is Wherobots Cloud isolated for security? The control plane is isolated from the compute plane, and each workload is isolated from the cloud hypervisor up. Compute is serverless by default or can run in your own AWS VPC (BYOC). --- ## The Spatial Intelligence Newsletter: GeoPandas, Isochrones, Iceberg GEO, SAM2 and More URL: https://wherobots.com/blog/spatial-intelligence-newsletter-geopandas-isochrones-iceberg-geo-sam2/ Updated: 2026-10-19 ✨ Welcome to this month’s newsletter! Whether you’re comparing performance, exploring isochrones for spatial analysis, or implementing ML models for feature detection in satellite imagery, there’s something here for everyone. Read on for expert insights, product updates, and upcoming events you won’t want to miss! Key takeawaysThis May 2025 Spatial Intelligence Newsletter is a roundup of existing posts, product notes, and events. It is not a standalone technical deep dive.A limited Pro trial on AWS ran through May 31st, with Pro-only features called out: raster inference, map matching, and travel isochrones.Raster Inference added Meta SAM 2 (with OWLv2) so you can prompt object detection and segmentation on terabytes of satellite imagery in SQL. Results land as Iceberg tables in your S3 bucket for use with 300+ spatial functions, with no local GPUs or model downloads.Wherobots became available in AWS Europe (Ireland), aimed at EU data-residency and lower-latency workloads in climate, mobility, automotive, agriculture, and urban development.Community notes include O'Reilly Cloud Native Geospatial Analytics with Apache Sedona (through the PyData chapter) and the next office hour previewing Sedona 1.8.0 (GeoPandas API, PyFlink, Spark 4.0).They also include Data+AI Summit booth #E406 and an Iceberg Geo Type session with Jia Yu and Szehon Ho. 🚨Last Call: Don’t miss your chance to try Wherobots Pro—free on AWS until May 31st! If you’ve been meaning to explore Wherobots, now’s the perfect time. Get full access to the Pro tier, including unlimited performance and scalability for production workloads. Take advantage of powerful features like raster inference, map matching, and travel isochrones—only available in the Pro tier. Latest Content 💡GeoPandas vs. Wherobots: Which is better for spatial analysis? We ran a spatial join between the Overture Buildings dataset and a postal codes dataset.  Wherobots consistently outperforms GeoPandas in terms of speed—especially at scale. In fact, GeoPandas was unable to handle the largest dataset due to memory limitations. That said, GeoPandas is great for smaller datasets. Its interoperability with lots of libraries makes it a great tool for lightweight spatial workflows. Wherobots & Sedona are built for scale. It supports both Python and SQL APIs. And it’s  ideal for large datasets and SQL-based workflows.  Combine these tools for the best of both worlds. Flexibility for small and large datasets with access to a broader ecosystem of libraries. Find out how Sedona and GeoPandas are better together.  How Wherobots Generated Drive Time Isochrones for Every POI in the US 📍Imagine if your geospatial models could reason in terms of real travel time rather than just distance. ⭐ Key highlights include: What makes the Isochrones Dataset unique and how it was built How to integrate isochrones with demographic, land use, or POI datasets A live demo of geospatial weighted regression to model service coverage, accessibility, or economic potential Why time-based modeling outperforms distance-based approaches in urban analytics Learn how Wherobots generated drive-time isochrones for every POI in the U.S., and how this data can transform planning in urban analytics, retail, transportation, and more. Geospatial Tables in the Open Lakehouse: A New Era for Iceberg & Parquet 🧊With geospatial data now supported natively in Apache Iceberg and Parquet, spatial analytics becomes as scalable and performant as any other big data workload. Join leaders from Planet, Databricks, Foursquare, and Wherobots in this insightful discussion as they explore the impact of native GEO support in Iceberg, including its core functionality, performance benefits, industry adoption, strategies for avoiding vendor lock-in, and what’s ahead for the future of geospatial data. 🔮 Product Updates What if you could detect features in satellite imagery using natural language– without relying on GPU-intensive infrastructure? With Raster Inference supporting Meta’s Segment Anything 2 (SAM2) model, you can now perform object detection and feature segmentation at scale on terabytes of satellite imagery—just by describing what you’re looking for in plain text. Instead of downloading models or manually wrangling raster data, just run everything on Wherobots’ distributed cloud compute.  Query massive satellite datasets using natural language: “Find container ships” 🚢 or “Segment pickleball courts” 🎾—no GPUs, no model downloads, just cloud-native inference. Because these results are stored as Iceberg tables in your S3 bucket, you can easily join with other datasets using WherobotsDB and continue your analysis inline with 300+ spatial features and functions. Currently it supports OWLv2 SAM2, and you can go from prompt to polygons in a single SQL query. 🚀 Wherobots is now available in the AWS Europe (Ireland) region! The EU leads in innovation across climate solutions, mobility, automotive design, precision agriculture, and urban development—industries that all rely heavily on geospatial data. Yet modern cloud tools haven’t kept pace, making geospatial development costly and complex, often requiring specialized teams and infrastructure. For teams working in the EU, this launch offers lower latency support for European data residency requirements and simplified scaling—with no infrastructure headaches. Apache Sedona Community Cloud Native Geospatial Analytics with Apache Sedona (published by O’Reilly) This latest chapter dives deeper intro the integration between Apache Sedona and the Python data science stack—empowering spatial workflows that scale using tools you already know and love. If you’re following the series or want to catch up: 🔹 Chapter 1: Introduction to Apache Sedona 🔹 Chapter 2: Getting Started with Apache Sedona 🔹 Chapter 3: Working With Geospatial Data at Scale (Data Loading) 🔹 Chapter 4: Vector Data Analysis with Spatial SQL (Points, Lines, and Polygons) 💡 Latest: Sedona + PyData Ecosystem 📥 Get the hands-on guide for working with large-scale spatial data.  Apache Sedona Community Office Hour Missed the most recent office hour? Watch the recording here. We covered: Broadcast join support for distributed KNN Joins The new STAC reader & OpenStreetMap (OSM) PBF reader  A live demo using Sedona with Overture Maps data. 📅 Mark your calendar for the next session, where we’ll cover upcoming Sedona 1.8.0 release: GeoPandas API on Sedona Sedona on PyFlink Spark 4.0 support Sedona vectorized Python UDF GeoParquet, and Parquet Geo types Upcoming Events Connect with us at the Data+AI Summit Our team is heading to the Data+AI Summit in San Francisco, and we’d love to connect in person! 🎤 Don’t miss our session: Iceberg Geo Type: Transforming Geospatial Data Management at Scale, presented by Jia Yu (Wherobots) and Szehon Ho (Databricks) 📍 Find us at booth #E406 for free SWAG and to learn more about geospatial ETL. 🍻 Join us Wednesday evening at the Apache Iceberg Meetup, featuring Iceberg GEO and building mobility knowledge graphs with PuppyGraph.  📧 Book a meeting with us here to find a time to connect. Join us at the EO Summit If you’re heading to the EO Summit in New York, we’d love to learn about how you’re working with earth observation data. Share your use cases and let’s explore how Wherobots can help. 📧 Reach out at info@wherobots.com to schedule a time to meet! Frequently Asked Questions What is in the May 2025 Spatial Intelligence Newsletter? Links to GeoPandas vs Wherobots performance, the U.S. POI isochrones dataset, an Iceberg/Parquet GEO discussion, SAM 2 raster inference, the AWS Europe (Ireland) launch, Sedona community updates, and Data+AI Summit / EO Summit events. Did this issue announce SAM 2 in Raster Inference? Yes. It says Raster Inference supports Meta SAM 2 with OWLv2. You can go from a natural-language prompt to polygons in a single SQL query on Wherobots distributed cloud compute, with results stored as Iceberg tables. Is Wherobots available in Europe in this newsletter? Yes. It announces availability in the AWS Europe (Ireland) region for lower latency and European data-residency requirements. What Sedona 1.8.0 features were previewed? The next office hour was slated to cover the GeoPandas API on Sedona, Sedona on PyFlink, Spark 4.0 support, vectorized Python UDFs, and GeoParquet / Parquet Geo types. --- ## Enabling Meta’s SAM 2 model for Geospatial AI on satellite imagery URL: https://wherobots.com/blog/sam-2-model-geospatial-ai-satellite-imagery/ Updated: 2026-10-19 Editor’s note: Raster inference is now part of RasterFlow, the Wherobots engine for running computer vision models on satellite and aerial imagery. Key takeawaysWherobots Raster Inference (now part of RasterFlow) added preview support for Meta Segment Anything 2. You can run general-purpose object detection and segmentation on terabyte-scale satellite and aerial imagery from a plain-English prompt.SAM 2 out of the box does not take text prompts. Raster Inference chains Google DeepMind OWLv2 open-vocabulary detector with SAM 2 to expose RS_TEXT_TO_BBOXES / Text_To_BBoxes and RS_TEXT_TO_SEGMENTS / Text_To_Segments in SQL and Python.Use bounding boxes when you only need to localize and count objects; use segments when you need size or shape. Results are georeferenced and stored as Iceberg tables in your S3 bucket for joins with WherobotsDB 300+ spatial functions.Get started on Professional Edition via AWS Marketplace, create a Tiny GPU Runtime, and run the Raster_Text_To_Segments_Airplanes example notebook. The post offered up to $400 in credits if you signed up before May 31, 2025.Preview limitations: OWLv2 was not trained on much satellite imagery, scale can confuse buildings vs neighborhoods, and quality is best on distinct features in simple scenes. The post shows strong airplane segmentation on NAIP 30 cm imagery and confusion between agriculture and solar farms on a solar farms prompt. UPDATE: Raster inference is included in Wherobots RasterFlow. See Wherobots Get Started with RasterFlow – Wherobots for the most up-to-date workflows. Wherobots Raster Inference makes it easy to create innovative solutions from large scale satellite and aerial imagery using SQL and Python, and geovision models you import or source off-the-shelf. Today, we’re excited to announce that Raster Inference now supports Meta’s Segment Anything 2 (SAM 2 ) model. With support for the SAM 2 model for geospatial AI in Raster Inference (in preview), you can now perform general purpose object detection and feature segmentation on terabyte scale collections of geospatial imagery, simply by describing what you’re looking for in plain text. You can now use Raster Inference to answer questions from satellite imagery like “find the container ships” or “segment crop circles” or ”segment pickleball courts” from very large areas of interest. Raster Inference results are stored as Iceberg tables in your S3 bucket, so you can easily join them with other data using WherobotsDB and continue your analysis inline with over 300+ features and functions optimized for spatial solution development. Click here to launch this interactive notebook Launch Notebook Scaling Segment Anything (SAM 2) for Large-Scale Image Prediction Foundation computer vision models like Segment Anything 2 revolutionized image understanding by allowing users to detect and delineate objects, typically from small scale images using simple point or text based prompts. However its been very hard, if not infeasible to use this model for large scale object detection on satellite imagery, like “find all of the container ships in the Pacific Ocean”. Raster Inference in Wherobots makes the SAM 2 model, along with other geospatial computer vision models (including custom), easier to deploy and run on terabyte scale inference runs using a cloud-parallel compute architecture. Such high scale and performance is necessary for extracting insights from high resolution satellite imagery data. Now, customers can prompt the SAM 2 model with English text, and explore use cases for AI on Earth observation AI models much faster than before. Use Cases for SAM 2 in Wherobots Raster Inference We launched support for SAM 2 in Raster Inference because we saw customers starting to use Raster Inference to explore the potential of geospatial AI for their use cases. Some did not have ML expertise, and experts just wanted a fast way to explore and test their ideas. Exploring is as easy as opening an example notebook, modifying a text prompt, and hitting run. You can work the tabular output of all Raster Inference runs inline using SQL or Python, and use Wherobots’ rich toolbox of spatial functions to accelerate the realization of value from complex spatial data. We believe this is a great general purpose AI tool for testing the feasibility of your ideas. From here, you can decide to invest in or find fine-tuned model alternatives that may be optimized for your earth observation use case. Just like LLMs you’ve probably interfaced with, you have to take quality, reliability, and risk into account before utilizing the results verbatim in an application. But even if they aren’t 100% correct, they offer immense productivity gains. And like we’ve seen with LLMs, text-promptable models like SAM 2 will evolve and get better over time, improving the direct utility of results and use cases that can serve out-of-the-box. Getting Started You can get started in a matter of minutes, without any infrastructure or model management overhead. Sign up for the Professional Edition of Wherobots on the AWS Marketplace. New customers receive up to $400 in free credits if they sign up before May 31st, 2025. Create a Tiny GPU Runtime. You may need to request a limit increase to access GPU runtimes. Open the Analyzing_Data/Raster_Text_To_Segments_Airplanes notebook Click on [run all cells] You can also learn more about running the SAM 2 model in Raster Inference using the Wherobots product documentation. Introducing Text-Prompts for Raster Inference Engineers who worked with SAM 2 might recognize that out of the box, SAM 2 does not support text-prompting. Instead, it supports automatic segment detection without categories, point prompts, and bounding box prompts to produce segment predictions. To enabled text-prompting in Raster Inference, we integrated a two-stage model pipeline combining Google Deepmind’s OWLv2 open-vocabulary object detector with SAM 2. This enables two new powerful functions: Text_To_BBoxes: Provide a text prompt (like 'solar panels'), and it returns georeferenced bounding boxes identifying potential matches across your imagery dataset. Text_To_Segments: Similar to the bounding box function, but it provides precise, georeferenced polygon segments outlining the boundaries of detected objects based on your text description. Using WherobotsDB, all results can be easily joined to other spatial and non-spatial data you may need to complete the solution. If your solution simply requires localizing and counting objects, use Text_To_BBoxes. If you need to know the size or shape of objects use Text_To_Segments. Accessing these capabilities is straightforward using either SQL or Python, fitting seamlessly into the your existing data analysis or data engineering workflows. Here’s how can predict solar panel geometries in SQL: -- Find bounding boxes for 'solar panels' CREATE OR REPLACE TEMP VIEW detected_bboxes AS SELECT raster_column, RS_TEXT_TO_BBOXES('SAM 2 ', raster_column, 'solar panels') AS detection_result FROM my_imagery_table; -- Find segments for 'large buildings' CREATE OR REPLACE TEMP VIEW detected_segments AS SELECT raster_column, RS_TEXT_TO_SEGMENTS('SAM 2 ', raster_column, 'solar panels') AS segmentation_result FROM my_imagery_table; And in Python: # Find bounding boxes for 'solar panels' df_bboxes = df_raster_input.withColumn( "detection_result", rs_text_to_bboxes("SAM 2 ", col("raster_column"), "solar panels") ) # Find segments for 'large buildings' df_segments = df_raster_input.withColumn( "segmentation_result", rs_text_to_segments("SAM 2 ", col("raster_column"), "solar panels") ) Behind the scenes, Raster Inference handles the heavy lifting. It scales your text-prompted inference request and model across a distributed GPU runtime optimized for loading large geospatial raster datasets, and ensures work is balanced across serverless compute nodes. It automatically handles varying image sizes via padding and other techniques, and efficiently reads your raster data using features like limit and sample pushdown. And the results – whether bounding boxes or polygons – are georeferenced, ready for immediate use in SQL or Python based analysis or visualization with helper functions like  show_detections. Improving SAM 2 for Geospatial Object Detection We’re still exploring the model’s capabilities, which is why the SAM 2 integration is in preview. Here are a few considerations we’ve identified based on observations during testing: The underlying OWLv2 model that powers the Text_To_Segments function wasn’t trained on a lot of satellite imagery examples so it can miss or incorrectly label visual features that are specific to satellite or aerial images. SAM 2 and OwLv2 might get confused with the concept of spatial scale. A prompt for “buildings” may return individual building segments or segments of entire neighborhoods. Inference performs well on distinct features in relatively simple visual environments, with minimal occlusion from clouds, shadows, or dense vegetation. SAM 2 performs well on high resolution NAIP 30cm imagery on simpler object categories, like airplane segmentation. Example: The OWLv2 object detection model (which Text_To_Segments depends on) can confuse visually similar features, like agriculture and solar farms, when prompted to detect “solar farms”. We are investigating paths to improve SAM 2’s accuracy, including supporting different prompting methods, such as using points to guide segmentation. Transforming Earth Observation with Geospatial AI Support for the SAM 2 model for geospatial AI in Raster Inference reflects on our core mission, which is to make it easy to utilize geospatial data at any scale. It also offers a tangible view into a future where interacting with vast archives of Earth Observation data is much easier and intuitive. We will continue to make SAM 2 and other geospatial models more accessible, and easier to use so customers can address diverse challenges solved with the help of Earth observation data. Tell Us What You Think Feel free to contact the team directly (product@wherobots.com) if you have feedback to share. We can’t wait to see what you discover! Get Started with RasterFlow START BUILDING Frequently Asked Questions Can I prompt SAM 2 with text in Wherobots? Yes, in Raster Inference preview. Wherobots wraps SAM 2 with OWLv2 so SQL/Python functions Text_To_BBoxes and Text_To_Segments accept prompts such as solar panels, container ships, or pickleball courts. Native SAM 2 alone does not support text prompts. What is the difference between Text_To_BBoxes and Text_To_Segments? Text_To_BBoxes returns georeferenced bounding boxes for counting and localizing. Text_To_Segments returns polygon outlines when you need object size or shape. Both run on distributed GPU runtimes over large raster collections. Where do SAM 2 inference results go? Raster Inference writes Iceberg tables to your S3 bucket. You can join those detections to other spatial and non-spatial data in WherobotsDB and visualize with helpers such as show_detections. How accurate is SAM 2 on satellite imagery? The integration is in preview. The post notes OWLv2 can miss or mislabel satellite-specific features, confuse spatial scale, and mix up visually similar classes (agriculture vs solar farms). It performs well on distinct objects in simpler, high-resolution scenes such as airplanes in NAIP 30 cm imagery. --- ## Wherobots, Sedona, and GeoPandas are better together URL: https://wherobots.com/blog/wherobots-sedona-and-geopandas-are-better-together/ Updated: 2026-10-19 This post shows you how to run computations on geospatial data with Wherobots, Sedona, and GeoPandas, explains how the engines execute computations differently, and describes how you can use these technologies for an amazing workflow.  Wherobots notebooks include the Sedona and GeoPandas engines, so you can easily access either library when running computations. Key takeawaysWherobots notebooks include both Sedona and GeoPandas, so you can run large joins in distributed Sedona, shrink the result, then convert to GeoPandas for libraries such as matplotlib and Folium.Sedona is lazy, clustered, and optimizer-driven (column pruning, predicate pushdown). GeoPandas is eager, single-node, and pandas-ecosystem friendly, but it hits out-of-memory errors when data does not fit in memory.On a spatial join of Overture buildings to 154,452 postal codes, Wherobots beat GeoPandas at every scale tested. It took 8.43s vs 13.3s at 1 million buildings and 12.8s vs 1 minute 6 seconds at 10 million.At 50 million buildings, Wherobots took 31.6s while GeoPandas ran out of memory. On the full 706,967,095 buildings, Wherobots took 5 minutes 42 seconds, and GeoPandas could not run.That comparison used 96 GB RAM on both sides (GeoPandas: 12 cores on one machine; Wherobots: 24 cores across a cluster). It is not a dask-geopandas comparison.Convert both ways: sedona_df.toPandas() into a GeoDataFrame after reducing size, or sedona.createDataFrame(geopandas_df) to pull formats Sedona cannot yet read (the post uses FlatGeoBuf as the example). A Sedona GeoPandas API lets you keep GeoPandas syntax on Sedona execution. The post will also show you how to write Sedona code with GeoPandas syntax using the Sedona GeoPandas API. Wherobots is great for quickly running computations on large datasets in parallel.  GeoPandas is familiar to lots of geospatial programmers and is interoperable with a lot of libraries, so both computation engines can be useful for an analysis. Let’s start with an example analysis that shows how to compute building centroids with either Sedona or GeoPandas. Wherobots and GeoPandas example computation Here’s how to read a GeoParquet file into a Sedona DataFrame. path = 's3://wherobots-examples/data/onboarding_1/nyc_buildings.parquet' buildings = sedona.read.format("geoparquet").load(path) Let’s inspect a few rows of data. buildings.select("BUILD_ID", "height_val", "geom").limit(5).show() +--------+----------+--------------------+ |BUILD_ID|height_val| geom| +--------+----------+--------------------+ | 2080161| 0.0|MULTIPOLYGON (((-...| | 2080159| 0.0|MULTIPOLYGON (((-...| | 2080158| 0.0|MULTIPOLYGON (((-...| | 7776189| 8.49|MULTIPOLYGON (((-...| | 7776214| 10.49|MULTIPOLYGON (((-...| +--------+----------+--------------------+ Let’s filter out all the rows with a zero height_val and compute the centroid for each building. (buildings .where(col("height_val") != 0.0) .withColumn("centroid", ST_Centroid(col("geom"))) .select("BUILD_ID", "height_val", "centroid") .limit(5) .show(truncate=False)) +--------+----------+---------------------------------------------+ |BUILD_ID|height_val|centroid | +--------+----------+---------------------------------------------+ |7776189 |8.49 |POINT (-73.9244121583531 40.876054867139366) | |7776214 |10.49 |POINT (-73.92479319267416 40.87608655645236) | |7740167 |37.44 |POINT (-73.93514476461972 40.81269938665691) | |7740151 |37.27 |POINT (-73.93622071995519 40.81267611885931) | |7740289 |36.19 |POINT (-73.93705258498942 40.813024939805196)| +--------+----------+---------------------------------------------+ You could also convert this buildings dataset to a GeoPandas DataFrame and compute the centroid for each building.  Here’s how we will run the computation: Use Sedona to read and filter the data Convert from Sedona to GeoPandas Use GeoPandas to compute the centroids Here’s how to filter the DataFrame and grab a few columns with Sedona: sedona_df = ( buildings .where(col("height_val") != 0.0) .select("BUILD_ID", "height_val", "geometry") ) Now convert the DataFrame to a pandas DataFrame: pandas_df = sedona_df.toPandas() Convert the pandas DataFrame to a GeoPandas DataFrame: import geopandas as gpd geopandas_df = gpd.GeoDataFrame(pandas_df, geometry="geometry") Compute the centroids with GeoPandas and view the contents of the GeoPandas DataFrame: geopandas_df["centroid"] = geopandas_df.geometry.centroid print(geopandas_df[["BUILD_ID", "height_val", "centroid"]].head(5)) --------------------------------------------------- BUILD_ID height_val centroid 0 7776189 8.490000 POINT (-73.92441 40.87605) 1 7776214 10.490000 POINT (-73.92479 40.87609) 2 7740167 37.439999 POINT (-73.93514 40.8127) 3 7740151 37.270000 POINT (-73.93622 40.81268) 4 7740289 36.189999 POINT (-73.93705 40.81302) Read an Iceberg table into a GeoPandas DataFrame Suppose you have an Iceberg table named local.db.icetable and would like to analyze the data with GeoPandas. GeoPandas does not have an Iceberg reader yet, so let’s read the table with Sedona and then convert it to a GeoPandas DataFrame. Here’s how to create the Sedona DataFrame: sedona_df = sedona.table("local.db.icetable") Now let’s convert the DataFrame to a GeoPandas DataFrame: import geopandas as gpd pandas_df = sedona_df.toPandas() geopandas_df = gpd.GeoDataFrame(pandas_df, geometry="geometry") print(geopandas_df) --------------------------- id geometry 0 a LINESTRING (1 3, 3 1) 1 d LINESTRING (2 7, 4 9) 2 e LINESTRING (6 7, 6 9) 3 f LINESTRING (8 7, 9 9) You can only convert smaller DataFrames from Sedona DataFrames to GeoPandas DataFrames.  Let’s take a look at the architectural differences between the engines to learn more. How Sedona and GeoPandas execute computations differently Sedona executes computations on a distributed cluster, so it can quickly run computations on large datasets. GeoPandas runs computations on a single node, so it’s not as scalable, but it can be quick for small datasets and is interoperable with libraries in the pandas ecosystem. GeoPandas computations can be distributed with Sedona GeoPandas or dask-geopandas, and we will describe those technologies in the sections that follow. Let’s take a look at the differences in more detail. Single-node execution with GeoPandas vs. Sedona cluster computing GeoPandas runs computations on a single computer and processes data using only a single node. This is fine for small datasets, but it cannot scale beyond the resources of a single machine. Sedona runs on many machines working in unison as a cluster.  The cluster has a driver node responsible for orchestration and worker nodes that process the data in parallel.   When a computation runs on a single node, only one machine reads the data and executes the query. When a computation is run on a cluster, all worker nodes read data in parallel and execute the query. As you can imagine, running on a cluster is faster and more scalable for large datasets. Lazy Sedona execution vs. eager computation with GeoPandas Wherobots is a lazy compute engine, and GeoPandas is an eager compute engine. Lazy compute engines build up query execution graphs but don’t run the underlying computations until they need to produce a result.  Let’s take a look at a line of Sedona code that reads a file: df = sedona.read.format("geojson").load("overture_buildings.geojson") This line doesn’t read the underlying file. It waits until the user requests a result from the data before doing the work—it’s lazy. This is good because it can inspect and optimize the queries before running them. Let’s compare this with GeoPandas code that reads in data to a DataFrame: overture_buildings = gpd.read_file("overture_buildings.geojson") This GeoPandas code runs instantly and eagerly loads all the data into an in-memory DataFrame. Eager execution can be beneficial, especially when the data is small and when the DataFrame is repeatedly queried. However, it has drawbacks for larger-than-memory datasets. Out-of-memory datasets with GeoPandas GeoPandas eagerly loads data into memory. When the machine does not have enough memory to load all the data, it will error out with an out-of-memory exception. In practice, GeoPandas works well with dataset sizes much smaller than the total memory on the machine. Wherobots is designed to run on datasets larger than a given machine’s memory. It processes data incrementally and does not load it into memory all at once, allowing It to process out-of-memory datasets. Let’s now dive into how the computations are executed. Sedona vs. GeoPandas: Query optimizations Wherobots uses a query optimizer to ensure the code executes efficiently. For example, suppose a query requires three columns of a 10-column dataset stored in GeoParquet. The query optimizer will intelligently select only the needed three columns rather than reading all 10 columns of data. GeoPandas doesn’t have a query optimizer, so users must manually specify the optimizations they want to be applied.  For example, when a GeoPandas user queries a GeoParquet file, they need to specify the column pruning and row-group filtering logic manually. The query optimizer provides a better developer experience and better performance, too. Sedona vs. GeoPandas: Syntax differences Sedona supports Python, SQL, Java, Scala, and R interfaces. GeoPandas just supports a Python API. The Wherobots Python syntax is different from the GeoPandas Python syntax.  Sedona is syntactically similar to PySpark, and GeoPandas is syntactically similar to Pandas. Now let’s take a look at the Sedona GeoPandas API. Sedona vs. GeoPandas: Library ecosystem Sedona and GeoPandas are compatible with different libraries. For example, suppose you would like to read a large geospatial dataset stored in Apache Iceberg, perform some data munging, and then display the results with matplotlib. Sedona is compatible with Iceberg, and GeoPandas is interoperable with matplotlib, so here is how you can run this computation: Read the Iceberg table with Sedona Perform data wrangling with Sedona and reduce the dataset size Convert to GeoPandas and plot with matplotlib Sedona and GeoPandas are interoperable with different libraries, and that’s one of the main reasons why it’s nice to have access to both. Sedona GeoPandas API The Sedona GeoPandas API is identical to the GeoPandas API, but executes computations with Sedona in a distributed manner.  It’s a great way for developers who are familiar with GeoPandas syntax to write code that’s executed with Sedona. Here’s an example of how to create a Sedona GeoPandas DataFrame: Dask-GeoPandas overview The dask-geopandas library is another way to parallelize GeoPandas computations to leverage all cores of a given machine or distribute computations to a cluster. Here’s a good summary of dask-geopandas: “Since GeoPandas is an extension to the pandas DataFrame, the same way Dask scales pandas can also be applied to GeoPandas”. A deep dive into the differences between Sedona and dask-geopanadas is beyond the scope of this post, which focuses on Sedona and GeoPandas, but we’re excited to investigate this in a future post! Converting from Sedona to GeoPandas You can convert a Wherobots DataFrame to a GeoPandas DataFrame, as you can see in this code snippet: pandas_df = sedona_df.toPandas() geopandas_df = gpd.GeoDataFrame(pandas_df, geometry="geom") When you convert from Sedona DataFrames to GeoPandas, you load all the data into the driver node and process it on a single machine. Converting from a Sedona DataFrame to a GeoPandas DataFrame is not recommended if the dataset is large. It’s better to convert from Sedona GeoPandas once a dataset has been pre-processed and reduced in size. Once the data is small, you can convert it to a GeoPandas DataFrame and enjoy the interoperability offered by the GeoPandas ecosystem. Converting from GeoPandas to a Sedona DataFrame You can also convert from a GeoPandas DataFrame to a Sedona DataFrame.Here’s an example of how to read a FlatGeoBuf file into a GeoPandas DataFrame and then convert it to a Sedona DataFrame: geopandas_df = gpd.read_file("overture_buildings.fgb") overture_buildings_df = sedona.createDataFrame(geopandas_df) Sedona doesn’t have a FlatGeoBuf reader yet, so this is a good way to read FlatGeoBuf files into Sedona DataFrames! Visualizing Iceberg Data with Sedona Wherobots, GeoPandas, and Folium Let’s illustrate how to leverage Sedona’s computational power to process large Iceberg tables, reduce the data to a manageable size, and then visualize the results with GeoPandas and Folium. This workflow showcases the strength of combining these tools for geospatial data analysis. First, we utilize Wherobots Sedona to efficiently read and process our extensive Iceberg data: buildings_joined = sedona.sql(""" WITH dry_state_roi AS ( SELECT * FROM wherobots_open_data.overture_2025_03_19_1.divisions_division_area WHERE country = 'US' AND subtype = 'region' ) SELECT Count(building.id) AS buildings_count, roi.region AS region, roi.geometry AS region_geometry FROM wherobots_open_data.overture_2025_03_19_1.buildings_building building JOIN dry_state_roi roi ON ST_Intersects(building.geometry, roi.geometry) GROUP BY roi.region, roi.geometry """) Here, Sedona’s ability to handle large datasets shines as it quickly aggregates building counts by region. This reduction in data size is crucial, as it prepares the data for the next step with GeoPandas. Next, we convert the Sedona DataFrame to a GeoPandas DataFrame: import geopandas as gpd buildings_pdf = buildings_joined.toPandas() buildings_gpdf = gpd.GeoDataFrame(buildings_pdf, geometry="region_geometry") Now, we move to visualization using Folium, a library that integrates seamlessly with GeoPandas: import folium m = folium.Map([43, -100], zoom_start=4) folium.Choropleth( geo_data=buildings_gpdf.to_json(), data=buildings_gpdf, columns=["region", "buildings_count"], key_on="feature.properties.region", fill_color="YlOrRd", fill_opacity=0.7, line_opacity=0.2, legend_name="Building Count", ).add_to(m) m While Sedona offers other graphing libraries, Folium’s direct compatibility with GeoPandas simplifies the visualization process. This code generates an interactive choropleth map, clearly displaying building density across US regions. This example illustrates the power of Wherobots Sedona for rapid, large-scale data reduction, followed by GeoPandas and Folium for effective visualization. This combination allows for efficient analysis and presentation of complex geospatial data. Comparing Sedona Wherobots and GeoPandas performance for a given query Let’s compare the query performance for a dataset with different scale factors using Sedona Wherobots and GeoPandas. The GeoPandas query is run on a machine with 12 cores and 96GB of RAM. The Wherobots Sedona query is run on a cluster of machines with a total of 24 cores and 96GB of RAM.  Both setups have the same total RAM. Important note: This comparison is for GeoPandas vs. Sedona Wherobots.  Dask-geopandas is not included in this analysis and would be a more direct comparison, as it is a parallel compute engine.  The purpose of this comparison is to see the performance inflection point, not to act as though GeoPandas and Sedona Wherebots are similar. We tested spatial joins on three different datasets with GeoPandas and Sedona Wherobots. Overture buildings & Postal codes join details Let’s start with a simple spatial join query that counts the number of Overture Buildings located within postal code zones, by joining the Overture Buildings dataset with a postal codes dataset. Here is the query: WITH t AS ( SELECT * FROM overture_buildings buildings JOIN postal_codes zones ON ST_Intersects(buildings.geometry, zones.geometry)) ) SELECT COUNT(1) FROM t Let’s perform this query with different dataset sizes: Sizeoverture_buildingspostal_codesSmall1,000,000154,452Medium10,000,000154,452Large50,000,000154,452Full size706,967,095154,452 Here are the benchmarking results for each scale factor: SizeWherobots execution timeGeoPandas execution timeOutput countSmall8.43s13.3s362,042Medium12.8s1m 6s3,099,105Large31.6s–15,170,494Full size5m 42s–295,732,669 ‘-’ Kernel died due to OOM (Out Of Memory) Wherobots is faster for all scale factors. GeoPandas cannot run the query on the large dataset because it’s too much data to fit into memory. Here is the GeoPandas code to run the query: import geopandas as gpd overture_buildings = gpd.read_parquet("path/to/overture_buildings/") postal_codes = gpd.read_parquet("path/to/postal_codes/") t = overture_buildings.sindex.query(postal_codes["geometry"], "intersects") count = t.shape[0] Here’s how to run the code with Sedona: df = sedona.read.format("geoparquet").load("s3://wherobots-examples/data/geopandas_blog/1M/overture-buildings/") df.createOrReplaceTempView("overture_buildings") df = sedona.read.format("geoparquet").load("s3://wherobots-examples/data/geopandas_blog/postal-code/") df.createOrReplaceTempView("postal_codes") sedona.sql(""" WITH t AS ( SELECT * FROM overture_buildings buildings JOIN postal_codes zones ON ST_Intersects(buildings.geometry, zones.geometry) ) SELECT COUNT(1) FROM t """).show() Accessing the datasets For those interested in replicating the analyses and experiments discussed in this blog post, the datasets are available in a public Amazon S3 bucket. Here’s how you can access them: s3://wherobots-examples/data/geopandas_blog/ ├── 1M/ │ └── overture-buildings/ ├── 10M │ └── overture-buildings/ ├── 50M │ └── overture-buildings/ └── postal-code/ Each xM/ directory (e.g., 1M/, 10M/, 50M/) contains datasets scaled to different sizes, allowing for performance comparisons and scalability testing. The postal-code/ directory contains the postal code dataset used in the spatial join examples. Conclusion Sedona and GeoPandas are both great tools for analyzing spatial data. GeoPandas has many advantages: Interoperability with lots of libraries in the pandas ecosystem Built-in matplotlib support for graphing Long-standing project with a good community and strong technical leadership  Easy installation GeoPandas is an excellent option if you have a small dataset and are familiar with pandas. Wherobots and Sedona are better for larger datasets.  Wherobots has Python and SQL APIs and is also better for users who prefer writing SQL. But as you’ve seen in this post, Sedona and GeoPandas are better together.  The technologies combined give you access to a larger ecosystem of libraries and the ability to run computations on large and small datasets. Get Started with Wherobots for free START BUILDING Frequently Asked Questions Should I use GeoPandas or Apache Sedona in Wherobots? Both. Use Sedona/Wherobots for large or out-of-memory geospatial work and SQL; use GeoPandas for small frames and pandas-ecosystem libraries. Wherobots notebooks ship both engines. How much faster was Wherobots than GeoPandas on the Overture join? Joining buildings to 154,452 postal codes: 8.43s vs 13.3s at 1 million buildings, 12.8s vs 1m 6s at 10 million. At 50 million and at the full 706,967,095 buildings, GeoPandas hit OOM; Wherobots finished in 31.6s and 5m 42s respectively. Can I convert a Sedona DataFrame to GeoPandas? Yes: toPandas() then gpd.GeoDataFrame(…). Only do this after filtering to a size that fits on the driver. Going the other way, createDataFrame() can ingest a GeoPandas frame (for example FlatGeoBuf, which Sedona could not read natively at the time). Is this a fair comparison to Dask-GeoPandas? No. The post explicitly says dask-geopandas is a closer parallel engine and is out of scope. The benchmark contrasts single-node GeoPandas with clustered Wherobots Sedona at equal total RAM (96 GB). --- ## Wherobots, the Spatial Intelligence Cloud, is Now Available in AWS Europe URL: https://wherobots.com/blog/wherobots-now-available-in-aws-europe/ Updated: 2026-10-19 The EU is widely recognized as a world leader for climate solutions, automotive design and manufacturing, mobility systems and analysis, environmental monitoring, agriculture and precision farming, and urban development. Geospatial data is foundational to the success of these innovations. However most of the new technology is developed using tools and cloud services not optimized for geospatial development. Compared to internet data, support for geospatial data in the modern cloud environments has lagged. This technology gap has made working with geospatial data expensive, and required staffing data teams with unique expertise. Key takeawaysWherobots is available for EU-native workloads in the AWS Europe (Ireland) region, so teams can process and store data in-region to meet data-residency requirements.The launch targets EU strengths in climate, automotive, mobility, environmental monitoring, precision agriculture, and urban development. These are areas where cloud tools have lagged for geospatial compared with internet data.Customers such as AddressCloud and Overture Maps Foundation are cited as running workloads up to 20x faster after migrating from popular cloud engines. Wherobots offers a feature-complete SQL and Python experience and on-demand Spatial Units billing.Architecture is a cloud-native lakehouse: 100% Apache Sedona compatible (lift-and-shift with zero code changes), defaulting to open Iceberg and Parquet/GEO formats so storage stays decoupled from compute.Start on Professional Edition via AWS Marketplace, open a notebook, and run examples, with no infrastructure to manage. Requests for additional clouds or regions go to product@wherobots.com. Introducing Wherobots for the AWS Europe (Ireland) Region We are excited to announce that Wherobots is ready for EU native workloads. This expansion makes it possible for many EU companies to approve the use of Wherobots and adhere to their data residency requirements by processing and storing data in-region.  Wherobots is the Spatial Intelligence Cloud Wherobots’ mission is to make it easy for our customers to utilize geospatial data. We are delivering on it via a cloud optimized for developing and running solutions about the physical world, at any scale. Our purpose-built, cloud native approach is enabling teams at AddressCloud and Overture Maps Foundation to accelerate their pace of innovation with geospatial data. Their workloads run up to 20x faster after migrating from popular cloud-based engines, developer productivity is boosted with the most feature complete development experience for SQL and Python, and costs are reduced, putting new solutions in reach.  A Cloud Native Lakehouse Architecture The architecture of Wherobots is cloud native, and is deeply rooted in open source. Apache Sedona, the open source geospatial engine for Apache Spark, Apache Flink, and Snowflake, is 100% compatible with Wherobots. Users can easily lift and shift their Apache Sedona based applications into Wherobots with zero code changes. Wherobots is also one of the leading companies bringing GEO support into popular open file and open table formats like Parquet and Iceberg, and uses these formats by default. That way, you can deploy various engines on your data, benefit from the advantages of a Lakehouse engine such as ACID transactions and table versioning, without locking your data into proprietary vendor siloes, or inelastic solutions that couple storage with compute.   Getting Started Getting started is easy. To use Wherobots within the AWS Europe (Ireland) region, get srated with the Professional Edition on the AWS Marketplace. Create a notebook and explore one of many examples designed to help you realize what you can create using SQL and Python. There’s no infrastructure to manage. Teams just use and pay for Wherobots usage on-demand via Wherobots Spatial Units, which reflect the amount of serverless computation consumed. If there are other clouds or regions that you’re interested in using beyond the ones we currently support, please reach out to us at product@wherobots.com or fill out this form here. You can read more about Wherobots on the website or by exploring our product documentation. Create a Pro tier account on AWS Get Started Frequently Asked Questions Is Wherobots available in Europe? Yes. This post announces availability in the AWS Europe (Ireland) region so EU companies can process and store data in-region. Does the Ireland region help with data residency? That is the stated purpose: EU-native workloads can keep processing and storage in-region to satisfy data-residency requirements. Is Apache Sedona code portable to Wherobots in Europe? Yes. Wherobots is 100% compatible with Apache Sedona on Spark, Flink, and Snowflake, so applications lift and shift with zero code changes. Data stays in open Iceberg/Parquet rather than a proprietary silo. How do I get started in AWS Europe (Ireland)? Subscribe to the Professional Edition on the AWS Marketplace, create a notebook, and run the example notebooks. Usage is billed on-demand in Spatial Units. Ask product@wherobots.com if you need other clouds or regions. --- ## Spatial Intelligence Newsletter: Location Intelligence w/ Isochrones, Overture Places, Cloud-Native Geospatial, Iceberg and More URL: https://wherobots.com/blog/spatial-intelligence-newsletter-isochrones-overture-places-apache-iceberg-geospatial/ Updated: 2026-10-19 Welcome to the April edition of the Spatial Intelligence Newsletter! This month, we’re covering the benefits of using Apache Iceberg, spatial joins, cloud-native geospatial, and new product updates like isochrones to help you make better location-based decisions. What does it all mean, and how can it help you increase data productivity? Check it out here! 👇 Key takeawaysThis April 2025 newsletter roundup points to Iceberg-for-geospatial, cloud-native geospatial with Overture and Dotlas, spatial-join tutorials, and product launches. It does not report original benchmark figures.A Professional Edition offer included a free $400 credit through May 31st, covering GeoAI Raster Inference, map matching, travel isochrones, and bring-your-own cloud storage.Pro catalog added Overture Places enriched with 5-, 10-, 15-, and 20-minute U.S. driving isochrones, plus new ST_Isochrone functions in SQL and Python.Other Pro items: audit logs and job-run monitoring. STAC reader and notebook idle timeout landed for Community+.Sedona 1.7.1 shipped SQL GeoStats (ST_DBSCAN, ST_GLocal, ST_LocalOutlierFactor), broadcast KNN joins, STAC and OSM PBF readers, and ST_RemoveRepeatedPoints. A Comcast success story cut ETL from 5 hours to 30 minutes versus GeoPandas.Upcoming at the time: an Iceberg/Parquet livestream on May 5, a San Francisco Iceberg GEO meetup on May 12, and CNG Conference sessions in Snowbird April 30-May 2. ⏰💰Hurry, time is running out!  We’re currently offering a FREE $400 credit when you subscribe to the Professional edition of Wherobots, which includes exclusive features like GeoAI with Wherobots Raster Inference, map matching for cleaning messy GPS data, new travel isochrones for better location-based decisions, and the ability to bring your own cloud storage, just to name a few.  In addition, with the release of our drive-time isochrones, we’re now offering free access to Overture Places data—enriched with drive-time isochrones across every location in the U.S.—through our Pro tier data catalog. And we will be maintaining that dataset with every release in the future, so you’ll be able to use it going forward for location intelligence. There’s no obligation to get started, so be sure to take advantage of this (it’s like free money). Offer ends on May 31st, so don’t wait! Latest Content Benefits of Apache Iceberg for geospatial data analysis 🧊 Apache Iceberg support for GEO data brings a significant modernization for geospatial data and solutions. This support makes it easier for you to bring geospatial data into an open data architecture that decouples compute and storage and lower your costs. By adopting Iceberg in a data lake, you’re enabling your team to leverage the right tool for the job without needing to worry about locking your data into a vendor or a database solution that doesn’t scale.  Additionally, traditional file formats and row-oriented databases struggle when scaling beyond a million features, often performing poorly or only accommodating data that fits comfortably in memory. 😩 Iceberg, built on Parquet, solves this with lightning fast reads, scalability for larger-than-memory datasets, and developer friendly features like DML operations. Plus with added capabilities like versioning and time travel, users can query both current and historical data seamlessly. 🔍 Follow along this post to learn how to use Apache Iceberg with Sedona and find out how these features benefit spatial computations. Cloud-Native Geospatial: More Than Just Big Data  e💡We had a very insightful discussion with Amy Rose (CTO) from Overture Maps and Eshwaran Venkat (CTO & Co-Founder) from Dotlas on cloud-native geospatial technology. Here are some highlights: Cloud-native geospatial is not just for big data; it’s more accessible than you might think. You should be able to work with spatial data the way you work with any other data type. Increasing deliverability and breaking down data silos: Non-spatial communities can now work with spatial data.  Compute systems that make the process more scalable, accessible, elastic, and cost-efficient. How Dotlas and Overture Maps are optimizing their data pipelines, achieving performance gains, and improving cost efficiency. Spatial Joins at Scale: Unlocking Advanced Geospatial Analytics with Wherobots 🌎🤝 Spatial joins are essential for geospatial data analysis, but it can be slow or computationally expensive when working with large-scale datasets. Follow along in this tutorial as we walk through how easy and cost-effective it is to: Join datasets using spatial predicates like ST_Intersects to combine facilities with administrative boundaries and efficiently find the k-nearest neighbor with the ST_AKNN function. Apply spatial filters and improve performance through strategies like partitioning by geohash Take your geospatial data analytics to the next level and ensure spatial joins aren’t a bottleneck in solving your business challenges. Apache Sedona Sedona Success Story: Optimizing ETL pipelines at scale with Comcast 📊 Some of the challenges that Comcast was trying to overcome was data volume and repeatability. That’s why David Buchanan, GIS Architect, turned to Apache Sedona, which allowed him to reduce processing times from 5 hours to 30 minutes compared to GeoPandas. Watch the recording to learn more.  Apache Sedona Office Hours 😎 We just released Sedona 1.7.1, with some new features : SQL interface for GeoStats (ST_DBSCAN, ST_GLocal, ST_LocalOutlierFactor) Broadcast join support for distributed KNN Join STAC catalog & OpenStreetMap (OSM) PBF reader New ST functions like ST_RemoveRepeatedPoints  If you missed the office hour, check out the recording to learn more about the latest release. And don’t forget to mark your calendar for the next office hour! 🗓️ Product Updates Overture Places with Isochrones Dataset: Accelerate accessibility analysis with a ready-to-use dataset containing pre-calculated 5, 10, 15, and 20-minute driving isochrones for millions of US Overture Places (pro+).  New ST Isochrones functions: Make data-driven decisions on logistics, site selection, and market reach using Wherobots’ travel isochrone functions in SQL or Python (pro+). Audit Logs: Admins gain enhanced security and accountability insights by using Wherobots’ detailed, exportable audit logs to track key Organization actions and system events (pro+). STAC Reader: Simplify workflows and accelerate queries by loading STAC geospatial datasets directly into Sedona DataFrames in Wherobots (OSS & community+). Job Run Monitoring: Visually track job execution, analyze resource usage, and manage runs directly within Wherobots for enhanced control and optimization (pro+).  Idle Timeout for Notebooks: Gain control over notebook runtime costs and resource usage with customizable idle timeouts that automatically terminate inactive notebooks (community+). 🆓 Both the Overture Places with isochrones dataset and isochrone functions, as well as the audit logs and job run monitoring, are available exclusively in the Pro tier. Take advantage of the free trial (ending soon!) to try these features and see how they can help solve some of the bottlenecks you might be facing when working with spatial data. Upcoming Events Geospatial Tables in the Open Lakehouse: A New Era for Iceberg and Parquet Wednesday, May 5 at 9AM PT | Virtual It’s easier than ever to work with geospatial data, with Iceberg and Parquet now offering powerful solutions for both geospatial experts and non-spatial professionals. Join this livestream with leaders from Foursquare, Databricks, Planet, and Wherobots as they discuss the historical challenges of handling spatial data, bridging the gap, and future adoption of these advancements.  Apache Sedona + Iceberg GEO Meetup Monday, May 12 at 5:00PM PT | San Francisco, California Join us for a fun and informative evening as we explore Apache Iceberg’s new native geospatial support, designed to solve major challenges in managing geospatial data at scale. This will be a great opportunity to connect with professionals in the field to learn about the latest developments in spatial data, as well as exciting projects people are working on.🌟 Featured speakers:  ​​Jia Yu, Co-Founder and Chief Architect, Wherobots ​Matt Forrest, Director of Customer Engineering and PLG, Wherobots ​Yingjun Wu, Founder and CEO, RisingWave Labs CNG Conference  April 30 – May 2 | Snowbird, Utah We’re excited to attend the upcoming CNG Conference! Be sure to check out these sessions:  Day 1 1:15pm-2:45pm | Workshop: Interfacing with Cloud-Native Overture Data and the GERS Ecosystem – Sean Knight Day 2 9:45am-11:15am | Track 2: Introducing geospatial support in Apache Iceberg – Matthew Powers 11:45am-1:15pm | Extract insights from satellite imagery at scale with Wherobots – Damian Wylie 4:30pm-5:00pm | Plenary Panel: Builders Panel – Mo Sarwat 👥 If you’ll be at the conference, we’d love to meet with and chat about how you’re working with geospatial data. Feel free to reach out if you’d like to schedule a time to connect! Frequently Asked Questions What product updates are in the April 2025 newsletter? Overture Places with 5/10/15/20-minute U.S. driving isochrones, ST Isochrone functions, audit logs, job-run monitoring (Pro+), a STAC reader (OSS and Community+), and customizable notebook idle timeouts (Community+). What was the $400 Wherobots credit mentioned here? A free $400 credit when subscribing to Professional Edition, described as ending May 31st, covering Pro features such as Raster Inference, map matching, isochrones, and customer cloud storage. What shipped in Apache Sedona 1.7.1? SQL GeoStats (ST_DBSCAN, ST_GLocal, ST_LocalOutlierFactor), broadcast joins for distributed KNN, a STAC catalog reader, an OSM PBF reader, and new functions such as ST_RemoveRepeatedPoints. How much did Sedona speed up Comcast pipeline in this issue? The newsletter cites GIS architect David Buchanan reducing processing from 5 hours to 30 minutes compared with GeoPandas. --- ## Location Intelligence with Isochrones: A Complete Guide URL: https://wherobots.com/blog/scale-location-intelligence-new-functions-overture-dataset-isochrones/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. What Are Isochrones and Why They Matter for Location Intelligence Isochrones are polygons showing areas reachable within specific travel times from a location. They help businesses make data-driven decisions about site selection, risk assessment, and resource allocation by accounting for actual road networks and travel constraints—unlike simple radius-based approaches. Key takeawaysIsochrones show reachable areas based on actual travel time, not simple distanceWherobots can generate tens of thousands of isochrones per minuteFree Overture Places dataset includes 53.2M pre-computed isochrones for 13.3M US locationsUse cases span retail, logistics, insurance, healthcare, and emergency servicesComplete US-wide site selection analysis costs under $110 and takes 30 minutes You can now accelerate, scale, and improve the effectiveness of risk-based and location-based decisions using new isochrone functions for SQL and Python in Wherobots. These functions are specifically designed to generate isochrones for location intelligence, enabling data teams to make data-driven decisions with greater accuracy and speed. Additionally we are announcing a free and open source isochrones-extended Overture Places dataset, to make it easy for you to make data-driven risk assessments and location decisions based on travel time at scale. Click here to launch this interactive notebook Launch Notebook ST Functions for IsochronesThe new functions (ST_Isochrones, ST_Isochrone) are purpose-built for generating isochrones for analytical scenarios at scale and high speed. Running on Wherobots’ cloud-parallel compute, they are capable of generating tens of thousands of travel isochrones per minute, from or to points of interest, at a very low cost. These functions are best used inline with Wherobots’ 300+ SQL and Python spatial functions operating on various data types, enabling the generation of isochrones for location intelligence at scale. Most notably are the Wherobots’ GeoStats functions that identify geospatial data clusters and hot spots. When combined, these capabilities make it easy for any data team to streamline risk and location-finding decisions on a continental scale. We’ll show you how in a US-wide fire department site selection analysis later in this blog. ---Generating 30 min travel isochrones using Overture Places SELECT *, ST_Isochrone(geometry, 30, 'car', false) AS isochrone FROM wherobots_open_data.overture_maps_foundation.places_place WHERE ST_Intersects(geometry, ST_GeomFromWKT('')) Overture Places with IsochronesWe dogfooded ST_Isochrones in WherobotsDB to create a free and open version of the Overture Places dataset extended with 53.2 million precomputed travel isochrones for 5, 10, 15 and 20 minute car travel times, for all 13.3 million US places in the dataset. The isochrone extended Overture Places dataset is now hosted in the Wherobots Spatial Catalog for anyone to use under the CDLA Permissive 2.0 license. This dataset makes it very easy for anyone to create location intelligence from isochrones, and is ready for experimentation and production use. ---Joining isochrones to buildings in Overture SELECT * FROM wherobots_open_data.overture_maps_foundation.buildings_building AS buildings JOIN wherobots_pro_data.overture_maps_foundation.overture_places_with_isochrones AS isochrones ON ST_Intersects(buildings.geometry, isochrones.geometry Getting StartedThe new isochrone functions along with the Overture Places dataset extension are offered at no additional cost in the Professional Edition of Wherobots. You can use these features after subscribing to the Wherobots Professional Edition through the AWS Marketplace. How Travel Isochrones Work Travel isochrones are polygons that define how far something can travel from or to a given location within a specified time and travel mode. This forms an area also known as reach. Unlike traditional radius or point-to-point based heuristics that ignore real-world conditions, isochrones can account for the actual travel constraints of road networks, transportation modes, and even congestion. A 10 minute travel isochrone from a point in St. Louis, MO. Note how the Mississippi River affects reach.  Why Data-Driven Location Decisions Beat Intuition Where you invest has a long-term impact on a location’s overall profitability. The mantra of “location, location, location” is absolutely still alive. But unlike 20 years ago, you now have the ability to let off-the-shelf data and modern geospatial engines like Wherobots tell you where the ideal physical locations are to invest in, across hundreds of thousands of options, using a few lines of SQL. Isochrones help you forecast network travel costs that cling to locations over time, and can burden a location’s profitability. These can be actual – like fuel, electricity, and labor expenses, or they are costs that weigh on your ability to sell, reflect risk, and take share of a market opportunity. As an example, if you are looking to expand your business via a new location, know where clusters of your target customers are or may be, and where your competitors are, you’ll naturally gravitate to picking locations that minimize travel costs for these customers and choose areas where you know you can be competitive. If you have hundreds or thousands of customer clusters to possibly serve, you’ll want to use Wherobots to help you find the right locations to invest in, and create a competitive advantage via location intelligence. 6 Industries Using Isochrone Analysis No matter your industry, location and speed determines your market reach. The following are typical industries and use cases better enabled via isochrones. Retail: Identify prime brick and mortar locations with high customer density, low travel costs, and minimal competition. Logistics & Supply Chain: Optimize distribution network design and reduce delivery costs. Insurance & Real Estate: Actuarial analyses assess emergency coverage to influence policy pricing and property valuation. Service Coverage: Identify strategic locations for healthcare and emergency services based on demographic accessibility. Advertising and Marketing: Identify prime locations for billboards, advertising campaigns, while identifying underserved audiences to reach.   Infrastructure: Select the ideal location for capital investments that optimize for long-term results. Case Study: Nationwide Fire Department Site Selection in 30 Minutes The goal of this example is to show you how easy it is to complete a nation-scale site selection analysis using Wherobots. In this example, we will narrow down logical options for new fire departments across the entire US, based on clusters of higher risk places. A place was arbitrarily deemed “high risk” if it took more than 30 minutes for a fire truck to reach the place based on the location of the nearest fire department. For a total compute cost of less than $110, and in less than 30 minutes of compute time, using Wherobots you can answer and automate nationwide questions on-demand, like “where is risk” and “where should my [investment or asset] be located in a country?” Site Selection Example In this example we used an Wherobots XL runtime, and started by computing 30 minute travel isochrones for all 29,777 US fire departments in the original Overture Places dataset in 20 minutes. This step cost $98. isochrones = sedona.sql(f''' SELECT *, ST_Isochrone(geometry, 30, 'car', false) AS isochrone FROM wherobots_open_data.overture_maps_foundation.places_place WHERE categories.primary = 'fire_department' AND ST_Intersects(geometry, ST_GeomFromWKT('')) ''') Then we joined 13.3 million places to the 30 min isochrones (one for each 29,777 fire department) to classify places as high risk when fire trucks cannot reach them within 30 min of travel time. This join took 51 seconds to complete using the following query. fire_risk = sedona.sql(''' SELECT places.*, iso.isochrone FROM wherobots_open_data.overture_maps_foundation.places_place as places LEFT JOIN isochrones AS iso ON ST_Intersects(iso.isochrone, places.geometry) WHERE iso.isochrone IS NULL AND ST_Intersects(places.geometry, ST_GeomFromWKT('')) ''') Finally, we applied the popular clustering algorithm DBSCAN, available in Wherobots’ GeoStats, to identify 688 high risk clusters of places. The clustering step took 90 seconds to complete. In a real example, you may want to rank these clusters, based on some characteristic like total asset value in a cluster, to finalize your site selection analysis. clustered_fire_risk = sedona.sql(''' SELECT *, ST_DBSCAN(geometry, 10000, 25, true) AS dbscan_result FROM fire_risk ''') The join and clustering step took ~140 seconds, for a cost of $11.41. In total, the nation-wide analysis cost less than $110, took less than 30 minutes to complete, and required 12 lines of SQL.Alternatively, if you utilize the new Overture Places with Isochrones dataset instead of generating isochrones in the query, the total query time in this example was 10 minutes, for a total cost of $37 (~66% less). You can run the same analysis using alternative datasets too, such as Foursquare’s Places dataset. Here’s a visual showing the clusters of potentially “high risk” places from a perspective of fire response coverage. You can also explore these results in our online PM tile viewer. Clusters of “high risk” places outside of a 30 min reach from the nearest fire department. You can start with a smaller scale, lower cost version of this example yourself using the “Isochrones” notebook in Wherobots, or explore how easy it is offline in GitHub. You can easily scale it up to fit your needs, and automate these results using Wherobots Job Runs.  Traditional Isochrone Methods vs. Modern Solutions Until now, if you wanted to perform a site selection analysis like the one above, you’d need to generate thousands of isochrones using rate limited APIs like those offered by Esri and others. Isochrone APIs like these are designed to generate isochrones for online, interactive applications like a map, but by nature they are not designed for integrating isochrones into offline decision-making processes at-scale. For example, it would take many hours just to generate isochrones in the previous fire response example using these APIs vs 20 minutes in Wherobots. Developers may also need to push these results from isochrone APIs into another system that may not be as optimized for spatial analytics, adding on undifferentiated expense.  Pre-Computed Isochrones Dataset for Overture Places The precomputed isochrones dataset for Overture Places is available in the Wherobots Pro Spatial Catalog, which is available to Professional Edition subscribers. wherobots_pro_data.overture_maps_foundation.overture_places_with_isochrones The table contains a US-wide version of the Overture Places dataset extended with four outbound car travel isochrone geometries per place. Schema Updates: The following columns are in addition to the base Overture Places schema, release version 2025-03-19.0 Column NameTypeDescriptionisochrone_5mingeometryArea reachable in 5 minutes from placeisochrone_10mingeometryArea reachable in 10 minutes from placeisochrone_15mingeometryArea reachable in 15 minutes from placeisochrone_20mingeometryArea reachable in 20 minutes from place All geometries were generated using the ST_Isochrones function with inbound = false and mobility_type = ‘car’. Dataset Specifications: Geographic coverage: All 50 US states and territories Number of places: 13.3 Million Total isochrones generated: 52.3 Million Mode of travel: car Direction: outbound (from each place) Time thresholds: 5, 10, 15 and 20 minutes CRS: EPSG:4326 (WGS84) CostsLike all other Wherobots functions, when you use ST_Isochrones you pay for the serverless computation you use, measured by spatial units. And its capability scales with the runtime size you choose. Use is not limited by requests, and your costs will scale with the computational complexity of the isochrones you are requesting. As previously mentioned, the Wherobots version of the Overture Places dataset is free to use.  How to Get Started to Generate Isochrones Start enhancing your location intelligence by subscribing to the Professional Edition of Wherobots via the AWS Marketplace. This gives you access to the new version of the Overture Places dataset and the ST Isochrones function. After subscribing, create and open a runtime. Then open the “Isochrones” example notebook and run all cells. You can explore the Isochrone functions in more detail in the product documentation. We welcome feedback on the functions and dataset. Please reach out to product@wherobots.com to share what you need and what you build. We are eager to learn how to improve future enhancements. Start building with Wherobots Get Started Frequently Asked Questions What are travel isochrones? Travel isochrones are polygons that define reachable areas within specific time limits, accounting for actual road networks and travel modes. How are isochrones different from radius-based analysis? Unlike simple radius buffers, isochrones account for real-world constraints like road networks, traffic patterns, and geographic barriers. What industries use isochrone analysis? Retail (site selection), logistics (route optimization), insurance (risk assessment), healthcare (service coverage), real estate (property valuation), and emergency services (response planning). How fast can Wherobots generate isochrones? Wherobots can generate tens of thousands of travel isochrones per minute using cloud-parallel computing. --- ## Benefits of Apache Iceberg for geospatial data analysis URL: https://wherobots.com/blog/benefits-of-apache-iceberg-for-geospatial-data-analysis/ Updated: 2026-10-19 Apache Iceberg is an open table format that recently added support for geometry data columns, which is game changing for geospatial data users both big and small.  Today, spatial data users have a problem if they need to scale above about a million features:  Key takeawaysApache Iceberg now supports geometry columns. That addresses a gap: traditional spatial files and row-oriented databases struggle beyond about a million features, fit-in-memory tools fall over, and immutable file dumps cannot handle changing data.Geometry-in-Iceberg sits on Parquet for fast, larger-than-memory reads and adds database-like DML (insert, update, merge, delete), ACID transactions, versioning, and time travel. The post shows this on a format-version 3 table of linestrings.Deletes can use spatial predicates (ST_Crosses in the example) as reliable transactions without taking the table down, unlike rewriting a data lake by hand.Time travel queries any snapshot (the demo table had three appends plus a delete). Upserts use MERGE.Schema enforcement rejects extra columns; schema evolution ADD COLUMNS then accepts them. Compaction via rewrite_data_files and merge-on-read delete vectors round out production ops.File listing is cheaper than a raw data lake because Iceberg metadata already has paths and file-level stats. The post argues an Iceberg table is almost always a better option than a plain Parquet lake, and converting existing Parquet is straightforward. Traditional file formats and row-oriented databases perform poorly compared to non-spatial equivalents like Parquet.  Some solutions only work well for data that comfortably fits in memory Other solutions only work well for data that does not change. Geometry in Iceberg allows for the best of both worlds:  It is built on Parquet, offers lightning fast reads, and is scalable for larger than memory data sets. It offers developer-friendly features like DML operations (insert, update, merge, and delete) that spatial users might expect from a database-backed spatial file format.  Beyond that, it implements extra features like versioning and time travel to allow queries against current or historical data. Let’s take a look at these features! Reliable geospatial transactions with Iceberg Iceberg provides reliable transactions, so data operations are completed fully and successfully or do not run at all. Data lakes don’t support transactions, which can cause issues: Suppose you’re writing to a data lake, and the compute engine errors in the middle of the write. The partially written files will corrupt the data lake and require manual cleanup. Data lakes are unreadable while DML operations are running (e.g. while files are being written). Data lakes don’t provide concurrency protection. Developers who usually work with databases are often surprised by these data lake limitations because databases have supported transactions for decades. Lakehouse storage systems significantly improve data lakes with reliable transactions. Create an Iceberg table with geometry data Let’s create an Iceberg table with the following linestrings: You can start by creating the Iceberg table: CREATE TABLE LOCAL.db.icetable (id string, geometry geometry) USING iceberg TBLPROPERTIES('format-version'='3'); Append lines a and b to the table: df = sedona.createDataFrame([ ("a", 'LINESTRING(1.0 3.0,3.0 1.0)'), ("b", 'LINESTRING(2.0 5.0,6.0 1.0)'), ], ["id", "geometry"]) df = df.withColumn("geometry", ST_GeomFromText(col("geometry"))) df.write.format("iceberg").mode("append").saveAsTable("local.db.icetable") Now append lines c and d to the table: df = sedona.createDataFrame([ ("c", 'LINESTRING(7.0 4.0,9.0 2.0)'), ("d", 'LINESTRING(2.0 7.0,4.0 9.0)'), ], ["id", "geometry"]) df = df.withColumn("geometry", ST_GeomFromText(col("geometry"))) df.write.format("iceberg").mode("append").saveAsTable("local.db.icetable") Finally append lines e and f to the table: df = sedona.createDataFrame([ ("e", 'LINESTRING(6.0 7.0,6.0 9.0)'), ("f", 'LINESTRING(8.0 7.0,9.0 9.0)'), ], ["id", "geometry"]) df = df.withColumn("geometry", ST_GeomFromText(col("geometry"))) df.write.format("iceberg").mode("append").saveAsTable("local.db.icetable") Check the content of the table: sedona.sql("SELECT * FROM local.db.icetable;").show(truncate=False) +---+---------------------+ |id |geometry | +---+---------------------+ |e |LINESTRING (6 7, 6 9)| |f |LINESTRING (8 7, 9 9)| |a |LINESTRING (1 3, 3 1)| |b |LINESTRING (2 5, 6 1)| |c |LINESTRING (7 4, 9 2)| |d |LINESTRING (2 7, 4 9)| +---+---------------------+ Geospatial delete operations with Iceberg Iceberg makes it easy to delete rows of data in a table based on a predicate.  Suppose you’d like to delete all the linestrings in the table that cross a polygon for example: Here’s how you can delete all the linestrings that cross the polygon. polygon = "POLYGON((3.0 2.0, 3.0 5.0, 8.0 5.0, 8.0 2.0, 3.0 2.0))" sql = f"DELETE FROM local.db.icetable WHERE ST_Crosses(geometry, ST_GeomFromWKT('{polygon}'))" sedona.sql(sql) Check the table to see that linestrings b and c are deleted from the table. sedona.sql("SELECT * FROM local.db.icetable;").show(truncate=False) +---+---------------------+ |id |geometry | +---+---------------------+ |e |LINESTRING (6 7, 6 9)| |f |LINESTRING (8 7, 9 9)| |d |LINESTRING (2 7, 4 9)| |a |LINESTRING (1 3, 3 1)| +---+---------------------+ Iceberg delete operations are much better than what’s offered by data lakes. Data lakes don’t allow you to delete rows in a table. Instead, you need to filter and overwrite the whole table or run a tedious manual process to identify the files you need to rewrite. This process is error-prone, requires downtime for the data lake table, and could lead to irreversible data loss (if a file is accidentally deleted and not backed up, for example). This Iceberg geospatial delete operation does not require downtime and is a reliable transaction. Geospatial time travel with Iceberg Iceberg also allows for time travel between different versions of a table.  Let’s see all the current versions of the Iceberg table: sql = "SELECT snapshot_id, committed_at, operation FROM local.db.icetable.snapshots;" sedona.sql(sql).show(truncate=False) +-------------------+-----------------------+---------+ |snapshot_id |committed_at |operation| +-------------------+-----------------------+---------+ |1978905766678632864|2025-03-13 13:54:46.057|append | |8271841988321279736|2025-03-13 13:55:03.642|append | |9187521890414340610|2025-03-13 13:55:19.286|append | |1785310483219777508|2025-03-13 13:55:33.908|delete | +-------------------+-----------------------+---------+ Let’s check the contents of the table before the delete operation was run: sql = "SELECT * FROM local.db.icetable FOR SYSTEM_VERSION AS OF 9187521890414340610;" sedona.sql(sql).show(truncate=False) +---+---------------------+ |id |geometry | +---+---------------------+ |c |LINESTRING (7 4, 9 2)| |d |LINESTRING (2 7, 4 9)| |a |LINESTRING (1 3, 3 1)| |b |LINESTRING (2 5, 6 1)| |e |LINESTRING (6 7, 6 9)| |f |LINESTRING (8 7, 9 9)| +---+---------------------+ And now let’s check the table state after the first append operation: sql = "SELECT * FROM local.db.icetable FOR SYSTEM_VERSION AS OF 1978905766678632864;" sedona.sql(sql).show(truncate=False) +---+---------------------+ |id |geometry | +---+---------------------+ |a |LINESTRING (1 3, 3 1)| |b |LINESTRING (2 5, 6 1)| +---+---------------------+ A new table version is created every time an Iceberg transaction is completed. Suppose you have a geospatial table and append new data daily.  You’re training a model on the data and are surprised that the model’s conclusions changed last week.  You’re unsure if your geospatial model provides different results because the data or model code has changed.  With time travel, you can run the latest model code on an earlier data version to help analyze the root cause. Time travel is commonly helpful in the following scenarios: Regulatory audit purposes Model training on different versions of a table Isolating specific versions of a table while iterating on model code  Iceberg lets you delete expired snapshots, which limits your ability to time travel.  Therefore, make sure you set each table’s retention properties correctly.   Geospatial upsert operations with Iceberg Iceberg also supports upsert operations, which allow you to update or insert rows in a table simultaneously. Upserts are especially useful when tables are updated incrementally regularly. Here are the current contents of the Iceberg table: +---+---------------------+ |id |geometry | +---+---------------------+ |d |LINESTRING (2 7, 4 9)| |e |LINESTRING (6 7, 6 9)| |f |LINESTRING (8 7, 9 9)| |a |LINESTRING (1 3, 3 1)| +---+---------------------+ Let’s perform an upsert with the following data: +---+---------------------+ |id |geometry | +---+---------------------+ |d |LINESTRING (2 7, 4 9)| # duplicate |e |LINESTRING (7 7, 6 9)| # updated geometry |z |LINESTRING (6 7, 6 9)| # new data +---+---------------------+ Here’s how the upsert append should run: New data should be appended Existing data should be updated Duplicate data should be ignored Here’s the code to execute this operation: merge_sql = """ MERGE INTO local.db.icetable target USING source ON target.id = source.id WHEN MATCHED THEN UPDATE SET target.geometry = source.geometry WHEN NOT MATCHED THEN INSERT (id, geometry) VALUES (source.id, source.geometry) """ sedona.sql(merge_sql) Here are the contents of the table after running this operation: +---+---------------------+ |id |geometry | +---+---------------------+ |a |LINESTRING (1 3, 3 1)| |d |LINESTRING (2 7, 4 9)| |e |LINESTRING (7 7, 6 9)| |z |LINESTRING (6 7, 6 9)| |f |LINESTRING (8 7, 9 9)| +---+---------------------+ The MERGE command has many other practical applications for geospatial tables. Geospatial schema enforcement with Iceberg Iceberg supports schema enforcement, prohibiting appending data with a mismatched schema to the table. It will error if you try to append a DataFrame with a mismatched schema to an Iceberg table. Let’s create a DataFrame with a different schema than table: df = sedona.createDataFrame([ ("x", 2, 'LINESTRING(8.0 8.0,3.0 3.0)'), ("y", 3, 'LINESTRING(5.0 5.0,1.0 1.0)'), ], ["id", "num", "geometry"]) df = df.withColumn("geometry", ST_GeomFromText(col("geometry"))) Now attempt to try and append the DataFrame to the table: df.write.format("iceberg").mode("append").saveAsTable("local.db.icetable") Here is the error: AnalysisException: [INSERT_COLUMN_ARITY_MISMATCH.TOO_MANY_DATA_COLUMNS] Cannot write to local.db.icetable, the reason is too many data columns: Table columns: id, geometry. Data columns: id, num, geometry. The append operation is prohibited because the DataFrame schema differs from the Iceberg table schema. Data lakes don’t have built-in schema enforcement, so you can append data with mismatched schema, which can corrupt a table or require developers to use specific syntax when reading the table. Schema enforcement is a nice feature that protects the integrity of your data tables. Geospatial schema evolution with Iceberg Iceberg also allows you to evolve a table’s schema when you want to add or remove columns. Add a num column to the Iceberg table: sql = "ALTER TABLE local.db.icetable ADD COLUMNS (num INTEGER);" sedona.sql(sql) Now try to append the DataFrame with id, num, and geometry columns to the Iceberg table: df.write.format("iceberg").mode("append").saveAsTable("local.db.icetable") The append operation now works since the schema was evolved.  Take a look at the contents of the table now: sedona.sql("SELECT * FROM local.db.icetable;").show(truncate=False) +---+---------------------+----+ |id |geometry |num | +---+---------------------+----+ |e |LINESTRING (6 7, 6 9)|NULL| |f |LINESTRING (8 7, 9 9)|NULL| |d |LINESTRING (2 7, 4 9)|NULL| |x |LINESTRING (8 8, 3 3)|2 | |y |LINESTRING (5 5, 1 1)|3 | |a |LINESTRING (1 3, 3 1)|NULL| +---+---------------------+----+ You cannot evolve the schema of a data lake. Developers must manually specify it when they read the data, or the engine must infer it. It’s problematic for engines to infer the schema because it can be slow if all the data is read or wrong if only a subset of the data is sampled to determine the schema. Efficient geospatial file listing operations with Iceberg When an engine queries a data lake, it must perform a file listing operation, read all the metadata from the file footers, and then execute the query.  For large datasets, file listing operations can be relatively slow.  They take longer if the dataset uses deeply nested Hive-style partitioning or cloud object stores. File listing operations are faster with Lakehouse storage systems like Iceberg. The engine can get all the file paths and file-level metadata directly from the metadata, so fetching metadata from a Lakehouse storage system is much faster than performing a separate file listing operation. Small file compaction of geospatial files with Iceberg Query engines don’t perform as efficiently when there are many small files. A table composed of 10 one-gig files usually performs much better than a table with 10,000 one-mb files. Iceberg supports small file compaction, automatically rearranging small files into bigger files and eliminating the small file problem. You can compact the small files in an Iceberg table using the rewrite_data_files stored procedure. CALL system.rewrite_data_files(table => 'local.db.icetable') Data lakes don’t support compaction, so you must manually compact the small files, which requires table downtime and is error-prone. Iceberg merge on read operations Iceberg supports both copy-on-write and merge-on-read for DML operations.  Copy-on-write operations immediately rewrite all files, which is slow.  Lakehouse storage systems store data in immutable Parquet files, so rewriting entire files is necessary for some DML operations. Merge-on-read implements DML operations differently.  Rather than rewriting the underlying data files, merge-on-read operations output deletion vector files with the diffs.  Subsequent reads are slightly slower because the data files and deletion vector files must be “merged,” but this strategy dramatically reduces the runtime of DML operations. Merge-on-read generally offers a better set of tradeoffs than copy-on-write.  Iceberg supports merge-on-read, and data lakes do not.Here’s how to enable merge-on-read for an Iceberg table: ALTER TABLE LOCAL.db.icetable SET TBLPROPERTIES ( 'write.delete.mode'='merge-on-read', 'write.update.mode'='copy-on-write', 'write.merge.mode'='copy-on-write' ); Conclusion Lakehouses bring many new features to the geospatial data community. An Iceberg table is almost always a better option than a Parquet data lake because it offers many advantages. If you already have Parquet tables, converting them into Iceberg tables is straightforward. It’s great to see how the geospatial data community collaborated closely with the Iceberg community to update the Iceberg spec to support geometry columns. The community can now start investing in spatial tables in Lakehouses, which are more performant and reliable in production applications. Here are some other blog posts in case you’d like to learn more: Iceberg GEO: Technical Insights and Implementation Strategies Apache Iceberg and Parquet now support GEO Iceberg v3 Gets Native Geo Types. It’s More Than a Format Upgrade Stay up-to-date with the latest on Wherobots, Apache Sedona, and geospatial data by subscribing to the Spatial Intelligence Newsletter: Frequently Asked Questions Why use Apache Iceberg for geospatial data? Iceberg geometry columns combine Parquet-speed, larger-than-memory reads with transactions, DML, schema evolution, time travel, and compaction. Data lakes and many spatial file formats lack these features, especially above about a million features. Can I run spatial DELETE and MERGE on Iceberg geometry tables? Yes. The post deletes linestrings with ST_Crosses against a polygon and upserts with MERGE INTO when matched / when not matched. Those operations are Iceberg transactions and do not require table downtime. What is Iceberg time travel for geospatial tables? Each completed transaction creates a snapshot. You can SELECT FOR SYSTEM_VERSION AS OF snapshot_id to query historical geometries.This is useful for audits, model training on prior data, and isolating table versions while you change model code. Expired snapshots cannot be traveled to, so set retention deliberately. Does Iceberg enforce geospatial table schemas? Yes. Appending a DataFrame with extra columns fails with an arity mismatch until you ALTER TABLE ADD COLUMNS. Data lakes have no built-in schema enforcement and can be corrupted by mismatched writes. --- ## The Spatial Intelligence Newsletter: Map Matching, Spatial Joins, ML for EO, Cloud-Native Geospatial and More URL: https://wherobots.com/blog/march-spatial-intelligence-newsletter-cloud-native-geospatial-and-more/ Updated: 2026-10-19 👋 Welcome back to the latest edition of the Spatial Intelligence Newsletter! We’ve been busy brewing up some exciting things here at Wherobots, so we have plenty of new updates and content to share! Key takeawaysThis March 2025 newsletter is a content and community roundup covering map matching, Iceberg/Parquet GEO, the MLM STAC Extension, getting-started videos, and upcoming events.It highlights Wherobots map matching for snapping noisy GPS to real road networks. It also highlights native geometry/geography types in Apache Iceberg and Parquet, so engines such as Wherobots, DuckDB, Sedona, Spark, Databricks, Snowflake, and BigQuery can share one copy of the data.A companion technical post on Iceberg GEO design is featured. So is a panel on the MLM STAC Extension and Raster Inference for describing and running computer-vision models on overhead imagery.Getting-started pointers include Wherobots 101 and 102 sessions and a Foursquare Open Places tutorial (100M+ global POIs) that maps San Francisco coffee shops by neighborhood.Community: Comcast Sedona ETL story, O'Reilly Sedona vector-SQL chapter, monthly office hours, a spatial-joins webinar, and a fireside chat with Overture Maps and Dotlas on cloud-native geospatial. Latest Content Don’t Let Messy GPS Slow You Down. The Fastest Way to Clean Up Messy GPS Data – And Save Money  Raw GPS data is messy. 😵‍💫 Noisy signals, lost connections, and inaccuracies make it hard to extract valuable insights. Imagine using your GPS to get to your location, only to find it telling you to drive over water instead of the road (personally, I’ve even had the map tell me to walk on water 🌊🚶🏻‍♀️). Wherobots’ map matching corrects trajectories by aligning them with real-world road networks (❌no more walking on water! ), all while delivering unmatched accuracy and performance (and saving money!). Apache Iceberg and Parquet now support GEO– A Huge Step Forward for Cloud Native Geo Geospatial data has always been thought of as a second class citizen because of what modernized the data ecosystem of today, leaving geospatial data mostly behind. But that’s no longer the case. Thanks to the efforts of the Apache Iceberg and Parquet communities, both Iceberg and Parquet now support geometry and geography (collectively the GEO) data types! 🎉 What does this mean? With native geospatial data type support in Apache Iceberg and Parquet, you can seamlessly run query and processing engines like Wherobots, DuckDB, Apache Sedona, Apache Spark, Databricks, Snowflake, and BigQuery on your data. All the while benefitting from faster queries and lower storage costs from Parquet formatted data. 💨 Exploring design and key features to enhance spatial data workloads with Iceberg GEO With Apache Icerberg and Parquet now supporting GEO types, this helps improve the economics of utilizing geospatial data in end solutions.This advancement allows organizations to create higher-value, lower-cost products and achieve faster results over time. Let’s take a closer look at these GEO data types in Iceberg, exploring their design, key features, and implementation considerations. Learn how leveraging these features with Apache Sedona and Wherobots can enhance cost performance and data governance, ensuring the best possible experience for spatial data workloads. 📈 Optimizing Earth Observation Models for Production with ML Model Extension What are the challenges of applying AI to geospatial problems? 🤖Join panel speakers from Wherobots, Radiant Earth, CRIM and Terradue as they discuss how this challenge led to the development of an open, portable solution for describing computer vision models trained on overhead imagery.  Learn about the MLM STAC Extension, its use cases, and why model developers should adopt it, along with Raster Inference– a serverless computer vision solution that extracts valuable insights from aerial imagery. 🌎 Getting Started With Wherobots Interested in getting started with Wherobots, but unsure of where to begin? Here are some helpful resources. 👇 Wherobots 101: Mastering Scalable Geospatial Data Processing  Want to take your geospatial analytics to the next level? Whether you’re just starting out or already working with spatial data, learn how to leverage valuable tools and workflows in Wherobots Cloud to analyze, visualize and interpret geospatial datasets. From setting up your account to mastering advanced analytics, this session is a helpful guide to set you up for success! Wherobots 102: Reading and Processing Cloud Native Geospatial Data  Learn how to efficiently load, manage and analyze raster and vector data in Wherobots’ hosted environment. Whether you’re working with massive geospatial datasets or looking for optimized workflows to write and query GeoParquet and Cloud-Optimized GeoTIFFs (COGs), this video will equip you with the tools and techniques to scale your geospatial analysis. Working with Foursquare Places Data Which neighborhood in San Francisco has the most coffee shops? Dive into the Foursquare Open Places dataset, a free and open dataset providing 100M+ global places of interest, with our latest tutorial. ☕ You’ll be able to query using Spatial SQL, subset the data for a specific region, search for specific businesses or places, and aggregate locations by geography. By the end of this tutorial, you’ll have a choropleth map showing the number of coffee shops, sorted by neighborhood. Apache Sedona Community Sedona Success Story: Optimizing ETL pipelines at scale with Comcast 🚀 Is scaling your ETL pipeline a priority? Discover how Comcast successfully achieved this by using Apache Sedona, all while boosting productivity and improving the quality of their network operations. 🌐 Learn how Apache Sedona reduces vendor lock-in. Understand why it outperforms tools like GeoPandas and PostGIS. See how it improves the ability of the Xfinity network team to optimize their network operations through a global view of performance quality and degradation. Find out how it integrates seamlessly with Apache Spark and other distributed engines. O’Reilly: Cloud Native Geospatial Analytics with Apache Sedona – Navigating Large-Scale Spatial Data We know that handling large-scale spatial data can be daunting, which is why we’ve designed this guide to simplify geospatial data. This will help boost your spatial analytics expertise and transform the way you work with geospatial data! 💪  Our newest chapter, focusing on vector data analysis using spatial SQL, is now available. If you’ve already accessed the previous chapters, be sure to check your inbox (on a separate email) for the latest one! 📧 Engage with the Community Through Sedona Office Hours We host monthly office hours to bring you the latest news and updates to Apache Sedona. Mark your calendars for the next one. Even if you can’t make it, we’ll send you the recording and slides to make sure you don’t miss anything that might be helpful to you. 🤝 Upcoming Events Spatial Joins at Scale: Unlocking Advanced Geospatial Analytics If you’ve ever struggled with Spatial Joins (you know who you are), then this is the one to join (pun intended, courtesy of Matt Forrest 😎)! Learn how to seamlessly integrate Python and Wherobots to perform advanced spatial joins and analyses on geospatial data. Gain practical skills and best practices for processing and visualizing spatial data at scale. Don’t miss this opportunity to boost your spatial analytics expertise and transform how you work with geospatial data.  Fireside Chat with Overture Maps and Dotlas on Cloud-Native Geospatial: More Than Just Big Data How is cloud-native geospatial reshaping the way organizations interact with spatial data? ☁️🌎 It prioritizes flexibility, changes how data consumers connect, removes friction, and unlocks new possibilities. Join us, alongside Amy Rose from the Overture Maps Foundation and Eshwaran Venka from Dotlas, as we explore how modern approaches enable scalability across various compute infrastructures, eliminate the need to move massive datasets, and allow users to work with data wherever they are—whether locally or in the cloud. Hear about where geospatial technology is headed. This is a conversation you definitely don’t want to miss! Getting Started 🆓 Getting started with Wherobots is easy. If you haven’t already, create a free account and dive in. If you’re looking to take your geospatial analytics to the next level—whether it’s full access to open datasets, map matching, or raster inference—try the Pro tier for free.  Get started with Wherobots Try Now Frequently Asked Questions What topics does the March 2025 newsletter cover? Map matching for messy GPS, Iceberg and Parquet GEO types, Iceberg GEO design, and the MLM STAC Extension and Raster Inference. Also Wherobots 101/102, Foursquare Places, the Comcast Sedona story, and upcoming spatial-join and cloud-native geospatial events. What is map matching in this issue? A Wherobots capability that corrects raw GPS trajectories by aligning them to real-world road networks, addressing noisy signals and implausible paths (the post walking-on-water example). Does the newsletter say Iceberg and Parquet support GEO? Yes. It states both Apache Iceberg and Parquet now support geometry and geography types. Multiple query engines can then run on the same Parquet-formatted geospatial data with faster queries and lower storage cost. How many places are in the Foursquare tutorial mentioned here? The newsletter describes Foursquare Open Places as a free and open dataset of 100M+ global points of interest, used in a tutorial that choropleths coffee shops by San Francisco neighborhood. --- ## Iceberg GEO: Technical Insights and Implementation Strategies URL: https://wherobots.com/blog/iceberg-geo-technical-insights-and-implementation-strategies/ Updated: 2026-10-19 In our previous blog post, we announced Apache Iceberg and Parquet’s support for spatial data types and discussed their significance. These enhancements significantly improve the economics of utilizing geospatial data in end solutions. Organizations will be capable of creating higher value, lower cost products, faster over time. Today, we take a closer look at these GEO data types in Iceberg (collectively Iceberg GEO), exploring design, key features, and implementation considerations. We will also demonstrate how to leverage these new Iceberg features with Apache Sedona and Wherobots in an upcoming blog post. Key takeawaysIceberg GEO grew from GeoParquet (2022) and Wherobots Havasu Iceberg extension (2023) into a native Iceberg spec in 2024. The spec has contributors from Wherobots, CARTO, Planet, Apple, Databricks, Snowflake, and others, rather than keeping spatial types in a fork.The spec adds two types: geometry (planar/Cartesian edges, local-scale work) and geography (ellipsoidal Earth, geodesic edges for global routing and satellite use). Six interpolation algorithms are identified; geography must declare which non-planar method it uses.Encoding follows OGC Simple Feature Access v1.2.1 in ISO WKB (Z/M allowed, no SRID in the bytes). Coordinate order is longitude-latitude (X, Y).CRS is stored as an SRID (e.g. srid:4326) or a PROJJSON document; geography allows only geographic CRSs.File bounds use west/east/north/south extents so antimeridian-crossing shapes (the Fiji waters example: 179°E as westernmost and −179°W as easternmost) do not look like they span the whole globe. Geography longitudes stay in [−180, 180] and latitudes in [−90, 90].Wherobots will migrate managed Havasu tables to native Iceberg automatically; self-managed Havasu tables get migration tools; raster-in-Havasu gets a dedicated path later. Catalogs that speak Iceberg REST work as-is; Glue/Hive/Polaris may need small type-recognition updates. The Story Behind Iceberg Support for GEO Types The foundation for Iceberg GEO can be traced back to early 2022 with the launch of the GeoParquet project, which aimed to standardize spatial data exchange across different vendors in the cloud-native and big data ecosystem. This initiative was a crucial first step toward unifying spatial data formats in modern data platforms. Its history, and how GeoParquet will become just Parquet, is described in this GeoParquet community blog post. As interest in spatial data support for lakehouses grew, early design explorations took shape through projects like GeoLake. Wherobots later expanded on these concepts, developing Havasu in 2023, a production-ready extension of Iceberg designed to support geometry, geography, and raster data in cloud data lakehouses. Havasu’s geometry encoding was inspired by GeoParquet, while its storage format remained fully Parquet-compatible, inheriting Iceberg’s key features such as ACID transactions, schema evolution, time travel, and data versioning. Recognizing the value and need to bring native spatial support to Iceberg, the cloud native spatial community ultimately decided that integrating these features directly into Iceberg would be more beneficial than maintaining a separate extension. This direction would ensure that spatial data was well supported by Iceberg without modifications. In early 2024, the spatial and Iceberg communities formally initiated discussions on adding GEO data type to Iceberg, using Havasu’s design as a reference. The collaboration involved many community members at Wherobots, CARTO, Planet, Apple, Databricks, Snowflake, and others. Through joint efforts and extensive discussions, the proposal was refined and successfully merged. Iceberg GEO Type Definitions and Storage The Iceberg GEO proposal introduces two spatial data types: geometry and geography. This distinction addresses the varying levels of spatial data processing support across different engines. Some primarily work with geometry, while others emphasize geography. The primary distinction between these types is how edges between points are interpolated. All other aspects of the Iceberg GEO proposal such as encoding, and bounds apply to both unless explicitly stated otherwise. Geometry Type The geometry type represents spatial objects in a planar space using Cartesian geometry, assuming all calculations, including distance and area measurements, are performed on a flat surface. It is best suited for applications requiring high-precision, local-scale spatial operations, such as urban planning, country-level modeling, and traffic engineering. Geometry uses planar edge interpolation, where edges between vertices are treated as straight lines. Geography Type The geography type represents spatial objects on the ellipsoidal surface of the Earth, making it more appropriate for global-scale applications such as satellite tracking, aviation navigation, and long-distance routing. Unlike geometry, geography accounts for the Earth’s curvature, ensuring that spatial operations like distance and area calculations reflect real-world geography. It requires non-planar edge interpolation algorithms, which define how edges between points behave on a curved surface. Edge Interpolation Algorithms Since the Earth is not flat, different interpolation methods impact the accuracy of spatial operations. The community identified six primary interpolation algorithms: Planar, Spherical, Vincenty, Thomas, Andoyer, and Karney. Taking Planar and Spherical as examples, planar interpolation assumes straight-line edges in a Cartesian plane and is used in the Geometry type while spherical interpolation models edges as geodesic curves on a sphere and could be used in the Geography type. Details of all interpolation methods can be found in this paper. The Iceberg Geography type requires implementations to explicitly specify which non-planar interpolation algorithm is used, ensuring consistency in spatial computations across different engines. Encoding Both Iceberg GEO types follow the OGC Simple Feature Access v1.2.1 data model, supporting geometric objects such as points, polygons, line strings, and geometry collections. It uses the ISO Well-Known Binary (WKB) format for encoding, which supports higher-dimensional geometries (Z and M values) but does not include a Spatial Reference Identifier (SRID). A more detailed comparison of WKB variants can be found in the GEOS library documentation. To ensure consistency across spatial tools, Iceberg GEO enforces a longitude-latitude (X, Y) coordinate order, aligning with standards used in GeoPandas, Apache Sedona, and Google Maps. Coordinate Reference Systems (CRS) Both geometry and geography types support CRS definitions using either a SRID (e.g., srid:4326) or a PROJJSON string (e.g., projjson: {…}), which provides a self-contained CRS definition. SRIDs are storage efficient for well-known coordinate systems, while PROJJSON allows detailed CRS specifications. A minor difference between the Geometry and Geography type is that the former allows any CRS, whereas the latter only allows geographic CRS, which only makes sense in the context of non-planar edge interpolation. Lower and Upper Bounds Iceberg GEO extends Iceberg’s lower and upper bounds statistics for spatial data by defining bounds based on the westernmost, easternmost, northernmost, and southernmost extents of spatial objects. While these longitude and latitude bounds can theoretically define the bounding box of a data file in Iceberg, allowing query predicates to be checked against it, they help optimize spatial filtering operations like ST_Intersects. However, certain complexities must be considered. This bounding method is necessary for handling objects that cross the antimeridian (±180° longitude), where the lower longitude bound may be greater than the upper bound. Additionally, for non-planar edge interpolation used in the Geography type, a shape’s bounding box may not always be defined by its vertices, requiring a more precise bounding approach. For example, the territorial waters of Fiji span both hemispheres, with points at (179°E, 18°S), (-179°W, 18°S), (-179°W, 16°S), and (179°E, 16°S). A naive min/max longitude calculation might incorrectly assume the bounding box extends from -179°W to 179°E, nearly covering the entire globe. Instead, Iceberg GEO correctly identifies 179°E as the westernmost point and -179°W as the easternmost, ensuring accurate query filtering and optimization. For geography types, longitude bounds must fall within [-180, 180], while latitude bounds must be within [-90, 90]. Operations and Catalogs DDL, DML, and DQL Iceberg GEO is natively supported by Iceberg’s table operations, allowing spatial data to be stored, modified, and queried efficiently. When defining a table schema, users can specify geometry or geography columns with optional CRS parameters. For data manipulation, Iceberg GEO supports inserting, updating, and deleting spatial data using formats such as WKB and WKT. Queries can leverage spatial functions like ST_Intersects, ST_Contains, and ST_Distance, enabling efficient spatial filtering and analysis. Iceberg’s manifest metadata optimizes query execution by pruning unnecessary data files, significantly improving performance for large datasets. Z-Ordering Iceberg GEO does not define a specific behavior for Z-ordering spatial objects, but engines can implement custom solutions. A common approach is to compute spatial indices such as H3 or S2 and use them for Z-order clustering. This helps preserve spatial locality in storage, improving query performance by reducing unnecessary scans. Compaction Compaction in Iceberg consolidates small files to improve performance. For spatial data, compaction can leverage Z-ordering to group spatially related objects together, enhancing data locality and reducing read overhead. During compaction, Iceberg needs to recalculate the lower and upper bounds for spatial objects to maintain accurate spatial statistics, ensuring that query pruning remains effective. Catalog Support Iceberg GEO is fully compatible with the Iceberg REST catalog, which stores metadata in JSON format and allows seamless integration across multiple compute engines. For catalogs like Apache Polaris, AWS Glue, and Hive Metastore, additional change may be required to recognize the new geometry and geography types. However, since Iceberg GEO follows Iceberg’s existing metadata structures, the effort required for adaptation is minimal. Migrating from Havasu-Iceberg to Native Iceberg GEO on Wherobots With the geo types now merged into Apache Iceberg, Wherobots will soon begin assisting customers in migrating all Havasu-Iceberg tables to native Iceberg tables. This transition will streamline spatial data management while ensuring full compatibility with the Apache Iceberg ecosystem. If you are using Wherobots-managed Havasu tables, we will handle the migration automatically. Your existing code and workflows will remain unaffected, and you will receive a notification once the migration is complete. For those using self-managed Havasu tables on Wherobots, we will provide migration tools to help transition your datasets to native Iceberg tables efficiently. Users relying on raster types in Havasu will have a dedicated migration solution available soon. Stay tuned for further updates. Wherobots is the best compute engine for processing spatial data, makes using Iceberg very easy, and has been tuned for working efficiently with Iceberg tables. Our technologies continue to enhance cost performance and data governance, ensuring the best possible experience for spatial data workloads. If you want to get started working with our Iceberg enabled Spatial Intelligence Cloud, and begin taking advantage of all the benefits of Iceberg GEO, sign up for a Wherobots pro account on the AWS marketplace, which includes $400 in compute credits. We are hosting regular getting started sessions, and the historical ones can be viewed on our Wherobots Youtube channel. As we mentioned upfront, expect to see additional content along with demonstrations in our blog moving forward. Sign up for our newsletter to stay up to date with everything we are doing to enable the spatial community to embrace the modern geospatial lake-house. Frequently Asked Questions What is the difference between Iceberg geometry and geography types? Geometry uses planar (Cartesian) edge interpolation for local, high-precision work. Geography represents objects on the ellipsoid with a declared non-planar interpolation algorithm, which is appropriate for global-scale distance and area. Encoding, bounds, and most metadata rules apply to both. How is Iceberg GEO data encoded? With the OGC Simple Features model stored as ISO Well-Known Binary. WKB can carry Z and M but not SRID; CRS lives in Iceberg metadata as an SRID or PROJJSON. Coordinates are stored longitude, latitude (X, Y). How does Iceberg GEO handle the antimeridian? Lower/upper bounds are westernmost/easternmost/northernmost/southernmost, so a lower longitude can be greater than the upper bound. The Fiji territorial-waters example is bounded 179°E to −179°W instead of incorrectly spanning −179° to 179°. How do I migrate Havasu tables to native Iceberg GEO? Wherobots-managed Havasu tables are migrated automatically with a notification when done. Self-managed Havasu tables on Wherobots will get migration tools. Raster types in Havasu will have a separate solution announced later. --- ## Apache Iceberg and Parquet now support GEO URL: https://wherobots.com/blog/apache-iceberg-and-parquet-now-support-geo/ Updated: 2026-10-19 Geospatial data isn’t special anymore, and that’s a good thing. Geospatial solutions were thought of as “special”, because what modernized the data ecosystem of today, left geospatial data mostly behind. This changes today. Thanks to the efforts of the Apache Iceberg and Parquet communities, we are excited to share that both Iceberg and Parquet now support geometry and geography (collectively the GEO) data types. Key takeawaysApache Iceberg and Apache Parquet now natively support geometry and geography (GEO) data types. Geospatial data can now live in the same open lakehouse formats as the rest of the modern data stack.Engines including Wherobots, DuckDB, Apache Sedona, Apache Spark, Databricks, Snowflake, and BigQuery can run on one copy of the data. Parquet brings faster queries and lower storage cost; Iceberg brings ACID transactions, versioning, time travel, and column/row-group pruning.The change is framed as breaking geospatial silos: no more proprietary file types and compute-coupled storage as the default path for spatial solutions.It was a grassroots effort across Planet, CARTO, Wherobots, GeoParquet, and the Iceberg community (quotes from Iceberg PMC member Szehon Ho and GeoParquet co-creator Chris Holmes). Hudi and Delta Lake are invited to add GEO as well.Wherobots already supported these types in Havasu (its Iceberg fork) and GeoParquet. WherobotsDB now runs natively on Iceberg and Parquet GEO with 3x faster query performance, and Sedona committers were adding support at the time of writing. Geospatial challenges Geospatial data has been disconnected from the broader data ecosystem that modernized from open file formats like Apache Parquet, and open table formats like Apache Iceberg, Delta Lake, and Apache Hudi.The benefits of these cloud-native open file and table formats fueled widespread adoption of data lake and lakehouse architectures. Organizations moved away from the use of expensive proprietary systems, away from data siloes that coupled compute with storage and didn’t scale, and away from formats that locked them in and stifled innovation. Relative to legacy options, these cloud-native formats fundamentally change how data is stored, managed, and accessed. This in turn lowers costs, increases agency, and unlocks innovation over time. But because geospatial data was different, which led to a number of technical challenges, it wasn’t supported by these formats from the start. As a result developers building solutions with geospatial data struggled with fragmented formats, proprietary file types, and data siloes – making solutions harder and costlier to build. The silos will break down With native geospatial data type support in Apache Iceberg and Parquet, you can seamlessly run query and processing engines like Wherobots, DuckDB, Apache Sedona, Apache Spark, Databricks, Snowflake, and BigQuery on your data. All the while benefitting from faster queries and lower storage costs from Parquet formatted data.These changes improve short and long term economics for geospatial solutions. Organizations will have a new freedom to innovate with a lower cost, highly interoperable architecture. They get to choose the best tool for the job over time without having to shuttle data between systems. Their costs reduce, productivity improves, innovation accelerates, and the playing field is leveled with respect to who can provide the best solution for their data. The legacy siloes will break down, just like they’ve done for non-geospatial data. And most importantly, these changes will lead to new innovation about our physical world.  Benefits of Iceberg and Parquet These changes make geospatial solutions based on a data lake a lot more attractive. Here are a few benefits.  Iceberg and Parquet alone don’t separate compute from storage, but together they make it possible to utilize low cost data lake storage, along with multiple independent high performance computing solutions for different use cases ACID transactions and data versioning enable the use of multiple compute engines without conflicts Time travel allows tracking of data changes over time Query performance is higher from features like column pruning, row-group filtering, and fast file access Open data formats minimize vendor lock-in Geospatial data will be supported across a broader ecosystem of tools and services And many more… See how these formats fit into a full Bronze, Silver, Gold pipeline in The Medallion Architecture for Geospatial Data Grassroots efforts made this happen These changes were the result of grassroots initiatives, investment, and influence from community members at Planet, CARTO, Wherobots, and many others across the Cloud Native Geospatial community. This includes GeoParquet, which was a grassroots project and an extension of Parquet that proved its worth through use and popularity, countless meetups, and discussions. And we also want to give credit to the Iceberg community for working with members of the Wherobots team, to bring a solution forward while also influencing the Parquet community to make a GEO native data type.While Iceberg and Parquet communities led with support for GEO data types, we welcome compatibility and support for GEO data types in all cloud-native formats, including Apache Hudi and Delta Lake. Thoughts from Szehon Ho, Apache Iceberg PMC Member“The long-awaited incorporation of geospatial data types in the Iceberg V3 spec extends a core theme of Iceberg as a project to provide a universal ‘shared warehouse storage’ across many engines and users, and will now allow this huge, growing ecosystem to work on the same geospatial data as well, unlocking many exciting use cases. It is also a demonstration of Iceberg community’s willingness to take the time and ‘do hard things’, engaging in months of very active discussions across companies and OSS communities, finally reaching consensus on a spec that supports the largest variety of use cases in the fast-evolving geospatial data domain.” Thoughts from Chris Holmes, co-creator of GeoParquet“The community developed and rallied behind GeoParquet to make geospatial data in Parquet fully interoperable and to let the geospatial world tap into all the advantages the big data world has been getting from Parquet. I’m very excited to see Parquet and Iceberg formally support geospatial types, and look forward to the acceleration in geospatial innovation that these changes will activate across industries and for our planet.” Looking ahead Committers are already working to bring support for these changes into Apache Sedona, and will notify the community as they are introduced.  At Wherobots, we’ve supported these GEO data types in Havasu (our Iceberg fork) which we built to enable geospatial lakehouse architectures with Wherobots, along with GeoParquet. We’ve begun developing native support for Iceberg and Parquet into how Wherobots operates on customer data, and will put our full support behind these native formats moving forward. WherobotsDB now runs natively on these formats, delivering 3x faster query performance.To learn more about the reasoning behind the Iceberg GEO types design, the trade-offs we navigated, and what it all means for implementers, please read our follow-up blog: Iceberg GEO: Technical Insights and Implementation Strategies. If you need support throughout your journey adopting and utilizing these cloud-native formats for geospatial use, reach out to Apache Iceberg on Slack or Apache Sedona on Discord. Watch this livestream with leaders from Foursquare, Databricks, Planet, and Wherobots as they discuss the historical challenges of handling spatial data, bridging the gap, and future adoption of these advancements. Sign up for our newsletter to stay up to date with everything we are doing to enable the spatial community to embrace the modern geospatial lake-house. Frequently Asked Questions Do Apache Iceberg and Parquet support geospatial types now? Yes. Both projects added native geometry and geography (GEO) data types, so spatial columns can be stored in standard Parquet files and Iceberg tables instead of sidecars or proprietary formats. Which engines can query Iceberg/Parquet GEO? The post lists Wherobots, DuckDB, Apache Sedona, Apache Spark, Databricks, Snowflake, and BigQuery as engines you can run on the same GEO-typed data. What benefits do Iceberg and Parquet give geospatial workloads? Decoupled compute and low-cost object storage, ACID transactions and multi-engine access without conflicts, time travel, column pruning and row-group filtering, and less vendor lock-in from open formats. How much faster is WherobotsDB on native Iceberg/Parquet GEO? The post states WherobotsDB now runs natively on these formats, delivering 3x faster query performance. It does not publish a fuller benchmark table here. --- ## Wherobots 2024 accomplishments, and what’s on-deck in 2025 URL: https://wherobots.com/blog/reflecting-on-wherobots-accomplishments-2024/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. Introduction 2024 was a transformative year for Wherobots. Our mission to revolutionize how geospatial data is used took significant strides forward, positively impacting our customers and industry. Over the past year, we more than tripled the size of our team and successfully closed a $21.5M Series A funding round. We expanded accessibility to Wherobots’ industry-leading geospatial query performance, integrated Wherobots into the native AWS buying experience, and unveiled groundbreaking features like Raster Inference, Map Matching, and GeoStats—empowering users to create scalable geospatial solutions like never before. Key takeawaysThis January 2025 year-in-review covers 2024 milestones rather than a single product launch. The team more than tripled, and Wherobots closed a $21.5M Series A led by Felicis, with Wing, Clear Ventures, JetBlue Ventures, and P7 Ventures.AddressCloud cut property-level flood/fire peril jobs from hours or days to minutes, including combined vector/raster analysis without converting rasters first. Overture global buildings pipeline (2.3 billion geometries in this post) accelerated up to 20x after a code redirect onto Wherobots.The company cites up to 20x better spatial-join performance than modern cloud data engines, full raster+vector support, Apache Sedona compatibility, and Iceberg/Parquet lakehouse architecture.2024 product launches included AWS Marketplace pay-as-you-go, S3 storage integration, SAML SSO, Spatial SQL API plus TypeScript/Python SDKs and JDBC, and the Havasu Catalog.They also included Raster Inference, distributed map matching, GeoStats, KNN joins, VTiles, Airflow job runs, and service principals. Starred items are Professional/Enterprise only.2025 plans stated here: AWS Europe (Ireland), SOC 2 Type 2 (then in progress), easier Earth observation, developer experience, query performance, availability, and admin/observability. A 30-day AWS Marketplace trial covered up to $400 in usage. Our Mission Before founding Wherobots, co-founders Mo and Jia identified critical challenges limiting the potential of geospatial data. These stemmed from how geospatial data was traditionally stored, formatted, and processed, and made this data incredibly painful to utilize, particularly at scale. Over the recent decades, data and analytics investment was mostly directed towards solutions for internet data. However compared to internet data, geospatial data is a lot more complex, which makes it harder to query. It’s polygons representing land and buildings, GPS trajectories, satellite and drone imagery, weather data, and more—all tied to Earth’s imperfect spherical surface. And querying this data generally means you need to filter and join it with other datasets (geo or non-geo). Due to this complexity, existing cloud analytics engines built for structured internet data struggle to efficiently run spatial queries at scale. They also miss features necessary to prepare this data, they lack features that make solution development productive, and simply cannot compute spatial results with high precision. As a result, solutions based on geospatial data are expensive, or otherwise shelved. We are addressing these challenges. By reducing the cost and effort to build with geospatial data, Wherobots will enable a new wave of innovation for the physical world. This will drive breakthroughs in products, business operations, science, government, and make a positive impact on our climate. Our mission is simple yet ambitious: make geospatial data easy to use. Here’s what some of our customers have to say about how we’re helping them achieve their missions. Customer Highlights AddressCloud Enabling insurers to calculate geographic risk with precision “Wherobots runs our compute operations that used to take hours or days to complete, in minutes. As we provide perils information (flood, fire, etc) to insurers at the property level, we particularly appreciate the ability to be able to run combined vector/raster analysis, without having to previously transform the raster data into vector format or some other format.” – John Powell, Senior Geospatial Data Engineer at AddressCloud Overture Maps Foundation Creating next-generation map products with scalable, open map data “Overture produces a building dataset covering all buildings in the world, with 2.3B geometries and growing, that’s updated frequently. There’s a lot of data and compute that goes into producing and keeping it up to date,” said Jennings Anderson, Geoscientist at Overture and Data Engineer at Meta. “We accelerated the pipelines that produce the buildings dataset by up to 20x after we moved them to Wherobots, which required a simple redirection of our code. We retained compatibility with Apache Sedona, and the move put us into a development experience that’s made us more productive.” – Jennings Anderson, Geoscientist at Overture and Data Engineer at Meta Why Wherobots Stands Out Several recurring themes highlight why customers choose Wherobots: Unmatched performance and cost efficiency: Wherobots delivers up to 20x better spatial join performance compared to modern cloud data engines, at a fraction of the cost. Ease of innovation: Wherobots makes it easy to build solutions with raster (e.g., satellite imagery), vector (e.g., geometry, geography) data, and your first party data regardless of scale. Modern cloud architecture: Wherobots is fully compatible with Apache Sedona, and runs seamlessly on data lakes with support for Apache Iceberg and Apache Parquet. 2024 Milestones Funding & Market Validation In 2024, we raised $21.5M in a Series A round led by Felicis, with support from Wing Venture Capital, Clear Ventures, JetBlue Ventures, and P7 Ventures. This funding reflects confidence in our mission and the massive market opportunity for geospatial solutions in the cloud. Team Growth The Wherobots team—the “Botsters”—tripled in size this year. While engineering saw the most growth, we also built out go-to-market, marketing, and product teams and are actively scaling our sales team. As we head into 2025, we’re actively hiring for roles across the company to support our expanding vision. Product Innovations We launched several key features in 2024 that expanded the boundaries of geospatial data solutions. *The features noted with an are only available in the professional or enterprise edition of Wherobots.**** Cloud Native A pay-as-you-go offering on the AWS Marketplace makes it easy to subscribe and pay on-demand using AWS Marketplace billing. A storage integration for Amazon S3, to quickly and securely integrate with first or third party data. Security and Access SAML Single Sign-On, makes logging in simple, secure, and seamless for users in companies with centralized login management systems. The Spatial SQL API, Typescript and Python SDKs, and a JDBC driver make it possible to query WherobotsDB using popular or custom query interfaces. Continuous improvement of internal security and service availability. Open Data Architecture The first version of the Spatial Catalog (known as Havasu, with core functionality soon to be merged into Apache Iceberg). Accelerating Geospatial Solution Development Raster Inference, to easily extract insights from satellite imagery at scale using SQL. (We’re hosting an upcoming panel discussion with an incredible lineup of speakers to discuss the MLM STAC Extension and Raster Inference, with a focus on optimizing Earth observation models for production. Learn more and save the date here.) Distributed Map Matching is a purpose built algorithm for snapping GPS trajectories to known segments like roads, with high performance at-scale. GeoStats: a geostatistics suite designed for scale, performance, and streamlining solution development. Support for K-nearest neighbor joins (exact and approximate) to efficiently query for geospatial neighbors at-scale. Vtiles, a vector tile solution purpose built for creating vector tiles at scale with high performance. Many new vector (ST) and raster (RS) functions to accelerate the developer productivity. Continuous improvement of spatial and non-spatial query performance to reduce cost and make workloads more compute efficient (reducing climate impact). Automation Job Runs integrated with Apache Airflow, to make it easy and familiar to automate new and existing processing workflows. Service Principals, enable authentication and automated usage of Wherobots, decoupled from the tenure or privileges of human users. Looking Ahead In 2025, we plan to bring Wherobots Cloud to the EU market with support for the AWS Europe (Ireland) region, and achieve the SOC 2 Type 2 certification (currently in progress). We’ll continue to focus on: Making Earth observation data easier to utilize. Enhancing developer productivity and experiences. Improving query engine performance and data compatibility. Strengthening service availability and support for customers. Delivering new administrative controls and observability. Ready to Build? We are currently offering a 30-day free trial covering up to $400 in usage via the AWS Marketplace. Getting started is easy. There are many example notebooks for various geospatial use cases that you can explore and run without any coding experience required. Not only do the notebooks help you get started, but we also see most of our customers use these notebooks as references for the solutions they end up building. Join the Mission Motivated by our mission? Join our growing team—visit our careers page for open roles. You can also share feedback at feedback@wherobots.com or contact me directly at damian@wherobots.com. Try Wherobots Pro Get Started Frequently Asked Questions How much did Wherobots raise in 2024? $21.5 million Series A led by Felicis, with Wing Venture Capital, Clear Ventures, JetBlue Ventures, and P7 Ventures. The team more than tripled the same year. What customer results are cited in the 2024 review? AddressCloud: peril computations that took hours or days now finish in minutes, including mixed vector/raster. Overture: a 2.3-billion-geometry buildings pipeline got up to 20x faster after moving to Wherobots with Sedona compatibility retained. What did Wherobots ship in 2024? Among the list: AWS Marketplace billing, S3 integration, SAML SSO, Spatial SQL API and SDKs, Havasu Catalog, and Raster Inference. Also distributed map matching, GeoStats, KNN joins, VTiles, Airflow job runs, and service principals. Some are only in Professional or Enterprise. What was on the 2025 roadmap in this post? EU availability in AWS Europe (Ireland), SOC 2 Type 2 certification (in progress at the time), plus continued work on Earth observation, developer productivity, query performance, availability, and administrative controls. A 30-day trial of up to $400 via AWS Marketplace was offered. --- ## Privacy Policy URL: https://wherobots.com/privacy-policy/ Updated: 2026-07-13 We care about your privacy Current as of Wherobots Inc. (“Wherobots,” “we,” “us,” or “our”) has prepared this Privacy Policy to explain (1) what personal information we collect, (2) how we use and share that information, and (3) your choices concerning our privacy and information practices. Applicability of this Privacy Policy We provide a spatial data analytics and AI platform (the “Services”). This Privacy Policy applies to personal information that we collect in connection with the Services, our mobile applications, our website(s), including https://wherobots.com/ and products and/or services that link to this Privacy Policy. If you are a customer of Wherobots, this Privacy Policy does not apply to personal information that we process on your behalf (if any) as your service provider. Such personal information shall instead be governed by the terms and conditions of the separate customer agreement or terms of service that you have agreed to with Wherobots. In addition, our Services are designed for businesses and are not intended for personal, family, or household use. Accordingly, we treat all personal information covered by this Privacy Policy as pertaining to individuals acting as business representatives, rather than in their personal capacity. Personal information we collect Information you provide to us: Business Contact Information: If you are a representative of one of our actual or prospective customers, suppliers or business partners, we may collect personal information about you (such as your name, contact details and role) when entering into an agreement with your company and during the course of our relationship with your company. Account information, such as your name, email address, and other similar information when you register an account with us. Transaction Information, such as your credit card or other payment information and authentication details when you purchase a license for the Services. We do not directly collect or process your payment card information. Depending on how you purchase our Services, your transactions are processed through a third-party payment processor (such as Stripe) or through a cloud marketplace (such as AWS Marketplace). These third parties provide your payment information directly to us only in limited circumstances (such as your name and the last four digits of your card for verification) or, in the case of marketplaces, handle the entire billing process on our behalf. Your information is governed by the respective privacy policies of these third parties. Feedback or correspondence, such as information you provide when you contact us with questions, feedback, reviews, or otherwise correspond with us online. Usage information, such as information about how you use the Services and interact with us. Marketing information, such as your preferences for receiving communications about our activities, services, and publications, and details about how you engage with our communications. Other information that we may collect which is not specifically listed here, but which we will use in accordance with this Privacy Policy or as otherwise disclosed at the time of collection. Information we obtain from third parties: We may maintain pages on social media platforms, such as Facebook, Twitter, Instagram, and other third-party platforms. When you visit or interact with our pages on those platforms, the platform provider’s privacy policy will apply to your interactions and their collection, use and processing of your personal information. You or the platforms may provide us with information through the platform, and we will treat such information in accordance with this Privacy Policy. We may obtain your personal information from other third parties, such as marketing partners, publicly-available sources and data providers. Automatic data collection. We and our service providers may automatically log information about you, your computer or mobile device, and your interaction over time with our Services, our communications and other online services, such as: Device data, such as your computer’s or mobile device’s operating system type and version, manufacturer and model, browser type, screen resolution, RAM and disk size, CPU usage, device type (e.g., phone, tablet), IP address, unique identifiers (including identifiers used for advertising purposes), language settings, mobile device carrier, radio/network information (e.g., WiFi, LTE, 4G), and general location information such as city, state or geographic area. Online activity data, such as pages or screens you viewed, how long you spent on a page or screen, browsing history, navigation paths between pages or screens, information about your activity on a page or screen, access times, and duration of access, and whether you have opened our marketing emails or clicked links within them. Email Open/Click Information. We may use pixels in our email campaigns that allow us to collect your email and IP address as well as the date and time you open an email or click on any links in the email that we may send to you. We use the following tools for automatic data collection: Cookies, which are text files that websites store on a visitor’s device to uniquely identify the visitor’s browser or to store information or settings in the browser for the purpose of helping you navigate between pages efficiently, remembering your preferences, enabling functionality, helping us understand user activity and patterns, and facilitating online advertising. Local storage technologies, like HTML5, that provide cookie-equivalent functionality but can store larger amounts of data, including on your device outside of your browser in connection with specific applications. Web beacons, also known as pixel tags or clear GIFs, which are used to demonstrate that a webpage or email was accessed or opened, or that certain content was viewed or clicked. How we use your personal information To operate our Services: Provide, operate, maintain, secure and improve our Services. Provide information about our Services. Communicate with you about our Services, including by sending you announcements, updates, security alerts, and support and administrative messages. Respond to your requests, questions and feedback. Marketing and advertising. We may from time-to-time send you direct marketing communications as permitted by law, including, but not limited to, notifying you of special promotions, offers and events via email. You may opt out of our marketing communications as described in the “Opt out of marketing communications” section below. For research and development. We may use your personal information for research and development purposes, including to analyze and improve our Services and our business. As part of these activities, we may create aggregated, de-identified, or other anonymous data from personal information we collect. We make personal information into anonymous data by removing information that makes the data personally identifiable to you. We may use this anonymous data and share it with third parties for our lawful business purposes, including to analyze and improve our Services and promote our business. Compliance and protection. We may use personal information to: Comply with applicable laws, lawful requests, and legal process, such as to respond to subpoenas or requests from government authorities. Protect our, your or others’ rights, privacy, safety or property (including by making and defending legal claims). Audit our internal processes for compliance with legal and contractual requirements and internal policies. Enforce the terms and conditions that govern our Services. Prevent, identify, investigate and deter fraudulent, harmful, unauthorized, unethical or illegal activity, including cyberattacks and identity theft. Job Applicants When you visit the careers portion of our website, we collect personal information that you provide to us in connection with your job application. This includes business and personal contact information, professional credentials and skills, educational and work history, and other information of the type that may be included in a resume. This may also include diversity information that you voluntarily provide. We use this information to facilitate our recruitment activities and process employment applications, such as by evaluating a job candidate for an employment activity, and monitoring recruitment statistics. We may also use and share this information to provide improved administration of the website, and as otherwise necessary: (a) to comply with relevant laws or to respond to subpoenas or warrants served on us; (b) to protect and defend the rights or property of us or others; or © in connection with a legal investigation. How we share your personal information Service providers. We may share your personal information with third party companies and individuals that provide services on our behalf or help us operate our Services (such as lawyers, bankers, auditors, insurers, and providers that assist with hosting, analytics, email delivery, marketing, and database management). Authorities and others. We may disclose your personal information to law enforcement, government authorities, and private parties, as we believe in good faith to be necessary or appropriate for the compliance and protection purposes described above. Business transfers. We may sell, transfer or otherwise share some or all of our business or assets, including your personal information, in connection with a business transaction (or potential business transaction) such as a corporate divestiture, merger, consolidation, acquisition, reorganization or sale of assets, or in the event of bankruptcy or dissolution. In such a case, we will make reasonable efforts to require the recipient to honor this Privacy Policy. Affiliates: We may share personal information with our current and future affiliates, meaning an entity that controls, is controlled by, or is under common control with us. Our affiliates may use the personal information we share in a manner consistent with this Privacy Policy. Cross-border processing of your personal information We are headquartered in the United States. To provide and operate our services, it is necessary for us to process your personal information in the United States. If we transfer personal information across borders such that we are required to apply appropriate safeguards to personal information under applicable data protection laws, we will do so. Please contact us for further information about any such transfers or the specific safeguards applied. Your choices Opt out of marketing communications. You may opt out of email communications by following the opt-out or unsubscribe instructions at the bottom of the email. Online tracking opt-out. There are a number of ways to opt out of having your online activity and device data collected through our Services, which we have summarized below: Blocking cookies in your browser. Most browsers let you remove or reject cookies. To do this, follow the instructions in your browser settings. Many browsers accept cookies by default until you change your settings. For more information about cookies, including how to see what cookies have been set on your device and how to manage and delete them, visit www.allaboutcookies.org. Using privacy plug-ins or browsers. You can block our Services from setting cookies used for interest-based ads by using a browser with privacy features or installing browser plugins like Privacy Badger, DuckDuckGo, Ghostery or uBlock Origin, and configuring them to block third party cookies/trackers. Google Analytics. We use Google Analytics to help us better understand how people engage with the Services by collecting information and creating reports about how users use our Services. For more information on Google Analytics, click here. For more information about Google’s privacy practices, click here. You can opt out of Google Analytics by downloading and installing the browser plug-in available at: https://tools.google.com/dlpage/gaoptout. Note that because these opt-out mechanisms are specific to the device or browser on which they are exercised, you will need to opt out on every browser and device that you use. Do Not Track. Some Internet browsers may be configured to send “Do Not Track” signals to the online services that you visit. We currently do not respond to “Do Not Track” or similar signals. To find out more about “Do Not Track,” please visit http://www.allaboutdnt.com. Data Retention We may retain your personal information for as long as it is reasonably needed in order to maintain and expand our relationship and provide you with our services; in order to comply with our legal and contractual obligations; or to protect ourselves from any potential disputes. To determine the appropriate retention period for personal information, we consider the amount, nature, and sensitivity of such information, the potential risk of harm from unauthorized use or disclosure of such information, the purposes for which we process it, and the applicable legal requirements. Other sites, mobile applications and services Our Services may contain links to other websites, mobile applications, and other online services operated by third parties. These links are not an endorsement of, or representation that we are affiliated with, any third party. In addition, our content may be included on web pages or in mobile applications or online services that are not associated with us. We do not control third party websites, mobile applications or online services, and we are not responsible for their actions. Other websites and services follow different rules regarding the collection, use and sharing of your personal information. We encourage you to read the privacy policies of the other websites and mobile applications and online services you use. We use Stripe for payments, analytics, and other business services. Stripe may collect personal data including via cookies and similar technologies. The personal data Stripe collects may include transactional data and identifying information about devices that connect to its services. Stripe uses this information to operate and improve the services it provides to us, including for fraud prevention and detection, authentication, analytics related to the performance of its services, and to enhance and customize the user experience. You can learn more about Stripe and read its privacy policy at https://stripe.com/privacy. Security practices We use reasonable organizational, technical and administrative measures designed to protect against unauthorized access, misuse, loss, disclosure, alteration and destruction of personal information we maintain. Unfortunately, data transmission over the Internet cannot be guaranteed as completely secure. Therefore, while we strive to protect your personal information, we cannot guarantee the security of personal information. In the event that we are required to notify you about a situation involving your data, we may do so by email or telephone to the extent permitted by law. Children Our Services are not intended for children, and we do not collect personal information from them. We define “children” as anyone under 18 years old. If we learn we have collected or received personal information from a child without verification of parental consent, we will delete the information. If you believe we might have any information from or about a child, please contact us via the contact information noted below. Changes to this Privacy Policy We reserve the right to modify this Privacy Policy at any time. If we make material changes to this Privacy Policy, we will notify you by updating the date of this Privacy Policy and posting it on our Services. We may also provide notification of changes in another way that we believe is reasonably likely to reach you, such as via email (if you have an account where we have your contact information) or another manner through our Services. Any modifications to this Privacy Policy will be effective upon our posting the new terms and/or upon implementation of the new changes on our Services (or as otherwise indicated at the time of posting). In all cases, your continued use of the Services after the posting of any modified Privacy Policy indicates your acceptance of the terms of the modified Privacy Policy. How to contact us If you have any questions or concerns, you can reach us by email at support@wherobots.com. --- ## Terms & Conditions URL: https://wherobots.com/terms-conditions/ Updated: 2026-07-13 Terms & Conditions Current as of These Terms of Service (this “Agreement“) are entered into by and between Wherobots Inc., a Delaware corporation (“Wherobots“), and the entity or person accessing or using the Wherobots Services (“Customer” or “you“). This Agreement consists of the terms and conditions set forth below and any Order Forms that reference this Agreement. If you are accessing or using the Wherobots Services on behalf of your company, you represent that you are authorized to accept this Agreement on behalf of your company, and all references to “you” reference your company. Please note that Wherobots may modify the terms and conditions of this Agreement in accordance with the Section titled “Amendment; Waivers” below. BY INDICATING YOUR ACCEPTANCE OF THIS AGREEMENT OR ACCESSING OR USING THE WHEROBOTS SERVICE, YOU ARE AGREEING TO BE BOUND BY ALL TERMS, CONDITIONS AND NOTICES CONTAINED OR REFERENCED IN THIS AGREEMENT. IF YOU DO NOT AGREE TO THIS AGREEMENT, PLEASE DO NOT USE THE WHEROBOTS SERVICE. FOR CLARITY, EACH PARTY EXPRESSLY AGREES THAT THIS AGREEMENT IS LEGALLY BINDING UPON IT. Definition The following terms, when used in this Agreement will have the following meanings: “Affiliates“ means an entity that directly or indirectly Controls, is Controlled by, or is under common Control with another entity, so long as such Control exists. For the purposes of this definition, Control means beneficial ownership of 50% or more of the voting power or equity in an entity. “Channel Partner“ means a third party reseller, marketplace (such as AWS Marketplace) or other channel partner of Wherobots that is responsible for collecting payments on behalf of Wherobots with respect to Customer’s subscription for the Wherobots Service. “Confidential Information“ means any information or data disclosed by either party that is marked or otherwise designated as confidential or proprietary or that should otherwise be reasonably understood to be confidential in light of the nature of the information and the circumstances surrounding disclosure. However, Confidential Information will not include any information which (a) is in the public domain through no fault of receiving party; (b) was properly known to receiving party, without restriction, prior to disclosure by the disclosing party; (c) was properly disclosed to receiving party, without restriction, by another person with the legal authority to do so; or (d) is independently developed by the receiving party without use of or reference to the disclosing party’s Confidential Information. “Documentation“ means the printed and digital instructions, on-line help files, technical documentation and user manuals made available by Wherobots for the Wherobots Service. “Order Form“ means any order form, online sign-up, or subscription sign-up flow provided by Wherobots or a Channel Partner that references this Agreement. “POC Period“ means a paid evaluation period as set forth in an Order Form during which Customer evaluates the Wherobots Service for potential production use. “Preferred Services Affiliate“ means a Wherobots partner who has completed its partner certification and is authorized to complete services on behalf of Wherobots due to their expertise in the respective domain. “Professional Services“ means professional services provided by Wherobots, or a Wherobots preferred services affiliate, to Customer as described in any Order Form, including services relating to the Wherobots Service and support, implementation, training, and on-boarding thereof. “System Data“ means data collected by Wherobots regarding the Wherobots Service that may be used to generate logs, statistics or reports regarding the performance, availability, usage, integrity or security of the Wherobots Service. “Third-Party Product“ means any applications, integrations, software, code, online services, systems, or other products not developed by Wherobots. “Wherobots Code“ means any software code provided by Wherobots to Customer for use in connection with the Wherobots Service. “Wherobots Dataset“ means any dataset provided by Wherobots to Customer, including through the Wherobots Service. “Wherobots Service“ means Wherobots’s data platform for geospatial analytics and AI, which may be provided both as a cloud offering or on-premise. Wherobots Cloud Account Registration Customer may need to register for a Wherobots account in order to use the Wherobots Service. Account information must be accurate, current, and complete. Customer agrees to keep this information up-to-date so that Wherobots may send notices, statements, and other information by email or through Customer’s account. Customer must ensure that any user IDs, passwords, and other access credentials for the Wherobots Service are kept strictly confidential and not shared with any unauthorized person. License to Wherobots Service Subject to the terms and conditions of this Agreement, Wherobots hereby grants Customer a non-exclusive, non-transferrable, non-sublicensable right to access and use the Wherobots Service set forth in the corresponding Order Form for its internal business purposes. To the extent Wherobots has provided Customer with any Wherobots Code, rights granted in this Section further include the right to install and run the relevant Wherobots Code in connection with Customer’s use of the Wherobots Service. License to Wherobots Datasets Subject to the terms and conditions of this Agreement, Wherobots hereby grants Customer a non-exclusive, worldwide, perpetual right to use, copy, reproduce, publish, and create derivative works from any Wherobots Datasets provided to Customer. During and after the term of this Agreement, in the event Customer (a) distributes or shares any Wherobots Datasets or derivative works thereof with a third party, or (b) uses a Wherobots Dataset in any public or commercial product or application, Customer agrees to (a) maintain any existing copyright and attribution notices included with the corresponding Wherobots Dataset; and (b) provide clear attribution to Wherobots regarding Customer’s use of such Wherobots Dataset. To the extent any Wherobots Datasets contains data or information from a third party open source dataset with “share-alike” or similar obligations (such as the Open Data Commons Open Database License), those portions of the Wherobots Dataset are instead licensed to Customer directly from the third party licensor pursuant to the terms of the applicable third party open source license. Trial Access Wherobots may provide Customer with the Wherobots Service for free or on a limited, paid evaluation basis, including as part of a POC Period (collectively, “Trial Access“). Wherobots makes no promises that any Trial Access will be made available under the same commercial or other terms. Wherobots may terminate Customer’s right to use the Wherobots Services at any time in Wherobots’s sole discretion without liability. Any Trial Access is provided by Wherobots “AS-IS” without any representations, warranties or support obligations. If Customer has agreed to a paid POC Period, Customer agrees to pay any applicable fees specified for such POC Period. Upon completion of the POC Period, and unless otherwise agreed in writing, Customer’s subscription to the Wherobots Service will automatically convert to an annual subscription based on the volume of data processed during the POC Period in a production environment, as further described in the applicable Order Form. Customer Limitations Customer will not directly or indirectly: (a) reverse engineer, decompile, disassemble, modify, create derivative works of or otherwise create, attempt to create or derive, or permit or assist any third party to create or derive, the source code underlying the Wherobots Service; (b) attempt to probe, scan or test the vulnerability of the Wherobots Service, breach the security or authentication measures of the Wherobots Service without proper authorization or willfully render any part of the Wherobots Service unusable; (c) use or access the Wherobots Service to develop a product or service that is competitive with Wherobots’s products or services or engage in competitive analysis or benchmarking; (d) transfer, distribute, resell, lease, license, or assign the Wherobots Service or otherwise offer the Wherobots Service on a standalone basis; or (e) otherwise use the Wherobots Service in violation of applicable law (including any export law) or outside the scope expressly permitted hereunder and in the applicable Order Form (collectively, the “License Restrictions“). Customer Responsibilities Customer will (i) be responsible for all use of the Wherobots Service under its account, (ii) use commercially reasonable efforts to prevent unauthorized access to or use of the Wherobots Service and notify Wherobots promptly of any such unauthorized access or use or any other known or suspected breach of security or misuse of the Wherobots Service and (iii) be responsible for obtaining and maintaining any equipment, software and ancillary services needed to connect to, access or otherwise use the Wherobots Service, including as set forth in the Documentation. Customer will be solely responsible for its failure to maintain such equipment, software and services, and Wherobots will have no liability for such failure (including under any service level agreement). Third-Party Products If Customer uses Third-Party Products in connection with the Wherobots Service (such as through integrations made available by Wherobots), Customer agrees and acknowledges that Wherobots does not warrant or support Third-Party Products and disclaims all responsibility and liability for these items and their use in connection with the Wherobots Service, including whether any integrations or support will continue to be made available by Wherobots or such third party. Affiliates Any Affiliate of Customer will have the right to enter into an Order Form executed by such Affiliate and Wherobots and this Agreement will apply to each such Order Form as if such Affiliate were a signatory to this Agreement. With respect to such Order Forms, such Affiliate becomes a party to this Agreement and references to Customer in this Agreement are deemed to be references to such Affiliate. Each Order Form is a separate obligation of the Customer entity that executes such Order Form, and no other Customer entity has any liability or obligation under such Order Form. Professional Services If an Order Form provides that Wherobots will conduct Professional Services, Wherobots will assign to Customer personnel or a Preferred Services Affiliate with the skills and experience required to successfully complete such Professional Services, and Customer will assign a primary point of contact to coordinate communication and make decisions on behalf of Customer during performance of the Professional Services. Wherobots’s or the Preferred Services Affiliate’s ability to complete the Professional Services, and to do so within the total number of days or weeks specified in the applicable Order Form, substantially depends upon Customer’s timely and effective cooperation and collaboration. Wherobots or any Preferred Services Affiliate will not be responsible for any delay in the Professional Services caused by the actions or inactions of Customer. Fees Pricing Plans To the extent the Wherobots Service is made available for a fee, Customer may choose to purchase either (a) a minimum commitment plan or (b) a pay-as-you-go plan. For the minimum commitment plan, Customer will be billed a recurring upfront amount for a certain minimum commitment, in each case, as set forth in the corresponding Order Form. If Customer’s usage of the Wherobots Service exceeds the amounts prepaid by Customer pursuant to its minimum commitment plan, Wherobots will invoice Customer for such excess usage at the rates set forth in the applicable Order Form or, if not specified, at Wherobots’s then-current standard rates. For the pay-as-you-go plan, Customer will be billed based on Customer’s usage at the rates set forth in the corresponding Order Form. If Customer has purchased any Professional Services, Customer will pay for such Professional Services in accordance with the terms of the applicable Order Form. Except as otherwise specified herein or in any applicable Order Form, (a) fees are quoted and payable in United States dollars, and (b) payment obligations are non-cancelable and non-pro-ratable for partial months, and fees paid are non-refundable. Credit Card Payment Terms If Customer elects to pay via credit card, then Customer is responsible for either (a) enabling auto-recharge on Customer’s payment instrument or (b) ensuring that Customer’s payment instrument has a sufficient positive balance to cover all fees due. If, for any reason, Customer has a negative balance on its payment account, then Wherobots reserves the right to suspend access to the paid version until all fees are paid in full. Invoicing Payment Terms If Customer elects to receive invoices and Wherobots approves Customer for the same, then invoices will be sent via email in accordance with the Order Form. Except as otherwise set forth in an Order Form, Customer will make all undisputed fee payments hereunder within thirty (30) days of the date of the invoice. Suspension; Late Payment Wherobots may suspend access to the Wherobots Service immediately upon notice if Customer fails to pay any amounts hereunder at thirty (30) days past the applicable due date. If Wherobots has not received payment within thirty (30) days after the applicable due date, interest will accrue on past due amounts at the rate of one percent (1%) per month, but in no event greater than the highest rate of interest allowed by law, calculated from the date such amount was due until the date that payment is received by Wherobots. Taxes All amounts payable hereunder are exclusive of any sales, use and other taxes or duties, however designated (collectively “Taxes“). Customer will be solely responsible for payment of all Taxes, except for those taxes based on the income of Wherobots. Customer will not withhold any taxes from any amounts due to Wherobots. Payments through Channel Partner If Customer is purchasing a subscription for the Wherobots Service through a Channel Partner, Customer agrees to pay all fees due for Customer’s use of the Wherobots Service in accordance with the payment terms agreed to with such Channel Partner. If Customer breaches its payment obligations to the Channel Partner and fails to cure such breach within the time period specified with such Channel Partner, Wherobots may suspend the provision of the Wherobots Service upon written notice to Customer. Proprietary Rights and Confidentiality Customer Data Customer shall retain all right, title and interest to all data and information provided to Wherobots in connection with its use of the Wherobots Service (“Customer Data“). Wherobots will maintain a security program materially in accordance with industry standards that is designed to (i) ensure the security and integrity of Customer Data; (ii) protect against threats or hazards to the security or integrity of Customer Data; and (iii) prevent unauthorized access to Customer Data. Customer warrants that it has all rights necessary to provide any information, data or other materials that it provides hereunder, and to permit Wherobots to use the same as contemplated hereunder. Proprietary Rights As between the parties, Wherobots exclusively owns all right, title and interest in and to the Wherobots Service, Wherobots Code, “System Data” and Wherobots’s Confidential Information. As between the parties, Customer exclusively owns all right, title and interest in and to its Customer Data and Customer’s Confidential Information. Feedback Customer may from time to time provide Wherobots suggestions or comments for enhancements or improvements, new features or functionality or other feedback (collectively “Feedback“) with respect to the Wherobots Service. Wherobots will have full discretion to determine whether or not to proceed with the development of any requested enhancements, new features or functionality. Wherobots will have the full, unencumbered right, without any obligation to compensate or reimburse Customer, to use, incorporate and otherwise fully exercise and exploit any such Feedback in connection with its products and services. Confidentiality Each party agrees that it will use the Confidential Information of the other party solely in accordance with the provisions of this Agreement and it will not disclose the same directly or indirectly, to any third party without the other party’s prior written consent, except as otherwise permitted hereunder. However, either party may disclose Confidential Information (a) to its employees, officers, directors, attorneys, auditors, financial advisors and other representatives who have a need to know and are legally bound to keep such information confidential by confidentiality obligations consistent with those of this Agreement; and (b) as required by law (in which case the receiving party will provide the disclosing party with prior written notification thereof, will provide the disclosing party with the opportunity to contest such disclosure, and will use its reasonable efforts to minimize such disclosure to the extent permitted by applicable law). Neither party will disclose the terms of this Agreement to any third party, except that either party may confidentially disclose such terms to actual or potential lenders, investors or acquirers. Each party agrees to exercise due care in protecting the Confidential Information from unauthorized use and disclosure. In the event of actual or threatened breach of the provisions of this Section or the License Restrictions, the non-breaching party will be entitled to seek immediate injunctive and other equitable relief, without waiving any other rights or remedies available to it. Each party will promptly notify the other in writing if it becomes aware of any violations of the confidentiality obligations set forth in this Agreement. Warranties and Disclaimers Performance Warranty If Customer is using the Wherobots Service through a paid subscription, Wherobots warrants that the Wherobots Service will conform in all material respects with the Documentation. In the event of a breach of the foregoing warranty, Wherobots will use commercially reasonable efforts to correct the deficiency at no additional charge to Customer. The remedies set forth in this section will be Customer’s sole remedy and Wherobots’s sole liability for breach of such warranty. DISCLAIMERS EXCEPT AS EXPRESSLY SET FORTH HEREIN, WHEROBOTS DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE. WHEROBOTS DOES NOT REPRESENT OR WARRANT THAT THE WHEROBOTS SERVICE WILL BE ERROR-FREE, AND WHEROBOTS EXPRESSLY DISCLAIMS ANY WARRANTY AS TO THE ACCURACY OR COMPLETENESS OF ANY INFORMATION OR DATA ACCESSED OR USED IN CONNECTION WITH THE WHEROBOTS SERVICE. WHEROBOTS IS NOT RESPONSIBLE OR LIABLE FOR ANY PRODUCTS OR SERVICES NOT PROVIDED BY WHEROBOTS (INCLUDING ANY THIRD-PARTY PRODUCTS), AND DOES NOT GUARANTEE THE CONTINUED AVAILABILITY THEREOF OR ANY INTEGRATION THEREWITH, AND MAY CEASE MAKING ANY SUCH INTEGRATION AVAILABLE IN ITS SOLE DISCRETION. Limitation of Liability UNDER NO LEGAL THEORY, WHETHER IN TORT, CONTRACT, OR OTHERWISE, WILL (A) EITHER PARTY BE LIABLE TO THE OTHER UNDER THIS AGREEMENT FOR ANY INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL OR PUNITIVE DAMAGES OF ANY CHARACTER, INCLUDING DAMAGES FOR LOSS OF GOODWILL, LOST PROFITS, LOST SALES OR BUSINESS, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, LOST CONTENT OR DATA, EVEN IF A REPRESENTATIVE OF SUCH PARTY HAS BEEN ADVISED, KNEW OR SHOULD HAVE KNOWN OF THE POSSIBILITY OF SUCH DAMAGES, OR (B) WHEROBOTS BE LIABLE FOR ANY AGGREGATE DAMAGES, COSTS, OR LIABILITIES IN EXCESS OF THE AMOUNTS PAID BY CUSTOMER UNDER THE APPLICABLE ORDER FORM DURING THE TWELVE (12) MONTHS PRECEDING THE INCIDENT OR CLAIM, OR ONE HUNDRED DOLLARS ($100.00) IF CUSTOMER HAS TRIAL ACCESS. Indemnification To the fullest extent permitted by law, Customer agrees to indemnify, release, and hold harmless Wherobots and its directors, officers, employees, and contractors for any third party claims, demands, suits, proceedings, liabilities, losses, damages, judgements, fines, or costs and expenses (including, without limitation, reasonable attorneys’ fees) arising out of or relating to: (a) Customer’s breach of this Agreement or (b) Customer’s unauthorized use or misuse of the Wherobots Service. Term and Termination Paid Users If Customer is a paid user, then each party may terminate this Agreement upon sixty (60) days prior written notice to the other party. In addition, each party may terminate this Agreement if the other party fails to cure any material breach of this Agreement (including a failure to pay undisputed fees) within thirty (30) days after written notice detailing the breach. In the event of any termination or expiration of this Agreement for any reason, Wherobots shall have no obligation to refund any prepaid commitments. Trial Access If Customer is accessing the Wherobots Service through Trial Access, each party may terminate this Agreement upon written notice to the other party. Survival Upon termination of this Agreement all rights and obligations will immediately terminate except that any terms or conditions that by their nature should survive such termination will survive, including the License Restrictions and terms and conditions relating to proprietary rights and confidentiality, disclaimers, indemnification, limitations of liability and termination and the general provisions below. General Export Compliance Each party will comply with the export laws and regulations of the United States, European Union and other applicable jurisdictions in providing and using the Wherobots Service. Publicity Customer agrees that Wherobots may refer to Customer’s name and trademarks in Wherobots’s marketing materials and website; however, Wherobots will not use Customer’s name or trademarks in any other publicity (e.g., press releases, customer references and case studies) without Customer’s prior written consent (which may be by email) not to be unreasonably delayed. If Customer does not agree to Wherobots’s use of Customer’s name or trademark in Wherobots’s marketing materials, Customer may opt out of such use by providing written notice to Wherobots within fourteen (14) days of the date of the initial Order Form. Assignment; Delegation Neither party hereto may assign or otherwise transfer this Agreement, in whole or in part, without the other party’s prior written consent, except that either party may assign this Agreement without consent to a successor to all or substantially all of its assets or business related to this Agreement. Any attempted assignment, delegation, or transfer by either party in violation hereof will be null and void. Subject to the foregoing, this Agreement will be binding on the parties and their successors and assigns. Amendment; Waiver Wherobots reserves the right in its sole discretion and at any time and for any reason to modify this Agreement. With respect to each Order Form, any modifications to this Agreement shall become effective upon the date of Customer’s next renewal of such Order Form. It is Customer’s responsibility to review this Agreement from time to time for any changes or modifications. If Customer does not agree to the modified Agreement, Customer may provide notice of Customer’s non-renewal at any point prior to Customer’s next renewal. No waiver by either party of any breach or default hereunder shall be deemed to be a waiver of any preceding or subsequent breach or default. Any such waiver will be only to the specific provision and under the specific circumstances for which it was given, and will not apply with respect to any repeated or continued violation of the same provision or any other provision. Failure or delay by either party to enforce any provision of this Agreement will not be deemed a waiver of future enforcement of that or any other provision. Relationship Nothing contained herein will in any way constitute any association, partnership, agency, employment or joint venture between the parties hereto, or be construed to evidence the intention of the parties to establish any such relationship. Neither party will have the authority to obligate or bind the other in any manner, and nothing herein contained will give rise or is intended to give rise to any rights of any kind to any third parties. Unenforceability If a court of competent jurisdiction determines that any provision of this Agreement is invalid, illegal, or otherwise unenforceable, such provision will be enforced as nearly as possible in accordance with the stated intention of the parties, while the remainder of this Agreement will remain in full force and effect and bind the parties according to its terms. Governing Law This Agreement will be governed by the laws of the State of Delaware, exclusive of its rules governing choice of law and conflict of laws. This Agreement will not be governed by the United Nations Convention on Contracts for the International Sale of Goods. Notices Any notice required or permitted to be given hereunder will be given in writing by personal delivery, certified mail, return receipt requested, or by overnight delivery. Notices to the Customer may be sent to the address listed on the Customer’s applicable Order Form or email address provided by Customer when Customer creates its Wherobots Service account. Notices to Wherobots must be sent to the following: Wherobots Inc350 California St., Suite 400San Francisco, CA 94104Attn: Legal Entire Agreement This Agreement comprises the entire agreement between Customer and Wherobots with respect to its subject matter, and supersedes all prior and contemporaneous proposals, statements, sales materials or presentations and agreements (oral and written). No oral or written information or advice given by Wherobots, its agents or employees will create a warranty or in any way increase the scope of the warranties in this Agreement. Force Majeure Neither party will be deemed in breach hereunder for any cessation, interruption or delay in the performance of its obligations due to causes beyond its reasonable control, including earthquake, flood, or other natural disaster, act of God, labor controversy, civil disturbance, terrorism, war (whether or not officially declared), cyber attacks (e.g., denial of service attacks), or the inability to obtain sufficient supplies, transportation, or other essential commodity or service required in the conduct of its business, or any change in or the adoption of any law, regulation, judgment or decree. Government Terms Wherobots provides the Wherobots Service, including related software and technology, for ultimate federal government end use solely in accordance with the terms of this Agreement. If Customer is an agency, department, or other entity of any government, the use, duplication, reproduction, release, modification, disclosure, or transfer of the Wherobots Service, or any related documentation of any kind, including technical data, software, and manuals, is restricted by the terms of this Agreement. All other use is prohibited and no rights other than those provided in this Agreement are conferred. The Wherobots Service was developed fully at private expense. --- ## Wherobots Raster Inference is GA with Support for Bring Your Own Model URL: https://wherobots.com/blog/wherobotsai-raster-inference-is-ga/ Updated: 2026-10-19 Editor’s note: Raster inference is now part of RasterFlow, the Wherobots engine for running computer vision models on satellite and aerial imagery. Key takeawaysWherobots Raster Inference is generally available as a serverless, planetary-scale computer vision service that extracts features from satellite and drone raster imagery for data scientists and developers.Bring-your-own-model is now supported through the STAC Machine Learning Model (MLM) Extension Specification, co-developed with CRIM and other collaborators, adopted at Terradue, and supported by Radiant Earth.Wherobots-hosted models are precompiled for scale; the post walks through landcover-eurosat-sentinel2 classification and solar-satlas-sentinel2 semantic segmentation, including converting predictions to geometries at a 0.65 confidence threshold.The GA release also accelerated asynchronous data loading in the inference engine. Experiments are shown for a Tiny GPU Runtime (chart on the page; no numeric speedups are stated in the text).Raster Inference is included for Professional and Enterprise users with GPU runtimes, not Community Edition. Community users can start a Professional trial via AWS Marketplace or an account upgrade. Introduction UPDATE: Raster inference is included in Wherobots RasterFlow. See Wherobots Get Started with RasterFlow – Wherobots for the most up-to-date workflows. We are excited to announce that Wherobots Raster Inference is now generally available! Raster Inference is a serverless, planetary-scale computer vision solution that enables data teams to extract meaningful insights from aerial imagery (raster data) sources, such as satellites or drones, and puts these insights at the fingertips of data scientists and developers. During the preview period, customers analyzed raster data by running inference with a limited set of Wherobots-hosted open-source computer vision models. Now, you can bring your own model into Raster Inference, offload inference pipeline management effort, and apply this capability to a much broader set of use cases. We have also made significant enhancements to our compute service to accelerate inference performance. Typical Use Cases Data teams use Wherobots Raster Inference to identify information in complex, large-scale overhead imagery data. Some common use cases include: Agriculture: Satellite and drone imagery are critical for monitoring land use, predicting crop yields, and improving sustainable farming practices. Environment and Conservation: Raster imagery is essential for monitoring ecosystem and biodiversity changes, such as tracking glacier melting, sea level rise, temperature fluctuations, and environmental degradation (e.g., oil spills, deforestation). Energy: Renewable energy developers analyze satellite data to assess land suitability, solar radiation, and wind patterns, to determine optimal locations for renewable energy projects. Insurance: Insurers use raster data to calculate risk assessments based on environmental and local factors to conduct and improve damage assessments at scale. Map Creation & Maintinence: Global digital, high fidelity map producers and maintainers extract features such as buildings, road networks, landcover, shipping lanes, etc., and their respective changes in order to maintain truthful connection between global map data products and the real world. Traditional challenges with computer vision pipelines We’ve met with many businesses struggling to get critical insights from raster data. Some are manually sifting through imagery. This method doesn’t scale, it’s expensive, error prone, and time intensive. Others are utilizing complex computer vision solutions that are not designed for overhead raster imagery. These computer visions solutions: Take time to build, and require significant management to efficiently load, store, and process large raster datasets. Are difficult to scale to accommodate increasing workload sizes. Are fragile with multiple components involved and challenges maintaining compatibility with an evolving modeling stack. Require effort to experiment, test, and integrate new models and inference runs. Benefits of Wherobots Raster Inference With Wherobots Raster Inference, you can: Use data pipelines that are ready for small to planetary-scale raster data. Deploy an on-demand solution in seconds that scales to meet workload needs without having to manage infrastructure. Easily import your model or utilize any model hosted by Wherobots. Experiment and generate critical insights faster. In the following sections, we’ll provide a brief overview of Wherobots-hosted models, how to bring your own model, recent performance improvements, and how to use this feature effectively. Choosing a Model for Raster Inference Wherobots-Hosted Models Wherobots-hosted models are precompiled and optimized for raster inference, enabling them to scale effortlessly and execute inference on large datasets. Below is a brief overview of the initial set of Wherobots-hosted models. We plan to host additional models based on customer feedback. For more information on these models and their performance metrics, see our docs page here. Below is a code snippet on how to use landcover-eurosat-sentinel2 in Wherobots Raster Inference: # set the model name model_id = "landcover-eurosat-sentinel2" # call the model in raster inference df_predictions = df_raster_input.withColumn("preds", rs_classify(model_id, "outdb_raster")) The STAC Machine Learning Model Extension Specification The model import function of Raster Inference is built on the STAC Machine Learning Model (MLM) Extension Specification, an open community standard for model sharing we co-developed with CRIM and other collaborators. The MLM specification enables model portability, making it easier to use models across teams and compute platforms. Before the MLM specification, data scientists and modelers sharing geospatial computer vision models often had to adapt existing standards, such as HuggingFace model cards, to store relevant information. This involved repurposing the cards to specify details like required raster bands, necessary data preprocessing, and post-processing functions. Without a community standard for organizing this information, these model cards were often inconsistent and documented in varying formats, making model sharing and reproducibility across different compute platforms cumbersome. The STAC MLM extension introduces a community standard designed to simplify storing and sharing geospatial computer vision models. It achieves this by providing a comprehensive schema to: Describe critical geospatial model attributes, such as geolocation and temporal range. Include key model inference reproducibility details, such as required bands, model artifact locations, and pre- and post- processing steps. Enable model collections to be searched alongside associated spatiotemporal datasets. The MLM specification has already been adopted in key modeling efforts at Terradue and is proudly supported by Radiant Earth. We’ll share more in a series of blog posts and a panel discussion with our collaborators on the MLM in late January — register here on the interest form to receive an invite when the date is finalized. Bring Your own Model The MLM specification enables users to quickly and easily use many geospatial, deep learning-based computer vision models with Raster Inference. We leverage a model’s MLM specification to specify and integrate the required data preprocessing, model, and post processing into the larger raster inference pipeline. To bring your own model to Raster Inference: Fill out our MLM form for your model. This will create a MLM formatted JSON file (MLM JSON) describing your model. Download the file. Upload the MLM JSON file from Step 1 to your AWS S3 bucket. Copy and save the AWS S3 URI to your MLM JSON. During runtime, use your model for inference by calling the raster inference function with your MLM’s S3 URI link. You can find a full walkthrough in our documentation on using the MLM form to bring your own model. Performance Improvements In addition to enabling bring your own model, we’ve accelerated asynchronous data loading in the inference engine to boost performance. Below, you can see how performance has evolved with experiments conducted using Wherobots Raster Inference and a Tiny GPU Runtime. Example: Raster Inference with Bring Your own Model For a full tutorial example on how to bring your own model to segment solar farms in Sentinel-2 imagery, see our documentation here. Example: Run Raster Inference with a Wherobots-hosted model We’ll walk through an example on how to identify solar infrastructure in raster imagery using a Wherobots-hosted model. In our example, we will be using the model: solar-satlas-sentinel2 The full Python notebook file can be found on our GitHub. Set up the WherobotsDB context import warnings warnings.filterwarnings('ignore') from wherobots.inference.data.io import read_raster_table from sedona.spark import SedonaContext from pyspark.sql.functions import expr from wherobots.inference.engine.register import create_semantic_segmentation_udfs from pyspark.sql.functions import col config = SedonaContext.builder().appName('segmentation-batch-inference') .getOrCreate() sedona = SedonaContext.create(config) Load Satellite Imagery tif_folder_path = "s3a://wherobots-benchmark-prod/data/ml/satlas" files_df = read_raster_table(tif_folder_path, sedona, limit=400) df_raster_input = files_df.withColumn( "outdb_raster", expr("RS_FromPath(path)") ) df_raster_input.cache().count() df_raster_input.show(truncate=False) df_raster_input.createOrReplaceTempView("df_raster_input") Run Wherobots Raster Inference Specify a Wherobots-hosted model to run inference model_id = "solar-satlas-sentinel2" You can run Wherobots Raster Inference using either the Wherobot’s SQL API or Python API. Using the SQL API predictions_df = sedona.sql(""" SELECT outdb_raster, segment_result.* FROM ( SELECT outdb_raster, RS_SEGMENT('{model_id}', outdb_raster) AS segment_result FROM df_raster_input ) AS segment_fields """) predictions_df.cache().count() predictions_df.show() predictions_df.createOrReplaceTempView("predictions") Using the Python API rs_segment = create_semantic_segmentation_udfs(batch_size = 10, sedona=sedona) df = df_raster_input.withColumn("segment_result", rs_segment(model_id, col("outdb_raster"))).select( "outdb_raster", col("segment_result.confidence_array").alias("confidence_array"), col("segment_result.class_map").alias("class_map") ) df.show(3) Extract predicted geometries (continued from step 4 using the SQL API) df_multipolys = sedona.sql(""" WITH t AS ( SELECT RS_SEGMENT_TO_GEOMS(outdb_raster, confidence_array, array(1), class_map, 0.65) result FROM predictions ) SELECT result.* FROM t """) df_multipolys.cache().count() df_multipolys.show() df_multipolys.createOrReplaceTempView("multipolygon_predictions") df_merged_predictions = sedona.sql(""" SELECT element_at(class_name, 1) AS class_name, cast(element_at(average_pixel_confidence_score, 1) AS double) AS average_pixel_confidence_score, ST_Collect(geometry) AS merged_geom FROM multipolygon_predictions """) df_filtered_predictions = df_merged_predictions.filter("ST_IsEmpty(merged_geom) = False") df_filtered_predictions.cache().count() df_filtered_predictions.show() Visualize results from sedona.maps.SedonaKepler import SedonaKepler config = { 'version': 'v1', 'config': { 'mapStyle': { 'styleType': 'dark', 'topLayerGroups': {}, 'visibleLayerGroups': {}, 'mapStyles': {} }, } } map = SedonaKepler.create_map(config=config) SedonaKepler.add_df(map, df=df_filtered_predictions, name="Solar Farm Detections") map Get started with Wherobots Raster Inference Professional Edition Users If you’re a Wherobots Professional Edition or Enterprise user, you have access to all capabilities of Wherobots Raster Inference! If you have access to GPU runtimes, sign in to your account now to launch a Wherobots Notebook and explore the feature. If you don’t yet have access, request it today and start using Raster Inference as soon as tomorrow. Explore how easy it is to bring your own model using our guided example on GitHub or within a Wherobots notebook instance. Start integrating Wherobots Raster Inference into your workflow today! Community Edition Users Although Raster Inference is not available in Wherobots Community Edition, we are currently offering a free trial for the Wherobots Professional Edition. You can either sign up through AWS Marketplace or upgrade your account to get started for free and integrate Raster Inference into your workflow today. What’s next We’re eager to hear about the models you’d like us to support and any features you’d like to see added. For product feedback, feel free to email us at feedback@wherobots.com (no request is too small). To see how others are using Raster Inference, ask questions, and share your own experiences, join the Wherobots community. We look forward to your ideas and creations! Missed our panel discussion with our collaborators CRIM, Terradue and Radiant Earth on the MLM STAC extension? Watch the recording below. Get Started with Wherobots Try Now Frequently Asked Questions What is Wherobots Raster Inference? It is a serverless computer vision capability for running inference on aerial and satellite raster imagery at planetary scale, using Wherobots-hosted models or a model you import. Can I bring my own model to Raster Inference? Yes. Fill out the MLM form to produce a JSON description of the model, upload that file to S3, and pass the S3 URI into the raster inference function at runtime. The pipeline uses the MLM spec for preprocessing, the model artifact, and post-processing. Which Wherobots editions include Raster Inference? Professional Edition and Enterprise users have access, including GPU runtimes. It is not available in Community Edition; the post points Community users to a Professional Edition free trial. What computer vision tasks does Raster Inference support in this post? The walkthrough covers classification (rs_classify / landcover-eurosat-sentinel2) and semantic segmentation (RS_SEGMENT / solar-satlas-sentinel2), then vectorizes predictions with RS_SEGMENT_TO_GEOMS for mapping in SedonaKepler. --- ## Building a Spatial Data Lakehouse URL: https://wherobots.com/blog/building-a-spatial-data-lakehouse/ Updated: 2026-10-19 Introduction In today’s data-centric world, geospatial data is collected at an unprecedented scale. Large organizations in sectors like logistics, telecommunications, urban planning, and environmental monitoring gather vast amounts of data daily—from GPS locations to satellite imagery and IoT sensors. This data is incredibly rich, holding insights into everything from human movement patterns to natural resource management. However, it is also extremely complex and challenging to store, process, and analyze effectively. Key takeawaysHavasu is Wherobots spatial data lakehouse format, built on Apache Iceberg, adding native geometry and raster types plus Iceberg features such as schema evolution, time travel, and versioning.Vector tables store points, lines, and polygons with spatial filter pushdown and clustering (CLUSTER BY geom). Data can be imported from GeoJSON, Shapefiles, GeoParquet, WKT, and PostGIS, or migrated from Parquet via snapshot into Havasu.Raster is a first-class type with in-DB storage for smaller images and out-DB rasters that keep pixels in S3 while the table stores metadata and paths. Out-DB guidance includes tile caching, spark.wherobots.raster.outdb.readahead (for example 64k or higher), and Cloud-Optimized GeoTIFFs.Spatial filter pushdown (RS_Intersects) plus partitioning (for example by SRID) and Hilbert spatial indexes cut the tiles scanned. Pixel-level map algebra should be preceded by RS_TileExplode (example 1024 by 1024); RS_ZonalStats only materializes pixels inside a geometry.STAC items can be loaded as a GeoJSON DataFrame, turned into out-DB rasters with RS_FromPath, and written as Havasu tables for RS_Intersects and RS_MapAlgebra. The post notes a planned move from Havasu to Iceberg-native GEO types. These challenges stem from the sheer scale, complexity, and unique processing needs of geospatial data. Traditional data lakes and warehouses were designed for tabular data and typically struggle to handle massive raster imagery, multi-layered vector datasets, and the spatial queries essential for geospatial analysis. This gap has left many organizations unable to fully leverage their geospatial data, which remains scattered, under-utilized, and costly to manage. Click here to launch this interactive notebook Launch Notebook Enter Havasu—Wherobots’ spatial data lakehouse solution that bridges this gap. Built on Apache Iceberg, Havasu brings the scalability of a data lake and the structured efficiency of a data warehouse to geospatial data, offering a comprehensive solution designed to meet the specific demands of spatial data management. You can learn more about the detailed specifications of Havasu here. With Havasu, organizations can: Achieve Performance at Scale: Havasu optimizes for high-speed processing of geospatial data, whether you’re performing complex spatial joins, analyzing real-time data streams, or querying historical records. Store Massive Volumes Efficiently: Havasu’s flexible in-DB and out-DB raster storage options allow organizations to manage enormous datasets, keeping costs low while enabling easy access to high-resolution imagery, vector layers, and more. Streamline Data Management: Built on the Iceberg table format, Havasu supports schema evolution, time travel, and versioning, empowering organizations to manage changing geospatial data with ease. This blog will walk you through the core principles of building a spatial data lakehouse with Havasu, showing how you can create and manage spatial datasets at scale, integrate external data sources, and optimize for performance and cost-efficiency. Whether your focus is on city planning, environmental monitoring, or large-scale logistics, this guide will equip you to unlock the full potential of your geospatial data. Creating a Table Creating tables in Wherobots is a breeze, and the process is highly adaptable. Whether working with vector data (points, lines, polygons) or raster images, you can set up tables in just a few steps. For instance, creating a table for storing vector geometries might look like this: sedona.sql(""" CREATE TABLE wherobots.test_db.cities (id bigint, name string, geom geometry) """) This command creates a simple table where the geom column is used to store spatial data in a geometry format, which can later be used in spatial queries. Similarly, you can create raster tables to store geospatial images like satellite data. Creating Tables & CRUD Operations In addition to creating tables, Wherobots fully supports CRUD (Create, Read, Update, Delete) operations. For example, if you need to update spatial data or remove records, it’s just as straightforward as using SQL commands. You can perform spatially-aware deletes, as shown below: sedona.sql(""" DELETE FROM wherobots.test_db.cities WHERE ST_Intersects(geom, ST_GeomFromText('POLYGON ((0 0, 0 2, 2 2, 2 0, 0 0))')) """) This flexibility allows you to manage your spatial data with the same ease as any other data in the database, while still taking advantage of the powerful geospatial capabilities of Wherobots. Connecting Storage A key feature of Havasu is its ability to integrate with external storage, allowing users to bring their own S3 buckets for managing spatial data. This enables users to scale their storage independently, providing flexibility and control over where and how their spatial data is stored. You can configure a catalog in Wherobots to connect directly to your own S3 bucket. This allows Havasu tables to be stored in your specified S3 location, ensuring that your spatial data lakehouse is highly scalable and aligned with your organization’s storage needs. For detailed instructions on setting up cross-account access and configuring your storage, please refer to documentation on S3 storage integrations. Sample Queries Once your table is created, running spatial queries is as easy as using standard SQL commands. However, Wherobots enhances this experience with powerful spatial functions. For example, finding all locations within a specific area could be done using the ST_Intersects function: sedona.sql(""" SELECT * FROM wherobots.test_db.cities WHERE ST_Intersects(geom, ST_GeomFromText('POLYGON ((0 0, 0 2, 2 2, 2 0, 0 0))')) """) These spatial queries leverage Wherobots’ built-in geospatial functions, making it easy to work with complex spatial relationships directly in your database. Vector Data In Havasu Vector tables in Havasu are crucial for managing and querying vector data, which includes points, lines, and polygons. These tables allow you to store geospatial features and leverage Havasu’s advanced spatial indexing and optimizations, such as spatial filter pushdown, to ensure fast data retrieval and processing. Let’s break down the process of working with vector tables in Wherobots. Creating Tables Creating a vector table in Wherobots is a straightforward process. When starting your spatial data lakehouse, the first step is to define how you will store vector data. Each feature (or record) in these tables is stored as a geometry column, which holds the spatial data—whether it’s a point representing a city or a polygon outlining a forest. For instance, to create a table for storing buildings in a city, you would use the following SQL command: sedona.sql(""" CREATE TABLE wherobots.test_db.buildings (id bigint, name string, geom geometry) """) This creates a table where the geom column is used for vector data like points, lines, and polygons. Once created, you can use Wherobots’ spatial SQL functions to run geospatial queries, such as finding intersections, distances, proximity relationships and more. Importing Common Formats WherobotsDB provides extensive support for importing spatial data in various commonly used formats, making it easy to integrate your existing geospatial datasets into Havasu. Whether you’re working with GeoJSON, Shapefiles, GeoParquet, WKT files, or even geospatial databases like PostGIS, Wherobots ensures seamless compatibility. Havasu stores spatial data in Apache Parquet format on cloud storage, a design choice that ensures cost-effective storage and a decoupled architecture for computation. This approach allows organizations to scale both storage and compute independently, optimizing for performance and budget. To learn more about importing specific formats and integrating your data with Havasu, check out the Wherobots Documentation on Importing Data Formats. Migrating from Parquet Many organizations already store their geospatial data in Parquet format due to its efficient columnar storage. However, Parquet lacks optimized support for spatial queries. Migrating your existing Parquet datasets to Havasu enables you to take full advantage of Native Spatial Data Types for geometry and raster, spatial indexing, optimized querying, and Havasu’s native geospatial capabilities. Create an external table from your Parquet file:sedona.sql("""CREATE TABLE spark_catalog.default.parquet_table ( id BIGINT, name STRING, geometry BINARY) USING parquet LOCATION 's3://path/to/parquet/files'""") Convert binary columns to geometry:Once the Parquet table is loaded, you can convert the geometry from a binary format into a format that Wherobots can use (EWKB or another supported geometry type). This can be done using an ALTER TABLE command:sedona.sql("""ALTER TABLE wherobots.test_db.parquet_tableSET GEOMETRY FIELDS geometry AS 'ewkb'""") This process ensures that you can utilize your existing Parquet datasets in Wherobots without reprocessing all the data. Click here to learn more about migrating Parquet files to Havasu. Converting Tables to Havasu Havasu extends the Iceberg format with spatial capabilities, and converting existing tables into Havasu tables brings a lot of advantages like schema evolution, time travel, and partitioning that optimizes spatial queries. To convert an existing table to a Havasu table, you simply need to perform a snapshot of the table. For example: sedona.sql(""" CALL wherobots.system.snapshot('spark_catalog.default.parquet_table', 'wherobots.test_db.new_havasu_table') """) This converts the table into a Havasu table format that benefits from all of Iceberg’s features. Clustering Geometries Clustering geometries is an optimization technique used to spatially organize data, which improves query performance, particularly for large datasets. By clustering geometries, spatial queries such as range queries or nearest-neighbor searches can be significantly faster. In Wherobots, you can cluster geometries during table creation or after the table has been populated. Here’s how you would cluster geometries in an existing table: sedona.sql(""" ALTER TABLE wherobots.test_db.buildings CLUSTER BY geom") """) This ensures that the geometries are spatially co-located, which minimizes the number of partitions scanned during spatial queries. To learn more about Spatial Filter Push-down and indexing strategies, click here. Raster Data In Havasu Havasu introduces raster data as a primitive type, meaning you can define tables with raster columns to store and manipulate spatial imagery, such as satellite imagery and elevation models. Users can create tables to store either in-DB rasters (where the image data is stored directly in the database) or out-DB rasters (where only metadata and paths are stored, with the images in external storage). With out-DB raster support, Havasu allows you to store only the metadata and file paths within the database, while actual raster files remain in external storage like AWS S3. This architecture makes it feasible to manage and query vast amounts of high-resolution imagery, supporting everything from city-scale maps to continent-wide satellite data without straining database resources. Creating and Loading Raster Data Creating a Basic Raster Table Here’s how you would create a raster table in Havasu: sedona.sql(""" CREATE TABLE wherobots.test_db.imagery ( id bigint, description string, rast raster) """) With this setup, the rast column will hold your raster data, allowing you to apply Havasu’s RS_ functions for raster processing and spatial queries. Loading Raster Data Havasu supports writing raster data using DataFrames, especially useful when you have image files (like GeoTIFFs) stored in S3 or local storage. This method allows you to read binary files and convert them into raster-compatible formats using the RS_FromGeoTiff function. # Create a DataFrame containing raster data df_binary = sedona.read.format("binaryFile")\ .option("pathGlobFilter", "*.tif")\ .option("recursiveFileLookup", "true")\ .load('s3://wherobots-examples/data/eurosat_small') df_geotiff = df_binary.withColumn("rast", expr("RS_FromGeoTiff(content)"))\ .selectExpr("rast", "path AS data") # Create a Havasu table using the DataFrame df_geotiff.writeTo("wherobots.test_db.test_table").create() This approach provides the option to write data as in-DB rasters or to reference them externally as out-DB rasters, depending on your storage and access requirements. Choosing Between In-DB and Out-DB Rasters Choosing between in-DB and out-DB storage is key for optimal performance. Here’s a breakdown: In-DB Rasters: Suitable for small to medium-sized rasters. These are fully managed within the database and provide faster access since all data is loaded directly from the database tables. Out-DB Rasters: Ideal for large, high-resolution images. With this setup, Havasu stores only metadata and file paths, while the raster images reside in external storage like S3, reducing database storage costs and allowing for lazy loading when data is accessed. Additional optimizations, such as tiling and caching frequently accessed tiles, allow you to efficiently handle extensive data operations without unnecessary overhead, making Havasu a cost-effective choice for large-scale raster data management. Best Practices for Out-DB Rasters Caching: Enable caching of frequently accessed tiles to avoid repeated reads from remote storage, improving overall performance. Read-Ahead Configuration: Set spark.wherobots.raster.outdb.readahead to an appropriate value (e.g., 64k or higher) to balance between read performance and network overhead. Using Cloud-Optimized GeoTIFFs (COG): These files are optimized for remote storage, reducing latency and bandwidth by organizing data in tile-friendly formats . Click here for more details about the Out-DB Raster type and a guide on improving it’s performance. Optimizing Performance with Spatial Filter Pushdown One of the strengths of Havasu for a raster data lakehouse is spatial filter pushdown, which applies spatial filters directly to reduce the amount of data read from storage. When querying for specific geographic regions, spatial pushdown ensures that only relevant raster tiles are accessed, significantly improving performance. For example: sedona.sql(""" SELECT * FROM wherobots.test_db.imagery WHERE RS_Intersects(rast, ST_GeomFromText('POLYGON ((...))')) """) This method is particularly effective when the raster tables are partitioned by location or other relevant attributes, making spatial filter pushdown even more efficient. For large-scale data lakehouse solutions, partitioning and indexing are essential to enhance query performance. Partitioning raster tables by spatial identifiers, such as SRID or city names, groups similar data together, further improving the efficacy of spatial filtering. For example, partitioning by SRID can be beneficial when dealing with geographically diverse datasets in different UTM zones. Partitioning by Region: Use partitionBy during table creation to reduce scanning times, especially for spatially filtered queries. # Write the data into a table partitioned by SRID/UTM zone df_geotiff.withColumn("srid", expr("RS_SRID(rast) as srid"))\ .sort('srid')\ .write.format("havasu.iceberg").partitionBy("srid")\ .saveAsTable("wherobots.test_db.eurosat_ms_srid") Indexing: For tables where partitions aren’t as useful, consider indexing raster data by geographic location using Havasu’s spatial indexing capabilities (e.g., hilbert indexing).sedona.sql("""CREATE SPATIAL INDEX FOR wherobots.db.test_table USING hilbert(rast, 10)")""") Hilbert curve with different number of iterations Advanced Raster Operations: Map Algebra and Pixel-Level Operations Havasu supports a suite of raster RS_ functions that enable complex analyses, including map algebra and zonal statistics. Lets dive into when each method is appropriate and their impact on performance. Map Algebra and Pixel-Level Operations This functionality is crucial for applications like remote sensing, where you might need to compute remote sensing indices on large geographical regions across multiple raster bands. For instance you can use RS_MapAlgebra to calculate the Normalized Difference Vegetation Index (NDVI) on a multi-band raster: sedona.sql(""" SELECT RS_MapAlgebra(rast, 'D', 'out = (rast[3] - rast[0]) / (rast[3] + rast[0]);') as ndvi FROM raster_table """) This flexibility allows Analysts to perform custom calculations directly within Havasu, simplifying workflows for raster analysis. RS_ZonalStats for Efficient Calculations within Areas of Interest For use cases where only specific areas within a raster need processing, RS_ZonalStats offers an efficient alternative. This function calculates statistics (e.g., mean, sum, etc) for pixels within a designated geometry (e.g., a polygonal area of interest), loading only the required subset of pixels into memory. Unlike pixel-level operations that materialize the entire raster, RS_ZonalStats selectively materializes pixels only within the specified geometry. This efficiency makes it ideal for spatial analyses that focus on specific regions without the overhead of processing the entire raster: sedona.sql(""" SELECT RS_ZonalStats(outdb_raster, geometry, 'mean') FROM raster_table """) Because RS_ZonalStats is targeted to the geometry, tiling may not be necessary for these operations. This distinction allows you to avoid tiling when performing zonal statistics, keeping the process streamlined and reducing unnecessary data handling steps. By choosing the appropriate approach based on your operation type, you can maximize efficiency when working with large out-DB raster datasets in Havasu, ensuring both performance and resource management. Handling Pixel-Level Operations on Out-DB Rasters in Havasu When performing pixel-level operations on raster data in Havasu, it’s essential to understand the implications of using out-DB rasters. Any operation that accesses individual pixels directly, such as map algebra calculations, will materialize these pixels in memory, which can be resource-intensive if working on a large out-DB raster dataset. This section explores best practices for managing these operations efficiently. Preprocessing with RS_TileExplode for Pixel-Level Operations For out-DB rasters, any pixel-level transformation will load pixel data from remote storage into memory, creating a significant memory load. To make these operations more manageable: Tile the Raster Data: Using RS_TileExplode splits the raster into smaller, more manageable tiles, allowing you to work on localized sections rather than loading the entire raster at once. df_tiled = sedona.sql(""" SELECT RS_TileExplode(raster_data, 1024, 1024, true) AS tile FROM outdb_rasters """) Before and after RS_TileExplode(). Image taken from nv5GeoSpatialSoftware With the raster data pre-tiled, pixel-level functions like RS_MapAlgebra can be applied to individual tiles, preventing full materialization of large rasters in memory and optimizing processing time and memory usage. This approach is particularly beneficial for complex calculations that require pixel-by-pixel transformations, as tiling minimizes memory consumption and enables parallelized processing of smaller raster sections. STAC Rasters in Havasu To incorporate STAC (SpatioTemporal Asset Catalog) datasets into Havasu, the process involves accessing the STAC dataset as a Sedona DataFrame, surfacing STAC assets (raster bands) as out-db or in-db rasters, and finally saving it in a Havasu table. This guide provides the essentials to help you set up STAC-based raster data in Havasu, with specific attention to handling the dataset efficiently in Wherobots. Accessing STAC Data and Creating a DataFrame STAC datasets like Sentinel-2 imagery are typically available in JSON format, which includes metadata about each raster, such as acquisition time, spatial extent, and the URLs of imagery files. The first step is to read these JSON files into a DataFrame: Fetch and Store JSON Metadata: STAC items, usually hosted on platforms like Earth-search, can be stored as JSON files in an S3 bucket or any accessible location. Load into Sedona DataFrame: Use Sedona’s GeoJSON reader to load the STAC metadata into a DataFrame. This DataFrame will contain essential attributes like URLs to individual raster bands (e.g., blue, red, NIR). df_stac = sedona.read.format("geojson").load("s3://your-bucket/path-to-stac-metadata") This DataFrame now acts as a container for your STAC items, enabling you to manipulate, transform and/or perform spatial joins on the metadata before loading actual raster data. Saving STAC Rasters as Out-DB Columns Havasu’s out-DB raster capability allows you to reference large raster files externally, ideal for high-resolution datasets like Sentinel-2 imagery. To set this up: Transform URLs: Ensure each STAC asset URL points to a valid path accessible by Wherobots (e.g., converting https URLs to s3:// format if stored on S3). Create Out-DB Raster Columns: Use RS_FromPath to reference each asset as an out-DB raster. Here’s an example with a blue band raster: df_rasters = df_stac.withColumn("raster_blue", expr("RS_FromPath(assets.blue.href)")) Repeat this process for each required band (e.g., red, NIR) to build a DataFrame that references all the necessary raster paths. This setup maintains efficient storage by referencing images externally, reducing data load times and storage requirements in Havasu. Saving the STAC Raster Data to Havasu Once you’ve set up the DataFrame with out-DB raster columns, the next step is to save it as a Havasu table: Write to Havasu: Use writeTo() to save the DataFrame as a new Havasu table, enabling further spatial queries and transformations within Wherobots. df_rasters.writeTo("wherobots.test_db.stac_raster_table").create() With this approach, your STAC imagery is now part of a Havasu table, ready for efficient querying and spatial operations. WherobotsDB enables advanced spatial functions like RS_Intersects and RS_MapAlgebra, making it straightforward to analyze the imagery stored as out-DB rasters. Considerations URL Compatibility: Ensure paths are accessible by Wherobots (e.g., transforming https to s3:// if needed) to avoid data access errors. Tile Size and Storage Optimization: For performance, adjust tile sizes and consider filtering edge-case tiles to optimize spatial queries. Tuning for Performance: For extensive STAC datasets, consider caching and configuring Spark to handle out-DB rasters efficiently by setting appropriate cache sizes and connection thresholds. This streamlined approach provides an effective way to incorporate STAC datasets in Havasu, enabling data engineers to leverage high-resolution satellite imagery in their spatial data lakehouse while optimizing for performance and storage. Monitoring and Maintenance Monitor your data lakehouse solution’s performance using WherobotsDB’s configurations and consider periodically converting standard GeoTIFF files to Cloud-Optimized GeoTIFF (COG) to reduce storage latency. Use gdalinfo to inspect file structures, tile sizes, and compression formats, ensuring that your files are optimized for remote access. Conclusion Geospatial data presents a wealth of opportunities for organizations across industries, yet its inherent complexity often makes it difficult to unlock its full potential. With Havasu, Wherobots has developed a solution tailored specifically to the demands of geospatial data management, combining the scalability of a data lake with the structured efficiency of a data warehouse. From its seamless integration with cloud storage and support for common geospatial formats to advanced capabilities like spatial indexing, filter pushdown, and raster processing, Havasu empowers organizations to efficiently store, query, and analyze spatial data at scale. By leveraging its open architecture and powerful features, teams can transform vast geospatial datasets into actionable insights, driving innovation in logistics, urban planning, environmental monitoring, and beyond. When paired with WherobotsDB, Havasu transforms geospatial analytics by providing high-speed querying for both raster and vector data, advanced spatial indexing, and seamless compatibility with cloud-native storage solutions like AWS S3. This differentiates Havasu from legacy solutions that struggle with scalability or require complex application-layer workarounds for spatial data. As geospatial data continues to grow in both scale and importance, adopting a spatial data lakehouse architecture with Havasu ensures that your organization remains at the forefront of data-driven decision-making. Whether you’re just beginning to integrate spatial data into your workflows or optimizing an existing system, Havasu equips you with the tools to manage, process, and analyze geospatial data with unmatched efficiency and flexibility. Learn more about how Havasu can help you redefine your geospatial data strategy in the official documentation. Unlock the future of geospatial intelligence today. Start building with Wherobots Get Started Frequently Asked Questions What is Havasu? Havasu is Wherobots spatial table format on Apache Iceberg. It stores vector geometries and rasters as native types and keeps files as Parquet on cloud storage. It adds spatial indexing and filter pushdown on top of Iceberg schema evolution, time travel, and versioning. Should raster data be stored in-DB or out-DB? Use in-DB rasters for small to medium images that should live fully in the table. Use out-DB rasters for large high-resolution imagery: Havasu stores metadata and paths while pixels stay in S3, with optional tile caching and COG layout for remote reads. How do I migrate existing Parquet into a spatial lakehouse? Create an external Parquet table, declare the binary column as geometry (for example EWKB) with ALTER TABLE … SET GEOMETRY FIELDS, then CALL wherobots.system.snapshot to produce a Havasu table. How do you keep map algebra from materializing a whole out-DB raster? Run RS_TileExplode first so algebra runs on tiles, or use RS_ZonalStats when you only need statistics inside a polygon. Partitioning by SRID and creating a Hilbert spatial index further reduce scans. --- ## Data Engineering URL: https://wherobots.com/solutions/data-engineering/ Updated: 2026-04-16 The Only Compute Engine Optimized for Spatial Data Handle raster and vector data at scale with unmatched speed. Get Started for Free Why Wherobots Existing data lakehouses fall short on spatial data. Wherobots is optimized for spatial compute, delivering faster processing and a more seamless experience than any solution on the market today. What does that mean for you? A broad set of integrated functions within easy to use notebooks for raster and vector data with visualizations built in. No more patching together tools, libraries, and platforms. Learn about WherobotsDB Fast and efficient spatial data processing, letting you focus on building data pipelines not waiting for them to run. Try it out Managed cloud-native, serverless infrastructure. No upgrades or updates, spatial computing power ready when you are at the scale you need. Wherobots Cloud Overview Seamlessly integrate into your current stack via jobs, Airflow, APIs or SDKs, so you can make your work → flow. Learn About Wherobots APIs Features Free to Enterprise Tier, See Your Options The best developer experience in geospatial Build geospatial data pipelines effortlessly with  a complete developer experience. Try Wherobots today The fastest, most efficient implementation of Apache Sedona Beat any data warehouse, Spark + Sedona setup, or legacy spatial processing tool. Read Example Stories Use python or spatial SQL Use familiar tools like Python and Spatial SQL, now supercharged for geospatial data Learn more about Apache Sedona A spatial data lakehouse with Apache Iceberg based Havasu tables Supports modern data lakehouse architectures  and efficient data management Use geospatial Iceberg, only in Wherobots Orchestrate with Apache Airflow Integrate with Airflow for simple, streamlined pipeline management. Use the Wherobots Airflow runner Bring your data lake Securely connect to your first party data on S3 or other blob storage. Learn how to integrate S3 storage with Wherobots We accelerated the pipelines that produce the Overture buildings data pipeline, which is made up of 2.3bn geometries and growing, by up to 20x after we moved them to Wherobots. This just required a simple redirection of our code. We retained compatibility with Apache Sedona, and the move put us into a development experience that’s made us much more productive Jennings Anderson, Software Engineer with Meta for the Overture Maps Foundation Overture Maps Foundation provides open map data to help companies build accurate, customizable mapping services without relying on proprietary platforms. Are You Ready to Transform Your Spatial Workflows? Try Wherobots --- ## Data Teams URL: https://wherobots.com/solutions/data-teams/ Updated: 2026-10-03 Collaborative Spatial Data Solutions for Data Teams Scale your spatial data pipelines, integrate with your existing tools, and reduce processing time and costs. Request a Demo Why Wherobots Managing spatial data across teams can be complex and costly. Wherobots offers a scalable, integrated platform that helps data teams process large vector and raster datasets more efficiently and cost-effectively, while seamlessly fitting into your existing infrastructure Fast and efficient spatial data processing, letting you focus on building data pipelines not waiting for them to run. Try it out A broad set of integrated functions within easy to use notebooks for raster and vector data with visualizations built in. No more patching together tools, libraries, and platforms. Learn About WherobotsDB Managed cloud-native, serverless infrastructure. No upgrades or updates, spatial computing power ready when you are at the scale you need. Wherobots Cloud Overview Enhance your spatial analysis with pre-trained GeoAI and ML models, directly within the Wherobots environment. Or, bring your own pre-trained models. Learn About RasterFlow Features Free to Enterprise Tier, See Your Options The best developer experience in geospatial Build geospatial data pipelines effortlessly with  a complete developer experience. Try Wherobots today The fastest, most efficient implementation of Apache Sedona Beat any data warehouse, Spark + Sedona setup, or legacy spatial processing tool. Read Example Stories A spatial data lakehouse with Apache Iceberg based Havasu tables Supports modern data lakehouse architectures and efficient data management Use geospatial Iceberg, only in Wherobots Orchestrate with Apache Airflow Integrate with Airflow for simple, streamlined pipeline management. Use the Wherobots Apache Airflow Provider Use your current data lake infrastructure Securely connect to your first party data on S3 or other blob storage. Learn how to integrate S3 storage with Wherobots Are You Ready to Transform Your Spatial Workflows? Try Wherobots With Wherobots Spatial SQL, we’re able to analyze population data more efficiently and more accurately, reducing processing time from 39 days to less than one day, and deliver it to our customers across the globe in a far more timely manner. Not only was this a massive speed increase, the overall impact to our data team is they are able to work far more efficiently and productively, answering questions for our customers faster and helping to grow our business. Jerome Urbain, Head of Data Products at GeoPostcodes --- ## Machine Learning for Earth Observation URL: https://wherobots.com/solutions/machine-learning-for-earth-observation/ Updated: 2026-10-03 On-demand inference built for aerial imagery Run models for aerial imagery on-demand and work with insights using the tools you know and love Request a Demo boreholes hydrology climate landform lancover Why Wherobots Analyzing earth observation data is often limited by human interactive capacity or data processing constraints. With Wherobots, you can process massive EO data using managed or open models, and easily complete your solution with SQL or Python. Enhance your spatial analysis with your own or hosted GeoAI and ML models, on-demand within Wherobots. Read About RasterFlow On-demand spatial computing is ready for various geospatial data types, at any scale. Wherobots Cloud Overview Complete your analysis using over 300 built-in vector and raster functions, and visualization support in a unified notebook environment. Learn About WherobotsDB Features Free to Enterprise Tier, See Your Options Use pre-trained models, or bring your own Use pre-trained models for segmentation, object detection, and classification from the Allen AI Institute, or import your own model using the STAC Machine Learning Model specification. Learn How Wherobots Accelerates GeoAI Simple tools for fast raster data preparation Wide range of functions to prepare and manage your raster data at any volume, quickly. Learn how to work with raster data in Wherobots Use models with public and commercial imagery Leverage open and commercial data using any STAC collection to analyze gigabytes, terabytes, or petabytes of imagery. Inference on Overhead Imagery, Fast Connect to remote raster sources Work directly on large scale spatial data and a wide range of earth observation datasets—like Earth on AWS, while minimizing data transfer costs. Learn how to load remote raster data in Wherobots Leverage JupyterLab, Apache Airflow, or your favorite tools. Work with the familiar tools you know, including popular notebooks and orchestration tools, or your favorite command line interface (CLI) via the Wherobots API. Learn About Wherobots APIs and SDKs From a developer perspective, having data, algorithms and compute (and to be presented with a Spark/Sedona context in a Jupiter notebook on startup) combined in one platform is extremely powerful, comparable in many respects to Google Earth Engine, but with much greater guarantees of, and control over, job completion. John Powell, Senior Geospatial Data Engineer at Addresscloud Are You Ready to Transform Your Spatial Workflows? Try Wherobots --- ## Wherobots is ready for AWS workloads URL: https://wherobots.com/blog/wherobots-is-ready-for-aws-workloads/ Updated: 2026-10-19 Planetary-scale geospatial solutions are now accessible via Wherobots on the AWS Marketplace We’re thrilled to announce that Wherobots is generally available for AWS customers with pay-as-you-go pricing via the AWS Marketplace. AWS customers can subscribe to a 30 day, free trial of the Wherobots Professional Edition for up to $400 in usage, and discover how easy it is to create spatial solutions that propel their business forward. The integration with the AWS Marketplace simplifies the Wherbots buying and usage experience, particularly those with AWS commitments or discounts that apply to AWS Marketplace spend. Coupled with a secure integration to run Wherobots on private or public S3 buckets, Wherobots is where the next generation of geospatial solutions are developed on AWS. Key takeawaysWherobots is generally available to AWS customers as pay-as-you-go on AWS Marketplace, with a 30-day Professional Edition trial covering up to $400 in usage.The Spatial Intelligence Cloud is built on Apache Sedona and is described as up to 20x more performant than Apache Sedona and Apache Spark. It has a serverless engine for spatial analytics and inference on the customer data lake.Development covers raster (satellite and drone imagery) and vector (mobility, polygons, trips, roads) in one place, using SQL, Python, or Scala in notebooks. It includes 300+ built-in functions plus Map Matching, GeoStats, and Raster Inference.AddressCloud reports jobs that used to take hours or days now run in minutes, including combined vector/raster peril analysis without converting rasters first.Overture’s global buildings dataset, 2.3 billion geometries and growing, accelerated by up to 20x after moving pipelines to Wherobots with a code redirect, while staying Apache Sedona compatible. The potential of spatial data is very high Many companies have significant investments in assets, products, or services that are influenced by our dynamic world. To be competitive, adaptive, and profitable, companies need to accelerate the velocity of decisions about these investments. Insurance companies like State Farm need solutions for calculating asset risk in the face of a rapidly changing climate. Telecommunications providers like Comcast optimize their network operations to account for bandwidth constraints from physical barriers like buildings, tunnels, and weather. Retailers like Starbucks need to identify the next retail location to launch or sunset based on mobility data, supply and demand, and demographic trends. Logistics providers like Amazon Last Mile Delivery need to autonomously adjust distribution and delivery plans based on roadway conditions, road updates, traffic conditions, and delivery payloads. Farming and forestry operations are looking for ways to optimize yields in a way that’s sustainable and profitable. Solar and wind farm operators are identifying the next best locations to develop sustainable power sources, and also connect to expanding charging station networks across the globe. These industries are modernizing with the cloud, but services in the cloud haven’t made it easy to create these types of solutions, until now. Spatial ideas are everywhere, but solutions are sparse If these types of solutions resonate with your business, I’d wager that if you asked your teams to produce ideas that rely on geospatial data, they’d have a lot to share. But the reality is most teams are not enabled to unlock these ideas. They will say it’s really hard, if not infeasible to turn these ideas into solutions that propel your business forward. Which also means the ideas are put on the back burner or considered far-fetched. Wherobots makes spatial solutions accessible Built on and fully compatible with Apache Sedona, Wherobots is the Spatial Intelligence Cloud. Wherobots offers geospatial ETL, analytics, and AI solutions that make it easy for data scientists and engineers to create spatial data products, and the intelligence that drives their business forward. Wherobots delivers industry leading scalability and spatial computing performance on your data lake. It’s up to 20x more performant than Apache Sedona and Apache Spark using a serverless analytics and inference engine optimized for spatial operations. Development is unified across what are otherwise siloed data types – raster (satellite and drone imagery) and vector (mobility data, polygons, trips, roads) data. And solutions can be built with SQL, Python, or Scala in a notebook, putting solutions in-reach to common developers. There’s 300+ built in functions and higher level features, like Map Matching, Geostats, and Raster Inference to accelerate development. With pay-as-you-go pricing on the AWS Marketplace, Wherobots is where the next generation of spatial data solutions are built. What are customers saying? Wherobots customers like AddressCloud and Overture realized typical performance gains of 5-20x, lower costs, and objectively higher developer productivity after migrating their Apache Sedona workloads into Wherobots. AddressCloud helps insurers calculate geographic risk “Wherobots has given us the potential to run jobs that used to take hours or days to minutes and removed the need to think about provisioning compute. As we provide perils information (flood, fire, etc) to insurers at the property level, we particularly appreciate the ability to be able to run combined vector/raster analysis, without having to previously transform the raster data into vector format or some other format,” said John Powell, Senior Geospatial Data Engineer at Addresscloud.” Overture provides current and next-generation map products by creating reliable, easy-to-use, and interoperable open map data “Overture produces a building dataset covering all buildings in the world, with 2.3B geometries and growing, that’s updated frequently. There’s a lot of data and compute that goes into producing and keeping it up to date,” said Jennings Anderson, Geoscientist at Overture and Data Engineer at Meta. “We accelerated the pipelines that produce the buildings dataset by up to 20x after we moved them to Wherobots, which required a simple redirection of our code. We retained compatibility with Apache Sedona, and the move put us into a development experience that’s made us more productive.” Getting started is easy. From your AWS account, subscribe to the Professional Edition of Wherobots on the AWS marketplace. You can get started risk-free in the professional edition with features required by production workloads. We’ve built tens of example notebooks to help you go from zero to iterating with spatial data in minutes. Feedback? Our mission is to make it easy for our customers to utilize geospatial data. We cannot complete our mission without your input, and are working with a variety of customers to shape what we do next. If you are invested in the problems we are solving, and have an idea to improve our product, please contact us at feedback@wherobots.com, or contact me directly at damian@wherobots.com. I’m eager to hear from you, and we are there to help you innovate with Wherobots on AWS. Try Wherobots on AWS Marketplace Get Started Frequently Asked Questions How do I buy Wherobots on AWS? Subscribe to the Professional Edition on AWS Marketplace from your AWS account. Spend can apply toward AWS commitments, and you can start with a 30-day trial of up to $400 in usage. How much faster is Wherobots than Apache Sedona on Spark in this post? The post states Wherobots is up to 20x more performant than Apache Sedona and Apache Spark. AddressCloud and Overture are cited with typical gains of 5-20x after migrating Sedona workloads. What did Overture report after moving to Wherobots? Jennings Anderson says Overture’s world buildings dataset has 2.3 billion geometries. Pipelines that produce it accelerated by up to 20x after a simple redirection of existing Apache Sedona code. Does Wherobots run on my S3 data? Yes. The post describes a secure integration to run Wherobots on private or public S3 buckets so spatial ETL, analytics, and AI stay on the data lake. --- ## Announcing Our 21.5M Series A :: Unlocking Answers to Planetary-scale Questions. URL: https://wherobots.com/blog/unlocking-answers-to-planetary-scale-questions/ Updated: 2026-10-19 Unlocking answers to planetary-scale questions. By Wherobots co-founders Mo Sarwat and Jia Yu Each day, satellites, drones, applications, and GPS devices generate petabytes of spatial data that can be used to solve real-world problems. But the majority of this data is stuck in siloed legacy systems or sits idle and disjointed. We see the potential this data can have for business, the planet, government, and societies. And we’re on a mission to help companies fully utilize it so they can tackle issues like how to manage their fleets of vessels and vehicles, where and how to build infrastructure, and determine the best methods to assess and mitigate risk of catastrophic natural disasters. Key takeawaysThis is a Series A funding announcement rather than a product deep dive: Wherobots raised $21.5M led by Felicis, with Wing Venture Capital, Clear Ventures, JetBlue Ventures, and P7 Ventures. Aydin Senkut (Felicis) joins the board with Peter Wagner (Wing).Co-founders Mo Sarwat and Jia Yu created Apache Sedona (from GeoSpark at Arizona State University). The post says Sedona has over 40 million downloads and is used for planetary-scale workloads by companies such as Amazon.com (last-mile delivery) and Land O’Lakes (precision agriculture).Wherobots is positioned as a fully managed Spatial Intelligence Cloud compatible with Apache Sedona. Industries cited can analyze real-world issues up to 20x faster at planetary scale.Customer quotes recap existing results: Overture’s 2.3 billion building geometries accelerated up to 20x, and GeoPostcodes cut population-boundary processing from 39 days to less than one day. AddressCloud moved property-level flood/fire jobs from hours or days to minutes.The round also funds go-to-market, including AWS Marketplace availability and AWS re:Invent (GeoParty on December 4 and a Thursday 12:30 lightning talk). To achieve our mission, we’re partnering with leading investors in the technology space and have raised $21.5M in Series A funding—led by Felicis, with continued support from Wing Venture Capital and Clear Ventures and participation from JetBlue Ventures and P7 Ventures. Aydin Senkut, Founder and Managing Partner at Felicis will also be joining Wherobots’ Board of Directors together with Peter Wagner from Wing Venture Capital. We are committed to constantly improving our technology to process and analyze geospatial data faster and more efficiently and this funding will accelerate our product development and go-to-market operations. From Research to Market Growing up in Egypt, Mo saw the impact of climate change first-hand. Rising temperatures and pollution are threatening the air quality and water supply of millions of Egyptians. These challenges, among others, are not isolated—they reflect global issues as our world changes faster than ever. Motivated by these realities, we set out to harness data that captures what’s happening in the physical world to drive innovation and empower people to tackle both large-scale and localized problems. We met when Mo was a professor and Jia was finishing his PhD at ASU. We bonded over our shared passion for geospatial data and its untapped use cases. We realized the popular data warehousing and analytics solutions available were built from the ground up to process internet data, not geospatial data. When geospatial data is forced into these systems, they underperform, lack essential features for intuitive geospatial analysis, and are often either closed-source or reliant on outdated architectures. These limitations make geospatial solutions inaccessible for most organizations. Recognizing this gap, we set out to create a solution tailored to the unique challenges of geospatial data, unlocking its power for organizations of all sizes. Apache Sedona — an open-source geospatial compute framework — was our first response to this issue. Today Apache Sedona has over 40M downloads and is now used to run planetary-scale workloads by companies like Amazon.com for last mile delivery and Land O’ Lakes for precision agriculture. After years of growing Apache Sedona, we saw a tremendous appetite for a more in-depth enterprise solution. Enter Wherobots, a fully managed, scalable cloud platform that is purpose-built to make geospatial solutions easy to create while maintaining compatibility with Apache Sedona. Wherobots also integrates well with the modern data and AI ecosystem, making it a plug-n-play option for Fortune 1000 companies to derive value from the geospatial data they collect. Putting Data to Work Wherobots’ Spatial Intelligence Cloud empowers businesses to unlock planetary-scale solutions and put their spatial data to work. Data teams are able to solve problems faster and more efficiently on a compute engine that’s optimized for spatial analytics, a broad set of functions in SQL, Python, and Java, with a variety of native geospatially specific functions, as well as the ability for customers to bring in their own AI and ML models to drive insight from the physical world. This makes Wherobots a far more productive system for data teams to get their work done without switching contexts. Using Wherobots, industries across financial services & insurance, transportation, logistics & supply chain, energy, agriculture, and social services can analyze real-world issues up to 20x faster at a planetary-scale. This means more informed, faster decision making around areas like last mile delivery, infrastructure, mobility, and agriculture. Our Community and Partners Industries need to stay ahead of an evolving planet as the climate changes, natural disasters become more prevalent, the rate in which people migrate increases, geopolitical issues become more common, and interconnected systems continue to evolve. These shifts can raise both macro and micro level challenges around everything from where to focus a businesses’ operations and infrastructure to where consumer demand is moving. Wherobots activates the data businesses already have available by making their geospatial context more complete and precise, allowing them to scale and plot an intelligent and adaptable course forward. We’re bringing this to life working with organizations like The Overture Maps Foundation, a coalition of industry leaders including Meta, Microsoft, Amazon, and TomTom, to support its global mapping initiatives, Addresscloud, to help insurers understand geographic risk, and GeoPostcodes, to support analytics for its global postal and population database. Here’s what they have to say: “Overture produces a building dataset covering all buildings in the world, with 2.3B geometries and growing, that’s updated frequently. There’s a lot of data, and compute that goes into producing it and keeping it up to date,” said Jennings Anderson, Geoscientist at Overture and Data Engineer at Meta. “We accelerated the pipelines that produce the buildings dataset by up to 20x after we moved them to Wherobots, which required a simple redirection of our code. We retained compatibility with Apache Sedona, and the move put us into a development experience that’s made us more productive.” “Our high quality data results from aggregating reliable raster population data with our curated boundaries vector database,” said Jerome Urbain, Head of Products at GeoPostcodes. “With Wherobots Spatial SQL, we’re able to analyze population data more efficiently and more accurately, reducing processing time from 39 days to less than one day, and deliver it to our customers across the globe in a far more timely manner. Not only was this a massive speed increase, the overall impact to our data team is they are able to work far more efficiently and productively, answering questions for our customers faster and helping to grow our business.” “Wherobots has given us the potential to run jobs that used to take hours or days to minutes and removed the need to think about provisioning compute. As we provide perils information (flood, fire, etc) to insurers at the property level, we particularly appreciate the ability to be able to run combined vector/raster analysis, without having to previously transform the raster data into vector format or some other format,” said John Powell, Senior Geospatial Data Engineer at Addresscloud. “From a developer perspective, having data, algorithms and compute (and to be presented with a Spark/Sedona context in a Jupyter notebook on startup) combined in one platform is extremely powerful, comparable in many respects to Google Earth Engine, but with much greater guarantees of, and control over, job completion.” AWS Marketplace Integration We’re researchers at heart and we understand that there are so many undiscovered use cases for geospatial data—our customers are the ones helping expand and retool the industry. We’re excited to reach even more teams through our availability on the AWS marketplace, allowing customers to leverage their AWS committed spend and benefit from integrated billing. We’ll be at AWS re:Invent in December (next week!) to learn what else geospatial data can take on. If you are coming to re:Invent, sign up for our GeoParty on the 4th of December, or check out our lightning talk at 12:30 on Thursday. Additionally, the Amazon Last Mile team will be showcasing how they utilize Apache Sedona at the Open Source Developer Theater. For a full overview of everything we have going on at re:Invent, checkout our overview page. What’s Next When we first started the groundwork for Wherobots, we were shocked at the disconnect between the vast amount of planetary data available and cloud data infrastructure support. Through this new round of funding, we hope to provide companies with the tools to really see the world we live in, adapt to new challenges, create intelligence, and potentially save lives. We hope you follow along for our next chapter and if this sounds like something you want to be a part of—we’re always looking for great talent. Want to keep up with the latest developer news from the Wherobots and Apache Sedona community? Sign up for the The Spatial Intelligence Newsletter: Frequently Asked Questions How much did Wherobots raise in its Series A? Wherobots raised $21.5 million, led by Felicis, with continued support from Wing Venture Capital and Clear Ventures and participation from JetBlue Ventures and P7 Ventures. Who created Apache Sedona and Wherobots? Mo Sarwat and Jia Yu met at Arizona State University (Mo as professor, Jia finishing his PhD). They created Apache Sedona and founded Wherobots as a managed cloud on top of it. What customer results are quoted in the Series A post? Overture sped buildings pipelines by up to 20x on 2.3 billion geometries. GeoPostcodes reduced processing from 39 days to less than one day. AddressCloud reports jobs that took hours or days now run in minutes, including combined vector/raster analysis. How many Apache Sedona downloads does this post cite? It says Apache Sedona has over 40 million downloads. --- ## Accelerating Vector and Raster Analysis at GeoPostcodes URL: https://wherobots.com/blog/accelerating-geospatial-analysis-wherobots-geopostcodes/ Updated: 2026-10-19 Accelerating Vector and Raster Analysis at GeoPostcodes How long is too long to wait for a data set to process? In the fast-paced world of data as a service, efficiency isn’t just a nice-to-have; it’s essential. But for GeoPostcodes, before Wherobots, previous updates to the global population movement datasets took about 39 days. This was running on a headless QGIS instance in combination with PostGIS, combining population rasters with postal code boundaries. Key takeawaysGeoPostcodes used to refresh global population movement datasets in about 39 days on a headless QGIS instance plus PostGIS, combining population rasters with postal-code boundaries.On Wherobots the same enrichment finished in hours, using out-DB rasters, RS_TileExplode(), and repartitioning so only required pixels are read and joined to mapping units.GeoPostcodes covers zip codes, cities, and administrative areas for 247 countries as 15.9 million geocoding points and 880,000 boundary polygons, now enriched with Global Human Settlement (GHS) population estimates.The analysis used GHS 100-meter resolution grids in 5-year increments from 1975 through 2030, rolling estimates from the smallest administrative units up to higher levels.Country runtimes versus the legacy system include United States 6 vs 780 minutes (135x, 30,144 zip codes) and Saudi Arabia 3 vs 125 minutes (44x). They also include Japan 3 vs 62 minutes (20x) and Russia 66 vs 1,170 minutes (18x). For GeoPostcodes, before Wherobots, previous updates to the global population movement datasets took about 39 days. At Wherobots, we’ve made it our mission to push the boundaries of what’s possible in distributed spatial computing to not just process data faster, but to increase productivity. When GeoPostcodes, a leader in geospatial data products, sought to enhance their administrative boundaries enrichment processes with population estimates derived from the Global Human Settlement (GHS) population grid, they knew they needed a new solution. Together, we’ve managed to transform a process that once took nearly a month and a half into a task completed in hours. See how this works in an interactive notebook Launch Notebook Let’s take a closer look at how this collaboration reshaped GeoPostcodes capabilities to deliver fresh data in orders of magnitudes of less time. TLDR: The collaboration between Wherobots and GeoPostcodes yielded a significant improvement in processing time for GeoPostcodes new data products. This progress has powerful implications for development and applications in fields that rely on timely and accurate data processing. Read ahead for the details or check out the live stream recording. Why This Matters So, why is this performance gain so important? The ability to process complex geospatial data in a fraction of the time has profound implications for a wide range of industries. The benefits are not isolated to reduced analysis time and system complexity. Running analysis quickly allows data engineers and analysts to iterate faster, test out new product / data ideas, and decrease time to market. For urban planners, home builders, and retailers, having access to up-to-date population estimates can inform better decisions about infrastructure development, operations, and services. For logistics companies, understanding population distributions can enhance route planning and resource allocation. And for market analysts, demographic insights are invaluable for crafting targeted strategies and predicting consumer behavior. By reducing processing times from weeks to hours, Wherobots and GeoPostcodes are empowering these industries to make faster, more informed decisions. The days of waiting weeks for analysis results are over—now, critical data can be at your fingertips in just a matter of hours. About Wherobots and GeoPostcodes Wherobots is at the forefront of distributed spatial computing technology with hosted and highly optimized Apache Sedona (our founders are the original creators of the project). We specialize in providing a platform that empowers data teams to build and deliver data products efficiently and at scale. Through a cloud native, highly optimized service, built for developers and data engineers, Wherobots enables data teams to iterate and produce faster by running complex spatial computations at unprecedented scale and speed. Wherobots technology scales to meet any data workload, offering the flexibility needed to handle even the most demanding spatial data processing tasks efficiently. Whether it’s raster or vector analysis, or even machine learning tasks, it delivers the computational power required to get the job done faster and more effectively, while maintaining 100% code compatibility with open source Apache Sedona. GeoPostcodes has established itself as a trusted provider of high-quality geospatial data. Their datasets are vital to industries such as Logistics, Insurance, e-commerce, and market analysis, providing zip codes, cities, and administrative areas for 247 countries, available as 15.9M points (geocoding) and 880k boundaries (polygons). With their newest feature—population estimates derived from the GHS population grid—GeoPostcodes adds a valuable layer of demographic information to their datasets, giving users deeper insights and more powerful tools for decision-making. A bit about the data Mapping Units: GeoPostcodes provides high resolution administrative units at various scales (e.g. county, state, national) as well as zip code boundaries. The smallest administrative units and the zip code boundaries served as the mapping units. We enriched the administrative units with population estimates from the GHS data. Using the smallest administrative unit allowed us to roll the population estimates into the higher level administrative units reducing the need for additional processing. Global Human Settlement data (GHS) The Global Human Settlement layer, developed by the European Commission’s Joint Research Centre, provides global population estimates at a high spatial resolution. It is based on a combination of satellite imagery, census data, and other sources. The estimates are available in 5 year increments starting in 1975 and run through 2030. They are provided in a gridded format with a resolution of at various resolutions, for this analysis we chose the 100m resolution data. The Old Way: Over a month of processing in PostgreSQL Before the collaboration with Wherobots, GeoPostcodes had developed a method for deriving population estimates for their administrative boundaries dataset. This process used their PosGIS data warehouse and a dockerized headless instance of QGIS. In this setup, the GHS population grid data is copied to the docker container running QGis. This dataset, rich with global population distribution information, was then subjected to a series of complex spatial operations. These operations included spatial joins and aggregations, which were necessary to map population estimates to the corresponding administrative boundaries. Despite the robustness of this method, the entire process took thirty nine (39) days to complete. The sheer size of the datasets, coupled with the complexity of the spatial operations, meant that the database was constantly working at full capacity. This prolonged processing time posed a significant bottleneck, delaying critical processes for GeoPostcodes’ data operations teams. The Wherobots Solution: Hours Instead of Weeks This is where Wherobots came in. Leveraging the Wherobots  distributed computing platform, we were able to reduce the processing time from weeks to just hours—a drastic improvement that has far-reaching implications for geospatial data analysis. Here’s how we did it. The process began with ingesting the administrative units and the GHS population grid into WherobotsDB. We leverage Wherobots  Out-DB Rasters ,  RS_TileExplode() function, and repartitioning which allows more performant reading and workload distribution as only the required pixels for analysis are read and joined to the mapping units. From there, we partitioned  the administrative units for even distribution of the workload. This partitioning allowed us to perform spatial joins and aggregations in parallel, significantly speeding up the process. While a single machine working through these operations sequentially would take days, our distributed approach meant that each task was handled simultaneously across multiple nodes, drastically reducing the overall processing time. Results Looking at a subset of the results and comparing them to the runtime of the legacy system we can clearly see that leveraging Apache Sedona on Wherobots provides increased performance and dramatically reduced run time. CountryWherobotsRun Time (minutes)Legacy SystemRun Time (minutes)Zip Code CountSpeed ratioJapan362113,29120xRussia66117042,98418xSaudi Arabia312537,28244xUnited States678030,144135xGreat Britain22510,05910xFrance3236,0359xCosta Rica1144709x Looking Ahead: The Future of Geospatial Data This collaboration between Wherobots and GeoPostcodes is just the beginning. As we continue to push the boundaries of what’s possible with distributed computing and geospatial analysis, we’re excited about the future possibilities. On the horizon are even more advanced features and capabilities. Real-time data processing and machine learning integration are among the innovations we’re exploring, promising to make geospatial data analysis not just faster, but also smarter and more adaptive to changing conditions. Together, Wherobots and GeoPostcodes are setting a new standard for efficiency and precision in the world of geospatial data. Whether you’re in urban planning, Insurance, logistics, or any other industry that relies on this data, the future’s looking brighter—and faster—than ever before. Start building with Wherobots Get Started Frequently Asked Questions How long did GeoPostcodes population updates take before Wherobots? About 39 days, running spatial joins and aggregations on a dockerized headless QGIS instance together with a PostGIS warehouse. How fast is the Wherobots pipeline? The post says the collaboration turned nearly a month and a half of processing into a task completed in hours. Per-country examples include the United States in 6 minutes versus 780 minutes on the legacy system (135x). What data is being enriched? GeoPostcodes administrative and zip-code boundaries (247 countries, 15.9 million points, 880,000 polygons) are enriched with population estimates from the European Commission JRC Global Human Settlement 100-meter grid. Why was the Wherobots job faster? Administrative units and the GHS grid were ingested into WherobotsDB as out-DB rasters, tiled with RS_TileExplode(), and partitioned. Spatial joins and aggregations then ran in parallel across nodes instead of sequentially on one machine. --- ## Overture Data In Wherobots Spatial Data Catalog URL: https://wherobots.com/blog/overture-data-in-wherobots-spatial-data-catalog/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. The Overture Maps Foundation dataset is now Generally Available (GA), making efficient access to its vast open map data a top priority for developers, researchers, and organizations. In this blog post, we’ll explore how to seamlessly integrate and leverage Overture datasets within Wherobots, guiding you through creating some exciting visualizations. Key takeawaysOverture Maps Foundation data is generally available in the Havasu Catalog as Havasu Iceberg tables under wherobots_open_data.overture_maps_foundation, with Wherobots handling ingest as new Overture releases land.SHOW TABLES lists 16 tables spanning places, transportation, buildings, divisions, addresses, geocodes, and base themes (land, land use, land cover, water, infrastructure, bathymetry).A buildings subtype count in the post is led by residential at 107,898,149 features, then outbuilding, agricultural, and commercial.Overture’s GA addresses theme is still alpha, covering addresses from 14 countries, and is queryable as addresses_address. The post maps global and US address density with H3.A k-nearest-neighbor grocery accessibility example (ST_KNN, k=1, 1,000-meter buffer on places) finds most New York City addresses within 200 meters of a grocery store, while Austin generally requires a car. Spatial catalog The spatial catalog utilizes the open table format, Havasu Iceberg, which natively supports spatial types and enables performance optimization through spatial push-down and indexing. Havasu builds upon the solid foundation of Apache Iceberg, extending its capabilities to better serve geospatial data needs. As an enhancement of Iceberg tables, Havasu inherits all the benefits that make Iceberg a powerful choice for data management, such as schema evolution, time travel, and efficient metadata handling. Update: Great news for geospatial data users! As the Iceberg community plans to natively support GEO datatypes, we’ll be transitioning Havasu to Iceberg native in the near future. This means all Wherobots users can expect full compatibility between Havasu and the Iceberg V3 spec, including these new GEO datatypes. Wherobots aggregates open datasets from various sources, cleaning and transforming them into the Havasu Iceberg format. This process facilitates the integration of enterprise data with real-world physical information. Some premium datasets are available exclusively to our Pro Edition subscribers. For more detailed information about our open data offerings, please refer to the Wherobots Spatial Catalog. Overture datasets Wherobots includes the latest Overture Maps release in its spatial catalog, offering users direct access to this and other popular geospatial datasets. We handle all the configuration and pre-processing, ensuring you always have up-to-date Overture data as new releases become available. Overture organizes its datasets into distinct themes, each containing various types. The structure of these themes and types is as follows: Wherobots simplifies access to Overture data by seamlessly integrating it into the Wherobots Cloud platform. The raw Overture data is processed into Havasu Iceberg tables, making it readily available for analysis within the WherobotsDB environment. Users can leverage the power of spatial SQL queries within the Notebook experience to directly interact with and gain insights from these tables: from sedona.spark import * config = SedonaContext.builder().getOrCreate() sedona = SedonaContext.create(config) sedona.sql("SHOW TABLES IN wherobots_open_data.overture_maps_foundation").show(truncate=False) +------------------------+---------------------------+-----------+ |namespace |tableName |isTemporary| +------------------------+---------------------------+-----------+ |overture_maps_foundation|places_place |false | |overture_maps_foundation|transportation_segment |false | |overture_maps_foundation|transportation_connector |false | |overture_maps_foundation|buildings_building |false | |overture_maps_foundation|divisions_division_area |false | |overture_maps_foundation|buildings_building_part |false | |overture_maps_foundation|base_land_cover |false | |overture_maps_foundation|addresses_address |false | |overture_maps_foundation|base_land_use |false | |overture_maps_foundation|base_infrastructure |false | |overture_maps_foundation|divisions_division_boundary|false | |overture_maps_foundation|base_land |false | |overture_maps_foundation|geocodes |false | |overture_maps_foundation|base_water |false | |overture_maps_foundation|divisions_division |false | |overture_maps_foundation|base_bathymetry |false | +------------------------+---------------------------+-----------+ Each table is accessible through a simple, standardized command. Below is an example for a single table, but you can access other tables in the same manner: sedona.sql("SELECT * FROM wherobots_open_data.overture_maps_foundation.base_land_use").show() Here’s an example to work with the tables in the Overture catalog: sedona.sql(""" SELECT subtype, COUNT(subtype) AS count FROM wherobots_open_data.overture_maps_foundation.buildings_building GROUP BY subtype ORDER BY count DESC """).show(truncate=False) +--------------+---------+ |subtype |count | +--------------+---------+ |residential |107898149| |outbuilding |7696532 | |agricultural |4290701 | |commercial |4008648 | |industrial |3520833 | |education |1686603 | |religious |1077831 | |civic |1015775 | |service |833565 | |transportation|475667 | |medical |297068 | |entertainment |200166 | |military |43198 | |NULL |0 | +--------------+---------+ Overture has made a significant shift in how they distribute their datasets worldwide, adopting GeoParquet as their new format of choice. GeoParquet, an extension of the popular Parquet format, is specifically designed to handle geospatial data efficiently. Update: Good news for geospatial data! Alongside Iceberg, Apache Parquet now also supports GEO data types. We anticipate GeoParquet merging into the Parquet standard in time. To create these GeoParquet files, Overture leverages Apache Sedona, an open-source project that’s gaining traction in the geospatial community. If you’re curious about how Overture uses Apache Sedona, you can dive deeper into the details by clicking here. This move to GeoParquet isn’t just about keeping up with trends, it brings some real benefits. One of the key advantages of using GeoParquet is its ability to support spatial filter push-down. This means that when you’re querying the data, you’re not wasting time and resources sifting through irrelevant information. Instead, the system only reads the files that are relevant to your specific query. This can lead to significant performance improvements, especially when dealing with large-scale geospatial datasets. While GeoParquet is a step forward for geospatial data storage, Havasu Iceberg takes things even further. Unlike GeoParquet, which is essentially a file format, Havasu is a comprehensive table format. This means it can offer more advanced features like ACID transactions, which are crucial for maintaining data integrity in complex, multi-user environments. See this post on the benefits of Apache Iceberg for GEO datatypes. Havasu Iceberg enhances the developer experience compared to GeoParquet by abstracting file management complexities. It presents data as SQL tables, allowing for intuitive querying and manipulation using familiar operations. Havasu’s support for write operations, partitioning, and advanced features. This higher-level abstraction lets you focus on data analysis and application logic rather than low-level file handling, boosting productivity and easing maintenance. Overture, new theme Overture’s GA release introduces the “addresses” theme, which currently consists of a single type named “address”. This theme, still in its alpha stage, covers addresses from 14 countries. Due to its alpha status, the schema is subject to changes. The current schema structure is as follows: root |-- id: string (nullable = true) |-- geometry: geometry (nullable = true) |-- bbox: struct (nullable = true) | |-- xmin: float (nullable = true) | |-- xmax: float (nullable = true) | |-- ymin: float (nullable = true) | |-- ymax: float (nullable = true) |-- country: string (nullable = true) |-- postcode: string (nullable = true) |-- street: string (nullable = true) |-- number: string (nullable = true) |-- unit: string (nullable = true) |-- address_levels: array (nullable = true) | |-- element: struct (containsNull = true) | | |-- value: string (nullable = true) |-- postal_city: string (nullable = true) |-- version: integer (nullable = true) |-- sources: array (nullable = true) | |-- element: struct (containsNull = true) | | |-- property: string (nullable = true) | | |-- dataset: string (nullable = true) | | |-- record_id: string (nullable = true) | | |-- update_time: string (nullable = true) | | |-- confidence: double (nullable = true) Let’s look at a few examples to understand the new theme from Overture: Density of the address table This query first generates an H3 index for every Point, then groups data sharing the same H3 index to count occurrences. Finally, it adjusts polygon longitudes derived from these H3 indexes to ensure accurate visualization: address_h3 = sedona.sql(""" -- Generating H3 cells at zoom level 2 WITH address_ww AS ( SELECT *, ST_H3CellIDs(geometry, 2, false) as h3 FROM wherobots_open_data.overture_maps_foundation.addresses_address ), -- Generating polygons representing H3 indexes, group data by the H3 index, -- and counting how many data entries belong to each H3 index. address_h3 AS ( SELECT COUNT(*) AS num, ST_H3ToGeom(h3)[0] as geometry, h3 FROM address_ww GROUP BY h3 ORDER BY num DESC ) -- Finally shifting longitude for the polygons that cross the International Date Line SELECT num, h3, CASE WHEN ST_CrossesDateLine(geometry) = true THEN ST_ShiftLongitude(geometry) ELSE geometry END AS geometry FROM address_h3 """) We can now visualize this aggregated data as a choropleth map using SedonaKepler. North America has some missing values. Let’s take a closer look at addresses just in America: address_US = sedona.sql(""" WITH address_US AS ( SELECT *, ST_H3CellIDs(geometry, 3, false) as h3 FROM wherobots_open_data.overture_maps_foundation.addresses_address WHERE country = "US" ) SELECT COUNT(*) AS num, ST_H3ToGeom(h3)[0] as geometry, h3 FROM address_US GROUP BY h3 ORDER BY num DESC """) The visualization reveals gaps in data coverage, likely due to privacy regulations in certain states or the absence of addresses in specific areas: Analyzing Spatial Accessibility to Grocery Stores in Austin and New York City Using KNN In this analysis, we explore the spatial accessibility of grocery stores in two major cities: Austin, Texas, and New York City, New York. Using the latest release of Overture Maps Foundation’s dataset, we aim to measure and compare the distances between addresses and the nearest grocery stores in each city. The process leverages the power of our new K-nearest neighbors (KNN) algorithm to identify the closest grocery stores to each address. Why This Analysis Matters Accessibility to essential services like grocery stores is a crucial factor in urban planning, public health, and economic development. Understanding how far residents have to travel to reach a grocery store can reveal insights into the livability of different neighborhoods, the potential for food deserts, and the effectiveness of current infrastructure. For instance: Urban Planning: City planners can use this information to identify underserved areas where additional grocery stores or better transportation options might be needed. Public Health: Easy access to fresh food is linked to better health outcomes. Areas where residents have to travel long distances to reach a grocery store may be at a higher risk of being food deserts, contributing to poor dietary habits and related health issues. Economic Development: Retailers and businesses can use these insights to identify optimal locations for new grocery stores or services, ensuring they meet the needs of the community while also maximizing profitability. Data Preparation and Spatial Filtering We begin by loading the Overture Maps Foundation’s datasets for addresses and places. The places dataset contains various categories, including grocery stores, which are our primary focus. addresses_df = sedona.sql("SELECT * FROM wherobots_open_data.overture_maps_foundation.addresses_address") places_df = sedona.sql("SELECT * FROM wherobots_open_data.overture_maps_foundation.places_place") For each city, we define a geographic bounding box to filter out the relevant addresses and places. Additionally, we apply a 1000-meter buffer around the bounding box used for places to account for addresses near the edges of the bounding box, ensuring that all nearby places are considered for those edge bound addresses. Austin, Texas: austin_addresses = addresses_df.where("ST_Intersects(geometry, ST_GeomFromWKT('POLYGON ((-97.998275 30.045308, -97.998275 30.543325, -97.465501 30.543325, -97.465501 30.045308, -97.998275 30.045308))'))") austin_places = places_df.where("ST_Intersects(geometry, ST_Buffer(ST_GeomFromWKT('POLYGON ((-97.998275 30.045308, -97.998275 30.543325, -97.465501 30.543325, -97.465501 30.045308, -97.998275 30.045308))'), 1000, True))") New York City, New York: nyc_addresses = addresses_df.where("ST_Intersects(geometry, ST_GeomFromWKT('POLYGON ((-74.016067 40.566497, -73.943949 40.532062, -73.73584 40.581101, -73.735153 40.606128, -73.742708 40.612383, -73.737213 40.630625, -73.735153 40.667092, -73.720729 40.68584, -73.72279 40.71395, -73.717982 40.738928, -73.777049 40.791454, -73.790786 40.816402, -73.755071 40.850691, -73.744768 40.871982, -73.834743 40.896381, -73.838864 40.906761, -73.853974 40.910913, -73.86153 40.904685, -73.917163 40.919734, -73.962494 40.826795, -74.012689 40.754014, -74.025738 40.706143, -74.064201 40.653029, -74.092767 40.647822, -74.108564 40.647822, -74.125391 40.642351, -74.132259 40.643393, -74.181711 40.645998, -74.201973 40.631409, -74.20369 40.624634, -74.202316 40.617598, -74.201973 40.611343, -74.202316 40.606652, -74.197852 40.601178, -74.201286 40.593618, -74.206437 40.586318, -74.215709 40.559197, -74.231163 40.558414, -74.246617 40.549545, -74.250051 40.54198, -74.245587 40.520582, -74.254172 40.515101, -74.257606 40.508576, -74.258636 40.499178, -74.249708 40.493435, -74.227729 40.496306, -74.180338 40.50962, -74.130199 40.528672, -74.070101 40.577192, -74.016067 40.566497))'))") nyc_places = places_df.where("ST_Intersects(geometry, ST_Buffer(ST_GeomFromWKT('POLYGON ((-74.016067 40.566497, -73.943949 40.532062, -73.73584 40.581101, -73.735153 40.606128, -73.742708 40.612383, -73.737213 40.630625, -73.735153 40.667092, -73.720729 40.68584, -73.72279 40.71395, -73.717982 40.738928, -73.777049 40.791454, -73.790786 40.816402, -73.755071 40.850691, -73.744768 40.871982, -73.834743 40.896381, -73.838864 40.906761, -73.853974 40.910913, -73.86153 40.904685, -73.917163 40.919734, -73.962494 40.826795, -74.012689 40.754014, -74.025738 40.706143, -74.064201 40.653029, -74.092767 40.647822, -74.108564 40.647822, -74.125391 40.642351, -74.132259 40.643393, -74.181711 40.645998, -74.201973 40.631409, -74.20369 40.624634, -74.202316 40.617598, -74.201973 40.611343, -74.202316 40.606652, -74.197852 40.601178, -74.201286 40.593618, -74.206437 40.586318, -74.215709 40.559197, -74.231163 40.558414, -74.246617 40.549545, -74.250051 40.54198, -74.245587 40.520582, -74.254172 40.515101, -74.257606 40.508576, -74.258636 40.499178, -74.249708 40.493435, -74.227729 40.496306, -74.180338 40.50962, -74.130199 40.528672, -74.070101 40.577192, -74.016067 40.566497))'), 1000, True))") Filtering and Repartitioning Data Next, we filter out the grocery stores from the places dataset using the primary category field. This allows us to focus on the relevant data for our analysis. austin_groceries = austin_places.where(col("categories")['primary'] == "grocery_store").repartition(3) nyc_groceries = nyc_places.where(col("categories")['primary'] == "grocery_store").repartition(5) K-Nearest Neighbors (KNN) Spatial Join The core of our analysis is the K-nearest neighbors (KNN) algorithm, which we use to identify the nearest grocery store for each address. KNN is a powerful tool in spatial analysis, enabling us to efficiently find the closest points of interest (in this case, grocery stores) to each address. In this context, we perform a spatial join using ST_KNN to calculate the distance between each address and its nearest grocery store. This method ensures that we accurately capture the nearest grocery store for every address in both cities. austin_groceries_join = sedona.sql(''' SELECT austin_addresses.id AS address_id, austin_addresses.country AS address_country, austin_addresses.postcode AS address_postcode, austin_addresses.street AS address_street, austin_addresses.number AS address_number, austin_addresses.unit AS address_unit, austin_addresses.GEOMETRY AS address_GEOM, austin_groceries.id AS place_id, austin_groceries.names['primary'] AS place_name, austin_groceries.GEOMETRY AS place_GEOM, ST_DISTANCESPHERE(austin_addresses.GEOMETRY, austin_groceries.GEOMETRY) AS DISTANCE FROM austin_addresses JOIN austin_groceries ON ST_KNN(austin_addresses.GEOMETRY, austin_groceries.GEOMETRY, 1, FALSE) ''') nyc_groceries_join = sedona.sql(''' SELECT nyc_addresses.id AS address_id, nyc_addresses.country AS address_country, nyc_addresses.postcode AS address_postcode, nyc_addresses.street AS address_street, nyc_addresses.number AS address_number, nyc_addresses.unit AS address_unit, nyc_addresses.GEOMETRY AS address_GEOM, nyc_groceries.id AS place_id, nyc_groceries.names['primary'] AS place_name, nyc_groceries.GEOMETRY AS place_GEOM, ST_DISTANCESPHERE(nyc_addresses.GEOMETRY, nyc_groceries.GEOMETRY) AS DISTANCE FROM nyc_addresses JOIN nyc_groceries ON ST_KNN(nyc_addresses.GEOMETRY, nyc_groceries.GEOMETRY, 1, FALSE) ''') In this SQL query, the ST_KNN function is used to perform the KNN join, identifying the closest grocery store to each address. The ST_DISTANCESPHERE function then calculates the great-circle distance between the two points. Statistical Summary We calculate key statistical measures such as the mean, median, and standard deviation of the distances for both cities. These statistics provide insights into the city’s overall accessibility to grocery stores. austin_stats = austin_groceries_join.agg( F.mean("DISTANCE").alias("mean"), F.median("DISTANCE").alias("median"), F.stddev("DISTANCE").alias("stddev") ).collect()[0] nyc_stats = nyc_groceries_join.agg( F.mean("DISTANCE").alias("mean"), F.median("DISTANCE").alias("median"), F.stddev("DISTANCE").alias("stddev") ).collect()[0] A histogram of distances to the nearest grocery store for each of the cities reveals the stark difference in walkability to grocery stores between the 2 cities. Majority of Addresses in NYC are within 200m from a grocery store. Austin’s distribution is a bit more diverse and in general, automobiles are needed to reach the nearest grocery store. Wrapping up In line with Wherobots’ mission to democratize access to open data and facilitate analysis of our world, we’ve made Overture data even more accessible and user-friendly. By leveraging the scalable compute capabilities of Wherobots Cloud, you can now effortlessly explore and analyze this rich geospatial dataset. The combination of Overture’s comprehensive data and Wherobots’ powerful platform opens up a world of possibilities for further analysis. Imagine conducting walkability studies to assess pedestrian-friendliness, identifying optimal locations for new businesses based on proximity to key amenities, or even modeling traffic patterns to improve urban planning. Stay tuned for more exciting explorations into the world of geospatial data analysis with Wherobots and Overture! Subscribe to our newsletter to stay up-to-date with the latest content: Frequently Asked Questions How do I query Overture data in Wherobots? In a notebook, run SQL against tables such as wherobots_open_data.overture_maps_foundation.buildings_building. Wherobots converts Overture releases into Havasu Iceberg tables so you do not manage raw files. What is new in Overture’s addresses theme? The GA release adds an addresses theme with type address, still in alpha, covering 14 countries. Schema fields include geometry, bbox, country, postcode, street, number, unit, and sources. Does Havasu replace GeoParquet for Overture? Overture distributes GeoParquet for spatial filter push-down. Wherobots additionally materializes the data as Havasu Iceberg tables, which add ACID transactions, SQL table semantics, writes, and partitioning. The post also notes upcoming native Iceberg GEO types. What does the grocery accessibility example show? Using ST_KNN on Overture addresses and grocery places, most NYC addresses are within 200 meters of a grocery store, while Austin’s distance distribution is wider and typically needs a car. --- ## Pricing URL: https://wherobots.com/pricing/ Updated: 2026-10-03 Pricing Professional $0 to Start No licensing, just on-demand pricing 14 day free trial for up to $95 in usage For individual developers and teams building the next generation of solutions with spatial data Build local to planetary scale solutions from raster, vector, and tabular data Full product access during trial with lakehouse and cloud storage integrations Post trial, $95/month in prepaid usage credits with 90-day expiration. S3, Databricks Unity, AWS Glue catalog integrations Spatial AI coding tools RasterFlow Up to 10 users, SSO, MFA, audit logs, compute region control Community + email support Get $250 in credits for connecting Spatial AI coding tools. Contact us to qualify. + Add-on Premium Support $1,000/month 8×5 Priority Support (Slack or Teams) Learn more Start for free Innovation from $3000/MO Annual innovation delivery partnership Contact Sales for a proof of value Augment your engineering team with Wherobots spatial expertise. Everything in professional, support included Fractional, hands-on engineering support to accelerate innovation and develop competency Outcome-aligned engagements measured against your business KPIs, with quarterly outcome reviews 12 month+ contract required Bring Your Own Cloud — deploy the Wherobots compute plane in your own VPC Optional: Run WherobotsDB on your own Spark Clusters (Bring Your Own Spark | BYOS). Includes $3,000 / month in usage credits. Included Premium Support Contact Sales Enterprise Based on scale Volume based discounts Contact Sales For at-scale deployments with 24×7 production requirements. Everything in Innovation 99.5% SLA on Wherobots Cloud compute availability 24×7 Enterprise Support Unlimited users Run WherobotsDB on your own Spark Clusters (Bring Your Own Spark | BYOS) in air-gapped environments Included Enterprise Support Contact Sales * $1.50/SU pricing applies to US-East and US-West regions. View full regional pricing table ↗ Consumption based pricing WherobotsDB What is a WherobotsDB Spatial Unit? A WherobotsDB Spatial Unit is an amount of computational horsepower provisioned to a serverless runtime. A single SU provides similar capacity as a 32 vCPU Apache Sedona cluster running on the latest stable Apache Spark runtime, for one hour. Runtimes emit SUs at a rate set by their type and size, for as long as they run. For reference, an Amazon EC2 m7i.8xlarge on-demand instance with 32 vCPUs in AWS US West (Oregon) costs $1.61 per hour. Cloud region $ per WherobotsDB SU AWS US West (Oregon) $1.50 AWS US East (N. Virginia) $1.50 AWS US East (Ohio) $1.50 AWS EU West (Ireland) $1.67 AWS AP South (Mumbai) $1.58 RasterFlow (Public Preview) What is a RasterFlow Spatial Unit? RasterFlow uses a “pixels processed” billing model that enables you to determine costs upfront, with usage measured in spatial units. RasterFlow Spatial Units used = billions of pixels × bands × time periods × complexity factor for a particular task. Learn more about RasterFlow pricing. RasterFlow task $ per RasterFlow SU Mosaic Generation $0.75 Inference $1.50 Build Multiscales $0.25 Mosaic Vectorization $0.25 Each task is billed a minimum of 1 SU. RasterFlow currently runs in AWS US West (Oregon). Reach out to request support elsewhere. RasterFlow pricing may change during or after the public preview. RasterFlow (Public Preview) Predictable pricing that scales with your AOI Here are a few examples that show how to determine costs for a particular AOI and task. Generate geometries for every farm field in a state 150,000 km² AOI Sentinel-2 at 10 m 8 bands Model: Fields of the World Task Billion pixels / 1,000 km² × 1,000 km² × Bands × Complexity factor = SUs × Price / SU = Cost Cost / 1,000 km² Mosaic Generation 0.01 150 8 1.0× 12.00 $0.75 $9.00 $0.060 Inference · Fields of the World 0.01 150 8 0.2× 2.40 $1.50 $3.60 $0.024 Mosaic Vectorization 0.0.1 150 1 1.50 $0.25 $0.38 $0.0025 Total $12.98 $0.0865 Find every solar array across a city 500 km² AOI NAIP at 30 cm 3-4 bands Model: SAM3 Task Billion pixels / 1,000 km² × 1,000 km² × Bands × Complexity factor = SUs × Price / SU = Cost Cost / 1,000 km² Mosaic Generation 11.11 0.5 4 0.1× 2.22 $0.75 $1.67 $3.33 Inference · SAM3 11.11 0.5 3 1.0× 16.67 $1.50 $25.00 $50.00 Total $26.66 $53.33 Visualize tree canopy height across a county 2,500 km² AOI NAIP at 60 cm 3-4 bands Model: Meta CHM v1 Task Billion pixels / 1,000 km² × 1,000 km² × Bands × Complexity factor = SUs × Price / SU = Cost Cost / 1,000 km² Mosaic Generation 2.778 2.5 4 0.1× 2.78 $0.75 $2.08 $0.83 Inference · Meta CHM v1 2.778 2.5 3 1.0× 20.84 $1.50 $31.25 $12.50 Build Multiscales 2.778 2.5 1 6.95 $0.25 $1.74 $0.69 Total $35.07 $14.03 Each task is billed a minimum of 1 SU. Complexity factors vary per task and per model. Learn more Billion pixels / 1,000 km² is set by the dataset’s resolution (Sentinel-2 10 m: 0.01; NAIP 60 cm: 2.778; NAIP 30 cm: 11.11). You can see the costs of historical RasterFlow task runs in the workload history viewer. Compare plans Professional Innovation Enterprise PRICING Plans Professional Innovation Enterprise Price $95 monthly usage minimum $3,000/month Custom Free trial 14 days or $95 in credits — — Credit card required to start No No No Billing On-demand with $95 minimum invoiced monthly Annual Annual Designated Spatial Architect (named, partially shared) — Dedicated Spatial Architect — — Data Engineering Support (hands-on Wherobots data engineers) — PLATFORM Plans Professional Innovation Enterprise WherobotsDB — 300+ spatial functions All sizes All sizes All sizes RasterFlow — computer vision and perception engine (in private preview, contact us) Spatial AI coding assistant, MCP and CLI tools Hub — shared models, data, notebooks, and jobs DEVELOPER EXPERIENCE Plans Professional Innovation Enterprise Jupyter Notebooks, VS Code Extension, MCP Server, SQL Session API access Job Runs and Native Jobs Mapping tools (currently available in RasterFlow) DATA Plans Professional Innovation Enterprise Bring your own cloud storage S3, AWS Glue, Databricks Unity catalog integrations Hosted models (currently available in RasterFlow) Wherobots-hosted datasets DEPLOYMENT Plans Professional Innovation Enterprise Wherobots Cloud (managed, full platform) Bring Your Own Cloud — Wherobots compute plane in your VPC — WherobotsDB on your existing Spark (Bring Your Own Spark | BYOS) — — BYOS for disconnected / air-gapped environments — — SECURITY Plans Professional Innovation Enterprise SAML SSO Audit logs Data Residency Control with AWS Regions SUPPORT Plans Professional Innovation Enterprise Channels Community + email; dedicated Slack with Pro Support add-on Dedicated Slack/support channel with the Wherobots team Dedicated Slack/support channel with the Wherobots team Hours 8×5 best effort; 8×5 priority with Pro Support 8×5 with target response SLAs 24×7 Runtime availability SLA — — 99.5% contractual Users included Up to 10 Up to 50 Unlimited Frequently Asked Questions Wherobots FAQs How does the monthly usage minimum work? The monthly usage minimum starts when the free trial period expires. Customers pay $95 at the beginning of each monthly billing cycle moving forward, which provides $95 worth in usage credits that expire after 90 days. Credits are non-refundable, and the upfront payment for the usage minimum will recur monthly as long as the subscription to the Professional Edition is active and the subscription can be canceled at any time. This monthly minimum usage subscription provides access to the Professional Edition with additional support. Usage credits apply to both WherobotsDB SUs and RasterFlow SUs. Are there other costs? Data transfer and managed storage costs are free, including RasterFlow artifacts kept in Wherobots-managed storage. If we start to charge for it in the future, we will give you plenty of notice so you can confidently manage your costs. What does the free trial include? 14 days or $95 in usage credits, whichever comes first. During the trial you get full Professional access — all runtime sizes (General Purpose and Memory Optimized), Job Runs, full RasterFlow, S3 / Databricks Unity / AWS Glue integrations, MCP server, native visualizations, and SSO/MFA. What happens when the trial ends? If a valid payment method is on file, your organization moves automatically to the paid Professional plan ($95/month minimum). If not, compute is disabled and a banner appears with an ‘Add a payment method’ CTA. Your data, notebooks, catalogs, configurations, and users are preserved — only the ability to launch compute is paused. What is the Professional Support add-on? A $1,000/month flat-fee add-on for Professional customers who want higher-touch support without moving to Innovation or Enterprise. It includes a private Slack channel with priority response 8×5 (business hours) plus best-effort architectural guidance. The add-on does not include usage credits and is in addition to your normal $95/month minimum. Contact us to activate. What's the difference between Professional Support and Innovation? Professional Support ($1,000/month) buys you faster support: a private Slack channel, 8×5 priority response, and best-effort architectural guidance. Innovation ($3,000/month) embeds Wherobots experts alongside your team — a Designated Spatial Architect partnered with your team, hands-on Data Engineering Support, and outcome-aligned engagement measured against your business KPIs. What does Data Engineering Support cover? Hands-on work from Wherobots data engineers on your production spatial pipelines: building and tuning ingestion, transformation, and output workflows; performance optimization on production workloads; integrations with your data stack (catalogs, warehouses, BI tools); and the production plumbing that gates spatial outcomes. What does outcome-aligned engagement mean? At the start of your Innovation contract year we capture the business KPIs your spatial work needs to move. Quarterly outcome reviews open with what shipped against those KPIs, what’s blocking, and what the next quarter’s priorities are. Your Designated Spatial Architect’s engagement is shaped by your KPIs, not by support ticket volume. The engagement is the commitment; the quarterly review is the course-correction mechanism. Can I upgrade from Innovation to Enterprise mid-contract? Yes. Any unused commit on your Innovation contract applies forward to the Enterprise contract. Enterprise upgrades are typical when customers need a Dedicated (full-time embedded) Spatial Architect, BYOCloud, disconnected/air-gapped BYOS, a contractual SLA, or 24×7 support. WherobotsDB FAQs What are Wherobots runtimes? A runtime is a dedicated, distributed cluster of cloud-based virtual machines that you don’t need to manage. The amount of concurrent computing power available to your workloads on a runtime is measured in Spatial Units and is based on the type and size of the runtime. Visit our user documentation to learn more about the runtimes and the rate spatial units are emitted for each type by size. Can I run Wherobots on my own Spark infrastructure? On the Innovation and Enterprise tier, yes — where your infrastructure or data residency requires it, Bring Your Own Spark on your existing Spark (AWS EMR, Databricks, Google Dataproc, Microsoft Fabric, or self-managed) can be paired with Wherobots Cloud. BYOS provides a subset of Wherobots Cloud capabilities. For disconnected or air-gapped environments, the Enterprise tier is required. RasterFlow FAQs Is there a minimum charge for RasterFlow tasks? Yes. Each RasterFlow task is billed at least 1 Spatial Unit at that task’s price, no matter how small the area of interest. What if I cancel a RasterFlow task, or run the same task twice? A RasterFlow task cancelled after processing has started may be charged in full. A RasterFlow task that repeats an earlier task with identical inputs within the cache period (currently 7 days) returns the cached result and is not charged. Which regions support RasterFlow? RasterFlow currently runs in AWS US West (Oregon). Reach out to request support elsewhere. --- ## This Month in Apache Sedona: November Edition URL: https://wherobots.com/blog/this-month-in-apache-sedona-november-edition/ Updated: 2026-10-19 Apache Sedona has reached ⭐ 2M+ downloads ⭐ in the past month! What’s New in Apache Sedona 1.7.0 Our newest features include KNN Join, GeoStats and DataFrame-based readers. Learn more about the latest release in our most recent office hour. Key takeawaysThis November 2024 Apache Sedona newsletter is a community roundup, not a standalone technical deep dive.The issue says Apache Sedona reached 2 million+ downloads in the past month.Sedona 1.7.0 features highlighted here are kNN Join, GeoStats, and DataFrame-based readers, with links to office-hour slides.At the Spatial Data Science Conference in New York, Wherobots ran an insurance-risk workshop with CARTO and a GeoPostcodes session on population data that cut processing from weeks to days.Upcoming items: Cloud Native Geospatial Meetup on November 19, and AWS re:Invent December 2–6 (booth #1865, GeoParty December 4).The Raster Inference lightning talk at re:Invent is December 5 12:30–12:50 PM at Venetian Hall B Expo Theater 4. The Sedona office hour is December 10. You can can access the presentation slides here and the kNN Join slides here. Be sure to save the date for the next office hour to stay up-to-date with the latest releases! Latest Content What is Apache Sedona? Spatial data should be treated as a first class citizen. Here’s an overview of Apache Sedona and some of its common use cases. Learn more. Introducing GeoStats A machine learning and statistical toolbox for Wherobots and Apache Sedona users. Learn about its use cases and what challenges it helps solve. Read more. O’Reilly: Cloud-Native Geospatial Analytics with Apache Sedona Ideal for developers, data scientists and engineers, this hands-on guide provides practical solutions for challenges in working with various types of geospatial data. Get access here. Past Event Spatial Data Science Conference Wherobots attended the Spatial Data Science Conference in New York last month. Head of Marketing Ben Pruden and Senior Solution Architect Daniel Smith led a workshop on insurance risk analysis using Wherobots and CARTO. We also took the stage with GeoPostcodes to showcase how Apache Sedona on Wherobots Cloud can be leveraged to better understand population data, reducing processing times from weeks to days. During the meetup, we enjoyed some drinks and light bites while having a great time connecting with members of the Apache Sedona Community. We’re grateful for the opportunity to meet and learn from others in the geospatial data space, hearing about their use cases and how they’re leveraging these technologies. Upcoming Events Cloud Native Geospatial Meetup: GIS Week – November 19 Hear from an amazing lineup of speakers from the Google Maps and Google Earth teams, former ESRI and Wherobots. Topics include kNN Join, the origins of GIS Day, the history and future of cloud-native geospatial technology, and current work within the open source community. More details here. AWS re:Invent – December 2-6 Expo booth (all week): Swing by the booth #1865 to learn more about Wherobots and Apache Sedona. Grab some free SWAG and participate in our trivia to win some exciting raffle prizes! GeoParty (December 4): Join us for a geoparty at the Venetian Pool Deck! Enjoy drinks, light snacks, good music and networking with other professionals in the field. Space is limited and you must register to attend. RSVP here. Session: Extract insights from satellite imagery at scale with Wherobots (December 5 12:30PM-12:50PM) at Venetian Hall B Expo, Theater 4Learn>Learn how Wherobots Raster Inference enables data platform and science teams to analyze our planet with satellite imagery faster, more reliably, and with a zero carbon footprint—using SQL and Python. This fully managed, high-performance, carbon-neutral planetary-scale computer vision solution makes AI/ML on satellite imagery accessible to most developers and data scientists. Connect at re:Invent: If you’ll be at re:Invent and would like to set up a time to meet, feel free email us at reinvent@wherobots.com and we can find a time to connect. Apache Sedona Office Hour – December 10 We host monthly office hours as a way to engage with the community, share the latest updates and releases, along with future plans. If you’re working on something exciting with Apache Sedona, we’d love to hear about it. Save the date for the next office hour. Frequently Asked Questions What is in the November 2024 Apache Sedona newsletter? Download stats, Sedona 1.7.0 (kNN Join, GeoStats, DataFrame readers), a What is Apache Sedona overview, GeoStats, and an O’Reilly Sedona guide. It also has a Spatial Data Science Conference recap and upcoming meetup, re:Invent, and office-hour dates. How many Sedona downloads does this issue cite? It says Apache Sedona reached 2 million+ downloads in the past month. Where is Wherobots at AWS re:Invent in this newsletter? Expo booth #1865 all week, and a GeoParty on December 4 at the Venetian Pool Deck (registration required). A Raster Inference session runs on December 5 from 12:30–12:50 PM at Venetian Hall B Expo, Theater 4. What shipped in Apache Sedona 1.7.0 according to this post? kNN Join, GeoStats, and DataFrame-based readers, with office-hour slides linked from the newsletter. --- ## How to shift Apache Sedona on Spark workloads to WherobotsDB URL: https://wherobots.com/blog/shifting-apache-sedona-to-wherobotsdb/ Updated: 2026-10-19 Wherobots customers are realizing up to a 20x performance increase and significant cost savings by shifting their Apache Sedona workloads into Wherobots. This guide shows you how easy it is to migrate Apache Sedona workloads into WherobotsDB, and focuses on best practices for Apache Sedona migrations from Amazon EMR, AWS Glue, and Databricks. Key takeawaysCustomers cited here see up to a 20x performance increase and cost savings by moving Apache Sedona workloads into WherobotsDB. That includes jobs that currently run on Amazon EMR, AWS Glue, or Databricks.WherobotsDB is built on Apache Sedona and is 100% code-compatible, so existing spatial functions, joins, and scripts can be reused after pointing them at a Wherobots Sedona context.Data and models stay in public or private S3 via Wherobots storage integration (the post also points to SAML SSO setup in the docs).Migration pattern: validate logic in a Wherobots notebook on an appropriate runtime, package it as a Python script, and upload it to an integrated S3 bucket or Wherobots managed storage.Production runs use the Airflow WherobotsRunOperator (example Runtime.TINY plus an S3 URI) or the Job Runs API if you are not on Airflow. What You’ll Achieve: By following this guide, you’ll be able to: Lift and shift existing Apache Sedona workloads: Whether your Sedona jobs are currently running in AWS Glue, Databricks, or EMR, we’ll show you how to move them to WherobotsDB. Orchestrate job runs with Airflow: We’ve made it easy to redirect your existing code and execute it seamlessly on WherobotsDB using Airflow for job orchestration. Getting Started: This guide assumes you’ve already decided to migrate to Wherobots. We’ll focus on the technical steps in moving your workloads, empowering you to get up and running quickly. Storage Integration Wherobots makes it easy to run the models and scripts you already have in your public or private Amazon S3 buckets using Wherobots’ secure S3 storage integration. For step-by-step configuration instructions, see S3 Storage integration and SAML Single Sign On (SSO) setup in the official Wherobots documentation. Initializing Sedona Context within WherobotsDB When you’re ready to dive into spatial data analysis within WherobotsDB, your first order of business is creating a Sedona context object. This object acts as your gateway to the capabilities of the Wherobots Cloud ecosystem, enabling you to leverage its extensive spatial functions and tools. To ensure a smooth start, it’s essential to double-check that your Sedona environment is correctly configured within your Wherobots notebook. Pay close attention to the sedona and spark variables used to initialize the Sedona environment, ensuring they match your existing setup and preferences. This approach will help you avoid potential hiccups and ensure a seamless transition into the world of spatial analysis with WherobotsDB. from sedona.spark import * config = SedonaContext.builder()\ # add your Sedona/Spark configurations here in this format .config("", "")\ .getOrCreate() sedona = SedonaContext.create(config) This configuration provides the foundation for utilizing Sedona’s spatial functions within WherobotsDB, empowering you to perform advanced geospatial analysis with ease and efficiency. Move your business logic Workload migration can be daunting and disruptive. Fortunately, WherobotsDB is built on Apache Sedona and is 100% code-compatible, so you can migrate your workloads seamlessly. You’ll find all the familiar functions, joins, and features of Sedona, performance enhanced by WherobotsDB. Follow the steps below to seamlessly transfer your business logic to WherobotsDB: Identify Your Logic Validate Functionality Create a Python Script Redeploy code in your S3 bucket This diagram illustrates how your Sedona workloads will be integrated within the Wherobots ecosystem: Identify Your Logic Start by identifying an obvious component of your spatial workflow to migrate to WherobotsDB. Ensure you have all the supporting elements required for its functionality. This approach will streamline your transition to the WherobotsDB ecosystem. Validate Functionality After identifying the business logic you intend to shift, it’s important to validate its functionality within the WherobotsDB environment to ensure it performs as expected. This validation process ensures that your spatial operations, data transformations, and analytical processes produce the same accurate results you rely on. Test your code using WherobotsDB notebooks. Start by selecting a runtime for your notebook that aligns with the demands of your workload. Then, seamlessly transfer your business logic into the notebook environment. Execute your code and carefully validate the outputs, paying close attention to data counts and consistency with your expected results. This validation process ensures that your logic functions seamlessly within WherobotsDB. Create a Python Script With your validated code ready, it’s time to package it into a Python script. This involves simply creating a .py file and organizing your code. This step ensures your logic is portable and easily executed within the WherobotsDB environment. Redeploy code in your S3 bucket Now that your business logic is neatly packaged within a Python script, you need to make it accessible to Wherobots Airflow. To do this, you can upload it to an S3 bucket that’s integrated with your Wherobots environment. Another alternative is to upload it to our Managed Storage. This secure and integrated storage solution ensures your code is readily available for execution within the Wherobots ecosystem. Click here on how to upload to Managed Storage. Execute Sedona Code with Wherobots Airflow operator Wherobots provides an Airflow operator called the WherobotsRunOperator to simplify the integration of your code with the Job Runs API. This operator, designed for Apache Airflow, allows you to seamlessly trigger your Wherobots runs within your Airflow workflows. Before running your script, you’ll need to establish a connection to Wherobots in the Airflow Server and retrieve the S3 URI of your uploaded Python file. This URI serves as a reference to your code’s location, enabling the Wherobots Airflow operator to access and execute it. Here’s an example of how to use the WherobotsRunOperator to execute your Sedona code on WherobotsDB: import datetime import pendulum from airflow import DAG from airflow_providers_wherobots.operators.run import WherobotsRunOperator from wherobots.db.runtime import Runtime with DAG( dag_id="test_run_operator", schedule="@once", start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), catchup=False, tags=["example"], ) as test_run_dag: operator = WherobotsRunOperator( task_id="analysis_task", name="airflow_run_operator", runtime=Runtime.TINY, run_python={ "uri": "S3-URI-PATH-TO-YOUR-FILE", "args": "test_run=True" }, dag=test_run_dag, poll_logs=True, ) In this example, the WherobotsRunOperator takes the S3 URI of your Python file and executes it on a specified runtime environment Runtime.TINY. You can configure the Airflow to run your code on a schedule, pass arguments to your code, and monitor the execution logs. By utilizing the WherobotsRunOperator and the Job Runs API, you can seamlessly integrate your existing Sedona code into WherobotsDB and take advantage of its powerful geospatial capabilities. This approach ensures a smooth transition and allows you to focus on your spatial data analysis without worrying about infrastructure management or complex configurations. To learn more about the WherobotsRunOperator and its capabilities, refer to the Wherobots documentation. Alternative to Airflow operator If you don’t use Airflow, the Wherobots Jobs Runs API provides a convenient way to execute your code directly on WherobotsDB. Conclusion Migrating your spatial data workflows doesn’t have to be a complex endeavor. With this guide, you can easily transition from Apache Sedona on Spark, EMR, or Databricks and leverage WherobotsDB on Wherobots Cloud, a cloud-native data processing solution designed to make you more productive and your spatial workloads accelerate. Ready to simplify your spatial data analysis? Get started with Wherobots today. Explore the benefits of WherobotsDB. Connect with us for a demo or for help O'Reilly Book: Cloud Native Geospatial Analytics with Apache Sedona Get Access Frequently Asked Questions Do I have to rewrite Apache Sedona jobs for WherobotsDB? No. The post says WherobotsDB is 100% code-compatible with Apache Sedona. You initialize a SedonaContext, drop in existing Spark/Sedona config keys, and move the same business logic. Which platforms does this migration guide cover? Apache Sedona on Amazon EMR, AWS Glue, and Databricks, orchestrated with Airflow or the Wherobots Job Runs API. How do I schedule migrated jobs? Upload a .py script to S3, then trigger it with airflow_providers_wherobots.operators.run.WherobotsRunOperator (runtime, S3 URI, args, poll_logs) or call the Job Runs API directly. Where does the code read and write data after the move? Through Wherobots S3 storage integration against your existing buckets, or by uploading scripts to Wherobots managed storage. --- ## Introducing kNN Join for Wherobots and Apache Sedona URL: https://wherobots.com/blog/introducing-knn-join-for-wherobots-and-apache-sedona/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. TL;DR: WherobotsDB and Apache Sedona 1.7.0 introduce two types of kNN Join for large-scale geospatial workloads. The Exact kNN Join (ST_KNN) returns precise nearest neighbors and is best when accuracy is critical. The Approximate kNN Join (ST_AKNN) trades roughly 3-7% accuracy for significantly faster query times and lower cost. Both outperform PostGIS at scale, with PostGIS unable to complete joins at the 10M x 1B dataset size. Key takeawaysWherobotsDB and Apache Sedona 1.7.0 add two k-nearest-neighbor joins: Exact kNN (ST_KNN) for precise neighbors, and Approximate kNN (ST_AKNN) when speed and cost matter more.ST_AKNN is tested at about 3–7% less accurate than ST_KNN across varying data sizes, with Jaccard overlap also reported against the exact results.Both scale better than PostGIS kNN because they distribute horizontally. PostGIS could not complete the join at the 10 million × 1 billion dataset size in the benchmark.The post points to a ST_KNN / ST_AKNN example on 44 million geometries across five US states, and a tutorial joining weather events to ADS-B flights with k=4.Exact and Approximate kNN Joins are available to all Wherobots users, including Community Edition, via the python/wherobots-db/wherobots-db-knn-joins.ipynb notebook. We are excited to introduce the k-Nearest Neighbors Join (kNN Join) for WherobotsDB and Apache Sedona 1.7.0. With the kNN Join, you can efficiently find the closest entities to your points of interest from datasets at scale. We’ve released two types of kNN Joins: the Exact kNN Join and the Approximate kNN Join. With the Exact kNN Join you get precise results, but the additional precision adds cost and time to the query. The Exact kNN Join is useful when precise object proximity is critical. It is now available in WherobotsDB and will be available in Apache Sedona 1.7.0. The Approximate kNN Join delivers results faster and at a lower cost than the Exact kNN Join, and is tested to be ~3-7% less accurate than the Exact kNN Join for varying data sizes (more info below). The Approximate kNN Join, available now in WherobotsDB, is useful when performance matters more than accuracy, such as testing workloads or when query speed matters more than precision. Click here to launch this interactive notebook Launch Notebook When is the kNN Join useful? The kNN Join allows you to quickly find a chosen set (k) of nearest entities (objects) to your points of interest (queries). When Should You Use the Exact kNN Join The Exact kNN Join will efficiently identify the exact k closest objects to queries of interest. This makes it a highly useful algorithm when precise object proximity is crucial. Common applications of the Exact kNN Join at scale include: Reverse geocoding: Ride share services can use the Exact kNN Join to map high quantities of user tracking coordinates to street address for smooth rider pickups. Identifying nearest transit options: Map services can use the Exact kNN Join to accurately locate (or simulate) the closest public transit options for many people simultaneously. Analyzing the distribution of public services: City planners can use the Exact kNN Join to identify geographic areas without public services nearby to inform future development plans. Efficient freight routing: Shipping and cargo trucks can use the Exact kNN Join to locate exact locations of nearest refueling stations, ramps, marine life, etc. to create efficient routes and reduce time and cost. When Should You Use the Approximate kNN Join The Approximate kNN Join trades off accuracy for higher query speed. It will find a set of k close neighbors (but not necessarily the closest neighbors) to your query set. Some common applications of the Approximate kNN Join include: Local search: Map services use Approximate kNN Join to help users find places of interest within a certain distance of their geolocation. Image search: Geospatial modeling teams leverage Approximate kNN to find images for geographic points of interest to augment available data for model training. More importantly, the Approximate kNN Join unlocks kNN to be used for any compute or time constrained workloads, including: Testing: Teams developing geospatial workloads leverage the speed of the Approximate kNN Join to quickly test and iterate their pipelines. Meeting latency requirements: Teams use Approximate kNN Join to meet latency requirements and serve identified nearest neighbors at scale in production. Why Self-Hosting kNN Join Algorithms Is Harder Than It Looks Before, teams leveraging the kNN algorithm for geospatial workloads would have to: Determine how to host and scale general-purpose open source kNN solutions, including managing the curse of dimensionality, manage computational complexity that increases with data size, and preprocessing outlier data. Limit the frequency of executing kNN join workloads due to high time and compute costs. What You Gain by Using kNN Join in Wherobots or Apache Sedona Now with the kNN Join in Wherobots or Apache Sedona, you can: Leverage geospatially optimized kNN joins that scale efficiently with increasing data sizes without the overhead of building and maintaining your own solution. Iterate at a higher pace, by leveraging the Approximate kNN Join to trade-off performance versus accuracy. And, as your workload requires, run the Exact kNN Join to guarantee accurate neighbors for points of interest. See how ST_KNN and ST_AKNN perform at 44 million geometries across five US states. We’ll walk through a brief overview of the kNN Join, share how each perform at various scale, and how to use it. How kNN Join Works in WherobotsDB and Apache Sedona When used with geospatial data, the kNN Join identifies the k-nearest neighbors for a given spatial point or region based on geographic proximity. It involves two datasets: a query dataset containing points of interest, and an objects dataset, containing the entities you’re trying to locate near those points of interest. For each record in the queries dataset, the kNN Join finds the resulting set (k) of nearest neighbors from the objects dataset based on a user-defined distance metric and k value. For example, let’s say you’re interested in locating the three closest coffee shops to specific public transit stops in your neighborhood. The query dataset would be gps coordinates of the public transit stops. The objects dataset would be gps coordinates of all coffee shops in your neighborhood. As we’re looking for the three closest coffee shops, the k value is 3. We’ll say that our distance metric is three blocks. Using this as input, the kNN Join will conduct a search of the objects and return three coffee shops that are within three blocks of each of the public transit stops in your neighborhood.An illustration of kNN join. Using the example above, the red dots are the query dataset containing gps coordinates of the public transit stops. The green dots are the objects dataset containing gps coordinates of all coffee shops in your area. We want the 3-nearest coffee shops (k=3) to these public transit stops. Using kNN join, we find the closest coffee shops to the public transit stops. The query dataset and only their closest found neighbors are shown in the df_joined. kNN Join SQL API Overview We’ve made it easy to integrate the kNN Join into your workflows. Here is a quick overview of the kNN Join Spatial SQL APIs. For an in-depth look, see our docs here. Exact kNN Join  Supported GeometriesHyperparametersOutputSQL APIExact kNN Joinpoints, geometriesnumber of nearest neighbors to identify (k)dataframe with k nearest neighbors per query ranked by distanceST_KNN(...) Exact_kNN_Join_Results = ST_KNN(WEATHER.GEOMETRY, FLIGHTS.GEOMETRY, 4, FALSE) Approximate kNN Join  Supported GeometriesHyperparametersOutputSQL APIApproximate kNN Joinpoints, geometriesnumber of nearest neighbors to identify (k)dataframe with k nearest neighbors per query ranked by distanceST_AKNN(...) Approximate_kNN_Join_Results = ST_AKNN(WEATHER.GEOMETRY, FLIGHTS.GEOMETRY, 4, FALSE) kNN Join Performance Benchmarks: Wherobots vs PostGIS We’ll compare how the Exact and Approximate kNN Joins perform vs PostGIS, and how the Approximate kNN Join performs against the Exact kNN Join. kNN Join vs PostGIS Let’s look at some performance benchmarks for the Exact and Approximate kNN Joins compared to PostGIS’s exact kNN join algorithm. The following benchmarks are based on measured wall clock time for each join on varying data sizes. Each data size is defined by the query data size and the object data size, so a query set of 1M records and a object set of 12M records is described as 1M x 12M in the graph below. To compare scale and performance, we avoid compute comparisons across options by normalizing on cost per hour for each join. As seen below, the Approximate and Exact kNN Joins scale better than PostGIS with increasing dataset sizes. A key limitation of PostGIS’s exact kNN join is its inability to scale horizontally across machines, which is why performance with large scale exact kNN joins is better with Wherobots. Meanwhile, the Exact and Approximate kNN Joins distribute the join horizontally across workers and process larger datasets more efficiently. Specifically, the Approximate kNN Join is more performant and efficient at cost per workload than PostGIS and Exact kNN Join. Meanwhile, the Exact kNN Join is more effective for larger workloads than PostGIS, with PostGIS unable to complete the join for the 10M x 1B data size. Approximate vs Exact KNN Join Benchmarks Let’s look at some performance benchmarks to help you choose which kNN Join is right for a given workload. We’ve chosen a variety of metrics to evaluate the accuracy of the Approximate kNN Join. Accuracy: Measures the percentage of the Approximate kNN Join results that are the closest objects to queries. Jaccard Index: Measures the overlap between the Approximate kNN Join results and the Exact kNN Join results. Let’s take a look at wall clock time for the Approximate kNN Join versus Exact kNN Join for increasing data sizes. Let’s take a look at accuracy and Jaccard scores for the Approximate kNN Join for increasing data sizes. As seen above, the Approximate kNN Join will run faster than the Exact kNN Join for datasets of varying size, is highly accurate, and identifies highly similar sets of nearest neighbors as the Exact KNN Join, even for increasing dataset sizes. We recommend leveraging the Approximate kNN Join whenever you’re workloads allow for less precision, are cost constrained, or require high performance. Tutorial: How to Run kNN Join on Weather and Flight Data in WherobotsDB The following example details how to apply the Exact and Approximate kNN Joins on weather events data to find which flights are closest to each weather event, which can be crucial for making real-time decisions in air traffic management and ensuring flight safety. We will load this weather data from the Wherobots Spatial Catalog. The Spatial Catalog includes a collection of Wherobots maintained open datasets from various data sources like Overture Maps, LandSAT, Wild Fires, New York Taxi Data, and more. These datasets are optimized for fast and efficient analytics with WherobotsDB. The queries table contains the locations of weather events, such as storms or turbulence, while the objects table contains flight locations. Visit the user documentation for a full walk through of both kNN joins. 1. Preparing the Weather Events Data as Queries DataFrame First, we load the weather events data from the Spatial Data Catalog. Then, we assign a monotonically increasing ID to each row in the weather events, and load it to a temporary view so we can use in the SQL. df_queries = sedona.table("wherobots_pro_data.weather.weather_events") df_queries = df_queries.withColumn("id", monotonically_increasing_id()) df_queries.createOrReplaceTempView("weather") df_queries.select("id", "geometry", "type").show(20, False) The weather queries events DataFrame looks like this: +-------+-------------------------+----+ |id |geometry |type| +-------+-------------------------+----+ |2716677|POINT (-110.974 41.8191) |Snow| |2656934|POINT (-109.4604 41.5323)|Snow| |2653971|POINT (-109.0528 41.5945)|Rain| |2519252|POINT (-105.0333 42.45) |Rain| |2480600|POINT (-105.5419 44.3394)|Snow| +-------+-------------------------+----+ only showing top 5 rows 2. Preparing the Flights Data as Objects DataFrame We are using the flights tracking data from ABS-B flight observation data. This data originated from ADSB.lol, which provides publicly available daily updates of crowdsourced flight tracking data. df_objects = sedona.read.format("geoparquet").load("s3a://wherobots-examples/data/examples/flights/2024_s2.parquet") df_objects.createOrReplaceTempView("flights") The flights objects DataFrame looks like this: +---------------------------+-----------------------------+-------------------+ |desc |geometry |timestamp | +---------------------------+-----------------------------+-------------------+ |BOEING 737-800 |POINT (-110.232108 43.929066)|2024-01-11 00:00:00| |CESSNA 240 CORVALIS TTX |POINT (-110.852247 43.765574)|2024-01-01 00:00:00| |CESSNA 172 SKYHAWK |POINT (-108.790218 44.801926)|2024-01-23 00:00:00| |CESSNA 510 CITATION MUSTANG|POINT (-110.795842 43.518448)|2024-01-26 00:00:00| |BOEING 737-800 |POINT (-110.873321 43.079086)|2024-01-18 00:00:00| +---------------------------+-----------------------------+-------------------+ only showing top 5 rows 3. Run the kNN Join Once the two datasets are loaded, we can use the following SQL to run the kNN Joins. The query below runs the Exact kNN Join with the number of neighbors set to 4. df_knn_join = sedona.sql(""" SELECT WEATHER.GEOMETRY AS WEATHER_GEOM, FLIGHTS.GEOMETRY AS FLIGHTS_GEOM FROM WEATHER JOIN FLIGHTS ON ST_KNN(WEATHER.GEOMETRY, FLIGHTS.GEOMETRY, 4, FALSE) """) You can also run the Approximate kNN Join with number of neighbors set to 4, and add UDFs to the result DataFrame as following. df_knn_join = sedona.sql(""" SELECT WEATHER.GEOMETRY AS WEATHER_GEOM, WEATHER.ID AS QID, FLIGHTS.GEOMETRY AS FLIGHTS_GEOM, ST_DISTANCESPHERE(WEATHER.GEOMETRY, FLIGHTS.GEOMETRY) AS DISTANCE, ST_MAKELINE(WEATHER.GEOMETRY, FLIGHTS.GEOMETRY) AS LINE FROM WEATHER JOIN FLIGHTS ON ST_AKNN(WEATHER.GEOMETRY, FLIGHTS.GEOMETRY, 4, FALSE) """) The joined DataFrame looks like the following for a single query point. +-------+-------------------------+-----------------------------+-----------------+ |QID |QUERIES_GEOM |OBJECTS_GEOM |DISTANCE | +-------+-------------------------+-----------------------------+-----------------+ |2804966|POINT (-110.4211 44.5444)|POINT (-110.425023 44.544205)|311.6515627672718| |2804966|POINT (-110.4211 44.5444)|POINT (-110.416483 44.546535)|436.1578754802839| |2804966|POINT (-110.4211 44.5444)|POINT (-110.428809 44.546302)|646.4967456258582| |2804966|POINT (-110.4211 44.5444)|POINT (-110.415679 44.550445)|797.7249421529948| +-------+-------------------------+-----------------------------+-----------------+ only showing top 4 rows+-------+-------------------------+-----------------------------+-----------------+ |QID |QUERIES_GEOM |OBJECTS_GEOM |DISTANCE | +-------+-------------------------+-----------------------------+-----------------+ |2804966|POINT (-110.4211 44.5444)|POINT (-110.425023 44.544205)|311.6515627672718| |2804966|POINT (-110.4211 44.5444)|POINT (-110.416483 44.546535)|436.1578754802839| |2804966|POINT (-110.4211 44.5444)|POINT (-110.428809 44.546302)|646.4967456258582| |2804966|POINT (-110.4211 44.5444)|POINT (-110.415679 44.550445)|797.7249421529948| +-------+-------------------------+-----------------------------+-----------------+ only showing top 4 rows 4. Visualize the kNN Join Results We can also visualize the Exact kNN Join results using SedonaKepler by adding the joined DataFrame to a map. # create map for the results map_view = SedonaKepler.create_map(df_unique_qid.select('QUERIES_GEOM'), name="WEATHER EVENTS") SedonaKepler.add_df(map_view, df=df_related_rows.select('OBJECTS_GEOM', 'DISTANCE').withColumnRenamed("OBJECTS_GEOM", "geometry"), name="FLIGHTS") SedonaKepler.add_df(map_view, df=df_related_rows.select('LINE', 'DISTANCE').withColumnRenamed("LINE", "geometry"), name="KNN LINES") # show the map map_view Below we see a portion of the map we generated above. In this portion of the map, we see the results of the Exact kNN Join. Given our distance requirement between a weather event and flight (the lines), for each of the weather events from our query database (blue dots), we see the 4 closest flights to each weather event (yellow dots) . Get started with the Wherobots kNN Join Wherobots Users All Wherobots users have access to the Exact and Approximate kNN Joins. If you haven’t already, create a free Wherobots organization subscribed to the Community Edition of Wherobots. Start a Wherobots Notebook In the Notebook environment, explore the python/wherobots-db/wherobots-db-knn-joins.ipynb example that you can use to get started. Need additional help? Check out our user documentation, and send us a note if needed at support@wherobots.com. What’s next We’re excited to hear what algorithms you’d like us to support. We can’t wait for your feedback and to see what you’ll create! Start building with Wherobots Get Started Frequently Asked Questions What is a kNN Join in Wherobots and Apache Sedona? For every record in a query dataset, it finds the k nearest geometries in an objects dataset. Exact kNN uses ST_KNN; Approximate kNN uses ST_AKNN. Both support points and other geometries and return neighbors ranked by distance. When should I use ST_AKNN instead of ST_KNN? Use Approximate kNN for testing, latency-sensitive serving, or cost-constrained workloads. The post measures it as roughly 3–7% less accurate than Exact kNN while running faster at every tested scale. How does kNN Join compare to PostGIS in this benchmark? Approximate and Exact kNN Joins scale better than PostGIS as dataset size grows. PostGIS could not finish the 10 million × 1 billion join; Wherobots completed it. Cost is compared on a normalized cost-per-hour basis. Which Sedona version includes Exact kNN Join? Exact kNN Join is in WherobotsDB now and in Apache Sedona 1.7.0. Approximate kNN Join is described as available in WherobotsDB. --- ## AWS re:Invent Happy Hour URL: https://wherobots.com/reinvent-geo-party/ Updated: 2026-07-13 Geo Party at AWS re:Invent Wednesday, December 4 6:00 PM – 9:00 PM Palazzo Pool Deck, 3rd Floor (CAPRI Pool Restaurant & Bar) Save your spot Calling all geospatial data teams at Re:Invent!🍸🍹 Join us for a special geospatial party Wednesday evening at the Venetian Pool Deck! Hosted by Wherobots (the original creators of Apache Sedona) and CARTO (Location Intelligence Platform for Spatial Analytics), connect with like-minded professionals who are working at the forefront of cloud native spatial data engineering and data science. Enjoy drinks, small bites, good music, networking and insights into the latest tools and innovations in the field. Whether you’re exploring and processing geospatial data, or looking for ways to implement GeoAI and ML models to get planetary-scale insights, this event is the perfect opportunity to share ideas and expand your network! Spots are limited and by confirmation only. Be sure to RSVP and save your spot! RSVP Here Completing this form does not guarantee a spot, as entry is by confirmation only. Please look out for an email from us. --- ## Introducing GeoStats for Wherobots and Apache Sedona URL: https://wherobots.com/blog/introducing-geostats/ Updated: 2026-10-19 Introducing GeoStats for Wherobots and Apache Sedona We are excited to introduce GeoStats, a machine learning (ML) and statistical toolbox for Wherobots and Apache Sedona users. With GeoStats, you can easily identify critical patterns in geospatial datasets such as hotspots and anomalies, and quickly get critical insights from large scale data. While these algorithms are supported in other packages, we’ve optimized each algorithm to be highly performant for small to planetary scale geospatial workloads. That means, you can get results from these algorithms significantly faster, at a lower cost, and do it all more productively, through a unified development experience purpose-built for geospatial data science and ETL. Key takeawaysGeoStats is a machine-learning and statistics toolbox for Wherobots and Apache Sedona, with DBSCAN clustering, Local Outlier Factor (LOF) anomaly detection, and Getis-Ord Gi* hot/cold spots.Apache Sedona users get DBSCAN starting in Sedona 1.7.0; the Wherobots toolbox includes all three algorithms and stays Sedona-compatible.On a Large Wherobots runtime, DBSCAN on a growing European Overture buildings sample (epsilon 0.005 degrees, about 30 feet, min_points 4) processed 100 million records in 1.6 hours.LOF on the same buildings progression with k=20 processed 100 million records in 10 minutes on a Large runtime.Gi* with binary neighbor weights and a 0.007-degree (about 0.5 mile) radius processed 100 million records in 1.6 hours on a Large runtime, scaling mostly linearly. The Wherobots toolbox supports DBSCAN, Local Outlier Factor (LOF), and Getis-Ord (Gi*) algorithms. Apache Sedona users can utilize DBSCAN starting with Apache Sedona version 1.7.0, and like all other features of Apache Sedona, its fully compatible with Wherobots. Use Cases for GeoStats DBSCAN DBSCAN is the most popular algorithm we see in geospatial use cases. It identifies clusters, areas of your data that are closely packed together, and outliers, areas of your data that are set apart. Typical use cases for DBSCAN are found in: Retail: Decision makers use DBSCAN with location data to understand areas of high and low pedestrian activity to decide where to setup retailing establishments. City Planning: City planners use DBSCAN with GPS data to optimize transit support by identifying high usage routes, areas in need of additional transit options, or areas that have too much support. Air Traffic Control: Traffic controllers use DBSCAN to identify areas with increasing weather activity to optimize flight routing. Risk computation: Insurers and others can use DBSCAN to make policy decisions and calculate risk where risk is correlated to the proximity of two or more features of interest. Local Outlier Factor (LOF) LOF is an anomaly detection algorithm that identifies outliers present in a dataset. Typical use cases for LOF include: Data analysis and cleansing: Data teams can use LOF to identify and remove anomalies within a dataset, like removing erroneous GPS data points from a trace dataset Getis-Ord (Gi*) Getis-Ord is also a popular algorithm for identifying local hot and cold spots. Typical use cases for Gi* include: Public health: Officials can use disease data with Gi* to identify areas of abnormal disease outbreak Telecommunications: Network administrators can use Gi* to identify areas of high demand and optimize network deployment Insurance: Insurers can identify areas prone to specific claims to better manage risk Click here to launch this interactive notebook Launch Notebook Traditional challenges with using these algorithms on geospatial data Before GeoStats, teams leveraging any of the algorithms in the toolbox in a data analysis or ML pipeline would: Struggle to get performance or scale from the underlying solutions that also don’t perform well when joining geospatial data. Determine how to host and scale open source versions of popular ML and statistical algorithms, like PostGIS or scikit-learn DBSCAN, PySal Gi*, or scikit-learn LOF, to work for geospatial data types and geospatial data formats. Replicate this overhead each time they want to deploy a new algorithm for geospatial data. Benefits of Wherobots GeoStats With GeoStats in Wherobots, you can now: Easily run native algorithms on a cloud-based engine, optimized for producing spatial data products and insights at scale. Use these algorithms without the operational overhead associated with setup and maintenance. Leverage optimized, hosted algorithms within a single platform to easily experiment and get critical insights faster. We’ll walk through a brief overview of each algorithm, how to use them, and show how they perform at various scales. Diving Deeper into the GeoStats Toolbox DBSCAN Overview DBSCAN is a density-based clustering algorithm. Given a set of points in some space, it groups points with many nearby neighbors and marks as outlier points that lie alone in low-density regions. How to use DBSCAN in Wherobots The following examples assume you have already setup an organization and have an active runtime and notebook, with a dataframe of interest to run the algorithms on. Wherobots GeoStats DBSCAN Python API OverviewFor a full walk through see the Python API reference: dbscan(...). Supported Geometries: points, linestrings, polygons Hyperparameters: max distance to neighbors (epsilon), min neighbors (min_points) Output: dataframe with cluster id DBSCAN Walk Through Choose your dataset and create a Sedona DataFrame. dataset=sedona.createDataFrame(X).select(ST_MakePoint("_1", "_2").alias("geometry")) Choose values for your hyperparameters, max distance to neighbors (epsilon) and minimum neighbors (min_points). These values will determine how DBSCAN identifies clusters. epsilon=0.3 min_points=10 Run DBSCAN on your DataFrame with your chosen hyperparameter values. clusters_df = dbscan(df, epsilon=0.3, min_points=10, include_outliers=True) Analyze the results. For each datapoint, DBSCAN returns the cluster it’s associated with or if it’s an outlier. +--------------------+------+-------+ | geometry|isCore|cluster| +--------------------+------+-------+ |POINT (1.22185277...| false| 1| |POINT (0.77885034...| false| 1| |POINT (-2.2744742...| false| 2| +--------------------+------+-------+ only showing top 3 rows There’s a complete example of how to use DBSCAN in the Wherobots user documentation. DBSCAN Performance Overview To show DBSCAN performance in Wherobots, we created a European sample of the Overture buildings dataset, and ran DBSCAN to identify clusters of buildings near each other, starting from the geographic center of Europe and worked outwards. For each subsampled dataset, we run DBSCAN with an epsilon of 0.005 degrees (i.e. ~30 feet) and min_points value of 4 on a Large runtime in Wherobots Cloud. As seen below, DBSCAN effectively processes an increasing number of records, with 100M records taking 1.6 hrs to process. Local Outlier Factor (LOF) LOF is an anomaly detection algorithms that identifies outliers present in a dataset. It does this by measuring how close a given data point is to a set of k-nearest neighbors (with k being a user chosen hyperparameter) in comparison to how close its nearest neighbors are to their nearest neighbors. LOF provides a score that represents the degree to which a record is an inlier or outlier. How to use LOF in Wherobots For the full example, please see this docs page. Wherobots GeoStats LOF Python API OverviewFor a full walk through see the Python API reference: local_outlier_factor(...). Supported Geometries: points, linestrings, polygons Hyperparameters: number of nearest neighbors to use Output: score representing degree of inlier or outlier LOF Walk Through Choose your dataset and create a Sedona DataFrame. df = sedona.createDataFrame(X).select(ST_MakePoint(f.col("_1"), f.col("_2")).alias("geometry")) Choose your k value for how many nearest neighbors you want to use to measure density near a given datapoint. k=20 Run LOF on your DataFrame with your chosen k value. outliers_df = local_outlier_factor(df, k=20) Analyze your results. LOF returns a score for each datapoint representing the degree of inlier or outlier. +--------------------+------------------+ | geometry| lof| +--------------------+------------------+ |POINT (-1.9169927...|0.9991534865548664| |POINT (-1.7562422...|1.1370318880088373| |POINT (-2.0107478...|1.1533763384772193| +--------------------+------------------+ only showing top 3 rows There’s a complete example of how to use LOF in the Wherobots user documentation. LOF Performance Overview We followed the same procedure with DBSCAN but ran LOF to identify clusters of buildings near each other. With each set of buildings we ran LOF with a k=20 on a large Wherobots Cloud runtime. As seen below, GeoStats LOF scales effectively with growing data size with 100M records taking 10 mins to process. Getis-Ord (Gi*) Overview Getis-Ord is an algorithm for identifying statistically significant local hot and cold spots. How to use GeoStats Gi* Wherobots GeoStats Gi* Python API OverviewFor the full example, please see this docs g_local(...). Supported Geometries: points, linestrings, polygons Hyperparameters: star, neighbor weighting Output: Set of statistics that indicate the degree of local hot or cold spot for a given record Gi* Walk Through Choose your dataset and create a Sedona Dataframe. places_df = ( sedona.table("wherobots_open_data.overture_2024_07_22.places_place") .select(f.col("geometry"), f.col("categories")) .withColumn("h3Cell", ST_H3CellIDs(f.col("geometry"), h3_zoom_level, False)[0]) ) Choose how you’d like to weight datapoints (ex: datapoints in a specific geographic area need to be weighted higher or any datapoint close to a given datapoint need to be weighted higher) and star (boolean to indicate if a record is a neighbor of itself). star = True neighbor_search_radius_degrees = 1.0 variable_column = "myNumericColumnName" weighted_dataframe = add_binary_distance_band_column( df, neighbor_search_radius_degrees, include_self=star ) Run Gi* on your DataFrame with your chosen hyperparameters. gi_df = g_local( weighted_dataframe, variable_column, star=star ) Analyze your results. For each datapoint, Gi* returns a set of statistics that indicate the degree of local hot or cold spot. +----------+-------------------+--------------------+--------------------+------------------+--------------------+ |num_places| G| EG| VG| Z| P| +----------+-------------------+--------------------+--------------------+------------------+--------------------+ | 871| 0.1397485091609774|0.013219284603421462|5.542296862370928E-5|16.995969941572465| 0.0| | 908|0.16097739240211956|0.013219284603421462|5.542296862370928E-5|19.847528249317246| 0.0| | 218|0.11812096144582315|0.013219284603421462|5.542296862370928E-5|14.090861243071908| 0.0| +----------+-------------------+--------------------+--------------------+------------------+--------------------+ only showing top 3 rows There’s a complete example of how to use Gi* in the Wherobots user documentation. Getis-Ord Performance Overview To showcase how Gi performs in Wherobots, again we used the same example as DBSCAN, but ran Gi on the area of the buildings. With each set of buildings we ran Gi* with a binary neighbor weight and a neighborhood radius of .007 degrees (~0.5 miles) on a Large runtime in Wherobots Cloud. As seen below, the algorithm scales mostly linearly with the number of records, with 100M records taking 1.6 hours to process. Get started with Wherobots GeoStats The way we implemented these algorithms for large scale geospatial workloads, will help you make sense of your geospatial data faster. You can get started for free today. If you haven’t already, create a free Wherobots Organization subscribed to the Community Edition of Wherobots. Start a Wherobots Notebook In the Notebook environment, explore the notebook_example/python/wherobots-ai/ folder for examples that you can use to get started. Need additional help? Check out our user documentation, and send us a note if needed at support@wherobots.com. Apache Sedona Users Apache Sedona users will have access to GeoStats DBSCAN with the Apache Sedona 1.7.0 release. Subscribe to the Spatial Intelligence Newsletter and join the Sedona community to get notified of the release and get started! What’s next We’re excited to hear what ML and statistical algorithms you’d like us to support. We can’t wait for your feedback and to see what you’ll create! Start building with Wherobots Access Here Frequently Asked Questions What is GeoStats? GeoStats is Wherobots’ hosted ML/stats toolbox for geospatial data, optimized from small to planetary scale. It covers DBSCAN (clusters and outliers), Local Outlier Factor (anomaly scores), and Getis-Ord Gi* (local hot and cold spots). Is GeoStats available in open-source Apache Sedona? DBSCAN is available to Apache Sedona users starting with Sedona 1.7.0. LOF and Gi* are described here as part of the Wherobots toolbox. How fast is GeoStats DBSCAN at 100 million records? On a Large Wherobots Cloud runtime, DBSCAN on European Overture buildings with epsilon 0.005 degrees and min_points 4 took 1.6 hours for 100 million records. What geometries do these algorithms accept? The Python APIs listed for DBSCAN, LOF, and Gi* all support points, linestrings, and polygons. --- ## What is Apache Sedona? URL: https://wherobots.com/blog/what-is-apache-sedona/ Updated: 2026-10-19 Last Updated: June 2026 Apache Sedona is an open-source cluster computing system built for processing large-scale spatial data across distributed environments. Originally developed at Arizona State University under the name GeoSpark, in the paper “Spatial Data Management in Apache Spark: The GeoSpark Perspective and Beyond” by Jia Yu and Mohamed Sarwat, it is now a top-level Apache Software Foundation project used by organizations across transportation, logistics, environmental monitoring, insurance, and urban planning. This page covers what Apache Sedona is, how it processes spatial queries, common use cases, and how to get started. Key takeawaysApache Sedona is an open-source cluster computing system for processing large-scale spatial data. It started as GeoSpark at Arizona State University (Jia Yu and Mohamed Sarwat) and is now a top-level Apache Software Foundation project.Apache Sedona extends Apache Spark, Apache Flink, and Snowflake with spatial types, operations, and indexing, and supports Python, Scala, Java, R, and SQL.It ingests Shapefiles, GeoJSON, GeoTiff, Parquet, and CSV into Spatial DataFrames. It then uses R-trees or quad-trees and a query optimizer to run spatial joins, distance calculations, and aggregations across a cluster.Common Apache Sedona use cases are geospatial ETL: national-scale environmental reports, planetary GeoParquet generation, converting billions of telemetry points into vehicle routes, and parcel enrichment for real estate analysis.Apache Sedona has over 80 million downloads and more than 100 individual contributors, with adoption in transportation, logistics, environmental monitoring, insurance, and urban planning. Comcast cut a geospatial ETL job from 5 hours to 30 minutes. What is Apache Sedona and How Does It Work Apache Sedona treats spatial data as a first-class citizen by extending distributed compute frameworks including Apache Spark, Apache Flink, and Snowflake with specialized data types, spatial operations, and indexing techniques optimized for spatial workloads. Unlike general-purpose compute frameworks, Sedona is purpose-built for the unique challenges of spatial data, including complex geometries, coordinate systems, and spatial relationships that standard data types cannot handle efficiently. The following section outlines how Apache Sedona processes spatial queries from data ingestion through to distributed execution. What Programming Languages Does Apache Sedona Support Apache Sedona supports multiple programming languages, including Python, Scala, Java, R, and SQL, making it accessible to a wide range of data engineering and analytics workflows. Developers can interact with Apache Sedona through whichever language fits their existing stack. On the integrations side, Apache Sedona runs on Apache Spark, Apache Flink, and Snowflake. Each runtime serves a different need: Apache Spark for large-scale distributed batch processing, Apache Flink for real-time streaming spatial analytics, and Snowflake for teams running spatial workloads inside a cloud data warehouse environment. How Does Apache Sedona Process Spatial Queries The first step in spatial query processing is to ingest geospatial data into Apache Sedona. Data can be loaded from various sources such as files (Shapefiles, GeoJSON, Parquet, GeoTiff, CSV, etc) or databases into Apache Sedona’s in-memory distributed spatial data structures (typically the Spatial DataFrame). Next, Sedona makes use of spatial indexing techniques to accelerate query processing, such as R-trees or Quad trees. The spatial index is used to partition the data into smaller, manageable units, enabling efficient data retrieval during query processing. Once the data is loaded and indexed spatial queries can be executed using Sedona’s query execution engine. Sedona supports a wide range of spatial operations, such as spatial joins, distance calculations, and spatial aggregations. Sedona optimizes spatial queries to improve performance. The query optimizer determines an efficient query plan by considering the spatial predicates, available indexes, and the distribution of data across the cluster. Spatial queries are executed in a distributed manner using Sedona’s computational capabilities. The query execution engine distributes the query workload across the cluster, with each node processing a portion of the data. Intermediate results are combined to produce the final result set. Since spatial objects can be very complex with many coordinates and topology, Sedona implements a custom serializer for efficiently moving spatial data throughout the cluster. What Are Common Apache Sedona Use Cases Organizations use Apache Sedona for a range of large-scale geospatial data processing tasks, including Creating custom weather, climate, and environmental quality assessment reports at national scale by combining vector parcel data with environmental raster data products. Generating planetary scale GeoParquet files for public dissemination via cloud storage by combining, cleaning, and indexing multiple datasets. Converting billions of daily point telemetry observations into routes traveled by vehicles. Enriching parcel level data with demographic and environmental data at the national level to feed into a real estate investment suitability analysis. Many of these use cases can be described as geospatial ETL operations. ETL (extract, transform, load) is a data integration process that involves retrieving data from various sources, transforming and combining these datasets, then loading the transformed data into a target system or format for reporting or further analysis. Geospatial ETL shares many of the same challenges and requirements of traditional ETL processes with the additional complexities of managing the geospatial component of the data, working with geospatial data sources and formats, spatial data types and transformations, as well as the scalability and performance considerations required for spatial operations such as joins based on spatial relationships. For a real-world example of Apache Sedona in production, watch how Comcast data engineer David Buchanan used Apache Sedona to optimize geospatial ETL pipelines at scale, reducing processing time from 5 hours to 30 minutes: “Apache Sedona has been a great asset to our team at Comcast. We adopted Apache Sedona to add geospatial capabilities to our existing Spark extract, transform, and load (ETL) pipelines. Its open-source nature enables us to be flexible in creating pipelines that are usable both in the cloud and on-premises, reducing vendor lock-in. Additionally, we can quickly scale our workloads depending on the team's needs, which has increased our productivity compared to using other tools like GeoPandas or PostGIS.” David Buchanan Comcast How Widely is Apache Sedona Used Apache Sedona is one of the most widely adopted geospatial analytics libraries in the distributed computing ecosystem, with over 80 million downloads and active use across industries including transportation, logistics, environmental monitoring, and insurance. As a top-level Apache Software Foundation (ASF) project since February 2023, Sedona’s governance, licensing, and community participation align with ASF principles. The project has an active and growing developer community, with contributors from many types of organizations and more than 100 individuals advancing geospatial analytics and distributed computing. Organizations in industries including transportation, urban planning, environmental monitoring, logistics, insurance and risk analysis and more have adopted Apache Sedona. These organizations leverage Sedona’s capabilities to perform large-scale geospatial analysis, extract insights from geospatial data and build geospatial analytical applications at scale. Apache Sedona has been featured in conferences, workshops, and research publications related to geospatial analytics, distributed computing, and big data processing. For a deeper look at Apache Sedona’s adoption and real-world impact, watch Iceberg Geo Type: Transforming Geospatial Data Management at Scale presented by Jia Yu and Szehon Ho at at Data + AI Summit. How to Get Started With Apache Sedona For quick access to documentation and community support: Check out the documentation for Apache Sedona. Join the community Discord server. Attend the community office hours. Find and contribute to Apache Sedona on GitHub. Running Sedona in production? Compare Wherobots and Apache Sedona to see what WherobotsDB and Wherobots Cloud add. For a comprehensive introduction, ‘Cloud Native Geospatial Analytics with Apache Sedona,’ published with O’Reilly, covers how to work with large-scale spatial data using Apache Sedona, Apache Spark, and modern cloud technologies. It is aimed at developers, data scientists, and data engineers Get Access to the Free Guide Download Frequently Asked Questions What is Apache Sedona? Apache Sedona is an open-source cluster computing system built for processing large-scale spatial data across distributed environments. It was originally developed at Arizona State University under the name GeoSpark. It is now a top-level Apache Software Foundation project used by organizations across transportation, logistics, environmental monitoring, insurance, and urban planning. What is Apache Sedona used for? Organizations use Apache Sedona for large-scale geospatial ETL. Examples are national-scale environmental reports that combine vector and raster, planetary GeoParquet generation, converting billions of telemetry points into vehicle routes, and parcel enrichment for real estate analysis. At Comcast, a geospatial ETL job dropped from 5 hours to 30 minutes. Who created Apache Sedona? Apache Sedona began at Arizona State University as GeoSpark, described in the paper Spatial Data Management in Apache Spark: The GeoSpark Perspective and Beyond by Jia Yu and Mohamed Sarwat. It is now a top-level Apache Software Foundation project. What programming languages does Apache Sedona support? Apache Sedona supports Python, Scala, Java, R, and SQL. It runs on Apache Spark for large-scale batch processing, Apache Flink for streaming spatial analytics, and Snowflake for spatial workloads in a cloud data warehouse. Is Apache Sedona open source and free? Yes. Apache Sedona is open source and a top-level Apache Software Foundation project since February 2023.Governance, licensing, and community participation follow ASF principles. The code is on GitHub, with more than 100 individual contributors. How does Apache Sedona process spatial data? Geospatial files such as Shapefiles, GeoJSON, Parquet, GeoTiff, and CSV are ingested into Spatial DataFrames. Sedona indexes them with R-trees or quad-trees, then runs spatial joins, distance calculations, and aggregations across the cluster. A query optimizer picks a plan, and a custom serializer moves complex geometries between nodes. --- ## Apache Sedona URL: https://wherobots.com/apache-sedona/ Updated: 2026-10-06 Apache Sedona Apache Sedona is the most widely deployed open-source distributed spatial engine in the world, with 80M+ downloads. It runs on Apache Spark and Apache Flink. Try Apache Sedona On Wherobots Cloud 2,000,000 Downloads per month 80,000,000 Number of downloads 2,200 Stars on github 200% Year over year growth The Open Source Solution for High-Performance Geospatial ETL & Analytics Apache Sedona extends distributed compute frameworks to add support for spatial data types, spatial indexing, and efficient spatial query processing using Spatial SQL and Python. With over 300 vector and raster Spatial SQL functions and support for multiple distributed compute engines including Apache Spark, Apache Flink, and Snowflake, as well as a purpose built engine in Rust with SedonaDB, Apache Sedona brings the most comprehensive support of Spatial SQL, python, R and Scala to parallel and scalable data processing environments. Wherobots was founded by Jia Yu and Mo Sarwat, the researchers who created Apache Sedona at Arizona State University. Get started The easiest way to get started is by using the official Apache Sedona Docker image docker run apache/sedona:latest Apache Sedona can be run in many different cloud platforms including: Docker Wherobots Cloud AWS EMR Databricks microsoft fabric aws glue Snowflake spark cluster learn more Leverage resources to learn more about using Apache Sedona to solve your large-scale spatial data problems. Apache Sedona Community Office Hour: July 2026 Apache Sedona Community Office Hour: July 2026 Apache Sedona Community Office Hour: June 2026 Apache Sedona Community Office Hour: June 2026 Apache Sedona Community Office Hour: May 2026 Apache Sedona Community Office Hour: May 2026 Apache Sedona Community Office Hour: February 2026 Apache Sedona Community Office Hour: February 2026 Apache Sedona Community Office Hour: January 2026 Apache Sedona Community Office Hour: January 2026 Apache Sedona Community Office Hour: November 2025 Apache Sedona Community Office Hour: November 2025 Apache Sedona Community Office Hour: October 2025 Apache Sedona Community Office Hour: October 2025 Apache Sedona Community Office Hour: September 2025 Apache Sedona Community Office Hour: September 2025 Apache Sedona Community Office Hour: July 2025 Apache Sedona Community Office Hour: July 2025 Apache Sedona Community Office Hour: June 2025 Apache Sedona Community Office Hour: June 2025 Apache Sedona Community Office Hour: May 2025 Apache Sedona Community Office Hour: May 2025 Apache Sedona Community Office Hour: April 2025 Apache Sedona Community Office Hour: April 2025 Apache Sedona Community Office Hour – March 2025 Apache Sedona Community Office Hour – March 2025 Apache Sedona Community Office Hours – February 2025 Apache Sedona Community Office Hours – February 2025 Apache Sedona Community Office Hours – December 2024 Apache Sedona Community Office Hours – December 2024 Apache Sedona Community Office Hours – November 2024 Apache Sedona Community Office Hours – November 2024 Apache Sedona Community Office Hours – September 2024 Apache Sedona Community Office Hours – September 2024 Apache Sedona Community Office Hour – August 2024 Apache Sedona Community Office Hour – August 2024 Apache Sedona Community Office Hour – June 2024 Apache Sedona Community Office Hour – June 2024 Apache Sedona Office Hours – May 2024 Apache Sedona Office Hours – May 2024 Connect with Apache Sedona across platforms and networks. Github The Apache Sedona GitHub repository is the home of Sedona’s open-source code visit our github Follow Apache Sedona On X Keep up to date with important announcements and links to new technical content follow us on X Connect On LinkedIn Find new events and announcements from the community on LinkedIn follow us on LINKEDIN Apache Sedona YouTube Videos Watch tutorials, livestreams, webinar recordings, and more on YouTube VISIT OUR YOUTUBE dockerhub The official Apache Sedona Docker image is the easiest way to get started with Apache Sedona VISIT OUR DOCKERHUB Review the latest on Apache Sedona across docs, blogs, and release notes. Apache Sedona Documentation Find tutorials and reference docs in the official Apache Sedona documentation Check sedona Documentation Apache Sedona On The Wherobots Blog Many of the posts on the Wherobots blog are technical examples using Apache Sedona Check our Blog release notes Keep up to date with new features in each release in Apache Sedona’s release notes Check our Release notes Get Involved Join the Apache Sedona community and be a part of the modern geospatial analytics ecosystem. There are many ways to be involved. Wherobots MCP Server Demo Wherobots MCP Server Demo Geospatial Python: Raster and vector data loading in Apache Sedona [Tutorial] Geospatial Python: Raster and vector data loading in Apache Sedona [Tutorial] Wherobots 101: Mastering Scalable Geospatial Data Processing Wherobots 101: Mastering Scalable Geospatial Data Processing Wherobots 102: Reading and Processing Cloud Native Geospatial Data Wherobots 102: Reading and Processing Cloud Native Geospatial Data Spatial Joins at Scale: Unlocking Advanced Geospatial Analytics with Wherobots Spatial Joins at Scale: Unlocking Advanced Geospatial Analytics with Wherobots Scaling Zonal Statistics: Fast Raster + Vector Joins with Wherobots Scaling Zonal Statistics: Fast Raster + Vector Joins with Wherobots Join Our Discord Server Connect with Apache Sedona Community members in real time to ask questions and share your JOIN OUR DISCORD SERVER Join Our Community Forum Find answers to your questions and share your projects with the Apache Sedona Community JOIN COMMUNITY PARTICIPATE IN THE COMMUNITY OFFICE HOURS Each month the Apache Sedona community hosts an office hour to share important updates, answer questions, and connect with the community SIGN UP TO JOIN Apache Sedona Issue Tracker Found a bug? Create an issue in the Apache Sedona JIRA site CREATE ISSUE ON JIRA Frequently Asked Questions What is Apache Sedona? Apache Sedona is the most widely deployed open-source distributed spatial engine in the world, with 80M+ downloads. It runs on Apache Spark and Apache Flink and supports spatial SQL, Python, Java, and Scala for processing geometry and raster data at scale. Is Apache Sedona open source? Yes. Apache Sedona is an open-source distributed spatial engine. The code lives on GitHub (2,200 stars on this page’s stats), with an official Docker image, community office hours, and channels on X, LinkedIn, YouTube, and Discord. What is Apache Sedona software? Apache Sedona is open-source software that extends distributed compute frameworks with spatial data types, spatial indexing, and Spatial SQL and Python capabilities. It also includes an engine purpose built for spatial data on Rust with SedonaDB as well as a framework for benchmarking spatial data processing with SpatialBench. For distributed compute it brings over 300 vector and raster Spatial SQL functions to parallel environments including Apache Spark, Apache Flink, and Snowflake. How do I get started with Apache Sedona? The easiest way to get started with Apache Sedona is to sign up to Wherobots Cloud and use it there directly. It’s fully managed, requires no infrastructure, and runs many times faster and more cost efficiently, especially at scale. And it comes with a built-in data catalog, key features like MCP server integration with VS Code or Claude, and more new capabilities coming every day. Learn about the price performance of WherobotsDB over open source Apache Sedona here. Who created Apache Sedona? Apache Sedona was created by researchers Jia Yu and Mo Sarwat at Arizona State University. They later founded Wherobots. Any Apache Sedona workload runs on Wherobots with zero code changes. Can I run Apache Sedona workloads on Wherobots? Yes. Any Apache Sedona workload runs on Wherobots with zero code changes. See how Wherobots compares with Apache Sedona. You can start from the free trial on this page, or join the Apache Sedona community on Discord to discuss with other members and experts. Try Apache Sedona on Wherobots Or join the community to discuss with other members and experts. START BUILDING JOIN COMMUNITY --- ## Resources URL: https://wherobots.com/resources/ Updated: 2026-07-13 Optimize your path to spatial intelligence There is a village dedicated to helping you find your path to success with Apache Sedona and Wherobots. Join the community Connect with the geospatial experts at Wherobots Whether it’s questions on geometries, geography, or raster data and inference, connect with us help you turn your spatial ideas into realities. Join the community, ask questions, make requests, or add extensions – whatever it may be, we want to hear from you! WHEROBOTS RESOURCES Documentation See how easy it is to get started with Wherobots Cloud, and explore the product using our documentation. Dive into our documentation Getting started videos Watch an overview of Wherobots Cloud, and see how easy it is to complete your first spatial analysis at-scale. SEE GETTING STARTED PLAYLIST Newsletter Want to know about our latest capabilities and announcements? Sign up for our newsletter Community Ask questions and learn what others have discovered. Join the community The Wherobots Blog Dive into use cases and new products Visit the blog Apache Sedona Get started with the leading open source framework for running analytics on geospatial data at scale. Learn more about Apache Sedona Resources Github The Wherobots GitHub repository is the home of Wherobots’ code and repos visit our github Follow Wherobots on X Stay informed on important announcements Follow us on X Connect with Wherobots on LinkedIn Build direct connections with the Wherobots team, discover events, and receive updates on LinkedIn Connect to Wherobots on LinkedIn Wherobots YouTube Channel Watch tutorials, livestreams, webinar recordings, and more on YouTube Visit our Youtube Docker Hub The official Apache Sedona Docker image is the easiest way to get started with Apache Sedona Visit the Apache Sedona Docker Hub Try the Spatial Intelligence Cloud Or join the community to discuss with other members and experts. TRY NOW JOIN COMMUNITY --- ## Solutions URL: https://wherobots.com/solutions/ Updated: 2026-10-09 Spatial data analytics for the industries that shape the physical world. AI built on text, documents, databases, structured data, and the internet misses the physical world entirely. Insurance, aerospace, telecom, energy, mobility, and agriculture all run on physical-world data. Wherobots is the context engine that gives these industries the ability to process, analyze, and act on the data behind their assets, their exposure, and their operations. TALK TO US INDUSTRY USE CASES Aerospace and Earth Observation Process petabytes of satellite imagery, run AI inference at scale, and build Earth observation intelligence. Focus: satellite imagery analysis. LEARN MORE Communication Service Providers Process billions of network events, optimize 5G deployments, and build network intelligence at scale. LEARN MORE Financial Services and Insurance Property risk assessment, catastrophe modeling, and climate risk analytics at portfolio scale. Know your exposure before the market does. LEARN MORE Mobility and Map Making Process billions of GPS points, build location intelligence products, and deliver fresh geospatial data to market. LEARN MORE Energy and Utilities Wildfire risk assessment, solar site selection, grid modernization, and infrastructure intelligence. Focus: grid analytics. LEARN MORE Sustainability and Agriculture Satellite crop monitoring, field boundary detection, and remote sensing agriculture at planetary scale. Focus: satellite crop monitoring. LEARN MORE Easily combine raster and vector data types to identify risks, track population movement OR IDENTIFY MOBILITY TRENDS. Wherobots Cloud builds on top of Apache Sedona for planetary scale data processing of geospatial datasets, unlocking answers for insurance, agriculture, mobility analytics, climate, real estate, and more. Frequently Asked Questions What industries does Wherobots serve? Wherobots serves industries that run on physical-world data: insurance and financial services for property risk assessment and catastrophe modeling, aerospace and Earth observation for satellite imagery analysis, communication service providers for telecom analytics and 5G network planning, energy and utilities for grid analytics and wildfire risk assessment, mobility and map making for location intelligence, and agriculture for satellite crop monitoring and remote sensing. The platform processes geospatial data at planetary scale for any industry where geography shapes decisions. How is Wherobots different from general-purpose analytics platforms for industry solutions? General-purpose analytics platforms like Snowflake, Databricks, and BigQuery treat spatial data as a secondary feature. Wherobots is built from the ground up for physical-world data. WherobotsDB includes 300+ spatial functions covering vector and raster data, with native Spark SQL for tabular operations. RasterFlow runs computer vision models on satellite imagery at any scale. The platform handles the computationally intensive spatial joins, raster-vector fusion, and geometric precision that industry-specific geospatial analytics demand. How does Wherobots integrate with existing data infrastructure? Wherobots connects to AWS S3, Databricks Unity Catalog, AWS Glue Catalog, and any Apache Iceberg catalog. Your data stays in your cloud storage. Wherobots runs compute against it without migration. SOC 2 Type 2 attested. Managed cloud, bring-your-own-cloud, and VPC deployment options available. Use Cases & Stories use cases View more 8 Mins Read 10 Dec 2025 Introducing RasterFlow: a planetary scale inference engine for Earth Intelligence RasterFlow takes insights and embeddings from satellite and overhead imagery datasets into Apache Iceberg tables,… 5 Mins Read 08 Apr 2026 Introducing developer tools that let AI build with physical world data Your AI can now understand and query spatial data using the Wherobots MCP server, VS… 11 Mins Read 18 Mar 2026 Streaming Spatial Data into Wherobots with Spark Structured Streaming Real-time Spatial Pipelines Shouldn’t Be This Hard (But They Were) I’ve been doing geospatial work… Stories View more 3 Mins Read 17 Nov 2025 How Aarden.ai Scaled Spatial Intelligence 300× Faster for Land Investments with Wherobots When Aarden.ai emerged from stealth recently with $4M in funding to “empower landowners in data center… 6 Mins Read 25 Nov 2024 Accelerating Vector and Raster Analysis at GeoPostcodes How long is too long to wait for a data set to process? In the… 8 Mins Read 17 Jul 2024 Generate Global PMTiles in 26 Minutes: Processing 2.3B Overture Maps Data Learn why WherobotsDB VTiles is the most scalable and performant solution for generating vector tiles.… Give your industry AI that sees the physical world Wherobots is the Context Engine for Physical World Data. START BUILDING TALK TO US --- ## Products URL: https://wherobots.com/products/ Updated: 2026-10-09 The platform for geospatial analytics, satellite imagery AI, and spatial data automation WherobotsDB for planetary-scale spatial compute. RasterFlow for Earth intelligence inference. The Spatial AI Coding Assistant for AI-native development. A Global Hub for data, notebooks, workflows and recipes. Built by the original creators of Apache Sedona. GET STARTED NOW Challenges preventing data teams from innovating with spatial data. Legacy solutions don’t perform at scale. Constrained to a single machine or traditional databases that only scale vertically. "Modern" cloud engines are geo-incomplete. Geospatial support in the cloud is second-rate, delivering underwhelming performance and suboptimal DevEx. LLM AND CODE GEN SYSTEMS AREN'T SKILLED IN SPATIAL Knowledge of spatial data functions requires fine tuned expertise. What you get with Wherobots Cloud Elevated spatial data productivity. Unified analytics of various data types at speeds orders of magnitude faster (typically 5-20x faster) than popular cloud engines, at a fraction of the cost. Get started now An open core geospatial platform in the cloud. Offering Apache Sedona compatibility, unified analytics of vector and raster data, 300+ functions, and an abundance of native spatial ETL and AI capabilities. Dive in here Expertise embedded accelerating time to value Let the product guide you through models, compute and learning journeys built into the user experience. Accelerate your time to productivity with our guidance. Explore Courses and Learning CAPABILITIES The Global Hub Datasets from Overture Maps and Foursquare. Pre-trained AI models. Solution notebooks. Your own data from S3 or Unity Catalog. Learn More Spatial AI Coding Assistant Discover datasets, construct queries, and run production jobs through natural language. VS Code and MCP. Learn More Automate Take spatial pipelines to production. Apache Airflow integration, Job Runs API, and full observability. The same code from notebooks, now in production. Learn More WherobotsDB Planetary-scale spatial compute. 300+ spatial functions for vector and raster data. 3x faster at 46% lower cost. Built on Apache Sedona. Learn More RasterFlow Satellite imagery analysis at any scale. Run computer vision models on satellite imagery. From a city block to the entire globe. Learn More Resources Blog View more 6 Mins Read 14 Feb 2025 Iceberg GEO: Technical Insights and Implementation Strategies In our previous blog post, we announced Apache Iceberg and Parquet’s support for spatial data… 5 Mins Read 24 Sep 2025 Introducing SedonaDB and SpatialBench for Apache Sedona The spatial-first query engine and benchmarking framework for Apache Sedona 12 Mins Read 16 Dec 2024 Building a Spatial Data Lakehouse Explore how Apache Iceberg based Havasu redefines data management for geospatial data lakehouse architectures. Learn… News View more 6 Mins Read 25 Nov 2024 Accelerating Vector and Raster Analysis at GeoPostcodes How long is too long to wait for a data set to process? In the… 6 Mins Read 26 Nov 2024 Announcing Our 21.5M Series A :: Unlocking Answers to Planetary-scale Questions. Each day, satellites, drones, applications, and GPS devices generate petabytes of spatial data that can… 5 Mins Read 11 Feb 2025 Apache Iceberg and Parquet now support GEO Geospatial solutions were thought of as “special”, because what modernized the data ecosystem of today,… Frequently Asked Questions What capabilities does Wherobots include? WherobotsDB is the distributed spatial compute engine with 300+ functions covering vector and raster data, with native Spark SQL for tabular operations. RasterFlow is the serverless inference engine for satellite imagery analysis and Earth intelligence. The Spatial AI Coding Assistant connects AI agents to spatial data through VS Code and MCP. The spatial data catalog provides hosted datasets from Overture Maps and Foursquare, pre-trained AI models, and solution notebooks. Production automation integrates with Apache Airflow and the Job Runs API for scheduled spatial pipelines. What deployment options are available for Wherobots? Wherobots offers managed cloud (SaaS), bring-your-own-cloud, and VPC deployment. All deployment options include SOC 2 Type 2 attestation. Data stays in your cloud environment. For teams with strict data residency or security requirements, VPC deployment keeps all compute and storage within your AWS account. Build AI that understands the physical world. Wherobots is the Context Engine for Physical World Data. START BUILDING JOIN THE COMMUNITY --- ## Announcing SAML Single Sign-On (SSO) Support URL: https://wherobots.com/blog/announcing-saml-single-sign-on-sso-support/ Updated: 2026-10-19 We’re excited to announce that Wherobots Cloud now supports SAML SSO for Professional Edition customers. This enhancement underscores our commitment to providing robust security features tailored to the needs of businesses that handle sensitive data. Key takeawaysWherobots Cloud now supports SAML SSO for Professional Edition customers, aimed at organizations that already centralize login through an identity provider.SAML exchanges authentication and authorization data between parties; SSO lets users log in once and reach multiple systems without re-entering credentials.Any Professional Edition administrator can enable it. Verify the company domain with a TXT DNS record, configure the IdP, and paste issuer URL, SSO URL, and certificate into Wherobots.Then ensure an admin email on the verified domain, and toggle Enable.Documented identity providers include Google Workspace, Okta, OneLogin, and Azure AD.The post argues SSO cuts password-reset tickets and phishing risk. It also helps control who can see sensitive location data inside Wherobots, for example healthcare clinic visits.Upgrading to Professional also unlocks more powerful workloads and service principals. What is SAML Single Sign-On Many companies already use SAML SSO. It is the mechanism by which you log in to third party tools with your company’s centralized login (Google, Okta, etc.) SAML (Security Assertion Markup Language) are essential components of modern security protocols. SAML is an open standard for exchanging authentication and authorization data between parties and SSO (Single Sign-On) allows users to log in once and gain access to multiple systems without re-entering credentials. How to enable SAML SSO Setting up SAML SSO is straightforward. Any Professional Edition Wherobots administrator can enable this feature by following these steps: Verify Your Domain:Go to your organization’s settings, copy the provided TXT DNS record, and add it to your domain provider’s DNS settings. Once done, click “Verify” in Wherobots. Configure Your Identity Provider (IdP):Log in to your IdP (e.g., Google Workspace, Okta, OneLogin, Azure AD) and configure it using the SAML details provided in the Wherobots settings. Enter IdP Details into Wherobots:Input the Identity Provider Issuer URL, SSO URL, and certificate details from your IdP into the SAML section in Wherobots. Enable SAML SSO:Make sure there’s an admin user with an email from the verified domain. Then, toggle the “Enable” switch in Wherobots to activate SSO. Test the Integration:Log in using your verified domain email to ensure everything is set up correctly. For more detailed step-by-step instructions, check out our comprehensive getting started guide. Why Your Organization Should Use SAML Single Sign-On Benefits to Users For users, SAML SSO simplifies the login process. With fewer passwords to remember and less frequent logins, users save time and reduce frustration. This streamlined access means employees can focus more on their tasks and less on managing multiple credentials. Benefits to Organizations Organizations benefit from SAML SSO by enhancing security and reducing administrative overhead. Centralized authentication means fewer password-related support tickets and a lower risk of phishing attacks, as users are less likely to fall for credential-stealing schemes. Moreover, it ensures compliance with security policies and regulatory requirements by enforcing strong, consistent access controls. It also allows organizations to grant access to certain third party services only for certain users/groups of users. Location data is particularly sensitive, as it can reveal personal habits, routines, and even confidential business operations. For example, in healthcare, location data of patients visiting specialized clinics could inadvertently disclose medical information. By implementing SAML SSO, organizations can better control access, ensuring that only authorized personnel can view and interact with this information within the Wherobots platform. Elevate Your Security with SAML SSO Take this opportunity to simplify authentication, reduce security risks, and improve productivity. If you are not already a Professional Edition customer, upgrade to gain access to SAML SSO. By upgrading, you’ll not only bolster your security measures and simplify logins, but you’ll gain access to more powerful workloads, service principals, and more. Contact us to schedule a demo or get started! Want to keep up with the latest developer news from the Wherobots and Apache Sedona community? Sign up for the Spatial Intelligence Newsletter: Frequently Asked Questions Does Wherobots support SAML SSO? Yes. SAML single sign-on is available to Wherobots Professional Edition customers and is enabled by an organization administrator. Which identity providers work with Wherobots SSO? The setup steps mention Google Workspace, Okta, OneLogin, and Azure AD, using the SAML details shown in Wherobots organization settings. How do I turn on SAML SSO? Verify your domain with the provided TXT DNS record, configure the IdP, and enter the Identity Provider Issuer URL, SSO URL, and certificate in Wherobots. Then confirm an admin user on that domain, enable the toggle, and test login. Why use SSO for a spatial platform? The post says location data can reveal personal habits or confidential operations, so centralized authentication limits access to authorized users and reduces password-related support and phishing exposure. --- ## Wherobots and PostgreSQL + PostGIS: A Synergy in Spatial Analysis URL: https://wherobots.com/blog/wherobots-postgresql-postgis-better-together/ Updated: 2026-10-19 TL;DR Wherobots (powered by Apache Sedona) and PostgreSQL + PostGIS are complementary tools, not competitors. Use Wherobots for large-scale spatial ETL, processing speed, and distributed analytics. Use PostGIS for data persistence, transactional integrity, and long-term storage. Together, they form a complete spatial data pipeline. At scale, WherobotsDB is up to 317x faster than PostGIS on large spatial join queries, but PostGIS holds the edge on smaller datasets. The right approach is to process with Wherobots, then persist with PostGIS. Key takeawaysThe post treats Wherobots (Apache Sedona) and PostgreSQL + PostGIS as complementary: Wherobots for large-scale spatial ETL and distributed analytics, PostGIS for persistence, ACID transactions, and long-term storage.Wherobots is described with horizontal scale to petabytes, in-memory processing, 300+ spatial SQL functions for raster and vector, a Pythonic DataFrame API, and a Python DB API 2.0 driver.On small joins PostGIS can be faster because of precomputed GiST indexes (1 million buildings × 1 million nodes: 0.70s vs 2.24s). At full scale PostGIS aborted after 24+ hours on all Overture buildings × all OSM nodes, while WherobotsDB (Cairo runtime) finished in 4 minutes 31.84 seconds, more than 317x.Other published speedups versus PostGIS: 10,000 buildings × all nodes at 193x (2h 29m 19s vs 46.42s). 100,000 buildings × all nodes ran at 304.57x (4h 22m 36s vs 51.75s).Benchmark datasets: OSM nodes 256 GB / 7,456,990,919 points; Overture buildings 103 GB / 706,967,095 polygons; OSM postal codes 0.86 GB / 154,452 polygons. Spatial data has never been more abundant and valued in decision making (everything happens somewhere!). The tools we use to process location based data can significantly impact the outcomes of our projects. In the geospatial ecosystem, Apache Sedona-powered Wherobots and PostgreSQL with the PostGIS extension each offer robust capabilities. They share some functionalities, but they are more powerful when used together, rather than in isolation. This post explores how combining Wherobots and PostgreSQL + PostGIS can enhance spatial data processing, offering a synergy that leverages the unique strengths of each tool to enhance data analysis and decision-making processes. What Is PostgreSQL + PostGIS and What Is It Best For? PostgreSQL is a powerful, open-source object-relational database system known for its robustness and reliability. When combined with the PostGIS extension, PostgreSQL transforms into a spatial database capable of executing location-based queries and spatial functions. This combination is ideally suited for projects where data integrity and detailed transaction management (ACID transactions) are crucial. Key Features: Data Integrity: Ensures high levels of data accuracy and consistency with ACID transaction compliance. Complex Queries: Supports a wide array of SQL and spatial queries for detailed data management. Integration: Seamlessly integrates with existing IT infrastructures and data systems. Architecture: PostgreSQL’s architecture, a traditional RDBMS, uses a process-based database server architecture. It is designed for detailed, transactional data management, where data integrity and complex query capabilities are paramount. Characteristics: Transactional Integrity: PostgreSQL excels in maintaining data consistency and integrity through ACID (Atomicity, Consistency, Isolation, Durability) compliance, making it ideal for applications requiring reliable data storage. Structured Data Management: Data must be written into PostgreSQL tables, allowing for sophisticated querying and indexing capabilities provided by PostGIS. This ensures precise spatial data management. Integration with Legacy Systems: PostgreSQL + PostGIS can easily integrate with existing IT infrastructure, providing a stable environment for long-term data storage and complex spatial queries. What Is Wherobots and How Does Apache Sedona Power It? Wherobots, founded by the original creators of Apache Sedona, represents a significant advancement in modern cloud native spatial data processing. Apache Sedona is an open-source cluster computing system designed for the processing of large-scale spatial data, and Wherobots (continuously optimizing Sedona for performance) employs this technology with serverless deployment principles to analyze data distributed across clusters. This approach allows Wherobots to perform complex spatial queries and analytics efficiently, handling massive datasets that are beyond the scope of traditional geospatial data processing tools. Key Features: Scalability: Easily scales horizontally to handle petabytes of data across through a cluster computing architecture. Speed: Utilizes memory-centric architecture to speed up data processing tasks. Complex Algorithms: Supports numerous spatial operations and algorithms essential for advanced geographic data analysis. Spatial SQL API: Over 300 (and growing) spatial type SQL functions covering both raster and vector analysis. Pythonic Dataframe API: Extends the Spark Dataframe API for spatial data processing. Python DB API: Python module conforming to the Python DB API 2.0 specification with familiar access patterns. Architecture: The backbone of Wherobots, Apache Sedona, is designed with a modern cloud native and distributed computing framework in mind. Wherobots orchestrates and manages the cluster distributed compute nodes to enable large-scale spatial data processing by bringing compute power directly to the data. This architecture is purpose built for handling big data analytics and planetary-scale spatial data processing. Characteristics: Distributed Processing: Wherobots and Apache Sedona utilize a cluster of nodes, enabling parallel processing of massive datasets. This makes it ideal for tasks requiring high scalability and speed. In-Memory Computation: By leveraging in-memory processing, Sedona significantly reduces the time needed for complex spatial operations, allowing for rapid data exploration and transformation. Cloud Integration: Wherobots architecture is naturally aligned with cloud-based solutions, enabling seamless integration with cloud services like Amazon Web Services (AWS). This facilitates scalable and flexible spatial data analytics. When to Use Wherobots vs PostgreSQL + PostGIS: A Practical Guide Sedona in Wherobots and PostgreSQL + PostGIS can both perform spatial queries, but their real power lies in how they complement each other. For example: Data Handling and Performance: Apache Sedona in Wherobots Cloud is second to none at handling and analyzing large volumes of data, making them ideal for initial data processing, exploration, transformation, and analysis. In contrast, PostgreSQL + PostGIS excels in managing more detailed transactions and operations requiring high precision and integrity. Use Wherobots for: Scalable Data Operations, Wherobots efficiently scales processing across multiple nodes, ideal for rapid analysis of spatial data at local to global levels. Use PostgreSQL & PostGIS for: PERSISTENCE, PostgreSQL + PostGIS provides the tools necessary for precise data management crucial for applications like urban planning and asset management. Use Case Flexibility: Wherobots can quickly process vast quantities of spatial data, making them suitable for environments and applications that require immediate insights on large volumes of data. PostgreSQL + PostGIS, being more transaction oriented, is perfect for applications where long-term data storage and management are needed. Use Wherobots for: Processing Speed, when your scenario requires immediate response. Use PostgreSQL & PostGIS for: Data Management, in scenarios requiring meticulous data integrity, such as environmental monitoring over years or detailed urban planning projects. Analytical Depth: When initial processing (extractions, transformations, enrichment, etc.) on large scale data is done with Wherobots, ETL run times can be greatly reduced. Once processed, the data can be permanently stored and hosted in PostgreSQL + PostGIS. This allows users to perform deep, granular analyses at scale and then persist and serve those insights. Use Wherobots for: Transforming and Enriching Data: Extract, transform, enrich, refine, and analyze data in Wherobots Cloud at scale and with unparalleled speed. Use PostgreSQL & PostGIS for: Robust Data Ecosystem. Combining these tools ensures a robust data and analysis and management ecosystem capable of supporting complex, multi-dimensional spatial queries. How to Integrate Wherobots with PostgreSQL + PostGIS: A Reference Architecture Let’s illustrate how these two systems can be integrated in a complimentary manner. We’ll assume the persona of a fictitious company named “Synergistic GeoFusion Technologies (SGT) holdings”. SGT holdings handles a vast array of spatial data from diverse sources such as sensors, satellites, and user inputs. The volume and velocity of the data collection requires a sophisticated approach to maximize efficiency. Wherobots steps in as the initial processing powerhouse, applying its Apache Sedona-based cluster computing to perform heavy-duty ETL (Extract, Transform, Load) tasks. This process involves cleansing, integrating, and transforming the raw data into a more structured format. Wherobots’ capability to handle massive datasets efficiently complements PostGIS’s robust data storage and querying capabilities by preparing the data for detailed spatial analysis and storage. Once Wherobots processes the data, it can be seamlessly transferred to PostGIS, which cab serve as the system of record. This PostgreSQL extension is well-suited for ongoing data management, thanks to its sophisticated spatial functions and ability to handle complex queries. PostGIS’s strong querying capabilities complement Wherobots’ data processing strength, providing a stable platform for further data manipulation and refinement. PostGIS is not only a storage layer but also a platform for ongoing data edits and updates, ensuring data integrity and relevance. When complex, resource-intensive spatial analyses are required, Wherobots is re-engaged. This dual engagement allows SGT holdings to handle routine data management in PostGIS while delegating computationally demanding tasks back to Wherobots, thus utilizing each system’s strengths to full effect. For visualization, SGT holdings again leverages Wherobots to generate vector tiles from the analyzed data. These tiles are crucial for dynamic, scalable visual representations in the company’s internal dashboards and tools. Wherobots’ ability to generate these tiles efficiently complements PostGIS’s role by providing a means to visualize the data stored and managed within PostGIS. This not only enhances user interactions with the data but also provides a seamless bridge from data analysis to actionable insights through visual exploration. Using Wherobots and PostGIS in this complimentary manner, SGT has established a highly efficient workflow that leverages the distinct capabilities of each system. They now have the capability to ingest all their data, manage it effectively, and run their post hoc analysis tasks to server internal and external clients efficiently and in a cost effective manner. Performance Benchmark: Wherobots vs. PostGIS When comparing WherobotsDB to PostgreSQL with PostGIS for spatial queries, WherobotsDB’s performance benefits become evident as data size increases. Initially, PostGIS’ precomputed GIST indexes give it an edge on smaller datasets due to faster query execution times. However, as datasets grow larger, the dynamic, on-the-fly indexing of WherobotsDB surpasses PostGIS. The overhead associated with WherobotsDB’s distributed system is outweighed by its ability to efficiently handle complex, large-scale queries, ultimately making it significantly faster and more scalable in high-demand scenarios. In essence, WherobotsDB may start off slower with smaller datasets, but its performance dramatically improves with larger datasets, far exceeding PostGIS’ capabilities. This makes WherobotsDB the preferred choice when working with extensive spatial data that demands efficient, scalable processing. See the tables below for a detailed comparison of performance metrics. DatasetsSizeNumber of Rows    Types of GeometriesOSM Nodes256GB7,456,990,919PointOverture Buildings    103GB706,967,095Polygon/MultipolygonOSM Postal Codes0.86GB154,452Polygon WITH t AS ( SELECT * FROM overture_buildings_test AS buildings JOIN osm_nodes_test AS nodes ON ST_Intersects( nodes.geometry, buildings.geometry) ) SELECT COUNT(*) FROM t; Dataset sizesPostGISWherobotsDB (Cairo)    Relative Speed1M Buildings x 1M Nodes0.70s2.24s0.31 x1M Buildings x 10M Nodes32.30s33.44s0.97 x10M Buildings x 1M Nodes28.30s21.72s1.30 x10M Buildings x 10M Nodes49.30s3m 36.29s0.23 xAll Buildings x 1M Nodes8m 44s36.59s14.32 xAll Buildings x 10M Nodes38m 30s49.77s46.42 x10K Buildings x All Nodes2h 29m 19s46.42s193.00 x100K Buildings x All Nodes4h 22m 36s51.75s304.57 x1M Buildings x All Nodes3h 29m 56s1m 19.63s158.17 x10M Buildings x All Nodes8h 48m 13s2m 13.65s237.17 xAll Buildings x All Nodes+24h (Aborted)4m 31.84s+ 317.83 x Conclusion: Why Wherobots and PostgreSQL + PostGIS Are Better Together for Large-Scale Spatial Analysis Individually, Wherobots and PostgreSQL + PostGIS are powerful tools. But when combined, they unlock new possibilities for spatial analysis, offering a balanced approach to handling both large-scale data processing and detailed, precise database management. By understanding and implementing their complementary capabilities, organizations can achieve more refined insights and greater operational efficiency in their spatial data projects. By utilizing both tools strategically, companies can not only enhance their data analysis capabilities but also ensure that they are prepared for a variety of spatial data challenges, now and in the future. To learn more about Wherobots, reach out for a technical session or get started with a free account. Start Building with Wherobots Get Started Frequently Asked Questions Is Wherobots a replacement for PostGIS? No. The post’s TL;DR is that they are better together: process and enrich at scale in Wherobots, then persist and serve in PostgreSQL + PostGIS. When is PostGIS faster than WherobotsDB in this benchmark? On smaller joins. 1 million buildings × 1 million nodes was 0.70 seconds in PostGIS versus 2.24 seconds in WherobotsDB (Cairo). The gap closes and then reverses as row counts grow. What is the largest join compared here? All Overture buildings (706,967,095) × all OSM nodes (7,456,990,919). PostGIS was aborted after 24+ hours; WherobotsDB finished in 4 minutes 31.84 seconds, reported as more than 317.83x. How should the two systems be wired together? The reference architecture uses Wherobots for heavy ETL from sensors, satellites, and user input, and loads curated tables into PostGIS as the system of record. Heavy analytics go back to Wherobots, and Wherobots generates vector tiles for dashboards. --- ## Wherobots Joins Overture, Winning The Taco Wars, Spatial SQL API, Geospatial Index Podcast – This Month In Wherobots URL: https://wherobots.com/blog/wherobots-joins-overture-taco-wars-spatial-sql-api-geospatial-index-podcast/ Updated: 2026-10-19 Welcome to This Month In Wherobots the monthly developer newsletter for the Wherobots & Apache Sedona community! This month we have news about Wherobots and the Overture Maps Foundation, a deep dive on new Wherobots Cloud features like raster inference, generating vector tiles, and the Spatial SQL API, plus a look at retail cannibalization analysis for the commercial real estate industry. Key takeawaysThis August 2024 “This Month In Wherobots” newsletter roundups existing posts and events rather than original benchmarks.Wherobots joined the Overture Maps Foundation as a Contributing Member after already supporting Overture’s use of Apache Sedona and GeoParquet.Featured community work: Ilya Marchenko and Sean Knight of YuzuData on a retail cannibalization study with Overture POIs, Valhalla isochrones, and SedonaKepler.Product posts recapped here include Wherobots Raster Inference, generating global PMTiles of Overture buildings in 26 minutes with VTiles, and the Spatial SQL API (Python/Java drivers, Airflow provider, Harlequin).Upcoming events listed: Apache Sedona office hours August 6, GeoMeetup in San Francisco September 5, and FOSS4G NA in St. Louis September 9–11. Wherobots Joins Overture Maps Foundation Wherobots has officially joined Overture Maps Foundation to support the next generation of planetary-scale open map data. Wherobots has supported the development of Overture datasets through Overture Maps Foundation’s use of the open-source Apache Sedona project to develop and distribute global data, enabling Overture to embrace modern cloud-native geospatial technologies like GeoParquet. By joining Overture as Contributing Members Wherobots will continue to support the ongoing development, distribution, and evolution of this critical open dataset that enables developers and data practitioners to make sense of the world around us. Read the announcement blog post Featured Community Members: Sean Knight & Ilya Marchenko This month’s featured community members is Ilya Marchenko from YuzuData where he focuses on AI and location intelligence for the commercial real estate industry. Ilya recently wrote a blog post showing how to use Wherobots for a retail cannibalization study. Thanks Sean and Ilya for being a part of the community and sharing how you’re building geospatial products using Wherobots! Comparing Taco Chains: A Consumer Retail Cannibalization Study With Isochrones Understanding the impact of opening a new retail location on existing locations is an important analysis in the commercial real estate industry. In this code-heavy blog post the YuzuData team detail a retail cannibalization analysis using WherobotsDB, Overture Maps point of interest data, drive-time isochrones using the Valhalla API, and visualization with SedonaKepler. Sean also presented this analysis earlier this week in a live webinar. Read the blog post or watch the video recording Unlock Satellite Imagery Insights With Wherobots Raster Inference One of the most exciting features in Wherobots’ latest release is Wherobots Raster Inference which enables running machine learning models on satellite imagery for object detection, segmentation, and classification. This post gives a detailed look at the types of models supported by Wherobots and an overview of the SQL and Python APIs for raster inference with an example of identifying solar farms for the purpose of mapping electricity infrastructure. Read the blog post to learn more about Wherobots Raster Inference Generating Global PMTiles In 26 Minutes With WherobotsDB VTiles WherobotsDB VTiles is a highly scalable vector tile generator capable of generating vector tiles from small to planetary scale datasets quickly and cost-efficiently and supports the PMTiles format. In this post we see how to generate vector tiles of the entire planet using three Overture layers. Using Wherobots Cloud to generate PMTiles of the Overture buildings layer takes 26 minutes. The post includes all code necessary to recreate these tile generation operations and a discussion of performance considerations. Read the blog post to learn more about WherobotsDB VTiles Spatial SQL API Brings Performance Of WherobotsDB To Your Favorite Data Applications The Wherobots Spatial SQL API enables integration with Wherobots Cloud via Python and Java client drivers. In addition to enabling integrations with your favorite data applications via the client drivers, Wherobots has released an Apache Airflow provider for orchestrating data pipelines and an integration with Harlequin, a popular SQL IDE. Read the blog post to learn more about the Wherobots Spatial SQL API Wherobots On The Geospatial Index Podcast William Lyon from Wherobots was recently a guest on The Geospatial Index podcast. In this episode he discusses the origins of Apache Sedona, the open-source technology behind Wherobots, how users are building spatial data products at massive scale with Wherobots, how Wherobots is improving the developer experience around geospatial analytics, and much more. Watch the video recording Upcoming Events Apache Sedona Community Office Hours (Online – August 6th) – Join the Apache Sedona community for updates on the state of Apache Sedona, presentation and demo of recent features, and provide your input into the roadmap, future plans, and contribution opportunities. GeoMeetup: Cloud Native Spatial Data Stack (San Francisco – September 5th) – Join us on September 5th for an exciting GeoMeetup featuring talks from industry leaders with Wherobots and Felt.com. In this meetup we will be exploring the elements of the cloud native spatial data stack. FOSS4G NA 2024 (St Louis – September 9th-11th) – FOSS4G North America is the premier open geospatial technology and business conference. Join the Wherobots team for a pre-conference workshop or come by and chat with us at the Wherobots booth to learn about the latest developments in Apache Sedona. Want to receive this monthly update in your inbox? Sign up for the The Spatial Intelligence Newsletter: Frequently Asked Questions What is covered in the August 2024 Wherobots newsletter? Overture membership, a taco-chain cannibalization study, Raster Inference, VTiles/PMTiles, the Spatial SQL API, a Geospatial Index podcast episode with William Lyon, and upcoming events. Did Wherobots join Overture Maps Foundation? Yes. This issue announces Wherobots as a Contributing Member, continuing support for Overture datasets that are produced with Apache Sedona and published as GeoParquet. How long to generate global PMTiles in the post this newsletter cites? The recap says generating PMTiles of the Overture buildings layer on Wherobots Cloud takes 26 minutes. What integrations does the Spatial SQL API add in this issue? Python and Java client drivers, an Apache Airflow provider for pipeline orchestration, and an integration with the Harlequin SQL IDE. --- ## Wherobots Joins Overture Maps Foundation As Contributing Member To Enable Open Cloud-Native Geospatial Intelligence URL: https://wherobots.com/blog/overture-maps-foundation-wherobots-new-member-cloud-native-geospatial-intelligence/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. Wherobots is excited to share that we have officially joined Overture Maps Foundation as a Contributing Member to support the next generation of planetary-scale open map data. Wherobots believes wholeheartedly in Overture’s mission to bring open global-scale map data to the world while leveraging cloud-native technologies to enable efficient and accessible usage of these datasets. Key takeawaysWherobots joined the Overture Maps Foundation as a Contributing Member to support planetary-scale open map data and cloud-native access patterns.Overture already uses open-source Apache Sedona to develop and distribute datasets, including GeoParquet. Wherobots also hosts Overture in the Spatial Catalog as a fast way to query it.Overture Maps Foundation was founded in 2022 to build reliable, interoperable open map data, extensible under an open data license, with members pooling resources to keep maps current.Executive director Marc Prioleau is quoted saying Overture’s mission includes helping users access and use the data for map apps as well as spatial ETL, analytics, and intelligence.The post points to Wherobots examples already run on Overture: global PMTiles in 26 minutes with VTiles, and Places queries for urban dynamics, plus free-account tutorial notebooks. Wherobots has supported the development of Overture datasets through Overture Maps Foundation’s use of the open-source Apache Sedona project to develop and distribute the Overture datasets, enabling Overture to embrace modern cloud-native geospatial technologies like GeoParquet. In addition, Wherobots has made the Overture datasets available within the Wherobots Cloud platform as part of the Wherobots Spatial Catalog which is one of the fastest and most efficient ways to query and analyze the Overture datasets. By joining Overture Maps Foundation as Contributing Members Wherobots will continue to support the ongoing development, distribution, and evolution of this critical open dataset that enables developers and data practitioners to make sense of the world around us. “Overture Maps’ mission is about more than building open map data. It is also about helping users access, discover and use that data, whether for building map applications or for spatial ETL, analytics and intelligence,” said Marc Prioleau, executive director of the Overture Maps Foundation. “Wherobots has already contributed to the project through  its support of Overture data on Apache Sedona and we look forward to working with them even more closely in the future as a member of the team.” — Marc Prioleau, Executive Director, Overture Maps Foundation About Overture Maps Foundation Founded in 2022, Overture Maps Foundation is the world’s leading home for collaboration on the development of reliable, easy-to-use, and interoperable open map data that will power current and next-generation map products. These interoperable set of map data assets are the basis for extensibility, enabling companies to contribute their own data. Members combine resources to build map data that is complete, accurate, and refreshed as the physical world changes. Map data will be open and extensible by all under an open data license. You can learn more about Overture Maps Foundation at overturemaps.org. Why Supporting Planetary Scale Open Map Data Is Important As the Spatial Intelligence Cloud, the Wherobots platform enables data practitioners to create large-scale spatial data products and for organizations to find insights in spatial data at scale. We do this by supporting the open-source Apache Sedona project that adds spatial functionality to distributed compute frameworks. We then build on top of Apache Sedona to manage the infrastructure needed for large-scale geospatial intelligence with a serverless architecture. And additionally extend the developer experience of Apache Sedona in Wherobots Cloud with APIs, governance and optimization of spatial joins and other spatial operations. Wherobots’ mission is to unlock spatial intelligence of earth, society, and business, at a planetary scale. Global scale open data is a key component to enabling this mission to understanding the world. Overture Maps Foundation data provides an important component toward enabling this mission, while aligning with our vision of open data architecture. Similarly, assembling and making sense of planetary-scale datasets like the Overture data requires the usage of scalable cloud-native geospatial technology which aligns perfectly with Wherobots’ mission. Finally, Wherobots Cloud offers a cloud-native platform for geospatial analytics while also supporting an open data infrastructure. To learn more about how Wherobots Cloud is pushing forward the state of geospatial intelligence, see our blog post covering the latest Wherobots release: Introducing WherobotsAI for Planetary Inference, and Capabilities That Modernize Spatial Intelligence At Scale. What’s Next For Wherobots And Overture We’re committed to continuing to support the development and evolution of both Overture Maps Foundation as an organization, and Overture’s adoption of cloud-native geospatial technologies. We’re excited to see where we can go with planetary-scale open map data for the world. As an example of the type of large-scale data processing Wherobots Cloud enables with Overture data, we recently demonstrated how to make use of the Wherobots VTiles distributed vector tiles generator to generate global PMTiles of Overture data in 26 minutes and also how to analyze the Overture Places dataset to efficiently execute spatial queries to find insights into urban dynamics. To get started working with Overture data today in Wherobots Cloud create a free Wherobots Cloud account and run some of the example tutorial notebooks available within that demonstrate how to query, analyze, and visualize Overture data (as well as other large-scale datasets and use cases). Want to keep up to date with the latest news from the Wherobots and Apache Sedona community? Sign up for the The Spatial Intelligence Newsletter: Frequently Asked Questions What is Wherobots’ relationship to Overture Maps Foundation? Wherobots is a Contributing Member. It already supported Overture through Apache Sedona and by publishing Overture tables in the Havasu Catalog. What is the Overture Maps Foundation? Founded in 2022, it is a collaboration to develop reliable, easy-to-use, interoperable open map data that members can extend with their own data under an open license. How can I analyze Overture data in Wherobots? Create a free Wherobots Cloud account and run the tutorial notebooks that query, analyze, and visualize Overture, or use the copy already loaded in the Spatial Catalog. What Overture-scale example does this announcement cite? Generating global PMTiles of Overture data with Wherobots VTiles in 26 minutes, plus spatial queries on the Overture Places dataset. --- ## Generate Global PMTiles in 26 Minutes: Processing 2.3B Overture Maps Data URL: https://wherobots.com/blog/generate-pmtiles-overture-maps-wherobotsdb-vtiles/ Updated: 2026-10-19 Overview: PMTiles Generation at Planetary Scale WherobotsDB VTiles generates global PMTiles from Overture Maps data in 26 minutes by processing billions of features with distributed computation. The system handles three datasets: Places (50M features, 2m 23s), Buildings (2.3B features, 26 minutes), and Division Areas (1M features, optimized to 10 minutes with feature filters). Key takeawaysWherobotsDB VTiles generated planetary PMTiles from Overture on a Tokyo (large) Professional runtime. Places: 50 million features in 2 minutes 23 seconds (28.1 GB, zooms 6–15); Buildings: 2.3 billion features in 26 minutes (438.4 GB, zooms 10–15).Division areas (about 1 million polygons) without a feature filter took 3+ hours and produced 158.0 GB at zooms 3–15, because large country outlines can land in millions of tiles.A subtype-by-zoom feature filter cut division-area generation to 9 minutes 47 seconds and 8.9 GB (94% faster and 94% smaller). It shows countries only at low zooms and neighborhoods only at high zooms.PMTiles is a cloud-native archive so individual vector tiles can be requested directly from S3 without a tile server. Wherobots also published a viewer at tile-viewer.wherobots.com and a get_signed_url helper for private buckets.Wherobots 1.3.1 adds GenerationConfig.repartition_frequency (2 or 4) to rebalance partitions when large geometries split unevenly during zoom-in. Key capabilities: Processes 2.3 billion building features in 26 minutes Reduces division area processing from 3 hours to 10 minutes with feature filters Generates cloud-native PMTiles format for direct S3 queries Scales to planetary datasets using Apache Sedona and Spark This article demonstrates how to use WherobotsDB VTiles to generate vector tiles for three planetary-scale Overture Maps Foundation datasets in PMTiles format: Places, Buildings, and Division Areas, with feature filtering and distributed computation across billions of features. What are Vector Tiles and PMTiles? Vector tiles and PMTiles together make it possible to store, render, and serve large-scale maps efficiently in the cloud. Vector tiles are small chunks of map data that allow for efficient and customizable map rendering at varying zoom levels. They contain geometric and attribute data, for example roads and their names, that facilitate dynamic styling of map features on the fly, offering more flexibility and interactivity. PMTiles is a cloud-native file format that is designed for holding an entire collection of tiles, in this case vector tiles. The PMTiles format enables individual tiles to be queried directly from cloud object storage like Amazon S3. By querying directly from cloud storage, you no longer need to set up and manage dedicated infrastructure, reducing your costs, effort, and time-to-tile-generation. Key terms: Vector tiles: Geometric and attribute data chunks that enable dynamic map styling at varying zoom levels PMTiles: Cloud-native archive format for storing entire tile collections with direct S3 query support Feature filtering: Method to control which features appear at specific zoom levels based on geometry size and type Overture Maps: Open-source geospatial dataset including 2.3B+ buildings, 50M+ places, and administrative boundaries Build PM Tiles with this interactive notebook Launch Notebook How to Visualize and Inspect PMTiles If you’re sharing, inspecting, or debugging tiles you’ll need to visualize them. To make these processes easier, Wherobots created a tile viewer site, available at tile-viewer.wherobots.com. This tool comes from the PMTiles github repository, and it has offers the following features: Viewing tiles with a dark themed basemap Inspecting individual tiles, selected from a list of all the tiles in the set Inspecting the metadata and header information of the PMTiles file This viewer takes a url for a tileset. If your tiles are stored in a private S3 bucket you will need to generate a signed URL. Wherobots Cloud has a function for converting your S3 URI to a signed url: from wherobots.tools.utility.s3_utils import get_signed_url get_signed_url(my_s3_path, expiration_in_seconds) my_s3_path will be an s3 uri, like s3://myBucket/my/prefix/to/tiles.pmtiles and expiration_in_seconds will be an int representing the number of seconds the signed url will be valid for. The tile viewer will be used to explore the tiles we generate in our examples. PMTiles Generation Examples: Overture Maps The following examples show tile generation using VTiles for three Overture layers at a planetary scale. Because we are working with planetary scale datasets and want quick results, we will use the large runtimes available in the professional tier of Wherobots Cloud. Tile generation time is provided in each example, and includes time to load the input data, transform it, generate tiles, and save the PMTiles file in an S3 bucket. It does not include the time to start the cluster. To run the examples below, just make sure your sedona session is started: from sedona.spark import SedonaContext config = SedonaContext.builder().getOrCreate() sedona = SedonaContext.create(config) Generating PMTiles for Overture Places Dataset (50M Features) We start by creating PMTiles for the places dataset. With VTiles, this is a straightforward case for several reasons: The dataset contains only points. A point feature rarely spans multiple tiles as it has no dimensions. The tile generation time is strongly influenced by the sum of the number of features multiplied by the number of tiles which that feature intersects. At 50 million records, this is a relatively small dataset compared to the buildings dataset at 2.3 billion features. We will do minimal customization. VTiles’ feature filters allow us to control which features go into which tiles based on the tile id (x, y, z) and the feature itself (area, length, and user-provided columns). We will go more in depth on feature filters in the division areas example. import pyspark.sql.functions as f import os from wherobots.vtiles import GenerationConfig, generate_pmtiles generate_pmtiles( sedona.table("wherobots_open_data.overture_2024_05_16.places_place").select( "geometry", f.col("names.primary").alias("name"), f.col("categories.main").alias("category"), f.lit('places').alias('layer'), ), os.getenv("USER_S3_PATH") + "tile_blog/places.pmtiles", GenerationConfig(6, 15) ) This example generates a PMTiles file for zooms 6 through 15. Since the places dataset contains features that are not relevant at a global level, we selected a minimum zoom of 6, about the size of a large European country. The max zoom of 15 is selected because the precision provided should be sufficient and overzooming means that our places will still render at higher zooms. The OpenStreetMap wiki has a helpful page about how large a tile is at each zoom level. The name and category of each place will be included in the tiles. Performance Results: Dataset size: 50 million features Processing time: 2 minutes 23 seconds Output file size: 28.1 GB Zoom levels: 6-15 Runtime: Tokyo (large) Generating PMTiles for Overture Buildings Dataset (2.3B Features) This example generates tiles for all buildings in the Overture building dataset. This is about 2.3 billion features. The roughly uniform size of the features and the relatively small size of buildings relative to the higher zoom tiles means that the number of (feature, tile) combinations is similar to |features| * |zooms|. Because of this homogeneity, we can expect a quick execution without the use of a feature filter. This example represents a typical use case where there is a very large number of features and where the extent of a tile at maximum zoom is larger than the size of a feature. import pyspark.sql.functions as f import os from wherobots.vtiles import GenerationConfig, generate_pmtiles generate_pmtiles( sedona.table("wherobots_open_data.overture_2024_05_16.buildings_building").select( "geometry", f.lit('buildings').alias('layer'), ), os.getenv("USER_S3_PATH") + "tile_blog/buildings.pmtiles", GenerationConfig(10, 15) ) This example generates a PMTiles file for zooms 10 through 15. The minimum zoom of 10 was selected because buildings aren’t useful at lower zooms for most use cases. The max zoom of 15 was selected because the precision provided should be sufficient and overzooming means that our buildings will still render at higher zooms. The properties of a very large percentage of the Overture buildings are null so we haven’t included any here. Performance Results: Dataset size: 2.3 billion features Processing time: 26 minutes Output file size: 438.4 GB Zoom levels: 10-15 Runtime: Tokyo (large) Generating PMTiles for Overture Division Areas Dataset The third example creates tiles for all polygons and multipolygons in the Overture division areas dataset. This dataset is just under one million records. Despite its small size, this dataset can be challenging to process. It contains polygons and multipolygons representing areas, from countries which are large and highly detailed, to small neighborhoods with minimal detail. The appropriate min/max zoom for countries and neighborhoods is very different. Recall from the places example that the amount of work the system must do is strongly related to the number of (feature, tile) pairs. A country outline like Canada might cover an entire tile at zoom 5. It will be in roughly 2 * 4^(max_zoom - 5) tiles across all zooms; if max_zoom is 15, that’s over 2 million tiles. You can quickly wind up with an unexpectedly large execution time and tiles archive if you do not take this into account. Most use cases will benefit from setting different min and max zooms for different features, which you can do in VTiles via a feature filter. Let’s first profile the base case with no feature filter. import pyspark.sql.functions as f import os from wherobots.vtiles import GenerationConfig, generate_pmtiles generate_pmtiles( sedona.table("wherobots_open_data.overture_2024_05_16.divisions_division_area").select( "geometry", f.col("names.primary").alias("name"), f.col("subtype").alias('layer'), ), os.getenv("USER_S3_PATH") + "tile_blog/division_area.pmtiles", GenerationConfig(3, 15) ) Performance Results (Without Optimization): Dataset size: 1 million features Processing time: 3+ hours Output file size: 158.0 GB Zoom levels: 3-15 Runtime: Tokyo (large) Issue: Large geometries like countries span millions of tiles How to Optimize PMTiles Generation with Feature Filters We can significantly accelerate the execution time of this example using the VTiles feature filters. These feature filters are most commonly used to determine what features should be in a tile on the basis of a category and the zoom level. In this case we will only show countries at lower zooms and neighborhoods at the highest zoom levels. The visual impact of a feature that is much larger than the tile is minimal in typical use cases. The visual impact of a neighborhood is null when it’s smaller than the tile can resolve; it is literally invisible, or perhaps a single pixel. By excluding these features that add no visual information, we save processing time and storage costs, as well as increase the performance of serving the now-smaller tiles. Here is an example of using feature filters to improve performance of this division area generation task: import pyspark.sql.functions as f import os from wherobots.vtiles import GenerationConfig, generate_pmtiles generate_pmtiles( sedona.table("wherobots_open_data.overture_2024_05_16.divisions_division_area").select( "geometry", f.col("names.primary").alias("name"), f.col("subtype").alias('layer'), ), os.getenv("USER_S3_PATH") + "tile_blog/division_area_filtered.pmtiles", GenerationConfig( min_zoom=2, max_zoom=15, feature_filter = ( ((f.col("subType") == f.lit("country")) & (f.col("tile.z") < f.lit(7))) | ((f.col("subType") == f.lit("region")) & (f.lit(3) < f.col("tile.z")) & (f.col("tile.z") < f.lit(10))) | ((f.col("subType") == f.lit("county")) & (f.lit(9) < f.col("tile.z")) & (f.col("tile.z") < f.lit(12))) | ((f.col("subType") == f.lit("locality")) & (f.lit(10) < f.col("tile.z")) & (f.col("tile.z") < f.lit(14))) | ((f.col("subType") == f.lit("localadmin")) & (f.lit(13) < f.col("tile.z"))) | ((f.col("subType") == f.lit("neighborhood")) & (f.lit(13) < f.col("tile.z"))) ) ) ) Performance Results: Dataset size: 1 million features (filtered by zoom/subtype) Processing time: 9 minutes 47 seconds Output file size: 8.9 GB Zoom levels: 2-15 (filtered by feature type) Runtime: Tokyo (large) Improvement: 94% faster processing, 94% smaller file size Improving PMTiles Performance Without Feature Filters We know that there are use cases with large geometries where it might be difficult to write an effective feature filter or it may be undesirable to filter. For those use cases we have launched a feature in Wherobots 1.3.1 to improve tile generation performance. This will be an option on the GenerationConfig called repartition_frequency. When features are repeatedly split as the algorithm zooms in, those child features wind up in the same partition. This can cause well partitioned input datasets to become skewed by even just a single large record. Setting a repartition frequency to 2 or 4 can help to keep utilization of the cluster high by keeping partitions of roughly uniform size. PMTiles Generation Performance Summary WherobotsDB VTiles is a fast and cost-effective solution for generating tiles from global datasets. The Apache Spark-based runtime powered by Apache Sedona enables straightforward data loading and transformation, delivering proven performance at planetary scale: Performance metrics: 2.3 billion building features processed in 26 minutes 94% performance improvement with feature filtering (3+ hours → 10 minutes) 94% file size reduction (158 GB → 8.9 GB) Direct S3 querying without tile server infrastructure Best practices for optimization: Apply feature filters to match geometry size with zoom level resolution Use repartitioning for datasets with large, irregular geometries Set zoom ranges appropriate to feature type (buildings: 10-15, places: 6-15) Leverage Apache Sedona for data loading and transformation Feature filters let you curate tile contents to match your specific use cases and performance goals. Try VTiles with your own data on Wherobots Cloud. Start building with Wherobots Get Started Frequently Asked Questions How long does it take to build global Overture buildings PMTiles? 26 minutes on a Tokyo (large) runtime for 2.3 billion building features at zooms 10–15, writing a 438.4 GB PMTiles file. Cluster startup time is not included. How fast are Overture Places tiles? 50 million point features generated in 2 minutes 23 seconds (28.1 GB) for zooms 6–15 on the same Tokyo large runtime. What is a VTiles feature filter? A SQL expression on tile.z and feature attributes that drops geometries that add no visual value at a zoom, cutting work and file size. For example, it can show countries only below zoom 7 and neighborhoods only above zoom 13. Do I need a tile server for PMTiles? No. PMTiles lets clients query tiles directly from object storage such as Amazon S3. The post uses Wherobots Cloud to write the archive and optionally sign a URL for the tile viewer. --- ## WherobotsAI Map Matching: Turn GPS Tracks into Road-Aligned Trip Insights at Scale URL: https://wherobots.com/blog/wherobotsai-map-matching-telematics-gps-road-segments/ Updated: 2026-10-19 What is Map Matching? GPS data is inherently noisy and often lacks precision, which can make it challenging to extract accurate insights. This imprecision means that the GPS points logged may not accurately represent the actual locations where a device was. For example, GPS data from a drive around a lake may incorrectly include points that are over the water! Key takeawaysMap matching reconstructs the most likely path on known road or trail segments from noisy GPS samples, instead of dropping outliers. Wherobots Map Matching uses a Hidden Markov Model approach in the lineage of Newson and Krumm, distributed across Wherobots rather than a single machine or per-trip REST API.Public list prices cited as of July 2024 for matching 1 million trips: Mapbox $1,600, HERE Maps $4,400, Google Maps Platform $8,000. Wherobots Map Matching is about $10 per million trips.A US-scale map matching job processed 90 million trips in 1.5 hours on the Wherobots 2XL runtime, about 1 million trips per minute.It cost $873 (average $9.70 per million trips), described as 99% less expensive than Mapbox.The API takes a trajectories DataFrame and a road-segments DataFrame (OSM can be loaded with matcher.load_osm) and returns observed_points, matched_points, and matched_nodes. The walkthrough uses the VED dataset and Ann Arbor OSM.Map matching prepares GPS data for satellite and GPS-based navigation, freight tracking, insurance risk, self-driving telematics, and transportation planning. Open-source options such as Valhalla and GraphHopper are single-machine; commercial REST APIs are costly at population scale. See how to run it now Launch Notebook To address these inaccuracies, teams commonly use two approaches: Identifying and Dropping Erroneous Points: This method involves manually or algorithmically filtering out GPS points that are clearly incorrect. However, this approach can reduce analytical accuracy, be costly, and is time-intensive. Map Matching Techniques: A smarter and more effective approach involves using map matching techniques. These techniques take the noisy GPS data points and compute the most likely path taken based on known transportation segments such as roadways or trails. Wherobots Map Matching offers an advanced solution for this problem that’s significantly more performant and 99% lower cost than Mapbox, Google Maps, or HERE maps alternatives. It performs map matching with high scale on millions or even billions of trips with ease and performance, ensuring that the GPS data aligns accurately with the actual paths most likely taken. An illustration of map matching. Blue dots: GPS samples, Green line: matched trajectory. Map matching is a common solution for preparing GPS data for use in a wide range of applications including: Sattelite & GPS based navigation GPS tracking of freight Assessing risk of driving behavior for improved insurance pricing Post hoc analysis of self driving car trips for telematics teams Transportation engineering and urban planning The objective of map matching is to accurately determine which road or path in the digital map corresponds to the observed geographic coordinates, considering factors such as the accuracy of the location data, the density and layout of the road network, and the speed and direction of travel. Existing Solutions for Map Matching Most map matching implementations are variants of the Hidden Markov Model (HMM)-based algorithm described by Newson and Krumm in their seminal paper, “Hidden Markov Map Matching through Noise and Sparseness.” This foundational research has influenced a variety of map matching solutions available today. However, traditional HMM-based approaches have notable downsides when working with large-scale GPS datasets: Significant Costs: Many commercially available map matching APIs charge substantial fees for large-scale usage. Performance Issues: Traditional map matching algorithms, while accurate, are often not optimized for large-scale computation. They can be prohibitively slow, especially when dealing with extensive GPS data, as the underlying computation struggles to handle the data scale efficiently. These challenges highlight the need for more efficient and cost-effective solutions capable of handling large-scale GPS datasets without compromising on performance. RESTful API Map Matching Options The Mapbox Map Matching API, HERE Maps Route Matching API, and Google Roads API are powerful RESTful APIs for performing map matching. These solutions are particularly effective for small-scale applications. However, for large-scale applications, such as population-level analysis involving millions of trajectories, the costs can become prohibitively high. For example, as of July 2024, the approximate costs for matching 1 million trips are: Mapbox: $1,600 HERE Maps: $4,400 Google Maps Platform: $8,000 Wherobots Map Matching: ~$10 (see below) These prices are based on public pricing pages and do not consider any potential volume-based discounts that may be available. While these APIs provide robust and accurate map matching capabilities, organizations seeking to perform extensive analyses often must explore more cost-effective alternatives. Open-Source Map Matching Solutions Open-source software such as such as Valhalla or GraphHopper can also be used for map matching. However, these solutions are designed for use on a single-machine. If your map matching workload exceeds the capacity that machine, your workload will suffer from extended processing times. Furthermore, you will end up running out of headroom if you are vertically scaling up the ladder of VM sizes. Meet Wherobots Map Matching Map Matching is a high performance, low cost, and planetary scale map matching capability for your telematics pipelines. Wherobots provides a scalable map matching feature designed for small to very large scale trajectory datasets. It works seamlessly with other Wherobots capabilities, which means you can implement data cleaning, data transformations, and map matching in one single (serverless) data processing pipeline. We’ll see how it works in the following sections. How it works Wherobots Map Matching takes a DataFrame containing trajectories and another DataFrame containing road segments, and produces a DataFrame containing map matched results. Here is a walk-through of using Wherobots Map Matching to match trajectories in the VED dataset to the OpenStreetMap (OSM) road network. 1. Preparing the Trajectory Data First, we load the trajectory data. We’ll use the preprocessed VED dataset stored as GeoParquet files for demonstration. dfPath = sedona.read.format("geoparquet").load("s3://wherobots-benchmark-prod/data/mm/ved/VED_traj/") The trajectory dataset should contain the following attributes: A unique ID for trips. In this example the ids attribute is the unique ID of each trip. A geometry attribute containing LineStrings, in this case the geometry attribute is for trip data. The rows in the trajectory DataFrame look like this: +---+-----+----+--------------------+--------------------+ |ids|VehId|Trip| coords| geometry| +---+-----+----+--------------------+--------------------+ | 0| 8| 706|[{0, 42.277558333...|LINESTRING (-83.6...| | 1| 8| 707|[{0, 42.277681388...|LINESTRING (-83.6...| | 2| 8| 708|[{0, 42.261997222...|LINESTRING (-83.7...| | 3| 10|1558|[{0, 42.277065833...|LINESTRING (-83.7...| | 4| 10|1561|[{0, 42.286599722...|LINESTRING (-83.7...| +---+-----+----+--------------------+--------------------+ only showing top 5 rows 2. Preparing the Road Network Data We’ll use the OpenStreetMap (OSM) data specific to the Ann Arbor, Michigan region to map match our trip data with. Wherobots provides an API for loading road network data from OSM XML files. from wherobots import matcher dfEdge = matcher.load_osm("s3://wherobots-examples/data/osm_AnnArbor_large.xml", "[car]") dfEdge.show(5) The loaded road network DataFrame looks like this: +--------------------+----------+--------+----------+-----------+----------+-----------+ | geometry| src| dst| src_lat| src_lon| dst_lat| dst_lon| +--------------------+----------+--------+----------+-----------+----------+-----------+ |LINESTRING (-83.7...| 68133325|27254523| 42.238819|-83.7390142|42.2386159|-83.7390153| |LINESTRING (-83.7...|9405840276|27254523|42.2386058|-83.7388915|42.2386159|-83.7390153| |LINESTRING (-83.7...| 68133353|27254523|42.2385675|-83.7390856|42.2386159|-83.7390153| |LINESTRING (-83.7...|2262917109|27254523|42.2384552|-83.7390313|42.2386159|-83.7390153| |LINESTRING (-83.7...|9979197063|27489080|42.3200426|-83.7272283|42.3200887|-83.7273003| +--------------------+----------+--------+----------+-----------+----------+-----------+ only showing top 5 rows Users can also prepare the road network data from any data source using any data processing procedures, as long as the schema of the road network DataFrame conforms to the requirement of the Map Matching API. 3. Run Map Matching Once the trajectories and road network data is ready, we can run matcher.match to match trajectories to the road network. dfMmResult = matcher.match(dfEdge, dfPath, "geometry", "geometry") The dfMmResult contains the trajectories snapped to the roads in matched_points attribute: +---+--------------------+--------------------+--------------------+ |ids| observed_points| matched_points| matched_nodes| +---+--------------------+--------------------+--------------------+ |275|LINESTRING (-83.6...|LINESTRING (-83.6...|[62574078, 773611...| |253|LINESTRING (-83.6...|LINESTRING (-83.6...|[5930199197, 6252...| | 88|LINESTRING (-83.7...|LINESTRING (-83.7...|[4931645364, 6249...| |561|LINESTRING (-83.6...|LINESTRING (-83.6...|[29314519, 773612...| |154|LINESTRING (-83.7...|LINESTRING (-83.7...|[5284529433, 6252...| +---+--------------------+--------------------+--------------------+ only showing top 5 rows We can visualize the map matching result using SedonaKepler to see what the matched trajectories look like: mapAll = SedonaKepler.create_map() SedonaKepler.add_df(mapAll, dfEdge, name="Road Network") SedonaKepler.add_df(mapAll, dfMmResult.selectExpr("observed_points AS geometry"), name="Observed Points") SedonaKepler.add_df(mapAll, dfMmResult.selectExpr("matched_points AS geometry"), name="Matched Points") mapAll The following figure shows the map matching results. The red lines are original trajectories, and the green lines are matched trajectories. We can see that the noisy original trajectories are all snapped to the road network. Performance We used Wherobots Map Matching to match 90 million trips across the entire US in just 1.5 hours on the Wherobots 2XL runtime, which equates to approximately 1 million trips per minute, at a cost of $873 (99% less expensive than Mapbox, while completing in a small fraction of the time). The average cost of matching 1 million trips is $9.70. Here’s how the cost of Map Matching 1 million trips in Wherobots compares to alternatives. Mapbox: $1,600 HERE Maps: $4,400 Google Maps Platform: $8,000 Wherobots Map Matching: $9.70 The “optimization magic” behind Wherobots Map Matching lies in how Wherobots intelligently and automatically co-partitions trajectory and road network datasets based on the spatial proximity of their elements, ensuring a balanced distribution of work. As a result, the computational load is balanced evenly through this partitioning strategy, and makes map matching with Wherobots highly efficient, scalable, and affordable compared to alternatives. Try It Out! You can try out Map Matching by starting a notebook environment in Wherobots Cloud and running our example notebook within Wherobots Cloud. notebook_example/python/wherobots-ai/mapmatching_example.ipynb You can also check out the Map Matching tutorial and reference documentation for more information! Try Map Matching Get Started Frequently Asked Questions How can I find a location using GPS coordinates? Map matching determines which road or path on a digital map corresponds to observed GPS coordinates. GPS data is noisy and often imprecise: a drive around a lake can incorrectly log points over water. Wherobots Map Matching snaps those points to known road or trail segments so the recorded location matches the path most likely taken. How much does map matching cost at scale? As of July 2024, approximate public list prices for matching 1 million trips were $1,600 for Mapbox, $4,400 for HERE Maps, and $8,000 for Google Maps Platform. Wherobots Map Matching costs about $10 per million trips. A US run of 90 million trips took 1.5 hours on the Wherobots 2XL runtime and cost $873. How does Wherobots Map Matching work? It takes a DataFrame of trajectories and a DataFrame of road segments, and returns a DataFrame of map-matched results. Road networks can be loaded from OpenStreetMap XML files. The walkthrough matches trips from the VED dataset to the OSM road network for Ann Arbor, Michigan. Why not use open-source map matching tools? Open-source tools such as Valhalla and GraphHopper are designed for a single machine. A workload that exceeds that machine’s capacity runs for longer, and scaling up to larger VMs eventually runs out of headroom. --- ## Unlock Satellite Imagery Insights with Wherobots Raster Inference URL: https://wherobots.com/blog/wherobotsai-for-raster-inference/ Updated: 2026-10-19 Editor’s note: Raster inference is now part of RasterFlow, the Wherobots engine for running computer vision models on satellite and aerial imagery. Key takeawaysWherobots Raster Inference (later folded into RasterFlow) runs open-source computer vision models on satellite and aerial rasters from SQL or Python, without requiring users to stand up GPU pipelines.Supported tasks are classification (RS_CLASSIFY), object detection (RS_BBOXES_DETECT), and semantic segmentation (RS_SEGMENT). Instance segmentation is not supported in this post.An Arizona solar-farm example processed an 85 GiB dataset with 2,200 scenes: 430 seconds on a Sedona (tiny) runtime and 246 seconds on a San Francisco (small) runtime. It then vectorized detections at 0.65 confidence with RS_SEGMENT_TO_GEOMS.The solar model comes from SATLAS (Allen AI, Apache 2.0). The post also points at TorchGeo models and says three models are hosted in Wherobots Cloud on GPU-optimized runtimes.Professional Edition via AWS Marketplace includes up to $400 in free credits. The authors say custom/BYO models are on the roadmap after this preview. UPDATE: Raster inference is included in Wherobots RasterFlow. See Wherobots Get Started with RasterFlow – Wherobots for the most up-to-date workflows. Recently we introduced Wherobots Raster Inference to unlock analytics on satellite and aerial imagery using SQL or Python. Raster Inference simplifies extracting insights from satellite and aerial imagery using SQL or Python, and is powered by open-source machine learning models. Below we’ll dig into the popular computer vision tasks that Raster Inference supports, describe how it works, and how you can use it to run batch inference to find and map electricity infrastructure. Watch the live demo of these capabilities here. The Power of Machine Learning with Satellite Imagery Petabytes of satellite imagery are generated each day all over the world in a dizzying number of sensor types and image resolutions. The applications for satellite imagery and other remote sensing data sources are broad and diverse. For example, satellites with consistent, continuous orbits are ideal for monitoring forest carbon stocks to validate carbon credits or estimating agricultural yields. However, this data has been inaccessible for most analysts and even seasoned ML practitioners because insight extraction required specialized skills. We’ve done the work to make insight extraction simple and accessible to more people. Raster Inference abstracts the complexity and scales to support planetary-scale imagery datasets, so you don’t need ML expertise to derive insights. In this blog, we explore the key features that make Raster Inference effective for land cover classification, solar farm mapping, and marine infrastructure detection. And, in the near future, you will be able to use Raster Inference with your own models! Introduction to Popular and Supported Machine Learning Tasks Raster Inference supports the three most common kinds of computer vision models that are applied to imagery: classification, object detection, and semantic segmentation. Instance segmentation (combines object localization and semantic segmentation) is another common type of model which is not currently supported, but let us know if you need by contacting us and we can add it to the roadmap. Computer Vision Detection Categories from Lin et al. Microsoft COCO: Common Objects in Context The figure above illustrates these tasks. Image classification is when an image is assigned one or more text labels. In image (a), the scene is assigned the labels “person”, “sheep”, and “dog”. Image (b) is an example of object localization (or object detection). Object localization creates bounding boxes around objects of interest and assigns labels. In this image, five sheep are localized separately along with one human and one dog. Finally, semantic segmentation is when each pixel is given a category label, as shown in image (c). Here we can see all the pixels belonging to sheep are labeled blue, the dog is labeled red, and the person is labeled teal. While these examples highlight detection tasks on regular imagery, these computer vision models can be applied to raster formatted imagery. Raster data formats are the most common data formats for satellite and aerial imagery. When objects of interest in raster imagery are localized, their bounding boxes can be georeferenced, which means that each pixel is localized to spatial coordinates, such as latitude and longitude. Therefore, georeferencing is object localization suited for spatial analytics. The example above shows various applications of object detection for localizing and classifying features in high resolution satellite and aerial imagery. This example comes from DOTA, a 15-class dataset of different objects in RGB and grayscale satellite imagery. Public datasets like DOTA are used to develop and benchmark machine learning models. Not only are there many publicly available object detection models, but also there are many semantic segmentation models. Sourced from “A Scale-Aware Masked Autoencoder for Multi-scale Geospatial Representation Learning”. Not every machine learning model should be treated equally, and each will have their own tradeoffs. You can see the difference between the ground truth image (human annotated buildings representing the real world) and segmentation results across two models (Scale-MAE and Vanilla MAE). These results are derived from the same image at two different resolutions (referred to as GSD, or Ground Sampling Distance). Scale-MAE is a model developed to handle detection tasks at various resolutions with different sensor inputs. It uses a similar MAE model architecture as the Vanilla MAE, but is trained specifically for detection tasks on overhead imagery that span different resolutions. The Vanilla MAE is not trained to handle varying resolutions in overhead imagery. It’s performance suffers in the top row and especially the bottom row, where resolution is coarser, as seen by the mismatch between Vanilla MAE and the ground truth image where many pixels are incorrectly classified. Satellite Analytics Before Raster Inference Without Raster Inference, typically a team who is looking to extract insights from overhead imagery using ML would need to: Deploy a distributed runtime to scale out workloads such as data loading, preprocessing, and inference. Develop functionality to operate on raster metadata to easily filter it by location to run inference workloads on specific areas of interest. Optimize models to run performantly on GPUs, which can involve complex rewrites of the underlying model prediction logic. Create and manage data preprocessing pipelines to normalize, resize, and collate raster imagery into the correct data type and size required by the model. Develop the logic to run data loading, preprocessing, and model inference efficiently at scale. Raster Inference and its SQL and Python APIs abstract this complexity so you and your team can easily perform inference on massive raster datasets. Raster Inference APIs for SQL and Python Raster Inference offers APIs in both SQL and Python to run inference tasks. These APIs are designed to be easy to use, even if you’re not a machine learning expert. RS_CLASSIFY can be used for scene classification, RS_BBOXES_DETECT for object detection, and RS_SEGMENT for semantic segmentation. Each function produces tabular results which can be georeferenced either for the scene, object, or segmentation depending on the function. The records can be joined or visualized with other data (geospatial or traditional) to curate enriched datasets and insights. Here are SQL and Python examples for RS_Segment. RS_SEGMENT('{model_id}', outdb_raster) AS segment_result df = df_raster_input.withColumn("segment_result", rs_segment(model_id, col("outdb_raster"))) Example: Mapping Electricity Infrastructure Imagine you want to optimize the location of new EV charging stations, but you want to target locations based on the availability of green energy sources, such as local solar farms. You can use Raster Inference to detect and locate solar farms and cross-reference these locations with internal data or other vector geometries that captures demand for EV charging. This use case will be demonstrated in our upcoming release webinar on July 10th. Let’s walk through how to use Raster Inference for this use case. First, we run predictions on rasters to find solar farms. The following code block that calls RS_SEGMENT shows how easy this is. CREATE OR REPLACE TEMP VIEW segment_fields AS ( SELECT outdb_raster, RS_SEGMENT('{model_id}', outdb_raster) AS segment_result FROM az_high_demand_with_scene ) The confidence_array column produced from RS_SEGMENT can be assigned the same geospatial coordinates as the raster input and converted to a vector that can be spatially joined and processed with WherobotsDB using RS_SEGMENT_TO_GEOMS. We select a confidence threshold of .65 so that we only georeference high confidence detections. WITH t AS ( SELECT RS_SEGMENT_TO_GEOMS(outdb_raster, confidence_array, array(1), class_map, 0.65) result FROM predictions_df ) SELECT result.* FROM t +----------+--------------------+--------------------+ | class|avg_confidence_score| geometry| +----------+--------------------+--------------------+ |Solar Farm| 0.7205783606825462|MULTIPOLYGON (((-...| |Solar Farm| 0.7273308333550763|MULTIPOLYGON (((-...| |Solar Farm| 0.7301468510823231|MULTIPOLYGON (((-...| |Solar Farm| 0.7180177244988899|MULTIPOLYGON (((-...| |Solar Farm| 0.728077805771141|MULTIPOLYGON (((-...| |Solar Farm| 0.7264981572898|MULTIPOLYGON (((-...| |Solar Farm| 0.7044100126912517|MULTIPOLYGON (((-...| |Solar Farm| 0.7137283466756343|MULTIPOLYGON (((-...| +----------+--------------------+--------------------+ This allows us to integrate the vectorized model predictions with other spatial datasets and easily visualize the results with SedonaKepler. Here Raster Inference runs on a 85 GiB dataset with 2,200 raster scenes for Arizona. Using a Sedona (tiny) runtime, Raster Inference completed in 430 seconds, predicting solar farms for all low cloud cover satellite images for the state of Arizona for the month of October. If we scale up our runtime to a San Francisco (small) runtime, the inference speed nearly doubles. In general, average bytes processed per second by Wherobots increases as datasets scale in size because startup costs are amortized over time. Processing speed also increases as runtimes scale in size. Inference time (seconds)Runtime Size430Sedona246San Francisco We use predictions from the output of Raster Inference to derive insights about which zip codes have the most solar farms, as shown below. This statement joins predicted solar farms with zip codes by location, then ranks zip codes by the pre-computed solar farm area within each zip code. We skipped this step for brevity but you can see it and others in the notebook example. az_solar_zip_codes = sedona.sql(""" SELECT solar_area, any_value(az_zta5.geometry) AS geometry, ZCTA5CE10 FROM predictions_polys JOIN az_zta5 WHERE ST_Intersects(az_zta5.geometry, predictions_polys.geometry) GROUP BY ZCTA5CE10 ORDER BY solar_area DESC """) These predictions are made possible by SATLAS, a family of machine learning models released with Apache 2.0 licensing from Allen AI. The solar model demonstrated above was derived from the SATLAS foundational model. This foundational model can be used as a building block to create models to address specific detection challenges like solar farm detection. Additionally, there are many other open source machine learning models available for deriving insights from satellite imagery, many of which are provided by the TorchGeo project. We are just beginning to explore what these models can achieve for planetary-scale monitoring. If you have a specific model you would like to see made available, please contact us to let us know. For detailed instructions on using Raster Inference, please refer to our example Jupyter notebooks in the documentation. Here are some links to get you started:https://docs.wherobots.com/latest/tutorials/wherobotsai/wherobots-inference/segmentation/ https://docs.wherobots.com/latest/api/wherobots-inference/pythondoc/inference/sql_functions Getting Started Getting started with Wherobots Raster Inference is easy. We’ve provided three models in Wherobots Cloud that can be used with our GPU optimized runtimes. Sign up for Wherobots Pro via the AWS Marketplace and get up to $400 in free credits. You can test out the Pro features, including Raster Inference. Stay tuned for updates on improvements to Raster Inference that will make it possible to run more models, including your own custom models. We’re excited to hear what models you’d like us to support, or the integrations you need to make running your own models even easier with Raster Inference. We can’t wait for your feedback and to see what you’ll create! Start building with Wherobots Get Started Frequently Asked Questions What is Wherobots Raster Inference? A managed way to run classification, object detection, and semantic segmentation on georeferenced satellite or aerial rasters using SQL functions or Python. The vectorized predictions can then be joined with other spatial data. Which SQL functions run inference? RS_CLASSIFY for scene classification, RS_BBOXES_DETECT for object detection, and RS_SEGMENT for semantic segmentation. RS_SEGMENT_TO_GEOMS georeferences a confidence array into polygons. How long did Arizona solar-farm inference take? 2,200 low-cloud-cover scenes (85 GiB) for October over Arizona finished in 430 seconds on a Sedona tiny runtime and 246 seconds on a San Francisco small runtime. Can I use my own model in this preview? Not yet in this June 2024 post. Three hosted models are provided; the authors say they will add more models, including customer models, and ask readers to request specific ones. --- ## Quickly and Easily Create Vector Tiles with Wherobots and Overture Maps Foundation Data URL: https://wherobots.com/blog/vector-tile-generation-pmtiles-wherobots/ Updated: 2026-10-19 Editor’s note: The Wherobots Spatial Data Catalog is now the Havasu Catalog. Generating map tiles can be challenging and expensive, especially when dealing with large datasets like those from the Overture Maps Foundation (Overture). It’s challenging and expensive because typical solutions are not scalable or performant, which forces you to build workarounds that waste your time and are not economical. Wherobots addresses these challenges using WherobotsDB, a purpose-built, planetary scale compute engine with a native vector tile generator (VTiles) that produces tiles in an easy to work with, cloud-native file format (PMTiles). Key takeawaysWherobotsDB VTiles generates vector tiles in PMTiles so clients can fetch tiles from S3 without a dedicated tile server.A demo clipped and unioned all 11 Overture layers for New York City from the Spatial Catalog (overture_2024_02_15) and wrote one PMTiles file in 79 seconds (74.7 MiB).Scaling to all transportation segments in New York State, with zoom-based feature filters (for example hiding driveways at state scale), finished in about 2.5 minutes (GenerationConfig min_zoom 4, max_zoom 16).The generator is distributed on WherobotsDB so tile jobs that previously crashed or took days on single-node tools can iterate in minutes.The NYC and New York State tiles from the blog are offered for free on AWS S3. A global Overture PMTiles set and a tile viewer are called out as coming next. In this post, we’ll show you how Wherobots makes generating vector tiles from billions of features at a large scale, a breeze! We’ll prove this to you using a demo that generates a tileset for all 11 Overture layers in New York City, and we’ll repeat this at a larger scale for all the transportation segments across the state of New York. What Are Vector Tiles and PMTiles? Vector tiles are small chunks of map data that allow for efficient rendering at varying zoom levels. Unlike raster tiles which are pre-rendered images, vector tiles contain attributes and geometric data that facilitate dynamic styling of map features on the fly, offering more flexibility and interactivity. PMTiles is a cloud-native file format that is designed for holding an entire collection of tiles, in this case vector tiles. The PMTiles format allows individual tiles to be queried directly from cloud object storage like Amazon S3. By querying directly from cloud storage, you no longer need to set up and manage dedicated infrastructure, reducing your costs and time-to-tile-generation. The Challenge of Creating Tiles in a Distributed Environment Generating tiles from worldwide map datasets was always a challenge. You had to process billions of geometric features using solutions that are not purpose-built for this scale, resulting in High compute costs from development and production runs as well as fixed infrastructure. Frequent crashes forcing developers to babysit and troubleshoot the system. Tiles that are out-of-date because tile generation is time consuming and difficult. Tile generation taking days or hours, vs minutes or seconds to complete. Benefits of Using Wherobots for Tile Generation Efficiency: Wherobots optimizes the tile generation process, making it faster and more cost efficient. Scalability: WherobotsDB and VTiles are part of a purpose-built system designed to handle large datasets without compromising performance, providing a resilient solution for your geospatial needs. Flexibility: VTiles accelerates time-to-production by allowing you to iterate faster using a more responsive, lower cost development experience. Wherobots for Highly Scalable Vector Tile Generation Wherobots VTiles, our new native vector tile generator, incorporates innovative algorithms for distributed tile generation on WherobotDB, a high performance spatial compute engine. VTiles is designed to generate vector tiles from small to planetary scale datasets quickly and cost-efficiently. Wherobots handles the heavy lifting and infrastructure management, ensuring the tile generation process is performant, scalable, and easy. We will prove this in the following demos. Demo: From NYC to NY State We’ll use Wherobots VTiles to generate PMTiles for all Overture layers in New York City. Then we will scale the demo up by generating PMTiles for all transportation segments in New York State, using feature filter optimizations. Step 1: Preparing the Data First, we need to load the administrative, places, transportation, base, and buildings layers (yes, all of them!) from the Overture data for New York City. The latest Overture dataset is included in the Wherobots Spatial Catalog out-of-the-box, which makes it easy to load all of these layers in a single statement. _aoi = "POLYGON ((-73.957901 40.885486, …, -73.957901 40.885486))" df_transportation_segment = sedona.sql(f""" SELECT ST_INTERSECTION(ST_GEOMFROMWKT("{_aoi}"),geometry), "transportation_segment" as layer FROM wherobots_open_data.overture_2024_02_15.transportation_segment t1 WHERE ST_INTERSECTS(ST_GeomFromText("{_aoi}"),geometry) """) Here we apply a spatial filter (WHERE ST_INTERSECTS()) and a “clipping” function (ST_INTERSECTION()) to reduce our data to our area of interest, New York City. We also add a layer attribute containing our layer name. You can add or bring in additional attributes if needed. This “load-intersect” statement is executed for each of the 11 Overture Maps Foundation layers in Wherobots and the resulting DataFrames are added to a list for the next step in data prep. We want to cut a single PMTile file for all the layers in one go, and to accomplish this all the layers need to be unioned together.  Here we iterate through the list of layers and perform the union with the DataFrame API. nyc_unioned_data = df_admins_administrativeBoundary for t in tables_4_tiles[1:]: nyc_unioned_data=nyc_unioned_data.union(t.where(ST_Intersects(t.geometry ,\ ST_GeomFromText(lit(_aoi)))).select \ ("layer",ST_Intersection(ST_GeomFromText(lit(_aoi)), t.geometry).alias("geometry"))) nyc_unioned_data = nyc_unioned_data.where(f'ST_IsEmpty(geometry) = False') Step 2: Generate the Tiles With our data prepared we are ready to kick off the tile generation process. This process looks like this: # Generate the tiles nyc_tiles_df = vtiles.generate(nyc_unioned_data) #Define storage endpoint nyc_full_tiles_path = os.getenv("USER_S3_PATH") + "nyc_tiles.pmtiles" #Define a vtile builder specifying the data for automatic schema discovery builder = vtiles.PMTilesConfigBuilder().from_features_data_frame(nyc_unioned_data)**** #Define the order in which to layer the tiles nyc_ordered_layers= [ buildings, places ..., base] builder.layers = nyc_ordered_layers #BUILD ALL THE TILES ordered_config= builder.build() #Write the tiles to storage vtiles.write_pmtiles(nyc_tiles_df, nyc_full_tiles_path, ordered_config) This process took 79 seconds and generated a 74.7 MiB file. You can visualize the results in Wherobots by calling vtiles.show_pmtiles(nyc_full_tiles_path) Wherobots VTiles breaks the dataset down into manageable chunks, processing each layer efficiently. The result is a single PMTile dataset that can be easily visualized and styled and served directly from S3. Step 3: Expanding to NY State Transportation Next, we scale the process up to cover all transportation segments in New York State. This involves a larger dataset, but WherobotsDB handles it seamlessly. The process is identical as above but this time we want to utilize zoom based feature filtering (do we really need to see driveways when viewing at the state scale?) in the vtiles.GenerationConfig() . gen_config = vtiles.GenerationConfig( # Minimum zoom level for generation min_zoom=4, # Maximum zoom level for generation max_zoom=16, feature_filter = ( when( # Only add motorway and trunk features to tiles level 8 and above (col("class").isin(["motorway", "trunk"])) & (col("tile.z") < 8), False) .when(…) … ).otherwise(True) # Default to rendering a feature ) ) We pass our configuration into VTiles: df_transportation_segment_tiles = vtiles.generate(df_transportation_segment,gen_config) and use the same vtiles.write_pmtiles() function as above. PMTile generation for NY state transportation segments completed in ~2.5 minutes. Wrapping Up Previously, generating vector tiles from large datasets, like those from the Overture Maps Foundation, was challenging. You now have a solution to these challenges. Wherobots makes tile generation at any scale, easy, reliable, and cost effective. We simplify the process by unlocking distributed tile generation, and we make it possible to visualize and share large-scale geospatial data efficiently. Whether you’re focusing on a single city like New York City, an entire state, or the entire planet, Wherobots provides tile generation capability that’s purpose-built for any scale. Ready to dive into vector tile generation with Wherobots? Start by signing up for a free Wherobots account, walk through this tutorial, connect Wherobots to your data in S3, and enjoy the benefits of efficient and flexible map visualization. Check out the WherobotsDB VTiles tutorial and reference documentation for more information Want More Tiles News at Wherobots? The tiles we generate in this blog are available for free via AWS S3 New York City is here New York State is here We are working on making a variety of global Overture PMTiles available for free via Amazon S3. We will document the process for and performance of preparing these tiles in a future publication. We are working on launching a tile viewer to help folks visualize and inspect the contents of PMTiles files. Start building with Wherobots Try Now Frequently Asked Questions What are vector tiles and PMTiles in this post? Vector tiles are chunks of geometry plus attributes that can be styled at render time. PMTiles packs a whole tileset into one cloud-native file that can be range-read from object storage such as S3. How long did NYC Overture tiles take? 79 seconds to generate a 74.7 MiB PMTiles file covering all 11 Overture layers clipped to New York City. How long did New York State transportation tiles take? About 2.5 minutes, using a feature filter so low zooms keep motorways and trunks while dropping features that are not useful at state scale. Where do I get the example tiles? The post says the NYC and New York State tiles generated for the blog are available for free via AWS S3, and that more global Overture PMTiles would follow. --- ## 🌶 Comparing taco chains :: a consumer retail cannibalization study with isochrones URL: https://wherobots.com/blog/real-estate-retail-cannibalization-with-isochrones/ Updated: 2026-10-19 Authors Ilya Marchenko Using Wherobots for a Retail Cannibalization Study Comparing Two Leading Taco Chains In this post, we explore how to implement a workflow from the commercial real estate (CRE) space using Wherobots Cloud. This workflow is commonly known as a cannibalization study, and we will be using WherobotsDB, POI data from OvertureMaps, the open source Valhalla API, and visualization capabilities offered by SedonaKepler. Key takeawaysThe notebook studies retail cannibalization between Torchy’s Tacos and Velvet Taco in Texas using Overture Places, 5-minute drive isochrones from the Valhalla API, H3, and Kontur population.Drive-time polygons are converted to H3 cells at resolution 8 (hex sides roughly 400 meters) and joined to Kontur US H3-8 population.About 1,546,765 people live within a 5-minute drive of a Torchy’s; about 750,360 live within 5 minutes of a Velvet Taco.97,903 people live within 5 minutes of more than one Torchy’s (about 6.3% of Torchy’s 5-minute population). 100,298 people are within 5 minutes of more than one Velvet Taco (about 13.4%).415,033 people live in the overlap of both chains’ 5-minute isochrones. More than half of Velvet Taco’s 5-minute population also lives near a Torchy’s. What is a retail cannibalization study? In CRE (consumer real estate), stakeholders are often interested in questions like “If we build a new fast food restaurant here, how will its performance be affected by other similar fast food locations that already exist nearby?”. The idea of the new fast food restaurant “eating into” the sales of other fast food restaurants that already exist nearby is what is known as ‘cannibalization’. The main objective of studying this phenomenon is to determine the extent to which a new store might divert sales from existing stores owned by the same company or brand and evaluate the overall impact on the company’s market share and profitability in the area. Cannibalization Study in Wherobots For this case study, we will look at two taco chains which are located primarily in Texas: Torchy’s Tacos and Velvet Taco. In general, information about the performance of individual locations and customer demographics are often proprietary information. We can, however, still learn a great deal about the potential for cannibalization both between these two chains as competitors, and between individual locations of each chain. We also know, based on our own experience, these chains compete with each other. Which taco shop to go to when we are visiting Texas is always a spicy debate. We begin by importing modules that will be useful to us as we go on. import geopandas as gpd import pandas as pd import requests from sedona.spark import * from pyspark.sql.functions import explode, array from pyspark.sql import functions as F Next, we can initiate a Sedona context. config = SedonaContext.builder().getOrCreate() sedona = SedonaContext.create(config) Identifying Points of Interest Now, we need to retrieve the locations of Torchy’s Tacos and Velvet Taco locations. In general, one can do this via a variety of both free and paid means. We will look at a simple, free approach that is made possible by the integration of Overture Maps data into the Wherobots environment: sedona.table("wherobots_open_data.overture.places_place"). \\ createOrReplaceTempView("places") We create a view of the Overture Maps places database, which contains information on points of interest (POI’s) worldwide. Now, we can select the POI’s which are relevant to this exercise: stores = sedona.sql(""" SELECT id, names.common[0].value as name, ST_X(geometry) as long, ST_Y(geometry) as lat, geometry, CASE WHEN names.common[0].value LIKE "%Torchy's Tacos%" THEN "Torchy's Tacos" ELSE 'Velvet Taco' END AS chain FROM places WHERE addresses[0].region = 'TX' AND (names.common[0].value LIKE "%Torchy's Tacos%" OR names.common[0].value LIKE '%Velvet Taco%') """) Calling stores.show() gives us a look at the spark DataFrame we created: +--------------------+--------------+-----------+----------+ | id| name| long| lat| +--------------------+--------------+-----------+----------+ |tmp_8104A79216254...|Torchy's Tacos| -98.59689| 29.60891| |tmp_D17CA8BD72325...|Torchy's Tacos| -97.74175| 30.29368| |tmp_F497329382C10...| Velvet Taco| -95.48866| 30.18314| |tmp_9B40A1BF3237E...|Torchy's Tacos| -96.805853| 32.909982| |tmp_38210E5EC047B...|Torchy's Tacos| -96.68755| 33.10118| |tmp_DF0C5DF6CA549...|Torchy's Tacos| -97.75159| 30.24542| |tmp_BE38CAC8D46CF...|Torchy's Tacos| -97.80877| 30.52676| |tmp_44390C4117BEA...|Torchy's Tacos| -97.82594| 30.4547| |tmp_8032605AA5BDC...| Velvet Taco| -96.469695| 32.898634| |tmp_0A2AA67757F42...|Torchy's Tacos| -96.44858| 32.90856| |tmp_643821EB9C104...|Torchy's Tacos| -97.11933| 32.94021| |tmp_0042962D27E06...| Velvet Taco|-95.3905374|29.7444214| |tmp_8D0E2246C3F36...|Torchy's Tacos| -97.15952| 33.22987| |tmp_CB939610BC175...|Torchy's Tacos| -95.62067| 29.60098| |tmp_54C9A79320840...|Torchy's Tacos| -97.75604| 30.37091| |tmp_96D7B4FBCB327...|Torchy's Tacos| -98.49816| 29.60937| |tmp_1BB732F35314D...| Velvet Taco| -95.41044| 29.804| |tmp_55787B14975DD...| Velvet Taco|-96.7173913|32.9758554| |tmp_7DC02C9CC1FAA...|Torchy's Tacos| -95.29544| 32.30361| |tmp_1987B31B9E24D...| Velvet Taco| -95.41006| 29.770256| +--------------------+--------------+-----------+----------+ only showing top 20 rows We’ve retrieved the latitude and longitude of our locations, as well as the name of the chain each location belongs to. We used the CASE WHEN statement in our query in order to simplify the location names. This way, we can easily select all the stores from the Torchy’s Tacos chain, for example, and not have to worry about individual locations being called things like “Torchy’s Tacos – Rice Village” or “Velvet Taco Midtown”, etc. We can also visualize these locations using SedonaKepler. First, we can create the map using the following snippet: location_map = SedonaKepler.create_map(stores, "Locations", config = location_map_cfg) Then, we can display the results by simply calling location_map in the notebook. For convenience, we included the location_map_cfg Python dict in our notebook, which stores the settings necessary for the map to be created with the locations color-coded by chain. If we wish to make modifications to the map and save the new configuration for later use, we can do so by calling location_map.config and saving the result either as a cell in our notebook or in a separate location_map_cfg.py file. Generating Isochrones Now, for each of these locations, we can generate a polygon known as an isochrone or drivetime. These polygons will represent the areas that are within a certain time’s drive from the given location. We will generate these drivetimes using the Valhalla isochrone api: def get_isochrone(lat, lng, costing, time_steps, name, location_id): url = "" params = { "locations": [{"lon": lng, "lat": lat}], "contours": [{"time": i} for i in time_steps], "costing": costing, "polygons": 1, } response = requests.post(url, json=params) if response: result = response.json() if 'error_code' not in result.keys(): df = gpd.GeoDataFrame.from_features(result) df['name'] = name df['id'] = location_id return df[['name','id','geometry']] The function takes as its input a latitude and longitude value, a costing paratemeter, a location name, and a location id. The output is a dataframe which contains a Shapely polygon representing the isochrone, along with the a name and id of the location the isochrone corresponds to. We have separate columns for a location id and a location name so that we can use the id column to examine isochrones for individual restaurants and we can use the name column to look at isochrones for each of the chains. The costing parameter can take on several different values (see the API reference here), and it can be used to create “drivetimes” assuming the user is either walking, driving, or taking public transport. We create a geoDataFrame of all of the 5-minute drivetimes for our taco restaurant locations drivetimes_5_min = pd.concat([get_isochrone(row.lat, row.long, 'auto', [5], row.chain, row.id) for row in stores.select('id','chain','lat','long').collect()]) and then save it to our S3 storage for later use: drivetimes_5_min.to_csv('s3://path/drivetimes_5_min_torchys_velvet.csv', index = False) Because we are using a free API and we have to create quite a few of these isochrones, we highly recommend saving the file for later analysis. For the purposes of this blog, we have provided a ready-made isochrone file here, which we can load into Wherobots with the following snippet: sedona.read.option('header','true').format('csv') .\\ load('s3://path/drivetimes_5_min_torchys_velvet.csv') .\\ createOrReplaceTempView('drivetimes_5_min') We can now visualize our drivetime polygons in SedonaKepler. As before, we first create the map with the snippet below. map_isochrones = sedona.read.option('header','true').format('csv'). \\ load('s3://path/drivetimes_5_min_torchys_velvet.csv') isochrone_map = SedonaKepler.create_map(map_isochrones, "Isochrones", config = isochrone_map_cfg) Now, we can display the result by calling isochrone_map . The Analysis At this point, we have a collection of the Torchy’s and Velvet Taco locations in Texas, and we know the areas which are within a 5-minute drive of each location. What we want to do now is to estimate the number of potential customers that live near each of these locations, and the extent to which these populations overlap. A First Look Before we look at how these two chains might compete with each other, let’s also take a look at the extent to which restaurants within each chain might be cannibalizing each others’ sales. A quick way to do this is by using the filtering feature in Kepler to look at isochrones for a single chain: We see that locations for each chain are fairly spread out and (at least at the 5-minute drivetime level), there is not a high degree of cannibalization within each chain. Looking at the isochrones for both chains, however, we notice that Velvet Taco locations often tend to be near Torchy’s Tacos locations (or vice-versa). At this point, all we have are qualitative statements based on these maps. Next, we will show how to use H3 and existing open-source datasets to make these statements more quantitative. Estimating Cannibalization Potential As we can see by looking at the map of isochrones above, they are highly irregular polygons which have a considerable amount of overlap. In general, these polygons are not described in a ‘nice’ way by any administrative boundaries such as census block groups, census tracts, etc. Therefore, we will have to be a little creative in order to estimate the population inside them. One way of doing this using the tools provided by Apache Sedona and Wherobots is to convert these polygons to H3 hexes. We can do this with the following snippet: sedona.sql(""" SELECT ST_H3CellIds(ST_GeomFromWKT(geometry), 8, false) AS h3, name, id FROM drivetimes_5_min """).select(explode('h3'), 'name','id').withColumnRenamed('col','h3') .\\ createOrReplaceTempView('h3_isochrones') This turns our table of drivetime polygons into a table where each row represents a hexagon with sides roughly 400m long, which is a part of a drivetime polygon. We also record the chain that these hexagons are associated to (the chain that the polygon they came from belongs to). We store each hexagon in its own row because this will simplify the process of estimating population later on. Although the question of estimating population inside individual H3 hexes is also a difficult one (we will release a notebook on this soon), open-source datasets with this information are available online, and we will use one such dataset, provided by Kontur: kontur = sedona.read.option('header','true') .\\ load('s3://path/us_h3_8_pop.geojson', format="json") .\\ drop('_corrupt_record').dropna() .\\ selectExpr('CAST(CONV(properties.h3, 16, 10) AS BIGINT) AS h3', 'properties.population as population') kontur.createOrReplaceTempView('kontur') We can now enhance our h3_isochrones table with population counts for each H3 hex: sedona.sql(""" SELECT ST_H3CellIds(ST_GeomFromWKT(geometry), 8, false) AS h3, name, id FROM drivetimes_5_min """).select(explode('h3'), 'name','id').withColumnRenamed('col','h3') .\\ join(kontur, 'h3', 'left').distinct().createOrReplaceTempView('h3_isochrones') At this stage, we can also quickly compute the cannibalization potential within each chain. Using the following code, for example, we can estimate the number of people who live within a 5 minute drive of more than one Torcy’s Tacos: sedona.sql(""" SELECT ST_H3CellIds(ST_GeomFromWKT(geometry), 8, false) AS h3, name, id FROM drivetimes_5_min """).select(explode('h3'), 'name','id').withColumnRenamed('col','h3') .\\ join(kontur, 'h3', 'left').filter('name LIKE "%Torchy%"').select('h3','population') .\\ groupBy('h3').count().filter('count >= 2').join(kontur, 'h3', 'left').distinct() .\\ agg(F.sum('population')).collect()[0][0] 97903.0 We can easily change this code to compute the same information for Velvet Taco by changing filter('name LIKE "%Torchy%"') in line 4 of the above snippet to filter('name LIKE "%Velvet%"') . If we do this, we will see that 100298 people live within a 5 minute drive of more than one Velvet Taco. Thus, we see that the Torchy’s Tacos brand appears to be slightly better at avoiding canibalization among its own locations (especially given that Torchy’s Tacos has more locations than Velvet Taco). Now, we can run the following query to show the number of people in Texas who live within a 5 minutes drive of a Torchy’s Tacos: sedona.sql(""" WITH distinct_h3 (h3, population) AS ( SELECT DISTINCT h3, ANY_VALUE(population) FROM h3_isochrones WHERE name LIKE "%Torchy's%" GROUP BY h3 ) SELECT SUM(population) FROM distinct_h3 """).show() The reason we select distinct H3 hexes here is because a single hex can belong to more than one isochrone (as evidenced by the SedonaKepler visualizations above). We get the following output: +---------------+ |sum(population)| +---------------+ | 1546765.0| +---------------+ So roughly 1.5 million people in Texas live within a 5-minute drive of a Torchy’s Tacos location. Looking at our previous calculations for how many people live near more than one restaurant of the same chain, we can see that Torchy’s Tacos locations near each other cannibalize about 6.3% of the potential customers who live within 5 minutes of a Torchy’s location. Running a similar query for Velvet Taco tells us that roughly half as many people live within a 5-minute drive of a Velvet Taco: sedona.sql(""" WITH distinct_h3 (h3, population) AS ( SELECT DISTINCT h3, ANY_VALUE(population) FROM h3_isochrones WHERE name LIKE '%Velvet Taco%' GROUP BY h3 ) SELECT SUM(population) FROM distinct_h3 """).show() +---------------+ |sum(population)| +---------------+ | 750360.0| +---------------+ As before, we can also see that Velvet Taco locations near each other cannibalize about 13.4% of the potential customers who live within 5 minutes of a Velvet Taco location. Now, we can estimate the potential for cannibalization between these two chains: sedona.sql(""" WITH overlap_h3 (h3, population) AS ( SELECT DISTINCT a.h3, ANY_VALUE(a.population) FROM h3_isochrones a LEFT JOIN h3_isochrones b ON a.h3 = b.h3 WHERE a.name != b.name GROUP BY a.h3 ) SELECT sum(population) FROM overlap_h3 """).show() which gives: +---------------+ |sum(population)| +---------------+ | 415033.0| +---------------+ We can see that more than half of the people who live near a Velvet Taco location also live near a Torchy’s Tacos location and we can visualize this population overlap: isochrones_h3_map_data = sedona.sql(""" SELECT ST_H3CellIds(ST_GeomFromWKT(geometry), 8, false) AS h3, name, id FROM drivetimes_5_min """).select(explode('h3'), 'name','id').withColumnRenamed('col','h3') .\ join(kontur, 'h3', 'left').select('name','population',array('h3')).withColumnRenamed('array(h3)','h3').selectExpr('name','population','ST_H3ToGeom(h3)[0] AS geometry') isochrones_h3_map = SedonaKepler.create_map(isochrones_h3_map_data, 'Isochrones in H3', config = isochrones_h3_map_cfg) Create a Free Account Get Started Frequently Asked Questions What is a retail cannibalization study? It estimates how a new (or competing) store diverts customers from existing locations. It measures overlapping trade areas, in this post 5-minute drive isochrones, and the population inside those overlaps. Where do the store locations come from? Overture Maps places in Wherobots (wherobots_open_data.overture.places_place), filtered to Texas addresses whose names match Torchy’s Tacos or Velvet Taco. How is population inside an isochrone estimated? Irregular drive-time polygons are exploded to H3 resolution-8 cells and joined to Kontur’s US H3-8 population dataset, then distinct cells are summed so overlapping hexes are not double-counted. Which chain shows more self-cannibalization in this study? Velvet Taco: about 13.4% of people within 5 minutes of a Velvet Taco are also within 5 minutes of another Velvet Taco. The figure for Torchy’s is about 6.3%, even though Torchy’s has more locations. --- ## New Wherobots Cloud Features, How Overture Maps Uses Apache Sedona, Aircraft Data, & Spatial Lakehouses URL: https://wherobots.com/blog/wherobots-ai-features-overture-maps-apache-sedona-flight-analytics-spatial-data-lakehouse/ Updated: 2026-10-19 Welcome to This Month In Wherobots the monthly developer newsletter for the Wherobots & Apache Sedona community! In this edition we have a look at the latest Wherobots Cloud release, how the Overture Maps Foundation uses Apache Sedona to generate their data releases, processing a billion aircraft observations, building spatial data lakehouses with Iceberg Havasu, the new Apache Sedona 1.6.0 release, and more! Key takeawaysThis June 2024 “This Month In Wherobots” newsletter recaps other posts: Wherobots Raster Inference, Spatial SQL API drivers, and a scalable vector tile generator.It highlights Overture Maps using Apache Sedona to build partitioned GeoParquet releases, with featured community member Feng Jiang (Microsoft / Overture).Also recapped: a tutorial processing a billion aircraft observations with weather, a PyData + Neo4j species-graph workshop, Apache Sedona 1.6.0, and a Subsurface talk on Havasu Iceberg.Sedona 1.6.0 notes in this issue: Shapely 2.0 and GeoPandas 0.11.1+, enhanced geography support, new vector and raster functions, and Rasterio/NumPy UDFs.Listed events include a GeoParquet meetup in San Francisco on June 12 and an aircraft-data live demo on June 20. They also include a Wherobots 1.3 webinar on July 10 and Sedona office hours on July 2. Introducing WherobotsAI For Planetary Inference And Capabilities That Modernize Spatial Intelligence At Scale Wherobots announced significant new features in Wherobots Cloud to enable machine learning inference on satellite imagery via SQL, new Python and Java database drivers for interacting with WherobotsDB in your own analytics applications or data orchestration tooling, and a scalable vector tiles generator. These new enhancements are available now in Wherobots Cloud. Read The Blog Post or Register For The Webinar Making Overture Maps Data More Efficient With GeoParquet And Apache Sedona The Overture Maps Foundation publishes an open comprehensive global map dataset with layers for transportation, places, 3D buildings, and administrative boundaries. This data comes from multiple sources and is published in cloud-native GeoParquet format made publicly available for download in cloud object storage. In order to wrangle such a large planetary-scale dataset the Overture team uses Apache Sedona to prepare, process, and generate partitioned GeoParquet files. This blog post dives into the benefits of GeoParquet, how Overture uses Sedona to generate GeoParquet (including a dual Geohash partitioning and sorting method), and how to query and analyze the Overture Maps dataset using Wherobots Cloud. Read the article: Making Overture Maps Data More Efficient With GeoParquet And Apache Sedona Featured Community Member: Feng Jiang Our featured Apache Sedona and Wherobots Community Member this month is Feng Jiang, a Senior Software Engineer at Microsoft where he works with map and geospatial data at scale. Through his involvement with the Overture Maps Foundation he also helps maintain and publish the public Overture Maps dataset. In the blog post “Making Overture Maps Data More Efficient With GeoParquet And Apache Sedona” he shared some insights gained from working with Apache Sedona at Overture in the pipeline used to create and generate GeoParquet data of planetary-scale map data. Thanks for your contributions and being a part of the Apache Sedona community! Processing A Billion Aircraft Observations With Apache Sedona In Wherobots Cloud An important factor to consider when analyzing aircraft data is the potential impact of weather and especially severe weather events on aircraft flights. This tutorial uses public ADS-B aircraft trace data combined with weather data to identify which flights have the highest potential to be impacted by severe weather events. We also see how to combine real-time Doppler radar raster data as well as explore the performance of working with a billion row dataset for spatial operations like point-in-polygon searches and spatial joins. Read The Tutorial: Processing A Billion Aircraft Observations With Apache Sedona In Wherobots Cloud Training Series: Large-Scale Geospatial Analytics With Graphs And The PyData Ecosystem Choosing the right tool for the job is an important aspect of data science, and equally important is understanding how the tools fit together and can be used alongside each other. This hands-on workshop shows how to leverage the scale of Apache Sedona with Wherobots Cloud for geospatial data processing, alongside common Python tooling like Geopandas, and how to add graph analytics using Neo4j to our analysis toolkit. Using a dataset of species observations we build a species interaction graph to find which species share habitat overlap, a common workflow for conservation use cases. Watch The Workshop Recording: Large Scale Geospatial Analytics With Graphs And The PyData Ecosystem Apache Sedona 1.6 Release Version 1.6.0 of Apache Sedona is now available! This version includes support for Shapely 2.0 and GeoPandas 0.11.1+, enhanced support for geography data, new vector and raster functions, and tighter integration Python raster data workflows with support for Rasterio and NumPy User Defined Functions (UDFs). You can learn more about this release in the release notes. Read The Apache Sedona 1.6 Release Notes Building Spatial Data Lakehouses With Iceberg Havasu This talk from Subsurface 2024 introduces the Havasu spatial table format, an extension of Apache Iceberg used to build spatial data lakehouses. We learn about the motivation for adding spatial functionality to Iceberg, how Havasu Iceberg enables efficient spatial queries for both vector and raster data, and how to use familiar SQL table interface when building large-scale geospatial analytics applications. Watch The Recording: Building Spatial Data Lakehouses With Iceberg Havasu Upcoming Events GeoParquet Meetup SF (San Francisco – June 12) – Join the Geoparquet community Wednesday June 12th from 5:30-7pm at 9zero, the climate tech community space. Welcoming participants from across the geospatial and data ecosystem to discuss the latest enhancements and extensions to GeoParquet. Live Demo: Processing A Billion Aircraft Observations Combined With Weather Raster Data On Wherobots Cloud (Online – June 20th) – This live demo will show how to analyze real-world aircraft observations and weather data to identify flights impacted by severe weather events. Wherobots Cloud Release Overview: Introducing WherobotsAI, Spatial SQL API, & Vector Tiles (Online – July 10th) – Join the product management and engineering team at Wherobots for an overview of Wherobots 1.3 and the latest capabilities we are bringing for extensibility and AI. Apache Sedona Community Office Hour (Online – July 2nd) – Join the Apache Sedona community for updates on the state of Apache Sedona, presentation and demo of recent features, and provide your input into the roadmap, future plans, and contribution opportunities. Want to receive this monthly update in your inbox? Sign up for the The Spatial Intelligence Newsletter: Frequently Asked Questions What is in the June 2024 Wherobots newsletter? Pointers to the release of Wherobots AI features, the Spatial SQL API, and VTiles. The newsletter also links Overture GeoParquet + Sedona, a billion-row aircraft tutorial, a graphs workshop, Sedona 1.6.0, and a Havasu lakehouse talk. What did Apache Sedona 1.6.0 add according to this issue? Support for Shapely 2.0 and GeoPandas 0.11.1+, enhanced geography data, new vector and raster functions, and tighter Python raster workflows with Rasterio and NumPy UDFs. How does Overture use Apache Sedona in this recap? To prepare, process, and generate partitioned GeoParquet files for planetary-scale map layers (transportation, places, 3D buildings, administrative boundaries), including a dual Geohash partitioning and sorting method. Is this a product-launch post? No. It is a monthly community newsletter that links out to launch and tutorial posts published separately. --- ## Introducing WherobotsAI for planetary inference, and capabilities that modernize spatial intelligence at scale URL: https://wherobots.com/blog/wherobots-ai-spatial-sql-vector-tile-gen/ Updated: 2026-10-19 Editor’s note: Raster inference is now part of RasterFlow, the Wherobots engine for running computer vision models on satellite and aerial imagery. Key takeawaysThis release previews Wherobots Raster Inference for detect/classify/segment on satellite imagery via SQL/Python. It also adds Map Matching, which snaps noisy GPS to road segments at trip scale.Raster Inference is fully managed on GPU runtimes in Professional Edition. The post says you can detect, segment, and classify solar farms, land cover, and marine infrastructure from terabyte-scale Sentinel-2 imagery in under half an hour.WherobotsDB is described as up to 60x more performant for spatial joins than popular general-purpose big-data engines and warehouses, and up to 20x faster than Apache Sedona alone.The new Spatial SQL API exposes WherobotsDB to remote SQL IDEs (Harlequin), Python and Java client SDKs, QGIS, and an Apache Airflow provider (WherobotsSqlOperator) for scheduled spatial ETL.VTiles generated PMTiles for all Overture buildings, zooms 4–15, planet-wide, in 23 minutes on a Tokyo runtime. UPDATE: Raster inference is included in Wherobots RasterFlow. See Wherobots Get Started with RasterFlow – Wherobots for the most up-to-date workflows. We are excited to announce a preview of WherobotsAI, our new suite of AI and ML powered capabilities that unlock spatial intelligence in satellite imagery and GPS location data. Additionally, we are bringing the high-performance of WherobotsDB to your favorite data applications with a Spatial SQL API that integrates WherobotsDB with more interfaces including Apache Airflow for Spatial ETL. Finally, we’re introducing the most scalable vector tile generator on earth to make it easier for teams to produce engaging and interactive map applications. All of these new features are capable of operating on planetary-scale data. Watch the walkthrough of this release here. Wherobots Mission and Vision Before we dive into this release, we think it’s important to understand how these capabilities fit into our mission, our product principles, and vision for the Spatial Intelligence Cloud so you can see where we are headed. Our MissionThese new capabilities are core to Wherobots’ mission, which is to unlock spatial intelligence of earth, society, and business, at a planetary scale. We will do this by making it extremely easy to utilize data and AI technology purpose-built for creating spatial intelligence that’s cloud-native and compatible with modern open data architectures. Our Product Principles We’re building the spatial intelligence platform for modern organizations. Every organization with a mission directly linked to the performance of tangible assets, goods and services, or data products about what’s happening in the physical world, will need a spatial intelligence platform to be competitive, sustainable, and climate adaptive. It delivers intelligence for the greater good. Teams and their organizations want to analyze their worlds to create a net positive impact for business, society, and the earth. It’s purpose-built yet simple. Spatial intelligence won’t scale through in-house ‘spatial experts’, or through general purpose architectures that are not optimized for spatial workloads or development experiences. It’s efficient at any scale. Maximal performance, scale, and cost efficiency can only be achieved through a cloud-native, serverless solution. It creates intelligence with AI. Every organization will need AI alongside modern analytics to create spatial intelligence. It’s open by default. Pace of innovation depends on choice. Organizations that adopt cloud-native, open source compatible, and modern open data architectures will innovate faster because they have more choices in the solutions they can use. Our VisionWe exist because creating spatial intelligence at-scale is hard. Our contributions to Apache Sedona, leadership in the open geospatial domain, and investments in Wherobots Cloud have, and will make it easier. Users of Apache Sedona, Wherobots customers, and ultimately any AI application will be enabled to support better decisions about our physical and virtual worlds. They will be able to create solutions to improve these worlds that were otherwise infeasible or too costly to build. And the solutions developed will have a positive impact on society, business, and earth — at a planetary scale. Introducing WherobotsAI There are petabytes of satellite or aerial imagery produced every day. Yet for most analysts, scientists, and developers, these datasets are analytically inaccessible outside of the naked eye. As a result most organizations still rely on humans and their eyes, to analyze satellite or other forms of aerial imagery. Wherobots can already perform analytics of overhead imagery (also known as raster data) and geospatial objects (known as vector data) simultaneously at scale. But organizations also want to use modern AI and ML technologies to streamline and scale otherwise visual, single threaded tasks like object detection, classification, and segmentation from overhead imagery. Like satellite imagery that is generally hard to analyze, businesses also find it hard to analyze GPS data in their applications because it’s too noisy; points don’t always correspond to the actual path taken. Teams need an easy solution for snapping noisy GPS data to road or other segment types, at any scale. Today we are announcing WherobotsAI which offers fully managed AI and machine learning capabilities that accelerate the development of spatial insights, for anyone familiar with SQL or Python. WherobotsAI capabilities include: [new] Raster Inference (preview): A first of its kind, Raster Inference unlocks the analytical potential of satellite or aerial imagery at a planetary scale, by integrating AI models with WherobotsDB to make it extremely easy to detect, classify, and segment features of interest in satellite and aerial images. You can see how easy it is to detect and georeference solar farms here, with just a few lines of SQL: SELECT outdb_raster, RS_SEGMENT(‘solar-satlas-sentinel2’, outdb_raster) AS solar_farm_result FROM df_raster_input These georeferenced predictions can be queried with WherobotsDB and can be interactively explored in a Wherobots notebook. Below is an example of detection of solar panels in SedonaKepler. The models and AI infrastructure powering Raster Inference are fully managed, which means there’s nothing to set up or configure. Today, you can use Raster Inference to detect, segment, and classify solar farms, land cover, and marine infrastructure from terabyte-scale Sentinel-2 true color and multispectral imagery datasets in under half an hour, on our GPU runtimes available in the Wherobots Professional Edition. Soon we will be making the inference metadata for the models public, so if your own models meet this standard, they are supported by Raster Inference. These models and datasets are just the starting point for WherobotsAI. We are looking forward to hearing from you to help us define the roadmap for what we should build support for next. Map Matching: If you need to analyze trips at scale, but struggle to wrangle noisy GPS data, Map Matching is capable of turning billions of noisy GPS pings into signal, by snapping shared points to road or other vector segments. Teams are using Map Matching to process hundreds of millions of vehicle trips per hour. This speed surpasses any current commercial solutions, all for a cost of just a few hundred dollars. Here’s an example of what Wherobots Map Matching does to improve the quality of your trip segments. Red and yellow line segments were created from raw, noisy GPS data. Green represents Map Matched segments. Visit the user documentation to learn more and get started with WherobotsAI. A Spatial SQL API for WherobotsDB WherobotsDB, our serverless, highly efficient compute engine compatible with Apache Sedona is up to 60x more performant for spatial joins than popular general purpose big data engines and warehouses, and up to 20x faster than Apache Sedona on its own. It will remain the most performant, earth-friendly solution for your spatial workloads at any scale. Until today, teams had two options for harnessing WherobotsDB: they could write and run queries in Wherobots managed notebooks, or run spatial ETL pipelines using the Wherobots jobs interface. Today, we’re enabling you to bring the utility of WherobotsDB to more interfaces with the new Spatial SQL API. Using this API, teams can remotely execute Spatial SQL queries using a remote SQL editor, build first-party applications using our client SDKs in Python (WherobotsDB API driver) and Java (Wherobots JDBC driver), or orchestrate spatial ETL pipelines using a Wherobots Apache Airflow provider. Run spatial queries with popular SQL IDEs The following is an example of how to integrate Harlequin, a popular SQL IDE with WherobotsDB. You’ll need a Wherobots API key to get started with Harlequin (or any remote client). API keys allow you to authenticate with Wherobots Cloud for programmatic access to Wherobots APIs and services. API keys can be created following a few steps in our user documentation. We will query WherobotsDB using Harlequin in the Airflow example later in this blog. $ pip install harlequin-wherobots $ harlequin -a wherobots --api-key $(< api.key) You can find more information on how to use Harlequin in its documentation, and on the WherobotsDB adapter on its GitHub repository. The Wherobots Python driver enables integration with many other tools as well. Here’s an example of using the Wherobots Python driver in the QGIS Python console to fetch points of interest from the Overture Maps dataset using Spatial SQL API. from wherobots.db import connect from wherobots.db.region import Region from wherobots.db.runtime import Runtime import geopandas from shapely import wkt with connect( token=os.environ.get("WBC_TOKEN"), runtime=Runtime.SEDONA, region=Region.AWS_US_WEST_2, host="api.cloud.wherobots.com" ) as conn: curr = conn.cursor() curr.execute(""" SELECT names.common[0].value AS name, categories.main AS category, geometry FROM wherobots_open_data.overture.places_place WHERE ST_DistanceSphere(ST_GeomFromWKT("POINT (-122.46552 37.77196)"), geometry) < 10000 AND categories.main = "hiking_trail" """) results = curr.fetchall() print(results) results["geometry"] = results.geometry.apply(wkt.loads) gdf = geopandas.GeoDataFrame(results, crs="EPSG:4326",geometry="geometry") def add_geodataframe_to_layer(geodataframe, layer_name): # Create a new memory layer layer = QgsVectorLayer(geodataframe.to_json(), layer_name, "ogr") # Add the layer to the QGIS project QgsProject.instance().addMapLayer(layer) add_geodataframe_to_layer(gdf, "POI Layer") Visit the Wherobots user documentation to get started with the Spatial SQL API, or see our latest blog post that goes deeper into how to use our database drivers with the Spatial SQL API. Automating Spatial ETL workflows with the Apache Airflow provider for Wherobots ETL (extract, transform, load) workflows are oftentimes required to prepare spatial data for interactive analytics, or to refresh datasets automatically as new data arrives. Apache Airflow is a powerful and popular open source orchestrator of data workflows. With the Wherobots Apache Airflow provider, you can now use Apache Airflow to convert your spatial SQL queries into automated workflows running on Wherobots Cloud. Here’s an example of the Wherobots Airflow provider in use. In this example we identify the top 100 buildings in the state of New York with the most places (facilities, services, business, etc.) registered within them using the Overture Maps dataset, and we’ll eventually auto-refresh the result daily. The initial view can be generated with the following SQL query: CREATE TABLE wherobots.test_db.top_100_hot_buildings_daily AS SELECT buildings.id AS building, first(buildings.names), count(places.geometry) AS places_count, '2023-07-24' AS ts FROM wherobots_open_data.overture.places_place places JOIN wherobots_open_data.overture.buildings_building buildings ON ST_CONTAINS(buildings.geometry, places.geometry) WHERE places.updatetime >= '2023-07-24' AND places.updatetime < '2023-07-25' AND ST_CONTAINS(ST_PolygonFromEnvelope(-79.762152, 40.496103, -71.856214, 45.01585), places.geometry) AND ST_CONTAINS(ST_PolygonFromEnvelope(-79.762152, 40.496103, -71.856214, 45.01585), buildings.geometry) GROUP BY building ORDER BY places_count DESC LIMIT 100 A place in Overture is defined as real-world facilities, services, businesses or amenities. We used an arbitrary date of 2023-07-24. New York is defined by a simple bounding box polygon (79.762152, 40.496103, -71.856214, 45.01585) (we could alternatively join with its appropriate administrative boundary polygon) We use two WHERE clauses on places.updatetime to filter one day’s worth of data. The query creates a new table wherobots.test_db.top_100_hot_buildings_daily to store the query result. Note that it will not directly return any records because we are loading directly into a table. Now, lets use Harlequin as described earlier to inspect the outcome of creating this table with the above query: SELECT * FROM wherobots.test_db.top_100_hot_buildings_daily Apache Airflow and the Airflow Provider for Wherobots allow you to schedule and execute this query each day, injecting the appropriate date filters into your templatized query. In your Apache Airflow instance, install the airflow-providers-wherobots library. You can either execute pip install airflow-providers-wherobots, or add the library to the dependency list of your Apache Airflow runtime. Create a new “generic” connection for Wherobots called wherobots_default, using api.cloud.wherobots.com as the “Host” and your Wherobots API key as the “Password”. The next step is to create an Airflow DAG. The Wherobots Provider exposes the WherobotsSqlOperator for executing SQL queries. Update the hardcoded “2023-07-24” in your query into the Airflow template macros {ds} and {next_ds}, which will be rendered as the DAG schedule date on the fly: import datetime from airflow import DAG from airflow_providers_wherobots.operators.sql import WherobotsSqlOperator with DAG( dag_id="example_wherobots_sql_dag", start_date=datetime.datetime.strptime("2023-07-24", "%Y-%m-%d"), schedule="@daily", catchup=True, max_active_runs=1, ): operator = WherobotsSqlOperator( task_id="execute_query", wait_for_downstream=True, sql=""" INSERT INTO wherobots.test_db.top_100_hot_buildings_daily SELECT buildings.id AS building, first(buildings.names), count(places.geometry) AS places_count, '{{ ds }}' AS ts FROM wherobots_open_data.overture.places_place places JOIN wherobots_open_data.overture.buildings_building buildings ON ST_CONTAINS(buildings.geometry, places.geometry) WHERE places.updatetime >= '{{ ds }}' AND places.updatetime < '{{ next_ds }}' AND ST_CONTAINS(ST_PolygonFromEnvelope(-79.762152, 40.496103, -71.856214, 45.01585), places.geometry) AND ST_CONTAINS(ST_PolygonFromEnvelope(-79.762152, 40.496103, -71.856214, 45.01585), buildings.geometry) GROUP BY building ORDER BY places_count DESC LIMIT 100 """, return_last=False, ) You can visualize the status of the and log of the DAG’s execution in the Apache Airflow UI. As shown below, the operator prints out the exact query rendered and executed when you run your DAG. Please visit the Wherobots user documentation for more details on how to set up your Apache Airflow instance with the Wherobots Provider. Generate Vector Tiles — formatted as PMTiles — at Global Scale Vector tiles are high resolution representations of features optimized for visualization, computed offline and displayed in map applications. This decouples dataset preparation from client side rendering driven by zooming and panning. By decoupling dataset preparation from the interactive experience, map developers use vector tiles to significantly improve the utility, clarity, and responsiveness of feature rich interactive map applications. Traditional vector tiles generators like Tippecanoe are limited to the processing capability of a single VM and require the use of limited formats. These solutions are great for small-scale tile generation workloads when data is already in the right file format. But if you’re like the teams we’ve worked with, you may start small and need to scale past the limits of a single VM, or have a variety of file formats. You just want to generate vector tiles with the data you have, at any scale without having to worry about format conversion steps, configuring infrastructure, partitioning your workload around the capability of a VM, or waiting for workloads to complete. Vector Tile Generation, or VTiles for WherobotsDB generates vector tiles in PMTiles format across common data lake formats, incredibly quickly and at a planetary scale, so you can start small and know you have the capability to scale without having to look for another solution. VTiles is incredibly fast because serverless computation is parallelized, and the WherobotsDB engine is optimized for vector tile generation. This means your development teams can spend less time building map applications that matter to your customers. Using a Tokyo runtime, we generated vector tiles with VTiles for all buildings in the Overture dataset, from zoom levels 4-15 across the entire planet, in 23 minutes. That’s fast and efficient for a planetary scale operation. You can run the tile-generation-example notebook in the Wherobots Pro tier to experience the speed and simplicity of Vtiles yourself. Here’s what this looks like: [videopress 3DYMNV9r] Visit our user documentation to start generating vector tiles at-scale. Try Wherobots Pro Get Started Frequently Asked Questions What AI features did Wherobots announce here? A managed AI/ML suite for spatial data. At launch that includes Raster Inference (preview) on satellite/aerial imagery and Map Matching for GPS trajectories, both usable from SQL or Python. How fast is WherobotsDB versus Spark/Sedona here? The post claims up to 60x better spatial-join performance than popular general-purpose engines and warehouses, and up to 20x faster than Apache Sedona on its own. What does the Spatial SQL API enable? Remote Spatial SQL from Harlequin, first-party apps via Python (WherobotsDB API driver) and Java (JDBC), QGIS Python console queries, and Airflow DAGs through WherobotsSqlOperator. How long did planetary building vector tiles take? 23 minutes on a Tokyo runtime for all buildings in the Overture dataset at zoom levels 4–15 across the planet. --- ## The Spatial SQL API brings the performance of WherobotsDB to your favorite data applications URL: https://wherobots.com/blog/wherobots-spatial-sql-api/ Updated: 2026-10-19 Since its launch last fall, Wherobots has raised the bar for cloud-native geospatial data analytics, offering the first and only platform for working with vector and raster geospatial data together at a planetary scale. Wherobots delivers a significant breadth of geospatial analytics capabilities, built around a cloud-native data lakehouse architecture and query engine that delivers up to 60x better performance than incumbent solutions. Accessible through the powerful notebook experience data scientists and data engineers know and love, Wherobots Cloud is the most comprehensive, approachable, and fully-managed serverless offering for enabling spatial intelligence at scale. Key takeawaysThe Wherobots Spatial SQL API, powered by Apache Sedona, lets applications and orchestrators run Spatial SQL on serverless WherobotsDB instead of only in managed notebooks or the jobs UI.Wherobots is framed as a lakehouse query engine for vector and raster together at planetary scale, without copying data into a proprietary store. It is framed as delivering up to 60x better performance than incumbent solutions.Community Edition includes a Sedona runtime for smaller datasets. Professional Edition unlocks larger runtimes up to Tokyo for planetary-scale work, plus GPU options for Wherobots.Open-source clients: a Python DB-API 2.0 driver (wherobots-python-dbapi), a Type 4 JDBC driver (wherobots-jdbc-driver), and an Airflow provider (airflow-providers-wherobots) with WherobotsSqlOperator.Use cases called out include nationwide/planetary dataset prep, processing hundreds of millions of mobility records every day, and real-estate spatial datasets, with Tableau/Superset-style JDBC tools described as coming soon. Today, we’re announcing the Wherobots Spatial SQL API, powered by Apache Sedona, to bring the performance of WherobotsDB to your favorite data applications. This opens the door to a world of direct-SQL integrations with Wherobots Cloud, bringing a serverless cloud engine that’s optimized for spatial workloads at any scale into your spatial ETL pipelines and applications, and taking your users and engineers closer to your data and spatial insights. Developers love Wherobots because compute is abstracted and managed by Wherobots Cloud. Because it can run at a planetary scale, Wherobots streamlines development and reduces time to insight. It runs on a data lake architecture, so data doesn’t need to be copied into a proprietary storage system, and integrates into familiar development tools and interfaces for exploratory analytics and orchestrating production spatial ETL pipelines. Utilize Apache Airflow or SQL IDEs with WherobotsDB via the Spatial SQL API Wherobots Cloud and the Wherobots Spatial SQL API are powered by WherobotsDB, with Apache Sedona at its core: a distributed computation engine that can horizontally scale to handle computation and analytics on any dataset. Wherobots Cloud automatically manages the infrastructure and compute resources of WherobotsDB to serve your use case based on how much computation power you need. Behind the scenes, your Wherobots Cloud “runtime” defines the amount of compute resources allocated and the configuration of the software environment that executes your workload (in particular for AI/ML use cases, or if your ETL or analytics workflow depends on 1st or 3rd party libraries). Our always-free Community Edition gives access to a modest “Sedona” runtime for working with small-scale datasets. Our Professional Edition unlocks access to much larger runtimes, up to our “Tokyo” runtime capable of working on planetary-scale datasets, and GPU-accelerated options for your Wherobots workloads. With the release of the Wherobots Spatial SQL API and its client SDKs, you can bring WherobotsDB, the ease-of-use, and the expressiveness of SQL to your Apache Airflow spatial ETL pipelines, your applications, and soon to tools like Tableau, Superset, and other 3rd party systems and applications that support JDBC. Our customers love applying the performance and scalability of WherobotsDB to their data preparation workflows and their compute-intensive data processing applications. Use cases include Preparation of nationwide and planetary-scale datasets for their users and customers Processing hundreds of millions of mobility data records every day Creating and analyzing spatial datasets in support of their real estate strategy and decision-making. Now customers have the option to integrate new tools with Wherobots for orchestration and development of spatial insights using the Spatial SQL API. How to get started with the Spatial SQL API By establishing a connection to the Wherobots Spatial SQL API, a SQL session is started backed by your selected WherobotsDB runtime (or a “Sedona” by default but you can specify larger runtimes if you need more horsepower). Queries submitted through this connection are securely executed against your runtime, with compute fully managed by Wherobots. We provide client SDKs in Java and in Python to easily connect and interact with WherobotsDB through the Spatial SQL API, as well as an Airflow Provider to build your spatial ETL DAGs; all of which are open-source and available on package registries, as well as on Wherobots’ GitHub page. Using the Wherobots SQL Driver in Python Wherobots provides an open-source Python library that exposes a DB-API 2.0 compatible interface for connecting to WherobotsDB. To build a Python application around the Wherobots DB-API driver, add the wherobots-python-dbapi library to your project’s dependencies: $ poetry add wherobots-python-dbapi Or directly install the package on your system with pip: $ pip install wherobots-python-dbapi From your Python application, establish a connection with wherobots.db.connect() and use cursors to execute your SQL queries and use their results: import logging import sys from wherobots.db import connect from wherobots.db.region import Region from wherobots.db.runtime import Runtime # Optionally, setup logging to get information about the driver's # activity. logging.basicConfig( stream=sys.stdout, level=logging.INFO, format="%(asctime)s.%(msecs)03d %(levelname)s %(name)20s: %(message)s", datefmt="%Y-%m-%d %H:%M:%S", ) # Get your API key, or securely read it from a local file. api_key = '...' with connect( host="api.cloud.wherobots.com", api_key=api_key, runtime=Runtime.TINY, region=Region.AWS_US_WEST_2) as conn: cur = conn.cursor() sql = """ SELECT names['primary'] AS name, id, geometry, population FROM wherobots_open_data.overture_maps_foundation.divisions_division WHERE subtype = 'country' ORDER BY population DESC LIMIT 10 """ cur.execute(sql) results = cur.fetchall() print(results) For more information and future releases, see https://github.com/wherobots/wherobots-python-dbapi-driver on GitHub. Using the Apache Airflow provider Wherobots provides an open-source provider for Apache Airflow, defining an Airflow operator for executing SQL queries directly on WherobotsDB. With this new capability, you can integrate your spatial analytics queries, data preparation or data processing steps into new or existing Airflow workflow DAGs. To build or extend your Airflow DAG using the WherobotsSqlOperator , add the airflow-providers-wherobots dependency to your project: $ poetry add airflow-providers-wherobots Define your connection to Wherobots; by default the Wherobots operators use the wherobots_default connection ID: $ airflow connections add "wherobots_default" \ --conn-type "wherobots" \ --conn-host "api.cloud.wherobots.com" \ --conn-password "$(< api.key)" Instantiate the WherobotsSqlOperator and with your choice of runtime and your SQL query, and integrate it into your Airflow DAG definition: from wherobots.db.runtime import Runtime import airflow_providers_wherobots.operators.sql.WherobotsSqlOperator ... select = WherobotsSqlOperator( runtime=Runtime.TINY, sql=""" SELECT names['primary'] AS name, id, geometry, population FROM wherobots_open_data.overture_maps_foundation.divisions_division WHERE subtype = 'country' ORDER BY population DESC LIMIT 10 """ ) # select.execute() or integrate into your Airflow DAG definition For more information and future releases, see https://github.com/wherobots/airflow-providers-wherobots on GitHub. Using the Wherobots SQL Driver in Java Wherobots provides an open-source Java library that implements a JDBC (Type 4) driver for connecting to WherobotsDB. To start building Java applications around the Wherobots JDBC driver, add the following line to your build.gradle file’s dependency section: implementation "com.wherobots:wherobots-jdbc-driver" In your application, you only need to work with Java’s JDBC APIs from the java.sql package: import com.wherobots.db.Region; import com.wherobots.db.Runtime; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; // Get your API key, or securely read it from a local file. String apiKey = "..."; Properties props = new Properties(); props.setProperty("apiKey", apiKey); props.setProperty("runtime", Runtime.TINY); props.setProperty("region", Region.AWS_US_WEST_2); try (Connection conn = DriverManager.getConnection("jdbc:wherobots://api.cloud.wherobots.com", props)) { String sql = """ SELECT names['primary'] AS name, id, geometry, population FROM wherobots_open_data.overture_maps_foundation.divisions_division WHERE subtype = 'country' ORDER BY population DESC LIMIT 10 """; Statement stmt = conn.createStatement(); try (ResultSet rs = stmt.executeQuery(sql)) { while (rs.next()) { System.out.printf("%s: %s %f %s\n", rs.getString("id"), rs.getString("name"), rs.getDouble("population"), rs.getString("geometry")); } } } For more information and future releases, see https://github.com/wherobots/wherobots-jdbc-driver on GitHub. Conclusion The Wherobots Spatial SQL API takes Wherobots’ vision of hassle-free, scalable geospatial data analytics & AI one step further by making it the easiest way to run your Spatial SQL queries in the cloud. Paired with Wherobots and Apache Sedona’s comprehensive support for working with all geospatial data at any scale and in any format, and with Wherobots AI’s inference features available directly from SQL, the Wherobots Spatial SQL API is also the most flexible and the most capable platform for getting the most out of your data. Wherobots Vision We exist because creating spatial intelligence at-scale is hard. Our contributions to Apache Sedona, leadership in the open geospatial domain, and investments in Wherobots Cloud have, and will make it easier. Users of Apache Sedona, Wherobots customers, and ultimately any AI application will be enabled to support better decisions about our physical and virtual worlds. They will be able to create solutions to improve these worlds that were otherwise infeasible or too costly to build. And the solutions developed will have a positive impact on society, business, and earth — at a planetary scale. Want to keep up with the latest developer news from the Wherobots and Apache Sedona community? Sign up for the The Spatial Intelligence Newsletter: Frequently Asked Questions What is the Wherobots Spatial SQL API? A remote SQL interface to WherobotsDB. You connect with an API key, pick a runtime, and execute Spatial SQL from Python, Java/JDBC, Airflow, or a SQL IDE such as Harlequin. Which client libraries are available? wherobots-python-dbapi (DB-API 2.0), com.wherobots:wherobots-jdbc-driver (JDBC Type 4), and airflow-providers-wherobots. All three are open source on GitHub and package registries. Do I need Professional Edition to use the API? You can connect with Community Edition’s Sedona runtime. Professional Edition is required for larger runtimes (up to Tokyo) and GPU-accelerated AI workloads in Wherobots. How do I run Spatial SQL in Airflow? Install airflow-providers-wherobots, add a wherobots_default connection (host api.cloud.wherobots.com, API key as password), and add a WherobotsSqlOperator with your SQL and runtime. --- ## Processing A Billion Aircraft Observations And Combining With Weather Data Using Apache Sedona On Wherobots Cloud URL: https://wherobots.com/blog/billions-aircraft-observations-apache-sedona-wherobots-cloud/ Updated: 2026-10-19 In this post we take a look at combining aircraft flight data with weather data to identify potentially impacted flights using public ADS-B data and weather data from NOAA. Along the way we introduce the types of spatial queries available with WherobotsDB including spatial range queries, spatial kNN, and spatial joins using Spatial SQL, geospatial visualization options, working with various file formats including GeoParquet, GeoTiff, Shapefiles, and more. Key takeawaysOne month of crowdsourced ADS-B traces from ADSB.lol was stored as S2-partitioned GeoParquet and loaded as 1,103,371,367 point observations in Wherobots Cloud.A Gulf of Mexico ST_Within range query returned 7,539,347 traces in 4.37 seconds. A kNN for the 5 nearest traces to Jackson Hole Airport took 11.1 seconds on the same 1.1 billion-row table.NOAA severe-weather events in the Wherobots catalog (over 8 million US events, 2016–2022) joined to the traces in 12.7 seconds, producing 53,788,395 traces in historically severe hexes.JetBlue traces were assembled into routes with ST_MakeLine, split into ~100 km segments via a Shapely UDF, and joined to severe-weather H3 cells to score flight-segment risk.A NEXRAD GeoTiff out-DB raster was joined to airport points with RS_Value (threshold > 100). It flagged Gen E L Logan Int'l (BOS) at precipitation index 108.0 and Durham Int'l (RDU) at 138.0. We’ll be running this example in Wherobots Cloud, where you can create a free account to follow along. See the Getting Started With Wherobots Cloud series for an overview of Wherobots Cloud. Flight Trace Data The ADS-B flight observation data we’ll be using comes from ADSB.lol which provides publicly accessible daily updates of crowd-sourced flight tracking data. I adapted some great examples for downloading, parsing and enriching this dataset from Mark Litwintschik’s blog post and extracted 1 month of data which resulted in just over 1.1 billion observations. I extended Mark’s approach a bit and saved this data as GeoParquet, partitioned by S2 id. This will enable more efficient spatial queries on the dataset. First, we’ll import dependencies and configure WherobotsDB to access an S3 bucket with our example data. from sedona.spark import * config = SedonaContext.builder().config("spark.hadoop.fs.s3a.bucket.wherobots-examples.aws.credentials.provider","org.apache.hadoop.fs.s3a.AnonymousAWSCredentialsProvider").getOrCreate() sedona = SedonaContext.create(config) We load one month of world-wide aircraft trace data which is just over 1.1 billion point observations. # Load flight traces via GeoParquet traces_df = sedona.read.format("geoparquet").load("s3a://wherobots-examples/data/examples/flights/2024_s2.parquet") traces_df.createOrReplaceTempView("traces") traces_df.count() ------------------- 1103371367 Exploratory Data Analysis I followed Mark’s approach of extracting individual trace observations into their own row and we store detailed information about the trace such as altitude, squawk code, heading, etc in a struct. You can find his code in this post. Let’s view the schema of our Spatial DataFrame that we loaded via GeoParquet. traces_df.printSchema() root |-- dbFlags: long (nullable = true) |-- desc: string (nullable = true) |-- icao: string (nullable = true) |-- ownOp: string (nullable = true) |-- r: string (nullable = true) |-- reg_details: struct (nullable = true) | |-- description: string (nullable = true) | |-- iso2: string (nullable = true) | |-- iso3: string (nullable = true) | |-- nation: string (nullable = true) |-- t: string (nullable = true) |-- timestamp: string (nullable = true) |-- trace: struct (nullable = true) | |-- aircraft: struct (nullable = true) | | |-- alert: long (nullable = true) | | |-- alt_geom: long (nullable = true) | | |-- baro_rate: long (nullable = true) | | |-- category: string (nullable = true) | | |-- emergency: string (nullable = true) | | |-- flight: string (nullable = true) | | |-- geom_rate: long (nullable = true) | | |-- gva: long (nullable = true) | | |-- ias: long (nullable = true) | | |-- mach: double (nullable = true) | | |-- mag_heading: double (nullable = true) | | |-- nac_p: long (nullable = true) | | |-- nac_v: long (nullable = true) | | |-- nav_altitude_fms: long (nullable = true) | | |-- nav_altitude_mcp: long (nullable = true) | | |-- nav_heading: double (nullable = true) | | |-- nav_modes: array (nullable = true) | | | |-- element: string (containsNull = true) | | |-- nav_qnh: double (nullable = true) | | |-- nic: long (nullable = true) | | |-- nic_baro: long (nullable = true) | | |-- oat: long (nullable = true) | | |-- rc: long (nullable = true) | | |-- roll: double (nullable = true) | | |-- sda: long (nullable = true) | | |-- sil: long (nullable = true) | | |-- sil_type: string (nullable = true) | | |-- spi: long (nullable = true) | | |-- squawk: string (nullable = true) | | |-- tas: long (nullable = true) | | |-- tat: long (nullable = true) | | |-- track: double (nullable = true) | | |-- track_rate: double (nullable = true) | | |-- true_heading: double (nullable = true) | | |-- type: string (nullable = true) | | |-- version: long (nullable = true) | | |-- wd: long (nullable = true) | | |-- ws: long (nullable = true) | |-- altitude: long (nullable = true) | |-- flags: long (nullable = true) | |-- geometric_altitude: long (nullable = true) | |-- geometric_vertical_rate: long (nullable = true) | |-- ground_speed: double (nullable = true) | |-- h3_5: string (nullable = true) | |-- indicated_airspeed: long (nullable = true) | |-- lat: double (nullable = true) | |-- lon: double (nullable = true) | |-- roll_angle: double (nullable = true) | |-- source: string (nullable = true) | |-- timestamp: string (nullable = true) | |-- track_degrees: double (nullable = true) | |-- vertical_rate: long (nullable = true) |-- year: string (nullable = true) |-- geometry: geometry (nullable = true) |-- date: date (nullable = true) |-- s2: long (nullable = true) We can also inspect the first few rows of data. traces_df.show(5) +-------+--------------------+------+-----+------+--------------------+----+-------------------+--------------------+----+--------------------+----------+-------------------+ |dbFlags| desc| icao|ownOp| r| reg_details| t| timestamp| trace|year| geometry| date| s2| +-------+--------------------+------+-----+------+--------------------+----+-------------------+--------------------+----+--------------------+----------+-------------------+ | 0|PIPER PA-28R-180/...|c81c51| null|ZK-RTE|{general, NZ, NZL...|P28R|2024-01-20 00:00:00|{{null, null, nul...|null|POINT (174.722786...|2024-01-20|7854277750134145024| | 0| AIRBUS A-320|c81e2c| null|ZK-OJS|{general, NZ, NZL...|A320|2024-01-15 00:00:00|{{0, 36400, 0, A3...|null|POINT (174.549826...|2024-01-15|7854277750134145024| | 0|PIPER PA-28R-180/...|c81c51| null|ZK-RTE|{general, NZ, NZL...|P28R|2024-01-20 00:00:00|{{null, null, nul...|null|POINT (174.722764...|2024-01-20|7854277750134145024| | 0| AIRBUS A-320|c81e2c| null|ZK-OJS|{general, NZ, NZL...|A320|2024-01-15 00:00:00|{{null, null, nul...|null|POINT (174.557251...|2024-01-15|7854277750134145024| | 0|PIPER PA-28R-180/...|c81c51| null|ZK-RTE|{general, NZ, NZL...|P28R|2024-01-20 00:00:00|{{0, 1600, null, ...|null|POINT (174.722589...|2024-01-20|7854277750134145024| +-------+--------------------+------+-----+------+--------------------+----+-------------------+--------------------+----+--------------------+----------+-------------------+ only showing top 5 rows We can query our aircraft traces Spatial DataFrame using Spatial SQL. To start off let’s just demonstrate selecting fields and viewing tabular results. Note that the geometry column here is a spatial type. The data we loaded was GeoParquet formatted so we don’t need to parse or cast the field to a geometry type. sedona.sql(""" SELECT desc, ownOp, geometry, trace.ground_speed, trace.altitude, trace.aircraft.flight FROM traces WHERE trace.altitude IS NOT NULL AND OwnOp IS NOT NULL AND desc IS NOT NULL AND trace.aircraft.flight IS NOT NULL LIMIT 10 """).show(truncate=False) +----------------+-------------------+-----------------------------+------------+--------+--------+ |desc |ownOp |geometry |ground_speed|altitude|flight | +----------------+-------------------+-----------------------------+------------+--------+--------+ |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.792839 -37.010239)|122.7 |400 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.782449 -37.013079)|161.6 |350 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.779046 -37.01401) |168.9 |475 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.771463 -37.016058)|165.7 |825 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.765248 -37.017746)|162.5 |1175 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.757827 -37.01976) |159.4 |1550 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.748356 -37.022296)|161.3 |1950 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.738951 -37.024796)|163.2 |2325 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.725607 -37.028395)|165.7 |2725 |DAL64 | |AIRBUS A-350-900|UMB BANK NA TRUSTEE|POINT (174.713367 -37.03184) |167.3 |3125 |DAL64 | +----------------+-------------------+-----------------------------+------------+--------+--------+ Let’s see where the aircraft activity is in the ADS-B flight observation dataset. Where are we seeing the most aircraft activity? We can use H3 hexagons to aggregate the individual traces and visualize the results using the SedonaKepler visualization integration. Here we count the number of aircraft trace observations within each level 5 H3 hexagon and create a choropleth map to visualize the spatial distribution. h3_traces_df = sedona.sql(""" SELECT COUNT(*) AS num, ST_H3ToGeom(ST_H3CellIDs(geometry, 5, false)) AS geometry, ST_H3CellIDs(geometry, 5, false) AS h3 FROM traces GROUP BY h3 """) SedonaKepler.create_map(h3_traces_df, name="Distribution of aircraft traces") Since our data source relies on crowdsourced data retrieved from ground stations, the data coverage is not evenly distributed. We are notably missing observations over the oceans and other areas that lack crowd-sourced ground sensors. This isn’t an issue for this analysis because flight disruption is most likely to occur around airports. We can filter for aircraft belonging to a specific airline using the ownOp column and also filter for traces that were observed while the aircraft was part of a named flight. This can help give us some insight into the routes flown by this airline. jbu_h3_traces_df = sedona.sql(""" SELECT COUNT(*) AS num, ST_H3ToGeom(ST_H3CellIDs(geometry, 5, false)) AS geometry, ST_H3CellIDs(geometry, 5, false) AS h3 FROM traces WHERE ownOp = "JETBLUE AIRWAYS CORP" AND trace.aircraft.flight LIKE "JBU%" GROUP BY h3 """) SedonaKepler.create_map(jbu_h3_traces_df, name="Distribution of aircraft traces") Flight Traces – Spatial Queries And Performance WherobotsDB supports optimizations for various types of spatial queries including: Spatial range query Spatial kNN query, and Spatial joins Let’s demonstrate these types of queries and compare the performance with this dataset. Spatial Range Query Let’s say we wanted to find all aircraft traces within the bounds of a specific area, perhaps the Gulf of Mexico region. We can do this using the ST_Within Spatial SQL predicate. Here we apply this spatial predicate to filter our 1.1 billion observations to only those within the bounds of a polygon representing a specific area. This takes just over 4 seconds. gulf_filter = 'ST_Within(geometry, ST_GeomFromWKT("POLYGON ((-84.294662 29.840644, -88.952866 30.297018, -89.831772 28.767659, -94.050522 29.61167, -97.038803 27.839076, -97.917709 21.453069, -94.489975 18.479609, -86.843491 21.616579, -80.779037 24.926295, -84.294662 29.840644))"))' gulf_traces = traces_df.where(gulf_filter) %%time gulf_traces.count() -------------------- 7539347 Wall time: 4.37 s Spatial kNN Query Another type of spatial query that might be relevant for working with this dataset is a spatial kNN query, which will efficiently find the “k” nearest geometries where the value of k is specified by the user. For example, let’s find the 5 nearest aircraft traces to the Jackson Hole Airport. jackson_hole_traces = sedona.sql(""" SELECT desc, ownOp, trace.aircraft.flight, ST_DistanceSphere(ST_Point(-110.7376, 43.6088), geometry) AS distance FROM traces ORDER BY distance ASC LIMIT 5 """) %%time jackson_hole_traces.show() ---------------------------- Wall time: 11.1 s +--------------------+--------------------+--------+------------------+ | desc| ownOp| flight| distance| +--------------------+--------------------+--------+------------------+ |BOMBARDIER BD-700...| FLEXJET LLC| null| 76.92424103100763| | AIRBUS A-320| UNITED AIRLINES INC| null|161.98830220247405| |CESSNA 700 CITATI...|AH CAPITAL MANAGE...| null|180.05761405860687| |CESSNA 750 CITATI...| 2FLIU LLC| null|187.01797656145476| |DASSAULT FALCON 2000|NEXTERA ENERGY EQ...|N58MW |204.06240031528034| In this case our query takes 11 seconds against a 1.1 billion row dataset. Historical Impact of Severe Weather Events On Flights An important analysis related to flight routes is the impact of severe weather events. To enable this type of analysis Wherobots makes public a dataset of severe weather events as part of the Wherobots Open Data Catalog. The dataset has over 8 million weather events reported by NOAA in the US from 2016-2022. weather = sedona.table("wherobots_pro_data.weather.weather_events") weather.show() +--------+-------------+--------+-------------------+-------------------+-----------------+----------+-----------+-----------+-----------+----+--------------+-----+-------+--------------------+ | EventId| Type|Severity| StartTime(UTC)| EndTime(UTC)|Precipitation(in)| TimeZone|AirportCode|LocationLat|LocationLng|City| County|State|ZipCode| geometry| +--------+-------------+--------+-------------------+-------------------+-----------------+----------+-----------+-----------+-----------+----+--------------+-----+-------+--------------------+ |W-237263| Cold| Severe|2016-01-01 08:57:00|2016-01-04 15:32:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237264| Rain| Light|2016-01-04 22:49:00|2016-01-04 23:30:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237265| Cold| Severe|2016-01-05 00:35:00|2016-01-05 15:32:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237266| Rain| Light|2016-01-05 15:32:00|2016-01-05 17:57:00| 0.2|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237267| Rain|Moderate|2016-01-05 17:57:00|2016-01-05 18:09:00| 0.14|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237268| Rain| Light|2016-01-05 18:09:00|2016-01-05 18:23:00| 0.07|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237269| Rain|Moderate|2016-01-05 18:23:00|2016-01-05 18:57:00| 0.35|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237270|Precipitation| UNK|2016-01-05 18:57:00|2016-01-05 19:41:00| 0.22|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237271| Cold| Severe|2016-01-06 00:57:00|2016-01-06 15:31:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237272| Rain| Light|2016-01-06 16:57:00|2016-01-06 18:33:00| 0.16|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237273|Precipitation| UNK|2016-01-06 18:57:00|2016-01-06 19:10:00| 0.23|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237274| Rain|Moderate|2016-01-06 19:10:00|2016-01-06 19:57:00| 0.16|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237275| Rain| Light|2016-01-06 20:57:00|2016-01-06 21:27:00| 0.03|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237276| Rain|Moderate|2016-01-06 21:27:00|2016-01-06 22:57:00| 0.26|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237277| Cold| Severe|2016-01-07 00:57:00|2016-01-07 15:35:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237278| Rain| Light|2016-01-07 18:10:00|2016-01-07 18:57:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237279| Rain| Light|2016-01-07 23:57:00|2016-01-08 00:57:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237280| Cold| Severe|2016-01-08 00:57:00|2016-01-08 15:29:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237281| Cold| Severe|2016-01-09 00:57:00|2016-01-11 14:32:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| |W-237282| Cold| Severe|2016-01-12 00:57:00|2016-01-12 15:57:00| 0.0|US/Pacific| KNSI| 33.2338| -119.4559|null|Ventura County| CA| null|POINT (-119.4559 ...| +--------+-------------+--------+-------------------+-------------------+-----------------+----------+-----------+-----------+-----------+----+--------------+-----+-------+--------------------+ only showing top 20 rows Severe Weather Events Let’s start our weather event analysis by finding areas that are commonly susceptible to severe weather events. We’ll again use H3 hexagons to aggregate the data, this time counting the number of severe weather events that occur within each hexagon. We’ll visualize the results as a choropleth to see areas where weather events frequently occur. weather_h3_df = sedona.sql(""" SELECT COUNT(*) AS num, ST_H3ToGeom(ST_H3CellIDs(ST_Buffer(geometry, 0.1), 5, false)) AS geometry, ST_H3CellIDs(ST_Buffer(geometry, 0.1), 5, false) AS h3 FROM wherobots_pro_data.weather.weather_events WHERE Severity = "Severe" GROUP BY h3 """) weather_h3_df.createOrReplaceTempView("weather_h3") SedonaKepler.create_map(weather_h3_df.cache(), name="Severe weather events") Historical Severe Weather Aircraft Trace Analysis Now that we’ve determined which areas are susceptible to frequent severe weather events, we can analyze flight trace observations in these areas to determine flights that may be susceptible to frequent severe weather events using a spatial join. Note that we’re joining a table with 1.1 billion observations against our weather event data, which takes just under 13 seconds in Wherobots Cloud. severe_weather_flight_traces_df= sedona.sql(""" SELECT traces.geometry AS geometry, desc, ownOp, trace.aircraft.flight AS flight, num AS eventCount FROM traces JOIN weather_h3 WHERE ST_Contains(weather_h3.geometry, traces.geometry) AND trace.aircraft.flight IS NOT null """) %%time severe_weather_flight_traces_df.count() ---------------------------- Wall time: 12.7 s 53788395 Using the flight number we can calculate an “intensity” metric that attempts to measure the potential impact of a flight to be disrupted by a severe weather event using the historical weather data. Here we calculate this intensity metric across all traces to find the most potentially impacted flights. most_impacted_flights = sedona.sql(""" SELECT sum(eventCount) AS intensity, ST_Collect(collect_list(geometry)) AS geometry, flight FROM severe_weather_traces WHERE NOT flight = " " AND NOT flight = "00000000" GROUP BY flight ORDER BY intensity DESC LIMIT 100 """) Flight Routes So far we’ve been working with individual aircraft traces (point observations), but it’s much more useful to analyze flights as routes. We can construct the individual flight routes from these aircraft traces, for a specific airline by filtering on the ownOp and trace.aircraft.flight fields. First we collect all aircraft traces that match our filter by airline, grouping by flight number. Then we can convert this collection of point geometries into a LineString geometry that represents the path the aircraft took during this flight using the ST_MakeLine Spatial SQL function. jbu_flights_df = sedona.sql(""" WITH jbu_traces AS ( SELECT any_value(trace.aircraft.flight) AS flight, collect_list(ST_Point(trace.lon, trace.lat)) AS points, any_value(CAST(date AS string)) AS date FROM traces WHERE ownOp = 'JETBLUE AIRWAYS CORP' AND trace.aircraft.flight IS NOT null GROUP BY trace.aircraft.flight, date ) SELECT flight, ST_MakeLine(points) AS geometry, date FROM jbu_traces WHERE size(points) > 100 """) jbu_flights_df.show() +--------+--------------------+----------+ | flight| geometry| date| +--------+--------------------+----------+ |JBU100 |LINESTRING (-112....|2024-01-24| |JBU101 |LINESTRING (-80.1...|2024-01-21| |JBU1016 |LINESTRING (-77.3...|2024-01-20| |JBU1044 |LINESTRING (-80.1...|2024-01-10| |JBU1053 |LINESTRING (-73.7...|2024-01-03| |JBU1055 |LINESTRING (-71.0...|2024-01-03| |JBU1060 |LINESTRING (-77.4...|2024-01-12| |JBU1060 |LINESTRING (-77.4...|2024-01-26| |JBU1067 |LINESTRING (-73.7...|2024-01-17| |JBU1068 |LINESTRING (-80.0...|2024-01-24| |JBU1114 |LINESTRING (-112....|2024-01-17| |JBU1131 |LINESTRING (-80.2...|2024-01-22| |JBU1136 |LINESTRING (-83.3...|2024-01-15| |JBU1142 |LINESTRING (-80.0...|2024-01-27| |JBU1196 |LINESTRING (-80.1...|2024-01-03| |JBU1196 |LINESTRING (-80.1...|2024-01-27| |JBU1217 |LINESTRING (-81.6...|2024-01-15| |JBU1230 |LINESTRING (-86.8...|2024-01-22| |JBU1238 |LINESTRING (-97.6...|2024-01-28| |JBU1251 |LINESTRING (-73.7...|2024-01-10| +--------+--------------------+----------+ only showing top 20 rows Identify Potential For Weather Impacted Flights Now that we’ve extracted flight routes from the individual aircraft trace point observations we can begin to determine the potential for severe weather events to impact these flights based on our historical weather event data. Creating Uniform Flight Route Segments To analyze which flights have the most potential to be impacted based on historical weather events we first create 100km segments of each flight which will allow us to identify not only entire flight routes that are potentially impacted by weather events, but specific flight segments with the most risk of disruption. To do this we’ll make use of the ability to create a user defined function in WherobotsDB using the Shapely library. We’ll use Shapely’s line interpolate functionality to create equal length segments of each flight route. from shapely.geometry import LineString, MultiLineString from sedona.sql.types import GeometryType # Define a Shapely UDF to create a series of consistent length line segments for each flight def interpolate_lines(line: GeometryType()): try: distance_delta = 1.0 # ~100km points_count = int(line.length // distance_delta) + 1 distances = (distance_delta * i for i in range(points_count)) points = [line.interpolate(distance) for distance in distances] + [line.boundary[1]] line_strings = [] for i in range(len(points) - 1): line_strings.append(LineString([points[i], points[i+1]])) return MultiLineString(line_strings) except: return None sedona.udf.register("interpolate_lines", interpolate_lines, GeometryType()) We can now call our user defined function in a spatial SQL statement and leverage WherobotsDB’s parallel execution to run this UDF. split_df = sedona.sql(""" SELECT flight, date, explode(ST_Dump(interpolate_lines(geometry))) AS geometry FROM jbu_flights """) split_df.createOrReplaceTempView("split_flights") split_df.show() +--------+----------+--------------------+ | flight| date| geometry| +--------+----------+--------------------+ |JBU100 |2024-01-24|LINESTRING (-118....| |JBU100 |2024-01-24|LINESTRING (-117....| |JBU100 |2024-01-24|LINESTRING (-116....| |JBU100 |2024-01-24|LINESTRING (-115....| |JBU100 |2024-01-24|LINESTRING (-114....| |JBU100 |2024-01-24|LINESTRING (-113....| |JBU100 |2024-01-24|LINESTRING (-112....| |JBU100 |2024-01-24|LINESTRING (-111....| |JBU100 |2024-01-24|LINESTRING (-110....| |JBU100 |2024-01-24|LINESTRING (-109....| |JBU100 |2024-01-24|LINESTRING (-108....| |JBU100 |2024-01-24|LINESTRING (-107....| |JBU100 |2024-01-24|LINESTRING (-106....| |JBU100 |2024-01-24|LINESTRING (-105....| |JBU100 |2024-01-24|LINESTRING (-104....| |JBU100 |2024-01-24|LINESTRING (-103....| |JBU100 |2024-01-24|LINESTRING (-102....| |JBU100 |2024-01-24|LINESTRING (-102....| |JBU100 |2024-01-24|LINESTRING (-101....| |JBU100 |2024-01-24|LINESTRING (-100....| +--------+----------+--------------------+ only showing top 20 rows Joining Flight Route Segments With Weather Events Now we perform a spatial join to identify flight segments that pass through areas that historically have a high frequency of severe weather events. severe_weather_split_df = sedona.sql(""" SELECT flight, date, split_flights.geometry AS geometry, num FROM split_flights JOIN weather_h3 WHERE ST_Intersects(weather_h3.geometry, split_flights.geometry) """) severe_weather_split_df.show() This gives us a measure of which individual flight segments have the highest potential for weather impact. +--------+----------+--------------------+----+ | flight| date| geometry| num| +--------+----------+--------------------+----+ |JBU2288 |2024-01-02|LINESTRING (-69.3...|1221| |JBU2288 |2024-01-02|LINESTRING (-70.3...|1774| |JBU2288 |2024-01-02|LINESTRING (-71.2...| 42| |JBU2288 |2024-01-02|LINESTRING (-71.2...|1192| |JBU2288 |2024-01-02|LINESTRING (-71.2...|1231| |JBU2288 |2024-01-02|LINESTRING (-72.2...| 672| |JBU2288 |2024-01-02|LINESTRING (-72.2...| 959| |JBU2288 |2024-01-02|LINESTRING (-73.2...| 652| |JBU2288 |2024-01-02|LINESTRING (-73.2...| 672| |JBU1053 |2024-01-03|LINESTRING (-73.7...| 416| |JBU2424 |2024-01-07|LINESTRING (-81.2...| 217| |JBU2424 |2024-01-07|LINESTRING (-81.2...| 467| |JBU2424 |2024-01-07|LINESTRING (-81.2...| 487| |JBU2424 |2024-01-07|LINESTRING (-81.2...| 611| |JBU2424 |2024-01-07|LINESTRING (-81.3...| 885| |JBU2424 |2024-01-07|LINESTRING (-81.3...| 722| |JBU2424 |2024-01-07|LINESTRING (-81.3...|2237| |JBU2424 |2024-01-07|LINESTRING (-81.3...| 722| |JBU2424 |2024-01-07|LINESTRING (-81.3...| 618| |JBU2424 |2024-01-07|LINESTRING (-81.3...| 607| +--------+----------+--------------------+----+ only showing top 20 rows Flights With The Highest Potential For Weather Impact Now we can join the flight segments and their corresponding weather intensity impact scores with the full flight routes to visualize the flights with the highest potential for weather impact based on the historical weather events. full_flight_intensity_df = sedona.sql(""" SELECT jbu_flights.flight, jbu_flights.geometry, jbu_flights.date, intensity FROM jbu_flights JOIN jbu_intensity ON jbu_flights.flight = jbu_intensity.flight AND jbu_flights.date = jbu_intensity.date """) map_view = SedonaKepler.create_map(full_flight_intensity_df.orderBy("intensity", ascending=False).limit(10), name="Flights") SedonaKepler.add_df(map_view, df=weather_h3_df, name="Weather") map_view Doppler Weather Raster Data So far we’ve been working with historical weather event data, lets now look at a simple example using more real-time weather radar data. Specifically, we’ll use NOAA’s NEXRAD Doppler weather radar surface reflectivity product to assess the impact of high precipitation at airports. We’ll load a GeoTiff raster image of the continental US to identify weather patterns, then join this raster data with the location of US airports. First, we load the raster image from S3 using the RS_FromPath function which will create an out-db raster in WherobotsDB. nexrad_raster_url = "s3://wherobots-examples/data/noaa/nexrad/n0q_202309231625.tif" nexrad_df = sedona.sql(f"SELECT RS_FromPath('{nexrad_raster_url}') AS raster") nexrad_df.createOrReplaceTempView("nexrad") nexrad_df.printSchema() root |-- raster: raster (nullable = true) Inspecting the meta data for this raster image we can see the spatial extent, spatial resolution, the CRS, and number of bands. sedona.sql("SELECT RS_MetaData(raster) from nexrad").show(truncate=False) +---------------------------------------------------------------------------+ |rs_metadata(raster) | +---------------------------------------------------------------------------+ |[-126.0025, 50.0025, 12200.0, 5400.0, 0.005, -0.005, 0.0, 0.0, 4326.0, 1.0]| +---------------------------------------------------------------------------+ We can visualize the raster using RS_AsImage. htmlDf = sedona.sql("SELECT RS_AsImage(raster, 1200) AS raster_image FROM nexrad") SedonaUtils.display_image(htmlDf) Next, we’ll load the point geometries of airports from a Shapefile. spatialRdd = ShapefileReader.readToGeometryRDD(sedona.sparkContext, "s3a://wherobots-examples/data/ne_50m_airports") poi_df = Adapter.toDf(spatialRdd, sedona) poi_df = poi_df poi_df.show(5) poi_df.createOrReplaceTempView("airports") +--------------------+---------+----------+-----+----------------+------+--------+--------+---------+--------------------+---------+ | geometry|scalerank|featurecla| type| name|abbrev|location|gps_code|iata_code| wikipedia|natlscale| +--------------------+---------+----------+-----+----------------+------+--------+--------+---------+--------------------+---------+ |POINT (113.935016...| 2| Airport|major| Hong Kong Int'l| HKG|terminal| VHHH| HKG|http://en.wikiped...| 150.000| |POINT (121.231370...| 2| Airport|major| Taoyuan| TPE|terminal| RCTP| TPE|http://en.wikiped...| 150.000| |POINT (4.76437693...| 2| Airport|major| Schiphol| AMS|terminal| EHAM| AMS|http://en.wikiped...| 150.000| |POINT (103.986413...| 2| Airport|major|Singapore Changi| SIN|terminal| WSSS| SIN|http://en.wikiped...| 150.000| |POINT (-0.4531566...| 2| Airport|major| London Heathrow| LHR| parking| EGLL| LHR|http://en.wikiped...| 150.000| +--------------------+---------+----------+-----+----------------+------+--------+--------+---------+--------------------+---------+ only showing top 5 rows And now we’re ready to join the raster radar data to our vector airport locations. This operation retrieves the pixel value (in this case a precipitation index value) from the raster at the location of each airport. We’ll filter for any airports where this index value is above 100, indicating significant precipitation. airport_precip_df = sedona.sql(""" SELECT name, iata_code, type, RS_Value(raster, geometry, 1) AS precip FROM airports JOIN nexrad """) airport_precip_df.where("precip > 100").show(truncate=False) +-------------------+---------+-----+------+ |name |iata_code|type |precip| +-------------------+---------+-----+------+ |Gen E L Logan Int'l|BOS |major|108.0 | |Durham Int'l |RDU |major|138.0 | +-------------------+---------+-----+------+ Based on this analysis we can see that Logan International Airport and Raleigh-Durham Airport are experiencing high precipitation events, which may potentially impact ground operations. Resources This blog post looked at combining aircraft trace observations from public ADS-B sensors with weather event and radar data to analyze the potential impact of severe weather events on flights. You can follow along with these examples by creating a free account on Wherobots Cloud and find the code for this example on GitHub. Interested in trying our Wherobots Pro features? Sign up here and receive $400 in credits for free. Try Wherobots for free Get Started Frequently Asked Questions How many aircraft observations are in this tutorial? Slightly more than 1.1 billion (count 1,103,371,367) from one month of worldwide ADS-B traces, stored as GeoParquet partitioned by S2. How fast are spatial queries on that table? A polygon range query over the Gulf of Mexico ran in 4.37 seconds (7.5 million hits). A 5-nearest kNN to Jackson Hole Airport ran in 11.1 seconds. A spatial join to severe-weather H3 cells ran in 12.7 seconds. What weather data is used? Historical NOAA severe-weather events (over 8 million, 2016–2022) from the Wherobots catalog, plus a continental US NEXRAD Doppler reflectivity GeoTiff for a raster/vector airport join. How are flight routes built from traces? Filter by operator and flight number, collect points per flight/day, ST_MakeLine into a LineString, then interpolate ~100 km segments with a registered Shapely UDF before joining to weather hexes. ---