4 ms·

Speaking from experience, trying to deploy a production-grade OSM instance is an enormous amount of work. Several businesses have been built purely around that

by nbadg 6y ago

Speaking from experience, trying to deploy a production-grade OSM instance is an enormous amount of work. Several businesses have been built purely around that (Maptiler and Mapbox, to name two off the top of my head). I agree that, particularly outside the US, OSM may seem theoretically to be a better choice, but I'm more inclined to assume that DDG simply decided the development resources needed for OSM were too great to justify it, and went with the alternative that they think gives them the best shot at both improving user privacy and competing with google.

lucb1e 6y ago
That sounds logical to me. Do you see anything the OSM community could do to make this easier? Or do we just need (more, perhaps) companies like Mapbox and recommend those rather than self hosting?
- nbadg 6y ago
  For my personal application, I needed access to the actual data, and wanted my map render to be in-sync with the data layer. For that, there aren't any companies (that I'm aware of) offering services; that would also be really tough to do, because your database data model/schema for that is always going to be application-dependent. So I think that Mapbox and co fill that particular role fairly well. But, I don't believe they offer route planning (it looks like there are other companies that do, but for DDG, their SLAs would be important), and route planning needs access to the raw data as well. So really I think the biggest impact would be in improved tooling. If I had the time, I'd personally focus on writing a loader replacement (ie, imposm/osm2pgsql "competitor") that: 1. supported arbitrary data transforms into postgres -- basically, can load data into any database schema, do on-load data transforms, enrichment, i18n, etc. 2. was distributable via some distributed message queue (I'd personally choose SQS, but you could do something like celery for less-opinionated solution) 3. was not opinionated about deployment compute environment (ie, neither requiring nor forbidding containerization) Basically, the ability to have a proper, production-grade, not-just-meant-for-slippymaps ETL pipeline on OSM data would be a really big deal. I haven't ever seen an open source solution for that.

by nbadg 6y ago

lucb1e 6y ago

That sounds logical to me. Do you see anything the OSM community could do to make this easier? Or do we just need (more, perhaps) companies like Mapbox and recommend those rather than self hosting?

nbadg 6y ago
For my personal application, I needed access to the actual data, and wanted my map render to be in-sync with the data layer. For that, there aren't any companies (that I'm aware of) offering services; that would also be really tough to do, because your database data model/schema for that is always going to be application-dependent. So I think that Mapbox and co fill that particular role fairly well. But, I don't believe they offer route planning (it looks like there are other companies that do, but for DDG, their SLAs would be important), and route planning needs access to the raw data as well. So really I think the biggest impact would be in improved tooling. If I had the time, I'd personally focus on writing a loader replacement (ie, imposm/osm2pgsql "competitor") that: 1. supported arbitrary data transforms into postgres -- basically, can load data into any database schema, do on-load data transforms, enrichment, i18n, etc. 2. was distributable via some distributed message queue (I'd personally choose SQS, but you could do something like celery for less-opinionated solution) 3. was not opinionated about deployment compute environment (ie, neither requiring nor forbidding containerization) Basically, the ability to have a proper, production-grade, not-just-meant-for-slippymaps ETL pipeline on OSM data would be a really big deal. I haven't ever seen an open source solution for that.