Imagery ID key for some entries about editor-layer-index HOT 12 CLOSED

Hey @Zverik any more details on the 'planned imagery offset database'? Is this something that could be hosted under /osmlab? I can write a script to do conflation if there's an api or static file.

from editor-layer-index.

Everything's here: http://wiki.openstreetmap.org/wiki/Imagery_Offset_Database. I doubt it can be hosted on github, and see no reason for that. Also there is no need for conflation: those special ids are very rare, I came up with only two (three at max), and the list has stayed the same for 1,5 years now.

from editor-layer-index.

Are there already ids for layers? Should we just choose them in this project? Need more context to actually implement this.

from editor-layer-index.

It's not a programming task, it concerns only the data model. Right now ids are only used for the offset database: no one before tried to come up with a scheme to determine unique ids for imagery layers. Probably because in almost every editor it is possible to add custom layers. But to effectively manage offset bookmarks, imagery layer ids are essential. So to avoid listing every possible imagery source and making users invent identifiers for them, I've made a simple algorithm /for editor apps/ to construct id based on a URL of an imagery layer.

The algorithm works in most cases, except for two layers that are neither regular WMS nor TMS: Bing layer (which uses quadtiles and therefore is marked a special case in all layer lists, including this one) and russian ScanEx IRS layer (for which I don't even know exact URL). Those layers needed to have identifiers not based on URL, because for them URL could change at any moment (for example, Bing URL has a variable number in its parameters which differs from app to app). So I invented both identifiers arbitrarily (though they're rather obvious) and prepared a wiki page on which all such identifiers could be catalogued.

So in this issue I propose to add a field to an imagery entry for storing this identifier. This essentially concerns only the Bing entry in the index, but may apply to any future layers which do not fit into regular WMS/TMS types.

from editor-layer-index.

I've made a simple algorithm /for editor apps/ to construct id based on a URL of an imagery layer.

What is it?

So basically this amounts to adding a <source_tag>bing</source_tag> to bing?

from editor-layer-index.

The link to the algorithm was in the opening message :) This one.

Yes, just a parameter to a tag (or a tag). I'm not sure it should be called source_tag, I think something like imagery_id (or a simple id) would be better.

from editor-layer-index.

...but of course it could be pre-generated for all entries in the index, if editors are to use only pre-generated files (and not that source xml). The reference implementation in java is here.

from editor-layer-index.

It doesn't look to me like you've specified an unambiguous algorithm. What is the definition of a "variable part" of a URL? Is an API key a "variable part"? An API version identifier? A cache-busting parameter? A locale or region specifier? Clearly your reference implementation makes choices one way or another, but it's not clear to me the rationale for those choices, nor that I could reimplement the algorithm in a way that would be likely to produce the same results as yours for any meaningful input set.

I would prefer that unique, unambiguous IDs are assigned in the index, which then can be used to look up the offset.

from editor-layer-index.

Variable part = part that defined through a variable, e.g. zoom, x, y, bbox, projection and so on. Everything that in imagery.xml is inside curly brackets. Everything else -- including API key -- is considered constant part. This algorithm works for every imagery in josm, potlatch and iD list, but I agree, API keys are not considered. I really don't know what to do with them. Maybe assign those sources an identifier and be done with it :)

As for creating and requiring ids not dependent on URL for every imagery source, I'm against it. The reason is simple: custom layers. The layer that in one editor is considered part of the library and is assigned a specific ID, can be enabled as a custom layer using its URL, and in your case there's no way of telling those are the same layer.

But I'm all for improving the id construction algorithm, if you have any suggestions that would work nicely with josm, merkaartor, potlatch, iD and other editors.

from editor-layer-index.

None of the existing information uniquely defines a layer and it doesn't make sense to make a unique key off of the URL template (because the URL for the layer could change), so let's just make one up. My suggestion is to use the "slug" created by the Python script that corresponds to the filename of the JSON document created. This implies that you can't have two layers that have a similar name, but if that's a problem then we should adjust the script so it adds arbitrary information (like a counter) at the end of the slug instead of removing the existing document.

from editor-layer-index.

Sorry, Ian, but it's like you didn't read the discussion before replying. Two points:

1. The algorithm works for every imagery layer included in this index and in lists in josm, potlatch and iD (except Bing, but this index doesn't support it either).
2. Let's assume some user group gained access to a private WMS which allows tracing into OSM. It cannot ever be included in this index, and therefore get a global identifier. How would those users exchange their offset bookmarks?

But the thing that bugs me the most is that while I propose to introduce a soft dependency to this index on a wiki page, you suggest to create a hard dependency for every editor that wishes to use offset database on this index. It's not much unlike requiring the OSM data to be edited with a single editor only. I am strongly opposed to any hard dependencies in OSM infrastructure, so I wouldn't allow it for the offset database.

So the options are either to fix the suggested algorithm to be applicable to as many imagery sources as possible, or to use it as is.

from editor-layer-index.

Closing as stale. The id property has existed for a while.

from editor-layer-index.