[GeoNetwork-devel] Some records not displaying in GeoNetwork 4.2 due to elasticsearch errors

Jo_Cook2 · February 8, 2023, 1:06pm

Hi All,

I have a GeoNetwork installation that has been upgraded from GeoNetwork 3.10.x to 4.2.x, and a number of records are causing indexing errors and warnings in ElasticSearch. Some are clear and fixable, and display OK in the catalogue, but I have a group of records that don’t display at all.

The error that I see in the admin console → statistics and status tab is this:

ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse]]; nested: ElasticsearchException[Elasticsearch exception [type=class_cast_exception, reason=class org.elasticsearch.index.mapper.KeywordFieldMapper cannot be cast to class org.elasticsearch.index.mapper.ObjectMapper (org.elasticsearch.index.mapper.KeywordFieldMapper and org.elasticsearch.index.mapper.ObjectMapper are in unnamed module of loader ‘app’)]];

I also see this at the base of the record in display view (where none of the actual metadata displays).

In the elasticsearch logs (I’ve tested this with 7.11.1 and 7.12.1) I can see the record, and I can see an index error, but it’s related to something else- namely an empty temporal extent.

Frustratingly, if I download the record and reimport it with a new UUID but no other changes, then the newly imported record displays just fine.

I can see from the error that the keywords seem to be the problem, but I can’t see what’s wrong with the record, or any common factor between the records where this problem occurs (approx 200 records from 1200).

If someone could point me in the right direction that would be wonderful!

Thanks

Jo

···

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com.
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

Jose_Garcia1 · February 8, 2023, 3:18pm

Hi Jo

Have you compared the xml of the existing and imported records? They should be the same, but just to make sure that the update fixed info process isn’t applying some changes on the imported metadata that make a difference.

I would try also reindexing the catalog after the migration from the Admin console > Tools.

Can you also point to a metadata to test?

Regards,

Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 14:06:08 +0100, Jo Cook via GeoNetwork-devel geonetwork-devel@lists.sourceforge.net escribió ----

Hi All,

I have a GeoNetwork installation that has been upgraded from GeoNetwork 3.10.x to 4.2.x, and a number of records are causing indexing errors and warnings in ElasticSearch. Some are clear and fixable, and display OK in the catalogue, but I have a group of records that don’t display at all.

The error that I see in the admin console → statistics and status tab is this:

ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse]]; nested: ElasticsearchException[Elasticsearch exception [type=class_cast_exception, reason=class org.elasticsearch.index.mapper.KeywordFieldMapper cannot be cast to class org.elasticsearch.index.mapper.ObjectMapper (org.elasticsearch.index.mapper.KeywordFieldMapper and org.elasticsearch.index.mapper.ObjectMapper are in unnamed module of loader ‘app’)]];

I also see this at the base of the record in display view (where none of the actual metadata displays).

In the elasticsearch logs (I’ve tested this with 7.11.1 and 7.12.1) I can see the record, and I can see an index error, but it’s related to something else- namely an empty temporal extent.

Frustratingly, if I download the record and reimport it with a new UUID but no other changes, then the newly imported record displays just fine.

I can see from the error that the keywords seem to be the problem, but I can’t see what’s wrong with the record, or any common factor between the records where this problem occurs (approx 200 records from 1200).

If someone could point me in the right direction that would be wonderful!

Thanks

Jo

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

GeoNetwork-devel mailing list

GeoNetwork-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geonetwork-devel

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Jo_Cook2 · February 8, 2023, 3:31pm

Hi Jose,

I thought about that- but the only difference between the imported and original record is the UUID. I have tried deleting and recreating the index, and reindexing several times after the migration. With some of the other errors I have been able to fix the problem and immediately the record has displayed. Here’s one of the records working just fine in GeoNetwork 3.10.x: https://spatialdata.gov.scot/geonetwork/srv/api/records/63a1b58b-3cff-4064-9828-eef26bcae090 but the 4.2.x version isn’t publicly accessible yet. It’s a Gemini 2.3 record.

Thanks!

Jo

···

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com.
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

Jose_Garcia1 · February 8, 2023, 3:37pm

Hi

Have you check the imported and original metadata are assigned to the Gemini 2.3 schema? I guess there is a version of the schema for 4.2?

