OSDU Software issueshttps://community.opengroup.org/groups/osdu/-/issues2024-01-19T05:37:54Zhttps://community.opengroup.org/osdu/platform/pre-shipping/-/issues/669IBM M22 Preship - WITSML Parser V1 fails2024-01-19T05:37:54ZDebasis ChatterjeeIBM M22 Preship - WITSML Parser V1 fails@vikasrana , @nikhil_patil , @ishakumari
As reported by email, I tried the first step (Create "Well" record) and it is failing for me.
"runId": "7a554510-5b1d-4495-ad7a-7859113e8d45",
See steps.[M22-IBM-WITSML-V1-Parser-Well-steps-Deb...@vikasrana , @nikhil_patil , @ishakumari
As reported by email, I tried the first step (Create "Well" record) and it is failing for me.
"runId": "7a554510-5b1d-4495-ad7a-7859113e8d45",
See steps.[M22-IBM-WITSML-V1-Parser-Well-steps-Debasis.txt](/uploads/6472c311bc1777d346caaca939757b3a/M22-IBM-WITSML-V1-Parser-Well-steps-Debasis.txt)
Enclosed is the log file from Airflow.
[2024-01-16-WITSML_V1-Parser-Airflow-log-failure.txt](/uploads/ef69ab1085ad65e611be0be9455e5e83/2024-01-16-WITSML_V1-Parser-Airflow-log-failure.txt)https://community.opengroup.org/osdu/platform/system/project-and-workflow/-/issues/2test2024-01-18T13:22:04ZKat Pisaniectesthttps://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/17Transformed and original record have the same kind2024-02-21T15:28:43ZRucha DeshpandeTransformed and original record have the same kindIssue noticed by Abdul Rasheed Nagoor Gani and me as well while testing:
(Possible bug with Storage service)
Steps to reproduce:
Step “1- Create Base Record” created record opendes:master-data--SeismicAcquisitionSurvey:999290296326 wit...Issue noticed by Abdul Rasheed Nagoor Gani and me as well while testing:
(Possible bug with Storage service)
Steps to reproduce:
Step “1- Create Base Record” created record opendes:master-data--SeismicAcquisitionSurvey:999290296326 with "kind": "osdu:wks:master-data--SeismicAcquisitionSurvey:1.0.0" and version 1693419225871510
Step “3- Upgrade Schema” created new version 1693419285078323
Step “6- Get Specific Record Version” both the versions returns kind as "kind": "osdu:wks:master-data--SeismicAcquisitionSurvey:1.1.0"
Expected result:
Version 1693419225871510: "kind": "osdu:wks:master-data--SeismicAcquisitionSurvey:1.0.0"
Version 1693419285078323: "kind": "osdu:wks:master-data--SeismicAcquisitionSurvey:1.1.0"Vikas Hoode [BP]vikas.hoode@bp.comVikas Hoode [BP]vikas.hoode@bp.comhttps://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/16/refvalupgrade is not idempotent2024-01-17T17:55:35ZRucha Deshpande/refvalupgrade is not idempotentSteps to Reproduce:
1. Send an /refvalupgrade request without the acl and legal tags in the request
1. Storage record is transformed and stored but Acitvityrecord creation fails
1. Fix the request by adding acl and legal tags for the sa...Steps to Reproduce:
1. Send an /refvalupgrade request without the acl and legal tags in the request
1. Storage record is transformed and stored but Acitvityrecord creation fails
1. Fix the request by adding acl and legal tags for the same record. Transformation fails
You need to delete the record created in step 2, and then repeat the process, which then works. Some validation and error handling is required here.https://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/15/upgrade API does not return a ActivityRecord ID to be used for the /rollback...2024-01-17T17:54:12ZRucha Deshpande/upgrade API does not return a ActivityRecord ID to be used for the /rollback request/upgrade API does not return a ActivityRecord ID to be used for the /rollback request
There is no way to know what rollback Id should be used./upgrade API does not return a ActivityRecord ID to be used for the /rollback request
There is no way to know what rollback Id should be used.https://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/13No authorization annotations on the APIs2024-01-17T17:52:00ZRucha DeshpandeNo authorization annotations on the APIsWho is allowed to call these APIs?
Authorization policy to be determined and implementedWho is allowed to call these APIs?
Authorization policy to be determined and implementedhttps://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/12If no Id is given in the upgradeRequest, it searches for records but limits r...2024-01-17T17:50:34ZRucha DeshpandeIf no Id is given in the upgradeRequest, it searches for records but limits response to ‘2’.If no Id is given in the upgradeRequest, it searches for records but limits response to ‘2’. Pagination needs to be implemented to support possibly 10s and 1000s of records as a result of searching a kind.If no Id is given in the upgradeRequest, it searches for records but limits response to ‘2’. Pagination needs to be implemented to support possibly 10s and 1000s of records as a result of searching a kind.https://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/11/upgrade is not idempotent2024-01-17T17:49:09ZRucha Deshpande/upgrade is not idempotentSteps to Reproduce:
1. Send an /upgrade request without the acl and legal tags in the request
2. Storage record is transformed and stored but Acitvityrecord creation fails
3. Fix the request by adding acl and legal tags for the same reco...Steps to Reproduce:
1. Send an /upgrade request without the acl and legal tags in the request
2. Storage record is transformed and stored but Acitvityrecord creation fails
3. Fix the request by adding acl and legal tags for the same record. Transformation fails
You need to delete the record created in step 2, and then repeat the process, which then works.
Some validation and error handling is required here.https://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/10Add API request validations for acl and legal tags2024-01-17T17:45:49ZRucha DeshpandeAdd API request validations for acl and legal tagsWhile testing the /upgrade API,
ActivityRecord failed creation since the upgradeRequest expects and acl and legal tags as part of the /upgrade request.
This is missing in the openapi spec.
Missing validation of the requestWhile testing the /upgrade API,
ActivityRecord failed creation since the upgradeRequest expects and acl and legal tags as part of the /upgrade request.
This is missing in the openapi spec.
Missing validation of the requesthttps://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/9Build failure with com.fasterxml.jackson.core.jackson-databind dependency ver...2024-01-17T17:43:52ZRucha DeshpandeBuild failure with com.fasterxml.jackson.core.jackson-databind dependency version 2.15.02. com.fasterxml.jackson.core.jackson-databind 2.15.0 did not work with error:
java.lang.NoSuchFieldError: READ_UNKNOWN_ENUM_VALUES_USING_DEFAULT_VALUE] with root cause
java.lang.NoSuchFieldError: READ_UNKNOWN_ENUM_VALUES_USING_DEFAULT_V...2. com.fasterxml.jackson.core.jackson-databind 2.15.0 did not work with error:
java.lang.NoSuchFieldError: READ_UNKNOWN_ENUM_VALUES_USING_DEFAULT_VALUE] with root cause
java.lang.NoSuchFieldError: READ_UNKNOWN_ENUM_VALUES_USING_DEFAULT_VALUE
at com.fasterxml.jackson.databind.deser.std.EnumDeserializer.createContextual(EnumDeserializer.java:211)
Downgrading to 2.14.0 workshttps://community.opengroup.org/osdu/platform/system/reference/schema-upgrade/-/issues/8Update service code to use search and storage service BASE URLS instead of en...2024-01-17T17:42:39ZRucha DeshpandeUpdate service code to use search and storage service BASE URLS instead of endpointsUpdate service code to use search and service BASE URLS instead of endpointsUpdate service code to use search and service BASE URLS instead of endpointshttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/issues/161[ADR] Auto removal of Groups from all storage ACL List once associated ACL gr...2024-02-07T06:36:49ZOm Prakash Gupta[ADR] Auto removal of Groups from all storage ACL List once associated ACL group is deleted from entitlement sevice## Status
* [x] Proposed
* [ ] Trialing
* [ ] Under review
* [ ] Approved
* [ ] Retired
**Context & Scope**
This ADR is about the auto removal of groups from the storage record ACL list when the associated group is deleted from entitl...## Status
* [x] Proposed
* [ ] Trialing
* [ ] Under review
* [ ] Approved
* [ ] Retired
**Context & Scope**
This ADR is about the auto removal of groups from the storage record ACL list when the associated group is deleted from entitlement.
**Current Behavior**
- Currently, its possible to delete a group using entitlement delete API without validation of group association with any storage records ACL association.
- Once the group is deleted then the group associated with storage records under the ACL list is not removed.
- Deleted groups still exist under the storage record ACL list which is not in existence though Access to the record fails as a group is not present in entitlement.
**Proposed Requirements**
Delete Groups API should:
- Not delete the Group if there are records that have Single OWNER as the Group being deleted. This is handled via #141.
- When it will not leave any record in inaccessible state, the group can be deleted. Once the group is deleted from the entitlement service, it shall be automatically removed from the storage record acl list.
- As this operation is a costly affair to go through each record and delete the associated group from acl list it can be done asynchronously.
- Entitlement service can notify about the group deleted and subscribers can asynchronously take care of clean ups.
**Trade-off Analysis**
These clean-ups are necessary to stop having records with unnecessary groups having either owner or viewer rights to a storage record.
**Challenges**
- Cleaning up the ACL list from each record might take significant time and resources but can be handled asynchronously.Deepa KumariOm Prakash GuptaDeepa Kumarihttps://community.opengroup.org/osdu/platform/data-flow/ingestion/external-data-sources/core-external-data-workflow/-/issues/57Support for multiple security schemes2024-01-16T23:37:45ZBen GreerSupport for multiple security schemesConnectedSourceDataJobs should be able to use multiple security schemes for each service (Search, Dataset).
- ConnectedSourceRegistryEntry schema has SecuritySchemes named plural and as a list type.
- In ConnectedSourceDataJob schema th...ConnectedSourceDataJobs should be able to use multiple security schemes for each service (Search, Dataset).
- ConnectedSourceRegistryEntry schema has SecuritySchemes named plural and as a list type.
- In ConnectedSourceDataJob schema there is a field for data.Workflows[].SecuritySchemeName
- - described as the "Reference name for the security scheme in the ConnectedSourceRegistryEntry document this scheduled job belongs to".
- data.Workflows[] field is deprecated with a note that is has been "Superseded by the contents of appropriate parameters in an ActivityTemplate instance".
- CSDJ Activity Template I does not have any parameters for Workflow Security Scheme Names.
Somewhere during deprecation of the data.Workflows[] field the ability to reference the security scheme by name in the CSDJ appears to have been lost.
The EDS implementation currently is hardcoded to use the first security scheme defined in the CSRE.Ashish SaxenaAshish Saxenahttps://community.opengroup.org/osdu/data/open-test-data/-/issues/96Fix TNO/Volve CRS reference data2024-02-19T20:09:46ZBert KampesFix TNO/Volve CRS reference dataTNO/Volve test data repo contains 3 reference data manifests that are not desired because they do not follow the standard record id agreement. Additionally they are not BoundCRSs and use schema version 1.0.0 and not 1.1.0. Meanwhile OSDU...TNO/Volve test data repo contains 3 reference data manifests that are not desired because they do not follow the standard record id agreement. Additionally they are not BoundCRSs and use schema version 1.0.0 and not 1.1.0. Meanwhile OSDU comes "out of the box" with distributed set of standard CRSs. The objective of this issue is to
- [ ] Replace any CRS id referenced in the (thousands of) Well and Wellbore TNO/Volve to use the standard "out of the box" CRSs (per table below).
- [ ] Remove the local CRS reference data manifests in the TNO/Volve repo because they won't be needed anymore (i.e., the Well and Wellbore manifest will point to the OSDU distributed CRSs).
The OSDU CRS record id standard is described at:https://gitlab.opengroup.org/osdu/subcommittees/data-def/work-products/schema/-/blob/master/Guides/Chapters/04-FrameOfReference.md?ref_type=heads#4331-record-id-dataid-for-coordinatereferencesystem
The standard CRS reference data included with a OSDU distribution are contained in file CRS_CT.json at https://gitlab.opengroup.org/osdu/subcommittees/data-def/work-products/schema/-/blob/master/ReferenceValues/Manifests/reference-data/LOCAL/CRS_CT.json?ref_type=heads
**Detailed analysis:**
There are 3 files with local reference data: The letters A,B,C are referenced in the below table.
* A) https://community.opengroup.org/osdu/platform/data-flow/data-loading/open-test-data/-/blob/master/rc--3.0.0/4-instances/Volve/reference-data/volve_ref_CoordinateReferenceSystem.1.0.0.json
* B) https://community.opengroup.org/osdu/platform/data-flow/data-loading/open-test-data/-/blob/master/rc--3.0.0/4-instances/Volve/reference-data/load_refCoordinateReferenceSystem.OPEN.json
* C) https://community.opengroup.org/osdu/platform/data-flow/data-loading/open-test-data/-/blob/master/rc--3.0.0/4-instances/TNO/reference-data/load_refCoordinateReferenceSystem.OPEN.json
<table>
<tr>
<th>
</th>
<th>
**_Volve/TNO 1.0.0 bogus string (record id)_**
</th>
<th>
**_Count in TNO/Volve manifests_**
</th>
<th>Replace in (Well and Wellbore) data manifests with proper record id</th>
<th>
**_Comment_**
</th>
</tr>
<tr>
<td>A,C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:23031</td>
<td>12000+</td>
<td>osdu:reference-data--CoordinateReferenceSystem:BoundProjected:EPSG::23031_EPSG::1311</td>
<td>
_23031 is ED50/UTM31N; We should confirm where the data is. Namely 1311 is valid in specific area and if this would be northern Norway it would not be correct._
_See below 23031024 is a different CT valid in Norway. I assumed the TNO data is in North Sea near Netherlands._
_Note: 23031 is a normal CRS, not BoundCRS. But in OSDU the standard is to use BoundCRS to ingest data, so we best fix the test data and assign a BoundCRS to the original coordinates. The normalizer on ingest is then able to compute the WGS 84 coordinates. (and WGS 84 should not be in the input manifest ingested)._
_We can confirm the CT by checking the WGS 84 coordinates._
</td>
</tr>
<tr>
<td>A</td>
<td>osdu:reference-data--CoordinateReferenceSystem:4230</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:BoundGeographic2D:EPSG::4230_EPSG::1311</td>
<td>4230 is ED50, base of above. Bound the same to CT 1311 (common offshore in North Sea)</td>
</tr>
<tr>
<td>A</td>
<td>osdu:reference-data--CoordinateReferenceSystem:4979</td>
<td>0 (confirmed)</td>
<td>osdu:reference-data--CoordinateReferenceSystem:Geographic2D:EPSG::4979</td>
<td>
_WGS 84 3D. Cannot be used by data. (I cannot believe that; it should only referenced in 4326). We should be OK to simply delete it from Volve reference data._
</td>
</tr>
<tr>
<td>A</td>
<td>osdu:reference-data--CoordinateReferenceSystem:4978</td>
<td>0 (confirmed)</td>
<td>osdu:reference-data--CoordinateReferenceSystem:Geographic2D:EPSG::4978</td>
<td>
_WGS 84 Geocentric. Cannot be used by data. (I cannot believe that; it should only referenced in 4979). We should be OK to simply delete it from Volve reference data._
</td>
</tr>
<tr>
<td>A</td>
<td>osdu:reference-data--CoordinateReferenceSystem:4326</td>
<td>many</td>
<td>osdu:reference-data--CoordinateReferenceSystem:Geographic2D:EPSG::4326</td>
<td>
_WGS 84 2D. Not bound._
</td>
</tr>
<tr>
<td>B</td>
<td>osdu:reference-data--CoordinateReferenceSystem:WGS%2084</td>
<td>
0
(confirmed)
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:Geographic2D:EPSG::4326</td>
<td>
_Violates current OSDU record id standard (space not allowed). Since it is not used, we can simply delete it from the local reference data .json, or let the issue resolve itself when that file is deleted out of this repo. If used, replace it with 4326 same as above (WGS 84 2D)_
</td>
</tr>
<tr>
<td>B</td>
<td>osdu:reference-data--CoordinateReferenceSystem:23031024</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:BoundProjected:EPSG::23031_EPSG::1613</td>
<td>
_024 is the variant for CT EPSG::1613 which is valid in Norway offshore, South of 62N._
[_https://epsg.org/transformation_1613/ED50-to-WGS-84-24.html_](https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fepsg.org%2Ftransformation_1613%2FED50-to-WGS-84-24.html&data=05%7C02%7CBert.Kampes%40shell.com%7C9caf2a1428bd475aa64908dc16cde043%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0%7C0%7C638410320683982171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3KoFHFfz3bUZEaaadjaRe%2BB0m5xwvRq7IBNBGBBjkBQ%3D&reserved=0)
</td>
</tr>
<tr>
<td>B,C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:MSL</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:Vertical:EPSG::5714</td>
<td>
\_MSL height \_[_https://epsg.org/crs_5714/MSL-height.html_](https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fepsg.org%2Fcrs_5714%2FMSL-height.html&data=05%7C02%7CBert.Kampes%40shell.com%7C9caf2a1428bd475aa64908dc16cde043%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0%7C0%7C638410320683982171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bpZh4B%2B6Pwx6VNPvQ%2FLKirv9To%2B2uQC85H6uJqmUKXg%3D&reserved=0)
</td>
</tr>
<tr>
<td>C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:5709</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:Vertical:EPSG::5709</td>
<td>
_5709 is NAP height (Dutch onshore vertical)_
</td>
</tr>
<tr>
<td>C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:23095</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:BoundProjected:EPSG::23095_EPSG::1311</td>
<td>ED50 / TM 5 NE used in NLD with CT 1311 generally</td>
</tr>
<tr>
<td>C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:23032</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:BoundProjected:EPSG::23032_EPSG::1311</td>
<td>ED50/UTM32N. Several CTs used. 1311, 1133, 1612, 1613, 1627, 1631, 1810 depending on area.</td>
</tr>
<tr>
<td>C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:25831</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:BoundProjected:EPSG::25831_EPSG::1149</td>
<td>
ETRS89 / UTM zone 31N \[1149_25831\]
</td>
</tr>
<tr>
<td>C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:28992</td>
<td>
</td>
<td>osdu:reference-data--CoordinateReferenceSystem:BoundProjected:EPSG::28992_EPSG::1672</td>
<td>Amersfoort/RD New used in NLD with CT 1672</td>
</tr>
<tr>
<td>C</td>
<td>osdu:reference-data--CoordinateReferenceSystem:4230</td>
<td>
</td>
<td>See above – first check if there is data in TNO with 4230 or if this is just a dependency for defining ED50 / UTM (projected CRS which points to 4230 geographic). If 4230 is used in data records, then we need to use the same CT as used in the BoundProjected here for the BoundGeographic</td>
<td>
</td>
</tr>
</table>
**Example manifests for a Well and Wellbore (search e.g., for AsIngestedCoordinates in data SpatialLocation):**
* https://community.opengroup.org/osdu/platform/data-flow/data-loading/open-test-data/-/blob/master/rc--3.0.0/4-instances/Volve/master-data/Well/load_Well.1.0.0_15%252F9-F-14.json
* containing "CoordinateReferenceSystemID": "osdu:reference-data--CoordinateReferenceSystem:4326:"
* [https://community.opengroup.org/osdu/platform/data-flow/data-loading/open-test-data/-/blob/master/rc--3.0.0/4-instances/TNO/master-data/Wellbore/load_Wellbore.1.0.0_1000.json](https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.opengroup.org%2Fosdu%2Fplatform%2Fdata-flow%2Fdata-loading%2Fopen-test-data%2F-%2Fblob%2Fmaster%2Frc--3.0.0%2F4-instances%2FTNO%2Fmaster-data%2FWellbore%2Fload_Wellbore.1.0.0_1000.json&data=05%7C02%7CBert.Kampes%40shell.com%7C9caf2a1428bd475aa64908dc16cde043%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0%7C0%7C638410320683982171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AAmNQVW2gz6f3dv0NSJ%2B1VZJZf%2FvXdMxubidAACc7lI%3D&reserved=0)
* Containing: "CoordinateReferenceSystemID": "osdu:reference-data--CoordinateReferenceSystem:23031:", with a PR as well.Dadong ZhouChad LeongDadong Zhouhttps://community.opengroup.org/osdu/platform/pre-shipping/-/issues/659GCZ Azure M22 - Feature layers do not display on map service2024-01-16T09:51:36ZStefania Gerbaudo LarongaGCZ Azure M22 - Feature layers do not display on map serviceHello,
Seismic 3D Live traces do not display on the ArcGIS map service (url: https://osdu-gcz.msft-osdu-test.org/ignite-provider/rest/services/test/FeatureServer/7).
Regards,
Stefania Laronga
For info: @debasiscHello,
Seismic 3D Live traces do not display on the ArcGIS map service (url: https://osdu-gcz.msft-osdu-test.org/ignite-provider/rest/services/test/FeatureServer/7).
Regards,
Stefania Laronga
For info: @debasiscSrinivasan Narayananshivani karipesaketh somarajuSrinivasan Narayananhttps://community.opengroup.org/osdu/platform/pre-shipping/-/issues/658GCZ M22 Azure returns empty features2024-01-16T09:57:14ZStefania Gerbaudo LarongaGCZ M22 Azure returns empty featuresHello,
Well kind, wellbore kind, 3D polygons, seismic 2D lines do not return any feature [].
Only 3D live traces returns results from ingestion.
Regards,
Stefania
For info @debasiscHello,
Well kind, wellbore kind, 3D polygons, seismic 2D lines do not return any feature [].
Only 3D live traces returns results from ingestion.
Regards,
Stefania
For info @debasiscSrinivasan Narayananshivani karipesaketh somarajuSrinivasan Narayananhttps://community.opengroup.org/osdu/platform/deployment-and-operations/infra-gcp-provisioning/-/issues/30GB WhatsApp Pro2024-01-13T13:56:49ZGhost UserGB WhatsApp ProWhatsApp is a globally popular messaging app that revolutionized communication by offering free text, voice, and video messaging over the internet. Launched in 2009, it quickly gained widespread adoption due to its user-friendly interfac...WhatsApp is a globally popular messaging app that revolutionized communication by offering free text, voice, and video messaging over the internet. Launched in 2009, it quickly gained widespread adoption due to its user-friendly interface and cross-platform compatibility. WhatsApp allows users to send messages, share multimedia content, and make voice and video calls seamlessly. End-to-end encryption ensures privacy, assuring users that their conversations remain secure. Acquired by Facebook in 2014, [WhatsApp ](https://apkwa.net/gb-whatsapp-pro/)continues to evolve with features like status updates and business tools. With over two billion users worldwide, it has become an integral part of daily communication for individuals and businesses alike.https://community.opengroup.org/osdu/data/open-test-data/-/issues/94WorkProduct manifests generation fails while parsing LAS files2024-01-17T20:48:31ZZhubin SalehiWorkProduct manifests generation fails while parsing LAS filesParsing LAS file in well_logs and well_logs_1_1_0 directories for TNO fails with the following error log for each file:
```
2024-01-12 15:31:53 ERROR Unable to read laslog file: /home/zhubin/tno-wpc-datasets/well-logs/3938_del08_1994_co...Parsing LAS file in well_logs and well_logs_1_1_0 directories for TNO fails with the following error log for each file:
```
2024-01-12 15:31:53 ERROR Unable to read laslog file: /home/zhubin/tno-wpc-datasets/well-logs/3938_del08_1994_comp.las
Traceback (most recent call last):
File "/home/zhubin/.local/lib/python3.10/site-packages/lasio/las.py", line 176, in read
assert version in (1.2, 2, None)
AssertionError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/zhubin/open-test-data/rc--3.0.0/2-scripts/load_manifest_scripts/src/loading_manifest/osdu_laslog_manifest.py", line 405, in create_laslog_manifest_from_path
log_data = read_data_from_log_file(full_valid_file_path)
File "/home/zhubin/open-test-data/rc--3.0.0/2-scripts/load_manifest_scripts/src/loading_manifest/osdu_laslog_manifest.py", line 39, in read_data_from_log_file
las = lasio.read(fp)
File "/home/zhubin/.local/lib/python3.10/site-packages/lasio/__init__.py", line 41, in read
return LASFile(file_ref, **kwargs)
File "/home/zhubin/.local/lib/python3.10/site-packages/lasio/las.py", line 77, in __init__
self.read(file_ref, **read_kwargs)
File "/home/zhubin/.local/lib/python3.10/site-packages/lasio/las.py", line 178, in read
if version < 2:
TypeError: '<' not supported between instances of 'str' and 'int'
```
I tried different version of `lasio` in `open-test-data/rc--3.0.0/2-scripts/load_manifest_scripts/requirements.txt` file. Using version 0.30 resolved the issue.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/122V4 API and Postman Collection showcasing the steps/sequence2024-01-11T17:24:56ZDebasis ChatterjeeV4 API and Postman Collection showcasing the steps/sequenceWe started to look at the collection provided by AWS
https://community.opengroup.org/osdu/platform/pre-shipping/-/blob/main/R3-M22/AWS-M22/DDMS%20Seismic/AWS_OSDUR3M22_Seismic_v4_Automated.postman_collection.json
This was apparently cre...We started to look at the collection provided by AWS
https://community.opengroup.org/osdu/platform/pre-shipping/-/blob/main/R3-M22/AWS-M22/DDMS%20Seismic/AWS_OSDUR3M22_Seismic_v4_Automated.postman_collection.json
This was apparently created with initial example from Dev team (Seismic DDMS).
We are a little unclear about the logical sequence and naming of the folder/requests.
Folder "Schema" is really to create some catalog record (Dataset FileCollection.SegY).
Folder "Connection" is apparently to upload some data files". Should this not be before we can create Dataset record?
Something similar to what we see here, as the sequence of steps.
![image](/uploads/e1579cc87851b5e8995c0892dde824f7/image.png)
Is the need for sdutil completely eliminated? Earlier, we had to upload data file (SegY) by using sdutil to suitable tenant and sub-project.
Perhaps a **companion document** with the **Postman Collection** would help.
@chad earlier mentioned that the DEV team would probably provide a video showing the steps?
Thank you
cc @spoddar , @kimjiman and @ydzenghttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/rock-and-fluid-sample/rafs-ddms-services/-/issues/326Postman Collection - propose to move documentation to start of each folder (a...2024-01-11T16:00:57ZDebasis ChatterjeePostman Collection - propose to move documentation to start of each folder (analysis type)For RCA, this is where we have it today.
![image](/uploads/a07eb57a115ceeb5da67bf716633623a/image.png)
Propose that you move (or repeat) the information here too.
![image](/uploads/c8ed93945fc1df9541d01c287e7fdf95/image.png)
cc @bdawso...For RCA, this is where we have it today.
![image](/uploads/a07eb57a115ceeb5da67bf716633623a/image.png)
Propose that you move (or repeat) the information here too.
![image](/uploads/c8ed93945fc1df9541d01c287e7fdf95/image.png)
cc @bdawson , @Siarhei_Khaletski , @michael_jones_epam