<p dir="ltr">I agree that multiple categories set for a resourcebase object should be possible.</p>
<p dir="ltr">Yes, with batch metadata editing, fixing by hand shouldn't be difficult.</p>
<p dir="ltr">For the flag, how will GeoNode "know" the categories are ISO. It's implied, since they are the only ones there by default, but the flag wouldn't trigger an ISO check. It would just check that the category currently exists or not. Otherwise, we'd probably need another field in the Category model to say whether each is ISO or not. Either option is acceptable.</p>
<p dir="ltr">Regards,<br>
Patrick</p>
<div class="gmail_quote">On Dec 30, 2015 10:37 AM, "Eduardo Castanho" <<a href="mailto:eduardo.castanho@ipma.pt">eduardo.castanho@ipma.pt</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi! Patrick<br>
<br>
In last day of the code sprint in Turin, we talked about the lack of fields in Geonode metatada, comparing with ISO 19115 profile.<br>
One of those fields was Topic Category, that isn't fully supported by Geonode, because it only accepts one, more specifically the first topic category value on the metadata file.<br>
<br>
Your suggestion seems fine to me, but it implies that if you start with the flag on False and then change it to True, the data that you have in Geonode will be inconsistent, for example, the TopicCategory Model/Table will have non ISO entries.<br>
Some sort of solution to minimize this can be implemented, but in my opinion it only will bring an overload to the Geonode and this can be easily managed by "hand".<br>
<br>
May be the name for the FLAG can be more explicit like ISO_CATEGORIES_STRICT.<br>
<br>
<br>
Regards,<br>
<br>
Eduardo Castanho<br>
<br>
IPMA<br>
Instituto Português do Mar e da Atmosfera<br>
Lisboa Portugal<br>
<br>
<br>
<br>
<br>
On 29-12-2015 22:30, Patrick Dufour wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Good afternoon, Eduardo.<br>
<br>
Could you briefly recap the relevant discussion during the sprint? I<br>
missed that conversation.<br>
<br>
That is the expected behavior. We wanted to be sure that if you<br>
imported data from a source that isn't following that ISO standard<br>
closely that the import will work rather than throwing an error.<br>
GeoNode will match an existing category if possible and will create a<br>
new category if needed.<br>
<br>
I think my preference is to maintain that existing "default" behavior.<br>
However, I think a flag in settings like "CATEGORIES_STRICT=False"<br>
would work. If CATEGORIES_STRICT is true, then if a category doesn't<br>
match on upload/import an error is thrown. If CATEGORIES_STRICT is<br>
false, then the existing behavior goes.<br>
<br>
Regards,<br>
Patrick<br>
<br>
On 12/29/15, Eduardo Castanho <<a href="mailto:eduardo.castanho@ipma.pt" target="_blank">eduardo.castanho@ipma.pt</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!! to all<br>
<br>
I'm trying to implement multiple Topic Categories in Geonode, so that<br>
the metadata is more according to ISO 19115, as was discussed in this<br>
year code sprint.<br>
<br>
But I have a doubt about the correct behavior in the upload of<br>
metadata that contains Topic Categories that doesn't belong to ISO<br>
CodeList.<br>
<br>
Currently, Geonode creates a new category :<br>
<br>
elif key == 'topic_category':<br>
value, created =<br>
TopicCategory.objects*.get_or_create*(<br>
identifier=value.lower(),<br>
defaults={'description': '',<br>
'gn_description': value})<br>
key = 'category'<br>
defaults[key] = value<br>
<br>
<br>
@ geonode/geonode/layers/utils.py (line 442)/****/<br>
<br>
Is this the expected behavior?<br>
If we have multiple categories imported from metatada files, the number<br>
of new categories will raise a lot (including spelling errors), can this<br>
be bad ?<br>
<br>
with best regards,<br>
Eduardo Castanho<br>
<br>
IPMA<br>
Instituto Português do Mar e da Atmosfera<br>
Lisboa Portugal<br>
<br>
</blockquote></blockquote>
<br>
</blockquote></div>