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 <cr...@amanzi.com> 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. < > klaassen.christ...@googlemail.com> 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 > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