Regards,
Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com…

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 16:31:18 +0100, Jo Cook jocook@anonymised.com escribió ----

Hi Jose,

I thought about that- but the only difference between the imported and original record is the UUID. I have tried deleting and recreating the index, and reindexing several times after the migration. With some of the other errors I have been able to fix the problem and immediately the record has displayed. Here’s one of the records working just fine in GeoNetwork 3.10.x: https://spatialdata.gov.scot/geonetwork/srv/api/records/63a1b58b-3cff-4064-9828-eef26bcae090 but the 4.2.x version isn’t publicly accessible yet. It’s a Gemini 2.3 record.

Thanks!

Jo

On Wed, Feb 8, 2023 at 3:18 PM Jose Garcia <jose.garcia@anonymised.com> wrote:

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training
Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

Hi Jo

Have you compared the xml of the existing and imported records? They should be the same, but just to make sure that the update fixed info process isn’t applying some changes on the imported metadata that make a difference.

I would try also reindexing the catalog after the migration from the Admin console > Tools.

Can you also point to a metadata to test?

Regards,

Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 14:06:08 +0100, Jo Cook via GeoNetwork-devel <geonetwork-devel@lists.sourceforge.net> escribió ----

Hi All,

I have a GeoNetwork installation that has been upgraded from GeoNetwork 3.10.x to 4.2.x, and a number of records are causing indexing errors and warnings in ElasticSearch. Some are clear and fixable, and display OK in the catalogue, but I have a group of records that don’t display at all.

The error that I see in the admin console → statistics and status tab is this:

ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse]]; nested: ElasticsearchException[Elasticsearch exception [type=class_cast_exception, reason=class org.elasticsearch.index.mapper.KeywordFieldMapper cannot be cast to class org.elasticsearch.index.mapper.ObjectMapper (org.elasticsearch.index.mapper.KeywordFieldMapper and org.elasticsearch.index.mapper.ObjectMapper are in unnamed module of loader ‘app’)]];

I also see this at the base of the record in display view (where none of the actual metadata displays).

In the elasticsearch logs (I’ve tested this with 7.11.1 and 7.12.1) I can see the record, and I can see an index error, but it’s related to something else- namely an empty temporal extent.

Frustratingly, if I download the record and reimport it with a new UUID but no other changes, then the newly imported record displays just fine.

I can see from the error that the keywords seem to be the problem, but I can’t see what’s wrong with the record, or any common factor between the records where this problem occurs (approx 200 records from 1200).

If someone could point me in the right direction that would be wonderful!

Thanks

Jo

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

GeoNetwork-devel mailing list

GeoNetwork-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geonetwork-devel

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Jo_Cook2 · February 8, 2023, 3:52pm

Hi Jose,

Yes I have, and yes there is a version for 4.2. I have other records that are Gemini 2.3 in GeoNetwork 4.2 and they display fine. I also have records in other standards (Gemini 2.2) that also don’t display, with the same error.

Thanks

Jo

···

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com.
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

Jo_Cook2 · February 8, 2023, 4:28pm

Hi Jose,

I should also add that the records display fine in advanced display view, just not in default view, and you can’t search them by title (though you can by UUID).

Thanks

Jo

···

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com.
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

Jose_Garcia1 · February 9, 2023, 12:12pm

Hi Jo

I’ve imported the xml from https://spatialdata.gov.scot/geonetwork/srv/api/records/63a1b58b-3cff-4064-9828-eef26bcae090 in latest 4.2.x. The metadata gets imported as iso19139 and the metadata detail page works fine.

I see an indexing warning:

Warning / Field resourceTemporalDateRange / Lower and upper bounds empty or not valid dates. Date range not indexed. (1)

But doesn’t affect the metadata detail view.

In the javascript console, I see 2 errors:

http://localhost:8080/geonetwork/srv/api/logos/sepa.org.uk.png 404 (Not Found)

The metadata have no reference to such logo, it contains a mail address and a url containing sepa.org.uk, but not sure why GeoNetwork tries to access that logo. In any case, doesn’t cause trouble.

Another error due to a search request, that I get with any metadata, and I’m investigating.

So in summary, it seems working fine with the iso19139 schema. Maybe is related to some customisation in Gemini 2.3 schema.

