sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SIS-187) Reduce visibility of Shapefile fields
Date Mon, 07 Dec 2015 11:33:11 GMT

    [ https://issues.apache.org/jira/browse/SIS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044798#comment-15044798
] 

Martin Desruisseaux commented on SIS-187:
-----------------------------------------

A method like {{envelope.getLower("latitude")}} requires that the user know that the coordinate
reference system (CRS) is geographic. If the CRS is projected, we would have no latitude axis
but instead {{envelope.getLower("northing")}}. On the north pole it would be for example {{envelope.getLower("South
along 90┬░E")}}, _etc_.

What should be the default CRS when there is no {{.prj}} file is an open question. But when
a {{.prj}} file is present, we can do the following process: First, parse the content of the
{{.prj}} file with a method call like below (note: there is an issue with the fact that GDAL/ESRI
WKT 1 has a slight incompatibility with the standard WKT 1 format in some cases. But we can
ignore that problem for starting):

{code:java}
CoordinateReferenceSystem crs = CRS.fromWKT(theWktString);
{code}

Then, let assume for now that you want the following mapping:

* The "x" axis on screen is whatever CRS axis is oriented toward East.
* The "y" axis on screen is whatever CRS axis is oriented toward North (or to South actually,
since screen "y" is oriented toward down).

On approach is to loop over the axis given by {{crs.getCoordinateSystem().getAxis(int)}},
query their {{getDirection()}} property and search for those having a value {{AxisOrientation.EAST}}
and {{AxisOrientation.NORTH}}:

{code:java}
CoordinateSystem cs = crs.getCoordinateSystem();
int dimension = cs.getDimension();
int dimensionOfX = -1;
int dimensionOfY = -1;
for (int i=0; i<dimension; i++) {
    AxisOrientation dir = cs.getAxis(i).getDirection();
    if (dir == AxisDirection.EAST) {
        dimensionOfX = i;
    } else if (dir == AxisDirection.NORTH) {
        dimensionOfY = i;
    }
}
// Here we should throw an exception if EAST and NORTH were not found.
double xmin = envelope.getLower(dimensionOfX);
double ymin = envelope.getLower(dimensionOfY);
{code}

For starting, this should be enough for covering the most common cases. In a future revision
we can delegate more of this task to {{sis-referencing}}. For example the {{Matrices.createTransform(...)}}
methods do the above loop for us, but the result is a matrix. I propose to leave matrix handling
for a little bit later, for more progressive steps.

> Reduce visibility of Shapefile fields
> -------------------------------------
>
>                 Key: SIS-187
>                 URL: https://issues.apache.org/jira/browse/SIS-187
>             Project: Spatial Information Systems
>          Issue Type: Sub-task
>          Components: Shapefile
>            Reporter: Martin Desruisseaux
>            Assignee: M. Le Bihan
>              Labels: JDBC, Shapefile
>             Fix For: 0.7
>
>
> The {{Shapefile}} implementation contains many fields, and all of them are currently
public. Probably many of them could be private. Below is a list of fields with a guess of
whether users are likely to want this information, and how he could obtain it.
> h3. Fields that could be considered internal mechanic
> * {{FileCode}}: currently used only in {{Shapefile.toString()}} implementation without
explanation.
> * {{FileLength}}: currently used only in {{Shapefile.toString()}} implementation. Potentially
useful to the {{Shapefile}} reader itself, but unlikely to be useful to external user since
getting a useful meaning from a file length require knowledge of the file format structure.
> * {{Version}}: currently used only in {{Shapefile.toString()}} implementation. Not clear
if it is the file format version or the dataset version. In the former case, this is an important
information for the {{Shapefile}} reader but less for other users. In the later case, it could
be an ISO metadata property.
> * {{dbf}}: a pointer to the underlying {{Database}} object. May be a dangerous things
to expose. If nevertheless we really want to give direct access to the DBF database, maybe
we should return a JDBC {{Connection}} instead.
> h3. Information to be made accessible through a public API
> * {{xmin}}, {{ymin}}, {{xmax}}, {{ymax}}: the spatial extent of the data. Could be made
accessible through the ISO 19115 {{GeographicBoundingBox}} element. However it is unclear
if those elements are always expressed in a geographic CRS or if they can be in a projected
CRS.
> * {{zmin}}, {{zmax}}: the vertical extent of the data. Could be made accessible through
the ISO 19115 {{VerticalExtent}} element. However the {{VerticalCRS}} of that extent is currently
unknown.
> * {{main}}, {{mmax}}: the javadoc does not said what those values are.
> * {{FeatureMap}}: the set of {{Feature}} is indeed important, but maybe we should return
them through some kind of iterator (or a JDK8 {{Stream}} ?) for fetching data on-demand (in
a later implementation, not necessarily now) rather than loading all of them at {{Shapefile}} construction
time.
> h3. Open questions
> * {{ShapeType}}: currently used only in {{Shapefile.toString()}} implementation. Tells
whether the geometries are points, polygons, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message