[Tagging] Layers (was Eruvs etc.)

[Minh Nguyen]

Vào lúc 18:05 2022-09-06, Kevin Kenny đã viết:
> On Tue, Sep 6, 2022 at 5:51 PM Mike Thompson 
> <miketho16 at gmail.com 
> <mailto:miketho16 at gmail.com>> wrote:
> 
>     But some nodes in the "highway layer" should be shared with the
>     "boundary layer", such as when a highway enters into a different
>     jurisdiction and gets a different name, max speed, etc. Also, in
>     some cases the centerline of the highway is legally the boundary
>     between two jurisdictions, and in that case all the nodes in the
>     highway should be shared with the applicable boundary .
> 
> 
> You have to be careful with that. Moving the highway will likely NOT 
> move the property lines that follow the boundary, and certainly will not 
> do so without compensating the landowner who's lost property.  When 
> natural features move, the law gets complicated, because accretion, 
> erosion, avulsion, reliction, and so on all are distinct cases in the law.

The considerations are different for boundaries that follow natural 
features versus elements of the built environment. In some regions, it's 
quite normal for a more substantial municipal boundary to be defined 
literally in terms of a preexisting road centerline. [1] In most the 
cases I'm aware of, it would be quite a big deal to move either the road 
or the boundary, so I'm not very concerned about such changes. I care 
more about being able to express the relationship between the two at the 
present time. There's a difference between "X is meant to follow the 
current Y" and "X follows the current Y by coincidence".

As the admin_level=* value increases, the stakes decrease. Some cities 
formally define (and signpost) neighborhood boundaries in terms of fixed 
objects and don't bother to define them more precisely than to say 
such-and-such road. A misaligned boundary could mislead others into 
thinking the boundary isn't quite meant to follow the road. If the 
practical centerline that gets mapped in OSM shifts within the right of 
way, for example due to a road diet, matters of compensation don't 
necessarily come into play, but a neighborhood-wide speed limit could be 
relevant.

> Example:   The boundaries around 
> https://www.openstreetmap.org/relation/7393864#map=16/42.8584/-74.2734 
> <https://www.openstreetmap.org/relation/7393864#map=16/42.8584/-74.2734> 
> are not sloppy or inconsiderate mapping.  The river changed course, The 
> boundaries did not.
> You see the same problem writ large at 
> https://www.openstreetmap.org/#map=13/37.9236/-89.9175 
> <https://www.openstreetmap.org/#map=13/37.9236/-89.9175> - where the 
> state line follows the former course of the river. There's a town in 
> Illinois on the Missouri side of the river.
> 
> The New York City law that establishes the boundary between Manhattan 
> and Brooklyn defines it in terms of the bulkhead line of the East 
> River.  It's well established, though, that the law is to be interpreted 
> as 'the bulkhead line as it stood in 1898, when New York and Brooklyn 
> consolidated'  In particular, the construction of the Gowanus terminal 
> in 1922 https://www.openstreetmap.org/#map=16/40.6921/-74.0061 
> <https://www.openstreetmap.org/#map=16/40.6921/-74.0061> did NOT move 
> the line between the boroughs. (I had to go in and fix that, because an 
> overzealous mapper 'cleaned it up' and conflated it with the current 
> shoreline.)

I've been in this situation many times and have written about them on 
the wiki to avoid having to repeat myself. [2] However, the lesson I 
draw is not that things shouldn't be connected to each other explicitly, 
but rather that mappers should be mindful about how existing data came 
to be. Even ignoring the issue of boundary alignment, there are many 
boundaries that don't make a ton of logical sense, so we have to be 
vigilant about mappers naïvely oversimplifying them. [3]

> I try hard to patch up boundary inconsistencies using the best available 
> data - ideally by fieldwork. 
> https://www.openstreetmap.org/relation/6304865 
> <https://www.openstreetmap.org/relation/6304865> is a case where I have 
> two supposedly authoritative data sources that simply disagree.  Because 
> the error was unusually large for authoritative sources (30 m or so), I 
> actually climbed into that area - and found cairns at both corners! I 
> left the inconsistent boundaries as 'beyond my pay grade." On the other 
> hand, I made substantial adjustments to the town line up on the ridge. 
> In any case, few people - including the respective landowners - care 
> where the precise boundary is between the state land and the New York 
> City water supply land, and the conditions in those mountains would make 
> a better survey inordinately expensive and dangerous.
> 
> Often the explanation for messy and inconsistent boundaries is that we 
> inhabit a messy and inconsistent world, as hard it is for some mappers 
> to believe.

The distinctions I mentioned above are an extra level of rigor that 
mappers can choose to apply or not. I'm not saying we should require 
boundary mappers to spend time looking at legal records to record a 
boundary they see on the ground via a sign. But requiring highways and 
boundaries to be separate, even if only by convention, means mappers 
cannot achieve this level of rigor even if they know what they're doing, 
care about the craft, and can corroborate their work.

The messiness cuts both ways, which is why the data model needs to be 
flexible enough to accommodate both strong and weak relationships 
between boundaries and physical objects.

[1] In many cases, one of the jurisdictions has an easement to maintain 
the entire roadway, irrespective of the survey markers embedded in the 
roadway. But mapping these easements is even more micro and less 
verifiable than mapping cadastral boundaries.
[2] 
<https://wiki.openstreetmap.org/wiki/Ohio_River#State_lines_do_not_follow_the_Ohio_River%27s_present-day_thalweg.>
[3] 
<https://lists.openstreetmap.org/pipermail/talk-us/2019-January/019187.html>

-- 
minh at nguyen.cincinnati.oh.us