Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: spatial
    • Labels:
      None

      Description

      This is another patch from William and I. My contribution to this patch was converting this patch to use the BaseResponseWriter framework I introduced (along with Noble) in SOLR-1516. This patch provides a GeoRSS compatible response writer for use in spatial.

      1. SOLR-2074.Mattmann.Quach.082210.patch.txt
        9 kB
        Chris A. Mattmann
      2. SOLR-2074.Mattmann.Quach.082310.2.patch.txt
        8 kB
        Chris A. Mattmann
      3. SOLR-2074.Mattmann.Quach.082310.patch.txt
        8 kB
        Chris A. Mattmann
      4. SOLR-2074.Mattmann.Quach.Li.042312.patch.txt
        9 kB
        Yiyu Li

        Issue Links

          Activity

          Hide
          Chris A. Mattmann added a comment -
          • patch attached for basic GeoRss writer. solrconfig.xml update to include the writer as well.
          Show
          Chris A. Mattmann added a comment - patch attached for basic GeoRss writer. solrconfig.xml update to include the writer as well.
          Hide
          Chris A. Mattmann added a comment -

          sorry, original patch used "get" instead of "getFirstValue", leading to an error. Fix attached.

          Show
          Chris A. Mattmann added a comment - sorry, original patch used "get" instead of "getFirstValue", leading to an error. Fix attached.
          Hide
          Chris A. Mattmann added a comment -

          Here are some notes from William about the collective of patches:

          NOTE 1: For best results, please use Mozilla Firefox when running the example.
          NOTE 2: If city contains white space, surround the city in double quotes (")
          NOTE 3: State needs to be an abbreviation (e.g. CA for California)
          NOTE 4: Country must be ISO-3166 2-letter country code (e.g. US for United States). See http://download.geonames.org/export/dump/readme.txt for more details.
          NOTE 5: If a location cannot be determined from the ct, s, and c parameters. A reverse-ip lookup will be initiated to attempt to determine your location.
          This will only work if your IP is accessible to the Java servlet. This usually does not work when client and server are on the same machine.
          The default GeotargetAdapter uses hostip.info webservice, so in order for this service to work, your IP must be located in their database.
          Visit http://www.hostip.info/ for more information and to add your IP and location to the hostip database.
          NOTE 6: If your location cannot be determined by either means, then spatial search will be aborted and you will get the results for the default free-text search. If the results contains geo data, then it will still be plotted on the map.

          Show
          Chris A. Mattmann added a comment - Here are some notes from William about the collective of patches: NOTE 1: For best results, please use Mozilla Firefox when running the example. NOTE 2: If city contains white space, surround the city in double quotes (") NOTE 3: State needs to be an abbreviation (e.g. CA for California) NOTE 4: Country must be ISO-3166 2-letter country code (e.g. US for United States). See http://download.geonames.org/export/dump/readme.txt for more details. NOTE 5: If a location cannot be determined from the ct, s, and c parameters. A reverse-ip lookup will be initiated to attempt to determine your location. This will only work if your IP is accessible to the Java servlet. This usually does not work when client and server are on the same machine. The default GeotargetAdapter uses hostip.info webservice, so in order for this service to work, your IP must be located in their database. Visit http://www.hostip.info/ for more information and to add your IP and location to the hostip database. NOTE 6: If your location cannot be determined by either means, then spatial search will be aborted and you will get the results for the default free-text search. If the results contains geo data, then it will still be plotted on the map.
          Hide
          Chris A. Mattmann added a comment -
          • made the code a bit more robust for lats and lons
          Show
          Chris A. Mattmann added a comment - made the code a bit more robust for lats and lons
          Hide
          Erik Hatcher added a comment -

          out of curiosity, why wouldn't an XSLT stylesheet and the xslt writer suffice for this need?

          Show
          Erik Hatcher added a comment - out of curiosity, why wouldn't an XSLT stylesheet and the xslt writer suffice for this need?
          Hide
          Chris A. Mattmann added a comment -

          well to each their own i guess. XSLT is scary for me, and Java code isn't

          Show
          Chris A. Mattmann added a comment - well to each their own i guess. XSLT is scary for me, and Java code isn't
          Hide
          Ryan McKinley added a comment -

          how about velocity maybe that is less scary then XSLT

          I fear adding and maintaining even more response writers when the ones we have are such a mess. How would this new response writer deal with things like location field names changing etc...

          Show
          Ryan McKinley added a comment - how about velocity maybe that is less scary then XSLT I fear adding and maintaining even more response writers when the ones we have are such a mess. How would this new response writer deal with things like location field names changing etc...
          Hide
          Chris A. Mattmann added a comment - - edited

          Heh. Dually noted. The thing is, I'm not against any of the solutions. We just so happened to have cooked one up in Java. If folks want an XSLT version, great, to each their own. I'd be happy to maintain the Java version, but I'm not good at XSLT. I'm not super great at Velocity either. I know Java very well though. So, dunno on this one. It's nice to have the ability to write it in any of these three methodologies, but I'm not sure any of them are better than the other. The benefit here is that we've already written one in Java, so it's there. You can use it, or feel free to rewrite it and start all over in your language/technology of choice.

          Show
          Chris A. Mattmann added a comment - - edited Heh. Dually noted. The thing is, I'm not against any of the solutions. We just so happened to have cooked one up in Java. If folks want an XSLT version, great, to each their own. I'd be happy to maintain the Java version, but I'm not good at XSLT. I'm not super great at Velocity either. I know Java very well though. So, dunno on this one. It's nice to have the ability to write it in any of these three methodologies, but I'm not sure any of them are better than the other. The benefit here is that we've already written one in Java, so it's there. You can use it, or feel free to rewrite it and start all over in your language/technology of choice.
          Hide
          Erik Hatcher added a comment -

          I hate XSLT too though pragmatic; for something straightforward like this it seems like a short and sweet stylesheet would do the trick.

          As for Velocity - having it generate an XML response would work, but care must be taken to XML encode all dynamic text properly so it's not quite the perfect tool for the job. But it's easy enough to encode XML using $esc.xml(...) in a Velocity template so it'd actually look quite lean and clean as a template.

          Show
          Erik Hatcher added a comment - I hate XSLT too though pragmatic; for something straightforward like this it seems like a short and sweet stylesheet would do the trick. As for Velocity - having it generate an XML response would work, but care must be taken to XML encode all dynamic text properly so it's not quite the perfect tool for the job. But it's easy enough to encode XML using $esc.xml(...) in a Velocity template so it'd actually look quite lean and clean as a template.
          Hide
          Uwe Schindler added a comment - - edited

          I hate XSLT too though pragmatic; for something straightforward like this it seems like a short and sweet stylesheet would do the trick.

          I love XSL, after Java it's my 2nd favorite programming language (really, additionally its also turing complete g). In my opinion, a stylesheet is here the best possibility to choose. Its short and comapct and easy to understand. Here at PANGAEA, our complete metadat processing is based on XSL, so I could possibly produce one (I prefer KML over GeoRSS, but that does not matter - we could possibly provide both).

          EDIT:: I think I have seen an GeoRSS/KML XSL in a testcase of another issue. I have to look for the issue number.

          Show
          Uwe Schindler added a comment - - edited I hate XSLT too though pragmatic; for something straightforward like this it seems like a short and sweet stylesheet would do the trick. I love XSL, after Java it's my 2nd favorite programming language (really, additionally its also turing complete g ). In my opinion, a stylesheet is here the best possibility to choose. Its short and comapct and easy to understand. Here at PANGAEA, our complete metadat processing is based on XSL, so I could possibly produce one (I prefer KML over GeoRSS, but that does not matter - we could possibly provide both). EDIT: : I think I have seen an GeoRSS/KML XSL in a testcase of another issue. I have to look for the issue number.
          Hide
          Lance Norskog added a comment -

          SOLR-1354 is my attempt at a real XSL. It lets you pass field names and other things in as parameters. The patch includes a one-size-fits-all stylesheet can be reused without copying and changing it.

          With GeoRSS I'm finding I still want to put code into creating the georss data, so I don't think a one-size-fits-all template is good enough. And I am now a well-informed, experienced XSL-hater.

          Show
          Lance Norskog added a comment - SOLR-1354 is my attempt at a real XSL. It lets you pass field names and other things in as parameters. The patch includes a one-size-fits-all stylesheet can be reused without copying and changing it. With GeoRSS I'm finding I still want to put code into creating the georss data, so I don't think a one-size-fits-all template is good enough. And I am now a well-informed, experienced XSL-hater.
          Hide
          Robert Muir added a comment -
          Show
          Robert Muir added a comment - Moving out all unassigned issues set to 3.1 per this email: http://www.lucidimagination.com/search/document/f026cc56081b5a51/unassigned_jira_issues_set_for_3_1
          Hide
          Robert Muir added a comment -

          Bulk move 3.2 -> 3.3

          Show
          Robert Muir added a comment - Bulk move 3.2 -> 3.3
          Hide
          Robert Muir added a comment -

          3.4 -> 3.5

          Show
          Robert Muir added a comment - 3.4 -> 3.5
          Hide
          Hoss Man added a comment -

          Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently.

          email notification suppressed to prevent mass-spam
          psuedo-unique token identifying these issues: hoss20120321nofix36

          Show
          Hoss Man added a comment - Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently. email notification suppressed to prevent mass-spam psuedo-unique token identifying these issues: hoss20120321nofix36
          Hide
          Yiyu Li added a comment -

          Patch updated: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt

          This updated patch also outputs the "pubDate" for the GeoRSS if the field "pubDate" or "timestamp" is indexed in solr.

          Show
          Yiyu Li added a comment - Patch updated: SOLR-2074 .Mattmann.Quach.Li.042312.patch.txt This updated patch also outputs the "pubDate" for the GeoRSS if the field "pubDate" or "timestamp" is indexed in solr.

            People

            • Assignee:
              Unassigned
              Reporter:
              Chris A. Mattmann
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development