"Model To geoJSON" deleted all other files in the target folder, why?!

Hello Everyone!
I’m working on a script for Urban District Energy Analysis and encountered a problem. After modifying the folder path in the “DF Model To geoJSON” component and executing it, it deleted all existing files in that directory. This issue also affected students following along in the class, leading to significant problems. Does anyone have suggestions on how to recover those files and understand why this occurred? It’s quite urgent, and any advice would be greatly appreciated!

@chris, I would appreciate it very much if you could take a look into this, I am teaching a course and this caused problems for several students. Thanks!!

Hi @fxh999 ,

Sorry for the late response and that my answer is likely not going to be what you were hoping.

The DF Model To GeoJSON component is designed to delete all of the files in the directory to which it is written. Otherwise, you would not be able to use a newly-written GeoJSON to get new/updated simulation results with URBANopt. You might chalk this up to a limitation of the current URBANopt SDK that it will not run a new simulation unless it does not find existing simulation files in the directory. So this kinda forces me to delete everything in the folder that the GeoJSON is written to in order to get the simulation to run correctly.

I’m also really sorry to say that the files deleted this way are wiped off the drive completely. So the answer to this:

Is that there’s really no reliable way to recover them since they are not in your recycle bin. If you have a backup system for your machine, that might provide you with a path to recover them. Or, if all else fails, the Windows File Recovery App might let you restore some of the files.

But I’m really sorry about this if you were trying to write the GeoJSON and run the simulation from a directory in which you already had files. We have been using this type of system to clear simulation directories for fresh simulations for over a decade now. And I have never gotten any reports about people accidentally deleting folders where they were running an E+ or Radiance simulation.

But, for some reason, these urban-scale simulations seem to be pretty vulnerable to this type of accidental deletion. The only other time that I saw this type of thing was for UWG simulation where someone deleted their Desktop by accident.

Now that I know this is another case where people are likely to make this mistake, let me see if I can revise the code such that only the URBANopt simulation files are deleted from the directory and nothing else.

Hi @fxh999 ,

I took a closer look at my code and I can see how this situation was particularly vulnerable to accidentally deleting files that people did not intend to remove. The URBANopt SDK uses an intensely nested folder structure, which can easily max out the number of characters allowed in file paths on Windows systems and necessitates that people use simulation folders that are shallow on their hard drive. I can see that this makes it particularly tempting to use your whole Desktop as the URBANopt simulation folder. Or worse, maybe your whole User folder.

To try and lower this risk to the point that it never happens again, I have refactored the code that writes out the GeoJSON and accompanying files for URBANopt simulation:

I tried to do a detailed accounting of everything that I could recognize as an URBANopt simulation file or folder and made sure to only delete those items (and no other files or folders). I think this is probably the best solution that I can offer for this case and, with this change, it should be very hard for people to get an accidental file deletion. The file would have a file extension ending in .geojson or .epw to be deleted accidentally.

I’m sorry, again, that this happened to you and/or your students. I know that it may not be much consolation but, because you reported it here, you have almost certainly saved this from happening to more people in the future.

The change that I made should be available with the LB Versioner component within an hour or so and, hopefully after that, we don’t see this issue arise again.