On 3/10/14, 12:56 PM, "javinsnc" <javiersangra...@mitula.com> wrote: >>> >>>/*********************/ >>>/* Document contents */ >>>/*********************/ >>>I have tried with 3 different content for my documents (lat-lon refers >>>to >>>Madrid, Spain): >> >> Um…. Just to be absolutely sure, are you adding the data in Solr’s XML >> format, which is this?: >> >> XML Formatted Index Updates >> >><https://cwiki.apache.org/confluence/display/solr/Uploading+Data+with+ >>Index >> +Handlers#UploadingDatawithIndexHandlers-XMLFormattedIndexUpdates> >> >> I am not sure If I understand you properly. I index the documents with >> Lucene, not with not with update handler of solr. Maybe here is the >> problem. Can you set the type of the field (apart from >> < >> fieldType defined in schema.xml) when indexing in Lucene? Months ago, I >> needed to index a LONG field, I do the trick with this aproach and it >> works. >> >> One thing is how Solr retrieve he data (defined in schema.xml with its >> <fieldType >> > >> ) and other thing is how lucene index the field, right?
This is indeed the source of the problem. Why do you index with Lucene’s API and not Solr’s? Solr not only has a web-service API but it also has the SolrJ API that can embed Solr — EmbeddedSolrServer. I only recommend embedding Solr in limited circumstances as it’s more flexible and usually plenty fast to communicate with Solr normally, or to easily customize Solr to load data from a custom file and so the indexing is all in-process. You would do the latter with either a custom DataImportHandler piece or a “ContentStreamLoader subclass. >> >> >> The examples you give below are the *output* XML format which is not the >> same as the input format. In particular you don’t give arrays of values >> to Solr; you simply give more than one field element that has the same >> name. >>> >>> >>>a) As it is WKT format, I tried "longitude latitude" (x y) >>> >> <doc> >>> >> <arr name="LOCATION"> >>> >> <str> >> -3.69278 40.442179 >> </str> >>> >> </arr> >>> >> </doc> >> That should work but I don’t recommend that, as a matter of taste, if >>all >> your data is in latitude & longitude, as opposed to projected data or >>any >> other spatial data. >> >> What do you recommend? >> >> With "all your data is in latitude & longitude", do you refer that every >> doc in the index has only the field LOCATION? If the answer is yes, then >> no, there is more fields in all the documents. I’m only talking about the spatial field. I mean if your *spatial data* is entirely data points where the two dimensions are latitude and longitude on the surface of the earth (or hypothetically some other spherical place). ~ David
