Spatial4j deprecated shape string formats other than WKT, leaving such things (like "lat,lon" and a couple other formats) for clients to do in any way they want. The non-WKT parser is now in LegacyShapeReadWriterFormat. I'd like to roll this change on through Lucene-spatial. So a Lucene-spatial user that wants to parse a "lat,lon" format or whatever has to handle this themselves. It's easy; I've updated the example demo test accordingly. They can still call ctx.readString(str) to get the legacy behavior, but I'm going to modify SpatialArgsParser to not use it; just WKT. SpatialArgsParser is what parses strings like "Intersects(SHAPE_FORMAT) distErrPct=0.025". I'll make it easy to subclass the parser for a client to parse other formats.

On the Solr subclass of SpatialArgsParser, I'll use LegacyShapeReadWriterFormat in the 4x branch for back-compat, but on trunk I want to only support "lat, lon" and "x y" (and WKT of course) – no more "Circle(x y d=mydist)" and no more "xMin, xMax, yMin, yMax". People using these should use {!geofilt} when possible. The WKT (as implemented in Spatial4j) equivalents to the 2 deprecated formats are "BUFFER(POINT(X Y), MYDIST)" and "ENVELOPE(xMin, xMax, yMax, yMin)" respectively. Note the quirky arg order for ENVELOPE (blame OGC's spec for that one).

If anyone has input on preferences as to which layer (Lucene/Solr) at which version (trunk/4x) should support what syntax then please share – otherwise I'll go with the plan above. I'm almost done with the patch.

+1 to update spatial4j

In 4x, we should make sure existing user query syntax continues to work (perhaps logging a warning in solar). 5x can drop the funky syntax

I'm moving some point parsing utilities and some specialized distance calculations (e.g. DistanceUtils.vectorDistance()) from Spatial4j that are only used by Solr, into Solr.

Patch attached. It was a bit of work because I weened Lucene/Solr off all of Spatial4j's deprecated things. I added a test to show that the old circle and rect syntax still work in Solr but there's no trace of it anywhere else. And instead of simply copying ParseUtils into Solr, I really wanted to improve and simplify it and all code using it. It's now "SpatialUtils" with just one real point parsing method. Arguably that should have been a separate Solr issue, but it's just an internal refactor.

I still need to actually release Spatial4j 0.4 but I was waiting for me to finish this patch. I'll release it tomorrow.

I'll commit this patch in ~24 hours, subject to feedback. I will open a separate issue for Solr to remove the old circle & rect format from trunk, and to ask a relation question about point formats.

Updated patch for released version of Spatial4j today, including sha1's, and the notice.txt. Also, I added back-compat for the worldBounds option to rewrite the old rect syntax, if supplied, to ENVELOPE.

I meant to say commit in 48 hours, not 24. And I'm on travel this week (NYC) so we'll see.

Commit 1561129 from David Smiley in branch 'dev/trunk'
[ https://svn.apache.org/r1561129 ]

LUCENE-5395: Upgrade Spatial4j 0.4. Moved away from stuff deprecated in Spatial4j.

Commit 1561142 from David Smiley in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1561142 ]

LUCENE-5395: Upgrade Spatial4j 0.4. Moved away from stuff deprecated in Spatial4j.

Commit 1561238 from David Smiley in branch 'dev/trunk'
[ https://svn.apache.org/r1561238 ]

LUCENE-5395: calculated sha1 via "ant jar-checksums" this time

Commit 1561239 from David Smiley in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1561239 ]

LUCENE-5395: calculated sha1 via "ant jar-checksums" this time

Commit 1561250 from David Smiley in branch 'dev/trunk'
[ https://svn.apache.org/r1561250 ]

LUCENE-5395: use Locale.ROOT

Commit 1561251 from David Smiley in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1561251 ]

LUCENE-5395: use Locale.ROOT