Opened 2 years ago

Closed 3 weeks ago

#1029 closed enhancement (fixed)

wcst_import: more meaningful type names

Reported by: bphamhuu Owned by: bphamhuu
Priority: minor Milestone: 9.5
Component: petascope Version: development
Keywords: wcst_import Cc: dmisev, vmerticariu
Complexity: Medium

Description

It looks like when import data with wcst-import (base/mdd/set) type is using an encrypted to make random string like

set

typedef set <zhyZwfhgLBcsyppsRoaCVfuhOknmcz> PJJPOvMITBaqExHqukFxHsdUXMXNZr;
typedef set <nQwXcEnmcTavrohjjnDjPHBiaZkHEi> PIdZXPOnBZTrUbnkSfjnYNrfGawnIv;
typedef set <RlNDbCvZiRvONsXGzpoFZiTPGzLoRG> RwpTfQMnNWVEIqgpgxyYZZtCaciNuG;

mdd

typedef marray <struct { short VHCYPEbfqIrhzCXzvlyImpUOOMJQwe, short NRHjCIZDseunvLNCkhzhruSaudsDpx, short lUpQFtfuQWbcQaOOfjeqJCnSHulrJF, short wKcWEEHKLiZYGyzYrJBlFySgwXUUjd, short wmyWVhbAlPnGITJUmaRKXOgNjIpgBO, short qYjkYPxaUQiKzphdXLKofVyWaQSDCV }, 2> zhyZwfhgLBcsyppsRoaCVfuhOknmcz;

and base

typedef struct { char OHMtfojPLTkGeumJNJlpeIkHNATlhI, char COibkSRwNrTChpxJTjbpRKMztkjgEK, char sDmhvgGbMtanbLApupZFoBUoafoapG } zVQjPHtQWdPIIwEmLuXLCSxiyelmzm;

I think this is very hard to manage definition data in RASDAMAN if user have to deal which this kind of naming convention. I would like to also propose that we should not do this (anyway from my point so you can have another idea).

If I could have a chance to change, I would like based on "coverage_id" in recipe to create the name of "base/mdd/type". Suppose I import data with wcst-import with "coverage_id": "Landsat8-Band1-3" and what I want to see when using rasdl --print is

typedef struct { char a, char b, char c} Lansat8-Band1-3_base  # I have no idea why not just use character from a, b, c... or a1 .... a10000 instead of random string like current imported data.

or

typedef marrray<struct {char a1, char a2, char a3}, 2>Landsat8-Band1-3_mdd

and

typedef <Landsat8-Band1-3_mdd>Landsat8-Band1-3_set

I think it is very helpful if it could like my example.

Thanks,

PS: As Dimitar mentioned 'We can always append some random bits in case there's a type name clash'. May I know which case Rasdaman will allow to add the base/mdd/type that is existed in RASBASE? (From my view this is an error).

Here is my example

Reading rasdaman data definition file /home/rasdaman/rasdl.type...inserting symbols into database...EDL003 rasdaman error: 905: Evaluation error 905 in line 2, column 1, near token abcPixel: Struct type name exists already.
rasdl done

and if using wcst_import with the same "coverage_id" then it will have an error when 2 different coverages using same "coverage_id" but has different structures (for example: 1 is GreySet?, 1 is RGBSet). If it is the same structure then it should be update to the "coverage_id".

Change History (14)

comment:1 Changed 23 months ago by dmisev

  • Owner changed from mdumitru to vmerticariu
  • Status changed from new to assigned

I think this is a petascope WCS-T ticket.

comment:2 Changed 21 months ago by dmisev

  • Owner changed from vmerticariu to bphamhuu

comment:3 Changed 21 months ago by dmisev

This is very similar to #1055, they can be done together.

comment:4 Changed 21 months ago by dmisev

  • Resolution set to wontfix
  • Status changed from assigned to closed

comment:5 Changed 17 months ago by dmisev

  • Resolution wontfix deleted
  • Status changed from closed to reopened

This has not been fixed as far as I can see, we still have random types. This is especially a problem with band names when using rasql fragments in WMS 1.3, the wcst_import band names do not match the rasql ones and it's necessary to use indexes in the query (or random band names).

comment:6 Changed 17 months ago by mdumitru

I guess only the struct type names are important in this case. Maybe we can just name them the same as the bands? It would be a bit confusing though as for existing types the rule would not be followed anymore, so maybe a new type for each coverage might be best.

Vlad what do you think?

comment:7 Changed 17 months ago by vmerticariu

It seems ok for the type name to be given by the band names. In case of conflicts, I guess we can add some suffix.

comment:8 Changed 17 months ago by dmisev

I don't expect any conflict in the band names case. It's sufficient if newly imported coverages follow this in my opinion, I wouldn't bother updating the types of existing ones.

comment:9 Changed 4 months ago by dmisev

  • Milestone changed from 9.1.x to 9.4

comment:10 Changed 7 weeks ago by bphamhuu

  • Cc mdumitru removed
  • Milestone changed from 9.4 to Future
  • Owner bphamhuu deleted
  • Status changed from reopened to assigned

comment:11 Changed 7 weeks ago by dmisev

  • Milestone changed from Future to 9.5

comment:12 Changed 4 weeks ago by dmisev

  • Owner set to bphamhuu

comment:13 Changed 4 weeks ago by dmisev

I'd suggest for set/array/struct cell types:

  • CovID_Set
  • CovID_Array
  • CovID_Cell

For the bands, by default we can name them band1, band2, band3, ..

comment:14 Changed 3 weeks ago by bphamhuu

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.