Ah... It does not say 1.58, so I assumed it was 1.57.

No, because it is always the work in progress next version, in this case it will become 1.5.8 later on

CMS Working.... But now openstreetmap does not display at all good or bad

Review your logs.

where do you set debugging options? I cant remember

zp-core/global-definitions.php

Errors are logged anyway.

OK... Interestingly.... Not seeing any errors in debug.log, or apache log.

Just no openstreetmaps

I am seeing new error... but it is not tied to web access

{3920463:Tue, 09 Mar 2021 20:49:45 GMT}
NOTICE: Uninitialized string offset: 1 in /var/www/cms.waltrips.com/zp-core/exif/makers/gps.php on line 82
formatGPSData called from parseGPS (gps.php [216])
from read_entry (exif.php [830])
from read_exif_data_raw (exif.php [1036])
from read_exif_data_protected (functions.php [2451])
from Image->updateMetaData (class-image.php [340])
from Gallery->garbageCollect (class-gallery.php [818])
from admin-refresh-metadata.php [33]

And I have been hunting around all of the settings... OpenStreeMap just is not working. I even tried switching to another theme (zenpage)

It seems that your image has invalid or corrupt meta data as the notice above tells. That is the core metadata handler and not the OSM plugin.

For example if there a values but not "real coordinates". Currently there is no check if the coordinates are valid itself. I have to look at the exif handler what it exaclty does and if there is already a check (it is technically a 3rd party tool that was taken in once).

I looked at the exif library and since it is a bit old it and I am not that familiar with it in detail, it seems not to use the PHP standard function exif_read_data() for reading the data but instead directly parses the file on its own.

I guess this library was made before this function was available. Perhaps not the best way to parse exif data anymore. And ZP does use exif_read_data() for getting image rotation values for example.

I reviewed and apparently my fix is not working as expected. Besides the issue your image provides.

There is a fix up that also validates that the geocoords are actually within the valid range. However there is no fix if there is actually no proper data within the image.