Feature type re-assignment

[michaelchin]

DM would like to select a range of features and reset them all to the one particular type of feature.

[michaelchin]

• add a new gplately command(reset_feature_type) to select a range of features and reset them all to the one particular type of feature.
• extend the filter command to allow users to select features of certain feature types

[michaelchin]

@jcannon-gplates

Changing feature type seems tricky. I guess this is the reason why

This kind of request has been on the wishlist for a long, long time.

I am thinking of creating new features with the new feature type and copying all properties into the new features. But I am not sure if this is the correct way to do it. To avoid wasting time on the wrong approach, I would like to hear your opinion. I have written some experimental code , see the code at https://github.com/GPlates/gplately/blob/f277a069877cda7ee94e779415b41a8775b944a0/gplately/commands/reset_feature_type.py

[jcannon-gplates]

This kind of request has been on the wishlist for a long, long time.

I suspect Dietmar said that 😉

Yes, it's a bit tricky. There is an option to change the feature type in GPlates...

...but it displays property types that are not valid for the changed feature type. But it'll still let you change the feature type anyway.

Some more details regarding adding properties to feature types in pygplates here and here.

I have written some experimental code

Your code looks good. Here's another version with some minor tweaks:

    new_f = pygplates.Feature(new_feature_type)
    for p in f:
        new_f.add(p.get_name(), p.get_time_dependent_value(), pygplates.VerifyInformationModel.no)

...where VerifyInformationModel shouldn't be needed in Feature constructor (as long as you're not inventing a new feature type - that's not in the GPGIM).

If the feature type is pygplates.FeatureType.gpml_unclassified_feature (as in your code) then it'll accept any property (provided it's in the GPGIM). But for other feature types you'll probably want to specify pygplates.VerifyInformationModel.no (when adding a property) so that it doesn't raise a InformationModelError exception.

And I've used p.get_time_dependent_value() instead of p.get_value(). While the latter is fine, it does extract the property value at time=0 by default - which can be a problem if the property is time-dependent - but it's probably fine in general because we don't really have any time-dependent properties yet. But just in case, the p.get_time_dependent_value() will handle both cases for us.

Also, not sure if you want to keep the feature ID or not. In my code it generates a new feature ID (in your code it re-uses the feature ID).

[michaelchin]

This kind of request has been on the wishlist for a long, long time.

I suspect Dietmar said that 😉

Thanks John.

It does not sound like DM indeed. But it does sound like another our beloved client. Sometimes DM acts like an email proxy...