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

[Ross]

On 25/01/16 20:36, Ian Sergeant wrote:

On 25 January 2016 at 19:38, Ross  wrote:


And the guess does not get fixed there are many locations where roads are
still on admin boundaries but the boundary is no long there (changes to
boundaries) or the road has moved but  nobody comes back to correct it.


To me this seems like a more general problem.  Mapping bare areas gets
done, but when a road moves or a boundary moves then they don't tend
to get noticed as much.  After the ABS2006 data was imported, it
wasn't linked to features, but quickly fell out of date as suburbs
changed and were added.

Ian.

There was plenty of linking to roads/rivers/railways with this import.

They are still to be found in the database.

Cheers
Ross


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Ross]

On 25/01/16 14:31, Ian Sergeant wrote:

On 25 January 2016 at 14:48, Ross  wrote


How do you know it is the physical feature?
Just because it follows approximately the feature does not mean it is.  When 
originally gazetted the physical feature may have been located differently 
(roads, railways realigned, rivers making new paths)  Don't automatically 
assume that the feature is still in the same place without looking at the 
imagery or physical survey.  Don't assume that the boundary changes to the new 
position of the road, etc.

There are numerous ways you can 'know' something.  Legislation
(including regulations, court judgement) is often the primary thing
involved here.  I'm not calling on people to guess, but we should bear
in mind that OSM is an evolution, and we have often used these
features in evolving the map until we locate or have free access to a
definitive source.

So you check each and every time for a source that shows the boundary 
you are working on is the physical feature and then provide the source 
in a tag?


As you suggest most people will just guess and a lot of the time it may 
be so but it still causes issues with later changes and corrupting the 
original data (such as the NSW reserves boundaries).


And the guess does not get fixed there are many locations where roads 
are still on admin boundaries but the boundary is no long there (changes 
to boundaries) or the road has moved but  nobody comes back to correct it.



But the border has not changed the river might have but there is no change to 
the border from when it was first surveyed/gazetted.  The border is the line as 
when gazetted, not as where the riverbank is now.

I think you're wrong.  The border has been defined by High Court
Judgement as including accretions and erosion.  Including landslip
such as in the Ward case.

Of course, where the river has fundamentally changed course, the
original course remains the boundary.  But gradual erosion actually
changes the border.

Ian.


But not in all cases as your previous post suggested and the location I 
pointed out shows.


Cheers
Ross


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Ian Sergeant]

On 25 January 2016 at 19:38, Ross  wrote:

> And the guess does not get fixed there are many locations where roads are
> still on admin boundaries but the boundary is no long there (changes to
> boundaries) or the road has moved but  nobody comes back to correct it.


To me this seems like a more general problem.  Mapping bare areas gets
done, but when a road moves or a boundary moves then they don't tend
to get noticed as much.  After the ABS2006 data was imported, it
wasn't linked to features, but quickly fell out of date as suburbs
changed and were added.

Ian.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Andrew Davidson]

Yeap,  that's why my recipe had the json to kml step.  If you pull the kmz 
directly you have to strip off the ele tags and you also need to run the JOSM 
validator on the layer when you open it because every node seems to be 
duplicated.  Not only that, if there is more than one park that matches your 
query then you get them all and there is no indication of which is which. 

On 25 Jan 2016 16:01, Warin <61sundow...@gmail.com> wrote:
>
> On 25/01/2016 3:44 PM, Warin wrote:
>
> Well I have roughly follow this procedure on;
>
> for my previously entered 'Putty State Forest' 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.  
>
> Arr found the problem.
> JOSM simplify will not touch any node with an elevation. The .klm files all 
> have elevations (0!) .. removing the elevation tag on the nodes is easy 
> find type=node .. and then delete the elevation tag .. does it for all of 
> them. 
>>
>>
>> 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 <u...@internode.on.net> 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" <nwas...@gmail.com>
>>>
>>> To:
>>> "OSM Australian Talk List" <Talk-au@openstreetmap.org>
>>> 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 <u...@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:

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

[Ian Sergeant]

