Optimize ST_Explode
Geometry type constraint use bytes array instead of Geometry object
This feature prevent H2 from converting WKB to Geometry to check constraints
Fix encoding issue with table engine
javadoc
fix javadoc
Merge pull request #60 from nicolas-f/optimize

Optimize H2GIS

- Geometry type constraint uses bytes array instead of Geometry object
- ST_Explode reads source table only when asking for the first row
fix dbf file import
Add ST_FurthestPoint

For now, if the furthest point is not unique, we return the first one we
find. The return type is POINT.
Make ST_FurthestPoint return ALL furthest pointS.

Now if the furthest point is not unique, we return all furthest points
in a MULTIPOINT. If it is unique, it is returned as a POINT. (In the
java code, the return type is `Puntal`.)
Add ST_LocateAlong

Note: PostGIS does not support polygonal elements. Also their examples
don't seem to correspond to their function signature. See
        http://postgis.refractions.net/docs/ST_LocateAlong.html

TODO?: Take holes into account?
Add ST_ClosestPoint (formerly ST_NearestPoints)

This new H2GIS function is related to the old GDMS function as follows:
```mysql
ST_ClosestPoint(geomA, geomB) = ST_NearestPoints(geomB, geomA)
```
It returns the 2D point on `geomA` closest to geomB. Note that the GDMS
function `ST_ProjectTo` is just a special case:
```mysql
ST_ClosestPoint((multi)linestring, point) = ST_ProjectTo(point, (multi)linestring)
```
For this reason, we will not implement `ST_ProjectTo` in H2GIS.

*Note*: If the closest point on geomA is not unique (it is easy to
imagine an example where there are infinitely many, mathematically
speaking), `ST_ClosestPoint` returns the first one it finds when
traversing geomB's coordinates, so the point returned depends on the
ordering of geomB's coordinates.

TODO: Rename `ST_FurthestPoint` -> `ST_FurthestCoordinate`, since this
function returns coordinates and not points.

TODO: Implement `ST_ClosestCoordinate`, which will return the closest
coordinate (rather than the closest point). (By request of @gpetit)

TODO?: Add `ST_3DClosestPoint`? See
        http://www.postgis.org/docs/ST_3DClosestPoint.html
Add a unit test to clarify ST_ClosestPoint

It was ambiguous which point was returned by ST_ClosestPoint when there
were infinitely many closest points. This unit test shows that the point
returned by ST_ClosestPoint depends on the orientations of geometries A
and B. If they have the same orientation, the point returned is the
first point found in A. If they have opposite orientation, the point
returned is the point of A closest to the first point found in B.
Rename ST_FurthestPoint -> ST_FurthestCoordinate

This function returned the furthest coordinate rather than the furthest
point.
Add ST_ClosestCoordinate

This function was not a part of GDMS or PostGIS but was added for
completeness (cf. ST_FurthestCoordinate).

TODO?: Add ST_FurthestPoint? (Not implemented in JTS)
Merge pull request #61 from nicolas-f/fix/59

Fix encoding issue with table engine. Fixes #59.
Merge pull request #62 from agouge/distance-fns

Here we add the following distance functions:

* `ST_ClosestCoordinate(Point point, Geometry geom)`
* `ST_ClosestPoint(geometry geomA, geometry geomB)`
* `ST_FurthestCoordinate(Point point, Geometry geom)`
* `ST_LocateAlong(Geometry geom, double segmentLengthFraction, double offSet)`

Fixes #42.

### Comparison to GDMS and PostGIS

#### `ST_ClosestCoordinate`

This function was not a part of GDMS or PostGIS but was added for
completeness (cf. `ST_FurthestCoordinate).`

#### `ST_ClosestPoint`

This new H2GIS function is related to the old GDMS function as follows:
```mysql
ST_ClosestPoint(geomA, geomB) = ST_NearestPoints(geomB, geomA)
```
(Note the reversed order.) It returns the 2D point on `geomA` closest to geomB.
Note that the GDMS function `ST_ProjectTo` is just a special case:
```mysql
ST_ClosestPoint((multi)linestring, point) = ST_ProjectTo(point, (multi)linestring)
```
For this reason, we will not implement `ST_ProjectTo` in H2GIS.

*Note*: If the closest point on geomA is not unique (it is easy to imagine an
example where there are infinitely many, mathematically speaking), the point
returned by `ST_ClosestPoint` depends on the orientations of geometries A and
B. If they have the same orientation, the point returned is the first point
found in A. If they have opposite orientation, the point returned is the point
of A closest to the first point found in B. See the [unit test](https://github.com/agouge/H2GIS/blob/99d8cbe8f21687f607a4ac803598690604c05ae6/h2spatial-ext/src/test/java/org/h2gis/h2spatialext/SpatialFunctionTest.java#L907).

*Note*: PostGIS has 3D support. See
        http://www.postgis.org/docs/ST_3DClosestPoint.html

*TODO*?: Add `ST_FurthestPoint?` (This is not implemented in JTS, and
the implementation is nontrivial.)

#### `ST_FurthestCoordinate`

If the furthest coordinate is not unique, we return all furthest coordinates in
a `MULTIPOINT`. If it is unique, it is returned as a `POINT`. (In the java code,
the return type is `Puntal`.)

#### `ST_LocateAlong`

Note: PostGIS does not support polygonal elements. Also their examples
don't seem to correspond to their function signature. See
        http://postgis.refractions.net/docs/ST_LocateAlong.html

*TODO?*: Should we take holes into account for polygons? For now we consider
only the exterior ring, but it would be pretty easy to add the holes. @gpetit

### Table

| GDMS | PostGIS | H2GIS |
|------|---------|-------|
| ---	| ---	| `ST_ClosestCoordinate(Point point, Geometry geom)` |
| `ST_NearestPoints(Geometry geomB, Geometry geomA)`	| `ST_ClosestPoint(geometry geomA, geometry geomB)`	| `ST_ClosestPoint(geometry geomA, geometry geomB)` |
| `ST_ProjectTo(Geometry point, Geometry (multi)lineString)`	| `ST_ClosestPoint(Geometry (multi)lineString, Geometry point)`	| `ST_ClosestPoint(Geometry (multi)lineString, Geometry point)` |
| `ST_FurthestPoint(Point point, Geometry geom)`	| ---	| `ST_FurthestCoordinate(Point point, Geometry geom)` |
| `ST_LocateAlong(Geometry geom, double segmentLengthFraction, double offSet)`	| `ST_LocateAlong(Geometry geom, float a_measure, float offset)` |	`ST_LocateAlong(Geometry geom, double segmentLengthFraction, double offSet)` |
Wrapper can now be used multiple times
Merge pull request #64 from nicolas-f/fix/dbfimport

Fix dbf file import, add unit test.

There were too many backticks. (TableLocation added them too.)
Merge pull request #63 from nicolas-f/fix/wrapper

Check connection and datasource before wrapping

Dev can now use SFSUtilities.wrapConnection without having to check if the connection is already wrapped.
Fetch master