Details

    • Type: New Feature
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.1, 7.0
    • Component/s: Response Writers
    • Labels:
      None

      Description

      With minor changes, we can modify the existing JSON writer to produce a GeoJSON `FeatureCollection` for ever SolrDocumentList. We can then pick a field to use as the geometry type, and use that for the Feature#geometry

      "response":{"type":"FeatureCollection","numFound":1,"start":0,"features":[
            {"type":"Feature",
              "geometry":{"type":"Point","coordinates":[1,2]},
              "properties":{
                ... the normal solr doc fields here ...}}]
        }}
      

      This will allow adding solr results directly to various mapping clients like Leaflet


      This patch will work with Documents that have a spatial field the either:
      1. Extends AbstractSpatialFieldType
      2. has a stored value with geojson
      2. has a stored value that can be parsed by spatial4j (WKT, etc)

      The spatial field is identified with the parameter `geojson.field`

        Activity

        Hide
        ryantxu Ryan McKinley added a comment -

        Here is a patch... now i will try to figure out this git bizness!

        Show
        ryantxu Ryan McKinley added a comment - Here is a patch... now i will try to figure out this git bizness!
        Show
        dsmiley David Smiley added a comment - I left some feedback: https://github.com/ryantxu/lucene-solr/commit/4792f0c13cb4d99cddf92c406a127ce08e04c715#diff-6ead4e8deaf560600de90a67c0b37e57R2126
        Hide
        ryantxu Ryan McKinley added a comment -
        Show
        ryantxu Ryan McKinley added a comment - updated patch... also check: https://github.com/ryantxu/lucene-solr/tree/with_geojson
        Hide
        ryantxu Ryan McKinley added a comment -

        Here is an updated patch with better tests and docs. I think this is ready to go

        Show
        ryantxu Ryan McKinley added a comment - Here is an updated patch with better tests and docs. I think this is ready to go
        Hide
        dsmiley David Smiley added a comment -

        Looks good, just a few comments...

        • In the test, it appears System.setProperty("enable.update.log", "false"); // schema12 doesn't support version is not needed since you don't use schema12
        • I suggest initializing the HashMap of the built-in transformers with the no-arg constructor (TransformerFactory.java), and same thing for the response writers (SolrCore.java). It's not worth it in trying in trying to optimize & maintain anything else. I realize you didn't introduce these but I suggest ending it now.
        • Personally I'd find it far easier to interpret the test if I was looking at the JSON string or toString'ed Map or whatever it is, versus the laborious extraction of each part of the data structure. If you disagree, leave it.
        • GeoTransformerFactory.java doesn't compile for me; it references GeoJSONResponseWriter.FIELD which doesn't exist. The patch file itself seemed strange; seemed like a list of commits and not one patch. Maybe this is related.
        Show
        dsmiley David Smiley added a comment - Looks good, just a few comments... In the test, it appears System.setProperty("enable.update.log", "false"); // schema12 doesn't support version is not needed since you don't use schema12 I suggest initializing the HashMap of the built-in transformers with the no-arg constructor (TransformerFactory.java), and same thing for the response writers (SolrCore.java). It's not worth it in trying in trying to optimize & maintain anything else. I realize you didn't introduce these but I suggest ending it now. Personally I'd find it far easier to interpret the test if I was looking at the JSON string or toString'ed Map or whatever it is, versus the laborious extraction of each part of the data structure. If you disagree, leave it. GeoTransformerFactory.java doesn't compile for me; it references GeoJSONResponseWriter.FIELD which doesn't exist. The patch file itself seemed strange; seemed like a list of commits and not one patch. Maybe this is related.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 5731331be1f5fcef829950fcfa9edcb3632babae in lucene-solr's branch refs/heads/branch_6x from Ryan McKinley
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5731331 ]

        SOLR-8814: Support GeoJSON response format

        Show
        jira-bot ASF subversion and git services added a comment - Commit 5731331be1f5fcef829950fcfa9edcb3632babae in lucene-solr's branch refs/heads/branch_6x from Ryan McKinley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5731331 ] SOLR-8814 : Support GeoJSON response format
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 36145d02ccc838f50538a8b9d6ff9c68f3ccce22 in lucene-solr's branch refs/heads/master from Ryan McKinley
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=36145d0 ]

        SOLR-8814: Support GeoJSON response format

        Show
        jira-bot ASF subversion and git services added a comment - Commit 36145d02ccc838f50538a8b9d6ff9c68f3ccce22 in lucene-solr's branch refs/heads/master from Ryan McKinley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=36145d0 ] SOLR-8814 : Support GeoJSON response format
        Hide
        ryantxu Ryan McKinley added a comment -

        In the test, it appears System.setProperty("enable.update.log", "false"); // schema12 doesn't support version is not needed since you don't use schema12

        fixed – thanks

        I suggest initializing the HashMap of the built-in transformers with the no-arg constructor (TransformerFactory.java), and same thing for the response writers (SolrCore.java). It's not worth it in trying in trying to optimize & maintain anything else. I realize you didn't introduce these but I suggest ending it now.

        Lets open another issue if you care about this... i don't know enough to say, and don't want that discussion to get lost in this issue

        Personally I'd find it far easier to interpret the test if I was looking at the JSON string or toString'ed Map or whatever it is, versus the laborious extraction of each part of the data structure. If you disagree, leave it.

        I think the tests have a good mix of this – some are testing with strings and others are checking the direct element. (Where parsing is important)

        GeoTransformerFactory.java doesn't compile for me; it references GeoJSONResponseWriter.FIELD which doesn't exist. The patch file itself seemed strange; seemed like a list of commits and not one patch. Maybe this is related.

        sorry, my git patch was weird. It was the 'patch' flavor, not the 'diff' flavor

        Show
        ryantxu Ryan McKinley added a comment - In the test, it appears System.setProperty("enable.update.log", "false"); // schema12 doesn't support version is not needed since you don't use schema12 fixed – thanks I suggest initializing the HashMap of the built-in transformers with the no-arg constructor (TransformerFactory.java), and same thing for the response writers (SolrCore.java). It's not worth it in trying in trying to optimize & maintain anything else. I realize you didn't introduce these but I suggest ending it now. Lets open another issue if you care about this... i don't know enough to say, and don't want that discussion to get lost in this issue Personally I'd find it far easier to interpret the test if I was looking at the JSON string or toString'ed Map or whatever it is, versus the laborious extraction of each part of the data structure. If you disagree, leave it. I think the tests have a good mix of this – some are testing with strings and others are checking the direct element. (Where parsing is important) GeoTransformerFactory.java doesn't compile for me; it references GeoJSONResponseWriter.FIELD which doesn't exist. The patch file itself seemed strange; seemed like a list of commits and not one patch. Maybe this is related. sorry, my git patch was weird. It was the 'patch' flavor, not the 'diff' flavor
        Hide
        hossman Hoss Man added a comment -

        Manually correcting fixVersion per Step #S5 of LUCENE-7271

        Show
        hossman Hoss Man added a comment - Manually correcting fixVersion per Step #S5 of LUCENE-7271
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit eb9985210ecc72d0bf6669e6002ac4f655e7e3c8 in lucene-solr's branch refs/heads/branch_6_0 from Steve Rowe
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb99852 ]

        SOLR-8902: branch_6_0 only: use [custom] transformer instead of [geo] transformer in ReturnFieldsTest, since the [geo] transformer, introduced in SOLR-8814 and landing in 6.1, won't be backported to branch_6_0

        Show
        jira-bot ASF subversion and git services added a comment - Commit eb9985210ecc72d0bf6669e6002ac4f655e7e3c8 in lucene-solr's branch refs/heads/branch_6_0 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb99852 ] SOLR-8902 : branch_6_0 only: use [custom] transformer instead of [geo] transformer in ReturnFieldsTest, since the [geo] transformer, introduced in SOLR-8814 and landing in 6.1, won't be backported to branch_6_0
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit e9e55d1ef5fd3cccfd80281c5f66ec3486cb98f1 in lucene-solr's branch refs/heads/branch_5_5 from Steve Rowe
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9e55d1 ]

        SOLR-8902: branch_6_0 only: use [custom] transformer instead of [geo] transformer in ReturnFieldsTest, since the [geo] transformer, introduced in SOLR-8814 and landing in 6.1, won't be backported to branch_6_0

        Show
        jira-bot ASF subversion and git services added a comment - Commit e9e55d1ef5fd3cccfd80281c5f66ec3486cb98f1 in lucene-solr's branch refs/heads/branch_5_5 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9e55d1 ] SOLR-8902 : branch_6_0 only: use [custom] transformer instead of [geo] transformer in ReturnFieldsTest, since the [geo] transformer, introduced in SOLR-8814 and landing in 6.1, won't be backported to branch_6_0
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit a409beecd0fb198466cc7874498446eab165d6fa in lucene-solr's branch refs/heads/branch_5x from Steve Rowe
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a409bee ]

        SOLR-8902: branch_6_0 only: use [custom] transformer instead of [geo] transformer in ReturnFieldsTest, since the [geo] transformer, introduced in SOLR-8814 and landing in 6.1, won't be backported to branch_6_0

        Show
        jira-bot ASF subversion and git services added a comment - Commit a409beecd0fb198466cc7874498446eab165d6fa in lucene-solr's branch refs/heads/branch_5x from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a409bee ] SOLR-8902 : branch_6_0 only: use [custom] transformer instead of [geo] transformer in ReturnFieldsTest, since the [geo] transformer, introduced in SOLR-8814 and landing in 6.1, won't be backported to branch_6_0

          People

          • Assignee:
            ryantxu Ryan McKinley
            Reporter:
            ryantxu Ryan McKinley
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development