<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 2, 2022 at 5:02 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Joe Rhodes <<a href="mailto:joe.rhodes@castlepinesco.gov" target="_blank">joe.rhodes@castlepinesco.gov</a>> writes:<br>
<br>
> I'm the GIS manager for the newest municipality in the State of<br>
> Colorado, City of Castle Pines. <br>
<br>
Welcome to OSM.<br></blockquote><div>Yes, welcome to OSM!</div><div><br></div><div>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).</div><div><br></div><div>Mike </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't know if you have experience editing OSM (not doing an import,<br>
just normal mapper activity).  Generally, I and I think most others see<br>
that as a prereq.<br>
<br>
Have you read:<br>
<br>
  <a href="https://wiki.openstreetmap.org/wiki/Import/Guidelines" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Import/Guidelines</a><br>
<br>
You'll have to prepare documentation.  One of the harder parts will be<br>
conflation with existing data.<br>
<br>
The easy part, to get one of the showstoppers out of the way:<br>
<br>
  Please provide a link to download the data (no login, that anybody can<br>
  do).<br>
<br>
  Please provide a link to a public statement of the license for the<br>
  data, so that we can see if it meets the OSM requirements.<br>
<br>
  Are you in touch with the mappers that have edited in your area?  Have<br>
  you discussed this with them?  What do they think?  If not, please<br>
  find them.<br>
<br>
> Many addresses in our city are missing<br>
> from OSM, and the ones that are there do not show Castle Pines as the<br>
> city (they appear to just be in unincorporated Douglas County). I am<br>
> seeking approval to do an import of the full set of address points for<br>
> our city in order to correct these problems.<br>
<br>
"import the full set" and "many are missing" do not go together.  You'll<br>
need a conflation process -- which I think should be one with published,<br>
open-source code, so others in the community can replicate it -- that<br>
looks at your address data and matches it with OSM data, more or less<br>
sorting it into "address match, close geographically", "address match,<br>
far off", and "address not in OSM".  The middle category needs manual<br>
review (that doesn't solidly presume either db is right) and the third<br>
is what ends up proceeding in import.  Then there's the question of what<br>
object it is attached too, or just a bare point with address tags.<br>
<br>
> In addition, the city boundary is incorrect in OSM. The city has a<br>
> multipart boundary (there are two non-contiguous sections on each side<br>
> of an interstate highway), and only the eastern portion shows on<br>
> OSM. Because it is non-contiguous/multipart, I am unable to edit it to<br>
> reflect the correct boundary, so I'm seeking approval to import the<br>
> correct boundary as well.<br>
<br>
I don't understand how you can't edit it.  Have you asked the local<br>
mappers for help?<br>
<br>
It sounds like it should be a multipolygon.  You say "shows on OSM" but<br>
we should be talking about the objects in the database, not the output<br>
of any render.  Let's assume there is a single closed way which is one<br>
of the parts and it has the admin/name tags.  The first thing to do is<br>
look at the history (^H in JOSM, and if you haven't learned JOSM I would<br>
recommend that before importing, because if you import anything you have<br>
bit off the repsonsibility to fix any problems) and contact the people<br>
that edited it before and talk about the situation.<br>
<br>
If what you want to do is take a polygon for the missing half -- after<br>
verifying it really is missing -- and convert that to osm and turn the<br>
existing closed way and the new one into a multipolygon, then that's not<br>
that big a deal, but given that you seem to be new I think the steps of<br>
community consultation, public data, license, transform mechanism should<br>
be written down.<br>
<br>
You didn't talk about the half that is there being wrong, so I'm<br>
assuming you don't wnat to change that.  In general "my data is better,<br>
and so I want to delete and add mine" is not ok; OSM has a strong<br>
doctrine of deference to hand mapping, even if any particular thing that<br>
is actually wrong can be fixed.  Sometimes OSM people have good data<br>
about boundaries and it can be better than the official data.  As an<br>
example I've measured my town's boundary stones with RTK, and the<br>
official data is an 1890 survey in the New England datum reckoned<br>
forward to NAD27 and then NAD83.  The amazing thing is that we agree at<br>
the 0.5m level, and I may this year get to the point where I can<br>
reasonably confidently say my values are better.  But most OSM data is<br>
not like this.<br>
<br>
Finally, and this is not a big deal, but I'm guessing your data is in<br>
NAD83(2011) epoch 2010.0 and OSM is nominally in WGS84.  That's fuzzy,<br>
but you should transform to the latest realization, WGS84(G2159), or<br>
something like ITRF2014 as a close proxy.<br>
<br>
Greg (osm user gdt)<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</blockquote></div></div>