Support for custom geojson via region map

Is your feature request related to a problem? Please describe.

https://github.com/opensearch-project/geospatial/issues/122 Currently, Opensearch provides a standard set of GeoJSONs to its customers. This task extends the scope by letting users to configure custom GeoJSONs for adding specific vector layers for visualization.

Describe the solution you’d like

Extend the region map plugin to include:

• a new tab to allow users to import a custom map that integrates with the backend geospatial plugin
• ability to select the custom maps uploaded and make use of them via Layer Options tab for visualization

This can be achieved by completing the following tasks:

• Allow users to upload custom vector map
• Allow users to select index as custom vector map for visualization

Describe alternatives you’ve considered

Since this feature was to be bundled as part of core OSD as an extension of region map, there was no other alternative considered for the time being.

Additional context

• Region map will communicate to the APIs of the backend plugin: https://github.com/opensearch-project/geospatial
• New tab allowing users to upload custom maps will look similar to the image attached below:

[vamshin]

@ahopp I think we are mixing multiple philosophies here 😃. I will try my best to narrow down the scope of this feature and lets take another stab to see if this fits to be a dedicated plugin on its own. To keep it simple, lets remove revamp of Maps out of equation.

What are we adding now?

We are developing a feature that extends existing feature which has been part of the dashboards plugin since the inception of Maps. Precisely we are adding a new tab to let the users upload custom vector maps to the already existing vector maps Given the above scope lets precisely think if this warrants to be a dedicated plugin or provides motivation for creating dedicated plugin.

Can you highlight some examples of community being blocked by this code being implemented in the Maps?

https://forum.opensearch.org/t/how-to-add-layers-to-a-map-in-opensearch-dashboard-1-2-0/8654 https://forum.opensearch.org/t/status-of-kibana-maps/5106/14 https://forum.opensearch.org/t/create-maps-on-opendistro/7188 Now that we have some view into the community interests. Lets think backward from community needs and see if this particular feature warrants to be a dedicated plugin and there by making community wait for 3.0 launch scheduled on Jan 2023(timeline to revamp maps part of ability to add multiple layers).

Finally, you say that the long-term plan is to revamp Maps, but I haven’t seen this as part of an RFC - can you share this as well?

Thanks for your interest in Maps. We are working on RFC and planning to publish soon. Let me try to explain the idea here. If you have some experience looking at Maps dashboard you would see there are two kinds of maps (I)Regional Maps and (2)Coordinate Maps. Our plan is to merge both of them to single Maps layout and have ability for customers to add layers. As mentioned this is a major refactor and thats where we plan to move it as a dedicated maps plugin.

[tmarkley]

Also >90% of our downloads are docker images which bundle all the plugins together where issue wont even exist. Considering this is blocking community and considering the magnitude of change(new tab and a file upload box), we would like to push bootstrapping effort to subsequent releases.

Does this number truly capture all customers/users?

This new feature is so integrated that we need to pull whole of regional maps and coordinate maps to the new plugin which is a huge effort and most importantly opening doors for potentially causes breaking issues. Since we anyways have plans to revamp Maps(combine regional and coordinate maps into layers), our proposal is to have a new dashboard-maps plugin then and move the code.

It’s a bit unclear what the rush is to merge this in then if there is a better solution planned?

Also Maps team would be taking ownership on any issues related to this feature.

It’s still in our repository so we are by default taking co-ownership of this feature. We want what’s best for the community but we need to take maintainability into consideration.