ExploreOurPla.net will soon release a GeoRSS viewer on top of their already remarkable interface. The viewer is currently in Beta, but nevertheless the most sophisticated GeoRSS viewer we know about. If you want to check it out, and I am sure you want, just add the RSS feed URL to the path ‘http://exploreourpla.net/georss/’. ExploreOurPla.net will call the geonames converter with the url and display the feed.
Here an example of google news about “flu” : http://exploreourpla.net/georss/http://news.google.com/news?hl=en&output=rss&q=flu
Reuters “World News” is already in the default profile. You can create a login with ExploreOurPla.net and create your own list of your favorite geo feeds.
An important feature for us here at geonames is the feedback menu for each feed entry. There are two options ‘ok’ and ‘nok’ (for “not ok”). A click on one of them will result in a callback to the geonames server. We will store your feedback in our database and use it to improve our conversion algorithm. We hope to be able to officially release the RSS to GeoRSS converter pretty soon. Below a screen shot of the ‘geoFeedExplorer’ I have underlined the feedback menus and marked them with a red arrow.
One of the most interesting parts of the 'natural language geocoder' is Place Name Disambiguation. Depending on the context, the grammatical structure or the language a term may have one of several possible meanings. Examples :
- Hayden : the CIA director Michael Hayden or the city in Idaho.
- Java : the island or the programming language
- Brisbane : city in Australia or city in California, USA
- Como : city in Italy or a very frequent word in Spanish.
We are using several processing steps to tackle this problem. First we identify the language of the text and the contexts (Example : In an IT context the term java most likely stands for the programming language).
Then we try to find person names and we do some simple grammatical analysis using coocurrences of left and right neighbours (Example : If the term we are looking at is preceded by the expression 'south of', we can be nearly certain that the term has a geographical meaning.)
With the new availability of google maps for many countries across Europe and Oceania, I thought it would be interessting to see how the geonames place name labelling algorithm is doing compared to google/teleatlas.
To my big surprise geonames compares very well, it even seems to be doing better. The close cities of Vienna and Bratislava are a good example. Geonames shows Vienna whereas google/teleatlas shows Bratislava. The blue labels are delivered by geonames :
Some of the sites using geonames place name labels are ExploreOurPla.net (use the GHYB overlay switch to turn on google maps hybrid) or globefeed (IE only).
Edit : Noiv, from ExploreOurPla.net, has just sent me these two links :
Region around Vienna with Googlemaps and with MSN Maps.
I am currently looking at first names in order to improve the 'natural language geocoder'. It is curious to see that it needs 4200 first names for girls to cover 90% of the population, but it only needs 1200 boy's names to reach a 90% coverage. The reason for this huge difference is mainly found in the top positions. The ten most popular male names reach 23% whereas the ten most popular female names reach a comparatively meager 10%.
The question is: why are parents looking for variety in a name for a girl and far less for a boy? Any ideas?
Source : US Census
PS, just in case you want to know the most popular names :
name freq cum.freq rank
MARY 2.629 2.629 1
PATRICIA 1.073 3.702 2
LINDA 1.035 4.736 3
BARBARA 0.980 5.716 4
ELIZABETH 0.937 6.653 5
JENNIFER 0.932 7.586 6
MARIA 0.828 8.414 7
SUSAN 0.794 9.209 8
MARGARET 0.768 9.976 9
DOROTHY 0.727 10.703 10
JAMES 3.318 3.318 1
JOHN 3.271 6.589 2
ROBERT 3.143 9.732 3
MICHAEL 2.629 12.361 4
WILLIAM 2.451 14.812 5
DAVID 2.363 17.176 6
RICHARD 1.703 18.878 7
CHARLES 1.523 20.401 8
JOSEPH 1.404 21.805 9
THOMAS 1.380 23.185 10
In a previous posting I have written about searching with country names in different languages and was asking our readers to find problems with the algorithm. No one found was able to spot the problem, but this does not stop us from fixing it.
The problem was with the country aliaser for composite country names in foreign languages. A search for 'Seoul, Süd Korea' would not have found anything as the aliaser was only looking at single tokens and was not considering composite country names.
The aliaser has been refactored and is now using a look ahead to see what other tokens are following and whether a sequence of tokens is matching a well known country name.
It is working flawless now, as you can see yourself :
The brand new Geonames RSS-to-GeoRSS-Converter reads each entry in an RSS feed and tries to determine a geo location for the entry using a modified version of the Geonames full text search. If a geo location is found, its latitude and longitude in GeoRSS format are added to the feed entry. It works for any RSS feed, just pass the feed url as a parameter to the converter and your feed entries will get latitude and longitude in real time.
Here the Reuters WorldNews Feed enriched with lat/lng by Geonames and displayed on the Acme GeoRSS Mapper. It works like a unix pipe : the orginal Reuters feed is piped through the Geonames converter and the result is displayed on the Acme Viewer. You could imagine to pipe the result through a translation service, trough a filter service, trough a sort service, merge with an other feed and so on. In the end you have the original feed translated into your language, filtered by some keywords, enriched with geo information and sorted by distance to your home address. I digress, lets go back to our service.
In addition to adding GeoRSS information the converter is also able to convert from one rss dialect to an other RSS dialect. This is useful if the converted feed with the geo information should be displayed with a GeoRSS viewer which does not support the RSS dialect of the original feed. Just add the parameter type to the url with the target RSS dialect.
The converter has to take the language of the feed into account. Supported languages are English, German, Spanish, Italian and French. The automatic language detection of the converter is rudimentary and only uses the top level domain of the feed to determine the language (.de > de, .it > it ,….). The parameter lang can be used to pass a language and circumvent the automatic language detection.
This a very first release for this service and there is a lot of way for improvement. Don't hesitate to use the comments form below for your ideas and feedback.