Geonames: Show on local map plugin?

peter_b · July 30, 2026, 8:39am

Hi everyone!

My colleagues have entered places, using Geonames from “Value Suggest” Module. Works great, but Geonames does not display a map by default anymore, saying:

“to view map click on map icon in bottom toolbar. (we need to reduce the cost for the map views)”

Now, since Omeka has a local mapping module anyways, is there a way to show these geoname locations on the Omeka-map?

Grateful for any suggestions!

mephillips · August 3, 2026, 3:01pm

Highly-technical option follows. It proves it’s possible to achieve what you want using some external coding, but I guess you would probably be glad to hear if anyone has any better ideas that use existing Omeka modules or built-in features!

With Value Suggest the items will not just have the name of the places stored, but also the Geonames URI.

You can use the URI via the Geonames API to look up the terms and the latitude/longitude of the centroid of the area. It is also possible to read the shape of the boundary of any area. To be nice to the Geonames people, you ought to cache this information to avoid looking up the same place repeatedly.

It would therefore be possible to write a process (e.g. a Python script using the Omeka-S REST API) which would read through all your items and find the Geonames references. You could, using the script, create a Mapping module point or area attached to the item. Then your item display can have a map embedded to show the location. It is possible also to set the bounds of the map via the API so that the map is not zoomed in so excessively that people have no clue where a place is.

You would also be able to have a map of all the items, and could cluster the points if you have several items all referencing the same place. This could be an attractive way to explore the data.

The above solution does have some practical objections.

If you edit an item to remove or alter a Geonames link (via Value Suggest) then the mapping object would need editing manually or you would need to have a way of updating them from time to time when records change.
It introduced a lot of duplication. Theoretically a nicer solution would be to create an Item in Omeka for each place you want to reference, then each place would only need to be linked to Geonames once, and your current items could link to an Omeka Resource for the place rather than via Value Suggest. But then on the global map you would only get one pin for each place, even if multiple items were linked to it, and you would need some clever coding in your theme if you wanted to display a map on every item page showing the location of the Resource it is linked to.

peter_b · August 10, 2026, 2:38pm

@mephillips : Thanks for the suggestion!
Have you done that already, or is it “would technically be possible”?

That “resolve latitude/longitude” by (python) code was my “plan C” already

Therefore I thought I’d ask here first, to avoid “re-coding the wheel”, in case someone has done that already, or has a better solution.

boregar · August 10, 2026, 8:32pm

Ok, so the locations entered by your colleagues are stored in Omeka S as an URL of the form http://www.geonames.org/7286993 where 7286993 is the identifier of the location (here a Swiss village named “Russin”)

You can also get the RDF data from Geonames by reading https://sws.geonames.org/7286993/about.rdf

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rdf:RDF xmlns:cc="http://creativecommons.org/ns#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:gn="http://www.geonames.org/ontology#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:wgs84_pos="http://www.w3.org/2003/01/geo/wgs84_pos#">
    <gn:Feature rdf:about="https://sws.geonames.org/7286993/">
        <rdfs:isDefinedBy rdf:resource="https://sws.geonames.org/7286993/about.rdf"/>
        <gn:name>Russin</gn:name>
        <gn:featureClass rdf:resource="https://www.geonames.org/ontology#A"/>
        <gn:featureCode rdf:resource="https://www.geonames.org/ontology#A.ADM3"/>
        <gn:countryCode>CH</gn:countryCode>
        <gn:population>541</gn:population>
        <wgs84_pos:lat>46.19387</wgs84_pos:lat>
        <wgs84_pos:long>6.01397</wgs84_pos:long>
        <gn:parentFeature rdf:resource="https://sws.geonames.org/6458783/"/>
        <gn:parentCountry rdf:resource="https://sws.geonames.org/2658434/"/>
        <gn:parentADM1 rdf:resource="https://sws.geonames.org/2660645/"/>
        <gn:parentADM2 rdf:resource="https://sws.geonames.org/6458783/"/>
        <gn:childrenFeatures rdf:resource="https://sws.geonames.org/7286993/contains.rdf"/>
        <gn:locationMap rdf:resource="https://www.geonames.org/7286993/russin.html"/>
        <gn:wikipediaArticle rdf:resource="https://en.wikipedia.org/wiki/Russin"/>
        <rdfs:seeAlso rdf:resource="https://dbpedia.org/resource/Russin"/>
    </gn:Feature>
    <foaf:Document rdf:about="https://sws.geonames.org/7286993/about.rdf">
        <foaf:primaryTopic rdf:resource="https://sws.geonames.org/7286993/"/>
        <cc:license rdf:resource="https://creativecommons.org/licenses/by/4.0/"/>
        <cc:attributionURL rdf:resource="https://www.geonames.org"/>
        <cc:attributionName rdf:datatype="https://www.w3.org/2001/XMLSchema#string">GeoNames</cc:attributionName>
        <dcterms:created rdf:datatype="https://www.w3.org/2001/XMLSchema#date">2010-04-05</dcterms:created>
        <dcterms:modified rdf:datatype="https://www.w3.org/2001/XMLSchema#date">2021-12-03</dcterms:modified>
    </foaf:Document>
</rdf:RDF>

Or you could attach a listener to the create and update operations (see Server Event Reference - Omeka S Developer Documentation) on an item that would 1) check the presence of an existing item’s property containing some coordinates, and 2) create that property and populate it in case it is absent, thus avoiding to run an external update script.

mephillips · August 11, 2026, 8:38am

@peter_b it was very much a “this is technically possible” suggestion. I have used the Geonames API in a similar way for producing a map of our museum objects. In this case the Geonames IDs are stored in an Adlib museum system where they are extracted via the Adlib API to be fed into our Alma library management system so that they appear in our Primo discovery interface (example).

We have only recently started using Omeka, so I’ve not done any work on this kind of thing yet. The suggestion from @boregar is really helpful. I was not aware of the server events. Having a listener would be much more efficient and I am sure we will find a use for this in various ways.

coret · August 11, 2026, 9:44am

Alternative solution: the URI Dereferencer module. This module already fetches RDF information via the Geonames URI and shows this as label/value pairs. You can adapt this easily to show a map based on the returned long/lat. See Demo · Data · Gouda Tijdmachine for an example (click the place Eindhoven) and https://www.goudatijdmachine.nl/omeka/modules/UriDereferencer/asset/js/uri-dereferencer-services.js for the changed source code.

mephillips · August 11, 2026, 10:23am

To start with I clicked on the link “Eindhoven” which took me to Geonames’s web site. The original problem @peter_b mentioned was from the Geonames site not showing the map straight away. But then I noticed the little icon alongside, which opens a map within the page. Very nice!

coret · August 11, 2026, 11:15am

Yes sorry, it’s the icon next to Eindhoven that triggers the UriDereferencer (get the RDF from Geonames and then load an Open Street Maps iframe).