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".
When I think about what I want in a map on a blog, my needs are fairly basic: posts that have a location should show a map with an indicator where the post was made and if I'm unsure of the coordinates (a guarantee) , I should to be able to search and find it on a map.
If the location too new or uncommon, it may not show up. In that scenario finding the location on the map and selecting in manually isn't large ask.
While maps are a an important point of many posts: that new coffee shop I checked in at, the location of that cool bridge in a photo I shared, or that time status I posted looking out the window of the shinkansen – they're not central or even wanted in most posts.
Sharing a thought, a checkin, or a photo is the point.
One day there might be public facing features where maps play a prominent role and are the point of a post. But until then the big maps will be reserved for when you're authoring a post and can use the extra space to pan and zoom, and on the public side, they'll be smaller and out of the way – they're not the point.
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.