Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange placement of names on complex buildings #349

Closed
tomchance opened this issue Feb 21, 2014 · 5 comments
Closed

Strange placement of names on complex buildings #349

tomchance opened this issue Feb 21, 2014 · 5 comments

Comments

@tomchance
Copy link

I've noticed names being placed in weird places recently, for example on these two ways:

http://www.openstreetmap.org/way/227767264

http://www.openstreetmap.org/way/262420024

It may be that the shapes of these buildings are a bit complex, but the placement is very odd and makes it seem as though only part of the building has that name.

@matthijsmelissen
Copy link
Collaborator

Thank you for the report.

I agree it looks strange. I believe that this is not a tagging mistake. The relevant code can be found in addressing.mss.

@mrwojo
Copy link
Contributor

mrwojo commented Feb 21, 2014

I believe the first example is a bug in Mapnik interior point positioning: mapnik/mapnik#2137.

Mapnik's interior point algorithm works like this:

  1. Calculate the centroid point of the polygon.
  2. If that point is inside the polygon, then use that as the interior point. (Done.)
  3. Otherwise, shift that point east or west into the middle of the widest subsection of the polygon.

There's a bug in step 3 where it fails to pick the widest subsection.

Way 227767264 appears to demonstrate the bug. The centroid is just above the lower half of the building. It finds two subsections to the east or west: a tiny sliver through the NW corner and the more substantial bit to the east. The point should be put it in the east part.

Way 262420039 appears to be working as intended, though. The centroid would be outside the building probably in the grass. The two placement options are either the star-like part on the left or the narrow funnel-like bit directly to the right. The algorithm successfully picks the wider of the two.

There's a similar algorithm in the GEOS library, but it still produces non-ideal results like the second example.

@pnorman
Copy link
Collaborator

pnorman commented Mar 4, 2014

Is calculating the point in postgresql with postgis functions a potential improvement?

@mrwojo
Copy link
Contributor

mrwojo commented Mar 4, 2014

ST_PointOnSurface handles multipolygons; IIRC that's a todo in Mapnik (I haven't tested either). PointOnSurface was noticeably slower when I tried it once on real data.

I threw together a quick demo:

master-349-ex osm 17 png-test-

postgis-349-ex osm 17 png-test-

@pnorman
Copy link
Collaborator

pnorman commented May 21, 2014

ST_PointOnSurface isn't a radically better improvement, and the performance issue is likely to be a killer on buildings anyways. Closing this out, as label placement is an upstream issue that we can't fix here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants