[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