Customize spatial relationship types and spatial node property names

[versae]

This is more of a feature request that I guess it is not that complicated, but I am not a Java guy and I feel a bit lost when trying to do the proper changes.

I just need to change the existing relationships types managed by the spatial plugin. Something basic like adding a prefix should suffice, but complete customization would be even better.

[craigtaverner]

You mean the relationship types used in the RTree? Like those found here: https://github.com/neo4j-contrib/spatial/blob/master/src/main/java/org/neo4j/gis/spatial/rtree/RTreeRelationshipTypes.java#L30

If this because you want to reuse these names in your domain model? They all start with the prefix 'RTREE_'. Do you want to build another RTree? That would be cool, and interesting. The workaround for you would be, of course, to add prefixes to your own relationships types. Changing the ones in the library is possible, but does have some upgrade compatibility issues, needing to re-import all data when using a new config. There are probably a few places that depend on these names.

[versae]

I don't need to create my own RTree, at least not yet. As you say, it's more a matter of name clash. So yes, the RTREE_* ones as well as the ones in OSMRelation.java. I was thinking about having a small config file with all those options and even the chance to change the bbox and gtype properties that are added to spatially indexed nodes.

[craigtaverner]

I believe configurable bbox is already supported, something I added for a customer that wanted the same node to support multiple geometries. See the createSimplePointLayer method. But I see your point, more configurability would be nice.

The OSM importing code is to some extent a very domain specific solution. There are probably an endless number of improvements and increased configurability we could consider. Hard to know where to draw the line. Improved import performance is, however, the highest priority, although far from trivial to achieve.

[versae]

That is also part of my use case, where a node can have multiple spatial properties. I just realized how useful configurable bbox and gtype would be for each of those spatial properties in a single node. Is that exposed to the API or Cypher? We don't know in advance the geometry, so for now we only use WKT.

[craigtaverner]

It is only really exposed in the embedded API for point layers. However it should be pretty trivial to support this in WKT layers, and through the REST and Index (cypher) API. Perhaps you could write a failing test case highlighting your use case and I could fill in the gaps? On Nov 22, 2015 12:06 AM, "Javier de la Rosa" [email protected] wrote:

That is also part of my use case, where a node can have multiple spatial properties. I just realized how useful configurable bbox and gtype would be for each of those spatial properties in a single node. Is that exposed to the API or Cypher? We don't know in advance the geometry, so for now we only use WKT.

— Reply to this email directly or view it on GitHub https://github.com/neo4j-contrib/spatial/issues/209#issuecomment-158689497 .

[versae]

I wish I could! I am a Python developer, so all I use is REST API and Cypher transactional endpoint through my neo4jrestclient. When I have more time I will try to write to setup a Java environment and write a couple of tests.

Very basically would be something like:

1. Create node with properties bbox, gtype and wkt
2. Create geometry WKT index on wkt property with custom bbox and gtype
3. Index the node and through legacy indices and the API method addNodeToLayer
4. Check that the value of the node property bbox has not changed

I will try to give it some time during the next month. Thanks for the interest and the responses, btw.

[ehx-v1]

By the way, i'd suppose he wants to be able of changing RTREE_* into TEST_RTREE_*. It would be easier to simply make a test_layer though.

[craigtaverner]

I should mention that the newer releases for Neo4j 3.0 now include Cypher procedures for spatial. These are much closer to the metal, and easier to expose the older Java API to Cypher than before. In the latest version, for example, the property names for the bbox can be set in both the spatial.addPointLayerWithConfig(name,encoderConfig) and spatial.addLayerWithEncoder(name,encoder,encoderConfig) can take the bbox property name as the last element of the ':' separated encoderConfig string. It would be great to get feedback on these procedures and suggestions for how to expose more configurability without cluttering the procedure signatures.