[Imports] Sonoma County California import

Tue Jan 4 05:46:54 UTC 2022

OK I've run the JOSM validator and things look good. No addresses should be
created within Santa Rosa city limits since those were imported previously.
There are perhaps a handful of geometry or overlap or duplicate address
validation errors per import file, however they are relatively easy to fix
by hand and relatively hard to fix automatically.

Here's my spot check notes:

buildings_1044:
- one malformed building that has a way segment twice (easily fixed)
- about a dozen buildings intersecting highways (misaligned highways)
- two pairs of duplicate house number (parcel addresses are also duplicated)

buildings_1008:
- one malformed apartment relation that needs manual fixing anyway: missed
because it wasn't a building and only detected because it's already
duplicated in OSM
- two newly inserted buildings intersecting way, but it's the way's fault
and easily fixed

buildings_966:
- one new building crossing a landuse
- two new buildings crossing a waterway (tunnel? misaligned culvert?)
- one new building pair that duplicates each other's address, usually
because it's two parcels with the same address (easily manually fixed)

buildings_977:
- five sheds that incorrectly intersect a preexisting fence (not a lot of
margin for error on these lots)
- two buildings intersecting highway (misaligned existing roads)
- building intersecting highway area (misaligned area)
- bus stop intersecting sidewalk (easily fixable)
- 8 duplicate pairs of house numbers (again seems like a minor parcel
labeling issue)

I'm feeling quite good about this data. We won't be importing 100% of the
available data (I'm not touching existing addresses or existing buildings
even though I could try) but the data we are importing should be quite
useful and accurate.

On Wed, Apr 28, 2021 at 1:49 PM zyphlar <zyphlar at gmail.com> wrote:

> 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/20220103/eee3e91b/attachment.htm>