Ok the fieldName generated with the above function is indeed used as a prefix in the Lucene Document.

Using the FQN is at least confusing for this log message:

@Message(id = 131, value = "The field used for the spatial query is not using SpatialFieldBridge: %1$s.%2$s")
SearchException targetedFieldNotSpatial(String className, String fieldName);

If would change the FQN to a literal which makes it understandable when inspecting the index content, like "default " or "defaultSpatial ";
Im adding a space at the end to make sure it doesn't conflict with a java beans property, but maybe this is pointless as it could still conflict with a field whose name is overriden.

Problem is when changing it some tests fail, like when using:

org.apache.lucene.search.Query luceneQuery = builder.spatial().onCoordinates( UserEx.class.getName() )
	.within( 100.0d, Unit.KM ).ofLatitude( 24.0d ).andLongitude( 31.5d ).createQuery();

the troublesome part is "onCoordinates" is being given the field name, explicitly matching the default Spatial field.

I would rather have this working as

org.apache.lucene.search.Query luceneQuery = builder.spatial().onCoordinates()
	.within( 100.0d, Unit.KM ).ofLatitude( 24.0d ).andLongitude( 31.5d ).createQuery();

(auto-applying the implicit spatial field when the argument is omitted)