Forum Replies Created

Viewing 15 posts - 16 through 30 (of 179 total)
  • Author
    Posts
  • in reply to: Voluntary UK #27119
    JohnPercy
    JohnPercy
    Participant

    Minor change to only show survey points on peaks, such as the old UK Ordnance Survey trig posts.
    Two versions for Locus app and all other apps in the zip files attached below.
    Direct link to full resolution key and notes:
    Locus version of key and notes – http://bit.ly/voluntarykey
    Key and notes for other apps – http://bit.ly/voluntary_key

    • This reply was modified 9 months ago by JohnPercy JohnPercy.
    1 user thanked author for this post.
    in reply to: UK Bridleway rendering for bikes #27091
    JohnPercy
    JohnPercy
    Participant

    The reason that at least this part of the Pennine Bridleway does not show as a cycle route or a mtb route is because it is mapped as network = “nhn;nwn”, which I take to be national hiking network and national walking network. It would also need to be mapped as part of a cycle or mtb network.
    As for showing bike access on tracks, I don’t understand Elevate well enough to comment but my Voluntary themes include dashed markers showing access on tracks, which are otherwise uncertain.
    Finally, using designated =”public_bridleway” is UK specific, and it is probably(?) better to work from the access tags.

    in reply to: Voluntary UK #27071
    JohnPercy
    JohnPercy
    Participant

    Apologies for such a quick update but I’ve realised that many of the wilderness huts (bothies) in Scotland are mapped as both “wilderness huts” and “basic_hut” shelters. I’ve now modified the two Voluntary themes to prioritise showing (a) if the hut is private (b) if it is a basic shelter (for example, no fire) (c) if it is a true wilderness hut. I think this conveys the best information and hope it works elsewhere. This update changes only wilderness huts and if you are not interested in them you can skip this update.

    1 user thanked author for this post.
    in reply to: Voluntary UK #27063
    JohnPercy
    JohnPercy
    Participant

    Updated version now available for download.
    Summary: Continued improvement in Mapsforge v 4 theme. Better and more specific displays of mountain huts and shelters, especially with Hiking style. Improvement with display of contours, peaks, tunnels, mini roundabouts, toll roads, national borders and more.
    As before there is one version for Locus and one for other apps.
    Direct link to full resolution key and notes:
    Locus version of key and notes – http://bit.ly/voluntarykey
    Key and notes for other apps – http://bit.ly/voluntary_key

    in reply to: Voluntary UK #26717
    JohnPercy
    JohnPercy
    Participant

    Without stroke-linecap I now get a round end on the zero-length dash at “0” in both the Locus fork and the standard Mapsforge engine in Locus, Orux, and Cruiser for Android. My current phone is a Moto G6 Plus, Android 8.0.0. On my previous phone, a Moto G2, a zero length dash did not “grow” round ends.

    2 users thanked author for this post.
    in reply to: Voluntary UK #26679
    JohnPercy
    JohnPercy
    Participant

    revisions to dashed lines for better compatibility with devices with later Android versions

    Interesting, what’s the issue here?

    This isn’t that easy to explain. You can (for example) get alternating black and white dashes by writing:

    [/crayon]

    Previously I had alternating coloured dots by writing something like:

    [/crayon]

    which used the default rounded end to give a blob centred on 0 and another of a different colour centred on 3.
    This worked fine on my old phone. With the rendering on my new phone, the second line gave a blob centred on 0 as well as one centred on 3. In other words the zero length dash had rounded ends as well as the one of length 0.1. This may be a Locus-specific problem but I had to get rid of this bit of cleverness.

    plus importantly the incorporation of Mapsforge v4 (multilingual) versions of both Voluntary and Velocity.

    You probably mean theme support for the standard mapsforge engine in Locus (which is used for V4+ maps only), as themes are not multilingual ;-).
    At least the Locus reference should be there, as for all other apps there is no connection between map and theme version

    .

    You are of course correct. What I actually had in mind in writing this was Christian’s announcement that this site is changing over to Mapsforge v4 multilingual maps and that these themes are ready for that.
    To unpack further, the Locus package now includes versions of Voluntary and Velocity themes for LoMaps and Mapsforge v3 and v4 maps from this site. The package for other apps includes the Velocity theme for the first time and works on both Mapsforge v3 and v4 maps ,
    (However, these themes are in fact multilingual, as indeed are Elevate and Elements,)

    • This reply was modified 10 months, 2 weeks ago by JohnPercy JohnPercy.
    1 user thanked author for this post.
    in reply to: Voluntary UK #26615
    JohnPercy
    JohnPercy
    Participant

    The Voluntary theme (plus the similar but simpler Velocity theme) have been updated and are available here for download.
    The most significant changes are revisions to dashed lines for better compatibility with devices with later Android versions, improvements with road numbers and names, plus importantly the incorporation of Mapsforge v4 (multilingual) versions of both Voluntary and Velocity.
    Plus, of course, numerous other small tweaks and improvements.

    As before there is one version for Locus and one for other apps.
    Direct link to full resolution key and notes:
    Locus version of key and notes – http://bit.ly/voluntarykey
    Key and notes for other apps – http://bit.ly/voluntary_key

    1 user thanked author for this post.
    in reply to: OS contours for Great Britain OpenAndroMap? #26023
    JohnPercy
    JohnPercy
    Participant

    OK, So if I decide to use 1″ in UK I will use SRTMV3

    What will you do about the Shetlands?

    1 user thanked author for this post.
    in reply to: OS contours for Great Britain OpenAndroMap? #26012
    JohnPercy
    JohnPercy
    Participant

    I like the increased detail on the Scotland map which looks very helpful to me. However I’m not familiar enough with the area to tell if it’s giving spurious detail..

    As for the OS OpenMaps: IMHO This is pure OS Landranger Raster – clear to be seen when I look at the area round the Storr. The cliffs/crags are Landranger, the forest at the base is not part of OSM but 100% Landranger (I have my old landranger map at hand and I know that the forrest exists cause I walked through several times)

    I’m not quite sure what you are saying here.
    a) Certainly the cliffs and crags come from OS Opendata. I think the folks at the Hug say so somewhere.
    b) The forest at the foot of the Storr appears to come from OS data but woods and forests elsewhere seem to be sourced from OSM data. In my local area of Northampton, Waymaps show woods from OSM data that do not appear on OS maps. As far as I can see Waymaps blend OS and OSM data. I think they are an excellent representation, btw.
    As already said, a lot of OS data is available for free download in both raster and vector formats from https://www.ordnancesurvey.co.uk/opendatadownload/products.html — this includes 10m vertical interval heights based on 50m sampling as grid or contours (vector). I believe however Opendata does not include footpaths as OS doesn’t hold the copyright to them,

    2 users thanked author for this post.
    in reply to: OS contours for Great Britain OpenAndroMap? #25986
    JohnPercy
    JohnPercy
    Participant

    I don’t find the 20m lines sufficient and have had to swap to OS maps to see the slopes when walking recently.
    i, too, would support 10m contour lines appearing at higher zooms. Would that reduce the amount of data packed into the maps themselves?
    However, there are two different issues being discussed here: contour spacing and resolution. Increasing the resolution from 3″ to 1″ would result in 9x the data unless there is some clever data packing. And I suspect that without increasing the resolution, reducing the contour spacing would result in more unsatisfactory artefacts.

    2 users thanked author for this post.
    in reply to: Cycle lanes in oneway street #25623
    JohnPercy
    JohnPercy
    Participant

    My scheme is designed in effect to use nested rules and test for oneway=yes.
    IF oneway:bicycle=no AND oneway=yes THEN two-colour blue/grey doubleheaded arrow
    IF cyclelane is on one side only THEN IF oneway:bicycle=no AND oneway=no|~ THEN blue doubleheaded arrow

    • This reply was modified 1 year, 2 months ago by JohnPercy JohnPercy.
    in reply to: Cycle lanes in oneway street #25571
    JohnPercy
    JohnPercy
    Participant

    when oneway:bicycle=no would be used, the two way road the cycleway is part of would be falsely rendered as oneway.

    I’m not sure of the reasoning behind this statement, Won’t the rendering depend on the theme?
    I agree however that specifying that oneway tag applies only to the bike lane by using (eg) cycleway:right:oneway=no avoids this potential ambiguity.

    in reply to: Cycle lanes in oneway street #25461
    JohnPercy
    JohnPercy
    Participant

    In terms of the map themes, I think the two headed arrows should be added to cycle themes where there is potential confusion as to what direction cycles are allowed in. This basically applies to contraflow cycle tracks or lanes, which may occur in one-way streets or if a two-way cycle.lane/track is shown on one side of a street.

    My two previous points are described in https://www.openandromaps.org/en/oam-forums/topic/cycle-tracks-from-1-dec-2016/page/2/#post-15492 and are to do with the tag-transform. .
    (a) At line 871 the test:

    [/crayon]

    is not needed as the cycle track/lane at one side of a two-way road may usefully be tagged as not oneway.
    (b) At (eg) line 963 the test

    [/crayon]

    works if BOTH sides of the road have cycle lanes in the wrong direction, which is probably unlikely. A further set of transforms are needed for the more likely case where only ONE side of the road has a cycle lane/track in the wrong direction. In such cases we additionally need to set oneway:bicycle to no.

    [/crayon]

    However since I wrote this in the post referred to above, the Wiki recommendation has changed to (eg) cycleway:right=lane + cycleway:right:oneway=no which is a further and unwelcome complication.

    1 user thanked author for this post.
    in reply to: Cycle lanes in oneway street #25449
    JohnPercy
    JohnPercy
    Participant

    Not entirely, but partly.
    In the first case (contraflow cycle traffic in a one way street), I can successfully show the modified arrow in cycling styles in many cases. It depends however on the exact tags used. From recollection, if the lane or track is specified as opposite_lane or opposite_track, then the tag mapping does not work correctly as I have pointed out before.
    In the second case (two way cycle traffic on one side of the street), is exactly as I have mentioned before and the tag mapping does not pick this up.

    1 user thanked author for this post.
    in reply to: Cycle lanes in oneway street #25429
    JohnPercy
    JohnPercy
    Participant

    – I don’t show oneway arrows on cycleway lanes/tracks in general, is this necessary?
    Tobias

    My view is that special arrows are required where the cycle track or way is contraflow, so either
    – cycles allowed in reverse direction in a street that is one-way for other traffic
    – a two way cycle track on one side of the road where track that would appear to be only one-way.
    I believe that each of these cases require a special double-headed arrow where these cycle tracks or lanes are displayed.

    1 user thanked author for this post.
Viewing 15 posts - 16 through 30 (of 179 total)