Hi Axel,
> Adding neo4j spatial to the picture should enable the CMS handling geo > data objects without adding to much complexity (I hope). > OK. I think I'm beginning to get an idea of what you want. You have a CMS, and some of the data is geolocated, in the sense that you know what countries it is associated with, and perhaps you even have relationships to 'country' nodes (or other nodes) representing locations. Now you want to use Neo4j Spatial to perform simple spatial queries on this. I could imagine something like: 'give me all countries in the specified region (bounding box) and include the number of pages as an attribute of the result set' so you can display a map of countries, with perhaps each country color coded with the number of pages, or hits, or some other attribute? I think I nice approach would be to create a GeometryEncoder that reported, via a SpatialDatabaseRecord, each country with a number of attributes attached (the page count, for example, would be converted from a count of incoming COUNTRY relations to an integer attribute of the record). Then using the GeoTools extensions you would be able to publish this as a layer to GeoServer or uDig, and use the GIS to color code the Geometries. Alternatively, write a PNG exporter to write the layer to an image directly? For the generic importer I'm not sure that my GIS knowledge is > sufficient, so probably I'll start with the multi-polygon. > If it were me, I would probably start with the approach that was easiest based on what I could find for libraries. If the suggested GeoJSON importer in GeoTools is easy to use, it might be easier to start with that code. I have not tried that one myself, so cannot comment further. If you do it yourself, use a basic JSON library like the one included in Neo4j and Neo4j Spatial (twice it seems), and from that generate an object model from the JSON document (one liner), and then pass the contents to an appropriate GeometryFactory to generate the multi-polygons. In theory this should only be a few lines of code. The polygons get pushed into Neo4j Spatial using your geometry encoder (or possibly using the default one if you want to handle the connection to your CMS in some other way). One trick you could use for your own GeometryEncoder would be to extend the default one, which means you get most capabilities for free, but make a change to handle the connections between the geometry nodes and the CMS graph for finding and publishing attributes (eg. number of incoming relations, etc.). The default GeometryEncoder expects attributes to be stored as properties on the node itself, but in your case you would resolve them, or some of them, in different ways. You would only need to override methods hasAttribute and getAttribute for this. Yes, I prefer a connected graph, too. So something like > country1.isNeighboursOf(country2) or getNeighbours(country) would be easy. > Then OSM is indeed a good data-source to consider. Unfortunately the current importer imports always the entire OSM model, which includes much more information than you need (and therefor runs too long and takes up too much database space). You would need a simple filter on the importer to import only the countries borders as a connected graph. Should be a small change, but unfortunately the OSMImporter code is relatively convoluted, so I'd need to investigate a little before recommending this change. The GeoJSON files are generated with the OGR Layer Converter, and the > original data is a shapefile from > http://thematicmapping.org/downloads/world_borders.php > (TM_WORLD_BORDERS-0.3.zip > <http://thematicmapping.org/downloads/TM_WORLD_BORDERS-0.3.zip>). Does > this file contain topologically connected structures? > I seem unable to connect to that site right now. I will try again later. Generally shapefiles contain separate shapes, so there is no topological connectedness. However, if you are working with shapefiles, Neo4j Spatial already has a shapefile importer, which means you do not need to write the GeoJSON importer at all. The final data structure in the database will be the same (especially if you base your GeoJSON importer on the ShapefileImporter code), so going SHP->GeoJSON->WKB is a longer route than going SHP->WKB directly. These all are good suggestions that I will consider. Maybe it's another > option to use the original shapefile for import and just build a GeoJSON > exporter. I hope I'll figure it out this week .. > Definitely. I think you should either use the original shapefiles and the existing ShapefileImporter or move to OSM data models for connected topologies. A GeoJSON importer is a nice idea, but not worth the effort if you already have shapefiles. Regards, Craig _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
