petern
|
9 years ago
|
on: Mapillary Now Able to Recognize and Label Objects in the Wild
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)
petern
|
9 years ago
|
on: Introducing OpenStreetView
You can get that metadata through the APIs.
petern
|
9 years ago
|
on: A Street Map of New York City in the 1800s
petern
|
9 years ago
|
on: A Street Map of New York City in the 1800s
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.
petern
|
11 years ago
|
on: Mapillary transforms crowd sourced streetview into interactive 3D
Yes, and this is just the beginning. There is much more potential.
petern
|
11 years ago
|
on: Mapillary in the OpenStreetMap iD Editor
Sorry, that is totally right. It's about the iD editor, nothing else.
petern
|
11 years ago
|
on: Mapillary in the OpenStreetMap iD Editor
petern
|
12 years ago
|
on: Show HN: Random Street View
petern
|
12 years ago
|
on: Show HN: Random Street View
petern
|
12 years ago
|
on: Neo4j 2.0 GA - Graphs for Everyone
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..
petern
|
12 years ago
|
on: Why You Should Never Use MongoDB
petern
|
13 years ago
|
on: How to bootstrap in The Valley/San Francisco for 3 months
petern
|
13 years ago
|
on: Titan: A Highly Scalable, Distributed Graph Database
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
petern
|
14 years ago
|
on: Neo4django 0.1.5 release
yeah, all review and contribution is very welcome!
petern
|
16 years ago
|
on: Cool spatial algos with Neo4j: Part 1 - Routing with A* in Ruby
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 :)
petern
|
16 years ago
|
on: Why learn Graph Theory? Here are some reasons ...
petern
|
16 years ago
|
on: Gremlin: A Graph-Based Programming Language
petern
|
16 years ago
|
on: No to SQL? Anti-database movement gains steam
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.
(I'm part of the Mapillary team)