The “location” element of a post has to contain the “lat” and “long” element by now - Couldn’t this dependancy be dropped?
Background: When transmitting events we know the location, but we don’t have to know the exact geo location. This is no problem for links to OSM, since they will search for the address as well. So it would be great if either “lat” and “long” or “address” has to be defined.
This won’t work without refactoring the diaspora* UI. We show a map for all locations and that wouldn’t work if we only know the address.
The link to OSM just had to contain the location instead of the geo coordinates, see for example:
https://www.openstreetmap.org/search?query=Trump%20Tower,%20New%20York
We don’t link to OpenStreetMap but show a map with a marker at the top of the post. We could try to find the correct coordinates for a location, but for some locations there could be more than one search result and some others (like “my secret location”) won’t return a result at all.
See https://pod.omgsrsly.net/posts/247205 for an example.
Don’t you think that this could be done solely upon an address as well? Aren’t you using some OSM functionality fort that as well?
Nice example that you have posted. That was an interesting game there.
How would you display “my secret location” on a map if there are no coordinates attached to it?
We get the coordinates from the browser and get the address by sending the coordinates to OSM Nominatim. For the maps we use Leaflet and OSM based map tiles.
Currently diaspora needs both to display the location (as @svbergerem mentioned). But we can maybe make it optional and if there are no coordinates, just display the address as text and don’t add a map, and if there is no address, we can display the coordinates as fallback. What do others think about that, should we loosen the constraints and use fallbacks instead?
But then you still need to wait until most of the pods use a version without that constraint, or your posts would be rejected.
As a side note: Yes, we probably could use the plain address and look that up every time, but that’s bad. Even right now, our use of Nominatim is technically illegal according to their usage policy, and I really don’t want to add more requests. 
For data normalization I think it is better to split those two fields instead of writing them into one field. This makes reporting, data mining and lookups much easier. My vision is that you e. g. could select all photos taken in your Florida vacation trip in May 2016 or all messages sent from your second home in Berlin. Our database should be independent of OpenStreetMap, so we can switch to another provider at any time. WGS84 is a standard with wide acceptance. Implementing it requires two separate fields for longitude and latitude.