Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
    Posts
  • #52769
    karlchick
    Participant

    Hi Tobias,

    I appreciate your concern, and for map themes that want to represent all car parks regardless this is fine.

    However, the point of themes is to provide people a way to display/customise maps how they prefer for their own specific purposes (otherwise we could have just one theme and just change the colours/symbols).

    Surely it should be up to each theme creator what and how to display in the map based on the ground truth described in the OSM data. However, excluding certain values like access=yes (The public has an official, legally-enshrined right of access) takes many options away from the themer.

    I already use access=destination to exclude customer car parks from view – however, users can select the “non-OS symbols” to display them using a different symbol to indicate customer parking and not general public parking, also display private car parks differently too, see attached.

    All the car parks I checked locally in the UK that include access=yes are public car parks, so (for my theme) I would like to use that as a starting point for indicating publicly accessible car parks.

    Another issue I noticed recently is that there has been a sharp increase in the number of micro-mapped amenity=parking with no tags being added recently to all towns and cities – these are having the effect of flooding the map with parking symbols and “hiding” the true public car parks. These will (presumably) never gain access-yes since they are generally private/customer parking.

    given that mappers state that we should tag “ground truth” and leave it up to the theme to select what to display, it would seem essential that we have all the main “access” values available to do this.

    To deal with the large volume of “lazy” new amenity=parking (with no other tags) being created, I want display these with a greyed out version of the parking symbol from around zoom=17, to indicate that these are car parks of unknown access and ensure that the public car parks (access=yes) are very visible and easier to locate.

    But this requires access=yes…

    I have started to deal with the parking=street_side|lane (many many more parking lots!) in a similar way (using a smaller parking symbol at higher zoom levels only).

    But the biggest issue for me, is that I can not use access=yes.

    Why not leave it to the theme creators to decide if the access=yes is useful for their purposes?

    #52774
    Avatar photoTobias
    Keymaster

    Surely it should be up to each theme creator what and how to display in the map based on the ground truth described in the OSM data. However, excluding certain values like access=yes (The public has an official, legally-enshrined right of access) takes many options away from the themer.

    There seems to be a misunderstanding. Mapsforge maps are not an OSM database. They come in two parts, the map and the theme. Both are part of processing OSM data for map rendering, one coarser (the map), one finer (the theme).
    The tag-mapping of OpenAndroMaps doesn’t take options away, it adds tags to the maps which are needed.
    With your argument every tag that exists should be added to the map and only the theme should decide what is rendered. This doesn’t work, as the maps couldn’t be generated (or it would take eons) and would be extremely large. So the map creator has to decide which tags should be added (and not taken away) to reduce these costs.
    What tags are added depend on the purpose of the map. For OAM that’s to provide worldwide hiking and cycling maps. So the map content and which tags are added reflects this purpose and is preprocessed for this. So a lot of primary, secondary and tertiary tags are added for that, but for other uses maybe none or just primary tags.

    So back to the original question, access=yes is a very common tag (1.612.726 uses), so this would increase the costs mentioned above. But would it increase the actual usage for hiking and cycling? My main usage of parking areas in OAM is to find them where I want to start hiking/cycling. E.g. in valleys in the alps there isn’t the micro-mapping you mentioned above, just plain parking for hikers, sometimes just amenity=parking. For this purpose access=yes wouldn’t add additional information, I usually also try other non-OSM sources if I’m not sure before driving long ways.

    We sometimes get asked to add tags for motorized traffic, but I think mapsforge maps isn’t made for this anyway. I use a car navigation app for that.

    Of course Mapsforge themes are a really good thing to have different rendering according to one’s preference; Elevate also started out like this, and we encourage it. We also are happy for suggestions of tags that would be useful to add to OAM. But this should be within our purpose. Of course themes can be designed for other purposes, but maybe OAM aren’t the right basis for those.

    Developer of Elevate mapstyle

    1 user thanked author for this post.
    #52784
    karlchick
    Participant

    The point was more trying to make is that access=yes (73,364 in UK) is excluded in OAM while most of other common usages of access are included and some of these are significantly higher in usage:
    – private (609,420 in UK)
    – destination (80,878 in UK) [access=customers|destination]
    – acc_no (48,709 in UK) [access=no]
    – permit (2,823 in UK)
    – forestry (4,256 in UK) [access=agricultural|forestry]
    For the UK, there are a total of 746,086 access values set in the UK, surely an increase of 73k more values to a total of 819,450 would not make such a large difference to the map size? Especially when you consider something like barrier=* which totals 2,724,528 in the UK.

    Interestingly “permissive” is excluded too from OAM. I’d have thought that both yes and permissive indicate access is allowed, which for public car parking is surely of primary interest to people driving somewhere to then use their map?

    #52790
    Avatar photoTobias
    Keymaster

    We have access=* mainly for rendering highway=*, especially path/footway/cycleway, and access restrictions for those. Because of the hierarchy of access-tags, access=* inherits to bicycle=* and foot=*. For the latter we have yes and permissive, e.g. for highway=cycleway and foot=yes. An access=yes/permissive is not necessary here. Again, all in accordance with our purpose.
    Of course we have more tags in the maps than access=yes. But those are tags which make sense, e.g. barrier for cycling,

    Interestingly „permissive“ is excluded too from OAM. I’d have thought that both yes and permissive indicate access is allowed, which for public car parking is surely of primary interest to people driving somewhere to then use their map?

    I think I answered that before:
    https://www.openandromaps.org/oam-forums/topic/rendering-accessno-and-accessyes#post-52759
    https://www.openandromaps.org/oam-forums/topic/rendering-accessno-and-accessyes/page/2#post-52774
    For the 70% amenity=parking without any access=* it makes sense to assume that in case of parking spaces in hiking areas that they are public. If in doubt, as always with things hiking concerned, check other sources, e.g. driving descriptions in hiking guides.

    Developer of Elevate mapstyle

Viewing 4 posts - 16 through 19 (of 19 total)
  • You must be logged in to reply to this topic.