Regards,
Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 17:28:05 +0100, Jo Cook jocook@anonymised.com escribió ----

Hi Jose,

I should also add that the records display fine in advanced display view, just not in default view, and you can’t search them by title (though you can by UUID).

Thanks

Jo

On Wed, Feb 8, 2023 at 3:52 PM Jo Cook <jocook@anonymised.com> wrote:

Hi Jose,

Yes I have, and yes there is a version for 4.2. I have other records that are Gemini 2.3 in GeoNetwork 4.2 and they display fine. I also have records in other standards (Gemini 2.2) that also don’t display, with the same error.

Thanks

Jo

On Wed, Feb 8, 2023 at 3:37 PM Jose Garcia <jose.garcia@anonymised.com> wrote:

Hi

Have you check the imported and original metadata are assigned to the Gemini 2.3 schema? I guess there is a version of the schema for 4.2?

Regards,
Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 16:31:18 +0100, Jo Cook <jocook@anonymised.com…1036…> escribió ----

Hi Jose,

I thought about that- but the only difference between the imported and original record is the UUID. I have tried deleting and recreating the index, and reindexing several times after the migration. With some of the other errors I have been able to fix the problem and immediately the record has displayed. Here’s one of the records working just fine in GeoNetwork 3.10.x: https://spatialdata.gov.scot/geonetwork/srv/api/records/63a1b58b-3cff-4064-9828-eef26bcae090 but the 4.2.x version isn’t publicly accessible yet. It’s a Gemini 2.3 record.

Thanks!

Jo

On Wed, Feb 8, 2023 at 3:18 PM Jose Garcia <jose.garcia@anonymised.com> wrote:

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

Hi Jo

Have you compared the xml of the existing and imported records? They should be the same, but just to make sure that the update fixed info process isn’t applying some changes on the imported metadata that make a difference.

I would try also reindexing the catalog after the migration from the Admin console > Tools.

Can you also point to a metadata to test?

Regards,

Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 14:06:08 +0100, Jo Cook via GeoNetwork-devel <geonetwork-devel@lists.sourceforge.net> escribió ----

Hi All,

I have a GeoNetwork installation that has been upgraded from GeoNetwork 3.10.x to 4.2.x, and a number of records are causing indexing errors and warnings in ElasticSearch. Some are clear and fixable, and display OK in the catalogue, but I have a group of records that don’t display at all.

The error that I see in the admin console → statistics and status tab is this:

ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse]]; nested: ElasticsearchException[Elasticsearch exception [type=class_cast_exception, reason=class org.elasticsearch.index.mapper.KeywordFieldMapper cannot be cast to class org.elasticsearch.index.mapper.ObjectMapper (org.elasticsearch.index.mapper.KeywordFieldMapper and org.elasticsearch.index.mapper.ObjectMapper are in unnamed module of loader ‘app’)]];

I also see this at the base of the record in display view (where none of the actual metadata displays).

In the elasticsearch logs (I’ve tested this with 7.11.1 and 7.12.1) I can see the record, and I can see an index error, but it’s related to something else- namely an empty temporal extent.

Frustratingly, if I download the record and reimport it with a new UUID but no other changes, then the newly imported record displays just fine.

I can see from the error that the keywords seem to be the problem, but I can’t see what’s wrong with the record, or any common factor between the records where this problem occurs (approx 200 records from 1200).

If someone could point me in the right direction that would be wonderful!

Thanks

Jo

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

GeoNetwork-devel mailing list

GeoNetwork-devel@anonymised.comorge.net

https://lists.sourceforge.net/lists/listinfo/geonetwork-devel

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

Jo_Cook2 · February 9, 2023, 1:25pm

Hi Jose,

Thanks. I have even tried exporting the record that’s not displaying, as xml, and then importing it back into the same catalog (with a different UUID) and the new version displays. Both records are in Gemini 2.3. I can see by searching the elasticsearch index that the original record is not indexed but the new one is.

Jo

···

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com.
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

Jo_Cook2 · February 13, 2023, 5:17pm

Hi Jose and everyone,

