Messages

@voldapet

Point 14
Request: would it be possible add natural=bay to LoMaps?

Attached is an example from OSM and comparison of OAM vs LoMap.

Point 15
This is probably something I should request against the app rather than here, but I'm wondering if it would be possible to have a grid like OS maps have, perhaps 1km lines and 10km lines that can be customised by the theme to appear at suitable zoom levels and stroke styles etc..

@voldapet

@karlchick
BTW: are there any standard symbols or styles that indicate designation in the UK maps?

See attached Ordnance Survey legends. PROW are red or green according to the map scale; there are different markings for different types of access rights.

@voldapet
Sorry, I missed that question. Yes OS maps do have symbology for different access rights, colours, dashes and dots are used to represent different Public Rights Of Way (PROW) as in 3rd and 4th attachments.

The designation tags in OSM should allow me to represent all these in the theme, I think.

Note that newer OS maps now also include orange dashed pathways for Permissibe PROW. I have tried to emulate this in OAM using combinations of available tags and it largely works, see first attached (left OS, right OAM). Currently path, PROW path, PROW bridleway, PROW permissive path. It should be a lot easier with the designation tag, but sometimes the access is set to permissive in other situations, hence OAM's foot=ft ft_permissive is useful...

I have also added tidal paths (blue) as a non-OS option, see second attached. Note I use thinner dashed paths for non-PROW paths (as do OS maps). This example shows a low tide alternative path that people sometimes use when walking the South West Coastal Path (SWCP). It has tidal paths/steps and a permissive set of stairs to return  to the hiking SWCP route.

With the designation tag I should be able to represent all the OS symbols... I'm looking forward to an updated LoMap to play with.

Edit:updated images for latest fixes.

Hmm.. I think the LoMap approach to cycle/mtb routes is very different compared to OAM.

OAM seems to remap the cycle/mtb/hiking network values through to the highways they are related and uses separated tags for each type of route (network=cycle, mtnetwork=mtb and hknetwork=hiking).

OAM additionally resolves issues like route=mtb and network=ncn, by remapping these through to mtbnetwork=nmn. An example of this can be seen in the attached first pair of images showing LoMap/OAM with the latest v5 Voluntary theme, see how the mtb route is displayed in LoMap with blue/purple blobs but in OAM is only purple blobs.

I resolved this for now in LoMap maps by ignoring the network tag and using just the route=mtb/bicycle values to differentiate them. Separate rules are used for OAM and ignored by LoMap by checking for route="~", since OAM doesn't used route tags for network routes. See second pair of images comparing LoMap/OAM with my latest OS prototype theme.

LoMap having separated routes results in multiple renders for each route, advantage is ref labels for both routes, disadvantage is multiple highlight/emphasis drawn.
 
Another feature/issue... since LoMap is using separated route ways from the highways, I can't determine if a route is off-road. With OAM I am introducing hollow blobs when a route is off-road, see attached third pair of images.

Finally, I am missing OAM's feature to autogenerate route refs when a route has no ref tag, it does this by raking the first letter if each word in the routes name and any numbers, see examples attached and how OAM names the mtb route PWCR.

POSTSCRIPT: It seems to be connected with routes which have neither osmc nor sac_scale. Changing line 1246 to test for sac_scale=hiking|~ makes some routes show.

I have also noticed this, the best I could render is attached (LoMap v3, LoMap v4, OAM). Seems some routes have ref tags and some do not, even when provided in OSM, e.g. NCN routes 1 in this example.

Note that OAM is only showing a single ref tag and seems to pick the ICN EV12 instead over the NCN 1, so highest order/class of route... I really hope LoMap will show a concatenation of all route refs when on the same way, e.g. EV12/1 in this case...

@voldapet

Point 9
The 1:250,000 OS maps do indeed include contours,  see attached screenshot from memory map and here is a link to the OS 250k legend

OS 250k Legend

You cannot view this attachment.

Interestingly 1:100k maps in the UK have pretty much fallen out of favour, they used to popular in the 50s to 70s as 1/2" scale maps. They used to also include contours, and were very useful for cycle touring. There is an interesting article about these maps:

The great lost map scale

Point 8
Something else about surface tags, in OAM they are also provided for the above surface mappings for several other types of ways, like natural=beach/desert/wetland/sand. Making it possible to render pebble beaches and gravel banks differently.

@karlchick
Point 8
Do you want to render a surface type in the map? Or you want to use a surface as fallback if tracktype isn't defined? What surface type you'd required? https://wiki.openstreetmap.org/wiki/Key:surface

Point 9
I'm sorry, but are you really sure that the contours in <Z12 have any practical benefit for hikers/bikers?

Point 12
The `lm_landuse` item should contain a combination of the original `landuse=residential` and the custom areas generated from the building location. IIRC, there is a logic where small areas are removed from the dataset. Frankly, I would prefer to avoid adding `landuse=residential` because of duplication of data. I'll check (later) the simplification factor and also the filtration of small areas...

Point 8
If you want to align with OAM surfaces, that would make our lives as theme creators alot simpler, here are the OAM tag mapping settings:

