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

[Nev Wedding]

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.
Much appreciated
Nev 

> On 24 Jan 2016, at 9:11 AM, Andrew Davidson  wrote:
> 
> 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. 
> 
> 
> 
> - Original Message -
> From:
> "Nev Wedding" 
> 
> To:
> "OSM Australian Talk List" 
> Cc:
> 
> Sent:
> Sat, 23 Jan 2016 12:42:53 +1000
> Subject:
> Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers
> 
> 
> (corrected message….opening the .kml file
> 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)
> 
> 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, 
> …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.?
> 
> Sooo…, am I ok to continue or is there another reason?  ..I am on-hold here 
> until I see a reply
> 
> Nev 
> 
> 
> On 22 Jan 2016, at 11:36 PM, Andrew Davidson  > 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

other way around works for me …  ogr2ogr -f “KML” output.ml output.son on OS X 
> 
> 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. 
> 
> 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 pa

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

[Andrew Davidson]

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. 

- Original Message -
From: "Nev Wedding" 
To:"OSM Australian Talk List" 
Cc:
Sent:Sat, 23 Jan 2016 12:42:53 +1000
Subject:Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers

 (corrected message….opening the .kml fileI 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)

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, …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.? 
 Sooo…, am I ok to continue or is there another reason?  ..I am
on-hold here until I see a reply 
 Nev  

 On 22 Jan 2016, at 11:36 PM, Andrew Davidson  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
[2]

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
[3]

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. 

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 impo