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

Ian Sergeant inas66+osm at gmail.com
Mon Jan 25 01:58:36 UTC 2016


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.

Ian.


On 25 January 2016 at 11:09, Ross <info at 4x4falcon.com> 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 <u887 at internode.on.net>
> 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 listTalk-au at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
>
>
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20160125/04bb422e/attachment.html>


More information about the Talk-au mailing list