Neo4j Wiki から
The Neo4j database core has no built in support for spatial data. However, it is in principle not difficult to model spatial data in a graph database. Several users of Neo4j have already done so in various domain specific ways. This project provides the tools and utilities to make it much easier for developers to spatially enable their graph models. If you have data with locations or spatial features, you should be able to use these libraries to considerably enhance the usability of your data in GIS environments. This includes support for spatial indexes, import and export from common spatial formats, publishing of the data to well know GIS systems like GeoTools, GeoServer and uDig, and advanced spatial queries based on bounding boxes, distance, topology, spatial analysis and graph matching.
 First Release in September 2010
The first announced release of Neo4j Spatial was made at the FOSS4G Conference in Barcelona in early September 2010. This version was capable of importing a number of different data formats, including Shapefile and Open Streetmap OSM files. It also included the API's for users to spatially enable any existing data model, without having to remodel the data. See the announcement: Neo Technology announces Neo4j Spatial.
The rest of this page still contains the old wiki discussions on the initial planning for the project. We will soon update these to reflect the current status of the project. In the meantime we have a few new pages to help you get started using what is already there:
Also take a look directly at the source code at:
 Original Planning Discussions
In this project we will discuss the various elements of spatial support, the types of solutions and approaches that have been discussed, and the proposed schedule of activities to achieve such a goal. We are also open to Collaboration on Spatial Projects, and are offering to mentor Google Summer of Code for Neo4j Spatial projects.
 Elements of a spatial database
The most basic requirements of a spatial database would be:
|Storage||Provide the ability to store spatial objects in a way that facilitates the other spatial requirements|
|検索||Facilitate indexing of spatial data for optimal search performance (both time and memory) as well as performance of spatial operations|
|Operations||Provide a set of common spatial operations in the Neo4j API to aid application developers in making use of Neo4j as a spatial database|
|I/O||Provide support for importing and exporting spatial data using a number of popular spatial standards|
We will start simple, taking inspiration from some specific use cases, and elements of the published standards, like OpenGIS, as well as other open source GIS projects, like those tracked by OSGeo. Since Neo4j is a Java library, the GeoTools project is of high relevance. As is the open source spatial database PostGIS.
 Suggested approaches
There are many things to consider here, but one of the most critical would be the question of how to store the spatial objects. There are two main groups of data:
For the early work in this project we will focus on feature data, primarily because the perceived benefits of using a graph database for such data are a little more apparent.
The current suggestions for storing feature data are:
- Storing all data associated with a single feature object within a single node. This can be done even within a single property, using either or both of the well known text and well known binary formats (WKT/WKB), or as a set of properties describing the various elements of the geometry.
- The Oracle and PostGIS spatial databases use approaches like this, because this works as well in tabular databases. There is a lot of public information available about both of these solutions and in PostGIS case, a lot of open source code is available for review.
- The indexing and spatial operations that are performed on this might are less transparent to the application developers and users, which has pros and cons.
- Storing the features as a sub-graph with a structure that matches the feature data structure itself.
- This approach makes much better use of the graph database itself, makes the feature storage transparent to the developers and users, and leads to 'graph-based' solutions to the spatial operations. It would also facilitate application developers extending the spatial support themselves.
- The storage and complexity of the database is much higher than in the other approach (many more primitives are involved in this approach), probably affecting scalability and performance.
The difference between the two approaches are likely to lead to very different performance characteristics of the database, and so it is suggested that both be prototyped and benchmarked in various scenarios. It might turn out that both have their place, and if possible both might be supported in the final solution, possibly behind a unified API. It is possible that the Neo4j community will come up with ways of working with spatial data that go well beyond the common scenarios from relational databases, and beyond the expectations of the original developers of the spatial support. We would not like to take decisions that might impede that kind of innovation.
 Proposed schedule
At the highest level, the project will take three phases:
- Setup - Planning, discussions with the community, discussions with identified early adopters and potential customers.
- Prototype - Develop and benchmark a decent minimal viable subset of the required features, sufficient to be released to the community, be of use to many, and enable feedback on the approaches taken.
- Release - Based on the response to the first public release, the minimum viable product, plan, develop and release a more complete system, covering all the most requested features. Ideally this might conform to published standards like OpenGIS, but possibly it might require a new standard focusing on graph databases.
Further details are available on the Neo4j Spatial Project Plan.
Some ideas for possible blogs on how to use Neo4j Spatial are being discussed on the page Neo4j Spatial Blog Ideas.