[OSM-talk] Not attaching polygons to roads
lester at lsces.co.uk
Wed Feb 26 08:34:36 UTC 2014
Clifford Snow wrote:
> When editing, it is time consuming to make changes to one when the two are
> connected. Leaving the two connect can lead to problems if the editor doesn't
> see that they inadvertently moved the other.
Roads are not a special case here ... any way elements that co-exist with other
polygon boundary ways can be equally problematic. Bundling relations into this
adds another layer of problems which make them as difficult to manage as simple
polygons. I have said this before, but it does really need to be looked at a lot
What we need here is to add a 'polygon' which consists of a combination of ways
in much the same way as 'nodes' get combined. This is essentially a relation
rather than an area, but I will repeat the example I've given before.
There is a substantial amount of micro mapping going on now, so for example a
field or property polygon may well have one boundary as a road, two as fences
and the fourth as a hedge. Since the way making up the polygon can't be used for
the boundary elements one ends up having to trace them, creating multiple
elements overlapping. Directly related to this thread, the next step may be to
add 'say' the dry stone wall that in reality divides the field from the road!
Pulling the boundary ways and polygon apart to add the extra detail is currently
painful? If however the 'field' simply consisted of 4 closed ways, one could
postulate that selecting the road element of the field/property would allow the
option to 'parallel' but maintain the other boundary elements to remain with the
separated field rather than having to be broken out individually. Going on from
this editing operation ... the new way will probably have an access point which
could not previously be mapped ON the road, but can now be identified as a link
off the road.
The remaining problems pulling this element apart from the originally linked
components is perhaps 'landuse=agricultural' polygon which may well be
overlaying the field polygon as well! Should the landuse polygon remain using
the road way as it's boundary or should it switch to the separated field way
boundary? That would be allowed by maintaining the landuse detail with one or
other of the new separate ways. I see this as a stepping stone maintaining the
integrity of the larger area polygons that are currently handled as 'relations'
but are more accurately closed way polygons and the same new tools that would
manage fine detail polygons could also be used to maintain the integrity of
larger 'polygons' such as administrative boundaries or larger landuse areas that
are currently created from a large number of conventional polygons?
It is not unusual these days to find several ways all overlaying one another,
and that can probably be simply extracted from the data? They are using the same
nodes but often the real reason for the 'boundary' is not easily identified and
adding that data currently requires an additional way for say 'fence', where
simply adding that tag to a single multiply used way would be a lot more
accurate? There will still be situations where a simple polygon is appropriate,
such as perhaps dropping buildings within a property boundary, and
'semi-detached' properties would have a common element with the boundary
polygon, and additional tools may be required to insert these fine details into
the larger elements, but that simply ensures that the data integrity is
maintained? Deleting or modifying elements that ARE being used by higher level
areas should be easier to identify?
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
More information about the talk