Private geospatial data: bringing local knowledge into LGM

Public geospatial data can show where buildings, roads and land cover exist. An organization’s own records often explain what those places mean to its operations: which assets it maintains, which sites are available and which projects are already planned.

LGM’s data approach brings these perspectives into the same investigation. Public layers supply context; project-specific collections make the question relevant to the organization asking it.

Three sources of project context

The reported GeoAI layer-access update gives each deployment access to three groups of layers: data uploaded for its account, layers shared with it by other users and public LGM layers, including Overture and Australia collections.

These groups serve different purposes. An uploaded asset inventory is project context. A shared collection makes selected information available across collaborating accounts. A public collection provides a common starting point without requiring each project to assemble that source independently.

Layers are managed through the LGM Platform. Access to one collection should never be interpreted as access to every dataset held by the organization or platform.

Prepare meaning, not just files

A technically readable file can still be difficult to use correctly. Before adding a collection, document what its features or pixels represent and which questions it can reasonably answer.

Useful preparation includes:

• The geographic coverage and coordinate reference system.
• Definitions and units for important attributes.
• The observation date, update cycle and known gaps.
• The distinction between observed, estimated and planned information.
• The intended audience and permitted uses of the data.

For example, a layer of planned green spaces should not be treated as a map of existing vegetation. A service-capacity field should not be interpreted as current attendance. These distinctions need to remain visible when the data reaches an AI workflow.

Use a concrete question to connect collections

Consider a municipality investigating access to sports facilities. Public layers may describe buildings and transport. Its own records could add opening hours, facility capacity, maintenance closures and approved future projects.

The combined analysis can ask a more specific question: which areas appear underserved after accounting for the facilities that are actually usable?

That is a proposed workflow, not a claim that every required local dataset is already available in LGM. The first step is to inventory the evidence and identify what the customer can supply.

Treat sharing and publication as different decisions

Sharing a collection with another account is not the same as publishing it for unrestricted use. Before a project begins, agree which users and applications should access the source and which derived outputs may be distributed.

Derived information deserves attention too. An aggregated report or a map excerpt may still reveal sensitive operational details. The appropriate review depends on the dataset and customer requirements.

Customers should validate access behavior in their actual deployment. This article does not imply independently certified isolation, data residency or a particular enterprise security commitment; those requirements need explicit technical and contractual confirmation.

Make the result reusable

A well-prepared collection can support several interfaces: map-based investigation, an agent’s tool request or an application’s API call. The underlying definitions should remain consistent across those uses.

Start with a small, useful dataset and one repeatable question. Check the source, account access and resulting geometry before expanding to more collections. Explore Geospatial Data Layers for LGM’s approach to collecting, preparing and serving regional and customer data.