Revised min zoom visibility for some elements #2139

Ircama · 2016-05-30T11:53:55Z

No description provided.

Revised min zoom visibility for some elements

Revert "Revised min zoom visibility for some elements"

imagico · 2016-05-30T13:01:30Z

If you change the starting zoom level of showing certain features, especially if this changes a lot - up to four zoom levels in your case, you need to demonstrate that this actually leads to good results in a large variety of settings (including different latitudes - this is the biggest problem in that regard with Mercator maps).

For place_of_worship for example this seems doubtful - see the following areas with high density of this kind of feature:

http://www.openstreetmap.org/#map=16/41.0104/28.9646
http://www.openstreetmap.org/#map=16/31.7767/35.2276
http://www.openstreetmap.org/#map=16/27.6735/85.3208

pnorman · 2016-05-30T13:50:07Z

addressing.mss

@@ -32,11 +32,13 @@
  }
 }

+// ircama: revised zoom and text size


These comments need removal

@Ircama: There's no need to leave comments like this in the code. "git blame" can be used to show when, why and who made the last change, if we ever need to know it.

@imagico

@imagico: now place_of_worship also need tourism = viewpoint to change the zoom @pnorman: comments should be removed now; no usage of <=

matkoniecz · 2016-06-06T20:32:38Z

Can you provide some examples of places (in form of before/after images) where it improves situation and in regions where it will likely make situation worse?

matkoniecz · 2016-06-06T20:34:16Z

See also message from Travis from https://travis-ci.org/gravitystorm/openstreetmap-carto/builds/134040029 (linked in box below in "continuous-integration/travis-ci/pr — The Travis CI build failed ").

project.yaml and project.mml are not in sync!

You should only modify project.yaml, not project.mml and run scripts/yaml2mml.py before committing.

Read https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md#editing-layers for further information.

Ircama · 2016-06-06T22:26:14Z

See also message from Travis from https://travis-ci.org/gravitystorm/openstreetmap-carto/builds/134040029 (linked in box below in "continuous-integration/travis-ci/pr — The Travis CI build failed ").

Yes, apologize.

I have a Windows installation of Tilemill/openstreetmap-carto/git and realized that, after issuing

               scripts\yaml2mml.py

I also need to run

               <Python>\Tools\Scripts\crlf.py project.mml

(or use an editor to convert <CR><LF> to UNIX <LF>).

This even if I have

              git config core.autocrlf true

if I forget to convert Windows line feeds to UNIX, travis_check_project_files fails.

…xtension-zooms # Conflicts: # amenity-points.mss # water.mss

…topo-extension-zooms # Conflicts: # project.mml

tourism=alpine_hut and tourism=viewpoint are now shown at zoom >= 14 instead of 15 and 16 respectively. viewpoint can be applied to chalet and place_of_worship in order to have them rendered at zoom >= 14: - tourism=chalet & tourism=viewpoint - amenity=place_of_worship & tourism=viewpoint - amenity=shelter & tourism=viewpoint

Ircama · 2016-06-13T23:38:04Z

compare with http://www.openstreetmap.org/#map=14/45.9129/10.0373 (check only areas highlighted in red).

Compare with
http://www.openstreetmap.org/#map=12/45.5869/10.5723

Notice that the rendering at lower zoom for chalet, place_of_worship and shelter is only applied when *tourism=viewpointé (which should be appropriate in the mountains, where those tags are orientation references):

tourism=chalet & tourism=viewpoint
amenity=place_of_worship & tourism=viewpoint
amenity=shelter & tourism=viewpoint

This should allow compatibility with some populated areas or cities where these tags are sometimes present.

dieterdreist · 2016-06-14T06:20:08Z

sent from a phone

Il giorno 14 giu 2016, alle ore 01:38, Ircama notifications@github.com ha scritto:

Notice that the rendering at lower zoom for chalet, place_of_worship and shelter is only applied when *tourism=viewpointé (which should be appropriate in the mountains, where those tags are orientation references):

tourism=chalet & tourism=viewpoint
amenity=place_of_worship & tourism=viewpoint
amenity=shelter & tourism=viewpoint

I don't understand the idea behind this, wouldn't you want to look at the landmark key rather than the viewpoint tag for this?

I don't think in the case of place of worship it would be a good idea to lower their visibility in lower zoom levels, these are deliberately shown early and it should remain like this. It doesn't matter whether you can look from the place of worship, and while they are usually landmarks that can be seen from a distance, they are also quite important in general and merit early rendering from a cultural, historical, urbanist point of view

Ircama · 2016-06-14T06:56:02Z

