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

Smart placing of #building-text #1661

Closed
kocio-pl opened this issue Jul 15, 2015 · 7 comments
Closed

Smart placing of #building-text #1661

kocio-pl opened this issue Jul 15, 2015 · 7 comments

Comments

@kocio-pl
Copy link
Collaborator

Smart placement of #building-text should allow us to show more names. For box 21.014,52.2316,21.0156,52.2324 on z17 in TileMill I got:

current:
text-tolerance-jablkowscy-z17-before

with added option text-label-position-tolerance: 20;:
text-tolerance-jablkowscy-z17-interior

with added option text-label-position-tolerance: 20; and removed text-placement: interior;:
text-tolerance-jablkowscy-z17-after

Now it's clear that text-label-position-tolerance option works also for closed lines/areas, but probably only in absence of text-placement: interior;(or maybe any value of text-placement?), however it should be investigated and tested more before creating any PR.

It's a proof of concept that we can really fix problems like cities/capitals being eclipsed by admin_level labels and area labels being eclipsed by other elements in the centre.

@kocio-pl
Copy link
Collaborator Author

Does it really?... I have also tried removing both text-label-position-tolerance: 20; and text-placement: interior; and it looks the same as with just using tolerance option:
text-tolerance-jablkowscy-z17-no-placement

There may be lot of possibilities - maybe it works just for some types of closed lines, maybe in this example the lack of interior placement was enough and adding tolerance was not even needed... I would love to have more detailed informations about Mapnik options!

@matkoniecz matkoniecz added this to the Bugs and improvements milestone Jul 16, 2015
@matkoniecz
Copy link
Contributor

Note that removal of text-placement: interior would make rendering worse in many cases (L shaped buildings etc.).

@kocio-pl
Copy link
Collaborator Author

I removed it purely for testing purposes (because I was looking for a difference), but I would be happy to check also how this option works on real map. For example this is - more or less - L-shaped building and its label is placed better without this option IMO than with it.

Looking at French tiles at the same place I can see that:

  • the name is positioned like without this option
  • there is also a housenumber visible on our default position

and I find it even better, so it will be easy to test how it works there and it's probably another nice to have osmfr solution.

However it needs some code investigating too, because their addressing.mss file is different than ours and I can't tell yet where the placement of name label on a building is defined.

@dieterdreist
Copy link

sent from a phone

Am 16.07.2015 um 11:27 schrieb kocio-pl notifications@github.com:

For example this is - more or less - L-shaped building and its label is placed better without this option IMO than with it.

not a building the positioning issues are clearly visible in the french render compared to osm carto: http://www.openstreetmap.org/relation/939256#map=14/42.4742/12.8104

@kocio-pl
Copy link
Collaborator Author

You mean this rendering probably? Yes, it looks to me like a clear counterexample. I look for the way to relocate some labels if needed, but they shouldn't be placed outside the area border.

@HolgerJeromin
Copy link
Contributor

Perhaps we can have text-placement: interior only for small buildings (way_area). Big buildings are probably big enough so labels will not collide. This could be a bad idea... :)

@kocio-pl
Copy link
Collaborator Author

I'm out of ideas how to fix it, so closing now.

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

5 participants