So far the only docs for the JSON syntax are in the code. But you are welcome to read the JSON parsing code itself. It is very short, albeit cryptic.
I'm sure I support 'not null', but I am also sure I do not support OR. I need to think a bit harder about how to support OR, since the current compact code was designed around supporting AND. It should be possible. But it is 1am now, and I definitely will not figure that out tonight ;-) On Fri, Oct 8, 2010 at 1:18 AM, David Winslow <cdwins...@gmail.com> wrote: > You may also find the styling section in the GeoServer manual useful while > getting up to speed on SLD: > http://docs.geoserver.org/stable/en/user/styling/index.html > > wrt filtering out "small" features, I think that is generally done in the > stylesheet (GeoTools combines the filters of all the style rules together > and sends them to the database so that GeoTools fetches only what will > actually be rendered from the database.) This avoids having a hard-coded > decision about the size of the "important" features in the rendering code, > which as you note does not work very well for point data. > > Is there documentation about the JSON query language beyond what is > available in the JavaDoc for DynamicLayer? In the short term, I am mainly > curious about (not) NULL tests, OR, and testing for specific values of > properties since these are the most used predicates in the MapQuest styles; > for example: > > CREATE TABLE landmark AS > > SELECT way, aeroway, amenity, landuse, leisure, > > man_made, military, "natural", power, shop, tourism, name, > > religion > > FROM planet_osm_polygon > > WHERE landuse is not null or leisure is not null > > or shop is not null > > or aeroway in ('apron', 'aerodrome', 'taxiway', 'runway') > > or amenity in ('parking', 'university', 'college', 'school', > > 'hospital', > > 'kindergarten', 'grave_yard') > > or military in ('barracks', 'danger_area') > > or "natural" in ('field', 'beach', 'heath', 'mud', 'wood') > > or power in ('station', 'sub_station') > > or tourism in ('attraction', 'camp_site', 'caravan_site', > > 'picnic_site', ' > > ORDER BY z_order, way_area DESC; > > > -- > David Winslow > > On Thu, Oct 7, 2010 at 3:52 PM, Craig Taverner <cr...@amanzi.com> wrote: > > > 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 > > http://geoserver.org/display/GEOSDOC/SLD+Intro+Tutorial > > > > Cheers, Craig > > > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
