You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2017/07/10 22:59:31 UTC
JavaFX application progress
Hello Siddhesh
I saw that you committed screenshots [1] on July 6th, thanks. 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?
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.
Could you share a link to the github wiki page proposed last week (with
a list of widgets)?
Martin
[1] https://github.com/SiddheshRane/sis-client/tree/master/screenshots
Re: JavaFX application progress
Posted by Siddhesh Rane <si...@disroot.org>.
Hello Martin,
I have added a fxml mock "Feature Editor" for gpx files. Please have a look at it and comment.
August 8, 2017 4:29 AM, "Martin Desruisseaux" <ma...@geomatys.com> wrote:
> Le 07/08/2017 à 18:24, Siddhesh Rane a écrit :
>
> I understand that tabs may be more convenient during development, but at
> least the first tab about Apache SIS configuration should move in an
> "About Apache SIS" menu item.
I have moved it to the About menu.
> As a side note, the current widget leaves the "semi-major" and
> "semi-minor" fields to zero. Those values can be fetched by
> Datum.getEllipsoid().getSemiMajor() and ...getSemiMinor().
I am already using that. Some CRS at the beginning like EPSG:2000 don't seem to have datum definitions. Try EPSG:4244 Kandawala, ellipsoid information loads for that one.
As a side note, I am currently setting SIS_DATA environment variable to point to a local installation on my hard disk. I tried adding sis-epsg maven module as a runtime dependency but it seems sis doesnt pick it up. There is warning about missing SIS_DATA variable and the factory being used is EPSGFactoryFallback. Am I missing something here?
> For the prime meridian, we should show the "Greenwich longitude"
> somewhere, maybe just on the right side of "Prime Meridian" combo box.
Done
Regards
Siddhesh
Re: JavaFX application progress - Final report
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
The link gives a good description of your work - I think it is fit the
Google's requirements. I would suggest to add a section about how this
work would be integrated in Apache SIS. The current plan is to integrate
in the JDK9 branch (because Jigsaw modularisation makes the use of
JavaFX a little bit easier). Code would be integrated piece by piece by
trying to complete some parts in the process.
Martin
Le 28/08/2017 à 19:33, Siddhesh Rane a écrit :
> I have prepared a final report for the work done during this GSoC
> according to Google's work product submission guidelines. Report is
> available in the README at https://github.com/SiddheshRane/sis-client.
> It documents the functionality implemented so far with screenshots
> acting like user manual. Mentors are requested to suggest any changes
> before the final submission tomorrow.
>
Re: JavaFX application progress - Final report
Posted by Siddhesh Rane <si...@disroot.org>.
Hello all,
I have prepared a final report for the work done during this GSoC according to Google's work product submission guidelines. Report is available in the README at https://github.com/SiddheshRane/sis-client. It documents the functionality implemented so far with screenshots acting like user manual.
Mentors are requested to suggest any changes before the final submission tomorrow.
Regards
Siddhesh Rane
Re: JavaFX application progress
Posted by Siddhesh Rane <si...@disroot.org>.
Hello Martin,
---- Martin Desruisseaux wrote ----
> The changes that you did looks good. I noticed a little oddity, the
> geographic bounding box in the metadata tab had a North and East value
> but no South and West value (at least on the NetCDF file I used for the
> test).
In the latest commit I have fixed this problem along with a detailed commit message explaining it's cause. I have also removed unused dependencies from pom.
> > dm = new DefaultMetadata(datastore.getMetadata() )
> >
> > dm.isModifiable() returns true, but the actual setvalue operation
> > throws an error.
> >
> Can you send me the stack trace?
I have attached the stack trace. The mailing list will remove attachments so check the direct message that you have received from me.
I'm preparing a report for work product submission according to gsoc guidelines. It will replace the README file at my repo. It needs to be approved by the mentor. I'll let you know know when that is done. Till then you can tell me anything you want included in that.
Regards
Siddhesh Rane
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
The changes that you did looks good. I noticed a little oddity, the
geographic bounding box in the metadata tab had a North and East value
but no South and West value (at least on the NetCDF file I used for the
test).
Le 20/08/2017 à 21:34, Siddhesh Rane a écrit :
> The metadata cells will use Node.setValue() for updating changes. The
> underlying treetable gives unsupported operation exception. I tried
>
> dm = new DefaultMetadata(datastore.getMetadata() )
>
> dm.isModifiable() returns true, but the actual setvalue operation
> throws an error.
>
Can you send me the stack trace?
Martin
Re: JavaFX application progress
Posted by Siddhesh Rane <Si...@disroot.org>.
A quick update
Home tab has been removed. The user directly sees the file tab and a list of CRS tab.
The menu bar has open feature and an about window where we display project name, logo, clickable website link and configuration information.
MetadataView has had code clean-up.
All treetable related code is in NodeTreeTable which extends TreeTableView , used for About window.
Metadata is shown by MetadataTable which extends NodeTreeTable.
Configuration management is moved to Config class. It can capture state of a NodeTreeTable, store it, modify it later and delete it. This is meant for different views for different types of metadata.
CRSEditor updates all values when you switch to different CRS in the combo box. If any property is modified the name is changed to "Modified <authority:code>" . A progress indicator is shown whenever CRS is being loaded.
The metadata cells will use Node.setValue() for updating changes.
The underlying treetable gives unsupported operation exception.
I tried
dm = new DefaultMetadata(datastore.getMetadata() )
dm.isModifiable() returns true, but the actual setvalue operation throws an error.
Regards
Siddhesh Rane
---- Martin Desruisseaux wrote ----
>Hello Siddhesh
>
>Le 09/08/2017 à 19:26, Siddhesh Rane a écrit :
>
>I have moved it to the About menu.
>
>Thanks. Since the "Home" tab is now empty, do we need to keep it?
>
>The "About" dialog box contains directly the tree with all details. Shouldn't the dialog box contains at least a title (e.g. "About Apache SIS" with link to the project) with the tree below that?
>
>
>I am already using that. Some CRS at the beginning like EPSG:2000 don't seem to have datum definitions. Try EPSG:4244 Kandawala, ellipsoid information loads for that one.
>
>All CRS should have datum definition. But EPSG:2000 is a projected CRS while EPSG:4244 is a geodetic CRS. In the former case, the datum is more indirect. To get it:
>
>if (crs instanceof SingleCRS) { Datum datum = ((SingleCRS) crs).getDatum(); if (datum instanceof GeodeticDatum) { Ellipsoid ellps = ((GeodeticDatum) datum).getEllipsoid(); } }
>
>The above works for both GeographicCRS and ProjectedCRS.
>
>
>As a side note, I am currently setting SIS_DATA environment variable to point to a local installation on my hard disk. I tried adding sis-epsg maven module as a runtime dependency but it seems sis doesnt pick it up. There is warning about missing SIS_DATA variable and the factory being used is EPSGFactoryFallback. Am I missing something here?
>
>How do you set SIS_DATA? You can verify if it was really setup by printing the value of System.getenv("SIS_DATA") in your application.
>
>
>Le 13/08/2017 à 05:20, Siddhesh Rane a écrit :
>
>The CRSEditor uses a combo box for the CRS name and a list of registered CRS is shown. There is search as you type functionality provided using controlsfx.
>
>Nice. But when I select another name, I did not see the other values being updated accordingly, or did I miss something? For example if we select "EPSG:4326 - WGS84", I would expect the ellipsoid semi-major, semi-minor, etc. to be updated accordingly. Conversely, if I modify an ellipsoid axis length, then the name should not be "EPSG:4326 - WGS84" anymore since I changed the definition.
>
>
>The coordinate system combo box lists all available epsg coordinate systems.
>
>I propose to rename the label as "Coordinate systems" instead than "Coordinate system types". The types would be "Cartesian", "Spherical", etc., but what the combo box shows is rather instances (e.g. Cartesian with axis in metres oriented to North and East, etc.), which are more specific than types.
>
>The list of coordinate systems could be filtered according the type of CRS. For example in the CRS is a GeographicCRS, then only coordinate systems with latitude, longitude and optionally a height axes should be proposed. Conversely if the CRS is a ProjectedCRS, then only coordinate systems with linear units (metres, feet, kilometre, etc.) should be proposed.
>
>
>The axes dimensions table below it gets populated based on your choice of coordinate system. I suppose there is no requirement to manually add/delete/modify the axes dimensions.
>
>Right. We may want manual add/delete/modify, but that would be after this GSoC.
>
>
>In the case of a custom CRS does the user ever have to create it from scratch or just a minor variation on one of the existing CRS?
>
>I suggest to do variation of an existing CRS for now (no creation from scratch). However as said above, if a CRS is modified, then its name can not be "EPSG:something" anymore, so the combo box on the top should automatically become "Unnamed" or something like that (and the users will have to provide the name themselves).
>
>
>How do I store the new values in the metadata? The tree table has setValue method
>
>That setValue method should work. It may be the easiest approach.
>
>
>FeatureEditor has separate tabs for Waypoints, routes and tracks. The Waypoints table lists some common columns like name lat, lon, elevation, description and time. Editing support is available for name, lat, lon.
>
>This is a nice start, but the waypoints, routes and tracks are specific to GPX data. Other data (Shapefile, etc.) will have completely different data. Consequently, the table and columns need to be created dynamically.
>
>
>In the sis-features api I couldn't find a way to get typed attribute value; only object is returned. I had to run sample files and then check the return types at runtime. eg lat and long are obtained from sis:geometry which returns a Point from esri geometry api.
>
>You can get the type as below:
>
>FeatureType type = feature.getType(); PropertyType pt = type.getProperty("name"); if (pt instanceof AttributeType) { Class<?> valueClass = ((AttributeType) pt).getValueClass(); }
>
>
>As for creating new instances of features, I checked test suite of sis-features api where there is choice between sparse and dense features.
>
>The distinction betwwen "sparse" versus "dense" features is an implementation details. The approach proposed above should make abstraction of that.
>
>
>Also how do store these changes back into a file?
>
>The API for feature types is not yet frozen. It may be worth to skip the saving part for now.
>
> Martin
>
>
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
Le 09/08/2017 à 19:26, Siddhesh Rane a écrit :
> I have moved it to the About menu.
>
Thanks. Since the "Home" tab is now empty, do we need to keep it?
The "About" dialog box contains directly the tree with all details.
Shouldn't the dialog box contains at least a title (e.g. "About Apache
SIS" with link to the project) with the tree below that?
> I am already using that. Some CRS at the beginning like EPSG:2000
> don't seem to have datum definitions. Try EPSG:4244 Kandawala,
> ellipsoid information loads for that one.
>
All CRS should have datum definition. But EPSG:2000 is a projected CRS
while EPSG:4244 is a geodetic CRS. In the former case, the datum is more
indirect. To get it:
if (crs instanceof SingleCRS) {
Datum datum = ((SingleCRS) crs).getDatum();
if (datum instanceof GeodeticDatum) {
Ellipsoid ellps = ((GeodeticDatum) datum).getEllipsoid();
}
}
The above works for both GeographicCRS and ProjectedCRS.
> As a side note, I am currently setting SIS_DATA environment variable
> to point to a local installation on my hard disk. I tried adding
> sis-epsg maven module as a runtime dependency but it seems sis doesnt
> pick it up. There is warning about missing SIS_DATA variable and the
> factory being used is EPSGFactoryFallback. Am I missing something here?
>
How do you set SIS_DATA? You can verify if it was really setup by
printing the value of System.getenv("SIS_DATA") in your application.
Le 13/08/2017 à 05:20, Siddhesh Rane a écrit :
> The CRSEditor uses a combo box for the CRS name and a list of
> registered CRS is shown. There is search as you type functionality
> provided using controlsfx.
>
Nice. But when I select another name, I did not see the other values
being updated accordingly, or did I miss something? For example if we
select "EPSG:4326 - WGS84", I would expect the ellipsoid semi-major,
semi-minor, etc. to be updated accordingly. Conversely, if I modify an
ellipsoid axis length, then the name should not be "EPSG:4326 - WGS84"
anymore since I changed the definition.
> The coordinate system combo box lists all available epsg coordinate
> systems.
>
I propose to rename the label as "Coordinate systems" instead than
"Coordinate system types". The types would be "Cartesian", "Spherical",
etc., but what the combo box shows is rather instances (e.g. Cartesian
with axis in metres oriented to North and East, etc.), which are more
specific than types.
The list of coordinate systems could be filtered according the type of
CRS. For example in the CRS is a GeographicCRS, then only coordinate
systems with latitude, longitude and optionally a height axes should be
proposed. Conversely if the CRS is a ProjectedCRS, then only coordinate
systems with linear units (metres, feet, kilometre, etc.) should be
proposed.
> The axes dimensions table below it gets populated based on your choice
> of coordinate system. I suppose there is no requirement to manually
> add/delete/modify the axes dimensions.
>
Right. We may want manual add/delete/modify, but that would be after
this GSoC.
> In the case of a custom CRS does the user ever have to create it from
> scratch or just a minor variation on one of the existing CRS?
>
I suggest to do variation of an existing CRS for now (no creation from
scratch). However as said above, if a CRS is modified, then its name can
not be "EPSG:something" anymore, so the combo box on the top should
automatically become "Unnamed" or something like that (and the users
will have to provide the name themselves).
> How do I store the new values in the metadata? The tree table has
> setValue method
That setValue method should work. It may be the easiest approach.
> FeatureEditor has separate tabs for Waypoints, routes and tracks. The
> Waypoints table lists some common columns like name lat, lon,
> elevation, description and time. Editing support is available for
> name, lat, lon.
This is a nice start, but the waypoints, routes and tracks are specific
to GPX data. Other data (Shapefile, etc.) will have completely different
data. Consequently, the table and columns need to be created dynamically.
> In the sis-features api I couldn't find a way to get typed attribute
> value; only object is returned. I had to run sample files and then
> check the return types at runtime. eg lat and long are obtained from
> sis:geometry which returns a Point from esri geometry api.
>
You can get the type as below:
FeatureType type = feature.getType();
PropertyType pt = type.getProperty("name");
if (pt instanceof AttributeType) {
Class<?> valueClass = ((AttributeType) pt).getValueClass();
}
> As for creating new instances of features, I checked test suite of
> sis-features api where there is choice between sparse and dense features.
>
The distinction betwwen "sparse" versus "dense" features is an
implementation details. The approach proposed above should make
abstraction of that.
> Also how do store these changes back into a file?
>
The API for feature types is not yet frozen. It may be worth to skip the
saving part for now.
Martin
Re: JavaFX application progress
Posted by Siddhesh Rane <Si...@disroot.org>.
Hello all,
Project update :
The CRSEditor uses a combo box for the CRS name and a list of registered CRS is shown. There is search as you type functionality provided using controlsfx.
The coordinate system combo box lists all available epsg coordinate systems.
The axes dimensions table below it gets populated based on your choice of coordinate system. I suppose there is no requirement to manually add/delete/modify the axes dimensions. Correct me if I am wrong.
In the case of a custom CRS does the user ever have to create it from scratch or just a minor variation on one of the existing CRS?
The MetadataView > reference System Info shows just the name of the CRS with an edit hyperlink that opens a dialog box with the CRSEditor.
GeographicExtent and VerticalExtent editors can create new objects using DefaultGeaographicBoundingBox and DefaultVerticalExtent constructors. I suppose the same method will work for all other types. How do I store the new values in the metadata?
-The tree table has setValue method
-I could create DefaultMetadata from users given metadata and then use setter methods.
What is the right approach?
FeatureEditor has separate tabs for Waypoints, routes and tracks. The Waypoints table lists some common columns like name lat, lon, elevation, description and time. Editing support is available for name, lat, lon.
In the sis-features api I couldn't find a way to get typed attribute value; only object is returned. I had to run sample files and then check the return types at runtime. eg lat and long are obtained from sis:geometry which returns a Point from esri geometry api.
As for creating new instances of features, I checked test suite of sis-features api where there is choice between sparse and dense features. Here too the property/attribute name and the value object type needs to be known before hand.
Also how do store these changes back into a file?
Regards
Siddhesh Rane
---- Martin Desruisseaux wrote ----
>Le 07/08/2017 à 18:24, Siddhesh Rane a écrit :
>
>> >What about making it a dialog box instead than part of the CRS pane?
>> (...snip...)
>>
>> CRSEditor can be embedded anywhere, even in dialog box.
>>
>Yes, this is nice. But the application currently uses tabs, with "About
>SIS" information, data files, metadata, Coordinate Reference System
>(CRS) all at the same level. I think that for most users, the entry
>point will be their data file. Then (s)he can see the metadata of their
>file, and one part of the metadata is the CRS. So the CRS dialog box
>would be opened by editing the "Reference System" node on the metadata page.
>
>I understand that tabs may be more convenient during development, but at
>least the first tab about Apache SIS configuration should move in an
>"About Apache SIS" menu item.
>
>
>> I have changed it to org.apache.sis.desktop, similar to the
>> sis-console module. The artifact would be a part of "applications"
>> submodule.
>>
>Thanks for the renaming. Yes, the plan is to port the code to the
>"applications" submodule.
>
>
>> When editing CRS when I have to update certain fields, what pattern
>> needs to be followed? Do I
>> * call setValue if available
>> * create a new object by calling constructor
>> * use a factory method like DatumFactory.createPrimeMeridian
>>
>There is no "setValue" on CRS objects. All CRS are immutable on design,
>because (typically) thousands of geometries and other objects will share
>a reference to the same CRS. New objects need to be created by calls to
>DatumFactory, CSFactory and CRSFactory methods.
>
>As a side note, the current widget leaves the "semi-major" and
>"semi-minor" fields to zero. Those values can be fetched by
>Datum.getEllipsoid().getSemiMajor() and ...getSemiMinor().
>
>For the prime meridian, we should show the "Greenwich longitude"
>somewhere, maybe just on the right side of "Prime Meridian" combo box.
>
>
>> Also once the CRS is edited where is it supposed to be stored?
>>
>In the metadata, under "Reference system" node. The proposed action
>would be to have no CRS tab, but instead an "edit" button for the
>"metadata.referenceSystem" node. This edit button would popup the CRS
>editor in a dialog box. The first "name" field could be an editable
>combo-box with the list of all CRS, plus a "user defined" choice. If the
>user select one of the names in the list, all values in the dialog box
>are updated accordingly but are unmodifiable. If the user selects
>"user-defined", the values become modifiable.
>
> Martin
>
>
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 07/08/2017 à 18:24, Siddhesh Rane a écrit :
> >What about making it a dialog box instead than part of the CRS pane?
> (...snip...)
>
> CRSEditor can be embedded anywhere, even in dialog box.
>
Yes, this is nice. But the application currently uses tabs, with "About
SIS" information, data files, metadata, Coordinate Reference System
(CRS) all at the same level. I think that for most users, the entry
point will be their data file. Then (s)he can see the metadata of their
file, and one part of the metadata is the CRS. So the CRS dialog box
would be opened by editing the "Reference System" node on the metadata page.
I understand that tabs may be more convenient during development, but at
least the first tab about Apache SIS configuration should move in an
"About Apache SIS" menu item.
> I have changed it to org.apache.sis.desktop, similar to the
> sis-console module. The artifact would be a part of "applications"
> submodule.
>
Thanks for the renaming. Yes, the plan is to port the code to the
"applications" submodule.
> When editing CRS when I have to update certain fields, what pattern
> needs to be followed? Do I
> * call setValue if available
> * create a new object by calling constructor
> * use a factory method like DatumFactory.createPrimeMeridian
>
There is no "setValue" on CRS objects. All CRS are immutable on design,
because (typically) thousands of geometries and other objects will share
a reference to the same CRS. New objects need to be created by calls to
DatumFactory, CSFactory and CRSFactory methods.
As a side note, the current widget leaves the "semi-major" and
"semi-minor" fields to zero. Those values can be fetched by
Datum.getEllipsoid().getSemiMajor() and ...getSemiMinor().
For the prime meridian, we should show the "Greenwich longitude"
somewhere, maybe just on the right side of "Prime Meridian" combo box.
> Also once the CRS is edited where is it supposed to be stored?
>
In the metadata, under "Reference system" node. The proposed action
would be to have no CRS tab, but instead an "edit" button for the
"metadata.referenceSystem" node. This edit button would popup the CRS
editor in a dialog box. The first "name" field could be an editable
combo-box with the list of all CRS, plus a "user defined" choice. If the
user select one of the names in the list, all values in the dialog box
are updated accordingly but are unmodifiable. If the user selects
"user-defined", the values become modifiable.
Martin
Re: JavaFX application progress
Posted by Siddhesh Rane <Si...@disroot.org>.
Sent from my Sony Xperia™ smartphone
---- Martin Desruisseaux wrote ----
>What about making it a dialog box instead than part of the CRS pane? A later version could have two tabs: one which is the current one, and one for the Well Known Text. I'm not suggest to do that now; just planing for future evolution.
CRSEditor can be embedded anywhere, even in dialog box.
> As a side note, I see many exceptions like below when running the application. Could you fix?
It's related to spinners being initialized from fxml. This exception was being thrown at fxml.load() time. I tried many options but so far I have partially solved the problem.
> Another note: the package name should be changed in order to start with "org.apache.sis". It could be for instance "org.apache.sis.desktop" (I suggest to avoid "client" since it may have other meaning unrelated to desktop application).
I have changed it to org.apache.sis.desktop, similar to the sis-console module. The artifact would be a part of "applications" submodule.
When editing CRS when I have to update certain fields, what pattern needs to be followed? Do I
* call setValue if available
* create a new object by calling constructor
* use a factory method like DatumFactory.createPrimeMeridian
Also once the CRS is edited where is it supposed to be stored?
Regards
Siddhesh Rane
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
Le 02/08/2017 à 19:25, Siddhesh Rane a écrit :
> The CRS editor is now functioning and connected to the CRS list. You
> can right click on a chosen CRS and click edit to see the pane in action.
>
Thanks, it is a good start. What about making it a dialog box instead
than part of the CRS pane? A later version could have two tabs: one
which is the current one, and one for the Well Known Text. I'm not
suggest to do that now; just planing for future evolution.
> For the prime meridian you have asked for a combo box. But upon
> analyzing the class there doesn't seem to be an enumerable type. What
> are the other options that can be used to populate the combo box and
> how to get them?
>
You can do as below (this is not the most efficient way, but we can
start like that):
CRSAuthorityFactory factory = CRS.getAuthorityFactory("EPSG");
if (factory instanceof DatumAuthorityFactory) {
DatumAuthorityFactory df = (DatumAuthorityFactory);
Set<String> codes = df.getAuthorityCodes(PrimeMeridian.class);
for (String code : codes) {
PrimeMeridian pm = df.createPrimeMeridian(code);
}
}
As a side note, I see many exceptions like below when running the
application. Could you fix?
Exception in thread "JavaFX Application Thread" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Double
at com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:182)
(...snip...)
at sis.client.metadata.GeographicExtentBox.<init>(GeographicExtentBox.java:54)
at sis.client.crs.CRSEditor.setValues(CRSEditor.java:130)
Another note: the package name should be changed in order to start with
"org.apache.sis". It could be for instance "org.apache.sis.desktop" (I
suggest to avoid "client" since it may have other meaning unrelated to
desktop application).
Martin
Re: JavaFX application progress
Posted by Siddhesh Rane <Si...@disroot.org>.
Hello Martin
The CRS editor is now functioning and connected to the CRS list. You can right click on a chosen CRS and click edit to see the pane in action.
For the prime meridian you have asked for a combo box. But upon analyzing the class there doesn't seem to be an enumerable type. What are the other options that can be used to populate the combo box and how to get them?
---- Martin Desruisseaux wrote ----
> Could you give an example? If a ReferenceSystem.getName() does not
> return a proper value, it may be an issue to investigate.
It will return the name when we have GeodeticCRS. But in case of ProjectedCRS with a base geod CRS it will return empty result.
> It may be useful to have the semi-major and semi-minor fields disposed
> vertically, since it make easier to visually compare their numerical value.
>
> The "Bounding Box" and "Area" field could be collectively be named
> "Domain of validity". Both provides the same information, but in
> different way.
Both changes done.
Regards
Siddhesh Rane
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
Thanks for the update, I think that this summary pane is very helpful
for having a quick look at the main metadata before to dig in the
details if the user wishes to.
Le 31/07/2017 à 19:07, Siddhesh Rane a écrit :
> For the name of reference system I'm using
> ReferenceSystem.getName().toString() but it may not always return a
> proper name like what you can see in the tree table view reference
> system info section.
>
Could you give an example? If a ReferenceSystem.getName() does not
return a proper value, it may be an issue to investigate.
> Secondly axis dimensions have not yet been added. In one file I have,
> there are two spatial representation info sections with two axis
> dimension properties each. Would you prefer to see them grouped in the
> separately or all together in the table, though the order is
> guaranteed to be maintained?
>
I propose that the summary panel shows only the "main" spatial
representation info, with a note saying that more spatial representation
info are available. Users would switch to the details view if (s)he
wants to see those other spatial representation info.
The "main" spatial representation info could be defined as the largest
one. We could compute that as the product of all "size" values (i.e.
compute the number of cells in the grid), and select the spatial
representation info having the largest result.
> I have added an fxml screenshot for the CRSEditor. I have also added
> an area description and bounding box view. Do comment on the format
> and any changes.
>
It may be useful to have the semi-major and semi-minor fields disposed
vertically, since it make easier to visually compare their numerical value.
The "Bounding Box" and "Area" field could be collectively be named
"Domain of validity". Both provides the same information, but in
different way.
Regards,
Martin
Re: JavaFX application progress
Posted by Siddhesh Rane <Si...@disroot.org>.
Hello all,
A quick summary view has been implemented which shows data section title, abstract, geographic extent, spatial representation type and reference system. For the name of reference system I'm using ReferenceSystem.getName().toString() but it may not always return a proper name like what you can see in the tree table view reference system info section. That is one problem so far.
Secondly axis dimensions have not yet been added. In one file I have, there are two spatial representation info sections with two axis dimension properties each. Would you prefer to see them grouped in the separately or all together in the table, though the order is guaranteed to be maintained?
I have added an fxml screenshot for the CRSEditor. I have also added an area description and bounding box view. Do comment on the format and any changes.
Regards
Siddhesh Rane
---- Martin Desruisseaux wrote ----
>Hello Siddhesh
>
>Le 28/07/2017 à 09:22, Siddhesh Rane a écrit :
>
>Are you pointing out to the non uniform widths of various spinners and combo boxes? These can be fixed by setting their maximum width to max value so they'll fill the entire width of the column.
>
>I was thinking more about the diversity of layouts. One row may have 2 fields for a minimum and maximum values, another row 4 fields, etc. In tables, data in the same column are usually represented in an uniform way. This is not completely true for metadata so we are taking some liberties with specialized widgets, but I think that we should not go too far. I suggest to use in the tree-table only widgets representable on a single line, and move larger widgets outside the tree-table (more on it later).
>
>
>Actually we do. I have put labels in the latest update. We can have as much vertical space as we want. Earlier I was just using prompt text but now we have both.
>
>Yes, those labels help a lot. Thanks.
>
>
>I'm not fully clear about what constitutes a simplified view. My view was that a simplified view will group together certain nodes that are related like min max, bounds, date and date type etc and show hide empty nodes and certain user specified nodes. But I thought the hierarchy had to be maintained because it has useful information, as certain fields like Identifier and citation appear at many different places, so I stuck to tree view.
>
>My idea of simplified view is to get ride of the hierarchy. Indeed it is not possible to represent the full ISO 19115 metadata without hierarchy. As you point out, structures like Identifier and Citation appear in many different places. But the proposal is to pick only one Citation and only one Identifier, the ones which are generally of most interest to users. For example an ISO 19115 metadata can contain Citation for:
>
>datametadata (may or may not be same as data citation)
>file formatalgorithm of data processing
>process for quality assessmentetc.
>
>But most of the time the user only wants to see the citation for the data, so we could show only that citation in the simplified view. If (s)he want to see other citations, then (s)he can switch to the tree-table view where all information are available.
>
>One of the first things that users will want to see is the title of the data and the geographic extent. In the tree-table view, users have to navigate into "Identification info" node, then "Citation", then "title" (and yet deeper if (s)he wants the author name). For the the geographic extent, users have to navigate to "Identification info", "Extents", "Geographic elements". This may not be obvious to users not familiar with ISO 19115. The proposal is to have a summary panel without hierarchy, showing only a pre-selected metadata (not all).
>
>
>According to the the sample image that you sent me I have come up with a similar summary view in tree table view instead using operations like removing unwanted subtree, flattening subtrees and rearranging nodes at https://github.com/SiddheshRane/sis-client/blob/master/screenshots/Summary.png This view was generated by user interface elements like shift+up/down for rearranging nodes, and right clicking to flatten subtree or remove nodes from the view. Do you want the simplified view to show only titles, names, descriptions, keywords, strings? Like You said Citation could be hidden but show only it's children, what other components are less important.
>
>I would suggest that the left column disappear for the simplified view; no tree at all. So the user would see "Title" directly, without "Identification info" node on top of it (but a button somewhere would hello him to switch to the tree-table view if (s)he wants). I would omit the online resources and contact information for now (we can revisit them later). For a first draft, I would suggest to use only the following:
>
>Title on one line
>Abstract on many linesGeographic extent
>Spatial reference system (only the name, not the full description) Spatial representation typeAxis dimensions in a table
>
>Nothing more for now (we can revisit later for more info). Above can be read-only (I think it is okay to ask users to switch to tree-table view if they want to edit).
>
>
>Oh I didn't know about the linear relationship. I will switch to Plate-Carré projection image.
>
>Alternatively, we could also omit the range sliders. They are not linearly related to the selection unless we restrict to Plate-Carrée, which is not the preferred projection. Even in Plate-carrée those sliders are not aligned with the selection unless the user zoom at a very specific level. All this come at the cost of an extra dependency. Wouldn't it be preferable to remove them for now? If we want range sliders for geographic extent, we will need to develop our own, but this would be more work than what we can do in the GSoC.
>
>
>
>Can you tell me the requirements of the CRS editor, like how do you wish to interact with it and what are the operations you need to perform. Whether you only need to edit certain values, or add new components like axes, parameters or change the types entirely like switching from geodeticCRS to projectedCRS. I need your requirements clearly, even if certain questions might sound senseless, because I'm not an expert at these.
>
>I suggest to begin with a dialog box like below (for easier start, I'm omitting some important elements like base CRS, ellipsoid name, etc.):
>
>The CRS name as a text fieldThe datum name as a text fieldPrime meridian as a combo box (not editable for now)Semi-major axis lengthSemi-minor axis length (later, we should add a button for switching to inverse flattening factor) Coordinate system type (for now only Ellipsoidal or Cartesian)A table on two or three rows containing the following columns:Axis name as a text fieldAxis units of measurement
>Axis direction (north, south, east, west) as a combo-box
>
>
>If you can give me a detailed scenario of how you'll use the functionality you are expecting in terms of user interface components then I can judge how much work it will require. But I think that the tree table view can fit our needs with the preferences functionality offering not only summaries but different views.
>
>My proposal is:
>
>In the tree-table, limit the specialized widgets to those that fit on a single line.Create a separated panel with no hierarchy and only the above-cited metadata elements. More complex widgets appear there.
>
>Of course it can be questioned, and it is okay to try alternatives.
>
>Martin
>
>
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
Le 28/07/2017 à 09:22, Siddhesh Rane a écrit :
> Are you pointing out to the non uniform widths of various spinners and
> combo boxes? These can be fixed by setting their maximum width to max
> value so they'll fill the entire width of the column.
>
I was thinking more about the diversity of layouts. One row may have 2
fields for a minimum and maximum values, another row 4 fields, etc. In
tables, data in the same column are usually represented in an uniform
way. This is not completely true for metadata so we are taking some
liberties with specialized widgets, but I think that we should not go
too far. I suggest to use in the tree-table only widgets representable
on a single line, and move larger widgets outside the tree-table (more
on it later).
> Actually we do. I have put labels in the latest update. We can have as
> much vertical space as we want. Earlier I was just using prompt text
> but now we have both.
>
Yes, those labels help a lot. Thanks.
> I'm not fully clear about what constitutes a simplified view. My view
> was that a simplified view will group together certain nodes that are
> related like min max, bounds, date and date type etc and show hide
> empty nodes and certain user specified nodes. But I thought the
> hierarchy had to be maintained because it has useful information, as
> certain fields like Identifier and citation appear at many different
> places, so I stuck to tree view.
>
My idea of simplified view is to get ride of the hierarchy. Indeed it is
not possible to represent the full ISO 19115 metadata without hierarchy.
As you point out, structures like Identifier and Citation appear in many
different places. But the proposal is to pick only one Citation and only
one Identifier, the ones which are generally of most interest to users.
For example an ISO 19115 metadata can contain Citation for:
* data
* metadata (may or may not be same as data citation)
* file format
* algorithm of data processing
* process for quality assessment
* etc.
But most of the time the user only wants to see the citation for the
data, so we could show only that citation in the simplified view. If
(s)he want to see other citations, then (s)he can switch to the
tree-table view where all information are available.
One of the first things that users will want to see is the title of the
data and the geographic extent. In the tree-table view, users have to
navigate into "Identification info" node, then "Citation", then "title"
(and yet deeper if (s)he wants the author name). For the the geographic
extent, users have to navigate to "Identification info", "Extents",
"Geographic elements". This may not be obvious to users not familiar
with ISO 19115. The proposal is to have a summary panel without
hierarchy, showing only a pre-selected metadata (not all).
> According to the the sample image that you sent me I have come up with
> a similar summary view in tree table view instead using operations
> like removing unwanted subtree, flattening subtrees and rearranging
> nodes at
> https://github.com/SiddheshRane/sis-client/blob/master/screenshots/Summary.png
> This view was generated by user interface elements like shift+up/down
> for rearranging nodes, and right clicking to flatten subtree or remove
> nodes from the view. Do you want the simplified view to show only
> titles, names, descriptions, keywords, strings? Like You said Citation
> could be hidden but show only it's children, what other components are
> less important.
>
I would suggest that the left column disappear for the simplified view;
no tree at all. So the user would see "Title" directly, without
"Identification info" node on top of it (but a button somewhere would
hello him to switch to the tree-table view if (s)he wants). I would omit
the online resources and contact information for now (we can revisit
them later). For a first draft, I would suggest to use only the following:
* Title on one line
* Abstract on many lines
* Geographic extent
* Spatial reference system (only the name, not the full description)
* Spatial representation type
* Axis dimensions in a table
Nothing more for now (we can revisit later for more info). Above can be
read-only (I think it is okay to ask users to switch to tree-table view
if they want to edit).
> Oh I didn't know about the linear relationship. I will switch to
> Plate-Carré projection image.
>
Alternatively, we could also omit the range sliders. They are not
linearly related to the selection unless we restrict to Plate-Carrée,
which is not the preferred projection. Even in Plate-carrée those
sliders are not aligned with the selection unless the user zoom at a
very specific level. All this come at the cost of an extra dependency.
Wouldn't it be preferable to remove them for now? If we want range
sliders for geographic extent, we will need to develop our own, but this
would be more work than what we can do in the GSoC.
> Can you tell me the requirements of the CRS editor, like how do you
> wish to interact with it and what are the operations you need to
> perform. Whether you only need to edit certain values, or add new
> components like axes, parameters or change the types entirely like
> switching from geodeticCRS to projectedCRS. I need your requirements
> clearly, even if certain questions might sound senseless, because I'm
> not an expert at these.
>
I suggest to begin with a dialog box like below (for easier start, I'm
omitting some important elements like base CRS, ellipsoid name, etc.):
* The CRS name as a text field
* The datum name as a text field
o Prime meridian as a combo box (not editable for now)
o Semi-major axis length
o Semi-minor axis length (later, we should add a button for
switching to inverse flattening factor)
* Coordinate system type (for now only Ellipsoidal or Cartesian)
* A table on two or three rows containing the following columns:
o Axis name as a text field
o Axis units of measurement
o Axis direction (north, south, east, west) as a combo-box
> If you can give me a detailed scenario of how you'll use the
> functionality you are expecting in terms of user interface components
> then I can judge how much work it will require. But I think that the
> tree table view can fit our needs with the preferences functionality
> offering not only summaries but different views.
My proposal is:
* In the tree-table, limit the specialized widgets to those that fit
on a single line.
* Create a separated panel with no hierarchy and only the above-cited
metadata elements. More complex widgets appear there.
Of course it can be questioned, and it is okay to try alternatives.
Martin
Re: JavaFX application progress
Posted by Siddhesh Rane <Si...@disroot.org>.
Hello Martin
---- Martin Desruisseaux wrote ----
> The approach taken so far was to
> insert the specialized widgets directly in the tree. It was nice to
> experiment, but we can now see the resulting heterogeneity (variations
> in the fields layout) in the "value" column.
Are you pointing out to the non uniform widths of various spinners and combo boxes? These can be fixed by setting their maximum width to max value so they'll fill the entire width of the column.
> Another complication is
> that we do not have a lot of room for putting labels telling to users
> what the fields mean.
Actually we do. I have put labels in the latest update. We can have as much vertical space as we want. Earlier I was just using prompt text but now we have both.
> My original idea was to create simplified views completely separated
> from the tree table, as proposed in my email one month ago [1]. That
> email contained a link to a screenshot of a competing software
> (Geonetwork) for inspiration. I proposed a few fields we could select
> for starting with something simpler. Some elements of the summary form
> would regroup many tree nodes (for example showing all
> AxisDimensionProperties in a table). If we implement such forms, some
> specialized widgets developed for the tree table could move to that
> form. I realize that designing a "metadata summary" form requires some
> familiarity with the semantic of ISO 19115 metadata, but we would be
> glad to help if we can have a prototype or a drawing somewhere.
I'm not fully clear about what constitutes a simplified view. My view was that a simplified view will group together certain nodes that are related like min max, bounds, date and date type etc and show hide empty nodes and certain user specified nodes. But I thought the hierarchy had to be maintained because it has useful information, as certain fields like Identifier and citation appear at many different places, so I stuck to tree view.
You have to understand that I'm not knowledgeable in metadata and I don't know what fields occur more frequently and/or are more important so I can't decide what to include or exclude or how to rearrange. I can't even come up with a mock diagram because in the different metadata files that I have used there is a large amount of variation in what fields are present or absent so I can't deduce patterns. So we need to be very specific and clear on this one.
According to the the sample image that you sent me I have come up with a similar summary view in tree table view instead using operations like removing unwanted subtree, flattening subtrees and rearranging nodes at
https://github.com/SiddheshRane/sis-client/blob/master/screenshots/Summary.png
This view was generated by user interface elements like shift+up/down for rearranging nodes, and right clicking to flatten subtree or remove nodes from the view.
Do you want the simplified view to show only titles, names, descriptions, keywords, strings? Like You said Citation could be hidden but show only it's children, what other components are less important.
> The other widgets (the map pane, the extent pane, the list of CRS) are
> interesting starts, but some changes are needed (e.g. there is no linear
> relationship between a latitude slider and a Mercator projection - maybe
> you wanted to use a Plate-Carré projection?)
Oh I didn't know about the linear relationship. I will switch to Plate-Carré projection image.
> and we may not have the
> time to connect those widgets to actual actions (e.g. open a CRS editor
> when a CRS is selected).
This can be done in a similar way to the how metadata is opened from file pane.
Can you tell me the requirements of the CRS editor, like how do you wish to interact with it and what are the operations you need to perform. Whether you only need to edit certain values, or add new components like axes, parameters or change the types entirely like switching from geodeticCRS to projectedCRS. I need your requirements clearly, even if certain questions might sound senseless, because I'm not an expert at these.
> Should we focus on the metadata form only?
If you can give me a detailed scenario of how you'll use the functionality you are expecting in terms of user interface components then I can judge how much work it will require. But I think that the tree table view can fit our needs with the preferences functionality offering not only summaries but different views.
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
To summarize my view on the various points in our email exchange, I'm
not sure that current direction is achieving our goal of providing
simplified views of metadata to users. The approach taken so far was to
insert the specialized widgets directly in the tree. It was nice to
experiment, but we can now see the resulting heterogeneity (variations
in the fields layout) in the "value" column. Another complication is
that we do not have a lot of room for putting labels telling to users
what the fields mean. Continuing this approach leads us to questionable
actions, like tables in tree-table - you rightly point out that this is
not a recommended practice. Recent developments allow the users to hide
columns or rows, or change row order, but it does not make the metadata
fundamentally easier for users.
My original idea was to create simplified views completely separated
from the tree table, as proposed in my email one month ago [1]. That
email contained a link to a screenshot of a competing software
(Geonetwork) for inspiration. I proposed a few fields we could select
for starting with something simpler. Some elements of the summary form
would regroup many tree nodes (for example showing all
AxisDimensionProperties in a table). If we implement such forms, some
specialized widgets developed for the tree table could move to that
form. I realize that designing a "metadata summary" form requires some
familiarity with the semantic of ISO 19115 metadata, but we would be
glad to help if we can have a prototype or a drawing somewhere.
In the part of my previous email talking about "straightforward tree",
indeed I mean the tree shown by ValueExistencePolicy.COMPACT (or
ValueExistencePolicy.ALL in edition mode). But we could have links
between the tree view and the summary form. Some nodes could have a
"summary" link which bring the focus to the corresponding element of the
summary form, and conversely some elements of the form could have a
"details" link that bring the focus to the corresponding node of the
tree table.
The other widgets (the map pane, the extent pane, the list of CRS) are
interesting starts, but some changes are needed (e.g. there is no linear
relationship between a latitude slider and a Mercator projection - maybe
you wanted to use a Plate-Carré projection?) and we may not have the
time to connect those widgets to actual actions (e.g. open a CRS editor
when a CRS is selected). Should we focus on the metadata form only?
Martin
[1] https://lists.apache.org/thread.html/97f8b80284797a7347655c3bac870abf5c1d48c21d5aed3494d981f7@%3Cdev.sis.apache.org%3E
Le 25/07/2017 à 16:56, Siddhesh Rane a écrit :
>> * In the tree view of current application, what is the meaning of the
>> eyes and arrows on the right side of each property name?
> The tree view will have an "profile edit" mode in which all possible metadata identifiers will be shown, the user can then click on the the "eye" to show/hide it by default in the read mode , and then user can drag the entire node to rearrange it for sorting. Once the user is finished he can capture this state and save it under a new profile. The eye and arrows won't be shown until the user hovers the mouse over the row. Css is yet to be added to it.
>
>> * The Extent pane does not seem to be currently connected to something
>> else, but I suppose that you have a plan for it. What would be the plan?
> The NSEW widget for geographic extent has a button in the center which upon clicking will open this bigger extent pane. Since we are planning to use this widget for searching in CRS and there its more convenient to draw the extent.
>
>> * I presume you noticed that the range sliders in the Extent pane are
>> not currently aligned with the bounding box. Is it something that
>> you plan to fix? (I realize that it may require that you write your
>> own range slider).
> You can scroll the map, but if you CTRL+scroll then the map will zoom. So you ctrl+scroll down to zoom out the map to the same width as the scroll pane. In this case the bounding box will align with the sliders. It's intentional. The sliders are not necessarily supposed to align though.
>
>> * Where the background map come from? I would be curious to know what
>> are the meaning of circles and the lines connecting them in the ocean.
> I searched for mercator projection of the earth and came across this image from Wikimedia commons. I wanted to consult with you about the accuracy of this map, which I presume is accurate. If you can point me to a more accurate image I'll use that.
>
>> * In the metadata tree view, the identifier and type columns may be
>> convenient for development, but shouldn't they be hidden by default
>> for the users?
> There is a plus shaped button at the top right corner which allows you to selectively hide unwanted columns.
> Right now JavaFX TreeTableView doesn't provide a programmatic way of keeping certain columns hidden by default, yet visible in the menu for a user to show extra columns.
> So what I'll do is place toggle buttons at the top to enable/disable these columns. These columns will be by default not added to the tree table. In the release version we are simply going to remove them, but keeping them hidden by default right now is going to make it more inconvenient for me during development.
>
>> The specialized widgets are compact, but I'm unsure about whether
>> inserting them in the tree is always helpful. Would it be possible to
>> allow switching between the 2 modes? (straightforward tree, or tree with
>> some specialized widgets)?
> By straightforward tree do you mean the one we get with ValueExistencePolicy.COMPACT or do you want to selectively disable certain widgets? Can you please elaborate this more?
>
> Another thing that may help is that some
>> specialized widgets could be made more high-level:
>>
>> * In Metadata/SpatialRepresentationInfo/AxisDimensionProperties,
>> instead of a (size, name) pair for each AxisDimensionProperties
>> node, we could do a single table for all properties under a single
>> AxisDimensionProperties node. The name column could be first, then
>> the size and the resolution. The column headers would also help user
>> to know what the properties are (currently we have to guess). I
>> realize that the result is a table inside a tree-table and I'm not
>> sure it is a great idea; an alternative could be to put such table
>> in a completely separated "summary" widget, as I proposed in earlier
>> emails.
>> * A similar approach could be done for descriptive keywords (one table
>> row for each keyword type).
> Well a table inside a table cell is generally not recommended practice, but I'll think of something. Too soon to tell.
>
>> In metadata identifiers (or any other identifier), the specialized
>> widget have 4 fields, but it is difficult to guess their meaning. Would
>> it be possible to put label, or tooltip?
> Yes I'll add labels and tooltips. Currently there is prompt text which shows when the field is empty
>
> Regards
> Siddhesh Rane
Re: JavaFX application progress
Posted by Siddhesh Rane <Si...@disroot.org>.
Hello Martin,
---- Martin Desruisseaux wrote ----
> * In the tree view of current application, what is the meaning of the
> eyes and arrows on the right side of each property name?
The tree view will have an "profile edit" mode in which all possible metadata identifiers will be shown, the user can then click on the the "eye" to show/hide it by default in the read mode , and then user can drag the entire node to rearrange it for sorting. Once the user is finished he can capture this state and save it under a new profile. The eye and arrows won't be shown until the user hovers the mouse over the row. Css is yet to be added to it.
> * The Extent pane does not seem to be currently connected to something
> else, but I suppose that you have a plan for it. What would be the plan?
The NSEW widget for geographic extent has a button in the center which upon clicking will open this bigger extent pane. Since we are planning to use this widget for searching in CRS and there its more convenient to draw the extent.
> * I presume you noticed that the range sliders in the Extent pane are
> not currently aligned with the bounding box. Is it something that
> you plan to fix? (I realize that it may require that you write your
> own range slider).
You can scroll the map, but if you CTRL+scroll then the map will zoom. So you ctrl+scroll down to zoom out the map to the same width as the scroll pane. In this case the bounding box will align with the sliders. It's intentional. The sliders are not necessarily supposed to align though.
> * Where the background map come from? I would be curious to know what
> are the meaning of circles and the lines connecting them in the ocean.
I searched for mercator projection of the earth and came across this image from Wikimedia commons. I wanted to consult with you about the accuracy of this map, which I presume is accurate. If you can point me to a more accurate image I'll use that.
> * In the metadata tree view, the identifier and type columns may be
> convenient for development, but shouldn't they be hidden by default
> for the users?
There is a plus shaped button at the top right corner which allows you to selectively hide unwanted columns.
Right now JavaFX TreeTableView doesn't provide a programmatic way of keeping certain columns hidden by default, yet visible in the menu for a user to show extra columns.
So what I'll do is place toggle buttons at the top to enable/disable these columns. These columns will be by default not added to the tree table. In the release version we are simply going to remove them, but keeping them hidden by default right now is going to make it more inconvenient for me during development.
> The specialized widgets are compact, but I'm unsure about whether
> inserting them in the tree is always helpful. Would it be possible to
> allow switching between the 2 modes? (straightforward tree, or tree with
> some specialized widgets)?
By straightforward tree do you mean the one we get with ValueExistencePolicy.COMPACT or do you want to selectively disable certain widgets? Can you please elaborate this more?
Another thing that may help is that some
> specialized widgets could be made more high-level:
>
> * In Metadata/SpatialRepresentationInfo/AxisDimensionProperties,
> instead of a (size, name) pair for each AxisDimensionProperties
> node, we could do a single table for all properties under a single
> AxisDimensionProperties node. The name column could be first, then
> the size and the resolution. The column headers would also help user
> to know what the properties are (currently we have to guess). I
> realize that the result is a table inside a tree-table and I'm not
> sure it is a great idea; an alternative could be to put such table
> in a completely separated "summary" widget, as I proposed in earlier
> emails.
> * A similar approach could be done for descriptive keywords (one table
> row for each keyword type).
Well a table inside a table cell is generally not recommended practice, but I'll think of something. Too soon to tell.
> In metadata identifiers (or any other identifier), the specialized
> widget have 4 fields, but it is difficult to guess their meaning. Would
> it be possible to put label, or tooltip?
Yes I'll add labels and tooltips. Currently there is prompt text which shows when the field is empty
Regards
Siddhesh Rane
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Siddhesh
Sorry for being silent lately, I was at the FOSS4G conference last week.
I just did a checkout of the current application and have the following
remarks:
* In the tree view of current application, what is the meaning of the
eyes and arrows on the right side of each property name?
* The Extent pane does not seem to be currently connected to something
else, but I suppose that you have a plan for it. What would be the plan?
* I presume you noticed that the range sliders in the Extent pane are
not currently aligned with the bounding box. Is it something that
you plan to fix? (I realize that it may require that you write your
own range slider).
* Where the background map come from? I would be curious to know what
are the meaning of circles and the lines connecting them in the ocean.
* In the metadata tree view, the identifier and type columns may be
convenient for development, but shouldn't they be hidden by default
for the users?
The specialized widgets are compact, but I'm unsure about whether
inserting them in the tree is always helpful. Would it be possible to
allow switching between the 2 modes? (straightforward tree, or tree with
some specialized widgets)? Another thing that may help is that some
specialized widgets could be made more high-level:
* In Metadata/SpatialRepresentationInfo/AxisDimensionProperties,
instead of a (size, name) pair for each AxisDimensionProperties
node, we could do a single table for all properties under a single
AxisDimensionProperties node. The name column could be first, then
the size and the resolution. The column headers would also help user
to know what the properties are (currently we have to guess). I
realize that the result is a table inside a tree-table and I'm not
sure it is a great idea; an alternative could be to put such table
in a completely separated "summary" widget, as I proposed in earlier
emails.
* A similar approach could be done for descriptive keywords (one table
row for each keyword type).
In metadata identifiers (or any other identifier), the specialized
widget have 4 fields, but it is difficult to guess their meaning. Would
it be possible to put label, or tooltip?
Martin
Re: JavaFX application progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
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
Re: JavaFX application progress
Posted by Siddhesh Rane <si...@disroot.org>.
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" <ma...@geomatys.com> 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