feat(editable-layers): non-geospatial coordinate system

[eKerney]

Related to RFC: Non-geospatial coordinate support for editable-layers #496
Discussion here at: feat(editable-layers): EditModeCoordinateSystem abstraction aligned with deck.gl COORDINATE_SYSTEM #516

Replaced TranslateMode with TranslateModeEx from @xinaesthete thank you!
Added OrthographicView, adjusted background image bounds and INITIAL_VIEW_STATE accordingly.
Added COORDINATE_SYSTEM.CARTESIAN to background and editableLayers.
Changed selected feature color to make more obvious to user.

Note: Running yarn start-local resulted in Failed to resolve import error, resolved by commenting line 22 in vite.config.local.mjs

'@deck.gl': join(rootDir, './node_modules/@deck.gl'),

no-map-editable.mp4

[charlieforward9]

Great proof of concept here - we certainly want to have the updated coordinate system be baked into the core modes - not create new ones per coordinate system - this would multiply our bug surface and make maintenance nearly impossible. Consider how we can update the current mode to work with non geo coordinates. or how we can pass the coordinate system into the core layer , or make a new master layer type EditableLayer that behaves like GeoJSON but isnt 'geo'.

[xinaesthete]

Yes I agree with @charlieforward9 TranslateModeEx was so-named as an experimental temporary hack to get things working (which it does afaik). For something to actually merge upstream #516 with interface EditModeCoordinateSystem seemed like it may be along the right lines?

EditableGeoJsonLayer.getModeProps() now automatically derives coordinateSystem from the layer's own this.props.coordinateSystem (the standard deck.gl layer prop) via fromDeckCoordinateSystem(). Users just set coordinateSystem={COORDINATE_SYSTEM.CARTESIAN} on the layer and edit modes automatically use Euclidean math — no separate configuration needed.

I haven't tried actually running the code from there.

[charlieforward9]

@eKerney you could try putting an agent on it and directing it towards the feedback

[eKerney]

@charlieforward9 made a very small change by swapping TranslateModeEx for the editable-layers/TranslateMode and everything works great! editableLayer coordinateSystem: COORDINATE_SYSTEM.CARTESIAN - from deck Core.

[charlieforward9]

Sweet, simple change!

Id say the real work with this coordinate task is to pull the edit mode widget into the no map example and show all the relevant modes with non-geographic values.

Basically have the editable layer operations be controlled by the active deck coordinate system

• if geo - work as is
• if non geo - handle that maths without turf.js.

Non non geo situation could have editable layers pulling in way less dependencies

[eKerney]

@charlieforward9 - I've updated modify-mode and corresponding functions in utils.ts - helper func projectOrUnprojectPoints() depending on whether EditModeCoordinateSystem is defined as instance of CartesianCoordinateSystem or GeoCoordinateSystem. Added test + all tests passing. If this model works I should be able to walk through all the edit modes without trouble.
Haven't started dynamically loading turf modules, that can be next step.

[charlieforward9]

Good progress here. The projectOrUnprojectPoints abstraction is the right call. Main blocker: nearestPointOnLine now constructs WebMercatorViewport unconditionally which will blow up in cartesian-only usage where theres no viewport. Fix that + the test typo and this is ready to merge into #516.

[charlieforward9]

new WebMercatorViewport(viewport) is now unconditional but viewport can be undefined. Old code guarded this with if (viewport). In cartesian-only usage (no map) this will throw. Need the guard back or make viewport optional and skip projection when its absent.

[eKerney]

This was throwing an error for Geomode editing, most edit modes don't pass a viewport to nearestPointOnLine. Not wanting to change the function signature since this is implemented in many places, I've added a rather inelegant viewportCheck which returns the viewport or a viewport placeholder. No errors testing with no-map & editor examples

[charlieforward9]

Now that wmViewport is optional in projectOrUnprojectPoints (nice fix btw), the placeholder object isn't needed anymore. Should be able to just do:

const wmViewport = viewport ? new WebMercatorViewport(viewport) : undefined;

and let the cartesian early-return in projectOrUnprojectPoints handle the rest.

[eKerney]

@charlieforward9 removed placeholder object, needed to add check for early return with wmViewport === undefined in projectOrUnprojectPoints - throwing an error in edit mode with editor demo.

[eKerney]

@charlieforward9 comments have been addressed in commit 9d2cf6c