get_timeseries "normalize" parameter
"if set to True, the function will return a normalized data frame with the following columns 'Date','Security','Field'"
With 1 RIC in the query the result looks like described in the doc:
The table with the headers: TIMESTAMP, STRING, STRING.
However, when I use 2 RICs in the query, dataFrame["Date"] or dataFrame["Security"] returns a series, but not a single element.
for row in range(0, len(dataFrame)):
ric = dataFrame["Security"][row]
date = dataFrame["Date"][row]
field = dataFrame["Field"][row]
value = dataFrame["Value"][row]
This code works fine when there is only 1 ric in the request/result. And it does not for multiply rics.
Isn't "normalize=true" supposed to convert it to the same structure for all possible results?
Best Answer
-
Thanks for reporting this. I see the inconsistency as you described it. It's easy enough to work around of course, but I guess what you're looking for is to future proof you code and I'm not sure what to recommend here. I cannot be certain at this point, but I don't think there would be much appetite to address this issue in the Python library for Eikon 4. So, if you implement the workaround of handling single RIC case separately from multiple RICs case, it's very likely to be future proof for Eikon 4. And for Eikon 5 I anticipate breaking changes I cannot fully predict yet. In Eikon 5 get_timeseries method will likely retrieve timeseries from a different Web service, which will provide richer timeseries datasets.
Personally I don't use the normalize option. I don't think it presents the data in a more usable form than the non normalized dataframe. In my opinion, if you're looking to traverse the timeseries you retrieve, your best choice is to use normalize=False and an explicitly defined list of fields (as opposed to omitting the fields parameter and retrieving all fields available for a RIC). I think this way you get the most predictability regarding the structure of the dataframe returned.0
Answers
-
@Alex Putkov. all your assumptions are correct. I thought it would be easier to convert the result from 1 'normalized' data structure than from 2 or 3, that's why I tried "normalize=True". And yes, I found a solution.
So I just wanted to report this issue.
Thanks
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 370 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