OSPP 2024 Project: Frontend technology based OpenS... OpenStreetMap diary

It’s been over two weeks since the last progress report, and it’s time to update on the current status.

Project Progress

The core modules of the project have now been largely finalized, allowing us to enter the latter stage of development. The upcoming work will mainly involve adding new features within the existing framework.

Render

Firstly, the rendering part has been set up, though there are still some details that need polishment, such as styles and elements controlling the rendering. These will be adjusted in sync with the subsequent feature development to ensure that the styling aligns with the editing logic.

API call and XML obj

I’ve developed an OSM API module that wraps some of OSM’s interfaces using Promises and parses the returned XML into a JavaScript object for easier manipulation within the program.

Editor’s status management

Following that is the editing module, which primarily includes the operation logic and global data management.

For the operation logic in map editing, I’ve introduced a state machine, which manages the current state of the editor by listening to mouse and keyboard events. The state machine, referred to as “stateMachine.js” in the code, handles state transitions and data maintenance based on the functions and state relationships provided in the state diagram. Depending on the current state, it determines which actions to trigger and the new state to transition into. The state machine provides hooks that allow other components, such as mouse events in Pixi.js, to track events. Editing operations are carried out during state transitions.

Generally speaking, a series of changes to the global data occur during state transitions within the state machine. To manage these changes, a doubly linked list is used, referred to as the “action list” in the code. This list offers undo, redo, and do interfaces. The do interface accepts an action, executes it, and then adds it to the end of the list. To avoid multiple duplicate actions, some actions are merged.

An action provides do, undo, and redo interfaces, and some actions also offer a merge option. Actions should maintain global data when executed, undone, or redone, and also manage other related changes, such as the UI of affected elements and data across layers. This approach ensures that all changes are centralized, minimizing the cognitive load associated with maintaining related changes during undo and redo operations.

The global data is an object referenced within each action, and the action list ensures that the sequence of actions is correct during undo and redo operations. For example, it ensures that when undoing an action, the state reflects that all subsequent actions have already been undone.

Since the actual editing operations are not yet complete, undo and redo functionalities are temporarily not considered, as they depend on parts of the code that are still in progress.

Mermaid graph of status management

Update Plan

The project has been under development for about a month now, and with the deadline at the end of September, time is relatively tight. Therefore, I will prioritize completing the core functionalities and defer some non-core features to be completed later, ensuring a smooth completion of the project.

Below are the main features that need to be implemented:

UI Components

Outline View: Displays all current elements, allowing selection and basic state management of elements.
Property View: Manages various properties, including global settings and metadata of the currently selected element.
Some standalone components, such as creating new nodes, connecting line segments, etc.

Please note that the implementation of the UI may be postponed, as priority will be given to developing the basic graphical module.

Functional Aspects

As a public transit editor, it should support public transit editing functionalities. In OSM XML, public transit relations are represented by a relation element that has a route and a series of tags indicating the specifics of that element.

For editing metadata, the previously mentioned Property View can be used.

For editing the exact positions of points, the map module will be utilized. I’ve consider adding some styles to highlight the current route being edited, making it easier to identify.

For the member relationship between routes, points, and paths, the map’s selection functionality needs to be integrated with the Property View.

Additionally, there may be a need for a route creation feature, including adding new points, creating new routes, and editing route properties.

To implement route calculation based on station relations, leveraging existing APIs such as Valhalla or OSRM can be highly effective, given their strong integration with the OSM data model. I am considering building a dedicated instance of one of these projects to be deployed concurrently with the release of the tool. This instance would be specifically configured for exclusive use with the editor.

Demo Effect

Apologies for haven’t had the opportunity to fully refine it; all elements share the same style, which indeed looks unappealing.

However, with a few more lines of code, I can remove the building’s(and other non-highway way feature’s) rendering, which will make it look much better. I will gradually adjust the style afterward—maybe borrow some colors from the iD editor?

As for editing features, I won’t demonstrate them now since the only functionalities are dragging points, panning the map, and adjusting the zoom level.