OSM data can be represented in many different ways. If you're interested in a relatively basic, non-geometry representation then you should be using osmosis which can write MySQL with its "apidb" tasks. If you are not so interested in the basic OSM building blocks (nodes, ways, relations) but instead would like to work with geometry objects, then you should look into using ogr2ogr to convert directly from OSM data to MySQL and generate geometries. The canonical program everyone uses the build geometries is osm2pgsql and it works for PostGIS only. A competing implementation in Python (old) or Go (new) is called imposm. A recent newcomer on the database import scene is osmium-tool which can now generate PostGIS "copy" files; I guess it should be relatively easy to modify that to work with MariaDB: https://github.com/osmcode/osmium-tool/commit/3b0fd2363dce06b9d856c8ba0dfdd83880af6044
If you were to attempt to write a full-blown MariaDb importer like osm2pgsql from scratch, you'd be looking at perhaps a person-month of coding work. Don't underestimate it.
answered 22 Dec '18, 00:14
Frederik Ramm ♦
82.5k●92●720●1273
accept rate: 23%
Frederik, isn't that a little over-optimistic "a person-month of coding work" for writing an osm2pgsql like converter from scratch? There is +10 years of development work in osm2pgsql by many contributors. Top contributors Ionvia and Twain47 alone seem to have both submitted around 100k code lines (https://github.com/openstreetmap/osm2pgsql/graphs/contributors), there may be well over 300k code lines in total, if I look at all the contributors... Of course, you can cut some corners by doing away with things like (minutely) updates, tag transform, multipolygon processing, but all in all, I'd say a "one person-year of coding work" seems more realistic for anything close to what osm2pgsql really does...
What about just osm2pgsql backend? This could be much easier:
https://github.com/openstreetmap/osm2pgsql#alternate-backends