# Placemark for Local GeoJSON Editing and Map Workflows

> Placemark is a TypeScript web application for creating, viewing, editing, and analyzing geospatial data. It is aimed at developers who need a local browser workflow for GeoJSON, KML, WKT, and related map data, with MapLibre rendering and optional external search and routing services.

**placemark/placemark** — A flexible web-based editor, converter, visualization tool, for geospatial data

- Repository: https://github.com/placemark/placemark
- Website: https://placemark.io/
- Stars: 1,469 · Forks: 125
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/placemark-placemark

## Placemark's Local GeoJSON Editing Scope

Placemark addresses a specific gap between raw geospatial files and a full desktop GIS environment. It is a web-based editor for creating, viewing, editing, and analyzing map data. The package metadata identifies GeoJSON, KML, WKT, and shapefiles as relevant formats, which makes the project relevant to developers, GIS practitioners, and teams that need to inspect or modify geometry without treating every task as a full desktop GIS deployment.

The README describes two usage paths. Most users are directed to the hosted Placemark.io instance. The README is aimed at developers who want to run the application locally, fork it, or experiment with its code. The project is therefore designed for browser-based experimentation and self-hosting, but the documented developer path focuses on local operation rather than a complete server-side GIS installation.

The distinction matters. Placemark can help with browser-based map data work, yet the README does not describe multi-user accounts, permissions, database-backed editing, transactional history, or an administrative GIS workflow. Those omissions do not prove that the application cannot support them, but they are not documented capabilities that an adoption decision should assume. A team needing collaborative editing and governed changes should verify those requirements before selecting the project.

## MapLibre Rendering and External Service Boundaries

The documented rendering layer uses MapLibre GL JS. Default basemaps are hosted by OpenFreeMap and require no token, while Mapbox-hosted basemap styles are explicitly not loaded. This gives local developers a map display without requiring a Mapbox token, but it also means that deployment depends on an external basemap service unless another compatible style is configured.

Search is optional and uses a Geocode Earth token. The token is exposed through a Vite public environment variable named `VITE_PUBLIC_GEOCODE_EARTH_TOKEN`. The README advises setting allowed Referrer Hostnames on the token when the application is used frequently or publicly. That is an operational requirement for the search integration, not a general requirement for rendering a map.

Routing is also optional. The repository supports openrouteservice, Geoapify, and OSRM, but no routing service is configured by default. A local developer can therefore start without a routing account, though route-related features will not have a configured backend service unless the provider settings are added. These boundaries make Placemark suitable for a modular editing front end, while leaving the organization responsible for choosing and managing third-party map and location services.

The default basemap and optional routing services also create external dependency questions. The README does not document offline map packaging, service availability guarantees, request quotas, or billing behavior. Teams operating in restricted networks or requiring predictable offline work should check those points separately.

## Running Placemark With Vite and pnpm

The README says the repository expects pnpm and Node 24.5.0. It gives a short local workflow for macOS and points to `mise` or manual installation for the required toolchain. The literal clone example in the README is incomplete, so it is shown here exactly as documented and should be completed with the repository URL before use.

```sh
git clone
pnpm install
```

After dependencies are installed, the application can be started in development mode with hot reloading:

```sh
pnpm dev
```

The `package.json` identifies Vite as the development server and `vite build` as the production build command. For a built static directory, the README gives this serving example:

```sh
pnpm build
pnpm dlx serve@latest dist
```

The expected result is a local development server for `pnpm dev`, or a `dist/` directory that can be served as ordinary static files after the build. The repository includes `dev.Dockerfile`, and the README also mentions Docker and Render approaches, but it does not provide enough detail here to reproduce either path without consulting those files.

The application is therefore easy to start for a developer who already has Node 24.5.0 and pnpm. The missing repository URL in the documented clone example is a documentation limitation, not an application feature. Before deployment, inspect the Docker configuration and the Vite build settings rather than assuming that a successful local build defines the production topology.

## Configuring Placemark Search and Routing Tokens

Placemark can run without optional service credentials for its default map display. If search is needed, the README instructs developers to obtain a Geocode Earth token and configure the Vite public variable. For local development, the repository includes `.env.example`, which can be copied to `.env.local`.

```sh
cp .env.example .env.local
```

The example file documents the search variable and optional routing variables:

```sh
VITE_PUBLIC_GEOCODE_EARTH_TOKEN=xxx
# VITE_PUBLIC_ROUTING_PROVIDER=openrouteservice
# VITE_PUBLIC_ROUTING_API_KEY=xxx
```

