forked from bcdev/beam
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO-4.10.txt
192 lines (176 loc) · 9.48 KB
/
TODO-4.10.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
Further development towards TrackPoints
=======================================
- Remove most calls to Placemark.createPointPlacemark():
* Many of those calls copy placemarks from one VDN to another, although this will
not be required anymore: we only need to copy VDN and their features. Then, placemarks
will be created accordingly. This basically already implemented in
ProductUtils.copyVectorData(source, target). Therefore we'll implement the capability
of a VDN to create corresponding Placemarks whenever features are added.
(Check: And vice versa?). Placemark collections will then stay in sync with feature
collection. Also this is already implemented in PlacemarkGroup.
* Analyse args of remaining calls: which are Pins, which GCPs, how general are these?
e.g.: PointPlacemarkDescriptor.createPointPlacemark(<point-args>)
* We don't store pins in DIMAP anymore, all placemarks will be stored in the same way.
- How will we import & export placemarks with respect to their underlying features.
Will we only export features? No, this way we won't get all associated (sample) data
for point placemarks.
- Action "Create new geometry container" --> "Create new feature collection" or
"vector data node", users should also select feature type. BUT where do feature types
come from? We have no registry. We have PlacemarkDescriptors. Shall users select
from registered PlacemarkDescriptors? Then these must provide (default / basis) feature
type. BUT then: How can they be responsible for (compatible with) more than one feature
type?
Possible idea: Every PlacemarkDescriptor produces a unique feature type and only features of
exactly this type. Users must make a choice, when multiple PlacemarkDescriptors match the
same feature type. This will happen when
1. importing data (e.g. shapefiles)
2. creating new vector data nodes (see "Create new geometry container")
We might need something like dynamic features that are created for point features
while bands are added or removed --> dynamic feature type (feature type extender, or
"runtime feature type")
- When copying VDNs --> rename ones with same name that exist before
- Remove ProductProjectionBuilder but usage in MosaicProcessor: is it still required?
- Remove all redundant calls to PinDescriptor.getInstance()
- Remove all redundant calls to GcpDescriptor.getInstance()
- Remove VectorDataGroupTN.mustCount(), because there is later no need to differentiate
- Ease access from Figure (selection) to specific Placemarks + Features
- InsertPlacemarkInteractor --> InsertPointPlacemarkInteractor
- Discuss following roles
* VectorDataNode:
+ feature type / placemark descriptor
+ collection of placemarks
* Placemark (VectorDataItem)
+ placemark descriptor
+ feature
Revise data import / export
- harmonise flat, plain text data table I/O
- exported pin files
- vector data node I/O
- pixel extraction, transect data extraction
- PixExOp
- PixBox
- Calvalus in-situ data / pixel extraction
- VISAT copy to clipboard actions
- text data table I/O shall be done using a transfer object that comprises a property map plus a feature collection
- feature type attribute naming: camel-case or underscore?
- format proposal:
feature-format := {<property-record> NL} <feature-type-record> {NL <feature-record>}
feature-type-record := {<feature-type-name>} {<sep> <attribute-header>}
feature-record := {<feature-id>} {<sep> <attribute-value>}
simple-format := {<property-record> NL} <header-record> {NL <data-record>}
header-record := <attribute-header> {<sep> <attribute-header>}
data-record := <attribute-value> {<sep> <attribute-value>}
attribute-header := <attribute-name> [<attribute-type-spec>]
attribute-type-spec := ':'<attribute-type>
property-record := '#'<property-name> '=' <property-value>
sep := TAB | [';' | ',', ...] (TBC)
Note that it is optional to provide a column for the feature id. If no such column is present, the features are
assigned ids in ascending order, starting from 0. If the first column shall be considered the feature id, it is
mandatory that it is named 'featureId'.
Special-meaning attribute names may be auto-detected by BEAM:
- lat, latitude
- lon, long, longitude
- time, date, date_time, dateTime
- station, easting, northing
Attribute format detection may apply if <attribute-type-spec> is missing
- number, date, time
Must specify which coordinate system using property 'crs=${some WKT}'
Date format is yyyy-MM-ddTHH:mm:ss per convention; may be extended to allow specifying arbitrary date formats (see
PixEx)
Metadata treatment: Each property is considered metadata and treated accordingly.
Non-numerical attributes within the feature type record are considered metadata, too.
MetadataRoot
|
+-+- Property-Metadata
| |
| +- each Property / Value
|
+- Record Metadata
|
+- each Attribute a_i in feature type with not-numerical DataType
|
+- featureId_0
| |
| +- attr_0 / value
| |
| +- attr_1 / value
| |
| .
| .
| .
|
+- featureId_1
| |
| +- attr_0 / value
| |
| +- attr_1 / value
| |
. .
. .
. .
- Revise Spectrum view
- use JFreeChart
- lines are too thin!
- fixed axis ranges!!!
- Revise profile plot with respect to reference data
- shall operate on selected vector data nodes
- if VDN contains points geometry types:
- points are vertexes
- each point may provide reference data (feature attributes)
- the GUI lets the user select an attribute to be displayed
- color used is the point color (pin)
- if VDN contains shapes
- for each shape a profile is drawn using the shape's color
- the selected shape may be also hi-lighted in the chart
- option to only display selected shape
- possibly visualise time difference (separate plot)
- optionally hide points with to large time delta
- revise scatter plot with respect to reference data
- extend existing or create a 2nd scatter plot panel for in-situ data comparisons
- allow to select vector data nodes containing point data as 2nd variable (feature attribute name)
In this case, data pairs are generated by reading pixel data at each given point and its attribute value
- display statistics
- allow for macro pixels (see Calvalus match-up scenario)
- possibly visualise time difference
- optionally hide points with to large time delta
- Revise PixExOp according to following use cases
- It shall be possible to import coordinates in two different ways:
- Import coordinates only (without time information)
This is needed if a pixel extraction for all input products is needed, not only for products
which matches the time.
The Name inside the Popup Menu should be "Load Coordinates"
In this case the import file must have a "name", "station" or "label" column.
All the coordinates with the same name are interpreted as one coordinate.
If the coordinates with one name are slightly different the first coordinate will be imported.
- Import coordinates and Time
already implemented!
The Name inside the Popup Menu should be changed to "Load coordinates and time"
- It should be possible to define a filename pattern for date extraction
- There should be a text input field to define a date pattern
e.g. yyyyMMdd 20120524 -> 24.5.2012
- There should be a text input field to define filename pattern
e.g. *${date}_????????_${date}_????????_*.dim
LL_K2PIS_20120524_13692749_bas_20120601_21875615_rim_dum.dim
--> Start Time = 24.5.2012
--> Stop Time = 1.6.2012
- It should be possible to define different output formats
- Default output format ---> is a valid CALVALUS import file
- ODESA output format ---> there are scripts existing in AR which can be translated to Java which defines
exactly the needs for a valid ODESA import file.
For ODESA there should be exported two files.
One with all the exported data
One with aggregated data like mean, median, standard deviation, ...
- user defined Export
- one column time export
there should be a text field to define a date/time output pattern
- two columns time export
there should be two text fields
the first one is for the date pattern
the second one is for the time pattern
- in the case of two columns export it should be able to define a time fill value
"noTime", "00:00", ...
- in all this cases, it should be possible to pick from predefined date or time patterns
- in the case, that a user defined export is not selected, all the fields should
be visible but not enabled. Inside the fields, the defined export format (default
od ODESA) should be visible.
- NavigationPanel shall allow linking by geo-coordinates