On Sep 7, 2011, at 12:34 PM, Phil! Gold wrote:
> * Michal Migurski <m...@stamen.com> [2011-09-07 09:13 -0700]:
>> This kind of thing [joining roads with similar names] really needs to be
>> applied all-at-once to a large dataset, because it can really mess with
>> tile boundaries when done at render-time.
>
> I'd be interested in any view-based solutions people have come up for
> merging road names. I've tried three different approaches that all fall
> short one way or another. I can generate an auxilary table with the
> merged geometries, but that won't be updated by the minutely updates.
> I've tried setting up recursive queries to spider their way along the
> extents of connected identically-named roads, but that gets really slow
> and I never got it working quite right. What I've settled on is running
> an ST_Collect() across all the ways in the current metatile's bbox, but
> that, as you note, makes for a lot of artifacts at tile boundaries.
It also has another nasty side-effect, which is that you end up needing to put
the whole query into your stylesheet with a "!bbox!" placeholder so that mapnik
can replace it with the render bounds. Otherwise, PostGIS does its level best
to collect geometries from the *entire* database. This is an annoying pain with
Mapnik or Cascadenik-based layers files, but it's even more annoying in Carto
where the JSON syntax precludes use of newlines in large, complex queries.
Here's a sample query showing what I mean:
http://code.google.com/p/mapnik-utils/source/browse/sandbox/cascadenik/hike_n_bike/style.mml?spec=svn891&r=880#762
High Road sticks to things that can be done solely with views, mostly to make
like easier for Carto + Tilemill users.
-mike.
----------------------------------------------------------------
michal migurski- m...@stamen.com
415.558.1610
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
