It's something of a kludge (as are most of my first-cut approaches to problems), but what I do is append a JSON object with potenitally-editable fields to the description tag.
For a current project I want to enable some candidate geographies to be visually verified, to check if the classifier for timber plantation detection is doing an OK job. (The candidates are obtained by a decision tree implemented in PostgreSQL that traverses five different datasets; the 'medium-high probability' targets are then fed to a customised image classifier that uses TensorFlow tf-slim - that's not important to your question, but it is hella cool and was great fun to build).
Anyhow... moving on...
To enable our visual-verification guys to do their jobs easily, KML is generated that can be mounted in Google Earth (so that we can exploit the historical high-res imagery).
GE can then 'fly' from parcel to parcel using the 'Tour' feature with 0.5sec time between features, and 2.5 seconds on each feature.
Now unless there's something editable, there's no mechanism for the verification to 'happen' unless they just delete features that aren't properly classified. That's not the best way to provide feedback to the classifier dev team (i.e., me).
So to give them something editable... you could generate the KML using ogr2ogr, with
-dsco NameField=[nameField]
and
-dsco DescriptionField=[descField]
(Items in square brackets are placeholders for actual column names).
We do something equivalent, but not using ogr2ogr for a couple of reasons: mostly because ogr2ogr doesn't produce ancillary tags (like <TimeStamp> and <TimeSpan>).
We generate KML straight out of PostgreSQL, with the polygon itself generated by ST_AsKML(ST_Transform(g1, 4326)) (since our g1 is canonically 4283). Other relevant KML data generated from aspatial table fields.
An example of what the content of the <description> tag looks like for a given polygon:
{
candidate2009: "Y",
candidate2015: "Y",
HasInteriorPlantation: "Y",
InteriorPlantationCount: "2",
InCluster: "Y",
HasCluster: "Y",
PlantationStatus2015: "mature",
PlantationStatus2009: "mature",
clearedYear:"",
Notes:""
}
Them as might, will recognise that as valid JSON (so that when the data is updated, it can be parsed and added to a DB).
If a parcel doesn't seem to be properly classified, the analyst can edit the description tag.
Works a treat.
In an ideal world it would be possible to have the 'Properties' for each geography open on double-click (or do so as the tour arrives at each feature), but as far as I am aware that's not possible in GE (they killed the JS API for GE in Dec 2014).
In Maps the JS API is great, so adding that sort of thing is a snap - just attach a jQuery .on('click', function(feature){}) to each data layer: we do that all the time for things that don't require historical aerials. Maps does not have historical aerial/satellite imagery, though, and Google Earth Engine only has low-res.
If you do go down this route: make certain that if the polygons themselves are to be editable, that the KML has an identifier that can be matched to the underlying geography. We do that by ensuring that [nameField] includes a persistent identifier.
TL;DR: set up editable attributes in the description tag, in a format that can be reliably parsed in your primary framework. (JSON is ideal: covers JS, PHP, Python, and most SQL variants).
