sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. Le Bihan (JIRA)" <>
Subject [jira] [Commented] (SIS-187) Reduce visibility of Shapefile fields
Date Mon, 07 Dec 2015 03:30:11 GMT


M. Le Bihan commented on SIS-187:

I think we can add this method, if you wish,
But how, reading the javadoc Shapefile API will the user know that e.getRange(0) means X axis,
if it means X ?
If it is the always the case ? Because if I don't know it, or if sometimes e.getRange(0) returns
Y or Z axis instead, I don't see how it would work ?

Currently for displaying few Shapefiles, I am doing calculations with X an Y axis, with a
How would you translate this code with getEnvelope() ?
{code:java}   /**
    * Initialiser la déclaration d'un SVG à partir des informations contenues dans son shapefile,
et des dimensions de la zone cible.
    * @param contenuSVG XHTML recevant le contenu SVG.
    * @param shapeFile Shapefile.
    * @param width Largeur de la zone de destination.
    * @param height Hauteur de la zone de destination.
    * @param styleImageCSS Style CSS de l'image SVG.
    * @param classeImageSVG Classe CSS de l'image SVG.
   private void initialiserSVG(StringBuffer contenuSVG, ShapeFile shapeFile, int width, int
height, String styleImageCSS, String classeImageSVG)
      // Calculer les dimensions de la Viewbox (xmin, ymin, viewPortWidth, viewPortHeight)
d'après la description du shapefile.
      double xmin = shapeFile.getShapefileDescriptor().getXmin();
      double xmax = shapeFile.getShapefileDescriptor().getXmax();
      double ymin = shapeFile.getShapefileDescriptor().getYmin();
      double ymax = shapeFile.getShapefileDescriptor().getYmax();
      double viewPortWidth = xmax - xmin;
      double viewPortHeight = ymax - ymin;
      double weightRotationX = xmin + (viewPortWidth / 2.0);
      double heightRotationY = ymin + (viewPortHeight / 2.0);

      // Attention : pour que le SVG soit représenté dans le bon sens, il faut :
      // - Inverser l'axe des X et des Y.
      // - Lui faire réaliser une rotation de 90°C.
      ajouter(contenuSVG, "xml.svg.debut", toString(width), toString(height), toString(ymin),
toString(xmin), toString(viewPortHeight), toString(viewPortWidth), styleImageCSS, classeImageSVG);
      ajouter(contenuSVG, "xml.svg.groupe.matrice.debut");
      ajouter(contenuSVG, "xml.svg.groupe.rotation.debut", toString(heightRotationY), toString(weightRotationX));

We can add the method, but Shapefile users that are knowing the ESPG Shapefile definition,
are used to manage them with their X, Y, Z, M values shall continue to have these getters
Especially because later you will have some setters too, at the time you will like to produce
yourself a new Shapefile from scratch by the mean of Apache SIS.

> 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