Geonames machine tags

“Geonames machine tags” is a nice idea proposed by Harry Chen in the Geospatial Semantic Web Blog. He suggests to annotate photos with machine tags that point to geonames features using the format “geonames:feature=5352844“. He writes : If flikr’s service is implemented to recognize geonames’s machine tag, then it can pull this semantic description from geonames.org, which is the RDF description about the Golden Gate Bridge. In this document, it describes how Golden Gate Bridge is called in different languages and other geographical information. Read the full posting on the Geospatial Semantic Web Blog …

Flickr’s Dan Catt on the geobloggers blog takes up the idea : Now while only a handful of us have the ability to make an implementation of that from the flickr side (upon which I can’t comment, other that to say it sounds like a good idea) …
He then continues describing how the geonames rdf format can easily be transformed into JSON using triplr.org. Read the full posting on Geoblogger.com …

Advertisement

A Basque region gives its public data to Geonames

Gipuzkoa is a territory in northern Spain, with its own parliament, part of the autonomous region of the Basque Country. It’s located in the westernmost part of the Pyrenees, bordering the Atlantic Ocean, in the borderline between France and Spain. It’s surface is around 2,000 km2 and nearly 700,000 inhabitants.

The geographic data of the region has just been greatly enhanced in Geonames. Nearly 250 locations have been corrected (moved to exact positions, and official and alternate names have been added, mostly in Basque), and other 750 new records were added, populated places most of them. The data set is from the Provincial Council of Gipuzkoa, the local administration, and has been kindly provided by the officials in charge of the local public Spatial Data Infrastructure (SDI), the B5M office, as it is called there.

Previously, Gipuzkoa’s places looked like this in Geonames:

A regular distribution pattern of some scarce populated places, due to rounded coordinates of old gazetteers. And only Spanish names appeared, despite Basque forms being the official ones for 20 years or so. Now, that region appears like this:

More places, updated Basque official names show first (Spanish names haven’t been deleted, they remain there as alternate form), and exact locations. In the case of municipalities, for instance, latitude and longitude are those of the town hall.

This addition follows the path of another public data upload we had recently, that one from Brazil. It is encouraging when public administrations decide to share their data openly, as in these cases. At the same time, this is the way to avoid embarrassing situations like outdated data appearing in online maps, as the Hitler-berg case shows. If you know about interesting free data sets from your country, please let us know. We are eager to integrate them.

The records of this load have been locked for updates by the anonymous user as this official SDI body is definitely a trustworthy data source.

Many thanks for this update to Luistxo from Eibar, Spain. Luistxo is a big help for geonames in particular with Basque place names and minority languages.

Heiglkopf or “Hitler-Berg”?

There is an interesting article on SPIEGEL Online today about the naming of a German hill on GoogleEarth. The hill Heiglkopf near Bad Tölz was renamed to ‘Hitler-Berg‘ in 1933, the very year Hitler took over power, and kept this name till the end of the Nazi regime in 1945. This is also the name GoogleEarth was displaying for the hill up to today much to the dismay of local authorities.

Lesson learnt : If local authorities want to be sure their places are properly named on the geospatial web then they should not hesitate to make the information freely available. If they continue to ask exorbitant prices for their data that not even Google can afford to pay for it, whom do they expect to be able to do so?

Web Map API Standard

Google is asking for feature requests for the Google Maps API. One request is for ‘Compatibility with other map APIs‘.

Following the lead of Google several other vendors are now also offering web map APIs. All these javascript based APIs have similar features but are unfortunately incompatible with each other. A switch from one vendor to the other requires rewriting most of the mapping code in your application. There are open source projects like mapstraction or myMap that try to solve this problem with adding an additional layer on top of Google, Yahoo and Microsoft.

Wouldn’t it be better if the map API vendors (Google, Microsoft, Yahoo, Mapquest and even the open source API openlayers) could directly agree on a common API? With a common API you could switch from one map vendor to the other by simply changing a single javascript import statement.

You are investing a lot of time in writing code for the Google Maps API and your application depends on it, what are you going to do if Google changes the licence and you are no longer able to use it? If you want to support the request for compatibility between mapping APIs put your name in the requested by field.