Well I have roughly follow this procedure on;
for my previously entered 'Putty State Forest' relation 5806844
<https://www.openstreetmap.org/relation/5806844>
and newly entered 'Wollemi National Park' relation 5901253
These are large! ..
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.
I got a .kml file from the website direct, thus avoiding the conversion.
BUT the JOSM simplification did not reduce the number of nodes! I will
have to do some thinking on it and play with it.
Maybe I'll try just a section .. say way 393301771 and see if I can
reduce its size.
On 24/01/2016 4:46 PM, Nev Wedding wrote:
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 <[email protected]
<mailto:[email protected]>> 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" <[email protected] <mailto:[email protected]>>
To:
"OSM Australian Talk List" <[email protected]
<mailto:[email protected]>>
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
<[email protected] <mailto:[email protected]>> 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 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 <[email protected]> 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
[email protected]
https://lists.openstreetmap.org/listinfo/talk-au
--
Andrew Davidson <[email protected]>
_______________________________________________
Talk-au mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-au
_______________________________________________
Talk-au mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-au
