Relates to GeoNode #8689

[mattiagiupponi]

relates to geonode #8689 and #8690

[gannebamm]

Sorry was late with my review. I just tested adding additional metadata to existing resources by following the documentation and that worked fine even though getting the metadata entered is cumbersome due to the JSON, but that's something a new frontend/client can improve upon. I did not test to add custom metadata schemas for a resource type, yet. I understand the default schema has to be copied and extended for that @mattiagiupponi ?

eg. something like this:

MAP_EXTRA_METADATA_SCHEMA= {
# copied from default, since default gets overridden by this one?
    Optional("id"): int,
    "filter_header": object,
    "field_name": object,
    "field_label": object,
    "field_value": object,
    # just a new map specific object
    "map_specific_object": object,
}

But these map_specific_object will not get displayed as filter facets dynamically, right? Nonetheless, they should get exposed in the API responses?

[afabiani]

@gannebamm yes, at least in 3.3.x those will be exposed as dynamic filter facets too and there will be the possibility to r/w also via the APIs both V1 and V2

[mattiagiupponi]

Hi @gannebamm

I did not test to add custom metadata schemas for a resource type, yet. I understand the default schema has to be copied and extended for that @mattiagiupponi ?

The idea is that that schema is default and, if needed, can be replaced by the schema defined by the user for a specific resource. So technically you can define a schema that is completely different from that one.

But these map_specific_object will not get displayed as filter facets dynamically, right? Nonetheless, they should get exposed in the API responses?

ALL the metadata are exposed by both APIs, by following the above example, you can easily search for the metadata that you want, for example in the V1:

http://host/api/base/?metadata__map_specific_object=my_value

Related to the dynamic filtering, now the code expected that they at least filter_header, field_name, field_value exists in the metadata. The reason is that we can generate the facet with the structure required and be able to correctly count the occurrences (by removing duplicates etc). Of course, this process can improve. Plus this is valid only for 33x

[gannebamm]

I like this. Thanks for the clarifications and great work :D