DINO-EdgeQuery:Edge-First Polygon Decoding for Building Footprint Extraction from Satellite Imagery

Building footprint extraction from high-resolution satellite imagery requires accurate building boundary raster masks and an effective shape reconstruction method to produce natural building footprints. Unlike vertex-centric graph approaches or mask contour tracing, we propose DINO-EdgeQuery, an edge-first paradigm that addresses this need. A frozen DINOv3 backbone, adapter neck, and an instance decoder inspired by Mask2Former provide building-aware boxes and masks, while a region of interest (ROI)-conditioned EdgeQuery decoder predicts edge activity, center, direction, length, and successor relations. By capturing dominant wall structures as edge primitives and reconstructing vertices purely through deterministic line intersections, we deliberately separate neural edge prediction from verifiable geometric assembly. Active edges are ordered by successor scores, and the P2 quality gate removes invalid or contained duplicate polygons. This geometric post-processing encourages sharp, line-intersection-based corners and enforces topology-safe polygons through deterministic validity checks. To improve generalization, we train segmentation and EdgeQuery branches separately, mask inactive losses to zero, and merge the trained weights for unified inference. Validation on the dataset publicly released on the website by the Wuhan University Geospatial Computer Vision Group demonstrates that our EdgeQuery framework, including the P2 quality gate, delivered high-quality, geometrically superior polygon outputs with zero self-intersections and triangle collapses, and simultaneously improved Intersection over Union (IoU) and suppressed duplicate building footprints.

Transcript

