jira at apache
Jul 5, 2012, 7:58 PM
Post #8 of 8
(88 views)
Permalink
|
|
[jira] [Commented] (LUCENE-4188) Storing Shapes shouldn't be Strategy dependent
[In reply to]
|
|
[ https://issues.apache.org/jira/browse/LUCENE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407668#comment-13407668 ]
Chris Male commented on LUCENE-4188:
------------------------------------
{quote}
The client doesn't have to use this method, but in all tests + the Solr adapters I don't think there's a reason not to. I found it to be useful, and to provide a place to document how it is recommended to store the shape (notice I even included the one-liner source in the javadocs). An advantage of it being an instance method on the Strategy is that it has convenient access to both the field name & SpatialContext. I could make this method final, and I could add more documentation that makes it clear that the user is free to store the shape in any way they wish since the spatial module doesn't care.
{quote}
I think it is a misnomer to say this is how we recommend a shape is stored. That is exactly what I disagree with and why I want it changed from how it is currently. To me the recommended way, if the consumer already has a String representation of the Shape that they used to construct the Shape, is to just store that String rather than re-parsing the Shape. I also dont like the use of SpatialContext. It represents Shapes in a non-standard way, sometimes using WKT (if you're using JtsSpatialContext) and sometimes not. Yes it is symmetrical with the readShape code, but that is only helpful if you use the Context to read your shapes in the first place.
Thinking about it, I think we need to improve the Shape reading code in SpatialContext so that it is clear what representation is used and so it is possible to extend the functionality when you want to use anything other than Strings.
> Storing Shapes shouldn't be Strategy dependent
> ----------------------------------------------
>
> Key: LUCENE-4188
> URL: https://issues.apache.org/jira/browse/LUCENE-4188
> Project: Lucene - Java
> Issue Type: Bug
> Components: modules/spatial
> Reporter: Chris Male
> Assignee: David Smiley
> Attachments: LUCENE-4188_remove_field_storage_from_createField.patch
>
>
> The logic for storing Shape representations seems to be different for each Strategy. The PrefixTreeStrategy impls store the Shape in WKT, which is nice if you're using WKT but not much help if you're not. BBoxStrategy doesn't actually store the Shape itself, but a representation of the bounding box. TwoDoubles seems to follow the PrefixTreeStrategy approach, which is surprising since it only indexes Points and they could be stored without using WKT.
> I think we need to consider what storing a Shape means. If we want to store the Shape itself, then that logic should be standardised and done outside of the Strategys since it is not really related to them. If we want to store the terms being used by the Strategys to make Shapes queryable, then we need to change the logic in the Strategys to actually do this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] lucene
For additional commands, e-mail: dev-help [at] lucene
|
