ProjectRecord

An independent, cloud-delivered GIS platform for US county and municipal government, aimed at ESRI-workflow parity for assessment and public-records work at a fraction of the cost. Parcels, LiDAR point clouds and orthoimagery are served from a PostgreSQL/PostGIS origin through a Cloudflare edge, and the whole stack ships as one appliance image that deploys turnkey on-premises or into any cloud.

The design decision the rest of the system is built around is that owner-privacy suppression lives in the data layer, not the interface. Public reads happen only through restricted views, so a protected owner is redacted once and is therefore redacted everywhere — vector tiles, API responses and exports alike. There is no code path that can forget to apply it. The same principle governs the job queue: the API is granted permission to enqueue work and nothing else, the worker to claim and update and nothing else, enforced by database grants rather than by convention.

The parcel record is a temporal cadastre — every reload preserves history and suppressions, so a record can be read as it stood at any prior ingest, with field-level diffs between versions. LiDAR is derived per parcel from USGS 3DEP: the worker computes a buffered parcel boundary, streams the source point cloud through PDAL into a COPC file and publishes it to a local VM's storage volume, where the viewer streams it directly over ranged HTTP — object storage moved out of the alpha environment to keep the testing surface cheap to run. No point-cloud server is involved at any stage.

PinePoint is presently in early alpha, developed by a small team based in Maine. External client testing has not opened yet; in its place, interested county and municipal contacts can register through the alpha interest form below, and early registrants get limited free testing as the platform moves toward a general pilot.

• Public parcel viewer with satellite basemap, per-municipality extents and suppression-redacted records
• Per-parcel 3D LiDAR streamed from local VM storage — measurement, annotation and per-class filtering
• Temporal cadastre with full version history and field-level diffs across ingests
• Access-gated admin console: municipality ingest, job control, data-quality reporting, batch export
• Owner-privacy suppression enforced in the data layer, applied identically to tiles, API and exports
• Append-only audit trail on every record access, with anomaly capture on every ingest
• Esri and OGC interop endpoints so existing county workflows keep working

A Windows desktop application and matching command-line tool that drive PDAL and GDAL to turn classified LAS/LAZ point clouds into terrain, surface, canopy and vegetation-obstruction deliverables. Every workflow runs from either surface, and the engine is shared — the app is a front end over the same code the CLI calls.

The interface is the part that was rebuilt. A navigation rail carries one page per workflow in execution order, with a dot beside any page that has something enabled so nothing can run from a screen you cannot currently see. Dependent options enforce themselves: selecting a canopy model switches on the terrain and surface models it derives from and holds them there, visibly checked and greyed, because the result is meaningless without them. A pinned action bar states the plan in words — “Will run: Classification → Rasters → Obstruction” — and a preflight dialog reviews it before anything starts, listing what each stage reads and blocking the run outright on a missing tool or an empty input. Cancel is the default button, so a stray keystroke cannot launch a multi-hour job.

Underneath, the dependency footprint is deliberately small. The processing engine and the entire CLI are standard-library only — no packages at all on a bare Python install. The desktop layer is the only part that needs Qt, and it installs itself into a local virtual environment on first launch without touching the system Python. Where PDAL and GDAL are not already on the path, the app resolves them from an existing QGIS installation.

• Terrain, surface and canopy models with optional Cloud-Optimized GeoTIFF output
• Vegetation and building classification by height-above-ground or absolute elevation
• Vegetation-obstruction heat map and a clustered obstruction table, ranked worst-first
• ASPRS accuracy reporting against surveyed checkpoints, with mean bias separated from scatter
• GCP vertical correction, project-wide LAS merge and automatic tiling of oversized inputs
• Preflight review dialog stating the run plan, its inputs and any blocking findings
• Native light/dark theming that follows the Windows accent colour, with settings persisted between launches

A Windows desktop application that answers the question asked at the start of every LiDAR job: what is actually in this delivery? It scans a directory of LAS files in parallel and writes a single self-contained HTML report — point counts and densities, return and classification distributions, geographic bounds, coverage acreage, an interactive map of the footprints, and a full overlap analysis. The report is one file with no dependencies, so it can be sent to a client or filed against the job without anything else needing to be installed to read it.

Coverage is computed as a true convex hull over the returns rather than from the bounding box, which is the difference between a defensible acreage figure and a flattering one. Point clouds are large enough that this has to be done carefully: the hull decimates adaptively above half a million points, drops to a far more aggressive sample when the machine is short on memory, and switches to 64-bit precision past a hundred million points where single precision would start to move the answer.

Overlap is analysed pairwise and per-folder, then run through a connectivity graph so isolated files — the tile nobody noticed was detached from the rest of the block — surface on their own rather than having to be spotted by eye. Coordinate reference systems are read from the file's own metadata and densities are reported in that system's units; where the CRS cannot be determined it is reported as unknown rather than assumed, because a density figure computed against a guessed unit is worse than no figure at all.

Long scans are cancellable at phase boundaries inside each file, not merely between files, so a hull computation running on a very large tile can still be interrupted. A preflight check warns before a scan whose concurrent memory use would exceed what is available.

• Parallel scan of a whole directory tree, with per-file and project-wide statistics
• Convex-hull coverage acreage with adaptive decimation and precision switching on large clouds
• Pairwise and per-folder overlap analysis, with connectivity detection for isolated files
• Interactive footprint map rendered into the report itself, with optional satellite basemap
• CRS read from file metadata with unit-aware density — unknown is reported, never assumed
• Ten toggleable report sections and a print-optimised layout, persisted between runs
• Memory preflight before a scan, and cancellation honoured mid-file rather than only between files