[
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)
