syncpoint / odin Goto Github PK

Rationale: Once fielded, access to online (i.e. Internet) raster tile providers is not an option. The application must be able to use tile providers on the local network.

For now a simple configuration file (tile-providers.json) defining one or more local or remote tile providers is good enough. Additional properties may directly be forwarded to Leaflet's tile layer options.

{  
    "id": "Basemap.AT",  
    "name": "Basemap (AT)",  
    "url": "https://maps{s}.wien.gv.at/basemap/geolandbasemap/normal/google3857/{z}/{y}/{x}.png",  
    "subdomains": ["", "1", "2", "3", "4"],  
    "maxZoom": 19,
    "bounds": [[46.35877, 8.782379], [49.037872, 17.189532]],
    "attribution": "Datenquelle: <a href=\"https://www.basemap.at\">basemap.at</a>"
}

If you try to use the flyto() function in the Class Map, a lot of exceptions: Uncaught TypeError: Cannot read property 'scale' of undefined at NewClass.updateScale (Map.js:464) at NewClass.fire (leaflet-src.js:593) at NewClass._move (leaflet-src.js:4235) at NewClass.frame (leaflet-src.js:3413) are fired.

Only when the new view is reached scale is defined and the updateScale function is satisfied.

If you zoom in too far on the different maps, no more map will be displayed.

The system should only zoom in so that the map is still visible at the maximum zoom level.

It is reasonable to assume, that the (military) user usually want's to find places in near proximity to current map view port.

Running npm test throws an error:

else throw err
           ^

Error: Cannot find module '../lib/disposable'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
    at Function.Module._load (internal/modules/cjs/loader.js:507:25)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.<anonymous> (/Users/Thomas/Dev/ODIN/test/disposable-test.js:2:20)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at /Users/Thomas/Dev/ODIN/node_modules/mocha/lib/mocha.js:330:36
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/Users/Thomas/Dev/ODIN/node_modules/mocha/lib/mocha.js:327:14)
    at Mocha.run (/Users/Thomas/Dev/ODIN/node_modules/mocha/lib/mocha.js:804:10)
    at Object.exports.singleRun (/Users/Thomas/Dev/ODIN/node_modules/mocha/lib/cli/run-helpers.js:207:16)
    at exports.runMocha (/Users/Thomas/Dev/ODIN/node_modules/mocha/lib/cli/run-helpers.js:300:13)
    at Object.exports.handler.argv [as handler] (/Users/Thomas/Dev/ODIN/node_modules/mocha/lib/cli/run.js:296:3)
    at Object.runCommand (/Users/Thomas/Dev/ODIN/node_modules/yargs/lib/command.js:242:26)
    at Object.parseArgs [as _parseArgs] (/Users/Thomas/Dev/ODIN/node_modules/yargs/yargs.js:1104:24)
    at Object.parse (/Users/Thomas/Dev/ODIN/node_modules/yargs/yargs.js:566:25)
    at Object.exports.main (/Users/Thomas/Dev/ODIN/node_modules/mocha/lib/cli/cli.js:63:6)
    at Object.<anonymous> (/Users/Thomas/Dev/ODIN/node_modules/mocha/bin/_mocha:10:23)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3)
npm ERR! Test failed.  See above for more details.

Besides creating a great UI experience for users I’d like to discuss the idea of building an API. The use case for the API is to automate (map) functionality for presentations or personal tracking (sending my gps position via mobile app and visualize it on the map; keep the center of the following my position).

This might be a little early but I like the idea of having an easy-to-use API that creates some kind of playground.

There seems to be an upstream problem with Leaflet and/or Chromium, which results in inexact tile placement on canvas. See the 'grid' in the following screenshot.

Currently we just can wait and hope that this issue gets fixed in the not so far future.

NOTE: On Windows platform this problem cannot be reproduced.

For now a online search will do: OSM Nominatim

