geoprocessing fails for the OSM File Loader (Load Only) tool.

[amalask]

@ThomasEmge

I don't know if this again some computer specific issue, but after installing ArcGIS for Desktop 10.6 + 64 bit background geoprocessing, and subsequently the install of the OSM Editor for 64 bit, background geoprocessing fails for the OSM File Loader (Load Only) tool.

I see the process starting up, but almost immediately finishing with the green mark of "success", but nothing is actually loaded into the target geodatabase.

If I disable background geoprocessing, the tool works as expected, and does create the Feature Classes with all the data. It just fails with background geoprocessing.

I fully uninstalled and reinstalled the 64 bit background geoprocessing component, and the OSM Editor as well, making sure I reinstalled the OSM Editor after installing the 64 bit background geoprocessing component, however all to no avail.

I did notice one other small anomaly, that the HTML Help page being opened after the OSM Editor install, still listed ArcGIS 10.5 instead of 10.6. However, I guess this is just an oversight to update the HTML page for the new 10.6 install...

[ThomasEmge]

@amalask The content in the HTML page is an oversight and I'll put in a request with the install team.

If possible, could you please post the geoprocessing messages from the 'successful' run. I just tried with the official installer and so far it looks ok on our office machines.

[mboeringa]

@ThomasEmge ,

@amalask literally copy&pasted my entire message from this other thread (#187) I started, only changing title.

Apparently, @amalask has the same issue...

Anyway, as to the "successfull" run, there isn't one for 64 bit background geoprocessing, the successfull run was with foreground geoprocessing. The failure is with 64 bit background geoprocessing enabled. As I wrote, I correctly installed the 64 bit background processing, and the 64 bit Editor for background processing. Uninstalling and re-installing did not help.

I have now also verified that some other NON-OSM EDITOR (!) tools do run successfully with 64 bit background geoprocessing on my machine, so it does seem an issue isolated to the OSM File Loader (Load Only) tool. The Load OSM File tool by the way, shows the same behavior, and also fails, so it may affect all the tools of the Editor.

Just to exclude some stuff, I even installed the ArcGIS (Desktop, Engine) Background Geoprocessing 64-bit Arcpy Exit and Shutdown Patch (https://support.esri.com/en/Products/Desktop/arcgis-desktop/arcmap/10-6#downloads?id=7579), that is actually supposed to be a Windows 7 fix only (I run Win10) for another issue related to arcpy, but since it involved the background processing, and was made available after the 10.6 release, I thought I might give it a try. It did not make a difference though, the background geoprocessing still failed.

The one thing I did not yet try is to uninstall the 64 bit background geoprocessing and 64 Editor, and than reinstall the 32 bit Editor and enable ordinary 32 bit background geoprocessing. I may give that a try next.

Marco

[ThomasEmge]

@mboeringa Hmm, I am loading Austria right now and it is still going strong. After reading the issue this morning I uninstalled the editor, cleaned out the configurations files, and did a reinstall with the official release. Could you please send me a copy of the messages for the 64bit geoprocessing run.

[mboeringa]

@ThomasEmge ,

Unfortunately, a totally uninformative message in the geoprocessing history for the background geoprocessing run, as you can see...

It fails immediately, however, doesn't report an error at all! In fact, it shows "Succeeded" when the background processing popup reports the end after less than a second, even though inspecting the target File Geodatabase shows nothing has happened...

[mboeringa]

@ThomasEmge

Hmm... could I have a failed install? I both uninstalled and re-installed twice, but I now notice the DLLs listed as 1-9-2017? Is that right, Thomas? Shouldn't those list 2018?

[ThomasEmge]

I don't think so, I have the same dates. I also tried to load with German OS settings and it is still working for me.

[mboeringa]

@ThomasEmge.

I have now uninstalled both the 64 bit version of the Editor and 64 bit background processing. If I subsequently re-install the 32 bit version of the Editor, and start an import using the OSM File Loader (Load Only) tool and background processing enabled, it works! The tool properly runs and loads the data without a hitch.

So only the 64 bit version is failing. Again note that I was able to use 64 bit background processing with other non-Editor system tools of ArcGIS. So only the Editor based tools seems to fail in the 64 bit environment on my machine.

[ThomasEmge]

@mboeringa When you have the 64bit geoprocessing background option installed, then you install the OSM Editor 64bit version. The installer itself puts down the 32bit and 64bit components. This approach we have checked with clean machine installation environments. We are still testing install variations.

[mboeringa]

When you have the 64bit geoprocessing background option installed, then you install the OSM Editor 64bit version.

@ThomasEmge .

I know, this is exactly what I did. I have definitely made sure to install the right version under the right circumstances (64 bit background geoprocessing installed or not).

I just wanted to notify you of the fact that the 32 bit environment including the 32 bit background processing works on my machine. It is just the combination of 64 bit background geoprocessing and the 64 editor that fails on my machine.

[ThomasEmge]

If this is still an issue, please reopen.

[arfisk]

I just encountered the same problem: trying to load an OSM file using ARC Editor seems to do nothing. I ended up trying the same approach as above, and reverting to the 32 bit version. I did encounter an additional clue: I tried disabling background processing, but Arcmap warned me that a background process needed to complete first. It may be that the script is working, but that it's chugging away in the background on a large file with little outward sign of activity (eg the ticker tape message). That would explain why the apparent workaround is to disable background processing. Running the 32 bit version of the load script, I found the only indication of activity was the message updates in the results window (which may not have been checked until an error gets flagged). If this is the case, then the issue becomes one of improved visibility of activity. I haven't tried the 64 bit version again.