[Imports] Address import from city government source

[Greg Troxel]

Joe Rhodes <joe.rhodes at castlepinesco.gov> writes:

> I'm the GIS manager for the newest municipality in the State of
> Colorado, City of Castle Pines. 

Welcome to OSM.

I don't know if you have experience editing OSM (not doing an import,
just normal mapper activity).  Generally, I and I think most others see
that as a prereq.

Have you read:

  https://wiki.openstreetmap.org/wiki/Import/Guidelines

You'll have to prepare documentation.  One of the harder parts will be
conflation with existing data.

The easy part, to get one of the showstoppers out of the way:

  Please provide a link to download the data (no login, that anybody can
  do).

  Please provide a link to a public statement of the license for the
  data, so that we can see if it meets the OSM requirements.

  Are you in touch with the mappers that have edited in your area?  Have
  you discussed this with them?  What do they think?  If not, please
  find them.

> Many addresses in our city are missing
> from OSM, and the ones that are there do not show Castle Pines as the
> city (they appear to just be in unincorporated Douglas County). I am
> seeking approval to do an import of the full set of address points for
> our city in order to correct these problems.

"import the full set" and "many are missing" do not go together.  You'll
need a conflation process -- which I think should be one with published,
open-source code, so others in the community can replicate it -- that
looks at your address data and matches it with OSM data, more or less
sorting it into "address match, close geographically", "address match,
far off", and "address not in OSM".  The middle category needs manual
review (that doesn't solidly presume either db is right) and the third
is what ends up proceeding in import.  Then there's the question of what
object it is attached too, or just a bare point with address tags.

> In addition, the city boundary is incorrect in OSM. The city has a
> multipart boundary (there are two non-contiguous sections on each side
> of an interstate highway), and only the eastern portion shows on
> OSM. Because it is non-contiguous/multipart, I am unable to edit it to
> reflect the correct boundary, so I'm seeking approval to import the
> correct boundary as well.

I don't understand how you can't edit it.  Have you asked the local
mappers for help?

It sounds like it should be a multipolygon.  You say "shows on OSM" but
we should be talking about the objects in the database, not the output
of any render.  Let's assume there is a single closed way which is one
of the parts and it has the admin/name tags.  The first thing to do is
look at the history (^H in JOSM, and if you haven't learned JOSM I would
recommend that before importing, because if you import anything you have
bit off the repsonsibility to fix any problems) and contact the people
that edited it before and talk about the situation.

If what you want to do is take a polygon for the missing half -- after
verifying it really is missing -- and convert that to osm and turn the
existing closed way and the new one into a multipolygon, then that's not
that big a deal, but given that you seem to be new I think the steps of
community consultation, public data, license, transform mechanism should
be written down.

You didn't talk about the half that is there being wrong, so I'm
assuming you don't wnat to change that.  In general "my data is better,
and so I want to delete and add mine" is not ok; OSM has a strong
doctrine of deference to hand mapping, even if any particular thing that
is actually wrong can be fixed.  Sometimes OSM people have good data
about boundaries and it can be better than the official data.  As an
example I've measured my town's boundary stones with RTK, and the
official data is an 1890 survey in the New England datum reckoned
forward to NAD27 and then NAD83.  The amazing thing is that we agree at
the 0.5m level, and I may this year get to the point where I can
reasonably confidently say my values are better.  But most OSM data is
not like this.

Finally, and this is not a big deal, but I'm guessing your data is in
NAD83(2011) epoch 2010.0 and OSM is nominally in WGS84.  That's fuzzy,
but you should transform to the latest realization, WGS84(G2159), or
something like ITRF2014 as a close proxy.

Greg (osm user gdt)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20220802/bdbbff0c/attachment.sig>