[
https://issues.apache.org/jira/browse/SOLR-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833433#comment-16833433
]
David Smiley commented on SOLR-13263:
-------------------------------------
bq. SpatialHeatmapFacetsTest#testGeoJsonBounds -> This test shows the odd
behavior showcased by Geo3D parsing context. When a Polygon is parsed in
GeoJson form, its bounding box seems to default to GeoWorld, as can be seen in
SpatialHeatmapFacetsTest#testGeoJsonBounds:341.
Indeed something seems wrong here. I played with that in a debugger and it's a
bit over my head but _appears_ to be a deficiency in Geo3D's
{{GeoConcavePolygon.getBounds}} CC [~daddywri] (see above).
The testGeoJsonBounds method also has several problems:
* On the surface of a sphere, the parsed shape of 4 points is different than a
Euclidean 2D plane. Geo3D is surface-of-sphere. Thus horizontal lines above
the equator bow upwards when viewed on a 2D plane. So the test is
fundamentally wrong to compare a surface-of-sphere shape to a lat-lon rectangle
(which isn't surface-of-sphere) wherein the inputs are the same since the
result won't match.
* Your top latitude is 90 which touches the north pole. _Debatably_ this wraps
the world; you could argue it either way. This makes reasoning about what the
bounding box _should_ be in a test debatable and thus not a good test input.
You could lower to say 70.
* Something trivial: confusingly, you pass an "expected" named var to the
second param of assertEquals when as that method documents, it should be the
first.
bq. SpatialHeatmapFacetsTest#testGeoJsonFacets
I don't notice any parsing bug. Keep in mind the first few things the test
asserts are that it fails for distErr=0 and distErrPct=0 so you might be
looking at expected failures, though we ignore them.
*org.apache.solr.util.SpatialUtils#parseGeomSolrException*
This seems to be the deficiency you identified that needs to be enhanced -- the
key to this issue and maybe others. I'm not sure I like looking for the
substring " TO " since perhaps it might be found in some spatial input. A
compiled regular expression would be safer. Perhaps we should use one
compatible with what Solr's parser does in
{{org/apache/solr/parser/QueryParser.jj}}.
> Facet Heat Map should support GeoJSON
> -------------------------------------
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, faceting
> Affects Versions: 8.0, 8.1, master (9.0)
> Reporter: Bar Rotstein
> Priority: Major
> Labels: Facets, Geolocation, facet, faceting, geo
> Attachments: SOLR-13263-nocommit-geo3d-failure.patch,
> SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other
> subjects other than WKT or '[ ]'. This seems to be caused since
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes
> the code a lot cleaner and should support more formats (including GeoJSON).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
