Redmine: Issueshttps://redmine.openatlas.eu/https://redmine.openatlas.eu/favicon.ico?17112826112022-06-14T09:11:39ZRedmine
Redmine OpenAtlas - Feature #1748 (Acknowledged): Extended Value Typeshttps://redmine.openatlas.eu/issues/17482022-06-14T09:11:39ZStefan Eichertstefan.eichert@univie.ac.at
<p>In order to manage types, that require certain additional information I propose the following:</p>
<p>Idea: For e.g. radiocarbon data we need certain values that define the relation between an entity and the respective Type:<br />E18 physical thing (Wooden bucket) - P2 has type - Radiocarbon dating. The link itself has another property - P3 has note - E62 String<br />So we can document "Wooden bucket" - {"lab id": "VERA", "sample id": "VERA1234", "14C Years": 1200, "range": "30"} - Radiocarbon dating</p>
<p>This would apply to various cases. E.g. if you have certain measurements with a range like 500 +- 30, Or if you need to document the measuring device, its error or a certain method.</p>
<p>I suggest to define a new openatlas_class type to accomplish that.</p>
<p>When creating a new type like this (only doable by admins), the user defines a number of fields and their attributes: label + type of values (string, integer, float)<br />The user interface validates them when entered and displays them with the respective labels.</p>
<p>The information could be stored in the description field of the link. E.g. as JSON: {"label1": "string", "label 2": "string", "label 3": INT, "label 4": float}</p> OpenAtlas - Feature #1708 (Acknowledged): Link multiple references at the same timehttps://redmine.openatlas.eu/issues/17082022-05-10T14:53:13ZNina Richards
<p>It would be great if it was possible to select not just one reference at a time when linking an entry to bibliography. It is possible already to link more than one file at one time (click the link button, choose all the files you want to link, and save). It would be great if this would be possible for references as well.</p> OpenAtlas - Feature #1660 (Acknowledged): Tool: Age estimationhttps://redmine.openatlas.eu/issues/16602022-03-21T15:48:01ZNina Richards
<p>Tool for age at death estimation based on human remains. See <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Anthropological_Analyses">Anthropological Analyses</a>.<br />Precedes <a class="issue tracker-2 status-7 priority-4 priority-default" title="Feature: Human Remains Interface (Acknowledged)" href="https://redmine.openatlas.eu/issues/1352">#1352</a> so we know which "Skelttmännchen" to show according to age bracket.</p> OpenAtlas - Feature #1648 (Acknowledged): Relative Chronological/Spatial relation between two art...https://redmine.openatlas.eu/issues/16482022-03-01T15:41:37ZJona Schlegel
<p>This would allow us to say that one graffito (artifact) was created above another graffito (artifact).</p> OpenAtlas - Feature #1573 (Acknowledged): 3d geometrieshttps://redmine.openatlas.eu/issues/15732021-09-11T14:28:21ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>In the INDIGO projects we will receive additional 3d geometry data. So far we only map points, lines and polygons so we need another geometry type (with height).<br />We will also use this opportunity to merge all GIS data into one table and move into the model schema (instead using a dedicated GIS schema)</p>
<p>In the first version they will be shown on the map but without functionality to add or edit them manually.</p>
<strong>To consider</strong>
<ul>
<li>Adapting database (see merge suggestion above)</li>
<li>How do we import them (INDIGO workflow specific)</li>
<li>How do we present them on the map, I guess it should be possible to "flatten" them</li>
<li>How to prevent them being overridden when working with maps the "classic" way</li>
</ul> OpenAtlas - Feature #1553 (Acknowledged): Boolean search operatorshttps://redmine.openatlas.eu/issues/15532021-07-29T10:26:39ZBecca Grose
<p>Might it be possible to enable Boolean search functionality on the OpenAtlas user interface?</p>
<pre><code>Currently, it does not seem to work (at least on the CONNEC database) and I'm not sure if this is design or a bug. If it were easy to introduce, it would be very useful for us and even more useful for end users.</code></pre>
<p>Absolutely understand if this isn't possible!</p> OpenAtlas - Feature #1525 (Acknowledged): Model: Spacetime Volume E92https://redmine.openatlas.eu/issues/15252021-06-02T11:11:16ZVincent Ducatteeuwvincent.ducatteeuw@ugent.be
<p><strong>Context:</strong><br />In OpenAtlas “Place’ is used as a label for a combination of multiple CRM entities. It is the “E18 Physical Thing” - that represents for example a settlement, a church or a castle - combined with an “E53 Place” entity that represents its space/location. The location is combined with a “E94 Space Primitive” and stored as a PostGIS geometry.</p>
<p><strong>Issue:</strong> <br />Currently multiple geometries and toponyms can be assigned to a “Place”. However, temporally dating these geometries and toponyms is not possible. For example, it is not possible to say that New York was named “Nieuw Amsterdam” during the 17th century and "New York" during the 18th century. (This is possible in the ongoing GeoJSON-T format).</p>
<p><strong>Proposal:</strong><br />If possible, I would suggest adapting the current OpenAtlas/CIDOC CRM data model to incorporate temporally dating geometries and toponyms through the use of the “E92 Spacetime Volume” and its properties “P160_has_temporal_projection” and “P161_has_spatial_projection” (Schneider et al., 2019)</p>
<p>“E18 Physical Thing” is a subclass of E92 and inherits these properties. If my understanding is correct, a time-span can be assigned to an “E18 Physical Thing” during which a toponym and geometry is valid. Multiple E18s with a timespan can refer to the same place. For example, an E18 entity referring to a city during the 17th century and an E18 entity referring to the same city in the 18th century. These timed observations can be linked to a new E18 that refers to the city from it’s beginning to its end via the property “P10_falls_within”. As attachment, I have provided an UML representation of the CIDOC CRM Classes. If my reasoning is incorrect, I will try to adapt the model as soon as possible.</p>
<p>This addition to the model would be very beneficial for the development of historical gazetteers and the mapping to GeoJSON-T.</p> OpenAtlas - Feature #1499 (Acknowledged): Adding references to imageshttps://redmine.openatlas.eu/issues/14992021-04-15T12:26:35ZNina Richards
<p>As for <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Adding references to subunits (citation) (Closed)" href="https://redmine.openatlas.eu/issues/1216">#1216</a> it would be handy to get a list of references already used in connected subunits but also the place for images.</p> OpenAtlas - Feature #1473 (Acknowledged): Tool: Bone Inventoryhttps://redmine.openatlas.eu/issues/14732021-03-01T11:18:08ZNina Richards
<p>For the (graphical) anthropological interface bones and bone parts have to be recorded, see <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Anthropological_Analyses#Bone-Inventory">Anthropological Analyses</a> and <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Bone_inventory">Bone_inventory</a></p>
<p>Possible interesting: <a class="external" href="https://humanos.cnrs.fr/?lang=en">https://humanos.cnrs.fr/?lang=en</a></p> OpenAtlas - Feature #1352 (Acknowledged): Human Remains Interfacehttps://redmine.openatlas.eu/issues/13522020-09-29T07:50:49ZNina Richards
<p>A (graphical) interface to enter anthropological data - making it easier to enter them not from published sources but raw information from analyses. Showing a graphical overview of preserved bones of a burial (also called "Skelettmännchen") as well as results from analyzes (e.g. age estimation and sex estimation).<br />This serves also as a base for implementing other tools: <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Anthropological_Analyses">Anthropological_Analyses</a></p>
<p>+1 Stefan</p> OpenAtlas - Feature #1233 (Acknowledged): API: External Authentication https://redmine.openatlas.eu/issues/12332020-05-10T08:34:26ZBernhard Koschiček-Krombholz
<p>External Authentication will be needed for projects who want a frontend without exposing all data (no public API).<br />For implementing an API authentication method see: <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/API_Authentication">Whitepaper</a>, <a href="https://realpython.com/token-based-authentication-with-flask/" class="external">authentication-with-flask</a></p>
<p>To consider: webclients will request data so we can't e.g. just block IPs or similar.</p> OpenAtlas - Feature #1064 (Acknowledged): Restructure UI for historical sourceshttps://redmine.openatlas.eu/issues/10642019-10-04T14:22:07ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>Due to the increasing complexity and additional features regarding written sources and their interconnections we need to reorganise the respective UI.</p>
<p>See draft: <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Source_workflow">Source workflow</a></p> OpenAtlas - Feature #1051 (Acknowledged): Remove workaround in Leaflet GeoNames pluginhttps://redmine.openatlas.eu/issues/10512019-08-14T13:21:16ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>Since we needed more information (e.g. what type of GeoNames entity) we changed a few line in</p>
<p>/openatlas/openatlas/static/vendor/leaflet-1.3.4/Geonames-0.4.7/L.Control.Geonames.js</p>
<p>see <a class="external" href="https://github.com/acdh-oeaw/OpenAtlas/commit/16a3a651bb6b448fa635308c48a4f83f3fe09fd6">https://github.com/acdh-oeaw/OpenAtlas/commit/16a3a651bb6b448fa635308c48a4f83f3fe09fd6</a></p>
<p>It would be good at some point to remove this manual changes.</p> OpenAtlas - Feature #1004 (Assigned): Dates before 4713 BChttps://redmine.openatlas.eu/issues/10042019-03-26T17:01:53ZStefan Eichertstefan.eichert@univie.ac.at
<p>Dates before 4713 BC are problematic because they can't be saved as a PostgreSQL timestamp.<br />One solution would be to implement a parallel date system (e.g. using only years) but this would be way to cumbersome and error prone, we really like using the database for date operations.</p>
<p>So I ask in the PostgreSQL mailing list about it.<br /><a class="external" href="https://www.postgresql.org/message-id/ca438ff8331c4e109aa1b75a130948ac%40oeaw.ac.at">https://www.postgresql.org/message-id/ca438ff8331c4e109aa1b75a130948ac%40oeaw.ac.at</a></p> OpenAtlas - Feature #998 (Acknowledged): Filter for Entity Overviewshttps://redmine.openatlas.eu/issues/9982019-03-06T09:03:28ZBernhard Koschiček-Krombholz
<p>It would be very comfortable if we can filter the entity overviews with their types, e.g. only show all events with the type "Building activity". In the contrary, it should also be possible to say, show me everything except "Building activity".</p>
<p>For the UI it would be a additional switchable overview site.</p>
<p>Hope it was clear ;)</p>