On 25 January 2016 at 14:48, Ross  wrote

> How do you know it is the physical feature?

> Just because it follows approximately the feature does not mean it is.  When 
> originally gazetted the physical feature may have been located differently 
> (roads, railways realigned, rivers making new paths)  Don't automatically 
> assume that the feature is still in the same place without looking at the 
> imagery or physical survey.  Don't assume that the boundary changes to the 
> new position of the road, etc.

There are numerous ways you can 'know' something.  Legislation
(including regulations, court judgement) is often the primary thing
involved here.  I'm not calling on people to guess, but we should bear
in mind that OSM is an evolution, and we have often used these
features in evolving the map until we locate or have free access to a
definitive source.

> But the border has not changed the river might have but there is no change to 
> the border from when it was first surveyed/gazetted.  The border is the line 
> as when gazetted, not as where the riverbank is now.

I think you're wrong.  The border has been defined by High Court
Judgement as including accretions and erosion.  Including landslip
such as in the Ward case.

Of course, where the river has fundamentally changed course, the
original course remains the boundary.  But gradual erosion actually
changes the border.

Ian.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Ross]

In Australia all property boundaries are not the centreline of the road 
there is always a road reserve as Andrew pointed out.  So simple do not 
make boundaries the road.


Likewise be very careful assuming the boundary is the centreline of a 
river.  eg the NSW Victoria border along the Murray River.  If you don't 
know it's actually the southern river bank.


Realistically with these boundaries if you move them to align with any 
physical  feature then you are corrupting the data.  Also  if you make 
the boundary part of a physical feature without checking the full length 
of the boundary then you are corrupting the data again.


It's really much cleaner and easier to just import/trace the boundary.  
If this shows up where a road/railway/whatever should be then trace it 
from the imagery as a separate way and tag it appropriately.


Cheers
Ross


On 25/01/16 08:53, Ian Sergeant wrote:
On 25 January 2016 at 09:29, Andrew Davidson > wrote:


 The boundaries of the parks and forests are not going to be roads
as they consist of a number of property lots that get declared for
that purpose. Property boundaries don't run down the middle of the
road, they'll be offset (at times the existing road isn't within
the road reserve anymore).  Property boundaries can be rivers
(bank or thalweg depending) or the MHWM (also known as the "coast"
in OSM).


If OSM was only a colouring-in exercise, then this would be 
straightforward.


However, roads in OSM are a vector representation of the road.  And is 
is very common for the boundary of an area to be the road itself, that 
is there is no small gap between the area and the road.


When the boundary of an area *is* the road, then I think it's entirely 
correct to include the ways that make up the road in the multi-poly 
that defines the area. Even though the vector nature of OSM slightly 
expands features that are 2 dimensional when they are adjacent to 
features that are 1 dimensional. The data is correct.


Of course, if the boundary isn't defined by the road, but just happens 
to be close to it, then that's different.


Ian.


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Warin]

On 25/01/2016 3:44 PM, Warin wrote:

Well I have roughly follow this procedure on;

for my previously entered 'Putty State Forest' 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.


Arr found the problem.
JOSM simplify will not touch any node with an elevation. The .klm files 
all have elevations (0!) .. removing the elevation tag on the nodes is easy
find type=node .. and then delete the elevation tag .. does it for all 
of them.


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 <u...@internode.on.net> 
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" <nwas...@gmail.com <mailto:nwas...@gmail.com>>

To:
"OSM Australian Talk List" <Talk-au@openstreetmap.org
<mailto:Talk-au@openstreetmap.org>>
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
<u...@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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml

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 optio

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

[Warin]

On 25/01/2016 12:58 PM, Ian Sergeant wrote:

Hi,

The road is a vector, representing the road.  It does not represent 
the road centreline. It has properties, such as width and lanes, and 
sidewalks.


If the boundary *is* the physical feature, then it is not corrupting 
the data by making it align with the physical feature. If the boundary 
is not the physical feature, then don't align it.


