On Windows multipolygon tests don't compare output with reference. about libosmium

[alex85k]

Here is an update for Ruby script that compares WKT without calling .sh
(it invokes Spatialite before, comparing takes ~2 minutes)
alex85k/osm-testdata@bb6a743
Previous version also did not do "exit 1" if one of the tests fail.
Please do not forget to check the code and test on Linux/BSD, I am Ruby-newbie :)

To fix running tests on Windows the following patch is needed:
alex85k@fa1d18e

Good news: all the tests for libosmium passed!

[joto]

Great work @alex85k! I took me a while to compare the ruby code to the shell code and test it to make sure it does the same thing. I have added everything (and made a few changes). Once you have verified my changes, we can close this issue.
Unfortunately the compare-areas.rb is now even slower than before (why I don't understand) and the code is still horrible, not your fault, it was horrible before. Much too complex for my comfort. Someday somebody has to refactor this.

[alex85k]

Yes, it is really huge :) I tried to get rid of spatialite by using https://github.com/rgeo/rgeo but it did not fully work with my geos installation.
Thank you for fixes!

One little problem remains:

34: C:/winbuilds/osm-testdata/bin/compare-areas.rb:91:in `delete': No such file or directory - compare-wkt-tmp.db (Errno::ENOENT)
34:     from C:/winbuilds/osm-testdata/bin/compare-areas.rb:91:in `spatial_sql'
34:     from C:/winbuilds/osm-testdata/bin/compare-areas.rb:111:in `compare_wkt'
34:     from C:/winbuilds/osm-testdata/bin/compare-areas.rb:135:in `compare_geom'
34:     from C:/winbuilds/osm-testdata/bin/compare-areas.rb:142:in `compare_area'
34:     from C:/winbuilds/osm-testdata/bin/compare-areas.rb:158:in `block (2 levels) in check_variant

Removing File.delete line does not help - there are "Process can not access occupied file" errors.

[joto]

There is a reason I am using the external spatialite binary: I had problems that with some invalid geometries I had crashes, so the test framework would just die. Putting those critical task in an extra program is an insurance against those problems.

Not sure how the database can not be there. You can try putting the begin/rescue around it like a few lines above.

[alex85k]

After experiments I have some working variant. The problems was caused by reusing compare-areas.log in two subshell (concurrent file access caused problems).

So the proposed fix is here: alex85k/osm-testdata@7bde7be

[joto]

I don't like this because then you can't see which output in the 'err' file belongs to which output in the 'log' file. Output to the same file in append mode should be fine. If Windows can't do this, then we'll have to read the file generated by spatialite back in Ruby and add the contents to the log file.

[alex85k]

Second variant will work. The first is certainly impossible on Windows.

[alex85k]

I have the script with error-file-copying-into-logfile:
alex85k/osm-testdata@e2e05cb
To pass test I had to increase timeout to 300 sec - it took 258s on my Core i7 notebook (Debug version of spatialite).

Could you check?

[joto]

I have used your patch. Thanks. Looks like this is resolved now.

[alex85k]

Thank you, all is working!
But the 60 ms timeout for testdata-multipolygon date is too low for debug version (takes 250 on debug+static spatialite...) :)

[joto]

I am not setting any timeouts. Where does it come from?

[alex85k]

From the cmake scripts, this one is failing :)

[joto]

Ah, I keep forgetting about those cmake scripts. Fixed now.

[alex85k]

Thank you, now the tests will pass without problems.