Thanks for the feedback Andrea. Comments below.
On Tue, Jan 27, 2015 at 2:24 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> On Tue, Jan 27, 2015 at 2:39 AM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> I have been looking at the solr data store that was developed recently
>> and I have a mandate to make some modifications to it. Before proceeding I
>> wanted to bounce the approach off of the group first.
>>
>> First change I need is pretty simple, and it's to support the bounding
>> box field type. [1] Fields of this type are encoded differently than the
>> other existing spatial types, they are encoded as a 4 value tuple rather
>> than wkt. What I was thinking here was just to introduce a simple strategy
>> interface based on the field type. All in all a pretty straight forward
>> modification I think.
>>
>
> Yep, that would be good, there are also other types of geometries we are
> not supporting at the moment,
> so having an interface to extend this further in the future would be
> useful down the road.
>
> Wondering, doesn't this also affect how searches are encoded? Or does the
> bbox type support all the same
> search operators we support for the wkt types?
>
I had the same question, and yes the bbox field type handles all of the
same operations.
>
>
>>
>> The second change is somewhat more involved. At the moment the
>> configuration of the datastore requires the user to specify a field that
>> groups documents in the index into logical layers. Unfortunately this
>> "mapping strategy" does't work with the types of indexes I am working with.
>> So what I would like to do is add an additional strategy. In my case I want
>> to serve up the entire index as a single layer (with potentially a few
>> parameters that would always be included in the filter query made to solr).
>>
>
> Right, this also came up in a thread on geoserver users. The current
> design is by sponsor spec, but towards the end of the development I also
> would have liked to have something more generic, where you would specify a
> name and a SOLR filter to go with it... it was just going to take too
> much time to develop it along with a user interface to go with it.
>
> I see. Not sure what you had in mind for ui but I was thinking this would
just boil down to another text field and perhaps a dropdown to choose the
mapping mode.
> I also did not think that adding an attribute to select the layers
> ownership would have been such a problem, SOLR has ways to add an
> attribute to all documents, and set its value, and documents are
> unstructured anyways. So... is the problem an issue of search efficiency?
>
A couple of problems. First is I am working with customers that have very
large indexes, some more complex than others with index clustering, etc...
so we want to avoid having them do any sort of mass update, and updating
there ingestion pipelines to add the new attribute to new documents, etc...
then is also the question of how to handle documents in multiple layers?
Multi-values attributes perhaps, but I think it gets more complex pretty
quickly.
Second is the static nature of it. We don't know ahead of time what types
of searches people are going to run so we can't really organize the
documents into layers ahead of time. Instead we'll be leaning on the
viewparams feature that is already there.
>
>
>> The approach i am thinking of is to add a "MappingStrategy" interface
>> that would encapsulate how documents in the index are mapped to features.
>> Given the unstructured nature of document storage in lucene I imagine this
>> interface could prove useful in order to support additional future mapping
>> strategies.
>>
>
> Wondering again if this might affect how filters should be encoded, and if
> MappingStrategy should have a say in the filter capabilties, or given
> a chance to alter the filter, or split it in a encodable/not encodable
> part.
>
Yeah, thought about that and we could definitely add filter capabilities to
the new interface. One issue though. Filter capabilities are advertised by
a datastore globally for the datastore. A single document may have fields
with different types, that may have different native filtering
capabilities. Not sure how we handle that... take the union of all filter
capabilities?
>
>
>>
>> The exisitng mapping strategy would of course remain the default and
>> while I was planning to add a few additional data store parameters to
>> control the mapping configuration it will remain 100% backward compatible
>> (important for geoserver users who already have data store configurations
>> out there).
>>
>
> Yep, that would work. I am wondering, the code in GeoServer relies on the
> current mapping strategy also at the level of attribute
> selection, there is dedicated GUI for it.
> How will the new mapping strategy fit into it? Like will the GUI just gets
> disabled because the newer mapping strategy just
> picks the attributes it likes internally?
>
> I was thinking that the attribute selection would remain orthogonal to the
mapping strategy being used. Or am I missing something? At least of the
mapping strategy I plan to implement I don't need to "pre-select" any
attributes. But I guess this is something that we could add to the new
interface.
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> -------------------------------------------------------
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
