Natalia Gutierrez
What is your baseline for saying "This tool is taking a very long time even to load very small testing areas" (it shouldn't!), what do you compare it to, and do you have concrete figures for this (x MB *.osm file imports in y minutes)?
Yes, there are considerably faster tools, like the command line tools reliant on PostGIS like osm2pgsql and imposm 3, but those are not "ArcGIS friendly", and require quite a bit of IT proficiency and familiarity with Linux to be able to work with them.
By the way, you haven't forgot to set the Parallel Processing Factor geoprocessing environment setting when running the tool? Only when you set it, will the tool be able to use multiple cores.
Also, be aware that I consider slow HDD based network drives utterly dead for use with OpenStreetMap. To import OSM data, you need fast random access to data on drive. This requires SSD storage. If you have slow network drives, and only an HDD on your local computer, I strongly recommend to get a fast USB 3.x SSD based external drive, and use that to import the data. After import, you can copy the File Geodatabase to your slow network drive for usage.
Why do you need fast random access?
OpenStreetMap data has its own geometry datamodel, that resembles classic CAD files (or if you have been around long enough, ESRI's ArcInfo "coverage" format), where an explicit Polygon data type does not exist. You may be astounded to hear this, but OSM at its basis only knows about nodes (points / vertex) and ways (lines that may or may not form a closed loop). Polygons are only secondarily defined by 1) either ways forming a closed loop and having been tagged with a tag that is generally recognized to be a polygon (e.g. building=x, a closed way with the tag building=house will be imported as Polygon by every tool I know of), 2) closed ways additionally tagged with an explicit area=yes, and 3) if the way is part of a multipolygon relation, otherwise the way is recognized and imported as Line geometry.
There a Pro and Cons to this datamodel:
- Pro is that it is a very flexible and efficient data format: the nodes / vertexes of any shared line between polygons are only stored once, and the two ways bordering each other, simply reference them. This makes for a very efficient storage.
- Con is that any way / Line, or way / Polygon needs to be reconstructed from its referenced nodes and ways.
It is this latter Con that is causing the need for fast random access to data. For any way or multipolygon relation, the import tools need to look up the corresponding nodes and ways that make it up. Only then, is the tool able to create a Simple Features compliant geometry (Line / Polygon), that can be stored in a File Geodatabase feature class, shapefile or PostGIS database spatial column.