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)
HN user
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
yeah, all review and contribution is very welcome!
Cool you like it! Next up (when I get time) is a full OpenStreetMap importer writeup, so you can run deep algos on a real dataset. Have tested routes with depths around 1000 in under 1s :)
Awesome post, love the pragmatic and no-bullshit approach! There are some more real world graphy projects on the Neo4j wiki, http://wiki.neo4j.org/content/Neo4j_In_The_Wild
Gremlin is not that old, and still in 0.1 ALPHA. Hope you enjoy it, feel free to join the users list at http://groups.google.com/group/gremlin-users . Would love to get feedback on it!
Fully agree. look at graph databases like Neo4j, which has ACID semantics but no SQL interface. Then, IMHO SQL is not only geared towards a special RDBMS type of underlying database but even against a special problem domain that is not always applicable, leading to query languages like SparQL.