Design proposal: (macOS) vertical Spotlight-like control with search text input (A), scrollable result list (B) (limited to 7 to 10 items and map preview (C) (with pan and zoom). The control should be placed as a sidebar on the right.

NOTE: The right sidebar is considered to overlap the map only temporarily (auto close). Whereas the left sidebar will have a more 'persistent' character.

The two shortcuts

Alt + Strg + 2 (for Contrast)
Alt + Strg + 3 (for Grayscale)

are inactive.

If you want to use it, the only possible way is about the Menue (View - Map - Filter ...).

the "spotlight" view on the right side, has a dynamic width depending on the size of the window. I would recommend to set its width using "em" so it is independent from resolution and window size.

Application window position and extent should be stored between sessions.
Testing should focus on situations where multiple displays are involved. E.g. move application to secondary display, close application, detach display, open application again.

NOTE: Electron seems to have some issues with explicit window positioning. Especially when more than one display with different scaling factors are used. Workarounds might be necessary to achieve this.

electron-builder can publish artifact to different platforms, including GitHub.
Build should allow for binary macOS and Windows artifacts to be published to GitHub.

Rationale: ODIN C2IS is map centered. Creating and displaying plans, (common operational) pictures and other geo-referenced information is what this application is about.

Applications main window should show an interactive map, backed by some raster tile provider (OSM and such). Map spreads out over complete window area. For now, there is no need for sidebars or similar panels. Principle: We want the map to use as much space as possible.

For now a single window and map is fine (primary display). Later more windows may show other maps with different content (secondary displays).

• Pan/zoom must be supported with keyboard, mouse, trackpad.
• Map center and zoom level must be stored between sessions.
• EPSG 3857 (web/pseudo mercator) for display is OK, later UTM support should follow
• One hard-coded tile provider (URL and other properties is acceptable)

Currently we have two (electron-)settings files

• Settings (default name) for main process
• MapSettings for renderer process

But MapSettings is also used to read menu information in main process. It seems that electron-settings does only support a single instance per process. So, overriding the default file name for MapSettings, also changes the Settings file name in main process.
This leads to file content corruption.

Even if we would use a single instance for both processes, I/O contention will probably occur.

To fix this, a strict separation of both files and processes must be established.

Restoring the last window position upon load might be incorrect. This is a long known and unsolved problem in Electron and has several underlying causes. To make matter even worse, the behavior differs between Windows and macOS (Linux probably too).

Instead of applying a bunch of seemingly unrelated workarounds, I propose to wait for Electron team to fix these issues once and for all.

If users are really unhappy with the current behavior, we have to re-evaluate and add one workaround or the other.

Nominatim support Lat/Long coordinates in search and finds places near by.
It would be nice if search text in UTM and MGRS coordinate formats would implicitly converted to Lat/Long for a search request.

In fullscreen mode for Windows platform, it would be nice to automatically hide the menu bar.

Electron seems to support some options to this regard:
BrowserWindow option autoHideMenuBar and https://electronjs.org/docs/api/browser-window#winsetautohidemenubarhide

Deleting a bookmark should be possible in Spotlight result list by pressing 'Delete' key.

HMR for map component does not work. On code changes a manual page reload in browser is required. Seemingly additional setup is required (hot-loader/react-dom).

Instead of diving into this for hours, react-hot-loader is to be removed from build (for now.)

On first start of application a default tile provider is used to display the map.
In that case, the providers attribution is not display correctly (or is missing).

While common on paper maps, scales and especially rulers are problematic for Web Mercator projection. Distortion increases heavily with the extent of the area covered (latitudinal).

Each circle in the Web Mercator projection above covers roughly the same area.

While the error might be acceptable for smaller areas, it is still wrong.

In #23 it says, that the search results of the location search are sorted by Euclidean distance, but if the the map currently shows Vienna, and you are searching for a street named “Rohrbacherstrasse” the resultlist doesn't show the corresponding nearest street. To find it, you have to search for “Rohrbacherstrasse, Vienna”

Throughout the application, all coordinates should be displayed in a single, consistent format. Also, the current format is used to copy coordinates to systems clipboard.
The user should be able to switch formats.

Supported formats:

• sexagesimal degree: degrees, minutes, and seconds : 40° 26′ 46″ N 79° 58′ 56″ W
• degrees and decimal minutes: 40° 26.767′ N 79° 58.933′ W
• decimal degrees: 40.446° N 79.982° W
• UTM (e.g. 32U 461344 5481745)
• MGRS/UTMREF (e.g. 32UMV 61344 81745)

Map has already a certain gravity and pulls in more and more code.
We have to come up with some architectural concepts to decouple modules and put code at predictable places.

Clicking on a link in attribution control opens a new page, without a way to navigate back.
In an offline environment this poses an additional problem.

To get our feed wet with military symbology, I propose to add a built-in layer which contains points of interest. Later this layer might also hold areas of interest.

This is by no means an easy feat to accomplish. There is quite a lot to take care of:

• Selection tracking/highlighting
• State synchronization between multiple views (map and properties)
• Clipboard support
• Undo/redo support

See also #46.

To mark areas of interest bookmarks should be supported:

• create new named bookmark from current map center and zoom level
• go to named bookmark
• delete named bookmark (needs UI/UX discussion) (separate feature)

Naturally, bookmarks are stored between sessions.

NOTE: Since we have only one map so far, a bookmark is associated with this map. This may change, when multiple map (documents) are supported.

The user should be able to pan the map to a specific coordinate.

Supported coordinate formats:

• Latitude/longitude (WGS84): different formats
• UTM/UTMREF
• MGRS

Discussion: What are use cases for this feature?
Discussion: Should we mark the coordinate on the map, how and for how long?

https://material-ui.com/customization/typography/#responsive-font-sizes

For the time being, MGRS (UTMREF) format will be used.
When coordinate display format can be configured (#11), the corresponding format will be used.

The search field which appears if you search for places or if you are filtering bookmarks, fires events.
Those events pass on the search/filter text.
But if you type in "New", just the two characters "Ne" are passed by. Maybe a different key listener like keyup would work better here.

When started, the window must be clicked to get focused.

url still points to outdated syncpoint repository

Changing the tile provider should also store it in user settings, thus the provider setting can be restored on application start.

Let's say we want to maintain a general list of points-of-interest, which is not necessarily limited to tactical requirements. We want to

• create new POIs with name (id) and position
• rename and move POIs
• delete POIs
• add/change POI comments and tags
• Find/delete POIs in Spotlight

All this requires quite some user interaction. We should collect ideas and thoughts on how to design UX and user interaction for such features, which later can be applied to the more general case of tactical symbols.

Concerning #10 (closed):

If you copy a coordinate from the ODIN map (with "Alt + C") and use it to find the location in Google Maps, the location of the "marker" is not at the same location.

The differences between the locations are a few meters and several kilometers and with repeated attempts (same location in ODIN) sometimes at different locations (in Google Maps).

There is really no need to see the world over and over again for zoom levels smaller than 3.

The user should be able to pick a coordinate directly from the map.
Selected coordinate is copied as text to the system clipboard in the coordinate display format configured in user settings.

Discussion: What are the use cases (i.e. the users goal) for this?

The user should be able to dim map brightness.
NOTE: Only the raster layer is affected, when the brightness is changed.

Discussion: Why would a user want to do this?

100% brightness:

60% brightness:

Home-growing complex UI component interactions with Vanilla Javascript and direct DOM manipulation is cumbersome, error-prone and hard to maintain. This is something I learned from various prototypes.

After internal discussions, we decided to use React to implement UI component, their rendering and state delegation/synchronization with actual DOM elements.

Once a plan (or part thereof) is finished, the terrain assessment is done, features, installations and units are in place, it is not uncommon to entirely turn off the map background to reduce noise and increase readability.

Through POI properties it should be possible to pick a new location directly from the map.

In the settings View → Map → Filter it is possible to change the appearance of the map. This functionality gets achieved by choosing a Filter (e.g. Brightness) and then change its value by pressing an arrow key.

The problem is the fact, that the focus stays at the menubar and if you press an arrow key, you jump between the menu entries. To change the values of the Filters you first have to click in the map to pass the focus to it.

Users might want to directly choose a standard scale (e.g. 1:50.000, 1:25.000).

This poses at least two problems

• Web Mercator distortion (see also #4)
• Leaflet zoom factor does not align to 'even' scales, e.g. closest to 1:50.000 is 1:35000

Compare OSM zoom levels

Can be access through application menu: File/New/Point of interest.
Later POIs can be added by dragging from 'Symbol Palette' (left sidebar).

User is then asked to pick a coordinate. After pick, symbol is placed on map and properties pane with following fields is opened:

• Name: Some sensible default, e.g. POI 1, POI 2, etc.
• Position: current coordinate
• Comment: empty multiline textfield

To project WGS84 lat/long coordinates to UTM/MGRS, the UTM zone (1-60) must be known (besides northern/southern hemisphere).
The projection is by no means unique. Lat/long coordinate at or near the eastern or western border of a zone, can also be projected with the neighboring zone.

Calculating the nearest zone is possible, but probably not what the user usually wants. Normally, the battle space lies within a fixed zone (or two). NOTE: In theory, a zone spans 1000km across with false easting of 500km at the zone meridian.

I see two possibilities:

• User has to supply/choose a fixed zone
• Zone can dynamically be calculated for the map center

Diskussion: Can we support both modes (fixed and dynamic)?

This is probably not what we want:

We have to define, what information should be included in this dialog. Some suggestions:

• Syncpoint name, logo, company link (if possible)
• Application version
• Copyright notice
• 'Hecho en Viena con mucho ❤️' (just kiddin', or ...)