Select to view content in your preferred language

Where did ogr2ogr go?

539
5
Jump to solution
3 weeks ago
AlfredBaldenweck
MVP Regular Contributor

Hi all,

I have a script that relies on ogr2ogr, written for 3.1 and works just fine in 3.3

I'm testing 3.5 ahead of our upgrade and the script is failing, telling me that ogr2ogr cannot be imported.

A search in file explorer (over all of Pro's ProgramFiles) shows that it just isn't there.

3.33.5
AlfredBaldenweck_1-1758123029070.png

 

AlfredBaldenweck_0-1758123017177.png

 

 

So uhhh. Where did it go? Was it renamed or something?

2 Solutions

Accepted Solutions
HaydenWelch
MVP Regular Contributor

it was just a sample that shipped with the gdal/osgeo_utils package and seems to have been removed with this PR:

https://github.com/OSGeo/gdal/pull/9633

You can check the commit for that PR and just copy down the original file and add it back to your environment.

 

There's more info in the parent PR here: https://github.com/OSGeo/gdal/pull/9628

 

Seems like they just didn't want to maintain it since the cpp version of the tool was faster and maintaining tests for both implementations was a pain?

 

Update: 

It seems like they replaced ogr2ogr with ogrupdate

https://gdal.org/en/stable/api/python/python_samples.html#python-vector-sample-scripts

 

View solution in original post

AlfredBaldenweck
MVP Regular Contributor

Yeah, ok, can absolutely confirm that ogr2ogr.exe does not exist on my 3.5 machine.

AlfredBaldenweck_0-1758225631413.png

In any case, reading those linked github pages, it seems like gdal.VectorTranslate() is the way to go, which unfortunately means I need to figure out how to make that work instead. Super sucky, but hopefully it will work better than ogr2ogr?

As it is, I ran into the issue of some tables would properly get copied into fGDB and other properly into GPKG, but not everything went to both, so I was doing both and then copying everything into one place. Not efficient at all.

Thanks guys

 

 

 

View solution in original post

5 Replies
JoshuaBixby
MVP Esteemed Contributor

When you say "relies on," are you importing ogr2ogr.py or calling it as a command?  If the latter:

C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Library\bin\ogr2ogr.exe
AlfredBaldenweck
MVP Regular Contributor

Importing it. Miles easier than figuring out how to use OGR to copy each table manually.

from osgeo_utils.samples import ogr2ogr
#Code
ogr2ogr.main(['ogr2ogr', '-f', 'GPKG',#'-resolveDomains',
                          mid_ds, in_ds])

I don't see that exe file in my 3.3 install, and unfortunately my remote machine is logged in to a different 3.3 and running something for the next few hours, so I can't check the 3.5 yet.

0 Kudos
HaydenWelch
MVP Regular Contributor

If you're just using it that way, you can fork the command out using the subprocess module:

import subprocess

ogr2ogr = 'C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Library\bin\ogr2ogr.exe'
subprocess.run([ogr2ogr, '-f', 'GPKG', #'-resolveDomains',
                          mid_ds, in_ds])
AlfredBaldenweck
MVP Regular Contributor

Yeah, ok, can absolutely confirm that ogr2ogr.exe does not exist on my 3.5 machine.

AlfredBaldenweck_0-1758225631413.png

In any case, reading those linked github pages, it seems like gdal.VectorTranslate() is the way to go, which unfortunately means I need to figure out how to make that work instead. Super sucky, but hopefully it will work better than ogr2ogr?

As it is, I ran into the issue of some tables would properly get copied into fGDB and other properly into GPKG, but not everything went to both, so I was doing both and then copying everything into one place. Not efficient at all.

Thanks guys

 

 

 

HaydenWelch
MVP Regular Contributor

it was just a sample that shipped with the gdal/osgeo_utils package and seems to have been removed with this PR:

https://github.com/OSGeo/gdal/pull/9633

You can check the commit for that PR and just copy down the original file and add it back to your environment.

 

There's more info in the parent PR here: https://github.com/OSGeo/gdal/pull/9628

 

Seems like they just didn't want to maintain it since the cpp version of the tool was faster and maintaining tests for both implementations was a pain?

 

Update: 

It seems like they replaced ogr2ogr with ogrupdate

https://gdal.org/en/stable/api/python/python_samples.html#python-vector-sample-scripts