What SQL datatype should be used to populate a Solr location (spatial) field when using a DataImportHandler?

I have a Solr schema which contains a location field (using the default solr.LatLonType ):

<field name="latlng" type="location" indexed="true" stored="true"/>

And I am trying to populate it using a DataImportHandler. Currently I SELECT the value a开发者_高级运维s nvarchar in the format of 17.74628,-64.70725; however it is not populating the Solr field (it remains empty).

What type and format should this column be in to update the location field in Solr?

solr.LatLonType is a multi-dimensional type; You can define the field type as:

<fieldType name="location" class="solr.LatLonType" subFieldSuffix="_coordinate"/>

Using your field name of "latlng" the schema for the coordinate fields will look like this (notice the "subFieldSuffix" used for the 2 dimensional field type solr.LatLonType):

<field name="latlng" type="location" indexed="true" stored="true" />
<field name="latlng_0_coordinate" type="double" indexed="true" stored="true" />
<field name="latlng_1_coordinate" type="double" indexed="true" stored="true" />

"latlng_0_coordinate" should be the latitude and "latlng_1_coordinate" should be the longitude. Your select statement should load "latlng_0_coordinate" and "latlng_1_coordinate" as doubles.

the previous answer works since you're manually creating the fields that Solr uses to store the lat and long individually, however there's a dynamic field for that purpose.

<!-- Type used to index the lat and lon components for the "location" FieldType --> <dynamicField name="*_coordinate" type="tdouble" indexed="true" stored="false" />

If you check field type location, you might find it uses the suffix _coordinate for their values:

<!-- A specialized field for geospatial search. If indexed, this fieldType must not be multivalued. -->

<fieldType name="location" class="solr.LatLonType" subFieldSuffix="_coordinate"/>

that works for me in Solr 4 beta, and I believe is present since Solr 3.6 or even older. Anyway, just another solution!

Hope this helps.