One area where OHM has struggled is in the best way to depict labels for areas. Should they just show a name, or should they include the time period of the borders, etc.? And, should the name=* tags include year information? (preferably not! - don’t duplicate the data on the same object, no?)
The problem with some of the labels in OHM right now is that they include the period that the borders were relevant, which can be confusing, as the entity being labeled might have been for a much longer period, or maybe it was the last or the first boundary, but you’d never know from the label.
So, maybe the community has some thoughts?
Implementing new labels that include more metadata might take a bit of work to implement, to make sure the information makes it from the osm database to the vector tiles, but having community feedback would be very valuable.
Also - should everything have this type of option - schools, parks, etc., or just “big” objects? Should it be an option for the mapper to include?
Starting point for alternatives to generate feedback - note: not all info would have to show up at all zoom levels. And, bigger labels means more possibility for overlap, which can be a real problem in denser areas or when mapping two objects with similar status, but vastly different size.
I personally would lean towards no date at all on labels, because the slider tells you date & if you want to know more you can always inspect the future in question.
I am curious to see if anyone else has opinions though, maybe I’m missing a key use case where date labels are particularly useful.
I also think that labels should not show dates, in order to make the map more pleasant to look at. Having dates in the name=* tag of relations (such as administrative boundaries) on the other hand can be useful for mappers who want to organize them into a chronology.
I also think no dates on labels would be ideal, given that the timeslider is providing the exploration of time, so a user can explore when things disappear and reappear, and if they really want to know, they can utilize Map Data Data Exploring option in order to look at specific start/end dates.
Empire labels themselves is definitely interesting. Given they are broader than countries, the current label visual hierarchy standards (based on admins from towns through states through country levels) would be to increase size, but I think that it could be effective to label empires along their boundaries with repeating labels.
Of course, with the new discussions of having styles have different purposes, it could also be that it would be fine to have very large labels for empires, given that an administrative map focusing on sovereignty and human locations only probably would have less data interfering with labels. So… depends on that too!
This is a good point and possibly off-topic, but good for the style designers to know. Right now, the “Map Data” and “Query Nearby Features” are a pretty unfriendly way of inspecting what’s on the map. It requires selecting a different mode of engaging with the map and generating a weird list of hopefully what you want to see. So, relying on that may not be the best way for users to extract that start_date and end_date info as a matter of curiosity.
It’s just dawning on me (light bulb over a caveman’s head) that we could have a more dynamic way of inspecting what’s on the map. @Minh_Nguyen - any thoughts on how to improve the interaction model?
The next release of iD will automatically append the start_date and end_date to the label of any feature. This will make it easier to arrange the members of a chronology relation without having to fudge the name tags.
A future enhancement could sort the members automatically when adding a member to the relation. (This is a bit tricky because iD doesn’t download all the members of a relation by default to know what their dates are.)
The website also needs to be modified similar to iD:
I agree, most mappers and end users won’t know that they can right-click anywhere on the map and choose “Query features” to search for whatever is under the mouse cursor. The user experience would be better if the user could simply point and click a feature on the map to see its details. This would be much more feasible once we replace Leaflet with MapLibre GL JS:
I think there’s some merit to the idea of showing the dates associated with a feature in a small gloss. This would enable the user to glean the timespan of prominent features at a glance. It could also be an important disclaimer where start_date is really just a placeholder for whatever is in start_date:edtf. But we’d need to weigh this benefit against the risk of information overload. I can’t be the only person whose eyes glaze over when confronted with lots of dates. The same GL JS upgrade that would enable point-and-click inspection would also enable us to show the date of a feature only when hovering over it or only when animating the time slider.
Minh, is this auto append process only seen in the editor, and what if the member has no label (I assume you are talking about the name=* tag)? Label/names are problematic because they appear on the map where you don’t necessarily want them, e.g. I labelled/named the river areas I am working on so that I could track them in the relations, but now I have labels all over the map. I will delete all the label/names when finished editing.
iD only appends the dates to the names for the purpose of drawing a label on screen; this doesn’t affect any tags that get uploaded.
I put in a special case to omit the dates from an unnamed feature’s label, since I didn’t want to greatly affect label density on the map in iD. For example, I recently mapped a number of street trees along a major street in my city, all of which have the same date; it would’ve been weird to see the same date plastered all over the streetscape as a result. Maybe the date labels should be enabled for certain features, or it could be a preference in iD’s seldom-used Preferences panel. I suggest filing a feature request if you have ideas about how to limit the date labels to where they’d be useful.
Map Data Data Exploring option in order to look at specific start/end dates.