[
https://issues.apache.org/jira/browse/SOLR-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836499#comment-16836499
]
Bar Rotstein edited comment on SOLR-13263 at 5/9/19 4:07 PM:
-------------------------------------------------------------
{quote}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.
{quote}
Even after changing the max Latitude value to 70, the parsed shape's bounding
box is still GeoWorld.
{quote}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.
{quote}
Ouch, my bad.
I am very inexperienced when it comes to GIS.
Would keeping all polygons make this test OK logic-wise?
was (Author: brot):
{quote}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.{quote}
Even after changing the maqY value to 70, the parsed shape's bounding box is
still GeoWorld.
{quote}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.{quote}
Ouch, my bad.
I am very inexperienced when it comes to GIS.
Would keeping all polygons make this test OK logic-wise?
> 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
