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