I’ve narrowed down the problem with this. It’s to do with the number of characters in the field relating to the validation status when it’s indexed. In my index I have the following:
“valid_schematron-rules-GEMINI_2.3_Schema-v1.0”: “1”,
“valid_xsd”: “1”,
“valid_schematron-rules-GEMINI_2.3_supp-v1.0”: “0”,
“valid_schematron-rules-ISOTS19139A1Const”: “1”,
If any of these field names are longer than 32 characters then the error occurs. If they are 32 characters or less, then the error does not occur, the record can be indexed, and displays just fine in GeoNetwork. You can test this quite easily by manually adding a record to the index using curl or the console in kibana.
It’s also possible to trigger the same error by validating a record that had not previously been validated. This is why it’s possible to import new records into the catalog without triggering the error.

Is this 32 character limit actually set somewhere, or is it dynamically created by the fact that some of the earlier records that I indexed were in a different schema with a shorter name?

Any help would be greatly appreciated!

Thanks

Jo

···

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com.
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

Jose_Garcia1 · February 14, 2023, 7:58am

Hi Jo

The problem seem related to the dots in the field names, not to the length. I’ve tested. The code that creates that names from the schematron rules, should remove that characters.

A quick fix, can be to update the file names to remove the dots, but will require to update also the schematron tables to reflect the new names.

Regards,

Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Mon, 13 Feb 2023 18:17:13 +0100, Jo Cook <jocook@anonymised.com36…> escribió ----

Hi Jose and everyone,

I’ve narrowed down the problem with this. It’s to do with the number of characters in the field relating to the validation status when it’s indexed. In my index I have the following:

“valid_schematron-rules-GEMINI_2.3_Schema-v1.0”: “1”,
“valid_xsd”: “1”,
“valid_schematron-rules-GEMINI_2.3_supp-v1.0”: “0”,
“valid_schematron-rules-ISOTS19139A1Const”: “1”,
If any of these field names are longer than 32 characters then the error occurs. If they are 32 characters or less, then the error does not occur, the record can be indexed, and displays just fine in GeoNetwork. You can test this quite easily by manually adding a record to the index using curl or the console in kibana.

It’s also possible to trigger the same error by validating a record that had not previously been validated. This is why it’s possible to import new records into the catalog without triggering the error.

Is this 32 character limit actually set somewhere, or is it dynamically created by the fact that some of the earlier records that I indexed were in a different schema with a shorter name?

Any help would be greatly appreciated!

Thanks

Jo

On Thu, Feb 9, 2023 at 1:25 PM Jo Cook <jocook@anonymised.com> wrote:

Hi Jose,

Thanks. I have even tried exporting the record that’s not displaying, as xml, and then importing it back into the same catalog (with a different UUID) and the new version displays. Both records are in Gemini 2.3. I can see by searching the elasticsearch index that the original record is not indexed but the new one is.

Jo

On Thu, Feb 9, 2023 at 12:12 PM Jose Garcia <jose.garcia@anonymised.com> wrote:

Hi Jo

I’ve imported the xml from https://spatialdata.gov.scot/geonetwork/srv/api/records/63a1b58b-3cff-4064-9828-eef26bcae090 in latest 4.2.x. The metadata gets imported as iso19139 and the metadata detail page works fine.

I see an indexing warning:

Warning / Field resourceTemporalDateRange / Lower and upper bounds empty or not valid dates. Date range not indexed. (1)

But doesn’t affect the metadata detail view.

In the javascript console, I see 2 errors:

http://localhost:8080/geonetwork/srv/api/logos/sepa.org.uk.png 404 (Not Found)

The metadata have no reference to such logo, it contains a mail address and a url containing sepa.org.uk, but not sure why GeoNetwork tries to access that logo. In any case, doesn’t cause trouble.

Another error due to a search request, that I get with any metadata, and I’m investigating.

So in summary, it seems working fine with the iso19139 schema. Maybe is related to some customisation in Gemini 2.3 schema.

Regards,
Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 17:28:05 +0100, Jo Cook <jocook@…1036…> escribió ----

Hi Jose,

I should also add that the records display fine in advanced display view, just not in default view, and you can’t search them by title (though you can by UUID).

Thanks

Jo

On Wed, Feb 8, 2023 at 3:52 PM Jo Cook <jocook@anonymised.com> wrote:

Hi Jose,

Yes I have, and yes there is a version for 4.2. I have other records that are Gemini 2.3 in GeoNetwork 4.2 and they display fine. I also have records in other standards (Gemini 2.2) that also don’t display, with the same error.

