<div dir="ltr"><div>Hi,</div><div><br></div><div>referring to uncertain dates:</div><div><br></div><div> At the moment, there is unluckily the incentive to give exact start and end_dates even if it is not known. That's a bit discomforting to me.<br></div><div><br></div><div>I also would advise against the procedure to give an approximate - but technically exact - start_date with a note that it is approximative. Instead we should agree on one form of tagging of uncertain time ranges and then strongly recommend to use it if there is uncertainty. Is there anything speaking against the form "1900-03-07..1905-04-09" / "1900..1905"? Maybe machine reading issues?<br></div><div><br></div><div>Further, there is the question of rendering: The idea, that the time slider should process an average date sounds not that bad, but in many cases, a start_date-range is very big. For example, when there is a single dated photo/map where a building appears. It could be built any time before that photo/map was created. Computing an average date out of 0..1905 or something doesn't make sense in my opinion. To give some more possibilities at least: There could be the option to show "maybe-objects" or not. If it is activated, in the years 0 to 1905 the building is shown, if not, it will appear on the map in the time slider year 1905 and after. Further, objects could be given a mark (colouring; higher transparency; a question mark symbol; ...) during the period in question.</div><div><br></div><div>As you see, I neither have a perfect solution, but we should discuss that topic with some priority because there is the danger that many objects get a seemingly but incorrect exact date as a result of mapping for the renderer.</div><div><br></div><div>Kind regards,</div><div>Paul<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 13. Juli 2020 um 15:06 Uhr schrieb Hannes Röst <<a href="mailto:hannesroest@gmx.ch">hannesroest@gmx.ch</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:Verdana;font-size:12px"><div>Dear Jeff<br>
<br>
Yes, I figured that much is still in flux. This is of course exciting and means that we can still shape some of these answers.<br>
<br>
On Sat, Jul 11, 2020 at 3:58 PM Jeff Meyer <<a href="mailto:jeff@gwhat.org" target="_blank">jeff@gwhat.org</a>> wrote:<br>
><br>
> Hannes - Welcome aboard & THANK YOU for your reat questions & initiative. Please be patient or provide your opinions, as we haven't figured everything out yet.  I'll do my best below. Anyone else, please join in!<br>
><br>
> p.s. love your old mapping!!<br>
><br>
> On Fri, Jul 10, 2020 at 2:22 PM Hannes Röst <<a href="mailto:hannesroest@gmx.ch" target="_blank">hannesroest@gmx.ch</a>> wrote:<br>
>><br>
>> Dear list<br>
>><br>
>> Hi, I have just started to map with OHM and it has been a fun ride. I do have a few questions:<br>
>><br>
>> 1. Mapping pre-historic buildings, I am not sure how to encode times before 1582 since they require additional conventions according to ISO 8601 [1] and it would be great to clarify this, I have now used the conversion of 3384 AD = -3383, see my buildings here [2]. Can you comment on whether this is the right way to do it? It is counter intuitive to be "one year off" but I think its most consistent to use ISO 8601, however this should be clarified on the wiki.<br>
><br>
><br>
> I myself just noticed that 1582 issue the other day. I think a "loose" answer is that we loosely use the 8601 format (i.e.., YYYY-MM-DD) for entering our tags, but not for processing those tags, if that makes sense.<br>
> So, your example is likely fine, but I am curious - did you mean "AD" or "BC"? And, so we have year-level precision that far back?<br>
><br>
<br>
Sounds good, using ISO 8601 makes most sense but we should mention<br>
this on the wiki otherwise we may run into issues with people entering<br>
Julian dates. I am not sure what you mean with "not for processing those tags" ? I guess for the renderer it mostly wont matter since we only deal with year-accuracy.<br>
<br>
Sorry, I meant 3384 BC = -3383 ( and yes, we do have year level precision<br>
using <a href="https://en.wikipedia.org/wiki/Dendrochronology" target="_blank">https://en.wikipedia.org/wiki/Dendrochronology</a> that is anchored<br>
up to 11 000 before present and this can be accurate to even less than<br>
a year (sometimes it is known that a tree was cut in Winter of a<br>
certain year; but not necessarily when the building was built since<br>
you can cut a tree and build something with it next year). Radiocarbon<br>
dating is actually calibrated against dendrochronology up to that<br>
point since its a "gold standard" method. So its probably a good idea<br>
to think that OHM could go back thousands of years and not just<br>
hundreds -- and a fun challenge: what is the oldest feature we can add<br>
to OHM? Probably some cave drawings? The set of buildings that I<br>
mapped were only present for a few years but researchers managed to<br>
piece together the date of construction for each and the date when<br>
they all burned down.<br>
<br>
>><br>
>> 2. I noticed on the mailing list some discussion about OSM imports and I cannot help but notice that major geographical and political features are missing in the areas I am interested in (eg lake Constance and Lake Ontario) and to me it seems like a reasonable idea to get things off the ground and tag imports with "licence=ODbL" for things like country boundaries and mountains/rivers/lakes. I am not sure whether spending a lot of time re-mapping geographical features simply so that they are under CC0 is a good use of (my) time. I am happy to have all content by default under CC0 but it seems like we would duplicate a lot of work simply for the purpose of having it under CC0.<br>
><br>
><br>
> I am guilty of this crime. I'm not sure why, but when we did an initial planet import from OSM, a loooooong time ago (~2012), I fear we (I) missed some pretty important natural features. In particular, inland lakes. These need to be restored and I would suggest the best way to get them fixed is a) import from a CC-BY-SA source like <a href="http://fosm.org" target="_blank">fosm.org</a>. I agree that that's not a good use of your time. How about if you let me know which areas you'd like / that would be helpful, & I'll prioritize adding those myself. We have a ticket for this open here: <a href="https://github.com/OpenHistoricalMap/issues/issues/4" target="_blank">https://github.com/OpenHistoricalMap/issues/issues/4</a>. In addition, there is much more CC0 data available than there was at the time of the initial creation of OSM's data.<br>
<br>
I would love to have<br>
<br>
- Lake Zurich<br>
- Lake Lucerne<br>
- Lake Zug<br>
- Lake Geneva<br>
- Current swiss borders<br>
<br>
Its hard to navigate Switzerland without those :-).<br>
<br>
However, I also saw a discussion on the mailing list in May<br>
(<a href="https://lists.openstreetmap.org/pipermail/historic/2020-May/001386.html" target="_blank">https://lists.openstreetmap.org/pipermail/historic/2020-May/001386.html</a>)<br>
regarding the licencing policy and some questions whether OSM imports<br>
may be performed or not. It seems that currently the consensus is to<br>
not perform any, but I am wondering whether we are hampering the<br>
project a bit by requiring CC0 and thus cannot use any of OSM current<br>
data (roads, towns, mountains, rivers, lakes). I understand the<br>
concerns with the "viral" nature of ODbL and this is a philosophical<br>
question, but practically I think these points are important: 1) ODbL<br>
has not really hindered the adoption of OSM and major commercial<br>
players like Facebook, Craigslist etc use it without concerns and 2)<br>
does OHM have the man/womanpower to build their own map that is free<br>
of OSM or would it make sense to compromise here just because there is<br>
already so much work done under ODbL and 3) there are advantages of a "viral" licence, namely that it requires people who change the data itself to "give back" and make their changes open but in general people who only display the data will not have to deal with the "viral" nature. Also, the wiki mentions that OSM data may be imported if the correct "licence=x" tag is used, this is a bit confusing in terms of what is allowed and what is not. If you and others are open to discuss, we probably should open a separate thread about this.<br>
<br>
><br>
>><br>
>> 3. Furthermore, I see rivers etc mapped in changeset 1 [3] and I wonder whether that data is truly CC0 or also from some OSM import / satellite (probably depends on how the import was done). I have used ESRI images to trace lake Constance since ESRI is free of restrictions and will produce CC0 content but I dont know about other imaging data and whether it has been used in OHM<br>
><br>
><br>
> Changeset 1 was the initial planet import & you are correct. That likely took place shortly after the OdBL switchover in OSM. This data should not be redistributed in any form util we resolve this issue.<br>
><br>
> Bing and a few others have authorized OHM use of their imagery. Richard Welty can comment on that & he may have already annotated it in the wiki, but I'm not sure.<br>
><br>
>><br>
>> 4. I would like to ask how replaced structures should be handled such as the bridge [4] which was built in 1520 replaced 1828 with another wooden bridge and finally replaced in  1839 with the (current) stone structure. I saw some mention on the mailing list with reference to the date namespace [5] and I wonder whether this has consensus and how to handle a complete replacement -> would it be better to have 3 separate ways here that have independent start/end dates since these are completely different bridges. It seems the date namespace makes more sense if roads change names or importance but is not intended for a different physical object. Personally I would prefer the different ways solution since one could then refer to these entities using a unique identifier for each (eg in Wikidata).<br>
><br>
><br>
> We're currently trying to figure this out. We do not recommend adding the years into the name tag. Right now, I think the 2 approaches are:'<br>
> 1) Do 3 different ways. This is currently a pain for editing, but will eventually be a bit more correct, esp. if the bridges had separate physical spatial geometries.<br>
> 2) Do 1 way associated with 3 relations. This will help ease editing, as there are fewer individual ways, but could allow for different Wikidata tags, names, materials, and other properties. It also gives a more stable OHM identifier for the bridge. The type of relation is still not clear, but we're actively trying to figure that out / open to suggestion.<br>
><br>
<br>
My suggestion would be to use (1) if there are different physical<br>
features present, such as different bridges that were torn down and<br>
replaced. However, there was a discussion about roads some time<br>
earlier and maybe just the name of the road changes, its surface or<br>
its classification (from primary road, becomes secondary if a better<br>
road is built). In that case it seems to make much more sense to use<br>
(2) since all other tags are the same and the way is the same but only<br>
one attribute (name) changed. For example if a road gets paved, I<br>
would really love to use<br>
<br>
surface:1800-1900 = unpaved<br>
surface:1900 = paved<br>
<br>
on roads. I also found that exact duplication of ways is quite hard to<br>
edit in most editors including JOSM and for the road example it would<br>
really lead to some crazy situations. Roads can have many attributes<br>
(<a href="https://wiki.openstreetmap.org/wiki/Key:highway#Attributes" target="_blank">https://wiki.openstreetmap.org/wiki/Key:highway#Attributes</a>) and to<br>
duplicate the way every time one attribute changes seems like a recipe<br>
for disaster. There are currently 30 attributes for roads and some<br>
allow multiple attributes, its easily conceivable how an old-ish road<br>
went through multiple changes in "name" and changes in attributes<br>
"surface" and "smoothness". This issue also applies to towns that have<br>
been around in Roman times and now have an English/German name.<br>
<br>
Regarding wikidata tags: again this may depend on the modelling but I<br>
think both discussed options should be available. Depending on how<br>
something is modelled in Wikidata, a newly paved road may not be<br>
considered a different entity and there may only be one Wikidata entry<br>
for the paved and the unpaved road.<br>
<br>
Just to highlight this: this already leads to a lot of problems, when<br>
you zoom around on the map in Europe in 1850 (default), you see Roman<br>
names such as this:<br>
<a href="https://www.openhistoricalmap.org/#map=11/51.0038/6.9640&layers=O" target="_blank">https://www.openhistoricalmap.org/#map=11/51.0038/6.9640&layers=O</a><br>
<br>
Of course the main issue is software support, this only makes sense if<br>
the rendering software supports it. I see multiple discussions on the mailing list on this problem over the last few years, maybe I need some time to think about this more.<br>
<br>
>><br>
>> 5. How should data from a map best be tagged? I have used the "as_of" tag since I dont know the exact starting time for a road on a map, I only know it was present at a certain time. However, this leads to some rendering artefacts: the roads will be there from the beginning of time, however the bridge for which I know when it was built will suddenly appear in 1520 and before 1520 there is simply a hole where the bridge was [4]. Any suggestions on how to deal with this situation? Would it be better to use "after 1838" for a map produced in 1838, how would that be rendered? (see suggestion here [6])<br>
><br>
><br>
> Right now, the renderer doesn't pay attention to "as_of" - that's more for data enrichment. I would suggest making an arbitrary assignment as to your best guess, and annotate that it needs to be fixed, either with something like: fixme=start_date or start_date:note=estimate.<br>
> We're still trying to figure out best conventions & would love your input!<br>
<br>
in that case I would suggest to implement parsing of approximate dates as well<br>
into the renderer as described here:<br>
<a href="https://wiki.openstreetmap.org/wiki/Key:start_date#Approximations" target="_blank">https://wiki.openstreetmap.org/wiki/Key:start_date#Approximations</a><br>
<br>
however there are many formats on the wiki, but I dont think we need<br>
all of them. However, having *something* would mean a lot. What I<br>
would really love to have is support of a date range, and this happens<br>
quite often with history (e.g. built in the 16th century, built in the<br>
1860s). People already do this (e.g.<br>
<a href="https://www.openhistoricalmap.org/relation/2683539" target="_blank">https://www.openhistoricalmap.org/relation/2683539</a> uses<br>
start_date=1790..1803) and it leads to strange rendering artefacts,<br>
such as the "Markgrafschaft Baden" being present in Roman times and<br>
pre-historic times (since the renderer does not understand its start<br>
date, its just there from the start of time). My suggestion is to just<br>
use the average time of a range, e.g. 1900..1910 renders the same as<br>
as start_date=1905 for example.<br>
<br>
For example, I have a map of 1838 and I would like to annotate<br>
"start_date=before 1838" so that the roads show up in 1838 but I dont<br>
want to put a hard date "just for the renderer"  (see<br>
<a href="https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer" target="_blank">https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer</a>) and its<br>
very unlikely all the roads in the map were built exactly one year<br>
before publication of the map :-) After this I can go back and collect<br>
more evidence and collect more accurate "start_date" for roads where<br>
its available. So we could potentially model this all with the ".." notation, using either 1860..1870 for the "built in the 1860s" and using ..1837 to indicate "before 1838".<br>
<br>
><br>
>><br>
>> 6. Similarly, I have traced the data of a river from a map of 1838 and the course of the river has changed quite a bit. Now using the "as_of" tag now means that there are 2 rivers displayed in the map which is not really what I wanted. [7] Any thoughts on best to handle this? Of course I could choose an arbitrary start/end date to switch from one river to the other but without more information this is not optimal either.<br>
><br>
><br>
> You should add a "start_date=" to the current river path that matches the "end_date=" of the old river course. This might also be handled by relations, where the relation stays constant, but the river geometry changes on the member relations underneath.<br>
><br>
> I think I've done something similar (without the relations) at:<br>
> Krakow (actually different... just added a split to the river: <a href="https://www.openhistoricalmap.org/#map=14/50.0601/19.9400&layers=O" target="_blank">https://www.openhistoricalmap.org/#map=14/50.0601/19.9400&layers=O</a><br>
> Seattle (partway through changing the course of the Duwamish... need to fix this): <a href="https://www.openhistoricalmap.org/#map=14/47.5413/-122.3250&layers=O" target="_blank">https://www.openhistoricalmap.org/#map=14/47.5413/-122.3250&layers=O</a><br>
><br>
<br>
I have done that now after doing more research on when actually the<br>
course of the river changed. Again, in this case it was available but<br>
it would be useful to put a date on this, e.g. if I have two maps that<br>
I could say "the river changed sometime between 1838 and 1915" and I<br>
dont have to put in known false information just for the renderer to<br>
work.<br>
<br>
>><br>
>> 7. I have another bridge where there is clear evidence (dendrochronological) when it was built, around 150 BC, but unclear when it was destroyed. We only know that its defunct today, so it was destroyed somewhere between 150 BC and 2020 BC, how should that best be tagged?<br>
><br>
><br>
> Hmm... tough one. I think we need a tag like fixme=end_date, but maybe something that implies more of a hunt / research project than that little tag would hint at.<br>
<br>
I dont think that would help here since the best archaeological data<br>
does not indicate an end date. Basically it is impossible to figure<br>
out after the fact when exactly a bridge collapsed especially for a<br>
Roman bridge. I have some detailed information on that bridge<br>
(<a href="https://data.geo.admin.ch/ch.astra.ivs-nat/PDF/TG00360204.pdf" target="_blank">https://data.geo.admin.ch/ch.astra.ivs-nat/PDF/TG00360204.pdf</a> ) from<br>
the local government but given they only found some wood in an<br>
archeological dig that they could date when it was cut, we simply may<br>
*never* know when exactly that bridge disappeared. So the only<br>
information we have is that is was there during Roman times and not<br>
any more once historic records picked up again. So unless we go out,<br>
dig up more of the bridge and stumble upon some information that helps<br>
us date when it collapsed, we will likely never actually know. I think this issue would also be fixed by adding proper "uncertainty" into the tags and have the renderer understand it.<br>
<br>
Best<br>
<br>
Hannes<br>
<br>
<br>
><br>
>><br>
>> Best regards<br>
>><br>
>> Hannes<br>
>><br>
>> 1. <a href="https://en.wikipedia.org/wiki/ISO_8601#Years" target="_blank">https://en.wikipedia.org/wiki/ISO_8601#Years</a><br>
>> 2. <a href="https://www.openhistoricalmap.org/relation/2690490" target="_blank">https://www.openhistoricalmap.org/relation/2690490</a><br>
>> 3. <a href="https://www.openhistoricalmap.org/way/4515328" target="_blank">https://www.openhistoricalmap.org/way/4515328</a><br>
>> 4. <a href="https://www.openhistoricalmap.org/way/198531945" target="_blank">https://www.openhistoricalmap.org/way/198531945</a><br>
>> 5. <a href="https://wiki.openstreetmap.org/wiki/Proposed_features/Date_namespace" target="_blank">https://wiki.openstreetmap.org/wiki/Proposed_features/Date_namespace</a><br>
>> 6. <a href="https://wiki.openstreetmap.org/wiki/Key:start_date#Approximations" target="_blank">https://wiki.openstreetmap.org/wiki/Key:start_date#Approximations</a><br>
>> 7. <a href="https://www.openhistoricalmap.org/#map=16/47.5895/8.9490&layers=O" target="_blank">https://www.openhistoricalmap.org/#map=16/47.5895/8.9490&layers=O</a><br>
>> 8. <a href="https://www.openhistoricalmap.org/way/198531929#map=18/47.55831/9.09103&layers=O" target="_blank">https://www.openhistoricalmap.org/way/198531929#map=18/47.55831/9.09103&layers=O</a><br>
>><br>
>> _______________________________________________<br>
>> Historic mailing list<br>
>> <a href="mailto:Historic@openstreetmap.org" target="_blank">Historic@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/historic" target="_blank">https://lists.openstreetmap.org/listinfo/historic</a><br>
><br>
><br>
><br>
> Regards,<br>
> Jeff<br>
><br>
> --<br>
> Jeff Meyer<br>
> 206-676-2347<br>
> osm: Open Historical Map (OHM) / my OSM user page<br>
> t: @OpenHistMap<br>
><br>
><br>
><br>
></div></div></div>

_______________________________________________<br>
Historic mailing list<br>
<a href="mailto:Historic@openstreetmap.org" target="_blank">Historic@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/historic" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/historic</a><br>
</blockquote></div>