Hot answers tagged 64bit
There is an option in the ArcGIS 10.2 Desktop Install for 64bit background Geo-Processing.
No. Once you've started executing your script at prompt, you're in either the 32 or 64 bit space. [yes you could do some sort of multiprocess or os.system call out to 32 or 64bit, but thats at your own risk and I've heard nothing but problems when people do this.] See this blog article about specifying what "bits" to run against. In short, you'll need to ...
It will work on a 64 Bit Machine, yes, but only from the 32 bit Python interpreter. It is documented: The ExportReport function has a dependency on the ArcMap installation. Therefore, ExportReport can only be executed on machines that have ArcMap installed. ExportReport will not run using stand-alone installations of ArcGIS Engine or ArcGIS for Server. ...
You'll need to get a 64 bit ArcGIS installation of some sort to get arcpy to work correctly in a 64 bit installation. The most expedient thing would be to install 64 bit background geoprocessing for your current install of ArcGIS. That will install a 64 bit version of all the necessary Python libraries needed to use arcpy.
If you launch the autorun.exe application, it will launch the startup window (otherwise known as the Quick Start Guide) of the 10.2 installation for Desktop. The option you're looking for is the 2nd one down from the ArcGIS for Desktop header:
64-bit Background Geoprocessing with ArcGIS 64-bit Background Geoprocessing installs a 64-bit version of Python 2.7.2, NumPy and Matplotlib if they are not already installed. By default they will be installed to C:\Python27\ArcGISx6410.1 (note the x64 in the path), an additional install from the 32-bit Python (C:\Python27\ArcGIS10.1) that Desktop ...
Yes SourcePole have created a 64 bit build. There should be an official 64bit build at some stage, there is funding and work happening, but no ETA at the moment. To build a 64 bit version of QGIS you must also build all the dependencies as 64 bit. These include libspatialindex, gdal/ogr, etc.
I also create ArcPy geoprocessing tools using PyDev for Eclipse. Generally, I run my scripts as in-process geoprocessing tools in a custom toolbox (.tbx) from within ArcMap so that the import arcpy happens instantly. If I run a script from outside of ArcMap, the import arcpy step usually takes about 5 seconds on a Sandy Bridge Core i5. I think your trouble ...
You cannot run a 64 bit executable within a 32 bit process space. That is, the Python window in ArcMap can only ever run in 32 bits, but Geoprocessing tools called from that window can run in a 64 bit background process if background processing is turned on. Your script tools can determine what environment they are running in by checking sys.executable
You actually have to install both 32bit and 64bit Oracle clients to get everything working properly. The article you show in your screenshot is referencing ArcGIS desktop (not the background processing), which is still a 32bit program. You will have to have the 32bit client to connect with ArcGIS Desktop and other 32bit programs. You'll also need the 64bit ...
This all depends on what python version your are running: If you install on a 64 bit Operating System you will get the option. Since ArcGIS for Server 10.1 was released, the ArcPy library has been accessible through a 64-bit platform. In addition, the 64-bit Background Geoprocessing patch was released at 10.1 Service Pack 1, which allows ArcGIS ...
See here. ArcMap (ArcMap.exe) is still a 32bit application and as such is limited to 4GB. The 64 bit background processing addon allows some geoprocessing tools (RuntimeLocalServer.exe) to run in 64bit.
In response to the answer which suggests to turn off background geoprocessing, I will just mention that if you do this you will negate the very purpose of the 64-Bit Geoprocessing installation. In order to take advantage of the 64-bit capability that this installation offers, you MUST have background geoprocessing turned on. Here are a few quotes (with ...
You are right that orfeo toolbox is not yet available in the 64 bit Version of OSGeo4w installer. You can compare the package listings here: http://download.osgeo.org/osgeo4w/x86/versions.html http://download.osgeo.org/osgeo4w/x86_64/versions.html The 64-bit version is still experimental, with packages missing or not working as expected. However, it is ...
You can install both the fme 64 and 32 bit. ESRI doesn't have a 64 bit application. You will extend the fme32 with arcgis. No the 64 bit background processing won't use fme. I have both installed and use each with extended software.
I had been putting off sorting this problem out for a long time but finally have a proper solution. The situation is this: I need a 64bit version of Python 32 and GDAL for a package other than QGIS. I need a 32bit version of GDAL to work with Python 2.7 for QGIS. QGIS consistently loads the wrong DLL and complains that it is not a 32bit Windows ...
QGIS/OSGeo4W is shipped with its own copy of python, that as you noticed is the old 2.5. You don't need to install any other copy of python to have the gdal tools work in your QGIS copy. [There is a ticket in the osgeo4w bug tracker asking to update python.] Nevertheless there should not be any conflict between python installed with osgeo4w and any other ...
Paul, The solution is to rename the following DLL from: C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll to: C:\OSGeo4W\apps\Python27\DLLs\xxsqlite3.dll There are two versions of this dll that ship with the OSGeo4W installer which I bet is what you are using. This change doesn't affect Python. When it doesn't see the dll because of the name change it ...
A 64 bit build is now available, and the QGIS team are hoping people will start using/testing. http://faunaliagis.wordpress.com/2013/08/26/qgis-64bit-for-windows-is-ready-to-test/
There is a Google Summer of Code 2013 project on OSGeo4W ongoing which may cover that, see: http://trac.osgeo.org/osgeo4w/wiki/Reports "Short description: Main goal for this project is develop functionalities in order to ask to the end users by an EULA license for proprietary libraries and building the majority of OSGeo components to x86-64 bits on Windows ...
Shapefiles still store numbers using 64 bits of precision, 16-16 digits. It looks like you need 11 or 12, so you should not get errors unless you are doing computations in which case floating point errors are a remote possiblility. If anything is ever converted into a 32-bit floating point number you would definitely lose precision.
You can also try this as well: import sys print sys.version for 32-bit python, you'll get something like this: 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] for 64-bit python, it will look something like this: 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]
Sorry, not an answer, but I want to confirm I am seeing the exact same connection lost issue, in the same pbf file and have been unable to load it for 2 weeks now. It fails after about 20 hours with this error. I will edit this if I find a cause or a solution. Right now I suspect that the pbf file is bad or its a bug. Tests that worked so far: Tested a ...
Only top voted, non community-wiki answers of a minimum length are eligible