See https://github.com/nuest/optimeta-plugin-geo/blob/98eb9a350a84090c9ff2249614319ef9520805cc/js/submissionMetadataFormFields.js#L39

Is it possible to extend one plugin from another plugin?

OJS has MARC21 as output for metadata formats: https://github.com/pkp/ojs/blob/main/plugins/oaiMetadataFormats/marcxml/OAIMetadataFormatPlugin_MARC21.inc.php

Some resources on geographic metadata in MARC21:

• https://www.loc.gov/marc/bibliographic/bd052.html
• https://www.loc.gov/marc/classification/cd034.html
• https://www.loc.gov/marc/authority/ad034.html
• https://www.oclc.org/bibformats/en/0xx/034.html

PostGIS now also supports MARC21, see https://github.com/postgis/postgis/search?q=marc21

Re-visit how plugins should access configurations.

This would be feasible only if OJS / pkp-lib actually hand a public search endpoint, e.g., OpenSearch-based.

See also tnier01/geoOJS#9

Antrag: "die artikel- und zeitschriftenspezifische Verfügbarmachung [...], über Integration in Metadatenexporte (z. B. OAI-PMH (via Dublin Core) und natives XML)"

• one integration test/headless test for HTML head metadata
• one headless test for map
• tests run locally with Cypress
• tests run as GitHub action

Useful resources to check out:

• https://docs.pkp.sfu.ca/dev/testing/en/plugins-themes
• https://github.com/pkp/ojs/blob/ef6facfcdc9b86a58bc3c788522f3b8d76730198/cypress/tests/data/20-CreateContext.spec.js#L70
• https://github.com/pkp/ojs/tree/main/cypress/tests/data/60-content (for submissions/content creation)
• useful functions for tests: https://github.com/pkp/pkp-lib/blob/main/cypress/support/commands.js
• https://github.com/RBoelter/twitterBlock/blob/stable-3_2_1/.github/workflows/twitter_ci_tests.yml
• https://github.com/o2r-project/ojs-erc-plugin/tree/master/test

Antrag: "die artikel- und zeitschriftenspezifische Verfügbarmachung [..] über die kartografische bzw. grafische Darstellung der räumlichen und zeitlichen Ausdehnung einzelner und aller Artikel einer Zeitschrift"

• show article on a map
• #63

Antrag: "die artikel- und zeitschriftenspezifische Verfügbarmachung [...], über die OJS-API (REST API Usage Guide: https://docs.pkp.sfu.ca/dev/api/; Enkodierung z. B. als GeoJSON oder Linked Open Data in Turtle: https://de.wikipedia.org/wiki/Turtle_(Syntax)​)"

Not sure how this could really work. Maybe have a http://ojs/article/geo.json endpoint?

• API endpoint providing data for each article
• Use the API endpoint for articles for the download button
• API endpoint providing data for each issue > #29
• API endpoint providing data for each journal > -29
• Create an issue about transferring the existing maps to the new API endpoint
• Add info about API below each map

"Recommend Similar" plugin: https://github.com/pkp/ojs/tree/main/plugins/generic/recommendBySimilarity

Is it possible to extend one plugin from another plugin?

This could be relevant related information that is already available through WMS or WMTS, e.g., protected areas, historic maps, ...

Related to #17

For discovery, a temporal precision of "days" is completely sufficient, can be extended later on user request.

Current UI:

Antrag: "die Verknüpfung von Geometrien und Ortsnamen (Vorschlagen von (normierter) Geometrien und Namen über Gazetteers (z. B. GeoNames, ​https://www.geonames.org/, Datenbanken mit Administrationsgrenzen (z. B. GADM, https://gadm.org/​, und Normdaten (z. B. Gemeinsame Normdatei - GND, ​https://www.dnb.de/DE/Professionell/Standardisierung/GND/gnd_node.html​ )"

Amdministrative regions first, fixed datasets, possible consider #28

Gazetteer candidates

• 👉 Geocoder PHP 👈 supports basically all out of the box > https://geocoder-php.org/docs/ | https://github.com/geocoder-php/Geocoder/
  • also has Laravel plugin: https://packagist.org/packages/toin0u/geocoder-laravel
