petern

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)

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..

See http://blog.neo4j.org/2013/11/why-graph-databases-are-best-t... on how to use Neo4j for the mentioned Diaspora cases (Neo4j was actually proposed back in 2010 to the team). Comments are very welcome.

you might wanna link up with other startuppers at http://www.hackersandfounders.com/

Yes, all information models are basically isomorphic. However, Neo4j for instance maintains referential integrity along the relationships, making sure there will never be a relationships without start- or endnode. In a K/V store or document store, there are no guarantees that your IDs pointing to other objects are updated as you change, delete or move the target data. Also, the graph structure is maintained on dics, meaning you can direct pointers on the storage level even in non-cached scenarios, while in a K/V or Document store you need to recreate the graph in memory before being able to do anything with it.

As for special indexes and queries, look at things like http://docs.neo4j.org/chunked/snapshot/cypher-query-lang.htm... expressing patterns and walks in graphs.

You can combine index lookups in e.g. Redis, MongoDB or Lucene with the core graph engine.

See http://docs.neo4j.org/chunked/snapshot/index.html for docs.

/peter