Formatting note: this report has been structured from supplied research text. Factual claims, product references, and standards references still need citation links and verification before this is treated as final research.
Map-centric panning over screen tap
Direct finger tapping on capacitive multi-touch screens introduces parallax and occlusion: the user’s hand can obscure the exact digitizing point. For professional-grade spatial accuracy, Meridian should consider a persistent center-screen crosshair where the user pans and zooms the canvas beneath the target point, then adds vertices through adjacent controls or hardware-adjacent actions.
Active-layer isolation and explicit lock state
Unlike desktop environments that can permit multi-layer editing sessions, Meridian should enforce a strict single-active-edit-layer pattern. The user explicitly selects one vector layer to modify, and all other vector assets are protected against accidental selection, editing, or spatial mutation.
Double-precision math
All internal spatial calculations in the Rust geospatial core should use 64-bit double-precision floats (f64). Single-precision float structures can introduce coordinate drift in geographic and projected coordinates, especially over long distances.
Local SQLite cache with hybrid RTree indexing
Raw GeoJSON is inefficient for real-time panning and querying. Meridian should compile imported GeoJSON into a local, offline-first SQLite database with coordinate-projected 2D RTree indexes for fast viewport bounding-box queries.
Asynchronous Rust-to-Swift core interop
Heavy geometry work such as spatial partitioning, line intersection, simplification, validation, and indexing should run in the Rust geospatial core on background threads. This keeps CPU-intensive spatial work away from the main SwiftUI thread and protects map rendering responsiveness.
Tactile and visual snapping feedback
Spatial alignment needs immediate confirmation. Meridian should display vector snapping overlays such as target rings and intersecting segments on the MapLibre canvas and can pair them with subtle haptic feedback as the cursor enters the snapping window.
Form-validation co-processor
To protect data integrity, Meridian should display a schema-validated attribute sheet immediately after geometry creation. Required fields and domain constraints should be validated before structural commits.
Transactional uncommitted buffer stack
Active drawing coordinates should be managed separately from persistent database records until the feature is finalized. This reduces the risk of corrupt geometries being committed during unexpected app interruption.
Resolution-driven geometry simplification
Rendering highly detailed geometry at low zoom levels wastes GPU and CPU resources. The Rust core should dynamically simplify render geometry, for example with Douglas-Peucker simplification, using thresholds based on current zoom and map resolution. Exact stored geometry remains the source of truth.
Lazy tabular data virtualization
Large attribute tables can exhaust iPad memory if rendered all at once. The attribute viewer should virtualize rows and query only the currently visible table window plus a buffer.
Designing an optimized iPad spatial editing workflow requires understanding how mature desktop systems manage vector data. This section compares ArcGIS Pro and QGIS patterns and translates their underlying principles for a mobile environment.
ArcGIS Pro starts an edit session automatically when a user creates, modifies, or deletes a feature on an editable layer. The edit session spans the layer workspace, such as a file geodatabase or enterprise geodatabase connection. Editing tools remain active, and transactions are pending until the user saves or discards changes.
QGIS requires an explicit Toggle Editing action on a selected layer before modifications can occur. This default read-only posture prevents accidental mutation. When active, edits are isolated to that layer’s provider, such as GeoPackage or SpatiaLite.
Meridian implication: prefer explicit editing state. Mobile users are more likely to trigger accidental gestures, so the app should make editable state visible and deliberate.
ArcGIS Pro manages layer editability through the editing view of the Contents pane, where users can toggle editing permissions for layers. Unchecked layers remain visible but protected from modification.
QGIS ties layer locking more directly to edit state. If editing is toggled off, the layer is read-only.
Meridian implication: use a single active edit layer with clear lock/read-only states for all other layers.
ArcGIS Pro snapping can run globally across the active map view and target vertices, edges, endpoints, intersections, midpoints, or tangents. Users can disable snapping for individual layers.
QGIS supports configurable snapping rules per layer and can snap to vertices, segments, areas, centroids, or segment midpoints. Tolerances can be set in map units or screen pixels.
Meridian implication: provide simple default snapping first, then expose advanced snapping options progressively. Snapping tolerance should be screen-space friendly and adapt to zoom.
ArcGIS Pro includes map topology and geodatabase topology concepts. Map topology is temporary and session-based, while geodatabase topology uses rule-based validation and identifies violations such as overlaps or gaps.
QGIS supports topological editing and validation through tools such as Geometry Checker and Topology Checker. These tools can inspect for self-intersections, duplicate nodes, dangles, gaps, overlaps, and related geometry issues.
Meridian implication: V1 should validate basic geometry correctness immediately, then reserve advanced topology rules for later.
ArcGIS Pro provides a dedicated Attributes pane for selected features, including value edits, relationships, attachments, and template defaults.
QGIS can display an attribute form immediately after feature geometry is digitized. Forms can be customized with widgets, range limits, defaults, and conditional visibility.
Meridian implication: after feature creation, show a focused attribute sheet before committing the feature.
ArcGIS Pro uses feature templates that pair target layers, construction tools, symbology, and default attributes. Feature modifications happen through a dedicated Modify Features pane.
QGIS separates creation and modification through the Digitize toolbar, Vertex Tool, and Advanced Digitizing tools such as split, reshape, rotate, and offset.
Meridian implication: V1 should keep drawing and vertex editing tools obvious and mode-specific, then grow into advanced reshape/split operations after core editing is stable.
ArcGIS Pro uses editing-specific selection flows to avoid accidentally clearing active editing selections during modification.
QGIS selection is more global across the map canvas and attribute table.
Meridian implication: selection should sync between map and table, but editing modes should protect the active selection from accidental loss.
ArcGIS Pro maintains a centralized undo/redo stack across the edit workspace.
QGIS typically isolates undo/redo to each editable layer.
Meridian implication: layer-scoped or edit-session-scoped undo is safer for an iPad V1 than project-wide undo across many layers.
ArcGIS Pro uses a Cartographic Information Model and can tie unique-value symbology to feature templates.
QGIS supports rule-based, categorized, and graduated renderers, with styling and labelling saved in project files.
Meridian implication: store styling and label rules in the project package, and let layer styles influence default feature creation where useful.
ArcGIS Pro projects contain maps, scenes, geodatabase connections, toolboxes, and folder shortcuts. Layers can include definition queries, scale ranges, and metadata.
QGIS projects organize layers in a tree with grouping, legend styling, visibility presets, and file/database/web-service connections.
Meridian implication: .gispad projects should preserve layer order, visibility, styles, labels, basemap, viewport, and metadata without becoming a desktop-GIS-style project kitchen sink.
Meridian should execute spatial calculations using 64-bit double-precision floats (f64). A 32-bit float provides roughly 24 bits of mantissa precision, or about 7 decimal digits. When working with global Mercator coordinates, values can reach roughly 20,037,508 meters, which limits coordinate resolution:
\text{Precision Limit} \approx \frac{20037508}{2^{23}} \approx 2.38
This precision limit is not acceptable for professional editing. A 64-bit double provides 53 bits of mantissa precision:
\text{Precision Limit} \approx \frac{20037508}{2^{52}} \approx 4.45 \times 10^{-9}
GPS receivers commonly output WGS84 (EPSG:4326) coordinates, while web map renderers such as MapLibre use Web Mercator (EPSG:3857) for map display. On-the-fly projection from geographic coordinates (phi, lambda) into projected Mercator coordinates (x, y) can be represented as:
x = R \cdot \lambda
y = R \cdot \ln \left( \tan \left( \frac{\pi}{4} + \frac{\phi}{2} \right) \right)
where R represents the Earth’s equatorial radius, commonly 6,378,137 meters in Web Mercator.
Planar Euclidean distance or area calculations on geographic coordinates can introduce severe distortion, especially as latitude changes. Meridian should calculate distance and area using geodesic or ellipsoidal methods.
If a user imports local projected data, such as UTM or State Plane, the app should avoid silent data loss. Possible handling patterns include:
V1 alignment note: the current app plan assumes editable GeoJSON is WGS84/EPSG:4326 and warns on unsupported CRS instead of transforming. Treat broader CRS transformation as a research recommendation, not an approved V1 requirement.
A valid vector feature should comply with OGC Simple Feature-style geometry expectations. The geospatial core should inspect incoming and modified geometries for:
If an edit violates these rules, Meridian should flag it as invalid, block commit, and direct the user to the issue.
Snapping keeps adjacent features aligned. On iPad, snapping tolerance should start from screen-space points and convert to map units based on zoom.
Let T_points be the user-defined snapping tolerance in iOS points, commonly 10 to 20 points. Let S be the current map scale, representing the relationship between screen points and ground meters:
S = \frac{W_{\text{meters}}}{W_{\text{points}}}
The active snapping tolerance in ground meters is:
T_{\text{meters}} = T_{\text{points}} \times S
When the user moves the cursor or crosshair, the snapping engine can query the SQLite spatial index using a bounding box centered on the target coordinate, buffered by T_meters. It then evaluates candidate vertices and segments to find the closest snap target inside the search radius.
To prevent data loss from crashes or power failure, Meridian should use a transactional write-ahead model:
Directly porting desktop interfaces to multi-touch usually creates frustration. Meridian should adapt desktop GIS principles to touch and Pencil interaction.
+----------------------------------------+
| |
| (Existing Polygon) |
| o--------------o |
| | | |
| | Target | |
| | Vertex | |
| o------X-------o |
| ^ |
| | <--- Snapping Vector |
| | |
| [ + ] <--- Center Crosshair
| (Fixed Point) |
| |
| Pan map to align Crosshair with target |
+----------------------------------------+
[ Add Vertex ]
Plan alignment note: Aero currently specifies tap/Pencil drawing with live snap rings and vertex handles. The center-crosshair model is a research recommendation to evaluate, especially for high-precision mode, not an automatic replacement for Aero’s drawing flow.
To reduce cognitive load and accidental edits, the interface should limit editing to a single active layer.
When the user selects a target layer and starts editing:
The research recommends a high-precision map-panning crosshair interface:
Overlapping feature selection is difficult on touch screens. Meridian should use spatial disambiguation:
For line and polygon creation, the editing interface should provide large controls:
When editing existing geometry, selecting a feature should reveal vertices as interactive handles. Selecting a vertex should allow repositioning or deletion.
Validation should be immediate but non-intrusive.
Example error:
Self-intersecting polygon boundary detected. Remove the crossing vertex to save.
Meridian should support clear layer organization:
MapLibre styles should drive high-performance GPU-rendered layers.
Core principles:
Example:
z_{\text{min}} \le z \le z_{\text{max}}
A dense parcel boundary layer might hide when zoomed out beyond level 14 to reduce clutter and rendering cost.
Research recommendation:
V1 alignment note: the current app plan emphasizes PMTiles for local basemaps. MBTiles support may be useful, but should be treated as a separate product decision.
Modern iPads have strong GPUs and unified memory. Meridian should lean on this hardware while preventing CPU-heavy GIS work from blocking UI.
+-------------------------------------------------------+
| SwiftUI / MapLibre View |
+-------------------------------------------------------+
^
| (Vector tiles / tile payloads)
|
+-------------------------------------------------------+
| Rust Geospatial Core |
| - SQLite database with RTree spatial index |
| - Dynamic Douglas-Peucker simplification |
| - Geometry validity inspections |
+-------------------------------------------------------+
Loading raw GeoJSON into memory and scanning every feature for viewport intersection is inefficient. SQLite RTree indexing can reduce viewport query work from linear scanning to indexed bounding-box lookup.
When the map extent changes, the system retrieves viewport coordinates and queries the RTree index:
SELECT feature_id, geometry_blob
FROM spatial_layer
WHERE feature_id IN (
SELECT id
FROM rtree_spatial_index
WHERE minX <= :x_max AND maxX >= :x_min
AND minY <= :y_max AND maxY >= :y_min
);
To keep memory and rendering costs low:
If each pixel represents R meters and the threshold is 1.5 pixels:
\epsilon = P_{\text{size}} \times d_{\text{threshold}}
For a threshold of d_threshold = 1.5, vertices within 1.5 * R meters of the simplified segment can be discarded from the render representation.
Keep data processing and UI rendering separated:
Pass optimized payloads across the boundary where possible, such as vector tiles or compact binary geometry blocks.
Attribute tables with thousands of features must be virtualized. SwiftUI List, lazy containers, or custom virtualized table views should be backed by database cursors and visible-row windows.
The UI should render only:
| Priority | Feature / Workflow | Technical Implementation Strategy | iPad Adaptation Justification |
|---|---|---|---|
| Must-have V1 | Single-active edit layer | Hard UI constraint. Starting edit mode locks all other layers. | Prevents write conflicts and accidental edits on overlapping layers. |
| Must-have V1 | Map-panning crosshair | Fixed central crosshair, map panned beneath it, large action buttons. | Avoids hand occlusion and precision limits of finger taps. |
| Must-have V1 | SQLite/RTree cache | Convert imported GeoJSON into SQLite with RTree index. | Avoids memory pressure and slow large-file rendering. |
| Must-have V1 | Basic vertex snapping | Snap to active or visible layer vertices with clear feedback. | Essential for precise node alignment. |
| Must-have V1 | Immediate form validation | Schema-aware SwiftUI sheet after geometry creation. | Protects attribute completeness and data integrity. |
| Should-have V1 | Segment snapping | Snap to line segments and polygon boundaries. | Supports touching boundaries and connected linework. |
| Should-have V1 | Geodesic measurement | Rust-based ellipsoidal area and distance calculations. | Avoids projection-related measurement errors. |
| Should-have V1 | CRS warnings | Detect layer/map CRS mismatch and show non-blocking alerts. | Makes transformation assumptions visible. |
| Should-have V1 | In-memory undo/redo | Edit-session undo stack for uncommitted vertex changes. | Lets users recover from mistakes before save. |
| Post-V1 | Avoid overlap | Split or trim intersecting polygons on save. | Useful for parcel and administrative boundary workflows. |
| Post-V1 | Split and reshape tools | Advanced line cutting and boundary modification. | Enables complex edits to existing geometries. |
| Post-V1 | GPS streaming mode | Record vertices by time or distance interval. | Supports field collection while walking or driving. |
| Desktop GIS Pattern | Core Software Principle | iPad-Native Adaptation |
|---|---|---|
| Per-layer toggle editing mode | Restrict data modification to authorized datasets. | Active layer focus: one target layer is editable, while other layers are locked. |
| Point-and-click digitizing | Capture exact map coordinates from user input. | Center crosshair with pan and zoom for high-precision mode. |
| Advanced snapping options panel | Align vertices within a tolerance to prevent topology gaps. | Simplified snapping controls with screen-point tolerance and haptic/visual feedback. |
| Manual topology runs | Enforce geometry validity before committing changes. | Background validation with highlighted invalid geometry and disabled save. |
| Floating or docked attribute table | Inspect and edit large tabular datasets. | Slide-over sheets and virtualized tables with large touch targets. |
| Feature / Workflow | ArcGIS Pro Desktop Model | QGIS Desktop Model | Meridian Recommendation |
|---|---|---|---|
| Editing session initiation | Automatic upon editing editable map layers; manual control optional. | Manual toggle editing per layer. | Active edit mode toggled deliberately, one layer at a time. |
| Layer isolation | Workspace-wide editable layers can be updated together. | Layer-specific edits through individual providers. | Single-layer isolation with other layers locked. |
| Snapping configuration | Global map settings with layer-specific exclusions. | Per-layer controls and map-unit or screen-pixel tolerances. | Global auto-tolerance in screen points, scaling with zoom. |
| Topology and validation | Geodatabase topology rules with post-edit validation. | Geometry Checker and Topology Checker tools. | Async validation in Rust with immediate warnings. |
| Geometry creation tools | Feature templates pair style, default attributes, and tools. | Separate feature drawing and vertex editing tools. | Touch-friendly drawing tools, plus optional high-precision crosshair mode. |
| Attribute forms | Attributes pane with manual inputs and relationships. | Customizable forms can open after feature creation. | Automated slide-over sheets after feature creation. |
| Undo/redo architecture | Project-wide undo stack across the edit workspace. | Layer-specific undo stack. | Edit-session drawing stack, committed only after confirmation. |
Add citations before treating this as final research: