• patch attached for basic GeoRss writer. solrconfig.xml update to include the writer as well.

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

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.

• made the code a bit more robust for lats and lons

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

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

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...

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.

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.

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.

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.

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

Bulk move 3.2 -> 3.3

3.4 -> 3.5

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

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.