OpenStreetMap
Wolgan River and Capertee Valley Canyon
Posted by Majormax on 28 March 2016 in English. Last updated on 7 April 2016.Have done a lot of work on cliff lines along the Wolgan River and Capertee Valley Canyon.
HELP please - the Wollemi National Park Boundary is no longer showing. FIXED 7 Apr 16
I have added a note. This is a large park and it has just disappeared in the last couple of weeks I believe. I don’t have the skills to fix this.
The boundary is shown on the LPI NSW Base Map which can appear as a layer.
Out of interest this is widely reported to be the second largest canyon (in terms of width) in the world but the map was pretty poor. OSM contours are problematic, I understand that OSM uses NASA’s Shuttle Radar Topography Mission (SRTM) data for contours. The Space Shuttle radar was only sensitive to about 30 metres, so any cliff smaller than 30m will not show on the map. But many of these cliffs are over 200m tall, and some almost 300m tall and they still don’t show up on the contour maps.
So to compensate I have been adding cliff lines and canyon names where they exist.
Discussion
Comment from Glassman on 28 March 2016 at 15:27
I see someone did a fix on Woolemi National Park seven hours ago. Because of the size, it may take a while before it renders.
Comment from Majormax on 28 March 2016 at 21:52
Thanks, it is not rendering yet but hopefully it will. I cannot see how to solve this. The park is so large that OSM will not let me download it with the slippery map. Parts are now rendering incorrectly. I can see that someone has had a go at the boundaries in the last couple of weeks with multiple edits but I am not sure if this has helped.
Comment from Warin61 on 28 March 2016 at 22:44
Cliffs … Can be mapped using the LPI Base Map … I think this is better than trying to use an image or contour lines, they are fairly clear in the Base Map - making mapping easy. I have added a few … but here are lots in there.
The Warba (sp?) Ridge Trail .. I will have to go back and mark that as ‘disused’ as I have found out that NP want it to ‘disappear’ by regrowth. It is still there and some parts won’t regrow for quite some time.
I put the Wollemi NP boundaries in from The LPI Admin boundaries, simplified the ways using JOSM to 3 meters, and combined them with various boundaries for common ways. I’ll have a look at the present configuration and see if there are any errors. Note that using the LPI Admin boundaries is much better (more accurate and less time) than using the Base Map. When I put them in … I was disappointed that they did not render .. but left them for some time. I did alter another mapper about it and they looked at it .. but nothing significant happened. As you say it is a large area. Relation: Wollemi National Park (5901253) .. edited 13 hours ago. Humm no reall change as far as I can see, other than some source entries on way that are not absolutely correct. Other than the deletion of area I have named .. and those names are real, so I have re entered them.
Comment from Warin61 on 28 March 2016 at 23:17
Humm .. nothing I can ‘see’ as an error.
I’ll give it some time (weeks) and see what happens. if it still does not render than I’ll chop up the large area in to several smaller areas to try and isolate the problem, this is not something that is ‘good’ but a work around to find the problem. Once the problem is found and fixed I’d recombine the areas back into one area. Finding the problem will be much simpler with a much smaller area. I think that is a way of working out what is going on?
Comment from Majormax on 28 March 2016 at 23:19
Thanks, I made a minor edit but this is way beyond my skills to fix.
Comment from Majormax on 29 March 2016 at 07:24
I did about 20 overlapping downloads and managed to download the entire boundary, and when I select almost anywhere on the boundary it all “appears” as a pink shaded boundary in JOSM but does not appear on the map. Thanks for your help.
Comment from Warin61 on 31 March 2016 at 00:21
The original boundary I put in would be accurate to within 3 metres .. meaning they should not be moved. Broken into segments - yes, moved no. Some adjacent things have a gap - a legal easement between them - so they should not be combined. Entering the original data is easy - breaking it up into shared ways takes time.
The stuff I saw yesterday in JOSM is correct as far as JOSM can ‘see’. But I did not download all the combined relations. That will take some time - I don’t have that at the moment. Once I do that (some weeks) I’ll then break up the large area into adjacent small areas and see what renders .. where it does not I’ll look in detail for ‘errors’, if I cannot ‘see’ errors then I’ll break up those into smaller bits and so on untill I find out what is happening.. process of elimination.
Comment from Majormax on 31 March 2016 at 00:36
Thanks, if anyone can explain to me what needs to be done or point me in the right direction on the OSM wiki I can have a look but I cannot work out where to even start to solve this problem. I downloaded all of the boundary (which took ages and about 20 separate downloads) and when selected the entire boundary appears to be is selected and also appears to indicate a “Park Boundary”.
I have not made any changes to the park boundary so I am pretty confident that this was me. But I have seen other editors making changes over the past month.
Comment from TheSwavu on 31 March 2016 at 03:10
I don’t think that the main body of the park has ever rendered correctly.
It’s a bit odd because Overpass Turbo is quite able to figure out which bits to colour in:
http://overpass-turbo.eu/s/flP
and JOSM can figure out which bits are inside the boundary but the map rendering software can’t seem to cope. It’s rendering some of the inner ways as if they are on the outside:
https://www.openstreetmap.org/way/393301680 https://www.openstreetmap.org/way/393301767
By the way, if you want to see the rest the ways that are part of a relation but haven’t been downloaded you can right click on it in JOSM and ask to download members. But if you are going to edit any of the members you need to download the surrounding area first otherwise you’ll end up breaking things.
The other thing to be careful of is that ways can be part of more than one relation. So when you moved the park boundary:
https://www.openstreetmap.org/changeset/38131822
you were also moving the boundaries of Upper Nile, Glen Alice and Glen Davis.
Comment from Majormax on 31 March 2016 at 03:32
Thanks very much! Apologies if I broke anything. I have been trying to improve the area around Newnes, Wolgan River Canyon and Capertree Valley etc. Mainly adding cliff lines and creek names where they are well recognised. Sources mainly in Rock Climbing and Canyoning Guide books etc. I was also going to do some fieldwork and GPS traces and pick up the old ruins at the Newnes Shale Oil Refinery. Source for that is old maps.
Comment from Majormax on 31 March 2016 at 03:33
When viewed like this it was definitely rendering correctly a few weeks ago https://www.openstreetmap.org/way/393301767#map=10/-33.0478/150.8052
Comment from Warin61 on 1 April 2016 at 01:25
I have just downloaded the garmin map rendering .. with mapnik typ .. that is rendering correctly. Dated 26/3/16 .. so it was ok some time ago (rendering takes some time so data would have been before that date). http://garmin.openstreetmap.nl/ The rendering on https://www.openstreetmap.org/ is not correct .. this may ‘just’ be a rendering issue there.
Guide books are general copyright … don’t use them to get data unless they are copyright free or you have specific permission in writing. If you do have specific permission then you need to add it to the OSM data somewhere - do a google to find it. You can use the LPI Base map … that does have cliff positions … if not names of clifts, It does have the major creek names, hill tops names and some other names.
Comment from Majormax on 1 April 2016 at 04:15
I am only adding names where they are in very broad public usage, i.e. multiple / typically more than 10 sources, multiple guide books and multiple outdoor companies. Am avoiding anything contentious, i.e. some of the off-the-track canyons.
Comment from TheSwavu on 2 April 2016 at 03:48
OK after much experimenting I have figured out what the problem is.
There are two inner ways that touched the outer way at a single point:
393301633 393301748
It turns out that if you had either of these in the relation (but not both) then it renders OK.
I have “fixed” the problem by putting a half metre gap between the corners. The boundary should start to reappear but it may take a while to clean up the “Renderer Test” left over from trying to figure out what was wrong.
So as expected its a problem with the rendering software used for the main page map.
Comment from Majormax on 2 April 2016 at 07:43
Thank you. It looks beautiful.
https://www.openstreetmap.org/relation/5901253
I was soooo worried that I had screwed it up. I will stick to cliff lines, canyons and creeks :-)
Comment from Warin61 on 3 April 2016 at 10:17
‘We’ all make errors from time to time. Don’t be afraid of making them … it is one of the ways ‘we’ learn. Most of the time I catch mine a day later. Much more important to add new things rather than simply modify old things. Roads, tracks, paths and huts are also ‘missing’ in the area… go for it.
Well spotted TheSwavu … I do wonder if adding all those areas and easements is really worthwhile.. I’d certainly not add them if I were simply tracing off the LPI Base Map. I was wondering if another relation to separate up the ways would have helped.
Comment from Majormax on 3 April 2016 at 11:44
Thank you. I can see that it is now working for Zoom Level 9 I am guessing that it will take a while for it to work for the higher level zoom levels.
Comment from Majormax on 7 April 2016 at 04:50
Fixed !!! Thanks everyone.