geophile/geophile

Spatial join, written in Java.

geophile's Issues

SpatialJoin.Filter#overlap method can have narrower parameter types

LEFT and RIGHT of SpatialJoin.Filter<LEFT,RIGHT>#overlap(LEFT, RIGHT) are not subtypes of anything. But I think we can make them extend SpatialObject.
That is,

  interface Filter<LEFT extends SpatialObject, RIGHT extends SpatialObject> {
    boolean overlap(LEFT, RIGHT);
  }

Right now LEFT and RIGHT can become Record or SpatialObject but in fact all the implementations of this interface inside geophile repository are not interested in anything but SpatialObject.

By making this change, user side work will become a bit easier and we can expect a slight performance improvement since Filter implementations will directly access SpatialObjects instead of accessing them through Records. (Yes, I know it will be very slight).

Even if you do not want to break compatibility with implementations of this interface that exist outside the repository, I think we can still do this.

If you are interested in this change, please let me know. I can create a pull request for it.

Examples fail with UnsupportedOperationException

Symptom

Examples bundled with geophile do not work currently. Attached is a stacktrace given by PointsInBox demo.

This failure was apparently introduced in the commit 6f4c402e284e4c405ad4109c000f7a4067d8f8b8 pushed on 11/23/14.

Removing ExampleRecord#copyTo method (or reverting throw new UnsupportedOperationException() to the previous commit) suppresses this failure but judging from your following commit message, this wouldn't be a right solution.

Added a distinction between indexes with stable and unstable records. A stable record, once retrieved from a cursor, never changes. An unstable record may change as a result of cursor operations. This can happen if the record derives its state from the current state of the cursor, for example. Stable records don't have to be copied (using Record.copyTo). There is still one use of Record.copyTo, in some implementations of Index.add. Getting rid of this copy will require an API change.

Fix

I modified a logic in TreeIndex to make it recognize if a record is stable or not.
Also added a test to make sure examples do not throw exceptions. Although it doesn't examine their output, I think still the tests would be useful to know if something is going wrong entirely in examples.

• Pull request: #6

Attached

/usr/lib/jvm/java-7-oracle/bin/java -Didea.launcher.port=7536 -Didea.launcher.bin.path=/opt/idea-IC-162.1628.40/bin -Dfile.encoding=UTF-8 -classpath /usr/lib/jvm/java-7-oracle/jre/lib/charsets.jar:/usr/lib/jvm/java-7-oracle/jre/lib/deploy.jar:/usr/lib/jvm/java-7-oracle/jre/lib/ext/dnsns.jar:/usr/lib/jvm/java-7-oracle/jre/lib/ext/localedata.jar:/usr/lib/jvm/java-7-oracle/jre/lib/ext/sunec.jar:/usr/lib/jvm/java-7-oracle/jre/lib/ext/sunjce_provider.jar:/usr/lib/jvm/java-7-oracle/jre/lib/ext/sunpkcs11.jar:/usr/lib/jvm/java-7-oracle/jre/lib/ext/zipfs.jar:/usr/lib/jvm/java-7-oracle/jre/lib/javaws.jar:/usr/lib/jvm/java-7-oracle/jre/lib/jce.jar:/usr/lib/jvm/java-7-oracle/jre/lib/jfr.jar:/usr/lib/jvm/java-7-oracle/jre/lib/jfxrt.jar:/usr/lib/jvm/java-7-oracle/jre/lib/jsse.jar:/usr/lib/jvm/java-7-oracle/jre/lib/management-agent.jar:/usr/lib/jvm/java-7-oracle/jre/lib/plugin.jar:/usr/lib/jvm/java-7-oracle/jre/lib/resources.jar:/usr/lib/jvm/java-7-oracle/jre/lib/rt.jar:/home/hiroshi/workspace/geophile/target/test-classes:/home/hiroshi/workspace/geophile/target/classes:/home/hiroshi/.m2/repository/junit/junit/4.8.1/junit-4.8.1.jar:/home/hiroshi/.m2/repository/com/vividsolutions/jts/1.13/jts-1.13.jar:/opt/idea-IC-162.1628.40/lib/idea_rt.jar com.intellij.rt.execution.application.AppMain com.geophile.z.examples.PointsInBox
Exception in thread "main" java.lang.UnsupportedOperationException
    at com.geophile.z.examples.ExampleRecord.copyTo(ExampleRecord.java:47)
    at com.geophile.z.index.tree.TreeIndex.add(TreeIndex.java:40)
    at com.geophile.z.space.SpatialIndexImpl.add(SpatialIndexImpl.java:41)
    at com.geophile.z.SpatialIndex.add(SpatialIndex.java:45)
    at com.geophile.z.examples.PointsInBox.run(PointsInBox.java:34)
    at com.geophile.z.examples.PointsInBox.main(PointsInBox.java:24)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

Process finished with exit code 1

SpatialObject not contained in Space causes Space.decompose to throw ArrayIndexOutOfBoundsException

This was reported by Hiroshi Ukai, using JCUnit. Here is the stack:

java.lang.ArrayIndexOutOfBoundsException: -1
at com.geophile.z.space.Region.up(Region.java:100)
at com.geophile.z.space.SpaceImpl.decompose(SpaceImpl.java:93)
at com.geophile.z.space.DecompositionTest.testBoxNotContainedInSpace(DecompositionTest.java:93)

This is not surprising, as SpatialObject's aren't checked for containment by the Space. They should be. Note that checking the level 0 Region is not a sufficient test, as this Region can be larger than the Space. There is currently no good way to check containment because SpatialObject doesn't provide a bounding box method or equivalent.

Duplicates.EXCLUDE is confused by equalTo SpatialObjects.

The following test (added to SelfJoinTest) finds only one pair of spatial objects, (1, 1), with EXCLUDE. With INCLUDE instead, it finds all four combinatins, (0, 0), (0, 1), (1, 0), (1, 1), with duplicates.

@Test
public void checkEqualSpatialObjects() throws IOException, InterruptedException
{
    Index index = new SortedArray();
    SpatialIndex spatialIndex = SpatialIndex.newSpatialIndex(SPACE, index);
    spatialIndex.add(new Box(10, 20, 30, 40));
    spatialIndex.add(new Box(10, 20, 30, 40));
    SpatialJoin spatialJoin = SpatialJoin.newSpatialJoin(KEEP_ALL, SpatialJoin.Duplicates.EXCLUDE);
    Iterator<Pair> iterator = spatialJoin.iterator(spatialIndex, spatialIndex);
    while(iterator.hasNext()) {
        Pair pair = iterator.next();
        SpatialObject left = pair.left();
        SpatialObject right = pair.right();
        System.out.format("%s <> %s\n", left.id(), right.id());
    }
}

Decomposition of Box(70, 90, 40, 90) in lat/lon space causes ArrayIndexOutOfBoundsException

This was discovered while moving FoundationDB to geophile 2.0.1. See SpaceTest.testLatLonDecomposition().

The box that got into trouble is Box(70, 90, 40, 90), (latitude 70 : 90, longitude 40 : 90). The problem is that decomposition grows a region from Box.arbitraryPoint and that the region never includes the top of the box.