Editor copy&paste uses wrong projection

[silvester-pari]

When copying the editor output at https://eox-a.github.io/EOxElements/?path=/story/elements-eox-drawtools--import-features-with-editor, clearing the features and pasting again, they get added in a wrong projection.

[santilland]

I think we need to evaluate how we want to handle the editor for geometries. This issue appears because it is possible to specify a wanted output projection, which defaults to 4326 as this is the one required by STAC/GeoJSON.
So, having an editor where you can input any geometry gets complex, as it could potentially have any projection. We either have an additional field for the editor that would allow you to set a projection, or we enforce that the editor only understands 4326.

**edit: some libraries understand a projection definition within the geojson, that might be an option if we have a geojson editor, but it is not standard conform

[silvester-pari]

This is part of the problem, yes, but I think it goes deeper; this used to work previously. Maybe this is a regression that happened with the map refactoring, but only came apparent with the recent "format" property introduced into drawtools.

Currently, the map has hardcoded values for reading and writing features: https://github.com/EOX-A/EOxElements/blob/main/elements/map/src/enums/map.js#L6-L9

export const READ_FEATURES_OPTIONS = {
  dataProjection: "EPSG:4326", // Define the source projection
  featureProjection: "EPSG:3857", // Define the target projection for the map
};

This is interfering with the drawtools using the parseTextToFeature function, the parseFeature function and the addNewFeature function (lots of hardcoded projection in that file btw.). I think two things need to happen:

• all of the here mentioned functions need a way for options to be passed (same options as for readFeatures and writeFeatureObject - and then, in the eox-drawtools to set the dataProjection/featureProjection accordingly when parsing/writing features to match what is defined in the drawtools.
• check other places in eox-map where a projection is hardcoded/assumed and rather get the current view projection instead of assuming EPSG.3857

Once this is fixed, we can think of how to deal with the editor input (as you say it could be in any format), OpenLayers apparently tries to derive the projection from the data (where possible) but we might need to support additional edge-cases.