Thanks

Jo

On Wed, Feb 8, 2023 at 3:37 PM Jose Garcia <jose.garcia@anonymised.com> wrote:

Hi

Have you check the imported and original metadata are assigned to the Gemini 2.3 schema? I guess there is a version of the schema for 4.2?

Regards,
Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 16:31:18 +0100, Jo Cook <jocook@anonymised.com> escribió ----

Hi Jose,

I thought about that- but the only difference between the imported and original record is the UUID. I have tried deleting and recreating the index, and reindexing several times after the migration. With some of the other errors I have been able to fix the problem and immediately the record has displayed. Here’s one of the records working just fine in GeoNetwork 3.10.x: https://spatialdata.gov.scot/geonetwork/srv/api/records/63a1b58b-3cff-4064-9828-eef26bcae090 but the 4.2.x version isn’t publicly accessible yet. It’s a Gemini 2.3 record.

Thanks!

Jo

On Wed, Feb 8, 2023 at 3:18 PM Jose Garcia <jose.garcia@anonymised.com7…> wrote:

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

Hi Jo

Have you compared the xml of the existing and imported records? They should be the same, but just to make sure that the update fixed info process isn’t applying some changes on the imported metadata that make a difference.

I would try also reindexing the catalog after the migration from the Admin console > Tools.

Can you also point to a metadata to test?

Regards,

Jose García

Jose Garcia

E-mail: jose.garcia@anonymised.com

https://www.geocat.net

Veenderweg 13

6721 WD Bennekom

The Netherlands

Tel: +31318416664

---- El Wed, 08 Feb 2023 14:06:08 +0100, Jo Cook via GeoNetwork-devel <geonetwork-devel@lists.sourceforge.net> escribió ----

Hi All,

I have a GeoNetwork installation that has been upgraded from GeoNetwork 3.10.x to 4.2.x, and a number of records are causing indexing errors and warnings in ElasticSearch. Some are clear and fixable, and display OK in the catalogue, but I have a group of records that don’t display at all.

The error that I see in the admin console → statistics and status tab is this:

ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse]]; nested: ElasticsearchException[Elasticsearch exception [type=class_cast_exception, reason=class org.elasticsearch.index.mapper.KeywordFieldMapper cannot be cast to class org.elasticsearch.index.mapper.ObjectMapper (org.elasticsearch.index.mapper.KeywordFieldMapper and org.elasticsearch.index.mapper.ObjectMapper are in unnamed module of loader ‘app’)]];

I also see this at the base of the record in display view (where none of the actual metadata displays).

In the elasticsearch logs (I’ve tested this with 7.11.1 and 7.12.1) I can see the record, and I can see an index error, but it’s related to something else- namely an empty temporal extent.

Frustratingly, if I download the record and reimport it with a new UUID but no other changes, then the newly imported record displays just fine.

I can see from the error that the keywords seem to be the problem, but I can’t see what’s wrong with the record, or any common factor between the records where this problem occurs (approx 200 records from 1200).

If someone could point me in the right direction that would be wonderful!

Thanks

Jo

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

GeoNetwork-devel mailing list

GeoNetwork-devel@anonymised.com.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geonetwork-devel

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com

Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training

Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009

–

Sign up to our mailing list for updates on news, products, conferences, events and training

Astun Technology Ltd, t:+44 1372 744 009 contact us online

web: astuntechnology.com twitter:@astuntech

iShare - enterprise geographic intelligence platform

GeoServer, PostGIS and QGIS training
Support

Company registration no. 5410695. Registered in England and Wales. Registered office: Penrose House, 67 Hightown Road, Banbury, OX16 9BE VAT no. 864201149.

Jo_Cook2 · February 14, 2023, 8:53am

Hi Jose,

Thanks- yes I eventually figured that out myself. Renaming the files and updating the schematrondes and validation tables with the new names worked just fine. What a relief!

Jo

···

Jo Cook
t:+44 7930 524 155 | twitter:@archaeogeek | mastodon:@archaeogeek@anonymised.com.
Please note that currently I do not work on Friday afternoons. For urgent responses at that time, please visit support.astuntechnology.com or phone our office on 01372 744009