[OSM-talk] Mapnik boundaries
Ben Laenen
benlaenen at gmail.com
Fri Feb 20 13:09:20 GMT 2009
Since no-one seems to bother, it's likely these lines in osm2pgsql that
are causing a problem here:
else if( strcmp( type, "boundary" ) == 0 )
{
make_polygon = 1;
}
(in
http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/output-pgsql.c)
Obviously the completely wrong way of handling this, as it completely
disregards the fact that this will overlay the same border with
multiple boundary ways.
It also has the side-effect that it renders the name of the boundary
relation as if it were a polygon. That may be something nice to have in
the end, but it currently clashes with the place node which has to be
solved first, and it needs some better font style as well. E.g. here
http://www.openstreetmap.org/?lat=51.07966&lon=4.39979&zoom=16&layers=B000FTF
where you can see "Terhagen" twice: the place node below, the boundary
relation polygon name above.
Ben
On Wednesday 18 February 2009, Ben Laenen wrote:
> Did someone break the boundary rendering on the Mapnik layers?
>
> It looks like all boundary relations on a given way are now
> rendering, and that means that if two or more relations for different
> admin_levels are on one way, different kinds of borders are rendered
> on top of each other.
>
> I guess this may have to do with someone thinking a relation with
> type=boundary should be treated the same as type=multipolygon
> (there's a proposal for that hanging around somewhere to tag
> boundaries with multipolygon relations, not a good idea IMHO, just
> because of this bad kind of rendering), but that's only guessing
> since I didn't look at the code, I just see the same wrong kind of
> rendering happening now to boundaries tagged with a boundary relation
> as those tagged with a "boundary multipolygon" relation.
>
> So, please fix this as current boundaries look pretty bad now. Given
> the current maritime boundaries getting voted on it's a good time to
> make a *proper* handler for boundary relations.
>
> Greetings
> Ben
More information about the talk
mailing list