[Talk-us-massachusetts] Talk-us-massachusetts Digest, Vol 45, Issue 2
Yury Yatsynovich
yury.yatsynovich at gmail.com
Wed Jun 3 12:09:15 UTC 2020
Greetings!
I was including rivers only in those sections of boundaries where MassGIS
explicitly indicates that the boundaries go along the rivers. I also
replace rivers' geometry with that of a boundary, if a boundary looks more
precise. I skipped some cases where the river's stream has been recently
modified due to construction (e.g. near exits 11 on I-95) as one needs to
double-check if towns' borders were adjusted in line with the river.
All towns' boundaries are mapped as relations, so what's wrong if some
rivers are included in these relations especially if the laws explicitly
say that rivers are parts of these relations? Shouldn't the map be accurate
and show where rivers&borders coincide?
In addition, although, MassGIS boundaries are of very fine quality, why OSM
should be a clone of MassGIS? If a river/border section in OSM is mapped in
finer details, why should the priority be given to a coarser geometry
imported from MassGIS?
On Wed, Jun 3, 2020, 7:03 AM <
talk-us-massachusetts-request at openstreetmap.org> wrote:
> Send Talk-us-massachusetts mailing list submissions to
> talk-us-massachusetts at openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-us-massachusetts
> or, via email, send a message with subject or body 'help' to
> talk-us-massachusetts-request at openstreetmap.org
>
> You can reach the person managing the list at
> talk-us-massachusetts-owner at openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-us-massachusetts digest..."
>
>
> Today's Topics:
>
> 1. Re: Towns' borders along rivers (Wayne Emerson, Jr.)
> 2. Re: Towns' borders along rivers (Greg Troxel)
> 3. Re: Towns' borders along rivers (Greg Troxel)
> 4. Re: Town boundaries redux - was Re: Talk-us-massachusetts
> Digest, (Greg Troxel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Jun 2020 15:55:13 -0400
> From: "Wayne Emerson, Jr." <ibemerson at verizon.net>
> To: talk-us-massachusetts at openstreetmap.org
> Subject: Re: [Talk-us-massachusetts] Towns' borders along rivers
> Message-ID: <a4727de0-ab0e-aef4-7887-34934bf3b17b at verizon.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 5/29/2020 10:40 AM, Greg Troxel wrote:
> > I think this needs research into authoriative evidence before doing it.
> > Absent that, I think our borders should follow the "towns survey" point
> > layer from massgis.
>
> After the latest MassGIS community boundaries were released last Sept.,
> I began to use this dataset to slowly upgrade the townlines for the
> entire state, one line at a time, using JOSM's plugin to "replace
> geometry." I finally finished this task this morning. This same morning
> Yuri Yatsynovich has begun deleting & replacing, or altering the course
> of many town and county borders that fall on rivers. There was no
> consensus for this.
>
> Also last fall the consensus seemed to be that overlapping polygons were
> preferable to multipolygons, so it would be undesireable to chop up an
> admin boundary to make conservation multipolygons out of them:
>
>
> https://lists.openstreetmap.org/pipermail/talk-us-massachusetts/2019-October/000542.html
>
> Yuri's changesets:
>
>
> https://osmcha.org/changesets/86095132?filters=%7B%22date__gte%22%3A%5B%7B%22label%22%3A%22%22%2C%22value%22%3A%22%22%7D%5D%2C%22users%22%3A%5B%7B%22label%22%3A%22Yury%20Yatsynovich%22%2C%22value%22%3A%22Yury%20Yatsynovich%22%7D%5D%7D
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 02 Jun 2020 18:00:11 -0400
> From: Greg Troxel <gdt at lexort.com>
> To: "Wayne Emerson\, Jr. via Talk-us-massachusetts"
> <talk-us-massachusetts at openstreetmap.org>
> Subject: Re: [Talk-us-massachusetts] Towns' borders along rivers
> Message-ID: <rmi4krtcems.fsf at s1.lexort.com>
> Content-Type: text/plain
>
> "Wayne Emerson, Jr. via Talk-us-massachusetts"
> <talk-us-massachusetts at openstreetmap.org> writes:
>
> > On 5/29/2020 10:40 AM, Greg Troxel wrote:
> >> I think this needs research into authoriative evidence before doing it.
> >> Absent that, I think our borders should follow the "towns survey" point
> >> layer from massgis.
> >
> > After the latest MassGIS community boundaries were released last
> > Sept., I began to use this dataset to slowly upgrade the townlines for
> > the entire state, one line at a time, using JOSM's plugin to "replace
> > geometry." I finally finished this task this morning. This same
> > morning Yuri Yatsynovich has begun deleting & replacing, or altering
> > the course of many town and county borders that fall on rivers. There
> > was no consensus for this.
>
> I think what you are doing about MassGIS data is the right thing.
>
> Yuri: it seems clear that there is no consensus to do what you are
> doing. From the comments on the list, and also my historical
> impressions of views, you are the only one who thinks what you are doing
> is ok. In my view, doing this unilaterally borders on vandalism.
> Please stop.
>
>
> There's another issue about rivers as boundaries. Just because a
> statute says that a river centerline (which in MA seems to be the
> midpoint of the banks when the water is at normal levels - this
> definition varies from state to state), doesn't mean that if some mapper
> looks at aerial imagery and moves the centerline to look better that
> this is a good place to put the boundary. It seems obvious from having
> dealt with these issues that the process of deciding on a town boundary
> from river changes is complicated, and reasonable to assume it involves
> some combination of a surveyor or other such licensed professional as
> well as agreement of the selectboards of the two towns, and that the
> results of any such discussion/agreement would be documented by
> coordinates. And then, the MassGIS towns layer would be updated.
>
> Which is a long way of saying that the town boundary representation in
> OSM should be what's in the MassGIS database, absent a particular reason
> with detailed rationale, probably backed up by discussion with both town
> governments.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 02 Jun 2020 18:03:23 -0400
> From: Greg Troxel <gdt at lexort.com>
> To: "Wayne Emerson\, Jr. via Talk-us-massachusetts"
> <talk-us-massachusetts at openstreetmap.org>
> Subject: Re: [Talk-us-massachusetts] Towns' borders along rivers
> Message-ID: <rmiwo4pazx0.fsf at s1.lexort.com>
> Content-Type: text/plain
>
> Greg Troxel <gdt at lexort.com> writes:
>
> > Yuri: it seems clear that there is no consensus to do what you are
>
> I copied a mispelling; should be Yury. Apologies!
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 02 Jun 2020 20:27:25 -0400
> From: Greg Troxel <gdt at lexort.com>
> To: Bill Ricker <bill.n1vux at gmail.com>
> Cc: OSM Massachusetts <talk-us-massachusetts at openstreetmap.org>
> Subject: Re: [Talk-us-massachusetts] Town boundaries redux - was Re:
> Talk-us-massachusetts Digest,
> Message-ID: <rmiftbdat8y.fsf at s1.lexort.com>
> Content-Type: text/plain; charset=utf-8
>
> Bill Ricker <bill.n1vux at gmail.com> writes:
>
> > Those ATLASes are good reading.
> > They are the Bible for the circumambulate the bounds exercise for each
> > town/city.
> > I've downloaded a bunch of them.
> >
> > Warning on data: the latitude longitude and state X-Y posits listed in
> > those were referenced to an antique geode and datum and can NOT be
> directly
> > used. AFAIK.
>
> This is a really good question, and a friend and I dug into it in 2000
> (before OSM existed) and I just looked at my notes.
>
> Bottom line up front: I believe that someone has transformed the atlas
> coordinates into NAD83 for the towns survey points layer, even if it's
> been lost track of how and who. There is or has been a "state
> geodesist" which I think was in MassDOT* that I speculate would have
> helped.
>
> *That seems odd at first glance, but it's really MassDOT that is
> concerned with cm-level positioning (and MassDOT runs MaCORS).
>
>
> The basic version of the story about town corner coordinates is that the
> coordinates in early legislation and I believe in the Atlases are in
> something called the "New England Datum", which was adopted in 1879/1880
> by the USCGS as their first datum. As triangulation networks extended,
> they were added on (but without a readjustment, and hence coordinates in
> MA remaining fixed) and was renamed to the United States Standard Datum
> of 1901 and then the North American Datum (of 1913) when Canada and
> Mexico joined. Then, there was a general readjustment in 1927, but most
> coordinates didn't change much. Of course the adjustment of NAD83 was a
> big change around here.
>
> So, it's mostly fair to just treat the old coordinates as USSD, and
> somewhat less fair as NAD27.
>
> My friend wrote to NGS, and heard back. I don't want to forward private
> mail, but if you are a US geodesy nerd and have read a lot of NGS
> publications you would instantly recognize the person writing back as
> among the most qualified to answer any question like this.
>
> The NGS person looked up records and found stations sort of near Stow
> (~20 and ~30 miles) for which there were both New England Datum and
> NAD83 coordinates, and said that based on those the transform from the
> New England Datum to NAD 83 (1996) is:
>
> Latitude = -0.201 seconds
> Longitude = - 1.770 seconds
>
> which is very very roughly (assuming 111 km for a degree)
>
> -6.2m in latitude
> -36.9m in longtitude
>
> Taking 42.5 -71.5 as my standard point for these sorts of conversions (a
> Western Middlesex centric view!), and asking NCAT for NAD27 to
> NAD83(1986), I get a shift of that's similar. (Do this yourself at
> https://www.ngs.noaa.gov/NCAT/ to get a nicer-to-read output.)
>
> Input Coordinate Output Coordinate Total Change + Uncertainty
> Latitude
> N42° 30′ 00.00000″
> N423000.00000
> 42.5000000000
> Longitude
> E288° 30′ 0.00000″
> W0713000.00000
> -71.5000000000
> Ellipsoid Height (m)
> Not given
> Orthometric Height (m)
> Not given
> Reference Frame
> NAD27
> Geopotential Datum
> Not given
>
> Latitude
> N42° 30′ 00.33483″
> N423000.33483
> 42.5000930095
> Longitude
> E288° 30′ 1.76680″
> W0712958.23320
> -71.4995092223
> Ellipsoid Height (m)
> Not given
> Orthometric Height (m)
> Not given
> Reference Frame
> NAD83(1986)
> Geopotential Datum
> Not given
>
> Latitude
> 0.33483″ ±0.001826″
> (10.332 m ±0.0563 m)*
> Longitude
> 1.76680″ ±0.002502″
> (40.341 m ±0.0571 m)*
> Ellipsoid Height
> Not given
> Orthometric Height
> Not given
>
> Then, I asked for the same thing in USSD, which is closer to the values
> from NGS in latitude, and there the signs make sense as values to add to
> north latitude and west longitude, which makes sense in the historical
> context of NAD83 and 2000. (Now, we are in an ITRF world where
> longitude is often positive east.)
>
> Input Coordinate Output Coordinate Total Change + Uncertainty
> Latitude
> N42° 30′ 00.00000″
> N423000.00000
> 42.5000000000
> Longitude
> E288° 30′ 0.00000″
> W0713000.00000
> -71.5000000000
> Ellipsoid Height (m)
> Not given
> Orthometric Height (m)
> Not given
> Reference Frame
> USSD
> Geopotential Datum
> Not given
>
> Latitude
> N42° 29′ 59.79866″
> N422959.79866
> 42.4999440729
> Longitude
> E288° 30′ 1.75341″
> W0712958.24659
> -71.4995129427
> Ellipsoid Height (m)
> Not given
> Orthometric Height (m)
> Not given
> Reference Frame
> NAD83(1986)
> Geopotential Datum
> Not given
>
> Latitude
> -0.20134″ ±0.003060″
> (-6.213 m ±0.0944 m)*
> Longitude
> 1.75341″ ±0.009674″
> (40.036 m ±0.2209 m)*
> Ellipsoid Height
> Not given
> Orthometric Height
> Not given
>
> So, I think the best thing that can reasonably be done with the old
> coords is to treat them as USSD and to use NCAT.
>
> > (If Paul @ MassGIS or anyone else has proj4 or similar definitions of
> the
> > old geode / datum / coordinate systems in the Atlases, that would be
> > wonderful to facilitate direct use. I tried to reverse engineer based on
> > X-Y being statehouse cupola centered and it didn't work well IIRC. If we
> > had a transform(s), it might be practical to georeference the plates as
> > layers for our editors or Grass/QGis??)
>
> I would say use NCAT and go for it, and please share! As I understand
> it NCAT has done all the hard work and the best you are likely to do is
> reinvent it with some errors. In particular there is a lot of thinking
> about whether to transform e.g. USSD to NAD83 by doing USSD->NAD27 and
> NAD27->NAD83 or to do it 1-hop.
>
> > Mass DOT has a public GIS website that has town corners as a layer (in
> > addition to USGS and Mass geodetic disks/monuments) with modern
> GEODE/DATUM
> > posits. The atlas will explain more but this gives the modern GPS posit
> if
> > you want to find it. IDK the license status of that data wrto OSM, but
> > should be usable for QA/QC.
>
> Earlier versions were clearly usable, and while there is this somewhat
> odd CC-BY license tags on the MassGIS website every time I or anyone
> else has asked they grant permission. Looking at the entire history
> over the entire time OSM has existed, it is entirely clear that MassGIS
> has been and is completely ok with us using their data.
>
> I also discussed with the Secretary of State's office and it seems that
> they don't believe public records generated by the state can be subject
> to copyright (as in the state could not assert copyright), but it also
> seems this is slightly a grey area. (This is similar to some other
> states actual laws that the state can't assert copyright, but here it's
> a bit indirect and doesn't have a court precedent.)
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Talk-us-massachusetts mailing list
> Talk-us-massachusetts at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us-massachusetts
>
>
> ------------------------------
>
> End of Talk-us-massachusetts Digest, Vol 45, Issue 2
> ****************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us-massachusetts/attachments/20200603/1e725a92/attachment-0001.htm>
More information about the Talk-us-massachusetts
mailing list