> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
I have run the PostGIS regression suite with the GEOS 3.9 NG build installed, and analyzed all the discrepencies, and there are very few of them (thanks Regina for fixing up the first route of normalizations). Discussion of each case is at the end of the document linked above. * There were a few more normalizations to add, in the split and tickets tests. * There was one cunit makevalid test that duplicates an existing test in GEOS. It can fairly be removed, IMO. * There was one small discrepency in a subdivide test, which might need to be version guarded, or maybe just altered slightly. The results appeared consistent for practical purposes (identical areas, etc). * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could? I think we are very close to being able to make NG the default overlay engine in GEOS. The task would look like: GEOS * Make NG the default. * Update the small set of GEOS regression tests that need changes to expect NG outputs. PostGIS * Remove duplicated cunit makevalid tset * Normalize test outputs as necessary (already done on branch, to be merged shortly) * Version guard or remove the subdivide regress test in postgis. * Version guard or fix the topology failure case (depends on what Sandro finds is the root cause) * Version guard the tickets test error messages and only test against 3.9 Thoughts? P _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
