Create "the present" from Openstreetmap

[yopaseopor]

Create "the present" from Openstreetmap. Making something similar to a import data from Openstreetmap we can create the present of our zone and then add the OHM tags to make it available and renderizable.

[MrMap13]

I am also in agreement about doing this sort of idea. To expand on your concept, I would propose that the start date be set to 2021 (the present year at the time of this posting). As time progresses into the future beyond 2021, features from our current year could be removed and replaced by newer ones if the case arises. I don't think this should apply to the largest scale things such as international borders. Most likely smaller features like traffic lights and restaurants.

[danrademacher]

This is not my area of expertise by a long shot, but wanted to chime in here with what I do know: We're trying to have OHM include as much Public Domain / CC0 data as possible, but any automated import from OSM would also bring in their ODBL license, and then those items need to be handled with item-level licensing. I imagine this is a solvable problem, but these license issues can get thorny.

[yopaseopor]

Cc0 is not always possible. Making shots of OSM would bring us the 'present' of OHM and make bridges between users and data usable to recover the history of the things.If not, starting from 0... is silly: same ways with same key=values all around the world?

Salut,mapes i història (health and maps and history) yopaseopor

El dt., 17 d’ag. 2021, 2:58, Dan Rademacher @.***> va escriure:

This is not my area of expertise by a long shot, but wanted to chime in here with what I do know: We're trying to have OHM include as much Public Domain / CC0 data as possible, but any automated import from OSM would also bring in their ODBL license, and then those items need to be handled with item-level licensing. I imagine this is a solvable problem, but these license issues can get thorny.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenHistoricalMap/issues/issues/275#issuecomment-899914292, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIB4VU2FZUEU2QBYTFCLGLT5GX2NANCNFSM5CFCKWOQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[flha127]

I would prefer merging both databases and projects, this way we could use already existing OSM data and make things way much simplier. The fact is, we don't have enough contributors to make a whole new database. For exemple I work on railways and public transport in Belgium and France and I can't simply re-make everyting from scratch, on the other hand it's often discouraging as I contribute to both OSM and OHM and have to make things twice on both databases.

Of course we could upload OSM data in OHM but it would be nearly impossible to keep all this data up to date with OSM.

Merging both database would take time but it's much less difficult than re-creating a whole new database from scratch.

The issue is how would OSM handle OHM content in the simplest way possible ? in such a way that OSM database and renderers are little or not modified.

1 The only modification to the OSM project would be to add a filter in renderers : "HIDE if end_date<CURRENTDATE". No database modification would be needed within OSM.

And we add a filter in OHM renderers : "HIDE if end_date or start_date are not used" this way we only show elements with start_date/end_date tags.

2 The other things would be to make different tag names for current data and historical data , but again no change to the OSM database would be needed, this could be done in a simple way by only using tags with numbers at their end for historical data : lets take for exemple a road which current name is "Blue street"

OSM data should give this : name=Blue street

However this street was before 1990 named "Red street" and before 1950 "Yellow street" so OHM data should looks like this : name=Yellow street name2=Red street name2_start_date=1950 name3=Blue street name3_start_date=1990

Same street in a merged database

// Data for OSM renderers name=Blue street - no change // Data for historical renderers name1=Yellow street - it's no longer name but name1 this way OSM renderers shouldn't considerer historical data. name2=Red street name2_start_date=1950 name3=Blue street name3_start_date=1990

As for licensing issues, all CC0 data could be imported, and we could ask members if they allow their work to be switched from CC BY SA 4.0 to ODBL.

[yopaseopor]

I think your approach is correct. I have seen lots of projects (OHM is not an exception) to break apart from OSM, collect and use their data outside OSM and then...die and disappear (and the work made by the project also). Other third projects outside of osm but using the data would prevail because the project can die but the data is also inside OSM so somebody with a little bit knowledge would show again this data. In OSM there are some approaches to use some date/time data. You can read here:

https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

I have used widely https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Date_namespace_suffix_as_.22keyname:DATESPEC.3D...22

I would leave keys and tags that are not compatible with OSM . I would convert start_date and end date in something like the above tags.

Also we can do some renderer like this with some topics which change the way to show the data:

https://yopaseopor.github.io/osmhistoricmap/#map=18.224/42.26818/2.96101/0&Topics=01000000 (II Spanish Republic) https://yopaseopor.github.io/osmhistoricmap/#map=18.224/42.26818/2.96101/0&Topics=00100000 (Spanish Dictatorship 1939-1975)

Also this render "understand" from 0 to 2020 data you may found inside OSM. OSM will not erase existing data about ruins, about no-more-existing business, or old names well tagged. Do we need other database rather than OSM's ? Well, If we need it we will have to start in some day with the present. Importing OSM data is not possible due to difficulties of licenses? Make it the same to avoid it. OHM is so small and we need data to make the present. Without present will not be past or future.

Time is running, I think we have to discuss it. Would it be possible to start the present some day on OHM?

yopaseopor History and Maps.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Libre de virus. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Aug 20, 2021 at 5:02 PM Dldwg @.***> wrote:

I would prefer merging both databases and projects, this way we could use already existing OSM data and make things way much simplier. The fact is, we don't have enough contributors to make a whole new database. For exemple I work on railways and public transport in Belgium and France and I can't simply re-make everyting from scratch, on the other hand it's often discouraging as I contribute to both OSM and OHM and have to make things twice on both databases.

Of course we could upload OSM data in OHM but it would be nearly impossible to keep all this data up to date with OSM.

Merging both database would take time but it's much less difficult than re-creating a whole new database from scratch.

The issue is how would OSM handle OHM content in the simplest way possible ? in such a way that OSM database and renderers are little or not modified.

_1. The only modification to the OSM project would be to add a filter in renderers : "HIDE if end_date<CURRENTDATE". No database modification would be needed within OSM.

And we add a filter in OHM renderers : "HIDE if end_date or startdate are not used" this way we only show in OHM elements with start/end tags.

2. We should also need to adapt OHM tagging so as not to have an influence on OSM renderer, this could also be done in a simple way by only using tags with numbers at their end for historical data : lets take for exemple a road which current name is "Blue street"

OSM data should give this : name=Blue street

However this street was before 1990 named "Red street" and before 1950 "Yellow street" so OHM data should looks like this : name=Yellow street name2=Red street name2_start_date=1950 name3=Blue street name3_start_date=1990

Now for OSM data not to considerer "historical" tags we should only use tags with numbers at its end :

Same street in a merged database

// Historical data name1=Yellow street - it's no longer name but name1 this way OSM renderers shouldn't considerer historical data. name2=Red street name2_start_date=1950 name3=Blue street name3_start_date=1990

// Current data (OSM) name=Blue street

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenHistoricalMap/issues/issues/275#issuecomment-902757546, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIB4VU5FFFJAMI22V57T7DT5ZVA7ANCNFSM5CFCKWOQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[flha127]

If I remember OHM's time slider is a variable that acts on data rendering. "key:YYYY-YYYY"=value format works well with renderers for a specific date or a range of dates, but I don't think it can works with a variable, only start_date + end_date do.

_But if it does it should be use in place of key=value + start_date + enddate.