Explicit CoordinateSequence support for XYZM #293

jodygarnett · 2018-07-01T05:59:50Z

Checklist:

Ideally:

proof of fitness with feedback from WKTReader/-Writer enhancement #291 WKT Reader/Writer enhancement

jodygarnett · 2018-07-01T06:00:12Z

This PR is for discussion and feedback and is not ready to be merged.

jodygarnett · 2018-07-17T17:17:07Z

So reading some of the javadocs indicates that it is up to the client code to assign a meaning to dimensions beyond 2.

Son in GeoTools if we have a SRS with dimension 2 and a geometry with dimension 3 we would know we are looking at XYM data.

Based on this we could abandon this PR, but it would mean that only client application could implement WKT Reader/Writer ...

I think I would prefer to make the explicit API change.

jodygarnett · 2018-07-17T17:21:48Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateSequence.java

+   * Returns the number of measures in each coordinate for this sequence.
+   * @return
+   */
+  default int getNumberOfMeasures() {


here is the default interface

jodygarnett · 2018-07-17T17:26:09Z

Discussion in JTS meeting - make an API change:

CoordinateSeqeunce.getNumberOfMeasures()
Coordinate.getZ() - needs some logic based on number of measures and dimension
Coordinate.getM() - needs some logic based on number of measures and dimension

jodygarnett · 2018-07-17T17:28:01Z

@bjornharrtell is the above use of default interfaces going to be okay for transpiling

bjornharrtell · 2018-07-17T19:22:20Z

Not sure, should be possible to fix in case of troubles, so don't let it be a blocker.

basisbit · 2018-07-17T21:22:52Z

could you please specify what Z and M should represent? I guess for Z this is obvious for many use cases, some clarification would still be nice.

dr-jts · 2018-07-17T21:26:55Z

Z is height (to support "2.5 D" - it's not intended to support true 3D at this time).

M is a Measure. The meaning of this is user-dependent, Example uses include: a time value along a trajectory; a "driven distance" along a linear track (e.g. one that takes into account terrain distance).

The only semantics JTS will attach to measures is that it is assumed they can be linearly interpolated along line segments.

jodygarnett · 2018-07-17T21:39:14Z

@basisbit I think we would stick with the SFSQL definition:

Reading the spec they relatively few references to "M" and do not define:

GEOMETRY_TYPE — the type of geometry values stored in this column. The use of a non-leaf Geometry class name from the Geometry Object Model for a geometry column implies that domain of the column corresponds to instances of the class and all of its subclasses. The suffixes "Z", "M" and "ZM" are three distinct copies of the geometry hierarchy as presented in Figure 4. If the value is NULL, then the appropriate GEOMETRY subtype is used consistent with the COORD_DIMENSION and SRID is implied.
COORD_DIMENSION — the number of ordinates used in the complex, usually corresponds to the number of dimensions in the spatial reference system. If an "M" ordinate is included it shall be one greater than the number of dimensions of the spatial reference system.

FObermaier · 2018-07-18T06:21:42Z

Some questions:

CoordinateSequence.getNumberOfMeasures
Does the introduction of getNumberOfMeasures imply changing the meaning of getDimensions (as in GeoTools' CoordinateAccess interface)? If so this would impose a breaking change for CoordinateSequence implementations like PackedCoordinateSequence that are used with a dimension greater than 3.
Coordinate.getZ()
Why, Coordinate already has a z field that we can publicly access?
Coordinate.getM()
Adding a measure member to the Coordinate class bloats it additionally. Coordinate.z is not used for the most part. Or do you want to add some reference to the sequence it belongs to? Either way, I don't think I like it. Access of measure values through the CoordinateSequence is sufficient IMHO.

dr-jts · 2018-07-18T16:10:02Z

@FObermaier my thoughts on answers to your questions:

the semantics of CoordinateSequence.getDimension should not change. It should continue to return the total number of ordinates available.
I think @jodygarnett meant CoordinateSequence.getZ. This returns NaN if no Z dimension was defined.
Again, I think the suggestion is to add CoordinateSequence.getM.

The Z and M accessors are suggested in order to make the support for Z and M explicit in the API (and to match the explicit support in the SFSQL spec).

It might be good to provide a CoordinateSequence.hasZ method, in order to encapsulate the logic of determining this (and this can be made a default interface method). hasM could be provided as well, but does have the fairly trivial equivalent of getNumberOfMeasures == 1

jodygarnett · 2018-07-18T18:27:16Z

Guess I am always confused if M counts as a ordinate with respect to getDimension().

dr-jts · 2018-07-18T18:31:12Z

Yeah, it's confusing. In JTS dimension has always referred to the total number of ordinates available. If we change that not sure what will happen...

If getDimension is changed to be just the number of geometric dimensions, then pretty sure that a getNumberOfOrdinates should be available as well, for ease of iteration.

dr-jts · 2018-07-18T18:56:20Z

Further to the question of the semantics of getDimension, my read of the SFSQL (below) is that getDimension should be the total number of ordinates, including the M value(s) if present, based on the second sentence.

COORD_DIMENSION — the number of ordinates used in the complex, usually corresponds to the number of dimensions in the spatial reference system. If an "M" ordinate is included it shall be one greater than the number of dimensions of the spatial reference system.

jodygarnett · 2018-07-18T21:58:49Z

You can see my quote above about GEOMETRY_TYPE having different values for POINT POINTZ POINTM POINTZM. If we went that approach and reported back the correct SFSQL type .. it would be a pain and not be visible at the CoordinateSequence level.

I would like to keep getDimension() in agreement with the SFSQL spec if we can:

dimension = spatialDimension + numberOfOrdinates

Would rather see an approach using numbers, rather than hasM() and hasZ() methods .. to allow for XYZMN etc...

dr-jts · 2018-07-18T23:03:30Z

I don't understand dimension = spatialDimension + numberOfOrdinates. What is numberOfOrdinates ?

Agreed that a numeric approach is needed (as you say, to allow for measures > 1). But doesn't preclude having the predicates too.

jodygarnett · 2018-07-30T06:12:45Z

@dr-jts and @jnh5y can I ask for a review, I have responded I think to most of the feedback.

I ended up having CoordinateSequence.getDimension() as described in the conversation above, and CoordinateSequence.getMeasures() being the number of measures (so if we have XYZM dimension is 4 and measures is 1.

I also removed the mutability from PackedCoordinateSequence as the factory methods were provided, and there was no need for PackagedCoordinateSequence to hold on to state (especially when their were static constances for PackagedCoordinateSequence.DOUBLE and PackagedCoordinateSequence.FLOAD.

@jnh5y I have introduced the specific Coordinate subclasses as you requested, so we end up with:

Coordinate - stores XYZ, the getM() method always returns Double.NaN
CoordinateXY - both getZ() and getM() return Double.NaN. The field "z" is still visible from superclass but not used
CoordinateXYM
CoordinateXYZM

elahrvivaz · 2018-07-30T15:42:23Z

modules/core/src/main/java/org/locationtech/jts/geom/Coordinate.java

+  public static final int M = 3;
+
+  /**
+   * The x-ordinate.
   */
  public double x;


would it make sense to deprecate direct access to x and y as well? It seems potentially confusing to have coord.x, coord.y and coord.getZ() be the established access pattern

I would like to do so, but discussion with @jnh5y and @dr-jts has me considering if having explicit classes, with access to the primitives, is required. Martin quite correctly focuses on these being primary a data structures, rather than an object.

With java value types on the horizon we are likely to change to the struct idea from C. Really want to have coordinates represent a block of [xy], [xyz], [xym], [xyzm] if continuous memory, so when we make an array of them everything is co-located in memory.

So my design hat agrees with you, prefer getX() and getY(), make them final so the JRE can inline them to avoid performance penalty which is a key concern ...

Have to keep public access to Coordinate x and y fields for backwards compatibility. These could be removed in a future non-compatible version (i,e, JTS 2)

Well, unless a big refactoring is done (as I see @jodygarnett has already done for the z field).

really? I thought it just made compiler warnings?

From the annotation javadocs:

A program element annotated @deprecated is one that programmers
are discouraged from using, typically because it is dangerous,
or because a better alternative exists. Compilers warn when a
deprecated program element is used or overridden in non-deprecated code.

In anycase I have it commended it as deprecated as the javadoc approach allows a message to be provided

Well, yes, warnings not errors. Still, it's nice to allow compiling warning-free.

my $0.02 - probably a good idea to comment and also mark them. the compiler warnings are useful to raise awareness that users should be moving away from the methods, whereas most wouldn't notice a comment change and then face an unexpected compile failure whenever they actually go away.

LOL emitting warnings so people change their code is entirely the point. Then they change their code and the warnings go away

I have been in situations where compile-time warnings trigger a rejection of the update to the library, and it is not possible to change the client code. So I'm very wary of deprecating things until at least a few releases containing the alternative functionality.

elahrvivaz · 2018-07-30T15:46:18Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateSequence.java

+   */
+  default double getM(int index) {
+     if( getDimension() > 2 && getMeasures() > 0 ) {
+	 final int mIndex = getDimension()-getDimension();


should this be getDimension() - getMeasures()?

yes, yes it should. And I should have test cases before this goes live :)

elahrvivaz · 2018-07-30T15:49:10Z

modules/core/src/main/java/org/locationtech/jts/geom/Coordinates.java

+	    return 2;
+	}
+	else if(coordiante instanceof CoordinateXYM) {
+	    return 2;


should this be 3?

elahrvivaz · 2018-07-30T15:51:38Z

modules/core/src/main/java/org/locationtech/jts/geom/impl/PackedCoordinateSequence.java

-          coords[i * this.dimension + 2] = coordinates[i].z;
+          coords[i * this.dimension + 2] = coordinates[i].getOrdinate(2); // Z or M
+        if (this.dimension >= 4)
+            coords[i * this.dimension + 2] = coordinates[i].getOrdinate(3); // M


should this be + 3?

jodygarnett · 2018-08-01T06:58:02Z

Okay folks test case written, this has collected all feedback provided.

This example may need to be rewritten to support arbitrary dimensions and measures

jnh5y · 2018-08-06T16:17:04Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateSequence.java

   *
   * @param index  the coordinate index in the sequence
-   * @param ordinateIndex the ordinate index in the coordinate (in range [0, dimension-1])
+   * @param ordinateIndex the ordinate index in the coordinate (in range [0, dimension-numberOfMeasures-1])


I'm not sure about the range here. It seems to me that the range would still be [0, dimension-1].

The bit from [0, dimension-numberOfMeasures-1] would be the XY(Z) values. For numberOfMeasures > 0, the bit from [dimension-numberOfMeasures, dimension-1] would the measures.

Yeah I think you are right, since we did not end up with a separate getMeasure method.

@param ordinateIndex the ordinate index in the coordinate (in range [0, dimension-1])

Should you update this line of documentation then?

jnh5y · 2018-08-06T16:17:18Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateSequence.java

@@ -133,7 +221,7 @@
   * Sets the value for a given ordinate of a coordinate in this sequence.
   *
   * @param index  the coordinate index in the sequence
-   * @param ordinateIndex the ordinate index in the coordinate (in range [0, dimension-1])
+   * @param ordinateIndex the ordinate index in the coordinate (in range [0, dimension-numberOfMeasures1])


numberOfMeasures instead of numberOfMeasures1

Remaining typo.

jnh5y · 2018-08-06T16:19:34Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateXY.java

+      case X: return x;
+      case Y: return y;
+      }
+      throw new IllegalArgumentException("Invalid ordinate index: " + ordinateIndex);


Should this be the 'default' case in the switch?

that would also be a valid way to represent it.

jnh5y · 2018-08-06T16:20:39Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateXYM.java

+  /** Default constructor */
+  public CoordinateXYM() {
+    super();
+    this.m = 0.0;


Do x and y default to 0.0?

Default constructor is:

Constructs a Coordinate at (0,0,NaN).

jnh5y · 2018-08-06T16:22:01Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateXYM.java

+
+  public CoordinateXYM(Coordinate coord) {
+    super(coord.x,coord.y);
+    m = getM();


Can you remind what the default value for an uninitialized double is?

inconsistent, 0 for a spatial dimension (XY), DnD for an optional value (Z)

jnh5y · 2018-08-06T16:23:40Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateXYZM.java

@@ -0,0 +1,96 @@
+/*
+ * Copyright (c) 2016 Vivid Solutions.


We should standardize on the copyrights going forward.

jnh5y · 2018-08-06T16:25:23Z

modules/core/src/main/java/org/locationtech/jts/geom/CoordinateXYZM.java

+    }
+  }
+
+  public String toString() {


On the topic of the 'toString' methods... It seems that the original Coordinate.toString has ()'s. Should we be careful here?

So original is Coordinate:

return "(" + x + ", " + y + ", " + z + ")";

And ExtendedCoordinate:

String stringRep = x + " " + y + " m=" + m; return stringRep;

I am happy to go with '(', kind of like the use of 'm=' so it is clear when measures are in play.

+1, I like it.

jnh5y · 2018-08-06T16:29:23Z

modules/core/src/main/java/org/locationtech/jts/geom/Coordinates.java

+    } else if (dimension == 4 && measures == 1) {
+      return new CoordinateXYZM();
+    }
+    return new Coordinate();


Hmm... This seems a tough case to handle properly...

I think I should make a CoordinateSequence.createCoordinate() method, it will make the ExtendedCoordinateSequence example easier to work with as well. If not we are demanding that these subclasses be used which is poor design.

jnh5y · 2018-08-06T16:32:55Z

modules/core/src/main/java/org/locationtech/jts/geom/impl/CoordinateArraySequence.java

@@ -153,7 +201,12 @@ public Coordinate getCoordinateCopy(int i) {
  public void getCoordinate(int index, Coordinate coord) {


As a sanity check, this seems like an easy place for a user to do something silly. If they pass in the wrong kind of Coordinate, they could get a no-Z/M-support error message, right?

In JTS 2.0, it'd be great to see if we can be clever enough to handle this at the type-system.

In this case we trust the coord set methods to handle things appropriately.

jnh5y · 2018-08-06T16:33:10Z

modules/core/src/main/java/org/locationtech/jts/geom/impl/CoordinateArraySequence.java

+    } else {
+      return Double.NaN;
+    }
+


Extra newline.

jnh5y · 2018-08-06T16:34:04Z

modules/core/src/main/java/org/locationtech/jts/geom/impl/CoordinateArraySequence.java

@@ -178,9 +256,9 @@ public double getOrdinate(int index, int ordinateIndex)
    switch (ordinateIndex) {
      case CoordinateSequence.X:  return coordinates[index].x;
      case CoordinateSequence.Y:  return coordinates[index].y;
-      case CoordinateSequence.Z:  return coordinates[index].z;
+      default:
+	      return coordinates[index].getOrdinate(ordinateIndex);


Sanity check, does one get Double.NaN or an exception if they go out of bounds?

found it was a little inconsistent. My understanding is exception if you are out of bounds, DnD if you are in bounds buy the value is undefined.

jnh5y · 2018-08-06T16:36:04Z

modules/core/src/main/java/org/locationtech/jts/geom/impl/CoordinateArraySequenceFactory.java

+    if (dimension < 2)
+      dimension = 2; // handle bogus dimension
+    if (dimension - measures < 2) {
+      throw new IllegalArgumentException("max spatial dimension 2 required");


Do you mean 'Minimum spatial dimension of 2 required'? (I'm also a fan of dumping the inputs. E.g. "Minimum spatial dimension of 2 required. Input dimension was $dimension, input number of measures was $measures.")

jnh5y · 2018-08-06T16:38:09Z

modules/core/src/main/java/org/locationtech/jts/geom/impl/PackedCoordinateSequence.java

@@ -271,14 +300,14 @@ public Double(Coordinate[] coordinates, int dimension) {
     * @param coordinates
     */
    public Double(Coordinate[] coordinates) {
-      this(coordinates, 3);
+      this(coordinates, 3,0);


(Picky) space after the comma.

aside: I could not find any code formatting guidelines for the project, I setup some defaults that kind of matched in my IDE an hoped for the best.

jnh5y · 2018-08-06T16:44:56Z

modules/core/src/test/java/org/locationtech/jts/geom/CoordinateTest.java

+      assertEquals( xym, coord );
+      assertTrue( !xym.equalInZ(coord,0.000001) ); 
+  }
+  public void testCoordinateXYMZ() {


Should be testCoordinateXYZM

jnh5y · 2018-08-06T16:51:58Z

modules/core/src/test/java/org/locationtech/jts/geom/impl/PackedCoordinateSequenceTest.java

+    Coordinate coord;
+    Coordinate[] array;
+
+    initProgression(seq);


Is there an easy way to share this test code with the other class?

Could place it in the superclass, the two tests are slightly different though. Since one store the coordinate instances (so == returns true) and one does not (so == returns false).

Could have an override-able method around that check?

jnh5y · 2018-08-06T16:52:33Z

modules/core/src/test/java/org/locationtech/jts/io/WKBTest.java

@@ -151,7 +151,7 @@ private void runWKBTest(String wkt) throws IOException, ParseException

 	private void runWKBTestPackedCoordinate(String wkt) throws IOException, ParseException {
 		GeometryFactory geomFactory = new GeometryFactory(
-				new PackedCoordinateSequenceFactory(PackedCoordinateSequenceFactory.DOUBLE, 2));
+				new PackedCoordinateSequenceFactory(PackedCoordinateSequenceFactory.DOUBLE));


What's the default dimension of the PackedCoordinateSequenceFactory?

-dimension 3, measures 0, you can see in the constructors.-

update: the above was incorrect, there is no default code is intended to use the factory to create the coordinate sequence they want.

Then this is a change, no? Here we are testing getting a PCSF which creates things of dimension 2, right?

Also, a WKBReader should be able to return values which have any 2, 3, and 4 dimensions...

Oh here is the deal, the previous implementation of the factory was modal! So it held on to the init value 2 and would use it as a default for some of the create methods.

I removed this modal functionality since it introduced the possibility for error, especially with the static final factory implementations. Any thread could change the "default" messing up another thread.

So the above change is on purpose.

jnh5y · 2018-08-06T16:53:19Z

pom.xml

@@ -193,7 +193,7 @@
                <version>2.15</version>
                <configuration>
                    <includes>
-                        <include>**/*Test.java</include>
+                        <include>**/*Test.`java`</include>


Does this affect anything?

eek! probably. Just reverted it, everything still builds.

jnh5y · 2018-08-06T16:56:11Z

@jodygarnett ok, I finished a read-through. Looks pretty close.

jodygarnett · 2018-08-06T17:26:26Z

Thanks @jnh5y I will update based on your feedback, and then we really have to call it done as I do not have more time to put towards it.

Based on the above how do you feel about:

CoordinateSequence.createCoordinate()
Either going ahead with (c) Vivid Solutions, and others or reverting to (c) Vivid Solutions. Can you ask and let us know what to do?

jratike80 · 2018-08-07T07:52:50Z

I can read "coordiante" in quite many places, like CoordianteSequence.createCoordiante(). Are they typos or something intentional?

jodygarnett · 2018-08-07T14:36:00Z

typos, fixed comments will need to check codebase

jnh5y · 2018-08-07T16:30:52Z

modules/core/src/main/java/org/locationtech/jts/geom/Coordinates.java

@@ -0,0 +1,90 @@
+/*
+ * Copyright (c) 2016 Vivid Solutions


Copyright clean-up.

jnh5y

There are some minor typos left to address. Also, we should update the copyright headers before merging.

jnh5y · 2018-08-07T16:34:44Z

@dr-jts Any more comments on this? I'd like to merge this PR later this week if there are no understanding issues.

jodygarnett added 2 commits June 30, 2018 22:39

clean up java comparable and comparator warnings

f8b0460

Add CoordinateSequence.getNumberOfMeasures() default method

175f9bd

jodygarnett commented Jul 17, 2018

View reviewed changes

jodygarnett added 2 commits July 29, 2018 23:03

Coordiante accessor methods for getX, getY, getZ, getM

92d9c78

Introduce CoordinateXY, CoordinateXYM, CoordinateXYZM

a5bf1fe

jodygarnett requested review from jnh5y and dr-jts July 30, 2018 06:05

elahrvivaz reviewed Jul 30, 2018

View reviewed changes

jodygarnett added 3 commits July 30, 2018 09:52

improved javadocs

e205f46

test coordinate subclasses and packed coordinate sequence

73de93e

confirm using factory to copy coordiante sequence works as expected

6f7eb4f

jodygarnett added 2 commits August 1, 2018 00:54

Updated CoordinateArraySequence to support measure

91e7371

ExtendedCoordinateSequence correctly reports measure

c182d55

This example may need to be rewritten to support arbitrary dimensions and measures

jnh5y reviewed Aug 6, 2018

View reviewed changes

revise based on feedback

9094b31

jnh5y reviewed Aug 7, 2018

View reviewed changes

jnh5y approved these changes Aug 7, 2018

View reviewed changes

address typos and header feedback

34178b1

jodygarnett merged commit 412bf17 into locationtech:master Aug 7, 2018

mprins mentioned this pull request Aug 25, 2018

[WIP] upgrade JTS to current release GeoLatte/geolatte-geom#69

Merged

dr-jts added type-improvement jts-core labels Jan 10, 2019

		@@ -153,7 +201,12 @@ public Coordinate getCoordinateCopy(int i) {
		public void getCoordinate(int index, Coordinate coord) {

Explicit CoordinateSequence support for XYZM #293

Explicit CoordinateSequence support for XYZM #293

Conversation

jodygarnett commented Jul 1, 2018 • edited

jodygarnett commented Jul 1, 2018

jodygarnett commented Jul 17, 2018 • edited

Choose a reason for hiding this comment

jodygarnett commented Jul 17, 2018 • edited

jodygarnett commented Jul 17, 2018

bjornharrtell commented Jul 17, 2018

basisbit commented Jul 17, 2018

dr-jts commented Jul 17, 2018

jodygarnett commented Jul 17, 2018

FObermaier commented Jul 18, 2018 • edited

dr-jts commented Jul 18, 2018

jodygarnett commented Jul 18, 2018

dr-jts commented Jul 18, 2018

dr-jts commented Jul 18, 2018 • edited

jodygarnett commented Jul 18, 2018 • edited

dr-jts commented Jul 18, 2018

jodygarnett commented Jul 30, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elahrvivaz Jul 30, 2018 • edited

Choose a reason for hiding this comment

jodygarnett commented Aug 1, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jodygarnett Aug 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jodygarnett Aug 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jodygarnett Aug 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jodygarnett Aug 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jodygarnett Aug 6, 2018 • edited

Choose a reason for hiding this comment

jnh5y commented Aug 6, 2018

jodygarnett commented Jul 1, 2018 •

edited

jodygarnett commented Jul 17, 2018 •

edited

jodygarnett commented Jul 17, 2018 •

edited

FObermaier commented Jul 18, 2018 •

edited

dr-jts commented Jul 18, 2018 •

edited

jodygarnett commented Jul 18, 2018 •

edited

jodygarnett commented Jul 30, 2018 •

edited

elahrvivaz Jul 30, 2018 •

edited

jodygarnett Aug 6, 2018 •

edited

jodygarnett Aug 6, 2018 •

edited

jodygarnett Aug 6, 2018 •

edited

jodygarnett Aug 6, 2018 •

edited

jodygarnett Aug 6, 2018 •

edited

jodygarnett commented Aug 6, 2018 •

edited

jodygarnett commented Aug 7, 2018 •

edited