[import import-proposal] Proposed import of Johnson County, Kansas address points (299,565)

Communities United States
, ,
1

Hello US community,

I am proposing to import the Johnson County, Kansas address point dataset
(299,565 points). This is my first import, so I am posting here before doing
anything, and I would genuinely value a blunt read on the licensing question
below — that is the main reason I am asking.

Documentation

I do not yet have a wiki page; I want the community’s view on the license
question first, since it determines whether a wiki page is worth writing. I am
happy to draft one immediately if the response to this is positive.

Source dataset (public ArcGIS MapServer, no auth, no rate limit):

  • Service: https://maps.opkansas.org/mapping/rest/services/MixedInfo/JOCO_Addresses/MapServer/0
  • This is Overland Park’s public server hosting Johnson County address data.
  • ~299,565 records. Fields: objectid, APID, AddNum, PreDir, StrName, StrType, SecUnitDes, SecUnit, City, State, Zip, County, Latitude, Longitude, GeoPropID, TaxPropID. No names, no occupants, no PII — addresses and
    coordinates only.

I can publish the conversion script and a sample .osm extract for review.

License

I want to be fully transparent, because this is the crux.

The upstream steward is Johnson County AIMS (Automated Information Mapping
System). I contacted them in January 2026, both to request an API key and to ask
about contributing address data to OSM. Their responses:

“The web service is an application that is not raw data.”

“Johnson County AIMS does not grant permission for individual data uses.
Further, in addition to K.S.A. 45-230 … K.S.A. 45-220(c)(2) contains an
anti-solicitation provision regarding requesters making names or addresses
available to third parties for certain solicitation purposes. While we
cannot determine if providing addresses to OpenStreetMap complies with these
statutes, you may want to take these statutes into consideration.”

They did not grant permission, and they did not state that it is
prohibited. They declined to interpret the statutes and pointed me at them.

My reading, for what it is worth:

  1. Feist v. Rural Telephone (1991) — factual data (addresses, coordinates) is
    not copyrightable; facts are “part of the public domain available to every
    person.” These are facts about physical locations.
  2. K.S.A. 45-216 — public records are open for inspection by any person.
  3. K.S.A. 45-230 / 45-220(c)(2) restrict using public records for
    solicitation of services. OSM does not sell data, advertise, or solicit.
  4. Precedent: the USDOT National Address Database import (53M+ points, public
    domain), plus Miami-Dade FL, Cuyahoga OH, and the state of Arkansas.

But I am not a lawyer and neither is the county’s position a clearance. I
would rather hear “no” or “here is what’s needed” now than create a 299k-object
cleanup problem later. If the consensus is that the chain of title is too
uncertain, I will not proceed.

One thing I would specifically like guidance on: the AIMS flow and the
Overland Park flow may be different sources. The records I hold carry an
APID field in what appears to be the AIMS address-point ID space, but I
retrieved them from Overland Park’s server, which publishes no terms of use and
no copyright text on the service. If anyone has prior art on whether Overland
Park’s own publication carries a separate or more permissive basis, that would
be very helpful.

Abstract

Size: 299,565 points.

Coverage: all of Johnson County, KS — 25 cities, 35 ZIP codes.
Largest: Overland Park (96,551), Olathe (67,564), Lenexa (31,313),
Shawnee (31,109), Leawood (14,734), Gardner (12,709),
Prairie Village (11,535), Merriam (6,621). 71,944 records include a unit.

Current OSM coverage — and why this is worth discussing. I measured this
with Overpass so the post is concrete rather than hand-wavy. County boundary
resolved by wikidata=Q374979 (there are three “Johnson County” admin_level=6
features reachable by name — KS, WY and GA — so a name-based query overcounts):

Extent Existing OSM addr:housenumber This dataset
Johnson County, KS (all) 19,797 (1,217 nodes + 18,580 ways) 299,565
City of Leawood 269 14,734
Within 2 km of my home 104 —
Within 300 m of my home 0 —

So county-wide coverage is not empty — it is concentrated almost entirely in
building polygons (18,580 ways vs 1,217 standalone nodes) and very thin in
places. Leawood is the clearest illustration: OSM has 269 addresses where the
dataset has 14,734, a ~55× gap. Near my own home there are zero within 300 m,
which is what led me here.

That unevenness cuts both ways and is the main technical risk: there are
18,580 existing address-bearing ways to conflate against, and the dataset’s
points are property-centroid coordinates, not building centroids.

Tag mapping (only verifiable, real-world tags):

Source field OSM tag
AddNum addr:housenumber
PreDir + StrName + StrType addr:street (abbreviations expanded: RD → Road, W → West)
SecUnitDes + SecUnit addr:unit
City addr:city
State addr:state
Zip addr:postcode

APID, GeoPropID, TaxPropID, objectid would not be imported — they
are internal database keys with no verifiable real-world meaning. (If anyone
thinks a ref tag is warranted, I would like to hear the argument; my reading
of the import guidelines is against it.)

Conflation — the part that is not finished

I want to be clear that the current tooling is not ready to upload, and
conflation is the main reason:

  • The converter emits every row as a new node with a negative ID and does not
    check existing OSM data at all. As written it would duplicate.
  • There are 19,797 existing address objects to reconcile against (of which
    18,580 are building ways), and the guidelines are explicit: do not put data
    on top of data    .
  • Existing objects must not be replaced; where a building already carries an
    address, the point should not be added separately.

