tudelft3d / City3D

Large-scale LoD2 Building Reconstruction from Airborne LiDAR Point Clouds
https://github.com/tudelft3d/City3D
GNU General Public License v3.0
223 stars 36 forks source link

GeoJSON footprint requirements #15

Closed wimdes5 closed 1 year ago

wimdes5 commented 1 year ago

When opening .geojson files there's always the message: Warning: I can handle only simple GeoJSON format! And reconstruction keeps failing with: - Warning: encountered non-simple foot print polygons. So it seems City3D skips on footprints deemed non-simple?

Shapes are quite simple, without touching or intersections. When inspecting in QGIS no errors are found. Even a file with only a simple rectangle will throw this warning. What could be the reason, or can a working example .geojson file be provided?

Some test files: https://github.com/tudelft3d/City3D/files/10297499/2huizen.zip

LiangliangNan commented 1 year ago

The warning about geojson format doesn't mean some geometry has been discarded. The warning is always there, just reminding us that the geojson parser is not complete. To be sure one can convert it into an obj file (storing all the polygons with Z=0.0). I looked into your files, it will for sure fail because your point cloud and footprint data do not align. One has very big translations.

wimdes5 commented 1 year ago

I carefully recreated the files, alignment looks perfect both in qgis and in City3D No offset when I check with lasinfo, but still no reconstruction :-( 2huizen2a.zip

yidahuang commented 1 year ago

I looked into your data, there are some issues with your geojson file, there are some repeated points in your footprint data( the starting and ending point of each polygon). So it cannot pass non-simple test. After removing one point, the result is like this, i think it is good.

CleanShot 2023-01-10 at 10 20 28@2x
hugoledoux commented 1 year ago

the specs of geojson require the first and last point to be the same, this is not an error, see https://www.rfc-editor.org/rfc/rfc7946.html#section-3.1.6

yidahuang commented 1 year ago

@hugoledoux, thanks for the correction (: @wimdes5, I have updated the code. It should work for your data now.

wimdes5 commented 1 year ago

Indeed this works, thank you! 1 remaining detail is the height scale (or ground level), how could this be corrected?

wimdes5 commented 1 year ago

After some more testing: most buildings reconstruct fine, but regularly reconstruction hangs on a building. I tried recommendations as described in issues #4 to no avail, experimenting with the weights traingle neither. In this example with some less regular shapes reconstruction hangs on the 2nd building: 14huizen.zip Or this church: kerk.zip All are from the same aerial lidar set

LiangliangNan commented 1 year ago

@wimdes5 What does "reconstruction hangs on a building" mean? I checked your data and found that the point clouds indeed hang above the footprint polygons. But this is not an error because from the footprint data we don't know the exact altitude (i.e., Z value) of the building. In theory, the ground plane should be extracted from the point cloud, but such information is ignored during the reconstruction. You can solve this "hanging building" issue using one of the following solutions: 1) provide the actual Z value of the building in the footprint data (and of course modify the code in the GeoJSON loader to use it); 2) extract the actual ground plane from the point cloud and use it to correct the Z coordinate of the footprint; 3) if none of the above works, the Z value of the ground plane can be approximated by the lowest Z coordinate. This may cause a large error because the lower part of a building can be completely missing. But this is the closest value we can obtain from such data.

wimdes5 commented 1 year ago

Thanks for the advice! The hanging is unrelated to the height question; I meant reconstruction gets stuck on specific buildings (using SCIP solver)

yidahuang commented 1 year ago

I use Gurobi and run your data, the result is like this, screenshot_4 the overall result looks good. I think the main reason you getting stuck is the scip solver, as the scale it can tackle is smaller than gurobi.

wimdes5 commented 1 year ago

I can test with Gurobi now, but processing still hangs on complex buildings like the church. Did you use any specific parameters?

wimdes5 commented 1 year ago

By increasing the 'numbers' parameter I could get the church to reconstruct.

Another (fairly complex) church I've been trying to reconstruct: kerk2.zip While experimenting with parameters sometimes one part improves, but another part deteriorates. (The existing footprint on the front of the church is clipping too much, that's not the issue)

Some more information on the working and interaction of the various parameters would be great!

image

LiangliangNan commented 1 year ago

@wimdes5 Thanks for the feedback.

While experimenting with parameters sometimes one part improves, but another part deteriorates.

This is indeed one limitation of the method. I don't think it can be solved by simply tuning the parameters (It may work for this particular model, but cannot guaranttee for any other examples). One possible extension would be to decompose a model into a few regions according to is complexity (don't have a solution now and it needs further research) and reconstruct each region with a proper set of parameters. This is out of the scope of this (already published) paper, but are are always open to discussions.

wimdes5 commented 1 year ago

OK that's clear. Is any more information on the parameters availabe? And a last question, is the polygon regularisation implemented in the demo executables?

LiangliangNan commented 1 year ago

You can find more details about the effect of the parameters in the following papers:

Regarding polygon regularization,no executable is available in the current implementation, but I think it is quite easy to call this function from the source code (in regularize_polygon.h)