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
