Latitude and longitude fields are strings

[drkane]

The location.latitude and location.longitude fields are specified as strings - should these not be floats as floats are the only valid values.

ref #38, https://github.com/ThreeSixtyGiving/standard/blob/master/schema/360-giving-schema.json#L137-L148

[caprenter]

I suppose in theory you could express e.g. latitude as: 40 deg 44 min 54.36 sec N - but this probably not the intention of the schema.

This would (probably) be a backwards incompatible change - but afaik not many publishers have this data and so not many consuming applications will be reliant on it yet.

I think it's worth asking for this to be considered for change soon tho.

[timgdavies]

I think given the other errors, and providing we don't find any publishers using degrees, we should consider this a bug (my bad on original schema writing!) and consider it for a bug-fix release.

[drkane]

I've found one publisher who's used this field on beneficiaryLocation.latitude/beneficiaryLocation.longitude - Blagrave Trust. They've used the decimal format for all the values, so it should be compatible with changing to float.

[BobHarper1]

There are three publishers using latitude and longitude fields from the schema: Blagrave, Power to Change and SCVO Digital. At a (very light) skim all look to be using floats so I don't think anything is going to break by changing string to number

[morchickit]

At the stewardship committee, we discussed why to allow only float and not both float and string. We then explain that having string can cause breakage and people can add characters, hence why we want only floats. @drkane - please add it I'm missing something.

[BobHarper1]

def agree @morchickit. Some coordinate systems (there are many) do use characters, but they tend to be relatively obscure. Again, if we do specify using WGS84 a la #216, then it's definitely float only.

[BobHarper1]

This is now changed as per the schema: lats and lons must be numbers