My intent is JOSM Conflation plus an Overpass pre-pass to drop exact
duplicates, with a manually reviewed sample before any bulk run. If the
community knows a better tool for address-point-to-building conflation at this
volume, I would rather be told now.

Process commitment

If the license question comes back acceptable, I commit to:

  • A wiki page with full data-prep and conflation detail before any upload.
  • A dedicated import account (jordan_d_miller_import), linked to my main
    account and to the wiki page.
  • The required 14-day review period after posting, with all concerns
    addressed first.
  • A staged, city-by-city upload — smallest first, pausing after each for
    validation and community feedback — not one 299k changeset.
  • Revert readiness and DWG contact before starting, per the guidelines.

Thank you for reading this far. I am mostly here for a straight answer on the
license chain, and I will take no as a real answer.

Proposal to add :robot: as a reaction to AI content
2

One correction and one substantive addition, both from measuring rather than assuming.

Correction to my own numbers

My first Overpass count for “existing OSM addresses in Johnson County” was wrong.
I matched the county by name, which silently matched three admin_level=6
features called “Johnson County” — in Kansas, Wyoming, and Georgia — giving
54,992. Resolving the boundary properly via wikidata=Q374979 gives:

Extent OSM addr:housenumber
Johnson County, KS (all) 19,797 (1,217 nodes + 18,580 ways)
City of Leawood ~214
Within 300 m of my home 0

Flagging it because a name-based admin lookup is an easy way to get a
confidently wrong number, and I’d rather correct my own post than have someone
else do it.

The actual case: 86% of buildings here have no address

This is a stronger framing than raw address counts, and it changes the method:

Johnson County, KS Count
Building footprints in OSM 127,720
…with an addr:housenumber 18,374
…without any address 109,346 (86%)

Leawood, as a local example: 10,258 buildings, of which only ~214 are
addressed — about 2%.

So this is not “OSM has no data here.” OSM already has the geometry; it lacks the
addresses. That is precisely the case the
US Addresses import plan
describes — add the address to the existing building footprint rather than as
a separate point.

The coordinates support that method

I tested whether these points would actually land on existing buildings. For the
718 dataset points in a 1.5 km box near my home, distance to the nearest OSM
building centroid:

Distance Share
≤ 10 m 85%
≤ 20 m 93%
≤ 50 m 96%

Median 1.5 m. So the points are effectively building-level, not generic parcel
centroids — which means the intended operation is to tag the ~109k unaddressed
buildings, not to add 299,565 standalone nodes.

I want to be explicit that the latter is what my current converter does, and that
it is wrong for this data: it would leave 18,374 existing addressed buildings
sitting under a duplicate point, and it would not attach any address to the
109,346 buildings that need one. Conflation is not a cleanup step here — it is
the job.

So my question shifts slightly. Beyond the licensing question in my first
post, I’d welcome guidance on:

  1. Is building-tagging (rather than point-adding) the right target here, given
    the numbers above?
  2. Is JOSM Conflation the right tool for ~109k building matches, or is there
    something better suited at this scale?
  3. Where a dataset point has no nearby building (4–7% of cases), is a standalone
    addr:* node acceptable, or should those be excluded pending survey?

Happy to publish the conversion and matching scripts plus a sample extract for
review before anything is proposed formally.

3

Looking at Johnson County Open Data Portal, the appear to use the license CC-BY-ND which is not compatible with ODbL. See Import/ODbL Compatibility - OpenStreetMap Wiki. You might want to check if they uploaded the addresses to the Federal Government. I think it’s the National Address Database. I’ve also sent emails to the counties’ GIS departments requesting permission to use their address data in OSM. I’ve been successful in my state, but not in others. good luck

2 Likes
4

“No solicitation” is a restriction on use that I believe is incompatible with OSM - downstream consumers can choose to solicit if they want.

5

Are import proposals written by LLM allowed?

3 Likes
6

Does the proposed process require pointing an LLM at a public Overpass API instance? If so, please let us review the query code beforehand. Popular models are known to brute-force Overpass queries in the most inefficient, counterproductive manner possible to answer high-level questions. The sysadmins for this service are suffering from that kind of misuse, so we should try to avoid it if possible. To mitigate the risk, develop the query code in the open; don’t have an agent run it behind the scenes.

4 Likes
7

Yes.

Sharing of accurate information that contributes to general knowledge created through artificial intelligence, such as computer code, step-by-step instructions for procedures, and the like, is of course always permissible.

8

This is AI slop and should be summarily deleted. I have reported it as such and the moderation team has declined to take action.

5 Likes
9

I am surprised that the moderators didn’t give the poster a chance to edit the proposal and post it again, without the AI “contributions” that make it virtually unreadable.

Posting it in the form that it was posted here shows no respect for the people in the community who are expected to review it.

3 Likes
10

Do they? A median residential building (in my suburban area) is about 10m x 10 m. The buildings mapped in OSM in your area looking similar. Like from centroid to building outline there are ~5m. So based on your analysis, >15% of your data will be outside of any building.

Are the <85% within the correct building?
How would you deal with larger complexes like shopping malls, where each shop has usually its own address, but there is only one building?