-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/18/2011 06:00 PM, Craig Taverner wrote:
>
> Internally Neo4j Spatial is working with bounding boxes too. I have to
> assume MongoDb does also. Our RTree index is optimized for general spatial
> objects, and while it can do distance queries, I think there are better
> ways. I'm thinking that a fixed size grid b-tree like index, similar to my
> own 'amanzi-index' would work very well for distance searches, because
> instead of traversing from the top of the tree, you would traverse from the
> central point outwards radially. This would be one way to have the graph
> really benefit the distance search. We have considered plugging in other
> indices into Neo4j Spatial, but have not actually done it (yet).
>
Actually, MongoDB is just geohashes AFAIK. So it works great for use
cases like Foursquare, but only partially well for me, where I want to
know things like the closest way to x latitude and y longitude. So
perhaps I'm comparing apples and orangutans when comparing MongoDB to Neo4J.
> It is still worth trying out the current index, it might be fast enough, not
> for infinite scrolling lists, but at least for the first many pages (so
> effectively infinite from the users point of view).
>
OK, but can you tell me how to translate that into code? In looking
through the source, I see there's a query for points within a specific
bounding box, but how would I make that appear infinite? Do I use a
sufficiently large bounding box such that the user will only reach the
end after 100 pages or so, or is there another way? I wouldn't mind that
as much, then requiring the user to hit the normal search API for
anything beyond such a large radius.
>
> Why can you not see them? Site blocked? Shall I email you the original
> presentation?
>
My product is a navigation platform for people who are blind or visually
impaired. I'm translating OSM data into natural language such that, for
instance, a node that happens to be an intersection of several ways is
described in natural language relevant to both the node's content and to
the user's current direction of travel. And, to borrow a tired
colloquialism, I'm not only the president, but also a client. :) So I
literally can't see your slides.
>
> The directory containing that test class contains many others, and all of
> them are run every night, so they should all work. Neo4j Spatial is sadly
> lacking in good documentation, so these test classes are the best place to
> investigate how to use it.
>
OK, good to know that all of the tests pass.
>
> The graph created has a tree structure rooted at the database root node. You
> can traverse down to a collection of nodes and a collection of ways. The
> Ruby wrapper actually exposes node and way counts through this, so you could
> look at that code to see how it is done.
>
OK, so perhaps I'm confused about something. Here's a shell transcript:
Welcome to the Neo4j Shell! Enter 'help' for a list of commands
neo4j-sh (0)$ cd 1
neo4j-sh (osm_root,1)$ ls
*name =[osm_root]
*type =[osm]
(me) --[OSM]-> (map,2)
(me) <-[OSM]-- (0)
neo4j-sh (osm_root,1)$ cd 2
neo4j-sh (map,2)$ ls
*generator =[Osmosis 0.36]
*name =[map]
*type =[osm]
*version =[0.6]
(me) <-[OSM]-- (osm_root,1)
(me) --[RELATIONS]-> (Walden of Westchase,50976192)
(me) --[WAYS]-> (Sam Rayburn Tollway,21973837)
neo4j-sh (map,2)$ quit
I'm still familiarizing myself with how the shell displays things, but
according to that last ls, it would appear that there is a map node
under osm_root ("map" was my layer name) with relations called
"relations" and "ways". Would I be wrong in my expectation to find a
"nodes" relation there as well?
>
> As discussed above, we use a lucene index to track the OSM node ids (I
> usually referred to them as the osm-id above). Obviously the neo4j id is not
> the same number, as you suspected, so we needed this index. This is also the
> bottleneck for loading large OSM files.
>
I haven't looked at the code yet, but instead have been familiarizing
myself with more Neo4J concepts, as well as the shell.
Via "index --indexes", I see that there is a "nodes" index. Actually,
given that I haven't seen "ways" or "relations" indexes but have seen
relations rooted off of "map", I now wonder if the lack of
ways/relations indexes and the lack of a nodes relationship are related?
In any case, is it possible to list the keywords associated with a given
index from the shell? Based on my reading of the wiki, I assume that I'd
query the nodes index by a keyword-value pair with the node ID as the
value. I'll be looking at that code later today, now that I'm grounded
in more of the concepts, but I wanted to understand those first before
reading code. Is the keyword I'd check "osm-id"? I'd like to learn how
to discover indexes from the shell for future reference, if indeed that
is possible.
Also, one more semi-related question. How do layers work in queries? My
app stores user POIs and, hopefully, user ways as well. I'd like to
return those right alongside other search results for nearby features,
but still wish to keep the storage separate as to indicate what data is
from OSM and what is user-contributed. Can layers do this, or do they
separate query results as well (I.e. such that user features on a "user"
layer would need to be queried separately?)
Thanks for all of these detailed answers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1iiJ8ACgkQIaMjFWMehWKvXACfeo+pZOZHaBa3GgXfw6fXrqfg
iTwAn0Vt1q7up5zdtaMlt+Ed85OuG52c
=YqdU
-----END PGP SIGNATURE-----
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
