Greetings all,
I noticed that Kibana uses maps from Elastic Co by calling https://tiles.maps.elastic.co/…
Is this going to continue after building the new fork or another maps service is going to be provided?
Thanks,
Hasan
1 Like
Hi asfoorial, Kibana Maps are not opensource. They are of X-Pack so they are out of Opensource version.
We need to reimplement them in OSS fork.
Regards,
Alberto
The Kibana that ships with the current Opendistro For Elasticsearch has Maps Visual Component feature which calls
https://tiles.maps.elastic.co/
As far as I understood the Kibana that comes with Opendistro is open source.
Welcome aparo!
Kibana Maps is indeed x-pack and not in Open Distro. I think @asfoorial is referring to something like Visualize > Coordinate Map which is OSS. The naming is super confusing.
Yep. You’re right - it does refer to tiles.map.elastic.co which the community has no control over. Not great.
From what I understand it can be configured in Kibana. On Amazon Elasticsearch Service, it uses an Amazon-provided tile maps instead of tiles.map.elastic.co.
How this should be handled in the Kibana fork is not a closed question. Thoughts?
@searchymcsearchface @aparo
One option is to use OpenStreetMap. However, their license is not apache 2.0 though!
There are a number of services out there, as long as they are WMS-compliant. However it would be better to have something that is maintained as part of the fork effort. The reason that Elastic has its own map service is that the one that they used to point to had overnight changed its license and required registration. Literally 100s of 1000s of users had their map dashboards break instantly. To avoid this in the future they created and operated the Elastic Map Service.
Here are a few examples of alternatives to the Elastic Map Service that can be used today…
1 Like
Have you looked at OpenMapTiles? No experience with Open Distro and OpenMapTiles but the license isn’t Apache 2 but BSD and CC-BY.
Thanks for the context. It’s tricky as an external ‘default’ service becomes a single point of failure (as evident by the history you described). On the other hand, starting without a default service it is a bad user experience.
Any thoughts on how to crack this nut?
Guess for the longterm we need something like CC-BY licensed “AWS Maps”
Is there any way that AWS could make the service used by AWS ES Service available to serve as the default for the fork?
What do you mean by that? Are you suggesting including the map tiles & server w/ the fork of Kibana?
Well, there is Amazon Location Services, but that’s a proper AWS service which requires accounts, etc. Not right for an out-of-the-box experience.
Would providing your own GEOJson maps work? It also seems to be an x-pack feature, and it would be a great option to be able to just upload a custom GEOJson directly to Kibana. For example, I am trying to develop a homegrown COVID tracker for myself, using data from the regional government and a GeoJSON map of the region. Supplying this info to Kibana and generating a map visualization just off the GeoJSON would be a good option for me. (I do understand that the GeoJSON can’t be too big, but for small regions, I don’t think it should be a problem)
PS.: If providing a default external maps provider is not a viable option, a built-in simplified “referece” map as a base layer or for testing/debugging purposes would be very nice (if it is not available right now).
Bring your own (BYO) GEOJSON is interesting but only covers some of the problem from what I can see.
I think there are a few problems here: map tiles and vector maps then user experience and what KibanaFork expects. BYO GeoJSON would cover the vector map but there are still map tiles to deal with.
For some folks (like you) providing your own GeoJSON might be easy. However, for a lot of users they just want a quick and dirty plot of data without thinking about it (the “user experience problem”).
The bigger problem is probably what KibanaFork expects. As it stands KibanaFork, is built for an external service to provide these assets. As at @robcowart pointed out, there are lots of services that can be used.
I do love your idea though - it would be interesting to know what effort it would take to implement.
(Welcome, by the way!)
There are free tiles server based on OpenStreetmap that can be used in dockerized environment: I used many of them in on-premise solution due to high demanding API calls that will costs huge amount of money in cloud solutions.
I suppose the a tile server similar to openstreetmap-tile-server should do the job. Just point in Kibana your own tile server. The tile server is from the same organization of the geo widget leaftlet used to show data in Elasticsearch (https://switch2osm.org/using-tiles/getting-started-with-leaflet/ ).
Interesting solution - looks like the openstreetmap-tile-server. It would probably a very good option for a some folks. One thing that bums me out about that particular repo is that that looks like it’s mixed license (Comes with a CC0 license in indexes.sql - CC0 is not recommended by the OSI).
Elastic has now blocked our usage of the “open source” elastic capabilities for mapping. Expect the company to continue to do more of this type of practice in the future. People need to move off these distributions ASAP. They are also collecting beacons and data from OSS users, which is immoral IMO. We are seeking an alternative for mapping.
Wow - so your service is blocked from getting map tiles?
As of yesterday or today that is correct.
1 Like