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-183) Basic Geometry Operations
Date Mon, 13 Oct 2014 04:27:33 GMT

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

Martin Desruisseaux commented on SIS-183:
-----------------------------------------

Thanks Mark for the proposal. We have no domain model specifically for Geotk. However we use
the OGC/ISO international standard as our domain model for large parts. The OGC standards
(not the ISO ones) can be downloaded for free, but there is so many of them that one can be
lost. We try to provide an overview for Apache SIS here:

* http://sis.apache.org/book/en/developer-guide.html

This is a work in progress, really just scratching the surface for now. If you have a chance
to take a look to this document, any help improving clarity or completing the document would
be greatly appreciated :-).

About the port of Geotk objects, it depends if we talk about geometries or other modules.
If the focus is on geometry, then there is not many thing that we can get from Geotk - we
are probably better to start from scratch in Apache SIS. If there is interest in other modules,
then maybe we should open a separated thread?

On geometry-related classes, Apache SIS currently contains 3 very basic types. Note that none
of them are formally geometry, in that they do not extends any {{Geometry}} base class:

* http://sis.apache.org/apidocs/org/apache/sis/geometry/GeneralDirectPosition.html
* http://sis.apache.org/apidocs/org/apache/sis/geometry/GeneralEnvelope.html
* http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/extent/DefaultGeographicBoundingBox.html

The domain model for a more complete geometry library would be the ISO 19107 specification.
However this specification is under revision right now, which complicate the task of creating
an implementation now. This domain model has been translated (with some differences) into
Java API there:

* http://www.geoapi.org/snapshot/pending/org/opengis/geometry/package-summary.html
* Sub-packages of above

However in its current state, the above is a mix of ISO 19107 formal release, ISO 19107 draft,
and a few idea from an other library (Java Topology Suite (JTS)). It is guaranteed to change,
and would at least need a little bit of cleaning before to implement them.

So would you like to work on geometry or on other aspects? If the work would be on geometry,
I see two paths (we would probably need to do both anyway):

* Define a set of classes close to the above-cited API (without implementing the interfaces
for now). The implementation would delegate the work to the ESRI library or an other library.
In other words, just wraps an existing library into an ISO 19107 API.
* Define a set of classes close to the above-cited API, and try to provide a truly 3-dimensional
implementation of them (if we do only a two-dimensional implementation in a Cartesian space,
I don't think that our library would have an advantage over the existing ESRI and JTS ones).


> Basic Geometry Operations
> -------------------------
>
>                 Key: SIS-183
>                 URL: https://issues.apache.org/jira/browse/SIS-183
>             Project: Spatial Information Systems
>          Issue Type: Wish
>          Components: Geometry objects
>         Environment: java 6 or 7
>            Reporter: Mark Giaconia
>
> It would be very useful to have some basic geometry operations available, such as:
> - Read WKT, CSV, or shapefile into a geometry object in which the attribute tables are
stored as a HashMap, geom projection info etc.
> - Buffer, and intersect (contains, within, overlaps equivalent in RDBMSs) operations
via a method for passing in a geom to compare against a geom collection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message