Frontmatter
| id | 6610 |
| title | main.addon.OpenStreetMaps |
| state | Open |
| labels | enhancementdeveloper-experienceno auto closecore |
| assignees | tobiu |
| createdAt | Apr 1, 2025, 10:01 PM |
| updatedAt | Jun 23, 2026, 7:33 AM |
| githubUrl | https://github.com/neomjs/neo/issues/6610 |
| author | tobiu |
| commentsCount | 3 |
| parentIssue | null |
| subIssues | [] |
| subIssuesCompleted | 0 |
| subIssuesTotal | 0 |
| contentTrust | |
| projected | |
| quarantined | 3 |
| signals | [] |
| blockedBy | [] |
| blocking | [] |
main.addon.OpenStreetMaps

I think this can be done with the OpenLayers [QUARANTINED_URL: openlayers.org] library. The markers would be created as a vector layer [QUARANTINED_URL: openlayers.org] on top of a tile layer pulled from OpenStreetMaps as described in this [QUARANTINED_URL: openlayers.org] example. It appears that there's no need for an api key to pull tiles from OSM.
I would be interested in working on this.

@TomDakan You are very welcome to give it a try! I think this specific topic should be fun (a great learning experience), since it covers a wrapper component, a new main thread addon, RPC based cross-thread communication, and the potential for using the new intercept remotes pattern for addons (e.g. easily queue a request to create a map instance until the map lib is loaded).
It might even work to use LLMs (like Gemini CLI) here.
I did use MapboxGL (also based on top of OSM) for the Covid Apps. Feel free to explore existing addons and wrapper components first, and explore how they work (or feed an LLM with it).
One very strong recommendation when it comes to PRs: Keep them as small and targeted as possible. E.g. create sub tickets, like "create the addon base class file" => PR, accepted. Next sub: "add logic for adding markers" => PR.
Submitting a massive PR which would e.g. resolve 8 tickets, but introduce 2 new bugs might end up in a lot of reasoning back and forth to get to a merge-ready state. This could lead to frustration, which can easily get avoided with smaller PRs.
Feel free to ask questions on Slack / Discord, and I can give you more pointers.
Best regards, Tobias
- 2026-06-23T05:33:33Z @neo-gpt added the
corelabel - 2026-06-23T05:33:33Z @neo-gpt added the
developer-experiencelabel
@neo-gpt - 2026-06-23T05:33:34Z
[ARCH_ALIGNMENT] Triage result: valid core/developer-experience enhancement; partially implemented, not complete.
Triaged per ticket-triage skill. Applied: core, developer-experience. Existing enhancement and no auto close remain correct. I did not add ai or change assignment because the issue is currently assigned to @tobiu.
Evidence checked:
src/main/addon/OpenStreetMaps.mjsexists and implements the OpenLayers loading path pluscreate(),panTo(), andsetZoom()for a basic OSM tile map.src/component/wrapper/OpenStreetMaps.mjsexists and exposes the worker-side wrapper API.examples/component/wrapper/openStreetMaps/exists as a runnable example surface.- The original issue scope also asks for markers. That part is still incomplete in the main-thread addon:
addMarker(),destroyMarkers(),hideMarker(),removeMarker(),showMarker(), andremoveMap()are still TODOs insrc/main/addon/OpenStreetMaps.mjs; marker vector source/layer wiring increate()is commented out.
Disposition: leave open. The current best next PR shape is a narrow marker-support slice against the existing addon/wrapper/example, not a from-scratch OpenStreetMaps addon.
In case this is the case, I would like to create a new addon which is roughly on feature parity with
main.addon.GoogleMaps.