I don't understand the idea behind this, wouldn't you want to look at the landmark key rather than the viewpoint tag for this?

In the mountains, in alpine unpopulated zones, a church is usually a reference point that should be visible at lower zoom levels.

This is a usually adopted practice in standard topographic maps.

In order to allow this, a church should be visible from great distances and useful for understanding places. As when using tourism=viewpoint this condition should be true, I would consider to only reduce zooms of these monuments when associated with this condition.

I don't think in the case of place of worship it would be a good idea to lower their visibility in lower zoom levels

Agreed for populated zones. A church in a city for instance shall not get tourism=viewpoint.

dieterdreist · 2016-06-14T08:10:26Z

sent from a phone

Il giorno 14 giu 2016, alle ore 08:56, Ircama notifications@github.com ha scritto:

tourism=viewpoint

there seems to be a misunderstanding, tourism=viewpoint is about a spot from where you can enjoy a good view, not a feature that can be seen from far

Ircama · 2016-06-14T09:37:35Z

Well, if in a place you can enjoy a good view, this does mean that it can be seen from far; at the end it should be considered a reference.

We could add both possibilities anyway:

[amenity=place_of_worship][landmark]: 27 points globally at the moment
[amenity=place_of_worship][tourism=viewpoint]: 39 points globally at the moment

Adding both options should not impact the existing rendering.

dieterdreist · 2016-06-14T09:51:31Z

sent from a phone

Il giorno 14 giu 2016, alle ore 11:37, Ircama notifications@github.com ha scritto:

Well, if in a place you can enjoy a good view, this does mean that it can be seen from far; at the end it should be considered a reference.

We could add both possibilities anyway:

[amenity=place_of_worship][landmark]: 27 points globally at the moment
[amenity=place_of_worship][tourism=viewpoint]: 39 points globally at the moment

Adding both options should not impact the existing rendering.

I see now you want to show places of worship earlier not later, sorry, no objection to this.

both options are currently so few that it doesn't really matter anyway ;-)

I would prefer to tie this to buildings (e.g. building=church/chapel/mosque/...), not places of worship , which might in some occasions also be sacred places without any visible structures

Ircama · 2016-06-14T11:11:43Z

both options are currently so few that it doesn't really matter anyway ;-)

I would consider this appropriate: the idea is to enable an appropriate rendering for those features, avoiding to be invasive.

I would prefer to tie this to buildings (e.g. building=church/chapel/mosque/...), not places of worship , which might in some occasions also be sacred places without any visible structures

OK, I'll investigate this

pnorman · 2016-06-14T19:30:32Z

addressing.mss

