Sorted how locations will display on a post publicly today. I really like the automatic zoom as your mouse gets closer to the center.

Managed to get reverse geocoding (looking up the address from for a given coordinate) working when you click the map. I've also hooked up the remove location button to...remove the location.

There's two last tweaks I need to make:  1) I'd like a reset button to reset your location form to it's initial state; 2) The address form is going to be hidden entirely and the values will be displayed as a single line of text below the map to emphasize that the address is "just meta".

Mapping is coming along nicely. Today I got markers to move by clicking the map, serializing changes to geo-json for saving, and integrated leaflet-geosearch. 

Next I'd like to automatically fill in the address when available, but in order to do so, I must first normalize the Nominatim addressdetail response to match up with my fields.

 After making it so I can update my location for an entry, I started to integrate Leaflet, rather than use the default GeoDjango OSM widget. It's my first time working with Leaflet, so it's a bit slow going.

I've managed to get basic display of the map working as well as clicking to move the point. I think if I can get the point to be powered by some GeoJSON in a hidden textarea, I should be able to once again set and update locations on entries.

I got locations saving to notes properly. Next up allowing you to update locations when editing an entry. When saving I initially ran into the following error:

spatalite no such function: lwgeom_version

The issue was that Django's PointField default projection is 4326, which is used for spherical references e.g. Google Earth. However, I'm displaying a flat service (an OSM Map), which uses a different projection 3857.  I fixed this by changing my database to match my most common display.

from django.contrib.gis.db import models as geo_models
...
point = geo_models.PointField(geography=True, srid=3857)

First steps in displaying location in the Tanzawa admin interface. Default point is Mount Tonodake in the Tanzawa mountain range. Still using the default OSM map included with GeoDjango.

I imagine this will be a Leaflet powered map in the end. I've got a couple of different ideas surrounding the location interface:

Handling "related" data about an entry is proving to be a bit more difficult than anticipated. It could be the way I've chosen to validate data. For my micropub endpoint I'm using DRF for request validation and then transform and pass that data to the Django Form I use when posting with the admin interface. The Django Form is important because it's where I prepare the actual records that get saved into the database.

Handling this complex data with DRF in micropub feels natural – mostly because DRF Serializers handle nested data natively and microformat data is nested. Django Forms are made for regular forms (single level) and don't handle nested data.

Flattening all nested "related" data (like locations) and putting it into a single form isn't a good long-term solution. That said, I do flatten nested data for content as it's required to create an entry. However using both Forms (for base entry data) and DRF serializers (for related data) in both my admin views and micropub endpoint seems like a bad architecture as I'm mixing concerns.

Rather I think it's I need to start introducing Formsets for related data for my webforms. And then have my micropub endpoint continue doing what it's currently doing: sanity-check  the request, transform it into format that matches my web form request, and then process as usual. This will also keep the data flowing a  single direction:

micrpub request: Micropub -> DRF -> Form Input -> Form -> DB
admin request: Form Input -> Form -> DB