• Geonames (implemented)
• Komoot Photon (tnier01/geoOJS#6): https://github.com/komoot/photon | https://photon.komoot.io/
• OSMNames: https://osmnames.org/
• #66
• GEBCO underwater features Gazetter (for geo journals?): https://www.ngdc.noaa.gov/gazetteer/docs/swagger#/Features
• GEOnet Names Server (has WFS Gazetteer Profile; WFS-G): https://geonames.nga.mil/gns/html/gns_services.html (generic WFS-G support?)
• https://www.library.ucsb.edu/geospatial/alexandria-digital-library-gazetteer

Steps gazetteer

• implement abstraction layer for gazetteers try out Geocoder PHP and how it can be integrated with the JavaScript code to sync text and map
• implement generic configuration UI, possibly generated, or just for selected providers?
• tunnel the requests through OJS to not expose third party authentication details, see tnier01/geoOJS#5 > check notes of call, likely Geocoder PHP solves this for us
• make Komot Phonton (no login required) default

Steps datasets

• check licenses of available datasets
• datasets are probably to large to be shipped with the plugin > add download functionality? ideally this is fully automated (pick one from the list, it gets downloaded and enabled)
  • do datasets need to be preprocessed to be used?
• implement abstraction layer, ideally integrate with gazetteer
• integrate 2-3 repositories

If we go down to minutes, we will not only struggle with time zones (see tnier01/geoOJS#12) and the related communication/filtering problems, a resolution more detailed than days is also not helpful for filtering.

See http://www.daterangepicker.com/ for configuration options.

The reverse of #5

See also tnier01/geoOJS#16

Antrag: "die artikel- und zeitschriftenspezifische Verfügbarmachung über Einbettung ins HTML (z. B. über Mikroformate (​http://microformats.org/wiki/h-geo​) und Element von Dublin Core (Dublin Core ‘Coverage’ ist bereits rudimentär als einfaches Textfeld im Dublin Core Meta Plugin umgesetzt, jedoch sollten hier die Nutzung von ‘Spatial Coverage’ und ‘Temporal Coverage’, ggf. sogar DCLite4G, https://wiki.osgeo.org/wiki/DCLite4G​, geprüft werden), und Schema.org, ​https://schema.org/GeoShape​)"

• Dublin Core
• microformats (h-geo) don't implement, only supports lat/lon coordinate pair, see http://microformats.org/wiki/h-geo
• #92
• there is a test

Antrag: "Die erweiterten Suchfunktionen nutzen räumliche Indizes für räumliche und zeitlichen Einschränkung der Ergebnisse bei Artikelsuche."

• use a proper spatial index (database? search database?)
• allow users to show all articles in a specific country
• simplify search, e.g., just "overlaps" queries

Ideally only a more powerful variant of #10

From tnier01/geoOJS#11

Display the geospatial metadata (locations) of all articles in an issue on one map in the issue overview. The same is conceivable for all issues in a journal.

Antrag: "Die automatische Extraktion unterstützt hochgeladene Geodaten, Links zu ausgewählten Diensten, und die Herleitung von Geodaten über Titel und Abstract des Artikels mit einem Gazetteer."

Antrag: "Nutzer-getriebene Metadatenerfassung einfacher Geometrien auf Basis einer Web-Karte (Punkte, Linien, Polygone; Erfassung auf Basis von Leaflet: ​ https://leafletjs.com/)"

• [ ] create wireframes (necessary?)
• implement storage of geodata
  • Geodaten als GeoJSON
  • Well-Known-Text/WKT?
  • ... in MySQL

This only makes sense after good test coverage is given.

• https://github.com/Leaflet/Leaflet/releases/
• https://github.com/Leaflet/Leaflet.draw/tags (is there a later one in a different project? can we use https://www.npmjs.com/package/leaflet-draw/v/1.0.4 ?)
• https://github.com/moment/moment/tags
• https://github.com/dangrossman/daterangepicker/releases
• https://github.com/perliedman/leaflet-control-geocoder/releases

• Add docs to README about how this works
• Update package.json, see #51

See tnier01/geoOJS#15

The OJS operator should be able to select and provide these, e.g., they might have their own (styled?) basemap or access to a fast tile server)

https://forum.pkp.sfu.ca/t/how-to-include-javascript-dependencies-in-ojs-plugin-project/73098/6

Better: Use composer! See https://asset-packagist.org/site/about

Alternative: npm and package.json - but how to get the files in the right places with decent file names?

Closely related to #41.

We need the proper types and indexes to really work with the spatial and temporal information, and for that the current approach of putting text in the submission metadata is not feasible.

Related to #7 and #27 but each with a different data set;

• map shows geometries
• clicking on a geometry opens pop-up with article metadata and link to article landing page

To be extended in #96

Depends on #4

• create file on demand (add cache if it takes long)
• add link on the map view page, e.g. #27

From tnier01/geoOJS#14

Instead of administrative units, also other spatial entities can be of interest. For an ecological journal, World Protected Areas (protectedplanet.net/en) are probably more interesting, than administrative units. So the integration of alternative spatial entities would be worthwhile. Or maybe not only the initial integration but also the possibility for the journal operators to integrate alternative spatial entities themselves, e.g. based on a GeoPackage.

https://github.com/withanage/ror/tree/master/docu

Antrag: "Die automatische Extraktion unterstützt hochgeladene Geodaten, Links zu ausgewählten Diensten, und die Herleitung von Geodaten über Titel und Abstract des Artikels mit einem Gazetteer."

Candidates

• Data repositories
  • PANGAEA (https://www.pangaea.de/)
  • GFZ Data Services (https://dataservices.gfz-potsdam.de/)
  • Hydroshare
  • Dryad
• Catalogs and geodata services
  • CKAN (​https://ckan.org/portfolio/geospatial/​)
  • OGC CSW (https://de.wikipedia.org/wiki/Web_Catalogue_Service )
  • OGC W{C,F}S (https://de.wikipedia.org/wiki/Web_Feature_Service​, https://de.wikipedia.org/wiki/Web_Coverage_Service​)
    • e.g., a WFS query response
  • STAC (see https://github.com/radiantearth/stac-spec/blob/master/extensions/scientific/README.md)
• COG URL (cloud-optimized GeoTIFF)

Goal

Find out which PHP library is the most promising one to support our requirements and works well with the OJS tooling, e.g., Laravel, and support the required databases (primarily MySQL, secondary: Postgres/PostGIS)

OJS

OJS supports MySQL >= 4.1 or PostgreSQL >= 9.1.5.

This page gives a good overview of the spatial features in MySQL and MariaDB: https://mariadb.com/kb/en/mysqlmariadb-spatial-support-matrix/

Libraries

Candidates for evaluation

• https://github.com/brick/geo

  Brick\Geo seems to be pretty powerful (based on GEOS) and has all functions we need; seems well maintained, single maintainer though "brick" looks like a big org, only four contributors though; would require a direct database connection via a PDO; also support for SpatiaLite, so we could also do standalone variant

• Laravel libraries

  • https://github.com/grimzy/laravel-mysql-spatial

    Supports MySQL >= 5.6 and last update ~1 year ago, seems to be (not actively) maintained by individual; yet, seems to have all features we need; actually many users but also 14 open PRs, some with seemingly trivial bugfixes, none of the forks is much ahead without being behind, see https://useful-forks.github.io/?repo=grimzy%2Flaravel-mysql-spatial

    See also https://medium.com/@brice_hartmann/getting-started-with-geospatial-data-in-laravel-94502dc74d55 for some quick examples

  • https://github.com/karomap/laravel-geo is the most recent fork of https://github.com/eleven-lab/laravel-geo (via https://useful-forks.github.io/?repo=eleven-lab/laravel-geo) with support for Laravel 5.4+, seems to be maintained by individual, support for MySQL and PostreSQL; documentation at https://karomap.github.io/laravel-geo/

  • https://github.com/mstaack/laravel-postgis

    Similar to the above (Laravel migrations etc.), meets all our requirements but for Postgres with PostGIS, 20+ contributors and relatively actively maintained by individual;

Other

• https://geophp.net/

  No changes since 2016, a fork maintained until mid 2020 seems to be https://github.com/funiq/geoPHP (https://useful-forks.github.io/?repo=phayes%2FgeoPHP), but only low level geometric operations, only Postgres, no MySQL/MariaDB

• https://packagist.org/packages/mjaschen/phpgeo | https://github.com/mjaschen/phpgeo

  Rather low-level geo library, not all required functions; seems well maintained (15 contributors); documentation at https://phpgeo.marcusjaschen.de/

• https://packagist.org/packages/league/geotools

  Looks well-maintained, 30+ contributors, but no polygon overlapping operations;

Evaluation

First thoughts

Pro Laravel libraries: we can just integrate with the existing database migration processes, no own schema (hopefully)

Pro brick/geo: Seems to be most well maintained, no need to distinguish between MySQL and other DBMSs, but need own schema then... maybe that's not so hard because we will be the only one

Tasks

• re-visit the libraries and check maintenance status
• create a new database table with a spatial column using each of the candidate libraries
• insert a GeometryCollection of a few points, lines, and polygons into a MySQL database using each of the candidate libraries, from the plugin

The option does not exist in 3.3.x anymore, can keeping it just for the backport to 3.2 is not really useful.

Add plugin settings to configure the default map view journal-wide.

Ideally the user is just shown a map and can configure the extent as desired and then "save".

Related to #38

Merge #78 first and use new settings class.

From tnier01/geoOJS#7 :

• enable/disable temporal metadata collection/display
• enable/disable geospatial metadata collection/display
• configure allowed geospatial shapes
• configure validation rules for timestamps?
• are authors allowed to manually edit the coverage string, or may it only be manipulated via the geometry input?
• ...

(does it make sense to configure collection and display separately?)

See tnier01/geoOJS#8

The test article should not have geospatial metadata, but the coverage field filled out.

• merge codebases across independent git repositories
• fix naming
• add note and ref to thesis to README
• run locally

See "Linked data: a Geographic Perspective" > https://www.taylorfrancis.com/books/oa-mono/10.1201/b13877/linked-data-geographic-perspective-glen-hart-catherine-dolbear

From tnier01/geoOJS#13

If the user enabled the coverage element in the settings (Settings->Workflow->Submission->Metadata->Coverage), then there are two inputs for the coverage element in the submission view, one created by OJS and one created by the geoOJS Plugin. But both store their data in the same database element ("coverage"). Besides the initial coverage input field is not able to show the stored data, stored by the geoOJS plugin, correctly(like shown in the screenshot).

Gist: So the initial coverage input field must be disabled when using the geoOJS plugin.
Since this is only the case when "Coverage" is activated, a straightforward solution could be to set the field to enable=false in JavaScript from our plugin.

"using schema.org to enable data discovery and via Google search" (via https://www.frontiersin.org/research-topics/20014/democratizing-data-environmental-data-access-and-its-future) - maybe this is possible for the article pages, or for the geoportal?

https://www.repo.uni-hannover.de/oai/request?verb=Identify

Antrag: "Die automatische Extraktion unterstützt hochgeladene Geodaten, Links zu ausgewählten Diensten, und die Herleitung von Geodaten über Titel und Abstract des Artikels mit einem Gazetteer."

Feature:

• User can click a button "use title and abstract to suggest geospatial extent"

https://docs.pkp.sfu.ca/dev/plugin-guide/en/release

Second part of #11 - See also tnier01/geoOJS#3

We need an index for searching/filtering based on time stamps.

Antrag: "die artikel- und zeitschriftenspezifische Verfügbarmachung [..] über die kartografische bzw. grafische Darstellung der räumlichen und zeitlichen Ausdehnung [..] aller Artikel einer Zeitschrift und im Zeitstrahl"

• add a page to the journal: https://docs.pkp.sfu.ca/dev/plugin-guide/en/examples-custom-page
• find a good way to add the page to the main navigation menu
• Map shows spatial extent of all articles
• popup has link to the article page
• Time line visualisation for temporal extent > #74

... so that editors can review and potentially adjust them.

**Base on ** https://github.com/TIBHannover/optimetaCitations/blob/main/OptimetaCitationsPlugin.inc.php#L114 and https://github.com/TIBHannover/optimetaCitations/blob/main/classes/Components/Forms/PublicationForm.inc.php

See forum.pkp.sfu.ca/t/insert-in-submission-settings-table/61291/19?u=tnier01

(via tnier01/geoOJS#4)

Possibly a duplicate of #53

The license of the spatial and temporal metadata should be made clear

• make license description configurable for OJS instance > all target databases (COCI, Wikidata) are CC0
• mention CC0 license to authors when they enter it (small) ("what happens with the data") in einem kleinen Popup
• for users/developers where they are shown, e.g., #7 #29 #27
• add license sentence under the download button and under each map/timeline

See tnier01/geoOJS#2

It could be helpful for the reader if the final administrative unit listed under "Coverage Information" would be highlighted in the map when the cursor is hovering the coverage information field (highlight the administrative unit (but not "Earth, Europe, Republic of Austria") in the same way.

Now:

Mockup:

• change name of section: "article's area and time of interest" ?
• move all explanatory text to a little "info" icon and a tooltip/popup
  • https://www.w3schools.com/css/css_tooltip.asp
  • jquery-ui is also loaded (only in the backend!): https://jqueryui.com/tooltip/ or use a toggle effect to show and hide detailed information: https://jqueryui.com/toggle/
• explain authors that they can choose the appropriate level of detail, e.g., to protect data sources