- AuthorPosts
- December 1, 2017 at 11:32 #21395JohnPercyParticipant
Interesting developments with peaks and passes, thanks.
Trying this out makes me ask whether the “yes” in mountain_pass=”yes” should be transformed in the mapping to a unique value such as “pass_yes” like other instances of “yes”?
Also, a little disappointed in the height ranges of the mountains. Fine for the Alps, but not so useful in the UK. I count only ten mountains in the next-to-lowest category and all the rest in the lowest category.Voluntary and Velocity themes - https://voluntary.nichesite.org
December 1, 2017 at 15:18 #21397ChristianKKeymasterTrying this out makes me ask whether the „yes“ in mountain_pass=“yes“ should be transformed in the mapping to a unique value
Yes, should be done.
However, its probably the last artefact of first tagmapping – so IMO this will couse no errors.I count only ten mountains in the next-to-lowest category and all the rest in the lowest category.
For Scotland there are [peaks / distance_group]
40 in pd_1
174 in pd_2
354 in pd_3
3848 in pd_4
4140 in pd_5So (eg) Ben Moore Assynt, Sgurr Alasdair,.. appear at ZL.9
Ben Hope, Ben Nevis at ZL.10Well, its not really easy to judge which peak ist “important” and which not, the “distance” approach is easy to handle and the results are IMO OK.
BTW: In GB the situation concerning “importance” of peaks is a little bit different compared to other countrys as there is the munro/corbet scale. It might be an Idea to “upscale” pd_# values for munros at least to (lets say) pd_2 ???
Is the tagging for the munro=yes done for 100% of all munro/peaks or should this be calculated upon the elevation of the peaks? (where hopefully all elevations are tagged in usefull way)Best regards
ChristianEDIT: Just seen that not every peak >3000ft is a “real” munro – so we rely on the munro_tag….
December 1, 2017 at 15:49 #21401ChristianKKeymasterThere are 282 peaks in Scotland tagged as munro=yes
there are 282 “official” munros.So a rule for tagtransform to upgrade munroes to pd_2 should work.
Open for discussion 😉
December 1, 2017 at 16:40 #21405TobiasKeymasterTrying this out makes me ask whether the „yes“ in mountain_pass=“yes“ should be transformed in the mapping to a unique value
Yes, should be done.
However, its probably the last artefact of first tagmapping – so IMO this will couse no errors.There are still others like tunnel=yes, area=yes, maybe more, I think we left them for compatibility reasons.
Also, a little disappointed in the height ranges of the mountains. Fine for the Alps, but not so useful in the UK. I count only ten mountains in the next-to-lowest category and all the rest in the lowest category.
Strange, cause dominance is independent of how high the peak is, it’s a relative value. So a 500m peak can be pd_1, if all others around him in an area of 100km are just 499m high. But all the others, if there is less distance than 1200m between them, are all pd_5.
The five categories are thought to be:
pd_1/ZL9 – the most famous peaks, often of (inter)national importance
pd_2/ZL10 – main peaks of whole mountain ranges
pd_3/ZL11 – main peaks of whole massifs
pd4/ZL12 – lesser dominant peaks
pd5 – everything elseDeveloper of Elevate mapstyle
December 1, 2017 at 16:45 #21407TobiasKeymasterThere are 282 peaks in Scotland tagged as munro=yes
there are 282 „official“ munros.So a rule for tagtransform to upgrade munroes to pd_2 should work.
Open for discussion
pd_2 might work, as most are probably in pd_1 or pd_2. Depends of course on a test, if it works on the zoom levels or gets crowded again.
BTW, the UK maps are still without pd_x values, aren’t they?
Developer of Elevate mapstyle
December 1, 2017 at 20:41 #21409ChristianKKeymasterBTW, the UK maps are still without pd_x values, aren’t they?
GreatBritain and UK_Scotland already contain pd_#
December 1, 2017 at 20:52 #21411ChristianKKeymasterLets give it a try
<translation> <name>set peak_dist to at least pd_2 if munro=yes </name> <description>set peak_dist to at least pd_2 if munro=yes</description> <match type="node" mode="and"> <tag k="natural" v="peak|volcano"/> <tag k="peak_dist" v="pd_3|pd_4|pd_5"/> <tag k="munro" v="yes"/> </match> <output> <copy-all/> <tag k="peak_dist" v="pd_2"/> </output> </translation>
UK_Scotland with latest mapping should be available this weekend.
1 user thanked author for this post.
December 1, 2017 at 21:12 #21414TobiasKeymasterGreatBritain and UK_Scotland already contain pd_#
Quick check with UK_Scotland and latest Elevate shows that it works there as well. A bit less dominant peaks than in the central alps in direct comparison, but probably because there are less peaks (or less named peaks) in general.
Developer of Elevate mapstyle
December 1, 2017 at 21:46 #21416JohnPercyParticipantI misunderstood the basis for assigning categories, and thought it was based on height in metres (and distance was a bad translation!)
Distance assignet to distance_groups:
pd_1 >=25000
pd_2 >=9000
pd_3 >=5000
pd_4 >=1200
pd_5 <1199It all makes sense now!
Voluntary and Velocity themes - https://voluntary.nichesite.org
3 users thanked author for this post.
December 2, 2017 at 15:47 #21427JohnPercyParticipantI don’t know if this behaviour is connected with this feature at all but with the new maps for Great Britain and for Scotland and using Elevate or Voluntary theme on Locus, I am getting a house number for many if not all peaks!
I’ve checked the themes and it is the house number test that is producing the extraneous number, 13785 in this case. I can’t find any relevant tags in the OSM data.
Theme: Elevate on Locus, map location: http://www.openstreetmap.org/node/258829862I don’t seem to get the same effect with Cruiser but I’ve not tested it extensively.
Voluntary and Velocity themes - https://voluntary.nichesite.org
December 2, 2017 at 23:22 #21434ChristianKKeymasterhi John,
I assigned the calculated distance to addr:housenumber for debugging and testing to the peaks.
1 user thanked author for this post.
December 2, 2017 at 23:27 #21436JohnPercyParticipantSo is that a temporary situation? Or do I need to change the test for house numbers?
Voluntary and Velocity themes - https://voluntary.nichesite.org
December 3, 2017 at 13:16 #21442ChristianKKeymasterYes its a temporary situation. I will disable this in the 2018 tagmapping once everyone is satisfied with the grouping of the distance values for the peaks.
However, I hope you don’t display addr:housenumber unconditional for every object in the tagmapping cause the current mapset includes the raw distance mapped to addr:h… for all maps….
December 3, 2017 at 14:49 #21448TobiasKeymasterI don’t know if this behaviour is connected with this feature at all but with the new maps for Great Britain and for Scotland and using Elevate or Voluntary theme on Locus, I am getting a house number for many if not all peaks!
…
I don’t seem to get the same effect with Cruiser but I’ve not tested it extensivelyGreat find! That’s an effect of missing priorities and bad working elemination algorithm (three items in one place) in the LoMaps Engine, so Cruiser would only display it with landscape features unchecked. And you have to zoom in quite a lot 🙂 – so I didn’t test with Locus quite as much as with other apps.
However, I hope you don’t display addr:housenumber unconditional for every object in the tagmapping cause the current mapset includes the raw distance mapped to addr:h… for all maps….
Displaying it unconditional is probably the norm, as there are tons of nodes which are only a housenumber. Only the OAM tag_transform for some tags (because of mapsforge limitations) make it necsessary. But it reality it’s pretty rare, but I’ll have to add some more conditions so that it doesn’t occur even then.
Developer of Elevate mapstyle
December 3, 2017 at 16:09 #21459ChristianKKeymasterDisplaying it unconditional is probably the norm
My foult, mea culpa…
I will re-render European maps…..Unfortunately most maps are on the transfer-server so for a few days addr:## will be shown on the peaks.
Sorry…
- AuthorPosts
- You must be logged in to reply to this topic.