[Neo4j] neo4j spatial - dynamic styling

Craig Taverner craig at amanzi.com
Thu Oct 7 21:52:18 CEST 2010

Hi David,

The most important thing you can do to improve performance is to ensure that
> your style renders an "appropriate" number of features (if you want render
> every driveway at state level it will take a while) and that your datastore
> can provide fast access to those features (ie, well-indexed).  Beyond that,
> most styling options have negligible impact on rendering speed. (However,
> with as many different style rules as you have with OSM data things will
> start to add up.)

Seems like a useful option is for the DataStore to only return geometries
that are 'big enough' to matter at the resolution in question. This could be
a clever modification to the spatial index itself, so that it is passed a
resolution hint during query time and simply ignores data that is 'too
small'. The concept of 'too small' is the tricky part, because it is not a
purely spatial concept. Some points are too small, while others are not,
depending on the tags. Points representing the location of cities are not
too small, while points representing the location of trees certainly. Of
course this can also be solved client side by putting such different objects
in different layers and setting zoom level filters on the entire layer.

wrt to mapnik2geotools - Mapnik allows styles to specify a postgres *
> subquery* in the table name field (so generated requests come out like
> "select
> foo from (select foo, bar, baz from quux as roads)" which is totally
> valid).
>  GeoTools doesn't support this option, so my approach so far has been to
> inspect the datastore parameters and for every table that looks like a
> subquery, I generate an actual table - "create table roads as (select foo,
> bar, baz from quux)".  While expedient, this approach doesn't translate
> well
> to other datastores.
> So, I think the first barrier to using mapnik2geotools with neo4j-spatial
> will be coming up with a solution to this problem that works with neo4j as
> the database.

My plan is for the DynamicLayers to support this kind of thing. You could
view these as database views, which is similar to your idea of generating an
actual table, minus the data duplication, of course. Right now my dynamic
layers only filter on combinations of OSM tags, but there is not reason why
not to filter on much more complex things. Today the filter is, in fact, a
graph matching algorithms, specified in JSON. The JSON document describes
how to traverse the graph checking for attributes on various nodes. The
original reason for such a complex solution was because the OSM tags node is
two steps away from the geometry node. However, now that it exists I can
hopefully use it for much more powerful queries of sub-graphs.

By the way, I added a modified version of your code to a unit test in
neo4j-spatial (not yet commited, but soon), and also played around with the
SLD to see if I could get some more interesting effects. I manage to
generate the attached image, which has three levels of road rendered with
different colors, all with dark borders. The bridges are highlighted, as you
had, but now also with glowing red labels. I got the labeling from the SLD
tutorial on the geoserver wiki at

Cheers, Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: highway.png
Type: image/png
Size: 495552 bytes
Desc: not available
Url : http://lists.neo4j.org/pipermail/user/attachments/20101007/0c75b806/attachment-0001.png 

More information about the User mailing list