sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <>
Subject [jira] [Commented] (SIS-187) Reduce visibility of Shapefile fields
Date Sun, 06 Dec 2015 22:17:10 GMT


Martin Desruisseaux commented on SIS-187:

About {{xmin}}, {{ymin}}, {{xmax}}, {{ymax}}, {{zmin}} and {{zmax}} I was thinking to something
different. Those fields describe what OGC/ISO standards call _"bounding box"_ or _"envelope"_
(note that there is also _"*geographic* bounding box"_ - I will explain the difference soon).
Envelopes are obviously important information in a geospatial application. Our goal is to
make those information available through an abstract method defined in {{Datastore}}. A client
should be able to use {{Datastore}} without knowing if the data come from a Shapefile or other
formats, unless he wants to use Shapefile-specific features.

We have not yet discussed what should be the {{Datastore}} API for providing the bounding
box or envelope. However it is unlikely to be a series of {{getMinX()}}, {{getMinY()}}, _etc._
methods. There is numerous problems with those method:

* They hard-code the number of dimensions (in Shapefile case, we sometime said "2.5D" because
it is not real 3D). It is more difficult to write code working with an arbitrary number of
dimensions with such API, because it does not encourage the use of loops.
* They are confusing: what is X and what is Y? Often X is defined as the first axis and Y
as the second axis no matter what the axis are. But in all geographic systems defined by EPSG,
the first axis is latitude and the second axis is longitude. Having X for latitude and Y for
longitude brings confusion.
* They provide no help for the users about tricky issue likes crossing the +/-180┬░ longitude.
Most of the time, the users simply ignore those issues, which prevent the application to work
in Pacific regions.

I propose to replace those 6 methods by a single method (would probably need to be completed
for detecting the actual number of dimensions):

public Envelope getEnvelope() {
    GeneralEnvelope e = new GeneralEnvelope(2);   // Put here the number of dimensions (2
in this example).
    e.setRange(0, xmin, xmax);
    e.setRange(1, ymin, ymax);
    return e;

In the particular case where the coordinate reference system (as defined in the {{.prj}} file
that come with the Shapefile) is geographic, the envelope can also be called _"geographic
bounding box"_. As the name imply, a _geographic bounding box_ is a bounding box which is
geographic, i.e. which uses latitude and longitude coordinates in degrees instead than projected
coordinates in metres for instances. In such case the above {{Envelope}} can also be stored
in {{GeographicBoundingBox}}, {{VerticalExtent}} and {{TemporalExtent}} objects. Those objects
are themselves stored (indirectly) in a {{Metadata}} object. But it can be done in a second
step - having an {{Envelope}} for now would already be a good step.

> Reduce visibility of Shapefile fields
> -------------------------------------
>                 Key: SIS-187
>                 URL:
>             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
> * {{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
> * {{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
> * {{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
> 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

View raw message