Board index FlightGear Development Scenery

Error ogr-decode

Questions and discussion about enhancing and populating the FlightGear world.

Re: Error ogr-decode

Postby Alant » Tue Sep 25, 2018 9:26 pm

Yes , https://onedrive.live.com/?authkey=%21A ... ion=locate is the latest version that works for me.

Thanks for pointers to the history.

Alan
Alant
 
Posts: 750
Joined: Wed Jun 23, 2010 5:58 am
Location: Portugal
Callsign: Tarnish99
Version: from Git
OS: Windows 10

Re: Error ogr-decode

Postby xDraconian » Wed Sep 26, 2018 4:43 am

Hi Jonathan,

legoboyvdlp wrote in Tue Sep 25, 2018 3:46 pm:Error reading Index file work/Default/w010n50/w010n52/chop.idx abort

Can you confirm that your chop.idx file is 4 bytes in length?
Also confirm that the value contained within the chop.idx file matches the highest extension number used within that folder.
e.g. Given files of pattern 999999.# - where the highest .# is 7 (e.g. 323981.7), then the chop file should contain the byte values: 07 00 00 00

legoboyvdlp wrote in Tue Sep 25, 2018 3:46 pm:also get the error on all roads, rail, stream, lake, and about half of corine landcover data

You are saving a bunch of different files to the same output folder. 13 items all targeting work/Road. In theory, this is suppose to be okay, but I think you may be trusting the multithreading a bit too much.
Code: Select all
ogr-decode --line-width 12 --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_motorway
ogr-decode --line-width 10 --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_motorway_link
ogr-decode --line-width 12 --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_trunk
ogr-decode --line-width 10 --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_trunk_link
ogr-decode --line-width 10 --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_primary
ogr-decode --line-width 8  --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_primary_link
ogr-decode --line-width 10 --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_secondary
ogr-decode --line-width 8  --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_secondary_link
ogr-decode --line-width 8  --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_tertiary
ogr-decode --line-width 7  --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_tertiary_link
ogr-decode --line-width 6  --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_residential
ogr-decode --line-width 7  --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_unclassified
ogr-decode --line-width 6  --continue-on-errors --all-threads --area-type Road        work/Road        data/osm_other

try running it without --all-threads and see if you get different results.

legoboyvdlp wrote in Tue Sep 25, 2018 3:46 pm:viewtopic.php?t=22464&p=211792#p218439

Unlikely that the argument is valid related to fread(...) != 1 being the problem. That is very standard functionality.
But... Things can get non-standard as soon as you add multithreading to the mix.
Firstly, fread can do its own mutex. Secondly, tgChopper adds a mutex. I cannot say whether the tgChopper mutex is correct (haven't studied it to make a conclusion).

I suspect either of these two actions would solve the problem you are seeing:
Don't use --all-threads - In fact, don't use anything other than 1 thread.
or, Eliminate saving multiple elements to the same folder (e.g. like work/Road). Doing so is allowing multiple threads to work within the same output folder and I'm speculating they are stepping on each other.

Hope that helps.
Scott
xDraconian
 
Posts: 86
Joined: Sun Jan 21, 2018 5:53 am
Version: Git
OS: Linux Mint

Re: Error ogr-decode

Postby legoboyvdlp » Wed Sep 26, 2018 10:48 am

Without --all-threads I get the same result.

there was one chop.idx file 5KB of length: its contents in hex were 1A 00 00 00, or in decimal, 26 00 00 00. As there were 26 of the other files I think this is ok.


as for this,

Eliminate saving multiple elements to the same folder (e.g. like work/Road). Doing so is allowing multiple threads to work within the same output folder and I'm speculating they are stepping on each other.


What should I do? Save them to different folders and map then in default priorities to road?


For now, I'm using the patched version by BecOzlacan for ogr-decode only. It returns things like
Code: Select all
fwrite index file work/Default/w010n50/w006n55/chop.idx, END NORMAL
User avatar
legoboyvdlp
 
Posts: 5826
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Error ogr-decode

Postby xDraconian » Wed Sep 26, 2018 7:48 pm

legoboyvdlp wrote in Wed Sep 26, 2018 10:48 am:there was one chop.idx file 5KB of length

Are you sure it is 5KB? 5KB would indicate a pretty significant error. I would delete the files in that folder and try again.
IDX files are usually 4 bytes (for 32-bit builds), or 8 bytes (for 64-bit builds), but I've never seen a 5KB IDX file. Something unexpected seems to be going wrong.
xDraconian
 
Posts: 86
Joined: Sun Jan 21, 2018 5:53 am
Version: Git
OS: Linux Mint

Re: Error ogr-decode

Postby legoboyvdlp » Wed Sep 26, 2018 11:04 pm

Windows called it that. The file when inspected in binary viewer seemed normal?
User avatar
legoboyvdlp
 
Posts: 5826
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Error ogr-decode

Postby legoboyvdlp » Thu Oct 04, 2018 5:39 pm

I'll be attempt to debug this - I'll start by seeing if wlbraggs patch still works. I take it that this is the same bug.
User avatar
legoboyvdlp
 
Posts: 5826
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Previous

Return to Scenery

Who is online

Users browsing this forum: No registered users and 3 guests