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 09:41:10 GMT

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

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

The meaning of axes is given by the {{CoordinateReferenceSystem}} associated with the {{Envelope}}.
In may be (_Easting_, _Northing_), or (_Latitude_, _Longitude_), or (_forward_, _starboard_),
or (_South along 0┬░ meridian_, _South along 90┬░ meridian_), _etc_. In Shapefiles, this information
is provided in the {{*.prj}} file. Just saying "X" and "Y" means nothing.

For displaying on screen, the process is more complicated than the above. We need to define
the map projection to use for rendering (OGC calls that _"objective coordinate reference system"_).
It may be the same than the Shapefile one, but not necessarily. Then we need to define the
conversion from _objective CRS_ to screen coordinates by an {{java.awt.geom.AffineTransform}}.
Managing those coordinate operations is the purpose of the {{sis-referencing}} module.

For setting values, we can have a {{setEnvelope(Envelope)}} method (exact API to be determined
later).

I would recommend to remove {{getMinX()}}, {{getMinY()}}, _etc._ completely. We know from
15 years of experience that they looks like good idea at first when the application is very
simple, but become very problematic when we try to handle more complex applications. Future
evolution will be easier if we avoid mistake in SIS from the ground.

> 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