It's because we need to upgrade and optimize some of the backend storage layout in order to cope with the data produced.

(I'm part of the Mapillary team)

Thanks for elucidating - makes sense.

You can get that metadata through the APIs.

I can be, since the time perspective is maintained and can be filtered out, see http://blog.mapillary.com/update/2016/03/21/mapillary-js-sli...

We are open sourcing anything that makes sense to do and can be reused by others, like https://github.com/mapillary/OpenSfM, traffico.io/examples.html and are working on open sourcing the apps too. However, putting out the docker setup of the backend is more hassle than use to anyone.

disclaimer: I am part of the Mapillary team.

Yes, and this is just the beginning. There is much more potential.

Sorry, that is totally right. It's about the iD editor, nothing else.

The WM app is contributed by Tommy Ovesen one of the Norway Mapillary members, see http://blog.mapillary.com/update/2014/05/15/windows-phone-re...

Sounds like something you could build with Mapillary, they have an API to get the images, the web view is all HTML5, key nav would be easy. See http://www.mapillary.com/map/im/WNYdrxB1Q8tiICsCFTra0A for an example

If you want a true long tail street picture app, there is a new one - Mapillary - with only phones and HTML5 no cars etc involved, e.g. http://www.mapillary.com/map/im/jvEX_s9fM7SwTDoMdeYDOw - works everywhere where you can have a smartphone and GPS fix.

They are used to attache indexes and constraints on them in order to speed up traversals. They themselves have very little logic right now, more will follow in terms of query optimisation etc..