[
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: kwri...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
