geoserver uses temporary id in metadata link

[juliepierson]

When specifying a temporary id that will be replaced by a uuid by geoflow, geoserver uses temporary id in the metadata links of layers.

[eblondel]

The implementation of use_uuid option done in geoflow is specific to metadata. It was not applied to other actions (geoserver, dataverse, etc), and not considered as global option. See it at geoflow::list_action_options("geometa-create-iso-19115"). The metadata id and layer id do not need to match necessarily, it's especially true for multilayer where you will have multiple layer IDs for one single metadata UUID.

[juliepierson]

Thanks for your answer ! I don't know if I understand you correctly, but the problem is in the metadata link of the geoserver layer, not in the layer id ?

[eblondel]

ah got it :-)

[eblondel]

@juliepierson i've just pushed a fix for this. Thanks for the review, i completely missed this when implementing the use_uuid strategy

[juliepierson]

Thanks :)

[juliepierson]

I just tried it, it seems that temp id is still used in metadata link in geoserver layer ?

[eblondel]

i'm going to check that one

[juliepierson]

Thanks !

[eblondel]

pushed a commit. can you indicate whether the geosapi action is set before the ISO 19115 action in your config? The problem is that before I was setting the UUID within the geometa action, and this would have worked only if geosapi action was executed after the metadata action. Now i've made it part of the entity enrichment so actions order shouldn't have effect.

When reading/enriching the geoflow entity, we check whether use_uuid was specified in ISO 19115 action, and generate an UUID assigning it as entity identifier; in a way that all underlying actions (those concerned) will benefit of this uuid

[juliepierson]

It works now, thanks ! Yes, geosapi action was set before create iso 19115 action, disn't realize that the order of actions was important !

[eblondel]

It can be important, but it's also aim of geoflow to solve this kind of issues