1. DINO-EdgeQuery Edge-First Polygon Decoding for Building Footprint Extraction from Satellite Imagery Yuji Kobayashi Orbitalnet, Inc. FOSS4G Hiroshima 2026 Academic Track
2. About Orbitalnet Company Turning Earth Data into GIS-Ready Intelligence. A geospatial technology company combining FOSS4G and AI. Nagoya → Hiroshima 01 Orbitalnet HQ 02 FOSS4G 2026 GeoAI FOSS4G DINO-EdgeQuery / FOSS4G Hiroshima Hiroshima Nagoya FOSS4G 2026 Orbitalnet HQ GIS-Ready 03 Nagoya, Japan • Established 2018 GeoAI for Earth Observation Satellite imagery • aerial photography • point clouds FOSS4G & GIS Engineering QGIS • PostGIS • WebGIS • workflow automation GIS-Ready Data & Services Vector maps • 3D models • geospatial content Research focus: from visual prediction to verifiable geospatial geometry. 1
3. Summary 1. Introduction 2. Related works 3. Method 4. Experiments 5. Results 6. Discussion 7. Conclusions
4. 1. Introduction
5. Research overview Objective, method, and inference flow from satellite imagery to GeoJSON Purpose Generate accurate and natural building polygons from high-resolution satellite imagery ② Post-processing ① Deep learning • Final vertices are reconstructed by deterministic line intersections. • DINOv3, an Adapter Neck, and a Mask2Former-style instance branch produce building boxes and masks. • Invalid geometries and contained duplicate polygons are suppressed. • EdgeQuery predicts edge primitives and successor relations. • Map coordinates are restored and exported as GeoJSON. • The separately trained segmentation and EdgeQuery models are merged. ③ Inference High-resolution satellite image → Deep learning P2 Quality Gate: line intersections → validity checks → containedduplicate suppression → Post-processing → GeoJSON building polygons Key point: training is separated for stability, while inference runs deep learning and post-processing as one pipeline. DINO-EdgeQuery / FOSS4G Hiroshima 02
6. 2. Related Work
7. Why raster masks are not enough Problem GIS workflows need: compact geometry editable vertices valid topology georeferenced output raster instance mask desired vector footprint For many geospatial tasks, a raster mask is not the final product. We need polygons that are compact, editable, georeferenced, and topologically valid. DINO-EdgeQuery addresses the geometric decoding problem after building recognition. DINO-EdgeQuery / FOSS4G Hiroshima 03
8. The challenge of mask-first polygonization Mask prediction Contour tracing jagged outlines redundant vertices self-intersections parameter sensitivity Problem Simplification corner drift A small raster error can become a large vector-quality problem. Conventional pipelines often predict a mask and then trace its contour. This is useful, but small raster errors can become jagged boundaries, redundant vertices, unstable corners, or invalid polygons. The final geometry can depend strongly on post-processing parameters. DINO-EdgeQuery / FOSS4G Hiroshima 04
9. Why use an edge-first representation? Motivation Mask contour Vertex graph Boundary sequence Edge-first geometry follows raster noise many points and unstable links ordered points, not explicit walls walls are the primary units Building footprints are often dominated by long straight walls and a small number of corners. Buildings are often composed of long straight walls and relatively few corners. DINO-EdgeQuery therefore predicts wall-like edge primitives and learns which edge follows which. Vertices are created later from intersections of the ordered support lines. DINO-EdgeQuery / FOSS4G Hiroshima 05
10. Core concept: edge-first polygon decoding Instance prior Edge primitives Successor cycle Method Line-intersection polygon The concept has four steps. First, an instance branch finds each building. Second, EdgeQuery predicts a fixed set of candidate edges. Third, successor scores order the active edges as a cycle. Finally, line intersections create the polygon vertices. DINO-EdgeQuery / FOSS4G Hiroshima 06
11. 3. Method
12. 『Behind-the-scenes story』 Design Original design: one end-to-end training graph image instance segmentation ROI + EdgeQuery polygon reconstruction final polygon One backward pass through all branches L_inst L_edge L_succ L_vertex L_rast L_topo L_reg Design intention: learn visual recognition, edge geometry, and polygon quality together from the beginning. At the design stage, we planned to train the whole path jointly. Segmentation, edge prediction, polygon reconstruction, raster consistency, topology, and regularity losses were expected to improve together. This was the original plan, but it was not the final implementation. DINO-EdgeQuery / FOSS4G Hiroshima 07
13. Why the original joint training stalled Engineering 1. Unstable ROI conditioning 2. Competing objectives 3. One large training graph early masks and boxes change every update mask and geometry losses converge at different rates all branches retain activations for one backward pass local coordinates move during edge learning hard cycle and validity rules give weak or no gradient little memory headroom inside the 96 GB envelope Observed implementation result: segmentation improved, but EdgeQuery and polygon losses did not converge reliably. The joint graph was difficult for three reasons. Early masks and boxes changed the ROI at every update. Segmentation and geometry losses competed at different scales. Finally, all branches and polygon losses had to keep activations for the same backward pass. Within the 96-gigabyte limit, EdgeQuery learning did not progress reliably. DINO-EdgeQuery / FOSS4G Hiroshima 08
14. Practical redesign: separate optimization, unified inference Training StageG1 StageG2 Merge Boundary-aware instance training Edge primitive + successor training Single inference pipeline DINO and EdgeQuery frozen all tiles, including empty tiles instance branch frozen oracle ROI in training only predicted masks and boxes only no oracle at inference lower trainable memory stable ROI targets simpler debugging reusable checkpoints Implementation lesson - this separation was not the initial premise. It proved more stable and efficient for this model and hardware. We changed the implementation. Stage G one learns building instances. Stage G two freezes that branch and learns edges from stable oracle regions. We then merge the weights. This reduces the trainable graph, stabilizes the targets, and makes debugging easier. In our implementation, staged training was more efficient than the original joint plan, while inference remained unified. DINO-EdgeQuery / FOSS4G Hiroshima 09
15. Final implementation: staged training, one inference path Input DINOv3 + Neck Instance Decoder StageG1 optimization ROI Tokenizer EdgeQuery StageG2 optimization Successor P2 polygon assembly Architecture GeoJSON Deterministic and non-learned Training is separated. Inference executes the complete path with predicted masks and boxes. This is the final implementation. Stage G one trains the instance branch. Stage G two trains the ROI and EdgeQuery modules. The deterministic P2 assembler is not learned. After weight merging, inference runs the complete path using predicted masks and boxes only. DINO-EdgeQuery / FOSS4G Hiroshima 10
16. Overview of DINO-EdgeQuery DINO-EdgeQuery / FOSS4G Hiroshima DINO-EdgeQuery / FOSS4G Hiroshima 11
17. The training dataset for DINO-EdgeQuery requires a dataset with building annotations in COCO format. As no open datasets of satellite imagery meeting these criteria existed, we used the following open datasets of aerial photography as an alternative. Wuhan University Geospatial Computer Vision Group, n.d. WHU Building Dataset. Available at: https://gpcv.whu.edu.cn/data/building_dataset.html DINO-EdgeQuery / FOSS4G Hiroshima 12
18. Capacity evidence and dataset adjustment Empirical capacity envelope Final stable setting Why Q=96 and E=48 were practical Measured peak VRAM • 512×512 input • micro-batch 8; accumulation 2 → effective 16 • Q=96 instance queries / tile 49,470 MiB ≈ 48.3 GiB • E=48 edge slots / instance • ROI 24×24, C=256 Data 50.5% 47.3 GiB of 97,887 MiB headroom Larger configurations caused CUDA out-of-memory errors during implementation trials. Memory growth drivers Batch Instances Edges Image size M∝B activations grow with micro-batch M ∝ BQE² successor matrix scales quadratically M ∝ BQ ROI and EdgeQuery state per building slot N ∝ HW larger tiles multiply image tokens The adopted setting used only about half of the 96GB GPU, leaving safety margin for temporary tensors, allocator cache, and tile-to-tile variation. Dataset adjustment after the capacity decision The original COCO annotations were converted into fixed-capacity EdgeQuery supervision. clip COCO polygons to each 512 tile WHU 1024×1024 512 512 512 512 four non-overlapping tiles repair invalid and tiny fragments normalize exterior winding convert exterior rings to ordered edge cycles If exterior edges > 48 topology-preserving simplification Training annotation cap matched the E=48 capacity Collapsed polygons were discarded. This is an implementation constraint from the memory and E=48 capacity decision, not a neutral COCO conversion. Capacity was fixed empirically: 512px, micro-batch 8, Q=96 and E=48 used a measured peak of 49,470 MiB. The training annotations were then constrained to that E=48 edge capacity. DINO-EdgeQuery / FOSS4G Hiroshima 13
19. Visual foundation model and instance prior Adapter Neck Frozen DINOv3 512 x 512 image F8 primary mask feature F16 context F32 global context F4 boundary residual only Method mask box query embedding predicted instances confidence The mask is a visual prior, not the final contour. The image passes once through a frozen DINOv3 backbone. The adapter creates F8, F16, and F32 features, with a lightweight F4 boundary residual. The instance decoder predicts masks, boxes, query embeddings, and confidence. These predictions localize buildings, but they are not used as the final polygon contour. DINO-EdgeQuery / FOSS4G Hiroshima 14
20. ROI Tokenizer and fixed model capacity ROI crop + multi-scale fusion Method ROI tokens B x Q x 24 x 24 x 256 48 EdgeQuery slots per building candidate predicted mask + box Building capacity Q = 96 candidate slots per tile Training edge capacity E = 48 exterior edges per building Final assembly top 32 edge candidates retained by P2 profile For each building candidate, the ROI Tokenizer creates a local 24 by 24 feature grid with 256 channels. Q is the number of building candidate slots, and E is the number of edge slots for each building. The final configuration uses Q equal to 96 and E equal to 48. DINO-EdgeQuery / FOSS4G Hiroshima 15
21. Edge primitives and successor relations Method Why edges? One primitive can represent a long straight wall. one edge primitive c ℓ ℓ Directed successor cycle successor matrix Sq e1 e5 d • a: active score • c: center • d: direction • ℓ: half-length • m: axis / mode • r: relation embedding e2 e4 e3 E×E matrix size grows with E squared Each edge slot predicts activity, center, direction, length, mode, and a relation embedding. The successor head then predicts which active edge comes next. Because the successor matrix has E by E entries, its size grows with the square of the edge count. DINO-EdgeQuery / FOSS4G Hiroshima 16
22. Deterministic polygon assembly and Quality Gate P2 P1 checks Geometry P2 containment duplicate suppression mask IoU coverage outside ratio area ratio A covered by B >= 50% area(B) >= area(A) clean GIS-ready footprint centroid(A) inside B validity intersections become vertices After neural prediction, consecutive support lines are intersected to create vertices. P1 removes polygons that fail mask consistency or geometric validity. P2 then removes nested duplicate polygons using containment rules. This final assembly is deterministic and can be inspected in a GIS workflow. DINO-EdgeQuery / FOSS4G Hiroshima 17
23. 4. Experiments
24. Final inference profile Inference • Pipeline predict instances decode edges assemble polygons apply P2 gate export vectors • Default parameters confidence mask threshold pre-mask NMS edge active retained candidates 0.60 0.50 0.75 0.15 32 / instance No ground-truth boxes or masks are used at inference time. At inference time, the model uses predicted masks and boxes only. It predicts instances, decodes edges, assembles polygons, applies the P2 quality gate, and exports vectors. The final profile keeps up to 32 edge candidates for each instance after confidence and activity filtering. DINO-EdgeQuery / FOSS4G Hiroshima 18
25. 5. Results
26. Validation metrics: P2 quality gate effect Union IoU Precision@75 Metric P1 P1 P2 0.7107 0.7064 P2 Δ −0.0043 · slightly lower 0.5486 0.5924 Δ +0.0438 · better Precision@80 FP / GT P1 P1 P2 0.4622 0.5013 Δ +0.0391 · better P2 0.2997 0.2295 Δ −0.0702 · lower is better Validation P1 P2 Change Predicted polygons 21,554 19,203 −2,351 Union IoU 0.7107 0.7064 −0.0043 Recall@75 0.6459 0.6213 −0.0246 Precision@75 0.5486 0.5924 +0.0438 Recall@80 0.5442 0.5258 −0.0184 Precision@80 0.4622 0.5013 +0.0391 FP / GT 0.2997 0.2295 −0.0702 Self-intersection / triangle collapse 0/0 0/0 unchanged P2 improves high-IoU precision and reduces over-prediction; Union IoU decreases only slightly. On nonempty validation tiles, P2 reduced predicted polygons from 21,554 to 19,203. Union IoU decreased only slightly, from 0.7107 to 0.7064 (−0.0043). Precision@75 and Precision@80 improved, while FP/GT decreased; recall was modestly lower. P2 therefore favors cleaner, less redundant GIS-ready output. DINO-EdgeQuery / FOSS4G Hiroshima 19
27. Validation visualization: image-space behavior Validation Purpose: explain accuracy and failure modes before GIS export. This slide is validation: it compares image-space predictions with validation annotations. input and GT show the evaluation target predicted masks provide instance priors input tile ground truth mask predicted instances raw edges are filtered into successor cycles P2 overlay shows the final validation geometry raw EdgeQuery edges DINO-EdgeQuery / FOSS4G Hiroshima selected cycle edges final P2 overlay 20
28. Test result: final GeoJSON output in QGIS GIS Output Purpose: demonstrate that the final output is usable as open geospatial vector data. Basemap@OpenStreetMap contributor, ODbL 1.0 pixel-space P2 polygons Basemap@OpenStreetMap contributor, ODbL 1.0 GeoTIFF affine + CRS Basemap@OpenStreetMap contributor, ODbL 1.0 GeoJSON footprint features QGIS + OpenStreetMap This is the final test-time GIS output. The P2 polygons are converted from image coordinates to map coordinates using the GeoTIFF affine transform and CRS. The footprints are exported as GeoJSON and loaded into QGIS over an OpenStreetMap basemap. This result is separate from the validation metric slide. DINO-EdgeQuery / FOSS4G Hiroshima 21
29. 6. Discussion
30. What we learned  DINO-EdgeQuery provides an edge-first framework for building footprint extraction  It combines: • • • • instance-based visual priors edge primitive prediction successor-relation learning deterministic line-intersection assembly  The final P2 profile suppresses contained duplicates and lowquality polygons  The method connects deep visual prediction with verifiable geospatial geometry DINO-EdgeQuery / FOSS4G Hiroshima 22
31. Current Limitations  Dependency on the instance branch Buildings missed during instance segmentation cannot be recovered by EdgeQuery.  Assumption of a single outer edge cycle Currently, only one closed outer boundary is handled per building instance.Holes, courtyards, and multi-part buildings are flattened or excluded during dataset creation.  Domain constraints of the evaluation data The WHU Building Dataset is based on aerial imagery rather than satellite imagery. For practical deployment, validation across a wider range of regions, resolutions, and sensors—including satellite imagery—is necessary. DINO-EdgeQuery / FOSS4G Hiroshima 23
32. 6. Conclusions
33. To conclude, DINO-EdgeQuery combines instance priors, edge-first decoding, successor relations, and deterministic quality-gated assembly. It produces cleaner, GIS-ready building footprints from overhead images. 24
34. Future Work • domain-robust instance priors • multi-cycle and hole-aware polygons • replacement of DINOv3 with future foundation models • integration with Spatial Arrow Generate model-ready tensor views at runtime directly from spatially referenced raster and vector data without pre-generating fixed tiles or task-specific derivative datasets. GIS Data → Runtime Tensor View → DINO-EdgeQuery → GIS-Ready Geometry DINO-EdgeQuery / FOSS4G Hiroshima 25
35. Please refer to the following URL for the published papers. https://isprs-archives.copernicus.org/articles/L-4-W1-2026/119/2026/ 26
36. Continue the Conversation with Orbitalnet
37. Thank you.