Removing longitude and latitude from the schema

[mkampik]

I'm wondering whether it might be a good idea to remove the longitude and latitude properties from the schema.

If this information is stored in the schema itself (and assuming we don't want every space to figure out and enter their longitude and latitude manually), then any forms developed against the schema would need to convert location text (address) into geographic coordinates.

Whilst this can obviously be done, it adds complexity to an otherwise relatively easy task which 3rd parties might want to do themselves.

If longitude and latitude aren't stored in the schema, they can be derived from the address only where actually necessary (in the maps interface), through usually built in geo-coding APIs.

[rrbaker]

No disagreement at all for users even considering to do their own lat/long lookups. I think we'd see considerable drop-off in submissions.

So while I considered the same, the argument I landed on to keep it in there, however, is that many locations around the world don't have an exact address and can't offer anything beyond a relative location, i.e. "red building down the street from the petrol station in X province." While I can't point to a specific example off the top of my head in our current data, I've certainly received driving directions like that in more than a few countries.

If the form displayed a map based on a realtime geonames search of city/region that the user could then further specify by dragging the point to a more granular location (I think Anna may have also suggested this in our datafields doc), we might be the best of all scenarios:

• exact point from a clear address
• exact point from a admin 2 or 3 level with user adjustments (dragging the point on the map)
• regional point from those who want to give some idea of location but not exact if there are an potential security concerns (also not sure we have that case but hypothetically)

I don't totally enjoy the idea of further complexity on the form either, especially since it's a combination of trying to generate this from directly from the schema and then inserting additional functionality over that library (alpaca). Might have to pick one or the other to keep it sane or keep myself from writing a novella of inline comments. However, perhaps better thinking all the way toward the end-user's UX perspective, limiting false positives on automated address lookups with a little more effort on the technical and submitted ends would yield more accurate results.

Further thoughts? Certainly leaving this open.

[annawb]

I'd agree with Rob here-- there are tons of spaces who already use addresses like "behind the school," "down the street from X," etc. There are also many cities that have multiple streets with the same names. I took my suggestion of dragging to a granular location from the fablabs.io site, which does this well for adding new spaces (and we can use their code if it's compatible)...

As per Chinmayi's suggestion, what about extrapolating from actual geolocation to http://what3words.com ?

[mkampik]

Hi both! Thanks for getting back so quickly. I wasn’t aware that addresses aren't accurate enough in all countries (although in hindsight makes perfect sense!). In that case that more than justifies leaving long/lat in the schema and think the dragging of a marker to the desired location is a good solution to this problem.

I would agree on prioritising accuracy and UX over the ease of implementation promised by something like alpaca. Given the unique requirements, it might well be easier to develop something custom.

I can definitely see how “addresses for everyone”-type services can increase accessibility. I suppose it raises a similar question as to whether it needs to be part of the schema. We are duplicating information in the schema given that it can be derived through longitude and latitude on an application level.

If it were to happen on the application level alone, there would be no harm in supporting the most adopted alternative services too. (some here: https://github.com/roberdam/Xaddress)