simonpoole
commented
6 years ago Given that've suggested similar things I suppose I should comment.
I've been thinking about where to take this project next for a while. The current index, which was a perfect solution when we had a dozen layers, is really showing its age.
* Everyone downloads 1.75 MB of geojson, most of which is in areas they're never going to edit * Everyone downloads all entries, even if our clients don't support the wms or wmts catalog endpoints.
We only have three editors P1, P2 and iD for which we can assume that network connectivity is present, essentially everything else will as a tendency pre-download/bundle/whatever the data and this should still be possible post any changes that are made.
Obviously any such system should allow generating a configuration that only contains supported sources (I doubt that anybody ever included WMS sources if they were not supported, they were simply removed before packaging).
* It's impossible to specify that a layer is "best" in some places but not others. * It's impossible to store extra local attributes like imagery offsets
Both imagery offsets and quality assessments would seem to share a couple of similar properties that might make it possible to include them in one system (as noted above there should be a facility to store this locally).
* The index only stores imagery. Local communities are another, incompatible project. For things like address display rules, local language preferences or local defaults, we don't even have a centralised index, and creating one would be hard.
This would seem to be substantially off topic and out of scope.
* The [JOSM schism](https://josm.openstreetmap.de/wiki/ImageryCompare) is wasting volunteer time. * The output is statically included in iD and only gets updated when a new version gets released. * Contributing a new layer can be confusing for newbies.The solution should use off-the-shelf when possible. This means existing software, existing APIs, code that already works.
I've already suggested that OAM might be a suitable starting point for a DB based index, I however don't think that this will work without additional work. The other issue is that OAM is likely in its stasis between rewrites to justify obtaining new funding for it, it is not quite clear to me how we could move OAM out of this loop so that we could have a multi-year (lets say around 10) stable base to work from and improve on.
The solution should let the clients query about any kind of local features, whether they're imagery, communities, or anything locally relevant we can think of (tagging presets? Validation rules?).
There have been a few similar solutions or attempts: the osm Imagery Offset Database, osmlab/osm-community-index#80, maybe the JOSM chat plugin, geocoders if you really stretch the definition.
WFS is possible, but is slow when not backed by elasticsearch and antiquated always. Parsing XML is a pain. Something like python FeatureServer (which seems dead) or JavaScript FeatureServer (which seems immature) would maybe work. Maybe elasticsearch's native geospatial support can do the trick. I really haven't played with any of these yet.
The data could still be integrated from ELI at first, but ideally I'd like something a bit more newbie-friendly to be made available, with a form you can fill out.
What do you think?
I think we should avoid feature creep :-)
grischard
imagico
Marc-marc-marc
don-vip
iandees
andrewharvey
bhousel
bryceco
stoecker
systemed
Klumbumbus
tordans
I've been thinking about where to take this project next for a while. The current index, which was a perfect solution when we had a dozen layers, is really showing its age.
The solution should use off-the-shelf when possible. This means existing software, existing APIs, code that already works.
The solution should let the clients query about any kind of local features, whether they're imagery, communities, or anything locally relevant we can think of (tagging presets? Validation rules?).
There have been a few similar solutions or attempts: the osm Imagery Offset Database, https://github.com/osmlab/osm-community-index/issues/80, maybe the JOSM chat plugin, geocoders if you really stretch the definition.
WFS is possible, but is slow when not backed by elasticsearch and antiquated always. Parsing XML is a pain. Something like python FeatureServer (which seems dead) or JavaScript FeatureServer (which seems immature) would maybe work. Maybe elasticsearch's native geospatial support can do the trick. I really haven't played with any of these yet.
The data could still be integrated from ELI at first, but ideally I'd like something a bit more newbie-friendly to be made available, with a form you can fill out.
What do you think?