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 <i...@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 <u...@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@openstreetmap.orghttps://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
