Hello Siddhesh
Thanks for the detailed report.
On metadata being large:
Le 11/07/2017 à 19:37, Siddhesh Rane a écrit :
> 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.
Indeed. This complexity is the reason why I proposed simplified (flat)
views together with the complete tree view. Simplified views can been
seen as "profile", and different domains (oceanography, transportation,
health, etc.) will want different profiles. So ideally profiles should
be customizable (but it is okay if we can't do customization in this GSoC).
> There are therefore few types which can have custom widgets, with some having
> widgets customized for only a set of attributes (like in Identifier).
I like the proposal seen in Identifier-mock.png. The
VerticalExtent-mock.png proposal is also both simple and efficient. It
should be possible to do something similar for TemporalExtent. For
GeographicExtent, putting the 4 numerical fields in a "+" shape (North
on top, South on bottom, West on left and East on right) could work,
optionally with a button showing the area on a map in a separated panel.
Other possible widgets are:
* OnlineResource: the "linkage" property could be hidden and used for
making the "name" property value a clickable hyper-link.
* BrowseGraphic: the image given by the URI could be shown.
* Party, Contact & Address: could we have a form like the one in
contact book? (e.g. like in Thunderbird)
* Telephone: could be similar to CitationDate-mock.png.
* SampleDimension: minimum, maximum and units of measurement could be
show together. Mean and standard deviation too. Scale factor, offset
and transfer function type could also be together.
* Band: boundMin, boundMax, peakResponse and boundUnits could also be
show together.
I think we can find more, this is just a few examples. But no worry, it
is normal to not be familiar with all those metadata details.
> 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.
Fine, lets begin like that. But I think it would be nice if we have
specialized widgets over relatively large metadata elements like
"Address", taking inspiration from the layout found in existing software.
> 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.
Looks good.
> 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.
Avoiding dependencies is not a strong requirement, especially for
prototype. Keeping the amount of dependencies low is nice (when we can)
not only for reducing size, but also for reducing version conflicts when
using Apache SIS together with other projects having similar
dependencies (e.g. some libraries like http-common are used by many
projects, so version conflicts happen often with them). But this is not
mandatory.
If you can keep the use of external dependencies isolated in a few
separated classes, that would be helpful. For example it would allow us
to make those dependencies optional, as we did for some other Apache SIS
modules (e.g. EPSG geodetic database, while strongly recommended, is
nevertheless optional).
> So are we limited to just rectangular bounds?
Not exactly. SIS is designed for working with either the Java Topology
Suite (JTS), the ESRI geometry library or the Java2D shapes, at user
choice. All those libraries allow complex shapes. But we are not yet
doing anything with those shapes. We are not yet using them for
filtering data in queries, for specifying a region on which to compute a
process, etc. So in current SIS state, it is not clear to me for which
purpose a user would want to draw polygons on a map.
The situation is different for metadata edition, since the user could
export them in ISO 19139 for use by other software.
> (…) 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?
I think this is sufficient. In long term, instead than using Google Map,
we would like to port a rendering engine with styling capabilities, but
this is out-of-scope of this GSoC.
Martin