The NSW/Victorian border has been done entirely along the riverbank.  
Much of it by me and a few others after you guys decided to take your 
bat & ball.  So, I don't believe this is actually an issue.  Do you 
have any examples of where this is a concern?


Tracing the actual border between NSW/Victorian border was actually 
quite interesting.  You have the gradual accretion or divulsion to 
consider, and it is clear the LPI data is not necessarily aligned with 
what is current.  Most of the border that I've traced I'd consider to 
be more current than the LPI data, and I'd certainly want to thrash it 
out before someone started replacing it with yet another import. We've 
had so much ugliness in the past with these imported data sets with no 
follow up.


This issue doesn't come up too much with property boundaries - that 
are defined independent of the roads.  It does come up with rivers and 
coastline, and other areas where the physical feature is what is the 
boundary.


There are places ..(when I came across one again I'll post a link) where 
the road goes down the centre of the boundaries between two properties.
Being a lazy Ozie I would prefer to tag the road and use that as the 
boundary! Save a lot of work, the meaning is fairly clear .. and has 
very few impacts on actual use of the  map rather than legal niceties.


However ... with this data being translated across 'we' get lots of 
nodes and detail... with very little 'work'. So it does make it 
practical to have the road separate from the boundary.
But if I were entering each node by hand .. you would have the road 
forming the boundary (as tagged by me). Someone with more time can do 
that detail .. probably less than 10 meters in it.

Ian.


On 25 January 2016 at 11:09, Ross > wrote:


In Australia all property boundaries are not the centreline of the
road there is always a road reserve as Andrew pointed out.  So
simple do not make boundaries the road.



Some roads are 'easements' through the property... 
http://www.findlaw.com.au/faqs/2296/what-is-an-easement.aspx
I tend not to map those .. the presence of the road may indicate it .. 
or not as the case may be. Again this is by hand.


Consider that the amount of things to map is vast, these details can 
treble it making getting placing these details on the map a much longer 
process.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Ross]

On 25/01/16 11:58, Ian Sergeant wrote:

Hi,

The road is a vector, representing the road.  It does not represent 
the road centreline. It has properties, such as width and lanes, and 
sidewalks.


If the boundary *is* the physical feature, then it is not corrupting 
the data by making it align with the physical feature. If the boundary 
is not the physical feature, then don't align it.


How do you know it is the physical feature?

Just because it follows approximately the feature does not mean it is.  
When originally gazetted the physical feature may have been located 
differently (roads, railways realigned, rivers making new paths)  Don't 
automatically assume that the feature is still in the same place without 
looking at the imagery or physical survey.  Don't assume that the 
boundary changes to the new position of the road, etc.





The NSW/Victorian border has been done entirely along the riverbank.  
Much of it by me and a few others after you guys decided to take your 
bat & ball.  So, I don't believe this is actually an issue.  Do you 
have any examples of where this is a concern?



No.  It was just an example of were an incorrect assumption had been made.

Tracing the actual border between NSW/Victorian border was actually 
quite interesting.  You have the gradual accretion or divulsion to 
consider, and it is clear the LPI data is not necessarily aligned with 
what is current.  Most of the border that I've traced I'd consider to 
be more current than the LPI data, and I'd certainly want to thrash it 
out before someone started replacing it with yet another import. We've 
had so much ugliness in the past with these imported data sets with no 
follow up.


But the border has not changed the river might have but there is no 
change to the border from when it was first surveyed/gazetted.  The 
border is the line as when gazetted, not as where the riverbank is now.


An example of this is here:

https://www.openstreetmap.org/#map=17/-36.19879/148.03658

Open it in josm then open the nsw imagery, and the nsw basemap and you 
can see where the river was originally and where the border runs.



Cheers
Ross

This issue doesn't come up too much with property boundaries - that 
are defined independent of the roads.  It does come up with rivers and 
coastline, and other areas where the physical feature is what is the 
boundary.



Ian.



On 25 January 2016 at 11:09, Ross > wrote:


In Australia all property boundaries are not the centreline of the
road there is always a road reserve as Andrew pointed out.  So
simple do not make boundaries the road.

