Closed daren-thomas closed 4 years ago
can you map zone.shp and terrain.tif in QGIS?
Are there supposed to be any differences between the building geometries of 2.90.0 and 2.31.0? I get the same error with the latest reference-case-open
on my computer. By replacing input geometries with geometries from 2.29.0 reference-case-open
the script runs. Terrain file does not seem to be the cause as both version of files have the same hashes.
Ok... I just tested and confirmed my fear and suspicion.
There might be something wrong with how input-editor
is saving geometry files. (assuming there were no changes with geometry properties between versions, since I did not see any after briefly scanning through them)
My guess was that the properties of the geometries might not have changed but 2.31.0 reference-case-open
geometry files might have been somehow "saved" by input-editor
.
How to reproduce:
1) Replace 2.31.0 reference-case-open
geometry files (i.e. zone and surroundings) with those in 2.29.0
2) Try running solar-radiation
it should pass the Creating 3D building surfaces
portion.
3) Go to input-editor
and change one value of zone
e.g. floors_bg
, save, then change back to original value and save again
4) Try running solar-radiation
and now it should fail showing the error as above.
I have not investigate it yet so I am not sure what is being changed/different from the original files. It might just happen only on my machine but I doubt so. Furthermore, I am also not sure how it will affect results of radiation. (i.e. if the user changes properties of zone using input-editor
and runs radiation but somehow is not affected by this error)
ok.
There seems to be differences in the .prj
files in both zone and surrounding where the project system is "WGS_1984_UTM_Zone_32S"
instead of "WGS_1984_UTM_Zone_32N"
and ["false_northing",10000000]
instead of ["false_northing",0]
2.31.0
PROJCS["WGS_1984_UTM_Zone_32S",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",10000000],UNIT["Meter",1]]
2.29.0
PROJCS["WGS_1984_UTM_Zone_32N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]
similarly,
There are differences between the coordinates of the bounding boxes of each geometry, their y coordinates are different. But the difference in "false_northing"
i.e. 10000000 seems to be equal to the difference between both y coordinates. So I guess they are actually referring to the same location.
2.31.0
[463110.6988839674, 15225351.444618214, 463136.1851344639, 15225376.930633564]
[463235.6402998573, 15225348.954802573, 463261.1265454693, 15225374.440813035]
[463360.5817018389, 15225346.464997474, 463386.06794257654, 15225371.951003049]
[463108.20905922476, 15225226.50435994, 463133.6953090251, 15225251.990374586]
[463233.1504855808, 15225224.014558226, 463258.63673050597, 15225249.500567988]
[463358.09189802676, 15225221.524767004, 463383.5781380866, 15225247.01077189]
[463105.7192484406, 15225101.564091276, 463131.20549753483, 15225127.05010521]
[463230.6606852149, 15225099.074303491, 463256.1469294432, 15225124.560312547]
[463355.6021080773, 15225096.58452614, 463381.08834744943, 15225122.070530333]
2.29.0
[463110.6988839674, 5225351.444618215, 463136.1851344639, 5225376.930633564]
[463235.6402998573, 5225348.954802573, 463261.1265454693, 5225374.440813034]
[463360.5817018389, 5225346.464997475, 463386.06794257654, 5225371.951003049]
[463108.20905922476, 5225226.504359941, 463133.6953090251, 5225251.990374586]
[463233.1504855808, 5225224.014558228, 463258.63673050597, 5225249.5005679885]
[463358.09189802676, 5225221.524767004, 463383.5781380866, 5225247.010771889]
[463105.7192484405, 5225101.564091276, 463131.20549753483, 5225127.05010521]
[463230.6606852149, 5225099.074303491, 463256.1469294432, 5225124.560312545]
[463355.6021080773, 5225096.584526142, 463381.08834744943, 5225122.070530332]
Opening both geometries in QGIS does confirm this and shows them in the same area. So we can confirm that the input-editor
does indeed change the projection system of the geometries, but technically they are still in the same location. (though it would be better if input-editor
could still save files in their original projection system)
Therefore, my suspicion now is that the algorithms to calculate the intersections of terrain and geometry in radiation might not be able to handle different projection systems as it could be reading the y coordinate as it is, so it would most likely be out of range of the bounding box of the terrain. This could be related to #2558
We should definitely investigate this and make sure that the algorithm converts both terrain and geometry coordinates to the same projection system before doing the calculation. This could also help with users being able to import their own terrain files as there is a chance that it could have a different coordinate system from the geometries.
Great invrstigation. I think i know what the problem is. I saved the reference case with the input editor qhen i created the typology file. This updated the Zone file to the latest cea prj ‘which we fixed a few prs ago.
What we need to do is to reimport the terrain file,the street file, and the surroundigns file so CEA change the coordinate systme to the newest one.
After that the solar radiation should work...
Jimeno A. Fonseca Dr. Sc. ETH Zurich
Senior Researcher Singapore ETH-Centre (SEC)https://sec.ethz.ch/
Project Coordinator Multi-Scale Energy Systems (MuSES)https://fcl.ethz.ch/research/high-density-cities/multi-scale-energy-systems.html
Product Owner & Developer City Energy Analyst (CEA)https://cityenergyanalyst.com/
Principal Investigator Cooling Singapore (CS1.5)https://www.coolingsingapore.sg/ Future Resilience Systems (FRS)https://frs.ethz.ch/research/cyber-physical-systems/digital-twin-enabled-system-resilience.html
On 23 Feb 2020, 19:41 +0800, Reynold Mok notifications@github.com, wrote:
ok. There seems to be differences in the .prj files in both zone and surrounding where the project system is "WGS_1984_UTM_Zone_32S" instead of "WGS_1984_UTM_Zone_32N" and ["false_northing",10000000] instead of ["false_northing",0]
2.31.0 PROJCS["WGS_1984_UTM_Zone_32S",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",10000000],UNIT["Meter",1]]
2.29.0 PROJCS["WGS_1984_UTM_Zone_32N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]
similarly, There are differences between the coordinates of the bounding boxes of each geometry, their y coordinates are different. But the difference in "false_northing" i.e. 10000000 seems to be equal to the difference between both y coordinates. So I guess they are actually referring to the same location.
2.31.0 [463110.6988839674, 15225351.444618214, 463136.1851344639, 15225376.930633564] [463235.6402998573, 15225348.954802573, 463261.1265454693, 15225374.440813035] [463360.5817018389, 15225346.464997474, 463386.06794257654, 15225371.951003049] [463108.20905922476, 15225226.50435994, 463133.6953090251, 15225251.990374586] [463233.1504855808, 15225224.014558226, 463258.63673050597, 15225249.500567988] [463358.09189802676, 15225221.524767004, 463383.5781380866, 15225247.01077189] [463105.7192484406, 15225101.564091276, 463131.20549753483, 15225127.05010521] [463230.6606852149, 15225099.074303491, 463256.1469294432, 15225124.560312547] [463355.6021080773, 15225096.58452614, 463381.08834744943, 15225122.070530333]
2.29.0 [463110.6988839674, 5225351.444618215, 463136.1851344639, 5225376.930633564] [463235.6402998573, 5225348.954802573, 463261.1265454693, 5225374.440813034] [463360.5817018389, 5225346.464997475, 463386.06794257654, 5225371.951003049] [463108.20905922476, 5225226.504359941, 463133.6953090251, 5225251.990374586] [463233.1504855808, 5225224.014558228, 463258.63673050597, 5225249.5005679885] [463358.09189802676, 5225221.524767004, 463383.5781380866, 5225247.010771889] [463105.7192484405, 5225101.564091276, 463131.20549753483, 5225127.05010521] [463230.6606852149, 5225099.074303491, 463256.1469294432, 5225124.560312545] [463355.6021080773, 5225096.584526142, 463381.08834744943, 5225122.070530332]
Opening both geometries in QGIS does confirm this and shows them in the same area. So we can confirm that the input-editor does indeed change the projection system of the geometries, but technically they are still in the same location. (though it would be better if input-editor could still save files in their original projection system)
Therefore, my suspicion now is that the algorithms to calculate the intersections of terrain and geometry in radiation might not be able to handle different projection systems as it could be reading the y coordinate as it is, so it would most likely be out of range of the bounding box of the terrain. This could be related to #2558https://github.com/architecture-building-systems/CityEnergyAnalyst/issues/2558
We should definitely investigate this and make sure that the algorithm converts both terrain and geometry coordinates to the same projection system before doing the calculation. This could also help with users being able to import their own terrain files as there is a chance that it could have a different coordinate system from the geometries.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/architecture-building-systems/CityEnergyAnalyst/issues/2594?email_source=notifications&email_token=ACEOXAUXWPASVP757QVW3UTREJOGHA5CNFSM4KZDJLS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMVZS3Y#issuecomment-590059887, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACEOXARFSQBKLVE3PIHQDK3REJOGHANCNFSM4KZDJLSQ.
I think it would be easier to just replace the shapefiles of zone and surroundings in the reference case if their properties have not changed. Then create another issue regarding the calculation of terrain intersection.
I'm trying to run the workflow (to be able to test all the new plots!) and ran into this problem: