[Dev] Spatial4j change ideas, mostly related to Shape

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Dev] Spatial4j change ideas, mostly related to Shape

dsmiley@mitre.org
Administrator
1. Remove JTS sub-packages in Spatial4j, moving classes up a level.

Chris and I are +1.  And I will commence with this within a few days.  See commit comment:
https://github.com/spatial4j/spatial4j/commit/2efcbc3e16a3caa176694a955507911f73441ac8

2. Rename Circle.getDistance() to getRadius() ?

I'm not sure but I think I named it this way instead of radius because I kept seeing "radius" show up in some contexts where it was ambiguous as to wether it was a earth radius figure (such as in Solr 3x's geo parameters?).  But I changed my mind now.

3. Should Rectangle.getArea() be removed?

Seems an odd-ball as it is not on Circle.  Or maybe elevate it to Shape?  RectangleImpl just does a simple getWidth() * getHeight() (i.e. isn't really geospatially aware), by the way.  It's used by a few places in Lucene spatial BBoxStrategy's AreaSimilarity, and in SpatialPrefixTree.getMaxLevelForPrecision…

I vote to get rid of it.

4. Rectangle has these two methods which are *perhaps* not named so great:

  public SpatialRelation relate_yRange(double minY, double maxY, SpatialContext ctx);
  public SpatialRelation relate_xRange(double minX, double maxX, SpatialContext ctx);

Some number of months ago I introduced these two methods because GeoCircle makes good use of them without having to create flat axis rectangles (e.g. either width or height is 0) just to call relate() (this is what it used to do) and because it also improved the structure within RectangleImpl (but I suppose that is not a reason to promote it to the interface).

5. Perhaps RectangleImpl's constructor should be in minX, minY, maxX, maxY order ?  (lower-left point, upper-right point)  

The newly suggested ordering seems more popular out in the wild.

------
And FYI some work needs are triggering me to think about a new BufferedLineString, and 3D geometries to add time, namely just Point3D and BufferedLineString3D for now and maybe Rectangle3D later.  Plus, implementing an extensible WKT parser & formatter.

~ David
_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] Spatial4j change ideas, mostly related to Shape

Itamar Syn-Hershko
inline

On Thu, Jul 19, 2012 at 11:39 PM, Smiley, David W. <[hidden email]> wrote:
1. Remove JTS sub-packages in Spatial4j, moving classes up a level.

Chris and I are +1.  And I will commence with this within a few days.  See commit comment:
https://github.com/spatial4j/spatial4j/commit/2efcbc3e16a3caa176694a955507911f73441ac8

Will this require having JTS also for the basic s4j operation, without polygons?

I'm looking at porting the JTS stuff to spatial4n now (just realized there is already a JTS port to .NET!), and my thought was to allow for 2 versions - one with JTS support and one without.

For many standard operations JTS isn't required, and I don't think dragging it around should be a prerequisite.

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] Spatial4j change ideas, mostly related to Shape

dsmiley
Hi Itamar,
JTS itself will definitely remain optional.  Spatial4j includes some classes for its support of JTS, and there isn't that many of them.  What I am discussing is wether such classes need to belong in several sub-packages or wether they can simply co-exist next to the non-JTS ones.  They will all be in the spatial4j jar either way.
~ David

On Thu, Jul 19, 2012 at 4:56 PM, Itamar Syn-Hershko <[hidden email]> wrote:
inline

On Thu, Jul 19, 2012 at 11:39 PM, Smiley, David W. <[hidden email]> wrote:
1. Remove JTS sub-packages in Spatial4j, moving classes up a level.

Chris and I are +1.  And I will commence with this within a few days.  See commit comment:
https://github.com/spatial4j/spatial4j/commit/2efcbc3e16a3caa176694a955507911f73441ac8

Will this require having JTS also for the basic s4j operation, without polygons?

I'm looking at porting the JTS stuff to spatial4n now (just realized there is already a JTS port to .NET!), and my thought was to allow for 2 versions - one with JTS support and one without.

For many standard operations JTS isn't required, and I don't think dragging it around should be a prerequisite.

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] Spatial4j change ideas, mostly related to Shape

Itamar Syn-Hershko
Thanks for the clarification.

On Fri, Jul 20, 2012 at 12:06 AM, [hidden email] <[hidden email]> wrote:
Hi Itamar,
JTS itself will definitely remain optional.  Spatial4j includes some classes for its support of JTS, and there isn't that many of them.  What I am discussing is wether such classes need to belong in several sub-packages or wether they can simply co-exist next to the non-JTS ones.  They will all be in the spatial4j jar either way.
~ David

On Thu, Jul 19, <a href="tel:2012" value="+9722012" target="_blank">2012 at 4:56 PM, Itamar Syn-Hershko <[hidden email]> wrote:
inline

On Thu, Jul 19, <a href="tel:2012" value="+9722012" target="_blank">2012 at 11:39 PM, Smiley, David W. <[hidden email]> wrote:
1. Remove JTS sub-packages in Spatial4j, moving classes up a level.

Chris and I are +1.  And I will commence with this within a few days.  See commit comment:
https://github.com/spatial4j/spatial4j/commit/2efcbc3e16a3caa176694a955507911f73441ac8

Will this require having JTS also for the basic s4j operation, without polygons?

I'm looking at porting the JTS stuff to spatial4n now (just realized there is already a JTS port to .NET!), and my thought was to allow for 2 versions - one with JTS support and one without.

For many standard operations JTS isn't required, and I don't think dragging it around should be a prerequisite.

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com