Allow migrating from id inside properties to top level id (in STJ)

[HarelM]

I have the following use case:
I have a database with features that have an id field in the properties (called poiId).
I have mobile clients that expect this field to be populated.
I would like the ability to transition from the field in the properties to the top level id.
So I would like to have a way to have the id in both places, then update the mobile clients to use the new top level id, and then retire the id inside the properties.
When I define the factory to look at a field inside properties for the id it will not emit it when serializing and will remove it from attributes table when deserializing.
Is there a way to tell the json converter to keep the id in the properties, serialize it and also serialize the top level id?
Is there a way to set the ID of an IFeature or IUnique?
Basically remove the following if:
https://github.com/NetTopologySuite/NetTopologySuite.IO.GeoJSON/blob/28502d559a1c27b291e1a7ead06888edadd5d1f4/src/NetTopologySuite.IO.GeoJSON4STJ/Converters/StjAttributesTableConverter.cs#LL43C53-L43C53
Or make an option in the converter to turn it off...?
Thanks!

[airbreather]

The only reason I can think of why anyone should ever need to change idPropertyName in the GeoJsonConverterFactory would be if they had an actual need for the string "_NetTopologySuite_id" to show up in a GeoJSON Feature's "properties" object, and so they would need us to choose a different magic string that won't clash with whatever they come up with.

For all other use cases, I recommend leaving that value alone (which you can just spell as "null" if you want).

Is there a way to tell the json converter to keep the id in the properties, serialize it and also serialize the top level id?

There is no way to tell the converter to take a single value that lives in one place and use it in two places for the output. However, I also don't know of anything that's stopping you from taking one value and copying it to two places so that you can have it written out in those two different places in the output...?

If you do not change idPropertyName from the default, then an attribute in the attributes table named "poiId" will be serialized in the GeoJSON Feature object's "properties" object with the property name "poiId", and an attribute named "_NetTopologySuite_id" in the attributes table will be serialized as the GeoJSON Feature object's top-level "id" value.

Is there a way to set the ID of an IFeature or IUnique?

I don't know what "set the ID of an IFeature" means in this context.

• If you serialize an instance of an object that implements both the IFeature interface and the IUnique interface, then our converters will serialize it as a GeoJSON Feature object whose top-level "id" property comes from the IUnique.
• If you serialize an instance of an object that implements the IFeature interface but not the IUnique interface, but it does happen to have an attribute whose name matches the idPropertyName that was given to the GeoJsonConverterFactory constructor (default being "_NetTopologySuite_id"), then our converters will serialize it as a GeoJSON Feature object whose top-level "id" property comes from the value of that attribute, instead of writing out that attribute into the "properties".
  • This was done so that you don't have to go out of your way to create a whole new class that implements both IFeature and also IUnique just to write out a GeoJSON Feature object with a top-level "id" property.
• If you serialize an instance of an object that implements the IFeature interface that does not meet any of the previous two criteria, then our converters will serialize it as a GeoJSON Feature object that does not have a top-level "id" property.

If you need the ability to specifically ensure that a particular instance of an object implements the IUnique interface with a particular value for its Id property, then you can implement it in a class that has all the flexibility you need. IUnique.Id only has a getter, but nothing's stopping you from implementing that interface using a class whose Id property also has a setter, after all...

[HarelM]

I see, thanks for the detailed explanation.
Bottom line, If I need to support this migration, I'll need to hack my way around :-)