You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Geocode.earth has offered to serve geocoding traffic for maps.earth, which should reduce hosting requirements and global latency. I'm happy with their privacy practices from the conversations I've had with them (apparently their privacy policy is being rewritten to be much more strict--might wait to switch maps.earth traffic over til that happens?)
Pelias is also hard to run in kubernetes, and for a production quality geocoding service I think it will always just make sense to offload it onto someone else who knows how to administer an Elasticsearch cluster. The docker-compose file will continue to have first-class support for self-hosted Pelias, but I might drop support for the Pelias k8s configs because they've been a pain to deal with. They'll stay in the repo but I'll probably put them into an unsupported/ subdirectory.
I also want to clarify that this is a feature I'm implementing for maps.earth and AFAIK I'm the only person on the planet who runs headway inside kubernetes so I don't really feel all that bad about making unilateral changes to what's supported as long as they don't affect actual users (who are all currently using docker-compose I believe). If someone wants to help maintain the Pelias k8s configs I'm more than happy to keep support but the bulk of my time really needs to be going towards other areas of the project.
The text was updated successfully, but these errors were encountered:
Geocode.earth has offered to serve geocoding traffic for maps.earth, which should reduce hosting requirements and global latency. I'm happy with their privacy practices from the conversations I've had with them (apparently their privacy policy is being rewritten to be much more strict--might wait to switch maps.earth traffic over til that happens?)
Pelias is also hard to run in kubernetes, and for a production quality geocoding service I think it will always just make sense to offload it onto someone else who knows how to administer an Elasticsearch cluster. The docker-compose file will continue to have first-class support for self-hosted Pelias, but I might drop support for the Pelias k8s configs because they've been a pain to deal with. They'll stay in the repo but I'll probably put them into an
unsupported/
subdirectory.I also want to clarify that this is a feature I'm implementing for maps.earth and AFAIK I'm the only person on the planet who runs headway inside kubernetes so I don't really feel all that bad about making unilateral changes to what's supported as long as they don't affect actual users (who are all currently using docker-compose I believe). If someone wants to help maintain the Pelias k8s configs I'm more than happy to keep support but the bulk of my time really needs to be going towards other areas of the project.
The text was updated successfully, but these errors were encountered: