Spec country code as 2-letter, use i18n-friendly column names for state/zip

[iansltx]

The idea here would be to store countries as ISO 3166-1 alpha-2 strings for consistency. Also, the US is the only country with a ZIP code to my knowledge; everyone else calls them postal codes or postcodes. "State" is a little more widely used, but "region" is more correct for more places.

If this looks good, I'll figure out how to replace the DDL screenshot with one that reflects these schema changes.

[vkWeb]

@iansltx Thanks for making these changes :)

The idea here would be to store countries as ISO 3166-1 alpha-2 strings for consistency.

Btw, why we shouldn't store the full country name?

"State" is a little more widely used, but "region" is more correct for more places.

Actually there's a location hierarchy: country -> state -> city -> address. So state is more relevant.

Also, the US is the only country with a ZIP code to my knowledge; everyone else calls them postal codes or postcodes.

This is fine.

[allella]

@vkWeb I got to run and grab lunch, but I think you were pretty much saying the same thing on the adress. Have fields that align well with a standard, like below, since we know those are well vetted for differences around the globe. The PostalAddress also confirms @iansltx 2-alpha country suggestion and looks like if you add in latitude and longitude then that covers geocoding.

[timrodz]

Great changes! I have some ideas to offer:

Have you considered changing country's type to char(3)? I work with these kinds of tables (& queries) all the time. Having that extra character can make it easier to read/work with data manipulation — Boosts overall readability and doesn't hurt the DB.

[allella]

From #75

• streetAddress
• addressLocality
• addressRegion
• addressCountry ISO 3166-1 alpha-2 country code (as mentioned in Spec country code as 2-letter, use i18n-friendly column names for state/zip #72 by @iansltx)
• postalCode
• latitude
• longitude

[vkWeb]

@allella How do we get the latitude and longitude?

[timrodz]

@allella How do we get the latitude and longitude?

Hey @vkWeb, you can get this from Google Maps as an example.

[cmenedes]

How do we get the latitude and longitude?

@vkWeb the address needs to be geocoded in order to get the longitude/latitude. there are various geocoding services around but here is the Geocoding API guide courtesy of Google: https://developers.google.com/maps/documentation/geocoding/intro
https://developers.google.com/maps/documentation/javascript/geocoding

[iansltx]

So, I'm wondering if we're getting "location" confused with "venue". Location would be city-level or similar, while venue would have an exact address/geocode.

@timrodz I'm not following your comment re: making the field a character longer than it needs to be. I've been doing this SQL thing for awhile, including using two-letter country codes, and haven't come across what you're talking about.

[allella]

@iansltx you're probably right about that. I just wanted to make sure if we're doing a zip, street and such that it follows a well thoughout naming convention and field definition, like schema.org

[vkWeb]

@vkWeb the address needs to be geocoded in order to get the longitude/latitude. there are various geocoding services around but here is the Geocoding API guide courtesy of Google: https://developers.google.com/maps/documentation/geocoding/intro

@cmenedes Thanks for that API doc link. The address will be entered by users so we'll need to follow this: https://developers.google.com/maps/documentation/geocoding/best-practices#user-input

No latitude or longitudes need to be stored in this case. Please correct me if I am going in the wrong direction. :)

[vkWeb]

@cmenedes Or maybe we can add a field to allow users to enter the Google Map URL of the location?

[matthewdarwin]

Please let's not require google services for this. OpenStreetMap geocoder and maps should be able to be used.

[timrodz]

@timrodz I'm not following your comment re: making the field a character longer than it needs to be. I've been doing this SQL thing for awhile, including using two-letter country codes, and haven't come across what you're talking about.

Fair point of view - The ISO 3 offers better visual association, but I suppose we can always convert these through our codebase. Thanks for your PR 😄

[cmenedes]

So, I'm wondering if we're getting "location" confused with "venue". Location would be city-level or similar, while venue would have an exact address/geocode.

@iansltx
check out the discussion in #75. i think it would make sense that a venue has a location (which would represent an address). an "exact-address" can consist of many fields (unless it's a single string) so referencing a location might make more sense instead of having it all in that one table.

[cmenedes]

Please let's not require google services for this. OpenStreetMap geocoder and maps should be able to be used.

@matthewdarwin
i was just providing an example of how it can be done; i'm not particularly married to the idea of using Google services. is this the geocoder you are talking about? https://nominatim.org/release-docs/develop/api/Overview/

[cmenedes]

@cmenedes Or maybe we can add a field to allow users to enter the Google Map URL of the location?

@vkWeb
i'm not sure what the use case for that would be....unless for some reason an address can't be geocoded. how it would work is the geocoder would take the user input in the form of an address (like 36 Union Square E, New York, NY 10003) and transform it into a location on the map (40.7360252, -73.9891655), and then plot it. i think we do still need to include location data (lng, lat) as part of the location definition.

[vkWeb]

@cmenedes No, I was thinking if we could plot the map directly through google map URL of the venue address entered by the user.

I'll leave this to @iansltx, @cmenedes and others interested to decide upon.

[allella]

#46 was merged so that's not blocking things now. Though, there's a conflict on this one, so someone will need to clear that up. My only vote on this would be to use schema.org's vocabulary and not city, state, zip. That would be locality and region, which are apparently more global-friendly.

[iansltx]

Heading out for a movie momentarily; can catch this up tomorrow, or we can retire this in favor of someone who's able to get the schema stuff set up in shorter order.

[bernhard-hofmann]

I'm happy to merge this to master and then update the schema diagram. The discussions about geocoding is not relevant to this specific issue relating to normalising country names and using more internationally friendly column names.

[nik-john]

@all-contributors please add @iansltx for code

[allcontributors]

@nik-john

I've put up a pull request to add @iansltx! 🎉