The comments show that the routing provider and API key are alternatives, not mandatory values. The example names `openrouteservice`, while the routing documentation referenced by the README also describes Geoapify and OSRM. Because the example uses `xxx` placeholders, a developer must replace the token and key values before expecting authenticated search or routing requests to work.

The README does not document token rotation, request quotas, billing, or a complete error-handling policy. Those points require checking with the relevant provider and by examining the routing configuration documentation. The variables are Vite public variables, so deployments should also review what information is embedded in the client bundle before adding credentials. The README itself only establishes that these variables are used for search and routing configuration; it does not establish a security model for third-party keys.

## Choosing Placemark Instead of a Desktop GIS Workflow

Placemark is a different kind of tool from a desktop GIS package. The repository layout points to a TypeScript application with `app/`, `pages/`, `state/`, `workers/`, `integrations/`, and tests under `test/`. The package includes CodeMirror components, MapLibre style tooling, geospatial conversion packages such as `@placemarkio/tokml`, `@placemarkio/osmtogeojson`, and geometry utilities, plus React-based interface dependencies. Based on that layout, the application is assembled from map rendering, editing state, data conversion, and supporting workers.

This approach is useful when the data already fits a web workflow and the team wants a user interface rather than a command-line conversion script. It also gives developers a codebase they can fork and change. The trade-off is that the README does not establish parity with desktop GIS systems for advanced projection management, large dataset processing, topology editing, or production cartographic publishing. Those workflows require separate verification.

The repository identifies `geojson.io/next` as an interesting fork and `epanetjs` as a specialized water-modeling fork. Those examples show that the application can be adapted for different audiences, but they are not evidence that every specialized feature is present in the main Placemark repository. A team whose work depends on specialized water modeling should examine the fork and its maintenance separately.

The repository also includes `state/`, `workers/`, and `integrations/`, which suggests that state management and heavier processing are separated from interface files. That separation may help developers modify the application, but the README does not document the data model, persistence layer, or limits on dataset size. Those are concrete adoption checks for large or frequently changing files.

## Maintenance, Licensing, and Adoption Boundaries

The repository is not archived. Its last push was on 2026-10-14, and the release information lists v0.4.1 on 2026-07-08, v0.4.0 on 2026-07-03, and v0.3.0 on 2026-04-19. The `package.json` currently reports version 0.5.0, while the listed releases end at v0.4.1. That difference is worth checking during dependency planning because the source version and published release history are not identical in the repository information.

Placemark uses the MIT license. That license is compatible with many forms of modification and redistribution, subject to its terms. This is a licensing observation, not legal advice. The repository contains `CHANGELOG.md`, `.changeset/`, Renovate configuration, a lockfile, and `mise.toml`, which indicates release and dependency maintenance files are part of the project structure. The README does not document a support policy, migration guide for every release, or compatibility promise for upgrades.

For adoption, the first verification should be operational rather than promotional. Confirm the supported input files, check whether the required routing provider needs credentials, and inspect the Docker or Render files if a public deployment is planned. The last recorded push and recent release history indicate recent repository activity, but the README still leaves deployment, persistence, and advanced GIS behavior undocumented. A production team should also review `SECURITY.md` and the project’s dependency policy before storing sensitive geospatial data.

## Conclusion

Adopt Placemark when a developer needs a self-hosted, browser-based workflow for inspecting and editing geospatial datasets, especially when MapLibre-compatible rendering and local development matter. Do not choose it as a ready-made production GIS platform without checking the deployment path, optional service configuration, and data compatibility requirements. Verify first whether the documented import formats and routing configuration match the files and services your team already uses, then inspect the current release and deployment setup before committing to it.

## FAQ

### How do I install Placemark locally?

The README requires pnpm and Node 24.5.0, then documents `pnpm install` followed by `pnpm dev`. It describes the clone command only as `git clone`, without a repository URL.

### Does Placemark require a Mapbox token to display its default maps?

No. The README states that default basemaps are hosted by OpenFreeMap and require no token, while Mapbox-hosted basemap styles are not loaded.

### Which routing services can Placemark use?

The repository supports openrouteservice, Geoapify, and OSRM. Routing is optional, and no routing service is configured by default.

## Sources

- [License: MIT](https://github.com/placemark/placemark/blob/main/LICENSE)
- [placemark/placemark on GitHub](https://github.com/placemark/placemark)
- [Project website](https://placemark.io/)
- [README](https://github.com/placemark/placemark/blob/main/README.md)
- [Releases](https://github.com/placemark/placemark/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/placemark-placemark