Likewise be very careful assuming the boundary is the centreline
of a river.  eg the NSW Victoria border along the Murray River. 
If you don't know it's actually the southern river bank.


Realistically with these boundaries if you move them to align with
any physical  feature then you are corrupting the data.  Also  if
you make the boundary part of a physical feature without checking
the full length of the boundary then you are corrupting the data
again.

It's really much cleaner and easier to just import/trace the
boundary.  If this shows up where a road/railway/whatever should
be then trace it from the imagery as a separate way and tag it
appropriately.

Cheers
Ross



On 25/01/16 08:53, Ian Sergeant wrote:

On 25 January 2016 at 09:29, Andrew Davidson
> wrote:

 The boundaries of the parks and forests are not going to be
roads as they consist of a number of property lots that get
declared for that purpose. Property boundaries don't run down
the middle of the road, they'll be offset (at times the
existing road isn't within the road reserve anymore). 
Property boundaries can be rivers (bank or thalweg depending)

or the MHWM (also known as the "coast" in OSM).


If OSM was only a colouring-in exercise, then this would be
straightforward.

However, roads in OSM are a vector representation of the road. 
And is is very common for the boundary of an area to be the road

itself, that is there is no small gap between the area and the road.

When the boundary of an area *is* the road, then I think it's
entirely correct to include the ways that make up the road in the
multi-poly that defines the area. Even though the vector nature
of OSM slightly expands features that are 2 dimensional when they
are adjacent to features that are 1 dimensional. The data is correct.

Of course, if the boundary isn't defined by the road, but just
happens to be close to it, then that's different.

Ian.


___
Talk-au mailing list
Talk-au@openstreetmap.org  
https://lists.openstreetmap.org/listinfo/talk-au

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

[Warin]

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 <u...@internode.on.net 
<mailto:u...@internode.on.net>> 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" <nwas...@gmail.com <mailto:nwas...@gmail.com>>

To:
"OSM Australian Talk List" <Talk-au@openstreetmap.org
<mailto:Talk-au@openstreetmap.org>>
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
<u...@internode.on.net <mailto:u...@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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml

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 

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

[Andrew Harvey]

On 25 January 2016 at 15:31, Ian Sergeant  wrote:
>> But the border has not changed the river might have but there is no change 
>> to the border from when it was first surveyed/gazetted.  The border is the 
>> line as when gazetted, not as where the riverbank is now.
>
> I think you're wrong.  The border has been defined by High Court
> Judgement as including accretions and erosion.  Including landslip
> such as in the Ward case.
>
> Of course, where the river has fundamentally changed course, the
> original course remains the boundary.  But gradual erosion actually
> changes the border.

Agreed, but this is only for natural features, not man made roads or
rail ways. I think in these cases it makes sense to share the boundary
(or better yet use a multiploygon relation where the river way is just
a member of the protected area relation).

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Ian Sergeant]

On 25 January 2016 at 15:45, Andrew Harvey  wrote:

> I think in these cases it makes sense to share the boundary
> (or better yet use a multiploygon relation where the river way is just
> a member of the protected area relation).

I always use multipolys for this.  Multi-tagging or ways sharing
consecutive nodes becomes quickly unmanageable in the OSM toolset..

Ian.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Andrew Davidson]

 The boundaries of the parks and forests are not going to be roads as
they consist of a number of property lots that get declared for that
purpose. Property boundaries don't run down the middle of the road,
they'll be offset (at times the existing road isn't within the road
reserve anymore).  Property boundaries can be rivers (bank or thalweg
depending) or the MHWM (also known as the "coast" in OSM). 

- Original Message -
From: "Warin" 
To:
Cc:
Sent:Mon, 25 Jan 2016 08:22:08 +1100
Subject:Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers

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 < [1]i...@4x4falcon.com [2]> wrote:

  Looks good to me.

On 23/01/16 13:19, Nev Wedding wrote:
  Done…Here it is   http://www.openstreetmap.org/relation/5892156
[3]  
  On 23 Jan 2016, at 12:43 PM, Ross  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 <
