How might an "average user" approach using spatial. In other words, what
real world issues and constraints would they be using as guides to sift
through these features? I mean, if there is no transparently obvious model
to guide average users, you might as well call the field types
"spatial_alpha", "spatial_beta", etc. and users can use folklore and trial
and error to decide which types to use, and the full, detailed names need
only appear in the field type class attributes.
Is there an updated wiki I can look at to understand this stuff a little
better?
-- Jack Krupansky
-----Original Message-----
From: Smiley, David W.
Sent: Tuesday, September 18, 2012 5:55 PM
To: [email protected] Dev
Subject: Spatial field names in Solr
This past Sunday I added 3 spatial field types to Solr in SOLR-3304:
SpatialTwoDoublesFieldType, SpatialRecursivePrefixTreeFieldType and
SpatialTermQueryPrefixTreeFieldType. Eventually there will also be a
SpatialBBoxFieldType following this naming convention. These are named in a
consistent way based on SpatialStrategy subclasses in the Lucene spatial
module. Of course, Solr 3 introduced PointType and LatLonType.
What do people think of these Solr field type names? They are kind of long;
perhaps the "Field" parts can be removed. Maybe "L4" should precede each of
these names? (a Lucene 4 spatial module reference). It would further
delineate these fields from the Solr native fields.
And about TwoDoubles in particular... I had a tough time coming up with a
name for that in the first place as I wanted to avoid a LatLon variation in
its name as I think that's a bad idea. For whatever reason I didn't simply
choose Point. I opened LUCENE-4374 to rename this SpatialStrategy subclass,
suggesting PointVectorStrategy. But maybe PointStrategy is fine. Ideally
the name suggests something about its implementation since there very well
may be alternative indexing strategies in the future for a given type.
~ David
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
