I’m still somewhat new to navigating the legal portion of these things and don’t have a great sense yet of whether the mail above is a strong enough statement. The folks on the import mailing group (US or otherwise) would have a better idea. The issues is that there’s lots of different flavors of “open” in data and they can conflict in various non-obvious ways. For example, a Creative Commons Non-Commercial license is an “open” license that conflicts with our OLDb license because we say you CAN use it for commercial use (with attribution).

Definitely add the source to the list here so it’s tracked and other users can reference: osm.wiki/Potential_datasources/Local_data#U.S.

I highly recommend finding imports of the type you’re trying to work on and reading their entries in the wiki. Scan through the Import Catalog. Always good to not reinvent things if you don’t have to. You can also find specific users to reach out to! For example, you’ll find my Indianapolis Address Import.

For address info specifically, you’ll probably want to use the already prepared National Address Database info from ESRI as it’s already been cleaned up and OSMified. I’m running a huge project for the greater Phoenix area to do just that. The instructions link off into other reading about address data additions you may find interesting.

I’m not super familiar with transforming building data but definitely wouldn’t mind working on it with you if that helps get things rolling. You can ping me here or the OSM US Slack or the OSM Discord with the same username.

Nice! Presumably they have road centerline, address, and building footprint data? Anything else?

Love love love to see this. Incredible work.

Totally right to be wary as it’s a “generate plausible text” tool and not a “go find the right answer” tool. That said, it’s always fun to play and see where things are and see where the limits of things are!

Have you considered asking it to give cuisine=* suggestions based off the website for the restaurant? Having the language model do parsing of that form could be super helpful.

I am reminded of some work someone posted in the OSM Discord some time back about using AI text tools to crawl website= tags to scrape and generate opening hours, phone number, and social media into data tags.

As we work through this, I’m getting more and more interested in a general deduplication/simplification/deletion of common US import tags. Many objects have more than one synonym (or roughly synonym with the same value) which leads to maintainance issues (ex: merged nodes with different GNIS IDs, but they are in different synonymous keys.)

Some cleanup that would immediately help reduce confusion/headaches: The 6 ways to tag GNIS ID. The many ways to encode name data NHD:GNIS_Name, gnis:name, the GNIS tags that are just is_in:* tags of a different format, etc

I wonder if there’s precedent for merging out synonyms etc. Something to ask around about I suppose.

When I did the Indianapolis import I definitely hit issues where they disagreed. In those cases I had to find ANOTHER source of data to tie break, typically street side data. You can also see notes I left around Indianapolis like “what is the name of this street ‘foo’ or ‘bar’?”. Because I figured it would eventually get seen by a local and they can help be my arbiter.

UPDATE! I have completed the address conflation of NAD data into Indianapolis. I’ll need to post an update to the dataviz for it to be reflected but… one city down, many to go.

This is extremely helpful and always nice to have written down in an accessible location. Thanks for writing it up!

Thank you for sharing! Seems all too easy to miss the correct accent marks. Reminds me of this excellent diary about finding and fixing spelling in the “cuisine” tag which you may find interesting.

Oh absolutely. I was curious about “genus” and it’s only in the list because Latin was one of the “languages” that happened to survive my sorting. I highly doubt anyone is actually accidentally submitting Latin into the database. Casting a wide net means you’ll very often find false positives!

I’m super new to this kind of editing work. I’ll definitely review my edits. Keeping on task (correcting typos etc) and resisting the urge to fiddle (in many cases somewhat haphazardly) is a real issue. This is all extremely well thought out and I appreciate the review and feedback from y’all.

Just finished running this workflow for my local area. What a great idea. Some cuisine tags that aren’t in the list but made sense to me were: “gelato”, “pho”,”terikayi”. There’s hits for all those in tag info but would love to know if folks think there’s ways to improve those entries.