-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Class column NULL vs matching subtype #250
Comments
@jeffdefacto Can you give specific examples? A table with at least one example for every theme and feature type would be super helpful, especially if it includes: theme, type, feature ID, subtype, and class. (Note that some feature types do not have a |
Here are the subtype and class counts for the water theme. All features have a class even if it just mirrors the subtype. In the case of 2024-08-20.0.theme=base.type=water.csv On the other hand, in transportation segments, 2024-08-20.0.theme=transportation.type=segment.csv Within buildings, there are instances of both of these approaches. For example, subtype 2024-08-20.0.theme=buildings.type=building.csv Here are the other relevant layers for reference as well. 2024-08-20.0.theme=base.type=infrastructure.csv I can provide specific feature ids as well if that would be helpful but the aggregate data is probably the clearest examples. |
I've noticed that the different themes are inconsistent in how the class column is handled. In some layers there are no nulls in the class field and it mirrors subtype when there is not a more specific value. E.g. when subtype = 'civic' then class can also be 'civic'
However, Divisions and Transportation seem to not have this mirroring and instead allow null values for class. The Buildings theme currently has a mixture of both situations.
We should have a consistent standard for how this field is populated.
The text was updated successfully, but these errors were encountered: