ValueError: Cannot transform naive geometries when creating scenario

[nasty-bos]

Describe the bug After creating a scenario with zone.shp containing more than 1000 buildings using Dashboard, it is not possible to re-open the scenario in the Dashboard.

To Reproduce Steps to reproduce the behavior:

1. Using CEA Dashboard, go to "create new project" and "create new scenario".
2. Select a large area on the map containing many buildings (more than 1000) and click "create".
3. After scenario is created, go to "project overview" and try to re-open this scenario.
4. See error.

Expected behaviour It is possible to open a scenario regardless of large amount of buildings.

Error

C:\Users\abosova\Desktop\CEA-case-studies\altstetten-test\status-quo-4\inputs\networks\streets.shp: No such file or directory
[Errno 2] No such file or directory: 'C:\\Users\\abosova\\Desktop\\CEA-case-studies\\altstetten-test\\status-quo-3\\inputs\\building-properties\\architecture.dbf'
[Errno 2] No such file or directory: 'C:\\Users\\abosova\\Desktop\\CEA-case-studies\\altstetten-test\\status-quo-3\\inputs\\building-properties\\internal_loads.dbf'

[Errno 2] No such file or directory: 'C:\\Users\\abosova\\Desktop\\CEA-case-studies\\altstetten-test\\status-quo-3\\inputs\\building-properties\\indoor_comfort.dbf'

[Errno 2] No such file or directory: 'C:\\Users\\abosova\\Desktop\\CEA-case-studies\\altstetten-test\\status-quo-3\\inputs\\building-properties\\air_conditioning.dbf'
[Errno 2] No such file or directory: 'C:\\Users\\abosova\\Desktop\\CEA-case-studies\\altstetten-test\\status-quo-3\\inputs\\building-properties\\supply_systems.dbf'

[Errno 2] No such file or directory: 'C:\\Users\\abosova\\Desktop\\CEA-case-studies\\altstetten-test\\status-quo-3\\inputs\\building-properties\\supply_systems.dbf'

[Errno 2] No such file or directory: 'C:\\Users\\abosova\\Desktop\\CEA-case-studies\\altstetten-test\\status-quo-3\\inputs\\building-properties\\supply_systems.dbf'

[2020-12-18 16:52:32,265] ERROR in app: Exception on /api/inputs/all-inputs [GET]
Traceback (most recent call last):
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask\app.py", line 2447, in wsgi_app
    response = self.full_dispatch_request()
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask\app.py", line 1952, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask_restplus\api.py", line 584, in error_router
    return original_handler(e)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask_restplus\api.py", line 584, in error_router
    return original_handler(e)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask\app.py", line 1821, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask\_compat.py", line 39, in reraise
    raise value
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask\app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask\app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask_restplus\api.py", line 325, in wrapper
    resp = resource(*args, **kwargs)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask\views.py", line 89, in view
    return self.dispatch_request(*args, **kwargs)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\flask_restplus\resource.py", line 44, in dispatch_request
    resp = meth(*args, **kwargs)
  File "c:\users\abosova\documents\cityenergyanalyst\cityenergyanalyst\cea\interfaces\dashboard\api\inputs.py", line 136, in get
    config, 'dh', trigger_abort=False)
  File "c:\users\abosova\documents\cityenergyanalyst\cityenergyanalyst\cea\interfaces\dashboard\api\inputs.py", line 295, in get_network
    network_json, crs = df_to_json(edges, trigger_abort=trigger_abort)
  File "c:\users\abosova\documents\cityenergyanalyst\cityenergyanalyst\cea\interfaces\dashboard\api\inputs.py", line 311, in df_to_json
    lat, lon = get_lat_lon_projected_shapefile(table_df)
  File "c:\users\abosova\documents\cityenergyanalyst\cityenergyanalyst\cea\utilities\standardize_coordinates.py", line 68, in get_lat_lon_projected_shapefile
    data = data.to_crs(get_geographic_coordinate_system())
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\geopandas\geodataframe.py", line 816, in to_crs
    geom = df.geometry.to_crs(crs=crs, epsg=epsg)
  File "C:\Users\abosova\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\geopandas\geoseries.py", line 527, in to_crs
    "Cannot transform naive geometries.  "
ValueError: Cannot transform naive geometries.  Please set a crs on the object first.

Hardware OS and version: Windows 10 Version of CEA: 3.13.0

[shanshanhsieh]

this will be a hackathon topic, please work on identifying:

1. what is the limit of creating scenarios with large building numbers via dashboard
2. if the dashboard is not able to handle a large number of buildings, please provide an alternative process

[nasty-bos]

I created a bunch of scenarios to identify the limit and couldn't catch the same error in the range of 500-6000 buildings, even though initially it occurred in the scenarios with ~3200 and ~1000 buildings. Seems to show random behavior. I also tried to create a scenario with 14000 buildings, this made Dashboard non-responsive.

[daren-thomas]

Status update: We're not sure how to reproduce this error. If it shows up again, we could use the site.shp file from that run to try and reproduce / debug this error. Closing for now.

[nasty-bos]

Unfortunately the problem occurred again, but this time the error behind "Something went wrong" is different.

[nasty-bos]

Here we go again, same scenario that we were looking at in the morning session. I left the Input Editor with this scenario open for the whole day, in the evening I went to Project Overview and tried to re-open the scenario. The error below appeared.

[nasty-bos]

Same error, different case study this time. It was working perfectly yesterday, I ran many scripts including radiation and was able to open and re-open the scenario in the Dashboard. It looked like PR of @reyery 2914 solved the issue. But not.

[shanshanhsieh]

@nasty-bos and i found out that the zone.prj are transformed in the corrupted files:

PROJCS["Transverse_Mercator",GEOGCS["GCS_unknown",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]]

the non-corrupted one has this:

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]]

the differences between these two scenarios are that the corrupted one was updated by the GWR mapper. any idea where this might happen, @reyery ?

[shanshanhsieh]

GWR mapper modifies zone.shp to adjust floor heights, the zone.prj might be transformed during the process.

[nasty-bos]

@shanshanhsieh I tried to reproduce the transformation of zone.prj after running GWR Mapper with a small case study. What I observed after creating a new scenario and sketching zone via Dashboard is the following: First zone.prj is created with "Transverse_Mercator", and after running GWR Mapper it is transformed into "WGS_1984_UTM_Zone_32S". So it is the other way around.

[shanshanhsieh]

as we cannot reproduce this error, we will close it for now.