<osm-tag key='surface' value='paved' equivalent-values='hard' renderable='false' zoom-appear='8' />
<osm-tag key='surface' value='asphalt' equivalent-values='concrete,cement,metal_grid,brick,chipseal,interlock,plastic,granite' renderable='false' zoom-appear='8' />
<osm-tag key='surface' value='compacted' equivalent-values='fine_gravel' renderable='false' zoom-appear='8' />
<osm-tag key='surface' value='smooth_paved' equivalent-values='concrete:plates,concrete:lanes,paving_stones,paving_stones:30,paving_stones:20,bricks,cement,metal,wood' renderable='false' zoom-appear='8' />
<osm-tag key='surface' value='rough_paved' equivalent-values='unhewn_cobblestone,cobblestone,stone,grass_paver,cobblestone:flattened,sett' renderable='false' zoom-appear='8' />
<osm-tag key='surface' value='gravel' equivalent-values='pebblestone,woodchips' renderable='false' zoom-appear='8' />
<osm-tag key='surface' value='raw' equivalent-values='ground,dirt,grass,sand,earth,mud,clay,saltrock,stone,dirt/sand,soil,trail' renderable='false' zoom-appear='8' />
<osm-tag key='surface' value='winter' equivalent-values='ice,snow' renderable='false' />
<osm-tag key='surface' value='unpaved' equivalent-values='unpaved_minor' renderable='false' zoom-appear='8' />

Point 9
I think having the major and then major and medium gradually introduced earlier provides the following benefits:
  1. You can visualise the landscape over a wider area, see how hills/mountains lie with respect to other landscape features like  lakes and roads etc.
  2. The map doesn't suddenly become very blank.
I can understand how this might have been desirable with older phones with limited resources, but most modern phones now easily cope with this in OAM maps.

Point 12
I dispute that landuse=residential is duplication, the lm_landuse tag is not the same ways/shapes. I really would prefer to use landuse=residential instead of lm_landuse since it matches OSM and also matches the other corresponding OSm tagged ways, e.g. schools, grass, parking etc. I find that lm_landuse=residential often cuts across a lot of other ways, or is completely missing for large parts of villages, or includes areas that are not residential.  E.g. see attached which compares LoMap and OAM residential areas (beige areas).

Point 14
By overlaying LoMap over OAM map I noticed a missing building=sports_centre, see attached.

Link to osm item: https://www.openstreetmap.org/#map=18/51.74991/-2.22494

@karlchick
Point 1
- make sense, added
BTW: are there any standard symbols or styles that indicate designation in the UK maps?

Point 2
- added but I'm not sure if tags access_land, public_cycleway, green_lane will be used ...

@voldapet
@Menion
Much appreciate you adding these requests to LoMaps, especially points #1 and #2, when can we expect an updated set of maps with these additions included?

2. What advantages will these latest maps have over OAM ones, particularly if you collaborate in unifying tag mapping etc.?

For me, I see the advantage that LoMap will have over OAM is they will include different tags, e.g. designation (PROW at last!), building=cathedral, horse, and (to be checked, but hopefully) a carry over of the combined network names when they follow the same sections of ways.

Point 13
I have also noticed that LoMaps draws the coastline differently, sometimes pruning parts of the land off. Perhaps LoMap coastline is using some method similar to residential landuse?

The result seems less accurate.

See attached example, bottom is OSM, left is OAM, right is LoMap.

Point 12
Since my theme for v4 is currently targeting OAM I am naturally comparing how OAM abd LoMap v4 maps differ.

I've just remembered that landuse for residential areas is very different in Lomaps, which provides "lm_landuse". This tag uses its own method to establish residential areas, but this results in rather approximate areas, see attached which compares building up residential area using various landuse values (RED) in OAM vs using lm_landuse in LoMap (BLUE).

Can we have the missing landuse=residential tag value?

Point 11
I'm missing a lot of tidal mud areas around some of the British coastline, see attached comparison of OAM vs LoMap v4.

OAM have mapped natural=mud + tidal=yes to be treated the same as wetland=tidalflat.

Can something be done to include mud+tidal in LoMap v4 maps? E.g. treat as wetland=tidalflat, or include natural=mud + tidal=yes...

@karlchick
Point 4
- the LoMaps V3 was generated as 512x512 tiles and zoom or area is really "shifted" in comparison of 256x256 V4 tiles. There were minor changes in `zoom-appear` attribute for some elements. But it was mainly for zoom-levels 9 - 10 (I think). Do you have some specific requests to change the zoom-appear for certain elements?

Point 7, re:Point 4
In OAM most of the natural land features (that can cover large areas) appear from zoom level 12, but in LoMap v4 these are appearing at later zoom levels:

From Z13: beach, cliff, desert, fell, heath, marsh, scree, shingle, valley

From Z14: barerock, earthbank, grassland, sand, rock, wetland

Can these appear from Z12? In fact OAM has sand appear from Z10.

At the moment the map goes very bare when zooming out from Z13/Z14 compared to OAM, see attached.



...and few more requests...

Point 8
Can we include "surface" tag for "highway" and "natural" elements?
I think only tracktype is included, but often only "surface" is set in osm. Being able to differentiate sealed surfaces is very useful to many map users (e.g. using pushchairs, cycles, wheelchairs).


Point 9
Is it possible to include 10m contours? And make contours appear earlier too? E.g. major from Z9, medium from Z10,  minor from Z12.  See attached for comparison of LoMap v4 with OAM at Z12.


Point 10
Can we have "peak_dist" available, this allows the theme to bring peaks into view in sensible order and avoid cluttered view, also to have text size varying based on peaks significance, see attached example, note how LoMap v4 map has all peaks same size font. Note that peak_dist values need to override the default peak appear zoom levels to introduce peaks gradually from Z9 to Z12, see OAM tagmapping file as an example.

@karlchick
please see the latest changes at https://github.com/mapsforge/mapsforge/blob/master/docs/Changelog.md

Looks like we're getting the curved contours back, yay!

Very much appreciate the improvements you are all making to mapsforge.