[Imports-us] Fwd: Vermont, U.S. address import

Greg Troxel gdt at lexort.com
Fri Oct 7 12:29:37 UTC 2022


Jared <osm at wuntu.org> writes:

> On Thu, Oct 6, 2022 at 8:13 AM Greg Troxel <gdt at lexort.com> wrote:
>
>> You are going to have to deal witha matching addresses between import
>> source and OSM programmatically like in #1 above, once you move beyond
>> non-addressed towns.  Once you do that, the ref won't help, as it won't
>> be 100% reliable.  Therefore it's noise.
>
> I was thinking of using the foreign key for a different use case.  I agree
> that relying on this key for *overwriting* OSM data does not seem safe.
> The scenario I'm thinking about is for NEW addresses that are added to the
> VCGI dataset.  To determine if a NEW VCGI e911 address exists in OSM, the
> "ref:vcgi:esiteid" tag would seem to be very helpful.  If an address in OSM
> already has that unique esiteid key, then we can be confident that it
> should be skipped.  If the esiteid does not exist in OSM, then other
> signals should be evaluated (housenumber, streetname, lat/long, etc., but
> those can be less precise due to misspellings or slightly different
> coordinates.

I see where you're going but I think you need to get the fuzzy match
right anyway and it's not going to help that much to have a key.

> I'd like to hear the negative impact a foreign key causes.  There are other
> similar foreign keys (eg. wikidata, wikipedia) and I've never found them to
> be detrimental to my work, but don't want to cause issues for others.  The
> 55,000 VT addresses that have been added using the Esri layer in the RapiD
> editor include this "ref:vcgi:esiteid" key, and I've found it to be useful.

A fair question, and it may be that the RapiD stuff is out of line.

I don't think the foreign keys really hurt.  I just think that the
history is that they are less useful than everybody thinks they are going
to be.

>> Wow.  Are you saying that apartment buildings have coordinates of entry
>> doors within the building, or that they are artificially skewed to make
>> rendering non-overlapping, or ?  Surely Vermont has at least some
>> multi-floor apartment buildings that have the same floor design and thus
>> multiple units that actually do have the same horizontal coordinates.
>
> I've asked my contact at VCGI for clarification on how multi-tenant
> buildings are addressed.  From what I've seen, some multi-tenat buildings
> just have one e911 address associated with them.  I have seen other
> buildings that have multiple addresses, but I've never seen them overlap.
> I'll keep a close eye out for this and will see what VCGI has to say.  I do
> have the VT data in a postgis database, but don't have experience using the
> GIS functions, so I'll try it out.

Sounds good.  There are hard questions about datasets and as you can see
my bias is to dig in and address them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/imports-us/attachments/20221007/c96d2ab8/attachment.sig>


More information about the Imports-us mailing list