Hi, looking for general insight into philosophy of OmekaS and external data. We are looking at OmekaS for managing external websites (exhibits essentially) and as an OAI-PMH repository but not using it as our main collection management tool.
It seems that I cannot reference an external database and its tables (example: postgresql/postgis used with a collection management system). Could this conceivably be done with in house development? Or does that somehow go against the model of OmekaS? Would having a different collection management tool require exporting from that tool and importing to OmekaS in order to use items from our collection?
There’s nothing that would prevent you from connecting to another database, but yes, it’s not the focus for Omeka S. Omeka S is built more for referencing external content and data than classic, but through using web APIs, URLs, iframes, things like that mostly, rather than a direct database connection to an external system.
Probably anything like that would be an area where it would be custom development. Even then, if your goal is really just to only connect over to another content management system (so you don’t want items, media, etc. created in Omeka’s database at all) then it’s probably not a good fit.
Thank you. I have been learning more about how Omeka S works, studying the database, and believe we can make this work by doing imports into Omeka S (so not doing data entry there, but only developing and managing sites).
The module Data Type Geometry is still actively maintained and developed. It allows to store latitude and longitude in a standard way, and markers and zones of an images or a map. It is used by module Cartography. Cartography do the same than module Mapping, but markers are standard annotations and areas can be added. It works for images too. The version for Omeka S v4 will be published in a few days. Furthermore, the module allows to sync markers between properties and map for module Mapping.
Because mariadb does not manage fully geographic data (they are managed like geometric ones), and the same, because the minimum mysql version required by Omeka S does not manage geometric data in a standard way, it is better to use an external database to store geometric data. In this module, only the table that stores geometric data can be on in another database, because postgre manage geographic data a lot better.
Because Omeka uses Doctrine to manage database, it probably works fine with postgre, but some modules uses specific direct sql queries that should be checked. So you can use postgre, install the list of common modules and find issues, then report or fixes them (probably not so many).
Thank you Daniel_KM. After studying Omeka-S now for a while, I realized the required database design is far different from what we are building in PostGres and so now we are learning how to code to the Rest API. This means duplicating data but we are okay with that as long as we are not duplicating media. We are still studying how to serve media to Omeka-S and to other applications as needed.