[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