I writing a Python script to read E00 layers and copy each of them to a it's own PostgreSQL/PostGIS table.

I am using the OGR library.

The problem is that it hangs using the method CopyLayer(). I can see the process Python.exe using 30% of the processor, but it just hangs and never complete. There is no error. The dataset is rather small.

Here is the code:

# Ouverture d'une connection à la base de donnée
database_host = ""
database_name = "acadb"
database_user = "database_user"
database_pw = "mysupersecretpassword"
database_schemas = "cadastre_import"

db_conn = psycopg2.connect(dbname=database_name, host=database_host, user=database_user, password=database_pw)

ogr_conn_string = "PG: host=%s dbname=%s user=%s password=%s schemas=%s" %(database_host,database_name,database_user,database_pw,database_schemas)

ogr_conn = ogr.Open(ogr_conn_string)

# Création d'un "curseur"
cur = db_conn.cursor()

for file in os.listdir(extract_folder):
    e00_file = os.path.join(extract_folder, file, file + 'base', file + 'polylot.e00')

    input_ds = ogr.GetDriverByName("AVCE00")
    f = input_ds.Open(e00_file)

    lyr_poly = f.GetLayerByName('PAL')

    ogr_conn.CopyLayer(lyr_poly,'file_test', [])

I can't find the problem... Or maybe I am not doing it the right way?

  • It's more than a little odd to see Arc/Info export format, which was never meant to be used as a heterogeneous transfer standard and died with the termination of Workstation, used to transfer anything into PostgreSQL. There are so many more suitable formats that it's hard to imagine that this would be necessary. – Vince Sep 27 '17 at 3:27
  • Indeed. Unfortunately, this is what I got when I bought a dataset from my government. The problem is not reading it with OGR though. Maybe I could try to convert to another format before copying in Postgres... – Gob Tron Sep 27 '17 at 11:25
  • Ah turns out that OGR is reaaaaaaally sloooooow reading the E00 coverage. I let the script run all night and when I got to work this morning, the import was done. But the geometries are invalid though... – Gob Tron Sep 27 '17 at 13:06
  • Coverage format was a multi-file, list of lists implementation; there's no doubt this would be inefficient as an ASCII dump, but if you have topology errors, it seems more likely an issue with the parser or the source data, not the format otself. – Vince Sep 27 '17 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.