Working a bit on how to integrate location information into a post. Right now I've got the location name appearing in the byline. Some day, I imagine this will be a link to search page that'll show you all posts within a given radius of that area.
Initially I had planned to have the map display on the right hand side of the post, in the "meta" column. But that felt like it's separate from the post. Moving down into the footer and increasing it's size a bit has helped it feel a bit more "at home".
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:
- 1. I'm probably not going to display the full address form and instead have a single unified search form + map when no location is set.
- 2. Once an address is set, I may show it in plain text below the map. Perhaps there with an "edit" link to manually override the address for whatever reason.
- 3. I'll probably do an initial release as-is (using OSM) and then focus one of my later sprints on really polishing the mapping 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
Started working on support for checkins (posted via backend micropub only) and adding locations to any post kind. I'm not sure how I'll expose adding a location to a post. One way would be get your current location. The other would be to let you just pick a point on a map. Or maybe default to your current location and let you adjust it?
Since my coordinates are all stored as a geo-django PointField, my hope is that it will allow me to create fun little apps on top of Tanzawa. "Make me a rollup of my checkins in Yokohama", "Show me my photos from Texas", and so forth.
As you may be able to tell from the previous post I just launched Bookmark support in Tanzawa. I'm contemplating if I shouldn't add a dedicated "bookmarks" page that just makes a long list of bookmarks, but for now it's good enough.
I realized one of the hardest parts about microformatting your html is making sure you haven't broken it in some subtle way. Mine were broken. I added some tests that verify a) I fixed them and b) they won't get broken again.