[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240485#comment-15240485
]
David Smiley commented on LUCENE-7202:
--
It's a shame to see scant agreement on the naming. :-( Jack, I concur that
"XYZPoint", by itself, loses the needed geo-ness and appears to be some generic
spatial/dimensional, which it certainly is not. Perhaps we shall have such a
field some day and then what?! Guys, can we standardize on "Geo" in the front
of these geodesic (relating to the earth) fields? Thus GeoXYZPoint is way
better than just XYZPoint. And GeoLatLon and Geo... whatever we're calling the
morton one? GeoPoint? Ugh; that name is bad too, these fields we are
discussing are *all* geodesic _point_ fields!
bq. maybe creating {{GeoFieldType extends FieldType}}
+1 to something along those lines; I had the same thought. It might reduce the
desire for a concise name (not a concern of mine). as you'd only need to user
the longer name at the line of construction the instance, in much the same we
create instances of ArrayList to assign to a List.
bq. absorb spatial3d module into spatial
I think it would be great if the Lucene parts of spatial3d (it's the part we're
actually talking about in this issue) move to the spatial module! Not only
does it just seem to fit better in terms of organization, but it might reduce
some pressure/desire for spatial stuff to be in Lucene core? Is anything to be
gained by moving the generic non-Lucene math parts too?
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239406#comment-15239406 ] Jack Krupansky commented on LUCENE-7202: Morton seems like more of a codec-level issue than an API - you still have k-dimensions of coordinates, but they are simply encoded to a singe number for each k-dimensional point. Maybe the implementation name finds its way into the API, but the first issue should be what is logically being modeled - what kind of points, like lat-lon, geospatial. or what. Presumably any can of k-dimensional space can be Morton-encoded. XYZ? That's fine for math-style axes, for things like 3-D CAD models and 3-D printing, but seems inappropriate for a coordinate system intended to model points on the surface of a sphere like the locations of places around the globe. To me, "Geo" seems to be an accepted reference to modeling "geographical" locations on the globe/planet. How you model things like the location of a satellite or the space station is another matter. Geosynchronous satellites simply have an elevation/altitude above a surface point. Non-geosynchronous satellites have an orbit rather than a location per se, although we can speak of their location (surface plus elevation/altitude) at any given/specified moment in time. Ditto for aircraft, which have a flight path and only momentary location at some altitude (although a helicopter can maintain location for a longer moment.) Besides geospatial surface points and 3-D CAD-style monitoring, which real-world use cases are these modules intended to cover. IOW, how should real-world users relate to them and choose from them? > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239371#comment-15239371 ] Karl Wright commented on LUCENE-7202: - +1 for that. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239358#comment-15239358
]
Michael McCandless commented on LUCENE-7202:
How about for this issue we only rename {{Geo3DPoint}} to {{XYZPoint}}, and
absorb spatial3d module into spatial?
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239250#comment-15239250 ] Nicholas Knize commented on LUCENE-7202: -1 for MortonPoint +1 for keeping LatLonPoint +0 for XYZPoint +1 for collapsing spatial3d to existing spatial module > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239198#comment-15239198 ] Karl Wright commented on LUCENE-7202: - Proposal: Let's at least get started by renaming the current public XXXPoint classes according to this proposal (MortonPoint, LatLonPoint, XYZPoint), and putting them into a common package in prep for collapsing the modules to one. What should the common package name be? I'm happy to tackle this specifically for the former Geo3DPoint family if I get some +1's for this... > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238305#comment-15238305 ] Karl Wright commented on LUCENE-7202: - 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238279#comment-15238279
]
Robert Muir commented on LUCENE-7202:
-
{quote}
These would not quite be the same as the classes we have today, because we'd
need to choose generic units rather than build in earth radius, etc. But they'd
be essentially the same. On top of those, we could build other classes
representing specific models that were heavily used, and name them by
projection:
{quote}
Then there is literally no need to have these classes. Lets not add more
classes, I don't see the need for any more classes.
Think about it this way: at the basic level, why have spatial classes at all?
User can just use a FloatPoint or DoublePoint or LongPoint in 1/2/3 dimensions
themselves.
Then just think about where we can do better and make things easier: and we
should have exactly those (and no other) classes. We already have a generic
solution: those are the primitive types and primitive types have been proven to
be great generic solutions for many years. We don't need more abstractions.
I give up on the issue though, this is just making spatial harder to use.
Instead of painting a bikeshed for one bike (which could be to fix a specific
name of ONE thing to be less confusing), this is trying to design a bikeshed
that holds a whole shit ton of bikes, a lot of which we do not need.
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238261#comment-15238261 ] Nicholas Knize commented on LUCENE-7202: bq. If i want to do some cool shit with data from mars, its not clear to me how to use geo3d to do that. Well this is the nice part. Planetary systems still operate lat/lon. But the reference constants are different. At the end of the day (like most existing projection packages) it should be using the same phi theta rho to XYZ reprojection code. If y'all want to settle on a name sooner than later I certainly won't hold it up. I'm just in favor of a simple API that can handle reference systems and raster order without creating a separate field class for all of them. That'll just get out of hand and need to change again down the road. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238258#comment-15238258 ] Karl Wright commented on LUCENE-7202: - bq. In general, i don't think trying to create some taxonomy of all the worlds problems we could possibly solve is the right way to go about it. Instead just specialize the ones that matter and keep things simple. Hmm, I'm in favor of simplicity, but also in favor of good organization. I see that there really is a natural taxonomy, which we can populate or not at our leisure/need, and it's a perfect marriage of your original idea and Nicolas's hint. The base classes describe the encoding. These are: MortonPoint LatLonPoint XYZPoint These would not *quite* be the same as the classes we have today, because we'd need to choose generic units rather than build in earth radius, etc. But they'd be essentially the same. On top of those, we could build other classes representing specific models that were heavily used, and name them by projection: CartesianMortonPoint extends MortonPoint CartesianPoint extends LatLonPoint etc. We'd want to keep the number of these low, but in theory it would be very clear how to extend and how to name when we do. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238232#comment-15238232
]
Robert Muir commented on LUCENE-7202:
-
{quote}
Ok, then we'd want names that would be capable of extending naturally into that
space, so we should think about how we'd do that now too. In the above scheme,
this would be the general planetoid advanced API class, which accepted a
general PlanetModel:
PlanetoidEllipsoidalPoint
{quote}
I don't think it needs to be that complicated. There is no need for geospatial
types to try to tackle non-planet stuff right now. If i want to do some cool
shit with data from mars, its not clear to me how to use geo3d to do that. If
that is an important use case then lets add PlanetPoint for that. Make sure it
really works with that too, e.g. if people working with that stuff compute
distance in meters, then that type should reflect that :)
Let geospatial types be specialized and take advantage of that to simplify and
speed up what they do.
Otherwise, the catch-all should always be to just use a multidimensional
"primitive" type. These already work and the user is an expert so they decide
things like encoding (double, int, float, long, biginteger, whatever). They
support basic operations like points/ranges/sets already without custom code.
{code}
document.add(new IntPoint("my2Dfield", 2, 3));
document.add(new DoublePoint("my3Dfield", 2, 3, 4));
document.add(new IntPoint("my4Dfield", 2, 3, 4, 5));
{code}
In general, i don't think trying to create some taxonomy of all the worlds
problems we could possibly solve is the right way to go about it. Instead just
specialize the ones that matter and keep things simple.
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238225#comment-15238225 ] Karl Wright commented on LUCENE-7202: - bq. Just a quick thought on the Cartesian/Spherical/Ellipsoidal naming. We did this at my last job and the maintenance / code sprawl was a nightmare. I would hope that the implementation itself was parameterized, and that there would be well-considered class hierarchy. The only difference between EllipsoidalPoint and SphericalPoint would therefore be the choice of PlanetModel. This kind of design would control maintenance and code sprawl. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238215#comment-15238215 ] Nicholas Knize commented on LUCENE-7202: bq. but since this is a public API now we have to stop at some point. I agree, but this supports my point of not forcing the issue? I think it's safe to keep current names through at least the life of Lucene 6. Deprecation and refactor can happen at least by the next major release? At that point we'll likely have a clearer picture and naming may happen naturally. Just a quick thought on the Cartesian/Spherical/Ellipsoidal naming. We did this at my last job and the maintenance / code sprawl was a nightmare. But that's just my opinion from living through it. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238181#comment-15238181 ] Karl Wright commented on LUCENE-7202: - bq. I think we could go back and forth on names all day. Yeah, but since this is a public API now we have to stop at some point. :-) bq. For example I like GeodeticPoint for Geo3D and specifying the reference datum by way of a GeoFieldType. This way it could be used for a Mars prolate spheroid without having to add a MarsPoint just to change the reference datum (there are more than 4000 reference systems). Ok, this raises an interesting possibility -- using the projection as the name. We could even then have a class derivation hierarchy from which we inherited some of the needed constants. For example: EarthCartesianPoint EarthCartesianMortonPoint EarthEllipsoidalPoint EarthSphericalPoint MarsSphericalPoint etc. By convention and for convenience, we could choose to omit the "Earth", so we would see: CartesianPoint CartesianMortonPoint EllipsoidalPoint SphericalPoint MarsSphericalPoint Then we'd be in good shape for additional projections as time went on. bq. Why did it sail? I argued for Geo3D to have a "typical" *Point type that worked with users in typical ways (latitude, longitude, meters). This does not prevent the possibility of a separate e.g. PlanetPoint type that works differently and has different APIs geared for advanced uses. Ok, then we'd want names that would be capable of extending naturally into that space, so we should think about how we'd do that now too. In the above scheme, this would be the general planetoid advanced API class, which accepted a general PlanetModel: PlanetoidEllipsoidalPoint > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238158#comment-15238158
]
Nicholas Knize commented on LUCENE-7202:
I think we could go back and forth on names all day. For example I like
{{GeodeticPoint}} for Geo3D and specifying the reference datum by way of a
{{GeoFieldType}}. This way it could be used for a Mars prolate spheroid without
having to add a {{MarsPoint}} just to change the reference datum (there are
more than 4000 reference systems).
I like {{MapPoint}} for the current {{GeoPointField}} raster approach and
specifying the pixel "order" using {{GeoFieldType}} instead of creating
separate {{MortonPoint}} {{MoorePoint}} {{HilbertPoint}} fields just to change
"pixel order" (which only compounds when adding 3D space filling order).
Bottom line, given the current state of the capability, I'm OK keeping things
as is for now and keeping this issue open for future consideration. I'm not
losing sleep over current class names and I don't think anyone is yet confused
about what does what (regardless of less than ideal names)?
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238143#comment-15238143
]
Robert Muir commented on LUCENE-7202:
-
{quote}
I think that ship has already sailed. The decision was made to use WGS84 and
keep the public API as simple as possible.
{quote}
Why did it sail? I argued for Geo3D to have a "typical" *Point type that worked
with users in typical ways (latitude, longitude, meters). This does not prevent
the possibility of a separate e.g. PlanetPoint type that works differently and
has different APIs geared for advanced uses. I do think it would be good to
follow the same structural pattern though, e.g. add methods for common use
cases: distance, shapes, etc: even if the methods are more complex (e.g. take
PlanetModel).
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238119#comment-15238119 ] Karl Wright commented on LUCENE-7202: - bq. I proposed PlanetPoint for the "3d" version. Then we can have the same lat/lon signature methods that are added now (which should use a sphere model, not ellipsoid, because it should match exactly how LatLonPoint models the earth), and then alternative methods that take PlanetModel. I think that ship has already sailed. The decision was made to use WGS84 and keep the public API as simple as possible. As for "PlanetPoint" vs. "XYZPoint", Robert's naming was meant to convey a representation. In XYZPoint, the x, y, and z values are stored, etc. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238113#comment-15238113 ] Karl Wright commented on LUCENE-7202: - bq. Seems like non Lucene committers will be totally confused for when to use one over another? That's why you'd want some kind of hint maybe in the naming. But really what you want is javadoc. If we had a completely orthogonal API then it would imply both identical functionality and identical capabilities, and that's not the case. I think the current approach of having similar (but not identical) API's and a single public implementation class is a pretty strong one. I'd just want to add more javadoc to each one describing why you'd want to use it and what the tradeoffs are. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238093#comment-15238093 ] Ryan Ernst commented on LUCENE-7202: bq. If I want to support Hilbert or Moore we add HilbertPoint, MoorePoint? Yes I think so? I think that makes a lot of sense, since the data impls can be independent of other point types? bq. Geo3dPoint: 3 dimensions I proposed PlanetPoint for the "3d" version. Then we can have the same lat/lon signature methods that are added now (which should use a sphere model, not ellipsoid, because it should match exactly how LatLonPoint models the earth), and then alternative methods that take PlanetModel. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238045#comment-15238045
]
Nicholas Knize commented on LUCENE-7202:
All of these Field classes make my head spin. If I want to support Hilbert or
Moore we add HilbertPoint, MoorePoint? I get the separation, but is there a way
to strike a balance by maybe creating {{GeoFieldType extends FieldType}} that
encapsulates these indexing options and controls the sprawl? Seems like non
Lucene committers will be totally confused for when to use one over another?
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238027#comment-15238027 ] Michael McCandless commented on LUCENE-7202: Woops sorry I meant XYZPoint (for what we now call Geo3DPoint). > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238016#comment-15238016 ] Karl Wright commented on LUCENE-7202: - GeoPoint? Didn't we decided to get rid of the "Geo" part? > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237963#comment-15237963 ] Michael McCandless commented on LUCENE-7202: +1 for MortonPoint, LatLonPoint, GeoPoint ... shorter is better. The fact that these classes will be living in a "spatial" module or a "geo" sub-package with javadocs already tells users what they are generally for. Naming is the hardest part ;) > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237677#comment-15237677 ] Karl Wright commented on LUCENE-7202: - I tend to agree with Robert that shorter is better, except when the name gets so terse as to be confusing or non-descriptive. So the only question is whether we want to hint about the implementation. The naming proposed here hints only about the representation, which is probably sufficient as far as I am concerned. Does anyone want to present any further proposals? > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237642#comment-15237642
]
Robert Muir commented on LUCENE-7202:
-
I would also recommend we restrict names to 3 syllables. Here is how i see it
{quote}
GeoPoint: 1 dimension with morton z encoding -> GeoMortonZLatLonPoint
{quote}
Why? such a complicated name. Why do we need Geo? Why do we need Morton if we
have Z? Why not just MortonPoint?
{quote}
LatLonPoint: 2 dimensions -> GeoLatLonPoint
{quote}
Putting Geo in front of this is not helping. Why not just LatLonPoint?
{quote}
Geo3dPoint: 3 dimensions -> GeoXYZPoint
{quote}
Putting Geo in front of this doesn't help. Why not just XYZPoint?
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237580#comment-15237580 ] David Smiley commented on LUCENE-7202: -- Thanks for raising this issue and for "@"-ing us, Karl. I'm sure [~nknize] might have some input as well. All/most our spatial implementations can index data provided as a latitude & longitude point, so I think it's confusing for any one of them to monopolize the name "LatLonPoint" for itself. It suggests to a user, who doesn't know about this stuff, that they should go right for the LatLonPoint one and not the other ones. So either all should have "LatLonPoint" in the name of none of them should, IMO. We need _some_ aspect of the implementation in the name of the class to hint at the implementation approach. bq. GeoPoint: 1 dimension with morton z encoding -> GeoMortonZLatLonPoint +1 Great name. Question: should it say "Term" in some way to reflect that it uses the term dictionary, not "PointValues" like some others do? GeoMortonZTermLatLonPoint. That's a mouth full, and so colloquially I'm sure we might abbreviate it but it doesn't have to be a big deal that the class name is long. Another possible name to throw in there, less long: Geo1DTermLatLonPoint. Arguably the fact that it's based on Lucene "terms" is more important to put in the name than the bit interleaving/encoding choice. bq. LatLonPoint: 2 dimensions -> GeoLatLonPoint Mmmm; but there's no implementation hint. How about Geo2DLatLonPoint? bq. Geo3dPoint: 3 dimensions -> GeoXYZPoint But people want see that their lat-lon data can go in there just as well as it can the other spatial impls. I like GeoEllipsoidLatLonPoint and Geo3DLatLonPoint and GeoXYZLatLonPoint options. Slightly prefer the 3D one only because it's been in the name thus far. Having the "LatLon" in the name *and* 3D or XYZ hopefully clarifies that it's not some generic 3d thing. It has latitudes and longitudes, which implies a sphere or ellipse surface location. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236601#comment-15236601 ] Karl Wright commented on LUCENE-7202: - Another proposal: GeoPoint: 1 dimension with morton z encoding -> GeoMortonZLatLonPoint LatLonPoint: 2 dimensions -> GeoLatLonPoint Geo3dPoint: 3 dimensions -> GeoXYZPoint > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236599#comment-15236599 ] Karl Wright commented on LUCENE-7202: - One proposal: GeoPoint: 1 dimension with morton z encoding -> Geo1DPoint LatLonPoint: 2 dimensions -> Geo2DPoint Geo3dPoint: 3 dimensions -> Geo3DPoint > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236592#comment-15236592 ] Karl Wright commented on LUCENE-7202: - I would disagree that LatLonPoint is sufficiently descriptive. All of the implementations have latitudes, longitudes, and points. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236595#comment-15236595 ] Karl Wright commented on LUCENE-7202: - +1, though, for fewer modules. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236589#comment-15236589 ] Robert Muir commented on LUCENE-7202: - Another way to see it: imagine there are 3 public classes: * GeoPoint: 1 dimension with morton z encoding * LatLonPoint: 2 dimensions * Geo3dPoint: 3 dimensions What better names can these classes have? I think this is a better place to start than worrying about modules. And i do honestly feel we can just have these 3 classes (and only these 3) public. I also know for a fact the 3d causes confusion with elevation, yes, practically if you want to do that, just index an integer field totally unrelated with any of these and people will be happy. But we should eliminate confusion. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[
https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236581#comment-15236581
]
Robert Muir commented on LUCENE-7202:
-
Less modules not more. I already explained how modules are just as confusing as
bad naming (bad packaging all around). I don't think we should create a module
for a single public class.
{quote}
Until we determine elevation-specific functionality, 3D is a meaningful moniker
{quote}
Ok then what are we doing here? Because e.g. LatLonPoint is a very simple name,
usable to the layman. Putting this in a package with a complex name like
spatial-planar hurts it, when it was never confusing to begin with :)
> 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236568#comment-15236568 ] Karl Wright commented on LUCENE-7202: - Also, one other thing to note: There has been discussion of the usage of 3D and the confusion that might have with implementations that support elevation. My thought is that *all* implementations currently "support elevation", because we don't actually do anything of consequence at the API level with elevation information. Until we determine elevation-specific functionality, 3D *is* a meaningful moniker. But I agree it is not specific enough in the long run. > 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
[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies
[ https://issues.apache.org/jira/browse/LUCENE-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236567#comment-15236567 ] Karl Wright commented on LUCENE-7202: - My proposal is as follows: The module names would include: - spatial-ellipsoid - spatial-planar - (+ one other TBD, since I don't know what really distinguishes the "point" implementation from the other 2D implementation) The implementation strategies could be called "ellipsoidal" or "planar" correspondingly. > 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