@@ -36,7 +36,10 @@
  [zoom >= 14][way_pixels > 3000],
  [zoom >= 17] {
    text-name: "[name]";
-    text-size: 11;
+    text-size: 8;


don't use text this small, it poses readability problems, particularly with CJK glyphs (e.g. Japanese)

pnorman · 2016-06-14T20:05:22Z

broadly speaking, there's three things in this PR

font size changes for low zoom addressing
rendering other features earlier if they happen to also be viewpoints
** Changing icon size for these features at low zoom
Scaling up font size for large water area labels.

I can see doing the last of these, I'm not sure about the other changes

Zoom reduction when using tourism=viewpoint or landmark for the following features: - amenity=place_of_worship - man_made=campanile - building=shrine - building=synagogue - building=temple - building=mosque - building=church - building=chapel - building=cathedral Besides, all the above features are rendered now, including symbol and text. Also the text for the following features is now rendered according to tourism=viewpoint and landmark: - man_made=cross - historic=wayside_cross - building=transformer_tower - man_made=chimney - man_made=communications_tower - man_made=tower - man_made=water_tower Peaks (natural=peak) with cross (man_made=cross) are appropriately rendered with a cross starting from zoom level 13. addressing.mss: text-size set to 9 rather than 8

Ircama · 2016-06-15T00:34:54Z

I can see doing the last of these, I'm not sure about the other changes

I can prepare some examples if needed

I would prefer to tie this to buildings (e.g. building=church/chapel/mosque/...), not places of worship , which might in some occasions also be sacred places without any visible structures

Now all those features should be rendered.

Nevertheless, managing landmark tag needs hstore (at least, I used hstore so far; if there is some other method, please advise).

Change list

Zoom reduction when using tourism=viewpoint or landmark for the following features:

amenity=place_of_worship
man_made=campanile
building=shrine
building=synagogue
building=temple
building=mosque
building=church
building=chapel
building=cathedral

Besides, all the above features are rendered now, including symbol and text.

Also the text for the following features is now rendered according to tourism=viewpoint and landmark:

man_made=cross
historic=wayside_cross
building=transformer_tower
man_made=chimney
man_made=communications_tower
man_made=tower
man_made=water_tower

Peaks (natural=peak) with cross (man_made=cross) are appropriately rendered with a cross starting from zoom level 13.

addressing.mss: text-size set to 9 rather than 8

pnorman · 2016-06-15T03:43:39Z

Nevertheless, managing landmark tag needs hstore (at least, I used hstore so far; if there is some other method, please advise).

You cannot use the landmark tag at this time.

pnorman · 2016-06-15T03:44:46Z

addressing.mss

@@ -36,7 +36,10 @@
  [zoom >= 14][way_pixels > 3000],
  [zoom >= 17] {
    text-name: "[name]";
-    text-size: 11;
+    text-size: 9;


this line never applies - the restrictions above require zoom >= 14

pnorman · 2016-06-15T03:48:11Z

You've added in a lot of code about certain building types which is not changing min zoom for some elements. That belongs in a different PR.

Ircama · 2016-06-15T07:48:11Z

You've added in a lot of code about certain building types which is not changing min zoom for some elements. That belongs in a different PR.

I understand that introducing elements that were not rendered at all has involved some coding. I would ask you to consider keeping all changes in a single PR just in this case. It is all about zooming and the new elements are of similar categories, part of the same zooming strategy.

If you anyway consider necessary to separate the coding, I will do that.

Ircama · 2016-06-15T07:53:03Z

You cannot use the landmark tag at this time.

Do you think this kind of commenting convention could be acceptable?

It would allow to temporarily disable hstore references in project.yaml and restore them in a moment as soon as hstore is available:

Before:

            tags->'landmark'::text AS landmark,

After:

            --hstoreADD tags->'landmark'::text AS landmark,
            NULL AS landmark, --hstoreREMOVE

Before:

                tags,

After:

                --hstoreADD tags,

Features can be developed and tested in advance on a dev env but have to be published with these disabling comments. To process project.yaml after hstore in order to enable them:

sed 's/--hstoreADD //;/--hstoreREMOVE/d' project.yaml

pnorman · 2016-06-15T08:15:56Z

No - just don't develop anything that requires a different method of data loading.

Ircama · 2016-06-15T08:26:37Z

No - just don't develop anything that requires a different method of data loading.

OK, I'll remove any reference or comment related to landmark from this branch

pnorman · 2016-06-15T08:46:30Z

I understand that introducing elements that were not rendered at all has involved some coding. I would ask you to consider keeping all changes in a single PR just in this case. It is all about zooming and the new elements are of similar categories, part of the same zooming strategy.

If you anyway consider necessary to separate the coding, I will do that.

There are too many things in this PR that are minimally related and can be considered independently.

water text size
adding special rendering for building=church/etc
address and building text size
rendering objects with tourism=viewpoint sooner
adding rendering man_made = 'cross' rendering
adding some tower-like object renderings
introducing marker-transform

I think the most effective route might be to close this PR and then you can create a new branch from master and not bundle unrelated changes together. A PR needs to have a clear scope, and expanding it to new changes makes review impossible.

dieterdreist · 2016-06-15T18:47:32Z

sent from a phone

Il giorno 14 giu 2016, alle ore 22:05, Paul Norman notifications@github.com ha scritto:

rendering other features earlier if they happen to also be viewpoints ** Changing icon size for these features at low zoom

I am inclined to see this as bad tagging practice, particularly for features like place of worship or buildings, which typically will cover a bigger area than the actual viewpoint (more likely a spot or part of an area of those mentioned before). A viewpoint is a place from which you can look in the distance, it is unlikely that from the whole of a building you will have a good view into the distance

Ircama · 2016-06-16T00:02:06Z

it is unlikely that from the whole of a building you will have a good view into the distance

well, it generally depends on the construction strategy of the building and mappers shall decide case by case.

A church in the Alps for instance is likely a viewpoint, often built on a prominent part of the surrounding territory, e.g., on a cliff, on the top of a hill, on a ridge. Mappers should tag these buildings as viewpoints if e.g. their surrounding courtyards are excellent observation places by design. And map rendering shall reflect this by showing the monument at a lower zoom level.

I am with you that sometimes a building or a place of worship which is not a viewpoint (and shall not be tagged as such in these cases) can still be a landmark, for instance for its facade or campanile that can be a reference for anyone in the valley. Generally a campanile would be a landmark (it is typically so by design) and not a viewpoint (access is generally not allowed).

Anyway the landmark tag cannot be rendered at the moment (I checked and there is a remarkable ongoing work) so we would need to complete the rendering as soon as tags like this can be exploited.

dieterdreist · 2016-06-16T10:45:02Z

2016-06-16 2:02 GMT+02:00 Ircama notifications@github.com:

well, it generally depends on the construction strategy of the building
and mappers shall decide case by case.

A church in the Alps for instance is likely a viewpoint,

no, the viewpoint is typically in front of the church. If you look at usage
for tourism=viewpoint, from 93.000 instances 90.600 are mapped on nodes. I
have checked all place_of_worship that lie in the Alps, they are 4 (!):
https://www.openstreetmap.org/way/173484441#map=19/47.57752/9.72613
https://www.openstreetmap.org/way/165625551
https://www.openstreetmap.org/way/270413340
and this one in the valley:
https://www.openstreetmap.org/way/43685450#map=16/46.9695/9.9221

This mapstyle is rendering commonly mapped objects. Adding complex rules
for very few objects is not justified.

IMHO your general idea is good (render some landmarks ealier). My
suggestion is to document the landmark key in the wiki and promote it
(because tourism=viewpoint is not suitable for your scope). Then implement
rules here (hoping that by the time, hstore will be activated in the
rendering db or a column for landmark will have been added)

Ircama · 2016-06-16T23:18:18Z

@dieterdreist

I'm learning now that churches like those ones linked here below will not be viewpoint references themselves, but maybe some surrounding area close to them:

http://footage.framepool.com/shotimg/qf/297459944-cortina-d'ampezzo-cappella-dolomiti-paesaggio-collinare.jpg

http://www.buonviaggioitalia.it/wp-content/uploads/2015/05/2015-04-14-2629.jpg

http://www.hafling-meran2000.eu/bilder/stkathrein-meran-hafling-suedtirol.jpg

http://www.golivefvg.com/wp-content/uploads/2012/09/milani_c1-162-2455-650x433.jpg

:-)

ok, no problem.

Provided that there are many underrepresented features in OSM, that there might be a relation between unused tags and not rendered ones and that IMHO the current style is actually poor in rendering mountainous unpopulated places, your suggestion is viable.

matthijsmelissen · 2016-07-25T22:03:59Z

@Ircama This pull request still does a lot more than what is stated in the title ('revised min zoom visibility'). Would you be able to split this up even more? Thanks!

Ircama · 2016-07-25T22:19:29Z

@math1985: sure, will do

This branch supersedes branch https://github.com/Ircama/openstreetmap-carto/tree/topo-extension-zooms for the specifical relation to peaks (natural=peak) with cross (man_made=cross), which are appropriately rendered with a cross starting from zoom level 13. Vs. previous branch, the marker-transform feature has been replaced by specifig icons. Related PR will replace gravitystorm#2139 for the feature "peaks with cross".

This branch supersedes branch https://github.com/Ircama/openstreetmap-carto/tree/topo-extension-zooms specifically for the text size to be used for lakes (natural=water or landuse=reservoir/basin). Related PR will replace gravitystorm#2139 for the feature "Revised text size for lakes".

This branch supersedes branch https://github.com/Ircama/openstreetmap-carto/tree/topo-extension-zooms specifically for the rendering of religious buildings and related text: amenity=place_of_worship man_made=campanile building=shrine building=synagogue building=temple building=mosque building=church building=chapel building=cathedral Related PR will replace gravitystorm#2139 for the rendering of religious features.

This branch supersedes branch https://github.com/Ircama/openstreetmap-carto/tree/topo-extension-zooms for the specifical relation to peaks (natural=peak) with cross (man_made=cross), which are appropriately rendered with a cross starting from zoom level 13. Vs. previous branch, the marker-transform feature has been replaced by specifig icons. Related PR will replace gravitystorm#2139 for the feature "peaks with cross".

This branch supersedes branch https://github.com/Ircama/openstreetmap-carto/tree/topo-extension-zooms specifically for the rendering of religious buildings and related text: amenity=place_of_worship man_made=campanile building=shrine building=synagogue building=temple building=mosque building=church building=chapel building=cathedral Related PR will replace gravitystorm#2139 for the rendering of religious features. Correct ('man_made_' || (CASE WHEN man_made IN ('tower', 'campanile') into ('man_made_' || (CASE WHEN man_made IN ('campanile')

Ircama added 4 commits May 30, 2016 13:18

Revised min zoom visibility for some elements

22cdbb2

(revised comment)

5c5aadf

Merge pull request #1 from Ircama/topo-extension-zooms

351bfcc

Revised min zoom visibility for some elements

Revert "Revised min zoom visibility for some elements"

3a2644e

Ircama mentioned this pull request May 30, 2016

topographic extensions #2134

Closed

Merge pull request #3 from Ircama/revert-1-topo-extension-zooms

a9e4139

Revert "Revised min zoom visibility for some elements"

pnorman reviewed May 30, 2016
View reviewed changes

Revised rendering following feedbacks

93f7640

@imagico: now place_of_worship also need tourism = viewpoint to change the zoom @pnorman: comments should be removed now; no usage of <=

Ircama added 4 commits June 13, 2016 08:28

Merge remote-tracking branch 'refs/remotes/origin/master' into topo-e…

26366dc

…xtension-zooms # Conflicts: # amenity-points.mss # water.mss

Updated from new master

9b53311

Merge remote-tracking branch 'refs/remotes/gravitystorm/master' into …

cbd6b3c

…topo-extension-zooms # Conflicts: # project.mml

pnorman reviewed Jun 14, 2016
View reviewed changes

pnorman reviewed Jun 15, 2016
View reviewed changes

matthijsmelissen closed this Jul 25, 2016

Ircama mentioned this pull request Aug 16, 2016

Add specific symbol for peaks with cross #2285

Closed

Ircama mentioned this pull request Aug 17, 2016

Revised text size for lakes #2287

Closed

pnorman mentioned this pull request Aug 18, 2016

Review onboarding #2291

Open

Ircama mentioned this pull request Aug 19, 2016

Revised min. zoom for tourism=alpine_hut #2294

Closed

This was referenced Aug 20, 2016

Better rendering of religious features #2296

Closed

Revised min. zoom for tourism=alpine_hut #2301

Merged

Revised text size for lakes #2302

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Revised min zoom visibility for some elements #2139

Revised min zoom visibility for some elements #2139

Ircama commented May 30, 2016

imagico commented May 30, 2016

pnorman May 30, 2016

gravitystorm Jun 6, 2016

matkoniecz commented Jun 6, 2016

matkoniecz commented Jun 6, 2016

Ircama commented Jun 6, 2016

Ircama commented Jun 13, 2016

dieterdreist commented Jun 14, 2016

Ircama commented Jun 14, 2016

dieterdreist commented Jun 14, 2016

Ircama commented Jun 14, 2016

dieterdreist commented Jun 14, 2016

Ircama commented Jun 14, 2016 •

edited

Loading

pnorman Jun 14, 2016

pnorman commented Jun 14, 2016

Ircama commented Jun 15, 2016 •

edited

Loading

pnorman commented Jun 15, 2016

pnorman Jun 15, 2016

pnorman commented Jun 15, 2016

Ircama commented Jun 15, 2016

Ircama commented Jun 15, 2016

pnorman commented Jun 15, 2016

Ircama commented Jun 15, 2016

pnorman commented Jun 15, 2016

dieterdreist commented Jun 15, 2016

Ircama commented Jun 16, 2016

dieterdreist commented Jun 16, 2016

Ircama commented Jun 16, 2016

matthijsmelissen commented Jul 25, 2016

Ircama commented Jul 25, 2016

Revised min zoom visibility for some elements #2139

Revised min zoom visibility for some elements #2139

Conversation

Ircama commented May 30, 2016

imagico commented May 30, 2016

pnorman May 30, 2016

Choose a reason for hiding this comment

gravitystorm Jun 6, 2016

Choose a reason for hiding this comment

matkoniecz commented Jun 6, 2016

matkoniecz commented Jun 6, 2016

Ircama commented Jun 6, 2016

Ircama commented Jun 13, 2016

dieterdreist commented Jun 14, 2016

Ircama commented Jun 14, 2016

dieterdreist commented Jun 14, 2016

Ircama commented Jun 14, 2016

dieterdreist commented Jun 14, 2016

Ircama commented Jun 14, 2016 • edited Loading

pnorman Jun 14, 2016

Choose a reason for hiding this comment

pnorman commented Jun 14, 2016

Ircama commented Jun 15, 2016 • edited Loading

Change list

pnorman commented Jun 15, 2016

pnorman Jun 15, 2016

Choose a reason for hiding this comment

pnorman commented Jun 15, 2016

Ircama commented Jun 15, 2016

Ircama commented Jun 15, 2016

pnorman commented Jun 15, 2016

Ircama commented Jun 15, 2016

pnorman commented Jun 15, 2016

dieterdreist commented Jun 15, 2016

Ircama commented Jun 16, 2016

dieterdreist commented Jun 16, 2016

Ircama commented Jun 16, 2016

matthijsmelissen commented Jul 25, 2016

Ircama commented Jul 25, 2016

Ircama commented Jun 14, 2016 •

edited

Loading

Ircama commented Jun 15, 2016 •

edited

Loading