added street number and address to location

[trojanpauro]

To make the locations geocoding friendly.

• I have read Chapter's contributing guidelines.
• My pull request has a descriptive title (not a vague title like Update README.md).
• My pull request targets the master branch of Chapter.

Closes #XXXXX

Users should be able to get directions to the venues of events using map applications on their phones ,the applications use geocoding to convert a text address to latitude and longitude coordinates on the map

[vkWeb]

@trojanpauro In a lot of places street numbers may not be there. Please add address text not null.

[vkWeb]

@trojanpauro Remove street_number and street_name and add address text not null.

[trojanpauro]

i have removed not null from the street number , i think that the address has to be broken down to allow for geocoding .

[apoorv-mishra]

I believe that address column should be a part of venues table instead of locations table. Think of it as how we inquire(hey, where's the venue? address?). That way, 'address' seems to be a perceived(assumed) characteristic of 'venue'. On another note, I'm not sure about the intent of the schema designer. If it is intended to be a flat design, then we can just chug address into locations. If intended to be a 'hierarchical' design around locations, locations takes us only till city and once reached, venues picks up from there(list all venues in NY?).

[leisenstein]

I think we would want latitude and longitude in here too.

[matthewdarwin]

Please have a look at the address schema in OpenStreetMap to have an idea of the variety of ways addresses are represnted. A house number and street name are not universal.

[matthewdarwin]

also "zip" is very american. (postal code is used most everywhere else in the world)

[allella]

Are there any suggested standards for a location, like https://schema.org/Place where we can start with a minimum of the require fields, consistent fieldnames, and add more fields as needed?

[apoorv-mishra]

Also, groups/chapters are generally tied to cities at start(not too local, checkout https://study-group-directory.freecodecamp.org/), and latest schema(https://raw.githubusercontent.com/freeCodeCamp/chapter/29db79781ef834fbf0083d5be49e294b2458a611/data/schema.png) reflects that too(see groups to locations linkage via location_id).

[apoorv-mishra]

@allella Apart from what we already have, I feel that latitude, longitude and address as a text field should do it.

[allella]

I'm sure we can include a lot of fields. I'm mainly suggesting naming the fields based on a standard, like schema.org objects, where it applies. That will help with future SEO efforts and also should help resolve questions about zip vs postalcode and such.

Also, it might be worth taking a glance at similar open-source projects to see if their schema reveals any tips
https://github.com/GetTogetherComm/GetTogether
https://github.com/eventoL/eventoL

[allella]

https://schema.org/PostalAddress may be the more applicable one for picking consistent field names that are flexible enough to handle international differences.

[allella]

Basically, it looks like if you want a flexible address then field names below should allow for differences between countries, then Schema.org uses

• 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

[vkWeb]

@allella Join me on #72. Let's sort this out.

[allella]

And the Geocoding fields for Schema.org basically just add latitude and longitude

[jacobbogers]

Here are format of addresses for each country wiki
there is also a document of the International Postal System

[allella]

#276 (comment) brought up that the locations don't have a street address or the geolocation talked about here and on #72 .

@jacobbogers@vkWeb@apoorv-mishra@trojanpauro do you have time continue with a contribution to make the locations more complete for the MVP?

[vkWeb]

@allella It's not clear to me what needs to be done. Can you specify the task?

[allella]

@vkWeb to some degree, the next steps need to be figured out.

There's a locations table. Both the chapters and venues are related to this table. However, it doesn't hold enough information for a venue, like a street address and latitude / longitude to help a user with directions.

I'd previously mentioned the schema.org address and geolocation as a way to help with the field names and keep them consistent with standards. Those fields were not added in this PR, so I hoped to revive the activity and get a new PR going.

It's not 100% clear if the location information needed for chapters is the same as venues. For instance, if a chapter is only going to have a city / locality, region, and country for a user to search chapters in their area, then perhaps the street address and geolocation information needed for a venue is not part of the same table.

Also, I suspect we might want an optional URL to a venue.

Does that help?

[vkWeb]

@allella Ohh. Thanks for the detailed explanation on the matter. I would suggest going with schema.org's postalAddress: https://schema.org/PostalAddress

It's not 100% clear if the location information needed for chapters is the same as venues. For instance, if a chapter is only going to have a city / locality, region, and country for a user to search chapters in their area, then perhaps the street address and geolocation information needed for a venue is not part of the same table.

The solution to this is to have locations table hold all the possible fields like streetAddress, addressRegion, etc. (nullable set to true). Then chapter and event venues can reference locations without any conflicts.