Hi Chris, I'm glad my comments were of help. I think you are exactly right in starting simple and enhancing as you need. This is certainly one of the points of a 'schema-less database' after all :-)
Neo4j can handle very large amounts of data, and every car on the planet would fit, but perhaps not every car logging GPS points every few seconds for a long time! You can deal with the performance issues as they arise (although it helps to keep performance in mind as you go, of course). If you are curious about a related system I was involved in, take a look at the videos on my vimeo account at http://vimeo.com/craigtaverner. They show an android application being driven around (in cars), uploading GPS and other data to a central database (using neo4j), then being downloaded by a desktop application containing another neo4j database which duplicates a small subset of the data, and performs statistical analysis of the results and displaying on a map. Not the same use case as yours, but certainly related. Regards, Craig On Fri, Mar 18, 2011 at 1:11 PM, Christoph K. < [email protected]> wrote: > Hi Craig, > > wow, this is a great reply :) Thank you very much for your advices. > > To be a bit more precise about the project: it's a mix of both of your > options. > Option 2 is a great start from which i could go on and test, how neo4j > behaves in my special case. I get the data from the car itself (via umts or > sth like that) and want to provide some environment informations back to > the > car. But it is intended that i have to deal with a huge amount of cars... > thousands up to... yeah maybe all cars on this planet ;-) (think big). > Option 1 with the possibility to inspect historical data would be > interesting, but i'm not sure, if neo4j is powerful enough to store that > amount of data, which is intended to be collected. So this would not be a > feature at this time but interesting for later enhancements. > > I think i will try a simple encoder implementation to do a hybrid of your > options :) this leaves the option to extend the model more easily if it's > desired. > > greetz > Chris > > On Fri, Mar 18, 2011 at 12:47 PM, Craig Taverner <[email protected]> wrote: > > > Hi Chris, > > > > A lot depends on your final intentions of how to use the model. There are > > many, many ways to model this, and each has its pros and cons. Let me try > > briefly describe two options I can think of that are related to the two > > factors you suggest below. > > > > *Option one - model time in the graph* > > > > In this case I'm assuming you want to store information about car > > movements. > > For example, you are a logistics company tracking your fleet, and each > > car/truck has a GPS and uploads data continuously. This data would be > > stored > > as an event stream in the database, indexed spatially in the RTree, and > > indexed with other indexes too (time of event (timeline index), which car > > (category index), which driver (category index), other properties of > > interest (lucene), etc.). You can relate the car to the OSM model through > > routing information (eg. the car is following a planned route on the OSM > > graph). Perhaps you model the route as a chain of nodes also, resulting > in > > a > > three layer graph, the static OSM, the planned route and the actual route > > coming in live. This approach results in a very complete data model can > can > > be historically mined for statistics and behaviours (eg. which cars match > > planned routes best, general speed patterns, driving behaviours, etc.) > > > > For this model there is value in adding your own geometry encoder if you > > wish to expose your own data (routes, and car traces) to a map or GIS. > > Since > > it is all point data, you could just use the SimplePointEncoder, but then > > you would not see lines, only points. If you want lines, rather make your > > own geometry encoder that understands how the nodes are connected in > > chains. > > Review the code of the sample encoders, it is not complex. > > > > *Option two - model time in analysis* > > > > Assuming the previous case is overkill, and you have no interest in fleet > > tracking and historical modeling, and all you want is a map that shows a > > single point for a car as it moves, it might be possible to not include > the > > car in the database at all. Where do you get the car data from? If it is > a > > stream of information from some data source, that stream could be > consumed > > by the map view itself, just updating the points on the map. If you wish > > the > > map to not have to know about your own stream, then you can use the > > database. Perhaps you do something very simple, just store each car > > location > > in a SimplePointLayer (like the blog), and whenever a car change event > > arrives (from your source of car data, whatever that is), you could > remove > > the car node from the RTree index and re-add it (basically re-index the > > point at a new location). The map needs to redraw that layer too, so you > > need to trigger that. If there are lots of cars moving all the time, > rather > > just redraw the map layer on a timer. > > > > The reason I called this 'model time in analysis' is that since there is > no > > time component in the graph, each car has only one current position, any > > analysis of car behaviour would have to be done external to the graph, > > perhaps on the incoming gps stream. So this is much more limited in > > possibility than the previous case. > > > > As you can see I had to make a ton of assumptions about your data and > your > > intentions to describe the above models. I assume the odds are low that I > > matched your exact case very well, but hopefully I gave you some ideas to > > think about. > > > > Regards, Craig > > > > On Fri, Mar 18, 2011 at 11:57 AM, Christoph K. < > > [email protected]> wrote: > > > > > Hi peole, > > > > > > i'm working on a project, where i want to map live data of cars on > > streets. > > > I take my map data from OSM-maps for test purposes - so there's no > > problem > > > at all. > > > But i have no idea on how to integrate my car data. Should i implement > my > > > own geometryencoder, so that my car nodes can contain a position > > property. > > > Or does it make sense to relate my car nodes to point nodes, which are > > > representing the current position of my car? Some advice would be > great! > > > > > > greetings from bavaria > > > Christoph > > > _______________________________________________ > > > Neo4j mailing list > > > [email protected] > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
