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 15:00:17 GMT

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

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

When no {{AXIS}} elements are explicitly declared, the default are (_longitude_, _latitude_)
for geographic CRS ({{GEOGCS}}), (_easting_, _northing_) for projected CRS ({{PROJCS}}), (_X_,
_Y_, _Z_) for geocentric CRS. Those default values are inferred from WKT 1 specification.
So in the above RGF 93 specification there is still no ambiguity.

A Shapefile creator may legitimately use the shapefile "Z" axis for time. This is precisely
the reason why we can not call this axis "Z", except in shapefile internal mechanic (but not
in public API). If that Shapefile has a correct {{.prj}} file, they will be no mistake - {{sis-referencing}}
will put the correct axis orientations. So to in summary: a {{DataStore}} should never assume
that an axis is X, an other axis is Y, etc. The SIS referencing module does the correct job
in the majority of cases, provided that the {{.prj}} file or the EPSG code associated with
the data store are not wrong.

> 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