<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Well I have roughly follow this
procedure on;<br>
<br>
for my previously entered 'Putty State Forest' relation 5806844 <a
class="relation landuse forest" title="landuse=forest"
href="https://www.openstreetmap.org/relation/5806844"></a><br>
and newly entered 'Wollemi National Park' relation 5901253 <br>
These are large! .. <br>
My past clickathon for the Putty state forest was some 800 nodes
... the data there is now well over the 2,000 mark! Much more
detail and accuracy - at some data cost. <br>
<br>
I got a .kml file from the website direct, thus avoiding the
conversion. <br>
BUT the JOSM simplification did not reduce the number of nodes! I
will have to do some thinking on it and play with it. <br>
<br>
Maybe I'll try just a section .. say way 393301771 and see if I
can reduce its size. <br>
<br>
On 24/01/2016 4:46 PM, Nev Wedding wrote:<br>
</div>
<blockquote
cite="mid:CB4A9BEA-E30C-42D0-BB2A-40216F1944E9@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="">Your work flow using the geometries has worked very
well for me with the LPI data and the last bit regarding the
merging each item separately into the existing OSM data seems
prudent and makes for easier management of the data.</div>
<div class="">Much appreciated</div>
<div class="">Nev </div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 24 Jan 2016, at 9:11 AM, Andrew Davidson <<a
moz-do-not-send="true" href="mailto:u887@internode.on.net"
class=""><a class="moz-txt-link-abbreviated" href="mailto:u887@internode.on.net">u887@internode.on.net</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">The work flow that JOSM wants you to use is to
have your new data in one layer and the existing OSM data
in another and to "merge selection" on individual items.
I'm assuming this is to slow down people just
dump-and-running. I found it useful to use the merge
approach as you can delete the ways from the kml layer as
you do each one and it lets you check that you've
processed each way. <br class="">
<br class="">
<br class="">
<blockquote class=""><br class="">
----- Original Message -----<br class="">
<div style="width:100%;background:rgb(228,228,228);"
class="">
<div style="font-weight:bold;" class="">From:</div>
"Nev Wedding" <<a moz-do-not-send="true"
href="mailto:nwastra@gmail.com" class="">nwastra@gmail.com</a>></div>
<br class="">
<div style="font-weight:bold;" class="">To:</div>
"OSM Australian Talk List" <<a moz-do-not-send="true"
href="mailto:Talk-au@openstreetmap.org" class="">Talk-au@openstreetmap.org</a>><br
class="">
<div style="font-weight:bold;" class="">Cc:</div>
<br class="">
<div style="font-weight:bold;" class="">Sent:</div>
Sat, 23 Jan 2016 12:42:53 +1000<br class="">
<div style="font-weight:bold;" class="">Subject:</div>
Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers<br
class="">
<br class="">
<br class="">
(corrected message….opening the .kml file
<div class="">I have the .kml file and the downloaded
osm data as seperate layers and want to upload the
.kml layers which contains all the updated info)<br
class="">
<div class="">
<br class="">
<div class="">I have followed this process for
Kooyong State Conservation Area which has gone
well after opening the .kml file and have
simplified and added all the tags,
<div class="">…but on trying to upload the final
boundary I get this ominous message<br class="">
“
<div class="">You are about to upload data from
the layer 'Kooyong.kml'.<br class="">
Sending data from this layer is <b class="">strongly
discouraged</b>. If you continue,<br
class="">
it may require you subsequently have to revert
your changes, or force other contributors to.<br
class="">
Are you sure you want to continue? <br
class="">
<div class="">“</div>
<div class=""><br class="">
</div>
<div class="">I assume the warning is to
dissuade mappers from careless import of
large uncorrected datasets.?</div>
<div class=""><br class="">
</div>
<div class="">Sooo…, am I ok to continue or is
there another reason? ..I am on-hold here
until I see a reply</div>
<div class=""><br class="">
</div>
<div class="">Nev </div>
<div class=""><br class="">
</div>
<div class="">
<br class="">
<div class="">
<blockquote class="">
<div class="">On 22 Jan 2016, at 11:36
PM, Andrew Davidson <<a
moz-do-not-send="true"
href="mailto:u887@internode.on.net"
class=""><a class="moz-txt-link-abbreviated" href="mailto:u887@internode.on.net">u887@internode.on.net</a></a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">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:<br
class="">
<br class="">
1. Use the query tool to find out
how many objects have the name that
you are looking for. You do this
with:<br class="">
<br class="">
<a moz-do-not-send="true"
href="http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Administrative_Boundaries/MapServer/6/query"
class="">http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Administrative_Boundaries/MapServer/6/query</a><br
class="">
<br class="">
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:<br class="">
<br class="">
<a moz-do-not-send="true"
href="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"
class="">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</a><br
class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
3. Save the resulting page, say
output.json<br class="">
<br class="">
4. Use ogr2ogr from GDAL to convert
the output into something JOSM can
read:<br class="">
<br class="">
ogr2ogr -f “KML" output.json
output.kml<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<div><br class="">
</div>
other way around works for me … ogr2ogr -f “KML” output.ml
output.son on OS X </div>
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote class="">
<div class="">
<div class="">
<div class="">
<div class="">
<div class="">
<div class="">
<div class="">
<blockquote class="">
<div class="">
<div class=""><br class="">
5. If you have the opendata plugin
installed you can open output.kml in
JOSM.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br
class="">
<br class="">
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. <br
class="">
<br class="">
I found while doing the few test
cases that I had to:<br class="">
<br class="">
- 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)<br class="">
<br class="">
- 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.<br
class="">
<br class="">
- If there are already ways in
place, using the replace geometry
function of the utils2 plugin to try
and preserve history.<br class="">
<br class="">
The cases I tried as a test were:<br
class="">
<br class="">
South East Forest National Park:<br
class="">
<a moz-do-not-send="true"
href="https://www.openstreetmap.org/relation/5853354"
class="">https://www.openstreetmap.org/relation/5853354</a><br
class="">
<br class="">
Murramarang National Park:<br
class="">
<a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/relation/5858067">https://www.openstreetmap.org/relation/5858067</a><br class="">
<br class="">
Clyde River National Park:<br
class="">
<a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/relation/5857616">https://www.openstreetmap.org/relation/5857616</a><br class="">
<br class="">
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.<br class="">
<br class="">
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?<br
class="">
<br class="">
<br class="">
On Tue, 19 Jan 2016 13:44:12 +1000<br
class="">
Nev Wedding
<a class="moz-txt-link-rfc2396E" href="mailto:nwastra@gmail.com"><nwastra@gmail.com></a> wrote:<br
class="">
<br class="">
<blockquote class="">Should the JOSM
Scanaerial plugin be able to scan
the LPI NSW<br class="">
Administrative Boundaries NPWS
Reserve WMS layer and others. I
would<br class="">
like to zoom in to a section and
use the plugin as an initial pass<br
class="">
instead of manually mouse clicking
around the long and winding<br
class="">
boundary and then refine the
result before tagging and
uploading.<br class="">
<br class="">
<a class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Scanaerial">https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Scanaerial</a><span
class="Apple-tab-span"> </span><br
class="">
I am using a mac OS X and there
are no instructions for that
install<br class="">
so I may not have it set up
correctly yet, so first up before<br
class="">
proceeding further, I would like
to know if it will help anyway. <br
class="">
<br class="">
I am unfamiliar with tracing
shapes other than tediously
wandering<br class="">
around the boundaries one click at
a time.<br class="">
<br class="">
I played around with Gimp and
Inkscape but found that to be
quite a<br class="">
task too and wasn’t sure if I
could use the output in Josm in
anyway.<br class="">
<br class="">
How do you manage such tasks? Are
their special mouse tools
available?<br class="">
<br class="">
Is what I am trying to do
essentially considered to be part
of an<br class="">
import and/or the current LPI
layers unsuitable for the tracing<br
class="">
process.<br class="">
<br class="">
Some links to where to find more
info on this topic would be<br
class="">
appreciated.
_______________________________________________<br
class="">
Talk-au mailing list<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:Talk-au@openstreetmap.org">Talk-au@openstreetmap.org</a><br
class="">
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-au">https://lists.openstreetmap.org/listinfo/talk-au</a><br class="">
</blockquote>
<br class="">
<br class="">
-- <br class="">
Andrew Davidson
<a class="moz-txt-link-rfc2396E" href="mailto:u887@internode.on.net"><u887@internode.on.net></a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-au mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-au@openstreetmap.org">Talk-au@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-au">https://lists.openstreetmap.org/listinfo/talk-au</a>
</pre>
</blockquote>
<br>
</body>
</html>