Open julietcohen opened 11 months ago
I documented a concern for this feature in issue#21.
A note on using geopandas explode to separate MultiPolygon geoms into single Polygon geoms that just occurred to me: This approach duplicates the attributes of the original row into the newly created row, which is fine for some attributes, but I suspect this may be a problem if there are attributes such as area or perimeter, because those were originally derived from the MultiPolygon geom, so when we change the geom to a subset of the original, those are no longer accurate. So when we use explode, we may then need to somehow detect which attributes are invalidated because they are specific to the original geom and would not be accurate when applied to the new geom, so the value needs to become NaN if that is the case (or whatever the no-data-val is for the dataset). Then after, we would want to remove the rows that have NaN for the attributes of interest.
It may be unnecessary to resolve this ticket. According to a recent conversation with Matt, converting multipolygon geometries into singular polygon geometries was implemented in order to subsequently 3D tile the staged tiles. But since @rushirajnenuji is working on adjusting the viz-3dtiles repo and we are actually considering not using that repo anymore in place of the original repo that it was forked from, py3dtiles, then we maybe can just remove this conversion of multipolygons -> singular polygons all together.
After we read in an input file to stage, we filter the geodataframe to just the rows that contain single polygon geometries here. If an input file contains all or some multipolygon geometries, these are still able to be staged by
viz-staging
, because they are polygons and not lines or points, so they should not be excluded. Instead of filtering them out, we should insert a step toexplode
them, which creates a single row for each polygon in the multipolygons. This was tested with Ingmar Nitze's lake size time series dataset.Currently, if a file contains all multipolygons geometries, the workflow does not error or express this in the log explicitly. Instead, the workflow halts because there is nothing to stage, and outputs a warning message that there are no features in the file.
I see no issues with inserting this exploding step, but it should be tested with a branch off of
develop
with various kinds of input geometries. Overall, including this step will retain more geometries and therefore make the data more comprehensive.