[talk-au] JOSM Scanaerial plugin on NSW LPI layers

Sun Jan 24 21:22:08 UTC 2016

On 23/01/2016 2:36 PM, Nev Wedding wrote:
> thanks
> it appears that the boundaries here sometimes follow a topo contour 
> and that abuts the next defined boundary which seems reasonable.
>> On 23 Jan 2016, at 1:22 PM, Ross <info at 4x4falcon.com 
>> <mailto:info at 4x4falcon.com>> wrote:
>>
>> Looks good to me.
>>
>>
>>
>> On 23/01/16 13:19, Nev Wedding wrote:
>>> Done…Here it is http://www.openstreetmap.org/relation/5892156
>>>
>>>> On 23 Jan 2016, at 12:43 PM, Ross <info at 4x4falcon.com 
>>>> <mailto:info at 4x4falcon.com>> wrote:
>>>>
>>>>
>>>>
>>>> On 23/01/16 12:26, Nev Wedding wrote:
>>>>> I have followed this process for Kooyong State Conservation Area 
>>>>> which has gone well after opening the kms file and have simplified 
>>>>> and added all the tags,
>>>>> …but on trying to upload the final boundary I get this ominous message
>>>>> “
>>>>> You are about to upload data from the layer 'Kooyong.kml'.
>>>>>
>>>>> Sending data from this layer is *strongly discouraged*. If you 
>>>>> continue,
>>>>> it may require you subsequently have to revert your changes, or 
>>>>> force other contributors to.
>>>>>
>>>>> Are you sure you want to continue?
>>>>> “
>>>>>
>>>>> I assume the warning is to dissuade mappers from careless import 
>>>>> of large uncorrected datasets.?
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>> Sooo…, am I ok to continue or is there another reason?  ..I am 
>>>>> on-hold here until I see a reply
>>>>>
>>>>> Nev
>>>>>
>>>>>
>>>> However you may want to upload one, provide a link to it and then 
>>>> see what others think.
>>>>
>>>> Cheers
>>>> Ross
>>>>
>>>>
>>>>>> On 22 Jan 2016, at 11:36 PM, Andrew Davidson 
>>>>>> <u887 at internode.on.net <mailto:u887 at internode.on.net>> wrote:
>>>>>>
>>>>>> You can extract the geometries from the database directly, you 
>>>>>> don't have to scan them. I tried this on three park areas to see 
>>>>>> how much work was involved. The recipe I followed was:
>>>>>>
>>>>>> 1. Use the query tool to find out how many objects have the name 
>>>>>> that you are looking for. You do this with:
>>>>>>
>>>>>> http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Administrative_Boundaries/MapServer/6/query
>>>>>>
>>>>>> with the return format set to html. Names must be in upper case 
>>>>>> and you need to see what object ids are returned. For example if 
>>>>>> you search for Yanununbeyan with:
>>>>>>
>>>>>> http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Administrative_Boundaries/MapServer/6/query?text=YANUNUNBEYAN&geometry=&geometryType=esriGeometryEnvelope&inSR=&spatialRel=esriSpatialRelIntersects&relationParam=&objectIds=&where=&time=&returnCountOnly=false&returnIdsOnly=false&returnGeometry=true&maxAllowableOffset=&outSR=&outFields=&f=html
>>>>>>
>>>>>> You get three different ids (198,208,1131) because there is a 
>>>>>> Yanununbeyan State Conservation Area, Yanununbeyan Nature 
>>>>>> Reserve, and Yanununbeyan National Park. All of which need to be 
>>>>>> tagged differently. Follow the object links to find out what type 
>>>>>> of area they are.
>>>>>>
>>>>>> 2. Having found the object id you need you get the geometry by 
>>>>>> using the query tool and setting the object id, setting the 
>>>>>> output spatial reference to 4326 (WGS84), and changing the output 
>>>>>> format to JSON.
>>>>>>
>>>>>> 3. Save the resulting page, say output.json
>>>>>>
>>>>>> 4. Use ogr2ogr from GDAL to convert the output into something 
>>>>>> JOSM can read:
>>>>>>
>>>>>> ogr2ogr -f "KML" output.json output.kml
>>>>>>
>>>>>> 5. If you have the opendata plugin installed you can open 
>>>>>> output.kml in JOSM.
>>>>>>
>>>>>> 6. Use the simplify way option in JOSM as there are far too many 
>>>>>> points in the resulting kml. I personally thought that the 
>>>>>> default 3m looks OK.
>>>>>>
>>>>>> 7. Tag the ways with an appropriate source:geometry and add a 
>>>>>> note to the effect that the way has been simplified using a max 
>>>>>> error criterion set to whatever you used.
>>>>>>
>>>>>> 8. Now comes the difficult and time consuming bit. You have to 
>>>>>> cut up and conflate the new boundaries with the existing data as 
>>>>>> you merge each new way from the layer you opened the kml in to 
>>>>>> the layer the osm data is in. This is the step where you could 
>>>>>> really make a mess.
At some point I would add
Compare to the LPI base Map for any boundary that is a feature (river, 
stream, road) so that it can be tagged correctly and added as a feature. 
(Not all features are in the OSM data base, so checking against the LPI 
Base Map may be beneficial).

