Point OHM iD at OHM-specific ELI

[jeffreyameyer]

What's your idea for a cool feature that would help you use OHM better.

In order to make it easier to trace old maps, it'd be great if OHM's iD layer selector pointed at a list of historical x/y/z servers.

We have such an ELI set up (https://openhistoricalmap.github.io/ohm-editor-layer-index/imagery.xml), but we do not a) have OHM iD pointing at it, and b) the list isn't ready to be pointed at.

This task depends on #296

Once the list is ready to be pointed at, we should move the OHM iD ELI pointer from the current one to the OHM ELI.

Current workarounds
Use JOSM and point to the OHM ELI.
Add custom layers one at a time.

Additional info
Please add any other context, comparables, screenshots, pictures of drawings on napkins about the feature request here.

[danrademacher]

in the iD repo, the output of the ELI file is hosted here:
https://github.com/OpenHistoricalMap/iD/blob/staging/data/imagery.json

That in turn is generated by this script:
https://github.com/OpenHistoricalMap/iD/blob/staging/scripts/update_imagery.js

so if we change this line to point at our ELI, then we should have an easy route to run our own ELI updates:
https://github.com/OpenHistoricalMap/iD/blob/staging/scripts/update_imagery.js#L3

[danrademacher]

Ah, sorry, this is actually a reference to this line in devDependencies in package.json

   "editor-layer-index": "github:osmlab/editor-layer-index#gh-pages",

I thought we could do this just by changing code on the iD side, to this:

    "editor-layer-index": "github:OpenHistoricalMap/ohm-editor-layer-index/#dist",

With that change, npm run imagery completes successfully, and I would expect the contents of https://openhistoricalmap.github.io/ohm-editor-layer-index/imagery.json to be written into the iD-local copy of imagery.json, but... none of our historical layers are present, the output is unchanged from the normal OSM run.

[danrademacher]

Seems like we might need to publish our own Node module for this to work. @andrewharvey was that your assumption, that we'd need to publish a separate node module? If so, I can pull in one of our devs to make sure it's done correctly (vs my as project manager poking around...), but first I wanted to check in with you to see if you know if that's what's required to pull this into iD.

[andrewharvey]

If the location in package.json is github:osmlab/editor-layer-index#gh-pages originally then we shouldn't need to publish to npm. Let me take a look at it from the iD side, maybe some of the changes I made impact it, I'll try to look later today.

[danrademacher]

OK, this is what I tried (on a branch):
OpenHistoricalMap/iD@3309500

The script output doesn't include what I would expect, such strings as "1820-1866 Alpes Maritime SCAN"

[andrewharvey]

@danrademacher hang on what about OpenHistoricalMap/iD#73?

[danrademacher]

Oy, I totally forgot about that PR! Lemme take a look at that now

[danrademacher]

Works great. Sorry I forgot we had that pending since July!

So this is the one to merge when the ELI is ready:
OpenHistoricalMap/iD#73

I deleted my duplicate (and incomplete) branch for the record.

[danrademacher]

Here's the working ELI in local dev:

I know part of the effort in #296 is finding the right set of layers to include for reference NOW vs historical periods.

The local ELI update I just did left me with only MAXAR imagery as a worldwide reference layer:

Not sure if that's expected at this point or not.

[andrewharvey]

I think iD has special treatment of Maxar so it never exists in the index and always loaded by iD code, might need to check that, and if we can use Maxar.

[danrademacher]

Not sure what happened here last fall that caused us to never deploy this change.

I just cherry picked the commits that made this work a year ago and put them on top of our updated iD and it is working as expected locally, as shown here with various layers around Sydney:

This will get deployed the next time we update iD on the website, which should be in next couple of weeks.

@jeffreyameyer, FYI, we should be able to get the OHM specific ELI live on iD in first part of January, and then we can tell OHM community about started to contribute to the ELI based on https://github.com/OpenHistoricalMap/ohm-editor-layer-index/blob/main/CONTRIBUTING.md

Based on this GH Action, any push to the ELI repo will republish the ELI to the dist branch, which serves the GH Pages at https://openhistoricalmap.github.io/ohm-editor-layer-index/

That's also where iD looks, based on this code here, for the latest ELI. I suspect for that, we only get a new ELI in iD when we do npm run build in our iD repo and deploy that code to Rails, so we'll have to keep in mind to do that whenever we have changes to the upstream ELI.

[danrademacher]

The above comment was a slight case of wishful thinking on my part that it would be so easy. Just realized I need to run the various update things. Here we go:

That's after running the commands at https://github.com/OpenHistoricalMap/iD/blob/844a12eb33d846f30f4768d6d9f5eec161316b79/RELEASING.md#update-develop-branch, specifically:

$  rm -rf node_modules/ohm-editor-layer-index/
$  npm install
$  npm run imagery
$  npm run all
$  git add . && git commit -m 'npm run imagery'

Very short list of imagery here! I wonder if that's good, and then folks will contribute, or a problem, since people might rely on those OSM layers for various thijngs.

@jeffreyameyer Id like to check in with you about what you want to do here before I just deploy this and remove so much imagery that people might be using.

[andrewharvey]

I just cherry picked the commits that made this work a year ago and put them on top of our updated iD and it is working as expected locally, as shown here with various layers around Sydney:

Actually that shows its now working it should have imagery from 1943 going forward every few years.

The corresponding iD change was at OpenHistoricalMap/iD#73 but might be outdated now.

[danrademacher]

@andrewharvey it does show that in Autstralia:

Looking at https://openhistoricalmap.github.io/ohm-editor-layer-index/, I would expect 24 imagery options in Australia (confirmed), one in France, and one in Boston (confirmed). So 26 total options.

Would you expect more options in other parts of the world? I assume for that we'd need to do a lot of outreach to get folks to add to our ELI and build it up over time.

[andrewharvey]

Great! I couldn't see them in your screenshot at #297 (comment)

I think if we include a link to the OHM ELI at https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Resources hopefully overtime more historical imagery and map sources can be added to the index.