[Imports] Address import from city government source

[Mike Thompson]

On Tue, Aug 2, 2022 at 5:02 PM Greg Troxel <gdt at lexort.com> wrote:

>
> 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.
>
Yes, welcome to OSM!

I am in Colorado and an experienced mapper.  I can help, but you will need
to deal with the license issue, and some of the other things Greg mentions
(good advice from Greg all around, which I second).

Mike


>
> 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)
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20220802/fae0279a/attachment-0001.htm>