Hello all, At this stage we have a tree table view of the data, which although presents full information is cumbersome to view. I proposed creating custom widgets to reduce unnecessary rows and to create more intuitive visualizations. However I found this works only for a few types, which have been listed here (https://github.com/SiddheshRane/sis-client/wiki/List-of-Widgets). The TreeTable was being generated using ValueExistencePolicy.COMPACT, which showed only the attributes that were present in the metadata file. This gave me a false impression of most data being small and simple, which could be clubbed together in smaller space. But the full set of attributes are available with ValueExistencePolicy.ALL. This showed me that many seemingly simple types are actually much bigger and complex.
Following are some reasons * Many types have a huge list of attributes, such as Citation, even if only a few may be present in the actual file. * Most data types have collections of attributes. Such as DefaultResponsibility parties and extents. * Some types have a few attributes but one or more of those attributes are complex. e.g. Identifier contains mostly simple strings but also Citation, which is pretty big. * Some types have an attribute whose data type is not statically known. e.g. DefaultResponsibility contains Party, which can be Individual, Organization etc. For each type the UI would be different. There are therefore few types which can have custom widgets, with some having widgets customized for only a set of attributes (like in Identifier). Martin wants an overview page showing only the most important information, and a tree table when more details are required. But we can adjust the tree table to do that. Here's how * For the types that have a custom widget, the widget will be used. No subchildren will be created. * For the types that have a widget for only some attributes, the widget will be displayed at the root, and other attributes will be added as subchildren. * TreeTableView supports sorting, we can set a sort policy for showing more important items above the less important * We can apply a filter that will show only the nodes that we consider important. Search field is also a type of filter. * Some nodes have a chain of single children, like a folder containing a single folder and so on. We can compress all those into one row and show only the end children, like what Github does. If there is a single child, show it directly at the root. Using schemes of sorting, filtering and other smart optimizations we can use the same TreeTableView to give an overview at first sight. sorting and filtering information can be saved in preferences files. We can create multiple preferences, and choose whichever is more applicable, depending on file type or other criteria at user discretion. The tree table view is more powerful when it comes to editing. When you enter edit state the particular node can be expanded to provide full set of supported attributes (ValueExistencePolicy.ALL) and the user can enter data and applicable fields. Once committed, the view will change back to read mode. This is for complex types. For simple types that use check boxes, date pickers, combo boxes and text fields you can directly interact with them. I'm making changes to the tree node generation code so that all these new requirements can be incorporated. July 11, 2017 4:38 AM, "Martin Desruisseaux" <[email protected]> wrote: > I presume that the 'GeographicExtent' and 'VerticalExtent-mock' images are > proposal for those two kinds of node under the > 'metadata/extent/geographicElement' node, is that right? Isn't the > 'GeographicExtent' proposal too big for fitting in a tree, or do you > plan to show it in a separated panel? Yes they are meant for that. The TreeTableView cells have a display state and an editing state. In the display state only a small scaled down thumbnail image of the extent will be shown. In the editing state, i.e. when you click on the thumbnail it will open the full size GeographicExtent viewer in a separate panel where you can edit it further using crude dragging as well as fine tuned lat/long entry in text boxes. One thing that prevented me from pushing those changes is that I have made this component using SnapshotView and RangeSlider from ControlsFX. These have made it really simple to prototype. And for bindings I have used ReactFX, without which the binding code would be made of many event listeners and too many if-else making it harder to understand the intent of the code. Is it really necessary that we do not use these libraries? They do make prototyping easier. And since this is a desktop app binary size wouldn't be that much of a problem. And these are well maintained libraries. > The 'map-polylines' and 'map-shapes-and-markers' screenshots are about > selecting an area over the map, but I'm not sure what you plan to do > with those polygons since SIS does not yet have much code for doing > processing with them? Since SIS in its current state is more advanced on > metadata and referencing aspects, I would suggest to focus on them. Those were there from the beginning when I added Google maps. At that point I didn't know what all SIS could do so I just kept general purpose shapes ready. So are we limited to just rectangular bounds? One reason I thought of Google maps was correctness of lat/long when I click at a point or draw a rectangle. Another being that you can zoom into smaller patches of land that wouldnt be visible in the world map. But in most EPSG CRS definitions that I saw the range of geographic extent is comparable to the size of a country, which is well visible it the world map. This is why GeographicExtent uses a png image for world map background. Is this sufficient, or do we ever have to deal with extremely small geographic extents that would require zooming into a proper map? The SnapshotView can be easily pasted on top of Google maps to get that kind of functionality. Regards Siddhesh Rane
