Viewing 15 posts - 1 through 15 (of 40 total)
  • Author
    Posts
  • #21043
    Interaktiv Grafika
    Participant

    Hi,

    I know you already hate me, so I have nothing to lose by asking questions about some (probably) missing elements in OAM maps.

    There are refs to the red_arch, black_arch, and white_arch waymarks in the legendary Elevate theme, but (at least) in Hungary the arch can carry the other colours too, like yellow_arch, blue_arch… and so on. The .svg symbols are there in the ele_res folder but despite placing the proper references into my poor little theme, the missing waymarks won’t come up, so maybe they are missing from the map file?

    e=”node” k=”natural” v=”rock” seems missing from the map, no ref in the Elevate theme either.

    Not exactly missing just k=”landuse” v=”residential” areas appear from zoom level 12 set by the map. Now it’s obviously quite subjective thing but for me it’s a little late entry, big cities can cover huge part of mobile screens at level 11 or even 10 so I’d enjoy the shape of the cities even at these zoom levels not just the roads. Yes, subjective and there can be even some technical reason for this specific zoom level.

    Thanks and best regards,
    IG

    #21046
    Avatar photoTobias
    Keymaster

    I know you already hate me, so I have nothing to lose by asking questions about some (probably) missing elements in OAM maps.

    No hate 😉 we can’t know everything, every input is welcome – we just can’t promise to add every wish.

    There are refs to the red_arch, black_arch, and white_arch waymarks in the legendary Elevate theme, but (at least) in Hungary the arch can carry the other colours too, like yellow_arch, blue_arch… and so on. The .svg symbols are there in the ele_res folder but despite placing the proper references into my poor little theme, the missing waymarks won’t come up, so maybe they are missing from the map file?.

    Seems like you missed the “MapBasics” part, where you can find what and how is defined in the maps. Here you can find the in the maps only these waymarks are contained:

    I don’t know if there are any other arches available in OSM data at all, as these sites also say that only those colors above are defined:
    http://wiki.openstreetmap.org/wiki/Key:osmc:symbol#Label_foreground
    http://www.wanderreitkarte.de/symbols_en.html
    Have you any examples where those are shown in OSM based maps?

    e=“node“ k=“natural“ v=“rock“ seems missing from the map, no ref in the Elevate theme either.

    Again, checking MapBasics helps: in https://www.openandromaps.org/en/map-basics-2/tag-mapping scroll down to the bottom, there is the current tag-mapping, where all available tags in the maps are defined. rock nodes are equivalent with nat_stone:
    <osm-tag key='natural' value='nat_stone' equivalent-values='rock,stone' zoom-appear='14' />
    So they are rendered like natural=stone.

    Not exactly missing just k=“landuse“ v=“residential“ areas appear from zoom level 12 set by the map. Now it’s obviously quite subjective thing but for me it’s a little late entry, big cities can cover huge part of mobile screens at level 11 or even 10 so I’d enjoy the shape of the cities even at these zoom levels not just the roads. Yes, subjective and there can be even some technical reason for this specific zoom level.

    In OAM, there are three basic zoom levels: 0-7,8-11,12-21
    Having something appear in an additional ZL where one of those borders is crossed will blow up the map and prolong the rendering, so one has to carefully decide for what information this is really important. Especially areas are more costly.
    I think it could be nicer if all those areas would show up earlier, but it doesn’t give any additional information. And residential wouldn’t be enough, I use all those to define the populated areas: residential|farmyard|retail|commercial|industrial|brownfield|railway|garages|construction|landfill

    Developer of Elevate mapstyle

    #21060
    Interaktiv Grafika
    Participant

    Hi Tobias,

    No hate 😉 we can’t know everything, every input is welcome – we just can’t promise to add every wish.

    I hoped so! 🙂 Yea, these OSM-based distributions are like boxes of chocolates: you never know what you’re gonna get. But OAM is definitely one of the most tastiests 🙂

    Seems like you missed the “MapBasics” part, where you can find what and how is defined in the maps. Here you can find the in the maps only these waymarks are contained:
    https://www.openandromaps.org/en/map-basics-2/osmcsymbols
    I don’t know if there are any other arches available in OSM data at all, as these sites also say that only those colors above are defined:
    http://wiki.openstreetmap.org/wiki/Key:osmc:symbol#Label_foreground
    http://www.wanderreitkarte.de/symbols_en.html
    Have you any examples where those are shown in OSM based maps?

    Sure, for e.g. (references from overpass turbo, screenshots from Locus with openmaps.eu map):

    Relation 2631621
    Tags:
    jel=zb
    name=ZΩ (Fekete salak út – Tábor-hegyi-barlang – Viharhegyi út am.)
    network=lwn
    osmc:symbol=green:white:green_arch
    ref=ZΩ
    route=hiking
    type=route

    null

    Relation 6664023
    Tags:
    jel=kb
    name=KΩ (Klastrompuszta – Legény-barlang)
    network=lwn
    osmc:symbol=blue:white:blue_arch
    route=hiking
    type=route

    null

    Relation 1623450
    Tags:
    jel=sb
    name=S omega (Szt. Mihály-hegy)
    network=lwn
    osmc:symbol=yellow:white:yellow_arch
    route=hiking
    symbol:hu=sárga omega
    type=route

    null

    Again, checking MapBasics helps: in https://www.openandromaps.org/en/map-basics-2/tag-mapping scroll down to the bottom, there is the current tag-mapping, where all available tags in the maps are defined. rock nodes are equivalent with nat_stone:
    <link rel=”stylesheet” type=”text/css” href=”https://cdn.openandromaps.org/wp-content/plugins/crayon-syntax-highlighter/themes/classic/classic.css”&gt;
    <link rel=”stylesheet” type=”text/css” href=”https://cdn.openandromaps.org/wp-content/plugins/crayon-syntax-highlighter/fonts/monaco.css”&gt;

    <span id=”crayon-5a0eb4b66ec5b615914032″ class=”crayon-syntax crayon-syntax-inline crayon-theme-classic crayon-theme-classic-inline crayon-font-monaco” style=”font-size: 12px !important; line-height: 15px !important;font-size: 12px !important;”><span class=”crayon-pre crayon-code” style=”font-size: 12px !important; line-height: 15px !important;font-size: 12px !important; -moz-tab-size:4; -o-tab-size:4; -webkit-tab-size:4; tab-size:4;”><span class=”crayon-o”><</span><span class=”crayon-v”>osm</span><span class=”crayon-o”>-</span><span class=”crayon-e”>tag </span><span class=”crayon-v”>key</span><span class=”crayon-o”>=</span><span class=”crayon-s”>’natural'</span><span class=”crayon-h”> </span><span class=”crayon-v”>value</span><span class=”crayon-o”>=</span><span class=”crayon-s”>’nat_stone'</span><span class=”crayon-h”> </span><span class=”crayon-v”>equivalent</span><span class=”crayon-o”>-</span><span class=”crayon-v”>values</span><span class=”crayon-o”>=</span><span class=”crayon-s”>’rock,stone'</span><span class=”crayon-h”> </span><span class=”crayon-v”>zoom</span><span class=”crayon-o”>-</span><span class=”crayon-v”>appear</span><span class=”crayon-o”>=</span><span class=”crayon-s”>’14′</span><span class=”crayon-h”> </span><span class=”crayon-o”>/</span><span class=”crayon-o”>></span></span></span>
    So they are rendered like natural=stone.

    Yea, I missed that Mapbasics article but from now on it is my bible!

    In OAM, there are three basic zoom levels: 0-7,8-11,12-21
    Having something appear in an additional ZL where one of those borders is crossed will blow up the map and prolong the rendering, so one has to carefully decide for what information this is really important. Especially areas are more costly.
    I think it could be nicer if all those areas would show up earlier, but it doesn’t give any additional information. And residential wouldn’t be enough, I use all those to define the populated areas: residential|farmyard|retail|commercial|industrial|brownfield|railway|garages|construction|landfill

    Understood. I thought it could be some performance-related consideration. Thanks for the reply.

    Best regards,
    IG

    #21062
    Avatar photoChristianK
    Keymaster

    OK, the map-basic pages were somewhat confusing.
    I moved the main informations up to top of the page – followed by the changelog.

    Added yellow,green,blue arch
    Now arches are in the tagmapping for all main colors

    Best regards
    Christian

    1 user thanked author for this post.
    #21064
    Interaktiv Grafika
    Participant

    Hi Christian,

    Thanks for the lightning fast reaction!

    Btw, what is the deadline of your next map release, I mean what is the last time point to commit changes to OSM that would show up in the next OAM map for Europe (Hungary)?

    Best regards,
    IG

    #21068
    Avatar photoChristianK
    Keymaster

    Btw, what is the deadline of your next map release

    Well, I have changed osm-base for map-creation from Geofabrik extracts to planet-latest.
    Planet-latest is updated every 7-9 days.
    Download and preprozessing of the planet file last 9h
    Map rendering for Europe is 5-6days, Germany 2-3days.

    So it’s hard to define a deadline, I would say at least 5days for europe.

    WHY: Most map provider are using the country extracts from Geofabrik.
    For usual maps this is OK, ist fast, its convenient, its easy to handle, the extract could be downloaded right bevore rendering a map, no need to create custom map borders and poly files.
    OAM maps are made for cyclists and hikers and the hike and cycle routes are passing borders or run along on both sides of borders (cycle ways along rivers aso) so the stahdard overlapping of Geofabrik extracts are not sufficient = routes are clipped. So 99% of the OAM maps have custom, optimized border-polys = extracts have to be clipped from planet-latest (or Europe-latest, aso..).

    Best regards
    Christian

    #21075
    Avatar photoTobias
    Keymaster

    Thanks for the examples and to Christian for the quick addition!
    BTW, waycolor is contained in the latest tag-mapping.

    Developer of Elevate mapstyle

    #21096
    Avatar photoChristianK
    Keymaster

    BTW, waycolor is contained in the latest tag-mapping.

    Yes, but only for the collor assigned to Relations with highest priority.
    To add colors for all relations reverenced to a way a major rewrite in resolving scripts would be necessary.

    Sorry

    Christian

    #21100
    Avatar photoTobias
    Keymaster

    I think it’s logical like that, as other things – routes and waymarks – are also that way. It wouldn’t make much sense to change only one thing and leave the others.

    Developer of Elevate mapstyle

    #21104
    Interaktiv Grafika
    Participant

    Hi,

    So when a way is part of
    Route A : network=national; osmc:symbol=blue:white:blue_cross and
    Route B : network=regional; osmc:symbol=green:white:green_rectangle,
    the way based on the network tags will only get hknetwork=nwn; osmc_color=wmco_blue and selected nodes will get osmc_foreground=wmfg_blue_cross, because national is higher priority than regional, right?

    Btw, what happens when the osmc:symbol tag doesn’t have a valid foreground part but for e.g. has text instead like osmc:symbol=blue:white:::M:blue? You just ignore it and step down to the next related route, I guess?

    Thanks and best regards
    IG

    1 user thanked author for this post.
    #21236
    Avatar photoTobias
    Keymaster

    The “new” arches work as expected, thanks for your examples. Will be included in next Elevate versions as well.

    Developer of Elevate mapstyle

    2 users thanked author for this post.
    #21248
    Interaktiv Grafika
    Participant

    Hi,

    So this December release seems quite sweet but I just couldn’t help thinking about improvements for the already-best map distribution from hikers for hikers. Already the best, because it provides the holy trinity of mountain path attributes: sac_scale, trail_visibility and surface. Too many other distributions are missing some or all of them unfortunately.

    Now, when I checked the theme hackers’ bible, i.e. your tag-mapping table I saw your 3 groups that mainly related to (mountain) paths:

    <osm-tag key=’surface’ value=’gravel’ equivalent-values=’pebblestone’ renderable=’false’ zoom-appear=’8′ />
    <osm-tag key=’surface’ value=’raw’ equivalent-values=’ground,dirt,grass,sand,wood,earth,mud,clay,salt,woodchips’ renderable=’false’ zoom-appear=’8′ />
    <osm-tag key=’surface’ value=’winter’ equivalent-values=’ice,snow’ renderable=’false’ />

    It looks nice and logical, but it reminded me of my pet peeve of the state of OpenStreetMap tagging: the not standardised surface values for paths in scree or bare_rock areas. There is gravel in the OSM Wiki and… that’s it. Now this is a pic of mine from a valley path in the Pilis Mountains, I wouldn’t call it gravel (or peeblestones), now would you?

    Valley in the Pilis Mountains

    You hike on rocks here (former streambed). But it’s not just valleys, in Hungarian mountains (and I guess others too) it’s quite common that a path starts with forest soil surface (ground/earth etc.) then at some point the area turns into scree or bare_rock. In the case of scree with bigger and smaller rocks you can force it to call the surface “gravel” but big rocks, boulders or bedrock are definitely not in this box.

    When I started mapping the mountain paths I hiked and I faced this omission I searched for an acceptable solution, based on OSM help/wiki but I found quite diverse values, it seemed rock, rocky, stone were kinda common, still dwarfed by gravel of course. As always I ran some queries through Overpass for highway=path with these surface values for Western+Central Europe and found about 250 with rock, 110 with rocky and 500 with stone (ok, 50 of them with bridge=yes as well, there are seemingly a LOT of stone bridges in Germany…). So it’s about 800 paths with these values in a big part of Europe, I’d call it a good start.

    Now if you think there’s some logic in the stuff above you may ask where to put these additional values, they are raw so it would be logical to put them there. But I’d argue for a separated group for them like

    <osm-tag key=’surface’ value=’rock’ equivalent-values=’rocky,stone’ renderable=’false’ zoom-appear=’8′ />

    because of the different dry/wet weather properties. Maybe unintentionally, but your raw “group” contains soft surfaces that turn into even softer in wet weather (well mud is already there, but the others can turn into that, ok wood(chips) can’t…). On the other hand rock is hard and stays hard but gets VERY slippery in the rain in my experience, so having this “group” would provide useful additional info about what to expect on a (mountain) path.

    Opinions?

    Thanks and best regards,
    IG

    #21256
    Avatar photoTobias
    Keymaster

    Now this is a pic of mine from a valley path in the Pilis Mountains, I wouldn’t call it gravel (or peeblestones), now would you?

    For this I would use surface=ground, as with any other surface which is the natural surface of the surroundings. Any artificial surface, so any kind of material which is introduced by man, would be something else. Even surface=rock, I would use this for rocks arranged on the ground as a surface of a path. And what kind of surface it is, can be seen then according to the area surrounding it – be it scree, bare_rock, sand, whatever. I would normally use gravel for ways where gravel is used as material to form the surface, not for any natural stuff.

    When I started mapping the mountain paths I hiked and I faced this omission I searched for an acceptable solution, based on OSM help/wiki but I found quite diverse values, it seemed rock, rocky, stone were kinda common, still dwarfed by gravel of course. As always I ran some queries through Overpass for highway=path with these surface values for Western+Central Europe and found about 250 with rock, 110 with rocky and 500 with stone (ok, 50 of them with bridge=yes as well, there are seemingly a LOT of stone bridges in Germany…). So it’s about 800 paths with these values in a big part of Europe, I’d call it a good start.

    Have you looked here?
    https://taginfo.openstreetmap.org/keys/surface#values
    We try to cover the most common surfaces, and also those which are used by OSM Carto. So any ot the values you mentioned are really rare.
    The categories for surface weren’t introduced for hiking anyway. For me personally surface isn’t really important on foot as long as it’s not paved. With other means it gets more important. In OAM the surfaces were clustered for cycling, maybe the categories make more sense now 🙂
    So raw means the most difficult surfaces for cycling or any other vehicles with wheels.

    Now if you think there’s some logic in the stuff above you may ask where to put these additional values, they are raw so it would be logical to put them there. But I’d argue for a separated group for them like

    <osm-tag key=’surface‘ value=’rock‘ equivalent-values=’rocky,stone‘ renderable=’false‘ zoom-appear=’8′ />

    because of the different dry/wet weather properties.

    In the categories intended in OAM it makes not a lot of sense, especially when it’s only 0.04% of all tagged surfaces.

    Maybe unintentionally, but your raw „group“ contains soft surfaces that turn into even softer in wet weather (well mud is already there, but the others can turn into that, ok wood(chips) can’t…). On the other hand rock is hard and stays hard but gets VERY slippery in the rain in my experience, so having this „group“ would provide useful additional info about what to expect on a (mountain) path.

    As said above, raw contains ground, and ground can be pretty hard and rocky :-), also wood (means wood planks) or salt is also very hard, and maybe slippery when wet.
    So we would need very different categories if we want to check for slippery paths. And in my experience, rocks don’t behave the same – chalk stone gets very slippery when wet, but granite is still pretty sticky.
    So maybe we should check again which surfaces are worth adding to our categories, but beware, they might end up where you don’t expect them – stone is already covered in rough_paved for example.

    Developer of Elevate mapstyle

    #21266
    Interaktiv Grafika
    Participant

    Hi Tobias,

    Thanks for the reply. Interesting to see how tagging “philosophies” can differ. Obviously I always looked at this from the viewpoint of the hiker on foot, then it seems your classification is more from the viewpoint of vehicles/cycling or natural/man-made surfaces, closer to the origins of OSM.

    Anyways you say that all the natural surfaces of paths should be ground and all the other surface types would be for man-made ways. So to see if I understood well, if people build a sandy road in a city for some reason, its surface=sand but if there’s a path through sand dunes it should be ground because it’s natural? Or a path through cultivated meadows or gardens could be surface=grass but through natural grasslands should be ground again, right? What is earth in this method?

    Thanks and best regards,
    IG

    #21270
    Avatar photoTobias
    Keymaster

    Anyways you say that all the natural surfaces of paths should be ground and all the other surface types would be for man-made ways.

    I said that I would use this, not that this is how it should be.

    So to see if I understood well, if people build a sandy road in a city for some reason, its surface=sand but if there’s a path through sand dunes it should be ground because it’s natural? Or a path through cultivated meadows or gardens could be surface=grass but through natural grasslands should be ground again, right? What is earth in this method?

    Don’t expect consistency in OSM :-), especially when there’s no proper concept involved as in surface
    I just think that ground covers a lot of ground 🙂

    Developer of Elevate mapstyle

Viewing 15 posts - 1 through 15 (of 40 total)
  • You must be logged in to reply to this topic.