: I'm not sure if you worry about it. But I'd argue it isn't natural : anyway. You would do the following instead, which is how any address : book I've ever seen works: : <field name="home" type="LatLonFT"/> : <field name="work" type="LatLonFT"/>
...the home vs work distinction was arbitrary. the point is what if i want to support an arbitrary number of distinct values in a PolyField? ... with your approach any attempt to search for people near X would require me to search for work near X or home near X ... which is analogous to oneof hte main purposes of multivalued fields: so i don't have to uniquely name every Field instance. I might have a thousand unique (but unamed) locations that i want to associate with a document, and i want to search for documents with a location near X ... likewise i might have thousands unique polygons associated with a document and i want to search for documents where one or more polygons overlap with an input polygon (ie: island nations overlapping with the flight path of an airplane). The question is: how can/would PolyFields deal with input like this? .. we've discussed cardniality in the number of fields produced by a single input value, but we haven't really discussed cardinality in the number of input values. : So, maybe the FT can explicitly prohibit multivalued? But, I suppose : you could do the position thing, too. This could be achieved through a : new SpanQuery pretty easily: SpanPositionQuery that takes in a term and : a specific position. Trivial to write, I think, just not sure if it is : generally useful. Although, I must say I've been noodling around with The problem is how do you let the PolyField specify the position when indexing? the last API i saw fleshed out in this discussion didn't give the PolyField any information about how many input values were in any given doc, it just allowed PolyFields to be String=>Field[] black boxes (as opposed to the String=>Field[] black box FieldTYpes must currently be). We can't assume even basic "lastPostion+1" type logic for these polyfields, because differnet input values might produce Filed arrays containing different quantities of fields, with differnet names. if a CartiesienPolyFieldType can get away with only using the grid_level1 and grid_level2 fields for one input value, but other input values require using grid_level2, grid_level2, and grid_level3, then simple position increments aren't enough if a document has multiple values (some of which need 2 different Field names, and others that need 3) -Hoss
