[Imports] Sonoma County California import

zyphlar zyphlar at gmail.com
Wed Apr 28 20:49:36 UTC 2021


I'll add to the wiki a description of the conflation process. As you can
see from the scripts, conflation is a major portion of the process and we
will not be importing or modifying any existing buildings. I have seen a
rare case where perhaps a polygon is planned to be imported on top of an
existing building which I think may be an artifact of the county using
multipolygons for courtyards and architectural features; since the actual
import will be divided into manual tasks and these instances seem rare I'm
not very worried about it. As you can see from the screenshots in Github,
the detection seems pretty reliable.

If you load up the OSM file you can see that often the imported data will
be even more high-fidelity than existing buildings, and the address data
seems quite good with only understandable mistakes for example at street
corners where perhaps a business owner has bought multiple lots and perhaps
chosen to advertise one address over another (which we can't know from our
armchairs), or buildings which span multiple parcels that can confuse the
conflation logic (in which case I've noticed we generally avoid assigning
an address at all rather than be incorrect). Still, the logic seems very
good and my spot checking has been pretty extensive: even if there's some
mistakes here and there, this data will greatly improve OSM's local
usability.

I have opened these files in JOSM, but I have not yet run the validator on
them, will do.

Once I am done debugging and the data looks good I'll remove the x_son
tags, that's been noted in my TODOs.

Finally, I just went ahead and used the `usecode` data to assign building
types when possible. I'll have that update ready for review shortly, and be
spot checking it myself.

Thanks for your feedback!

On Wed, Apr 28, 2021 at 1:28 PM Mateusz Konieczny via Imports <
imports at openstreetmap.org> wrote:

> In general thanks for making import! It takes plenty of time but if done
> well
> can allow to avoid spending mapping time on something already mapped
> and to avoid drudgery of mapping buildings from aerial imagery.
>
>
> ------------------------------------------------------------------------------------
>
> ref:database_code=object_code is something that I deeply dislike, so
> personally
> I would remove it unless absolutely necessary.
>
> It is confusing, not human readable, and sometimes scares/confuses newbies.
>
> In most cases is never used or trusted too much if ever used.
>
> Though it was used in many import and noone died from it and I am not a
> local mapper,
> so treat it as a suggestion/opinion.
>
>
> ------------------------------------------------------------------------------------
>
> source=* tag definitely goes on changeset, not on every edited object
>
>
> ------------------------------------------------------------------------------------
>
> Have you tried opening upload files, downloading existing data and running
> JOSM validator?
>
>
> ------------------------------------------------------------------------------------
>
> Wiki page does not mention explicitly that duplicating already existing
> building data
> (conflation) is done, hopefully it is just missing from wiki page.
>
>
> ------------------------------------------------------------------------------------
>
> Have you checked whether building quality in that dataset is good enough
> for importing?
>
> Apr 28, 2021, 21:11 by zyphlar at gmail.com:
>
> Absolutely, great suggestions, I've updated the wiki and license.
>
> I was planning to remove the x_son_p tags before final import as they are
> mostly useful for debugging, however if you think it's useful to keep
> database foreign keys like GID, or I also have a parcel use code available
> that may correlate to building type (either parseable now during import or
> perhaps in the future), I can leave one or both in. If there's no other
> major task remaining maybe I can put energy into correlating usecodes with
> OSM building types and then leave the x_son data completely out.
>
> Question, some imports seem to attach a source tag to every item they
> import, which seems excessive to me. Maybe I can just mark the source in
> the changesets?
>
> On Wed, Apr 28, 2021 at 6:22 AM Mateusz Konieczny via Imports <
> imports at openstreetmap.org> wrote:
>
> Can you add license to https://github.com/zyphlar/sonoma-import/
> repository,
> so that this code would be potentially reusable by someone else?
>
>
> https://wiki.openstreetmap.org/wiki/Sonoma_County_Building_and_Address_Import
> is missing info which tags will be used.
>
> For example in
>
> https://raw.githubusercontent.com/zyphlar/sonoma-import/main/out/clean/buildings_1000.osm
> I see tags such as x_son_p:gid
>
> Apr 28, 2021, 05:58 by zyphlar at gmail.com:
>
> Hi there!
>
> I think I'm ready for a review and approval of building and address import for
> Sonoma County California.
>
> Please see: https://wiki.openstreetmap.org/wiki/Sonoma_County_Building_and_Address_Import
> and: https://github.com/zyphlar/sonoma-import/
> for status, details, and downloadable OSM files to preview the data.
>
> Local community involvement has unfortunately been lackluster, but 1ec5 and impiaaa
> have been invaluable in helping me get my first import together.
>
> Any and all feedback is appreciated!
>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>
> _______________________________________________
> 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/20210428/da4f4443/attachment.htm>


More information about the Imports mailing list