[ 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