In part 8 .. I simply merge the entire layer. Then check each way.
>>>>>>
>>>>>> I found while doing the few test cases that I had to:
>>>>>>
>>>>>> - Make sure that common boundaries use only one way (which means 
>>>>>> that the more parks, state forests, admin areas, etc that share 
>>>>>> ways the more time consuming it gets)
>>>>>>
>>>>>> - Make judgement calls about if you should use the new boundary 
>>>>>> or keep the existing way where the boundary is something physical 
>>>>>> on the ground like a river bank or coastline. This is why I 
>>>>>> tagged the new ways with source:geometry so other mappers can see 
>>>>>> where they came from.
>>>>>>
>>>>>> - If there are already ways in place, using the replace geometry 
>>>>>> function of the utils2 plugin to try and preserve history.
>>>>>>
>>>>>> The cases I tried as a test were:
>>>>>>
>>>>>> South East Forest National Park:
>>>>>> https://www.openstreetmap.org/relation/5853354
>>>>>>
>>>>>> Murramarang National Park:
>>>>>> https://www.openstreetmap.org/relation/5858067
>>>>>>
>>>>>> Clyde River National Park:
>>>>>> https://www.openstreetmap.org/relation/5857616
>>>>>>
>>>>>> The South East Forest case was a multi-hour mapping marathon as 
>>>>>> the park has a lot of separate sections and shares many 
>>>>>> boundaries with neighbouring state forests and parks. The other 
>>>>>> two were much simpler but Murramarang need more time than Clyde 
>>>>>> River as it has more sections and shares a lot of common ways 
>>>>>> with the coast and various rivers.
>>>>>>
>>>>>> As to the import question it seems to me that there is a tacit 
>>>>>> agreement that tracing the boundaries one at a time is acceptable 
>>>>>> (not sure what the rest of OSM would think about this). Given 
>>>>>> that the biggest problem with an import would be conflating the 
>>>>>> data with the existing, provided that we're carefully 
>>>>>> hand-crafting each park I think we're OK. Does anyone have a 
>>>>>> differing opinion?
>>>>>>
>>>>>>
>>>>>> On Tue, 19 Jan 2016 13:44:12 +1000
>>>>>> Nev Wedding <nwastra at gmail.com> wrote:
>>>>>>
>>>>>>> Should the JOSM Scanaerial plugin be able to scan the LPI NSW
>>>>>>> Administrative Boundaries NPWS Reserve WMS layer and others. I would
>>>>>>> like to zoom in to a section and use the plugin as an initial pass
>>>>>>> instead of manually mouse clicking around the long and winding
>>>>>>> boundary and then refine the result before tagging and uploading.
>>>>>>>
>>>>>>> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Scanaerial
>>>>>>> I am using a mac OS X and there are no instructions for that install
>>>>>>> so I may not have it set up correctly yet, so first up before
>>>>>>> proceeding further, I would like to know if it will help anyway.
>>>>>>>
>>>>>>> I am unfamiliar with tracing shapes other than tediously wandering
>>>>>>> around the boundaries one click at a time.
>>>>>>>
>>>>>>> I played around with Gimp and Inkscape but found that to be quite a
>>>>>>> task too and wasn’t sure if I could use the output in Josm in 
>>>>>>> anyway.
>>>>>>>
>>>>>>> How do you manage such tasks? Are their special mouse tools 
>>>>>>> available?
>>>>>>>
>>>>>>> Is what I am trying to do essentially considered to be part of an
>>>>>>> import and/or the current LPI layers unsuitable for the tracing
>>>>>>> process.
>>>>>>>
>>>>>>> Some links to where to find more info on this topic would be
>>>>>>> appreciated. _______________________________________________
>>>>>>> Talk-au mailing list
>>>>>>> Talk-au at openstreetmap.org
>>>>>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Andrew Davidson <u887 at internode.on.net>
>>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20160125/9fa0c439/attachment-0001.html>