[openstreetmap-website] OWL Activity Tab (#876)

PaweĊ‚ Paprota notifications at github.com
Wed Mar 2 20:13:59 UTC 2016

The "tag-focused (history) viewer" in my view would be just one possible use case of OWL - at least OWL as it was planned/partly implemented by me. It was meant to be a pretty generic service providing couple of APIs - of course main focus was on finding "changes" but there was also geometry available for every change so that would not be too far from vector tiling.

The main difference to other services (at least at the time I worked on OWL - maybe something changed since then) is that OWL would let you query data at any point in time while most services either don't deal or are not scalable to full history.

Perhaps that's actually the wrong approach to the problem because such a service would require HUGE infrastructure (meaning - lots of disk space and preferably lots of processing power), by now I think the number of changesets has basically doubled and of course continues to grow.

So the target architecture would probably be something that combines couple of larger services like Overpass (e.g. augmented diffs) AND maintains a tailored full history database itself. That would reduce the complexity and make it more maintainable/deployable and less prone to grow out of control in terms of size. Of course the trade off would be that you have a string of services that depend on each other but that's maybe easier to swallow than a monolithic monster that I implemented :-)

> IMO tracking of geometry-topology of country/Europe-scale relations is up to specialized validators

Yeah but from my point of view that does not provide too much value to the regular/casual/non-technical user. Of course experts use it a lot but my idea for OWL was to really make something that would be a basis for a lot of "cool" functionalities like "social" activity stream with meaningful items in it and of course scalable to full history and including the whole world.

> Avoid special cases with relations

That would definitely simplify the problem A LOT. I had my mind set on handling everything or at least preparing the database design and the code to add relations later. That resulted in a lot of complexity and unanswered questions and headaches (nested relations anyone?). So I would not recommend this approach in the future.

Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20160302/6fa13689/attachment.html>

More information about the rails-dev mailing list