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.