lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7195) GeoPolygon construction sometimes inexplicably chooses concave polygons when order of points is clockwise
Date Sat, 09 Apr 2016 09:44:25 GMT


Michael McCandless commented on LUCENE-7195:

Thanks for fixing this [~daddywri], it let me run the geo bench again!

Our geobench (in luceneutil) now has so many options that I wrote a wrapper Python script
(also pushed to luceneutil) to run it on the N possibilities and summarizes the results

These results are on the 60.8 M point London, UK extract (100% of London, 2.5% of the rest
of the world) from the OpenStreetMaps export:

h3. Indexing performance:

||Approach||Index time (sec)||Force merge time (sec)||Index size (GB)||Reader heap (MB)||

Here {{geopoint}} wins big since it builds on postings which are much faster at merging than
BKD trees, but note that the benchmark intentionally picks settings that provoke heavy merging
(small indexing buffer, serial merge scheduler).  It also shows that using the same morton
code, but on (1D) points instead of postings, should be a really good option too.

h3. Search performance, if queries are NOT pre-built (i.e., query construction time counts):

||Shape||Approach||QPS||Hit count||
|Polygon (10 sides)|Geo3d|5.94|355855224|
|Polygon (10 sides)|Points|29.26|355809475|
|Polygon (10 sides)|Geopoint|19.43|355809465|

h3. Search performance if queries are pre-built:

||Shape||Approach||QPS||Hit count||
|Polygon (10 sides)|Geo3d|24.88|355855224|
|Polygon (10 sides)|Points|29.12|355809475|
|Polygon (10 sides)|Geopoint|19.29|355809465|

Pre-building makes a huge difference in {{Geo3d}} for polygons, and curiously seems not to
matter much for {{Points}} and {{Geopoint}}.

> GeoPolygon construction sometimes inexplicably chooses concave polygons when order of
points is clockwise
> ---------------------------------------------------------------------------------------------------------
>                 Key: LUCENE-7195
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: modules/spatial3d
>    Affects Versions: master
>            Reporter: Karl Wright
>            Assignee: Karl Wright
>             Fix For: master, 6.x
>         Attachments: LUCENE-7195.patch
> The following input generates the following polygon, which is backwards from the correct
> {code}
> MAKE POLY: centerLat=51.204382859999996 centerLon=0.23125274999999992
> radiusMeters=44832.90297079173 gons=10
>   polyLats=[51.204382859999996, 50.89947531437482, 50.8093624806861,50.8093624806861,
50.89947531437482, 51.204382859999996, 51.51015366140113, 51.59953838204167, 51.59953838204167,
51.51015366140113, 51.204382859999996]
>   polyLons=[0.8747711978759765, 0.6509219832137298, 0.35960265165247807, 0.10290284834752167,
-0.18841648321373008, -0.41226569787597667, -0.18960465285650027, 0.10285893781346236, 0.35964656218653757,
0.6521101528565002, 0.8747711978759765]
>  --> QUERY: PointInGeo3DShapeQuery: field=point: Shape:
> GeoCompositeMembershipShape: {[GeoConcavePolygon:
> {planetmodel=PlanetModel.WGS84, points=
> [[lat=0.899021779599662, lon=0.011381469253029434],
>  [lat=0.9005818372758149, lon=0.006277016653633617],
>  [lat=0.9005818372758149, lon=0.0017952271299490152],
>  [lat=0.899021779599662, lon=-0.003309225469446801],
>  [lat=0.8936850723587506, lon=-0.007195393820967987],
>  [lat=0.8883634317734164, lon=-0.0032884879971082164],
>  [lat=0.8867906661272461, lon=0.0017959935133446592],
>  [lat=0.8867906661272461, lon=0.006276250270237971],
>  [lat=0.8883634317734164, lon=0.011360731780690846],
>  [lat=0.8936850723587506, lon=0.015267637604550617]], internalEdges={}, holes=[]}]}
> {code}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message