lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Wright (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
Date Wed, 13 Apr 2016 07:13:25 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238305#comment-15238305
] 

Karl Wright edited comment on LUCENE-7202 at 4/13/16 7:12 AM:
--------------------------------------------------------------

bq. I give up on the issue though, this is just making spatial harder to use.

This is a discussion ticket.  It's about coming up with ideas and eventually choosing the
best ones.  I'm not sure I get your bike analogy, but I can assure you that *my* goal is to
not making things harder to use.  Given that, what is your preferred direction?  Is your issue
that there are there too many implementations?  Or is it your desire that we leave things
as they are?  If you are serious that we should just go home and let people figure out their
own encoding and roll their own spatial implementation, then there's not much further discussion
possible?

I thought MortonPoint/LatLonPoint/XYZPoint were good starts.  We can, of course, add different
encodings at this level.  But we cannot at present represent the situation where the encoding
is the same but the interpreted values are different.  This matters when the API has baked-in
constants like earth radius.  If we're going to have extremely limited API support, we'd better
not make it hard for people to use our API's generically.

To make the point clear, let's go back to the numeric field analogy.  The reason numeric fields
have been successful is because they have a wide variety of applications, and that the API
does not enforce a specific interpretation of an integer on them.  If we really want the APIs
we provide for spatial to have the same characteristics, then we should take care to insure
they don't have characteristics that make them un-generic.  To me, that means we would need
to specify distance in degrees rather than meters, and we would need some way of specifying
geometry where applicable.  But then the API becomes less friendly to the typical use case,
which is why you might want a derived class that sets all that stuff for you that is specific
to the typical case.

Anyhow, that's my thinking on the matter.  I'm happy to accept the consensus as to what to
do of course.



was (Author: kwright@metacarta.com):
bq. I give up on the issue though, this is just making spatial harder to use.

This is a discussion ticket.  It's about coming up with ideas and eventually choosing the
best ones.  I'm not sure I get your bike analogy, but I can assure you that *my* goal is to
not making things harder to use.  Given that, what is your preferred direction?  Is your issue
that there are there too many implementations?  Or is it your desire that we leave things
as they are?  If you are serious that we should just go home and let people figure out their
own encoding and roll their own spatial implementation, then there's not much further discussion
possible?

I thought MortonPoint/LatLonPoint/XYZPoint were good starts.  We can, of course, add different
encodings at this level.  But we cannot at present represent the situation where the encoding
is the same but the interpreted values are different.  This matters when the API has baked-in
constants like earth radius.  If we're going to have extremely limited API support, we'd better
not make it hard for people to use our API's generically.




> Come up with a comprehensive proposal for naming spatial modules and technologies
> ---------------------------------------------------------------------------------
>
>                 Key: LUCENE-7202
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7202
>             Project: Lucene - Core
>          Issue Type: Task
>          Components: modules/sandbox, modules/spatial, modules/spatial3d
>    Affects Versions: master
>            Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, and nobody
seems happy with the naming of them.  For each implementation strategy, we need both a module
name and a descriptive technology name that we can use to distinguish one from the other.
 I would expect the following people to have an interest in this process: [~rcmuir], [~dsmiley],
[~mikemccand], etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message