[5]u...@internode.on.net [6]> 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
[7]

 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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml
[8]

 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 t

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

[Warin]

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 > 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 > 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 
> 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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml

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 

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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml
[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 import question it seems to me that there is a tacit
agreement that tracing the boundaries one at a time is accepta

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 <u...@internode.on.net> 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" <nwas...@gmail.com>
> 
> To:
> "OSM Australian Talk List" <Talk-au@openstreetmap.org>
> 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 <u...@internode.on.net 
> <mailto:u...@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
>  
> <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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml
>  
> <http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Administrative_Boundaries/MapServer/6/query?text=YANUNUNBEYAN==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml>
> 
> 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 co

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

[Ross]

On 22/01/16 23:36, Andrew Davidson wrote:

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)
Why?  There is no reason to have only one way for a boundary where a 
park and state forest (for example) join.  The two ways can share the 
same nodes but keeping the two separate makes later editing correction 
so much easier.  I'd also be very careful joining to admin boundarys 
without confirming with the basemap that the admin boundary is correct.



- 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.


I don't think this is a good idea and your actually corrupting the 
data.  The boundaries are separate to what is on the ground.  I've see 
many where the boundary was where the original river was but over time 
the river has moved and the boundary is no longer where the river is.  
Likewise roads that have been rerouted.



- 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.
Did you compare the boundary with the coastline on the imagery? It's 
probably not the same and therefore should not be joined to the coastline.


Cheers
Ross


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Andrew Davidson]

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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml

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 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  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. 

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

[Nev Wedding]

Done…Here it is   http://www.openstreetmap.org/relation/5892156 


> On 23 Jan 2016, at 12:43 PM, Ross  > 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 >> > 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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml
>>>  
>>> 
>>> 
>>> 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 
>>> 

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

[Ross]

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 > 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 > 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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml

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 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 

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

[Nev Wedding]

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  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 >> > 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  > 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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml
>  
> 
> 
> 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 

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

[Nev Wedding]

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.?

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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml
> 
> 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 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  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 

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

[Ross]

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 > 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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml

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 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  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

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

[Nev Wedding]

(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==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml
> 
> 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 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 
> 

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

[FlashKiwi]

All the data presented in the WMS services is available from the LPI as vector 
data under a CC3.0. The catch is that there is a 'supply fee' ($3600 from 
memory)..I will check with my contact at LPI on the current situation. QLD, 
VIC, SA and TAS provide similar administrative data (park boundaries etc) under 
similar licence for direct download at no cost. 
As a side note it is frustrating that govt. departments talk about open data 
and yet provide WMS services (webstacles) for vector data...

On Tuesday, 19 January 2016 3:01 PM, Nev Wedding  wrote:
 

 That’s great news, thanks
Nev

> On 19 Jan 2016, at 2:23 PM, Ross  wrote:
> 
> scanaerial or tracer2 plugins both work with the Reserves WMS layer.
> 
> As to setting it up on OSX I'd suggest it's similar to the linux setup as the 
> operating systems are similar, just need to put the config file in the 
> appropriate place and have python installed.
> 
> Cheers
> Ross
> 
> 
> On 19/01/16 13:44, Nev Wedding 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@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


  ___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Nev Wedding]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Ross]

scanaerial or tracer2 plugins both work with the Reserves WMS layer.

As to setting it up on OSX I'd suggest it's similar to the linux setup 
as the operating systems are similar, just need to put the config file 
in the appropriate place and have python installed.


Cheers
Ross


On 19/01/16 13:44, Nev Wedding 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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au



___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Nev Wedding]

That’s great news, thanks
Nev

> On 19 Jan 2016, at 2:23 PM, Ross  wrote:
> 
> scanaerial or tracer2 plugins both work with the Reserves WMS layer.
> 
> As to setting it up on OSX I'd suggest it's similar to the linux setup as the 
> operating systems are similar, just need to put the config file in the 
> appropriate place and have python installed.
> 
> Cheers
> Ross
> 
> 
> On 19/01/16 13:44, Nev Wedding 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@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au